RU2462822C2 - Способ подтверждения приема данных - Google Patents

Способ подтверждения приема данных Download PDF

Info

Publication number
RU2462822C2
RU2462822C2 RU2009117216/07A RU2009117216A RU2462822C2 RU 2462822 C2 RU2462822 C2 RU 2462822C2 RU 2009117216/07 A RU2009117216/07 A RU 2009117216/07A RU 2009117216 A RU2009117216 A RU 2009117216A RU 2462822 C2 RU2462822 C2 RU 2462822C2
Authority
RU
Russia
Prior art keywords
block
data
variable
blocks
code
Prior art date
Application number
RU2009117216/07A
Other languages
English (en)
Other versions
RU2009117216A (ru
Inventor
Дэвид ХОУЛ (GB)
Дэвид ХОУЛ
Original Assignee
Нокиа Сименс Нетворкс Гмбх Унд Ко. Кг
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Нокиа Сименс Нетворкс Гмбх Унд Ко. Кг filed Critical Нокиа Сименс Нетворкс Гмбх Унд Ко. Кг
Publication of RU2009117216A publication Critical patent/RU2009117216A/ru
Application granted granted Critical
Publication of RU2462822C2 publication Critical patent/RU2462822C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1614—Details of the supervisory signal using bitmaps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809—Selective-repeat protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1664—Details of the supervisory signal the supervisory signal being transmitted together with payload signals; piggybacking

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

Изобретение относится к области передачи данных. Технический результат заключается в уменьшении избыточности сообщений подтверждения приема. Сущность изобретения заключается в том, что для подтверждения приема данных в системе связи, содержащей более одного блока (4, 5) данных верхнего уровня в блоке (3) протокола нижнего уровня, посылают данные (6) подтверждения приема и данные (4, 5) верхнего уровня в одном и том же блоке (3) протокола нижнего уровня. Данные подтверждения приема, относящиеся ко всем блокам данных верхнего уровня в (или в каждом) блоке протокола нижнего уровня, кодируют в соответствии с вероятностью типа подтверждения приема. 14 з.п. ф-лы, 4 ил.

Description

Это изобретение относится к способу подтверждения приема данных в системе связи.
Данные универсальной пакетной радиослужбы (GPRS) передают в блоках управления линией радиосвязи (RLC)/управления доступом к среде (MAC). Эти блоки данных верхнего уровня кодируют и передают в блоках протокола нижнего уровня, известных как радиоблоки. В зависимости от схемы кодирования обычно имеются один или два блока RLC/MAC на радиоблок. Радиоблок обычно содержит один заголовок и один или два блока RLC/MAC. Декодирование заголовка является предварительным требованием для декодирования блока (блоков) RLC/MAC.
В универсальной пакетной радиослужбе (GPRS)/сети радиодоступа развития расширенных данных для глобальной системы мобильной связи (GSM)(EDGE)(GERAN) Проекта партнерства 3-го поколения в настоящее время проводится работа, чтобы ввести быстрые сообщения подтверждения приема (Ack)/отрицательного подтверждения приема (Nack)'(FANR). Традиционно подтверждение приема принятых данных осуществлялось посредством специального сообщения, такого как Ack/Nack нисходящей пакетной линии связи, которое содержит данные подтверждения приема и, возможно, другие управляющие данные, но не содержит никаких данных пользователя.
Идеей FANR является включать небольшое количество данных подтверждения приема вместе с данными пользователя в одном и том же радиоблоке. Выгодой от этого является то, что эти блоки могут быть посланы более часто, позволяя устройству однорангового узла более часто повторно посылать блоки, которые были неправильно приняты. Если бы существующие сообщения посылались с более высокой частотой, то имело бы место существенное уменьшение пропускной способности для передачи пользовательских данных, и была бы существенная избыточность сообщений подтверждения приема.
В соответствии с первым аспектом настоящего изобретения способ подтверждения приема данных в системе связи, содержащей более одного блока данных верхнего уровня в блоке протокола нижнего уровня, содержит посылку данных подтверждения приема и данных верхнего уровня в одном и том же блоке протокола нижнего уровня, причем данные подтверждения приема, относящиеся ко всем блокам данных верхнего уровня в каждом блоке протокола нижнего уровня, кодируют в соответствии с вероятностью типа подтверждения приема.
Хотя традиционно имеются только один или два блока верхнего уровня в блоках нижнего уровня, возможно, что могло бы быть включено большее число блоков верхнего уровня, обычно три или четыре.
Предпочтительно, каждому множеству блоков данных верхнего уровня в блоке протокола нижнего уровня, прием которого подтверждают, назначают блок переменной длины в сообщении подтверждения приема, причем относительная позиция блока переменной длины в сообщении приема связана с истекшим временем после того, как был послан блок данных верхнего уровня.
Предпочтительно, сообщение подтверждения приема включает в себя множество блоков переменной длины, причем каждый блок переменной длины кодируют в соответствии с кодом переменной длины, связанным с вероятностью типа подтверждения приема.
Предпочтительно, код переменной длины используют только тогда, когда максимальное число блоков данных верхнего уровня на блок протокола данных нижнего уровня равно 2.
Предпочтительно, сообщение подтверждения приема включает в себя указание максимального числа блоков данных верхнего уровня на блок протокола нижнего уровня всех сообщенных блоков протокола нижнего уровня, и используется ли код переменной длины.
Предпочтительно, код переменной длины дополнительно содержит префикс, действительный только для первого кода.
Предпочтительно, код переменной длины дополнительно содержит конечную последовательность, указывающую традиционным устройствам конец кода переменной длины.
Предпочтительно, код переменной длины выбирают из некоторого числа сохраненных кодов.
Предпочтительно, идентификацию выбранного кода включают в сообщение подтверждения приема.
Предпочтительно, один специальный бит в сообщении подтверждения приема относится к специальному блоку данных верхнего уровня.
Предпочтительно, блоки данных верхнего уровня назначают в подгруппы предварительно определенным способом и код переменной длины применяют к каждой подгруппе.
Множество разных механизмов может быть использовано для кодирования блоков переменной длины в сообщении подтверждения приема. В одном варианте осуществления неудачу приема всех блоков данных верхнего уровня в блоке протокола нижнего уровня указывают с помощью более короткого кода, чем код, используемый для неудачи приема только некоторых блоков данных верхнего уровня.
Это допускает, что, если все множества блоков данных верхнего уровня потерпели неудачу, система пошлет их повторно, в то время как если только некоторые потерпели неудачу, может потребоваться дополнительная детализация в кодировании, чтобы узнать, какой блок посылать.
В качестве альтернативы, в другом варианте осуществления неудача приема всех множеств блоков данных верхнего уровня в блоке данных нижнего уровня также может быть указана с помощью более длинного кода.
Предпочтительно, блок данных верхнего уровня является блоком данных протокола доступа к среде управления линией радиосвязи.
Предпочтительно, система является сетью радиодоступа развития универсальной пакетной радиослужбы с увеличенными скоростями передачи данных для глобальной системы мобильной связи (GERAN).
В одном варианте осуществления однобитовый код указывает успешный прием всех блоков данных верхнего уровня в одном радиоблоке.
Это предполагает, что успешный прием является наиболее общей ситуацией. Однако при обстоятельствах, когда это не имело места, тогда однобитовый код может быть использован, чтобы указывать некоторый другой результат. Когда необходимо предоставить дополнительную информацию, а также указание успешного приема, код может быть самым коротким кодом, а не однобитовым кодом.
Ниже описан пример способа подтверждения приема данных в системе связи, в соответствии с настоящим изобретением, со ссылкой на сопровождающие чертежи, на которых:
фиг.1 иллюстрирует пример системы, в которой может быть выполнен способ настоящего изобретения;
фиг.2 иллюстрирует обмен сообщениями между компонентами системы фиг.1;
фиг.3 изображает пример радиоблока и возможные варианты приема; и
фиг.4 изображает сообщение подтверждения приема, использующее способ настоящего изобретения для современных и традиционных устройств.
В примере по фиг.1 базовая станция (BS) сети взаимодействует с одним или более подвижных устройств (MS1, MS2, MS3). Когда базовая станция или подвижное устройство передают 1, 2 друг другу, они требуют указания, безошибочно ли было принято содержимое передачи, или должна быть повторно передана некоторая часть. Традиционно это подтверждение приема было отдельным сообщением. Например, как проиллюстрировано на фиг.2, если базовая станция (BS) передает 1 ко всем трем мобильным устройствам, то она принимает три ответа 2а, 2b, 2с, если все три устройства принимают успешно.
Разработка быстрого сообщения ACK/NACK (FANR) с учетом этих непроизводительных затрат выявила дополнительные вопросы. Одним вариантом является то, что быстрое сообщение ACK/NACK будет содержать приблизительно 20 битов данных подтверждения приема, 2 бита из которых используют для того, чтобы указывать состояние каждого ранее принятого радиоблока. Кроме того, могут быть два блока RLC/MAC на радиоблок, и кодирование может быть осуществлено, например, следующим образом:
00 - неудачное декодирование заголовка
- заголовок правильно принят, но неудачно декодирована полезная нагрузка блока RLC (или блоков, имеется более одного блока RLC на радиоблок)
01 - заголовок правильно принят, но неудачно декодирован первый блок данных RLC, правильно декодирован второй блок данных RLC
10 - заголовок правильно принят, правильно декодирован первый блок данных RLC, неудачно декодирован второй блок данных RLC
11 - правильно декодирована полезная нагрузка (одного) блока RLC или правильно декодирован как первый, так и второй блоки данных RLC
Однако некоторое число вопросов остается, а именно, как быстро должны передаваться сообщения FANR каждым одноранговым узлом и сколько блоков может быть сообщено в сообщении FANR.
Другие данные подтверждения приема, такие как посланные ACK/NACK пакетной нисходящей линии радиосвязи, посылают либо как незакодированную битовую карту с одним битом на блок RLC/MAC, либо с помощью использования закодированной версии битовой карты переменной длины. Однако вследствие небольшой длины битовой карты, приблизительно 20 битов, в этом случае такое кодирование является неэффективным.
В одной схеме для FANR, как описано выше, идентификация блоков, которые упомянуты как «временные», например, быстрых блоков в сообщении, является идентификацией, которая была послана 40 мс тому назад в противоположном направлении в соответствующем интервале времени как FANR. Каждая точка кодирования в этом решении относится к радиоблоку, а не к блоку RLC/MAC.
Альтернативным решением является иметь битовую карту с одним битом на блок RLC/MAC плюс порядковый номер (SN) первого блока в битовой карте. Все блоки до одного перед первым блоком в битовой карте неявно подтверждаются как правильно принятые. С другой стороны, это означает, что FANR не должны передаваться так часто, например, при хороших условиях радиосвязи, если принята длинная строка успешных блоков, тогда не нужно посылать FANR. Только тогда, когда имеется ошибка, FANR должно быть послано. С другой стороны, SN (который может быть длиной 11 битов) занимает существенную часть FANR, уменьшая величину доступного пространства битовой карты.
Дополнительным преимуществом первой схемы является то, что в нисходящей линии связи, т.е. данные подтверждения приема передаются от мобильного устройства в сеть, может выполняться широковещательная передача FANR, и она может относиться к блокам, принятым из множества пакетных «соединений» (известных как временные потоки блоков - TBF) и даже из разных мобильных устройств. Это является невозможным при подходе, основанном на SN, поскольку SN определяется на основе TBF, и, таким образом, FANR могло бы относиться только к одному TBF. Однако выгодой подхода, основанного на SN, является то, что SN не должен посылаться до тех пор, пока не случится ошибка, поскольку подход, основанный на SN, неявно подтверждает прием блоков с меньшими SN, чем SN, указанным в FANR.
Дополнительным преимуществом первой схемы является то, что FANR немедленно указывает тот факт, что заголовок принятого блока мог бы быть декодирован. В противоположность этому подход, основанный на SN, требует знания порядкового номера (который кодируется с заголовком) рассматриваемого блока. Идентификация блока, для которого заголовок не мог бы быть декодирован, может быть выведена из приема следующего блока, но, поскольку это требует приема упомянутого следующего блока, это вводит задержку в указание неудачно декодированного заголовка относительно основанного на времени подхода FANR.
Фиг.3 иллюстрирует типичное множество блоков передачи и приема. Блок 3 RLC/MAC посылают в периоде одного радиоблока, и он содержит заголовок 4 RLC/MAC и один или более (в этом случае два) протокольных блоков 5 данных (PDU) RLC/MAC. Имеются разные возможные исходы. Если заголовок не принят (вариант А) или если заголовок принят, но не приняты PDU, результат является одинаковым. В качестве альтернативы, может быть принят один PDU и заголовок (варианты С и D), или принято и то и другое, или все PDU и заголовок (вариант Е).
В настоящем изобретении «основанный на времени» подход может быть усовершенствован, делая его значительно более эффективным, с помощью использования кода переменной длины для определения каждой точки кода. Когда ранее обычно требовались 2 бита на радиоблок, изобретение может уменьшить это до менее чем 1,5 (в зависимости от конкретного шаблона ошибок).
При нормальной работе вероятность того, что блок RLC/MAC является ошибочным, должна быть менее чем 30%. Следовательно, поскольку наиболее вероятным исходом является то, что весь (все) блок (блоки) RLC/MAC в радиоблоке принят (приняты) правильно, чтобы указывать это, используется один бит. Более длинные коды используются для других соответствующих ситуаций.
Изобретение также использует тот факт, что в случае, когда имеются два блока данных на радиоблок, вероятность ошибки для каждого из них может быть сильно коррелирована (т.е. если один блок является ошибочным, вероятно, что другой блок также является ошибочным). Следовательно, более короткий код назначается для случая, когда оба блока являются ошибочными, чем для случая, когда только один блок является ошибочным. (Этот код также используется, когда один блок является носителем на радиоблок и является ошибочным). Поскольку никакая точка кода не начинается в одной и той же последовательности битов, что и другая более короткая точка кода, при декодировании отсутствует неоднозначность.
Декодирование полезной нагрузки зависит от правильного декодирования заголовка, таким образом, указание успешного декодирования одного или более блоков RLC обеспечивает явное указание того, что заголовок был успешно декодирован. Необязательно отличать случай, когда заголовок не декодирован успешно, от случая, когда заголовок декодирован, но никакой из блоков данных RLC не мог бы быть декодирован. Согласно фиг.3 вариант Е, когда заголовок декодирован и блок (оба блока) успешно декодирован(ы), кодируется как 0; вариант В, когда заголовок декодирован, но блок (оба блока) декодирован(ы) с ошибкой, кодируется как 10; вариант D, когда заголовок декодирован и первый блок RLC/МАС успешно декодирован, но второй является ошибочным, кодируется как 110; и вариант С, когда заголовок декодирован, а первый блок RLC/МАС декодирован с ошибкой, но второй блок декодирован успешно, кодируется как 111.
Будущее использование этого FANR для других целей или в новом формате удовлетворяется за счет допущения более длинных точек кода, оставляя неиспользованным один «префикс». Примером решения для этого является:
0 Заголовок декодирован и блок (оба блока) успешно декодирован(ы) (вариант Е);
10 Заголовок декодирован, но блок (оба блока) является(ются) ошибочным(и) (вариант В);
110 Заголовок декодирован, первый блок RLC/МАС декодирован успешно, второй является ошибочным (вариант D);
1110 Заголовок декодирован, первый блок RLC/МАС декодирован с ошибками, второй успешно (вариант С);
1111 Префикс остается неиспользованным и доступным для будущего использования.
Поскольку вероятность случая «заголовок декодирован, первый блок RLC/МАС декодирован с ошибками, второй успешно» предполагается низкой (например, 1%), увеличение среднего числа битов, используемых на точку кода, является несущественным.
Однако это можно решить с помощью дополнительного уточнения, в соответствии с чем префикс «будущего использования» используется только для первой точки кода в FANR, причем следующие точки кода возвращают к первому, не расширяемому, варианту. В качестве альтернативы определяется «конечная последовательность», чтобы позволить «традиционным» устройствам определять, где будет находиться конец новой точки кода. (Эта конечная последовательность не может появиться в середине любых новых точек кода, только в конце). При использовании для подтверждения приема данных нисходящей линии связи точка '0' также должна охватывать случай, когда заголовок был декодирован, но данные не были предназначены для этого мобильного устройства.
При допущении, что используется первый, не расширяемый, вариант, если вероятности каждого события являются следующими:
80% Заголовок декодирован и блок (оба блока) успешно декодирован(ы) (вариант Е);
20% Заголовок декодирован, но блок (оба блока) является(ются) ошибочным(и) (вариант В);
5% Заголовок декодирован, первый блок RLC/МАС декодирован успешно, второй является ошибочным (вариант D);
5% Заголовок декодирован, первый блок RLC/МАС декодирован с ошибками, второй успешно (вариант С),
то среднее число битов на радиоблок соответствует 1,5 битам на радиоблок (0,75 на RLC/MAC блок, если 2 RLC/MAC блока посланы в каждом радиоблоке), по сравнению с 2 битами на радиоблок (1 бит на RLC/MAC блок) с использованием современной схемы.
Приведенные выше вероятности находятся вблизи конца обычного рабочего диапазона (общая вероятность ошибки блока RLC/MAC в данном случае равна 25%, обычно она равна приблизительно 10%, хотя может увеличиваться до 30%). При лучших условиях радиосвязи улучшение было бы даже больше, так, например, со следующими вероятностями (общая вероятность ошибки блока 7,5%):
90% Заголовок декодирован и блок (оба блока) успешно декодирован(ы) (вариант Е);
5% Заголовок декодирован, но блок (оба блока) является(ются) ошибочным(и);
2,5% Заголовок декодирован, первый блок RLC/МАС декодирован успешно, второй является ошибочным;
2,5% Заголовок декодирован, первый блок RLC/МАС декодирован с ошибками, второй успешно,
тогда используется только 1,15 битов на радиоблок.
Выгодой более эффективного кодирования является то, что FANR могут передаваться менее часто, уменьшая непроизводительные затраты, возникающие при их использовании. Более высокие непроизводительные затраты означают, что либо посылается меньше данных, либо данные кодируются менее интенсивно, делая менее вероятным их правильный прием.
Различие между использованием расширяемых и не расширяемых вариантов не очень велико: для изображенных двух сценариев вероятности расширяемые версии используют в среднем 1,55 или 1,175 битов на радиоблок соответственно.
В зависимости от диапазона сообщенных шаблонов ошибок могут быть сохранены разные коды переменной длины, выбор которых выполняют как часть структуры сообщения, и идентификация кода, указанная в сообщении.
Фиг.4 изображает содержимое блока 3 RLC/MAC при использовании быстрого сообщения ACK/NACK. Так же, как заголовок 4, блок 6 данных подтверждения приема включен до PDU 5. В противоположность традиционной системе, как изображено на фиг.4b, блок RLC/MAC включает в себя заголовок и блок управления, который содержит данные подтверждения приема, но не включает в себя PDU.
В зависимости от числа блоков RLC/MAC, посланных в каждом из сообщенных радиоблоков, может быть выгодно (т.е. позволяет более эффективное кодирование) возвратиться к подходу n битов на радиоблок, где n - максимальное число блоков RLC/MAC на радиоблок из всех сообщенных радиоблоков и имеется прямое однозначное отображение между битами в сообщении и конкретными блоками RLC/MAC. Таким образом, дополнительным признаком этого изобретения является сигнализировать в сообщении о том, какой тип кодирования используется (т.е. значение n, и/или использовано ли кодирование переменной длины или нет). Дополнительной возможностью является то, что использование (или не использование) кодирования переменной длины непосредственно связано со значением n, например, кодирование переменной длины используется всегда (и только всегда) для n=2.
В качестве альтернативы могло бы быть более эффективным использовать подход, описанный выше для двух блоков RLC на радиоблок, и когда имеются более двух блоков RLC на радиоблок, чтобы группировать блоки RLC в две подгруппы предварительно заданным способом. Тогда кодирование, описанное выше, может быть использовано без модификации, за исключением того, что, когда делают ссылку, например, на «первый блок RLC», принятый правильно, теперь это бы означало, что «все блоки RLC в первой подгруппе» приняты правильно, т.е. положительное подтверждение приема указывает, что блоки RLC в подгруппе приняты правильно, отрицательное подтверждение приема указывает, что один или более блоков RLC в подгруппе были приняты неправильно.

Claims (15)

1. Способ подтверждения приема данных в системе связи, содержащей более одного блока данных верхнего уровня в блоке протокола нижнего уровня, причем способ содержит этап, на котором посылают данные подтверждения приема и данные верхнего уровня в одном и том же блоке протокола нижнего уровня, причем данные подтверждения приема, относящиеся ко всем блокам данных верхнего уровня в (или в каждом) блоке протокола нижнего уровня, кодируют в соответствии с вероятностью типа подтверждения приема.
2. Способ по п.1, в котором каждому множеству блоков данных верхнего уровня в блоке протокола нижнего уровня, прием которого подтверждают, назначают блок переменной длины в сообщении подтверждения приема, причем относительная позиция блока переменной длины в сообщении подтверждения приема связана с истекшим временем после того, как был послан блок данных верхнего уровня.
3. Способ по п.1 или 2, в котором сообщение подтверждения приема включает в себя множество блоков переменной длины, причем каждый блок переменной длины кодируют в соответствии с кодом переменной длины, связанным с вероятностью типа подтверждения приема.
4. Способ по п.3, в котором код переменной длины используют, только когда максимальное число блоков данных верхнего уровня на блок протокола данных нижнего уровня равно 2.
5. Способ по п.3, в котором сообщение подтверждения приема включает в себя указание максимального числа блоков данных верхнего уровня на блок протокола нижнего уровня всех сообщенных блоков протокола нижнего уровня, и использован ли код переменной длины.
6. Способ по п.5, в котором код переменной длины дополнительно содержит префикс, действительный только для первого кода.
7. Способ по п.6, в котором код переменной длины дополнительно содержит конечную последовательность, указывающую традиционным устройствам конец кода переменной длины.
8. Способ по п.3, в котором код переменной длины выбирают из некоторого числа сохраненных кодов.
9. Способ по п.8, в котором идентификацию выбранного кода включают в сообщение подтверждения приема.
10. Способ по п.1, в котором один специальный бит в сообщении подтверждения приема относится к специальному блоку данных верхнего уровня.
11. Способ по п.3, в котором блоки данных верхнего уровня назначают в подгруппы предварительно определенным способом и код переменной длины применяют к каждой подгруппе.
12. Способ по п.1, в котором неудачу приема всех множеств блоков данных верхнего уровня в блоке протокола нижнего уровня указывают с помощью более короткого кода, чем код, используемый для неудачи приема только некоторых блоков данных верхнего уровня.
13. Способ по п.1, в котором блок данных верхнего уровня является блоком данных протокола доступа к среде управления линией радиосвязи.
14. Способ по п.1, в котором система является сетью радиодоступа развития универсальной пакетной радиослужбы с увеличенными скоростями передачи данных для глобальной системы мобильной связи.
15. Способ по п.1, в котором однобитовый код указывает успешный прием всех блоков данных верхнего уровня в одном радиоблоке.
RU2009117216/07A 2006-10-06 2007-10-03 Способ подтверждения приема данных RU2462822C2 (ru)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GBGB0619769.3A GB0619769D0 (en) 2006-10-06 2006-10-06 Variable length coding
GB0619769.3 2006-10-06
GB0716435.3 2007-08-23
GB0716435A GB2442551B (en) 2006-10-06 2007-08-23 A method of acknowledging data

Publications (2)

Publication Number Publication Date
RU2009117216A RU2009117216A (ru) 2010-11-20
RU2462822C2 true RU2462822C2 (ru) 2012-09-27

Family

ID=37454095

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2009117216/07A RU2462822C2 (ru) 2006-10-06 2007-10-03 Способ подтверждения приема данных

Country Status (6)

Country Link
US (1) US8208379B2 (ru)
EP (1) EP2074731B1 (ru)
CN (1) CN101529778B (ru)
GB (2) GB0619769D0 (ru)
RU (1) RU2462822C2 (ru)
WO (1) WO2008041033A1 (ru)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8156397B2 (en) * 2007-08-21 2012-04-10 Broadcom Corporation Method and system for feedback of decoded data characteristics to a decoder in stored data access and decoding operations to assist in additional decoding operations
US8392811B2 (en) * 2008-01-07 2013-03-05 Qualcomm Incorporated Methods and systems for a-priori decoding based on MAP messages
US8780817B2 (en) * 2008-09-22 2014-07-15 Qualcomm Incorporated Apparatus and method for reducing overhead for communications
EP2323114B1 (fr) * 2009-11-13 2012-10-31 Hager Controls Procédé d'obtention rapide d'informations sur l'état de fonctionnement d'une pluralité d'équipements fonctionnant en groupe dans un réseau de type domotique.
DE102012210816A1 (de) 2012-06-26 2014-01-02 Siemens Aktiengesellschaft Datenpaket für eine bidirektionale Übertragung von Datenpaketen bei einer Datenübertragung zwischen einem ersten und einem zweiten Kommunikationsgerät sowie Verfahren zum Übertragen eines solchen Datenpaketes
US9660768B2 (en) 2015-01-26 2017-05-23 Link Labs, Inc. Dense acknowledgement broadcast/multicast
US20180063854A1 (en) * 2016-08-30 2018-03-01 Qualcomm Incorporated Acknowledgement message prioritization

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002314546A (ja) * 2001-02-28 2002-10-25 Sharp Corp 無線ネットワーク局間の通信に優先順位を付ける方法
RU2004108124A (ru) * 2001-08-21 2005-05-10 Роук Мэнор Рисерч Лимитед (Gb) Способ подтверждения приема данных
WO2005107127A1 (en) * 2004-05-04 2005-11-10 Telefonaktiebolaget Lm Ericsson (Publ) Improved incremental redundancy operation in a wireless communication network
EP1626519A2 (en) * 2004-08-11 2006-02-15 Kabushiki Kaisha Toshiba Communication apparatus and communication method

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4841526A (en) * 1984-05-25 1989-06-20 Wilson Jon C Data communications system
US6658619B1 (en) * 2000-10-06 2003-12-02 Ericsson Inc. Systems and methods for implementing hierarchical acknowledgement bitmaps in an ARQ protocol
US6606037B2 (en) * 2000-11-13 2003-08-12 Telefonaktiebolaget Lm Ericsson (Publ) Qualitative modeling and compression of request sequences in ARQ protocols
US7414989B2 (en) * 2003-05-07 2008-08-19 Motorola, Inc. ACK/NACK determination reliability for a communication device
US7296204B2 (en) * 2003-05-30 2007-11-13 Wegener Communications, Inc. Error correction apparatus and method
US7716160B2 (en) * 2003-11-07 2010-05-11 Alien Technology Corporation Methods and apparatuses to identify devices
FI116114B (fi) 2004-01-27 2005-09-15 Nokia Corp Kuittausviestien käsittely päätelaitteessa
JP4331088B2 (ja) * 2004-11-01 2009-09-16 株式会社東芝 通信装置および通信方法
BRPI0609889B1 (pt) * 2005-05-23 2019-05-07 Optis Wireless Technology, Llc Método de operação de um receptor e método de operação de um transmissor para uso em um sistema de telecomunicação sem fio
JP2010503250A (ja) * 2006-08-30 2010-01-28 ノキア コーポレイション モバイル通信システムにおける高速ａｃｋ／ｎａｃｋの方法及び装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002314546A (ja) * 2001-02-28 2002-10-25 Sharp Corp 無線ネットワーク局間の通信に優先順位を付ける方法
RU2004108124A (ru) * 2001-08-21 2005-05-10 Роук Мэнор Рисерч Лимитед (Gb) Способ подтверждения приема данных
WO2005107127A1 (en) * 2004-05-04 2005-11-10 Telefonaktiebolaget Lm Ericsson (Publ) Improved incremental redundancy operation in a wireless communication network
EP1626519A2 (en) * 2004-08-11 2006-02-15 Kabushiki Kaisha Toshiba Communication apparatus and communication method

Also Published As

Publication number Publication date
RU2009117216A (ru) 2010-11-20
CN101529778B (zh) 2014-04-23
US8208379B2 (en) 2012-06-26
EP2074731A1 (en) 2009-07-01
CN101529778A (zh) 2009-09-09
GB2442551B (en) 2009-01-07
GB0716435D0 (en) 2007-10-03
GB2442551A (en) 2008-04-09
US20100182958A1 (en) 2010-07-22
EP2074731B1 (en) 2016-02-17
GB0619769D0 (en) 2006-11-15
WO2008041033A1 (en) 2008-04-10

Similar Documents

Publication Publication Date Title
US7379434B2 (en) Radio communication system
EP1530844B1 (en) Arq system with status and packet acknowledgement
KR101123144B1 (ko) 데이터 통신을 위한 방법 및 시스템과, 데이터 전송을 위한 국
CN111030785B (zh) 在无线网络中进行数据重传的方法、系统以及无线接收器
US20090031185A1 (en) Hybrid arq systems and methods for packet-based networks
US20020064167A1 (en) Hybrid ARQ with parallel packet transmission
RU2462822C2 (ru) Способ подтверждения приема данных
US20080043777A1 (en) Method of transmitting or receiving a data packet in packet data communication system using hybrid automatic repeat request
CN104782072B (zh) 采用可靠停等混合自动重传请求协议的系统和方法
RU2531264C2 (ru) Способ кодирования информации обратной связи harq с помощью двух отдельных кодовых слоев с неравной защитой от ошибок для dtх и ack/nack
EP2229746A1 (en) Method and transmitting unit for reducing a risk of transmission stalling
EP2137863A1 (en) Multiple packet source acknowledgement
WO2003007530A2 (en) Method of transmitting data packets
US20050226159A1 (en) Apparatus, and associated method, for providing a medium access control layer hybrid automatic repeat request scheme for a carrier sense multiple access communication scheme
Dong et al. CARE: Corruption-aware retransmission with adaptive coding for the low-power wireless
US20040170192A1 (en) Method of transmitting data packets
CN101278514A (zh) 用于纠错和选择性重传的方法、设备和系统
US9853766B2 (en) Radio communication devices, access points, method for controlling a radio communication device, and methods for controlling an access point
CN101867439B (zh) 比特映射方式的指示方法
KR100857778B1 (ko) 서브패킷을 이용한 패킷 송수신 방법
CN104253679A (zh) 解码方法

Legal Events

Date Code Title Description
PD4A Correction of name of patent owner
PC41 Official registration of the transfer of exclusive right

Effective date: 20150622

MM4A The patent is invalid due to non-payment of fees

Effective date: 20161004