Лекция 7 Диагностика качества iptv

Вид материалаЛекция

Содержание


Измерения уровня ADSL
Контроль режима Multicast
Подобный материал:
Лекция 7


Диагностика качества IPTV


Перейдем к исследованию принципов диагностики качества услуг IPTV. Для этого рассмотрим систему, представленную на рис.6.5, как отдельный технологически независимый сегмент современной сети NGN.

Основной эксплуатационный вопрос, который всегда возникает в услови­ях внедрения новой технологии: «А будет ли это все работать?» Детальный анализ возможных проблем показывает, что в случае с IPTV сомнений более чем достаточно.

Экcплуатационный вопрос можно разделить на несколько ме­нее эпохальных и более прикладных.

  • Способна ли абонентская сеть в должной мере поддержать услугу Triple Play, чтобы абонентам ADSL2+ стала доступна услуга IPTV?
  • Имеет ли транспортная сеть достаточный ресурс для того, чтобы вы­держать взрывоподобный рост трафика, обычно сопровождающий вне­дрение IPTV?
  • Правильно ли выбрано оборудование IPTV?
  • Правильно ли подобран (разработан) контент?


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

А где исследование, там неизбежны измерения и тестирование как обору­дования, так и сегментов сетей.

Рассмотрим, что и как целесообразно тести­ровать в новых для российской практики сетях IPTV.

Анализ четырех перечисленных выше вопросов приводит нас к измери­тельной концепции IPTV, которая состоит из трех уровней (рис.7.1):
  • уровень доступа (в частности, уровень ADSL), где все определяется качеством «последней мили» и оборудованием DSLAM;
  • уровень транспортной сети, поскольку любые нарушения в передачи трафика Multicast, перегрузки в сети, проблемы маршрутизации и пр. -все сразу скажется





Рис.7.1. Три уровня контроля сети IPTV

на качестве картинки;
  • уровень контроля качества самой услуги, где диагностируется уровень качества той самой картинки, которая и является целью развертыва­ния всей сети IPTV.

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

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

Ниже мы отдельно рассмотрим все уровни контроля качества услуги IPTV.


Измерения уровня ADSL


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

Зададимся вопросом, какие нюан­сы необходимо учесть, анализируя потенциальную проблемность уровня ADSL для услуг IPTV.
  • Первая проблема, связанная с услугами TVoDSL, ограничения по поло­се передачи цифровой информации, которые имеет ADSL для каждого пользователя.

Здесь следует учесть, что каждый STB, размещаемый в доме пользователя, требует полосы 5-6 Мбит/с.

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

Уже сейчас во многих домах используется несколько телевизоров, в среднем - 2-3 (отец семейства, мать, дети).

В таком случае на дом не­обходимы 3 STB и полоса передачи более 15-18 Мбит/с, что соответ­ствует самому высокому тарифному плану.
  • Вторая потенциальная проблема связана с фактором нестабильности скорости в канале ADSL. Как было показано в [1] главы 1 и 2, в случае вне­шних воздействий на абонентскую пару, технология ADSL подстраива­ет скорость передачи данных. Даже при использовании адаптивных ал­горитмов SRA, исключающих факты перезагрузки моде­ма, скорость передачи данных в ADSL не может быть постоянной.

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

Только стандарт MPEG-4 позволяет адаптировать скорость передачи, ухудшая качество видеосигнала. Но пока нет алгоритма, который по­зволил бы связать изменение скорости в ADSL с изменение типа коди­рования MPEG.

Следовательно, все рассмотренные выше варианты линейных и нелинейных искажений сигнала могут присутствовать на сети TVoDSL.
  • Третий источник потенциальных проблем - оборудование пользовате­ля и, даже в большей степени, сетевое оборудование - DSLAM. В [1] глава 6 кратко показаны проблемы, связанные с функционированием DSLAM в условиях передачи и приема трафика Triple Play.

До последне­го времени не было ни одного производителя DSLAM, который гаранти­ровал бы работоспособность своего оборудования в условиях интен­сивной загрузки трафиком Triple Play всех портов. Поэтому в цепи от STB к видеосерверу DSLAM может оказаться «бутылочным горлом» и тем самым еще уменьшить итак небольшой для IPTV абонентский ка­нал ADSL2+.

По перечисленным выше причинам уровень ADSL является одним из са­мых критичных для работы сети IPTV.

Если переходить к практике контроля параметров уровня ADSL, то можно сказать, что приведенные выше проблемные факторы ADSL не являются но­выми.

В разных разделах мы говорили о методах кон­троля уровня ADSL, и все описанные выше методики могут эффективно при­меняться для диагностики IPTV.

  • SELT, тестирование по методам DMT,
  • клиент­ские измерения,
  • философия AWARE и пр.


- все это будет чрезвычайно востребовано в процессе измерений сети IPTV. Более того, выше не было рассмотрено ни одной методики, которая не была бы интересна для эксплуа­тации сети IPTV.

При массовом внедрении услуг Triple Play (и особенно IPTV) сеть ADSL начинает работать на пределе, поэтому все наработки методичес­кого плана, вся квалификация эксплуатирующего персонала, все невыявленные проблемы сети - все это проявится в сети IPTV.


Контроль режима Multicast


Второй уровень тестирования сетей IPTV - уровень транспортной сети. Стратегический вопрос применительно к уровню транспортной сети звучит так: «Готова ли транспортная сеть к появлению и расширению в ней трафика IPTV?»

Выше мы рассматривали принципы групповой рассылки Multicast и по­тенциальные проблемы, которые могут возникать в сети.

Технологически транспортную сеть можно представить как соединение транспортных пото­ков и системы маршрутизации трафика.

Соответственно, сомнения относи­тельно готовности транспортной сети к IPTV также делятся на два уровня воп­росов.

Во-первых, в сети может быть недостаточно ресурсов.

Во-вторых, сами методы и протоколы маршрутизации могут спровоцировать недопустимые параметры качества соответствующих потоков IPTV, и качество услуг станет неприемлемым. Это особенно критично, если учесть, что транспортные сети многих операторов создавались вовсе не под задачи IPTV.

На уровне транспорта сеть IPTV рассматривается как набор каналов пе­редачи трафика определенного свойства: большие по размеру пакеты, высо­кий приоритет, выделение под каждый канал полосы пропускания 5-6 Мбит/с для каждого пользователя, соответствующая сигнализация.

[3десь мы рассматриваем принципы измерений по методике RFC-2544 довольно кратко, так как они до­вольно далеки от темы ADSL. Все интересующиеся данной темой могут найти самое детальное описание проблематики контроля транспортных сетей в монографии [2]«SDH-NGSDH: практический взгляд на развитие транспортных сетей». М.: Метротек, 2006.]

Разрешить все сомнения помогает паспортизация транспортной сети по методике RFC-25441 (рис.7.2). Эта методика в настоящее время рассматри­вается многими как стандарт для измерений параметров качества на уровне транспортной сети.




Рис.7.2. Паспортизация транспортной сети по методике RFC-2544


Данная методика предусматривает использование двух приборов для те­стирования распределенной системы (DUT). Один прибор генерирует тесто­вый профиль трафика, задаваемый следующими параметрами:

  • уровень использования ресурса (GAP);
  • длина тестовых пакетов (L);
  • уровень приоритетности (Рг);
  • тип поддерживаемой сигнализации (Sig).


Тестовый поток с заданным профилем передается по транспортной сети и анализируется на удаленном конце по параметрам качества RFC-2544:

  • пропускная способность (Throughput, Th);
  • количество потерянных пакетов (Frame Loss, FL);
  • количество пакетов с ошибками (Frame Error, FE);
  • задержка передачи (Latency, Lat) и ее распределение (Latency Distribution, LD);
  • динамика изменения параметра задержки со временем (Latency over Time, LOT);
  • тесты берстности трафика (Back-to-Back).


Отдельные измерения отличаются только профилем генерируемой нагруз­ки и результирующими зависимостями параметров качества.

Для IPTV в про­цессе исследований на отечественных сетях были проработаны несколько тестовых профилей и профилей ожидаемых результатов (по сути, нормы), в зависимости от схемы организации взаимодействия STB - сервер.

Так что можно считать, что этот раздел методики измерений IPTV проработан по срав­нению с другими довольно хорошо.

Измерения на транспортной сети перед внедрением IPTV не ставят только вопрос проверки возможности или невозможности развертывания услуг IPTV. Вообще, «однобитовый» ответ в наше время мало кого заинтересует.

Целью проведения измерений на транспортной сети может стать определение воз­можных ограничений на участках STB - сервер, «бутылочных горл» на сети, где новые услуги IPTV будут «буксовать», разработка практических требований к параметрам качества в соглашениях о качестве обслуживания (SLA), а также оценка потенциального размера будущей сети по количеству пользователей.

Словом, измерения потоков транспортной сети - весьма полезный инст­румент, позволяющий проверить готовность ресурсов к внедрению IPTV.

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

Выше были рассмотрены принципы функционирования системы маршрутизации в сети IPTV на основе применения методов групповой рассылки (Multicast) и различ­ных вариантов протокола IGMP.

Именно эти два фактора - поддержка режима Multicast и протокола IGMP - определяют в настоящее время готовность транспортной сети к внедрению услуги IPTV.

Выше мы говорили, что самое простое с точки зрения обычного телезри­теля явление переключения каналов (Zapping) для систем IPTV представляет довольно сложный механизм, требующий подключения нового абонента к системы групповой рассылки или даже формирования новой группы Multicast.

По этой причине тесты Zapping стали одной из основ проверки работы транс­портной сети.

Методика измерений Zapping связана с имитацией отдельного пользова­теля или группы пользователей. Имитационные измерения вообще часто ис­пользуются в NGN и в методиках диагностики транспортной сети. Рассмот­рим методику таких измерений. Вместо сети рис.6.5 схема измерений предполагает использование двух устройств (рис.7.3). Со стороны пользователей к сети подключается прибор Avalanche, позволяющий имитировать группу STB от нескольких пользовате­лей до нескольких десятков тысяч. С другой стороны вместо набора видео­серверов подключается «эталонный» видеосервер Reflector.





Рис.7.3. Диагностика транспортной сети на предмет ее готовности к предоставлению услуг IPTV


Целесообразность использования вместо реальных видеосерверов ими­татор обусловлена рядом важных методических факторов.

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

Эталонный видеосервер исключает влияние производительности ре­альных видеосерверов на результаты измерений, равно как использо­вание Avalanche исключает субъективное влияние на результат про­изводительности STB. По сути, методика из трех компонентов IPTV: STB, серверов и транспортной сети, оставляет только транспортную сеть и диагностирует ее параметры.

В ходе измерений выполняются тесты Zapping по схеме рис.7.4.

Имита­тор пользователя осуществляет переключение с видеосервера с мультфиль­мом «Шрек» на видеосервер с мультфильмом «В поисках Немо».

С точки зре­ния пользователя это одно нажатие на пульте переключения каналов.

С точки зрения процессов в сети IPTV команда на переключение требует отключить пользователя от группы Multicast «Шрек» (команда Leave) и подключить его к группе Multicast «Немо» (команда Join). Время переключения фиксируется как время отклика сервера. Чтобы услуга IPTV не раздражала пользователя, Zapping time не должен превышать 100 мс, в противном случае недовольства не избежать.

Следует отметить, что для функционирования транспортной сети не столько страшна задержка переключения каналов отдельного пользователя, сколько массовое переключения каналов. В таком случае проблема приоб­ретает статистические и даже отчасти социологические свойства. В миро­вой практике уже сейчас было обнаружено явление, которое получило назва­ние «спираль коллапса» сети IPTV.




Рис.7.4. Методика диагностики Zapping


Сценарий возникновения «спирали кол­лапса» можно описать следующим образом.

Предположим, на сети IPTV имеет место трансляция популярной про­граммы, например, футбольного матча финала мирового первенства. Большая часть (более 30%) всех зрителей смотрят сегодня этот матч, т.е. принадлежат к единой группе Multicast.

Матч заканчивается, и каждый зритель понимает, что после него идет надоевшая всем реклама. Большая часть пользователей переключают канал.

В таком случае в сети возникает ситуация массового переключения каналов. Сеть наполняется служебными командами Join/Leave. Спис­ки групп Multicast стремительно меняются.

В результате массового переключения сеть перегружается и дает вы­сокий показатель потери пакетов (более 5%) для 1% пользователей. Что в таком случае видит на экранах этот 1% пользователей, пред­ставлено на рис.6.6.

Качество нового канала вполне естественно не нравится, и пользова­тели спонтанно переключают канал снова, некоторые по нескольку раз.

Новая волна массовых переключений приводит к еще большей пере­грузки сети. Это вызывает недопустимый уровень потерь пакетов еще для 5% пользователей сети.

Далее лавина нарастает; 5% пользователей делают массовое пере­ключение каналов, так что перегрузка «убивает» качество для 10% пользователей. А потом 15, потом 20, 50% и т.д.

В результате вся сеть «падает». Она не может предоставить качествен­ной трансляции видеопрограмм и нуждается в ПОЛНОЙ перезагрузке.

Представленный сценарий «спирали коллапса» показывает всю серьез­ность возможных нарушений в работе системы маршрутизации трафика для работы сети IPTV. При неправильных настройках системы маршрутизации либо при любых нарушениях в работе транспортной сети по обслуживанию трафика Multicast услуга IPTV не просто может дать сбой, но и вызвать нару­шения работы всей транспортной сети, включая компоненты VoIP и передачи данных.

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

Подводных камней в диагностике транспортной сети на ее готовность к обработке трафика IPTV очень много.

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

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





Рис.7.5. Профили имитируемого трафика тестов Multicast (слева) и

Unicast + Multicast (справа)


В обоих случаях профиль нагрузки имеет ступенчатый характер. Каждые 10 с в течение 100 с добавляется 100 абонентов. После того, как число або­нентов достигает 1000 (в случае Unicast 2250), генерация трафика заканчива­ется и через 120 с закрываются все сессии.

В процессе измерений рассматривались все ключевые параметры каче­ства транспортной сети, важные для предоставления услуг:
  • уровень неравномерности задержки (Jitter). Фиксировалось количество потоков вещания с джиттером менее 50 мс, от 50 до 100 мс и т.д.;
  • уровень ошибок в потоках (Streams Errors), причем контролировались одновременно уровень активных потоков и уровень «убитых» потоков, т.е. тех потоков где уровень потерь пакетов был выше 5%;
  • количество Join/Leave команд;

среднее время отклика видеосервера (Streaming Average Response Time), что является эквивалентом среднего времени Zapping.


Литература


1. Бакланов И.Г. Технологии ADSL/ADSL2+: теория и практика применения.-М.: Метротек,2007.

2. Бакланов И.Г. SDH-NGSDH: практический взгляд на развитие транспортных сетей. М.: Метротек, 2006.


Контрольные вопросы

  1. Какие проблемы необходимо проанализировать перед началом эксплуатации сети IPTV.
  2. Изобразите схему трех уровней контроля сети IPTV.
  3. Какая должна быть полоса передачи на каждый STB размещенный в квартире пользователя.
  4. Укажите три источника потенциальных проблем уровня ADSL при внедрении IPTV.
  5. Какие вопросы необходимо решить при тестировании сети IPTV на уровне транспортной сети.
  6. Изобразите схему паспортизации транспортной сети по методике RFC-2544.
  7. По каким параметрам качества RFC-2544 анализируется тестовый поток.
  8. Какие два фактора определяют готовность транспортной сети к внедрению услуги IPTV.
  9. Опишите методику измерений тестов Zapping.
  10. Изобразите схему методики диагностики Zapping.
  11. Опишите сценарий возникновения «спирали кол­лапса» в сети IPTV.