Система и способ для объединения пассивного и активного режимов
Изобретение относится области передачи цифровой информации, а именно к загрузке контента в системе связи с использованием сочетания push- и pull-режимов. Технический результат заключается повышении эффективности оптимизирования использования полосы пропускания сети за счет плавного (непрерывного) переключения между режимами для продолжения загрузки контента. Для этого способ загрузки контента в системе (10) связи, содержащей первый терминал (1), по меньшей мере второй терминал (2) и сервер (5, 8) контента, причем упомянутый способ на уровне первого терминала содержит этапы, на которых загружают контент в pull-режиме с сервера контента или по меньшей мере второго терминала; и продолжают загрузку этого контента в push-режиме, без необходимости запрашивания какой-либо дополнительной информации, когда push-режим запускается на сервере контента. Аналогично, если загружают контент в push-режиме с сервера контента, то продолжают загрузку этого контента в pull-режиме с сервера контента или по меньшей мере второго терминала, без необходимости запрашивания какой-либо дополнительной информации, когда доступен pull-режим. 4 н. и 5 з.п. ф-лы, 4 ил., 3 табл.
Настоящее изобретение в целом относится к загрузке контента, и, в частности, к использованию сочетания пассивного (pull) и активного (push) способов.
Это раздел предназначен для знакомства читателя с различными особенностями области техники, которые могут относиться к различным особенностям настоящего изобретения, которые описываются и/или заявляются ниже. Данное обсуждение считается полезным в обеспечении читателя вводной информацией для содействия лучшего понимания различных особенностей настоящего изобретения. Соответственно, следует понимать, что эти утверждения нужно понимать в этом аспекте, а не как признание предшествующего уровня техники.
Распространение контента между сервером и несколькими приемниками требует установления либо двухточечного соединения между сервером и каждым приёмником, либо многоточечного соединения. Двухточечное соединение позволяет распространять контент индивидуальным способом каждому приёмнику и обеспечивает надежное распространение; в дальнейшем это называется pull-режимом, и обычно клиенты являются активными инициаторами. Однако при значительном количестве приемников требуется сложное управление всеми соединениями. Это также может значительно увеличить трафик в сети. Многоадресное распространение обеспечивает меньшую сетевую нагрузку с менее надежным распространением. В дальнейшем это называется push-режимом.
Оператор услуги, который управляет сервером, не может точно предсказать поведение приемников. В сеансе push-доставки контента приемники могут исключаться из полной или частичной загрузки контента по следующим причинам: приемники выключаются во время push-распространения; приемники включаются, когда происходит push-распространение; вся зарезервированная полоса пропускания не доступна для push-распространения, например пользователь STB смотрит одну программу наряду с записью другой; приемники испытывают недостаток пространства хранения во время push-распространения; приемники полностью используют CPU во время push-распространения; сети не в состоянии обработать многоадресный трафик и т.д. Чтобы оптимизировать полосу пропускания, оператору может потребоваться выбрать, поддерживать ли push-сеанс или остановить его. Остановка push-сеанса позволяет оператору выделить сети большой объем трафика, и приемники, которые пропустили контент, могут вернуть его, используя режим исправления. Способ исправления определен в европейской заявке на патент с номером 06291464.3. С другой стороны, в pull-режиме оператору может потребоваться быть готовым к максимальному спросу на контент. Для оператора тогда может быть лучше эффективно оптимизировать использование полосы пропускания сети и задержку размещения с помощью многоадресной передачи этого контента в push-режиме вместо использования pull-режима.
Настоящее изобретение имеет отношение к способу для эффективного переключения между pull-режимом и push-режимом.
С этой целью изобретение относится к способу для загрузки контента в системе связи, содержащей первый терминал, по меньшей мере второй терминал и сервер контента. Способ на уровне первого терминала содержит этапы загрузки контента либо в pull-режиме с сервера контента или по меньшей мере второго терминала, либо в push-режиме с сервера контента; и плавного переключения между режимами для продолжения загрузки контента.
В этом контексте "плавно" означает, что терминал непрерывно переключается с одного режима на другой режим без необходимости запроса любой дополнительной информации.
В соответствии с вариантом осуществления, способ содержит этап загрузки контента в push-режиме и продолжение загрузки контента в pull-режиме, когда push-режим останавливается на сервере контента.
Когда оператор останавливает push-сеанс, терминал продолжает загрузку без большого перерыва. Он получил достаточно информации во время push-сеанса для переключения и управления режимом pull-загрузки.
В соответствии с другим вариантом осуществления, способ содержит этап загрузки контента в pull-режиме и продолжение загрузки контента в push-режиме, когда push-режим запускается на сервере контента.
В соответствии с вариантом осуществления, способ содержит этап приема push-контента в сеансовой доставке в соответствии с протоколом FLUTE и прием информации в Таблице доставки файлов, FDT, во время сеансовой доставки, позволяющей переключиться в pull-режим.
FDT содержит дополнительную информацию, необходимую для плавного переключения в pull-режим. Когда останавливается push-режим, терминалу не нужно извлекать никакой дополнительной информации. Он уже принял соответствующую информацию с FDT для переключения в pull-режим.
В соответствии с вариантом осуществления, способ содержит этап проверки целостности экземпляра FDT; указание индексирующему серверу, успешно ли принят экземпляр FDT, и указание индексирующему серверу, успешно ли принят файл, ассоциированный с экземпляром FDT.
В соответствии с вариантом осуществления, способ при обнаружении экземпляра FDT, который поврежден, содержит этап ожидания окончания доставки файла и выполнение исправления экземпляра FDT в pull-режиме.
В соответствии с вариантом осуществления, способ при обнаружении поврежденной полной FDT содержит этап ожидания окончания сеансовой доставки и выполнение исправления полной FDT в pull-режиме.
В соответствии с вариантом осуществления, способ содержит этап приема pull-контента в соответствии с протоколом однорангового взаимодействия и прием файла с одноранговой метаинформацией, содержащей информацию, позволяющую переключение в push-режим.
Настоящее изобретение также имеет отношение к терминалу, содержащему средство для загрузки контента в push-режиме; средство для загрузки контента в pull-режиме и средство для плавного переключения из одного режима в другой режим.
Другая цель изобретения - компьютерный программный продукт, содержащий команды программного кода для выполнения этапов процесса в соответствии с изобретением, когда эта программа выполняется на компьютере. Под "компьютерным программным продуктом" подразумевается носитель компьютерной программы, который может состоять не только из пространства хранения, содержащего программу, такого как дискета или кассета, но также из сигнала, например электрического или оптического сигнала.
Некоторые особенности, сопоставимые по содержанию с раскрытыми вариантами осуществления, излагаются ниже. Следует понимать, что эти особенности представляются лишь для предоставления читателю сущности некоторых форм, которые может принимать изобретение, и что эти особенности не предназначены для ограничения объема изобретения. В действительности, изобретение может включать в себя ряд особенностей, которые могут быть не изложены ниже.
Изобретение будет лучше понято и проиллюстрировано посредством следующего варианта осуществления и примеров выполнения, никоим образом не ограничивающих, со ссылкой на прилагаемые чертежи, на которых:
Фиг.1 - блок-схема системы, совместимой с вариантом осуществления;
Фиг.2 представляет терминал в соответствии с вариантом осуществления;
Фиг.3 - схема последовательности операций, иллюстрирующая pull-режим; и
Фиг.4 - схема последовательности операций, иллюстрирующая сочетание push- и pull-режимов.
На Фиг. 1 и 2 изображенные блоки являются чисто функциональными сущностями, которые не обязательно соответствуют физически отдельным сущностям. А именно они могли бы быть разработаны в виде программного обеспечения или реализованы в одной или нескольких интегральных схемах.
Фиг.1 представляет архитектуру системы 10 связи, согласно варианту осуществления, для распространения контента. Терминалы 1, 2, 3 содержат клиентские приложения. В частности, они содержат функцию телеприставки (STB). В дальнейшем в варианте осуществления терминал является STB, но вариант осуществления не ограничивается такими терминалами. Он применим к устройству, которое содержит клиентское приложение для загрузки данных с сервера контента.
Терминал также содержит средство для загрузки контента в push-режиме и средство для загрузки контента в pull-режиме. Он выполняет pull- и push-функции, которые описаны ниже.
Система содержит push-сервер 5 контента и pull-сервер 8 контента. Pull-сервер контента приспособлен для распространения контента в pull-режиме. Он содержит средство для установления двухточечного соединения с несколькими клиентами. Push-сервер контента приспособлен для распространения контента в push-режиме. Конечно, эти серверы могут содержаться в одном и том же устройстве.
Роль Индексирующего сервера 6 состоит в том, чтобы связать одноранговые STB друг с другом для выполнения восстановления или извлечения контента. Роль Индексирующего сервера в том, чтобы связать одноранговые узлы, необходимые для восстановления файлов или частей файлов, с одноранговыми узлами, способными предоставить отсутствующую информацию. Индексирующий сервер не хранит никаких файлов контента, он действует в качестве централизованного индекса для хранения информации о расположении файлов. Pull-протокол требует, чтобы Индексирующий сервер информировался каждой STB о состоянии загрузки контента. В соответствии с вариантом осуществления, система содержит только один Индексирующий сервер. Сеть может иметь несколько Индексирующих серверов, чтобы оптимизировать доступ, например, по географической области или по типу контента. Один и тот же Индексирующий сервер используется в среде push-режима, а также в среде pull-режима.
Сервер 7 обнаружения сервисов, в дальнейшем обозначенный SD&S, приспособлен для выполнения механизма обнаружения и выбора сервисов, как указано в стандарте ETSI TS 102 034 V1.2.1 (2006-09), "Digital Video Broadcasting (DVB), Transport of MPEG-2 Based DVB Services over IP Based Networks" (Цифровое видеовещание (DVB), Доставка DVB-услуг на основе MPEG-2 по IP-сетям).
В соответствии с вариантом осуществления, один и тот же сервер SD&S используется в среде push-режима, а также в среде pull-режима.
Фиг.2 представляет компоновочные блоки терминала в соответствии с вариантом осуществления. Терминал содержит средство 1.1 хранения, среду 1.2 связи, средство 1.3 обработки и внутреннюю шину 1.4. Средство хранения предназначено для хранения программы, которая позволяет терминалу загружать файл либо в push-, либо в pull-режиме. Таким образом, терминал содержит средство 1.6 push-загрузки и средство 1.5 pull-загрузки. Он содержит средство 1.7 для переключения из одного режима в другой режим.
Сейчас описывается pull-способ. Он основывается на одноранговой стратегии, обозначенной P2P.
Чтобы выполнить pull-способ, терминал сначала выполняет фазу обнаружения адреса Индексирующего сервера. STB находит контент для загрузки путем просмотра каталога контента, доступного для загрузки. Адрес каталога обнаруживается с использованием Данных справочника широкополосного контента DVB-IP, которые указаны в ETSI TS 102 034 V1.2.1 (2006-09) и ETSI TS 102 539 V1.1.1, Цифрового видеовещания (DVB); Доставки информации Справочника широкополосного контента (BCG) по Интернет-протоколу (IP); который описывает транспортировку и передачу сигналов справочников контента применительно к DVB-IP. Терминал находит адрес Индексирующего сервера в каталоге. Конечно, адрес Индексирующего сервера может быть обнаружен другими средствами, например данными предложения о загрузке контента, которые доставляются с помощью передачи сигналов DVB-IP/SD&S.
Для повышения возможности загрузки большого контента каждый файл контента разделяется на блоки меньшего размера. Одноранговые узлы затем могут принимать и проверять блоки контента, а затем обмениваться этими блоками перед приемом контента полностью или частично. По каждому блоку вычисляется хэш-код. Метаинформация, которая указана в таблице 1, хранится в виде файла на Сервере контента. Метаинформация содержит всю информацию, необходимую для выполнения файлового обмена в одноранговой сети. Операция хэширования может выполняться сервером контента.
Нижеследующая таблица представляет метаинформацию контента в соответствии с вариантом осуществления. Поля TSI и TOI определяются в протоколе FLUTE; они являются необязательными. Они используются здесь для поддержки плавного переключения между pull- и push-режимами. Поля Content-Block-Length, Content-Block-Digests, File-Name, File-Length, File-Digest, File-Block-Length и File-Block-Digests являются минимальной метаинформацией, необходимой для протокола P2P.
| Таблица 1 | |
| Наименование | Описание |
| Multi-Files-Attributes | Атрибуты, имеющие отношение к нескольким файлам |
| Meta-information-length | Размер файла с метаинформацией |
| Content-Type | Тип файлов контента |
| Content-Encoding | Сжатие |
| Client-Id | Для задания загрузки контента в зависимости от идентификатора клиента (HW, SW, Профиль и т.д.) |
| Content-Block-Length | Размер блока |
| Content-Block-Digests (одно на блок) | Хэш блоков (SHA1, …) |
| File-Attributes (одно на файл) | Атрибуты, имеющие отношение к самому файлу |
| File-Type | MIME-тип файла |
| File-Encoding | Сжатие |
| Client-Id | Для задания загрузки файла в зависимости от идентификатора клиента (HW, SW, Профиль и т.д.) |
| TSI | Идентификатор транспортного сеанса. Однозначно определяет сеанс FLUTE для заданного IP-адреса источника |
| TOI | Идентификатор транспортного объекта |
| File-Name | Идентификация и расположение файла для загрузки, например URI |
| File-Length | Размер файла |
| File-Digest | Хэш файла (например, SHA1, …) |
| File-Block-Length | Размер блока |
| File-Block-Digests (одно на блок) | Хэш блоков (SHA1, …) |
| Meta-Info-Digest | |
| Meta-Info-Digest | Хэш метаинформации (например, MD5, SHA1, …) |
Поле Meta-Info-Digest может использоваться для передачи подписи RSA, чтобы позволить аутентификацию файла с метаинформацией.
Способ для загрузки файла происходит следующим образом, как описано на Фиг.3.
Этап S1. STB 1 отправляет запрос выбранного контента к Индексирующему серверу.
Этап S2. Индексирующий сервер отвечает STB адресом одноранговой STB 2, способной предоставить метаинформацию о контенте. Конечно, Индексирующий сервер мог бы предоставить адрес нескольких одноранговых узлов.
STB 1 инициирует соединение с указанным одноранговым узлом, Этап S3. Она извлекает файл с метаинформацией на Этапе S4, проверяет целостность на Этапе S5, сохраняет этот файл и уведомляет Индексирующий сервер о приеме метаинформации, Этап S6. STB 1 хранит этот файл в памяти, пока не удалится ассоциированный с ним контент.
С помощью этого файла с метаинформацией STB может запросить любой байтовый диапазон блока у других одноранговых узлов и проверить целостность принятых данных. После того как STB приняла файл с метаинформацией, она может загрузить один или несколько файлов или блоков одного или нескольких файлов.
STB запрашивает один блок у Индексирующего сервера, Этап 7. Конечно, STB может запрашивать несколько блоков одновременно. Она отправляет номер блока и идентификатор файла (это может быть имя файла); ID файла необходим, когда одновременно загружаются несколько файлов.
Индексирующий сервер возвращает адрес однорангового узла, способного предоставить блок контента, Этап 8.
STB инициирует соединение с указанным одноранговым узлом (узлами), Этап 9, извлекает блок (блоки) контента, Этап 10, и проверяет его/их целостность, Этап 11.
STB указывает Индексирующему серверу состояние загрузки блока в значениях успеха или сбоя, Этап 12.
Клиент может отправлять новые запросы других блоков к Индексирующему серверу, пока он не загрузил полный контент.
Используя информацию, переданную в отчетах, которые он принимает от STB, Индексирующий сервер непрерывно обновляет свою базу данных. В любой заданный момент он способен связать STB, которая нуждается в восстановлении данных, с одноранговой STB, способной предоставить отсутствующую информацию.
Благодаря полям TSI и TOI терминал может плавно переключаться в push-режим для загрузки файла.
На Фиг.3 - одноранговый узел, который предоставляет блок контента, является тем же одноранговым узлом, который предоставляет метаинформацию о контенте. Конечно, это может быть другой одноранговый узел.
Кроме того, Индексирующий сервер мог бы вернуть адреса более чем одного однорангового узла, допускающего предоставление блока контента. STB тогда бы, возможно, подключился более чем к одному одноранговому узлу.
Индексирующий сервер может обладать информацией, что запрошенный контент или файл с метаинформацией не могут быть предоставлены никакой из одноранговых STB.
В этом случае он может предоставить адрес Сервера контента, допускающего доставку контента напрямую. Чтобы избежать лавинного обращения к Серверу контента с запросами контента, Индексирующий сервер может обслуживать только пул одноранговых STB. Он переводит другие STB в режим ожидания и позже указывает им адреса пулов одноранговых STB, которые успешно загрузили контент.
В качестве альтернативы, Индексирующий сервер может передать запрос другому Индексирующему серверу или Индексирующему "суперсерверу". Если он обнаруживает запрошенную информацию, Индексирующий сервер может сохранить информацию в своей базе данных и положительно ответить STB.
Индексирующий сервер может предоставить несколько адресов для одного и того же контента. Контент может быть распространен по нескольким одноранговым STB, то есть никакая из одноранговых STB не имеет полного контента, но весь контент может быть создан из частичных контентов, находящихся на одноранговых STB. Индексирующий сервер также может указывать альтернативные одноранговые STB, которые могут предоставить запрошенный контент целиком или частично, чтобы дать STB возможность извлекать контент из другого однорангового узла, если она обнаружит, что скорость загрузки очень низкая, или если одноранговый узел подтвержден как недоступный.
С другой стороны, Индексирующий сервер может снабжаться алгоритмами, которые предусматривают интеллектуальный выбор одноранговых узлов, например, на основе статистики по количеству успешных загрузок от однорангового узла.
Сейчас описывается способ для push-распространения. Push-распространение основывается на Доставке файлов по Однонаправленному транспортному протоколу, обозначенному FLUTE, который указывается в RFC 3926. Push-распространение содержит механизм восстановления, который использует описанный выше одноранговой механизм.
Протокол FLUTE определяет передачу многоадресных объектов и ассоциированные таблицы дескрипторов. Он определяет Таблицу доставки файлов, обозначенную FDT, которая содержит информацию о файлах, которые нужно передать в текущем сеансе. Протокол FLUTE передает FDT с сервера контента в многоадресном режиме всем STB. FLUTE определяет несколько режимов передачи, например одну полную FDT с последующими несколькими файлами или последовательность экземпляров FDT (промежуточные FDT) с последующими ассоциированными файлами. Последний случай особенно подходит для передачи огромных видеофайлов; он позволяет приёмнику проверить, правильно ли принят объект или файл, перед тем как достигнуто окончание сеанса. Первый режим передачи довольно удобен в среде, где передаются небольшие файлы. Полная FDT строится из всех экземпляров FDT одного сеанса.
В соответствии с вариантом осуществления, FDT FLUTE содержит определенную одноранговую метаинформацию (содержащую длину блока и хэш блока), которая указана в нижеследующей таблице 2. Тогда во время загрузки контента можно плавно переключиться с одного протокола на другой. На самом деле приемники, которые не загрузили контент вообще или полностью в конце многоадресного push-сеанса FLUTE, могут плавно переключиться в одноранговый pull-режим и загрузить отсутствующие блоки благодаря информации в FDT, которая позволяет им точно знать отсутствующие блоки контента. Аналогичным образом приёмник, который начал загружать контент посредством однорангового pull-режима, может плавно переключиться в push-режим, используя FDT, которая дает приёмнику необходимую информацию для восстановления отсутствующих блоков файла push-режимом.
Нижеследующая таблица представляет Таблицу доставки файлов FLUTE, включающую метаинформацию P2P, в соответствии с вариантом осуществления.
| Таблица 2 | |
| Элемент/Наименование атрибута | Элемент/Описание атрибута |
| FDT-Instance-Attributes | Общие атрибуты для всех файлов, описанных экземпляром FDT |
| Expiration-Time | Момент окончания срока действия экземпляра FDT |
| Send-Complete | Описывает, является ли экземпляр FDT полным (например, описывает все файлы, которые нужно доставить в сеансе) |
| Multi-Files-Delivery-Attributes | Атрибуты, имеющие отношение к доставке нескольких файлов |
| FEC-OTI-FEC-Encoding-ID | Идентификация алгоритма FEC |
| FEC-OTI-FEC-Instance-ID | Экземпляр FEC в зависимости от идентификации алгоритма FEC |
| FEC-OTI-Maximum-Source-Block-Length | Максимальное количество символов источника на блок источника |
| FEC-OTI-Encoding-Symbol-Length | Длина символов кодирования в байтах |
| FEC-OTI-MaxNumber-Of-Encoding-Symbols | Максимальное количество Символов кодирования, которое может формироваться для блока источника |
| Multi-Files-Attributes | Атрибуты, имеющие отношение к нескольким файлам |
| Content-Type | Тип файлов контента |
| Content-Encoding | Сжатие |
| Client-Id | Для задания загрузки контента в зависимости от идентификатора клиента (HW, SW, Профиль, …) |
| Content-Block-Length | Размер блока |
| Content-Block-Digests (одно на блок) | Хэш блоков (SHA1, …) |
| Download-File-Attributes (одно на файл) | |
| File-Delivery-Attributes | Атрибуты, имеющие отношение к доставке файла |
| TOI | Идентификатор транспортного объекта |
| Transfert-Length | Размер транспортного объекта, перемещающего файла |
| Bandwidth-Requirement | Совокупная скорость отправки пакетов во все каналы |
| FEC-OTI-FEC-Encoding-ID | Идентификация алгоритма FEC |
| FEC-OTI-FEC-Instance-ID | Экземпляр FEC в зависимости от идентификации алгоритма FEC |
| FEC-OTI-Maximum-Source-Block-Length | Максимальное количество символов источника на блок источника |
| FEC-OTI-Encoding-Symbol-Length | Длина символов кодирования в байтах |
| FEC-OTI-MaxNumber-Of-Encoding-Symbols | Максимальное количество Символов кодирования, которое может формироваться для блока источника |
| File-Attributes | Атрибуты, имеющие отношение к самому файлу |
| File-Type | MIME-тип файла |
| File-Encoding | Сжатие |
| Client-Id | Для задания загрузки файла в зависимости от идентификатора клиента (HW, SW, Профиль, …) |
| File-Name | Идентификация и расположение файла для загрузки, например URI |
| File-Length | Размер файла |
| File-Digest | Хэш файла (например, MD5, SHA1, …) |
| File-Block-Length | Размер блока |
| File-Block-Digests (одно на блок) | Хэш блоков (SHA1, …) |
| FDT-Instance-Digest | |
| FDT-Instance-Digest | Хэш экземпляра FDT (например, MD5, SHA1, …) |
| FDT-Complete-Digest (только в последнем экземпляре FDT) | |
| Complete-FDT-Digest | Хэш полной FDT (например, MD5, SHA1, …) |
Поля Content-Block-Length, Content-Block-Digests, File-Name, File-Length, File-Digest, File-Block-Length и File-Block-Digests являются минимальной метаинформацией, необходимой для протокола P2P. Файл разбивается на несколько блоков.
Поле Complete-FDT-Digest может использоваться для передачи подписи RSA, чтобы позволить аутентификацию полной FDT.
Чтобы загрузить контент push-способом, клиент выполняет фазу обнаружения сеанса push-загрузки контента. Клиентская STB подписывается на предложение о push-загрузке. Она получает адрес распространения как часть подписки, где сигнализация услуги передается с помощью сервера SD&S, посредством механизма DVB-IP/SD&S. STB затем слушает выделенный групповой адрес. Она обнаруживает данные предложения о загрузке контента DVB-IP.
В этих данных предложения о загрузке контента она находит дату/время начала и окончания сеанса загрузки контента, а также другую информацию, например групповой адрес и порты, по которым распространяется контент, и адрес индексирующего сервера, от которого он зависит. Файл данных SD&S в соответствии с вариантом осуществления показывается в нижеследующей таблице 3.
| Таблица 3 | |
| Элемент/Наименование атрибута | Элемент/Описание атрибута |
| @DomainName | Доменное имя в DNS Интернета, зарегистрированное Поставщиком услуг, которое однозначно идентифицирует Поставщика услуг |
| @Version | Версия данных Предложения DVB-IP, номер версии должен увеличиваться каждый раз, когда выполняется изменение в данных Предложения DVB-IP |
| Тип ContentDownloadOffering (один на список Служб загрузки контента): | ContentDownloadServiceDiscovery/ContentDownloadServiceList |
| Catalogue@Id | Этот идентификатор назначается Поставщиком услуг |
| Name | Наименование каталога предложений Загрузки контента для отображения на одном или нескольких языках; одно наименование разрешается на каждый код языка, и должен предоставляться по меньшей мере один язык (хотя и не обязательно больше одного) |
| Description | Описание общего каталога предложений Загрузки контента для возможного отображения на одном или нескольких языках; по одному описанию на каждый код языка |
| ContentReleaseTime | Дата и время, когда новый контент доступен для замены старого контента |
| ClientId | Для задания сеанса загрузки контента в зависимости от идентификатора клиента. Он может включать в себя версию аппаратных средств клиента, версию программного обеспечения клиента, профиль клиента, районирование, … Также указывается в FDT для задания конкретно каждого файла загрузки в зависимости от профиля пользователя |
| Тип ServiceLocation (один на Службу загрузки контента, например Сеанс). | Расположение, где может быть найдена Служба загрузки контента |
| ProtocolType | FLUTE или другой |
| Transport Session Identifier (TSI) | Однозначно определяет сеанс FLUTE для заданного IP-адреса источника |
| IPMulticastAddress@Source | Один IP-адрес отправителя на сеанс доставки контента |
| IPMulticastAddress@Address | Групповой адрес |
| Количество каналов в сеансе | Использование нескольких каналов LCT для доставки контента в одном сеансе FLUTE |
| Номер IPMulticastPort для каждого канала в сеансе | Номер порта, соответствующий каждому номеру канала |
| Дата и время начала сеанса доставки контента | Дата и время начала Сеанса многоадресной доставки контента |
| Дата и время окончания сеанса доставки контента | Дата и время окончания Сеанса многоадресной доставки контента |
| Тайм-аут приема пакета FLUTE | Время для приема по меньшей мере одного пакета FLUTE на сеансовом уровне |
| Тайм-аут приема Таблицы доставки файлов (FDT) | Время для приема по меньшей мере одного экземпляра FDT на сеансовом уровне |
| Тайм-аут приема объекта (например, файла) | Время для приема по меньшей мере одного файла на сеансовом уровне |
| BandwidthRequirement | Максимальная полоса пропускания для использования сеансом |
| Тип RecoveryMode | Информация о режиме восстановления |
| P2P IndexServer URI | Идентификация и расположение (URI) Индексного сервера P2P |
| P2P IndexServerBackup URI | Список URI серверов резервного копирования индексов |
| Current Session File Repair OffsetTime | Время, которое клиенту нужно подождать после окончания доставки файла или сеанса доставки контента (в зависимости от режима передачи FLUTE) для начала процедуры восстановления файла |
| Current Session File Repair RandomTimePeriod | Длительность интервала времени, за который клиент должен вычислить произвольное время для инициирования процедуры восстановления файла |
| Тип целостности | |
| AnnouncementDigest | Дайджест объявления (хэш, CRC, …) |
Поле AnnouncementDigest может использоваться для передачи подписи RSA, чтобы позволить аутентификацию объявления.
Как проиллюстрировано на Фиг.4, используя информацию, полученную в фазе обнаружения, STB прослушивает групповой адрес, по которому распространяется контент push-сеанса, этап S'1.
Каждый экземпляр FDT содержит несколько хэш-кодов, которые позволяют проверку своей целостности и целостности блоков ассоциированного с ним файла. Эта информация соответствует файлу с метаинформацией, который описан для pull-режима. Как и для pull-режима, STB хранит файл с метаинформацией до тех пор, пока хранит ассоциированный контент. Файл может затем использоваться впоследствии для обслуживания одноранговых узлов в pull-режиме.
STB обнаруживает, когда заканчивается доставка файла, посредством признака "End-Of-Transmission-File" протокола FLUTE. С этого момента каждая STB может проверить целостность экземпляра FDT, этап S'2, S'3. После этой проверки каждая STB отправляет сообщение Индексирующему серверу, которое указывает, приняла ли она экземпляр FDT, этапы S'4, S'5.
Если проверка целостности экземпляра FDT успешна, то STB проверяет целостность блоков файла, ассоциированного с экземпляром FDT (этапы S'6, S'7), и отправляет отчет Индексирующему серверу для ассоциированного файла, этапы S'8, S'9; этот отчет содержит информацию о блоках, которые были корректно приняты, а также идентификатор файла. Индексирующий сервер сохраняет эту информацию и обновляет базу данных. Для отсутствующей части файлов STB выполняет восстановление файла, которое описано в дальнейшем.
Если проверка целостности экземпляра FDT неуспешна, поврежденный экземпляр FDT не позволяет STB проверить целостность блоков ассоциированного с ним файла, так как эта информация содержится в экземпляре FDT. STB сохраняет файл, который следует за поврежденной FDT, и ждет обнаружения окончания доставки файла для начала исправления экземпляра FDT, которое описано в дальнейшем. Пакеты FLUTE, содержащие блок, включают в себя идентификатор, именуемый TOI, который уникален для каждого файла. FDT также содержит этот идентификатор, который позволяет устанавливать связь блоков с файлом.
Последний экземпляр FDT в сеансе также содержит хэш-код, вычисленный по всем экземплярам FDT, которые являются частью сеанса. Это дает возможность проверки целостности полной FDT и понимание, отсутствуют ли экземпляры FDT. Это может использоваться для обнаружения случая, где экземпляр FDT доставляется только с помощью одного пакета FLUTE, и этот пакет потерян.
STB обнаруживает, когда заканчивается сеанс, посредством времени/даты окончания сеанса, которые включаются в запись сигнализации сеанса или посредством признака "End-Of-Session", предоставленного в заголовке пакета FLUTE.
Каждая STB поэтому проверяет целостность полной FDT, которая является суммой всех принятых экземпляров FDT; затем она проверяет, повреждена ли полная FDT или отсутствуют ли какие-нибудь экземпляры FDT. Если полная FDT не повреждена, она все еще может быть необходима для запуска процесса восстановления для некоторых файлов, в зависимости от их состояния приема. С другой стороны, если обнаруживается, что полная FDT повреждена, STB отправляет сообщение Индексирующему серверу, указывающее запрос полной FDT, после которого она проверяет, необходим ли процесс восстановления для поврежденных файлов.
Push-контент, который был потерян или поврежден, может быть восстановлен в обычной фазе pull-режима, как описано выше.
Если проверка целостности на полной FDT или на экземпляре FDT неуспешна (этап S'10), то STB отправляет сообщение Индексирующему серверу, указывающее запрос полной FDT (соответственно, экземпляра FDT, как проиллюстрировано на Фиг.4).
Поскольку не предполагается, что у Индексирующего сервера есть какие-либо сведения о FLUTE, применяется нижеследующее, чтобы позволить извлечение полной FDT (соответственно, экземпляра FDT).
STB хранит полную FDT и экземпляры FDT в памяти в течение некоторого периода, в частности, вплоть до загрузки нового контента в новом сеансе. Она сообщает Индексирующему серверу о безошибочном приеме этой полной FDT (соответственно, экземпляра FDT).
STB, у которой есть поврежденная полная FDT (соответственно, поврежденный экземпляр FDT), может запросить Индексирующий сервер (этап S'11), который предоставит адреса одноранговых узлов, способных на отправку неповрежденной версии, этап S'12, S'13.
STB может извлечь неповрежденную полную FDT (соответственно, неповрежденный экземпляр FDT), этап S'14, S'15, S'16, S'17, с помощью значения ее хеш-функции. Она проверяет ее целостность. Она анализирует полную FDT, чтобы установить, какие файлы в push-сеансе она пропустила, или чтобы восстановить поврежденный экземпляр FDT. Затем она проверяет целостность ассоциированного файла. Если STB обнаруживает отсутствующий файл, она начинает восстановление файла для отсутствующего файла. Если STB обнаруживает поврежденный файл, она начинает восстановление блоков.
Используя информацию, переданную в отчетах, которые он принимает от STB, Индексирующий сервер непрерывно обновляет свою базу данных. В любой заданный момент он способен связать STB, которая нуждается в восстановлении данных, с равноправной STB, способной предоставить отсутствующую информацию.
Благодаря длительности сеанса, переданной объявлением сеанса в данных SD&S, STB знает, пропустила ли она push-сеанс. STB, которая пропустила push-сеанс, может запросить у Индексирующего сервера полную FDT с именем файла "FDT", и приступает к восстановлению файла для отсутствующих файлов.
STB, которая подключается, когда происходит сеанс доставки файла, все еще может получить часть контента из многоадресного сеанса FLUTE. Для получения файлов, пропущенных в сеансе FLUTE, она ждет окончания сеанса для выполнения восстановления "полной" FDT и получения отсутствующих файлов от одноранговых узлов.
В среде загрузки видеофайла сочетание pull- и push-способов предоставляет усовершенствованную модель распространения. Стратегия распространения может быть следующей. Фильмы, которые относительно популярны, могут предлагаться в push-режиме, а остальные фильмы, которые требуются меньше, могут предлагаться в pull-режиме. Когда набор фильмов push-режима заменяется новым, старый набор присоединяется к набору фильмов, доступных в pull-режиме.
С другой стороны, Индексирующие серверы могут указывать Серверам контента, что интересно переключить режим доставки некоторых фильмов с pull- на push-режим или наоборот, в соответствии со статистикой запросов, которую способны собрать Индексирующие серверы.
Для субъектов отслеживания или управления Индексирующие серверы предлагают возможность собирать статистику об активности восстановления файлов. Эта информация используется оператором для отслеживания или динамической адаптации стратегии доставки. Последняя может состоять из планирования дополнительного сеанса push-доставки или в добавлении FEC. Другие действия могут включать в себя изменение полосы пропускания, выделенной для доставки файла загрузки.
В этом документе ссылка на "один вариант осуществления" или "вариант осуществления" означает, что конкретный признак, структура или характеристика, описанные по отношению к этому варианту осуществления, могут включаться по меньшей мере в одну реализацию изобретения. Появления фразы "в одном варианте осуществления" в разных местах в описании изобретения не обязательно указывают на один и тот же вариант осуществления, а также не являются отдельными или альтернативными вариантами осуществления, обязательно взаимоисключающими другие варианты осуществления.
Номера ссылок, появляющиеся в формуле изобретения, наличествуют только ради иллюстрации и не должны обладать ограничивающим действием на объем формулы изобретения.
1. Способ загрузки контента в системе (10) связи, содержащей первый терминал (1), по меньшей мере второй терминал (2) и сервер (5, 8) контента, причем упомянутый способ на уровне первого терминала содержит этапы, на которых:
загружают контент в pull-режиме с сервера контента или по меньшей мере второго терминала; и
продолжают загрузку этого контента в push-режиме, без необходимости запрашивания какой-либо дополнительной информации, когда push-режим запускается на сервере контента.
2. Способ для загрузки контента в системе (10) связи, содержащей первый терминал (1), по меньшей мере второй терминал (2) и сервер (5, 8) контента, причем упомянутый способ на уровне первого терминала содержит этапы, на которых:
загружают контент в push-режиме с сервера контента; и продолжают загрузку этого контента в pull-режиме с сервера контента или по меньшей мере второго терминала, без необходимости запрашивания какой-либо дополнительной информации, когда доступен pull-режим.
3. Способ по п.2, отличающийся тем, что содержит этапы, на которых:
принимают push-контент в сеансовой доставке в соответствии с протоколом FLUTE; и
принимают информацию в Таблице доставки файлов, FDT, во время сеансовой доставки, позволяющей переключиться в pull-режим.
4. Способ по п.3, отличающийся тем, что содержит этапы, на которых:
проверяют целостность экземпляра FDT;
указывают индексирующему серверу (6), успешно ли принят экземпляр FDT; и
указывают индексирующему серверу, успешно ли принят файл, ассоциированный с экземпляром FDT.
5. Способ по п.4, отличающийся тем, что при обнаружении поврежденного экземпляра FDT содержит этапы, на которых:
ожидают окончания доставки файла; и выполняют восстановление экземпляра FDT в pull-режиме.
6. Способ по п.4, отличающийся тем, что при обнаружении поврежденной полной FDT он содержит этапы, на которых:
ожидают окончания сеансовой доставки; и выполняют восстановление полной FDT в pull-режиме.
7. Способ по п.1, отличающийся тем, что он содержит этапы, на которых:
принимают pull-контент в соответствии с одноранговым протоколом; и принимают файл с одноранговой метаинформацией, содержащей
информацию, позволяющую переключение в push-режим.
8. Терминал (1, 2, 3), выполненный с возможностью загрузки контента в системе связи, содержащий:
средство (1.6) для загрузки контента в push-режиме;
средство (1.5) для загрузки контента в pull-режиме; и
средство (1.7) для загрузки контента в pull-режиме с сервера контента или по меньшей мере второго терминала и продолжения загрузки контента в push-режиме, без необходимости запрашивания какой-либо дополнительной информации, когда push-режим доступен на сервере контента.
9. Терминал (1, 2, 3), выполненный с возможностью загрузки контента в системе связи, содержащий:
средство (1.6) для загрузки контента в push-режиме;
средство (1.5) для загрузки контента в pull-режиме; и
средство (1.7) для загрузки контента в push-режиме с сервера контента и продолжения загрузки контента в pull-режиме с сервера контента или по меньшей мере второго терминала, без необходимости запрашивания какой-либо дополнительной информации, когда доступен pull-режим.
