Устройство и способ для передачи/приема уведомляющего сообщения в системе цифрового видеовещания
Патент 2494547
Авторы
Правообладатели
Классы МПК
Устройство и способ для передачи/приема уведомляющего сообщения в системе цифрового видеовещания
Иллюстрации
Изобретение относится к устройству и способу для передачи/приема уведомляющего сообщения в системе цифрового видеовещания (DVB). Техническим результатом является обеспечение эффективной передачи/приема уведомляющего сообщения через интерактивную сеть в системе DVB. Указанный технический результат достигается тем, что передают сообщение запроса списка доставки уведомляющих сообщений на сервер; принимают список доставки уведомляющих сообщений, включающий в себя список из по меньшей мере одного уведомляющего сообщения, переданного за предварительно определенный период времени из сервера по интерактивной сети или широковещательной сети, в ответ на запрос и получают уведомляющее сообщение, которое должно быть принято, из сервера на основе списка из по меньшей мере одного уведомляющего сообщения, включенного в принятый список доставки уведомляющих сообщений. 4 н. и 16 з.п. ф-лы, 3 ил., 9 табл.
Реферат
УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ
1. Область техники, к которой относится изобретение
Настоящее изобретение относится к устройству и способу для передачи/приема уведомляющего сообщения в системе цифрового видеовещания (DVB). Более точно, настоящее изобретение относится к устройству и способу для передачи/приема уведомляющего сообщения по каналу связи в системе DVB.
2. Описание предшествующего уровня техники
Цифровое видеовещание (DVB) является европейской технологией цифрового вещания и поддерживает стандарт передачи для предоставления цифровой мультимедийной услуги через мобильное или портативное устройство, а также унаследованной услуги цифрового вещания.
Система DVB может одновременно мультиплексировать основанные на транспортном потоке (TS) стандарта 2 Экспертной группы по киноизображению вещательные данные и передавать основанные на межсетевом протоколе (IP) потоки данных. Система DVB также может передавать мультиплексированные данные из множества услуг в одном IP-потоке. Поэтому, терминал, который поддерживает систему DVB, принимает IP-поток, демультиплексирует IP-поток в данные отдельных услуг, демодулирует данные услуги и визуально выдает демодулированные данные услуги пользователю.
Могут существовать различные услуги для DVB. Одной из услуг является передача уведомляющих сообщений. Уведомляющее сообщение может включать в себя сообщение о чрезвычайной ситуации, уведомляющее сообщение о новой услуге, сообщение биржевой тикерной ленты, сообщение о погоде, и тому подобное.
Уведомляющее сообщение также включает в себя уведомляющее сообщение по умолчанию, которое все терминалы обычно принимают без регистрации в сети, у поставщика электронного справочника услуг (ESG) или поставщика платформы.
Уведомляющие сообщения также включают в себя сообщение имеющего отношение к услуге уведомления (SRN), которое терминал может принимать после процедур подписки и закупки. Как и в других услугах общего назначения, информация о SRN переносится в ESG. То есть, если в ESG существует SRN, услуга, связанная с SRN, информация о содержимом услуги и информация о сеансе, требуемая для приема SRN, включены в ESG.
Поэтому, пользователь терминала может находить намеченное уведомляющее сообщение в принятой ESG. Подобно другим услугам, пользователь может покупать уведомляющее сообщение в процедуре закупки.
Уведомляющее сообщение может принимать форму автономной услуги уведомления. То есть, скорее само уведомляющее сообщение определяется в качестве услуги, чем уведомляющее сообщение, связанное с любой услугой общего назначения. В этом случае, каждое уведомляющее сообщение идентифицируется идентификатором услуги (ServiceID), а не идентификатором сообщения (MessageID).
В настоящее время, определены только подписка на и прием уведомляющего сообщения по вещательному каналу, а передача уведомляющего сообщения по вещательному каналу еще только должна быть специфицирована.
Примерное уведомляющее сообщение является уведомляющим сообщением для «уведомления о времени начала подписной услуги». Примерное уведомляющее сообщение обеспечивает, чтобы покупатель услуги принимал вещательную услугу, заблаговременно предупреждая покупателя услуги о времени начала вещательной услуги.
Однако, в случае, где терминал покупателя услуги не присоединен к вещательной услуге, когда уведомляющее сообщение передается по вещательному каналу, терминал не может принимать уведомляющее сообщение. Поэтому, чтобы принимать каждое непредвиденное уведомляющее сообщение, терминал должен удерживаться присоединенным к вещательной услуге все время, несмотря на неэффективность этого.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Аспект настоящего изобретения состоит в том, чтобы принять меры в ответ на по меньшей мере упомянутые выше проблемы и/или недостатки, и чтобы обеспечить по меньшей мере преимущества, описанные ниже. Соответственно, аспект настоящего изобретения состоит в том, чтобы предоставить устройство и способ для передачи/приема уведомляющего сообщения в системе цифрового видеовещания (DVB).
В соответствии с аспектом настоящего изобретения, предложены устройство и способ для формирования сигнальной информации для доставки уведомляющего сообщения и передачи/приема сигнальной информации по каналу связи в системе DVB.
В соответствии с еще одним аспектом настоящего изобретения, предложены устройство и способ для передачи/приема уведомляющего сообщения через интерактивную сеть, а также уведомляющего сообщения по вещательному каналу в системе DVB.
В соответствии с еще одним другим аспектом настоящего изобретения, предложены устройство и способ для эффективной передачи/приема уведомляющего сообщения через интерактивную сеть в системе DVB.
В соответствии с еще одним другим аспектом настоящего изобретения, предложен способ для приема уведомляющего сообщения на терминале в системе DVB. Способ включает в себя выявление точки доступа (AP) из сеанса самозагрузки электронного справочника услуг (ESG), опрос AP для запрашивания списка уведомляющих сообщений либо целого или части уведомляющего сообщения по каналу связи и прием списка уведомляющих сообщений либо целого или части уведомляющего сообщения от AP.
В соответствии с еще одним другим аспектом настоящего изобретения, предложен способ для передачи уведомляющего сообщения на сервере в системе DVB. Способ включает в себя передачу сеанса самозагрузки ESG, в том числе, информации об AP на терминал, прием опроса касательно списка уведомляющих сообщений либо целого или части уведомляющего сообщения от терминала по каналу связи и передачу списка уведомляющих сообщений либо целого или части уведомляющего сообщения на терминал.
В соответствии с еще одним другим аспектом настоящего изобретения, предложена система для передачи и приема уведомляющего сообщения в системе DVB. Система включает в себя сервер для передачи сеанса самозагрузки ESG, в том числе, информации об AP на терминал и для приема опроса касательно запрашивания списка уведомляющих сообщений либо целого или части уведомляющего сообщения от терминала, и терминал для приема запрошенного списка уведомляющих сообщений любо всего или части запрошенного уведомляющего сообщения от AP, и сеть для передачи и приема опроса и запрошенного списка уведомляющих сообщений либо целого или части запрошенного уведомляющего сообщения по одному из канала связи и вещательного канала.
Другие аспекты, преимущества и выдающиеся признаки изобретения станут очевидными специалистам в данной области техники из последующего подробного описания, которое, взятое в соединении с прилагаемыми чертежами, раскрывает примерные варианты осуществления изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Вышеприведенные и другие аспекты, признаки и преимущества некоторых примерных вариантов осуществления настоящего изобретения станут более очевидными из последующего описания, взятого в соединении с прилагаемыми чертежами, на которых:
фиг.1 - блок-схема последовательности операций способа, иллюстрирующая операцию управления для приема уведомляющего сообщения на терминале в системе цифрового видеовещания (DVB), согласно примерному варианту осуществления настоящего изобретения;
фиг.2 - блок-схема последовательности операций способа, иллюстрирующая операцию управления для передачи уведомляющего сообщения на передатчике в системе DVB, согласно примерному варианту осуществления настоящего изобретения; и
Фиг.3 - структурная схема системы DVB согласно примерному варианту осуществления настоящего изобретения.
На всем протяжении чертежей, должно быть отмечено, что подобные номера ссылок используются для изображения одинаковых или подобных элементов, признаков и конструкций.
ПОДРОБНОЕ ОПИСАНИЕ ПРИМЕРНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
Последующее описание со ссылкой на прилагаемые чертежи приведено для содействия во всестороннем понимании примерных вариантов осуществления изобретения, которое определено формулой изобретения и ее эквивалентами. Соответственно, специалисты в данной области техники будут осознавать, что различные изменения и модификации вариантов осуществления, описанных в материалах настоящей заявки, могут быть произведены, не выходя из объема и сущности изобретения. В дополнение, описания широко известных функций и конструкций опущены для ясности и краткости.
Термины и слова, используемые в последующем описании и формуле изобретения, не ограничены библиографическими значениями, но используются заявителем, только чтобы дать возможность ясного и непротиворечивого понимания изобретения. Соответственно, специалистам в данной области техники должно быть очевидно, что последующее описание примерных вариантов осуществления настоящего изобретения приведено только с целью иллюстрации, а не с целью ограничения изобретения, которое определено прилагаемой формулой изобретения и ее эквивалентами.
Должно быть понятно, что формы единственного числа включают в себя многочисленные объекты ссылки, если контекст явно не предписывает иное. Таким образом, например, ссылка на «составляющую поверхность» включает в себя ссылку на одну или более таких поверхностей.
Несмотря на то, что примерные варианты осуществления настоящего изобретения описаны в контексте стандарта асинхронной мобильной связи, такого как основанная на Проекте партнерства 3его поколения (3GPP) система или система цифрового видеовещания (DVB), любая ссылка на них приведена только для содействия в понимании примерных вариантов осуществления настоящего изобретения. Соответственно, должно быть принято во внимание, что стандарты, системы и их наименования не ограничивают объем настоящего изобретения, и что настоящее изобретение применимо к любым другим стандарту или системе с подобным технологическим уровнем техники.
Примерные варианты осуществления настоящего изобретения предлагают способ и процедуру для передачи уведомляющего сообщения по каналу связи, такому как в интерактивной сети, а также по вещательному каналу, в системе DVB. Примерные варианты осуществления настоящего изобретения также предлагают способ и процедуру для приема уведомляющего сообщения по вещательному каналу или интерактивному каналу на терминале.
Система DVB использует по меньшей мере одно из обнаружения услуги наделенного возможностью вещательного приема терминала, подписку терминала на услугу, предоставление управляющей информации, требуемой для приема услуги, передачу услуги и прием услуги на терминале.
Для приема услуги, терминал принимает уведомляющее сообщение, несущее информацию о вещательной услуге. Уведомляющие сообщения являются уведомляющим сообщением по умолчанию и имеющим отношение к услуге уведомлением (SRN) для конкретной услуги.
Между тем, терминал принимает электронный справочник услуг (ESG) для запуска приема услуги. Некоторая информация может изменяться в любое время в ESG, и каждый раз, когда возникает изменение в отношении ESG, ESG должен передаваться на терминал. Принимая во внимание появление новых терминалов, принадлежащих к классу вещательных услуг, ESG повторно передается, даже если нет изменений в ESG.
Касательно уведомляющего сообщения по умолчанию, поэтому, примерные варианты осуществления настоящего изобретения указывают точку доступа (AP), от которой терминал может принимать уведомляющее сообщение по умолчанию по каналу связи. Уведомляющее сообщение по умолчанию, которое могут принимать все терминалы, в большинстве случаев, без какой бы то ни было подписки на их сети или поставщиков, может быть уведомлением по умолчанию сети (NDN), уведомление по умолчанию ESG (EDN) или уведомлением по умолчанию платформы (PDN).
В соответствии с примерными вариантами осуществления настоящего изобретения, информация об AP добавляется в сеанс самозагрузки ESG в системе DVB. Добавление информации об AP проиллюстрировано в первом и втором примерных вариантах осуществления настоящего изобретения, как определено в таблицах 1-6.
Между тем, после того, как терминал подписывается на и закупает конкретную услугу, он принимает SRN в модели данных ESG. Поскольку модель данных ESG передается через интерактивную AP, может быть определена AP для передачи SRN через интерактивную сеть. Соответственно, примерные варианты осуществления настоящего изобретения не предусматривают схему для добавления информации об AP в случае SRN.
В примерных вариантах осуществления настоящего изобретения, после того, как терминал получает информацию об AP из уведомляющего сообщения по умолчанию или SRN интерактивной сети, терминал может действовать, как изложено ниже.
Терминал запрашивает список уведомляющих сообщений (DeliveryList (Список доставки)) по примерным вариантам осуществления настоящего изобретения, или запрашивает передачу уведомляющего сообщения по умолчанию по интерактивному каналу, либо запрашивает часть уведомляющего сообщения, через AP.
Так как терминал принимает информацию только об AP, которая передает уведомляющее сообщение по умолчанию по вещательному каналу, он не может иметь гарантию, принял ли он уведомляющее сообщение по умолчанию успешно. Отсюда, терминал запрашивает DeliveryList и получает список уведомляющих сообщений по умолчанию, которые сервер передал или будет передавать на терминал в течение предопределенного периода времени, так что он может повторно запрашивать претерпевшее неудачу или ошибочное уведомляющее сообщение по каналу связи, то есть, через интерактивную сеть.
DeliveryList может быть расширен для SRN. Хотя терминал может определять SRN, которое должно приниматься, на основании набора информации об AP уведомляющего сообщения в ESG, он может не знать заблаговременно время передачи SRN ввиду природы SRN. В этом случае, терминал запрашивает DeliveryList для SRN и проверяет SRN в DeliveryList, чтобы, тем самым, иметь гарантию, что он принял SRN безошибочно, или повторно запрашивает ошибочный SRN.
В этом контексте, примерные варианты осуществления настоящего изобретения определяют новейший формат опроса протокола передачи гипертекста (HTTP) для запрашивания информации, показанный в таблицах 7A, 7B и 7C.
После передачи опроса на сервер, терминал принимает целое или часть запрошенного уведомляющего сообщения или DeliveryList от сервера. С таблицы 8A по таблицу 9 показывают синтаксисы и семантику расширяемого языка разметки (XML) предложенного DeliveryList.
<<Определение AP>>
Будет описан примерный вариант осуществления настоящего изобретения, в котором информация об AP добавляется в сеанс самозагрузки ESG.
Таблица 1 и таблица 4 перечисляют синтаксисы и семантику XML описателей для указания AP, от которой уведомляющее сообщение по умолчанию может приниматься в сеансе самозагрузки ESG. AP указывается посредством PDNIAEntry() и EDNIAEntry(), которые добавлены согласно примерным вариантам осуществления настоящего изобретения.
Синтаксисы PDNIAEntry() и EDNIAEntry() показаны в таблицах 2A, 2B и 2C, а также в таблицах 3A, 3B и 3C, соответственно, а семантика PDNIAEntry() и EDNIAEntry() показана в таблице 5.
Таблица 2A и таблица 2B определяют два примера синтаксиса PDNIAEntry(). Они отличаются тем, добавляют они или нет значение «IAmode», указывающее режим интерактивной передачи.
Таблица 3A и таблица 3B определяют два примера EDNIAEntry() согласно тому, имеют ли они дополнительное значение «IAmode».
В таблице 1, информация о PDNEntry() и EDNEntry() дает IP-адрес AP сервера, который широковещательно передает уведомляющее сообщение по умолчанию. С другой стороны, в таблицах с 2A по 3B, информация о PDNEntry() и EDNEntry() дает унифицированный указатель ресурса (URI) AP интерактивного сервера.
Два режима имеются в распоряжении для интерактивной передачи, «PUSH» и «PULL» («с активным источником данных» и «с пассивным источником данных»). В режиме с активным источником данных, сервер передает информацию на конкретный терминал, тогда как в режиме с пассивным источником данных, терминал производит запрос ради информации на сервер и принимает информацию от сервера. AP интерактивного сервера согласно примерным вариантам осуществления настоящего изобретения может выполнять два режима согласно характеристикам сервера.
Для указания поддерживаемой модели терминалу, сервер передает информацию 'IAmode' на терминал. Если 'IAmode' имеет значение «PUSH», терминал может быть осведомленным об адресе AP с сервера с активным источником данных и, таким образом, может считать активно доставляемый сигнал от сервера надежным. Если 'IAmode' имеет значение «PULL», терминал может быть осведомленным об AP согласно URL сервера, который он может опрашивать. Когда необходимо, терминал опрашивает AP (обратитесь к таблице 5).
По сравнению с вышеописанными примерными вариантами осуществления настоящего изобретения, информация 'Purchase_item_ID' ('Идентификатор_позиции закупки') передается в таблицах 2C и 3C, так что поставщик услуг может начислять плату за уведомляющее сообщение по умолчанию, когда оно передается в интерактивную сеть.
Помимо уведомляющего сообщения по умолчанию, передаваемого через вещательную сеть без подписки, уведомляющее сообщение, передаваемое через интерактивную сеть, может требовать процедур подписки и закупки. Процедура закупки выполняется посредством идентификации 'Purchase_item_ID' для каждой позиции закупки. Поэтому, 'Purchase_item_ID' выделяется для каждой записи уведомляющего сообщения по умолчанию, чтобы сделать функцию жизнеспособной. 'Purchase item_ID' может быть специфичной для каждого уведомляющего сообщения по умолчанию.
Описанные выше примерные варианты осуществления настоящего изобретения воплощены в контексте основной информации. Синтаксисы, описанные в примерных вариантах осуществления, могут использоваться в комбинации. То есть, кроме информации базовой записи сообщения по умолчанию, могут совместно использоваться 'IAmode' и 'Purchase item_ID'.
| Таблица 1 | ||
| Синтаксис описателя доступа к уведомлению по умолчанию (DefaultNotificationAccessDescriptor) | ||
| Синтаксис | Число бит | Мнемоника |
| DefaultNotificationAccessDescriptor { | ||
| PDNFlag | 1 | uimsbf |
| Reserved | 7 | uimsbf |
| n_o_EDNEntries | 8 | uimsbf |
| If(PDNFIag){ | ||
| PDNEntry() | ||
| PDNIAEntry() | ||
| } | ||
| For(i=0;i< n_o_ EDNEntries;i++){ | ||
| EDNEntry[i]() | ||
| EDNIAEntry[i]() | ||
| } | ||
| } |
| Продолжение таблицы 1 | ||
| Синтаксис | Число бит | Мнемоника |
| PDNEntry{ | ||
| PDNEntryversion | 8 | uimsbf |
| EntryLength | 8+ | vluimsbf8 |
| IPVersion6 | 1 | bslbf |
| Reserved | 7 | bslbf |
| If(IPVersion6){ | ||
| SourceIP Address | 128 | bslbf |
| DestinationIPAddress | 128 | bslbf |
| }else{ | ||
| SourceIPAddress | 32 | bslbf |
| DestinationIPAddress | 32 | bslbf |
| } | ||
| Port | 16 | uimsbf |
| TSI | 16 | uimsbf |
| } | ||
| } |
| Продолжение таблицы | ||
| Синтаксис | Число бит | Мнемоника |
| EDNEntry{ | ||
| EDNEntryVersion | 8 | uimsbf |
| EntryLength | 8+ | vluimsbf8 |
| ProviderID | 16 | uimsbf |
| IPVersion6 | 1 | bslbf |
| Reserved | 7 | bslbf |
| If(IPVersion6){ | ||
| SourceIPAddress | 128 | bslbf |
| DestinationIPAddress | 128 | bslbf |
| }else{ | ||
| SourceIPAddress | 32 | bslbf |
| DestinationIPAddress | 32 | bslbf |
| } | ||
| Port | 16 | uimsbf |
| TSI | 16 | uimsbf |
| } | ||
| } | ||
| Таблица 2A | ||
| Синтаксис PDNIAEntry | ||
| Синтаксис | Число бит | Мнемоника |
| PDNIAEntry{ | ||
| PDNIAIAEntryversion | 8 | uimsbf |
| EntryLength | 8+ | vluimsbf8 |
| Reserved | 8 | bslbf |
| For(i=0; i<URILength ; i++){ | ||
| URIByte | ||
| } | ||
| } |
| Таблица 2B | ||
| Синтаксис PDNIAEntry | ||
| Синтаксис | Число бит | Мнемоника |
| PDNIAEntry { | ||
| Iamode | 1 | bslbf |
| Reserved | 7 | bslbf |
| PDNIAEntryversion | 8 | uimsbf |
| EntryLength | 8+ | vluimsbf8 |
| Reserved | 8 | bslbf |
| For(i=0; i<URILength ; i++){ | ||
| URIByte | ||
| } | ||
| } |
| Таблица 2C | ||
| Синтаксис PDNIAEntry | ||
| Синтаксис | Число бит | Мнемоника |
| PDNIAEntry{ | ||
| Purchase_item_ID | 8 | uimsbf |
| PDNIAEntryversion | 8 | uimsbf |
| EntryLength | 8+ | vluimsbf8 |
| Reserved | 8 | bslbf |
| For(i=0; i<URILength ; i++){ | ||
| URIByte | ||
| } | ||
| } |
| Таблица 3A | ||
| Синтаксис EDNIAEntry | ||
| Синтаксис | Число бит | Мнемоника |
| EDNIAEntry { | ||
| EDNIAEntryversion | 8 | uimsbf |
| EntryLength | 8+ | vluimsbf8 |
| ProviderID | 16 | vluimsbf8 |
| Reserved | 8 | bslbf |
| For(i=0; i<URILength ; i++){ | ||
| URIByte | ||
| } | ||
| } |
| Таблица 3B | ||
| Синтаксис EDNIAEntry | ||
| Синтаксис | Число бит | Мнемоника |
| EDNIAEntry{ | ||
| Iamode | 1 | bslbf |
| Reserved | 7 | bslbf |
| EDNIAEntryversion | 8 | uimsbf |
| EntryLength | 8+ | vluimsbf8 |
| ProviderID | 16 | vluimsbf8 |
| Reserved | 8 | bslbf |
| For(i=0; i<URILength; i++){ | ||
| URIByte | ||
| } | ||
| } |
| Таблица 3C | ||
| Синтаксис EDNIAEntry | ||
| Синтаксис | Число бит | Мнемоника |
| EDNIAEntiy{ | ||
| Purchase_item_ID | 8 | uimsbf |
| EDNIAEntryversion | 8 | uimsbf |
| EntryLength | 8+ | vluimsbf8 |
| ProviderID | 16 | vluimsbf8 |
| Reserved | 8 | bslbf |
| For(i=0; i<URILength; i++){ | ||
| URIByte | ||
| } | ||
| } |
| Таблица 4 | |
| Семантика описателя доступа к уведомлению по умолчанию | |
| Поле | Семантика |
| PDNFlag | Указывает, есть ли запись PDN в текущем описателе. Если установлен в «1», есть запись PDN, сопровождающая поле «n_o_EDNEntries». |
| n_o_EDNEntries | Задает количество записей EDN, в которых сигнализируется информация об услуге EDN. |
| n_o_IAEDNEntries | Задает количество записей EDN, в которых информация о доступе услуги EDN сигнализируется по интерактивному каналу. |
| PDNEntryVersion | Задает версию спецификации записи PDN. Значение должно быть установлено в «1».ПРИМЕЧАНИЕ 1: Эта версия инкрементируется, если спецификация записи PDN изменяется некоторым образом, который не является совместимым снизу вверх;ПРИМЕЧАНИЕ 2: Приемник должен декодировать только записи PDN, которым он соответствует. |
| EDNEntry Version | Задает версию спецификации записи EDN. Значение должно быть установлено в «1».ПРИМЕЧАНИЕ 3: Эта версия инкрементируется, если спецификация записи EDN изменяется некоторым образом, который не является совместимым снизу вверх;ПРИМЕЧАНИЕ 4: Приемник должен декодировать только записи EDN, которым он соответствует. |
| EntryLength | Задает длину записи PDN/EDN в байтах, исключая поля PDNEntryVersion/EDNEntryVersion и EntryLength.ПРИМЕЧАНИЕ 5: Это предоставляет возможность совместимых снизу вверх реализаций, даже если в будущем к DefaultNotificationAccessDescriptor добавляются поля. |
| IPVersion6 | Если установлено в «1», это задает, что SourceIPAddress и DestinationIPAddress сигнализируются согласно версии 6 IP. Если установлено в «0», это задает, что SourceIPAddress и DestinationIPAddress сигнализируются согласно версии 4 IP. |
| ProviderID | Этот ID используется, чтобы уникально идентифицировать поставщика ESG в ESGProviderDiscoveryDescriptor. Поставщик ESG должен регистрировать ProviderID в службе, которая управляет каналом самозагрузки, чтобы гарантировать уникальность. |
| SourceIPAddress | Задает IP-адрес источника сеанса FLUTE, транспортирующего сообщения PDN/EDN. Версия IP сигнализируется полем IPVersion6. |
| DestinationIPAddress | Задает IP-адрес пункта назначения сеанса FLUTE, транспортирующего сообщения PDN/EDN. Версия IP сигнализируется полем IPVersion6. |
| Port | Задает номер порта IP-потока сеанса FLUTE, в котором транспортируются сообщения PDN/EDN. |
| TSI | Задает идентификатор сеанса транспортировки (TSI) сеанса FLUTE, в котором транспортируются сообщения PDN/EDN. |
| Таблица 5 | |
| Семантика с таблицы 2A по таблицу 3C | |
| Поле | Семантика |
| IAmode | Если режимом доставки является IA PULL, значение должно быть установлено в «1». В случае PUSH, значение должно быть установлено в «0». |
| PDNIAEntryVersion | Задает версию спецификации записи PDNIA. Значение должно быть установлено в «1».ПРИМЕЧАНИЕ 1: Эта версия инкрементируется, если спецификация записи PDNIA изменяется некоторым образом, который не является совместимым снизу вверх;ПРИМЕЧАНИЕ 2: Приемник должен декодировать только записи PDNIA, которым он соответствует. |
| EDNIAEntryVersion | Задает версию спецификации записи EDNIA. Значение должно быть установлено в «1».ПРИМЕЧАНИЕ 3: Эта версия инкрементируется, если спецификация записи EDNIA изменяется некоторым образом, который не является совместимым снизу вверх;ПРИМЕЧАНИЕ 4: Приемник должен декодировать только записи EDNIA, которым он соответствует. |
| EntryLength | Задает длину записи PDNIA/EDNIA в байтах, исключая поля PDNIAEntryVersion/ EDNIAEntryVersion и EntryLength. |
| ProviderID | Этот ID используется, чтобы уникально идентифицировать поставщика ESG в ESGProviderDiscoveryDescriptor. Поставщик ESG регистрирует ProviderID в службе, которая управляет каналом самозагрузки, чтобы гарантировать уникальность. |
| URIByte | Байты URI, формирующие закодированный в UTF-8 URL интерактивной точки доступа интерактивного уведомления по умолчанию. |
| Purchase_item_ID | Идентифицировать PDNIAEntry или EDNIAEntry. Эта информация используется в качестве идентификатора для закупки интерактивного уведомления по умолчанию. |
<Вариант 2 осуществления>
Таблица 6 показывает еще один примерный вариант осуществления настоящего изобретения, который добавляет информацию об AP в сеанс самозагрузки ESG.
В первом и втором примерных вариантах осуществления настоящего изобретения, информация определена одинаково. Чтобы быть более точным, PDNIAEntry() и EDNIAEntry[i]() определены в DefaultNotificationAccessDescriptor в первом примерном варианте осуществления настоящего изобретения наряду с тем, что DefaultNotificationIAAccessDescriptor определены во втором примерном варианте осуществления настоящего изобретения.
| Таблица 6 | ||
| Синтаксис описателя доступа к уведомлению IAIA по умолчанию | ||
| Синтаксис | Число бит | Мнемоника |
| DefaultNotificationIAAccessDescriptor { | ||
| PDNFlag | 1 | uimsbf |
| Reserved | 7 | uimsbf |
| n_o_IAEDNEntries | 8 | uimsbf |
| If(PDNFlag){ | ||
| PDNIAEntry() | ||
| } | ||
| For(i=0;i< n_o_IAEDNEntries;i++){ | ||
| EDNIAEntry[i]() | ||
| } | ||
| } |
<<Определение формата опроса HTTP>>
Таблицы 7A, 7B и 7C являются форматами опроса для уведомляющего сообщения, предложенными в примерных вариантах осуществления настоящего изобретения согласно их применениям. При допущении, что HTTP/1.1 POST используется в качестве протокола, примерные варианты осуществления настоящего изобретения определяют значения 'Key' ('Ключ'), значения 'Value' ('Значение') у значений 'Key' и их семантику. Множество значений ключей может использоваться одновременно и может использоваться избирательно по запросу терминала.
Как показано в таблицах 7A, 7B и 7C, если терминал запрашивает «type=NotificationDeliveryList», он может запрашивать DeliveryList уведомляющих сообщений, переданных за предопределенный период времени, устанавливая тип «NotiType=EDN» уведомляющего сообщения или устанавливая «StartDelivery» и «StopDelivery».
Если терминал запрашивает «type=NotificationMessage», он может запрашивать информацию уведомляющего сообщения или повторную часть ошибочной части уже принятого уведомляющего сообщения, устанавливая MessageID или указывая часть уведомляющего сообщения с MessageID, с использованием Content-ID и Content-Position.
Если терминала запрашивает «type=NotificationInitContainer», сервер может передавать адрес, по которому терминал может принимать InitContainer или он может передавать InitContainer непосредственно на терминал.
Если «type=DefaultNotification», это формат опроса, посредством которого терминал запрашивает, чтобы все уведомляющие сообщения по умолчанию, передаваемые по вещательной сети, должны были передаваться по интерактивной сети.
| Таблица 7A | ||
| Формат опроса уведомления IA | ||
| Ключ | Значение | Семантика |
| Type | Notification DeliveryListNotification MessagesNotification Init ContainerDefault Notification | Тип ожидаемого ответа, например, если запрошены список или контейнеры доставки уведомлений. |
| NotiType | NDN (уведомление по умолчанию сети)PDN (уведомление по умолчанию платформы)EDN (уведомление по умолчанию поставщика ESG)All DN | Запрашивается тип уведомляющих сообщений или список доставки. Возможны многочисленные значения, разделенные запятой. 'All DN' означает все типы уведомлений по умолчанию. |
| MessageID | 16-битное положительное целое число | ID запрошенного уведомляющего сообщения. |
| MessageVersion | Беззнаковый байт | Номер версии уведомляющего сообщения. |
| Content-ID | любой URI | ID части уведомляющего сообщения. |
| Content-Position | 16-битное положительное целое число | Индекс составной/связанной части сообщения, которая содержит в себе соответствующую часть уведомляющего сообщения. |
| Content-Type | Строка | Указывает тип многоцелевых расширений электронной почты (MIME) соответствующей части уведомляющего сообщения. |
| Content-Transfer-Encoding | Строка | Указывает тип кодирования передачи контента, применяемого для соответствующей части уведомляющего сообщения. |
| Subscription information | Строка | Связанная с подпиской информация, например тип валюты цены, тип закупки и т. д. |
| StartDelivery | Date&Time (временная отметка протокола сетевого времени (NTP), беззнаковое целое) | Время начала интересующего периода, это время основано на времени доставки уведомляющего сообщения, для сообщений или для списка доставки. |
| StopDelivery | Date&Time (временная отметка NTP, беззнаковое целое) | Время конца интересующего периода, это время основано на времени доставки уведомляющего сообщения для сообщений или для списка доставки. |
| ValidFrom | Date&Time (временная отметка NTP, беззнаковое целое) | Время начала интересующего периода, это время основано на времени истечения. |
| ValidTo | Date&Time (временная отметка NTP, беззнаковое целое) | Время конца интересующего периода, это время основано на времени истечения уведомляющего сообщения. |
| DeliveryListVersion | ЗначениеdateTime (временная отметка NTP, беззнаковое целое) | Последний обновленный вариант DeliveryList. |
Таблица 7B показывает примерный вариант осуществления настоящего изобретения, в котором устранена информация, требуемая для приемной части уведомляющего сообщения, то есть, Content-ID, Content-Position, Content-Type и Content-Transfer-Encoding. Когда предполагается, что терминал должен запрашивать целое уведомляющее сообщение, указывается, что формат опроса, показанный в таблице 7A, не используется в примерном варианте осуществления настоящего изобретения.
| Таблица 7B | ||
| Формат опроса уведомления IA | ||
| Ключ | Значение | Семантика |
| Type | Notification DeliveryListNotification MessagesNotification Init ContainerDefault Notification | Тип ожидаемого ответа, например, если запрошены Notification Delivery List или контейнеры |
| NotiType | NDN (Уведомление по умолчанию сети)PDN (Уведомление по умолчанию платформы)EDN (Уведомление по умолчанию поставщика ESG)All DN | Запрашивается тип уведомляющих сообщений или список доставки.Возможны многочисленные значения, разделенные запятой.'All DN' означает все типы уведомлений по умолчанию. |
| MessageID | 16-битное положительное целое число | ID запрошенного уведомляющего сообщения. |
| MessageVersion | Беззнаковый байт | Номер версии уведомляющего сообщения. |
| Subscription information | Строка | Связанная с подпиской информация, например тип валюты цены, тип закупки и т. д. |
| StartDelivery | Date&Time (временная отметка NTP, беззнаковое целое) | Время начала интересующего периода, это время основано на времени доставки уведомляющего сообщения для сообщений или для списка доставки. |
| StopDelivery | Date&Time (временная отметка NTP, беззнаковое целое) | Время конца интересующего периода, это время основано на времени доставки уведомляющего сообщения для сообщений или для списка доставки. |
| ValidFrom | Date&Time (временная отметка NTP, беззнаковое целое) | Время начала интересующего периода, это время основано на времени истечения уведомляющего сообщения. |
| ValidTo | Date&Time (временная отметка NTP, беззнаковое целое) | Время конца интересующего периода, это время основано на времени истечения уведомляющего сообщения. |
| DeliveryListVersion | Значение LASTUPDATED dateTime (временная отметка NTP, беззнаковое целое) | Последний обновленный вариант списка доставки |
Таблица 7C идентична таблице 7A за исключением добавления имеющего отношение к услуге уведомления (SRN) и услуги уведомления (NS), а также добавления ServiceID.
То есть, таблица 7C является расширением, которое дает терминалу возможность запрашивать DeliveryList или уведомляющее сообщение ради SRN и NS, а также уведомляющее сообщение по умолчанию. NS имеет ServiceID подобно услуге общего назначения. В этом случае, формат опроса может быть определен добавлением ServiceID вместо MessageID.
| Таблица 7C | ||
| Формат опроса уведомления IA | ||
| NotiType | NDN (Уведомление по умолчанию сети)PDN (Уведомление по умолчанию платформы)EDN (Уведомление по умолчанию поставщика ESG)SRN (Имеющее отношение к услуге уведомление)NS (Услуга уведомления)ВсеAll DN | Запрашивается тип уведомляющих сообщений или список доставки.Многочисленные значения возможны и разделены запятой. |
| ServiceID | Notification Service ID |
Несмотря на то, что не показано особо, форматы опороса, показанные в таблицах 7A, 7B и 7C, могут использоваться в комбинации.
<<Определение DeliveryList>>
С таблицы 8A по таблицу 8E описывают синтаксисы XML предложенного DeliveryList. Таблица 9 описывает семантику DeliveryList, показанного в таблице с 8A по 8E.
Таблица 8A показывает DeliveryList для уведомляющих сообщений, передаваемых по интерактивной сети, а таблица 8B определяет DeliveryList, расширенный для вещательной сети. Таблица 8C описывает примерный вариант осуществления настоящего изобретения без SubListSubList (подсписка). SubList является схемой для передачи DeliveryList во множестве сегментов, когда DeliveryList слишком велик. Несмотря на то, что таблица 8C показывает DeliveryList для уведомляющих сообщений, передаваемых по интерактивной сети, он может быть применен к DeliveryList без Sublist, расширенного для вещательной сети.
Таблица 8D показывает примерный вариант осуществления настоящего изобретения, исключающий версию DeliveryList и связанные с истечением атрибуты. Поскольку DeliveryList является перечисляющим уведомляющие сообщения, передаваемые/должные быть переданными в установленные терминалом и установленные пользователем моменты времени, информация о версии DeliveryList может не быть необходимой. По синтаксисам в таблице 8D наблюдается, что атрибуты 'lastupdated', 'expirationDate' и 'expirationWindow' не передаются.
Таблица 8E показывает примерный вариант осуществления настоящего изобретения, в котором информация о цене и закупке предоставлена в качестве информации о запрошенном терминалом уведомляющем сообщении. Помимо информации о цене, на таблице 8D основана другая информация. Кроме то