IPTV в России

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

Строить ли IPTV?

То есть, даже не так. Скорее «Что делать с этим IPTV?». По самым скромным расчётам построить платформу на 10 тысяч пользователей меньше чем за пару миллионов ну никак не получится. Ещё примерно столько же придётся отдать за контент, который хоть кто-то будет смотреть. И это только прямые затраты, связанные с закупкой оборудования и контента. А ещё создание и содержание программной дирекции, маркетинг продукта и приведение сети в божеский вид. И всё это для того, чтобы попасть на чрезвычайно тесную поляну, на которой и без того много кабельных и спутниковых операторов.

Вообще, стоит обратить внимание на «успехи» операторов в построении собственных VAS. Платформ развёрнута масса, от электронной почты до IMS. И что же в итоге? Электронную почту у операторов успешно отобрали интернет-сервисы, те инновационные presense и instant messaging, ради которых повелись на IMS тоже достались скайпу и jabber’у. Единственное, что осталось, кроме «пакетной трубы» — это телефония, и та осталась лишь потому что операторы «держат» абонентов за телефонный номер. Как только появится возможность мигрировать с номером между различными операторами, малина может закончиться.

К сожалению, ситуация уже сложилась таким образом, что пользователь 80% сервисов потребляет «на стороне». В интернете. И тенденции к тому, чтобы клиенты вернулись в лоно оператора, не видно. Скорее напротив, тот же messaging теперь отберут у Яндекса разнообразные одноклассники и вконтакте, а предполагать, что операторы окажутся шустрее интернетчиков и придумают свой веб-икс-ноль, довольно наивно.

К слову, пираты уже активно монетизируют свои услуги. Пока операторы раздумывают, где им взять HD-контент, а правообладатели яростно пытаются «снять сливки» на этом контенте, крупные торрент-трекеры, такие как HDTracker, зарабатывают на поставке клонов Popcorn Hour. BBK также выходит на этот рынок, а это уже крупный игрок.

Какие же выходы? Выходов несколько. Первый — стать большим оператором, захватив максимально возможные куски value chain. То есть, построить мощную собственную агрегацию, собственное производство и собрать пару (а лучше несколько) сотен тысяч пользователей. Тогда можно прикинуться Comcast’ом и можно, в общем, вступать, опять же, в вышеописанную борьбу за доходы с пиратами, правообладателями и регуляторами. Возможно, такому оператору удастся пролоббировать введение смертной казни через повешение за потребление пиратского контента и провести несколько публичных акций устрашения. Тогда жизнь наладится.

Второй выход — предоставить оператору возможность эксплуатировать его близость к абоненту и тот уровень доверия, которым он обладает. То есть, принимать платежи и конкурировать «витринами», качеством доставки и обслуживания. Для того, чтобы это сделать, сервисы, включая доставку «тяжёлого» контента должны стать действительно общедоступными. То есть, любой оператор должен иметь возможность предоставить своему клиенту тот контент, который ему нужен.

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

Один из потенциальным IPTV-операторов недавно попросил рассказать о том, как загружаются STB и в чём смысл «священной войны», которая и тут тоже есть своя.

Если вкратце, то есть два основных типа STB. Одни работают самостоятельно (та же Amino, например), другие при каждом включении загружаются из сети (самый популярный у нас из подобных — Motorola/Kreatel).

Начнём со второго типа, с тех, что грузятся из сети. Когда Kreatel включается, в нём нет практически никакого софта, кроме сетевого загрузчика, который подключает сетевой контроллер, получает по DHCP собственный адрес и начинает слушать multicast-группу, в которой вещается операционная система со всеми пирогами — драйверами, брузерами и кусками middleware. Занимает это в среднем минуты полторы. Выключение STB с пульта управления вводит устройство в спящий режим и прошивку он не теряет, однако, если «моргает» свет, то устройству придётся перегрузиться полностью, с самого начала. Это офигенный минус. Кроме того, нужен отдельный, довольно надёжный сервер, который будет постоянно вещать софт для желающих его загрузить. Но это мелочи.

Другой вариант STB, как, например, та же AmiNET, через сеть загружается лишь один раз. Вы покупаете «пустую» приставку, которая умеет только получить DHCP, в котором, кроме её собственного адреса, вещается ещё и адрес софта. Приставка получает собственный адрес и прошивается софтом, который вещается в указанной multicast-группе. Для того, чтобы приставка прошилась санкционированно, и не абы чем, вещаемые образы обычно шифруются, при этом ключи генерируются производителем для каждого оператора отдельно и жёстко прописываются в приставке (изменить их, впрочем, возможно с помощью совсем уж специальных утилит). Таким образом, приставка, выпущенная для оператора X, использоваться оператором Y не сможет, потому что свою версию софта последний «залить» не сможет. После этого STB работает самостоятельно. Системы поддержки AmiNET, Scientific Atlanta и некоторые другие, в целях большей гибкости, вещают отдельно загрузчик софта (bootstrap) и саму операционную систему с приложениями (software image).

Основной аргумент, который применяют производители первого типа устройств в пользу своей концепции — гибкость. Мол, при этой схеме функционирования оператор имеет возможность в любой момент времени обновить софт, полностью сменить middleware и, вообще, совершить любые необходимые манипуляции. На самом деле это не так. Точнее, ровно так, но применимо и к устройствам, способным включаться самостоятельно. Для всех этих устройств также существуют обслуживающие системы, которые включают инструментарий, обеспечивающий вещание необходимого софта и утилитки, которые позволяют «дёрнуть» любой конкретное устроёство или группу STB и либо просто «ребутнуть» их, либо обновить софт, либо сделать что-то ещё. То есть, возможности управления и администраторования STB никоим образом не страдают от того, загружается он из сети при каждом включении или лишь при инициализации в сети оператора.

Почему эти отличия важны? Причин две. Во-первых, в условиях российских городов, где скачки напряжения не являются исключительной редкостью, тот факт, что при каждом прерывании электропитания перерыв в обслуживании абонента составляет как минимум минуту-полторы, раздражает. Во-вторых, будьте внимательны. Отчего-то часто выходит так, что за необходимость загружать абонентскую приставку при каждом включении, нужно ещё и дополнительно платить. Так, один известный производитель не только продаёт сам сервер-вещатель за 700 с лишним евро, так ещё и каждый обслуживаемый им STB лицензирует ещё за некоторое количество евро. Оно вам нужно?!

Кстати, тот же Kreatel новые, ещё не выпущенные версии приставок будет делать как раз прошиваемыми единыжды, а затем обновляемыми по запросу.

NB. Кстати, мы скоро поднимем ещё два сервиса на сайте — wiki (он уже есть, нужно только сделать «начальную набивку», если есть желающие поучаствовать в этом процессе, заходите на http://wiki.telecombuzz.ru/, через неделю-две он пойдёт в «продакшн» ) и новостная лента.

В связи с тем, что тема мониторинга достаточно актуальна, но практически не раскрыта на блоге, я решил написать немного на эту тему… Начать же хочу с описания самой распространенной на данный момент методики — RFC 4445.

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

В связи с этим был утвержден индекс MDI (Media Delivery Index) определенный в методике RFC 4445. Он основан на принципе формирования интегральной оценки качества по совокупности двух самых важных параметров качества на всех участках транспорта IPTV инфраструктуры — джиттера и количества потерянных пакетов. И логика метода MDI заключается в том, что если с транспортом пакетов проблем не будет, то не будет проблем и с контентом. Эти параметры определены как уровень задержки Delay Factor (DF) и уровень потерянных пакетов Media Loss Rate (MLR).

MDI вычисляется за произвольный промежуток времени, обычно это 1 секунда

• MDI-DF показывает наибольшее значение параметра джиттера пакетов за период измерения
• MDI-MLR показывает количество транспортных пакетов , потерянных за период измерения

И если с измерениями уровня MLR, выполняющимися методами пассивного мониторинга все предельно понятно, то с DF дело обстоит сложнее. Джиттером в MDI является задержка между ожидаемым и реальным временем приема пакета (см. рисунок).

где IAT — среднее время доставки соседних IP-фреймов.

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

MDI — это простой алгоритм мониторинга уровня транспорта для квалификации качества уровня услуг. За счет применения MDI можно осуществить мониторинг параметров качества на всех основных узлах транспорта начиная HeadEnd и заканчивая STB, выявить участок, где происходит ухудшение качества, и определить в какой степени это критично для услуги IPTV.

Ещё один из «установочный» пост, для создания общего контекста того, о чём мы будем говорить. Об услугах.

Здесь, собственно, есть две мощных ипостаси. Мы пока не будем вдаваться уж совсем в подробности, но, вообще говоря, принято считать, что есть два основных направления услуг — «телевизионные» и «коммуникационные».

Услуги «телевизионные» — для пользователя телевизора относительно привычные. Это, собственно:

• теле- и радиовещание (broadcast). то же самое, что и обычное телевидение. Рано или поздно, можно предположить, этот вид услуг отомрёт и уступит место…
• …видео по требованию. Услуга тоже вполне понятная и даже привычная. Существует в разных проявлениях, например, Near Video on Demand (закрученные по кругу фильмы, что-то вроде кинозала), True Video on Demand (действительно «по требованию», с перемоткой, паузой) и в разных прочих маркетинговых вариациях. Реализуется, в том числе, в кабельных сетях.
• Системы оповещения. Слава Богу, нам нечасто приходится пользоваться этой услугой (обычно после этого приходится ложиться лицом к взрыву и класть автомат под себя), однако она есть!
• Электронная почта. Собственно, как и простой веб-сёрфинг, эта услуга однажды уже реализовывалась, например, в середине 90-х годов, когда были попытки продвигать железяку с названием то ли WebTV, то ли что-то такое. Ну и DreamBox, конечно. Частично этот функционал реализуется и телетекстом. Тоже ничего сверхособенного.

Настоящий синергетический эффект от внедрения IPTV проявляется, однако, с запуском «коммуникационных» услуг:

• клиентский и сетевой PVR (personal video recorder — «видик»). Отчасти эта услуга уже реализована в тех же DreamBox’ах и прочих сеттопбоксах DVB с «винчестверами», но долгое время была в большей степени присуща компьютерам с ТВ-тюнерами. А это совсем другое.
• timeshift TV. Одна из вариаций PVR, однако, отличающаяся как реализацией интерфейса. так и некоторыми лицензионными моментами.
• домашние видеокоммуникации с использованием ТВ. Ставите на телевизор камеру и полный вперёд — можно совершать видеозвонки «точка-точка», участвовать в видеоконференциях и делать всё, что с этим связано. Здесь, кстати, возникает новое применение концепции Пограничных контроллеров сессий (Session Border Controller).
• домашнее видеонаблюдение. наблюдаем за старенькими родителями или малыми детьми дома с телевизора компьютера, телефона и т. д.
• распределение самодетельного контента. YouTube на телевизоре — «Сам Себе Режиссёр» с «человеческим лицом», а также средство обмена фотографиями с сообществом
• чаты. конкуренция с тем СМС-безумием, которое творится на всех молодёжных каналах, когда всем вот этим вот «Люся, я тебя люблю. Серёга из Дмитрова» завалено до четверти полезной площади экрана.
• и, в целом, такое объединяющее последние пункты явление как social networking. Модный Web 2.0, объединяясь с привычными телекоммуникационными и информационными услугами формирует даже не инфокоммуникации (слово-то какое прогнившее), формирует что-то вроде Telecom 2.0*.

Это всё довольно условно и должно лишь показать возможности для реализации новых услуг, однако сказать об этом тоже необходимо, чтобы понимать, что можно, а чего нельзя.

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

* — что такое Telecom 2.0 с точки зрения, например, Игоря Масленникова, я расскажу попозже, как только послушаю его доклад на 11-й Ежегодной Конференции по IP-телефонии и IP-коммуникациям.

Что же такое IPTV в смысле технологии? Давайте быстренько разберёмся, из чего всё это состоит и как устроено.

Собственно, компонентов не так уж и много. Изучим схемку.

Вообще-то там хорошо бы делать мультик, но пока обойдёмся без мультика. Итак, базовый, условно рабочий набор компонентов можно поделить вообще на следующие части:

• Головная станция (HeadEnd)
• Подсистема Видео по требованию (Video on Demand)
• Сервисная платформа (Middleware)
• Бизнес- и операционные системы (OSS/BSS)
• Абонентское оборудование (SetTopBox)

Есть ещё вся история «за кадром» — системы OSS/BSS — биллинг, системы мониторинга, управления и прочее-прочее-прочее. Телевизионщики часто делят это несколько иначе, объединяя все операторские компоненты в термин «головная станция» и выделяя только сеть и абонентское оборудование. Мы так поступать не будем, потому что эти компоненты для нас очень важны.

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

• достаточная полоса пропускания — это от 4 Mbps для MPEG2 и от 2,5 Mbps для MPEG4. Естественно, для получения приемлимого качества изображения на среднестатистическом телевизоре.
• поддержка Multicast во всей сети. обязательное условие для реализации broadcast-услуг
• сквозная поддержка механизмов QoS. Я сталкивался с мнением, что если у нас будет достаточная полоса пропускания, то плевать мы хотели на QoS — всё пролезет и так. На самом деле в реальности это работает, конечно, потому что если в сеть Вы загоняете не только IPTV-трафик, но и голосовой, и данные и интернет, да ещё и там есть клиенты с договором, подразумевающим качество обслуживания.

Вообще говоря, роль сети довольно часто недооценивается, но вот эти простые три требования в реальности трансформируются в огромный геморрой — выясняется, что требование про multicast выливается в то, что хорошо бы иметь поддержку IGMP v3 или как минимум возможность трансляции из IGMP v2 в IGMP v3. Что время сходимости сети при авариях имеет большое значение (не столь значительное, впрочем, как обычно представляется). Ну и масса всяких других факторов, которые всё же подразумевают, что сеть у вас «умная». Строго говоря, в большинстве случаев именно сеть является основной статьёй расходов при запуске IPTV.

Итак, собственно, компоненты IPTV. Те, что не сеть :-)

Головная станция

Самая телевизионная часть всего решения, решает задачу, собственно, запихивания телевизионного сигнала в IP-сети. С помощью головной станции сигнал принимается из эфира, спутника или наземного источника, если необходимо, цифруется (кодер), декодируется (декодер) и в итоге ремультиплексируется (стример) в IP MPEG SPTS, каждая программа в отдельную multicast-группу. Современные тенденции таковы, что ASI-компоненты современных головных станций активно вытесняются IP-компонентами (иногда даже и SDI-компоненты во внутристудийном обмене). Основные игроки на рынке головных станций — Scientific Atlanta, Tandberg Television, Scopus, Minerva, OptiBase.

Часто в головную станцию относят (тёмное прошлое, когда головной станцией называли всё, что находится в одном месте :-) ещё и Системы защиты контента (CAS/DRM). Производителей этого хабара совсем-совсем немного. Не наберётся, в общем-то, и десятка. Суть здесь проста — весь контент необходимо шифровать. И, к сожалению, владельцы контента живут вообще в другом мире. Они не знают, что IP-сеть управляема, что Вы можете делать фильтрование по MAC-адресам и аутентификацию сессий с помощью токенов. Они знают, что если что-то зашифровать сумашедшими ключами, то это будет надёжно. Собственно, причина, по которой в мире IPTV производители этих систем не погибли, пожалуй, ровно в том, что наличие этих систем затребовано поставщиками контента. И, более того, наличие совершенно определённых систем, сертифицированных как надёжные. Список их невелик и среди наболее используемых Verimatrix, Irdeto, NDS, Widevine, Viaccess, Nagra. Системы могут работать как с карточками, так и без карточек (смарт-картами, в смысле).

Подсистема Видео по требованию

Подсистема видео по требованию выполняет простую функцию — отдаёт или записывает по требованию (запрос пользователя, программированное событие, etc)
видеоматериалы. Отдаёт по протоколу RTSP, а записывает путём перехвата multicast-групп, таким образом реализуется пауза «живого» эфира и сетевой видеомагнитофон. Сервер подключается к каналу, начинает запись и запись кладёт в список доступных для Видео по требованию материалов.

Когда кто-то хочет посмотреть контент, сервер отдаёт его либо в Unicast (в большинстве случаев) с адреса rtsp://server_adderss:port/asset, либо в Multicast, скажем, для реализации Near Video on Demand. (об услугах мы ещё поговорим отдельно :-)) Услуги как таковые VOD не предоставляет, он просто отдаёт файлы и иногда записывает потоки. Основные производители этих систем — Kasenna, Arroyo, C-COR (бывш. NCube), Concurrent, SeaChange, BitBand.

Сервисная платформа

Более всего на Middleware похожи IP-телефонные Class 5 softswitch’и. Это штука, которая реализует услугу — предоставляет интерфейс пользователя и осуществляет интеграцию всех компонентов. Работает это, например, так. Абонент включает телевизор, ему на экране показывается меню работы с услугами. Это меню взято с сервера middleware. Выбирая просмотр какого-то фильма, middleware обращается в сторону BSS и OSS систем, спрашивая у них, можно ли абоненту посмотреть фильм, есть ли у него для этого средства, подписан ли он на услугу, есть ли ресурсы сервера VoD и сети для предоставления этой услуги. Получив положительные ответы, middleware отдаст адрес фильма на сервере VOD, с этого адреса абонент получит искомый фильм, а middleware снимет деньги со счёта. Примерно так.

Системы middleware очень сложны, обязаны обладать возможностями расширения, написания дополнительных услуг, реализации собственного интерфейса пользователя и прочее-прочее. Собственно, это должна быть платформа, на которой оператор связи напишет собственный пользовательский портал, собственные подпрограммы для реализации своих услуг, прикрутит систему к собственному биллингу, системам проключения услуг (service provisioning), СRM? мониторингу и прочее. Таких систем, к сожалению, очень мало. В большинстве случаев производители middleware постараются «подсадить» клиентов на собственный сервис, дальнейшую поддержку и разработку дополнительных элементов. Это, в свою очередь, привело к большому распространению собственноручно созданных сервисных платформ. Многие из которых, в свою очередь, выделились в отдельные продукты.

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

Производителей этих систем много. Больше, чем кого бы то ни было. Самые именитые — Microsoft, Orca, Minerva, Myrio. Есть и российский производитель — компания Netris (бывший IPSoft, отдел разработки компании CTI). Её решение используется в проекте Стрим-ТВ компании МТУ-Интел.

Системы OSS/BSS

Собственно говоря, тут всё понятно. Как ни крути, в большой сети Вам понадобится система управления услугами, система мониторинга доступности ресурсов, хранилище ресурсов, автоматизированное проключение услуг, биллинг, CRM и всё прочее-прочее. Вот это всё оно и есть.

Абонентские устройства

SetTopBox (буквально, «находящийся сверху») — устройство отображения IPTV на телевизоре. Больше всего похоже на приставку для кабельного или спутникового телевидения, только на задней панели разъём для ethernet, а не коаксиального кабеля. Представляет из себя маленький компьютер под управлением Linux или Windows, с TCP-стеком, браузером или клиентом middleware и MPEG-декодером. Производителей этого хабара огромное количество, наиболее известны в России приставки Amino и Kreatel (ныне Motorola), вообще же в мире хорошо известны также Thomson, Pace, Scientific Atlanta/KiSS, Tilgin (экс-i3micro) и некоторые другие.

Нюанс в использовании STB (так его будем звать) состоит в том, что устройство должно быть тесно интегрировано со всеми компонентами, в используемом ПО должны быть клиенты для Системы защиты контента, для Video on Demand, для сервисной платформы и, возможно, какие-то дополнительные модули, необходимые для работы решения в целом. То есть, это штука изготавливаемая (обычно в смысле софта, по-крайней мере) под конкретный проект. В этом обычно кроется некоторый «облом» — купить на рынке какой-нибудь STB и применить его в проекте не получается. Это не сотовый телефон.

Собственно, техническое введение на этом можно и закончить пока, увидимся через некоторое время, поговорим о том, какие услуги можно развернуть в сети IPTV. Зачем-то люди же всё это затевают?!

Пожалуй, для полноты картины давайте «сверим часы» — убедимся, что мы говорим об одном и том же.

Что же такое IPTV?

Если коротко, то IPTV — это способ передавать видеоизображение по каналам пакетной коммутации. Конкретно, по IP. Это если совсем коротко.

Видеоизображение при этом является компонентом огромного количества современных телекоммуникационных приложений — собственно, телевещания, видео по требованию, видеонаблюдения, видеотелефонии и много ещё чего. Весь этот спектр приложений и сервисов какое-то время назад было принято называть Video over IP, по аналогии с Voice over IP. Но как-то так получилось, что marketing people к движению в этот раз подключились гораздо раньше, чем в случае с IP-телефонией и термин Video over IP довольно быстро стал исключительно технологическим и даже анахронистичным.

Бурная деятельность маркетологов привела к появлению вполне устойчивого термина IPTV, который сегодня означает предоставление на телеприёмниках телевизионных услуг, доставляемых по IP-сети — и «звучит» и менее технологично и, вообще, «ближе к народу».

Более того, я бы советовал Вам к этому понятию относится так широко, как только возможно. Я для себя и для своих собеседников IPTV определяю как «IP в телевизоре», а не «Телевидение в IP». Последний термин, на мой взгляд, куда более скуден и не способствует восприятию революционности происходящих процессов.

А это как раз тот случай, когда эволюционное количество начинает переходить в революционное качество. Но об этом в следующий рза.