vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

Тестирование IPTV: как можно ближе к реальному обслуживанию

Дата публикации: 23.05.2006
Количество просмотров: 1463

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

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

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

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

Во-вторых, если сеть не проверена специально для применимости с точки зрения организации IPTV, всегда будет оставаться неуверенность в том, как она поведет себя во время реального предоставления услуги, как на уровне поставщика, так и на уровне потребителя. Скорее всего, это будет просто обозначать, что о Quality of Service (QoS) и, что еще более важно, о Quality of Experience (QoE) можно попросту забыть. Протокол IP, в сущности, ненадежен, а TCP "рассматривает" проблемы с точки зрения пропущенных или изменивших порядок следования, пакетов, что не имеет значения при передаче данных или приеме E-Mail, но мгновенно отрицательно сказывается на восприятии движущейся картинки поскольку человеческий глаз с высокой точностью распознает погрешности в QoS/QoE. Как показывает практика, пользователь при этом не докладывает о каждом дефекте изображения в СТП оператора, а просто, потерпев некоторое время для приличия, уходит к другому поставщику услуг. Это означает финансовую потерю для компании, поскольку на привлечение клиента была затрачена определенная сумма денег. Вывод прост: низкое качество равносильно прямой потере денежных средств. Следовательно, ключевым фактором маркетинговой политики становится поддержка QoS. А для этого нужна правильная методология тестирования сети.

Функционирование IPTV в полной мере находится в руках владельца сетевой инфраструктуры и поставщика обслуживания. Большинство операторов, вне зависимости от организации сети, проверяют сеть для IP-телевидения, отправляя пакеты по 64 байта. Если они проходят нормально, сеть признается качественной и вполне пригодной для IPTV. Метод, может, и неплох, но для современных услуг, вроде VoIP или IPTV слишком упрощен и не может гарантировать удовлетворительного результата. Потребителю абсолютно все равно, насколько качественно выполняются некие придуманные тесты в определенных условиях. Факт успешного запуска какого-либо теста вряд ли успокоит клиента, сталкивающегося с дефектом обслуживания. Тестирование должно проводиться в условиях максимально приближенных к реальному обслуживанию. Ключ к успеху – эмуляция, а не моделирование.

Эмуляция нужна для того, чтобы лучше понять, как именно правильно организовать передачу трафика для IP-телевидения. Это сразу позволяет избавиться от иллюзий и скорректировать большинство ошибок. В типовом варианте IPTV передается по протоколу IGMP (Internet Group Management Protocol). IGMP позволяет организовать мультикастинг (точка-многоточие). Видеосервер передает отдельные телеканалы как единый поток, направленный к определенному набору IP-адресов. Если потребитель хочет получать этот поток, его set-top-box (STB) отправляет запрос на присоединение и данные о своем IP-адресе. В этом случае, инфраструктура сети направляет потребителю копию потока.

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

Обычно видео передается как потоки MPEG-2 или MPEG-4. Потоки MPEG состоят из множества различных типов фреймов. Чтобы обеспечить эффективное сжатие, каждый фрейм несет информацию об отличии от предыдущего фрейма, или, как ее еще называют, дельту. Однако, если первые фреймы или одна из "дельт" потеряны, цифровой поток видео или аудио расшифровать уже невозможно. Чтобы преодолеть эту проблему, в поток MPEG-2 добавляют I-фрейм, содержащий полноценную информацию, независящую от других фреймов. Обычно I-фрейм ставят не реже, чем через каждые 15 обычных фреймов.

Однако, при сбое или новом подключении, зритель должен ждать прихода очередного I-фрейма, что в условиях кодирования изображения на уровне 30 кадров в секунду, будет означать полусекундную задержку. Увеличение частоты расстановки I-фреймов принципиально проблему не решает.

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

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

Следует также иметь ввиду, что при разработке IGMP никто особо не задумывался об организации безопасности обслуживания, что дает огромный простор для деятельности разного рода злоумышленникам. Поэтому предупреждение проблем из-за DoS-атак, всевозможных видов мошенничества и вирусной активности – это отдельная огромная область, учитывая которую необходимо проводить специальные обширные тесты.

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

Дмитрий

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/news/newsline/6721/testirovanie-iptv-kak-mojno-blije-k-realnomu-obslujivaniyu.html

Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться