Необходимость удаленного обновления прошивок ТВ-приставок (STB) по сети, получившее название OTA (over-to-air), появилась почти одновременно с внедрением цифрового вещания и сегодня широко используется в сетях цифрового телевидения. Разработчики систем условного доступа часто включают услугу OTA в базовую версию своих продуктов. В этом случае операторы, приобретая систему условного доступа (СУД ), решают и проблему организации обновлений. Но иногда включение функции OTA в продукте, невозможно или требует дополнительных затрат.

Как поступить оператору при отсутствии функции OTA? ПO приемников можно обновить и через интерфесы USB или RS 232, но это гораздо менее удобно.

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

Рассмотрим организацию сервиса OTA на примере работы одного из операторов кабельного телевидения в стандарте DVB-C. Применительно к данному случаю услуга ОТА, разумеется, означает обновление по кабелю.

На рисунке 1 приведена структурная схема организации сервиса OTA. Важным компонентом системы является наличие мультиплексора с возможностью приема потоков данных по IP.

Рис. 1 Структурная схема организации обновления ПО по эфиру

В качестве источника потока данных выступает персональный компьютер под управлением операционной системы Linux с установленным ПО, которое позволяет проигрывать транспортный поток с заданной скоростью по IP-протоколу. Скорость выбирается в результате компромисса между двумя требованиями. С одной стороны, поток обновления должен занимать как можно меньшую транспортную полосу, а с другой, процесс передачи информации должен быть достаточно быстрым. В рассматриваемом примере была выбрана скорость 100 Кбит/с, которая позволяет передать обновление примерно за 2 минуты.

Транспортный поток с обновлениями формируется производителем STB и в готовом виде передается оператору. Задача последнего — правильно интегрировать обновления в общий транспортный поток в соответствии со стандартами DVB. Поток данных с обновлениями можно скремблировать, что защитит его от несанкционированного доступа. Важной характеристикой системы также является возможность одновременной передачи обновлений ПО для нескольких моделей приставок одного или нескольких производителей.

Для описания параметров потока данных используется дескриптор data_broadcast_id_descriptor в сервисной таблице PMT (Program Map Table).

Рассмотрим структуру полей таблицы PMT на примере реального транспортного потока.

Структура, приведенная на рис 2, получена с помощью анализатора сервисной информации TSR.

Рис. 2 Пример структуры таблицы PMT для потока данных обновления ПО

• В поле stream_type вводится значение 0x0B, указывающее на то, что передается поток типа IEC 13818-6, и передача ведется с помощью секций DSM-CC
• В поле data_broadcast_id указывается значение 0x000a, зарезервированное для передачи данных обновления ПО в соответствии со стандартом ETR 162
• Поле id_selector_byte для data_broadcast_id со значением 0x000a должно содержать структуру system_software_update_info, сформированную в соответствии со стандартом ETSITS 102 006

В таблице 1 приведен синтаксис этой структуры.

Таблица 1. Синтаксис структуры system_software_update_info

• OUI_data_length: поле определяет общую длину следующих данных OUI (уникальный идентификационный номер организации)
• OUI: 24-битное поле содержит IEEE OUI (как описано в IEEE 802) организации, которая предоставляет услугу программного обновления в транспортном потоке. Значение OUI 0x00015A указывает на услугу любой организации
• update_type: 4-битное поле определяет тип системы обновления в соответствии с таблицей 2. В данном примере это значение равно 0x0, т.к. использовано собственное решение
  

Таблица 2. Тип обновления

• update_versioning_flag: значение 0 указывает на то, что в следующем поле update_version нет значащей информации. Если флаг установлен в 1, то поле update_version отражает изменения в системе.
• update_version: значение поля должно увеличиваться на 1 при каждом изменении обновления
• selector_length: поле определяет общую длину данных размещенных в поле selector
• selector_byte: это поле позволяет передавать дополнительную информацию. В нашем случае это поле содержит информацию о модели STB, версию аппаратного обеспечения и код производителя

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

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

Для запуска обновлений в рассматриваемом проекте используется специальная программа broadcast_update. Она работает в ОС на базе Linux (возможна компиляция под Windows), управление осуществляется через командную строку.

Программа предназначена для вещания транспортного потока из файла на мультиплексер: исходный поток для вещания берётся из файла, ПО читает его порциями, кратными 188 байтам, и выдает с заданной скоростью на указанный в командной строке IP-адрес и порт мультиплексера. Файл вещается непрерывно, по кругу. Чтобы не нарушалась его целостность, приходится править поле Continuity Counter для каждого пакета (учитывая Packet ID), т. е. фактически поле Continuity Counter в TS-пакетах из файла игнорируется и для каждого Packet ID на выходе считается заново.

Вызов программы вещания предельно прост: broadcast_update IP_ADDRESS UDP_PORT BITRATE FIRMWARE_TS_FILE, где

• IP_ADDRESS и UDP_PORT — адрес и UDP-порт назначения пакетов (где их будет ожидать мультиплексор)
• BITRATE — максимально допустимый битрейт в килобитах
• FIRMWARE_TS_FILE — путь к файлу транспортного потока с обновлениями ПО

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

Литература:

1. ETSI TS 102 006: Digital Video Broadcasting (DVB); Specification for System Software Update in DVB Systems.
2. ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems".
3. ETSI ETR 162: "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes for DVB systems".

Скачать PDF