Способ передачи цифровых услуг по сети и устройство, осуществляющее способ

Способ передачи цифровых услуг по сети и устройство, осуществляющее способ

Иллюстрации

Показать все

Реферат

Настоящее изобретение относится к передаче цифровых услуг, а более конкретно услуг, совместимых с DVB-стандартом (цифровое видеовещание). DVB определяет услугу как «последовательность программ под управлением станции вещания, которая может транслироваться как часть перечня» по сети обычно типа широковещательной трансляции (наземная, кабельная или спутниковая), но также, особенно в последнее время, по сети IP-типа, другими словами, по сети, поддерживающей протокол Интернета (IP). Спецификация IP может быть найдена в RFC-документах (запрос на комментарии), поддерживаемых IETF (инженерной проблемной группой Интернет) под номером 791.

Распознавание цифровых услуг, предлагаемых сетью, стандартизировано стандартом DVB в контексте спутниковой, кабельной или цифровой наземной сети передачи. Этот стандарт описывается в документе «Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB Systems», опубликованном ETSI (Европейским институтом стандартов по телекоммуникациям) под номером ETSI EN 300 468. Этот документ описывает набор таблиц, содержащих информацию о сети, о частотах, при которых потоки данных, содержащие услуги, передаются, о предлагаемых услугах и т.д. Читатель может также обратиться к документу «MPEG-2 system-ISO IEC 13818-1" для определения формата транспортного потока. Транспортный поток поэтому содержит аудиоданные, видеоданные, вспомогательные данные, такие как субтитры, телетекст или интерактивные приложения в форме простых потоков, и минимум обязательных сигнализирующих таблиц, используемых для того, чтобы организовать содержимое как таблицу сетевой информации (NIT), разрешающую другим транспортным потокам в сети быть найденными, таблицу ассоциативной связи программ (PAT) и таблицу соответствия программ (PMT) среди прочего. Эти таблицы объединены в транспортный поток, приемник конфигурируется с помощью данных, необходимых для того, чтобы подключиться к первому потоку, разрешая ему принять эти таблицы и создать из их содержимого базу данных, содержащую список услуг, предложенных сетью, и данных соединения, необходимых для того, чтобы принять их.

С распространением цифровых двунаправленных сетей данных, в частности Интернет, и вышеупомянутого вывода высокоскоростных услуг техническая возможность передавать аудиовизуальные цифровые услуги по этому типу сети теперь стала доступной. Также частные, с высокой скоростью передачи данных IP-сети развиваются как для корпоративного, так и для домашнего использования. В этом контексте DVB работает для того, чтобы стандартизировать трансляцию DVB-услуг по IP-сетям. Рабочая группа, называемая DVB-IPI (Инфраструктура протокола Интернета), находится в процессе завершения спецификации, касающейся транспортировки цифровых DVB-услуг по IP-сети, а более конкретно, распознавания этих услуг. Предложение, в качестве рассматриваемого в настоящий момент, описано в документе «DVB-IP Phase 1 Handbook» под ссылкой IPI2003-227. Решение, как рассматриваемое в настоящий момент рабочей группой, ориентировано на разделение между трансляцией услуг в форме транспортных потоков, содержащих одну DVB-услугу, с одной стороны, и информацией, описывающей эти услуги, доступной в форме XML-файлов (расширяемый язык разметки), доступных терминалам по запросу, например, HTTP (протокол передачи гипертекста) может, например, быть использован для того, чтобы найти эти файлы. Это решение кажется обычным, поскольку оно эксплуатирует двунаправленную природу IP-соединения, как противоположную спутниковой передаче, например. На практике стандарты, такие как DVB, разработаны исходя из перспективы однонаправленной сети передачи, требующей, чтобы вся информация, которая, вероятно, является полезной для приемника, передавалась постоянно. Двунаправленная природа рассматриваемых сетей означает, что различие может быть очерчено между информацией, полезной для декодирования аудиовизуальной услуги, и информацией описания услуги. Эти два типа информации, которые обычно включены в DVB-поток, не используются одновременно приемником. Их передача по сети может поэтому быть разделена, таким образом предоставляя сохранение пропускной способности посредством того, что сигнализирующая информация передается только по запросу, а не постоянно в аудио- и видеоканале. Кроме того, предоставление информации по сети IP-типа через HTTP-серверы в форме XML-файлов данных является преобладающим решением, широко принятым в этом типе сети.

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

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

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

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

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

Согласно конкретному варианту осуществления изобретения первый IP-адрес широковещательной трансляции и первый номер порта вводятся пользователем.

Согласно конкретному варианту осуществления изобретения первый IP-адрес и первый номер порта получают из сети посредством приемника.

Согласно конкретному варианту осуществления изобретения потоки содержат только одну DVB-услугу.

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

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

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

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

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

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

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

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

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

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

фиг.6 представляет структуру NIT (Таблицы сетевой информации) согласно стандарту DVB;

фиг.7 представляет структуру стандартного цифрового декодера, например, в случае наземного приема;

фиг.8 представляет структуру цифрового декодера, подходящего для приема по IP;

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

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

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

Подключение к серверу по сети IP-типа может быть достигнуто с использованием IP-протокола многоадресной передачи. Одним примером такого протокола является IGMP (Протокол управления шлюзом Интернет), определенный в RFC 2236. В этом протоколе сервер многоадресной передачи имеет ассоциативно связанный адрес многоадресной передачи. Этот адрес имеет формат IP-адреса в домене, зарезервированном для этой цели, но не соответствует IP-адресу машины, к которой может быть получен доступ по сети. Приемник, желающий подключиться к этому серверу, будет отправлять запрос по сети, содержащий этот IP-адрес многоадресной передачи. Этот запрос будет перенаправляться через сеть до тех пор, пока он не достигнет сервера, способного ответить на эту трансляцию, который затем зарегистрирует приемник в качестве клиента трансляции. Маршрутизаторы на пути между сервером и приемником будут затем способны перенаправлять IP-пакеты, которые составляют поток, к терминалам, подписавшимся на трансляцию. Зная IP-адрес серверной машины в дополнение к IP-адресу многоадресной передачи, улучшенная версия этого протокола может оптимизировать маршрут, принятый посредством запроса подписки, маршрутизируя его непосредственно серверу назначения вместо трансляции его по всей сети. Эта улучшенная версия известна под именем SSM (определенная источником многоадресная передача). Поэтому это является системой, основанной на подписке на трансляцию цифровых данных. Сервер транслирует цифровые данные в пакетной форме по сети. До тех пор, пока нет приемника, подписавшегося на эту широковещательную рассылку, ни один пакет фактически не передается. Когда приемник подписывается, пакеты передаются ему посредством маршрутизации через сеть, следуя по маршруту между сервером и клиентом. Протокол гарантирует то, что пакеты будут использовать только те маршруты сети, которые ведут к приемникам, которые фактически подписываются на трансляцию. Когда приемник отписывается, фактическая передача пакетов этому приемнику останавливается. Протокол также обеспечивает то, что пакеты не дублируются в узлах маршрута в сети, который ведет к нескольким приемникам, подписавшимся на трансляцию.

Передача данных, которые составляют услугу, может также быть осуществлена с использованием IP-протокола одноадресной передачи. Одним примером такого протокола является протокол потока реального времени (RTSP), определенный в RFC 2326. Так как этот протокол используется для того, чтобы управлять трансляцией потока по IP, он предназначен для того, чтобы работать совместно с подходящим протоколом широковещательной передачи, таким как RTP, главное отличие от системы многоадресной передачи состоит в том, что для каждого клиента, желающего подключиться к потоку, сервер будет инициировать трансляцию "точка-точка" между самим сервером и клиентом. Очевидно, что это решение является более интенсивным в плане использования пропускной способности, чем решение, основанное на многоадресной передаче. На практике в этом решении пакеты данных, путешествующие по части маршрута сети, который ведет к ряду подписавшихся приемников, дублируются так много раз, сколько наличествует подписавшихся приемников. Это решение может быть рассмотрено в контексте ограниченной сети, в которой только небольшое число терминалов подходят для того, чтобы подключиться к потоку.

Чтобы ограничить пропускную способность, используемую для трансляции DVB-услуг по IP-сети при ограничении модификаций, которые должны быть сделаны в последовательности производства услуги, используемой станциями вещания, уже предлагающими услуги этого типа на других носителях передачи, таких как спутник или кабель, мы примем организацию данных, формирующих услуги, как следующее. С одной стороны, так называемый поток установки будет содержать таблицу информации о сети, близко наследованную от DVB NIT, и только эта таблица, которую мы назовем модифицированной NIT в смысле того, что она использует такой же синтаксис, что и DVB NIT, содержит особенные дескрипторы, подходит для того, чтобы транслировать DVB-услуги по IP. Кроме того, услуги будут разделены на поток содержимого, который будет объединять простые аудио-, видео-, субтитровые потоки и потоки других услуг, а также минимальное сигнализирование, используемое для того, чтобы организовать эти простые потоки, например, PAT и PMT, и на поток описания, содержащий только информацию описания услуги. Только потоки содержимого будут поддерживать формат транспортного потока, как определено посредством MPEG-2. Потоки установки и описания непосредственно составлены из таблиц, таких как NIT для потока установки и SDT или других таблиц для потоков описания. Эти таблицы используют синтаксис секций MPEG-2. На практике, доступ к информации описания услуги является единичным требованием, не находящимся в связи с необходимостью декодировать аудио- и видеосодержимое. Текущие пропускные способности в IP и необходимость ограничить пропускную способность в сети делают возможным то, что поток будет создан для каждой услуги, но является возможным объединение ряда услуг в один поток в контексте изобретения.

Для того, чтобы приспособить NIT к использованию в IP-сети, должны быть определены дескрипторы, применимые к определению местоположения потока в IP-сети. Такой дескриптор, подходящий для использования многоадресной передачи, приведен ниже:

Синтаксис	Число битов идентификатора
Ip_stream_descriptor () {
Descriptor_tag	8	uimsbf
Descriptor_length	8	uimsbf
Content_multicast_address	32	bslbf
Content_multicast_port_number	16	bslbf
Content_multicast_protocol_mapping	8	bslbf
Content_source_address	32	bslbf
For (i=0; i < N; i++) {
Descriptor () }
}

Поле «Descriptor_tag (тэг дескриптора)» является идентификатором, соответствующим этому новому типу дескриптора.

Поле «Descriptor_length (длина дескриптора)» задает длину дескриптора.

Поле «Content_multicast_address (адрес многоадресной передачи содержимого)» задает IP-адрес многоадресной передачи сервера, которому доступен поток содержимого.

Поле «Content_multicast_port_number (номер порта многоадресной передачи содержимого)» - это номер порта сервера, к которому приемник должен подключиться для того, чтобы принять поток содержимого.

Поле «Content_multicast_protocol_mapping (соответствие протокола многоадресной передачи содержимого)» - это поле, идентифицирующее протокол кодирования всех или каждой услуги, транслируемой по этому адресу. Протокол может быть MPEG-2, MPEG-4, MHP или другим. Это необязательное поле может быть использовано для того, чтобы фильтровать по типу содержимого, чтобы сохранять только те услуги, которые приемник способен декодировать.

Поле «Content_source_address (Адрес источника содержимого)» является настоящим IP-адресом сервера, который предусматривает эффективную маршрутизацию запроса подключения к серверу многоадресной передачи согласно протоколу SSM.

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

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

Ip_stream_descriptor () {
Descriptor_tag	8	uimsbf
Descriptor_length	8	uimsbf
Content_unicast_address	32	bslbf
Content_unicast_port_number		bslbf
Content_unicast_protocol_mapping		bslbf
For (i=0; i < N; i++) {
Descriptor () }
}

Поле «Descriptor_tag» является идентификатором, соответствующим этому новому типу дескриптора.

Поле «Descriptor_length» задает длину дескриптора.

Поле «Content_unicast_address (адрес одноадресной передачи содержимого)» задает IP-адрес одноадресной передачи сервера, которому доступен поток, передающий содержимое.

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

Поле «Content_unicast_protocol_mapping (соответствие протокола одноадресной передачи содержимого)» - это поле, идентифицирующее протокол кодирования всех или каждой трансляции услуги по этому адресу. Этот протокол может быть MPEG-2, MPEG-4, MHP или другим. Это необязательное поле может быть использовано для того, чтобы фильтровать по типу содержимого, чтобы сохранить только те услуги, которые приемник способен декодировать.

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

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

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

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

Ip_stream_multicast_locator_descriptor () {
Descriptor_tag	8	uimsbf
Descriptor_length	8	uimsbf
Filter_length	8	uimsbf
Filter_descriptor()
multicast_address	32	bslbf
multicast_port_number	16	bslbf
multicast_protocol_mapping	8	bslbf
source_address	32	bslbf
}

Здесь мы найдем стандартные поля дескриптора для определения местоположения трансляции потока по IP в режиме многоадресной передачи. Только поля «Filter_length (длина фильтра)» и «Filter_descriptor (дескриптор фильтра)» требуют пояснения. На практике, в контексте иллюстративного варианта осуществления изобретения, информация описания услуги отделена от информации содержимого и передается в отдельном другом потоке. Кроме того, также возможно передавать эту сигнализирующую информацию, т.е. эти таблицы, во множестве различных потоков. Совершенно верно принять эту возможность во внимание, что дескриптор «Ip_stream_descriptor» содержит цикл. Кроме того, когда этот дескриптор сканируется, необязательно известно, какой поток в цикле дескрипторов будет содержать данную таблицу, которая разыскивается для услуги, затронутой дескриптором. Действие от введения полей "Filter_length" и "Filter_descriptor" в дескриптор делает возможным осуществить средство для хранения в дескрипторе информации для установления того, какие таблицы содержатся в каждом потоке в цикле. Один способ кодирования этой информации может быть, например, таким, чтобы поместить в это поле «Filter_descriptor» строки битов, используемых, например, для того, чтобы программировать демультиплексор для того, чтобы фильтровать упомянутые таблицы. Так как каждый табличный тип имеет назначенный идентификатор, фильтр может быть запрограммирован с помощью строки битов, представляющей идентификатор таблицы, содержащейся в потоке. В случаях, где желательно быть способным иметь ряд таблиц в потоке, может быть принят способ, использованный для того, чтобы программировать фильтр демультиплексора. Первая битовая строка указывает идентификатор, который должен быть отфильтрован, а вторая строка такой же длины указывает для каждого бита первой строки, определено или нет это значение. Данный идентификатор поэтому будет соответствовать фильтру, если для каждого бита этого идентификатора, для которого соответствующий бит второй битовой строки установлен в один, соответствующий бит первой строки имеет такое же значение. Например, если рассматриваются строки из трех бит - первая битовая строка со значением в 0b101, вторая строка со значением 0b110 - идентификаторы, соответствующие этому фильтру будут иметь значения 0b101 и 0b100. Этот способ может быть использован для того, чтобы определить таблицы, содержащиеся в потоке, таким же путем, каким демультиплексор будет запрограммирован для того, чтобы искать их.

В другом, более простом осуществлении, дескрипторы информационных описательных потоков, относящихся к услуге трансляции, могут, например, принимать следующую форму:

Ip_stream_multicast_locator_descriptor_table_ids () {
Descriptor_tag	8	uimsbf
Descriptor_length	8	uimsbf
NbOfTableIDs	8	uimsbf
TableIDList()
multicast_address	32	bslbf
multicast_port_number	16	bslbf
multicast_protocol_mapping	8	bslbf
source_address	32	bslbf
}

Здесь мы найдем стандартные поля дескриптора, использованного, чтобы определить местоположение трансляции потока по IP в режиме многоадресной передачи. Только поля "NbOfTableIDs" и «TableIDList» требуют объяснения.

Поле "TableIDList" соответствует списку идентификаторов таблиц, которые включены в соответствующий поток, а поле «NbOfTableIDs» представляет число идентификаторов таблиц, внесенных в список. Таким образом, поток, содержащий как информацию относительно сигнализирующей информации о текущих и последующих событиях текущего потока, для которого идентификатор таблицы равен 0x4E, так и сигнализирующую информацию о текущих и последующих событиях других потоков, для которой идентификатор таблицы равен 0x4F, будут иметь дескриптор со значением 2 для "NbOfTableIDs" и значения 0x4E и 0x4F в поле "tableIDList".

Другая возможность осуществления широковещательной трансляции потоков, содержащих сигнализирующую информацию, может быть в том, чтобы выбрать простой протокол передачи файлов между сервером и приемником вместо протокола многоадресной передачи. Такой протокол может, например быть протоколом передачи гипертекста (HTTP). Это протокол является простым для осуществления, особенно, если он ограничен осуществлением возможности выполнять «GET», чтобы получить файл от сервера. Этот протокол гораздо проще, чем XML, для того, чтобы управлять обработкой файла, описанной во введении. В этом случае важно иметь другой дескриптор, такой как дескриптор ниже, который используется для того, чтобы связать с данной таблицей идентификатора URL (унифицированный указатель ресурса) файла, содержащий это:

Ip_stream_HTTP_locator_descriptor () {
Descriptor_tag	8	uimsbf
Descriptor_length	8	uimsbf
Table_id	8	bslbf
For (i=0; i<N; i++) {
Char	8	bslbf
}
}

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

Фиг.1 описывает общую архитектуру последовательности производства MPEG-2 DVB-услуги в контексте спутникового вещания. В начале последовательности существует аудио- и видеосодержимое 1.1, которое должно быть передано. Это содержимое кодируется согласно стандарту MPEG-2 в кодере 1.2 для того, чтобы сформировать простой аудио/видеопоток 1.5. Параллельно с кодированием аудио- и видеосодержимого формируется сигнализирующая информация 1.3, которая обычно создается из базы данных, содержащей информацию, описывающую услугу, которая должна быть транслирована. Эта информация генерируется в форме сигнализирующего потока 1.6. Другой модуль 1.4 управляет генерацией потока 1.7 субтитров. Также возможно включить поток 1.8 интерактивного приложения, последовательность производства которого детально не описывается в данном документе. Все эти простые потоки с другими потоками, если необходимо, передающими другое аудио- и видеосодержимое, относящееся или другое сигнализирование, затем объединяются в мультиплексоре 1.9, чтобы сгенерировать транспортный поток MPEG-2, который затем будет модулирован и преобразован в частоту, выбранную модулятором/преобразователем 1.10. Набор потоков этого типа может быть смешан смесителем 1.11 для передачи спутнику 1.13 через станцию 1.12 передачи. В этом случае необходима синхронизация сигнализирующей информации между разными потоками для того, чтобы включить информацию о других потоках в таблицы, описывающие каждый поток. Эти программы могут затем быть приняты в доме пользователя через спутниковую антенну 1.14 так, чтобы быть декодированными декодером телевизионных сигналов и отображенными на телевизоре. Такая система в настоящее время находится вполне в рамках возможностей станций вещания.

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

Эта модифицированная NIT описывает число потоков, содержащих услуги. Стандартная структура NIT, как определено посредством DVB, приведена на фиг.6. Хотя поток, невзирая на средство передачи, может содержать в себе ряд DVB-услуг, возможно, по причинам пропускной способности, что только потоки, содержащие только одну DVB-услугу, будут использованы в начальной стадии в контексте трансляции по IP. Поэтому пример, описанный на фиг.2, отражает этот случай. Однако очевидно, что изобретение не ограничено использованием потоков, содержащих только одну DVB-услугу в потоке. Поэтому мы поэтому имеем в модифицированной NIT 2.4 описание трех услуг 2.5, 2.6 и 2.7. Описание услуг будет содержать дескрипторы 2.8 и 2.9 для определения местоположения потока 2.2 содержимого, так же, как и потока, содержащего описание, касающееся услуги 2.3. Поток 2.2 содержимого будет содержать PAT (таблицу ассоциативной связи программ), указывающую содержимое, относящееся к услуге 2.11, составленной из PMT (таблицы соответствия программ). Поток 2.3 описания поэтому является отдельным потоком от предшествующего. Этот поток не имеет формата транспортных потоков MPEG-2, а непосредственно таблицы, имеющие синтаксис секции MPEG-2. Это разделение разрешает клиенту подключиться к этому потоку, только когда необходимо получить доступ к информации описания, и поэтому избегает использования пропускной способности для постоянной передачи этой информации. Таким образом, использование этой пропускной способности улучшается. Напомним, что при широковещательной трансляции по IP, когда приемник отписывается от трансляции, фактическая передача пакетов по сети к этому приемнику прекращается. В примере поток описания содержит информацию о событиях 2.14, такую как информация от текущем событии следующем событии, и, где подходит, законченный календарь событий, такой, что может быть создан электронный путеводитель по программе. Он также содержит информацию об услуге 2.13, такую как SDT (таблица описания услуги).

Фиг.3 является другим примером архитектуры потока согласно примерному варианту осуществления изобретения. Этот пример является более простым по сравнению с предыдущим, который представлен на фиг.2. Различие находится в том, что в этом случае информация описания, относящаяся к событиям, и информация, относящаяся к услуге, передаются посредством двух различных потоков. Поэтому мы в этом случае имеем для услуги 1 3.5 три отображенных дескриптора 3.8, 3.9 и 3.10 вместо двух предшествующих, указывающих на поток 3.2 содержимого, поток 3.3 информации об услуге и поток 3.15 информации о событии. Поэтому возможно разделить разные таблицы, которые составляют сигнализирующую информацию, по разным потокам согласно доступным таблицам и использовать то, что будет сделано из них, для того, чтобы управлять пропускной способностью сети. Также возможно принять во внимание ограничения управления услугой, группируя вместе таблицы, имеющие одинаковую частоту обновления.

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

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

Приемник может быть подключен к потоку, например, через IGMP. Обычно этот транспортный поток является инкапсулированным MPEG-2 по IP-типу, использующим уровни IP/UDP/RTP (протокол пользовательских дейтаграмм, протокол реального времени), но может также быть MPEG-4, MHP или потоком другого типа.

Фиг.5 представляет последовательность производства услуги согласно изобретению. Во-первых, необработанное аудио- и видеосодержимое 5.1 кодируется кодером 5.4 для того, чтобы выдать простые аудио- и видеопотоки 5.7. База 5.2 данных содержит полное описание услуг и информацию о событиях. Модуль 5.5 используется для того, чтобы создать сигнализирующие таблицы 5.8 с этой информацией. Сигнализирующая информация 5.8, потоки 5.7 аудио- и видеосодержимого и другая необязательная информация, например интерактивные и другие приложения 5.6, объединяются 5.9, чтобы создать поток 5.10 содержимого. Первый модуль 5.11 форматирования использует сигнализирующие таблицы 5.8, созданные, где необходимо, из информации, содержащейся в базе 5.2 данных, и дополнительной информации о других услугах 5.3, для того, чтобы создать поток 5.12 описания. Второй модуль 5.13 форматирования использует дополнительную информацию о сетевых услугах 5.3 для того, чтобы создать поток 5.14 установки, который будет содержать описание всех потоков, доступных в сети, с адресами, предоставляющими доступ к ним. Главные модули, которые не существуют в традиционной последовательности производства DVB-услуги, являются этими модулями 5.11 и 5.13 форматирования. Однако эти модули являются простыми для создания, так как они просто создают потоки, содержащие сигнализирующие таблицы, такие как те, которые уже созданы сигнализирующим модулем 5.5, новшество порождается из использования дескрипторов, подходящих для того, чтобы определять местоположение потока в IP-сети, передается ли этот поток в режиме многоадресной или одноадресной передачи или даже доступен через протокол передачи файлов, такой как HTTP. Эти потоки 5.10, 5.12 и 5.14, однажды созданные, могут затем быть переданы серверам IP-сети.

Фиг.7 описывает архитектуру традиционного декодера, такого как цифровой наземный декодер. Декодер 7.1 имеет экран 7.3. Пользователь 7.2 вза