СПОСОБ И УСТРОЙСТВО ДЛЯ ПРЕДОСТАВЛЕНИЯ СООБЩЕНИЯ ОПОВЕЩЕНИЯ В СИСТЕМЕ ШИРОКОВЕЩАТЕЛЬНОЙ ПЕРЕДАЧИ
METHOD AND DEVICE TO OUTPUT WARNING MESSAGE IN BROADCASTING TRANSMISSION SYSTEM

Область техники, к которой относится изобретение
Настоящее изобретение, в общем, относится к системе широковещательной передачи, поддерживающей услуги широковещательной передачи. Более конкретно настоящее изобретение относится к способу и устройству для предоставления сообщения оповещения в системе широковещательной передачи, поддерживающей мобильные услуги широковещательной передачи.
Уровень техники
Мобильная система широковещательной передачи включает в себя несколько процессов, в том числе: обнаружение услуги терминалом, выполненного с возможностью осуществлять прием мобильных услуг широковещательной передачи; подписку на услугу терминалом; предоставление различной управляющей информации для приема услуги; передача услуги и прием услуги терминалом. В процессе приема мобильных услуг широковещательной передачи от мобильной системы широковещательной передачи терминал принимает сообщение оповещения, содержащее различную управляющую информацию для услуги широковещательной передачи.
Пример такой мобильной системы широковещательной передачи подробно раскрывается в Патентной заявке (Корея) номер 2005-16650, зарегистрированной заявителем, которая полностью содержится в данном документе по ссылке. В этой системе широковещательной передачи изменения могут возникать вследствие различных причин, в то время когда терминал принимает широковещательную передачу. Некоторыми из изменений может быть информация, о которой должен быть оповещен терминал. Например, информация изменений может включать в себя изменение времени мобильной услуги широковещательной передачи и изменение информации для приема мобильной услуги широковещательной передачи.
Раскрытая система широковещательной передачи представляет архитектуру мобильных широковещательных оповещений. Тем не менее, терминал, допускающий прием мобильной услуги широковещательной передачи, не может принимать сообщение оповещения, поскольку нет определения базовой информации для приема сообщения оповещения, а также фактической передачи/приема сообщения оповещения. Следовательно, есть необходимость в определении этих конкретных элементов информации.
Раскрытие изобретения
Примерные варианты осуществления настоящего изобретения разрешают, по меньшей мере, вышеописанные проблемы и/или недостатки и предоставляют, по меньшей мере, преимущества, описанные ниже. Соответственно, аспект настоящего изобретения заключается в том, чтобы предоставить систему и способ для передачи управляющего сообщения в системе широковещательной передачи, поддерживающей мобильную услугу широковещательной передачи.
Другой аспект примерного варианта осуществления настоящего изобретения заключается в том, чтобы предоставить систему и способ для формирования и передачи сообщения оповещения в терминал при обслуживании в системе широковещательной передачи, поддерживающей мобильные услуги широковещательной передачи.
Дополнительный другой аспект примерного варианта осуществления настоящего изобретения заключается в том, чтобы предоставить устройство и способ для передачи сообщения оповещения в терминал, который находится в режиме ожидания или осуществляет доступ к другой системе взаимодействия в системе широковещательной передачи, поддерживающей мобильные услуги широковещательной передачи.
Согласно одному аспекту примерного варианта осуществления настоящего изобретения предусмотрен способ предоставления услуг широковещательной передачи в передающем устройстве системы широковещательной передачи на основе Интернет-протокола (IP). Способ содержит этапы: (a) передачи первой информации доступа, включающей в себя первый сетевой адрес, для передачи сообщения общего оповещения в приемное устройство широковещательной передачи, которое принимает услугу широковещательной передачи, и второй информации доступа, ассоциативно связанной с управлением системой широковещательной передачи, в приемное устройство широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия; и (b) формирования сообщения общего оповещения и передачи сформированного сообщения общего оповещения в приемное устройство широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия с помощью первого сетевого адреса, если возникает событие общего оповещения.
Согласно другому аспекту примерного варианта осуществления настоящего изобретения предусмотрено передающее устройство системы широковещательной передачи на основе Интернет-протокола (IP). Передающее устройство содержит первое средство для передачи первой информации доступа, включающей в себя первый сетевой адрес для передачи сообщения общего оповещения, и второй информации доступа, ассоциативно связанной с управлением системой широковещательной передачи, посредством одного из сети широковещательной передачи и сети взаимодействия; и второе средство для формирования, если возникает событие общего оповещения, сообщения общего оповещения и передачи сформированного сообщения общего оповещения посредством одного из сети широковещательной передачи и сети взаимодействия с помощью первого сетевого адреса.
Согласно дополнительному аспекту примерного варианта осуществления настоящего изобретения предусмотрен способ приема услуг широковещательной передачи в приемном устройстве широковещательной передачи системы широковещательной передачи на основе Интернет-протокола (IP). Способ содержит этапы (a) приема первой информации доступа, включающей в себя первый сетевой адрес, для приема сообщения общего оповещения, и второй информации доступа, ассоциативно связанной с управлением системой широковещательной передачи, от передающего устройства широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия; и (b) приема сообщения общего оповещения на основе первого сетевого адреса в данных, принимаемых от передающего устройства широковещательной передачи.
Согласно еще одному другому аспекту примерного варианта осуществления настоящего изобретения предусмотрено приемное устройство широковещательной передачи системы широковещательной передачи на основе Интернет-протокола (IP). Приемное устройство широковещательной передачи содержит первое средство для приема первой информации доступа, включающей в себя первый сетевой адрес, для приема сообщения общего оповещения, и второй информации доступа, ассоциативно связанной с управлением системой широковещательной передачи, от передающего устройства широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия; и второе средство для приема сообщения общего оповещения на основе первого сетевого адреса в данных, принимаемых от передающего устройства широковещательной передачи.
Согласно еще одному другому аспекту примерного варианта осуществления настоящего изобретения предусмотрен способ предоставления услуг широковещательной передачи в системе широковещательной передачи на основе сети, использующей Интернет-протокол (IP). Способ содержит этапы: (a) передачи, посредством передающего устройства широковещательной передачи, первой информации доступа, включающей в себя первый сетевой адрес, для передачи сообщения общего оповещения в приемное устройство широковещательной передачи, и второй информации доступа, ассоциативно связанной с управлением системой широковещательной передачи, в приемное устройство широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия; (b) если возникает событие общего оповещения, формирования сообщения общего оповещения и передачи сформированного сообщения общего оповещения в приемное устройство широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия с помощью первого сетевого адреса; и (c) приема сообщения общего оповещения на основе первого сетевого адреса в данных, принимаемых от передающего устройства широковещательной передачи.
Согласно еще одному другому аспекту примерного варианта осуществления настоящего изобретения предусмотрена система широковещательной передачи на основе сети, использующей Интернет-протокол (IP). Система широковещательной передачи содержит передающее устройство широковещательной передачи для предварительной передачи первой информации доступа, включающей в себя первый сетевой адрес, для передачи сообщения общего оповещения, и второй информации доступа, ассоциативно связанной с управлением системой широковещательной передачи, в приемное устройство широковещательной передачи, и если возникает событие общего оповещения, формирования сообщения общего оповещения и передачи сформированного сообщения общего оповещения в приемное устройство широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия с помощью первого сетевого адреса; и приемное устройство широковещательной передачи для приема сообщения общего оповещения на основе первого сетевого адреса в данных, принимаемых от передающего устройства широковещательной передачи.
Согласно еще одному другому аспекту примерного варианта осуществления настоящего изобретения предусмотрен машиночитаемый носитель записи, хранящий программу для реализации способа предоставления услуг широковещательной передачи в приемном устройстве системы широковещательной передачи на основе Интернет-протокола (IP). Способ включает в себя этап (a) передачи первой информации доступа, включающей в себя первый сетевой адрес, для передачи сообщения общего оповещения в приемное устройство широковещательной передачи, которое принимает услугу широковещательной передачи, и второй информации доступа, ассоциативно связанной с управлением системой широковещательной передачи, в приемное устройство широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия. Дополнительно способ включает в себя этап (b) формирования сообщения общего оповещения и передачи сформированного сообщения общего оповещения в приемное устройство широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия с помощью первого сетевого адреса, если возникает событие общего оповещения.
Согласно еще одному другому аспекту примерного варианта осуществления настоящего изобретения предусмотрен машиночитаемый носитель записи, хранящий программу для реализации способа приема услуг широковещательной передачи в передающем устройстве широковещательной передачи системы широковещательной передачи на основе Интернет-протокола (IP). Способ включает в себя этап (a) приема первой информации доступа, включающей в себя первый сетевой адрес, для приема сообщения общего оповещения, и второй информации доступа, ассоциативно связанной с управлением системой широковещательной передачи, от передающего устройства широковещательной передачи посредством одного из сети широковещательной передачи и сети взаимодействия. Дополнительно способ включает в себя этап (b) приема сообщения общего оповещения на основе первого сетевого адреса в данных, принимаемых от передающего устройства широковещательной передачи.
Другие аспекты, преимущества и выраженные признаки изобретения должны стать очевидными специалистам в данной области техники из последующего подробного описания, которое при рассмотрении вместе с прилагаемыми чертежами раскрывает примерные варианты осуществления изобретения.
Краткое описание чертежей
Вышеуказанные и другие цели, признаки и преимущества конкретных вариантов осуществления настоящего изобретения должны стать более понятными из последующего подробного описания, рассматриваемого вместе с прилагаемыми чертежами, из которых:
Фиг. 1 - схема, иллюстрирующая функциональную архитектуру для передачи сообщения оповещения в мобильной системе широковещательной передачи согласно первому примерному варианту осуществления настоящего изобретения;
Фиг. 2 - блок-схема последовательности операций, иллюстрирующая способ формирования и передачи SGDD согласно примерному варианту осуществления настоящего изобретения;
Фиг. 3 - блок-схема последовательности операций, иллюстрирующая способ приема SGDD терминалом в мобильной системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения;
Фиг. 4 - блок-схема, иллюстрирующая систему широковещательной передачи для передачи сообщения общего оповещения в мобильной системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения;
Фиг. 5 - блок-схема, иллюстрирующая процесс передачи сообщения общего оповещения в мобильной системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения;
Фиг. 6 - блок-схема, иллюстрирующая процесс приема сообщения общего оповещения в клиентской функции оповещения мобильной системы широковещательной передачи согласно примерному варианту осуществления настоящего изобретения;
Фиг. 7 - блок-схема, иллюстрирующая процесс приема сообщения общего оповещения в клиентской функции оповещения, когда она соединена с сетью взаимодействия или системой, имеющей терминал в режиме ожидания, мобильной системы широковещательной передачи согласно примерному варианту осуществления настоящего изобретения;
Фиг. 8 - схема, иллюстрирующая архитектуру модели данных в руководстве по услугам, предлагаемом для мобильной широковещательной передачи в OMA BAC BCAST, одной из стандартных групп для технологии мобильной широковещательной передачи;
Фиг. 9 - блок-схема, иллюстрирующая способ формирования и передачи фрагмента доступа в мобильной системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения;
Фиг. 10 - блок-схема, иллюстрирующая способ приема и обработки фрагмента доступа в терминале мобильной системы широковещательной передачи согласно примерному варианту осуществления настоящего изобретения;
Фиг. 11 - схема, иллюстрирующая архитектуру сети цифрового видеовещания-сходимости услуг широковещательной и мобильной передачи (DVB-CBMS) согласно второму примерному варианту осуществления настоящего изобретения;
Фиг. 12 - схема, иллюстрирующая модель данных электронного руководства по услугам (ESG) в DVB-CBMS согласно второму примерному варианту осуществления настоящего изобретения;
Фиг. 13 - это схема, иллюстрирующая операцию доставки ESG в DVB-CBMS согласно второму примерному варианту осуществления настоящего изобретения;
Фиг. 14 - блок-схема, иллюстрирующая схематичный процесс передачи/приема сообщения оповещения согласно второму примерному варианту осуществления настоящего изобретения;
Фиг. 15 - блок-схема, иллюстрирующая операцию формирования и доставки дескриптора самонастройки ESG в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения;
Фиг. 16 - блок-схема, иллюстрирующая операцию приема информации канала сообщения оповещения в дескрипторе самонастройки ESG терминалом в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения;
Фиг. 17 - блок-схема, иллюстрирующая операцию формирования и доставки информации канала сообщения оповещения в фрагменте ESG Acquisition в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения;
Фиг. 18 - блок-схема, иллюстрирующая операцию приема информации канала сообщения оповещения в фрагменте ESG Acquisition терминалом в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения;
Фиг. 19 - блок-схема, иллюстрирующая операцию доставки сообщения общего оповещения в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения;
Фиг. 20 - блок-схема, иллюстрирующая операцию приема сообщения оповещения посредством клиентской функции оповещения терминала в мобильной системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения; и
Фиг. 21 - блок-схема, иллюстрирующая процесс приема сообщения оповещения в клиентской функции оповещения терминала, когда она соединена с сетью взаимодействия в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
На всех чертежах одинаковые номера ссылок чертежей должны пониматься так, чтобы обозначать одинаковые элементы, признаки и структуры.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
Аспекты, указываемые в описании, такие как подробная структура и элементы, предоставляются для того, чтобы помочь в исчерпывающем понимании вариантов осуществления настоящего изобретения, и являются просто примерными. Следовательно, специалисты в данной области техники должны признавать, что различные изменения и модификации вариантов осуществления, описанных в данном документе, могут выполняться без отступления от области применения и духа изобретения. Помимо этого, описания хорошо известных функций и конструкций опущены для ясности и краткости.
Примерный вариант осуществления настоящего изобретения включает в себя устройство и способ для формирования и передачи сообщения оповещения в терминал, принимающий мобильную услугу широковещательной передачи, когда связанные с услугой/системой изменения возникают в системе широковещательной передачи, поддерживающей мобильную услугу широковещательной передачи, или есть необходимость оповестить о чрезвычайной ситуации. Помимо этого, примерный вариант осуществления настоящего изобретения предоставляет способ, допускающий доставку сообщения оповещения независимо от того, принимает или нет терминал услугу. В нижеследующем описании система мобильной связи, поддерживающая мобильную услугу широковещательной передачи, упоминается как "мобильная система широковещательной передачи".
Для понятности и краткости после того как представляется примерный вариант осуществления мобильной системы широковещательной передачи, описывается формат сообщения оповещения согласно примерным вариантам осуществления настоящего изобретения и мобильная система широковещательной передачи, к которой применяется формат сообщения. Затем приводится описание устройства и способа для формирования и передачи сообщения оповещения в мобильной системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения. Первый примерный вариант осуществления описывается со ссылкой на систему широковещательной передачи, заданную в Партнерском проекте третьего поколения (3GPP), который является группой стандартизации для асинхронной мобильной связи, или Открытом альянсе мобильной связи (OMA), который является группой стандартизации терминальных приложений. Второй примерный вариант осуществления описывается со ссылкой на систему цифрового видеовещания-сходимости услуг широковещательной и мобильной передачи (DVB-CBMS), заданную другой группой стандартов для мобильной широковещательной передачи.
Ниже приводится описание мобильной системы широковещательной передачи согласно первому примерному варианту осуществления, чтобы предоставить понимание сообщения оповещения. Хотя названия объектов, используемых в мобильной системе широковещательной передачи OMA, применяются в первом примерном варианте осуществления, использование имен и стандарт OMA не должны ограничивать область применения примерных вариантов осуществления настоящего изобретения, и первый примерный вариант осуществления может быть применен к любой системе, имеющей аналогичный уровень техники.
Фиг. 1 - это схема, иллюстрирующая функциональную архитектуру для передачи сообщения оповещения в мобильной системе широковещательной передачи согласно первому примерному варианту осуществления настоящего изобретения. Система, показанная на фиг. 1, задается рабочей группой по широковещательной передаче и просмотру мобильного содержимого Открытого альянса мобильной связи (OMA BAC BCAST) одной из групп стандартизации для мобильных широковещательных терминалов. Хотя примерный вариант осуществления настоящего изобретения описывается со ссылкой на архитектуру широковещательных оповещений OMA BCAST, он также может быть применен к другой мобильной системе широковещательной передачи, имеющей функцию передачи сообщений оповещения, из широковещательных систем на основе Интернет-протокола (IP), и этот примерный вариант осуществления не ограничивает область применения примерного варианта осуществления настоящего изобретения. Помимо этого, примерный вариант осуществления использует "руководство по услугам" в качестве информации, включающей в себя, например, описание, связанное с приемом услуги широковещательной передачи, и способ приема BCAST-системы. Также применяется "фрагмент доступа" в качестве информации, включающей в себя способ доступа к услуге широковещательной передачи. Термины "руководство по услугам" и "фрагмент доступа" могут быть заданы как различные термины согласно типу системы широковещательной передачи.
Ссылаясь на фиг. 1, блок 101 создания содержимого - это поставщик услуги широковещательной передачи (далее упоминаемой как BCAST-услуга). BCAST-услуга может включать в себя традиционную аудио/видеовещательную услугу, услугу загрузки файлов (музыкальных файлов или файлов с данными) и т.п. Если есть какие-либо проблемы при предоставлении BCAST-услуги или какие-либо изменения в содержимом услуги, блок 101 создания содержимого оповещает об изменении в функцию оповещаемого событий (NTE) 102-1 в приложении 102 BCAST-услуги.
Приложение 102 BCAST-услуги имеет функцию приема данных для BCAST-услуги, предоставляемой от блока 101 создания содержимого, обработки принимаемых данных в форме, подходящей для сети широковещательной передачи, и формирования данных BCAST-услуги. Приложение 102 BCAST-услуги также имеет функцию формирования стандартизированных метаданных, необходимых для управления мобильной широковещательной передачей. Помимо этого, приложение 102 BCAST-услуги принимает изменение в BCAST-услуги, сообщенное блоком 101 создания содержимого, и оповещает об изменении в функцию 104-1 формирования оповещений, размещенную в блоке 104 управления BCAST-подпиской.
Блок 103 распространения/адаптации BCAST-услуги имеет функцию установления однонаправленного канала для передачи данных BCAST-услуги, предоставляемых от приложения 102 BCAST-услуги, функцию определения расписания передачи для BCAST-услуги, и функцию формирования руководства по мобильной широковещательной передаче. Блок 103 распространения/адаптации BCAST-услуги соединен с системой широковещательной передачи распространения (BDS) 106, допускающей предоставление BCAST-услуги, или сетью 107 взаимодействия, поддерживающей связь взаимодействия. Помимо этого, блок 103 распространения/адаптации BCAST-услуги, включающий в себя функцию распространения/адаптации оповещений (NTDA) 103-1, принимает сообщение оповещения от блока 104 управления BCAST-подпиской и передает сообщение оповещения одному или множеству пользователей посредством BDS 106 или сети 107 взаимодействия.
Блок 104 управления BCAST-подпиской управляет информацией подписки для приема BCAST-услуги, информацией предоставления услуги и информацией устройства для устройства, принимающего BCAST-услугу. В частности, блок 104 управления BCAST-подпиской, поскольку он включает в себя функцию 104-1 формирования оповещений, формирует сообщение оповещения с помощью информации событий для оповещения, принимаемой от блока 101 создания содержимого или BDS 106, либо формирует сообщение оповещения для события BCAST-услуги.
Блок 105 распространения BDS-услуг имеет функцию распространения всех принимаемых BCAST-услуг через канал широковещательной передачи или канал взаимодействия. Блок 105 распространения BDS-услуг - это объект, который может присутствовать либо отсутствовать согласно типу реализованной BDS 106.
BDS 106 - это сеть для передачи BCAST-услуг, и ей может быть, например, DVB-H, услуга широковещательной и многоадресной передачи (MBMS) 3GPP, 3GPP2-услуга широковещательной и многоадресной передачи (BCMCS) и т.п. Помимо этого, в случае если есть изменение в передаче конкретной BCAST-услуги, если X-1-интерфейс 131 или блок 105 распространения BDS-услуг существует, BDS 106 оповещает об изменении в блок 103 распространения/адаптации BCAST-услуг посредством NT-B1-интерфейса 124.
Сеть 107 взаимодействия передает BCAST-услуги на основе "от точки к точке" либо интерактивно обменивается управляющей информацией и дополнительной информацией, связанной с приемом BCAST-услуг, и может быть, например, существующей сотовой сетью.
Терминал 108 допускает прием BCAST-услуги и может иметь функцию осуществления доступа к сотовой сети согласно своим характеристикам. Здесь предполагается, что терминал 108 - это терминал, допускающий осуществление доступа к сотовой сети. Терминал 108 принимает сообщение оповещения, передаваемое посредством NT-5-интерфейса 125 с помощью клиентской функции оповещения (NTC) 108-1, и выполняет соответствующую операцию согласно принимаемому сообщению оповещения. Альтернативно терминал 108 принимает сообщение оповещения, передаваемое посредством NT-6-интерфейса 126, и выполняет соответствующую операцию согласно принимаемому сообщению оповещения.
Далее приводится описание интерфейсов между вышеуказанными объектами.
NT-1-интерфейс 121 - это интерфейс между функцией 102-1 событий для оповещения, находящейся в приложении 102 BCAST-услуг, и блоком 101 создания содержимого. NT-1-интерфейс 121 используется для того, чтобы доставлять соответствующее событие для оповещения в функцию 102-1 событий для оповещения, когда требующее оповещения событие происходит у блока 101 создания содержимого.
NT-3-интерфейс 122 - это интерфейс между функцией 102-1 событий для оповещения, находящейся в приложении 102 BCAST-услуг, и функцией 104-1 формирования оповещений блока 104 управления BCAST-подпиской. NT-3-интерфейс 122 доставляет информацию, требуемую для оповещения о событии или для формирования сообщения оповещения, с тем чтобы функция 104-1 формирования оповещений могла сформировать событие для оповещения.
NT-4-интерфейс 123 - это интерфейс между функцией 104-1 формирования оповещений, находящейся в блоке 104 управления BCAST-подпиской, и функцией 103-1 распространения/адаптации оповещений для блока 103 распространения/адаптации BCAST-услуг. NT-4-интерфейс 123 используется для передачи события для оповещения в функцию 103-1 распространения/адаптации оповещений, чтобы передавать сообщение оповещения, сформированное в функции 104-1 формирования оповещений, в BDS 106 или сеть 107 взаимодействия. Вместо этого NT-4-интерфейс 123 может быть использован функцией 103-1 распространения/адаптации оповещений для того, чтобы передавать сообщение оповещения для события, возникшего в BDS 106.
NT-5-интерфейс 125 - это интерфейс, используемый, когда сообщение оповещения, предоставленное от функции 103-1 распространения/адаптации оповещений для блока 103 распространения/адаптации BCAST-услуг, непосредственно передается в терминал 108 через канал широковещательной передачи через BDS 106. NT-5-интерфейс 125 используется для передачи сообщения оповещения в один или множество терминалов.
NT-6-интерфейс 126 - это интерфейс, используемый, когда сообщение оповещения, предоставленное от функции 103-1 распространения/адаптации оповещений для блока 103 распространения/адаптации BCAST-услуг, непосредственно передается в терминал 108 через выделенный канал к терминалу 108 через сеть 107 взаимодействия или через широковещательный канал, предоставленный сетью 107 взаимодействия. NT-6-интерфейс 126 используется для передачи сообщения оповещения в один или множество терминалов 108.
NT-B1-интерфейс 124 - это интерфейс между блоком распространения/адаптации 103 BCAST-услуг и блоком 105 распространения BDS-услуг, и он используется в качестве пути передачи блоком 103 распространения/адаптации BCAST-услуг в BDS 106 или в качестве пути приема информации событий, сформированной в BDS 106.
X-1-интерфейс 131 - это интерфейс, используемый в качестве пути передачи, который блок 103 распространения/адаптации BCAST-услуг должен использовать в BDS, или он используется в качестве пути приема информации событий, сформированной в BDS 106, когда блок 105 распространения BDS-услуг отсутствует. Тем не менее, когда блок 105 распространения BDS-услуг существует, X-1-интерфейс 131 используется в качестве интерфейса между BDS 106 и блоком 105 распространения BDS-услуг для оповещения о том, что событие возникло в BDS 106.
X-2-интерфейс 132 - это интерфейс, используемый для установления пути передачи, который блок 103 распространения/адаптации BCAST-услуг должен использовать в сети 107 взаимодействия, когда блок 105 распространения BDS-услуг отсутствует. Тем не менее, когда блок 105 распространения BDS-услуг существует, X-2-интерфейс 132 используется в качестве интерфейса между BDS 106 и сетью 107 взаимодействия для установления однонаправленного канала, в котором событие для оповещения должно быть использовано в сети 107 взаимодействия, а также для передачи события для оповещения.
X-3-интерфейс 133, интерфейс между BDS 106 и терминалом 108, используется для BCAST-услуги или всех сообщений, передаваемых через канал широковещательной передачи.
X-4-интерфейс 134 - это интерфейс канала широковещательной передачи между блоком 105 распространения BDS-услуг и терминалом 108.
X-5-интерфейс 135 - это интерфейс канала взаимодействия между блоком 105 распространения BDS-услуг и терминалом 108.
X-6-интерфейс 136 - это интерфейс взаимодействия, посредством которого сеть 107 взаимодействия может передавать управляющую информацию, связанную с BCAST-услугой.
Функция 102-1 событий для оповещения имеет функцию предоставления информации, требуемой для формирования сообщения оповещения, через функцию 104-1 формирования оповещений, и после обнаружения возникновения требующего оповещения события предоставляет информацию о событии в функцию 104-1 формирования оповещений. Функция 104-1 формирования оповещений формирует сообщение оповещения, используя информацию и событие, требуемое для формирования сообщения оповещения, принимаемого от функции 102-1 событий для оповещения. Когда функция 104-1 формирования оповещений принимает событие для оповещения от BDS 106 через функцию 103-1 распространения/адаптации оповещений, она формирует сообщение оповещения и передает сообщение оповещения в функцию 103-1 распространения/адаптации оповещений. В процессе формирования сообщения оповещения, если есть необходимость заново указать начало услуги, функция 104-1 формирования оповещений принимает оповещение, указывающее изменение в информации услуги, от блока 101 создания содержимого. Следовательно, задан один случай, когда есть необходимость в передаче нового руководства по мобильной широковещательной передаче, и другой случай, когда возникает конкретное событие в BDS 106.
Функция 103-1 распространения/адаптации оповещений служит для того, чтобы передавать сообщение оповещения через NT-5-интерфейс 125 или NT-6-интерфейс 126, а также доставлять событие для оповещения, указывающее изменение информации по конкретной мобильной услуге широковещательной передачи, от BDS 106 в функцию 104-1 формирования оповещений по NT-4-интерфейсу 123. При этом изменение в информации по услуге широковещательной передачи может включать в себя, например, корректировку скорости передачи данных или невозможность предоставления услуги из-за беспроводного сетевого окружения.
До того как предоставляется подробное описание способа, допускающего прием сообщения оповещения, сначала описываются типы сообщений оповещения.
Сообщение оповещения грубо может быть разделено на два типа.
Первое сообщение оповещения - это сообщение общего оповещения, которое доставляется всем пользователям для общего назначения. Это сообщение оповещения используется поставщиком услуг для того, чтобы предоставлять информацию сбоев широковещательной передачи или системных изменений пользователям.
Второе сообщение оповещения - это сообщение конкретного оповещения, которое ограничено конкретной услугой. Это сообщение оповещения передается только пользователям, принимающим соответствующую услугу, и используется для того, чтобы указать изменение и начало услуги.
Далее приводится описание передачи сообщения общего оповещения или первого сообщения оповещения.
Ниже поясняется ServiceGuideDeliveryDescriptor (SGDD), или сообщение доставки руководства по услугам, согласно примерному варианту осуществления настоящего изобретения. Сообщение общего оповещения согласно примерному варианту осуществления настоящего изобретения показано в таблице 1 и таблице 2 ниже. Таблица 1 и таблица 2 иллюстрируют элементы и атрибуты ServiceGuideDeliveryDescriptor (SGDD), используемые для широковещательной передачи OMA. Для удобства таблица 1 и таблица 2 разделены из одной таблицы.
Таблица 1
Имя
Тип
Категория
Количество элементов
Описание
ServiceGuideDeliveryDescriptor
E
M
1...N
Дескриптор доставки руководства по услугам
DescriptorEntry
E1
M
1...N
Запись в дескрипторе доставки руководства по услугам.
Transport
E2
M
1
Указатель на транспортный сеанс, доставляющий фрагменты руководства по услугам в рамках модулей доставки руководства по услугам, указанных в этом DescriptorEntry.
IpAddress
A
M
1
IP-адрес целевого сеанса доставки.
Port
A
M
1
Порт целевого сеанса доставки.
SessionID
A
M
1
Идентификатор целевого сеанса доставки.
AlternativeAccessURL
E2
O
0...N
Альтернативный URL-адрес для извлечения модулей доставки руководства по услугам посредством канала взаимодействия.
ServiceGuideDeliveryUnit
E2
M
1...N
Группа фрагментов.
transportObjectID
A
O
0...1
Идентификатор транспортного объекта модуля доставки руководства по услугам, переносящего объявленные фрагменты в рамках этой группы фрагментов.
validFrom
A
M
1
Первый момент времени, когда эта группа фрагментов руководства по услугам действительна. Форматом является NTP.
validTo
A
M
1
Последний момент времени, когда эта группа фрагментов руководства по услугам действительна. Форматом является NTP.
Таблица 2
Имя
Тип
Категория
Количество элементов
Описание
Fragment
E3
M
1...N
Объявление фрагмента руководства по услугам, который доступен по каналу широковещательной передачи.
FragmentID
A
M
1
Идентификатор объявленного фрагмента руководства по услугам.
FragmentVersion
A
M
1
Версия объявленного фрагмента руководства по услугам.Примечание. Область действия FragmentVersion ограничена заданным транспортным сеансом. Значение FragmentVersion изменяется от 2^32-1 до 0.
Type
A
M
1
Перечислимое значение, обозначающее схему или MIME-тип для фрагмента. Когда самый старший бит == 1, заданный пользователем тип разрешен.
NotificationEntry
E1
M
1
Запись для сообщения оповещения в дескрипторе доставки руководства по услугам.
NotificationPort
A
M
1
Порт доставки сообщения оповещения.
NotificationAddress
A
O
1
IP-адрес доставки сообщения оповещения.
Термины, используемые в таблице 1 и таблице 2, описываются далее. "Имя" означает имена значений элементов и значений атрибутов, составляющих соответствующее сообщение. "Тип" указывает то, соответствует ли соответствующее имя значению элемента или значению атрибута. Значение элемента имеет значения 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 соответствующих значений элемента.
"Описание" задает смысл соответствующего значения элемента или атрибута.
Ссылаясь на таблицу 1, проиллюстрированы элементы и атрибуты ServiceGuideDeliveryDescriptor (SGDD), используемые для широковещательной передачи OMA. До описания SGDD, описывается руководство по услугам (SG). Руководство по услугам используется для того, чтобы указывать то, какая услуга в данный момент предоставляется пользователю в мобильной системе широковещательной передачи. Информация, предоставляемая посредством руководства по услугам, может включать в себя информацию по самой услуге, информацию по приобретению услуги, информацию по приему услуги и информацию по поставщику услуги и системе связи.
Руководство по услугам состоит из нескольких фрагментов согласно характеристике информации, предоставляемой в нем. Следовательно, чтобы сконфигурировать одно полное руководство по услугам, необходимо принять множество фрагментов. Назначение SGDD состоит в том, чтобы предоставлять информацию по расписанию передачи и каналам передачи множества фрагментов, тем самым позволяя терминалу, назначенному для приема фрагментов руководства по услугам, эффективно принимать фрагменты руководства по услугам.
Ссылаясь на таблицу 1 и таблицу 2, DescriptorEntry предоставляет информацию, доступную для приема произвольных фрагментов руководства по услугам в SGDD, и может существовать множество DescriptorEntry.
Transport содержит информацию позиции для транспортного сеанса для доставки руководства по услугам и задается посредством следующих трех атрибутов. Атрибут IPAddress, один из атрибутов элемента Transport, указывает адрес Интернет-протокола (IP) транспортного сеанса. Атрибут Port, один из атрибутов элемента Transport, указывает номер порта транспортного сеанса. Атрибут SessionID, один из атрибутов элемента Transport, указывает идентификатор (ID) транспортного сеанса.
AlternativeAccessURL, когда невозможно принимать фрагменты руководства по услугам через канал широковещательной передачи в канале, указанном посредством DescriptorEntry, указывает позицию, где можно принимать фрагменты руководства по услугам, с тем чтобы мобильный широковещательный терминал мог принимать фрагменты руководства по услугам посредством сети 107 взаимодействия, и AlternativeAccessURL указывается посредством универсального указателя информационного ресурса (URL).
ServiceGuideDeliveryUnit указывает пакет из нескольких фрагментов данных, составляющих руководство по услугам, и состоит из имеющихся 3 атрибутов и множества элементов. Число элементов в ServiceGuideDeliveryUnit является пропорцией к числу фрагментов данных. TransportObjectID, один из атрибутов элемента ServiceGuideDeliveryUnit, указывает идентификатор объекта для доставки руководства по услугам. ValidFrom, один из атрибутов элемента ServiceGuideDeliveryUnit, указывает допустимое время начала соответствующего фрагмента данных руководства по услугам. ValidTo, один из атрибутов элемента ServiceGuideDeliveryUnit, указывает допустимое время окончания соответствующего фрагмента данных руководства по услугам.
Fragment - это элемент, принадлежащий ServiceGuideDeliveryUnit, и может существовать множество Fragment. Fragment, который является информационным фрагментом для доступного в данный момент руководства по услугам, имеет 3 атрибута. FragmentID, один из атрибутов элемента Fragment, указывает идентификатор информационного фрагмента. FragmentVersion, один из атрибутов элемента Fragment, указывает информацию версии информационного фрагмента. Type, один из атрибутов элемента Fragment, указывает схему или тип многоцелевых расширений электронной почты в Интернете (MIME) для информационного фрагмента.
Элемент NotificationEntry имеет два атрибута: NotificationPort и NotificationAddress. NotificationPort и NotificationAddress указывают информацию о канале, посредством которого терминал может принимать сообщение общего оповещения. В большинстве мобильных широковещательных передач обсуждается использование IP в качестве технологии передачи данных. Если способ, которым терминал может принимать сообщение общего оповещения при допущении, что используется IP, предоставляет информацию по IP-адресу, по которому сообщение общего оповещения должно быть доставлено, и предоставляет информацию по номеру порта протокола передачи дейтаграмм пользователя (UDP) при допущении, что UDP используется поверх IP, то терминал может принимать сообщение общего оповещения. Причина для использования UDP следующая. Хотя другие транспортные протоколы, такие как TCP, также могут быть использованы, заголовок транспортного протокола UDP имеет меньше дополнительной служебной информации и не поддерживает подтверждение приема, так что транспортный протокол UDP подходит для характеристик однонаправлено передаваемой услуги широковещательной передачи. NotificationPort имеет номер UDP-порта, ранее выделенный так, что сетевой поставщик или поставщик услуг использует номер UDP-порта, когда он отправляет сообщение общего оповещения. Терминал, принимающий сообщение, передаваемое посредством UDP-порта, указанного для использования сообщения общего оповещения, может немедленно обнаружить соответствующий пакет в качестве сообщения общего оповещения и обработать пакет, поскольку он знает UDP-порт для сообщения общего оповещения через SGDD.
Функция 102-1 событий для оповещения или функция 103-1 распространения/адаптации оповещений по фиг. 1 доступна в качестве объекта для формирования сообщения доставки, чтобы доставлять сообщение общего оповещения. Устройство для формирования сообщения доставки имеет информацию по всем сеансам, где услуга в данный момент передается. Т.е. можно присоединить сообщение общего оповещения к существующему транспортному сеансу, без формирования отдельного транспортного сеанса.
Базовый идентификационный модуль сеанса состоит из IP-адреса, и сообщение общего оповещения использует IP-адрес текущего сеанса. Если мобильная система широковещательной передачи доставляет сообщение общего оповещения посредством текущего IP-сеанса посредством простого различения UDP-порта, терминал может сразу принимать сообщение общего оповещения без необходимости отдельно отслеживать сеанс. NotificationPort может быть использован, когда терминал принимает мобильную услугу широковещательной передачи и хочет доставить сообщение общего оповещения посредством IP-потока (или транспортного пути IP), где мобильная услуга широковещательной передачи передается.
NotificationAddress используется, когда есть намерение выделить специальный IP-адрес в ходе доставки сообщения общего оповещения и доставить сообщение общего оповещения посредством потока (или транспортного пути), имеющего IP-адрес. NotificationAddress предоставляет IP-адрес, чтобы доставить сообщение общего оповещения в терминал, принимающий мобильную услугу широковещательной передачи, или терминалы в режиме бездействия, не принимающие мобильную услугу широковещательной передачи, чтобы сэкономить электроэнергию. Терминал, назначенный для того, чтобы принимать сообщение общего оповещения, имеет информацию по NotificationPort и NotificationAddress и принимает сообщение общего оповещения, поскольку объект, желающий доставить состояние терминала либо сообщение общего оповещения, задает адрес приема сообщения общего оповещения.
Далее приводится описание способа доставки сообщения SGDD с помощью системы по фиг. 1 в качестве мобильной системы широковещательной передачи согласно примерному варианту осуществления настоящего изобретения.
Фиг. 2 - это блок-схема, иллюстрирующая способ формирования и передачи SGDD согласно примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 2, блок 103 распространения/адаптации BCAST-услуг указывает элементы и атрибуты SGDD, которые должны быть доставлены в терминал 108, на этапе 201. На этапе 201 указываются значения NotificationEntry, NotificationPort и NotificationAddress согласно примерному варианту осуществления настоящего изобретения. При этом элементы и атрибуты SGDD заранее определены в соответствии с поставщиком широковещательной передачи или системным окружением. После этапа 201 блок 103 распространения/адаптации BCAST-услуг формирует SGDD на этапе 202. Затем блок 103 распространения/адаптации BCAST-услуг передает сформированный SGDD в терминал 108 на этапе 203. Хотя указание и формирование SGDD выполняется здесь блоком 103 распространения/адаптации BCAST-услуг, оно также может осуществляться функцией 102-1 событий для оповещения.
Фиг. 3 - это блок-схема последовательности операций, иллюстрирующая способ приема SGDD терминалом 108 в мобильной системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения.
Согласно фиг. 3, терминал 108 приводит в исполнение услугу широковещательной передачи по запросу пользователя на этапе 301 и определяет на этапе 302 то, есть ли руководство по услугам (SG) в терминале 108, чтобы отобразить руководство по услугам для пользователя. Если имеется ранее принятое руководство по услугам на этапе 302, терминал 108 отображает руководство по услугам на дисплее на этапе 306. Тем не менее, если нет руководства по услугам, терминал 108 принимает SGDD, передаваемый от блока 103 распространения/адаптации BCAST-услуг, на этапе 303.
На этапе 304 терминал 108, принимающий SGDD, расшифровывает SGDD, чтобы получить информацию для приема руководства по услугам, и устанавливает прием руководства по услугам с помощью полученной информации. В частности, в примерном варианте осуществления настоящего изобретения терминал 108 получает значения NotificationEntry, NotificationPort и NotificationAddress, требуемые для приема сообщения общего оповещения, помимо общих настроек. Затем терминал 108 сразу принимает руководство по услугам на этапе 305. После приема достаточных данных руководства по услугам терминал 108 отображает принимаемое руководство по услугам на своем дисплее для пользователя на этапе 306.
Терминал 108, принимающий SGDD, устанавливает прием для широковещательной передачи и затем принимает широковещательную передачу. Затем терминал 108 обменивается сообщением общего оповещения в ходе приема широковещательной передачи, и система широковещательной передачи для обмена сообщениями описывается ниже.
Фиг. 4 - это блок-схема, иллюстрирующая систему широковещательной передачи для передачи сообщения общего оповещения в мобильной системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения. Подробная структура функции распространения/адаптации 103-1 оповещений и клиентской функции 108-1 оповещений по фиг. 1 проиллюстрирована на чертеже. Клиентская функция 108-1 оповещений, один функциональный блок терминала 108, может рассматриваться как терминал 108.
Ссылаясь на фиг. 4, функция распространения/адаптации 103-1 оповещений служит для того, чтобы доставлять сообщение общего оповещения в терминал или группу терминалов, и включает в себя генератор 402 UDP-пакетов и генератор 403 IP-пакетов. Генератор 402 UDP-пакетов, если есть сообщение общего оповещения, доставляемое от функции 102-1 событий для оповещения, формирует UDP-пакет с помощью порта оповещений, ранее отправленного в терминал посредством SGDD, и затем доставляет сформированный UDP-пакет в генератор 403 IP-пакетов. При этом порт оповещений - это значение, заданное в NotificationPort, принятом посредством SGDD. Причина, по которой сообщение общего оповещения сразу вводится в уровень UDP, заключается в том, что когда используются транспортные протоколы других верхних уровней, размер заголовков протоколов больше размера сообщения, которое должно быть передано, тем самым снижая эффективность.
Генератор 403 IP-пакетов формирует пакет с помощью IP-адреса текущего выполняющегося сеанса при приеме оповещения, указывающего UDP-пакет, передаваемый из генератора 402 UDP-пакетов. Хотя можно отправить сообщение общего оповещения просто с помощью номера UDP-порта, как описано выше, есть потребность в отдельном IP-сеансе, чтобы "разбудить" терминал из состояния ожидания и позволить терминалу принять сообщение общего оповещения. Это обусловлено тем, что терминал, когда разбужен из состояния ожидания, не имеет выполняющегося сеанса. При рассмотрении этой ситуации генератор 403 IP-пакетов не только формирует пакет для IP-адреса текущего выполняющегося сеанса, но также формирует пакет с помощью IP-адреса the NotificationAddress и передает сформированный пакет.
Сформированные IP-пакеты передаются в клиентскую функцию 108-1 оповещений посредством системы широковещательной передачи распространения или сети 404 взаимодействия. При этом система широковещательной передачи распространения или сеть 404 взаимодействия для удобства показана в одном блоке. Т.е. выбор устройства 404 выполняется в соответствии с поставщиком широковещательной передачи или системным окружением.
Клиентская функция 108-1 оповещений расшифровывает сообщение общего оповещения посредством декапсуляции данных IP-пакетов, передаваемых из функции 103-1 распространения/адаптации оповещений. Следовательно, клиентская функция 108-1 оповещений включает в себя дешифратор IP-пакетов 406, дешифратор 407 UDP-пакетов и дешифратор 408 сообщений общего оповещения.
Дешифратор 406 IP-пакетов определяет то, соответствует ли IP-пакет, принимаемый посредством системы широковещательной передачи распространения или сети 404 взаимодействия, текущему выполняющемуся сеансу, или указан адрес приема сообщения общего оповещения. Т.е. если IP-пакет соответствует NotificationAddress, дешифратор 406 IP-пакетов формирует UDP-пакет посредством декапсуляции IP-заголовка и доставляет сформированный UDP-пакет в дешифратор 407 UDP-пакетов. Тем не менее, если IP-пакет не соответствует NotificationAddress, дешифратор 406 IP-пакетов отбрасывает соответствующий пакет.
Дешифратор 407 UDP-пакетов доставляет UDP-пакет, предоставленный от дешифратора 406 IP-пакетов, на верхний уровень, только когда UDP-пакет соответствует текущему выполняющемуся сеансу. Тем не менее, когда принятый UDP-пакет ранее имел до этого сформированный идентификационный номер порта сообщения общего оповещения посредством NotificationPort для SGDD, дешифратор 407 UDP-пакетов доставляет принятый UDP-пакет в дешифратор 408 сообщений общего оповещения без декапсуляции принятого UDP-пакета и доставки его на верхний уровень. Дешифратор 408 сообщений общего оповещения принимает распакованный пакет, чтобы расшифровать сообщение общего оповещения, и определяет будущую работу терминала согласно результату расшифровки. Дешифратор 408 сообщений общего оповещения также может быть реализован в контроллере.
Со ссылкой на фиг. 5, далее приводится описание способа передачи сообщения общего оповещения согласно примерному варианту осуществления настоящего изобретения.
Фиг. 5 - это блок-схема, иллюстрирующая процесс передачи сообщения общего оповещения в мобильной системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 5, блок 103 распространения/адаптации BCAST-услуг принимает сообщение общего оповещения, содержащее содержимое оповещения, от функции 102-1 событий для оповещения на этапе 501. На этапе 502 блок 103 распространения/адаптации BCAST-услуг затем формирует UDP-пакет с помощью заранее определенного UDP-порта и принимаемого сообщения общего оповещения. Формат сообщения общего оповещения, поскольку оно передается на уровне поставщика услуг, не связан напрямую с передачей, так что соответствующее сообщение общего оповещения сразу формируется в UDP-пакет.
Между тем, существует возможность нахождения в режиме ожидания терминалов, которые подключены к сети 107 взаимодействия, как показано на фиг. 4, или они могут принимать сообщение поискового вызова после приема принятого сообщения общего оповещения, но приемное устройство широковещательной передачи отключено. Следовательно, терминал 108 в этом состоянии должен "разбудить" приемное устройство широковещательной передачи в режиме ожидания (не показано) посредством выполнения поискового вызова с помощью сети 107 взаимодействия или другого способа. С этой целью блок 103 распространения/адаптации BCAST-услуг формирует сообщение поискового вызова для пробуждения приемного устройства широковещательной передачи в режиме ожидания на этапе 504 и отправляет сообщение вызова посредством сети 107 взаимодействия или другого способа на этапе 505, тем самым пробуждая приемное устройство широковещательной передачи терминала.
Пакет для передачи сообщения общего оповещения формируется с помощью ранее указанного номера UDP-порта, т.е. NotificationPort, для использования доставки оповещения. Это служит для того, чтобы разрешить терминалу 108 распознать принимаемый пакет в качестве сообщения общего оповещения. На этапе 503 сформированный UDP-пакет формируется в IP-пакет с помощью IP-адреса текущего выполняющегося сеанса или IP-адреса для доставки сообщения общего оповещения, т.е. NotificationAddress. Функция 103-1 распространения/адаптации оповещения может получать IP-адрес текущего выполняющегося сеанса, поскольку он управляется посредством стороны для передачи услуги в распространении/адаптации 103 BCAST-услуг. Сформированные IP-пакеты доставляются в передающее устройство нижнего уровня. В этом случае сообщение общего оповещения может быть повторно доставлено в передающее устройство нижнего уровня несколько раз согласно потребностям сетевого поставщика или поставщика услуг, учитывая ситуацию, в которой есть потеря пакетов или прием пакетов может завершиться неудачно.
Фиг. 6 - это блок-схема, иллюстрирующая процесс приема сообщения общего оповещения в клиентской функции 108-1 оповещения мобильной системы широковещательной передачи согласно примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 6, на этапе 601 клиентская функция 108-1 оповещения принимает принятый IP-пакет и расшифровывает заголовок IP-пакета. Клиентская функция 108-1 оповещения определяет на этапе 602 то, является ли IP-адрес пакет идентичным IP-адресу текущего выполняющегося сеанса как результат расшифровки заголовка. Причина выполнения проверки IP состоит в том, что клиентской функции 108-1 оповещения не требуется принимать пакет, который нерелевантен для текущего выполняющегося сеанса. Следовательно, если адрес IP-заголовка отличается от адреса текущего выполняющегося сеанса как результат проверки IP, клиентская функция 108-1 оповещения отбрасывает текущий принятый пакет на этапе 606.
Тем не менее, если адрес принятого IP-пакета идентичен IP-адресу текущего выполняющегося сеанса, клиентская функция 108-1 оповещения переходит к этапу 603, на котором она расшифровывает заголовок UDP-пакета, полученный посредством распаковывания IP-пакета. Затем клиентская функция 108-1 оповещения определяет на этапе 604 то, является ли номер UDP-порта, полученный посредством расшифровки заголовка UDP-пакета, указанным UDP-портом, посредством определения того, что он идентичен номеру порта, заранее определенному посредством SGDD, как показано на фиг. 3. Т.е. клиентская функция 108-1 оповещения определяет то, является ли принятый пакет сообщением общего оповещения или пакетом общего сеанса широковещательной передачи.
Если определено на этапе 604, что номер порта принятого заголовка UDP-пакета идентичен номеру UDP-порта, предназначенному для того, чтобы принимать сообщение общего оповещения, клиентская функция 108-1 оповещения распаковывает принятый UDP-пакет, чтобы открыть рабочие данные сообщения общего оповещения, и расшифровывает соответствующее сообщение, чтобы выполнить требуемую операцию, на этапе 605. Тем не менее, если номер порта принятого UDP-пакета отличается от заранее заданного номера UDP-порта, клиентская функция 108-1 оповещения переходит к этапу 607, на котором она обрабатывает принимаемый UDP-пакет, рассматривая его в качестве пакета существующего сеанса широковещательной передачи.
Фиг. 7 - это блок-схема, иллюстрирующая процесс приема сообщения общего оповещения в клиентской функции 108-1 оповещения, когда она соединена с сетью 404 взаимодействия или системой, имеющей терминал в режиме ожидания, мобильной системы широковещательной передачи согласно примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 7, на этапе 701 клиентская функция 108-1 оповещения принимает сообщение поискового вызова согласно блоку сети 404 взаимодействия или блоку поискового вызова либо другому способу. На этапе 702 клиентская функция 108-1 оповещения активирует приемное устройство широковещательной передачи в режиме ожидания посредством сообщения поискового вызова и подготавливает для приема. Подготовка к приему включает в себя формирование сеанса с помощью NotificationPort и NotificationAddress, переданных посредством SGDD, и перехода в режим готовности. На этапе 703 клиентская функция 108-1 оповещения в режиме готовности расшифровывает заголовок принимаемого IP-пакета после приема IP-пакета от функции распространения/адаптации 103-1 оповещения.
Клиентская функция 108-1 оповещения определяет на этапе 704, идентичен ли адрес IP-пакета IP-адресу для сообщения общего оповещения, указанному из NotificationAddress, полученного посредством SGDD. Если определено, что адрес в заголовке IP-пакета отличается от адреса в NotificationAddress, клиентская функция 108-1 оповещения отбрасывает пакет на этапе 708. Тем не менее, если IP-адрес IP-пакета идентичен IP-адресу NotificationAddress, клиентская функция 108-1 оповещения расшифровывает заголовок UDP-пакета, полученный посредством распаковывания IP-пакета на этапе 705.
После этого клиентская функция 108-1 оповещений определяет на этапе 706, идентичен ли номер UDP-порта, полученный посредством расшифровки заголовка UDP-пакета, номеру UDP-порта NotificationPort, полученному посредством SGDD. Этап 706 выполняется для того, чтобы определить, является ли принимаемый пакет сообщением общего оповещения или некорректно переданным пакетом.
Если определено на этапе 706, что номер порта принятого заголовка UDP-пакета идентичен NotificationPort, т.е. номеру UDP-порта, предназначенному для того, чтобы принимать сообщение общего оповещения, клиентская функция 108-1 оповещения распаковывает принятый UDP-пакет, чтобы открыть рабочие данные сообщения общего оповещения, и расшифровывает соответствующее сообщение, чтобы выполнить требуемую операцию, на этапе 707. Тем не менее, если номер порта принятого UDP-пакета отличается от номера порта NotificationPort, клиентская функция 108-1 оповещения отбрасывает принимаемый UDP-пакет на этапе 708, рассматривая его в качестве некорректно принятого UDP-пакета.
Далее приводится описание сообщения конкретного оповещения или второго сообщения оповещения.
Фиг. 8 - это схема, иллюстрирующая архитектуру модели данных в руководстве по услугам, предлагаемом для мобильной широковещательной передачи в OMA BAC BCAST, одной из стандартных групп для технологии мобильной широковещательной передачи. На фиг. 8 каждая линия, соединяющая фрагменты, представляет взаимную ссылку на каждый соответствующий фрагмент.
Ссылаясь на фиг. 8, одно руководство по услугам состоит из фрагментов, имеющих свой уникальный объект, и делится на 4 крупные группы согласно использованию.
Административная группа 800, группа для предоставления базовой информации, доступной для приема руководства по услугам, состоит из ServiceGuideContext 801 и ServiceGuideDeliveryDescriptor 802. ServiceGuideContext 801 предоставляет идентификационную информацию поставщика услуг, который сформировал и передал идентификатор руководства по услугам и руководство по услугам, и информацию об общем руководстве по услугам. ServiceGuideDeliveryDescriptor 802 предоставляет в терминал информацию, допускающую прием множества фрагментов руководства по услугам, а также информацию диспетчеризации и информацию обновления для канала, с тем чтобы терминал мог принимать только необходимое руководство по услугам в соответствующее время.
Группа 810 предоставления услуг, группа для предоставления информации по оплате за прием услуг, состоит из Purchase Item 811, Purchase Data 812 и Purchase Channel 813. Purchase Item 811 предоставляет информацию по оплате за услуги или пакет услуг, а Purchase Data 812 предоставляет информацию, указывающую то, каким способом пользователь услуги может производить оплату. Purchase Channel 813 предоставляет информацию по системе, от которой пользователь услуги фактически может приобретать услугу.
Базовая группа 820, группа для предоставления информации о самой услуге, состоит из Service 821, Schedule 822 и Content 823. Service 821 предоставляет описание самой услуги, которую пользователь должен принять, и информацию, указывающую то, с помощью какого содержимого услуга может быть сконфигурирована. Schedule 822 предоставляет информацию по времени, в которое услуга может предоставляться и использоваться. Content 823 предоставляет информацию по каждому из множества вариантов содержимого, составляющих услугу.
Группа 830 доступа состоит из Access 831 и Session Description 832 и предоставляет информацию доступа к услуге, указывающую то, как принимать услуги базовой группы 820, а также подробную информацию по сеансу, в котором содержимое, составляющее услугу, передается, с тем чтобы дать возможность терминалу осуществлять доступ к услуге. Access 831 предоставляет в терминал множество способов доступа для одной услуги, с тем чтобы предоставить способ, которым терминал может осуществлять доступ к нескольким дополнительным услугам на основе одной услуги. Session Description 832 предоставляет информацию сеанса для услуги, передаваемой посредством доступа к услуге, заданного в одном фрагменте доступа.
Помимо 4 групп имеется фрагмент 824 Preview Data, и фрагмент 824 Preview Data предоставляет миниатюры и значки для услуги и содержимого.
Таблицы 3-11 иллюстрируют подробное содержимое фрагмента доступа, заданного в настоящее время в OMA BCAST.
Таблица 3
Имя
Тип
Категория
Количество элементов
Описание
Тип данных
Access
E
O
0...N
Фрагмент доступа.Содержит следующие атрибуты:- id- version- validFrom- validTo- ServiceProtection- AudioLanguageСодержит следующие подчиненные элементы:- AccessType- ExtensionURL- ServiceIDRef- ScheduleIDRef- UsageInfo- AlternativeAccessURL- TerminalCapabilityRequirement- BandwidthRequirement- ApplicationSpec- MediaInformation
id
A
M
1
Идентификатор фрагмента доступа, глобально уникальный.
anyURI
version
A
M
1
Версия этого фрагмента. Более новая версия переопределяет более старую, как только она принята.
unsignedInt (32 бита)
validFrom
A
O
0...1
Первый момент, когда этот фрагмент является допустимым. Если не предоставлен, предполагается, что допустимость начата некоторое время назад.
Integer (32 бита), выраженное как время NTP
Таблица 4
Имя
Тип
Категория
Количество элементов
Описание
Тип данных
validTo
A
O
0...1
Последний момент, когда этот фрагмент является допустимым. Если не предоставлен, предполагается, что допустимость завершается в неопределенное время в будущем.
Integer (32 бита), выраженное как время NTP
ServiceProtection
A
O
0...1
Если истинно, это указывает, что данный доступ, связанный с ассоциативно связанной услугой, защищен посредством OMA BCAST Service Protection; если ложно, это указывает, что данный доступ, связанный с ассоциативно связанной услугой, не защищен посредством OMA BCAST Service Protection.
Boolean
AudioLanguage
A
O
0...1
Данный атрибут описывает язык, используемый в аудиопотоке, если тип доступа относится к A/V-доступу.Примечание. Информация языка может быть предоставлена для каждого аудиопотока в SDP, который описывает все варианты языка. Но текущие мультимедийные проигрыватели не предлагают API для выбора языка.
Language
AccessType
E1
M
1
Задает тип доступа.Содержит следующий атрибут:- TransmissionMediaСодержит следующие элементы:- BroadcastTransmission- InteractiveTransmissionScheme
Таблица 5
Имя
Тип
Кате-гория
Количество элементов
Описание
Тип данных
TransmissionMedia
A
M
1
Этот атрибут указывает то, какой канал используется для предоставления услуги:0 - широковещательный канал1 - канал взаимодействия
Integer
BroadcastTransmission
E2
O
0...1
Этот элемент используется для указания IP-передачи.Содержит следующий атрибут:- IpAddressСодержит следующие элементы:- SessionDescriptionReference- SDP
IpAddress
A
O
0...1
IP-адрес приемного устройства IP-потока, который транспортирует услугу по каналу широковещательной передачи.Примечание. Этот атрибут используется, когда SDP не включен в фрагмент доступа.Если SDP во фрагменте доступа существует, IP-адрес приемного устройства в SDP используется.
String
Таблица 6
Имя
Тип
Категория
Количество элементов
Описание
Тип данных
SessionDescriptionReference
E3
O
0...1
Ссылка на SessionDescription, к которому относится этот доступ.Примечание. Сам SessionDescription может быть доставлен двумя способами посредством широковещательной передачи или посредством выборки по каналу взаимодействия.В случае широковещательной доставки SessionDescription либо доставляется в SGDU, либо инкапсулируется в этот фрагмент доступа. Во втором случае данный элемент не используется, а вместо него используется элемент SDP.В случае выборки по каналу взаимодействия SessionDescription может быть получен посредством осуществления доступа к URI (заданному как атрибут этого элемента).Атрибуты:- Type- URI- id
SessionDescriptionReference
Таблица 7
Имя
Тип
Категория
Количество элементов
Описание
Тип данных
Type
A
M
1
Тип описания сеанса, указываемого посредством этого SessionDescriptionReference:1 - SDP
2 - MBMS-описание пользовательской услуги (MBMS-USD), как указано в [26.346] раздел 5.2. Он может содержать одно или несколько описаний SDP.
Integer
URI
A
O
0...1
URI на файл, содержащий SessionDescription, который мультимедийное приложение в терминале использует для того, чтобы осуществлять доступ к услуге.
Any URI
idRef
A
O
0...1
Идентификатор фрагмента SessionDescription, на который ссылается этот доступ, глобально уникальный.
Any URI
SDP
E3
O
0...1
Описание сеанса в формате SDP (протокол описания сеанса IETF).
String (в SDP-формате)
InteractiveTransmissionScheme
E2
O
0...1
Этот элемент указывает то, какая система или протокол связи используется для канала взаимодействия.Содержит следующий атрибут:- TansmissionSchemeTypeСодержит следующие элементы:- AccessServerIPaddress- AccessServerURL- AccessServerPhoneNumber
Таблица 8
Имя
Тип
Категория
Количество элементов
Описание
Тип данных
TransmissionSchemeType
A
M
1
1 - канал взаимодействия, предоставленный посредством сети взаимодействия2 - MMS3 - WAP 1.04 - WAP 2.x5 - SMS6 - HTTP
Integer
7 - речевой вызов8 - заданная поставщиком услуг схема передачиПримечание. Другой протокол или система связи может быть добавлена на основе функции взаимодействия услуг OMA.
AccessServerIPaddress
E3
O
0...N
IP-адрес сервера, который предоставляет другой доступ (по каналу взаимодействия) услуги.
String
AccessServerURL
E3
O
0...N
URL-адрес сервера, который предоставляет другой доступ (по каналу взаимодействия) услуги.
anyURI
AccessServerPhoneNumber
E3
O
0...N
Телефонный номер сервера, который предоставляет другой доступ (по каналу взаимодействия) услуги.Примечание. MMS и SMS используют телефонный номер в качестве адреса.
Integer
ExtensionURL
E1
O
0...N
URL-адрес, содержащий дополнительную информацию, связанную с этим фрагментом на веб-странице. Терминал может извлекать дополнительную информацию посредством осуществления доступа к этому URL-адресу.
anyURI
Таблица 9
Имя
Тип
Категория
Количество элементов
Описание
Тип данных
ServiceIDRef
E1
O
0...N
Ссылка на фрагмент(ы) услуги, которым принадлежит данный фрагмент доступа.Любой один из ServiceIDRef и ScheduleIDRef, но не оба ОБЯЗАТЕЛЬНО должен быть задан. Примечание. Реализация в XML-
anyURI
схеме с помощью <choice>.Каждый фрагмент услуги ДОЛЖЕН быть ассоциативно связан, по меньшей мере, с одним фрагментом доступа, чтобы обеспечить доступ терминала к услуге.
ScheduleIDRef
E1
O
0...N
Ссылка на фрагмент(ы) расписания, которым принадлежит данный фрагмент доступа.Он предоставляет ссылку на фрагмент расписания, чтобы временно переопределять фрагмент доступа к услуге по умолчанию, указанный посредством расписания.Любой один из ServiceIDRef и ScheduleIDRef, но не оба ОБЯЗАТЕЛЬНО должен быть задан. Примечание. Реализация в XML-схеме с помощью <choice>.
anyURI
UsageInfo
E1
O
0...N
Этот текст помогает пользователю понять, какая разница в том, чтобы использовать один или другой фрагмент доступа. В этом случае обязательно, чтобы более одного фрагмента доступа было доступно в данный момент времени.Возможен на нескольких языках. Язык выражается с помощью встроенного XML-атрибута xml:lang с помощью этого элемента.
String
Таблица 10
Имя
Тип
Категория
Количество элементов
Описание
Тип данных
AlternativeAccessURL
E1
O
0...N
Задает альтернативный URL-адрес содержимого для извлечения его посредством канала взаимодействия, если содержимое не может быть извлечено через канал широковещательной передачи. Например, вследствие некачественного окружения радиосвязи либо терминал находится вне зоны обслуживания.
anyURI
TerminalCapabilityRequirement
E1
O
0...1
Спецификация требуемых характеристик терминала для этого доступа, таких как протоколы, кодеки, скорость передачи битов, обработка, запоминающее устройство;UAprof используется для выражения характеристик.
String
BandwidthRequirement
E1
0
0...1
Спецификация требуемой полосы пропускания сети для доступа, описанного в этом фрагменте.Услуга широковещательной передачи может включать в себя несколько доступных потоков (одно и то же содержимое) с различной полосой пропускания, так что терминал может делать выбор в зависимости от текущего состояния приема.
Integer
ApplicationSpec
E1
O
0...N
Тип приложения, которое может потреблять услугу с помощью этой спецификации доступа, заданной посредством MIME-типа.
String
MediaInformation
E1
O
0...N
Необязательная ссылка на значок, пиктограмму, анимацию или аудио. PreviewData или ссылка на PreviewData используется здесь.Атрибуты:- usage- idRef
Таблица 11
Имя
Тип
Кате-гория
Количество элементов
Описание
Тип данных
Usage
A
M
1
Возможные значения: фон, значок (к примеру)
Integer (8 битов)
idRef
A
M
1
Идентификатор фрагмента PreviewData.
anyURI
<пользовательские элементы/атрибуты>
E1 или ниже, A
O
0...N
Любое число пользовательских или конкретных для приложения элементов или атрибутов, которые не заданы в этой спецификации.
NotificationEntry
E1
M
1
Запись для сообщения оповещения в дескрипторе доставки руководства по услугам.
NotificationPort
A
M
1
Порт доставки сообщения оповещения.
NotificationAddress
A
O
1
IP-адрес доставки сообщения оповещения.
documents/BAC/BCAST/Permanent documents/OMA-TS-TS-BCAST ServiceGuide-Vl 0 0-20050930-D.zip
Описание "Категория" в таблицах 3-11 идентично ее описанию в таблице 1 и таблице 2, и подробное описание таблиц 3-11 раскрыто в документе описания, содержащемся на веб-узле по адресу http://www.openmobilealliance.org/ftp/Public для OMA, который полностью содержится в данном документе по ссылке. Указанный ссылкой документ являлся последней версией на момент, когда готовилось это описание изобретения, и если документ обновлялся впоследствии, примерный вариант осуществления настоящего изобретения может быть применен к обновленной версии.
В таблицах 3-11 последние три элемента являются новыми заданными в данном документе для оповещения, заданного в таблице 1 и таблице 2. Элемент NotificationEntry имеет два атрибута NotificationPort и NotificationAddress. NotificationPort и NotificationAddress указывают информацию о канале, по которому терминал может принимать сообщение оповещения. Использование IP в качестве технологии передачи данных для мобильной широковещательной передачи описывается ниже. Если способ, которым терминал может принимать сообщение оповещения при допущении, что используется IP, предоставляет информацию по IP-адресу, по которому сообщение оповещения должно быть доставлено, и предоставляет информацию по номеру UDP-порта при допущении, что UDP используется поверх IP, то терминал может принимать сообщение оповещения. Причина для использования UDP следующая. Хотя другие транспортные протоколы, такие как TCP, также могут быть использованы, заголовок транспортного протокола UDP имеет меньше дополнительной служебной информации и не поддерживает подтверждение приема. Таким образом, транспортный протокол UDP подходит для характеристик однонаправлено передаваемой услуги широковещательной передачи.
NotificationPort имеет номер UDP-порта, ранее выделенный так, что сетевой поставщик или поставщик услуг использует номер UDP-порта, когда он отправляет сообщение оповещения для конкретной услуги. Терминал, принимающий сообщение, передаваемое посредством UDP-порта, указанного для использования сообщения оповещения, может немедленно обнаружить соответствующий пакет в качестве сообщения оповещения и обработать пакет, поскольку он знает UDP-порт для сообщения оповещения посредством фрагмента доступа. Поскольку фрагмент доступа существует для каждой услуги, NotificationPort в фрагменте доступа предоставляет возможность приема сообщения оповещения для соответствующей услуги.
Функция 102-1 событий для оповещения или функция 103-1 распространения/адаптации оповещений по фиг. 1 доступна в качестве объекта для формирования сообщения доставки, чтобы доставлять сообщение оповещения. Устройство для формирования сообщения доставки имеет информацию по всем текущим сеансам. Т.е. можно присоединить сообщение оповещения к требующему оповещения транспортному сеансу, т.е. сеансу конкретной услуги, подключенной к произвольному фрагменту доступа, без формирования отдельного нового сеанса. Базовый идентификационный модуль сеанса состоит из IP-адреса, и сообщение оповещения использует IP-адрес сеанса выполняющейся услуги, подключенного к требующему оповещения фрагменту доступа. Поскольку мобильная система широковещательной передачи доставляет сообщение оповещения посредством выполняющегося конкретного IP-сеанса посредством простого различения UDP-порта, терминал может сразу принимать сообщение оповещения, связанное с текущим выполняющимся сеансом, без необходимости отдельно отслеживать сеанс. NotificationPort может быть использован, когда терминал принимает мобильную услугу широковещательной передачи и хочет доставить сообщение оповещения через IP-поток (или транспортного пути IP), в котором передается мобильная услуга широковещательной передачи.
NotificationAddress используется, когда есть намерение выделить специальный IP-адрес в ходе доставки сообщения оповещения и доставить сообщение оповещения посредством потока (или транспортного пути), имеющего IP-адрес. NotificationAddress предоставляет IP-адрес, чтобы доставить сообщение оповещения для конкретной услуги, подключенной к фрагменту доступа, в терминал, принимающий мобильную услугу широковещательной передачи, или терминалы в режиме бездействия, не принимающие мобильную услугу широковещательной передачи, чтобы сэкономить электроэнергию. Терминал, назначенный для того, чтобы принимать сообщение оповещения, имеет информацию по NotificationPort и NotificationAddress и принимает сообщение оповещения, поскольку объект, желающий доставить состояние терминала либо сообщение оповещения, задает адрес приема сообщения оповещения.
Фиг. 9 - это блок-схема, иллюстрирующая способ формирования и передачи фрагмента доступа в мобильной системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 9, блок 103 распространения/адаптации BCAST-услуг указывает элементы и атрибуты фрагмента доступа, которые должны быть доставлены в терминал 108, на этапе 901. В частности, на этапе 901 указываются значения NotificationEntry, NotificationPort и NotificationAddress согласно примерному варианту осуществления настоящего изобретения. При этом элементы и атрибуты фрагмента доступа заранее определены в соответствии с поставщиком широковещательной передачи или системным окружением. После этапа 901 блок 103 распространения/адаптации BCAST-услуг формирует фрагмент доступа на этапе 902. Затем на этапе 903 блок 103 распространения/адаптации BCAST-услуг предоставляет фрагмент доступа, сформированный на этапе 902, в терминал 108.
Фиг. 10 - это блок-схема, иллюстрирующая способ приема и обработки фрагмента доступа в терминале 108 мобильной системы широковещательной передачи согласно примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 10, терминал 108 принимает фрагмент доступа посредством своего приемного устройства на этапе 1001. На этапе 1002 терминал 108, принимающий фрагмент доступа, расшифровывает фрагмент доступа, чтобы получить информацию, доступную для приема конкретной услуги, ассоциативно связанной с фрагментом доступа, и устанавливает прием конкретной услуги с помощью полученной информации. В частности, в примерном варианте осуществления настоящего изобретения терминал 108 получает значения NotificationEntry, NotificationPort и NotificationAddress, требуемые для приема сообщения оповещения, помимо общих настроек.
Терминал 108, принимающий фрагмент доступа, принимает конкретную услугу после задания приема конкретной услуги. После этого терминал 108 передает/принимает сообщение оповещения в ходе приема конкретной услуги, и система широковещательной передачи для этого описывается ниже.
Процедура доставки сообщения оповещения, ассоциативно связанного с фрагментом доступа, аналогична процедуре, описанной на фиг. 5, но используемые NotificationPort и NotificationAddress должны быть значениями, применяемыми только для услуги, подключенной к фрагменту доступа, а не значениями, используемыми для общей цели. Вышеуказанные значения определяются поставщиком услуг или сетевого поставщика.
Операция терминала 108 для приема сообщения оповещения для конкретной услуги посредством фрагмента доступа идентична операции, описанной на фиг. 6 и 7, так что ее описание опущено.
Фиг. 11 - это схема, иллюстрирующая архитектуру сети цифрового видеовещания-сходимости услуг широковещательной и мобильной передачи (DVB-CBMS) согласно второму примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 11, блок 1101 создания содержимого (CC) - это поставщик BCAST-услуги, и BCAST-услуга может включать в себя услугу широковещательной передачи аудио/видео, услугу загрузки файлов (музыкальных файлов или файлов данных) и т.д. Блок 1101 создания содержимого, если есть какие-либо проблемы в предоставлении BCAST-услуги или какие-либо изменения в содержимом услуги, сообщает о проблеме или изменении в функцию 1102a событий для оповещения (NTE) в приложении 1102 BCAST-услуг. Функция 1102a событий для оповещения доставляет событие сообщения оповещения в функцию формирования оповещений (NGF) 1103a на основе принимаемого события.
Приложение 1102 BCAST-услуги имеет функцию приема данных содержимого для BCAST-услуги, предоставляемой от блока 1101 создания содержимого, обработки принимаемых данных содержимого в форме (например, потоковой передачи аудио/видео или загрузки фильмов), подходящей для сети широковещательной передачи, и формирования данных BCAST-услуги. Например, приложение 1102 BCAST-услуги имеет функцию формирования стандартизированных метаданных, требуемых для руководства по широковещательной передаче, и имеет функцию формирования информации выставления счетов согласно пользователю. Помимо этого, приложение 1102 BCAST-услуги принимает изменение в BCAST-услуге, сообщенное блоком 1101 создания содержимого, доставляет событие для оповещения в функцию 1103a формирования оповещений, находящуюся в управлении услугами (SM) 1103, и предоставляет информацию атрибутов руководства по услугам, используемую для формирования сообщения оповещения, в функцию 1103a формирования оповещений.
Блок 1103 управления услугами имеет функцию определения расписания передачи BCAST-услуги, предоставляемой от приложения 1102 BCAST-услуги, и функцию формирования руководства по услугам. Блок 1103 управления услугами подключен к системе 1106 распространения широковещательной передачи, поддерживающей BCAST-услугу, и сети 1107 взаимодействия, поддерживающей связь взаимодействия. Помимо этого, блок 1103 управления услугами, включающий в себя функцию 1103b распространения/адаптации оповещений (NTDA), принимает сообщение оповещения от блока 1103 управления услугами и передает сообщение оповещения в один терминал или группу терминалов посредством системы 1106 распространения широковещательной передачи или сети 1107 взаимодействия. Блок 1103 управления услугами имеет информацию сеанса, требуемую функцией 1103a формирования оповещений, чтобы сформировать сообщение оповещения для использования терминалом, и функция 1103b распространения/адаптации оповещений передает информацию сеанса в функцию 1103a формирования оповещений.
Блок 1103 управления услугами управляет абонентской информацией для приема BCAST-услуги, информацией предоставления услуги, такой как информация, указывающая то, приобрел ли абонент связанное содержимое, и информацией устройства для терминалов, принимающих BCAST-услугу. Т.е. блок 1103 управления услугами предоставляет информацию выставления счетов пользователям в приложение 1102 BCAST-услуги. Блок 1103 управления услугами также предоставляет информацию подписки, информацию предоставления услуги и информацию устройства в систему 1106 распространения широковещательной передачи и сеть 1107 взаимодействия. В частности, блок 1103 управления услугами, поскольку он включает в себя функцию 1103a формирования оповещений, формирует сообщение оповещения для события для оповещения или формирует сообщение оповещения для информации, указывающей то, что содержимое предоставляется от BCAST-услуги, когда имеется событие, которое произошло, указывающее добавление новой функции или изменение в существующей функции, предоставляемой от блока 1101 создания содержимого, приложения 1102 BCAST-услуги, блока 1103 управления услугами и системы 1106 распространения широковещательной передачи. Например, сообщение оповещения может быть ассоциативно связано с самим событием, указывая информацию о том, что соответствующая широковещательная передача будет предоставлена по истечении определенного количества времени.
Система широковещательной передачи 1106 распространения - это сеть для передачи BCAST-услуги. В этом примерном варианте осуществления система 1106 распространения широковещательной передачи основана на DVB-H в качестве примера. Система 1106 распространения широковещательной передачи, если возникает изменение в процессе передачи BCAST-услуги, сообщает об изменении в блоке 1103 управления услугами посредством CBMS-6-интерфейса 1124a или X-3-интерфейса 1124b.
Сеть 1107 взаимодействия передает BCAST-услуги на основе "от точки к точке" либо интерактивно обменивается управляющей информацией и дополнительной информацией, связанной с приемом BCAST-услуг, и может быть существующей сотовой сетью, такой как сеть 3GPP с широкополосным множественным доступом с кодовым разделением каналов (WCDMA).
Терминал 1108 - это терминальное устройство, допускающее прием BCAST-услуги, и оно может иметь функцию осуществления доступа к сети 1107 взаимодействия с помощью канала взаимодействия согласно характеристикам терминального устройства. В данном документе предполагается, что терминал 1108 - это терминал, допускающий осуществление доступа к сотовой сети, в качестве примера сети 1107 взаимодействия, посредством X-2 1134. Терминал 1108 принимает сообщение оповещения, передаваемое посредством клиентской функции оповещения (NTC) 1108a через CBMS-3-интерфейс 1125, и выполняет соответствующую операцию согласно принимаемому сообщению оповещения. Альтернативно терминал 1108 принимает сообщение оповещения, передаваемое посредством CBMS-4-интерфейса 1126, и выполняет соответствующую операцию согласно принимаемому сообщению оповещения.
Далее приводится описание интерфейсов между блочными элементами мобильной системы широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
CBMS-7-интерфейс 1122, интерфейс между функцией 1102a событий для оповещения, находящейся в приложении 1102 BCAST-услуги, и функцией формирования 1103a оповещений блока 1103 управления услугами, переносит информацию (например, информацию атрибутов руководства по услугам), требуемую для формирования оповещения или сообщения оповещения для события, с тем чтобы функция 1103a формирования оповещений могла сформировать сообщение оповещения.
CBMS-5-интерфейс 1125, интерфейс, используемый тогда, когда сообщение оповещения, передаваемое от функции 1103b распространения/адаптации оповещений блока 1103 управления услугами, напрямую доставляется в терминал 1108 через канал широковещательной передачи по системе 1106 распространения широковещательной передачи, используется для передачи сообщения оповещения в один или множество терминалов 1108.
CBMS-4-интерфейс 1126, интерфейс, используемый тогда, когда сообщение оповещения, передаваемое от функции 1103b распространения/адаптации оповещений блока 1103 управления услугами, напрямую доставляется в терминал 1108 посредством выделенного канала к терминалу 1108 по сети 1107 взаимодействия или посредством канала широковещательной передачи, предоставляемого посредством сети 1107 взаимодействия, используется для передачи сообщения оповещения в один или множество терминалов 1108.
CBMS-6-интерфейс 1124a, интерфейс между блоком 1103 управления услугами и системой 1106 распространения широковещательной передачи, используется в качестве пути передачи, который должен быть использован блоком 1103 управления услугами в системе 1106 распространения широковещательной передачи, или пути приема информации событий, формируемой в системе 1106 распространения широковещательной передачи.
X-3-интерфейс 1124b - это интерфейс, используемый для установления пути передачи, который должен быть использован между блоком 1103 управления услугами и сетью 1107 взаимодействия.
CBMS-1-интерфейс 1133 - это интерфейс, используемый, когда управляющий сигнал системы 1106 распространения широковещательной передачи доставляется в терминал 1108. Например, в DVB-H управляющий сигнал, называемый информацией, конкретной для программы/информацией об услуге (PSI/SI), соответствует управляющему сигналу.
X-2-интерфейс 1134 - это интерфейс между сетью 1107 взаимодействия и терминалом 1108.
Функция 1102a событий для оповещения имеет функцию предоставления информации, требуемой для формирования сообщения оповещения, в функцию 1103a формирования оповещений, и после обнаружения возникновения требующего оповещения события предоставляет информацию о событии в функцию 1103a формирования оповещений. Функция 1103a формирования оповещений формирует сообщение оповещения, используя информацию и событие, требуемое для формирования сообщения оповещения, принимаемого от функции 1102a событий для оповещения. Когда функция 1102a событий для оповещения принимает событие для оповещения от системы 1106 распространения широковещательной передачи через функцию 1103b распространения/адаптации оповещений, она формирует сообщение оповещения и передает сообщение оповещения в функцию 1103b распространения/адаптации оповещений. В процессе формирования сообщения оповещения, если есть необходимость заново указать начало услуги, функция 1103a формирования оповещений принимает оповещение, указывающее изменение в информации услуги, от блока 101 создания содержимого, задавая один случай, когда есть необходимость в передаче нового руководства по мобильной широковещательной передаче, и другой случай, когда конкретное событие возникает в системе 1106 распространения широковещательной передачи.
Функция 1103b распространения/адаптации оповещений служит для того, чтобы передавать сообщение оповещения посредством CBMS-5-интерфейса 1125 или CBMS-4-интерфейса 1126, а также доставлять событие для оповещения, указывающее изменение информации по конкретной мобильной услуге широковещательной передачи, от системы 1106 распространения широковещательной передачи в функцию 1103a формирования оповещений. При этом изменение в информации по услуге широковещательной передачи может включать в себя корректировку скорости передачи данных или недоступность услуги из-за беспроводного сетевого окружения.
Фиг. 12 - это схема, иллюстрирующая модель данных электронного руководства по услугам (ESG) в DVB-CBMS согласно второму примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 12, каждый блок представляет фрагмент ESG-данных. Т.е. модель данных ESG включает в себя фрагмент 1202 Service, фрагмент 1204 Schedule Event, фрагмент 1206 Content, фрагмент 1208 Acquisition, фрагмент 1210 Service Bundle, фрагмент 1212 Purchase и фрагмент 1214 Purchase Channel.
Фрагмент 1202 Service включает в себя полное описание услуги. Фрагмент 1204 Schedule Event представляет информацию об услуге согласно времени. Фрагмент 1208 Acquisition включает в себя информацию доступа к услуге, которую необходимо знать, чтобы принимать данные услуги. Фрагмент 1210 Service Bundle включает в себя информацию по случаю, когда несколько услуг сгруппировано в один пакет услуг. Фрагмент 1212 Purchase указывает информацию цены для приобретения пакета услуг. Фрагмент 1214 Purchase Channel указывает информацию по системе, которая должна быть использована для того, чтобы получить право на приобретение.
Каждый фрагмент модели данных может осуществлять ссылку на другие фрагменты, и стрелка между фрагментами представляет отношение ссылки. Фраза "осуществление ссылки" относится к процессу, при котором текущий фрагмент предоставляет информацию, ассоциативно связанную с ним, с помощью информации, доставляемой из другого фрагмента. Т.е. когда одна услуга состоит из нескольких вариантов содержимого, фрагмент 1202 Service включает в себя только полное описание услуги, например имя и язык услуги, но не включает в себя описание содержимого, передаваемого посредством услуги. Тем не менее, фрагмент 1206 Content соответствующего содержимого осуществляет ссылку на фрагмент Service соответствующей услуги. Помимо этого, чтобы получить различную информацию, требуемую для приема услуги, к примеру, информацию сеанса, используемую для протокола передачи, терминал может получать информацию посредством приема фрагмента 1208 Acquisition, на который фрагмент 1202 Service осуществляет ссылку, и демодуляции принимаемого фрагмента 1208 Acquisition.
ESG-данные доставляются в терминал с помощью отдельного IP-потока во время, отличное от времени фактического потока данных. Следовательно, поставщик услуг может предоставлять до доставки услуги информацию, которую пользователь должен получить до того, как он принимает услугу, с помощью модели данных ESG. Посредством приема ESG-потока терминал получает информацию, требуемую для приема услуги, предоставляемой поставщиком услуг, и когда пользователь выбирает конкретную услугу, терминал осуществляет доступ к потоку данных, где услуга доставляется, используя полученную информацию, а затем принимает данные. Информация требуется терминалом для того, чтобы осуществлять доступ к потоку данных услуги, передаваемому посредством фрагмента 1208 Acquisition, как описано на фиг. 11.
В модели данных ESG несколько фрагментов пакетируются и помещаются в один контейнер, и каждый контейнер рассматривается как один объект в сеансе FLUTE в ходе своей передачи.
Фиг. 13 - это схема, иллюстрирующая операцию доставки ESG в DVB-CBMS согласно второму примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 13, передающее устройство предоставляет информацию канала сеанса 1310 инициализации ESG в терминал посредством PSI/SI-сигнала для доставки ESG. Терминал осуществляет доступ к каналу согласно информации канала, а затем принимает информацию инициализации. Информация инициализации состоит из дескриптора 1312 поставщика ESG и дескриптора 1313 доступа к ESG (или дескриптора инициализации ESG). Экземпляр 1311 таблицы описания файлов (полная FDT) - это FDT, используемая в протоколе FLUTE, и это таблица, включающая в себя параметры, описывающие файловые объекты, передаваемые в сеансе FLUTE.
Дескриптор 1312 поставщика ESG включает в себя связанную информацию, такую как идентификатор, имя и логотип поставщика ESG, а дескриптор 1313 доступа к ESG включает в себя информацию канала 1320 уведомлений ESG, информацию по числу IP-сеансов, в которых ESG доставляется, и информацию адреса IP-сеансов.
Канал 1320 уведомлений ESG переносит контейнер инициализации 1340 ESG и информацию индекса ESG, и информация, переносимая посредством контейнера 1340 инициализации ESG, следующая. Заголовок 1332 контейнера включен. Сообщение инициализации 1333 ESG включает в себя вариант декодера для расшифровки ESG, а информация 1334 разделения включает в себя информацию критериев разделения сеансов и информацию канала каждого сеанса, когда ESG передается посредством множества сеансов. Индексный список 1335 и индексная структура 1336 включает в себя фрагменты ESG передачи и информацию соответствия между контейнерами 1340-1-1340-n. Более того, дополнительно включен экземпляр 1321 таблицы описания файлов (полной FDT).
ESG содержится в нескольких контейнерах в ходе своей передачи, как показано на фиг. 13, и каждый контейнер состоит из информации управления фрагментом, указывающей информацию по фрагментам, составляющим соответствующий контейнер, и фрагменты ESG.
До того, как приводится описание операции приема сообщения оповещения согласно второму примерному варианту осуществления, сначала описываются типы сообщений оповещения. Сообщение оповещения грубо может быть разделено на два типа.
Первое сообщение оповещения - это сообщение общего оповещения, которое доставляется всем пользователям для общего назначения. Это сообщение оповещения используется поставщиком услуг для того, чтобы предоставлять информацию сбоев широковещательной передачи или системных изменений пользователям.
Второе сообщение оповещения - это сообщение конкретного оповещения, которое ограничено конкретной услугой. Это сообщение оповещения передается только пользователям, принимающим конкретную услугу, и может быть использовано для того, чтобы указать изменение и начало услуги. Сообщение конкретного оповещения также может быть сформировано и передано отдельно для каждой отдельной конкретной группы пользователей, а не для каждой отдельной услуги. "Конкретной группой пользователей" может быть группа пользователей, сформированная посредством подписки на услугу оповещения, или группа пользователей, сформированная, когда сеть стремится доставить сообщение оповещения в конкретную зону. Когда есть намерение доставить сообщение оповещения группе пользователей, сформированной посредством подписки на услугу, можно передавать сообщение оповещения на основе от точки к точке, поскольку информация по каждому подписчику управляется. Когда нет намерения доставить сообщение оповещения отдельно в каждую отдельную конкретную зону, группа пользователей, находящаяся в этой конкретной зоне, не управляется отдельно.
При приеме/передаче сообщения оповещения общий поток согласно второму примерному варианту осуществления настоящего изобретения показан на фиг. 14. Как показано на фиг. 14, настоящее изобретение в общем случае включает в себя операцию A (1410) доставки/получения информации канала сообщения оповещения, операцию B (1420) передачи/приема сообщения оповещения и операцию C (1430), при которой терминал принимает и расшифровывает сообщение оповещения и выполняет операцию согласно ему. Операция A (1410) описывается во втором примерном варианте осуществления, операция B (1420) описывается со ссылкой на фиг. 21-26, а описание операции C (1430) опущено для ясности и краткости.
I. Операция A (1410)
В системе DVB-CBMS согласно второму примерному варианту осуществления информация канала сообщения оповещения передается в терминал с помощью ESG, и терминал обнаруживает, что принимаемый пакет включает в себя сообщение оповещения, с помощью информации канала.
Со ссылкой на таблицу 12 ниже далее приводится описание информации канала сообщения оповещения, примеряемой к системе DVB-CBMS согласно примерному варианту осуществления настоящего изобретения.
Таблица 12
Имя
Тип
Категория
Описание
NotificationEntry
E
M
Запись для сообщения оповещения
NotificationPort
A
M
Порт доставки сообщения оповещения
NotificationAddress
A
O
IP-адрес доставки сообщения оповещения
Описание терминов, используемых в таблице 12, приводится. "Имя" означает имена значений элементов и значений атрибутов, составляющих соответствующее сообщение. "Тип" указывает то, соответствует ли соответствующее имя значению элемента или значению атрибута. Значение элемента имеет значения E1, E2, E3 и E4. E1 означает значение верхнего элемента для всего сообщения, E2 означает значение подчиненного элемента E1, E3 означает значение подчиненного элемента E2, а E4 означает значение подчиненного элемента E3. Значение атрибута указывается посредством A, и A означает значение атрибута соответствующего элемента. Например, A согласно E1 означает значение атрибута E1.
"Категория" используется для указания того, является ли соответствующее значение элемента или значение атрибута обязательным, и имеет значение M, если значение обязательное, и значение O, если значение необязательное. "Описание" задает смысл соответствующего значения элемента или атрибута.
Элемент NotificationEntry имеет два атрибута: NotificationPort и NotificationAddress. NotificationPort и NotificationAddress указывают информацию о канале, посредством которого терминал может принимать сообщение оповещения. Использование IP в качестве технологии передачи данных описывается ниже. Если способ, которым терминал может принимать сообщение оповещения при допущении, что используется IP, предоставляет информацию по IP-адресу, по которому сообщение оповещения должно быть доставлено, и предоставляет информацию по номеру UDP-порта при допущении, что UDP используется поверх уровня IP, то терминал может принимать сообщение оповещения. Причина для использования UDP следующая. Хотя другие транспортные протоколы, такие как TCP, также могут быть использованы, заголовок транспортного протокола UDP имеет меньше дополнительной служебной информации и не поддерживает подтверждение приема. Таким образом, транспортный протокол UDP подходит для характеристик однонаправленно передаваемой услуги широковещательной передачи.
Когда сообщение оповещения доставляется на основе "от точки к точке", TCP может быть использован вместо UDP. Поэтому следует понимать, что TCP используется в качестве порта сообщения оповещения в схеме "от точки к точке", если не указано иное. Хотя UDP-порт используется в качестве порта сообщения оповещения в дальнейшем описании, TCP-порт может быть использован в качестве порта сообщения оповещения в схеме "от точки к точке", как указано выше.
NotificationPort имеет номер UDP-порта, ранее выделенный так, что сетевой поставщик или поставщик услуг использует номер UDP-порта, когда он отправляет сообщение оповещения. Терминал, принимающий сообщение, передаваемое посредством UDP-порта, указанного для использования сообщения оповещения, может немедленно обнаружить соответствующий пакет в качестве сообщения оповещения и обработать пакет, поскольку он знает UDP-порт для сообщения оповещения.
Операция формирования сообщения оповещения в качестве передаваемого сообщения может быть выполнена в функции 1102a событий для оповещения или функции 1103b распространения/адаптации оповещений по фиг. 11. Объект для формирования сообщения оповещения имеет информацию по всем выполняющимся сеансам. Т.е. можно присоединить сообщение оповещения к существующему транспортному сеансу без формирования отдельного транспортного сеанса. Базовый идентификационный модуль сеанса состоит из IP-адреса, и сообщение оповещения использует IP-адрес текущего сеанса. При этом текущий сеанс может быть ассоциативно связан с конкретной услугой, подключенной к требующему оповещения фрагменту Acquisition.
Поскольку мобильная система широковещательной передачи доставляет сообщение оповещения посредством выполняющегося IP-сеанса посредством простого различения UDP-порта, терминал может сразу принимать сообщение оповещения (сообщение общего оповещения или сообщение конкретного оповещения, связанное с услугой выполняющегося сеанса), без необходимости отдельно отслеживать сеанс. NotificationPort может быть использован, когда терминал принимает мобильную услугу широковещательной передачи и хочет доставить сообщение оповещения посредством IP-потока (или транспортного пути IP), где мобильная услуга широковещательной передачи передается.
NotificationAddress используется, когда есть намерение выделить специальный IP-адрес в ходе доставки сообщения оповещения и доставить сообщение оповещения посредством потока (или транспортного пути), имеющего IP-адрес. NotificationAddress предоставляет IP-адрес, чтобы доставить сообщение общего или конкретного оповещения в терминал, принимающий мобильную услугу широковещательной передачи, или терминалы в режиме бездействия, не принимающие мобильную услугу широковещательной передачи, чтобы сэкономить электроэнергию. С помощью NotificationPort и NotificationAddress терминал принимает сообщение оповещения согласно адресу приема для сообщения оповещения объекта, желающего доставить состояние терминала либо сообщение оповещения.
В системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения, поскольку терминал, который уже осуществил доступ к услуге широковещательной передачи, принимает PSI/SI-сигнал, передающее устройство не передает отдельно информацию канала сообщения оповещения.
Далее приводится описание способа доставки сообщения оповещения в системе широковещательной передачи согласно примерному варианту осуществления настоящего изобретения.
Для сообщения общего оповещения передающее устройство вносит информацию канала по таблице 12 в дескриптор 1313 самонастройки ESG по фиг. 13 до передачи. Для сообщения конкретного оповещения передающее устройство вставляет информацию канала по таблице 12 во фрагмент 1208 Acquisition по фиг. 12.
Со ссылкой на фиг. 15 и 16, ниже приводится описание передачи/приема дескриптора 1313 самонастройки ESG в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
Фиг. 15 - это блок-схема, иллюстрирующая операцию формирования и доставки дескриптора 1313 самонастройки ESG в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 15, функция 1103b распространения/адаптации оповещений обозначает элементы и атрибуты информации канала сообщения общего оповещения в качестве информации самонастройки ESG, которая должна быть доставлена в терминал 1108, на этапе 1501. В частности, на этапе 1501 указываются значения NotificationEntry, NotificationPort и NotificationAddress, описанные выше. При этом элементы и атрибуты информации канала сообщений общего оповещения заранее определены в соответствии с поставщиком широковещательной передачи или системным окружением. После этапа 1501 функция 1103b распространения/адаптации оповещений формирует дескриптор 1313 самонастройки ESG, включающий в себя информацию канала сообщения общего оповещения, на этапе 1502. После этого на этапе 1503 функция 1103b распространения/адаптации оповещений доставляет сформированный дескриптор 1313 самонастройки ESG в терминал 108. Хотя формирование информации канала сообщения общего оповещения выполняется в данном документе функцией 1103b распространения/адаптации оповещений, но также может выполняться функцией 1102a событий для оповещения.
Фиг. 16 - это блок-схема, иллюстрирующая операцию приема информации канала сообщения оповещения в дескрипторе 1313 самонастройки ESG терминалом 1108 в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 16, терминал 1108 приводит в исполнение услугу широковещательной передачи посредством пользователя на этапе 1601, а затем принимает дескриптор 1313 самонастройки ESG, передаваемый из функции 1103b распространения/адаптации оповещений, на этапе 1602. После приема дескриптора 1313 самонастройки ESG терминал 1108 расшифровывает дескриптор 1313 самонастройки ESG на этапе 1603 и получает NotificationEntry, NotificationPort и NotificationAddress, требуемые для приема сообщения общего оповещения, на этапе 1604. Затем терминал 1108 переходит к операции B (1420) по фиг. 14.
Со ссылкой на фиг. 17 и 18 ниже приводится описание передачи/приема фрагмента 1208 ESG Acquisition в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
Фиг. 17 - это блок-схема, иллюстрирующая операцию формирования и доставки информации канала сообщения оповещения в фрагменте 1208 ESG Acquisition в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 17, функция 1103b распространения/адаптации оповещений обозначает элементы и атрибуты информации канала сообщения конкретного оповещения в качестве информации фрагмента ESG Acquisition, которая должна быть доставлена в терминал 1108, на этапе 1701. В частности, на этапе 1701 указываются значения NotificationEntry, NotificationPort и NotificationAddress, описанные выше. При этом элементы и атрибуты информации канала сообщений конкретного оповещения заранее определены в соответствии с поставщиком широковещательной передачи или системным окружением. После этапа 1701 функция 1103b распространения/адаптации оповещений вставляет информацию канала сообщений конкретного оповещения во фрагмент 1208 ESG Acquisition на этапе 1702. После этого функция 1103b распространения/адаптации оповещений завершает ESG посредством комбинирования фрагмента 1208 ESG Acquisition с другими фрагментами на этапе 1703, и затем доставляет ESG в терминал 1108 на этапе 1704. Хотя формирование информации канала сообщения конкретного оповещения выполняется в данном документе функцией 1103b распространения/адаптации оповещений, но также может выполняться функцией 1102a событий для оповещения.
Фиг. 18 - это блок-схема, иллюстрирующая операцию приема информации канала сообщения оповещения в фрагменте 1208 ESG Acquisition терминалом 1108 в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 18, терминал 1108 приводит в исполнение услугу широковещательной передачи посредством пользователя на этапе 1801, а затем принимает дескриптор 1313 самонастройки ESG, передаваемый из функции 1103b распространения/адаптации оповещений, на этапе 1802. После приема дескриптора 1313 самонастройки ESG терминал 1108 расшифровывает дескриптор 1313 самонастройки ESG на этапе 1803. Затем на этапе 1804 терминал 1108 получает информацию, доступную для приема ESG, выполняет аппаратные и программные настройки для приема ESG с помощью полученной информации, а далее сразу принимает ESG. На этапе 1805 терминал 1108 получает и проверяет NotificationEntry, NotificationPort и NotificationAddress, которые требуются для приема сообщения конкретного оповещения и включены в фрагмент 1208 Acquisition для ESG. Затем терминал 1108 переходит к операции B (1420) по фиг. 14.
В качестве еще одного примера терминал 1108 может обнаружить конкретную услугу, связанную с сообщением оповещения, посредством приема сообщения оповещения и расшифровки Service_ID, вставленного в сообщение оповещения, без получения информации канала сообщения конкретного оповещения посредством фрагмента 1208 Acquisition для ESG, как выполнено на фиг. 17 и 18. Предпочтительно, чтобы Service_ID имел тот же смысл, что идентификатор услуги в ESG.
II. Операция B (1420)
Со ссылкой на фиг. 19, далее приводится описание передачи сообщения общего оповещения согласно второму примерному варианту осуществления настоящего изобретения. Поскольку сообщение общего оповещения и сообщение конкретного оповещения идентичны друг другу в отношении способа передачи, они не различаются в описании фиг. 19.
Фиг. 19 - это блок-схема, иллюстрирующая операцию доставки сообщения общего оповещения в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 19, функция 1103b распространения/адаптации оповещений принимает сообщение общего оповещения, содержащее содержимое оповещения (т.е. событие для оповещения), от функции 1102a на этапе 1901. На этапе 1902 функция 1103b распространения/адаптации оповещений затем формирует UDP-пакет с помощью заранее определенного UDP-порта и сообщения общего оповещения. Формат сообщения общего оповещения, поскольку оно задается на уровне поставщика услуг, не связан напрямую с передачей, так что сообщение общего оповещения сразу формируется в UDP-пакет. После этого на этапе 1903 функция 1103b распространения/адаптации оповещений формирует пакет согласно выполняющемуся сеансу широковещательной передачи и ранее указанному IP-адресу оповещения с помощью сформированного сообщения оповещения и доставляет сформированный пакет в терминалы. Между тем, в зоне обслуживания существует возможность того, что имеются терминалы в режиме ожидания, когда они подключены к сети 1107 взаимодействия или могут принимать услугу радиовызова, но их приемное устройство широковещательной передачи отключено. Для терминалов в этом режиме система должна "разбудить" широковещательные приемные устройства в режиме ожидания (не показаны) для терминалов посредством использования канала взаимодействия сети 1107 взаимодействия или осуществления радиовызова посредством другого средства. С этой целью система формирует сообщение радиовызова для пробуждения приемного устройства широковещательной передачи в режиме ожидания на этапе 1904 и отправляет сообщение радиовызова в терминалы посредством сети 1107 взаимодействия или другого способа на этапе 1905, тем самым пробуждая приемное устройство широковещательной передачи терминала.
Пакет для передачи сообщения общего оповещения формируется с помощью ранее указанного номера UDP-порта, т.е. NotificationPort, для использования доставки оповещения. Это служит для того, чтобы разрешить терминалу 1108 распознать принимаемый пакет в качестве сообщения общего оповещения. Сформированные UDP-пакеты формируются в IP-пакеты с помощью IP-адреса текущего выполняющегося сеанса или IP-адреса для доставки сообщения общего оповещения, т.е. NotificationAddress. IP-адрес текущего выполняющегося сеанса может быть получен, поскольку функция 103-1 распространения/адаптации оповещения для формирования сообщения доставки оповещений существует в управлении 1103 услугами для управления всеми передачами. Полные IP-пакеты доставляются в передающее устройство нижнего уровня. В этом случае сообщение общего оповещения может быть повторно доставлено в передающее устройство нижнего уровня несколько раз согласно потребностям сетевого поставщика или поставщика услуг, учитывая ситуацию, в которой есть потеря пакетов или прием пакетов может завершиться неудачно.
Со ссылкой на фиг. 20 и 21 далее приводится описание операции приема сообщения оповещения в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения. Поскольку сообщение общего оповещения и сообщение конкретного оповещения идентичны друг другу в отношении способа приема, они не различаются в нижеследующем описании.
Фиг. 20 - это блок-схема, иллюстрирующая операцию приема сообщения оповещения посредством клиентской функции 1108a оповещения в терминале в мобильной системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения.
Ссылаясь на фиг. 20, после приема информации канала сообщений оповещения в операции A (1410) по фиг. 14 клиентская функция 1108a оповещений принимает IP-пакет и расшифровывает заголовок IP-пакета на этапе 2001. Клиентская функция 1108a оповещений определяет на этапе 2002 то, идентичен ли IP-адрес пакета требуемому IP-адресу в результате расшифровки заголовка. Здесь "требуемый IP-адрес" означает IP-адрес текущего выполняющегося сеанса или конкретный IP-адрес, т.е. NotificationAddress, назначенный для сообщения оповещения. Следовательно, если IP-адрес в заголовке не является требуемым IP-адресом как результат IP-проверки, клиентская функция 1108a оповещений отбрасывает принятый IP-пакет на этапе 2006.
Тем не менее, если адрес принимаемого IP-пакета идентичен требуемому IP-адресу, клиентская функция 1108a оповещений переходит к этапу 2003, где она получает UDP-пакет посредством распаковывания IP-пакета и расшифровывает заголовок UDP-пакета. Далее клиентская функция 1108a оповещений определяет на этапе 2004 то, идентичен ли номер UDP-порта, полученный посредством расшифровки заголовка UDP-пакета, номеру порта NotificationPort заранее определенной информации канала сообщения оповещения, ранее полученной посредством дескриптора 1313 самонастройки ESG или PSI/SI-сигнала. Т.е. клиентская функция 1108a оповещений определяет то, является принимаемый пакет сообщением общего оповещения или пакетом общего сеанса широковещательной передачи.
Если определено на этапе 2004, что номер порта принимаемого заголовка UDP-пакета идентичен номеру UDP-порта, предназначенного для того, чтобы принимать сообщение оповещения, клиентская функция 1108a оповещений распаковывает принимаемый UDP-пакет, чтобы получить сообщение общего оповещения, включенное в рабочие данные, и расшифровывает сообщение оповещения, чтобы выполнить требуемую операцию, на этапе 2005, а затем переходит к операции C (1430) по фиг. 14. Тем не менее, если номер порта принимаемого UDP-пакета отличается от заранее указанного номера UDP-порта, клиентская функция 1108a оповещений переходит к этапу 2007, на котором она обрабатывает принимаемый UDP-пакет для услуги широковещательной передачи, рассматривая его в качестве пакета существующего сеанса широковещательной передачи, либо игнорирует принимаемый UDP-пакет, если он не является требуемым сообщением оповещения.
Фиг. 21 - это блок-схема, иллюстрирующая процесс приема сообщения оповещения в клиентской функции оповещения 1108a терминала, когда она соединена с сетью взаимодействия в системе широковещательной передачи согласно второму примерному варианту осуществления настоящего изобретения. Этот процесс может быть применен не только к сети взаимодействия, но также к терминалу, подключенному к системе, допускающей управление терминалом в режиме ожидания.
Ссылаясь на фиг. 21, после приема информации канала сообщения оповещения в операции A (1410) по фиг. 14 клиентская функция 1108a оповещений принимает сообщение радиовызова согласно блоку радиовызова сети взаимодействия или другой системы на этапе 2101. На этапе 2102 клиентская функция 1108a оповещений активирует приемное устройство широковещательной передачи в режиме ожидания посредством сообщения радиовызова и подготавливается к приему. Подготовка к приему включает в себя формирование сеанса с помощью NotificationPort и NotificationAddress, переданных способом, описанным во втором примерном варианте осуществления, и перехода в режим готовности. После перехода в режим готовности клиентская функция 1108a оповещения расшифровывает заголовок принимаемого IP-пакета после приема IP-пакета от функции распространения/адаптации 1103b оповещения на этапе 2103.
Клиентская функция 1108a оповещения определяет на этапе 2104, идентичен ли адрес IP-пакета IP-адресу, указанному из NotificationAddress. Если определено, что адрес в заголовке IP-пакета отличается от адреса в NotificationAddress, клиентская функция 1108a оповещения отбрасывает пакет на этапе 2108. Тем не менее, если IP-адрес IP-пакета идентичен IP-адресу NotificationAddress, клиентская функция 1108a оповещения расшифровывает заголовок UDP-пакета, извлеченный посредством декапсуляции IP-пакета на этапе 2105.
Клиентская функция 1108a оповещений определяет на этапе 2106 то, идентичен ли номер UDP-порта, полученный посредством расшифровки заголовка UDP-пакета, номеру UDP-порта NotificationPort. Этап 2106 выполняется для того, чтобы определить, является ли принимаемый пакет сообщением общего оповещения или некорректно переданным пакетом.
Если определено на этапе 2106, что номер порта принятого заголовка UDP-пакета идентичен NotificationPort, т.е. номеру UDP-порта, предназначенному для того, чтобы принимать сообщение общего оповещения, клиентская функция 1108a оповещения распаковывает UDP-пакет, чтобы получить сообщение оповещения, включенное в рабочие данные, и расшифровывает сообщение оповещения, чтобы выполнить требуемую операцию, на этапе 2107, а затем переходит к операции C (1430) по фиг. 14. Тем не менее, если номер порта принятого UDP-пакета отличается от номера порта NotificationPort, клиентская функция 1108a оповещения отбрасывает принимаемый UDP-пакет на этапе 2108, рассматривая его в качестве некорректно переданного UDP-пакета. Затем терминал переходит к операции C (1430) по фиг. 14. Операция C не относится к сущности примерного варианта осуществления настоящего изобретения, поэтому ее описание опущено.
Из вышеприведенного описания следует понимать, что примерный вариант осуществления настоящего изобретения устанавливает IP-адрес и UDP-порт для доставки сообщений оповещения в SGDD, чтобы предотвратить необходимость расшифровки всех заголовков принимаемого сигнала, снижая объем системной служебной информации и предоставляя возможность доставлять сообщение оповещения, даже когда терминал находится в режиме ожидания или взаимодействует с другой системой.
Примерные варианты осуществления настоящего изобретения могут быть осуществлены в вычислительной машине общего назначения посредством выполнения программы с машиночитаемого носителя, в том числе, но не только, запоминающих устройств, таких как магнитные запоминающие устройства (ПЗУ, ОЗУ, гибкие диски, магнитные ленты и т.д.), оптически считываемые запоминающие устройства (CD-ROM, DVD и т.д.), и волновые носители (передача по Интернету).
Несмотря на то что конкретные примерные варианты осуществления изобретения показаны и описаны со ссылкой в данном документе на конкретные предпочтительные варианты осуществления, специалистам в данной области техники следует понимать, что различные изменения по форме и содержанию могут быть сделаны без отступления от духа и области применения изобретения, заданной прилагаемой формулой изобретения и ее эквивалентами.