ТАБЛИЦА ДАННЫХ О ПРИЛОЖЕНИЯХ ДЛЯ СИСТЕМЫ ЦИФРОВОЙ ПЕРЕДАЧИ, ПРЕДОСТАВЛЯЮЩЕЙ МНОЖЕСТВО СЕРВИСОВ Российский патент 2005 года по МПК H04N7/52 

Настоящее изобретение относится к системе цифровой передачи, в частности к системе цифрового телевидения.

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

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

В обычном транспортном потоке данные организованы следующим образом. На самом высоком уровне в таблице доступа к программам (также называемой таблицей программ), или РАТ-таблице, перечисляются значения PID для одной или нескольких таблиц распределения программ (называемых также таблицами структуры программ), или РМТ-таблиц, каждая из которых ассоциирована с некоторым сервисом, передаваемым в транспортном потоке. В свою очередь РМТ-таблица ссылается на значения PID пакетов, содержащих аудиоданные, видеоданные, данные приложений и т.д. данного сервиса. Как станет очевидно, хотя сервис можно, в первом приближении, считать телевизионным каналом, понятие "сервис" является несколько более широким понятием, так как сервис может включать в себя множество потоков аудио- и/или видеоданных, только данные приложений и т.д.

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

Информация, касающаяся передаваемых в некотором сервисе приложений, включая номер версии приложения, объем памяти, необходимый для приложения, и т.п. обычно помещается в РМТ-таблицу, в точке входа для данного сервиса.

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

Более того, гибкость функционирования декодера в том, что касается оценки приоритетности приложения и т.п., значительно ограничивается.

Цель настоящего изобретения, в самых широких и/или конкретных вариантах его осуществления, состоит в решении этой проблемы.

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

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

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

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

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

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

В типичном случае один коммерческий оператор обычно отвечает за содержание множества каналов предоставления сервисов, причем эти каналы группируются друг с другом, образуя группу ("букет") сервисов. Некоторый определенный транспортный поток часто содержит несколько групп сервисов, каждую из которых администрирует отдельный оператор. Тогда как каждый оператор обладает полной информацией о приложениях в сервисах своей группы, по очевидным причинам эта информация обычно отсутствует у других операторов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Особенности, раскрытые выше при описании аспектов настоящего изобретения, касающихся способов, могут быть также применены к аспектам, касающимся устройств, и наоборот.

Термин "система цифровой передачи", как он понимается в этом тексте, охватывает любые системы передачи для передачи или вещания, например, главным образом аудиовизуальных или мультимедийных цифровых данных. Хотя настоящее изобретение особенно применимо в системе цифрового телевизионного вещания, оно может в равной степени быть использовано в выделенных сетях передачи данных для мультимедийных Internet-приложений, в системах кабельного телевидения и т.п.

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

Используемый в этом тексте термин "декодер" или "приемник-декодер" может обозначать приемник для приема как закодированных, так и незакодированных сигналов, например, телевизионных и/или радиосигналов, которые могут передаваться путем вещания или другими способами. Этот термин может также обозначать декодер для декодирования принимаемых сигналов. Примерами исполнения подобных приемников-декодеров могут служить декодер, совмещенный с приемником для декодирования принимаемых сигналов, например, в приставке к телевизору (set-top box), декодер, функционирующий в сочетании с физически отдельным приемником, декодер, снабженный дополнительными функциями, такими как Web-браузер, или декодер, совмещенный с другими устройствами, такими как видеомагнитофон или телевизор.

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

Термин "MPEG" обозначает стандарты передачи данных, разработанные Экспертной группой по кинематографии Международной организации стандартизации (ISO) и, в частности, но не исключительно, стандарт MPEG-2, разработанный для приложений цифрового телевидения и описанный в документах Международной организации стандартизации ISO 13818-1, ISO 13818-2, ISO 13818-3 и ISO 13818-4. В контексте настоящего описания данный термин включает в себя все варианты, разновидности и усовершенствования форматов MPEG, которые могут применяться в области цифровой передачи данных.

Ниже будет описан, исключительно в качестве иллюстративного примера, предпочтительный вариант осуществления настоящего изобретения, со ссылками на прилагаемые чертежи, на которых:

фиг.1 - схематическое представление системы цифрового телевидения в соответствии с данным вариантом осуществления настоящего изобретения;

фиг.2 - архитектура системы условного доступа, показанной на фиг.1;

фиг.3 - элементы приемника-декодера, используемого в данном варианте осуществления настоящего изобретения;

фиг.4 - структура программного обеспечения декодера, используемого в данном варианте осуществления настоящего изобретения;

фиг.5 - архитектура виртуальной машины системы, представленной на фиг.4;

фиг.6 - иерархия пакетов для различных сервисов в транспортном потоке;

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

Схематически система 1 цифрового телевизионного вещания и приема показана на фиг.1. Изобретение включает в себя главным образом стандартную систему 2 цифрового телевидения, в которой для передачи сжатых цифровых сигналов используется стандарт MPEG-2. Более подробно, MPEG-2-компрессор 3 в центре вещания принимает поток цифровых сигналов (например, поток аудио- или видеосигналов). Компрессор 3 подключен к мультиплексору и скремблеру 4 линией связи 5. Мультиплексор 4 принимает несколько дополнительных входных сигналов, компонует один или несколько транспортных потоков и передает сжатые цифровые сигналы в передатчик 6 центра вещания по линии связи 7, тип которого, естественно, может быть самым разным, включая телекоммуникационные каналы связи.

Передатчик 6 передает электромагнитные сигналы по каналу связи 8 "Земля-спутник" на спутниковый транспондер 9, где выполняется их обработка электронными средствами и вещание по виртуальному каналу связи 10 "спутник-Земля" на наземный приемник 11, обычно имеющий форму тарелки, принадлежащий конечному пользователю или арендуемый им.

Сигналы, принимаемые приемником 11, передаются на совмещенный приемник-декодер 12, принадлежащий конечному пользователю или арендуемый им и подключенный к телевизору 13 конечного пользователя. Приемник-декодер 12 декодирует сжатый MPEG-2-сигнал в телевизионный сигнал для телевизора 13.

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

В состав системы может входить интерактивная система 17, также подключенная к мультиплексору 4 и приемнику-декодеру 12 и также размещенная частично в центре вещания и частично в приемнике-декодере, позволяющая конечному пользователю взаимодействовать с различными приложениями через модемный обратный канал 16.

Ниже будет более подробно описана система 20 условного доступа.

Как показано на фиг.2, система 20 условного доступа включает в себя систему 21 санкционирования подписчиков, SAS (Subscriber Authorization System). SAS 21 подключена к одной или нескольким системам 22 управления подписчиками, SMS (Subscriber Management System) 22, по одной SMS для каждого провайдера вещания, посредством TCP/IP-канала 23 (хотя в альтернативном варианте могут использоваться и другие типы линий связи). В альтернативном варианте одну SMS могут совместно использовать два провайдера вещания, или один провайдер может использовать две системы SMS, и т.п.

Первые устройства шифрования в виде шифрующих блоков 24, использующих "материнские" смарт-карты 25, подключены к SAS посредством канала связи 26. Вторые устройства шифрования, также в форме шифрующих блоков 27, использующих материнские смарт-карты 28, подключены к мультиплексору 4 посредством канала связи 29. В приемник-декодер 12 устанавливается "дочерняя" смарт-карта 30. Он подключен непосредственно к SAS 21 с помощью коммуникационных серверов 31 по модемному обратному каналу 16. SAS, наряду с другими сигналами, по запросу передает в дочернюю карту подписные права.

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

Первый и второй шифрующие блоки 24 и 27 содержат шасси, электронную VME-плату с программным обеспечением, записанным в ЭСППЗУ, до 20 электронных плат и одну смарт-карту 25 и 28 соответственно для каждой электронной платы, одну карту 28 для шифрования сообщений ЕСМ и одну карту 25 для шифрования сообщений EMM.

Функционирование системы 20 условного доступа в системе цифрового телевидения будет более подробно описано ниже со ссылками на различные компоненты системы 2 и системы 20 условного доступа.

Мультиплексор и скремблер

Обратимся к фиг.1 и фиг.2; в центре вещания цифровой видеосигнал сначала сжимают (или уменьшают скорость передачи) с помощью MPEG-2-компрессора 3. Сжатый сигнал затем передают в мультиплексор и скремблер 4 по каналу связи 5, для того чтобы мультиплексировать его с другими данными, такими как другие сжатые данные.

Скремблер формирует управляющее слово, используемое в процессе скремблирования и включаемое в MPEG-2-поток данных в мультиплексоре. Управляющее слово формируется внутри системы и позволяет совмещенному приемнику-декодеру 12 конечного пользователя дескремблировать программу.

В MPEG-2-поток данных добавляются также критерии доступа, указывающие, каким образом программа предлагается потребителям. Программа может предлагаться как в одном из многих режимов "подписки", так и/или в одном из многих режимов "с оплатой за каждый отдельный просмотр" (PPV - Pay Per View). В режиме подписки конечный пользователь подписывается на одно или несколько коммерческих предложений, или групп ("букетов"), получая таким образом права на просмотр любого канала из этих групп каналов. В предпочтительном варианте осуществления настоящего изобретения из одной группы каналов можно выбрать до 960 коммерческих предложений.

В PPV-режиме конечному пользователю предоставляется возможность покупать передачи по желанию. Это может обеспечиваться либо путем осуществляемого заранее предварительного заказа передачи ("режим предварительного заказа"), либо путем приобретения программы сразу после начала вещания ("импульсный режим"). В предпочтительном варианте осуществления настоящего изобретения все пользователи являются подписчиками (абонентами) независимо от режима просмотра - подписка или PPV-режим, но, естественно, PPV-зрителям не обязательно нужно быть подписчиками.

Сообщения управления правами (ЕСМ)

Как управляющее слово, так и критерии доступа используются для формирования сообщения управления правами (ЕСМ). ЕСМ - это сообщение, передаваемое вместе со скремблированной программой; оно содержит управляющее слово (которое позволяет дескремблировать программу) и критерии доступа к вещаемой программе. Критерии доступа и управляющее слово передаются во второй шифрующий блок 27 по каналу связи 29. В этом блоке сообщение ЕСМ формируется, шифруется и передается в мультиплексор и скремблер 4. На протяжении вещательной передачи управляющее слово обычно изменяется через каждые несколько секунд, и потому сообщения ЕСМ также передаются периодически, чтобы дать возможность дешифровать изменившееся управляющее слово. В целях резервирования каждое сообщение ЕСМ обычно включает в себя два управляющих слова: текущее управляющее слово и следующее управляющее слово.

Каждый сервис, вещаемый оператором вещания в потоке данных, включает в себя несколько отдельных компонент; например, телевизионная программа включает в себя компоненту видеоданных, компоненту аудиоданных, компоненту субтитров и т.д. Каждая из этих компонент сервиса для последующей передачи на транспондер 9 скремблируется и шифруется отдельно. Для каждой скремблированной компоненты сервиса требуется отдельное ЕСМ. В альтернативном варианте, для всех скремблированных компонент сервиса может использоваться одно ЕСМ. В том случае, когда доступ к одной и той же передаваемой программе контролируется несколькими системами условного доступа, также формируются несколько ЕСМ.

Трансляция программ

Мультиплексор 4 принимает электрические сигналы, содержащие зашифрованные EMM - из SAS 21, зашифрованные ЕСМ - из второго шифрующего блока 27 и сжатые программы - от компрессора 3. Мультиплексор 4 скремблирует программы и передает скремблированные программы, зашифрованные EMM и зашифрованные ЕСМ в виде электрических сигналов на передатчик 6 центра вещания по каналу связи 7. Передатчик 6 передает электромагнитные сигналы на спутниковый транспондер 9 через канал 8 "Земля-спутник".

Прием программ

Спутниковый транспондер 9 принимает и обрабатывает электромагнитные сигналы, передаваемые передатчиком 6, и передает эти сигналы на наземный приемник 11, обычно имеющий форму тарелки, принадлежащий конечному пользователю или арендуемый им, по каналу связи 10 "спутник-Земля". Сигналы, принимаемые приемником 11, передаются в совмещенный приемник-декодер 12, принадлежащий конечному пользователю или арендуемый им и подключенный к телевизору 13 конечного пользователя. Приемник-декодер 12 демультиплексирует сигналы с целью получения скремблированных программ с зашифрованными EMM и ЕСМ.

Если программа нескремблированная, т.е. с MPEG-2-потоком данных ЕСМ не передается, приемник-декодер 12 выполняет декомпрессию данных и преобразует сигнал в видеосигнал для передачи его в телевизор 13.

Если программа скремблированная, приемник-декодер 12 извлекает из MPEG-2-потока данных соответствующее ЕСМ и передает его в "дочернюю" смарт-карту 30 конечного пользователя. Она устанавливается в гнездо в корпусе приемника-декодера 12. Дочерняя смарт-карта 30 проверяет, имеет ли этот конечный пользователь права на дешифрирование данного ЕСМ и на доступ к данной программе. Если нет, то в приемник-декодер 12 передается отказ, указывающий, что программа не может быть дескремблирована. Если конечный пользователь такие права имеет, ЕСМ дешифрируется и извлекается управляющее слово. Приемник-декодер 12 может затем, используя это управляющее слово, дескремблировать программу. После этого выполняется декомпрессия MPEG-2-потока данных и его преобразование в видеосигнал для дальнейшей передачи в телевизор 13.

Сообщения управления предоставлением прав (EMM)

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

Возможны различные специальные типы сообщений EMM. Индивидуальные EMM предназначены для индивидуальных подписчиков и обычно используются при предоставлении PPV-услуг; они содержат идентификатор группы подписчиков и местоположение данного подписчика в этой группе.

Сообщения EMM групповой подписки предназначены для групп подписчиков из, положим, 256 индивидуальных пользователей и используются обычно для управления некоторыми услугами по подписке. Такое EMM содержит идентификатор группы и битовый массив группы подписчиков.

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

Система управления подписчиками (SMS)

Система 22 управления подписчиками (SMS) включает в себя базу данных 32, которая обрабатывает, помимо прочего, все файлы конечных пользователей, коммерческие предложения, подписки, подробные сведения об оплате в PPV-режиме и данные, касающиеся потребления услуг конечным пользователем и его прав. SMS может быть физически удалена от SAS.

Каждая SMS 22 передает в SAS 21 по соответствующему каналу связи 23 сообщения, которые предполагают изменение существующих или создание новых EMM, подлежащих передаче конечному пользователю.

SMS 22 также передает в SAS 21 сообщения, которые не предполагают каких-либо изменений в существующих EMM или создание новых, но предполагают только изменение статуса конечного пользователя (относительно прав на доступ, предоставленных конечному пользователю при заказе продукции, или суммы, на которую конечному пользователю будет выставлен счет).

SAS 21 передает сообщения (обычно запрашивающие информацию, такую как информация обратного вызова или информация о счете) в систему SMS 22, так что очевидно, что связь между этими двумя системами является двухсторонней.

Система санкционирования подписчиков (SAS)

Сообщения, формируемые SMS 22, передаются по линии связи 23 в SAS 21, которая в свою очередь формирует сообщения, подтверждающие прием сообщений, формируемых SMS 22, и передает эти подтверждения в SMS 22.

В общем, SAS содержит область ветви подписки для предоставления прав в режиме подписки и для ежемесячного автоматического возобновления прав, область ветви PPV для предоставления прав на PPV-передачи и инжектор EMM для передачи сообщений EMM, создаваемых в областях ветвей подписки и PPV, в мультиплексор и скремблер 4, тем самым обеспечивая подачу сообщений EMM в поток данных MPEG. Если должны быть предоставлены другие права, такие как права пофайловой оплаты (PPF - Pay Per File) в случае загрузки компьютерного программного обеспечения в персональный компьютер пользователя, предусматриваются также другие области такого типа.

Одна из функций SAS 21 состоит в управлении правами доступа к телевизионным программам, доступным как коммерческие предложения в режиме подписки или продаваемым в режиме PPV-передач в соответствии с различными коммерческими режимами (режим предварительного заказа, импульсивный режим). SAS 21, в соответствии с этими правами и информацией, принимаемой от SMS 22, генерирует для подписчика сообщения EMM.

Сообщения EMM передаются в шифрующий блок 24 для шифрования ключами управления и рабочими ключами. Шифрующий блок добавляет к сообщению EMM подпись и передает сообщение EMM обратно в генератор сообщений в SAS 21, где добавляется заголовок. Сообщения EMM передаются в передатчик сообщений как полные сообщения EMM. Генератор сообщений определяет время начала и конца вещания и частоту рассылки сообщений EMM и передает эти сведения как соответствующие указания вместе с сообщением EMM в передатчик сообщений. Генератор сообщений формирует любое сообщение EMM только один раз; циклическую передачу сообщений EMM выполняет передатчик сообщений.

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

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

Приемник-декодер

Ниже, со ссылкой на фиг.3, будут описаны элементы приемника-декодера 12, или приставки к телевизору (set-top box), используемого в системах цифрового вещания и пригодного для использования в настоящем изобретении. Как будет видно, основные элементы этого декодера являются практически обычными, и их реализация не выходит за рамки возможностей специалиста в этой области.

Как показано, декодер 12 снабжен несколькими интерфейсами для приема и передачи данных, в частности тюнером 40 для приема вещаемых в формате MPEG передач, последовательным интерфейсом 41, параллельным интерфейсом 42 и модемом 43 для передачи и приема данных через телефонную сеть. Декодер также включает в себя первое и второе устройство считывания смарт-карт, 44 и 45, первое устройство 44 для работы с подписной смарт-картой и второе устройство 45 для работы с банковскими и/или другими смарт-картами.

Декодер включает в себя также приемник 46 для приема инфракрасных управляющих сигналов с ручного пульта 47 дистанционного управления и выход Peritel для передачи аудиовизуальных сигналов на телевизор 13, подключенный к декодеру.

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

Архитектура программного обеспечения блока управления декодера будет описана ниже, со ссылками на фиг.4 и фиг.5. Вкратце - система использует виртуальную машину, взаимодействующую через интерфейсный уровень с операционной системой более низкого уровня, реализованной в аппаратных компонентах декодера. В том, что касается аппаратных компонентов, блок 48 управления снабжен процессором, компонентами памяти, такими как ПЗУ, ОЗУ, флэш-память и т.д., как и в известных декодерах.

Обрабатываемые блоком 48 управления приложения могут быть либо резидентными, хранящимися в ПЗУ или флэш-памяти декодера, либо вещаемыми и загружаемыми через MPEG-2-интерфейс декодера. Это могут быть приложения гидов по программам (программ передач), игры, интерактивные сервисы, приложения дистанционных покупок (для телешопинга), а также активизируемые при запуске декодера приложения, позволяющие ему немедленно переходить в рабочий режим, и приложения для настройки параметров декодера. Приложения хранятся в ячейках памяти декодера и представлены файлами ресурсов, включающими в себя файлы описаний графических объектов, файлы библиотек, файлы блоков переменных, файлы последовательностей команд, файлы приложений, файлы данных и т.п.

Архитектура системы декодера

Обратившись к фиг.4, на которой показана архитектура программного обеспечения системы приемника-декодера, можно видеть, что она является многоуровневой. Первый уровень 51 представляет собой операционную систему аппаратных компонентов приемника-декодера. Это операционная система реального времени, выбранная производителем для управления аппаратными компонентами приемника-декодера. Для обеспечения корректной синхронизации операций, осуществляемых аппаратными компонентами, используется операционная система реального времени с относительно быстрым временем ответа. Система обработки данных расположена над операционной системой аппаратного обеспечения и содержит уровень 52 промежуточного программного обеспечения и уровень 53 интерфейса приложений.

Сообщения о событиях передаются между уровнем 51 операционной системы и уровнем 52 промежуточного программного обеспечения, находящимся непосредственно над ним. Уровень промежуточного программного обеспечения написан на таком языке, как ANSI С, и содержит элементы виртуальной машины 54 и ряд интерфейсов 55, включая графический интерфейс 56, интерфейс флэш-памяти/ППЗУ 57, интерфейс 58 протоколов и интерфейс 59 устройств.

Использование виртуальной машины позволяет, в частности, обеспечить независимость между приложениями 66, 67 верхнего уровня, описанными более подробно ниже и обычно предоставляемыми администратором системы или одним или несколькими операторами, и низкоуровневой операционной системой 51, как правило, реализованной производителем аппаратного обеспечения декодера.

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

Уровень 53 интерфейса приложений (API) содержит ряд высокоуровневых модулей 60-65, написанных на объектно-ориентированном интерпретируемом языке, таком как Java. Эти модули обеспечивают интерфейс между высокоуровневыми приложениями, обычно создаваемыми провайдером сервисов (интерактивный гид по программам, приложения для телешопинга, Internet-браузер и т.д.), и виртуальной машиной системы. Примеры подобных приложений представлены ниже.

Низкоуровневая операционная система обычно встроена в аппаратных компонентах декодера; тем не менее, в некоторых реализациях низкоуровневая операционная система может быть загружаемой. Модули уровня промежуточного программного обеспечения и уровня интерфейса приложений могут загружаться в ОЗУ или флеш-память декодера из вещаемой передачи. С другой стороны, некоторые или все компоненты уровня промежуточного программного обеспечения или уровня интерфейса приложений могут сохраняться в ПЗУ либо флеш-памяти (при ее наличии) декодера. Понятно, что физическая организация памяти декодера отличается от ее логической организации.

Приложения и менеджер приложений

Как показано на фиг.4, несколько высокоуровневых приложений 66 расположены над нижними уровнями и взаимодействуют с ними через уровень 53 интерфейса приложений. Как будет описано ниже, приложения могут происходить из различных источников и/или от различных операторов. Общее управление такими приложениями осуществляется менеджером 67 приложений, который сам установлен как приложение и который отвечает за организацию загрузки вещаемых приложений, управление правами каждого приложения на доступ к более низким уровням системы и управление ими, и т.д.

Уровень интерфейса приложений

Обратимся к уровню 53 интерфейса приложений, показанному на фиг.4; как упоминалось выше, модули этого уровня написаны на объектно-ориентированном языке, таком как Java. Каждый модуль определяет набор библиотек классов, вызываемых во время работы системы. В настоящей системе установлены следующие модули.

Модуль Lang/Util 60. Эти модули определяют классы, необходимые виртуальной машине для работы с объектами. Эти библиотеки классов обычно входят в состав стандартной библиотеки выбранного объектно-ориентированного языка.

Модуль MHEG-5 61. Этот модуль определяет классы, относящиеся к манипуляции графическими объектами на телевизионном экране. Эти объекты являются отличными от аудиовизуальных данных и могут образовывать, например, идентификаторы каналов или текст, накладываемый поверх отображаемых изображений. Определение классов внутри этого модуля должно отвечать нормам формата MHEG-5, определяемым стандартами ETS 300777-3 и ISO/ISE 13522-5 (и стандарту ISO/ISE 13522-6 в случае системы на базе Java).

Модуль 62 инструментальных средств. Этот модуль содержит классы, используемые для загрузки и декомпрессии информации, а также классы, относящиеся к управлению файловой системой и памятью приемника-декодера, и классов, относящихся к соединению с Internet.

Модуль 63 внешних устройств. Этот модуль определяет классы, необходимые для управления периферийными устройствами, подключенными к приемнику-декодеру, как описано выше, и включающими в себя модем, устройства считывания смарт-карт, MPEG-тюнер, и т.д.

Сервисный модуль 64. Этот модуль определяет классы, необходимые для разработки высокоуровневых интерактивных приложений, таких как управление данными кредитных карт и т.п.

Модуль DSMCC-UU 65. Этот модуль реализует протоколы, необходимые для обмена данными между клиентом и сервером для поиска и чтения файлов данных. Реализация этого модуля должна соответствовать требования стандарта ISO/IEC 13818-16 и директивам, изложенным в DAVIC, часть 9.

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

Модули 53 предоставляют библиотеки классов для среды объектно-ориентированного программирования. Поведение их классов будет зависеть от выбранного языка. В случае Java-приложения, например, будет использоваться структура классов с простым наследованием.

Уровень интерфейсов

Как показано, уровень интерфейсов состоит из четырех модулей: графического модуля 56, модуля 57 управления файлами памяти, модуля 58 протоколов и менеджера 59 устройств. Хотя модули на этом уровне описываются как интерфейсные модули, их функция заключается в создании "склеивающего" слоя для реализации модулей интерфейса приложений и работы виртуальной машины в целом.

Графический модуль 56, например, обеспечивает создание графических объектов и управление ими. Он запрашивает у низкоуровневой ОС отображение основных графических примитивов, таких как одиночные пиксели, линии, прямоугольники и т.п. Реализация этого модуля зависит от графических возможностей низкоуровневой ОС, устанавливаемой производителем. Помимо модуля MHEG-5 4311, в некоторых случаях эти функции могут быть более эффективно реализованы на этом программном уровне, чем на языке более высокого уровня, выбранном для уровня приложений, расположенного выше.

Аналогичным образом модуль 57 управления файлами памяти включает в себя низкоуровневые команды чтения/записи файлов, применяемые с компонентами памяти системы. Как правило, операционная система аппаратных компонентов включает в себя лишь команды, необходимые для чтения/записи сектора или страницы компонента памяти. Как и в случае графического модуля 56, данный модуль позволяет эффективно вводить в систему набор простых низкоуровневых приложений.

Модуль 58 протоколов определяет библиотеку протоколов передачи данных, вызовы которой могут осуществляться для передачи данных через, например, уровень TCP/IP декодера.

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

Описание виртуальной машины

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

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

Центральным элементом многопоточной машины является планировщик 70, состоящий из утилиты 71 диспетчеризации потоков и утилиты 72 управления монитором. Планировщик 70 отдает команды на выполнение потоков, создаваемых приложениями, находящимися вне виртуальной машины, и создаваемых самой виртуальной машиной (например, потока очистки памяти, или "сборки мусора").

Менеджер 73 событий обрабатывает таблицу маршрутизации событий и перечни событий, на которые подписаны потоки, и осуществляет централизованную отправку результатов обработки событий.

Менеджер 74 памяти осуществляет и отменяет выделение областей памяти в запоминающих устройствах системы, а также производит удаление из памяти объектов, на которые нет ссылок (очистка памяти).

Менеджер 75 классов ведает классами программного кода, загруженного из вещательного сигнала, взаимодействуя с менеджером 80 безопасности с целью проверки целостности загруженного кода и менеджером 76 файлов, выполняющим приложения.

Менеджер 76 файлов выполняет файлы в системе и управляет механизмом загрузки интерактивных приложений и данных.

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

Интерпретатор 77, содержащий утилиту 78 интерпретации байт-кода и утилиту 79 интерпретации промежуточного кода ("m-кода"), осуществляет интерпретацию приложений, написанных в этих двух видах кода, причем байт-код соответствует Java приложениям, а "m-код" - это название оригинального кода, разработанного авторами.

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

Организация таблиц данных в транспортном потоке

Как показано на фиг.6, вещаемый транспортный поток данных содержит несколько пакетов стандартного формата, несущих в себе таблицу 90 доступа к программам (таблицу программ) (PAT), при этом идентификатор PID такого пакета устанавливается стандартом MPEG-2 равным 0×00. Таблица 90 доступа к программам предоставляет точку входа для доступа к данным программ и содержит таблицу, в которой указываются значения идентификаторов PID таблиц 91, 92 распределения программ (таблиц структуры программ) (РМТ), ассоциированных с определенными сервисами или каналами данного потока. Каждая таблица 91, 92 распределения программы содержит в свою очередь ссылки на значения идентификаторов PID пакетных потоков аудиотаблиц 93 и видеотаблиц 94, относящихся к этому сервису.

Как можно видеть, таблица 92 распределения программы также содержит ссылки на значения идентификаторов PID других пакетов 95, 96, 97, включающих в себя дополнительные данные, ассоциированные с этим сервисом, в частности данные сообщений ЕСМ, сформированные несколькими системами условного доступа и ассоциированные с этим сервисом, а также данные приложений, передаваемых в этом сервисе.

Помимо таблицы 90 доступа к программам (PAT), транспортный MPEG-поток также содержит таблицу 101 условного доступа (CAT), значение идентификатора PID которой установлено равным 0×01. Таким образом, любые пакеты, заголовки которых содержат эти значения PID, автоматически идентифицируются как содержащие информацию по управлению доступом.

CAT 97 содержит ссылки на значения PID MPEG-пакетов 98, 99, 100, относящихся к ЕММ-данным одной или нескольких систем условного доступа. Как и в случае пакетов с таблицами РМТ, значения PID для ЕММ-пакетов, на которые содержатся ссылки в таблице CAT 101, не являются фиксированными и могут задаваться по выбору оператора системы.

Кроме значений идентификаторов таблицы PAT и таблицы CAT, упомянутых выше, стандарт MPEG-2 определяет очень мало фиксированных значений идентификаторов PID. Соответственно, большинство значений идентификаторов PID могут задаваться, в определенных пределах, оператором. Как будет описано ниже более подробно, согласно рассматриваемому варианту осуществления настоящего изобретения предлагается присвоить таблице, содержащей данные, касающиеся приложений, передаваемых в нескольких сервисах и группах сервисов, идентификатор PID с фиксированным значением.

Формат транспортных пакетов и данных приватных секций

Как известно, транспортные MPEG-пакеты имеют фиксированную длину в 188 байтов, включая заголовок. В стандартном пакете три байта заголовка, следующие за данными синхронизации, содержат:

Таблица IПризнак ошибки передачи1 битПризнак блока полезной нагрузки1 битПриоритет при передаче1 битИдентификатор пакета (PID)13 битовУправление скремблированием при транспортировке2 битаУправление полем адаптации2 битаСчетчик непрерывности4 бита

Формат этих полей определяется главным образом стандартом MPEG.

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

В случае других данных, таких как данные приложений или данные сообщений ЕСМ и EMM, используется формат, отличный от PES-пакетирования. В частности, данные, содержащиеся в полезной нагрузке транспортного пакета, разделяются на последовательность секций или таблиц, причем заголовок таблицы или секции содержит идентификатор таблицы, или TID, идентифицирующий эту таблицу. В зависимости от размера данных секция может быть полностью размещена в полезной нагрузке пакета или может быть расширена в последовательность таблиц, размещенных в нескольких транспортных пакетах. В контексте стандарта MPEG-2 термин "таблица" часто используется для обозначения одиночной таблицы данных, тогда как термин "секция" обычно означает одну из нескольких таблиц с одинаковым значением TID.

Фактические значения TID, используемые для ссылки на информацию, содержащуюся в этих таблицах или секциях, стандартом MPEG-2 не фиксируются и могут задаваться оператором сервиса или группы сервисов по собственному усмотрению.

Как и в случае данных транспортных пакетов и данных PES-пакетов, структура данных (синтаксис) таблицы или секции дополнительно определяется стандартом MPEG-2. В частности, предлагаются две возможные формы синтаксиса приватной таблицы или секции: длинный формат и короткий формат.

Как в коротком, так и в длинном формате заголовок включает в себя по меньшей мере данные, содержащие:

Таблица IIИдентификатор таблицы (TID)8 битовПризнак синтаксиса секции1 битПризнак приватности/зарезервировано1 битЗарезервировано согласно ISO2 битаДлина секции12 битов

Поля признака приватности и длины приватной секции включают данные, не нормированные стандартом MPEG-2, и оператор системы может использовать их в своих целях. Более подробную информацию о синтаксисе таблицы читатель может почерпнуть из описания стандарта MPEG-2.

Приложения с доступом через одну или несколько таблиц РМТ

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

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

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

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

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

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

Кроме того, после каждого переключения канала декодеру необходимо загружать и анализировать данные РМТ-таблицы, прежде чем у него будет достаточно информации для выполнения каких-либо действий в отношении подлежащих загрузке приложений или приложений, выполняемых в данный момент. Это может занять некоторое время. Как упоминалось выше, каждый сервис полностью независим и включает в себя все приложения, необходимые для его функционирования; информация, касающаяся таких приложений, передается в РМТ-таблице этого сервиса.

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

Обратимся к фиг.7; ниже будет определен формат таблиц и секций транспортного MPEG-потока, позволяющий преодолеть такие проблемы известных систем.

Таблица данных о приложениях

Как показано на фиг.7, транспортный поток включает в себя, помимо таблиц РМТ1 91 и РМТ2 92, используемых для описания данных, содержащихся в первом и втором сервисах, таблицу или таблицы данных о приложениях, 110 и 111, для каждой имеющейся группы сервисов. ADT B1 - таблица такого вида для первой группы сервисов, ADT B2 - для второй группы сервисов, и т.д.

Так же как и для таблиц PAT и CAT, идентификатору PID для ADT-таблицы присвоено постоянное значение, которое в настоящее время не зарезервировано и не запрещено стандартом MPEG-2. Ссылки на все таблицы данных о приложениях, или ADT, во всех группах сервисов производятся с помощью этого значения PID и, предпочтительно, фиксированного значения TID. Для обеспечения разным группам сервисов разных ADT-таблиц каждой ADT-таблице, ассоциированной с определенной группой сервисов, присваивается уникальное расширение TID. Эти значения расширений TID не обязаны быть фиксированными, и они могут выбираться по согласованию между операторами отдельных групп сервисов.

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

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

Переключение между группами сервисов, на которые подписан абонент, путем замены подписной карты заставит декодер загрузить ассоциированную с новой группой сервисов ADT-таблицу, обращение к которой производится по ее собственному уникальному значению расширения TID. Значение расширения TID может быть непосредственно предоставлено информацией, принятой от подписной карты, или может быть определено таблице в декодере. Равным образом, декодер может быть настроен на правильное значение расширения TID другими способами, например, по модемному каналу связи.

В альтернативном варианте исполнения декодер может быть сконфигурирован на сканирование и фильтрование всех ADT-таблиц в транспортном потоке, используя фиксированные значения идентификаторов PID и TID. Как будет описано ниже, в каждой ADT-таблице имеется ссылка на РМТ сервисов, к которым применима данная ADT-таблица. По этой информации при работе с конкретной группой сервисов декодер может прийти к заключению, какая ADT-таблица должна применяться.

Как можно видеть, ADT-таблица 110, ассоциированная с группой сервисов В1, разделена на три части: часть 112 описания сервисов, часть 113 описания приложений и необязательная сигнатурная (с подписью) часть 114.

Часть 112 описания сервисов содержит информацию о том, какие из приложений А1, А2, A3 и т.д. передаются в каждом сервисе РМТ1, РМТ2 и т.д. группы В1 сервисов. Каждое приложение идентифицируется уникальным идентификатором приложения (A1, A2 и т.д.).

На фиг.7 часть 112 описания сервисов идентифицирует сервис РМТ1 как ассоциированный с приложениями A1, A3 и т.д., а сервис РМТ2 - как ассоциированный с приложениями A1, A2, А4 и т.д.

Часть 113 описания приложений содержит описание приложений, доступных через все сервисы данной группы сервисов, и связывает идентификатор приложения с данными, описывающими характеристики этого приложения. Это описание обычно включает в себя следующие параметры:

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

"Тип приложения" (application_type) - например, приложение на чистом языке Java или MHEG-5-приложение. Определение типа приложения является необходимым потому, что активация приложения может быть совершенно разной для приложений разных типов и поскольку в одной и той же группе сервисов могут передаваться приложения различных типов. Тип приложения может также включать в себя номер версии программного обеспечения.

"Название приложения" (application_name) - название приложения, как оно известно пользователю или как оно отображается для пользователя. Обычно это то название, которое пользователь видит при запуске приложения. Например, можно представить себе вывод в окне сообщения "загружается ПРОВОДНИК" после запуска приложения, которое называется "ПРОВОДНИК".

"Загрузочная информация приложения" (application_bootinfo). Точка входа для приложения (в зависимости от параметра "тип приложения"), к которой менеджер приложений должен обратиться для загрузки и запуска этого приложения.

"Флаг приложения" (application_flag). Это поле отображает поведение приложения в том, что касается загрузки, запуска и т.д. В частности, это поле может быть использовано для задания того, должно ли данное приложение оставляться или удаляться при переключении с одного сервиса группы на другой, независимо от указаний, содержащихся в РМТ рассматриваемых сервисов.

"Ключ приложения" (application_key). Клавиша пульта дистанционного управления или другое входное воздействие, связанное с запуском приложения. Например, в случае приложения типа проводника или штурмана ключом приложения может быть клавиша пульта дистанционного управления, запускающая проводник. Для автоматически запускаемых приложений значение ключа приложения может быть некоторым значением по умолчанию.

"Эксклюзивность приложения" (application_exclusive). Признак, указывающий на то, что приложение является эксклюзивным для некоторого сервиса. Это позволяет менеджеру приложений составить перечень идентификаторов приложений, эксклюзивных для каждого сервиса, при этом менеджер приложений удаляет такое приложение при переключении на другой сервис.

"Приоритет приложения" (application_priority) - находится в диапазоне, например, между минимальным уровнем "1" и максимальным "7". Приоритет может означать приоритетность при доступе к ресурсам декодера и/или приоритет приложения по загрузке. При необходимости, для отражения этих различных приоритетов можно использовать два различных поля приоритета.

"Память приложения" (application_memory) - объем памяти, необходимый для загрузки приложения. Имеется в виду не только размер приложения, но и оценка максимального объема памяти, который будет использоваться самим приложением и его данными.

"Версия приложения" (application_version). Это текущая версия приложения.

"DVB-триплет". Идентифицирует перечень сервисов для приложений, специфичных для некоторого определенного сервиса. DVB-триплет складывается из исходного идентификатора сети (Network_id), идентификатора транспортного потока (TransportStream_Id) и идентификатора сервиса (Service_Id).

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

Среди другой информации, помещаемой в часть описания приложений, может быть информация, необходимая для обнаружения модулей приложения, находящихся на следующем структурном уровне в таблицах или секциях с данным TID. Например, в дополнение к пакетированию в таблицы и секции для передачи, само приложение может быть организовано в карусель данных, например, в соответствии с форматом DSMCC. Содержащаяся в ADT-таблице информация может включать в себя описание маршрута или адрес карусели, что позволит декодеру переходить в определенную точку входа для загрузки приложения.

Наконец, ADT-таблица 110 включает в себя подпись 114, содержащую электронную подпись данных ADT-таблицы 110 и позволяющую декодеру проверять происхождение и целостность данных таблицы.

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

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

Как было описано выше, ADT-таблица для некоторой определенной группы сервисов имеет наперед заданные значения PID и расширения TID, и эта таблица загружается и проверяется сразу же после запуска декодера, независимо от того, на какой канал предоставления сервиса настроен декодер (если он вообще настроен на какой-либо канал). Получив информацию из этой таблицы, менеджер приложений сможет затем принимать обоснованные решения в отношении того, оставлять или удалять приложения после настройки на некоторый сервис или переключения на другой сервис, без необходимости в ожидании загрузки РМТ-таблицы.

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

В случае, если декодер сначала настраивают на канал предоставления сервиса РМТ1, показанный на фиг.7, менеджер приложений идентифицирует приложения А1, A3, передаваемые в этом канале предоставления сервиса, как наличествующие и действительные, то есть как приложения, соответствующие приложениям, перечисленным в части 112 описания сервисов ADT-таблицы данной группы сервисов. Используя данные ADT-таблицы для этих приложений, менеджер приложений затем определяет, загружать или не загружать эти приложения, и, в том случае, если выполнены все условия (достаточно памяти и т.д.), загружает приложения А1, A3 и т.д.

Если пользователь теперь переключится на канал предоставления сервиса РМТ2, менеджер приложений идентифицирует приложения А1, А2, А4 как наличествующие в этом канале и действительные.

Что касается приложения А1, менеджеру приложений будет известно, что это приложение уже загружено и его последняя версия находится в декодере; он не предпримет никаких действий, оставляя приложение А1 выполняться в декодере "как есть". Что касается приложений А2 и А4, менеджер приложений может, например, оценить значения полей "приоритет приложения", "память приложения" и т.д. для этих приложений и сравнить эти значения с соответствующими значениями для приложения A3, загруженного ранее и выполняемого в данный момент в декодере. Сравнение может также производиться по значению поля "флаг приложения" выполняемого в данный момент приложения (см. выше).

Несмотря на то что приложение A3 не требуется для доступа к каким-либо возможностям, предоставляемым каналом предоставления сервиса, доступ к которому осуществляется через РМТ2, и не присутствует в нем, менеджер приложений может, тем не менее, решить, в зависимости от значения параметра "флаг приложения", продолжить выполнение приложения A3, вместо того чтобы загружать то или иное из приложений А2, А4, или вместе с этим. Если пользователь затем вернется к РМТ1, приложение A3 будет, таким образом, немедленно доступным.

Возможны многие другие альтернативные варианты осуществления. Например, менеджер приложений может быть сконфигурирован на удаление приложения А1 (например, если флаг "эксклюзивность приложения" приложения А1 ассоциирован с таблицей РМТ1); на оставление приложения A3 в течение ограниченного периода времени, по истечении которого приложение A3 удаляется и приложения А2, А4 загружаются; на оставление приложения A3 до тех пор, пока пользователь не нажмет некоторую клавишу на пульте дистанционного управления, и на уничтожение приложения A3 после этого с последующей загрузкой одного из приложений А2, А4, и т.д.

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

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

Изобретение относится к системе цифрового телевидения. Достигаемый технический результат – повышение быстродействия и обеспечение гибкости функционирования декодера. Способ передачи данных приложений в цифровом транспортном потоке характеризуется тем, что вводится таблица данных о приложениях, содержащая информацию, касающуюся приложений, передаваемых в каждом сервисе транспортного потока. Таблица данных о приложениях может известным способом снабжаться фиксированным идентификатором пакета (PID) и расширением идентификатора таблицы (TID), изменяющимся в зависимости от выбранной группы сервисов. Использование одной таблицы данных о приложениях для предоставления информации по всем сервисам группы дает ряд преимуществ, в частности при принятии решений оставлять или не оставлять определенные приложения при переключении с одного сервиса на другой. 2 н. и 25 з.п. ф-лы, 7 ил.

1. Способ передачи данных приложений в множестве сервисов в цифровом транспортном потоке, причем в каждом сервисе из упомянутого множества сервисов передается по меньшей мере одно приложение, включающий введение в транспортный поток таблицы данных о приложениях, содержащей информацию, касающуюся упомянутого по меньшей мере одного приложения, передаваемого в каждом из множества сервисов упомянутого транспортного потока.2. Способ по п.1, отличающийся тем, что упомянутая таблица данных о приложениях передается в транспортном пакете, имеющем некоторое предварительно заданное значение идентификатора пакета, указывающее на наличие в данном пакете таблицы данных о приложениях.3. Способ по п.1, отличающийся тем, что упомянутая таблица данных о приложениях подписывается электронной подписью, так чтобы позволить декодеру убедиться в происхождении таблицы данных о приложениях от известного оператора.4. Способ по п.1, отличающийся тем, что каждый сервис дополнительно включает в себя таблицу распределения программы, предоставляющую доступ к приложениям, передаваемым в данном сервисе, причем сама таблица распределения программы содержит информацию, касающуюся упомянутого по меньшей мере одного приложения, передаваемого в данном сервисе.5. Способ по п.1, отличающийся тем, что упомянутая таблица данных о приложениях дополнительно содержит информацию о том, какие приложения могут быть доступны через какой сервис.6. Способ по п.1, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, также включает в себя информацию об объеме памяти, необходимом для выполнения приложения.7. Способ по п.1, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, включает в себя значение уровня приоритета, указывающее на относительный приоритет приложения.8. Способ по п.1, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, включает в себя значение показателя эксклюзивности, указывающее на то, что приложение является эксклюзивным для по меньшей мере одного сервиса.9. Способ по п.1, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, включает в себя значение флага, определяющее, какое действие должно быть выполнено над приложением при переключении сервиса.10. Способ по п.1, включающий введение множества упомянутых таблиц данных о приложениях, каждая из которых содержит информацию, касающуюся приложений, входящих в некоторую группу сервисов.11. Способ по п.10, отличающийся тем, что каждая таблица данных о приложениях передается либо в таблице, либо в секции транспортного пакета, при этом каждая таблица данных о приложениях ассоциирована либо с таблицей, либо с секцией, имеющей либо некоторое особое значение идентификатора таблицы, либо некоторое особое значение расширения идентификатора таблицы.12. Способ по п.1, используемый в системе цифрового телевидения.13. Способ по п.1, отличающийся тем, что упомянутый цифровой транспортный поток соответствует стандарту MPEG.14. Декодер для использования в способе по п.1, содержащий запоминающее устройство для хранения таблицы данных о приложениях, включающей в себя информацию, касающуюся приложений, передаваемых в множестве сервисов в транспортном потоке, и средство для управления по меньшей мере одним — загрузкой или оставлением — таких приложений в зависимости от упомянутой информации, содержащейся в упомянутой таблице данных о приложениях, при переключении на другой сервис.15. Декодер по п.14, отличающийся тем, что упомянутая таблица данных о приложениях подписана электронной подписью, так чтобы декодер мог удостовериться в происхождении таблицы данных о приложениях от известного оператора.16. Декодер п.14, отличающийся тем, что упомянутая таблица данных о приложениях дополнительно содержит информацию о том, какие приложения могут быть доступны через какой сервис.17. Декодер по п.14, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, также включает в себя информацию об объеме памяти, необходимом для выполнения приложения.18. Декодер по п.14, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, включает в себя значение уровня приоритета, указывающее на относительный приоритет приложения.19. Декодер по п.14, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, включает в себя значение показателя эксклюзивности, указывающее на то, что приложение является эксклюзивным для по меньшей мере одного сервиса.20. Декодер по п.14, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, включает в себя значение флага, определяющее, какое действие должно быть выполнено над приложением при переключении сервиса.21. Декодер, содержащий запоминающее устройство для хранения таблицы данных о приложениях, включающей в себя информацию, касающуюся приложений, передаваемых в множестве сервисов в транспортном потоке, и средство для управления по меньшей мере одним - загрузкой или оставлением - таких приложений в зависимости от упомянутой информации, содержащейся в упомянутой таблице данных о приложениях, при переключении на другой сервис.22. Декодер по п.21, отличающийся тем, что упомянутая таблица данных о приложениях подписана электронной подписью, так чтобы декодер мог удостовериться в происхождении таблицы данных о приложениях от известного оператора.23. Декодер по п.21, отличающийся тем, что упомянутая таблица данных о приложениях дополнительно содержит информацию о том, какие приложения могут быть доступны через какой сервис.24. Декодер по п.21, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, также включает в себя информацию об объеме памяти, необходимом для выполнения приложения.25. Декодер по п.21, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, включает в себя значение уровня приоритета, указывающее на относительный приоритет приложения.26. Декодер по п.21, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, включает в себя значение показателя эксклюзивности, указывающее на то, что приложение является эксклюзивным для по меньшей мере одного сервиса.27. Декодер по п.21, отличающийся тем, что информация, касающаяся приложений, передаваемая в упомянутой таблице данных о приложениях, включает в себя значение флага, определяющее, какое действие должно быть выполнено над приложением при переключении сервиса.