динамическое обновление sdp при широковещательной передаче данных по протоколу ip в системе dvb-h

Формула изобретения

1. Способ планирования обновления сеанса, в котором:

принимают новую версию файла описания сеанса для потоковой услуги;

определяют время начала для новой версии файла описания сеанса;

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

планируют обновление сеанса новой версией файла описания сеанса в соответствии с синхронизированным временем.

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

3. Способ по п.1, отличающийся тем, что время начала для новой версии указывают в поле "t=" протокола описания сеанса в новой версии файла описания сеанса.

4. Способ по любому из пп.1-3, отличающийся тем, что новую версию файла описания сеанса принимают посредством сеанса доставки файлов.

5. Способ по п.4, отличающийся тем, что сеанс доставки файлов проводят согласно протоколу однонаправленной доставки файлов.

6. Способ по п.5, отличающийся тем, что протокол однонаправленной доставки файлов включает протокол FLUTE.

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

8. Способ по любому из пп.1-3, отличающийся тем, что отчет отправителя передают в потоках протокола управления RTP.

9. Способ по п.1, в котором:

определяют, влияет ли новая версия файла описания сеанса на какой-либо используемый в данное время медиапоток;

если новая версия файла описания сеанса потенциально влияет на потоковый сеанс, то осуществляют действие по обращению к новой версии файла описания сеанса.

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

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

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

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

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

15. Устройство для планирования обновления сеанса, содержащее:

средство для приема новой версии файла описания сеанса для потоковой услуги;

средство для определения времени начала для новой версии файла описания сеанса;

средство для использования по меньшей мере одного отчета отправителя потоковой услуги, чтобы синхронизировать время начала для новой версии файла описания сеанса; и

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

16. Система для передачи потока, содержащая:

передающее устройство, сконфигурированное для передачи по меньшей мере одного из потокового сеанса и сеанса доставки файлов; и

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

машинный код для приема новой версии файла описания сеанса, относящегося к потоковой услуге от передающего устройства;

машинный код для определения, влияет ли новая версия файла описания сеанса на какой-либо используемый в данное время медиапоток; и

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

Описание изобретения к патенту

Область техники

[0001] Данное изобретение относится, в целом, к использованию услуг широковещательной передачи данных по протоколу Интернета (IPDC) согласно спецификации на технологию мобильного вещания, позволяющую передавать цифровой видеосигнал на карманные устройства (DVB-H). Более конкретно, данное изобретение касается синхронизации и использования обновлений информации протокола описания сеанса (SDP), когда терминал использует потоковую услугу в соответствии с протоколом IPDC по технологии DVB-H.

Предпосылки создания изобретения

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

[0003] IPDC - технология эфирного вещания, которая позволяет с наименьшими затратами и эффективно доставлять цифровой контент массовой аудитории. Технически, IPDC использует сети наземного цифрового телевидения (DVB-T) для широковещательной передачи любых данных на основе протокола Интернета. Технология IPDC по спецификации DVB-H определяет способы доставки двух различных видов. Эти способы включают доставку файлов и потоковую доставку. Способ доставки файлов основан на доставке файлов с помощью однонаправленного транспортного протокола (FLUTE) и позволяет осуществлять доставку файлов на терминал в виде транспортных объектов. Протокол FLUTE подробно рассмотрен в документе www.ietf.org/rfc/rfc3926.txt, который полностью включен в данное описание путем ссылки на источник. Способ доставки файлов используется, например, для доставки данных электронного справочника услуг (ESG). Данные ESG сообщают информацию об услугах и о том, как получить к ним доступ с терминала. Ряд других услуг, таких как загрузка музыки и файлов видеозаписей, также могут быть реализованы с использованием способа доставки файлов.

[0004] С другой стороны, способ потоковой доставки используется для реализации потоковых услуг, таких как мобильное телевидение и радио. Потоковый способ доставки основан на транспортном протоколе реального времени (RTP) и стандартных медиакодеках, например, по стандартам H.264/AVC и MPEG-4 НЕ ААС. Информация о протоколе RTP может быть найдена в документе www.ietf.org/rfc/rfc3550.txt, полностью включенном в данное описание путем ссылки на источник.

[0005] Чтобы пользователь мог использовать услугу IPDC, обычно требуется выполнить ряд шагов. Сначала терминал должен настроиться на сеанс начальной загрузки справочника ESG, который расположен по известному IP адресу. Сеанс начальной загрузки ESG предоставляет информацию о существующих провайдерах ESG и их соответствующих сеансах ESG. Терминал должен затем настроиться на выбранный/предварительно сконфигурированный сеанс ESG и отыскать "моментальный снимок" текущих данных ESG. Затем пользователю предлагается возможность просмотреть информацию ESG и отобрать услугу по своему выбору для использования. Терминал отыскивает в справочнике ESG соответствующий фрагмент доступа (Acquisition Fragment). Acquisition Fragment содержит описание различных медиакомпонентов сеанса, а также файл протокола описания сеанса (SDP), который описывает, как получить доступ к сеансу, используемые медиакодеки и другую информацию о конфигурации. Информация о протоколе SDP может быть найдена в документе www.ietf.org/rfc/rfc2327.txt, полностью включенном в данное описание путем ссылки на источник. Терминал затем настраивается на потоки IР, чтобы использовать данные. Файл SDP сеанса может доставляться вложенным во фрагмент Acquisition Fragment или как отдельный элемент в сеансе FLUTE. Сеанс FLUTE описывается вложенным файлом SDP во фрагменте Acquisition Fragment.

[0006] Некоторые каналы мобильного телевидения могут требовать динамических и непредсказуемых модификаций конфигурации сеанса. Эти модификации могут быть аналогичны каналу прямой телевизионной передачи, в котором неожиданно становятся доступными дополнительный язык звукового сопровождения или вид с нескольких камер. В такой ситуации терминалы в среде мобильного телевидения, которые получают услугу в это время, обычно не знают об изменениях, так как они обычно не отслеживают обновления справочника ESG. Имеется возможность доставлять обновления для SDP в сеансе FLUTE, который доставляется вместе с медиапотоками. Однако новый файл SDP должен быть синхронизирован с текущим сеансом, и в настоящее время имеются проблемы в отношении того, как терминал должен обрабатывать обновления сеанса SDP. Динамическое обновление сеанса, как описано здесь, относится к операции, с помощью которой файл SDP продолжающегося сеанса заменяется более новым файлом SDP, о котором сигнализируется посредством подходящих механизмов.

[0007] Данные ESG обычно доставляются в другом элементарном потоке и, возможно, также в другом транспортном потоке, чем сеансы доставки файлов и потоков, которые описывают эти данные ESG. В таком случае терминал обычно обновляет свою базу данных ESG после настройки и затем переключается на выбранный поток для использования услуги. Во время использования услуги предполагается, что терминал не отслеживает обновления справочника ESG, так как это значительно увеличивает потребляемую мощность и может быть невозможно, например, в случае различных транспортных потоков. Однако некоторые услуги, такие как услуга канала телевидения, могут требовать обновления ESG непредсказуемым образом. Например, новый язык звукового сопровождения или поток субтитров могут внезапно появиться в контенте канала телевидения. В другом случае предварительно запланированное событие может быть отложено из-за задержек различного вида. В таких сценариях файл описания потокового сеанса должен быть обновлен, чтобы правильно использовать услугу. Кроме того, терминалы, которые используют услугу и не настроены на справочник ESG, должны быть извещены об изменениях в параметрах сеанса. Спецификация ESG (которая может быть найдена в документе "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG)" ETSI TS 102 471 V 1.1.1 (2006-04), webapp.etsi.org/action/PU/20060425/ts_102471v010101p.pdf, полностью включенном в данное описание путем ссылки на источник) определяет для вышеупомянутой цели внеполосный механизм доставки файлов SDP. Сеанс FLUTE может использоваться для доставки наиболее нового файла SDP на терминалы, которые в настоящее время используют услугу или только настраиваются на услугу. Ожидается, что сеанс FLUTE будет доставляться в том же самом элементарном потоке, что и медиапотоки потоковой услуги.

Сущность изобретения

[0008] Различные формы осуществления настоящего изобретения касаются синхронизации потока SDP с медиапотоком. В различных формах осуществления изобретения приложение, использующее протокол SDP, инициирует получатель FLUTE и отыскивает новые версии файла SDP. Терминал также отыскивает информацию на уровне протокола управления RTF (RTCP) о текущем времени отправителя. Время отправителя обычно указывается в виде временной метки сетевого протокола времени (NTP) в отчетах отправителя RTCP. Терминал указывает воспроизводящему устройству, что новый файл SDP будет действителен через некоторый интервал времени.

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

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

Краткое описание чертежей

[0011] На фиг.1 показана процедура, с помощью которой поток SDP синхронизируется с медиапотоком в соответствии с одной из форм осуществления настоящего изобретения.

[0012] Фиг.2 - схема, показывающая, как медиаплеер может реагировать на новую версию SDP, которая становится доступной, в различных формах осуществления настоящего изобретения.

[0013] Фиг.3 - схема, показывающая, как медиаплеер может реагировать на новый файл SDP, создающий новые строки media, согласно различным формам осуществления настоящего изобретения.

[0014] На фиг.4 показано перспективное изображение терминала, который может использоваться при реализации настоящего изобретения.

[0015] На фиг.5 показано схематическое изображение схем терминала фиг.4.

Подробное описание различных форм осуществления изобретения

[0016] Настоящее изобретение касается синхронизации потока SDP с медиапотоком. Настоящее изобретение охватывает также поведение терминала после приема обновления SDP. Кроме того, настоящее изобретение обеспечивает внеполосную доставку справочника ESG с более богатым содержимым, чем обычные системы, позволяя выполнять более значительные обновления сеанса.

[0017] На фиг.1 показана процедура, с помощью которой поток SDP синхронизируется с медиапотоком в соответствии с одной из форм осуществления настоящего изобретения. Предполагается, что терминалы, использующие потоковую услугу с сеансом 100 FLUTE, для динамических обновлений сеанса загружают некоторую новую версию файла SDP. Как описано в спецификации протокола доставки контента (CDP) (которая может быть найдена в документе "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocol, ETSI TS 102 472, V 1.1.1 (2006-06)) и в спецификации электронного справочника услуг (ESG) (которая может быть найдена в документе Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG), ETS) TS 102 471 VI.1.1 (2006-04)) (оба документа полностью включены в данное описание путем ссылки на источник)), новая версия идентифицируется измененным соответствием между идентификатором транспортного объекта (TOI) и однородным идентификатором ресурса (URI), которое появляется в более новом экземпляре таблицы доставки файлов (FDT). Идентификатор URI файла SDP получается из элемента SDPURI во фрагменте Acquisition Fragment.

[0018] После обнаружения новой версии файла SDP потоковой услуги 110, изображенной в прямоугольнике 130 на фиг.1, терминал отмечает время начала в поле "t=" SDP новой версии 130. Время начала задается как временная метка сетевого протокола времени (NTP)) (переносящего скоординированное универсальное время (UTC), которое не зависит от часовых поясов и летнего времени). Терминал затем использует отчеты отправителя, посланные в потоках 120 протокола управления RTP (RTCP) потоковой услуги 110, чтобы установить временную синхронизацию и спланировать обновление сеанса новым файлом SDP.

[0019] Терминал может прослушивать сеанс(-ы) 100 FLUTE для обнаружения полных или частичных обновлений справочника ESG и фрагментов ESG. В дополнение к прослушиванию или вместо него терминал в одной из форм осуществления изобретения может принимать одно или более уведомлений, которые сообщают терминалу об одном или нескольких доступных обновлениях. Терминал тогда может получить доступ ко всем или некоторым из сеансов, позволяющих доставить обновления.

[0020] Ниже рассматривается, как медиаплеер может вести себя после приема новой версии файла SDP согласно различным формам осуществления настоящего изобретения. Следует отметить, что поведение терминала будет зависеть от типа полученных обновлений. Фиг.2 - это схема, показывающая, как медиаплеер может реагировать на новую версию SDP, которая становится доступной, в различных формах осуществления настоящего изобретения. На шаге 200 терминал принимает новую версию файла SDP, которая касается используемой потоковой услуги. На шаге 210 терминал вычисляет время активации нового файла SDP, как было рассмотрено ранее, и планирует обновление сеанса на шаге 220. В одной из форм осуществления изобретения терминал опускает любые завершенные разрывы и повторную инициализацию потокового сеанса. На шаге 230 терминал анализирует обновляемый SDP, чтобы обнаружить, прерывается ли какой-либо из медиапотоков, используемых в настоящее время. Конкретный медиапоток идентифицируется своим IP-адресом места назначения и номером порта.

[0021] Если определяется, что используемый в настоящее время медиапоток прерывается, как представлено на шаге 240, терминал должен дать медиаплееру инструкции, как продолжить использование (потребление) услуги. Возможно несколько опций для продолжения использования услуги. Первая опция, представленная в блоке 250, требует от терминала полностью остановить прием прерываемого медиакомпонента. Это реально в некоторых ситуациях, например в случае, когда прерывается вспомогательный медиапоток (то есть поток субтитров). Вторая опция, представленная в блоке 260, заставляет терминал заменить прерываемый медиапоток эквивалентным медиапотоком из обновленного файла SDP. С помощью этой опции аудиопоток может заменить другой аудиопоток, видеопоток может заменить другой видеопоток, поток субтитров может быть заменен другим потоком субтитров и т.д. Выбор медиапотока может быть основан, например, на предпочтениях пользователя. Например, если пользователь имеет предпочтительный язык для своего звука, то медиаплеер может автоматически выбирать предпочитаемый пользователем аудиопоток с этим языком, когда он становится доступным. Терминал может также пригласить пользователя выбрать из сеанса предпочтительные потоки медиаданных, которые должны использоваться. Если доступна только одна альтернатива для аудио- и видеопотоков, то медиаплееру может быть подана команда использовать доступный медиапоток без дальнейшего взаимодействия с пользователем. Другая опция, представленная в блоке 270, заставляет терминал полностью прекратить использование услуги. Эта опция может быть выбрана, например, если сеанс объявляется законченным с помощью установки такого времени конца сеанса, которое является меньшим, чем время начала сеанса, или равным ему.

[0022] Другой сценарий, который может возникнуть, включает новый файл SDP, который описывает новые строки media, возможно, в дополнение к строкам media, которые в настоящее время используются терминалом. Фиг.3 - это схема, показывающая, как медиаплеер может реагировать на новый файл SDP, создающий новые строки media. Когда это происходит, как представлено в блоке 300, терминал имеет несколько опций того, как себя вести. Например, терминал может продолжить воспроизведение инициализированных в данное время медиапотоков, как представлено в блоке 310. Альтернативно, терминал может решить для каждого медиатипа, переключиться ли на альтернативный медиапоток (как представлено в блоке 320) или, возможно, одновременно использовать несколько медиапотоков одного типа (например, в случае дополнительных аудиоканалов в новом медиапотоке) (как представлено в блоке 330). Это решение может быть основано на предпочтениях пользователя или на взаимодействиях с пользователем. Кроме того, терминал может решить, использовать ли новый медиапоток нового медиатипа (например, недавно добавленный поток субтитров) на основании предварительно сконфигурированных предпочтений пользователя или взаимодействия с пользователем, как представлено в блоке 340.

[0023] Чтобы обеспечить непрерывное воспроизведение, медиаплеер не должен прерывать воспроизведение медиапотока прежде, чем он буферизировал необходимое количество данных нового альтернативного медиапотока. Медиаплеер должен выполнить переключение на новый медиапоток на порции медиаданных, как можно более близкой к последней воспроизводимой порции медиаданных из старого медиапотока.

[0024] Ниже рассматривается, как в соответствии с различными формами осуществления настоящего изобретения может быть реализована внеполосная доставка ESG с более богатым содержимым. Проблема с обычной доставкой ESG состоит в том, что терминалы не информированы о семантике изменений для сеанса, когда они принимают обновление для SDP. В таком случае добавление нового медиапотока может быть непонятно терминалу. Поэтому необходимы дополнительные метаданные, чтобы сообщить терминалу о недавно ставших доступными медиакомпонентах или прерванных медиакомпонентах. Это может быть достигнуто, например, доставкой различных фрагментов ESG в том же сеансе FLUTE, который переносит внеполосный файл SDP. Один такой фрагмент выполнен в виде Acquisition Fragment (фрагмента доступа), который содержит описания компонентов для каждого из компонентов сеанса. Другой такой фрагмент выполнен в виде Schedule Fragment (фрагмента расписания), который описывает запланированное время начала и время конца события. Другие связанные фрагменты, такие как Content Fragment (фрагмент контента) и Service Fragment (фрагмент услуги), также могут доставляться посредством внеполосного сеанса FLUTE.

[0025] Когда выпускается внеполосный справочник ESG с более богатым содержимым, провайдер ESG указывает для сети обновляемые фрагменты ESG и инкапсулирует их в контейнер ESG. Провайдер ESG включает также фрагмент индексации, чтобы описать контент контейнера ESG. Затем сеанс FLUTE доставляет контейнеры ESG с теми же самыми идентификаторами URI, что и те, которые использовались в основном сеансе ESG для рассматриваемых терминалов.

[0026] На фиг.4 и 5 показан типичный терминал, в котором может быть реализовано настоящее изобретение. Однако должно быть понятно, что настоящее изобретение не ограничено терминалом одного конкретного вида. Терминал, показанный на фиг.4 и 5, содержит корпус 30, дисплей 32 в виде дисплея на жидких кристаллах, клавиатуру 34, микрофон 36, динамик 38, аккумуляторную батарею 40, инфракрасный порт 42, антенну 44, смарт-карту 46 в виде универсальной карты с интегральными микросхемами (UICC) согласно одной из форм осуществления изобретения, устройство 48 считывания карт, схему 52 радиоинтерфейса, схему 54 кодека, контроллер 56 и память 58. Все отдельные схемы и элементы представляют собой устройства, хорошо известные в данной области, например, из модельного ряда мобильных телефонов фирмы Nokia.

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

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

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