МЕХАНИЗМ ЗАПРОСА НА ВОССТАНОВЛЕНИЕ ДАННЫХ В РЕЖИМЕ "ТОЧКА-ТОЧКА" ДЛЯ СИСТЕМ ПЕРЕДАЧИ "ТОЧКА-МНОГО ТОЧЕК"
MECHANISM OF REQUEST FOR RESTORATION OF DATA IN "POINT-POINT" MODE FOR TRANSFER SYSTEMS OF "POINT-MANY POINTS" TYPE

ОБЛАСТЬ ТЕХНИКИ
Настоящее изобретение относится к способу, системе, передатчику, сетевому элементу, приемнику и программному обеспечению для системы, способной осуществлять передачу в режиме "точка - много точек".
УРОВЕНЬ ТЕХНИКИ
Для служб типа "точка - много точек" (PtM, Point-to-Multipoint) (называемых также службами "один-многим") в таких системах, как групповое вещание по протоколу Интернета (IP), вещательная передача данных по IP (IPDC, IP Data Casting) и мультимедийное вещание/групповое вещание (MBMS, Multimedia Broadcast/Multicast Services), важной службой является доставка файлов, например загрузка мультимедийных файлов.
Однако многие характеристики доставки файлов в рамках протоколов в режиме точка-точка (РtР), например протокола передачи файлов (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), то есть путем посылки определенного количества избыточных данных, которые могут помочь приемнику исправить ошибочные данные; во второй категории надежность достигается с помощью обратной связи.
Асинхронное Многоуровневое Кодирование (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).
По сути, протокол ALC представляет собой схему на основе прямой коррекции ошибок, которая позволяет приемникам восстанавливать поврежденные пакеты или пакеты, которые не приняты. В протоколе ALC используется кодирование с прямой коррекцией ошибок для множества каналов, что позволяет отправителю посылать данные с разными скоростями (по разным каналам), возможно, в разные приемники. Кроме того, в протоколе ALC используется механизм управления перегрузкой, обеспечивающий поддержку различных скоростей передачи в различных каналах.
Протокол ALC является масштабируемым в широких пределах относительно количества пользователей, поскольку не требует использования восходящих сигналов. Поэтому любое увеличение количества дополнительных приемников непосредственно не приводит к повышению требований к системе. Однако протокол ALC не является надежным на 100%, поскольку прием не гарантируется, а значит, этот протокол, в общем, не считается устойчивым.
В свою очередь, NORM определяет использование сообщений с отрицательными подтверждениями (NACK), предназначенных для сигнализации о том, какие пакеты данных, ожидаемые приемником, не были получены приемником вообще или были приняты неправильно. Другими словами, приемники используют сообщения NACK для информирования передатчика о потере или повреждении переданных пакетов данных. Соответственно, приемник, который пропустил некоторые из переданных пакетов данных, может послать в передатчик (или сервер восстановления данных) сообщение NACK с запросом передатчику (или серверу восстановления данных) на ретрансляцию пропущенного блока или блоков данных. В качестве опции протокол NORM позволяет также использовать кодирование с прямой коррекцией ошибок на уровне пакета данных с целью обеспечения превентивных надежных передач.
Сообщения 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 при соединениях с использованием сеансов FLUTE (или других сеансов с использованием протокола транспортного уровня, специально предназначенного для поддержки передачи в режиме "точка - много точек"), идентификация пакетов данных, отсутствующих в приемниках, представляет собой важную задачу. Использование протоколов, предназначенных для передачи в режиме точка-точка, например TCP, и способов подтверждения, применяемых в них, в этом случае не всегда возможно.
В сеансе FLUTE транспортные объекты, например мультимедийные файлы или их части, идентифицируются идентификатором транспортного объекта (TOI, Transport Object Identifier) и передаются из передатчика в множество приемников в рамках сеанса передачи, который идентифицирован идентификатором сеанса передачи (TSI, Transport Session Identifier). Передачу указанных объектов фактически выполняют путем передачи пакетов данных FLUTE, причем пакеты данных FLUTE содержат в качестве полезной нагрузки необработанные или кодированные части указанного транспортного объекта, так называемые кодовые символы. Указанные пакеты данных FLUTE дополнительно содержат TSI и TOI, а также идентификатор полезной нагрузки с прямой коррекцией ошибок (FEC Payload ID), который будет пояснен ниже.
Различные схемы прямой коррекции ошибок, определенные рабочей группой RMT, основаны на структуре исходного блока и кодового символа. Такие схемы прямой коррекции ошибок описаны в публикации RFC 3452 "Forward Error Correction Building Block" и публикации RFC 3695 "Compact Forward Error Correction (FEC) Schemes". Каждый кодовый символ может быть идентифицирован по его номеру исходного блока (SBN, Source Block Number) и его идентификатору кодового символа (ESI, Encoding Symbol ID). Во всех этих схемах прямой коррекции ошибок предполагается, что в пределах каждого транспортного объекта номер исходного блока последовательно увеличивается на единицу и что в пределах исходного блока идентификатор кодового символа увеличивается на единицу для каждого переданного кодового символа. И SBN, и ESI содержатся в идентификаторе полезной нагрузки с прямой коррекцией ошибок (FEC Payload ID), который содержится в пакете данных FLUTE.
В этих схемах прямой коррекции ошибок идентификация пакетов данных FLUTE, которые не приняты приемником вообще или приняты неправильно, может быть обеспечена по их SBN и ESI, которые содержатся в идентификаторе полезной нагрузки с прямой коррекцией ошибок в пакетах данных FLUTE. Эти параметры можно затем послать назад в передатчик в виде NACK, чтобы инициировать повторную передачу этих идентифицированных пакетов данных.
Однако в публикации М.Луби (М.Luby) "Simple Forward Error Correction (FEC) Schemes" (Интернет-проект) представлены схемы прямой коррекции ошибок, в которых используется более простой идентификатор полезной нагрузки с прямой коррекцией ошибок и которые могут использоваться для доставки объектов без использования какой-либо явной исходной блочной структуры. В этих схемах FEC могут, например, использоваться коды без фиксированной скорости (rateless), например коды преобразования Луби (LT, Luby Transform) или коды Raptor.
Кодер LT (см. М.Luby, "LT-codes" в материалах Proceedings of the ACM Symposium on Foundations of Computer Science (FOCS), 2002) передает поток кодированных битов, которые являются разреженными случайными линейными комбинациями k битов данных. Приемник принимает кодированные биты с шумами и использует декодер "с распространением доверия" с целью вычисления k битов данных. Количество n кодированных битов с шумами, необходимое для успешного декодирования, зависит от качества и типа канала. Коды LT, созданные с использованием "устойчивого солитонного ступенчатого распределения", могут обеспечить пропускную способность в каждом бинарном канале со стиранием (ВЕС, Binary Erasure Channel). Другими словами, отношение R=k/n может быть сделано сколь угодно близким к (1-р) для каждой вероятности р стирания.
Ключевой идеей кодирования Raptor (см. A.Shokroilahi, "Raptor codes", Digital Fountain, Inc., Tech. Rep.DF2003-06-001, June 2003) является ослабление условия, которое требует восстановить все входные символы. Если код LT должен восстановить только постоянную долю входных символов, то его граф декодирования должен иметь только 0(k) ребер, обеспечивая кодирование с линейной зависимостью от времени. Все входные символы все еще можно восстановить конкатенацией традиционного кода с коррекцией стирания и кода LT. Тогда получают n промежуточных символов кодированием k входных символов блочным кодом (k, n) с коррекцией стирания, что позволяет восстановить все входные символы из фиксированной доли промежуточных символов. Затем n промежуточных символов кодируют кодом LT, который позволяет восстановить по своим выходным символам необходимую долю промежуточных символов.
Идентификатор полезной нагрузки с прямой коррекцией ошибок, предложенный для этих схем прямой коррекции ошибок, состоит из 4-байтового ключа, по которому генерируют граф декодирования. В идентификатор полезной нагрузки с прямой коррекцией ошибок не входит SBN, и предполагается, что ESI несет идентификатор, например в данном случае указанный 4-байтовый ключ.
Кроме того, ключи генерируются случайным образом кодером прямой коррекции ошибок. Таким образом, приемник может быть не в состоянии идентифицировать недостающие пакеты данных по ключам других пакетов данных, которые он принял в сеансе связи. В результате идентификация недостающих пакетов данных FLUTE по связанных с ними SBN и ESI неприменима в этих схемах прямой коррекции ошибок.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Ввиду вышеуказанных проблем имеется потребность в усовершенствованном способе, системе, передатчике, сетевом элементе, приемнике и программном обеспечении для передачи пакета данных в системе, способной к передаче в режиме "точка - много точек".
Предложен способ передачи пакетов данных в системе, способной к передаче в режиме "точка - много точек", включающий передачу одного или большего количества пакетов данных из передатчика в один или более приемников, причем по меньшей мере одному конкретному приемнику из указанных приемников требуется прием пакетов восстановительных данных, и посылку информации восстановления в сервер восстановления данных для запуска передачи указанных пакетов восстановительных данных, причем указанная информация восстановления включает информацию, относящуюся к количеству переданных пакетов данных, правильно принятых указанным конкретным приемником.
Указанная система может представлять собой любую беспроводную или проводную систему, причем пакеты данных передаются по меньшей мере из одного передатчика в один или более приемников. Указанная передача может быть трансляцией, в которой все приемники связаны с указанным передатчиком, или передачей группового вещания, в которой только подгруппа из всех приемников связана с указанным передатчиком. Указанная система может, например, быть развернута в контексте UMTS, LAN, WLAN, DVB-T или DVB-S и может быть предназначена для распределения содержания, например мультимедийных файлов, среди множества приемников. Передача указанного символа данных или большего количества пакетов данных может быть выполнена с использованием однонаправленных или двунаправленных каналов.
Указанные переданные пакеты данных могут, например, быть связанными с содержанием, которое должно быть передано в указанные приемники. Это содержание может быть сегментировано и обработано для передачи в указанные приемники, при этом должно быть понятно, что указанные пакеты данных получаются в результате этой сегментации и обработки. Например, указанные пакеты данных могут быть пакетами данных FLUTE, полезная нагрузка которых получена кодированием с прямой коррекцией ошибок транспортного объекта, например мультимедийного файла. В этом случае полезная нагрузка указанного пакета данных FLUTE может, например, быть кодовыми символами или кодированными пакетами.
По меньшей мере одному из указанных приемников, который будем называть конкретным приемником, требуется прием пакетов восстановительных данных, что может быть обусловлено множеством причин, например неправильным приемом или потерей переданных пакетов данных. Указанный конкретный приемник может "осознать" необходимость получения пакетов восстановительных данных либо в течение указанной передачи пакетов данных, либо после того, как передача пакетов данных завершена.
Указанные пакеты восстановительных данных могут быть, например, простыми копиями переданных пакетов данных, которые не были приняты указанным конкретным приемником. В равной степени они могут отличаться как кодированием, так и фактическим содержанием. Например, если используется rateless-кодирование с прямой коррекцией ошибок, для формирования пакетов восстановительных данных можно использовать другие ключи. Таким образом, пакеты восстановительных данных служат для предоставления указанному конкретному приемнику такого количества информации, которое ему требуется.
Для запуска передачи пакетов восстановительных данных из указанного сервера восстановления данных указанный конкретный приемник выдает сигнал с информацией о восстановительных данных в указанный сервер восстановления данных. Это может иметь место при передаче в режиме точка-точка. Таким образом, сервер восстановления данных имеет возможность генерировать соответствующие пакеты восстановительных данных и передавать их в конкретный приемник. Эта передача символов восстановительных данных может, например, происходить в сеансе восстановления данных в режиме точка-точка.
Согласно настоящему изобретению предложено, чтобы эта информация восстановления включала информацию, относящуюся к количеству переданных пакетов данных, которые были правильно приняты в указанном конкретном приемнике. Здесь термин "правильно приняты" следует понимать в том смысле, что приемник способен использовать информацию, содержащуюся в указанном принятом пакете данных, для дальнейшей обработки и не должен отбросить этот пакет данных. Это решение может быть принято, например, на основе контрольной суммы, входящей в пакет данных. Суть этого предложения заключается в том, что для некоторых способов кодирования с прямой коррекцией ошибок, которые могут использоваться для формирования указанных пакетов данных из объекта данных, который должен быть фактически передан в процессе указанной передачи в режиме "точка - много точек" между указанным передатчиком и указанным одним или более приемниками, для обеспечения приемнику возможности самостоятельного восстановления указанного объекта данных оказывается достаточным прием минимального количества пакетов данных. Например, если объект данных закодирован в N пакетов данных, может потребоваться только L<N пакетов данных, чтобы приемник смог восстановить указанный объект данных. Здесь не обязательно требуется прием L конкретных пакетов данных, а достаточен прием только L различных пакетов данных из N пакетов данных. Таким образом, чтобы сервер восстановления данных смог генерировать пакеты восстановительных данных, достаточно информации о том, сколько пакетов данных было принято правильно указанным конкретным приемником, а также дополнительной структурной информации, относящейся к кодированию с прямой коррекцией ошибок.
Таким образом, в отличие от известных технических решений отсутствует необходимость точной идентификации пакетов данных, которые требуются указанному конкретному приемнику, например в терминах SBN и ESI, относящихся к определенному транспортному объекту и определенному сеансу передачи, для их посылки обратно в указанный сервер восстановления данных, что значительно уменьшает количество восходящих сигналов в сеансах восстановления данных.
В предпочтительном варианте способа согласно настоящему изобретению указанные пакеты восстановительных данных требуются из-за потери или неправильного приема по меньшей мере одного из указанных переданных пакетов данных указанным конкретным приемником. Это может быть вызвано, например, затуханием в передающем канале, задержками, искажениями или аддитивным шумом. В равной степени некоторые или все указанные переданные пакеты данных могут быть не приняты указанным конкретным приемником вообще.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанные переданные пакеты данных относятся к объектам данных. Например, указанные пакеты данных могут содержать части указанного объекта данных в исходном или кодированном виде.
В предпочтительном варианте способа согласно настоящему изобретению указанные пакеты восстановительных данных требуются для восстановления по меньшей мере одного из указанных объектов данных в указанном конкретном приемнике. Например, может возникнуть ситуация, когда указанный передатчик заканчивает передачу пакетов данных прежде, чем конкретный приемник принял все пакеты данных, которые требуются для восстановления всего транспортного объекта, загружаемого в настоящее время. В этом случае пакеты данных, отсутствующие в указанном конкретном приемнике, могут быть пакетами данных, которые фактически не были переданы ранее указанным передатчиком.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанные объекты данных представляют собой транспортные объекты, а указанная информация восстановления включает идентификатор одного из указанных транспортных объектов. Указанные транспортные объекты могут быть, например, (мультимедийными) файлами или их частями.
В еще одном предпочтительном способе согласно настоящему изобретению указанные объекты данных представляют собой части транспортных объектов, а указанная информация восстановления включает идентификатор одной из указанных частей и идентификатор соответствующего транспортного объекта. Указанные транспортные объекты могут быть, например, (мультимедийными) файлами, которые загружаются указанными приемниками. Указанные транспортные объекты могут быть сегментированы на части, например исходные блоки транспортных объектов, которые в этом случае представляют собой указанные объекты данных. Затем из указанных частей (исходных блоков) можно сформировать указанные пакеты данных, например, путем кодирования с прямой коррекцией ошибок указанного исходного блока с получением N пакетов данных. При этом предпочтительно иметь идентификатор указанной части (например, ее SBN) и идентификатор соответствующего транспортного объекта (например, его ТOI), чтобы сервер восстановления данных на основе информации, сколько пакетов данных, относящихся к исходному блоку транспортного объекта, правильно принято указанным конкретным приемником, мог определить, сколько пакетов восстановительных данных, относящихся к указанному исходному блоку указанного транспортного объекта, должно быть передано в указанный конкретный приемник. Кроме того, имеется возможность того, что транспортный объект разбит на несколько составных исходных блочных структур, и идентификатор части указанного транспортного объекта может идентифицировать одну из указанных составных исходных блочных структур и исходный блок, содержащийся там.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанные транспортные объекты относятся к сеансу передачи, а указанная информация восстановления включает идентификатор указанного сеанса передачи. Множество транспортных объектов может быть передано в пределах одного и того же сеанса передачи, а могут использоваться несколько параллельных сеансов передачи.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанная информация восстановления включает количество переданных пакетов данных, правильно принятых указанным конкретным приемником.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанная информация восстановления включает количество переданных пакетов данных, принятых указанным конкретным приемником с ошибкой. Это количество принятых с ошибкой пакетов данных связано с количеством правильно принятых пакетов данных, поскольку на основе указанного количества правильно принятых пакетов данных можно определить, известно ли конкретному приемнику полное количество переданных или необходимых пакетов данных.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанные пакеты данных и указанные пакеты восстановительных данных генерируют из указанных объектов данных путем кодирования с прямой коррекцией ошибок. Указанные пакеты данных могут, например, быть генерированы путем кодирования указанного полного объекта данных сразу целиком или его кусочным кодированием. При этом термин "кодирование" следует понимать как любой способ, который добавляет к исходным данным избыточные данные, что позволяет упростить обнаружение и/или исправление кодированных данных вследствие их искажения в передающем канале.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанное кодирование по меньшей мере частично основано на ключах кодирования, которые включены в указанные пакеты данных и пакеты восстановительных данных. Указанные ключи могут быть необходимы для декодирования указанных пакетов данных. Указанные ключи могут быть, например, бинарными псевдослучайными ключами.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанное кодирование с прямой коррекцией ошибок характеризуется тем, что для того, чтобы приемник смог восстановить указанный объект данных, этот приемник должен правильно принять только подмножество всех переданных пакетов данных, которые относятся к одному объекту данных. Например, если в процессе кодирования указанного объекта данных (или его части) генерировано N пакетов данных, то для восстановления указанного объекта данных (или его части) потребуется только L<N правильно принятых пакетов данных. Однако прием дополнительных пакетов данных может повысить качество восстановления.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанный сервер восстановления данных определяет по меньшей мере частично на основе указанной переданной информации восстановления, сколько пакетов восстановительных данных необходимо передать в указанный конкретный приемник, чтобы тот смог восстановить указанный объект данных, генерирует указанные пакеты восстановительных данных и передает эти пакеты восстановительных данных по меньшей мере в указанный конкретный приемник. Указанное определение может, например, быть основано на количестве правильно принятых пакетов данных, переданных из конкретного приемника, размере указанного объекта данных, например в терминах количества частей, на которые сегментирован указанный объект данных, и таких параметров, как избыточные данные при приеме, которые указывают, сколько пакетов данных, превышающих минимальное количество пакетов данных, необходимых для надлежащей реконструкции объекта данных, должно быть выдано в приемник.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанная прямая коррекция ошибок по меньшей мере частично основана на коде LT.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанная прямая коррекция ошибок по меньшей мере частично основана на коде Raptor.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанной передачей одного или более пакетов данных в один или более приемников по меньшей мере частично управляет зависящий от сеанса связи протокол, относящийся к однонаправленной передаче в режиме "точка - много точек".
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанной передачей одного или более пакетов данных в один или более приемников по меньшей мере частично управляет протокол доставки файлов однонаправленным транспортом (FLUTE, File Delivery over Unidirectional Transport). Тогда указанные пакеты данных могут быть, например, протокольными блоками данных протокола FLUTE.
В еще одном предпочтительном варианте способа согласно настоящему изобретению передачу указанной информации восстановления выполняют в сеансе связи в режиме точка-точка между указанным конкретным приемником и указанным сервером восстановления.
В еще одном предпочтительном варианте способа согласно настоящему изобретению передачей указанной информации восстановления по меньшей мере частично управляют с помощью протокола пересылки гипертекста.
В еще одном предпочтительном варианте способа согласно настоящему изобретению для передачи указанной информации восстановления используют методы GET или POST протокола пересылки гипертекста.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанную передачу пакетов восстановительных данных из указанного сервера восстановления в указанный конкретный приемник выполняют в сеансе связи в режиме точка-точка.
В еще одном предпочтительном варианте способа согласно настоящему изобретению указанная система представляет собой систему мультимедийного вещания / многоадресной передачи согласно стандартам Проекта партнерства третьего поколения.
Кроме того, предложена система для передачи пакетов данных, способная осуществлять передачу в режиме "точка - много точек", содержащая передатчик, один или более приемников и сервер восстановления данных, причем один или более пакетов данных передаются из указанного передатчика в указанные приемники, по меньшей мере одному конкретному приемнику из указанных приемников требуется прием пакетов восстановительных данных, информация восстановления передается в указанный сервер восстановления данных для запуска передачи указанных пакетов восстановительных данных, и указанная информация восстановления включает информацию, относящуюся к количеству переданных пакетов данных, правильно принятых указанным конкретным приемником.
Кроме того, предложен передатчик для системы, способной осуществлять передачу в режиме "точка - много точек", содержащий средство для передачи одного или большего количества пакетов данных в один или более приемников, причем по меньшей мере одному конкретному приемнику из указанных приемников требуется прием пакета восстановительных данных, информация восстановления выдается в сервер восстановления данных для запуска передачи указанных пакетов восстановительных данных, и информация восстановления включает информацию, относящуюся к количеству переданных пакетов данных, правильно принятых указанным конкретным приемником. Указанные передатчик и сервер восстановления данных могут быть расположены в одном месте или даже идентичны.
В предпочтительном варианте выполнения передатчика согласно настоящему изобретению указанные переданные пакеты данных относятся к объектам данных, а передатчик дополнительно содержит средство для формирования указанных пакетов данных из указанных объектов данных путем кодирования с прямой коррекцией ошибок.
Кроме того, предложен сетевой элемент для системы, способной осуществлять передачу в режиме "точка - много точек", где один или большее количество пакетов данных передаются из передатчика в один или более приемников, причем по меньшей мере одному конкретному приемнику из указанных приемников требуется прием пакетов восстановительных данных; указанный сетевой элемент включает средство для приема информации восстановления, переданной в этот сетевой элемент для запуска передачи указанных пакетов восстановительных данных, причем указанная информация восстановления включает информацию, относящуюся к количеству переданных пакетов данных, правильно принятых указанным конкретным приемником. Указанный сетевой элемент может быть расположен в одном месте с передатчиком или даже может быть идентичным ему и может быть, например, сервером восстановления данных.
В предпочтительном варианте выполнения сетевого элемента согласно настоящему изобретению указанные переданные пакеты данных относятся к объектам данных, указанные пакеты восстановительных данных генерируются из указанных объектов данных кодированием с прямой коррекцией ошибок, а характерным свойством указанного кодирования с прямой коррекцией ошибок является то, что для того, чтобы восстановить указанный объект данных, приемник должен принять только подмножество переданных пакетов данных, которые относятся к одному объекту данных, указанный сетевой элемент содержит средство для определения по меньшей мере частично на основе указанной информации восстановления, сколько пакетов восстановительных данных необходимо передать в указанный конкретный приемник, чтобы тот смог восстановить указанный объект данных, средство для формирования указанных пакетов восстановительных данных и средство для передачи указанных пакетов восстановительных данных по меньшей мере в указанный конкретный приемник.
В еще одном предпочтительном варианте сетевого элемента согласно настоящему изобретению указанные переданные пакеты данных относятся к объектам данных, а указанный сетевой элемент дополнительно содержит средство для формирования указанных пакетов восстановительных данных из указанных объектов данных кодированием с прямой коррекцией ошибок.
Кроме того, предложен приемник для системы, способной осуществлять передачу в режиме "точка - много точек", содержащий средство для приема одного или более пакетов данных, которые передаются из передатчика в один или более приемников, причем по меньшей мере указанному приемнику требуется прием пакетов восстановительных данных, и средство для передачи информации восстановления в сервер восстановления данных для запуска передачи указанных пакетов восстановительных данных, причем указанная информация восстановления включает информацию, относящуюся к количеству переданных пакетов данных, правильно принятых указанным приемником.
Кроме того, предложено программное обеспечение, выполняемое в приемнике системы, способной осуществлять передачу в режиме "точка -много точек", причем программное обеспечение включает программные коды с целью заставить приемник принять один или более пакетов данных, которые переданы передатчиком в один или более приемников, причем по меньшей мере указанному приемнику требуется прием пакетов восстановительных данных; и программные коды для того, чтобы заставить приемник выдать информацию восстановления в сервер восстановления данных и запустить передачу указанных пакетов восстановительных данных, причем указанная информация восстановления включает информацию, относящуюся к количеству переданных пакетов данных, правильно принятых указанным приемником.
Программное обеспечение может также быть компьютерным программным продуктом, включающим программный код, который хранится на носителе, например, в памяти.
Эти и другие аспекты настоящего изобретения станут понятны из последующего описания вариантов выполнения настоящего изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
На чертежах изображено следующее:
на фиг.1 схематично иллюстрируется кодирование транспортного объекта в последовательность пакетов данных согласно спецификациям для кодирования Raptor при MBMS-загрузке файла;
на фиг.2а схематично иллюстрируется система для работы в режиме "точка - много точек" согласно настоящему изобретению, где пакеты данных передаются из передатчика в множество приемников;
на фиг.2b схематично иллюстрируется система для работы в режиме "точка - много точек" согласно настоящему изобретению, в которой конкретный приемник передает информацию восстановления обратно в сервер восстановления данных;
на фиг.2с схематично иллюстрируется система для работы в режиме "точка - много точек" согласно настоящему изобретению, в которой сервер восстановления данных передает пакеты восстановительных данных в конкретный приемник; и
на фиг.3 показан пример последовательности операций для способа приема пакетов данных и пакетов восстановительных данных в режиме "точка - много точек" в системе согласно настоящему изобретению.
ПОДРОБНОЕ ОПИСАНИЕ НАСТОЯЩЕГО ИЗОБРЕТЕНИЯ
Предваряя дальнейшее изложение, следует отметить, что в качестве дополнения к данному подробному описанию можно использовать содержание вводной части настоящего документа.
В настоящем изобретении предлагается, чтобы информация, относящаяся к количеству пакетов данных, которые правильно приняты конкретным приемником в системе передачи пакетов данных в режиме "точка - много точек", передавалась обратно в сервер восстановления данных для запуска передачи тех пакетов восстановительных данных, которые требуются указанному конкретному приемнику. Это обеспечивает особенно эффективную обратную связь по информации, что позволяет серверу восстановления данных определить те пакеты восстановительных данных, которые должны быть переданы в указанный конкретный приемник. Этот подход особенно полезен, когда указанные пакеты данных генерированы кодированием транспортных объектов с прямой коррекцией ошибок посредством кодов без фиксированной скорости, например кодов LT или Raptor.
На фиг.1 схематично иллюстрируется кодирование с прямой коррекцией ошибок транспортного объекта 1 размером 3 Мб (типичный размер для MBMS-загрузок файлов) в последовательность из N кодированных пакетов 3-1…3-N с использованием N ключей кодирования 2-1…2-N, причем это кодирование с прямой коррекцией ошибок соответствует техническим требованиям на код Raptor для MBMS-загрузки файлов (см. публикацию 3GPP Tdoc S4-040230 "Raptor Code Specification for MBMS file download", SA4 #31, Montreal, Canada, May 17-21, 2004). Части кодированных пакетов 3-1…3-N, полученные указанным кодированием с прямой коррекцией ошибок (в частности, один или большее количество кодовых символов 30-i), в этом случае могут служить, например, полезной нагрузкой для пакетов данных FLUTE, как более подробно обсуждается ниже.
На фиг.1 транспортный объект 1, который может быть идентифицирован идентификатором TOI, представляет собой только один из множества транспортных объектов, которые передаются из передатчика в множество приемников в сеансе передачи, который идентифицирован идентификатором TSI. Согласно фиг.1 транспортный объект 1 состоит из 15 исходных блоков 10-1…10-16, причем каждый из этих исходных блоков состоит из К=6144 32-разрядных исходных символов, которые для примера обозначены для исходного блока 10-1 как 100-1…100-6144. Каждый исходный блок 10-1…10-16 имеет размер 32 байта на 6144.
Кодирование с прямой коррекцией ошибок всего транспортного объекта 1 достигается матричным умножением транспортного объекта 1 на матрицу размером К×N, колонки которой составлены из 6144×1 бинарных ключей кодирования, причем значение "1" ключа кодирования схематично показано черной областью, а "0" схематично изображен белой областью. Указанные N различных ключей кодирования могут, например, представлять собой бинарные псевдослучайные коды, но в равной степени могут быть выбраны более преднамеренно.
Указанное количество N используемых ключей кодирования превышает К и определяет объем избыточных данных для приемника. С увеличением К вероятность правильного восстановления транспортного объекта 1 из набора кодовых символов 3-1…3-N повышается.
При выполнении вышеописанного матричного умножения получают N кодированных пакетов 3-1…3-N, каждый кодированный пакет имеет размер 512 байтов. По различной штриховке кодированных пакетов легко заметить, что каждый кодированный пакет состоит из 16 кодовых символов соответственно, например, кодированный пакет 3-1 состоит из кодовых символов 30-1…30-16. Можно также заметить, что на кодовый символ 30-1 влияют все элементы исходного блока 10-1, но только один ключ кодирования 2-1. Аналогично на кодовый символ 30-2 влияют все элементы исходного блока 10-2 и ключ кодирования 2-1. Поэтому ключ кодирования 2-1 включен в кодированный пакет 3-1 в качестве ключа 31, и точно так же другие кодирующие ключи 2-1…2-N включены в N кодированных пакетов 3-2…3-N соответственно. При этом включение не обязательно означает, что все бинарные ключи включены в кодированные пакеты, как показано на фиг.1. Более эффективно идентифицировать соответствующий ключ кодирования 2-1…2-N соответствующими 4-байтовыми идентификаторами, которые, например, для кодирующего пакета 3-1 показаны на фиг.1 как ключ 31. Указанная идентификация может, например, относиться к состояниям регистра сдвига, который подходит для формирования необходимого ключа кодирования, или к аналогичному параметру.
Тот факт, что каждый кодированный пакет 3-i зависит только от ключа кодирования 2-i, не должен создавать впечатления, что возможно изолированное декодирование всего исходного блока на основе единственного кодированного пакета. Фактически, как можно заметить на фиг.1, информация об одном исходном блоке 10-i содержится в соответствующих кодовых символах всех кодированных пакетов 3-1…3-N. Для правильного декодирования исходного блока 10-i, вследствие характеристик кодов без фиксированной скорости (rateless), необходимо обработать по меньшей мере К кодированных пакетов. Обработка более К пакетов, например всех N кодовых символов, улучшает качество декодирования. Кроме того, легко заметить, что когда для декодирования имеется достаточно (больше, чем К) кодированных пакетов, можно декодировать не только один исходный блок 10-i, но и все исходные блоки 10-1…10-16. Таким образом, когда для декодирования доступно больше, чем К, кодированных пакетов, можно восстановить весь транспортный объект 1.
Этот принцип применяют при использовании кодов без фиксированной скорости в каналах передачи с потерями. Когда транспортный объект, каждый исходный блок которого состоит из К исходных символов, как показано на фиг.1, закодирован в N кодированных пакетов, приемник, чтобы быть в состоянии восстановить транспортный объект 1, не обязательно должен правильно получить все N кодированных пакетов. Кроме того, не требуется даже определенной последовательности приема кодированных пакетов или приема соседнего по времени блока кодированных пакетов, поскольку информации ключа кодирования, который также включен в каждый кодированный пакет, достаточно для использования принятого пакета данных при декодировании транспортного объекта.
Поэтому для гарантии того, что в приемнике имеется достаточно кодированных пакетов, достаточно, как предложено в настоящем изобретении, сообщить количество правильно принятых пакетов данных, которое соответствует количеству правильно принятых кодированных пакетов (поскольку в данном случае каждый пакет данных содержит в качестве полезной нагрузки один кодированный пакет), в сервер восстановления данных, который затем формирует дополнительные кодированные пакеты (пакеты восстановительных данных), которые после их правильного приема позволят приемнику декодировать указанный транспортный объект. Указанная информация запроса на восстановление, состоящая по меньшей мере из указанного количества правильно принятых пакетов данных (соответствующего в этом случае количеству правильно принятых кодированных пакетов), предпочтительно дополнительно включает идентификаторы TSI и TOI, позволяющие идентифицировать сеанс передачи и, если имеется несколько транспортных объектов, тот транспортный объект, для которого требуются пакеты восстановительных данных. Кроме того, запрос на восстановление может также включать IP-адрес передатчика. Он может потребоваться, поскольку один и тот же сервер может действовать в качестве предпочтительного сервера восстановления данных для многих передатчиков. В этом случае в запрос на восстановление, возможно, придется включить также IP-адрес передатчика. Таким образом, IP-адрес передатчика и идентификатор TSI однозначно идентифицируют сеанс.
На фиг.1 весь транспортный блок 1 сегментирован на исходные блоки 10-1…10-10, которые совместно кодированы с использованием одинаковых ключей кодирования 2-1…2-N с получением кодированных пакетов 3-1…3-N. Понятно, что, если каждый пакет данных FLUTE содержит весь кодированный пакет 3-i, сервер восстановления данных также должен будет генерировать все кодированные пакеты 3-i в случае запроса на восстановление из конкретного приемника вследствие недостатка пакетов данных. Однако может быть предпочтительной сегментация транспортного блока на исходные блоки, что облегчает декодирование при наличии небольшой быстрой памяти в декодере приемника, то есть быстрая память приемника в этом случае должна одновременно содержать только кодовые символы, соответствующие одному исходному блоку. Кроме того, декодер может повторить те же самые шаги при восстановлении каждого исходного блока, поскольку он при этом декодирует кодовые символы, которые занимают в принятой последовательности точно те же самые позиции.
Напротив, если каждый пакет данных FLUTE содержит только один кодовый символ (например, 30-1 на фиг.1) из каждого кодированного пакета (например, 3-1 на фиг.1), в случае недостающего пакета данных необходимо генерировать только пакет восстановительных данных, содержащий этот кодовый символ, а не весь кодированный пакет. Однако при этом для обеспечения идентификации исходного блока, к которому относится кодовый символ, может потребоваться дополнительный идентификатор для SBN в идентификаторе полезной нагрузки с прямой коррекцией ошибок для каждого пакета данных FLUTE. При этом каждый заголовок пакета данных FLUTE содержит, например, TSI, TOI, SBN и идентификатор ключа, и в случае потери или неправильного приема пакета данных FLUTE в дополнение к количеству уже принятых правильно пакетов данных FLUTE конкретному приемнику, возможно, придется включить SBN исходного блока для транспортного объекта, к которому относится кодовый символ в потерянном пакете данных. Тогда сервер восстановления данных генерирует только новые кодовые символы для исходного блока, как указано SBN в информации восстановления.
Если исходный файл является настолько большим, что не вписывается в составную исходную блочную структуру, изображенную на фиг.1, то может оказаться необходимым сегментировать исходный файл в более чем одну составную исходную блочную структуру. В этом случае в запрос о восстановлении, возможно, придется также включить идентификатор составной исходной блочной структуры. В этом случае каждый заголовок пакета данных FLUTE может содержать, например, TSI, ТO1, составной SBN и идентификатор ключа, и в случае потери или неправильного приема пакета данных FLUTE в дополнение к количеству уже правильно принятых пакетов данных FLUTE (которое в этом случае соответствует количеству правильно принятых кодовых символов) конкретному приемнику, возможно, придется дополнительно включить составной SBN исходного блока для транспортного объекта, к которому относится кодовый символ в потерянном пакете данных FLUTE. Тогда сервер восстановления данных может генерировать только новые кодовые символы для составного исходного блока, как указано составным SBN в запросе на восстановление.
Настоящее изобретение охватывает обе вышеуказанные возможности встраивания в пакеты данных FLUTE как кодовых символов всего кодированного пакета, так и только отдельных кодовых символов.
На фиг.2а показаны функциональные компоненты передатчика 4 и приемника 5-1 для сценария передачи в режиме "точка - много точек", когда пакеты данных FLUTE (несущие в качестве полезной нагрузки все кодовые символы кодированного пакета или только отдельный кодовый символ, как обсуждалось выше) передаются в множество приемников 5-1…5-3.
Передатчик 4 содержит интерфейс 40 для сети 6, например Интернета, и, таким образом, имеет доступ к контенту, который имеется в сети и распределяется между указанными приемниками 5-1…5-3 в сеансе вещания / многоадресной передачи. Затем этот контент может, например, храниться в памяти 41 указанного передатчика. Для передачи указанного контента производится его кодирование и модуляция блоком 42 модуляции и кодирования. Операции, производимые указанным блоком 42, удовлетворяют требованиям, налагаемым различными уровнями стека протоколов ISO/OSI. В частности, в этом блоке 42 производится генерация пакетов данных FLUTE на основе кодирования, с прямой коррекцией ошибок, транспортных объектов с формированием кодовых символов (либо одного, либо нескольких на пакет данных), являющихся полезной нагрузкой пакетов данных FLUTE, и определение полей заголовка пакетов данных FLUTE, содержащих, например, идентификаторы TSI, TOI и идентификатор полезной нагрузки с прямой коррекцией ошибок (в данном случае кодирования без фиксированной скорости с прямой коррекцией ошибок это соответствует 4-байтовому идентификатору ключа и, возможно, SBN). Затем блок 42 модулирует сигналы, которые передаются блоком 43, работающим в качестве интерфейса беспроводного или проводного (например, оптического) канала передачи. Всеми блоками 40, 41, 42 и 43 передатчика 4 управляет блок 44 управления.
В приемнике 5-1, который в данном случае рассматривается в качестве некоторого конкретного приемника, модулированные сигналы принимаются посредством блока 50, а затем подаются в блок 51 демодуляции и декодирования, который функционально соответствует блоку 42 модуляции и кодирования в передатчике 4. В частности, модулированные сигналы демодулируют, и производится проверка, приняты пакеты данных FLUTE правильно или нет. Это может быть, например, осуществлено уровнями протокола, лежащими ниже уровня FLUTE, по контрольной сумме или с использованием аналогичных способов. Если установлено, что пакет данных FLUTE был получен правильно, значение счетчика 510 в указанном блоке 51 увеличивается. Указанный блок 51 демодуляции и декодирования служит также буфером для принятых пакетов данных FLUTE и, если было получено достаточно много пакетов FLUTE, выполняет декодирование пакетов данных FLUTE с восстановлением желаемого транспортного объекта, который затем может быть сохранен в памяти 52 приемника 5-1. Указанный приемник 5-1 дополнительно содержит блок 53 модуляции и кодирования с функциональными возможностями, аналогичными функциональным возможностям блока 42 модуляции и кодирования в передатчике 4, и блок 54, который действует как интерфейс с каналом передачи. Всеми блоками 50, 51, 52, 53 и 54 управляет блок 55 управления.
На фиг.2b иллюстрируется сеанс восстановления данных в режиме точка-точка между сервером 7 восстановления и конкретным приемником 5-1 в течение передачи пакетов данных или после того, как передача пакетов данных, показанная на фиг.2а, была завершена. При этом приемник 5-1 проверяет значение счетчика 510, чтобы определить, было ли получено достаточно пакетов данных FLUTE, чтобы восстановить транспортный объект. Если это не так, контроллер 55 с помощью блока 53 модуляции и кодирования обеспечивает формирование запроса на восстановление (аналогичного сообщению NACK), который содержит информацию восстановления, например, TSI, TOI, количество правильно принятых пакетов данных, подсчитанное указанным счетчиком 510, и, возможно, SBN. При генерации указанного запроса на восстановление может по меньшей мере частично использоваться другой протокольный стек по сравнению с протокольным стеком, который используется для указанной передачи в режиме "точка - много точек", например, может использоваться протокол HTTP. При этом указанный запрос на восстановление может, например, иметь следующий вид:
GET http://www.website.com/greatmusic/numberl.mp3?mbms-rel6-FLUTE repair&TSI=123&TOI=456&NumRxedPkts=5432
НТТР/1.1
В этом сообщении GET (Получить) сервер восстановления данных, TSI (123), TOI (456) и количество правильно полученных пакетов данных (5432) представляют собой информацию восстановления. В сообщение запроса на восстановление может также быть включен IP-адрес (или URL) сервера (передатчика) MBMS.
Альтернативно, для запроса недостающих пакетов данных могут быть использованы другие методы HTTP, например POST (Послать). Например, следующее сообщение POST эквивалентно сообщению GET, приведенному выше.
POST http://www.website.com/greatmusic/ НТТР/1.1
From: subscriberl0@provider.com
Content-Type: application/x-www-form-url-encoded
Content-Length: 56
numberl.mp3&mbms-rel6-FLUTE-repair&TSI=123&TOI=456& NumRxedPkts=5432
Затем этот запрос на восстановление передается через блок 54 в сервер 7 восстановления, где он принимается посредством блоков 70, демодулируется и декодируется в блоке 71, который выполняет функции, обратные функциям блока 53 в конкретном приемнике 5-1, и, в случае необходимости, сохраняется в памяти 72. Указанный сервер 7 восстановления дополнительно содержит блок 73 модуляции и кодирования, блок 74 передачи и интерфейс 75 к сети 6. Всеми блоками сервера восстановления управляет блок 76 управления.
Наконец, на фиг.2с показана ситуация, когда сервер 7 восстановления передает пакеты восстановительных данных FLUTE в указанный конкретный приемник 5-1 в ответ на указанный запрос на восстановление, посланный, как показано на фиг.2b. При этом сервер восстановления данных оценивает информацию восстановления, принятую из конкретного приемника 5-1 посредством протокола HTTP, и определяет, сколько пакетов данных нужно генерировать и передать в указанный конкретный приемник, чтобы тот смог восстановить указанный транспортный объект. Сервер 7 восстановления берет указанный транспортный объект или его части либо из собственной памяти, либо через интерфейс 75 из сети 6 и выполняет кодирование указанного объекта или его частей с прямой коррекцией ошибок, как показано на фиг.1, с формированием кодовых символов, которые служат полезной нагрузкой для пакетов восстановительных данных FLUTE, при этом в качестве полезной нагрузки для пакетов данных можно использовать один или несколько кодовых символов. Сервер 7 восстановления данных может, например, определить количество М пакетов восстановительных данных FLUTE для каждого объекта (TSI, ТОI и, возможно, SBN) на основе количества колонок транспортного объекта 1 (переменная К на фиг.1), избыточных символов при приеме и количества правильно принятых пакетов данных FLUTE, переданных конкретным приемником в его запросе на восстановление. Тогда сервер 7 восстановления данных генерирует набор М ключей и генерирует соответствующие кодовые символы, которые затем встраиваются в пакеты восстановительных данных FLUTE (по одному или по несколько кодовых символов), модулируются и передаются в указанный конкретный приемник 5-1 посредством блоков 73 и 74.
Затем в указанном приемнике 5-1 модулированные сигналы, содержащие пакеты восстановительных данных FLUTE, принимаются посредством блока 50 и обрабатываются в блоке 51, чтобы определить, был ли пакет данных принят правильно или нет. Если достаточно много пакетов данных FLUTE или пакетов восстановительных данных было принято правильно, транспортный объект может быть восстановлен указанным блоком 51 и сохранен в указанной памяти 52 для дальнейшей обработки.
На фиг.3 показан пример последовательности операций для способа приема пакетов данных в приемнике в системе, осуществляющей прием в режиме "точка - много точек". На первом шаге 801 счетчик пакетов устанавливают в нуль, например, чтобы начать прием пакетов данных, относящихся к новому транспортному объекту. Затем, на шаге 802, принимают пакеты данных, переданные передатчиком в множество приемников. На шаге 803 проверяют правильность каждого отдельного принятого пакета данных. Если пакет принят правильно, то показания счетчика увеличивают на единицу, а в противном случае оставляют без изменения. Затем, на шаге 805, проверяют, завершена ли передача пакетов данных. Если нет, то способ возвращается назад к шагу 802 приема пакетов данных. В противном случае на шаге 806 проверяют, достаточно ли пакетов данных принято, путем сравнения, превышает ли значение счетчика минимальное необходимое количество пакетов данных. Если это так, на шаге 807 принятые пакеты данных декодируют с получением желаемого транспортного объекта. В противном случае необходимо начать сеанс восстановления, посылая информацию восстановления, включающую по меньшей мере значение счетчика и, возможно, SBN, а предпочтительно дополнительно включающую TSI и TOI, в запросе на восстановление на сервер восстановления данных. Тогда сервер восстановления данных начинает передачу пакетов восстановительных данных на основе указанной переданной информации восстановления, в результате чего приемник переходит к шагу 802 приема пакетов восстановительных данных. Эту процедуру продолжают до тех пор, пока указанный приемник не примет достаточно пакетов данных, что проверяют на шаге 806.
Выше настоящее изобретение было описано на примере предпочтительных вариантов его выполнения. Следует отметить, что имеются альтернативные пути и модификации, которые очевидны специалистам в данной области техники и могут быть реализованы без выхода за рамки формулы изобретения.