Управление сеансом доставки файлов

Управление сеансом доставки файлов

Иллюстрации

Показать все

Реферат

Область техники

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

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

FLUTE - это проект, развиваемый под эгидой Рабочей группы по инженерным проблемам Интернета (IETF=Internet Engineering Task Force). FLUTE определяет протокол однонаправленной доставки файлов по сети Интернет. Этот протокол особенно хорошо подходит для сетей многоадресной передачи, хотя технические решения в равной степени применимы для использования с одноадресной передачей. Параметры FLUTE основаны на асинхронном многоуровневом кодировании (ALC - Asynchronouse Layered Coding), базовый протокол предназначен для объемного масштабируемого многоадресного распределения. ALC определяет перенос произвольных бинарных объектов и основан на документе Luby, M., Gemmeil, J., Vicisano, L., Rizzo, L. and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002. Для приложений по доставке файлов простого переноса объектов оказывается недостаточно. Оконечные системы должны знать, что эти объекты представляют собой фактически. FLUTE обеспечивает механизм сигнализации и отображения свойств файлов для концепций ALC таким способом, который позволяет приемникам присвоить эти параметры принятым объектам. В рамках FLUTE понятие "файл" относится к "объекту" согласно вышеуказанному документу, посвященному ALC.

В сеансе доставки файлов в рамках FLUTE имеется отправитель, который "посылает" сеанс, и множество приемников, которые "принимают" сеанс. Приемник может присоединиться к сеансу в произвольное время. Сеанс "доставляет" один или несколько абстрактных объектов, например файлов. Количество файлов может меняться. Любой файл можно послать с использованием более одного пакета. Любой пакет, посланный в рамках сеанса, может быть потерян.

FLUTE имеет перспективы для использования при доставке файлов любого вида и любого размера. FLUTE подходит для доставки файлов многим хостам с использованием сеансов продолжительностью в несколько секунд и более. Например, FLUTE можно использовать для доставки объемных обновлений программного обеспечения одновременно многим хостам. Кроме того, FLUTE может использоваться для непрерывных, но сегментированных, данных, например временной текстовой последовательности для субтитров, и, таким образом, может использовать свою многоуровневую природу, унаследованную от ALC и LCT (LCT - Layered Coding Transport - транспорт с многоуровневым кодированием), для масштабирования всего содержания сеанса в соответствии со статусом перегрузки сети. Кроме того, FLUTE подходит для базового переноса метаданных, например файлов протокола описания сеанса (SDP - Session Description Protocol), которые позволяют пользовательским приложениям получить доступ к мультимедийным сеансам. FLUTE может использоваться с системами радиотрансляции и, как ожидается, в особенности будет использоваться в связи с многоадресной передачей данных с использованием Интернет-протокола (IPDC - Internet Protocol Datacast) в рамках цифрового телевизионного вещания для портативных устройств (DVB-H - Digital Video Broadcast - Handheld), для которой в настоящее время разрабатываются стандарты.

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

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

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

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

а) таймер ожидания фрагмента;

б) таймер ожидания нового объекта;

в) таймер ожидания таблицы;

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

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

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

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

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

Приемный модуль может быть выполнен так, чтобы принимать пакеты, например пакеты в формате протокола Интернета, и содержать объекты и декларации, а кроме того, в качестве опции один или более параметров таймера.

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

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

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

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

а) запуск таймера ожидания фрагмента;

б) запуск таймера ожидания нового объекта;

в) запуск таймера ожидания таблицы;

причем способ дополнительно включает прекращение сеанса доставки файлов в ответ на истечение времени любого из одного или нескольких таймеров.

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

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

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

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

На фиг.1 схематично показан мобильный телефон, который принимает данные от сервера, подключенного к Интернету;

на фиг.2 показана блок-схема соединений мобильного телефона, изображенного на фиг.1;

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

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

на фиг.6-8 иллюстрируется работа мобильного телефона, изображенного на фиг.2, как конечного автомата.

Подробное описание предпочтительных вариантов осуществления изобретения

На фиг.1 мобильная станция в виде мобильного телефона 1 принимает транслируемые данные от DBV-H транслятора В, который через сеть 2, например Интернет, связан с сервером 3 контента, который может загрузить данные в мобильный телефон 1. Сервер 3 контента имеет связанный с ним биллинговый сервер 4, предназначенный для выставления счета абоненту за загруженный контент.

Телефон 1 содержит микрофон 5, клавиатуру 6, функциональные клавиши 7, дисплей 8, динамик 9 и внутреннюю антенну 10. Телефон 1 предназначен для передачи как голоса, так и данных. Например, телефон может использоваться в сети GSM и может осуществлять операции DVB-H, хотя специалистам в данной области техники понятно, что могут использоваться другие сети и протоколы связи. Обработка сигналов происходит под управлением контроллера 11. Соответствующая память 12 включает долговременную память большой емкости на твердотельном носителе, предназначенную для хранения данных, загруженных из сервера 3 контента, например прикладных программ, видеоклипов, телевизионных программ и т.п. Электрические аналоговые звуковые сигналы генерируются микрофоном 5 и усиливаются предварительным усилителем 13а. Аналогично, аналоговые звуковые сигналы подаются в динамик 9 или во внешние головные телефоны (не показаны) через усилитель 13b. Контроллер 11 получает управляющие сигналы от клавиатуры и функциональных клавиш 6, 7 и управляет работой дисплея 8. Информация, относящаяся к личности пользователя, хранится в съемной интеллектуальной карте 14. Она может иметь вид GSM SIM карты, которая содержит обычные данные о личности мобильного абонента согласно международным требованиям стандарта GSM и ключ K_i шифрования, который используется для кодирования радиопередачи известным способом. Радиосигналы передаются и принимаются антенной 10, связанной через радиоинтерфейс 15 с кодеком 16, производящим обработку сигналов под управлением контроллера 11. Таким образом, при использовании для кодирования речи кодек 16 получает аналоговые сигналы из микрофонного усилителя 13а, переводит их в цифровую форму, подходящую для передачи, и передает в радиоинтерфейс 15 для передачи через антенну 10 в наземную мобильную сеть общего пользования (PLMN, на фиг.1 не показана). Аналогично, сигналы, принятые от наземной мобильной сети общего пользования, проходят через антенну 10 для демодуляции в радиоинтерфейсе 15 и подачи в кодек 16 для выработки аналоговых сигналов и подачи их в усилитель 13b и динамик 9.

Телефон может иметь возможности протокола WAP (протокол беспроводного доступа), позволяющего принимать данные, например, по каналу GPRS (канал пакетной радиосвязи общего назначения) со скоростью порядка 40 кбит/с. Однако понятно, что изобретение не ограничено никакой конкретной скоростью передачи данных или механизмом передачи данных, например, могут использоваться системы WCDMA, CDMA, EDGE, WLAN, ВТ, DTV-T, IPDC, DAB, ISDB-T, ATSC, MMS, TCP/IP, UDP/IP или IP.

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

Телефон включает также DVB-H приемный модуль 19. Он принимает транслируемые сигналы цифрового телевизионного вещания от DVB транслятора В через DVB антенну 20.

Пользователь телефона 1 может запросить загрузку контента у одного или нескольких серверов, например сервера 3, для загрузки видеоклипов и т.п. и отображения их на дисплее 8. Такие загруженные видеоклипы хранятся в памяти 12. Кроме того, другие файлы данных различных размеров могут быть загружены и храниться в памяти 12. Загрузка может быть инициирована пользователем или может быть разрешена пользователем на основе установок телефона. Альтернативно, загрузка данных может быть затребована оператором сети 2, в особенности если речь идет об обновлении программного обеспечения.

В протоколе FLUTE сеанс доставки файлов имеет время начала и время окончания и включает один или более каналов. Одно или оба из времени начала и окончания могут быть неопределенными, то есть одно или оба времени могут быть неизвестны приемнику. Если имеется множество каналов, используемых в сеансе, они могут быть параллельными, последовательными или могут быть совокупностью параллельных и последовательных каналов. Сеанс доставки файлов организует перенос файлов в качестве транспортных объектов. Когда транспортный объект сопровождается семантикой, этот объект становится файлом. Семантика может включать название, локализацию, размер и тип. Каждый сеанс доставки файлов организует перенос нулевого количества, одного или более транспортных объектов (ТО - transport object). Каждый транспортный объект доставляется в виде одного или более пакетов, инкапсулированных в основной протокол. Какой-либо конкретный пакет может появиться несколько раз в течение сеанса. Конкретный транспортный объект может быть доставлен с использованием одного канала или с использованием нескольких каналов. Транспортный объект может быть передан несколько раз.

Особый транспортный объект, называемый таблицей доставки файлов (FDT - file delivery table) сигнализирует об отображении набора файлов на транспортные объекты. Могут иметься насколько таблиц FDT. Каждую отдельную таблицу FDT можно называть экземпляром FDT. Содержание различных экземпляров FDT может перекрываться, а может и не перекрываться. Экземпляр FDT может быть пустым. FLUTE обеспечивает детализированное определение того, как могут использоваться экземпляры FDT. Прием и обработка содержания транспортных объектов и таблиц FDT известны специалистам в данной области техники и здесь не описываются.

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

Кратко, эти три параметра следующие:

время ожидания фрагмента - этот параметр относится к максимально допустимому времени между приемом таблицы FDT и приемом по меньшей мере первого фрагмента транспортного объекта из этой таблицы FDT.

Время ожидания нового объекта - этот параметр относится к максимально допустимому времени между приемом всех транспортных объектов для таблицы FDT и приемом другой таблицы FDT.

Время ожидания таблицы - этот параметр относится к максимально допустимому времени между приемом транспортного объекта, не декларированного в действующей таблице FDT, и приемом таблицы FDT, в которой декларируется этот транспортный объект.

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

В одном варианте выполнения настоящего изобретения параметры передаются в телефон 1, который является приемником, посредством трансляции радиосигналов через сеть DVH-H. Альтернативно, параметры могут быть встроены в телефон 1 при его изготовлении. Передача параметров в виде сигнализации предпочтительна, поскольку это обеспечивает гибкость в процессе сеанса доставки файлов, в частности, во время между передачей определенных компонентов сеанса без необходимости компромисса с работой приемника. В любом случае параметры хранятся в телефоне 1, например в памяти 12 или в памяти, являющейся частью DVH-H приемника 19.

На фиг.3 и 4 иллюстрируется работа телефона 1, в частности его DVH-Н приемника 19, при подключении к сеансу доставки файлов. На фиг.3 алгоритм начинается на шаге S3.1, после которого таймер t3 ожидания нового объекта устанавливают на значение параметра времени ожидания нового объекта и запускают этот таймер на шаге S3.2. Затем на шаге S3.3 DVB-H приемник 19 принимает первый транспортный объект (ТО). В этом примере транспортный объект считается принятым, когда пакет, если он только один, или все пакеты, если транспортный объект распределен по нескольким пакетам, приняты правильно. Два или более пакетов, относящихся к одному транспортному объекту, могут быть приняты последовательно, но возможно также, что в этот период будет принят один или несколько пакетов, относящихся к другим транспортным объектам. Когда принят последний пакет для некоторого транспортного объекта, этот транспортный объект считается принятым на шаге S3.3. На шаге S3.4 определяют, относится ли этот пакет к таблице FDT. Если да, операция продолжается на шаге S3.5.

На шаге S3.5 определяют, является ли таблица FDT новой таблицей FDT, то есть является ли она той таблицей, которая еще не была принята в текущем сеансе доставки файлов. Если она - новая таблица FDT, то на шаге S3.6 из таблицы FDT выбирают идентификатор транспортного объекта (TOI). Каждый транспортный объект (ТО) имеет соответствующий идентификатор TOI, и для каждого транспортного объекта используется не более одного идентификатора TOI. Затем на шаге S3.7 определяют, является ли этот идентификатор TOI новым идентификатором TOI, то есть идентификатором TOI, который не был включен в таблицу FDT, принятую в текущем сеансе доставки файлов. Если это новый идентификатор TOI, то на шаге S3.8 определяют, активен ли таймер t2 ожидания таблицы (идентификатор TOI N) для этого идентификатора TOI, то есть ведет ли отсчет этот таймер. Для каждого идентификатора TOI имеется отдельный таймер t2 ожидания таблицы. Если таймер ведет отсчет, то на шаге S3.9 его останавливают. Если таймер t2 ожидания таблицы (идентификатор TOI N) не активен, то на шаге S3-10 таймер t1 ожидания фрагмента для данного идентификатора TOI устанавливают на значение параметра времени ожидания фрагмента и запускают. Для каждого идентификатора TOI имеется отдельный таймер t2 ожидания фрагмента. После шагов S3.9 или S3.10 в зависимости от результата ответа на вопрос на шаге S3.8, на шаге S3.11 определяют, включает ли таблица FDT дополнительные идентификаторы TOI. Если имеются дополнительные идентификаторы TOI, то алгоритм возвращается на шаг S3.6, где выбирают новый идентификатор TOI, т.е. такой идентификатор TOI, который не был обработан в текущем процессе. Если на любой стадии шага S3.7 выявлено, что рассматриваемый идентификатор TOI не является новым, то есть он уже был принят в текущем сеансе, то алгоритм непосредственно переходит к выяснению ответа на вопрос шага S3.11, и соответственно шаги s3.9, S3.10 и S3.10 игнорируются. Если на шаге S3.5 выявлено, что таблица FDT не является новой, то есть она уже была принята в текущем сеансе, то шаги S3.6-S3.11 игнорируются, а алгоритм переходит на шаг S3.12.

В результате выполнения шагов S3.5-S3.10 имеем то, что если имеется новый идентификатор TOI в новой таблице FDT, то таймер t1 ожидания фрагмента для этого идентификатора TOI устанавливают и запускают, если таймер t2 ожидания таблицы для этого идентификатора TOI не активен, а если активен, то останавливают таймер t2 ожидания таблицы для этого идентификатора TOI. Процесс проверяет все новые идентификаторы TOI в таблице FDT и либо устанавливает и запускает таймер t1 ожидания фрагмента, либо останавливает таймер t2 ожидания таблицы для каждого идентификатора TOI.

Непосредственно после шага S3.11 или непосредственно после отрицательного ответа на вопрос шага S3.5 на шаге S3.12 определяют, включает ли принятая таблица FDT какие-нибудь новые идентификаторы TOI, то есть какие-нибудь идентификаторы TOI, относящиеся к транспортным объектам, которые еще не были приняты в текущем сеансе. Если ответ положителен, то есть выявлено, что таблица FDT включает один или более идентификаторов TOI, относящихся к транспортным объектам, которые еще не были приняты в текущем сеансе, то на шаге S3.13 сбрасывают таймер t3 ожидания нового объекта и вновь его запускают. После этого шага или после отрицательного ответа на вопрос на шаге S3.12 алгоритм возвращается на шаг S3.3, где начинают обработку нового транспортного объекта или таблицы FDT.

Если на шаге S3.4 определено, что принятый транспортный объект не относится к таблице FDT, то считают, что транспортный объект относится к файлу, и алгоритм переходит на шаг S3.14. На нем определяют, активен ли таймер t1 ожидания фрагмента для этого идентификатора TOI данного транспортного объекта. Если да, то на шаге S3.15 таймер t1 ожидания фрагмента останавливают. Поскольку таймер t1 ожидания фрагмента для данного идентификатора TOI активен только в случае, если он установлен на шаге S3.10, активность таймера указывает на то, что была принята новая таблица FDT. Поскольку таймер t1 ожидания фрагмента останавливают на шаге S3.15, если на шаге S3.14 обнаружено, что он активен, в результате таймер t1 ожидания фрагмента для данного идентификатора TOI завершит отсчет времени, если соответствующий транспортный объект не будет принят в пределах времени, заданного параметром времени ожидания фрагмента. Таймер отменяют, то есть он не завершает отсчет, если транспортный объект принят в пределах времени, заданного параметром времени ожидания фрагмента. Таким образом, приемник будет ожидать только в течение времени, заданного параметром времени ожидания фрагмента для каждого транспортного объекта из таблицы FDT, который должен быть принят до прекращения сеанса доставки файлов в случае, если эти транспортные объекты не приняты.

После шагов S3.14 и S3.15 алгоритм переходит на шаг S3.16. На нем определяют, была ли принята декларация для идентификатора TOI, то есть определяют, была ли в текущем сеансе принята таблица FDT, включающая идентификатор TOI. Если ответ отрицателен, на шаге S3.17 устанавливают таймер t2 ожидания таблицы для этого идентификатора TOI на значение параметра времени ожидания таблицы и запускают таймер. В результате таймер t2 ожидания таблицы для идентификатора TOI запускают, когда транспортный объект принят, но идентификатор TOI не декларирован. Этот таймер t1 ожидания фрагмента отменяют на шаге S3.9, если идентификатор TOI декларирован прежде, чем таймер t2 ожидания таблицы завершил отсчет. Если транспортный объект не принят, таймер ожидания таблицы завершает свой отсчет времени.

После шагов S3.16 и S3.17 алгоритм возвращается на шаг S3.3, на котором для обработки принимают другой транспортный объект.

Таймер t3 ожидания нового объекта и таймеры t1, t2 ожидания фрагмента и ожидания таблицы для каждого идентификатора TOI могут быть реализованы любым подходящим способом, например с использованием дискретных таймеров (не показаны), с использованием подпрограмм, запущенных в контроллере 11 или в процессоре (не показан), входящем в DVB-H приемник 19.

Из анализа последовательности операций на фиг.3 понятно, что таймер t2 ожидания таблицы для данного идентификатора TOI активен только в случае, если DVB-H приемник 19 ожидает таблицу FDT, что имеет место только тогда, когда транспортный объект принят, но этот транспортный объект не идентифицирован в таблице FDT, принятой в течение текущего сеанса. В этом случае DVB-H приемник 19 ожидает приема таблицы FDT или по меньшей мере таблицы FDT, отличающейся от любой полученной ранее, и использование таймера t2 ожидания таблицы заставляет DVB-H приемник ожидать приема таблицы в течение заданного времени, равного значению параметра времени ожидания этой таблицы. Если соответствующая таблица FDT, то есть таблица, включающая идентификатор TOI для этого транспортного объекта, не будет принята до того, как таймер t2 ожидания таблицы для этого идентификатора TOI досчитает до нуля, DVB-H приемник 19 прекращает сеанс.

Хотя в предыдущем описании транспортный объект считается принятым на шаге S3.3, когда все пакеты транспортного объекта, распределенного по множеству пакетов, приняты правильно, алгоритм может вместо этого выполняться для отдельных пакетов, даже если все пакеты, которые составляют транспортный объект, еще не приняты. В этом случае шаг S3.3 относится с приему одного пакета, а шаг S3.18 вставлен непосредственно перед шагом S3.14. На шаге S3.18 определяют, является ли данный пакет первым пакетом, принятым для данного транспортного объекта. Если ответ положителен, то алгоритм продолжается на шаге S3.14. В противном случае алгоритм игнорирует пакет и возвращается на шаг S3.3. В результате этого шага таймер t1 ожидания фрагмента для этого транспортного объекта останавливают, если был принят какой-либо фрагмент этого транспортного объекта.

Ниже описан альтернативный вариант выполнения настоящего изобретения. Вместо того чтобы шаг S3.13 зависел от результата ответа на вопрос на шаге S3.12, шаг S3.12 можно полностью опустить, а шаг S3.13 вставить вместо него после положительного ответа на вопрос на шаге S3.7. Например, шаг S3.13 можно разместить непосредственно после шага S3.7 или непосредственно перед шагом S3.1. Результат использования этого варианта аналогичен результату выполнения варианта, описанного выше, хотя описываемый альтернативный вариант включает на одно решение меньше, поскольку шаг S3.12 можно опустить.

Таймеры ожидания фрагмента показаны на фиг.2 позициями 24а, 24b… 24n. Таймеры ожидания таблицы показаны позициями 25а, 25b… 25с. Таймер ожидания нового объекта показан позицией 26.

Ниже со ссылкой на фиг.4 описана работа телефона 1 и DVB-H приемника 19 в отношении таймеров t1 ожидания фрагмента, таймера t3 ожидания нового объекта и таймеров t2 ожидания таблицы. Эти операции выполняются параллельно операциям, показанным на фиг.3. Они могут быть реализованы с помощью отдельного оборудования или, альтернативно, с помощью подпрограмм и соответствующего программного обеспечения для операционной системы.

Как показано на фиг.4, пока сеанс находится в стадии проведения, то есть имеет место прием сеанса, что обозначено шагом S4.1 начала сеанса, операция на шаге S4.2 представляет собой цикл до тех пор, пока не будет определено, что таймер закончил отсчет. Шаг S4.2 завершается положительным ответом, что заставляет алгоритм перейти на шаг S4.3, если любой из таймеров t1 ожидания фрагмента, таймера t3 ожидания нового объекта и таймеров t2 ожидания таблицы досчитал до нуля. Конечно, вместо этого счетчики могут считать по возрастающей от нуля или другой величины до заданной величины.

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

На шаге S4.3 определяют, были ли получены все транспортные объекты, идентифицированные соответствующими идентификаторами TOI в таблицах FDT, принятых в течение текущего сеанса. Если ответ положителен, считают, что сеанс доставки файлов завершился успешно в том смысле, что телефон 1 принял все файлы, предназначенные для доставки в процессе сеанса, и на шаге S4.4 этот сеанс прекращают. Подразумевается, что прекращение сеанса включает прекращение приема пакетов для этого сеанса. В большинстве случаев это подразумевает выключение по меньшей мере некоторых функций DVB-H приемника 19, хотя они могут оставаться включенными для приема других транслируемых данных. Как только сеанс прекращен, потребляемую мощность телефона можно значительно снизить, таким образом увеличивая время до подзарядки аккумулятора 17.

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

После положительного ответа на шаге S4.5 алгоритм переходит на опционный шаг S4.6. Он является опционным, поскольку может быть полностью опущен. На шаге S4.6 определяют, будет ли процесс доставки файла завершен быстро; в этом примере определяют, будет ли отсутствующий или неполный транспортный объект принят или завершен в пределах короткого, заранее заданного промежутка времени. Это может быть реализовано любым подходящим способом. Например, можно прогнозировать время, необходимое для завершения приема пакета, если известна скорость приема принимаемого в настоящее время пакета и его длина. Время, необходимое для завершения приема сеанса доставки файлов, может быть вычислено или оценено с использованием информации о любых параметрах временной организации или расписания передачи пакета (например, когда происходит неоднократная передача пакетов по кругу или аналогично), любого вычисления усредненных или оперативных скоростей приема данных и/или количества данных, которое осталось принять. Если данные прямого исправления ошибок, например данные Рида-Соломона, являются частью объекта передачи, DVB-H приемник 19 может не требовать дополнения нулями. Кроме того, в этом случае нет необходимости принимать все данные приложения и/или данные проверки четности, поскольку данные проверки четности могут исправить ошибки в данных приложения и поскольку данные проверки четности необходимы только тогда, когда имеются ошибки в данных приложения.

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

Если на шаге S4.6 получен положительный ответ, то на шаге S4.7 сеанс продолжают в течение короткого времени, например в течение заранее заданного времени, использованного в качестве порога на шаге S4.6, а затем приемник 19 прекращает сеанс на шаге S4.4. Для реализации шага S4.7 может быть использован отдельный таймер.

Если на одном из шагов 4.5 и 4.6 получен отрицательный ответ, сеанс прекращают на шаге S4.4, не приняв все файлы. То же самое имеет место, если после шага S4.7 приняты не все файлы. В любом из этих случаев может генерироваться сообщение об ошибке, например, отображаемое на дисплее 8. На основании этого DVB-H приемник может заключить, что сеанс доставки файлов был неподдерживаемого типа.

Система может выполнить пропуск ненужной информации перед прекращением сеанса путем ожидания следующего планируемого временного окна для уровня связи (то есть пакетного временного интервала для DVB-H) или всего цикла окон (что требует максимум 41 секунду для DVB-Н) после завершения таймером отсчета.

Операции, соответствующие шагам S3.3-S18 на фиг.3 могут быть реализованы в программном обеспечении, например, на основе следующих псевдокодов, которые не нуждаются в пояснениях (table_wait_timer - таймер ожидания таблицы, global_new_table_wait_timer - глобальный таймер ожидания новой таблицы, fragment_wait_timer - таймер ожидания фрагмента).

Прием пакета Р с идентификатором TOI М в сеансе

Если пакет Р несет часть или весь экземпляр таблицы FDT {

Если после приема экземпляр таблицы FDT был принят полностью{

Если полностью принятый экземпляр FDT - "новый" экземпляр FDT {

Если каждый TOI N в принятом экземпляре таблицы FDT {

Если N - "новая" декларация идентификатора TOI {

Если table_wait_timer (N) активен {

Остановка table_wait_timer (N)}

} иначе {

Установка fragment_wait_timer (N);

Запуск fragment_wait_timer (N)

}

}

}

Если была любая "новая" декларация TOI в экземпляре FDT {

Сброс global_new_table_wait_timer;

}

}

} иначе {

Если это первый пакет, увиденный/принятый приемником для TOI М {

Если fragment_wait_timer (М) активен {

Остановка fragment_wait_timer (М)

}

Если приемник не видел/не получил декларацию для TOI М {

Установка table_wait_timer (М);

Запуск table_wait_timer (М)

}

}

}

Повторение для следующего пакета Р.

Имеется альтернатива. Вместо размещения команды "сброс global_new_table_wait_timer" так, как это показано выше, того же эффекта можно достичь, помещая эту команду после определения "Если N - "новая" декларация идентификатора TOI", то есть как команду в последовательность шага определения "Если table_wait_timer (N) активен". Результат будет такой же, как в варианте, описанном выше со ссылкой на фиг.3.

Работу DVB-Н приемника 19 можно пояснить следующим образом. При "приеме" сеанса доставки файлов, в котором таблицы дескрипторы полей FDT идентифицируют транспортные объекты, переданные наряду с таблицами FDT, приемник 19 с использованием множества таймеров определяет, были ли приняты файлы сеанса. Таймер t1 ожидания фрагмента запускают для каждого нового транспортного объекта, декларированного в таблице FTD, когда эта таблица FDT принята. Каждый таймер останавливают, когда принят по меньшей мере один фрагмент соответствующего транспортного объекта. Альтернативно, один таймер останавливают, когда приняты все транспортные объекты. Таймер t3 ожидания нового объекта запускают, когда приняты все транспортные объекты, декларированные в таблице FDT, и отменяют, когда принята новая таблица FDT. Один из множества таймеров 2 ожидания таблицы запускают каждый раз, когда принят транспортный объект, не декларированный ни в какой таблице FDT, и отменяют, когда принята таблица FDT, декларирующая прием этого объекта. Сеанс доставки файлов прекращают, если какой-либо таймер завершает отсчет. Если после истечения времени таймера полагают, что сеанс доставки файлов был принят почти полностью, сеанс прекращают после короткого промежутка времени, чтобы обеспечить прием всего сеанса.

Операции, иллюстрированные на фиг.3 и 4, обеспечивают поддержку динамических сеансов трансляции файлов, то есть сеансов, в которых файлы, а следовательно, транспортные объекты, могут меняться в процессе сеанса. В частности, именно для этой цели предусмотрен шаг S3.12.

Ниже со ссылкой на фиг.5 будет описано приложение операций, иллюстрированных на фиг.3, к ожидаемому сценарию сеанса доставки файлов. На фиг.5 показаны временные диаграммы работы DVB-H приемника 19 в телефоне 1 в п