СПОСОБ И УСТРОЙСТВО ДЛЯ ПРЕДОСТАВЛЕНИЯ РУКОВОДСТВА ПО УСЛУГЕ В МОБИЛЬНОЙ ШИРОКОВЕЩАТЕЛЬНОЙ СИСТЕМЕ Российский патент 2013 года по МПК H04W4/06 H04H60/68 H04H20/28 

1. ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение относится к мобильной широковещательной системе, поддерживающей услугу широковещательной рассылки (Broadcast Service, BCAST). Более конкретно, настоящее изобретение относится к способу и устройству для предоставления другого Руководства по Услуге (Service Guide, SG) посредством базового SG в мобильной широковещательной системе.

2. УРОВЕНЬ ТЕХНИКИ

Рынок мобильной связи сталкивается с постоянно увеличивающимися запросами на новые услуги вследствие перестройки или преобразования существующих технологий. Разработка коммуникаций и технологий широковещательной рассылки достигла того уровня, когда услуга широковещательной рассылки может предоставляться через переносной терминал (далее в настоящем описании, мобильный терминал), такой как переносной телефон, персональный цифровой помощник (карманный компьютер) и т.д. Со всеми этими потенциальными и реальными запросами рынка, включая быстро увеличивающиеся запросы пользователей на мультимедийную услугу, стратегии провайдеров услуг, которые помимо обычной голосовой услуги намерены оказывать новые услуги, включая услугу широковещательной рассылки, и интересы компаний, предоставляющих Интернет-Технологии (Internet Technology, IT), которые укрепляют бизнес, связанный с мобильной связью, удовлетворяя запросы клиентов, тенденция на конвергенцию мобильной связи и Интернет-Протокола (Internet Protocol, IP) была существенной в технологическом развитии систем мобильной связи будущих поколений. Полученная в результате значимая конвергенция, т.е. внедрение различных беспроводных услуг или услуг широковещательной рассылки на рынок беспроводной связи, а также на рынок мобильной связи, сформировала такую же потребительскую среду для различных услуг независимо от проводной или беспроводной широковещательной рассылки.

Открытое сообщество производителей мобильной связи (Open Mobile Alliance, ОМА) является организацией, которая работает над стандартизацией функциональной совместимости между отдельными решениями относительно мобильной связи. ОМА главным образом служит для создания множества прикладных стандартов для игр по мобильной связи, Интернет-услуги и т.д. Рабочая группа ОМА BCAST изучает технологический стандарт для предоставления услуги широковещательной рассылки через мобильный терминал. Таким образом, рабочая группа ОМА BCAST должна в процессе разработки стандартизировать технологии для предоставления IP-услуги широковещательной рассылки в конечную мобильную среду, включая предоставление Руководства по Услуге (SG), загрузку и передачу потока данных, защиту услуги и контента, роуминг при подписке на услугу и т.д.

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

Фиг.1 представляет собой блок-схему обычной структуры для передачи SG в мобильный терминал в мобильной широковещательной системе.

Интерфейсы между компонентами (логическими объектами), показанные на фиг.1, сначала описаны в таблице 1 и таблице 2 со ссылкой на фиг.1.

Таблица 1 Интерфейс Описание SG1 Связь сервер-сервер для доставки атрибутов контента, таких как информация об описании, информация о местоположении, возможности терминала назначения, профиль пользователя назначения и т.п., либо в виде BCAST SG фрагментов, либо в проприетарном формате SG2 Связь сервер-сервер для доставки атрибутов BCAST услуги, таких как информация об описании услуги/контента, информация о составлении графика, информации о местоположении, возможности терминала назначения, профиль пользователя назначения и т.п., в виде BCAST SG фрагментов SG-B1 Связь сервер-сервер либо для доставки характерной для системы распространения широковещательной рассылки (Broadcast Distribution System, BDS) функции Настройки из BDS в BCAST SG для оказания содействия в настройке SG в конкретной BDS, либо для доставки BCAST SG атрибутов в BDS для характерной для настройки BDS и распространения SG4 Связь сервер-сервер для доставки информации о регистрации, информации о покупке, информации о подписке, рекламной информации и т.д., в виде BCAST SG фрагментов SG5 Доставка BCAST SG по каналу широковещательной рассылки, по IP. SG6 Доставка BCAST SG по интерактивному каналу, интерактивный доступ для поиска SG или дополнительной информации, относящейся к SG, например, с помощью HTTP SMS или MMS

Таблица 2 Интерфейс Описание x-1 124 Контрольная точка между распространением BDS услуг и BDS 122 x-2 125 Контрольная точка между распространением BDS услуг и интерактивной сетью 123 x-3 126 Контрольная точка между BDS 122 и терминалом 119 x-4 127 Контрольная точка между распространением BDS услуг 121 и терминалом 119 по каналу вещательной рассылки x-5 128 Контрольная точка между распространением BDS услуг и терминалом по интерактивному каналу (радио интерфейс 130) x-6 129 Контрольная точка между интерактивной сетью 123 и терминалом 119

Согласно фиг.1 разработчик 101 контента разрабатывает услугу широковещательной рассылки (далее в настоящем описании, BCAST услуга). BCAST услуга может представлять собой обычную услугу аудио/видео широковещательной рассылки или обычную услугу по загрузке музыкального файла/файла данных. В разработчике 101 контента Источник 102 Разработки Контента SG (SG Content Creation Source, SGCCS) передает через описанный в Таблице 1 SG1 интерфейс 103 информацию об описании контента, информацию о возможностях терминала, пользовательские профили и информацию о таймировании (временных параметрах) контента, необходимую для определения конфигурации SG для BCAST услуги в Источник 105 SG Приложения (SG Application Source, SGAS) приложения 104 BCAST услуги.

Приложение 104 BCAST услуги генерирует данные BCAST услуги, получая данные для BCAST услуги от создателя 101 контента и обрабатывая эти данные в форме, подходящей для BCAST сети. Приложение 104 BCAST услуги также генерирует стандартизированные мета данные, необходимые для руководства по услуге мобильной широковещательной рассылки. SGAS 105 передает информацию, полученную из SGCCS 102 и источников и необходимую для конфигурации SG, включающую информацию об описании услуг/контента, информацию о составлении графика и информацию о местоположении, в Генератор SG (SG Generator, SG-G) 109 дистрибьютора/адаптера 108 BCAST услуги через SG2 интерфейс 106, также описанный в Таблице 1.

Дистрибьютор/адаптер 108 BCAST услуги устанавливает канал для доставки данных BCAST услуги, полученных из приложения 104 BCAST услуги, составляет график передачи BCAST услуги и генерирует информацию о руководстве по мобильной широковещательной услуге. Дистрибьютор/адаптер 108 BCAST услуги соединен с Системой 122 Распространения Широковещательной Рассылки (Broadcast Distribution System, BDS), которая передает данные BCAST услуги, и с интерактивной сетью 123, которая поддерживает двустороннюю связь.

Сгенерированное в SG-G 109 SG поступает в мобильный терминал 119 через Дистрибьютор 110 SG (SG Distributor, SG-D) и SG-5 интерфейс 117. Если SG должно предоставляться через BDS 122 или интерактивную сеть 123, или SG нуждается в настройке, чтобы соответствовать конкретной системе или сети, оно подается в SG-D 110 после настройки в Адаптере SG (SG Adapter, SG-A) 111 или в описанный ниже дистрибьютор 121 BDS услуг через SG-B1 интерфейс 116.

Менеджер 113 BCAST подписки управляет информацией о подписке, запрошенной для приема BCAST услуги, информацией о предоставлении услуги и информацией устройства о мобильных терминалах для получения BCAST услуги. Источник 114 SG подписки (SG Subscription Source, SGSS) менеджера 113 BCAST подписки передает информацию о регистрации, информацию о покупке, информацию о подписке и рекламную информацию относительно SG генерации в SG-G 109 через SG4 интерфейс 112.

Дистрибьютор 121 BDS услуг распространяет все полученные BCAST услуги по каналам широковещательной рассылки или по интерактивным каналам. Дистрибьютор 121 BDS услуг представляет является необязательным объектом, который можно использовать или который может быть независимым от типа BDS 122. BDS 122 представляет собой сеть, по которой доставляется BCAST услуга. Например, BDS 122 может представлять собой широковещательную сеть, такую как открытый стандарт цифрового телевидения (Digital Video Broadcasting-Handheld, DVB-H), служба многоадресного мультимедийного вещания (Multimedia Broadcast/Multicast Service, MBMS) или служба мультимедийного вещания (Broadcast Multicast Service, BCMCS) Проекта Партнерства 3^-его Поколения 2 (3^rd Generation Partnership Project 2, 3GPP2). Интерактивная сеть 123 передает BCAST услугу по типу “один к одному” или выполняет двунаправленный обмен управляющей информацией и дополнительной информацией, ассоциированной с приемом BCAST услуги. Например, интерактивная сеть 123 может представлять собой унаследованную сотовую сеть.

На фиг.1 мобильный терминал 119 представляет собой терминал, поддерживающий прием BCAST. В зависимости от функциональных характеристик мобильный терминал 119 может быть соединен с сотовой связью. Мобильный терминал 119, который включает Клиента SG (SG Client, SG-C) 120, получает SG через SG5 интерфейс 117 или сообщение Извещение через SG6 интерфейс 118 и функционирует соответствующим образом для получения BCAST услуги.

Таблица 3, таблица 4 и таблица 5 суммируют функции главных компонентов (логических объектов), показанных на фиг.1, определенных в ОМА BCAST стандартах.

Таблица 3 Логический объект Описание Создатель 101 контента В создателе контента SGCCS может предоставлять атрибуты контента, такие как информация об описании контента, возможности целевого терминала, профиль целевого пользователя, информация о таймировании контента и т.д., и может посылать их по SG1 в виде стандартизированных BCAST SG фрагментов или в закрытом формате Приложение 104 BCAST услуги В приложении BCAST услуги SGAS 105 предоставляет информацию об описании услуги/контента, информацию о составлении графика, информацию о местоположении, возможности целевого терминала, профиль целевого пользователя и т.д. и посылает их по SG2 106 в виде стандартизированных BCAST SG фрагментов Менеджер 113 BCAST подписки В менеджере BCAST подписки SGSS 114 предоставляет информацию о регистрации, информацию о покупке, информацию о подписке, рекламную информацию и т.д., и посылает их по SG4 112 в виде SG фрагментов

Таблица 4 Логический объект Описание SG-G 109 SG-G в сети отвечает за получение SG фрагментов из различных источников, таких как SGCCS 102, SGAS 105, SGSS 114, по интерфейсам SG-2 и SG-4. SG-G 109 собирает фрагменты, такие как услуги и информацию о доступе к контенту, согласно стандартизированной схеме и генерирует SG, который посылает в SG-D для передачи. Перед передачей его необязательно настраивают в SG-A 111 на соответствие определенной BDS SG-C 120 SG-C в терминале 119 отвечает за получение SG информации из основной BDS и доступность SG для мобильного терминала. SG-C получает характерную для SG информацию. Он может фильтровать ее с тем, чтобы соответствовать заданным критериям терминала (например, местоположению, профилю пользователя, возможностям терминала) или может просто получать всю доступную SG информацию. Обычно пользователь может просматривать SG информацию в формате меню, списка или таблицы. SG-C может посылать запрос в сеть через SG-6 118 для получения характерной для SG информации или SG полностью

Таблица 5 Логический объект Описание SG-D110 SG-D генерирует IP поток для передачи SG через SG5 интерфейс 118 и канал широковещательной рассылки в SG-C 120. Перед передачей SG-G может посылать SG в SG-A 111 для настройки SG на соответствие конкретной BDS согласно BDS атрибутам, посланным дистрибьютором BDS услуг по SG-B1 116. Настройка может привести к модификации SG. Следует отметить, что с целью настройки SG-A также может послать BCAST SG атрибуты или BCAST SG фрагменты по SG-B1 в дистрибьютор BDS услуг для настройки, такая настройка в дистрибьюторе BDS услуг выходит за рамки BCAST, SG-D также может получать запрос на SG информацию и посылать запрошенную SG информацию в терминал непосредственно по интерактивному каналу. SG-D также может фильтровать SG информацию из SG-G 109, основываясь на заранее определенном профиле конечных пользователей. SG-D также может посылать SG в BDS, который модифицирует SG (например, добавляя информацию, характерную для BSD) и дополнительно распространяет SG в SG-C характерным для BDS способом

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

Согласно фиг.2 модель данных SG включает Административную (Administrative) Группу 200 для предоставления информации о конфигурации верхнего уровня обо всем SG, Группу 210 Регистрации (Provisioning) для предоставления информации о подписке и информации о покупке, Основную (Core) Группу 220 для предоставления основной SG информации, такой как услуги/контент и графики, и Группу 230 Доступа (Access) для предоставления информации о предоставлении доступа для получения доступа к услугам/контенту.

Административная Группа 200 включает Дескриптор 201 Доставки SG (Service Guide Delivery Descriptor, SGDD), а Группа 210 Регистрации включает Пункт 211 Покупки, Данные 212 о Покупке и Канал 213 Покупки.

Основная Группа 220 включает Услугу 221, График 222 и Контент 223. Группа 230 Доступа выполнена с возможностью включения Доступа 231 и Описания 232 Сеанса.

Дополнительно к этим четырем группам 200, 210, 220 и 230, SG информация также может включать Данные 241 Предварительного Просмотра и Интерактивные Данные 251. Вышеописанные компоненты SG называются фрагментами с минимальными модулями, составляющими SG.

Что касается фрагментов, то фрагмент 201 SGDD предоставляет информацию о сеансе доставки, несущем Модуль Доставки SG (SG Delivery Unit, SGDU) с фрагментами, предоставляет многоадресную информацию о SGDU и точку входа для получения сообщения Извещение.

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

Фрагмент 222 График (Schedule) предоставляет информацию о времени для контента, включенного в услугу, такую как потоковая передача, загрузка и т.д.

Фрагмент 223 Контент (Content) предоставляет описание, группу целевых пользователей, область услуги и классы для широковещательного контента.

Фрагмент 231 Доступ (Access) предоставляет информацию о предоставлении доступа для возможности пользователю получить доступ к услуге, а также предоставляет информацию о схеме доставки сеанса доступа и информацию сеанса о сеансе доступа.

Фрагмент 232 Описание Сеанса (Session Description) может быть включен во фрагмент 231 Доступ. В качестве альтернативы информация о местоположении фрагмента 232 Описание Сеанса дается в виде Единого Идентификатора Ресурсов (Uniform Resource Identifier, URI) с тем, чтобы терминал мог детектировать фрагмент 232 Описание Сеанса. Кроме того, фрагмент 232 Описание Сеанса предоставляет адресную информацию и информацию кодер-декодера о мультимедийном контенте, включенном в сеанс.

Фрагмент 211 Пункт Покупки (Purchase Item) группирует одну или несколько услуг или запланированных пунктов вместе с тем, чтобы пользователь мог купить услугу или пакет услуг или подписаться на них.

Фрагмент 212 Данные о Покупке (Data Purchase) включает информацию о покупке и подписке на услуги или пакеты услуг, такую как информация о цене и рекламная информация.

Фрагмент 213 Канал Покупки (Purchase Channel) предоставляет информацию о получении доступа для подписки на услугу или пакет услуг или их покупки.

Фрагмент 201 SGDD указывает на точку входа для получения руководства по услуге и предоставляет групповую информацию о SGDU, который является контейнером фрагментов.

Фрагмент 241 Данные Предварительного Просмотра (Preview Data) предоставляет информацию об услугах, графиках и контентах для предварительного просмотра, а фрагмент 251 Интерактивные Данные (Interactive Data) предоставляет интерактивную услугу во время широковещательной рассылки согласно услугам, графикам и контентам. Подробная информация относительно SG может быть определена с помощью различных элементов и атрибутов для предоставления контентов и значений на основе описанной выше модели данных по фиг.2.

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

В ходе генерации руководства по услуге в SG-G 109 на основе модели данных SG и предоставления фрагментов SG через SG-D 110 и SG-C 120, представляющим собой пользовательский терминал, передается больше услуг и контента, предоставляемых провайдерами услуг, и больше информации. Получающееся экспоненциальное увеличение фрагментов SG в размере и числе может вызвать существенное увеличение затрат на получение фрагментов, времени для сбора SG и времени и ресурсов для его отображения в терминале.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг.1 представляет собой блок-схему, иллюстрирующую логическую структуру обычных функций ОМА BCAST SG;

Фиг.2 представляет собой модель данных обычного ОМА BCAST SG;

На фиг.3 показан способ получения SG, используя базовый SG, согласно иллюстративному варианту осуществления настоящего изобретения;

Фиг.4 представляет собой блок-схему последовательности операций, иллюстрирующую операцию получения SG, используя базовый SG, в терминале согласно иллюстративному варианту осуществления настоящего изобретения;

Фиг.5 представляет собой иллюстративное представление информации во фрагменте Услуга в модели данных ОМА BCAST SG;

Фиг.6 представляет собой иллюстративное представление информации во фрагменте Доступ в модели данных ОМА BCAST SG; и

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

На всех чертежах одинаковые ссылочные позиции относятся к одинаковым элементам, признакам и структурам.

ПОДРОБНОЕ ОПИСАНИЕ ИЛЛЮСТРАТИВНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

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

Хотя описание иллюстративных вариантов осуществления настоящего изобретения приведено с использованием названий объектов, определенных в 3GPP, который представляет собой стандарт асинхронной мобильной связи, или определенных в ОМА BCAST, стандартная группа для приложения мобильных терминалов, установленные стандарты и имена их объектов не ограничены объемом настоящего изобретения, и настоящее изобретение можно применять к любой системе, имеющей аналогичную техническую базу.

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

Таблица 6 Имя Тип Категория Количество элементов Описание Тип данных            

В таблице 6, термин "Имя" указывает имя объекта, являющегося элементом или атрибутом в сообщении. Термин "Тип" указывает на то, является ли объект элементом или атрибутом. Если объект является элементом, он имеет значение E1, E2, E3 или E4, причем E1 указывает на верхний элемент во всем сообщении, E2 указывает на подэлемент E1, E3 указывает подэлемент E2, а E4 указывает подэлемент E3. Если объект представляет собой атрибут, его Тип имеет значение A. Например, А под E1 указывает на атрибут E1. Термин "Категория" указывает на то, является ли элемент или атрибут обязательным или необязательным. Если элемент или атрибут является обязательным, Категория имеет значение М, а если он является необязательным, то Категория имеет значение O. Термин "Мощность связи" указывает на отношения между элементами и имеет значение 0, 0…1, 1, 0…n, или 1…n. Здесь 0 означает необязательное отношение, 1 означает обязательное отношение, а n означает, что может использоваться множество значений. Например, 0…n означает, что у элемента не может быть никакого значения или он может иметь n значений. Термин "Описание" описывает элемент или атрибут простым текстом, а термин "Тип данных" определяет структуру данных элемента или атрибута.

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

Согласно фиг.3 SG-C терминал (не показан) в мобильной широковещательной системе получает доступ к Сеансу 301 Оповещения и получает SGDD 310 в Сеансе 301 Оповещения. Как указано выше, SGDD 310 включает список SGDU и информацию о сеансах доставки, несущих SGDU. В иллюстративном варианте осуществления на фиг.3 SGDD 310 имеет список SGDU, содержащий фрагменты базового SG и информацию о сеансе 302 доставки (Сеанс X Доставки), несущем запланированные SGDU. Терминал интерпретирует SGDD 310, получает доступ к Сеансу X Доставки и получает SGDU 311 для базового SG из Сеанса X Доставки. Затем терминал извлекает фрагменты для базового SG из SGDU 311 и отображает конечный базовый SG 320 пользователю.

Базовый SG 320 может включать дополнительную информацию об услуге или предоставлять информацию о том, как получить доступ к SG, предоставляемому другим провайдером услуг. На фиг.3 терминал может детектировать информацию о приеме первого SG 321 (SG1) и второго SG 322 (SG2) в базовом SG 320. Информация о приеме SG1 включает информацию о сеансе 303 доставки (Сеанс Y Доставки), несущем SGDU 312 для SG1, а информация о приеме SG2 включает информацию о сеансе 304 доставки (Сеанс Z Доставки), несущем SGDU 313 для SG2. Терминал получает доступ к Сеансу Y Доставки или Сеансу Z Доставки, получает SGDU 312 для SG1 или SGDU 313 для SG2 и отображает SG1 или SG2 пользователю.

Фиг.4 представляет собой блок-схему последовательности операций, иллюстрирующую способ получения SG в терминале согласно иллюстративному варианту осуществления настоящего изобретения.

Согласно фиг.4, терминал получает доступ к Сеансу Оповещения и получает SGDD в Сеансе Оповещения на этапе 401. На этапе 402 терминал интерпретирует SGDD и детектирует информацию о сеансе доставки и SGDU, которые несут фрагменты для SG. Терминал получает все SGDU, на которые указал SGDD из сеанса доставки на этапе 403. Терминал извлекает фрагменты из SGDU и конфигурирует SG, интерпретируя эти фрагменты на этапе 404, и проверяет список фрагментов Услуга в SG на этапе 405. Фиг.5 представляет собой диаграмму, показывающую иллюстративные значения верхних элементов и значения атрибутов фрагмента Услуга.

На этапе 406 терминал определяет, существует ли ServiceType 501 (фиг.5), установленный для Руководства по Услуге, интерпретируя фрагменты Услуга списка фрагментов Услуга. Если ServiceType 501 (фиг.5), установленный для Руководства по Услуге отсутствует, можно предположить, что SG содержит только информацию, которую терминал получил от провайдера услуг без информации о регистрации другого SG. В этом случае терминал отображает SG пользователю на этапе 407.

В качестве альтернативы, если ServiceType 501 (фиг.5), установленный для Руководства по Услуге, существует, что означает включение информации о приеме SG и получение доступа к другому SG в данном SG, то терминал детектирует все фрагменты Доступ, связанные с фрагментом Услуга, с ServiceType 501 (фиг.5), установленным для Руководства по Услуге на этапе 408. Фиг.6 представляет собой диаграмму, показывающую иллюстративные значения верхних элементов и значения атрибутов фрагмента Доступ.

На этапе 409 терминал определяет значение ServiceClass 601 в каждом из обнаруженных фрагментов Доступ. Если ServiceClass 601 представляет собой 'urn:oma:oma_bsc:sg:1.0', это означает, что сеанс доставки, соответствующий информации о доставке, включенной во фрагмент Доступ, несет независимый SG. Если ServiceClass 601 представляет собой 'urn:oma:oma_bsc:csg:1.0', это означает, что сеанс доставки, соответствующий информации о получении доступа, включенной во фрагмент Доступ, несет дополнительный SG, который предоставляет дополнительную информацию о SG. Таким образом, терминал приобретает предварительную информацию о независимом SG или дополнительном SG путем проверки подэлемента ReferredSGInfo в ServiceClass на этапе 410, который задан следующим образом.

Таблица 7 Имя Тип Категория Мощность связи Описание Тип данных Access Е     Фрагмент 'Доступ' содержит следующие атрибуты:
id
version
validFrom
validTo
Содержит следующие элементы:
AccessType
KeyManagementSystem
EncryptionType
ServiceReference
ScheduleReference
TerminalCapability-Requirement
BandwidthRequirement
ServiceClass
PreviewDataReference
NotificationReception
PrivateExt   id А NM/TM 1 ID фрагмента 'Доступ'. Значение этого атрибута ДОЛЖНО быть глобально уникальным nyURI version А NM/TM 1 Версия этого фрагмента. Более новая версия блокирует более старую версию с момента, задаваемого атрибутом validFrom, или сразу после ее получения, если атрибут validFrom не задан nsignedInt validFrom А NM/TM 0…1 Первый момент, когда этот фрагмент является достоверным. Если он не задан, предполагается, что его достоверность уже задана в какое время в прошлом. Это поле содержит 32-битную целую часть временной отметки NTP unsignedInt validTo А NM/TM 0…1 Последний момент, когда этот фрагмент является достоверным. Если он не задан, предполагается, что его достоверность прекратится через какое-то время в будущем. Это поле содержит 32-битную целую часть временной отметки NTP unsignedInt AccessType Е1 NM/TM 1 Определяет тип доступа. Примечание: ДОЛЖЕН быть создан экземпляр одного из: 'BroadcastService-Delivery' либо 'UnicastService-Delivery', но не обоих. Для реализации в Схеме XML следует использовать <choice>.
Содержит следующие элементы:
BroadcastService-Delivery
UnicastServiceDelivery   Broadcast
Service
Delivery Е2 NM/TM 0…1 Этот элемент используется для указания IP передачи.
Содержит следующие элементы:
BDSType
SessionDescription
FileDescription   BDSType Е3 NM/TM 0…1 Идентификатор типа основной системы распространения, к которой относится этот фрагмент 'Доступ'.
Содержит следующие элементы:
Type
Version   Type Е4 NM/TM 0…1 Тип основной BDS, возможные значения:
0. IPDC по DVB-H
1.3GPPMBMS
2. 3GPP2 BCMCS
3-127. зарезервированы для будущего использования
128-255. зарезервированы для закрытого использования Unsigned-Byte Version Е4 NM/TM 0…N Версия основной BDS. Например, возможными значениями являются Rel-6 или Rel-7 для MBMS и 1x или HRPD или Enhanced HRPD для BCMCS string Session
Descrip-tion Е3 NM/TM 0…1 Ссылка или встраиваемая копия информации Описание Сеанса, связанной с этим фрагментом 'Доступ', который использует медиа приложение в терминале для получения доступа к услуге. Примечание: упомянутый фрагмент 'SessionDescription' может доставляться двумя способами: по широковещательной рассылке или путем вызова по интерактивному каналу. В случае вызова по интерактивному каналу, фрагмент 'SessionDescription' может быть приобретен путем получения доступа к URI (заданному в виде атрибута другого элемента ссылки на Описание Сеанса). Содержит следующие элементы:
SDP
SDPRef
USBDRef
ADPRef
Наличие элементов 'SDP' и 'SDPRef' является взаимоисключающим. Если предоставлен элемент 'SessionDescription', и атрибут 'type' имеет одно из значений "4" или "5", терминал МОЖЕТ его использовать вместо вызова информации Описание Сеанса через RTSP   SDP Е4 NM/TM 0…1 Встроенное Описание Сеанса в формате SDP [RFC 4566], которое ДОЛЖНО быть либо введено в секцию CDATA, либо кодировано по base64. Содержит следующий атрибут:
encoding string encoding А NM/TM 0…1 Этот атрибут сигнализирует о способе введения Описания Сеанса: он не ДОЛЖЕН присутствовать, если Описание Сеанса введено в секцию CDATA. Он должен присутствовать и быть установлен в "base64" в случае, если Описание Сеанса кодировано по base64 string SDPRef Е4 NM/TM 0…1 Ссылка на Описание Сеанса в формате SDP [RFC 4566]. Содержит следующие атрибуты:
uri
idRef
Если присутствуют оба, 'uri' и 'idRef, упомянутая информация Описание Сеанса ДОЛЖНА быть идентичной   uri А NM/TM 0…1 URI ссылается на внешний ресурс, содержащий информацию SDP. Этот URI используется для интерактивного поиска anyURI idRef А NM/TM 0…1 id упомянутого фрагмента 'SessionDescription', если фрагмент передается по каналу широковещательной рассылки в SGDU, глобально уникальный anyURI USBDRef Е4 NM/TM 0…1 Ссылка на экземпляр Описание Группы Пользовательских Услуг MBMS как описано в секции 5.2.2 [26.346], с ограничениями, определенными в секции 5.1.2.5 этой спецификации. Содержит следующие атрибуты:
uri
idRef
Если присутствуют оба, 'uri' и 'idRef, упомянутая информация Описание Сеанса ДОЛЖНА быть идентичной   uri А NM/TM 0…1 URI ссылается на внешний ресурс, содержащий информацию MBMS-USBD. Этот URI используется для интерактивного поиска anyURI idRef А NM/TM 0…1 id упомянутого фрагмента 'SessionDescription', если фрагмент передается по каналу широковещательной рассылки в SGDU, глобально уникальный anyURI ADPRef Е4 NM/TM 0…1 Ссылка на AssociatedDelivery-Procedure для Распространения Файлов и Потоков, как описано в секции
5.3.4 [BCAST10-Distribution].
Содержит следующие атрибуты:
uri
idRef
Если присутствуют, оба 'uri' и 'idRef, упомянутая информация Описание Сеанса ДОЛЖНА быть идентичной   uri А NM/TM 0…1 URI ссылается на внешний ресурс, содержащий AssociatedDelivery-Procedure для Распространения Файлов и Потоков. Этот URI используется для интерактивного поиска. anyURI idRef А NM/TM   id упомянутого фрагмента 'SessionDescription', если фрагмент передается по каналу широковещательной рассылки в SGDU, глобально уникальный anyURI FileDes-cription Е3 NO/TM 0…1 Метаданные файлов для сеансов доставки файлов. Этот элемент ДОЛЖЕН предоставляться, когда используется ALC. Этот элемент НЕ ДОЛЖЕН использоваться совместно с FLUTE.
Сеть ДОЛЖНА поддерживать элемент 'FileDescription' и все его подэлементы и атрибуты, если используется ALC для функции Распространения Файлов.
Содержит следующие атрибуты:
Content-Type
Content-Encoding
FEC-OTI-FEC-Encoding-ID
FEC-OTI-FEC-Instance-ID
FEC-OTI-Maximum-Source-Block-Length
FEC-OTI-Encoding-Symbol-Length
FEC-OTI-Max-Number-of-Encoding-Symbols
FEC-OTI-Scheme-Specific-Info Содержит следующий элемент:
File   Content-Type А NO/TM 0…1 См. RFC 3926, секция 3.4.2 string Content-Encoding А NO/TM 0…1 См. RFC 3926, секция 3.4.2 string FEC-OTI-FEC-Encoding-ID А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Byte FEC-OTI-FEC-Instance-ID А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long FEC-OTI-Maximum-Source-Block-Length А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long FEC-OTI-Encoding-Symbol-Length А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long FEC-OTI-Max-Number-of-Encoding-
Symbols А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long FEC-OTI-Scheme-Specific-Info А NO/TM 0…1 Этот атрибут МОЖНО использовать для обмена FEC информацией, которая неадекватно представлена другими атрибутами, относящимися к FEC base64-Binary File Е4 NO/TM 1…N Параметры файла. Содержит следующие атрибуты:
Content-Location
TOI
Content-Length
Transfer-Length
Content-Type
Content-Encoding
Content-MD5
FEC-OTI-FEC-Encoding-ID
FEC-OTI-FEC-Instance-ID
FEC-OTI-Maximum-Source-Block-Length
FEC-OTI-Encoding-Symbol-Length
FEC-OTI-Max-Number-of-Encoding-Symbols
FEC-OTI-Scheme-Specific-Info   Content-Location   NO/TM 1 См. RFC 3926, секция 3.4.2 nyURI TOI А NO/TM 1 См. RFC 3926, секция 3.4.2 Positive-Integer Content-Length А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long Transfer-Length А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long Content-Type А NO/TM 0…1 См. RFC 3926, секция 3.4.2 string Content-Encoding А NO/TM 0…1 См. RFC 3926, секция 3.4.2 string Content-MD5 А NO/TM 0…1 См. RFC 3926, секция 3.4.2 base64-Binary FEC-OTI-FEC-Encoding-ID А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Byte FEC-OTI-FEC-Instance-ID А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long FEC-OTI-Maximum-Source-Block-Length А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long FEC-OTI-Encoding-Symbol-Length А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long FEC-OTI-Max-Number-of-Encoding-Symbols А NO/TM 0…1 См. RFC 3926, секция 3.4.2 Unsigned-Long FEC-OTI-Scheme-Specific-Info А NO/TM 0…1 Этот атрибут МОЖНО использовать для обмена FEC информацией, которая может быть неадекватно представлена другими атрибутами, относящимися к FEC base64-Binary Unicast-Service-Delivery Е2 NM/TM 0…N Этот элемент указывает, какая услуга и/или протокол используется для доставки услуги по Интерактивному Каналу.
Содержит следующий атрибут:
type
Содержит следующие элементы:
AccessServerURL
SessionDescription
ServiceAccessNotification
URL   type А NM/TM 1 Задает механизм транспортировки, который используется для получения этого доступа.
0 - HTTP
1 - WAP 1.0
2 - WAP 2.x
3 - Родовой RTSP для использования RTP доставки
4- RTSP для инициализации RTP доставки согласно 3GPP-PSS (3GPP услуга передачи данных с коммутацией пакетов)
5 - RTSP для инициализации RTP доставки согласно 3GPP2-MSS (3GPP2 мультимедийные потоковые услуги)
6 - FLUTE по Unicast
7-127 зарезервированы для будущего использования
128-255 зарезервированы для закрытого использования
Примечание: Спецификация или согласование портов, используемых для одноадресной передачи услуги, задействуется при используемых механизмах одноадресного распространения. Например, системы на основе RTSP и PSS (значения 3 и 4) выполняют согласование портов внутри обмена RTSP сигнализации Unsigned-Byte Access-ServerURL Е3 NM/TM 0…N Сервер URL, из которого терминал может получать услугу через Интерактивную Сеть, как определено в секции 5.5 и 6.5 [BCAST10-Distribution]. Например, AccessServerURL может быть HTTP URL, указывающим на загружаемый контент, или RTSP URL, указывающим на услугу потоковой передачи для начала сеанса потоковой передачи. Если атрибут 'type' имеет одно из значений "3", "4" или "5", ДОЛЖЕН быть создан экземпляр либо 'SessionDescription' элемента E3, либо 'AccessServerURL' элемента E3, либо обоих элементов anyURI Session-Descrip-tion Е3 NM/TM 0…1 Ссылка или встроенная копия информации Описание Сеанса, связанной с фрагментом 'Доступ', который использует медиа приложение в терминале для получения доступа к услуге.
Примечание: упомянутый фрагмент 'SessionDescription' может доставляться двумя способами: через широковещательную рассылку или путем вызова по интерактивному каналу.
В случае вызова по интерактивному каналу фрагмент 'SessionDescription' может быть приобретен путем получения доступа к URI (заданного в виде атрибута других ссылочных элементов Описание Сеанса).
Содержит следующие элементы:
SDP
SDPRef
USBDRef
ADPRef
Наличие элементов 'SDP' и 'SDPRef взаимо исключается. Если создается экземпляр 'SessionDescription' элемента E3, и атрибут 'type' имеет одно из значений "3", "4" или "5", терминал МОЖЕТ использовать его для приобретения информации Описание Сеанса (включая RTSP URL) по каналу широковещательной рассылки или интерактивному каналу, используя 'SDPRef', или путем использования встроенного SDP ('SDP' элемента E4), вместо запроса информации Описание Сеанса через RTSP. Более того, в этом случае 'AccessServerURL' элемента E3 МОЖЕТ НЕ присутствовать. Если атрибут 'type' имеет одно из значений "3", "4" или "5", ДОЛЖЕН быть создан экземпляр либо 'SessionDescription' элемента E3, либо 'AccessServerURL' элемента E3, либо оба элемента   SDP Е4 NM/TM 0…1 Встроенное Описание Сеанса в формате SDP [RFC 4566], которое ДОЛЖНО быть либо введено в секцию CDATA, либо кодировано по base64.
Содержит следующий атрибут:
encoding string encoding А NM/TM 0…1 Этот атрибут сигнализирует о способе введения Описания Сеанса: Он НЕ ДОЛЖЕН присутствовать при введении Описания Сеанса в секцию CDATA. Он ДОЛЖЕН присутствовать и быть установлен в "base64" в случае если Описание Сеанса кодировано по base64 string SDPRef Е4 NM/TM 0…1 Ссылка на Описание Сеанса в формате SDP [RFC 4566].
Содержит следующие атрибуты:
uri
idRef
При наличии обоих, 'uri' и 'idRef', упомянутая информация Описание Сеанса ДОЛЖНА быть идентичной   uri А NM/TM 0…1 URI, ссылающийся на внешний ресурс, содержащий SDP информацию. Этот URI используется для интерактивного поиска. Для этой цели терминал ДОЛЖЕН поддерживать HTTP URI anyURI idRef А NM/TM 0…1 id упомянутого фрагмента 'SessionDescription', если фрагмент доставляется по каналу широковещательной рассылки в SGDU, глобально уникальный anyURI USBDRef Е4 NM/TM 0…1 Ссылка на экземпляр Описание Группы Пользовательских Услуг MBMS, как описано в секции 5.2.2 [26.346], с ограничениями, определенными в секции 5.1.2.5 этой спецификации.
Содержит следующие атрибуты:
uri
idRef
При наличии обоих, 'uri' и 'idRef', упомянутая информация Описание Сеанса ДОЛЖНА быть идентичной   uri А NM/TM 0…1 URI, ссылающийся на внешний ресурс, содержащий информацию MBMS-USBD. Этот URI используется для интерактивного поиска. Для этой цели терминал ДОЛЖЕН поддерживать HTTP URI anyURI idRef А NM/TM 0…1 id упомянутого фрагмента 'SessionDescription', если фрагмент передается по каналу широковещательной рассылки в SGDU, глобально уникальный anyURI ADPRef Е4 NM/TM 0…1 Ссылка на AssociatedDelivery-Procedure для Распространения Потоков и Файлов, как определено в секции 5.3.4 в [BCAST10-Distribution].
Содержит следующие атрибуты:
uri
idRef
При наличии обоих, 'uri' и 'idRef, упомянутая информация Описание Сеанса ДОЛЖНА быть идентичной   uri А NM/TM 0…1 URI, ссылающийся на внешний ресурс, содержащий информацию AssociatedDelivery-Procedure для Распространения Потоков и Файлов. Этот URI используется для интерактивного поиска anyURI idRef А NM/TM 0…1 id упомянутого фрагмента 'SessionDescription', если фрагмент передается по каналу широковещательной рассылки в SGDU, глобально уникальный anyURI Service-Access-Notifi-cationURL Е3 NM/TM 0…N URL, который терминал ДОЛЖЕН использовать для извещения BSD/A при получении доступа (подключении) к этому серверу по этому одноадресному доступу. 'ServiceAccess-NotificationURL' МОЖЕТ использоваться совместно с типами 3, 4, 5 или 6 'UnicastServiceDelivery'. При его использовании устройство НЕ ДОЛЖНО использовать RTSP TEARDOWN и RTSP SETUP для завершения существующего RTSP потока и запуска нового потока.
Терминал НЕ ДОЛЖЕН использовать этот URL для извещения без согласия пользователя.
Примечание: Этот URL может, например, использоваться для инициации управляемого сервером канала, который подключает одноадресную передачу anyURI KeyManage-mentSystem Е1 NM/TM 0…N Информация Система(системы) Управления Ключами (Key Management System, KMS), которую можно использовать для установления контакта с Издателем Разрешения Доступа к BCAST и, в случае Профиля SmartCard, при котором для получения SMK используется GBA, либо обязательным является GBAU либо можно использовать GBAME или GBA_U. Следует отметить, что Издатель Разрешения Доступа к BCAST может поддерживать более одной KMS. Если не KeyManagementSystem определена, это означает, что не применяется услуга или контент. В этом фрагменте разрешено многочисленное появление элементов 'KeyManagementSystem' только, если все элементы 'KeyManagementSystem' имеют различные атрибуты 'kmsType'.
Содержит следующие элементы:
ProtectionKeyID
PermissionsIssuerURI
TerminalBindingKeyID
Содержит следующие атрибуты:
kmsType
protectionType   kmsType А NM/TM 1 Определяет тип Системы(Систем) Управления Ключами (KMS). Возможные значения:
0. oma-bcast-drm-pki указывает профиль OMA BCAST DRM (Инфраструктура Открытого Ключа (Public Key Infrastructure))
1. oma-bcast-gba_u-mbms указывает профиль BCAST Smartcard, использующий GBA_U (Инфраструктура Симметричного Ключа (Symmetric Key Infrastructure))
2. oma-bcast-gba_me-mbms указывает профиль BCAST Smartcard, использующий GBA_ME
3. oma-bcast-prov-bcmcs указывает на предоставленный 3GPP2 BCMCS SKI
4-127 зарезервированы для будущего использования,
128-255 зарезервированы для закрытого использования Unsigned-Byte protectionType А NM/TM 1 Определяет тип защиты, предлагаемый KMS.
Значения:
0. Защита только контента, как определено LTKM (protection_after_reception в STKM = 0x00 или 0x01 [BCAST10-ServContProf])
1. Защита только услуги (protection_after_
reception в STKM = 0x03 [BCAST10-ServContProt])
2. Защита контента, как определено LTKM, плюс воспроизведение защищенного разрешения на запись (protection_after_reception в STKM = 0x02 [BCAST10-ServContProt])
3-127 зарезервированы для будущего использования
128-255 зарезервированы для закрытого использования
Этот атрибут также может использоваться для целей презентации пользователям, для указания того, защищен или нет пункт(пункты) контента, связанные с упомянутым Графиком с помощью фрагмента 'Доступ' Unsigned-Byte PermissionsIssuerURI Е2 NM/TM 1 Адрес Издателя Разрешения Доступа к BCAST, которому направляется запрос на материал ключа, разговоры и/или правила регистрации, должен посылаться BCAST Терминалом. Содержит следующие атрибуты:
type anyURI type А NM/TM 1 Тип PermissionsIssuerURI, идентифицируемый следующими значениями:
ложный - DRM Profile
истиный - Smartcard Profile
Примечание: В случае профиля DRM, PermissionsIssuerURI соответствует RightsIssuerURL, как определено [DRMDRM-v2.0]. В случае профиля Smartcard, PermissionsIssuerURI соответствует сетевому объекту (т.е., BSM), у которого все сообщения по Регистрации на BCAST Услугу посылаются терминалом boolea ProtectionKeyID Е2 NO/TO 0…N Идентификатор ключа должен получить доступ к защищенному контенту. Эта информация позволяет терминалу определить, имеет он или нет корректный материал ключа для получения доступа к услугам в PurchaseItem. В сценарии, при котором этот фрагмент совместно используется многочисленными провайдерами услуг, различные идентификаторы ключа от различных провайдеров услуг для получения доступа к этой конкретной защищенной услуге/контенту могут быть смешаны в этом элементе, и терминал должен быть способным отсортировать идентификаторы ключа, связанные с провайдерами дочерних услуг терминала на основе ID Домена Ключа. Как это используется следует из объема и предоставляется для реализации. Сеть и терминал ДОЛЖНЫ поддерживать этот элемент в случае, если поддерживается профиль Smartcard [BCAST10-ServContProt]. Защита идентификаторов ключа для получения доступа к конкретной услуге или пункту контента ДОЛЖНА сигнализироваться в один из следующих типов фрагментов: 'Услуга', 'Контент', 'PurchaseItem' или 'Доступ', но не смешиваться.
Содержит следующий атрибут: type base64-Binary type А NM/TM 1 Тип ProtectionKeyID:
0: ProtectionKeyID = ID Домена Ключа, сцепленный с ID SEK/PEK, где оба значения такие, как используется в профиле Smartcard [BC AST 10-ServContProt].
1-127 зарезервированы для будущего использования,
128-255 зарезервированы для закрытого использования Unsigned-Byte Terminal-Binding
KeyID E2 NO/TO 0…1 Номер, идентифицирующий ID Ключа Связи с Терминалом (Terminal Binding Key ID, TBK ID), который необходим для получения доступа к услуге. Если элемент отсутствует, используется TerminalBindingKey. Оба, и сеть и терминал, с профилем Smartcard ДОЛЖНЫ поддерживать этот элемент. Он представляет собой TM для терминалов с профилем Smartcard. Этот элемент не применяется для профиля DRM.
Содержит следующий атрибут:
tbkPermissionsIssuerURI unsignedInt tbkPermis-sionsIssuerURI А NO/TM 0…1 Определяет URI Издателя Разрешения Доступа для TerminalBindingKey, если он отличается от подэлемента 'PermissionsIssuerURI' элемента 'KeyManagementSystem'. Если атрибут не присутствует, тот же самый 'PermissionsIssuerURI', указанный для KeyManagementSystem, используется для приобретения обоих, SEK/PEK и TerminalBindingKey anyURI EncryptionType Е1 NM/TM 0…N Определяет, какие способы шифрования терминал способен поддерживать для использования этого Доступа. Содержит такие же значения, как traffic_protection_protocol, сигнализируемый в STKM.
0 - IPsec
1-STRP
2 - ISMACryp
3-DCF
4-255 зарезервированы для будущего использования.
Если этот элемент не присутствует, этот Доступ не шифруется Unsigned-Byte Service-Reference Е1 NM/TM 0…N Ссылка на фрагмент(фрагменты) 'Услуга', которому принадлежит фрагмент 'Доступ'. ДОЛЖЕН быть создан экземпляр либо одного из: 'ServiceReference' или 'ScheduleReference', либо ни одного из них, но не обоих. Каждый фрагмент 'Услуга' ДОЛЖЕН быть связан с по меньшей мере одним фрагментом 'Доступ', чтобы терминал смог получить доступ к Услуге. Один фрагмент 'Доступ' МОЖЕТ ссылаться на множество фрагментов 'Услуга'. Это используется, когда имеется несколько независимых описаний одной Услуги   idRef А NM/TM 1 Идентификация фрагмента 'Услуга', с которой этот фрагмент 'Доступ' связан. anyURI Schedule-Reference Е1 NM/TM 0…N Ссылка на фрагмент(фрагменты) 'График', которому принадлежит фрагмент 'Доступ'. Он предоставляет ссылку на фрагмент 'График' для временного замещения отсутствия фрагмента 'Доступ' Услуги, к которой обращаются через График. ДОЛЖЕН быть создан экземпляр либо одного из: 'ServiceReference' или 'ScheduleReference', либо ни одного из них, но не обоих. Примечание: Реализация в схеме XML, использующей <choice>. Содержит следующий атрибут:
idRef
Содержит следующий элемент:
DistributionWindowID   idRef А NM/TM 1 Идентификация фрагмента 'График', который относится к фрагменту 'Доступ'. anyURI Distribu-tionWindowID Е2 NO/TM 0…N Родственная ссылка на DistributionWindowID, которой принадлежит фрагмент 'Доступ'. Элемент 'DistributionWindowID', заявленный в этом элементе, ДОЛЖЕН представлять собой полную коллекцию или поднабор DistributionWindow ID, заявленных во фрагменте 'График', которому принадлежит ссылка 'idRef' unsignedint Terminal-Capabi-lity-Requi-rement Е1 NO/TM 0…1 Возможности терминала, необходимые для покупки услуги или контента. Этот элемент предоставляет подсказку терминалу, который нуждается в применении способа покупки, представленного этим фрагментом 'Доступ'. Он выходит за пределы объема описания того, как терминал использует информацию. Для видео и аудио, медиа тип и родственный атрибут 'тип' в SDP (см. секцию 5.1.2.5) передают сигнал в аудио/видео декодер. Таким образом, эти параметры дополняют TerminalCapability-Requirement. Кроме того, здесь описаны сложности аудио/видео потоков, если они отличаются от сложности, которая может исходить из атрибутов медиа типа в SDP (например, уровень). В этом случае, имеют приоритет параметры, определенные во фрагменте 'Доступ'.
Содержит следующие элементы:
Video
Audio
DownloadFile   Video Е2 NO/TM 0…1 Возможность видео кодека, соответствующая требованиям.
Содержит следующий элемент:
Complexity   Complexity Е3 NO/TM 1 Сложность, с которой имеет дело видео декодер. РЕКОММЕНДУЕТСЯ включение этого элемента, если сложность, указанная параметрами MIME типа в SDP, отличается от реальной сложности.
Содержит следующие элементы:
Bitrate
Resolution
MinimumBufferSize   Bitrate Е4 NO/TM 0…1 Общая битовая скорость видео потока. Содержит следующие атрибуты:
average
maximum   average А NO/TM 0…1 Средняя битовая скорость в кбит/с Unsigned-Short maximum А NO/TM 0…1 Максимальная битовая скорость в кбит/с Unsigned-Short Resolution А NO/TM 0…1 Разрешение видео.
Содержит следующие атрибуты:
horizontal
vertical
temporal   horizontal А NO/TM 1 Горизонтальное разрешение видео в пикселях. Unsigned-Short vertical А NO/TM 1 Вертикальное разрешение видео в пикселях. Unsigned-Short temporal А NO/TM 1 Максимальное временное разрешение в кадрах на секунду. decimal MinimumBufferSize Е4 NO/TM 0…1 Минимальный размер буфера декодера, необходимый для обработки видео контента, в килобитах. unsignedint Audio Е2 NO/TM 0…1 Возможность аудио кодека.
Содержит следующий элемент:
Complexity   Complexity Е3 NO/TM 1 Сложность, с которой аудио декодер должен справляться. РЕКОМЕНДУЕТСЯ, чтобы этот элемент был включен, если сложность, указанная параметрами типа MIME в SDP, отличается от реальной сложности.
Содержит следующие элементы:
Bitrate
MinimumBufferSize   Bitrate Е4 NO/TM 0…1 Общая битовая скорость аудио потока.
Содержит следующие атрибуты:
average
maximum   average А NO/TM 0…1 Средняя битовая скорость в кбит/с Unsigned-Short maximum А NO/TM 0…1 Максимальная битовая скорость в кбит/с Unsigned-Short MinimumBufferSize Е4 NO/TM 0…1 Минимальный размер буфера декодера, необходимый для обработки аудио контента, в кбит unsignedInt Download-File Е2 NO/TM 0…1 Требуемая возможность для загрузки файлов.
Содержит следующий элемент:
MIMEType   MIMEType Е3 NO/TM 1…N При условии, что загруженная услуга состоит из набора файлов с различными типами MIME, которые вместе составляют услугу, терминал должен поддерживать все эти типы MIME, чтобы быть способным предоставлять эту услугу пользователю. Формат этой строки ДОЛЖЕН соответствовать синтаксису 'Content-Type', определенному в [RFC 2045].
Кроме того, 'Content-Type' МОЖЕТ быть увеличен, как определено в [RFC 4281]. В последнем случае 'Content-Type' ДОЛЖЕН начинаться с помощью
"audio/3 gpp",
"audio/3gpp2",
"video/3 gpp",
"video/3gpp2".
Содержит следующий атрибут:
codec string codec А NO/TM 0…1 Параметры кодека для связанного медиа типа MIME. Если определение файла типа MIME описывает обязательные параметры, они ДОЛЖНЫ быть включены в эту строку. Необязательные параметры, содержащие информацию, которая может быть использована для определения того, может ли терминал организовать использование файла, ДОЛЖНЫ быть включены в строку. Один из примеров таких параметров, определенных для audio/3 GPP, audio/3 GPP2, video/3 GPP, video/3 GPP2, описан в [RFC4281] string Bandwidth-Require-ment Е1 NO/TM 0…1 Спецификация необходимой способности пропускной сети, в кбит/с, для получения доступа к каналу, описанному в этом фрагменте. Услуга широковещательной рассылки может включать множество доступных потоков (с одним и тем же контентом) с разной пропускной способностью, так что терминал может выбирать в зависимости от своего текущего состояния приема unsignedint Service-Class Е1 NM/TM 1 ServiceClass идентифицирует класс услуги. Эта идентификация является более детальной, чем элемент 'ServiceType' во фрагменте 'Услуга', и позволяет связь комбинации услуга/доступ для конкретных приложений.
Содержит следующий атрибут:
urn
Содержит следующий элемент:
ReferredSGInfo   urn А NM/TM 1 Описывает ServiceClass, как определено в регистре OMNA (см. Приложение E).
Терминал ДОЛЖЕН быть способным интерпретировать информацию string ReferredSGInfo Е2 NM/TM 0…1 Описывает дополнительную информацию для упомянутого Руководства по Услуге. Этот элемент ДОЛЖЕН присутствовать, только когда 'ServiceClass' представляет собой "urn:oma:bcast:oma_bsc;csg:1.0" или "urn:oma:bcasst:oma_bsc:sg:1.0".
Содержит следующие элементы:
BSMSelector
ServiceIDRef
ServiceGuideDelivery-Unit   BSMSelec-tor Е3 NM/TM 0…N Описывает BSM, связанный с упомянутым Руководством по Услуге.
Содержит следующие атрибуты:
idRef   idRef А NM/TM 1 Ссылка на идентификатор BSMSelector, заявленный с 'BSMList' в ServiceGuideDeliver-Descriptor, который используется для приема этого фрагмента anyURI SPName Е4 NO/TM 0…1 Предоставляет пользователю считываемое имя для BSMSelector, возможно множество языков. Значение должно быть таким же, как предоставлено в ServiceGuideDelivery-Descriptor, на который была приведена ссылка выше через idRef.
Этот элемент может использоваться для предоставления пользователю информации для выбора релевантного упомянутого Руководства по Услуге string Service-IDRef Е3 NM/TM 0…1 Значение этого поля представляет собой ID фрагмента для фрагмента 'Услуга', относящегося к упомянутому Руководству по Услуге. anyURI Service-Guide-Delivery-Unit Е3 NM/TM 1…N Группа фрагментов.
Содержит следующие атрибуты:
transportObjectID,
versionIDLength,
contentLocation,
validFrom,
validTo
Содержит следующий элемент:
Fragment   Transport-ObjectID А NM/TM 0…1 ID объекта передачи Модуля Передачи Руководства по Услуге, несущего заявленные фрагменты в этой группе. Если 'FileDescription' присутствует в этом фрагменте, то значение 'transportObjectID' ДОЛЖНО совпадать со значением TOI, спаренным в FDT, например, с 'Content-Location', имеющим в качестве своего значения значение приведенного ниже атрибута 'contentLocation'. Если и только если создан экземпляр 'Transport' элемента E2, ДОЛЖЕН быть создан экземпляр этого атрибута Positive-Integer Versioni-DLength А NO/TO 0…1 Указывает на количество по меньшей мере значимых битов, представляющих ID версии в transportObjectID, когда используется Split-TOI. Если этот элемент опущен, предполагается, что терминал не использует Split-TOI Unsigned-Long Content-Location А NM/TM 1 Это представляет собой местоположение Модуля Доставки Руководства по Услуге. Он соответствует атрибуту 'Content-Location' в FDT. Если и только если создан экземпляр 'Transport' элемента E2, ДОЛЖЕН быть создан экземпляр этого атрибута anyURI validFrom А NM/TM 0…1 Первый момент времени, когда эта группа фрагментов Руководства по Услуге является достоверной. Это поле содержит 32-битную целую часть отметки времени NTP.
Примечание: Если этот атрибут не присутствует, то в подэлементе 'Fragment' ДОЛЖЕН присутствовать атрибут 'validFrom' unsignedInt validTo А NM/TM 0…1 Последний момент времени, когда эта группа фрагментов Руководства по Услуге является достоверной. Это поле содержит 32-битную целую часть отметки времени NTP.
Примечание: Если этот атрибут не присутствует, то в подэлементе 'Fragment' ДОЛЖЕН присутствовать атрибут 'validTo' unsignedInt Fragment Е4 NM/TM 1…N Объявление фрагмента Руководства по Услуге. Если этот фрагмент доступен по каналу широковещательной рассылки, он ДОЛЖЕН здесь присутствовать. Если фрагмент доступен по интерактивному каналу, он МОЖЕТ здесь присутствовать.
Содержит следующие атрибуты:
transportID,
id
version
validFrom
validTo
fragmentEncoding
fragmentType
Содержит следующий элемент:
GroupingCriteria   Transport-ID А NM/TM 0…1 Идентификатор объявленного фрагмента Руководства по Услуге, предназначенного для использования в заголовке Модуля Доставки Руководства по Услуге.
Примечание: Если SG передается только по каналу широковещательной рассылки, этот элемент ДОЛЖЕН присутствовать unsignedInt id А NM/TM 1 Идентификатор объявленного фрагмента Руководства по Услуге. anyURI version А NM/TM 1 Версия объявленного фрагмента Руководства по Услуге.
Примечание: объем версии ограничен для данного сеанса передачи. Значение версии обновляется от 2^˄32-1 до 0 unsignedInt validFrom А NM/TM 0…1 Первый момент, когда этот фрагмент является достоверным. Если он не задан, подразумевается, что этот фрагмент становится достоверным спустя какое-то время. Это поле содержит 32-битную целую часть отметки времени NTP.
Примечание: Если этот атрибут присутствует и атрибут 'validFrom' для 'ServiceGuideDelivery-Unit' также присутствует, то значение этого атрибута отменяет значение атрибута 'validFrom' для 'ServiceGuideDelivery-Unit' unsignedInt validTo А NM/TM 0…1 Последний момент, когда этот фрагмент является достоверным. Если он не задан, то предполагается, что достоверность этого фрагмента заканчивается в неопределенном времени в будущем. Это поле содержит 32-битную целую часть отметки времени NTP.
Примечание: Если этот атрибут присутствует и атрибут 'validTo' для 'ServiceGuideDelivery-Unit' также присутствует, то значение этого атрибута отменяет значение атрибута 'validTo' для 'ServiceGuideDelivery-Unit' unsignedInt Fragment-Encoding А NM/TM 1 Сигнализирует кодирование фрагмента Руководства по Услуге, с помощью следующих значений:
0 - фрагмент Руководства по Услуге OMA BCAST, кодированный в XML
1 - фрагмент SDP
2 - Пользовательская Услуга MBMS
Описание, как определено в [26.346] (см. 5.1.2.4, SessionDescription-Reference)
3 - Связанная Процедура Доставки, кодированная в XML, как определено в секции 5.3.4 [BCAST10-Distribution].
4-127 зарезервированы для будущих BCAST расширений
128-255 доступны для закрытых расширений Unsigned-Byte Fragment-Type А NM/TM 0…1 Это поле сигнализирует тип фрагмента Руководства по Услуге BCAST, кодированного в XML, с помощью следующих значений:
0 - неопределено
1 - фрагмент 'Услуга'
2 - фрагмент 'Контент'
3 - фрагмент 'График'
4 - фрагмент 'Доступ'
5 - фрагмент 'Пункт Покупки'
6 - фрагмент 'Данные Покупки'
7- фрагмент 'Канал Покупки'
8 - фрагмент 'Предварительный Просмотр Данных'
9 - фрагмент 'Интерактивные Данные'
10-127 зарезервированы для BCAST расширения
128-255 доступны для закрытого расширения
Этот атрибут ДОЛЖЕН присутствовать в случае, когда 'fragmentEncoding'=0.
По умолчанию: 0 Unsigned-Byte Preview-Data-Reference Е1 NM/TM 0…N Ссылка на фрагмент 'PreviewData', который описывает данные предварительного просмотра (например, картинку, видео клип или поток с низкой скоростью), связанные с этим доступом. Может присутствовать более одного экземпляров PreviewDataReference, связанных с одним и тем же фрагментом, в этом случае значения атрибутов "usage" этих экземпляров PreviewDataReference ДОЛЖНЫ быть разными.
Содержит следующие атрибуты:
idRef
usage   idRef А NM/TM 1 Идентификация фрагмента 'PreviewData', с которым связан этот фрагмент. anyURI usage А NM/TM 1 Описывает использование связанных данных предварительного просмотра.
Возможные значения:
0. неопределено
1. Переключение Услуга-за-Услугой
2. Просмотр файлов Руководства по Услуге
3. Предварительный Просмотр Услуги
4. Крупный Заголовок
5. Альтернатива для прекращения связи
6-127. зарезервированы для будущего использования
128-255. зарезервированы для закрытого использования
Пояснения и ограничения на использование вышеуказанных данных предварительного просмотра определены в секции 5.7 Unsigned-Byte Notifica-tion-Reception Е1 NM/TM 0…1 Информация о приеме для характерных для услуги сообщений Извещение.
В случае доставки по каналу широковещательной рассылки, 'IPBroadcastDelivery' описывает адресную информацию для приема сообщения Извещение. В случае доставки по интерактивному каналу, 'RequestURL' описывает адресную информацию для описания извещения, 'TollURL' описывает адресную информацию для извещения о проведении опроса.
Если этот элемент присутствует, то по меньшей мере должен присутствовать один из следующих элементов: "IPBroadcastDelivery", "RequestURL" или "PollURL".
Содержит следующие элементы:
IPBroadcastDelivery
RequestURL
PollURL   IP-Broadcast-Delivery Е2 NM/TM 0…1 Предоставляет IP-групповой адрес и номер порта для приема сообщения Извещение по каналу широковещательной рассылки. 'Порт' является ОБЯЗАТЕЛЬНЫМ и для сети и для терминала, поскольку назначенный UDP Порт должен использоваться для доставки сообщения Извещение через активный в настоящий момент сеанс или назначенный сеанс, в то время как 'Адрес' является НЕОБЯЗАТЕЛЬНЫМ для использования для доставки сообщений Извещение через назначенный групповой сеанс или сеанс широковещательной рассылки. В случае не предоставления атрибута 'Адрес' ОБЯЗАТЕЛЬНО присваиваемый адрес места назначения предоставляется путем получения доступа к фрагменту.
Содержит атрибуты:
port
address   port А NM/TM 1 Номер порта UDP места назначения Доставки характерного для услуги сообщения Извещение, доставка по каналу широковещательной рассылки unsignedInt address А NM/TM 0…1 IP адрес групповой доставки характерного для услуги сообщения Извещение, доставка по каналу широковещательной рассылки string RequestURL Е2 NM/TM 0…1 URL, по которому терминал может подписаться на характерные для услуги сообщения Извещение anyURI PollURL Е2 NM/TM 0…1 URL, по которому терминал может проголосовать за характерные для услуги сообщения Извещение anyURI PrivateExt Е1 NO/TO 0…1 Элемент, служащий в качестве контейнера для закрытых или характерных для приложения расширений   <proprie-tary elements> Е2 NO/TO 0…N Закрытые или характерные для приложения элементы, которые не определены в этом описании. Эти элементы могут дополнительно содержать подэлементы или атрибуты  

На этапе 411 терминал получает автономный SG или дополнительный SG, формирует SG и отображает его пользователю.

Согласно настоящему изобретению 'BSMSelector', 'ServiceIDRef и 'ServiceGuideDeliveryUnit' определены в виде подэлементов ReferredSGInfo в таблице 7. Другая предварительная информация об автономном SG или дополнительном SG может дополнительно предоставляться путем использования подэлементов ReferredSGInfo.

Использование подэлементов ReferredSGInfo описано ниже.

Подэлемент BSMSelector определяет провайдера услуг, который предоставляет автономный SG или дополнительный SG. Провайдер услуг может быть идентифицирован Идентификатором (IDentifier, ID) BSMSelector путем использования idREF или другого имени, которое пользователь может идентифицировать. В первом случае терминал проверяет BSMList, определенный в SGDD, используемый для получения базового SG, ищет информацию BSMSelector, совпадающую с idRef в BSMList, и приобретает информацию, такую как BSM код, соответствующий провайдеру услуг или имени провайдера услуг, которое пользователь может идентифицировать. После получения автономного SG или дополнительного SG терминал может классифицировать и управлять SG на основе кода или имени провайдера услуг, используя эту информацию. Или базовый SG может предоставлять информацию пользователю таким образом, чтобы пользователь мог выборочно получать SG. Эта информация может быть предоставлена в виде опознаваемого пользователем имени непосредственно пользователю с помощью 'SPName', а также в виде ID с помощью idRef.

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

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

Фиг.7 представляет собой блок-схему BCAST системы сети для предоставления BCAST услуги и BCAST терминала согласно иллюстративному варианту осуществления настоящего изобретения.

Согласно фиг.7 система 710 BCAST сети может включать следующие объекты: создатель 101 контента, приложение 104 BCAST услуги, дистрибьютор/адаптер 108 BCAST услуги и менеджер 113 BSCAST подписки, показанные на фиг.1. Что касается SG, система 710 BCAST сети включает в себя генератор 711 источника SG, генератор 712 SG и передатчик 713 SG.

Генератор 711 источника SG может включать в себя объекты SGCCS 102, SGAS 105 и SGSS 114, показанные на фиг.1, и предоставляет базовую информацию об услугах и программах для генерации SG.

Генератор 712 SG получает информацию о генерации SG от генератора 711 источника SG и генерирует SG, используя эту информацию о генерации SG. Генератор 712 SG может включать в себя объекты SG-G 109 и SG-A 111, показанные на фиг.1. Генератор 712 SG также генерирует фрагменты SG и определяет перекрестные ссылки между этими фрагментами. По существу, генератор 712 SG определяет перекрестные ссылки между фрагментами для базового SG, автономного SG и дополнительного SG согласно иллюстративному варианту осуществления настоящего изобретения.

Передатчик 713 SG может включать в себя объекты SG-D 110. Передатчик 713 SG отвечает за передачу SG, сгенерированного из генератора 712 SG. В частности, передатчик 713 SG формирует сеансы доставки для переноса базового SG и автономного в дополнительный SG для фрагментов, сгенерированных генератором 712 SG, и передает фрагменты в сеансах доставки в иллюстративном варианте осуществления настоящего изобретения.

BDS 720 представляет собой систему, которая предоставляет каналы широковещательной рассылки, включая систему 721 широковещательной передачи, которая может представлять собой DVB-H, 3GPP MBMS, 3GPP2 BCMCS и т.п.

BCAST терминал 730 соответствует терминалу 119 на фиг.1. Согласно иллюстративному варианту осуществления настоящего изобретения BCAST терминал 730 получает, интерпретирует и отображает SG. BCAST терминал 730 может включать в себя приемник 731 данных широковещательной рассылки для приема данных широковещательной рассылки, приемник 732 SG для приема SG, интерпретатор 733 SG для интерпретации SG и дисплей 734 SG для отображения SG на дисплее 735.

Приемник 732 SG, интерпретатор 733 SG и дисплей 734 SG выполняют функции SG-C 120, показанного на фиг1. Более конкретно, приемник 732 SG получает базовый SG, интерпретатор 733 SG интерпретирует фрагменты базового SG, а дисплей 734 SG отображает результат интерпретации на дисплее 735 для пользователя в иллюстративном варианте осуществления настоящего изобретения. Когда пользователь выбирает запланированную услугу, BCAST терминал 730 приобретает информацию о выбранной услуге путем проверки связанного фрагмента Доступ в базовом SG, получения фрагмента Доступ через приемник 731 данных широковещательной рассылки и приемник 732 SG и интерпретации его с помощью интерпретатора 733 SG. Затем BCAST терминал 730 отображает приобретенную информацию на дисплее 735.

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

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

Изобретение относится к мобильной широковещательной системе, поддерживающей услугу широковещательной рассылки (Broadcast Service, BCAST), и в частности, к способу и устройству для предоставления другого Руководства по Услуге (Service Guide, SG) посредством базового SG в мобильной широковещательной системе. Техническим результатом является эффективное предоставление услуги и возможности приема дополнительной информации о базовом SG или другом независимом SG, использующем базовое SG в мобильной широковещательной системе. Указанный технический результат достигается тем, что предложен способ и устройство для предоставления SG в мобильной широковещательной системе, содержащее терминал для приема первого SG, приобретения информации о приеме второго SG из первого SG, если список фрагментов услуги из первого SG включает информацию о по меньшей мере одном втором SG, отличающемся от первого SG, и приема второго SG на основе приобретенной информации о приеме. 4 н. и 15 з.п. ф-лы., 7 ил., 7 табл.

1. Способ приема Руководства по Услуге (Service Guide, SG) в терминале в мобильной широковещательной системе, включающий в себя этапы, на которых:
принимают первое SG, содержащее, по меньшей мере, один из фрагментов услуги и, по меньшей мере, один из фрагментов доступа;
получают, если тип услуги, по меньшей мере, одного из фрагментов услуги, извлеченных из первого SG, установлен равным SG, информацию о приеме второго SG из, по меньшей мере, одного из фрагментов доступа первого SG; и
принимают второе SG на основе полученной информации о приеме, причем упомянутые, по меньшей мере один из фрагментов доступа, ассоциированы с, по меньшей мере, одним из фрагментов услуги.

2. Способ по п.1, в котором прием первого SG содержит: получение доступа к сеансу оповещения и прием Дескриптора Доставки Руководства по Услуге (Service Guide Delivery Descriptor, SGDD) в сеансе оповещения; получение информации о сеансе доставки, несущем первое SG, посредством интерпретации SGDD; получение доступа к сеансу доставки и прием Модуля Доставки Руководства по Услуге (Service Guide Delivery Unit, SGDU) для первого SG в упомянутом сеансе доставки; извлечение фрагментов первого SG из принятого SGDU; формирование первого SG путем использования извлеченных фрагментов; и отображение первого SG.

3. Способ по п.1, в котором информация о приеме второго SG содержит информацию о сеансе доставки, несущем второе SG.

4. Способ по п.3, в котором прием второго SG содержит: получение доступа к сеансу доставки, несущему второе SG, и прием SGDU для второго SG в сеансе доставки; извлечение фрагментов второго SG из SGDU для второго SG; формирование второго SG путем использования извлеченных фрагментов; и отображение второго SG.

5. Способ по п.3, в котором информация о приеме второго SG дополнительно содержит, по меньшей мере, одно из: информации о провайдере услуг, который предоставляет второе SG, отношения между вторым SG и первым SG, и отношения между вторым SG и SGDU для второго SG.

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

7. Способ по п.6, в котором передача первого SG содержит: предоставление терминалу Дескриптора Доставки Руководства по Услуге (SGDD), когда терминал получает доступ к сеансу оповещения; и предоставление терминалу Модуля Доставки Руководства по Услуге (SGDU) для первого SG, когда терминал получает доступ к сеансу доставки, несущему первое SG, путем интерпретации SGDD.

8. Способ по п.6, в котором информация о приеме второго SG содержит информацию о сеансе доставки, несущем второе SG.

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

10. Устройство для приема Руководства по Услуге (SG) в терминале в мобильной широковещательной системе, содержащее:
приемник данных широковещательной рассылки для приема данных широковещательной рассылки;
приемник SG для получения первого SG, содержащего, по меньшей мере, один из фрагментов услуги и, по меньшей мере, один
из фрагментов доступа, и, по меньшей мере, одного второго SG из данных широковещательной рассылки;
интерпретатор SG для интерпретации первого SG и получения, если тип услуги, по меньшей мере, одного из фрагментов услуги, извлеченных из первого SG, установлен равным SG, информации о приеме второго SG из, по меньшей мере, одного из фрагментов доступа первого SG; и
дисплей SG для отображения, по меньшей мере, одного из: полученного первого SG и второго SG,
причем упомянутые, по меньшей мере, один из фрагментов доступа ассоциированы с, по меньшей мере, одним из фрагментов услуги.

11. Устройство по п.10, в котором приемник SG принимает Дескриптор Доставки Руководства по Услуге (SGDD) в сеансе оповещения, когда терминал получает доступ к сеансу оповещения, и интерпретатор SG получает информацию о сеансе доставки, несущем первое SG, путем интерпретации SGDD.

12. Устройство по п.11, в котором приемник SG получает доступ к сеансу доставки, несущему первое SG, и принимает Модуль Доставки Руководства по Услуге (SGDU) для первого SG в этом сеансе доставки, и интерпретатор SG извлекает фрагменты первого SG из принятого SGDU.

13. Устройство по п.10, в котором информация о приеме второго SG содержит информацию о сеансе доставки, несущем второе SG.

14. Устройство по п.13, в котором приемник SG получает доступ к сеансу доставки, несущему второе SG, и принимает SGDU для второго SG в этом сеансе доставки, и интерпретатор SG извлекает фрагменты второго SG из SGDU для второго SG.

15. Устройство по п.14, в котором информация о втором SG содержит по меньшей мере одно из: информации о провайдере услуг, предоставляющем второе SG, отношения между вторым SG и первым SG и отношения между вторым SG и SGDU для второго SG.

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

17. Устройство по п.16, в котором передатчик SG предоставляет терминалу Дескриптор Доставки Руководства по Услуге (SGDD), когда терминал получает доступ к сеансу оповещения, и предоставляет терминалу Модуль Доставки Руководства по Услуге (SGDU) для первого SG, когда терминал получает доступ к сеансу доставки, несущему первое SG, путем интерпретации SGDD.

18. Устройство по п.17, в котором информация о приеме второго SG содержит информацию о сеансе доставки, несущем второе SG.

19. Устройство по п.18, в котором информация о приеме второго SG дополнительно содержит по меньшей мере одно из: информации о провайдере услуг, предоставляющем второе SG, отношения между вторым SG и первым SG и отношения между вторым SG и SGDU для второго SG.