СПОСОБ И СИСТЕМА ДЛЯ ОБЕСПЕЧЕНИЯ СООБЩЕНИЯ ИЗВЕЩЕНИЯ В СИСТЕМЕ МОБИЛЬНОГО ВЕЩАНИЯ Российский патент 2010 года по МПК H04B7/26 H04N7/173 

Область техники, к которой относится изобретение

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

Уровень техники

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

Открытый мобильный альянс (Open Mobile Alliance) (OMA), т.е. группа, собранная для изучения стандарта для взаимодействия между отдельными мобильными решениями, взял на себя ответственность за установление различных прикладных стандартов для мобильных игр, служб Интернета и т.п. В частности, OMA Browser and Content (BAC) Mobile Broadcast (BCAST) Sub Working Group, один из рабочих коллективов OMA, исследует технологию, которая обеспечивает широковещательные услуги с использованием мобильных терминалов. Ниже будет приведено краткое описание системы мобильного вещания, обсуждаемой в OMA BCAST Working Group.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

фиг.5A-5D - подробные варианты осуществления руководства по обслуживанию, включающего в себя значение Notification в системе мобильного вещания согласно первому варианту осуществления настоящего изобретения;

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

фиг.7 - процесс генерации и запрашивания события извещения в системе мобильного вещания согласно первому варианту осуществления настоящего изобретения;

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

фиг.9A - пример фрагмента «доступ» в системе мобильного вещания согласно первому варианту осуществления настоящего изобретения;

фиг.9B - тип доступа во фрагменте «доступ» в системе мобильного вещания согласно первому варианту осуществления настоящего изобретения;

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

фиг.11 - архитектура доставки электронного руководства по обслуживанию (ESG) на основе CBMS в системе мобильного вещания согласно второму варианту осуществления настоящего изобретения;

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

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

фиг.14 - сигнализация между сетевыми объектами в системе мобильного вещания согласно второму варианту осуществления настоящего изобретения;

фиг.15A-15D - фрагменты модели данных ESG на основе CBMS в системе мобильного вещания согласно второму варианту осуществления настоящего изобретения; и

фиг.16 - модуль данных ESG на основе CBMS в системе мобильного вещания согласно второму варианту осуществления настоящего изобретения.

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

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

Настоящее изобретение предусматривает способ и систему для управления сообщением извещения в системе мобильного вещания, поддерживающей канал взаимодействия. Здесь будет описано несколько вариантов осуществления системы мобильного вещания согласно настоящему изобретению. Также будет описан способ доставки сообщения извещения согласно настоящему изобретению. В первом варианте осуществления будет описана широковещательная система, заданная в 3^rd Generation Partnership Project (3GPP), который является стандартом асинхронной мобильной связи, или заданный в Открытом мобильном альянсе (OMA), который является группой стандартов приложений для терминала, и во втором варианте осуществления будет описана система Digital Video Broadcasting-Convergence of Broadcasting and Mobile Service (DVB-CBMS), которая является другой группой стандартов мобильного вещания. Первый вариант осуществления настоящего изобретения будет описан со ссылкой на архитектуру и термины, используемые в OMA, и архитектура и термины, используемые во втором варианте осуществления, будут сопоставлены с архитектурой и терминами системы мобильного вещания согласно первому варианту осуществления.

Для лучшего понимания сообщения извещения опишем систему мобильного вещания согласно первому варианту осуществления. Хотя в первом варианте осуществления будут использоваться сущности и имена, заданные в OMA-BCAST, их установленный стандарт и имена сущностей не призваны ограничивать объем настоящего изобретения, и настоящее изобретение можно применять к любой системе, имеющей сходную техническую основу.

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

Хотя описание настоящего изобретения приведено здесь, в порядке примера, со ссылкой на технологию OMA-BCAST, которая является одной из стандартных технологий мобильного вещания, описание не призвано ограничивать настоящее изобретение.

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

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

Согласно фиг.1, создание контента [Content Creation] (CC) 101 является поставщиком широковещательных услуг (услуги BCAST), и услуга BCAST может включать в себя традиционную услугу вещания аудио/видео, услугу загрузки файлов музыки/данных и т.п. Благодаря использованию источника создания контента руководства по обслуживанию [Service Guide Content Creation Source] (SGCCS) 102 CC 101 доставляет информацию контента, необходимую для генерации руководства по обслуживанию для услуги BCAST, информацию возможностей мобильного терминала, профиль пользователя, информацию времени контента и т.п. на источник приложения руководства по обслуживанию [Service Guide Application Source] (SGAS) 105 приложения услуги BCAST [BCAST Service Application] (BSA) 104 через интерфейс SGI 103 согласно Таблице 1.

BSA 104 управляет переработкой данных услуги BCAST, поступающих из CC 101 в формат, пригодный для сети BCAST. Кроме того, BSA 104 управляет генерацией стандартизованных метаданных, необходимых для руководства по мобильному вещанию. SGAS 105 доставляет различные источники, необходимые для генерации руководства по обслуживанию, например информацию конкретной услуги/контента, информацию планирования, информацию местоположения и т.д., включая информацию, поступающую из SGCCS 102 для генерации руководства по обслуживанию [Service Guide Generation] (SG-G) 109 в распространении/адаптации услуги BCAST [BCAST Service Distribution/Adaptation] (BSD/A) 108 через интерфейс SG2 106.

BSD/A 108 управляет установлением однонаправленного канала, по которому он будет доставлять данные услуги BCAST, поступающие из BSA 104, определением расписания доставки услуги BCAST и генерацией информации руководства по мобильному вещанию. BSD/A 108 подключен к системе распространения вещания [Broadcast Distribution System] (BDS) 131 для доставки данных услуги BCAST по широковещательному каналу и к интерактивной сети [Interaction Network] (IN) 133 для поддержания интерактивной связи по каналу взаимодействия.

Руководство по обслуживанию, сгенерированное из SG-G 109, доставляется на мобильный терминал (терминал) 119 через распространение SG [SG Distribution] (SG-D) 110 и интерфейс SG5 117.

Управление подпиской BCAST [BCAST Subscription Management] (BSM) 113 управляет информацией подписки и информацией по предоставлению услуг для получения услуги BCAST и информацией устройства для мобильного терминала, получающего услугу BCAST. Источник подписки руководства по обслуживанию [Service Guide Subscription Source] (SGSS) 114 в BSM 113 доставляет источники подписки/предоставления, относящиеся к генерации руководства по обслуживанию, и источники, например информацию приобретения и информацию продвижения, на SG-G 109 для генерации руководства по обслуживанию через интерфейс SG4 112.

Терминал 119 это терминал, способный принимать услугу BCAST и имеющий функцию, способную обеспечивать подключение к сотовой сети согласно возможностям терминала. Терминал 119, имеющий клиент руководства по обслуживанию [Service Guide Client] (SG-C) 120, принимает руководство по обслуживанию, доставляемое через интерфейс SG5 117, или принимает сообщение извещения, доставляемое через интерфейс SG6 118, и осуществляет операцию, необходимую для получения услуги BCAST.

В таблицах 2-4 приведены определения функций для основных составных элементов, показанных на фиг.1, заданных в стандарте OMA BCAST.

Таблица 2 Логические сущности Определение Создание контента В создании контента источник создания контента руководства по обслуживанию (SGCCS) может обеспечивать атрибуты контента, например информацию описания контента, возможности терминала назначения, профиль пользователя назначения, информацию хронирования контента и т.д., и передает их по SGI в форме стандартизованных фрагментов руководства по обслуживанию BCAST, либо в особом формате. Приложение услуги BCAST В приложении услуги BCAST источник приложения руководства по обслуживанию (SGAS) обеспечивает информацию описания услуги/контента, информацию планирования, информацию местоположения, возможности терминала назначения, профиль пользователя назначения и т.д. и передает их по SG2 в форме стандартизованных фрагментов руководства по обслуживанию BCAST. Управление подпиской BCAST В управлении подпиской BCAST источник подписки руководства по обслуживанию (SGSS) обеспечивает информацию предоставления услуг, информацию приобретения, информацию подписки, информацию подписки, информацию продвижения и т.д. и передает их по SG4 в форме фрагментов руководства по обслуживанию.

Таблица 3 Логические сущности Определение Генерация руководства по обслуживанию (SG-G) Генерация руководства по обслуживанию (SG-G) в сети отвечает за получение фрагментов руководства по обслуживанию из различных источников, например SGCCS, SGAS, SGSS, по интерфейсам SG-2 и SG-4, SG-G собирает фрагменты, например информацию доступа к услугам и контенту, согласно стандартной схеме, и генерирует руководство по обслуживанию, которое поступает на распространение руководства по обслуживанию (SG-D) для передачи. До передачи, оно, в необязательном порядке, адаптируется в функции адаптации руководства по обслуживанию (SG-A) для адаптации к конкретной BDS. Функция клиента руководства по обслуживанию (SG-G) Функция клиента руководства по обслуживанию (SG-C) на терминале отвечает за получение информации руководства по обслуживанию от нижележащей BDS и предоставление мобильному терминалу доступа к руководству по обслуживанию. SG-C получает информацию о конкретном руководстве по обслуживанию, может фильтровать ее для согласования с критериями, установленными на терминале (например, местоположением, профилем пользователя, возможностями терминала), или просто получает всю доступную информацию руководства по обслуживанию. В общем случае пользователь может просматривать информацию руководства по обслуживанию в виде меню, списка или таблицы. SG-C может посылать запрос в сеть через SG-t для получения информации о конкретном руководстве по обслуживанию или всего руководства по обслуживанию.

Таблица 4 Логические сущности Определение Распространение SG (SG-D SG-D генерирует поток IP для передачи руководства по обслуживанию по интерфейсу SG5 и широковещательному каналу на SG-C. До передачи SG-G может передавать руководство по обслуживанию на адаптацию руководства по обслуживанию (SG-A) для адаптации руководства по обслуживанию к конкретной BDS согласно атрибутам BDS, переданным распространением услуг BDS по SG-B1. Адаптация может приводить к модификации руководства по обслуживанию. Заметим, что, в целях адаптации, SG-A также может передавать атрибуты руководства по обслуживанию BCAST или фрагменты руководства по обслуживанию BCAST по SG-B1 на распространение услуг BDS для адаптации, причем эта адаптация в распространении услуг BDS находится вне объема BCAST, SG-D также может принимать запрос на информацию руководства по обслуживанию и передавать запрашиваемую информацию руководства по обслуживанию на терминал непосредственно по каналу взаимодействия. SG-D также может фильтровать информацию руководства по обслуживанию от SG-G на основании заранее заданных профилей конечных пользователей. SG-D также может передавать руководство по обслуживанию на BDS, которая модифицирует руководство по обслуживанию (например, добавляя информацию конкретной BDS), и дополнительно распространяет руководство по обслуживанию на SG-C в зависимости от конкретной BDS.

На фиг.2 показана архитектура извещения в системе мобильного вещания согласно первому варианту осуществления настоящего изобретения.

CC 101 является поставщиком широковещательных услуг (услуги BCAST). Услуга BCAST может включать в себя традиционную услугу вещания аудио/видео, услугу загрузки файлов музыки/данных и т.п. При наличии какой-либо проблемы или изменения в предоставлении услуги BCAST CC 101 извещает об этом изменении функцию событий извещения [Notification Event Function] (NTE) 201 в BSA 104.

BSA 104 управляет переработкой данных услуги BCAST, поступающих из CC 101 в формат, пригодный для сети BCAST, и генерацией стандартизованных метаданных, необходимых для руководства по мобильному вещанию. Кроме того, BSA 104 извещает об изменении в услуге BCAST, поступающей из CC 101, функцию генерации извещений (NTG) 203 в BSM 113.

BSD/A 108 управляет установлением однонаправленного канала, по которому он будет доставлять данные услуги BCAST, поступающие из BSA 104, определением расписания доставки услуги BCAST и генерацией информации руководства по мобильному вещанию и подключен к BDS 131 и IN 133. Кроме того, BSD/A 108, имеющий функцию распространения/адаптации извещений (NTDA) 202, принимает сообщение извещения от BSM 113 и доставляет сообщение извещения отдельному пользователю или множеству пользователей через BDS 131 или IN 133.

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

Терминал 119 - это терминал, способный принимать услугу BCAST, и имеющий функцию, способную обеспечивать подключение к сотовой сети согласно возможностям терминала. Благодаря использованию функции клиента извещения [Notification Client Function] (NTC) 204, Терминал 119 принимает сообщение извещения, доставленное через интерфейс NT5 214, и осуществляет соответствующую операцию согласно сообщению извещения NT5, или принимает сообщение извещения, доставленное через интерфейс NT6 215, и осуществляет соответствующую операцию согласно сообщению извещения NT6.

Интерфейс NT-1 211, интерфейс между NTE 201 в BSA 104 и CC 101 используется для доставки на NTE 201 события извещения, происходящего в CC 101.

Интерфейс NT-3 212, интерфейс от NTE 201 в BSA 104 к NTG 203 в BSM 113 переносит информацию, необходимую для генерации извещения о событии или сообщения извещения, чтобы NTG 203 мог генерировать сообщение извещения.

Интерфейс NT-4 213, интерфейс от NTG 203 в BSM 113 к NTDA 202 в BSD/A 108 используется для доставки сообщения извещения, сгенерированного в NTG 203, на NTDA 202 для дальнейшей доставки сообщения извещения на BDS 131 или IN 133, или для доставки события, происходящего в BSD/A 108 или BDS 131, на NTDA 202.

Интерфейс NT-5 214 - это интерфейс, используемый для непосредственной доставки сообщения извещения, поступающего из NTDA 202 в BSD/A 108, на терминал 119 через BDS 131 по широковещательному каналу. Интерфейс NT-5 214 используется для доставки сообщения извещения на совокупность терминалов.

Интерфейс NT-6 215 - это интерфейс, используемый для непосредственной доставки сообщения извещения, поступающего из NTDA 202 в BSD/A 108, на терминал 119 через IN 133. Интерфейс NT-6 215 используется для доставки сообщения извещения на отдельный терминал.

Интерфейс NT-B1 216 используется как путь доставки, подлежащий использованию в BDS 131 посредством BSD/A 108, или используется как путь получения информации события, сгенерированной в BDS 131. Интерфейс NT-B1 216 - это интерфейс между BSD/A 108 и распространением услуг BDS (BDS-SD) 130.

NTE 201 управляет доставкой информации, необходимой для генерации сообщения извещения, на NTG 203 и доставкой информации о генерации события извещения, если таковое существует, на NTG 203. NTG 203 управляет генерацией сообщения извещения с использованием информации и события, необходимых для генерации сообщения извещения, принятых от NTE 201, или генерацией сообщения извещения по получении события извещения от BDS 131 или IN 133 через NTDA 202, и доставкой сообщения извещения на NTDA 202. NTG 203 может генерировать сообщение извещения, (i) когда необходимо повторно известить о начале обслуживания, (ii) когда необходимо доставить новое руководство по мобильному вещанию, когда он принимает от CC 101a извещение, указывающее изменение в информации услуги, и (iii) когда конкретное событие произошло в BDS 131 или IN 133.

NTDA 202 управляет доставкой сообщения извещения через интерфейс NT-5 214 или интерфейс NT-6 215. Кроме того, по получении от BDS 131 информации, указывающей изменение в конкретной мобильной широковещательной услуге, например информации, указывающей регулирование скорости или невозможность обслуживания по причине условий в беспроводной сети, NTDA 202 доставляет соответствующее событие извещения на NTG 203 через интерфейс NT-4 213.

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

Согласно фиг.3, управление предоставлением широковещательной услуги [Broadcast Service Provisioning Management] (BSP-M) 301 обеспечивает информацию подписки и приобретения. На основании информации подписки пользователя BSP-M 301 обеспечивает информацию оплаты пользователя соответствующим сущностям и поддерживает оплату мобильной широковещательной услуги. BSP-M 301 принимает запрос и отчет для подписки и оплаты от клиента предоставления широковещательной услуги [Broadcast Service Provisioning Client] (BSP-C) 302 через интерфейс SP-7 311 и интерфейс SP-8 312. BSP-C 302 управляет генерацией отчета о подписке и приобретении мобильной широковещательной услуги. BSP-C 302 может запрашивать подписку и приобретение или запрашивать дополнительную информацию в зависимости от информации предоставления услуг, извлеченной из руководства по обслуживанию. Описание интерфейса SP-7 311 и интерфейса SP-8 312 показано в Таблице 5.

Таблица 5 Интерфейс Опорная точка Использование SP-7 BCAST-7 Доставка сообщений, используемых для подписки, например запроса на подписку пользователя и ответа от управления подпиской BCAST.
Доставка платежной информации SP-8 Вне диапазона Конечный пользователь подписывается на услуги и приобретает их через внеполосные интерфейсы. Это выходит за рамки объема OMA-BCAST.

Согласно Таблице 6 'Имя' указывает имена элементов и атрибутов, составляющих соответствующее сообщение. 'Тип' указывает тип (Element или Attribute) соответствующего имени. Элементы имеют значения E1, E2, E3 и E4. E1 указывает верхний элемент для всего сообщения, E2 указывает подэлемент E1, E3 указывает подэлемент E2 и E4 указывает подэлемент E3. Атрибут обозначается A, и A указывает атрибут соответствующего элемента. Например, A под E1 указывает атрибут E1. 'Категория' используется для определения, является ли соответствующий элемент или атрибут обязательным или необязательным, и имеет значение M для обязательного элемента или атрибута, и значение O для необязательного элемента или атрибута. 'Мощность' указывает соотношение между элементами, и имеет значения 0, 0..1, 1, 0..n, 1..n. Здесь 0 означает необязательное соотношение, 1 означает обязательное соотношение, и n означает, что можно использовать совокупность значений. Например, 0..n означает, что соответствующее сообщение может не иметь ни одного элемента или n элементов. 'Описание' указывает смысл соответствующего элемента или атрибута, и 'Тип данных' указывает тип данных для соответствующего элемента или атрибута.

Таблица 6 Имя Тип Категория Мощность Описание Тип данных            

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

Согласно фиг.4 SG-G 109 генерирует на этапе 401 руководство по обслуживанию включающее в себя информацию времени, приобретения и доступа, относящуюся к услуге и контенту, и затем передает запрос для доставки руководства по обслуживанию на SG-D 110. Затем SG-D 110 передает руководство по обслуживанию на терминал 119 на этапе 402. Руководство по обслуживанию может доставляться через BDS и/или IN по широковещательному каналу и/или каналу взаимодействия, соответственно. Когда руководство по обслуживанию доставляется по широковещательному каналу, терминал 119 принимает руководство по обслуживанию из сеанса, по которому доставляется руководство по обслуживанию, и когда руководство по обслуживанию доставляется по каналу взаимодействия, терминал 119 осуществляет доступ к IN и затем принимает руководство по обслуживанию в ответ на соответствующий запрос.

SG-C 120 на терминале 119 управляет получением руководства по обслуживанию от SG-D 110, и пользователь получает информацию услуги и контента из принятого руководства по обслуживанию. На основании руководства по обслуживанию пользователь определяет информацию подписки и приобретения для услуги, расписание, контент и т.д., после чего делает запрос на предоставление услуги, например подписку и приобретение с использованием BSP-C 302. Для получения сообщения извещения, связанного с услугой, BSP-C 302 передает запрос на подписку/отписку на BSP-M 301 на этапе 403.

По получении запроса на ID пользователя, ID устройства и информацию подписки на услугу/извещение BSP-M 301 сохраняет соответствующую пользовательскую информацию в DB 411 в BSM 113. Событие извещения может происходить в различных сетевых сущностях для обеспечения мобильной широковещательной услуги. Согласно фиг.4 событие извещения может происходить в CC 101, BSA 104, BSD/A 108 и BSM 113, и на этапах 404-406, CC 101, BSA 104 и BSD/A 108 передают запрос на генерацию сообщения извещения на NTG 203.

NTG 203 генерирует сообщение извещения для принятого события. После генерации сообщения извещения NTG 203 получает из DB 411 адрес назначения TargetAddress, по которому он будет доставлять сообщение извещения, и затем генерирует сообщение запроса для доставки сообщения. Если какой-либо пользователь подписался на услугу получения сообщений по каналу взаимодействия, NTG 203 генерирует сообщение запроса, включающее в себя информацию об адресе, по которому соответствующий пользователь может принимать сообщение.

NTG 203 передает запрос для доставки сообщения извещения на NTDA 202 на этапе 407. NTDA 202 доставляет сообщение извещения на NTC 204 на этапе 408. В этом случае NTDA 202 доставляет сообщение извещения по широковещательному каналу или каналу взаимодействия согласно адресу назначения.

Сообщение извещения можно грубо классифицировать на общее сообщение извещения для услуги извещения и сообщение извещения для конкретной услуги в качестве вспомогательного средства, связанного с услугой. Получив руководство по обслуживанию, терминал или пользователь может распознать общее сообщение извещения и/или сообщение извещения для конкретной услуги согласно следующей процедуре. Термин 'услуга извещения' означает услугу, состоящую из извещений. Например, услуга извещения - это услуга, которая доставляется посредством сообщений извещения службы коротких сообщений [Short Message Service] (SMS) или службы мультимедийных сообщений [Multimedia Messaging Service] (MMS) на ежедневной основе, например 'Погода на сегодня', 'Today's English' и т.д. Сообщение извещения для конкретной услуги в качестве вспомогательного средства является примером вспомогательной услуги для главной программы, а не независимой услуги извещения. Например, при проведении музыкального опроса службой 'Music Top 10' в прямом эфире SMS-сообщение извещения для опроса доставляется телезрителям для сбора опросной информации, сообщение извещения для опроса - это сообщение извещения для конкретной услуги в качестве вспомогательного средства. Услуга извещения - это услуга, состоящая только из извещений, и сообщение извещения для конкретной услуги - это сообщение извещения, которое может происходить в главной программе.

Что касается услуги извещения, когда тип услуги ServiceType во фрагменте Service («услуга») [Service Fragment] руководства по обслуживанию имеет значение Notification (извещение), терминал распознает, что соответствующая услуга является услугой извещения.

Что касается конкретной услуги, в которой доставляется сообщение извещения, терминал может распознать, что он может принимать сообщение извещения, относящееся к соответствующей услуге, (i) когда фрагмент Access («доступ»), относящийся к услуге, включает в себя элемент NotificationReception 904, (ii) когда элемент ServiceClass 903 во фрагменте Access («доступ»), относящемся к услуге, имеет значение URI, указывающее 'sdo.oma.nt' ли его аналогичное значение Notification, и (iii) при наличии элемента или атрибута соответствующего фрагмента, указывающего возможность приема сообщения извещения, например, NTviaInteraction во фрагменте Service («услуга») или фрагменте PurchaseItem.

На фиг.5A-5D показаны подробные варианты осуществления руководства по обслуживанию, включающего в себя значение Notification в системе мобильного вещания согласно первому варианту осуществления настоящего изобретения. Поскольку фрагмент Access («доступ») на фиг.5A и 5B подробно показаны на фиг.9A и 9B, будем ссылаться на них.

На фиг.5A показан пример фрагмента Access («доступ») 901, содержащего информацию NotificationReception («получение извещения»), и сообщение извещения, относящееся к соответствующей услуге, имеет информацию доступа извещения, доставленного по широковещательному каналу, включенную в элемент NotificationReception 904, и содержит информацию, относящуюся к соответствующей услуге, в элементе AccessType 902.

На фиг.5B показан пример, в котором доступы для услуги и сообщения извещения включены отдельно. Использование, на основании которого можно различить информацию соответствующего доступа, зависит от значения ServiceClass 903. Например, для услуги доставки файлов [File Delivery] AccessType 902 доступа с ServiceClass 903='sdo.oma.fd' содержит информацию доступа, доступную для загрузки файлов, и AccessType 902 доступа с ServiceClass 903='sdo.oma.nt' содержит информацию доступа для получения извещения.

На фиг.5C показана иллюстративная конфигурация услуги, состоящей только из сообщения извещения, в котором ServiceType фрагмента Service («услуга») равен Notification Service («услуга извещения»). Одно различие между фиг.5A и фиг.5C состоит в том, что фрагмент Access («доступ») содержит информацию адреса для получения сообщения извещения, а не NotificationReception, отдельно включенный во фрагмент Access («доступ»).

На фиг.5D показана иллюстративная конфигурация для случая, когда для подписки/приобретения услуги с конкретным расписанием соответствующая услуга включает в себя Notification («извещение»).

Как описано выше, терминал может распознать, что соответствующая услуга относится к извещению, когда ServiceType равен Notification Service, Access («доступ») включает в себя NotificationReception 904, или ServiceClass 903 для Access («доступа») равен sdo.oma.nt.

На фиг.6 показана подписка на сообщение извещения по каналу взаимодействия в системе мобильного вещания согласно первому варианту осуществления настоящего изобретения.

Согласно фиг.6 терминал 119 принимает руководство по обслуживанию на этапе 601. Затем, на этапе 602, терминал 119 проверяет, для полученного руководства по обслуживанию, контент извещения с использованием руководства по обслуживанию, описанного на фиг.5, определяет будет ли терминал 119 принимать извещение по каналу взаимодействия при подписке на услугу/приобретении услуги и затем определяет подписку на сообщение извещения.

Иллюстративное сообщение запроса на подписку для этого случая показано в Таблицах 7A-7C.

Таблица 7A Имя Тип Категория Мощность Описание Тип данных PR-7 Version E M 1 Версия интерфейса PR-7, поддерживаемая терминалом. Номер версии PR-7, описанной в этом описании, равен 1. Целое UserID E M 1 Идентификатор пользователя, известный для BSM. Строка DeviceID E M 1 Уникальный идентификатор устройства известный для BSM (например, международный идентификатор мобильного оборудования, IMEI). Строка RequestID E O 1 Идентификатор для сообщения запроса на услугу. Целое

Service Protection Protocol E O 1 Указывает каждый протокол защиты услуги, поддерживаемый устройством, включая обязательные. Заданные значения: "ipsec", "srtp". Устройство может включать в себя больше идентификаторов; однако, в зависимости от того, какие протоколы поддерживает сеть, их можно игнорировать. [Примечание] Этот элемент включается в сообщение, только если услуга доставляется по каналу взаимодействия. Строка Broadcast Mode E O 1 Указывает, поддерживает ли устройство необязательный режим вещания для операции получения прав помимо интерактивного режима работы. "да" или "нет"

Таблица 7B Имя Тип Категория Мощность Описание Тип данных BsdaID E M 1 Глобально скоординированный ID для BSD/A.
примечание: BSM использует этот ID для извлечения информации услуги из BSD/A. любой URI RiURL E O 1 URL эмитента прав, из которого BSM может извлечь триггеры ROAP**, которые будут доставлены на устройство. Любой URI PurchaseItem E M 1..N Список позиций, которые пользователь хочет заказать. Сложный тип ItemID E1 M 1 ID фрагмента PurchaseItem. ItemID рекламируются в руководстве по обслуживанию и вставляются в это сообщение в том же формате. Любой URI Order Option E1 O 1 Идентификатор варианта заказа. Возможные варианты заказа рекламируются в руководстве по обслуживанию. Строка Price E1 O 1 Цена, известная пользователю. Целое Currency A O 1 Валюта, в которой выражена цена. Если пропущен, используется настройка системы по умолчанию. Код валюты задан в [ISO4217] Строка

Таблица 7C Имя Тип Категория Мощность Описание Тип данных Authentication E O 1 Аутентификация сообщения двоичное число, закодированное в Base64 Notification E O 0..1 Подписка на получение сообщения извещения по каналу взаимодействия. Если Notification=TRUE, это означает подписку на извещение по каналу взаимодействия. Если Notification=FALSE, это означает, что извещение по каналу взаимодействия не доставляется. Логический

На этапе 603 терминал 119 передает запрос на подписку/приобретение сообщения извещения на BSP-M 301 с использованием BSP-C 302. Затем, на этапе 604, BSP-M 301 обрабатывает сообщение запроса на подписку и сохраняет соответствующую услугу и пользовательскую информацию. После обработки соответствующего события BSP-M 301 передает сообщение ответа на запрос на подписку на BSP-C 302 на этапе 605. Пример сообщения ответа показан в Таблице 8.

Таблица 8 Имя Тип Категория Мощность Описание Тип данных Global Status Code E M 1 Общий итог запроса, согласно кодам возврата, заданным в Таблице 2. Целое Rights Validity EndTime E O 0..N Время и дата истечения срока действия сообщения долгосрочного ключа, после которого его нужно обновить.
[Примечание] Этот элемент удостоверяется, при условии вещания RO. В противном случае, этот элемент не нужен. DateTime ID A M 1 ID фрагмента PurchaseItem, к которому относится время истечения срока действия. Любой URI RequestID E O 1 Идентификатор соответствующего сообщения запроса услуги. Целое

Authentication E O 1 Аутентификация сообщения
[Примечание] Способ аутентификации сообщения задан в 5.1.3 Двоичное число, закодированное в Base64 Trigger E M 1 Триггер получения RO ROAP**. Предполагается, что устройство использует триггер для инициирования одного или нескольких получений сообщения долгосрочного ключа. часть MIME

Если терминал 119 определяет на этапе 611 наличие отписки от сообщения извещения после получения услуги, BSP-C 302 передает запрос на отписку для подписки на услугу/приобретения услуги на BSP-M 301 на этапе 612. Пример сообщения запроса на отписку показан в Таблице 9.

Таблица 9 Имя Тип Категория Мощность Описание Тип данных PR-7 Version E M 1 Версия интерфейса PR-7, поддерживаемая терминалом. Номер версии PR-7, описанный в этом описании, равен 1 Целое UserID E M 1 Идентификатор пользователя, известный для BSM Строка DeviceID E O 0..N Уникальный идентификатор устройства известный для BSM (например, международный идентификатор мобильного оборудования, IMEI).
[Примечание] Если пользователь имеет несколько устройств, этот элемент указывает устройство или группу устройств, от которого/ой пользователь хочет отписаться Строка PurchaseItem ID E M 1..N ID фрагмента PurchaseItem, от которого пользователь хочет отписаться. Любой URI RequestID E O 1 Идентификатор сообщения запроса отписки. Целое Auhtentication E O 1 Аутентификация сообщения
[Примечание] Способ аутентификации сообщения задан в 5.1.3 Двоичное
число,
закодированное
в Base64 Notification E O 0..1 Подписка на получение сообщения извещения по каналу взаимодействия. Если Notification=TRUE, это означает отписку от извещения по каналу взаимодействия. Если Notification=FALSE, это означает, что извещение по каналу взаимодействия не доставляется. Логический

BSP-M 301 обрабатывает запрос на отписку на этапе 613, и затем передает сообщение ответа на BSP-C 302 на этапе 614. Пример сообщения ответа показан в Таблице 10.

Таблица 10 Имя Тип Категория Мощность Описание Тип данных Global Status Code E M 1 Общий итог запроса, согласно кодам возврата, заданным в Таблице 2. Целое Unsubscribe InfoMessage E M 1..N Для каждой успешно удаленной подписки, сообщение (в форме свободного текста) указывающее, когда отмена подписки вступит в силу. Строка PurchaseItemID A M 1 ID фрагмента PurchaseItem, к которому относится сообщение. Любой URI RequestID E O 1 Идентификатор соответствующего сообщения запроса отписки. Целое Authentication E O 1 Аутентификация сообщения Двоичное число, закодированное в Base64

На фиг.7 показан процесс генерации и запрашивания события извещения в системе мобильного вещания согласно первому варианту осуществления настоящего изобретения. Этот процесс демонстрирует последовательность операций, в котором NTG 203 принимает событие извещения, или генерирует сообщение для события извещения, происходящего в BSM 113, и передает запрос для доставки сообщения.

Согласно фиг.7, NTG 203 имеет событие извещения, произошедшее в BSM 113, или принимает событие извещения от другой сетевой сущности на этапе 701. В Таблице 11A и Таблице 11B показано сообщение запроса для генерации сообщения извещения от соответствующих сетевых сущностей (например, CC, BSA и BSD/A), для события извещения. Кроме того, в Таблице 12 показан пример сообщения ответа на соответствующее сообщение запроса.

Таблица 11A Имя Тип Категория Мощность Описание Тип данных NTEReq E     Задает сообщение доставки события извещения для генерации сообщения извещения. Содержит следующие атрибуты:
NTEId
EntityAddress
DeliveryPriority
Содержит следующие элементы:
NotificationEvent   NTEId A M 1 Идентификатор события извещения беззнаковое целое (32 бита) EntityAddress A M 1 Адрес сетевой сущности для приема ответа на это сообщение. Любой URI Delivery Priority A O 0..1 Задает приоритет этого события извещения. Эта информация применяется для генерации сообщения извещения в NTG. NTG может игнорироваться в этом поле Логический

Таблица 11B Имя Тип Категория Мощность Описание Тип данных NotificationEvent E1 M 1..N Задает событие извещения от CC, содержащее информацию от CC, подлежащую включению в сообщение извещения. РЕКОМЕНДУЕТСЯ, чтобы информация доставлялась в форме сообщения извещения в формате BCAST (заданном в Разделе 8.3). МОЖНО использовать другие форматы.
Если используется формат BCAST сообщения извещения, обязательные сетевые элементы или атрибуты, которые не релевантны, ДОЛЖНЫ доставляться как пустое поле, необязательные сетевые элементы или атрибуты, которые не релевантны, НЕ ДОЛЖНЫ быть представлены.
Содержит атрибут:
Namespace   Namespace A O 0..1 Задается равным имени пространства имен XML извещения BCAST для сигнализации, что контент NotificationEvent согласуется с форматом сообщения извещения BCAST. Любой URI

Таблица 12 Имя Тип Категория Мощность Описание Тип данных NTERes       Задает сообщение ответа для NTEReq.
Содержит следующие элементы:
NTEid   NTEid E1 M 1..N Идентификатор сообщения NTEReq
Содержит следующие атрибуты:
StatusCode беззнаковое целое (32 бита) StatusCode A M 1 Указывает общий итог обработки NTEReq, согласно глобальному коду статуса (заданному в Приложении G). беззнаковый байт

По наступлении события извещения или по поступлении события извещения от другой сетевой сущности NTG 203 генерирует сообщение извещения на этапе 702. Затем, на этапе 703, NTG 203 определяет, по какому пути он будет доставлять соответствующее сообщение извещения. Сообщение извещения может доставляться по широковещательному каналу и/или каналу взаимодействия. Когда NTG 203 определяет, что будет доставлять сообщение извещения по широковещательному каналу 710, NTG 203 проверяет на этапе 711 адрес назначения сеанса, по которому он будет доставлять соответствующее сообщение извещения. На этапе 712, NTG 203 генерирует на этапе 712 сообщение запроса на доставку для запрашивания доставки сообщения извещения, включающее в себя соответствующий TargetAddress, и передает запрос для доставки сообщения извещения на NTDA 202 на этапе 713.

Однако, если NTG 203 определяет, что будет доставлять сообщение извещения по каналу взаимодействия 720, NTG 203 проверяет на этапе 721 адрес назначения пользователя [Target User Address] для пользователя, который согласился/подписался на прием сообщения извещения по каналу взаимодействия. Затем, на этапе 722, NTG 203 генерирует сообщение запроса на доставку для запрашивания доставки сообщения извещения, включающее в себя TargetAddress каждого пользователя, относящийся к сообщению извещения. В этом случае, при наличии большого числа пользователей, NTG 203 может генерировать несколько сообщений запроса на доставку для одного и того же сообщения извещения. Затем, на этапе 723, NTG 203 передает соответствующее сообщение доставки извещения на NTDA 202.

На фиг.8 показан процесс, в котором NTDA 202 доставляет сообщение извещения на терминал по получении запроса доставки для сообщения извещения от NTG 203.

Согласно фиг.8, NTDA 202 принимает сообщение запроса на доставку для сообщения извещения на этапе 801. В таблицах 13A - 13C показан пример сообщения запроса на доставку для сообщения извещения, доставляемого из NTG 203 на NTDA 202. В Таблице 14 показан пример сообщения ответа на него.

Таблица 13A Имя Тип Категория Мощность Описание Тип данных NTDReq E     Задает сообщение запроса на доставку сообщения извещения от NTG на NTDA.
Содержит следующие атрибуты:
NTDReqid
EntityAddress
DeliveryPriority
Содержит следующие элементы:
TargetAddress
NotificationMessage   NTDReqid A M 1 Идентификатор NTDReq беззнаковое целое (32 бита) EntityAddress A M 1 Адрес сетевой сущности для приема ответа на это сообщение. Любой URI DeliveryPriority A 0 0..1 Задает приоритет доставки этого сообщения извещения. NTG может запрашивать у NTDA доставку этого сообщения извещения с высоким приоритетом. Если priority=TRUE, это означает высокий приоритет. Если priority=FALSE, это означает общее сообщение. Логический

Таблица 13B Имя Тип Категория Мощность Описание Тип данных TargetAddress E1 0 0..N Задает TargetAddress для доставки сообщения извещения.
Для извещения для конкретной услуги AccessID или IPAddress согласно NotificationReception в AccessFragment может иметь возможное значение.
Если сообщение извещения должно доставляться по каналу взаимодействия, значение может представлять собой адрес электронной почты, IMSI и т.д.
Если он не задан, сообщение извещения ДОЛЖНО доставляться всем пользователям с использованием SGDD.
Содержит следующие атрибуты:
DeliveryChannel
AddressType Строка DeliveryChannel A M 1 1 Задает канал доставки
Если DeliveryChannel=0, сообщение извещения ДОЛЖНО доставляться по широковещательному каналу.
Если DeliveryChannel=1, сообщение извещения ДОЛЖНО доставляться по каналу взаимодействия. Логический AddressType A M 1 Задает тип значения TargetAddress
0 - IP-адрес
2 - Любой URI
3 - IMSI
4 - 200: для использования в будущем
201-255: для специального использования беззнаковый байт

Таблица 13C Имя Тип Кате-
гория Мощ-
ность Описание Тип данных NotificationMessage E1 M 1..N Задает сообщение извещения, содержащее информацию, подлежащую включению в сообщение извещения. РЕКОМЕНДУЕТСЯ, чтобы информация доставлялась в форме сообщения извещения в формате BCAST (заданном в Разделе 8.3). МОЖНО использовать другие форматы.
Если используется формат BCAST сообщения извещения, обязательные сетевые элементы или атрибуты, которые не релевантны, ДОЛЖНЫ доставляться как пустое поле, необязательные сетевые элементы или атрибуты, которые не релевантны, НЕ ДОЛЖНЫ быть представлены.
Содержит следующий атрибут:
Namespace   Namespace A O 0..1 Задается равным имени пространства имен XML извещения BCAST для сигнализации, что контент NotificationEvent согласуется с форматом сообщения извещения BCAST. Любой URI

Таблица 14 Имя Тип Категория Мощ-
ность Описание Тип данных NTDRes       Задает сообщение ответа для NTDReq.
Содержит следующие элементы:
NTDReqid   NTDReqid E1 M 1..N Идентификатор сообщения NTDReq
Содержит следующие атрибуты:
StatusCode беззнаковое целое (32 бита) StatusCode A M 1 Указывает общий исход обработки NTDReq согласно глобальному коду статуса (заданному в Приложении G) беззнаковый байт

На этапе 802 NTDA 202 проверяет адрес назначения, включенный в сообщение запроса. Затем NTDA 202 определяет на этапе 803, будет ли использоваться широковещательный канал или канал взаимодействия для доставки сообщения, анализируя информацию TargetAddress. Если NTDA 202 определяет, что для доставки сообщения будет использоваться широковещательный канал 810, NTDA 202 проверяет на этапе 811 информацию сеанса, например IP-адрес из информации TargetAddress в сообщении запроса, и затем доставляет сообщение извещения в соответствующем сеансе.

Если же NTDA 202 определяет, что будет использоваться канал взаимодействия 820, NTDA 202 проверяет тип TargetAddress на этапе 821. Затем, на этапе 822, NTDA 202 определяет способ доставки согласно типу адреса назначения и затем доставляет сообщение извещения с использованием сообщения доставки.

В таблицах 15-17 показан иллюстративный способ подписки/отписки на/от сообщение/я извещения для каждой отдельной услуги в подписке на сообщения извещения, описанной на фиг.6.

Таблица 15 Имя Тип Категория Мощность Описание Тип данных ServiceID E 0 0..1 Уникальный ID услуги. Это может быть ID фрагмента Service («услуга») или GlobalServiceID
Содержит следующие атрибуты:
Notification Любой URI Notification A M 1 Подписка на получение сообщения извещения, относящегося к услуге, по каналу взаимодействия. Если Notification=TRUE, это означает подписку на извещение по каналу взаимодействия. Если Notification=FALSE, это означает, что извещение по каналу взаимодействия не доставляется. Логический

Таблица 16 Имя Тип Катего-рия Мощность Описание Тип данных ServiceID E O 0..1 Уникальный ID услуги. Это может быть ID фрагмента Service («услуга») или GlobalServiceID
Содержит следующие атрибуты:
Notification Любой URI Notification A M 1 Отписка от получения сообщения извещения по каналу взаимодействия. Если Notification=TRUE, это означает отписку от извещения по каналу взаимодействия. Если Notification=FALSE или значение отсутствует, это означает, что текущая подписка на сообщение извещения сохранится. Логический

Таблица 17 Имя Тип Катего-рия Мощность Описание Тип данных KeepSubscription A O 0..1 Сохраняет текущую подписку на PurchaseItem. Когда пользователь сохраняет текущую подписку на PurchaseItem и хочет отписаться от получения релевантного извещения по каналу взаимодействия, это поле необходимо задать равным TRUE. Если этот элемент отсутствует, или значение равно FALSE, это означает отписку от PurchaseItem и релевантного ему извещения. Логический

В Таблице 15 показано сообщение для случая, когда для подписки на PurchaseItem или пакет услуг [Service Bundle], получение сообщения извещения для конкретной услуги выбирается из услуг, включенных в соответствующий пакет. Элемент и связанный с ним атрибут в Таблице 15 доставляются с сообщением запроса в ходе подписки на услугу на этапе 603 согласно фиг.6. Если получение сообщения извещения для конкретного ServiceID желательно, атрибут Notification задается равным TRUE, и если получение сообщения извещения для конкретного ServiceID нежелательно, атрибут Notification задается равным FALSE.

В Таблице 16 показано сообщение для случая, когда производится отписка от получения сообщения извещения для конкретной услуги из услуг, включенных в PurchaseItem или Пакет услуг. Элемент и связанный с ним атрибут в Таблице 16 доставляются совместно с сообщением запроса в ходе отписки от услуги на этапе 612 согласно фиг.6. Если отписка от сообщения извещения для конкретного ServiceID желательна, атрибут Notification задается равным TRUE. Если атрибут Notification задан равным FALSE или атрибут Notification отсутствует, это означает, что пользователь сохраняет свою текущую подписку. Если пользователь запрашивает отписку от соответствующего PurchaseItem или Пакета услуг, производится отписка от каждой соответствующей услуги и получения сообщения извещения без необходимости выбора конкретной услуги согласно Таблице 16. Однако, если пользователь желает отписаться от сообщения извещения для конкретной услуги, но сохранить свою подписку на PurchaseItem или Пакет услуг, Таблица 16 и Таблица 17 включаются в сообщение отписки, и атрибут в Таблице 17 задается равным TRUE, и отписку от получения сообщения извещения можно выбрать для каждой отдельной услуги с использованием Таблицы 16.

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

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

С использованием позиций 1012 и 1014 пользователь определяет, обеспечивается ли сообщение извещения через Взаимодействие для каждой отдельной услуги. В этом варианте осуществления только спортивные каналы ESPN и SBS обеспечивают сообщение извещения через Взаимодействие. Если пользователь подписывается на услугу с использованием кнопки Подписка 1015, экран 1001 переключается на генерацию экрана 1002 сообщения подписки. Если пользователь желает принимать сообщение извещения через Взаимодействие в конкретной услуге, он выбирает этот вариант с помощью флажка 1024 и запрашивает подписку на услугу и релевантное сообщение извещения с использованием кнопки 1025, и соответствующая информация доставляется на BSM посредством сообщения подписки «предоставление услуги» [Service Provisioning], включающего в себя Таблицу 15, тем самым завершая подписку. Отписка осуществляется аналогичным способом.

Ниже будет приведено описание способа доставки сообщения извещения в системе Digital Video Broadcasting - Convergence of Broadcasting and Mobile Service (DVB-CBMS) согласно второму варианту осуществления настоящего изобретения.

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

На фиг.11 показана архитектура доставки электронного руководства по обслуживанию (ESG) на основе CBMS, которое ставится в соответствие архитектуре, показанной на фиг.1. Определение сетевых сущностей, используемых на фиг.11, приведено в Таблице 18. Из сущностей, показанных на фиг.11, 'Конкретный логический агрегатор ESG' - это важная сущность в настоящем изобретении и имеет объединенную функцию SG-D 110 и SG-G 109, показанных на фиг.1, т.е. управляет генерацией и доставкой ESG.

Таблица 18 Логическая подсущность Логическая сущность является частью Используемые опорные точки Описание Источник ESG приложения услуги CBMS-7, CBMS-2 Конкретный источник приложения услуги фрагментов ESG, содержащий информацию привлекательности, информацию получения (поступающую от подсущности конфигурации приложения услуги) и файлы SDP информации приобретения, которые являются частью информации получения, может доставляться отдельно от ESG. В этом случае приложение услуги может доставлять файлы SDP посредством опорной точки CBMS-2.

Информация приобретения ESG приложения услуги внутри SA Источник информации приобретения, участвующий в ESG. Приложение услуги может опираться на другие источники для получения этой информации. Конкретный логический агрегатор ESG управления услугой CBMS-7 CBMS-3 Объект, принимающий блоки информации ESG от одного или нескольких приложений услуги, агрегирующая их в один ESG (что воспринимается конечным пользователем) и генерирующая согласованный набор блоков информации ESG, включающих в себя контейнеры; блоки информации выводятся на физический агрегатор ESG.
Логический ESG агрегатор отвечает за версии контейнера управления.
Приложение услуги может участвовать в более чем одном логическом агрегаторе ESG. Самозагружаемый агрегатор ESG управления услугой CBMS-3 Объект, принимающий информацию уведомления ESG от всех конкретных агрегаторов и генерирующая самозагружаемый поток ESG. Предоставление и планирование ресурсов управления услугой CBMS-6 Используется здесь для конкретной конфигурации доставки ESG Сервер интерактивной доставки управления услугой CBMS-4 Обеспечивает двусторонний доступ (проталкивания или вытягивания) к ESG через интерактивную сеть Физический агрегатор ESG широковещатель-ной сети CBMS-3 Объект, принимающий блоки информации ESG (например, контейнеры) от одного или нескольких логических агрегаторов ESG, помещающий их в карусель(и) FLUTE и оптимизирующий отображение в пакеты DVB-H (например, во избежание фрагментации информации ESG по множественным пакетам) Менеджер ресурсов DVB-H Широковещатель-ной сети CBMS-6 См. описание в разделе конфигурации услуги Блок отображения IP в секцию Широковещатель-ной сети CBMS-6 Объект, отвечающий за инкапсуляцию IP-датаграмм в секции MPE DVB-H и генерацию секций MPE-FEC путем осуществления кодирования MPE-FEC. Обычно является частью IP- инкапсулятора. Обработчик описания услуги и контента терминала CBMS-3 Принимает и агрегирует частично или полностью блоки информации ESG, поддерживает их обновление и делает их доступными приложению ESG
Представление и взаимодействие с информацией ESG выходит за рамки объема данного описания

На фиг.12 показана архитектура, соответствующая архитектуре на основе OMA, показанной на фиг.2, показаны структуры сетевых сущностей для доставки сообщений извещения в CBMS.

Согласно фиг.12, создание контента (CC) 1201 является поставщиком широковещательных услуг, и широковещательная услуга может включать в себя традиционные услугу вещания аудио/видео, услугу загрузки файлов музыки/данных и т.п. При наличии какой-либо проблемы или изменения в предоставлении широковещательной услуги CC 1201 извещает об изменении функцию событий извещения (NEF) 1202a в приложении услуги (SA) 1202. NEF 1202a доставляет событие извещения на функцию генерации извещений (NGF) 1203a на основании принятого события.

SA 1202 управляет переработкой данных контента широковещательной услуги, поступающих из CC 1201, в формат (например, поток аудио/видео или загружаемый фильм), пригодный для широковещательной сети, для генерации данных широковещательной услуги, генерации стандартизованных метаданных, необходимых для руководства по обслуживанию, и генерации информации оплаты для пользователей. Кроме того, для изменения широковещательной услуги, поступающей из CC 1201, SA 1202 доставляет событие извещения на NGF 1203a в управлении услугой [Service Management] (SM) 1203 и выдает информацию атрибута руководства по обслуживанию, используемую для генерации сообщения извещения, на NGF 1203a.

SM 1203 управляет определением планирования доставки для широковещательной услуги, поступающей из SA 1202, и генерацией руководства по обслуживанию, и подключен к сети DVB-H 1206, поддерживающей широковещательный канал, и интерактивной сети 1207, поддерживающей канал взаимодействия. Кроме того, SM 1203, имеющее функцию распространения/адаптации извещений (NDAF) 1203b, принимает сообщение извещения, доставленное от SM 1203, и доставляет сообщение извещения на один терминал или группу терминалов через широковещательную сеть 1206 или интерактивную сеть 1207. SM 1203 имеет информацию сеанса, которая нужна NGF 1203a для генерации сообщения извещения для терминала. Информация сеанса поступает из NDAF 1203b на NGF 1203a.

SM 1203 управляет информацией подписки для получения широковещательной услуги и информацией по предоставлению услуг, например информацией, указывающей, приобрел ли пользователь релевантный контент, а также управляет информацией устройства для терминалов, получающих широковещательную услугу. Кроме того, SM 1203 доставляет пользователю информацию оплаты на SA 1202 и выдает информацию подписки, информацию по предоставлению услуг и информацию устройства в широковещательную сеть 1206 и интерактивную сеть 1207. В частности, SM 1203, поскольку оно включает в себя NGF 1203a, генерирует сообщение извещения для события извещения, указывающее наличие, если таковое существует, добавления новой функции или изменения существующей функции, поступающее из создания контента 101, SA 1202, SM 1203 и широковещательной сети 1206, или генерирует сообщение извещения для самого события, указывающее, что широковещательная услуга обеспечивает контент, т.е. соответствующая широковещательная услуга будет предоставлена по истечении заранее определенного времени.

Широковещательная сеть 1206 - это сеть для доставки широковещательной услуги. Здесь, в порядке примера, сеть DVB-H используется в качестве широковещательной сети 1206. При наличии какого-либо изменения в доставке широковещательной услуги, широковещательная сеть 1206 управляет извещением об изменении для SM 1203 через интерфейс CBMS-6 1224a или интерфейс X-3 1224b.

Интерактивная сеть 1207 доставляет широковещательную услугу на двусторонней основе или интерактивно обменивается информацией управления и дополнительной информацией, относящейся к получению широковещательной услуги. Например, интерактивная сеть 1207 может представлять собой существующую сотовую сеть, например сеть широкополосного множественного доступа с кодовым разделением 3GPP (WCDMA).

Терминал 1208 - это терминал, способный принимать широковещательную услугу и имеющий функцию, способную обеспечивать подключение к сотовой сети согласно возможностям терминала. Предполагается, что терминал 1208 - это терминал, который может подключаться к сотовой сети. Благодаря использованию функции клиента извещения (NCF) 1208a терминал 1208 принимает сообщение извещения, доставленное через интерфейс CBMS-5 1225, и осуществляет соответствующие действия, или принимает сообщение извещения, доставленное через интерфейс CBMS-4 1226, и осуществляет соответствующие действия.

Интерфейс CBMS-7 1222 - это интерфейс от NEF 1202a в SA 1202 к NGF 1203a в SM 1203, который переносит информацию (например, информацию атрибутов руководства по обслуживанию), необходимую для генерации извещения о событии или сообщения извещения, чтобы NGF 1203a мог генерировать сообщение извещения.

Интерфейс CBMS-3 1225 - это интерфейс, используемый, когда сообщение извещения, доставляемое из NDAF 1203b в SM 1203, непосредственно доставляется на терминал 1208 через широковещательную сеть 1206 по широковещательному каналу. Этот интерфейс используется для доставки сообщения извещения на один или несколько терминалов.

Интерфейс CBMS-4 1226 - это интерфейс, используемый, когда сообщение извещения, доставляемое из NDAF 1203b в SM 1203, непосредственно доставляется на терминал 1208 через интерактивную сеть 1207 по выделенному каналу на терминал 1208 или по широковещательному каналу, обеспеченному в интерактивной сети 1207. Этот интерфейс используется для доставки сообщения извещения на один или несколько терминалов.

Интерфейс CBMS-6 1224a - это интерфейс между SM 1203 и широковещательной сетью 1206, используемый для установления пути доставки, используемого SM 1203 в широковещательной сети 1206 или пути получения информации события, сгенерированной в широковещательной сети 1206.

Интерфейс X-3 1224b - это интерфейс, используемый для установления пути доставки, используемого между SM 1203 и интерактивной сетью 1207.

Интерфейс CBMS-1 1233 - это интерфейс, через который информация управления широковещательной сети 1206 поступает на терминал 1208. В DVB-H, канал сигнала управления, именуемый Информация конкретной программы/Информация услуги [Program Specific Information/Service Information] (PSI/SI), соответствует этому интерфейсу.

NEF 1202a управляет доставкой информации, необходимой для генерации сообщения извещения, на NGF 1203a и доставкой информации, указывающей наступление, если таковое существует, события извещения на NGF 1203a. NGF 1203a управляет генерацией сообщения извещения с использованием информации и события, необходимых для генерации сообщения извещения, принятых от NEF 1202a, или генерацией сообщения извещения по получении события извещения от широковещательной сети 1206 через NDAF 1203b и доставкой сообщения извещения на NDAF 1203b. NGF 1203a может генерировать сообщение извещения, (i) когда необходимо повторно известить о начале обслуживания, (ii) когда необходимо доставить новое руководство по обслуживанию, когда она принимает от CC 1201 извещение, указывающее изменение в информации услуги, и (iii) когда конкретное событие произошло в широковещательной сети 1206.

NDAF 1203b управляет доставкой сообщения извещения через интерфейс CBMS-3 1225 или интерфейс CBMS-4 1226. Кроме того, по получении из широковещательной сети 1206 информации, указывающей изменение в конкретной мобильной широковещательной услуге, например информации, указывающей регулирование скорости или невозможность обслуживания по причине условий в беспроводной сети, NDAF 1203b доставляет соответствующее событие извещения на NGF 1203a.

По сравнению с объектами, показанными на фиг.2, сетевые объекты, соответствующие сообщению извещения, идентичны тем, которые заданы в OMA и CBMS в терминах определения и имен, поэтому их описание здесь не приведено. Что касается интерфейсов, NT-6 соответствует CBMS-4, и NT-5 соответствует CBMS-3.

На фиг.13 показана архитектура приобретения услуги на основе CBMS, соответствующая архитектуре на основе OMA, показанной на фиг.3. Описание сущностей, показанных на фиг.13, приведено в Таблице 19.

Таблица 19 Логический подобъект Логический объект является частью Используемые опорные точки Описание Источник кодированного потока приложения услуги CBMS-2 Объект, выводящий мультимедийные потоки (например, аудио, видео, данные) в широковещательные сети с использованием параметров конфигурации, полученных от подобъекта конфигурации приложения услуги Шифрование контента приложения услуги CBMS-2 Объект, отвечающий за шифрование потока контента. Шифрование контента и шифрование линии связи не обязательно использовать одновременно. Шифрование линии связи широковещательной сети CBMS-2 Объект, отвечающий за шифрование потока данных на канальном уровне. Этот тип шифрования не зависит от контента услуги. Шифрование контента и шифрование линии связи не обязательно использовать одновременно. Генерация ключей трафика и генерация ECM/KSM приложения услуги или широковещательной сети CBMS-2 Этот объект генерирует ключи шифрования трафика для трафика контента или линии связи, соответственно. TEK часто изменяются. Генерация ключей услуги/
программы приложения услуги или широковещательной сети CBMS-7 Этот объект генерирует ключи для доступа к услуге/программе. Им управляет подобъект управления критериями/политикой доступа для управления услугой. Ключи услуги/программы обмениваются с подобъектом выдачи прав в Управлении услугой. IP в секцию широковещательной сети   См. таблицу 5. Управление критериями/
политикой доступа управления услугой CBMS-7, CBMS-6 Этот объект может задавать услуги, программы и их сроки службы, какие пакеты мультимедийных потоков они содержат, и критерии доступа к контенту. Он также может задавать приобретаемые позиции, например пакеты услуг. Выдача прав управления услугой CBMS-3, CBMS-4, CBMS-6, CBMS-7 Этот объект предоставляет сообщения прав для доставки на агент системы управления ключами терминала. Этому процессу могут требоваться критерии доступа, ключи к услугам/программам и результат успешной транзакции приобретения. Последняя осуществляется под управлением подобъекта управления подпиской.

Управление подпиской управления услугой X-5 (необяз.) Этот объект определяет особенности подписки каждого конечного пользователя. Он может использовать функцию тарификации интерактивной сети по опорной точке X-5 или другим независимо действующим системам тарификации. Однако эта функция тарификации выходит за рамки объема этого описания. Обеспечение/
планирование ресурсов управления услугой   См. таблицу 3. Используется здесь для конфигурации доставки KSM Дешифрования контента/услуги Терминала CBMS-2 Этот объект дешифрует трафик контента/линии связи с помощью TEK, обеспечиваемых агентом системы управления ключами Агент системы управления ключами Терминала CBMS-2, CBMS-3, CBMS-4 Этот объект принимает сообщения прав и сообщения потока ключей и управляет ими. Если все критерии предоставления права выполняются, TEK реконструируется и поступает на объект дешифрования контента/услуги. Потребление контента терминала CBMS-2 Объект, обрабатывающий принятый мультимедийный поток; он может включать в себя средства буферизации, синхронизации, сохранения и представления потока контент.

Из объектов, представленных на фиг.13 и в Таблице 19, объекты, необходимые для настоящего изобретения, включают в себя объект 'Subscription Management' (управление подпиской), объект 'Rights issuing' (выдача прав) и объект 'Key management system agent' (Агент системы управления ключами) на терминале.

Функции объекта 'Управление подпиской' и объекта 'Выдача прав' отображаются в функцию BSP-M 301, показанного на фиг.3, и функции объекта 'Агент системы управления ключами' отображаются в функцию BSP-C 302, показанного на фиг.3.

На фиг.14 показана архитектура, соответствующая архитектуре на основе OMA, показанной на фиг.4. Показаны процедуры сигнализации, соответствующие процедурам сигнализации 402, 403, 405 и 408 между сетевыми сущностями, описанными на фиг.4. Таким образом, позиции 1450, 1460, 1470 и 1440 соответствуют позициям 402, 408, 403 и 405 на фиг.4.

На фиг.15A-15D показаны фрагменты модели данных ESG на основе CBMS, соответствующие показанным на фиг.5A-5D. Однако фрагмент, соответствующий фрагменту PurchaseItem, здесь опущен, поскольку он не относится к настоящему изобретению. Фрагмент Service ('услуга') и фрагмент Acqvisition ('получение') соответствуют фрагменту Service ('услуга') и фрагменту Access ('Доступ') на фиг.5A-5D, соответственно.

Что касается элементов и атрибутов в фрагментах, 'ServiceType' соответствует 'ServiceType', 'AccessType' соответствует 'SessionDescription', 'ServiceClass' соответствует 'ComponentCharacteristic' и 'NotificationReception' соответствует 'NotificationReception'. Таким образом, согласно фиг.15A-15D 'NotificationService' можно задать как тип ServiceType в 'ServiceType'. Поскольку информация доступа для доступа к сообщению извещения содержится в 'AccessType', согласно фиг.5A-5D соответствующая информация доступа выражается в 'SessionDescription'. Наподобие 'ServiceClass', указывающего класс услуги для сообщения извещения, NotificationComponentType, помимо видео, аудио и файла, задается с использованием элемента 'ComponentCharacteristicType', что указывает, что тип компонента для соответствующего фрагмента «получение» является сообщением извещения.

В Таблице 20A показана иллюстративная схема XML для вновь заданного NotificationComponentType, и она имеет элемент NotificationType.

Таблица 20A    

Также возможна конфигурация, показанная в Таблице 20B. В Таблице 20B NotificationType задан как элемент NotificationComponentType, и можно использовать множественные типы NotificationType. Кроме того, можно добавлять другие элементы, способные задавать NotificationComponent. "esg: ComponentCharacteristicType" в Таблице 20B - это часть, указывающая характеристику основного компонента, заданного в современном техническом описании DVB-CBMS ESG (ETSITS 102 471), и это используется так, как используется в существующих VideoComponentType или AudioComponentType.

Таблица 20 В    

В Таблице 21A показан пример сообщения запроса на подписку сообщения извещения, пригодного для сети CBMS согласно настоящему изобретению, которое отображается в сообщение в Таблице 7. Таблица 21B включает в себя вариант осуществления, который предусматривает подписку для конкретного ServiceID в Таблице 15. В Таблице 21 части, выделенные наклонным шрифтом, добавлены для запроса на подписку на сообщения извещения.

Таблица 21А  
  Таблица 21 В  
 

В Таблице 22 показан пример сообщения запроса на отписку от сообщения извещения и результат, полученный путем отображения сообщений отписки из Таблицы 9, Таблицы 16 и Таблицы 17 в сеть CBMS. Согласно Таблице 22B можно по отдельности отписываться от запрашиваемого сообщения извещения для каждого отдельного ServiceID. Когда не требуется отписка для конкретного ServiceID, вариант осуществления может предусматривать отписку от всего извещения для PurchaseItem, как показано в Таблице 22A. Кроме того, при отписке от общей услуги пользователь может не хотеть отписываться от сообщения извещения, относящегося к услуге. В этом случае, как показано в Таблице 22C, даже при отписке от главной услуги, благодаря использованию атрибута 'KeepSubscription', пользователь может не отписываться от сообщения извещения, обеспеченного в связи с главной услугой.

Таблица 22A    

Таблица 22B  
 

Таблица 22C  
 

Фиг.7 и 8 используются даже в варианте осуществления на основе CBMS, поэтому их подробное описание будет опущено.

На фиг.16 показана модель данных ESG на основе CBMS, которой ставится в соответствие модель данных ESG на основе OMA, показанная на фиг.9, и показаны элементы модели данных ESG, описанные на фиг.15. Согласно фиг.16 следует заметить, что 'NotificationComponentType' 1603 вновь задан для указания фрагмента Acqvisition («получение») для сообщения извещения в Component Characteristic (характеристике компонента).

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

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

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

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

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

3. Способ по п.1, в котором на этапе (b)
проверяют адрес назначения сеанса для широковещательного канала на основании адреса назначения, если сообщение извещения доставляют с использованием широковещательного канала, и
доставляют сообщение извещения на терминал по широковещательному каналу согласно адресу назначения сеанса.

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

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

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

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

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

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

10. Передатчик по п.9, в котором объект для определения канала проверяет тип адреса терминала на основании адреса назначения, если сообщение извещения доставляется с использованием канала взаимодействия, и
доставляет сообщение извещения на терминал по каналу взаимодействия согласно типу адреса.

11. Передатчик по п.9, в котором объект для определения канала проверяет адрес назначения сеанса для широковещательного канала на основании адреса назначения, если сообщение извещения доставляется с использованием широковещательного канала, и
доставляет сообщение извещения на терминал по широковещательному каналу согласно адресу назначения сеанса.

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

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

14. Передатчик по п.9, в котором объект для управления информацией подписки
по получении от конкретного терминала сообщения для запрашивания отписки от сообщения извещения для всех услуг отменяет подписку на доставку сообщения извещения для всех услуг для терминала.

15. Передатчик по п.9, в котором объект для управления информацией подписки по получении от терминала сообщения для запрашивания отписки от сообщения извещения для конкретной услуги отменяет подписку на доставку сообщения извещения для услуги, в отношении которой подан запрос на отписку.

16. Передатчик по п.9, в котором адрес назначения включает в себя информацию канала для доставки сообщения извещения и тип адреса на основании канала доставки для каждого терминала.

17. Передатчик по п.9, в котором объект для управления информацией подписки представляет собой функцию генерации извещений (NTG) и второе средство представляет собой функцию распространения/адаптации извещений (NTDA).

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

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

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

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

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

23. Терминал по п.22, в котором сообщение запроса на подписку для сообщения извещения включает в себя информацию идентификации услуги, и информацию подписки и приобретения сообщения извещения для услуги.

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

25. Терминал по п.22, в котором первый объект доставляет сообщение для запрашивания отписки от сообщения извещения для конкретной услуги на объект, который управляет информацией подписки.

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

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