IPTV в России

Один из потенциальным 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/, через неделю-две он пойдёт в «продакшн» ) и новостная лента.

Ответ на вопрос о Мостелекоме. Отличная новость. Если Мостелеком и Alcatel не блефуют, то мы получим ещё одного оператора с неплохой metro-сетью и IPTV.

Другой вопрос в том, что к 2009 году, когда будет построена сеть, в Москве на рынке платного телевидения будут присутствовать Космос-ТВ, Комстар-Директ, НТВ+, Центральный Телеграф, Комкор и, скорее всего, Golden Telecom либо сам по себе, либо как Корбина. И это не считая тех домовых операторов, которые тоже заняты разворачиваением ТВ-услуг. Тот же NetByNet, если не озаботится чем-то таким ультрамодным, непонятно как будет конкурировать. То есть, нужно очень круто постараться, чтобы влезть на этот рынок.

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

В любом случае, ещё одна хорошая сеть — это хорошо.

> И ещё. Насколько я понял из вводной про структуру IPTV вообще, то концепции SoftSwitch, IPTV Middleware и IN. Больно уж похожи. Везде передача данных отделена от реализации услуг. Но наверняка есть какие-то отличия. Или отличие только в той информации, которая передаётся, и на основе которой построены собственно все услуги (для IPTV - это видео, для Softswitch - голос, IN - тот же голос, только не по IP). Кроме того, мне казалось, что Софтсвич достаточно широкое понятие чтобы вместить туда не только голос но и вообще любой IP трафик, и IPTV в частности. Я не прав?

И да и нет. Эти концепции действительно очень схожи. Дело только в том, что мы уже все давно путаем маркетинговые и технические термины. :-) Некое волшебное устройство, которое будет делать все услуги на свете — это утопия. Эта порочная идея была однажды представлена в одной из концепций развития телекоммуникаций в России, получила широкую огласку и привела к тому, что все производители оборудования тут же явили этот магический «софтсвитч для сетей ЭнДжиЭн» … и, конечно же, оба термина таким образом были в значительной степени дискредетированы.

Каша в голове многих журналистов становится кашей в голове широкой публики. Здесь, конечно же, заслуга маркетологов. За попытки ввести в оборот понятие «2,75G» в контексте мобильной связи я бы просто, наверное, бил линейкой по пальцам. IMS, например, это же не просто очередной marketing bullshit, высосанный из пальца термин. Это, вообще-то, вполне описанная технологическая концепция, набор технических документов.

• SoftSwitch — это вполне определённый класс продуктов, выполняющих либо функции транзитного коммутатора (Class 4) и им сопутствующие, либо функции сервисной коммуникационной платформы (Class 5). Причём сейчас даже эти понятия становятся не такими чёткими — часть функций переносится на границу сети, на SBC (см. предыдущий пост :)), а сам софтсвитч занимается только маршрутизацией.
• IPTV Middleware — это тоже вполне определённый класс продуктов, которые выполняют функции интеграции компонентов IPTV-решения между собой и в сеть оператора и реализует функции абонентского интерфейса. Причём вторая функция может реализовываться отдельным компонентом или даже продуктом.
• IMS — набор технических концепций, предполагающий реализацию продвинутой сервисной модели и описывающий необходимые для этого компоненты и способы их взаимодействия.

Концептуальная идея разделения сети доступа и услуг, лежащая в основе IMS, конечно же, впервые дала ростки в софтсвичах , имеет место быть в современных IPTV middleware и вообще, соответствует реалиям мира, в котором нам предстоит жить, потому и пересекается со всеми сферами.

> С уважением,
> Максим

Уффф. Спасибо, Максим, за дельные вопросы :-) Надеюсь, ответы удовлетворили :)

P.S. Кто-нибудь посчитал, сколько раз я употребил слово концепция?

> 3. И самый главный вопрос! Зачем всё это реализовывать при помощи отдельного устройства SetTopBox, если есть PC с кучей возможностей? И как со всем этим соотносится Microsoft Windows Media Center Edition?

Вот здесь всё довольно просто. Потребление услуги тогда становится массовым, когда становится простым. Наиболее простая и привычная вещь в доме, после холодильника и электроплиты, наверное, телевизор. Именно поэтому мы на него хотим выводить эти новые услуги. Потому что домашнее развлечение для большинства людей — это телевизор. Когда мы говорим «компьютер», мы обычно подразумеваем жужжащую штуку с более чем сотней кнопок и мышкой. Это не то устройство, которое может развлечь. СетТопБокс же, строго говоря, и есть компьютер. Внутри Linux, либо Windows, веб-браузер, MPEG-декодер. Только управляется этот компьютер пультом, ставится сверху на телевизор и напоминает то, что у нас пользователи всегда называли «телевизионной приставкой», а в англоязычном мире «SetTopBox». Вот и всё. Устройством, которое будет показывать на телевизоре IPTV, а точнее, предоставлять все те услуги, которые под этим подразумеваются, может быть и XBox и PlayStation и Windows Media Center-компьютеры. Лишь бы это было удобоваримо с точки зрения интерфейса, потому что обычный современный компьютер хорош для работы с электронными таблицами, а не для просмотра фильмов.

> 4. И как IPTV отнесётся к переходу на HD?

Совершенно нормально отнесётся. Нет никаких препятствий тут — лишь бы сеть выдержала. Это уже не вопрос, собственно, к IPTV, это вопрос к сетевой инфраструктуре. Технологически сейчас нет никаких препятствий к тому, чтобы построить IP-сеть, которая будет нормально обслуживать HDTV, большинство операторов IPTV в Европе, Северной Америке и Азии предоставляют HDTV, как вещательный контент, так и VOD. У нас пока таких нет, но те, кому сеть позволит (например, Центральному Телеграфу и Норильск-Телекому — они строятся не на xDSL, а на нормальном ethernet), я думаю, обязательно введут пакеты HDTV.

продолжение следует…

Мне тут прислали вопросы в связи с тем, что я успел уже написать.

Ответы получились очень уж большими. Поэтому я разделю это всё на два поста.

>1. Кто такие Session Border Controllers и какое новое применение им можно придумать в рамках видеокоммуникаций?

Концепция Session Border Controller выросла из софтсвичей. В мире IP-телефонии однажды стали очевидными проблемы, связанные с тем, что RTP-трафик (сам голос) «бегает» отдельно от сигнализации (управляющих команд и кодов), неведомыми путями. Не было понятно, как делать СОРМ, где бороться с NAT и PAT-устройствами, за которыми прячут абонентов и как осуществлять транскодирование голосовых потоков, если их нужно отдать наружу, партнёру или на биржу. Полное проксирование RTP в центре, на софтсвиче, начисто лишало систему масштабируемости, выявляло точку отказа и вообще, становилось пугающе похоже на классическую телефонию с одной Большой-АТС-Которая-Делает-Всё-На-Свете. И-которую-легко-сломать, конечно же.

Поэтому появилась концепция SBC, подразумевающая, что определённый функционал, который должен решать задачи NAT traversal (решение проблем, связанных с NAT/PAT), СОРМ и помогать в сопряжении с другими сетями, стоит выносить на границы сети. К тому же SBC хорошо знают состояние линий и RTP-трафика, который по ним бегает и помогают принимать решения о качестве работы направления.

Применение в рамках видеокоммуникаций ровно такое, какое следует из всего этого. Нам нужно устройство, которое будет, например, CIF или QCIF, формируемый дешёвыми камерками, используемыми для личных видеозвонков, транслировать в MPEG, который будет понятен всем STB на свете. Или, например, позволит просматривать материал специфичных камер видеонаблюдения на обычном телеке. К тому же, помимо того самого walled garden, собственного сервисного пространства оператора, есть масса задач, требующих взаимодействия с внешним миром. Это сейчас достаточно того, чтобы услуга работала во внутренней сети оператора. Рано или поздно хорошо было бы выйти наружу. А чтобы, скажем, через мобильный телефон в 3G-сети можно было общаться по видео с оставшимися дома близкими, нужны какие-то средства, которые разберут поток и сделают одно понятным для другого. Вот вам и применение.

> 2. Чем же всё-таки отличается timeshift от PVR? Я так понимаю, что таймшифт, это просто буферизация потока, пока пользователь нажал на паузу, а когда отжал, то буферизация продолжается, а воспроизведение стартует уже из буфера. А ПВР это просто запись потока, и отличие клиентского от сетевого только в местонахождении хранилица.

Совершенно верно. То есть, функционально, ничем не отличается одно от другого. То, что Вы называете буферизацией, суть, работающий PVR. Вы ставите на «паузу» телеканал, в это время включается запись телеканала, а в middleware адрес multicast-группы, где вещается канал, подменяется на адрес записанного ролика. Некоторые системы позволяют «домотать» записанный ролик до конца и переключиться опять на «прямой» эфир.

Обычный PVR — просто запись по расписанию. Зашли в программу передач, выбрали интересную и нажали на кнопку записи/архивирования. Ну или с мобильного запрограммировали. Это уже детали. Потом, когда программа закончится, она будет доступна в списке записанных.

По поводу сетевого и локального, верное замечание. Однако здесь есть нюанс. Проблема в том, что не всё сводится к техническим решениям. Если PVR хранится у абонента на его локальном диске, то ответственность юридически за него несёт абонент. А если контент лежит в зоне ответственности оператора, на сервере, то юридически за него отвечает оператор. Из этого могут следовать разные дополнительные строки в лицензионном соглашении и много крючкотворческих всяких сложностей. Может, впрочем, и не следовать — тут уж как договоритесь.

продолжение следует…