МЕХАНИЗМ ОТВЕТА ПРИ ВОССТАНОВЛЕНИИ ДАННЫХ В РЕЖИМЕ "ТОЧКА-ТОЧКА" ДЛЯ СИСТЕМ ПЕРЕДАЧИ "ТОЧКА - МНОГО ТОЧЕК" Российский патент 2009 года по МПК H04L1/16 H04L29/06 

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

Для служб типа "точка-много точек" (PtM, Point-to-Multipoint) (называемых также службами "один-многим") в таких системах, как групповое вещание по протоколу Интернета (IP), вещательная передача данных по IP (IPDC, IP Data Casting) и мультимедийное вещание/ многоадресная передача (MBMS, Multimedia Broadcast/Multicast Services), важной службой является доставка файлов, например, загрузка мультимедийных файлов.

Однако многие характеристики доставки файлов в рамках протоколов в режиме точка-точка (PtP), например, протокола передачи файлов (FTP, File Transfer Protocol) и протокола пересылки гипертекста (HTTP, Hypertext Transfer Protocol), являются проблематичными для сценариев точка-много точек. В частности, надежная доставка файлов, то есть гарантированная доставка файлов с использованием протоколов подтверждения (АСК), аналогичных режиму точка-точка, например протокола управления передачей (TCP, Transport Control Protocol), невыполнима.

В настоящее время рабочая группа по надежной передаче данных группового вещания (RMT, Reliable Multicast Transport) международной организации IETF (International Engineering Task Force) производит стандартизацию двух категорий транспортных протоколов группового вещания, устойчивых к ошибкам. В первой категории надежность обеспечивается с использованием прямой (упреждающей) коррекции ошибок (коррекции ошибок без обратной связи) (FEC, Forward Error Correction), то есть путем посылки определенного количества избыточных данных, которые могут помочь приемнику исправить ошибочные данные; во второй категории надежность достигается с помощью обратной связи, то есть за счет того, что приемник посылает подтверждения (АСК) или неподтверждения (NACK) приема данных.

Асинхронное Многоуровневое Кодирование (ALC, Asynchronous Layered Coding) относится к протоколам первой категории, в то время как протокол NACK-ориентированного надежного группового вещания (NORM, NACK-Oriented Reliable Multicast) относится ко второй категории. Сети доступа, в которых могут использоваться эти протоколы, включают, но этим не ограничены, беспроводные сети многостанционного доступа, такие как универсальная мобильная система связи (UMTS, Universal Mobile Telecommunications System, включая сеть радиодоступа усовершенствованной глобальной системы мобильной связи (GERAN, Global System for Mobile Communications Evolution Radio Access Network) и наземную сеть радиодоступа для UMTS (UTRAN, UMTS Terrestrial Radio Access Network)), беспроводные локальные сети (WLAN, Wireless Local Area Networks), сети для трансляции цифрового телевидения через наземные средства (DVB-T, Digital Video Broadcasting - Terrestrial) и сети для трансляции цифрового телевидения через спутники (DVB-S, Digital Video Broadcasting - Satellite).

Сообщения NACK в общем не связаны только с NORM, но они также могут использоваться совместно с другими протоколами или системами, например с системами, которые поддерживают сеансы под управлением протокола Доставки Файлов Однонаправленным Транспортом (FLUTE, File Delivery over Unidirectional Transport).

FLUTE представляет собой транспортный протокол типа "один-многим", который основан на использовании блоков FEC и ALC. Он предназначен для доставки файлов из передатчика (передатчиков) в приемник (приемники) по однонаправленным системам передачи. В нем имеются специальные особенности, которые делают его подходящим для беспроводных систем, работающих в режиме точка - много точек. Детали протокола FLUTE более подробно обсуждаются в работе "FLUTE - File Delivery over Unidirectional Transport" (Интернет-проект), подготовленной вышеупомянутой рабочей группой RMT IETF.

Использование FLUTE предписано, например, Проектом партнерства по системам третьего поколения (3GPP) для загрузки файлов в сеансах систем MBMS. В таких сеансах FLUTE прямая коррекция ошибок может как использоваться, так и не использоваться. В любом случае не следует ожидать, что по завершении сеанса связи все приемники смогут получить файл целиком. В связи с этим 3GPP работает над определением сеансов восстановления данных в режиме точка-точка, при этом приемникам разрешено выдавать сигналы запроса на передачу символов восстановительных данных, например символов данных, которые не были корректно приняты приемником, в передатчик или сервер восстановления данных путем сообщений NACK, с целью получения достаточного количества символов данных для последующего восстановления загруженного контента. В указанных сообщениях NACK указанные символы восстановительных данных, потребованные указанными приемниками, должны быть в достаточной мере идентифицированы, чтобы сервер восстановления данных был в состоянии определить, какие символы данных необходимо передать или повторно передать.

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

Хотя символы данных передают в сеансе связи "точка-много точек", который основан на ненадежном протоколе, например протоколе пользовательских дейтаграмм (UDP, User Datagram Protocol), а символы восстановительных данных передают в сеансе точка-точка, который основан на надежном протоколе, например протоколе управления передачей (TCP), в настоящее время символы восстановительных данных несут ту же самую заголовочную информацию, что и символы данных. Эта заголовочная информация включает:

- принятый по умолчанию заголовок Транспорта с Многоуровневым Кодированием (LCT, Layered Coding Transport),

- секцию расширений заголовка LCT и

- секцию идентификатора полезной нагрузки с прямой коррекцией ошибок (FEC Payload ID).

Заголовок LCT включает:

- первую секцию с рядом флагов, поле длины заголовка LCT и поле "точки кода" (Code Point) для указания идентификатора кодирования с прямой коррекцией ошибок (FEC Encoding ID),

- информацию управления перегрузкой (CCI, Congestion Control Information),

идентификатор сеанса передачи (TSI, Transport Session Identifier),

идентификатор транспортного объекта (TOI, Transport Object Identifier),

текущее время отправителя (SCT, Sender Current Time) и

ожидаемое оставшееся время (ERT, Expected Residual Time).

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Таким образом, имеется потребность в более эффективном способе, системе, передатчике, сетевом элементе, приемнике и программном обеспечении для системы, предназначенной для передачи символов данных в сеансах связи в режиме точка-много точек и в режиме точка-точка.

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

Указанная система может представлять собой любую беспроводную или проводную систему, причем символы данных передают по меньшей мере из одного передатчика в один или более приемников. Указанная передача в режиме точка-много точек может быть широковещательной трансляцией, в которой все приемники связаны с указанным передатчиком, или передачей группового вещания, в которой только подгруппа из всех приемников связана с указанным передатчиком. Указанная система может, например, быть развернута в контексте UMTS, LAN, WLAN, DVB-T или DVB-S, и может быть предназначена для распределения контента (содержания), например мультимедийных файлов, среди множества приемников. Передача указанного символа данных или большего количества символов данных может быть выполнена с использованием однонаправленных или двунаправленных каналов.

Указанные переданные символы данных могут, например, быть связанными с содержанием, которое должно быть передано в указанные приемники. Это содержание может быть сегментировано и обработано для передачи в указанные приемники, при этом должно быть понятно, что указанные символы данных получаются в результате этой сегментации и обработки. Например, один символ данных может представлять собой один или более кодовый символ (например, кодовый пакет), полученный кодированием транспортного объекта, например, мультимедийного файла, или его части, с прямой коррекцией ошибок. Поэтому каждый символ данных может представлять собой только одну единицу переносимой информации, например, один двоичный символ (бит), или множество единиц переносимой информации.

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

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

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

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

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

Таким образом, настоящее изобретение предлагает использовать различные типы заголовков для передачи, с одной стороны, символов данных и, с другой стороны, символов восстановительных данных. Это предложение учитывает тот факт, что символы данных передаются в сеансах связи в режиме "точка-много точек", которые основаны на ненадежных протоколах (например, UDP), тогда как символы восстановительных данных передаются в сеансе связи в режиме точка-точка, который основан на надежных протоколах (например, TCP), поэтому по меньшей мере некоторые из параметров, которые должны содержаться в заголовках первого типа, используемых для символов данных, не должны содержатся в заголовках символов данных второго типа, используемых с символами восстановительных данных. Этот подход в рамках настоящего изобретения обеспечивает более эффективную передачу символов восстановительных данных при значительно меньшем количестве служебных данных. При использовании заголовков второго типа, которые по меньшей мере частично подчиняются указанному протоколу доставки файлов, требуются лишь незначительные изменения как в сервере восстановления, так и в объектах протокола приемников и соответствующей реализации, или таковые вообще не требуются.

Согласно настоящему изобретению указанный заголовок первого типа может содержать по меньшей мере один параметр, который не содержится в указанном заголовке второго типа, и этот указанный параметр может быть связан с передачей в режиме точка-много точек. Указанный параметр может быть, например, информацией управления перегрузкой (CCI), текущим временем отправителя (SCT), ожидаемым оставшимся временем (ERT), а в некоторых случаях идентификатором сеанса передачи (TSI).

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

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

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

Согласно настоящему изобретению указанный протокол доставки файлов может быть протоколом Доставки Файлов Однонаправленным Транспортом (FLUTE), а указанные символы данных и символы восстановительных данных могут представлять собой кодовые символы FLUTE. Указанные кодовые символы FLUTE могут быть получены, например, кодированием с прямой коррекцией ошибок частей транспортного объекта, который нужно доставить в указанный приемник или большее количество приемников в рамках указанного сеанса связи в режиме точка-много точек. Каждый символ данных может представлять собой, например, один или несколько кодовых символов.

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

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

Согласно указанному первому варианту выполнения настоящего изобретения указанный заголовок второго типа в сжатых пакетах FLUTE включает по меньшей мере часть заголовка Транспорта с Многоуровневым Кодированием, идентификатор указанного кодового символа FLUTE в указанном сжатом пакете FLUTE и размер указанного кодового символа FLUTE. Указанный заголовок для Транспорта с Многоуровневым Кодированием может основываться на стандартном блоке Транспорта с Многоуровневым Кодированием, а уровень протокола FLUTE может быть надстроен на его вершине. Указанный идентификатор кодового символа FLUTE может быть, например, идентификатором полезной нагрузки с прямой коррекцией ошибок, обеспечивающим номер исходного блока (SBN, Source Block Number) и идентификатор кодового символа (ESI, Encoding Symbol Identifier), соответствующие указанному кодовому символу FLUTE.

Согласно второму варианту выполнения настоящего изобретения указанный по меньшей мере один пакет HTTP имеет составную структуру расширений почтовой службы Интернета (MIME, Multipurpose Internet Mail Extension), а указанные сжатые пакеты FLUTE отделены от указанного заголовка пакета HTTP и друг от друга границами MIME. Такое разделение границами MIME позволяет опускать параметр размера кодового символа в указанных заголовках второго типа.

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

Согласно третьему варианту выполнения настоящего изобретения по меньшей мере один из указанных пакетов HTTP включает заголовок пакета HTTP, один или более блоков, которые включают по меньшей мере два кодовых символа FLUTE и соответствующие им идентификаторы, и один соответствующий заголовок второго типа для каждого из указанных блоков, причем каждый соответствующий заголовок второго типа действителен для всех кодовых символов FLUTE соответствующего блока. Объединение кодовых символов FLUTE в блоки позволяет использовать только один заголовок второго типа для каждого блока, вместо того, чтобы обязательно давать один заголовок второго типа на каждый кодовый символ FLUTE. Указанные кодовые символы FLUTE, объединенные в блок, предпочтительно имеют те же самые параметры, например, тот же самый размер, тот же самый Т01, тот же TSI, а параметры, которые являются различными для каждого кодового символа FLUTE, могут тогда быть включены в указанные блоки кодовых символов FLUTE.

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

Согласно указанному третьему варианту выполнения настоящего изобретения указанные соответствующие заголовки второго типа включают часть заголовка транспорта с многоуровневым кодированием и размер указанных кодовых символов FLUTE в указанных соответствующих блоках.

Согласно указанному третьему варианту выполнения настоящего изобретения по меньшей мере один из указанных блоков включает кодовый символ FLUTE, соответствующий ему идентификатор, соответствующую длину заголовка транспорта с многоуровневым кодированием (LCT) и по меньшей мере одно расширение заголовка транспорта с многоуровневым кодированием. Указанный заголовок LCT может, например, представлять собой EXT_FTI или EXT_FDT. Указанная соответствующая длина заголовка LCT может указывать на присутствие или отсутствие одного или более указанных расширений заголовка LCT.

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

Согласно указанному четвертому варианту выполнения настоящего изобретения указанный по меньшей мере один пакет HTTP имеет структуру MIME, а указанный заголовок пакета HTTP, указанный один заголовок второго типа и указанный один или более блоков взаимно разделены границами MIME. Это позволяет опустить явную передачу размера блоков кодовых символов FLUTE.

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

Согласно указанному четвертому варианту выполнения настоящего изобретения по меньшей мере один из указанных подзаголовков включает одну длину заголовка транспорта с многоуровневым кодированием (LCT) для каждого кодового символа FLUTE в соответствующем блоке и по меньшей мере одно расширение заголовка транспорта с многоуровневым кодированием по меньшей мере для одного из указанных кодовых символов FLUTE в соответствующем блоке. Указанное расширение заголовка LCT может представлять собой, например, EXT_FDT или EXT_FTI. Длина заголовка LCT может указывать, присутствует ли одно или большее количество из указанных расширений заголовка LCT или нет.

Согласно настоящему изобретению указанный заголовок второго типа может дополнительно включать идентификатор указанного сеанса передачи в режиме точка-много точек. Указанный идентификатор может быть, например, Идентификатором Сеанса Передачи (TSI, Transport Session Identifier), Однако, если присутствует только один сеанс передачи или если из контекста понятно, к какому именно сеансу передачи относятся кодовые символы FLUTE, идентификатор указанного сеанса передачи может и не требоваться.

Согласно настоящему изобретению указанный заголовок второго типа может дополнительно включать идентификатор передаваемого объекта, к которому относятся указанные кодовые символы FLUTE. Этот идентификатор может быть, например, идентификатором транспортного объекта (TOI). Однако, если в сеансе передачи передан только один транспортный объект, указанный идентификатор может и не требоваться.

Согласно настоящему изобретению указанный заголовок второго типа может дополнительно включать расширения заголовка транспорта с многоуровневым кодированием. Эти расширения заголовка LCT могут представлять собой, например, EXT_FTI или EXT_FDT.

Согласно настоящему изобретению указанная часть заголовка LCT может включать номер версии LCT, флаг управления перегрузкой, зарезервированное место, флаг идентификатора сеанса передачи (TSI), флаг идентификатора транспортного объекта (TOI), флаг текущего времени отправителя, флаг ожидаемого оставшегося времени, флаг завершения сеанса, флаг закрытия объекта, длину заголовка LCT и точку кода (Code Point). Указанная часть заголовка LCT может иметь длину, например, 4 байта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эти и другие аспекты настоящего изобретения станут понятны из последующего описания вариантов выполнения настоящего изобретения.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

На чертежах иллюстрируется следующее:

на фиг.1a схематично представлена передача символов данных в сеансе передачи "точка-много точек" (PtM) согласно настоящему изобретению;

на фиг.1b схематично представлен сигнал запроса символов восстановительных данных в сеансе восстановления данных в режиме точка-точка (PtP) согласно настоящему изобретению;

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

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

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

на фиг.3а схематично представлен сжатый пакет FLUTE согласно первому варианту выполнения настоящего изобретения;

на фиг.3b схематично представлено встраивание сжатых пакетов FLUTE в пакет HTTP согласно первому варианту выполнения настоящего изобретения;

на фиг.4а схематично представлен сжатый пакет FLUTE согласно второму варианту выполнения настоящего изобретения;

на фиг.4b схематично представлено встраивание сжатых пакетов FLUTE в пакет HTTP согласно второму варианту выполнения настоящего изобретения;

на фиг.5а схематично представлен пакет HTTP согласно третьему варианту выполнения настоящего изобретения;

на фиг.5b схематично представлен общий заголовок FLUTE согласно третьему варианту выполнения настоящего изобретения;

на фиг.5с схематично представлен блок кодовых символов согласно третьему варианту выполнения настоящего изобретения;

на фиг.5d схематично представлен альтернативный блок кодовых символов в случае использования расширений заголовка LCT согласно третьему варианту выполнения настоящего изобретения;

на фиг.6а схематично представлен пакет HTTP согласно четвертому варианту выполнения настоящего изобретения;

на фиг.6b схематично представлен заголовок индексного объекта согласно четвертому варианту выполнения настоящего изобретения;

на фиг.6с схематично представлен блок кодовых символов согласно четвертому варианту выполнения настоящего изобретения; и

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

В этом подробном описании мы будем часто обращаться к ситуации, при которой протокол FLUTE/UDP используется в случае передачи в режиме PtM (точка-много точек), а протокол HTTP/TCP используется в случае передачи в режиме PtP (точка-точка). Следует отметить, что такой выбор сделан только для примера, и настоящее изобретение может быть в равной степени применено в аналогичных сценариях, когда символы данных, которые подчиняются определенному протоколу и сначала передаются в режиме точка-много точек, затем должны повторно передаваться в режиме точка-точка, а следовательно, должны по меньшей мере частично соответствовать указанному протоколу.

На фиг.1а иллюстрируется сеанс передачи в режиме точка-много точек, когда символы данных передаются из передатчика 1 в множество приемников 3-1…3-3. Передатчик связан с сетью 2, например Интернетом, и, таким образом, имеет доступ к контенту, который должен быть доставлен в указанное множество приемников при широковещательной трансляции или в сеансе группового вещания, например в системе 3GPP MBMS. Для этого передатчик содержит процессор 10, память 11 и передающий/приемный (Tx/Rx) элемент. Контент собирается из сети 2 под управлением процессора 10, возможно, хранится в памяти 11, а затем кодируется и модулируется для передачи через передающий/приемный элемент 12 в передающие/приемные элементы 32 приемников 3-1…3-3. Понятно, что указанный процессор 10 реализует функциональные возможности всех уровней протокольного стека ISO/OSI, в частности, кодирование контента в кодовые символы FLUTE, которые совместно с заголовком FLUTE формируют пакет FLUTE, генерацию этих заголовков FLUTE выполняет указанный процессор 10.

В указанных приемниках 3-1…3-3, из которых более подробно показан только конкретный приемник 3-1, пакеты FLUTE принимаются посредством передающего/приемного элемента 32, демодулируются и декодируются процессором 30 и сохраняются в памяти 31 в качестве входных данных для приложения любого типа, запущенного в указанном приемнике или в присоединенном устройстве.

На фиг.1b изображен случай, когда пакеты FLUTE не были правильно приняты в указанном конкретном приемнике 3-1 или если в указанном конкретном приемнике 3-1 получены не все пакеты FLUTE, так что требуется передача символов восстановительных данных, которые позволяют указанному конкретному приемнику 3-1 восстановить полный контент, который передается указанным передатчиком 1. Для этого посылается сообщение запроса на восстановление данных из приемника 3-1 в сервер 4 восстановления данных, который имеет структуру, аналогичную структуре передатчика 1, и может быть идентичным указанному передатчику 1. Передача указанных сообщений запроса на восстановление данных может иметь место, например, в сеансе связи по протоколу HTTP. Затем указанный сервер 4 восстановления данных обрабатывает указанное сообщение запроса на восстановление данных, которое содержит информацию, связанную с пакетами FLUTE, затребованными указанным конкретным приемником 3-1.

На фиг.1с изображен результат этой обработки сервером 4 восстановления данных. Когда сервер 4 восстановления данных определил кодовые символы FLUTE, которые нужно выслать в конкретный приемник 3-1 в качестве символов восстановительных данных в ответном сообщении восстановления, он берет информацию, необходимую для генерации этих символов восстановительных данных, из сети 2, например, в виде транспортного объекта или его части, к которым относятся затребованные кодовые символы FLUTE. На основе этого транспортного объекта процессор 40 генерирует символы восстановительных данных (кодовые символы FLUTE), снабженные сжатым заголовком FLUTE для формирования сжатого пакета FLUTE, а затем передает их в конкретный приемник 3-1 в ответном сообщении восстановления.

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

На фиг.2а схематично изображен протокольный стек, который используется для передачи в режиме точка-много точек кодовых символов FLUTE (содержащихся в пакетах FLUTE) из объектов протокола FLUTE в передатчике 1 в равноправные объекты протокола FLUTE в приемниках 3-1…3-3. Для передачи пакетов FLUTE уровень 51 FLUTE использует службы уровня 53 UDP, который, в свою очередь, использует службы уровня 53 протокола Интернет (IP). Фактическая передача пакетов IP осуществляется более низкими уровнями 54 протокольного стека. При этом используется заголовок FLUTE в соответствии с протоколом FLUTE.

На фиг.2b схематично изображен протокольный стек, который используется для передачи в режиме точка-точка кодовых символов FLUTE (содержащихся в сжатых пакетах FLUTE) из объектов протокола FLUTE в сервере 4 восстановления данных в равноправные объекты протокола FLUTE в конкретном приемнике 3-1. В этом случае используются сжатые заголовки FLUTE. В отличие от протокольного стека на фиг.2а уровень 51 протокола FLUTE теперь использует службу передачи в режиме точка-точка нижележащего уровня 55 HTTP, который находится выше уровня 56 TCP. Поэтому сжатые пакеты FLUTE встраиваются в пакеты HTTP, которые затем передаются между равноправными объектами HTTP сервера 4 восстановления данных и конкретного приемника 3-1. Для этой передачи HTTP/TCP использует службы нижележащего уровня 53 IP. По аналогии с фиг.2а затем пакеты IP передаются более низкими уровнями 54.

ПЕРВЫЙ ВАРИАНТ ВЫПОЛНЕНИЯ ИЗОБРЕТЕНИЯ

На фиг.3a изображен сжатый пакет 8 FLUTE согласно первому варианту выполнения настоящего изобретения. Этот сжатый пакет 8 FLUTE состоит из сжатого заголовка 6 FLUTE и одного кодового символа 7 в качестве полезной нагрузки.

Некоторые поля в пакетах FLUTE, которые используются при передаче в режиме точка-много точек, более не являются необходимыми в сеансе восстановления данных в режиме точка-точка, поскольку ответное сообщение восстановления передается по надежному каналу TCP в противоположность пакетам FLUTE в сеансе передачи в режиме точка-много точек, которые передаются по ненадежным каналам UDP. Таким образом, настоящее изобретение предлагает уменьшить пакеты FLUTE до минимума, чтобы в формат ответной полезной нагрузки в режиме точка-точка, который используется в сеансе восстановления данных, входили только существенные поля.

Сжатый заголовок FLUTE на фиг.3а содержит первые 4 байта заголовка 61, принятого по умолчанию для транспорта с многоуровневым кодированием (LCT, Layered Coding Transport). Соответствующие поля 6100-6111 и их значения остаются теми же самыми. Поля флага 6103 TSI, флага 6104 TOI и флага 6105 полуслова дают информацию о размере поля 62 TSI и поля 63 TOI. Поле 6111 точки кода используется для указания идентификатора кодирования с прямой коррекцией ошибок, как определено в протоколе FLUTE. Некоторые поля, такие как флаг 6101 управления перегрузкой, флаг 6106 текущего времени отправителя, флаг 6107 ожидаемого оставшегося времени, флаг 6108 завершения сеанса и флаг 6109 закрытия объекта, могут не посылаться в ответном сообщении в режиме точка-точка, поскольку они бесполезны при посылке данных по надежному каналу в режиме точка-точка. В итоге содержание и размеры в битах полей секции 61 заголовка LCT могут быть подытожены следующим образом:

V - номер версии LCT (4 бита)

С - флаг управления перегрузкой (2 бита)

R - зарезервировано (2 бита)

S - флаг TSI (1 бит)

0 - флаг TOI (2 бита)

Н - флаг полуслова (1 бит)

Т - флаг текущего времени отправителя (1 бит)

R - флаг ожидаемого оставшегося времени (1 бит)

А - флаг завершения сеанса (1 бит)

В - флаг закрытия объекта (1 бит)

HDR_LEN - длина заголовка LCT (8 битов)

СР - точка кода (8 битов)

Поле 62 TSI сжатого заголовка 6 FLUTE может иметь размер 0, 16, 32 или 48 битов. TSI необходим для идентификации сеанса передачи. До сеанса восстановления в режиме точка-точка конкретный приемник может участвовать в более чем одном сеансе загрузки FLUTE из того же самого передатчика. Таким образом, конкретный приемник в своем запросе на восстановление данных в режиме точка-точка должен указать сеанс, для которого он запрашивает восстановление данных в режиме точка-точка. Сервер восстановления данных в своем ответе восстановления в режиме точка-точка посылает TSI, чтобы конкретный приемник был в состоянии идентифицировать сеанс, которому принадлежит символ восстановительных данных. Адрес передатчика и TSI однозначно определяют сеанс.

Поле 63 TOI сжатого заголовка 6 FLUTE может иметь размер 0, 16, 32, 48, 64, 80, 96 или 112 битов. Идентификатор TOI необходим для идентификации объекта передачи в сеансе передачи. Доставка FLUTE может включать более одного объекта передачи (файла) в одном сеансе. Например, в одном и том же сеансе FLUTE можно загрузить звуковой файл и видеофайл. Конкретный приемник должен определить объект передачи, для которого необходимо восстановление данных в режиме точка-точка. Идентификаторы TOI и TSI уникально идентифицируют объект передачи.

Идентификатор 64 полезной нагрузки с прямой коррекцией ошибок (FEC) в сжатом заголовке 6 FLUTE зависит от идентификатора кодирования с прямой коррекцией ошибок. Идентификатор кодирования FEC и идентификатор полезной нагрузки FEC являются теми параметрами, которые были определены в RFC 3452 "Forward Error Correction Building Block" и RFC 3695 "Compact Forward Error Correction (FEC) Schemes" by the IETF and most recent IETF internet draft "Simple Forward Error Correction Schemes" by M. Luby, Digital Fountain, June 7, 2004 (доступно по адресу http://www.ietf.org/mail-archive/web/rmt/current/msg00312.html). Например, согласно RFC 3695 (принято для MBMS FLUTE), для идентификатора кодирования с прямой коррекцией ошибок, равного 0 (без кода FEC), идентификатор полезной нагрузки с прямой коррекцией ошибок состоит из следующего:

SBN - Номер исходного блока (2 байта)

ESI - Идентификатор кодового символа (2 байта).

Размер 65 поля кодового символа в сжатом заголовке 6 FLUTE имеет длину 2 байта и включает размер 7 кодового символа, который содержится в сжатом пакете 8 FLUTE в виде полезной нагрузки.

Очевидно, что сжатый заголовок 6 FLUTE согласно первому варианту выполнения настоящего изобретения больше не включает информацию об управлении перегрузкой (CCI), текущее время отправителя (SCT) и ожидаемое оставшееся время (ERT), хотя эти параметры присутствуют в заголовке FLUTE, который используется для передачи FLUTE/UDP в режиме точка-много точек. Эти параметры поддерживают ненадежный транспорт и широкую масштабируемость и, таким образом, не обязаны входить в сжатый заголовок 6 FLUTE, который используется для передачи FLUTE/HTTP в режиме точка-точка.

Информацию в сжатом заголовке 6 FLUTE, как показано на фиг.3а, можно рассматривать как базовую информацию, необходимую для реконструкции данных в конкретном приемнике 3-1. В другом воплощении настоящего изобретения к этой минимальной информации можно добавить любое количество полей. Однако в других вариантах выполнения настоящего изобретения может использоваться сжатый пакет FLUTE, который может до некоторой степени отличаться от сжатого пакета 8, изображенного на фиг.3а. Например, могут присутствовать не все поля, если они могут быть получены из контекста. Например, поле 63 TOI может быть опущено, если предполагается, что в сеансе FLUTE доставлен только один объект (файл). В наиболее общих вариантах выполнения настоящего изобретения может быть вероятным, что конкретный приемник не потребует данные восстановления со ссылкой на более чем один сеанс передачи. В этом случае TSI неявно следует из контекста и остается тем же самым для всех пакетов, посланных в ответе восстановления данных в режиме точка-точка. Таким образом, в сжатых заголовках FLUTE поле TSI может быть опущено. Как показано на фиг.3, заголовок пакета 6 FLUTE может также включать дополнительные секции, например, секции расширения заголовка LCT, такие как EXT_FTI и EXT_FDT.

Кроме того, для полной идентификации этого сеанса связи IP-адресом передатчика и TSI, сервер 4 восстановления данных может также послать IP-адрес передатчика 1 для сеанса передачи в режиме точка-много точек, если эта информация не может быть получена из контекста.

На фиг.3b иллюстрируется встраивание множества сжатых пакетов 8-1…8-М FLUTE, изображенных на фиг.3а, в пакет 9 HTTP, который затем передается с использованием протоколов HTTP/TCP между равноправными объектами протокола в сервере 4 восстановления данных и конкретном приемнике 3-1. То есть пакет 9 HTTP дополнительно включает заголовок 9 HTTP с практическим примером типа содержания "х-flutePtP/compressedFlutePkt", который обозначает, что тело сообщения пакета 9 HTTP содержит сжатые пакеты 8-1…8-М FLUTE.

В этом случае ответ HTTP в режиме точка-точка, переданный из сервера 4 восстановления данных в конкретный приемник 3-1, имеет следующий вид:

НТТР/1.1 200 OK

Вид-содержания: x-flutePtP/compressedFlutePkt

Длина-содержания: TOTAL_LENGTH

Кодирование-при-передаче-содержания: бинарное

Сжатый пакет FLUTE - 1

Сжатый Пакет FLUTE - 2

…

Сжатый Пакет FLUTE - М.

Здесь TOTAL_LENGTH представляет собой размер всех сжатых пакетов FLUTE.

ВТОРОЙ ВАРИАНТ ВЫПОЛНЕНИЯ ИЗОБРЕТЕНИЯ

Информация, содержащаяся в пакете 9 HTTP согласно первому варианту выполнения настоящего изобретения (см. фиг.3a и 3b), может быть сжата или переупорядочена по-разному.

Например, согласно второму варианту выполнения настоящего изобретения для разделения и посылки сжатых пакетов FLUTE может использоваться составная структура MIME. В составной структуре MIME составные части разделены "граничными строками". Таким образом, поле 65 размера кодового символа сжатого заголовка 6 FLUTE на фиг.3а может быть опущено, в результате чего получается сжатый заголовок 6' FLUTE, содержащийся в сжатом пакете 8' FLUTE, изображенном на фиг.4а.

На фиг.4b изображен соответствующий пакет 9' HTTP. Здесь поле заголовка HTTP "Content-Type" (тип содержания) установлен в значение "multipart/mixed (составной/смешанный). Первичный подтип для multipart, "mixed", предназначен для использования в случае, когда части тела HTML независимы и должны быть соединены в конкретном порядке. Могут также использоваться другие релевантные типы содержания, например "multipart/parallel" (составной/параллельный) или "multipart/related" (составной/связанный). В частности, в элементе "multipart/parallel" порядок частей тела не существенен. Тип содержания "multipart/related" обеспечивает обычный механизм представления объектов, которые являются совокупностями связанных частей тела MIME. Любые составные подтипы, которые при реализации не распознаются, нужно рассматривать как относящиеся к подтипу "multipart/mixed" (составной/смешанный).

Согласно второму варианту выполнения настоящего изобретения, обычная граничная строка (BOUNDARY_P2P_REPAIR_RESPONSE) 92 задана так, чтобы отмечать начало каждой части многоуровневой структуры MIME в пакете 9' HTTP на фиг.4b. Эта граничная строка 92 может достигать 70 символов. Она предпочтительно выбрана так, что не появляется (или появляется с исчезающе малой вероятностью) в любых частях тела. За граничной строкой после заключительной части следует "--".

Кодирование-содержания-для-передачи каждой части составного MIME установлено на "бинарное", поскольку сжатые пакеты 8' FLUTE no своей сути являются бинарными объектами, которые можно считывать по одному биту. "Бинарная" схема кодирования не включает никаких избыточных данных. Могут также использоваться другие приемлемые схемы кодирования, например кодирование "base64". Кодирование "base64" может привести к наличию 33% избыточных данных.

Тогда пакет 9' HTTP на фиг.4b, включающий заголовок 91 HTTP, граничные строки 92 и сжатые пакеты 8'-1…8'-М, может быть представлен посредством следующего псевдокода:

НТТР/1.1 200 OK

Тип-содержания: multipart/mixed;

граница = BOUNDARY_P2P_REPAIR_RESPONSE

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип-содержания: x-flutePtP/compressedFlutePkt

Кодирование-при-передаче-содержания: бинарное

Сжатый пакет FLUTE - 1

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип-содержания: x-flutePtP/compressedFlutePkt

Кодирование-при-передаче-содержания: бинарное

Сжатый пакет FLUTE - 2

…

…

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип-содержания: x-flutePtP/compressedFlutePkt

Кодирование-при-передаче-содержания: бинарное

Сжатый пакет FLUTE - М

--BOUNDARY_P2P_REPAIR_RESPONSE--

ТРЕТИЙ ВАРИАНТ ВЫПОЛНЕНИЯ ИЗОБРЕТЕНИЯ

Согласно третьему варианту выполнения настоящего изобретения информация ответа по протоколу HTTP в режиме точка-точка в виде составного MIME может также быть передана более эффективным способом по сравнению со вторым вариантом выполнения настоящего изобретения. Ниже этот третий вариант выполнения настоящего изобретения описан со ссылками на фиг.5а-5с.

Сервер 4 восстановления данных может обрабатывать все пакеты FLUTE, которые имеют одинаковые TSI и TOI, и объединять их кодовые символы 7 FLUTE в М блоков 7''-m пакетов FLUTE, которые имеют соответствующие общие заголовки 6''-m FLUTE, где целое число m лежит в диапазоне от 1 до М. Таким образом удается избежать повторения идентичных частей сжатых заголовков FLUTE.

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

"x-flutePtP/encSymbolHdr" означает, что тело сообщения содержит общий заголовок 6''-m, который является общим для всех кодовых символов в следующей части (в блоке 7''-m кодовых символов FLUTE) многоуровневой структуры MIME.

"x-flutePtP/encSymbolVideo" означает, что тело сообщения содержит кодовые символы FLUTE 7-1-m…7-Mm-m (с соответствующими идентификаторами полезной нагрузки FEC 64-1-m…64-Mm-m, где Mm обозначает количество кодовых символов FLUTE в блоке 7''-m), соответствующие видеообъекту.

"x-flutePtP/encSymbolAudio" означает, что тело сообщения содержит кодовые символы FLUTE 7-1-m…7-Mm-m (с соответствующими идентификаторами полезной нагрузки FEC 64-1-m…64-Mm-m, где Mm обозначает количество кодовых символов FLUTE в блоке 7''-m), соответствующие аудиообъекту.

"x-flutePtP/encSymbolOther" означает, что тело сообщения содержит кодовые символы FLUTE 7-1-m…7-Mm-m (с соответствующими идентификаторами полезной нагрузки FEC 64-1-m…64-Mm-m, где Mm обозначает количество кодовых символов FLUTE в блоке 7''-m), соответствующие "другим" объектам.

Альтернативно, в некоторых вариантах выполнения настоящего изобретения может не делаться дифференциации между различными видами мультимедиа и, например, может использоваться обобщенное содержание вида "x-flutePtP/encSymbolData".

Полученная в результате структура ответа 9'' по протоколу HTTP в режиме точка-точка иллюстрируется на фиг.5а, общий заголовок 6''-m FLUTE показан на фиг.5b, а формат блока 7''-m кодовых символов FLUTE показан на фиг.5с. Как видно на фиг.5с, идентификатор 64-1-m…64-Mm-m полезной нагрузки FEC для каждого кодового символа FLUTE 7-1-m…7-Mm-m (где m - целое число в пределах от 1 до M) предпочтительно перемещен в блок 7''-m кодовых символов FLUTE, поскольку он определяется кодовым символом FLUTE. Кроме того, поскольку кодовые символы FLUTE взаимно не разделены границами МIМЕ, размер 65-m кодовых символов FLUTE 7-1m…7-Mm-m должен быть определен в общем заголовке 6''-m FLUTE, см. фиг.5b.

HTTP-ответ 9'' на фиг.5а может быть представлен в виде псевдокода (комментарии начинаются с двойной косой черты):

НТТР/1.1 200 OK

Версия MIME: 1.0

Тип-содержания: multipart/mixed;

граница = BOUNDARY_P2P_REPAIR_RESPONSE

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип содержания: х-flutePtP/encSymbolHdr

Кодирование-при-передаче-содержания: бинарное

// Включение TSI, TOI и размера кодовых символов, общих

// для всех кодовых символов FLUTE последующей части.

// (В этом примере последующая часть содержит все

// кодовые символы, которые принадлежат видеообъекту).

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип содержания: x-flutePtP/encSymbolVideo

Кодирование-при-передаче-содержания: бинарное

// Включение всех кодовых символов FLUTE (с их

// идентификаторами полезной нагрузки с прямой коррекцией ошибок

// (FEC Payload ID), которые принадлежат видеообъекту.

FEC Payload ID - 1 кодовый символ - 1

FEC Payload ID - 2 кодовый символ - 2

…

…

FEC Payload ID - M1 кодовый символ - М1

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип содержания: x-flutePtP/encSymbolHdr

Кодирование-при-передаче-содержания: бинарное

// Включение TSI, TOI и размера кодовых символов,

// общих для всех кодовых символов FLUTE последующей части.

// (В этом примере последующая часть содержит все

// кодовые символы, которые принадлежат аудиообъекту).

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип содержания: x-flutePtP/encSymbolAudio

Кодирование-при-передаче-содержания: бинарное

// Включение всех кодовых символов FLUTE (с их

// FEC Payload ID, которые принадлежат аудиообъекту.

FEC Payload ID - 1 кодовый символ - 1

FEC Payload ID - 2 кодовый символ - 2

…

…

FEC Payload ID - M2 кодовый символ - М2

…

…

…

--BOUNDARY - P2P_REPAIR_RESPONSE

Тип содержания: x-flutePtP/encSymbolHdr

Кодирование-при-передаче-содержания: бинарное

// Включение TSI, TOI и размера кодовых символов,

// общих для всех кодовых символов FLUTE последующей части.

// (В этом примере последующая часть содержит все

// кодовые символы, которые принадлежат аудиообъекту).

--BOUNDARY_P2P_REPAIR__RESPONSE

Тип содержания: x-flutePtP/encSymbolOther

Кодирование-при-передаче-содержания: бинарное

// Включение всех кодовых символов FLUTE (с их

// FEC Payload ID, которые принадлежат аудио-объекту.

FEC Payload ID - 1 кодовый символ - 1

FEC Payload ID - 2 кодовый символ - 2

…

…

FEC Payload ID - MM кодовый символ - MM

--BOUNDARY_P2P_REPAIR_RESPONSE-

До сих пор в третьем варианте выполнения настоящего изобретения предполагалось, что в заголовке FLUTE не содержатся расширения заголовка LCT, такие как EXT_FTI и EXT_FDT. Таким образом, как показано на фиг.5с, блок 7''-m кодовых символов FLUTE не содержит никаких расширений заголовка LCT.

Однако, если расширения заголовка LCT используются по меньшей мере частью кодовых символов FLUTE, третий вариант выполнения настоящего изобретения, иллюстрированный на фиг.5а-5с, должен быть изменен только в отношении структуры блока 7''-m кодовых символов FLUTE. Этот пример изображен на фиг.5d и служит альтернативой блоку, изображенному на фиг.5с, вследствие чего используются те же позиции.

Согласно фиг.5с блок 7''-m кодовых символов FLUTE также содержит кодовые символы 7-1-m…7-Mm-m, где целое число m лежит в диапазоне от 1 до M, Mm обозначает количество кодовых символов на блок m, а М - полное количество блоков. Как и на фиг.5с, идентификаторы полезной нагрузки с прямой коррекцией ошибок 64-1-m…64-Mm-m для каждого кодового символа находятся в указанном блоке перед соответствующим кодовым символом. Однако для учета использования расширений заголовка LCT по меньшей мере некоторыми из кодовых символов поля длины заголовка LCT (HDR-LEN) 6110-1-m…6110-Mm-m для каждого соответствующего кодового символа 7-1-m…7-Mm-m введены в блок 7''-m. Эти поля длины заголовка LCT указывают, используются ли расширения заголовка LCT, и какое количество из них связано с каждым кодовым символом. При этом эти расширения заголовка LCT 68-1-m…68-Mm-m находятся после полей длины заголовка LCT, соответственно.

В примере на фиг.5d два заголовка EXT_FTI присутствуют в первом кодовом символе, никакого заголовка EXT_FTI нет во втором кодовом символе, и один заголовок EXT_FTI присутствует в последнем кодовом символе в блоке. В этом случае поле 6110 HDR-LEN, входящее в общий заголовок кодового символа (6''-m на фиг.5b), может не иметь значения.

Очевидно, что вышеописанный способ поддержки использования расширений заголовка LCT работает также и для элементов EXT-FDT заголовка LCT, которые используются, когда кодовые символы принадлежат к элементам таблицы распределения файлов (FDT, File Distribution Table).

ЧЕТВЕРТЫЙ ВАРИАНТ ВЫПОЛНЕНИЯ ИЗОБРЕТЕНИЯ

Еще один вариант выполнения настоящего изобретения получается путем перегруппировки информации, содержащейся в ответе HTTP в режиме точка-точка, как описано ниже со ссылкой на фиг.6а-6c.

Согласно этому варианту выполнения настоящего изобретения кодовые символы FLUTE, ассоциированные с одинаковыми TSI и TOI, вновь сохраняются в блоках 7'''-m кодовых символов FLUTE (где m меняется в пределах от 1 к М), а общие заголовки FLUTE используются для кодовых символов FLUTE каждого блока; однако, в отличие от третьего варианта выполнения настоящего изобретения, поля всех общих заголовков FLUTE объединены в одном индексном объекте 6''', а идентификаторы полезной нагрузки с прямой коррекцией ошибок для всех кодовых символов FLUTE, содержащихся в одном блоке 7'''-m кодовых символов FLUTE, больше не хранятся в указанных блоках кодовых символов FLUTE, как в третьем варианте выполнения настоящего изобретения, а хранятся в зависящих от блоков массивах идентификаторов полезной нагрузки с прямой коррекцией ошибок 64-1-m…64-Mm-m, которые также включены в указанный индексный объект 6'''. Это обеспечивает произвольный доступ к каждому желаемому кодовому символу FLUTE в ответе 9''' HTTP в режиме точка-точка.

Этот HTTP-ответ 9''' (пакет) иллюстрируется на фиг.6а. Вновь для разделения индексного объекта 6''' и блоков 7'''-m кодовых символов FLUTE различных типов может использоваться составная структура MIME с границами 92 MIME. Здесь определен новый тип содержания "х-flutePtP/lndexObject", который означает, что тело сообщения содержит индексный объект 6'''.

На фиг.6b показан формат индексного объекта 6''', который содержит информацию (TSI, TOI, длину кодового символа, идентификатор полезной нагрузки с прямой коррекцией ошибок) для всех кодовых символов, посланных в HTTP-ответе 9'''. Индексный объект 6''' можно считать состоящим из М подзаголовков (модифицированных общих заголовков FLUTE третьего варианта выполнения настоящего изобретения) с индексами m=1…М, где каждый из указанных подзаголовков относится к определенному TSI, TOI, размеру кодового символа FLUTE и, естественно, количеству Mm кодовых символов для каждого блока 7''' кодовых символов FLUTE; эти значения хранятся в полях 62-m, 63-m, 65-m и 67-m соответственно Кроме того, каждый из указанных подзаголовков дополнительно включает часть заголовка 61-m LCT и указанный зависящий от блока массив идентификаторов 64-1-m…64-Mm-m полезной нагрузки с прямой коррекцией ошибок.

На основе этой информации конкретный приемник 3-1 может сопоставить каждый идентификатор полезной нагрузки с прямой коррекцией ошибок с уникальным диапазоном байтов в полученном потоке байтов. Таким образом, конкретный приемник 3-1 может иметь произвольный доступ к любому желаемому кодовому символу. Формат блоков 7'''-m кодовых символов FLUTE (где m лежит в диапазоне от 1 до М, а М - количество блоков кодовых символов FLUTE) показан на фиг.6с. Очевидно, что, в отличие от третьего варианта выполнения изобретения, значения идентификаторов полезной нагрузки с прямой коррекцией ошибок не содержатся в блоках кодовых символов FLUTE, поскольку они теперь содержатся в индексном объекте 6'''.

Ответ 9''' HTTP на фиг.6а может быть выражен в виде псевдокода (комментарии начинаются с двойной косой черты):

НТТР/1.1 200 OK

Версия MIME: 1.0

Тип-содержания: multipart/mixed;

граница = BOUNDARY_P2P_REPAIR_RESPONSE

- -BOUNDARY_P2P_REPAIR_RESPONSE

Тип-содержания: х-flutePtP/lndexObject:

Кодирование-при-передаче-содержания: бинарное

// Включает индексный объект, который содержит всю

// информацию, необходимую для получения доступа к любому

// кодовому символу FLUTE, уникально идентифицированному

// посредством TSI, TOI и FEC Payload ID.

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип-содержания: x-flutePtP/encSymbolVideo

Кодирование-при-передаче-содержания: бинарное

// Включение всех кодовых символов FLUTE,

// которые принадлежат видеообъекту.

Кодовый символ - 1

Кодовый символ - 2

Кодовый символ - М1

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип-содержания: x-flutePtP/encSymbolAudio

Кодирование-при-передаче-содержания: бинарное

// Включение всех кодовых символов FLUTE,

// которые принадлежат аудиообъекту.

Кодовый символ - 1

Кодовый символ - 2

…

…

Кодовый символ - М2

…

…

…

--BOUNDARY_P2P_REPAIR_RESPONSE

Тип содержания: x-flutePtP/encSymbolOther

Кодирование-при-передаче-содержания: бинарное

// Включение всех кодовых символов FLUTE,

// которые принадлежат "другому" объекту.

Кодовый символ - 1

Кодовый символ - 2

…

…

Кодовый символ - ММ

--BOUNDARY_P2P_REPAIR_RESPONSE-

При описании четвертого варианта выполнения настоящего изобретения предполагалось, что с кодовыми символами не связаны никакие расширения заголовка LCT, такие как EXT_FTI и EXT_FDT. Однако следует отметить, что в четвертом варианте выполнения настоящего изобретения можно использовать подход, аналогичный используемому в третьем варианте выполнения изобретения (см. фиг.5 d). Для этого в каждый подзаголовок просто включают ряд длин заголовков LCT, который для каждого кодового символа указывает, используются ли расширения заголовка LCT и сколько их используется. При этом записи в таком ряду обозначают количество расширений заголовка LCT, которые хранятся в структуре данных, специфической для кодовых символов, в каждом подзаголовке.

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

На первом шаге 701 передатчик 1 генерирует кодовые символы FLUTE, например, в виде кодированных с прямой коррекцией ошибок частей транспортного объекта, которые должны быть переданы в множество приемников 3-1…3-3 в сеансе передачи в режиме точка-много точек. Затем на шаге 702 эти кодовые символы FLUTE снабжают заголовками FLUTE (заголовками первого типа), которые подчиняются протоколу FLUTE, в результате чего создают пакеты FLUTE, которые затем передают в указанное множество приемников (шаг 703). Это может быть достигнуто, например, при использовании служб UDP и протокола IP нижнего уровня. Затем переданные пакеты FLUTE принимают в приемниках 3-1…3-3, но по меньшей мере одному из указанных приемников, конкретному приемнику 3-1, требуется дополнительный прием пакетов восстановительных данных вследствие потерь данных, приема пакетов с ошибками или вследствие других причин. Затем конкретный приемник 3-1 выдает сигнал запроса на восстановление данных в сервер восстановления данных, который в этом примере идентичен передатчику.

В указанном сервере 4 восстановления данных прием запроса на восстановление данных производят на шаге 704, и информация восстановления, содержащаяся в нем, например четверка параметров TSI, TOI, SBN и ESI недостающих кодовых символов FLUTE, используется для определения того, какие кодовые символы FLUTE нужно генерировать в качестве символов восстановительных данных. Эта операция производится сервером 4 восстановления данных на шаге 705. Затем на шаге 706 генерированные кодовые символы FLUTE снабжают сжатым заголовком FLUTE (заголовком второго типа), подчиняющимся протоколу FLUTE, например, сжатым заголовком 6 FLUTE, соответствующим первому варианту выполнения настоящего изобретения и изображенным на фиг.3а. В результате кодовые символы FLUTE и сжатый заголовок FLUTE формируют сжатый пакет 8 FLUTE, показанный на фиг.3а. Затем этот сжатый пакет 8 FLUTE передают сервером восстановления в конкретный приемник в рамках сеанса восстановления в режиме точка-точка (см. шаг 707), например, путем встраивания множества сжатых пакетов 8-1…8-М FLUTE в один пакет 9 HTTP (см. фиг.3b), который служит ответом на запрос восстановления данных, и путем использования служб HTTP/TCP для передачи этих пакетов HTTP между объектами сервера 4 восстановления данных и конкретным приемником 3-1.

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

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

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

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

2. Способ по п.1, в котором указанный заголовок первого типа содержит по меньшей мере один параметр, который отсутствует в указанном заголовке второго типа и связан с передачей в режиме точка - много точек.

3. Способ по п.1, в котором указанный протокол доставки файлов является протоколом Доставки Файлов Однонаправленным Транспортом (FLUTE).

4. Способ по п.1, в котором в указанном сеансе восстановления данных в режиме точка-точка указанный протокол доставки файлов использует службы Протокола Управления Передачей.

5. Способ по п.1, в котором в указанном сеансе восстановления данных в режиме точка-точка указанный протокол доставки файлов использует службы Протокола Пересылки Гипертекста.

6. Способ по п.1, в котором указанный протокол доставки файлов является протоколом Доставки Файлов Однонаправленным Транспортом (FLUTE), a указанные символы данных и символы восстановительных данных представляют собой кодовые символы FLUTE.

7. Способ по п.1, в котором указанный сеанс передачи в режиме точка - много точек является сеансом мультимедийного вещания/многоадресной передачи 3GPP.

8. Способ по п.1, в котором комбинация одного кодового символа FLUTE и одного связанного с ним заголовка второго типа формирует сжатый пакет FLUTE, при этом протокол пересылки гипертекста (HTTP) обеспечивает передачу пакетов HTTP между указанным сервером восстановления данных и указанным приемником, и по меньшей мере один из указанных пакетов HTTP включает заголовок пакета HTTP и один или более указанных сжатых пакетов FLUTE.

9. Способ по п.8, в котором указанный заголовок второго типа в сжатых пакетах FLUTE включает по меньшей мере часть заголовка транспорта с многоуровневым кодированием (LCT), идентификатор указанного кодового символа FLUTE в указанном сжатом пакете FLUTE и размер указанного кодового символа FLUTE.

10. Способ по п.8, в котором указанный по меньшей мере один пакет HTTP имеет составную структуру многоцелевых расширений почтовой службы Интернета (MIME), а указанные сжатые пакеты FLUTE отделены от указанного заголовка пакета HTTP и друг от друга границами MIME.

11. Способ по п.10, в котором указанный заголовок второго типа в сжатых пакетах FLUTE включает часть заголовка транспорта с многоуровневым кодированием и идентификатор указанного кодового символа FLUTE в указанном сжатом пакете FLUTE.

12. Способ по п.1, в котором протокол пересылки гипертекста (HTTP) обеспечивает передачу пакетов HTTP между указанным сервером восстановления данных и указанным приемником, при этом по меньшей мере один из указанных пакетов HTTP включает заголовок пакета HTTP, один или более блоков, которые включают по меньшей мере два кодовых символа FLUTE и соответствующие связанные с ними идентификаторы, и один соответствующий заголовок второго типа для каждого из указанных блоков, причем каждый соответствующий заголовок второго типа действителен для всех кодовых символов FLUTE соответствующего блока.

13. Способ по п.12, в котором указанный по меньшей мере один пакет HTTP имеет структуру MIME, а указанный заголовок пакета HTTP, указанные блоки и указанные протокольные заголовки второго типа взаимно разделены границами MIME.

14. Способ по п.13, в котором указанные соответствующие протокольные заголовки второго типа включают часть заголовка транспорта с многоуровневым кодированием и размер указанных кодовых символов FLUTE в указанных соответствующих блоках.

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

16. Способ по п.1, в котором протокол пересылки гипертекста (HTTP) обеспечивает передачу пакетов HTTP между указанным сервером восстановления данных и указанным приемником, при этом по меньшей мере один из указанных пакетов HTTP включает заголовок пакета HTTP, один заголовок второго типа и один или более блоков, которые включают по меньшей мере два кодовых символа FLUTE.

17. Способ по п.16, в котором указанный по меньшей мере один пакет HTTP имеет структуру MIME, а указанный заголовок пакета HTTP, указанный один заголовок второго типа и указанный один или более блок взаимно разделены границами MIME.

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

19. Способ по п.18, в котором по меньшей мере один из указанных подзаголовков включает одну длину заголовка транспорта с многоуровневым кодированием для каждого кодового символа FLUTE в указанном соответствующем блоке и по меньшей мере одно расширение заголовка транспорта с многоуровневым кодированием по меньшей мере для одного из указанных кодовых символов FLUTE в указанном соответствующем блоке.

20. Способ по любому из пп.9, 11, 14 и 18, в котором указанный заголовок второго типа дополнительно включает идентификатор указанного сеанса передачи в режиме точка - много точек.

21. Способ по любому из пп.9, 11, 14 и 18, в котором указанный заголовок второго типа дополнительно включает идентификатор транспортного объекта, к которому относятся указанные кодовые символы FLUTE.

22. Способ по любому из пп.9, 11, 14 и 18, в котором указанный заголовок второго типа дополнительно включает расширения заголовка транспорта с многоуровневым кодированием.

23. Способ по любому из пп.9, 11, 14 и 18, в котором указанная часть заголовка транспорта с многоуровневым кодированием включает номер версии транспорта с многоуровневым кодированием, флаг управления перегрузкой, зарезервированное место, флаг идентификатора сеанса передачи, флаг идентификатора транспортного объекта (TOI), флаг полуслова, флаг текущего времени отправителя, флаг ожидаемого оставшегося времени, флаг завершения сеанса, флаг закрытия объекта, длину заголовка транспорта с многоуровневым кодированием и точку кода.

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

25. Устройство по п.24, в котором указанный протокол доставки файлов является протоколом Доставки Файлов Однонаправленным Транспортом (FLUTE).

26. Устройство по п.24, в котором указанный сеанс передачи в режиме точка - много точек является сеансом мультимедийного вещания/многоадресной передачи 3GPP.

27. Устройство по п.24, в котором указанный заголовок первого типа содержит по меньшей мере один параметр, который отсутствует в указанном заголовке второго типа, причем этот параметр связан с передачей в режиме точка - много точек.

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

29. Устройство по п.28, в котором указанный заголовок первого типа содержит по меньшей мере один параметр, который отсутствует в указанном заголовке второго типа, причем этот параметр связан с передачей в режиме точка - много точек.

30. Устройство по п.28, в котором указанный протокол доставки файлов является протоколом Доставки Файлов Однонаправленным Транспортом (FLUTE).

31. Устройство по п.28, в котором указанный сеанс передачи в режиме точка - много точек является сеансом мультимедийного вещания/многоадресной передачи 3GPP.

32. Устройство для приема данных, включающее средство для приема, в приемнике, одного или более символа данных в сеансе передачи в режиме точка - много точек, причем указанные символы данных снабжены протокольными заголовками первого типа, подчиняющимися точка - много точек указанный протокол доставки файлов использует службы Протокола Пользовательских Дейтаграмм; и
приема одного или более символов восстановительных данных от сервера восстановления данных в сеансе восстановления данных в режиме точка-точка, при этом указанные символы восстановительных данных снабжены одним или более протокольным заголовком второго типа, по меньшей мере частично подчиняющимся тому же самому указанному протоколу доставки файлов, причем указанные протокольные заголовки второго типа представляют собой модификацию указанных протокольных заголовков первого типа, полученную путем удаления по меньшей мере одного параметра указанных протокольных заголовков первого типа.

33. Устройство по п.32, в котором указанный заголовок первого типа содержит по меньшей мере один параметр, который отсутствует в указанном заголовке второго типа, причем этот параметр связан с передачей в режиме точка - много точек.

34. Устройство по п.32, в котором в указанном сеансе восстановления данных в режиме точка-точка указанный протокол доставки файлов использует службы Протокола Управления Передачей.

35. Устройство по п.32, в котором в указанном сеансе восстановления данных в режиме точка-точка указанный протокол доставки файлов использует службы Протокола Пересылки Гипертекста.

36. Устройство по п.32, в котором указанный протокол доставки файлов является протоколом Доставки Файлов Однонаправленным Транспортом (FLUTE), а указанные символы данных и символы восстановительных данных представляют собой кодовые символы FLUTE.

37. Устройство по п.32, в котором комбинация одного кодового символа FLUTE и одного связанного с ним заголовка второго типа формирует сжатый пакет FLUTE, при этом протокол пересылки гипертекста (HTTP) обеспечивает передачу пакетов HTTP между указанным сервером восстановления данных и указанным приемником, и по меньшей мере один из указанных пакетов HTTP включает заголовок пакета HTTP и один или более указанных сжатых пакетов FLUTE.

38. Устройство по п.37, в котором указанный заголовок второго типа в сжатых пакетах FLUTE включает по меньшей мере часть заголовка транспорта с многоуровневым кодированием (LCT), идентификатор указанного кодового символа FLUTE в указанном сжатом пакете FLUTE и размер указанного кодового символа FLUTE.

39. Устройство по п.37, в котором указанный по меньшей мере один пакет HTTP имеет составную структуру многоцелевых расширений почтовой службы Интернета (MIME), а указанные сжатые пакеты FLUTE отделены от указанного заголовка пакета HTTP и друг от друга границами MIME.

40. Устройство по п.39, в котором указанный заголовок второго типа в сжатых пакетах FLUTE включает часть заголовка транспорта с многоуровневым кодированием и идентификатор указанного кодового символа FLUTE в указанном сжатом пакете FLUTE.

41. Устройство по п.39, в котором протокол пересылки гипертекста (HTTP) обеспечивает передачу пакетов HTTP между указанным сервером восстановления данных и указанным приемником, при этом по меньшей мере один из указанных пакетов HTTP включает заголовок пакета HTTP, один или более блоков, которые включают по меньшей мере два кодовых символа FLUTE и соответствующие связанные с ними идентификаторы, и один соответствующий заголовок второго типа для каждого из указанных блоков, причем каждый соответствующий заголовок второго типа действителен для всех кодовых символов FLUTE соответствующего блока.

42. Устройство по п.41, в котором указанный по меньшей мере один пакет HTTP имеет структуру MIME, а указанный заголовок пакета HTTP, указанные блоки и указанные протокольные заголовки второго типа взаимно разделены границами MIME.

43. Устройство по п.42, в котором указанные соответствующие протокольные заголовки второго типа включают часть заголовка транспорта с многоуровневым кодированием и размер указанных кодовых символов FLUTE в указанных соответствующих блоках.

44. Устройство по п.41, в котором по меньшей мере один из указанных блоков включает кодовый символ FLUTE, соответствующий связанный с ним идентификатор, соответствующую длину заголовка транспорта с многоуровневым кодированием и по меньшей мере одно расширение заголовка транспорта с многоуровневым кодированием.

45. Устройство по п.32, в котором протокол пересылки гипертекста (HTTP) обеспечивает передачу пакетов HTTP между указанным сервером восстановления данных и указанным приемником, при этом по меньшей мере один из указанных пакетов HTTP включает заголовок пакета HTTP, один заголовок второго типа и один или более блоков, которые включают по меньшей мере два кодовых символа FLUTE.

46. Устройство по п.45, в котором указанный по меньшей мере один пакет HTTP имеет структуру MIME, а указанный заголовок пакета HTTP, указанный один заголовок второго типа и указанный один или более блок взаимно разделены границами MIME.

47. Устройство по п.46, в котором указанный заголовок второго типа включает один соответствующий подзаголовок для каждого соответствующего блока в указанном пакете HTTP, а каждый из указанных соответствующих подзаголовков включает часть заголовка транспорта с многоуровневым кодированием, размер указанных кодовых символов FLUTE в указанном соответствующем блоке, количество кодовых символов FLUTE в указанном соответствующем блоке и один идентификатор для каждого кодового символа FLUTE в указанном соответствующем блоке.

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

49. Устройство по любому из пп.38, 40, 43 и 47, в котором указанный заголовок второго типа дополнительно включает идентификатор указанного сеанса передачи в режиме точка - много точек.

50. Устройство по любому из пп.38, 40, 43 и 47, в котором указанный заголовок второго типа дополнительно включает идентификатор транспортного объекта, к которому относятся указанные кодовые символы FLUTE.

51. Устройство по любому из пп.38, 40, 43 и 47, в котором указанный заголовок второго типа дополнительно включает расширения заголовка транспорта с многоуровневым кодированием.

52. Устройство по любому из пп.38, 40, 43 и 47, в котором указанная часть заголовка транспорта с многоуровневым кодированием включает номер версии транспорта с многоуровневым кодированием, флаг управления перегрузкой, зарезервированное место, флаг идентификатора сеанса передачи, флаг идентификатора транспортного объекта (ТО), флаг полуслова, флаг текущего времени отправителя, флаг ожидаемого оставшегося времени, флаг завершения сеанса, флаг закрытия объекта, длину заголовка транспорта с многоуровневым кодированием и точку кода.

53. Устройство по п.32, в котором указанный протокол доставки файлов является протоколом Доставки Файлов Однонаправленным Транспортом (FLUTE).

54. Устройство по п.32, в котором указанный сеанс передачи в режиме точка - много точек является сеансом мультимедийного вещания/многоадресной передачи 3GPP.

55. Носитель, хранящий программный код, для обеспечения выполнения процессором способа по любому из пп.1-23.

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

57. Способ по п.56, в котором указанный протокол доставки файлов является протоколом Доставки Файлов Однонаправленным Транспортом (FLUTE).

58. Способ по п.56, в котором указанный сеанс передачи в режиме точка - много точек является сеансом мультимедийного вещания/многоадресной передачи 3GPP.

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

60. Способ по п.59, в котором указанный протокол доставки файлов является протоколом Доставки Файлов Однонаправленным Транспортом (FLUTE).

61. Способ по п.59, в котором указанный сеанс передачи в режиме точка - много точек является сеансом мультимедийного вещания/многоадресной передачи 3GPP.

62. Носитель, хранящий программный код для обеспечения выполнения процессором способа по любому из пп.59-61.