УПРАВЛЕНИЕ СЕАНСОМ ДОСТАВКИ ФАЙЛОВ

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

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

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

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 в процессе приема сеанса доставки файлов, увеличение времени происходит слева направо. Сеанс начинается в момент Tbegin и заканчивается в момент Tend.

В момент T1 DVB-H приемник 19 подключается к сеансу доставки файлов.

В момент Т2 приемник 19 принимает экземпляр А таблицы FDT (FDT А). Эта таблица ассоциирует объекты с их семантикой (например, названием, размером, типом носителя и т.д.). В этом примере FDT А декларирует транспортные объекты х, у, а может декларировать и какой-либо другой транспортный объект. Это пример первой таблицы FDT, которую видит приемник 19. Приемник устанавливает таймер t1 ожидания фрагмента для каждого идентификатора TOI в таблице FDT на значение, равное параметру времени ожидания фрагмента. Затем производится запуск этих таймеров.

Между моментом T1 и моментом ТЗ приемник 19 принимает некие пакеты. Некоторые из этих пакетов принадлежат к транспортным объектам, декларированным в FDT А. Приемник 19 останавливает таймер t1 ожидания фрагмента для транспортных объектов, декларированных в таблице FDT, при приеме первого фрагмента. В этом примере принят фрагмент каждого из декларированных транспортных объектов, а в противном случае сеанс был бы прекращен.

В момент Т4 приемник 19 принимает пакет, принадлежащий транспортному объекту "z", пока еще не декларированному в каком-либо экземпляре таблицы. Затем приемник 19 устанавливает таймер t2 ожидания таблицы на значение параметра ожидания таблицы и запускает этот таймер.

К моменту Т5 приемник 19 принял все файлы, декларированные в экземплярах обнаруженных на данный момент таблиц FDT. Тогда как к моменту Т3 принят по меньшей мере один фрагмент от каждого транспортного объекта, к моменту Т5 приняты все фрагменты для каждого транспортного объекта. Здесь приемник 19 устанавливает таймер t3 ожидания нового объекта на значение, равное параметру времени ожидания нового объекта, и запускает таймер.

В момент Т6 приемник 19 принимает экземпляр В таблицы FDT (FDT В). В этом примере FDT В отличается от FDT А и декларирует транспортные объекты w, v и, возможно, некоторый другой транспортный объект. Если любой транспортный объект, декларированный в FDT В, является транспортным объектом, который не объявлен ни в каком предыдущем экземпляре таблицы FDT, а именно FDT А, приемник останавливает (и как опция сбрасывает) таймер t2 ожидания таблицы для этих транспортных объектов (см. шаг S3.8 на фиг.3). Кроме того, если FDT В декларирует транспортный объект "z", приемник 19 останавливает (и как опция сбрасывает) таймер t3 ожидания нового объекта (см. шаг S3.13).

Сеанс доставки файлов имеет заданное время Tend окончания, которое в этом примере известно приемнику 19. В этом случае, когда приемник 19 достигает времени Tend окончания сеанса доставки файлов, он прекращает сеанс доставки файлов.

Конечный автомат 29 на фиг.6 включает пять состояний, 30-34. Во втором состоянии 31 приемник ожидает идентификатор TOI или декларацию идентификатора TOI. В третьем состоянии 32 приемник бездействует. В пятом состоянии 34 были полностью приняты все декларированные объекты. Сеанс можно прекратить в первом состоянии 30, которое является состоянием ошибки, или в четвертом состоянии 33, которое свидетельствует о том, что сеанс завершен.

Имеется множество событий, которые могут вывести из состояния 31 ожидания. Первый переход 36 происходит, когда принята таблица FDT, которая содержит один или несколько новых идентификаторов TOI, ранее не декларированных. Это включает установку и запуск таймера t1 ожидания фрагмента для каждого из новых идентификаторов TOI. Переход 36 является переходом в состояние 31 ожидания. Второй переход 37 запускается в ответ на событие, заключающееся в принятии пакета для идентификатора TOI, для которого имеется активный таймер t1 ожидания фрагмента. Реакция заключается в остановке таймера t1 ожидания фрагмента для этого идентификатора TOI. Этот переход 37 может произойти только при условии, что все еще имеется один или несколько активных таймеров t1 ожидания фрагмента. Переход 37 является переходом в состояние 31 ожидания. Третий переход 38 запускается при событии, заключающемся в принятии таблицы FDT, содержащей декларацию для идентификатора TOI, для которого имеется активный таймер t2 ожидания таблицы. Это может произойти, только если все еще имеется один или несколько активных таймеров t2 ожидания таблицы. При переходе 38 активный таймер t2 ожидания таблицы для данного идентификатора TOI останавливают. Третий переход 38 является переходом в состояние 31 ожидания. Четвертый переход 39 запускается событием, заключающемся в принятии первого пакета для идентификатора TOI, которого нет в таблице FDT. Это событие запускает таймер t2 ожидания таблицы для этого идентификатора TOI. Этот переход является переходом в состояние 31 ожидания.

Переход 40 происходит из состояния 31 ожидания в состояние 32 бездействия в ответ на событие, заключающееся в приеме пакета для того идентификатора TOI, для которого имеется активный таймер t1 ожидания фрагмента. Таймер t1 ожидания фрагмента для этого идентификатора TOI останавливается. Шестой переход 41 запускается событием, заключающимся в приеме таблицы FDT, которая содержит декларацию для идентификатора TOI, для которого имеется активный таймер t2 ожидания таблицы. В результате этого перехода 41 происходит остановка таймера ожидания таблицы для этого идентификатора TOI. Шестой переход 41 является переходом из состояния 31 ожидания в состояние 32 бездействия.

В состоянии 32 бездействия имеются три возможных перехода. Первый переход 42 происходит в ответ на событие приема таблицы FDT, которая содержит один или несколько новых идентификаторов TOI. Это событие приводит к установке и запуску таймера t1 ожидания фрагмента для каждого из этих новых идентификаторов TOI. Переход происходит из состояния 32 бездействия в состояние 31 ожидания. Другой переход 43 из состояния 32 бездействия в состояние 31 ожидания происходит в ответ на прием первого пакета для идентификатора TOI, которого нет в FDT. Это событие запускает таймер t2 ожидания таблицы для этого идентификатора. Третий переход происходит из состояния 32 бездействия в состояние 34 приема объектов. Этот переход на чертеже обозначен позицией 44. Этот переход 44 имеет место, когда принят последний недостающий фрагмент файла. Это событие запускает сброс и запуск таймера t3 ожидания нового объекта.

Из состояния 34 приема объектов возможны три перехода. Первый переход 45А происходит в состояние 31 ожидания и имеет место, когда принята таблица FDT, содержащая один или несколько новых идентификаторов TOI. Это событие запускает установку и запуск таймера t1 ожидания фрагмента для каждого из новых идентификаторов TOI. Как опция этот переход 45А может вызвать остановку таймера t3 ожидания нового объекта. Второй переход 45В происходит в состояние 31 ожидания. Этот переход 45В имеет место, когда принят пакет с идентификатором TOI, который не был декларирован ни в одном экземпляре принятой ранее таблицы FDT. Переход 45В приводит к установке и запуску таймера t2 ожидания таблицы для принятых новых идентификаторов TOI. Как опция этот переход 45В может вызвать остановку таймера t3 ожидания нового объекта. Третий переход 46 происходит из состояния 34 приема транспортных объектов в состояние 33 завершения сеанса. Этот переход 46 происходит, когда таймер t3 ожидания нового объекта завершает свой отсчет.

Переход из состояния 31 ожидания в состояние 30 ошибки происходит, когда завершает отсчет любой из таймеров t1 ожидания фрагмента или таймеров t2 ожидания таблицы для любого идентификатора TOI. На чертеже этот переход обозначен позицией 47. Переход 48 из состояния 31 ожидания в состояние 34 приема транспортного объекта происходит тогда, когда принят последний недостающий фрагмент файла. Это приводит к сбросу и запуску таймера t3 ожидания нового объекта.

На фиг.7 показан альтернативный конечный автомат 49. В этом автомате состояние 50 ожидания относится к состоянию, в котором ожидается идентификатор TOI или декларация идентификатора TOI. Имеется состояние 51 незавершенности сеанса. В него переходят из состояния 50 ожидания путем перехода 52, который происходит в ответ на истечение времени таймера t3 ожидания нового объекта. Это происходит только в случае, если один или несколько декларированных объектов еще не приняты. Переход 53 происходит из состояния 50 ожидания в состояние 54 ошибки в ответ на истечение времени таймера t1 ожидания фрагмента или любого таймера t2 ожидания таблицы для любого идентификатора TOI. Кроме того, имеются состояние 55 бездействия и состояние 56 окончания сеанса.

Переход 57 происходит из состояния 50 ожидания в него же в ответ на событие, заключающееся в приеме таблицы FDT, которая содержит новый идентификатор TOI, т.е. идентификатор TOI, который не был ранее декларирован. Действия, следующие из перехода 57, - это запуск и установка таймера t1 ожидания фрагмента для каждого нового идентификатора TOI, декларированного в FDT, и сброс таймера t3 ожидания нового объекта. Второй переход 58 из состояния ожидания в него же происходит в ответ на событие, заключающееся в приеме пакета для такого идентификатора TOI, для которого имеется активный таймер t1 ожидания фрагмента. Это вызывает остановку таймера t1 ожидания фрагмента для этого идентификатора TOI. Это происходит только в том случае, если имеется один или несколько активных таймеров t1 ожидания фрагмента. Третий переход 59 из состояния 50 ожидания в него же происходит в ответ на событие, заключающееся в приеме таблицы FDT, которая содержит декларацию для такого идентификатора TOI, для которого имеется активный таймер t2 ожидания таблицы. В результате происходит остановка таймера t2 ожидания таблицы для этого идентификатора TOI. Это происходит только в случае, если имеется один или несколько активных таймеров t2 ожидания таблицы. Четвертый переход 60 из состояния 50 ожидания в него же происходит, когда принят первый пакет для идентификатора TOI, которого нет в FDT. Это вызывает запуск таймера t2 ожидания таблицы для этого идентификатора TOI.

Переход 61 происходит из состояния 50 ожидания в состояние 55 бездействия, когда принят пакет для такого идентификатора TOI, для которого имеется активный таймер t1 ожидания фрагмента. Это приводит к остановке таймера t1 ожидания фрагмента для этого идентификатора TOI. Еще один переход 62 из состояния 50 ожидания в состояние 55 бездействия происходит, когда принята таблица FDT, содержащая декларацию для такого идентификатора TOI, для которого имеется активный таймер t2 ожидания таблицы. В результате происходит остановка таймера t2 ожидания таблицы для этого идентификатора TOI.

Переход 63 из состояния 55 бездействия в состояние 50 ожидания происходит в ответ на событие, заключающееся в приеме таблицы FDT, которая содержит один или несколько новых идентификаторов TOI. При переходе 63 происходит установка и запуск таймера t1 ожидания фрагмента для каждого нового идентификатора TOI и сброс таймера t3 ожидания нового объекта. Еще один переход 64 из состояния 55 бездействия в состояние 50 ожидания происходит, когда принят первый пакет для идентификатора TOI, который отсутствует в таблице FDT. Это вызывает запуск таймера t2 ожидания таблицы для этого идентификатора TOI.

Переход 65 из состояния 55 бездействия в состояние 51 незавершенности сеанса происходит, когда завершает отсчет таймер t3 ожидания нового объекта. Это происходит только в случае, если один или несколько декларированных объектов еще не приняты. Если в состоянии 55 бездействия таймер t3 ожидания нового объекта завершает отсчет и все декларированные объекты приняты, то вместо этого происходит переход 66 в состояние 56 завершения сеанса.

Из состояния 51 незавершенности сеанса возможно пять переходов. Во-первых, в ответ на событие, заключающееся в приеме пакета, который отсутствует в декларированных идентификаторах TOI, и при условии, что все декларированные объекты были приняты, происходит переход 67 в состояние 56 завершения сеанса.

В ответ на событие, заключающееся в приеме первого пакета для недекларированного идентификатора TOI, которого нет в таблице FDT, возможно два альтернативных перехода, которые составляют два различных варианта выполнения настоящего изобретения. Первый вариант заключается в переходе 68А из состояния 51 незавершенности сеанса в состояние 50 ожидания. Это перемещение 68А вызывает запуск таймера t2 ожидания таблицы для этого идентификатора TOI. Наличие перехода 68А позволяет дополнить набор файлов, которые были приняты к данному моменту, файлами, которые еще не встречались. Альтернативно, переход 68В из состояния 51 незавершенности сеанса в него же является более жестким и позволяет завершить лишь встретившиеся файлы. Этот переход не приводит к изменению состояния каких-либо таймеров.

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

Могут также быть и другие переходы (не показаны) из состояния 51 незавершенности сеанса в состояние 54 ошибки.

На фиг.8 показан альтернативный конечный автомат 70. В конечном автомате 70 имеется состояние 71 ожидания. В состоянии ожидания конечный автомат 70 ожидает идентификатор TOI или декларацию идентификатора TOI. Другими состояниями в конечном автомате 70 являются состояние 72 ошибки, состояние 73 бездействия и состояние 74 завершения сеанса.

Из состояния 71 ожидания конечный автомат 70 может совершить переход 75 назад в состояние 71 ожидания. Переход 75 происходит в ответ на событие, заключающееся в приеме таблицы FDT, которая содержит один или несколько новых идентификаторов TOI, Этот переход 75 инициирует установку и запуск таймера t1 ожидания фрагмента для каждого нового идентификатора TOI. Кроме того, он сбрасывает таймер t3 ожидания нового объекта. Еще один переход 76 из состояния 71 ожидания в него же происходит, когда принят пакет для идентификатора TOI, для которого имеется активный таймер t1 ожидания фрагмента. Он вызывает остановку таймера ожидания фрагмента для этого идентификатора TOI. Это происходит только в том случае, когда имеется один или несколько активных таймеров t1 ожидания фрагмента. Третий переход 78 из состояния 71 ожидания в него же происходит, когда принята таблица FDT, содержащая декларацию для такого идентификатора TOI, для которого имеется активный таймер t2 ожидания таблицы. Это происходит только в том случае, когда имеется один или несколько активных таймеров t2 ожидания таблицы. Таймер t2 ожидания таблицы для каждого идентификатора TOI, который входит в принятую таблицу FDT, останавливают. Четвертый переход 79 из состояния 71 ожидания в него же происходит, когда принят первый пакет для такого идентификатора TOI, который имеется в таблице FDT. При этом происходит запуск таймера t2 ожидания таблицы для этого идентификатора TOI.

Из состояния 71 ожидания переход 80 в состояние 73 бездействия происходит в результате события, заключающегося в приеме пакета для такого идентификатора TOI, для которого имеется активный таймер t1 ожидания фрагмента. Переход 80 приводит к остановке таймера ожидания фрагмента для этого идентификатора TOI. Еще один переход 81 из состояния 71 ожидания в состояние 73 бездействия происходит в ответ на прием таблицы FDT, которая содержит декларацию для такого идентификатора TOI, для которого имеется активный таймер t2 ожидания таблицы. Таймер t2 ожидания таблицы для этого идентификатора TOI останавливают.

Из состояния 73 бездействия переход 82 в состояние 71 ожидания происходит в ответ на прием таблицы FDT, которая содержит один или несколько новых идентификаторов TOI. Это приводит к установке и запуску таймера t1 ожидания фрагмента для каждого нового идентификатора TOI и к сбросу таймера t3 ожидания нового объекта. Еще один переход 83 из состояния 73 бездействия в состояние 71 ожидания происходит, когда принят первый пакет для такого идентификатора TOI, которого нет в таблице FDT. Это приводит к запуску таймера t2 ожидания таблицы для этого идентификатора TOI.

Если конечный автомат 70 находится в состоянии 71 ожидания и таймер t3 ожидания нового объекта завершил отсчет, происходит переход 84 в состояние 72 ошибки. Это происходит только в случае, если существует один или несколько декларированных объектов, которые еще не были приняты. Если в состоянии 71 ожидания любой из таймеров t1 ожидания фрагмента или любой из таймеров t2 ожидания таблицы для любого идентификатора TOI завершает отсчет, происходит переход 85 в состояние 72 ошибки.

Из состояния 73 бездействия при завершении времени таймера t3 ожидания нового объекта происходит переход 86 в состояние 74 завершения сеанса. Для этого необходимо, чтобы были приняты декларированные объекты. Если таймер t3 ожидания нового объекта завершает отсчет, а один или несколько декларированных объектов не были приняты, вместо этого происходит переход 87 в состояние 72 ошибки.

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

Параметры можно передавать в заголовках LCT расширения (LCT - Layered Coding Transport - транспорт многоуровневого кодирования). Например, все параметры можно передать в пределах одного LCT расширения переменной длины. Здесь заголовок LCT расширения может включать последовательно следующие поля: НЕТ (Header Extension Type - Тип расширения заголовка); HEL (Header Extention Length - Длина расширения заголовка); параметр времени ожидания фрагмента; параметр времени ожидания таблицы и параметр времени ожидания объекта. Порядок полей не имеет значения.

Альтернативно, каждый параметр может быть передан в соответствующем заголовке LCT расширения фиксированной длины. Например, могут быть три расширения заголовка, каждый из которых включает поле Тип расширения заголовка (НЕТ) и соответствующее поле параметра времени.

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

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

<xs:attribute name="table_wait"

type="xs:unsignedLong" use="optional"/>

<xs:attribute name="fragment_wait"

type="xs:unsignedLong" use="optional"/>

<xs:attribute name="new_object"

type="xs:unsignedLong" use="optional"/>

Например, экземпляр таблицы может иметь следующий вид:

<?xml version="1.0" encoding="UTF-8"?>

<FDT-Instance xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmms:fl="http://www.example.corn/flute"

xsi:schemaLocation=:"http: //www. example.corn/flute-fdt.xsd"

Expires="2890842807"

table_wait="100"

fragment_wait="50"

new_object="200">

<File

Content-Location="www.example.com/menu/tracklist.httml"

TOI="1"

Content-Type="text/html"/>

<File

Content-Location="www.example.com/tracks/trackl.mp3"

TOI="2"

Content-Length="6100"

Content-Type="audio/mp3"

Content-Encodings="gzip"

Content-MD5="Eth76GlkJU45sghK"

Some-Private-Extension-Tag="abcl23"/>

</FDT-Instance>

Альтернативно, параметры можно передавать в виде заголовков расширения на любом другом уровне протокола, например L2, IP, UDP, TCP или RTP.

Альтернативно, параметры можно переносить в транспортных объектах, например в файлах (коротких файлах). Можно использовать любой подходящий формат, например XML, или же любой текстовый файл или файл данных. Ниже приведен пример файла:

<start-of-file>

table_wait=100; fragment_wait=200; new_object=300

<end-of-file>

Альтернативно, параметры можно передавать по внеполосной сигнализации. В одном из примеров используется поле протокола описания сеанса (SDP - Session Description Protocol). Ниже даны примеры полей:

a=fragment_wait:100

a=table_wait:200

a=new_object:300

Альтернативно:

a=fragment_wait:100; table_wait:200; new_object:300

Вышеуказанные поля могут быть параметрами уровня среды или уровня сеанса.

Параметры, передаваемые вне полосы, могут быть вызваны из памяти или могут транслироваться по выделенному каналу.

Альтернативно, параметры могут быть помещены в "конверт", например:

<file-envelope

table_wait=100

fragment_wait=200

new_object=300

<file-body …the actual file data…

</file-body

</file-envelope

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

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

Хотя варианты выполнения настоящего изобретения были описаны в связи с многоадресной передачей данных с использованием Интернет-протокола (IPDC) в рамках цифрового телевизионного вещания для портативных устройств (DVB-H), изобретение может быть применено в любой системе, способной осуществлять пакетную передачу в режимах "один - одному" (передача в один адрес), "один - многим" (многоадресная передача) или "многие - многим" (групповое вещание). Кроме того, канал системы связи может быть однонаправленным (например DVB-T/S/C/H, DAB) или двунаправленным (например GPRS, UMTS, MBMS, BCMCS, WLAN и т.д.). Пакеты данных могут быть пакетами стандарта IPv4 или IPv6, хотя изобретение не ограничено этими типами пакетов.