Способ и устройство передачи данных

Изобретение относится к мобильной связи, а именно к способу и устройству передачи данных. Техническим результатом является повышение производительности передачи данных по нисходящей линии связи. Технический результат достигается тем, что способ передачи данных содержит этапы, на которых принимают объектом расширения функции (ОРФ) протокола управления передачей (TCP) пакет данных (ПД), переданный отправителем; передают объектом ОРФ TCP принятый ПД получателю через уровень управления радиоканалом; после того как информация подтверждения ПД принята уровнем управления радиоканалом от получателя, получают объектом ОРФ TCP информацию о соответствующем ПД согласно информации подтверждения, причем информация подтверждения указывает прием ПД получателем; если сообщение квитирования для приема ПД получателем не принято объектом ОРФ TCP от получателя, то формируют объектом ОРФ TCP квитирование (ACK), чтобы указать, что ПД корректно принят получателем, согласно полученной информации о соответствующем ПД; и передают объектом ОРФ TCP сформированное АСК к отправителю. 3 н. и 11 з.п. ф-лы, 10 ил.

 

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

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

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

Протокол управления передачей (TCP) обычно применяется в службах с коммутацией пакетов (PS) беспроводной связи. Беспроводная сеть характеризуется такими признаками, как большая задержка, переменная скорость передачи данных, асимметрия, пик задержки и колебания полосы, которые могут негативно сказываться на производительности TCP. С развитием информационных услуг требования к качеству обслуживания (QoS), предъявляемые пользователем, становятся все выше. Важно повышать производительность передачи TCP в радиоканале-носителе.

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

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

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

Варианты осуществления настоящего изобретения обеспечивают способ и устройство передачи данных для повышения производительности передачи данных по нисходящей линии связи.

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

принимают пакет данных, переданный отправителем;

отправляют принятый пакет данных получателю через протокольный уровень;

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

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

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

блок приема, выполненный с возможностью приема пакета данных, переданного отправителем, и записи информации о принятом пакете данных;

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

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

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

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

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

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

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

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

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

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

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

Фиг. 5 - структура устройства передачи данных согласно варианту осуществления настоящего изобретения.

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

Фиг. 7 - структура устройства передачи данных согласно другому варианту осуществления настоящего изобретения.

Фиг. 8 - структура устройства передачи данных согласно другому варианту осуществления настоящего изобретения.

Фиг. 9 - структура промежуточного NE согласно варианту осуществления настоящего изобретения.

Фиг. 10 - структура промежуточного NE согласно другому варианту осуществления настоящего изобретения.

Подробное описание вариантов осуществления

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

S101. Принять пакет данных, переданный отправителем, и записать информацию о принятом пакете данных.

После приема пакета данных от отправителя порядковый номер (SN) пакета данных записывается согласно порядку приема пакетов данных. SN может увеличиваться в возрастающем порядке. Например, первый принятый пакет данных идентифицируется по SN 1, и второй принятый пакет данных идентифицируется по SN 2, и т.д. Число цифр SN пакета данных не ограничено, но слишком длинный SN неудобно записывать. Таким образом, отсчет SN может начинаться заново, если SN достигает определенного значения. Например, если SN достигает 65535, отсчет SN снова начинается с 1. Таким образом, можно учитывать большое количество пакетов данных. Если пакет данных является TCP-пакетом, можно записывать длину пакета и порядковый номер TCP.

S102. Отправить принятый пакет данных получателю через протокольный уровень.

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

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

Отображение пакета данных отражает отношение между записанным пакетом данных и пакетом данных, принятым протокольным уровнем, и отображение пакета данных может представлять собой таблицу отображения. Отображение пакета данных можно генерировать следующим образом: поскольку информация о принятом пакете данных записана на этапе S101, и протокольный уровень также записывает SN принятого пакета данных, который однозначно соответствует SN пакета данных, записанному TCP-прокси. Например, если первый пакет данных, принятый TCP-прокси, идентифицируется по SN 1, первый пакет данных, принятый протокольным уровнем, также идентифицируется по SN 1. Таким образом, порядок пакетов данных, записанных протокольным уровнем, соответствует порядку пакетов данных, записанных TCP-прокси, во взаимнооднозначном соответствии. Взаимнооднозначное соответствие называется отображением пакета данных.

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

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

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

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

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

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

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

Если протокольный уровень принял информацию подтверждения от получателя, но TCP-прокси не принял ни одного TCP ACK от получателя в ответ на пакет данных, можно определить, что получатель верно принял пакет данных, переданный отправителем, и TCP-прокси может строить ACK и передавать его отправителю. ACK можно строить согласно информации о пакете данных, найденной посредством отображения пакетов данных. Информация о пакете данных может включать в себя SN. Если пакет данных является TCP-пакетом, информация о пакете данных может дополнительно включать в себя порядковый номер TCP и длину пакета TCP-пакета, и поэтому SN построенного ACK может быть равен порядковому номеру TCP плюс длина пакета для TCP-пакета. Для других типов пакетов данных, ACK можно строить иначе согласно конкретным условиям. TCP-прокси отправляет построенное ACK отправителю и записывает SN построенного ACK.

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

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

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

S201. TCP-прокси принимает пакет данных, отправленный сервером, и записывает информацию о принятом пакете данных.

Для процесса передачи по нисходящей линии связи пакет данных, отправленный сервером на терминал, пересылается через TCP-прокси, и поэтому все пакеты данных проходят через TCP-прокси. Таким образом, SN пакета данных можно записывать согласно порядку приема пакета данных. SN может увеличиваться в возрастающем порядке. Например, первый принятый пакет данных идентифицируется по SN 1, и второй принятый пакет данных идентифицируется по SN 2, и т.д. Если пакет данных является TCP-пакетом, можно записывать длину пакета и TCP SN TCP-пакета. Информацию о длине пакета данных и TCP SN TCP-пакета можно получить из информации заголовка пакета для TCP-пакета.

S202. Отправить принятый пакет данных на терминал через уровень RLC.

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

S203. Генерировать отображение пакета данных согласно записанной информации о пакете данных.

Сгенерированное отображение пакета данных можно сохранять в виде таблицы отображения пакета данных.

Заметим, что отображение пакета данных можно сохранять на TCP-прокси или на уровне RLC. Отображение пакета данных обобществляется между TCP-прокси и уровнем RLC. Согласно этому варианту осуществления предполагается, что TCP-прокси генерирует отображение пакета данных.

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

S204. Уровень RLC ищет соответствующую информацию согласно отображению пакетов данных после приема информации подтверждения от терминала.

Заметим, что терминал является общим понятием, которое включает в себя оконечное устройство и его протокольный(е) уровень(ни).

Уровень RLC может действовать в двух режимах: с подтверждением и без подтверждения. Здесь применяется механизм подтверждения передачи данных между уровнем RLC и терминалом. При прохождении через уровень RLC сервисный блок данных (SDU) делится на протокольные блоки данных (PDU), которые передаются на терминал. После приема PDU терминал возвращает на уровень RLC информацию подтверждения, указывающую, что терминал принял пакет данных от сервера. Уровень RLC знает, какие пакеты данных верно приняты терминалом, согласно информации подтверждения, принятой от терминала, и затем, какие пакеты данных на TCP-прокси приняты терминалом, можно узнать путем поиска отображения пакета данных на этапе S202. Поскольку TCP-прокси также записывает информацию о пакете данных, например длину пакета и SN TCP-пакета, можно найти информацию о соответствующем пакете данных.

S205. Принять решение, необходимо ли строить ACK, согласно найденной информации о пакете данных.

TCP-прокси также записывает SN для TCP ACK, который передается на TCP-прокси от терминала.

Информация о пакете данных может включать в себя SN пакета данных. Если пакет данных является TCP-пакетом, информация о пакете данных может включать в себя длину пакета и SN TCP-пакета. Согласно найденной информации о пакете данных, SN ACK, подлежащего построению, известен. Например, для TCP-пакета, если SN первого пакета данных равен 1, и длина пакета равна 1460, SN ACK, подлежащего построению, равен 1461; SN второго пакета данных равен 1461, и SN ACK, подлежащего построению, равен 2921, и т.д. Для других типов пакетов данных ACK можно строить другими способами.

SN для TCP ACK, возвращенный терминалом и записанный в TCP-прокси, можно сравнивать с SN ACK, подлежащего построению, для определения, необходимо ли строить ACK. TCP-прокси может записывать, по меньшей мере, один SN для TCP ACK, возвращенный терминалом. Максимальный SN для TCP ACK, записанный на TCP-прокси, сравнивается с SN ACK, подлежащего построению. Если максимальный SN для TCP ACK, возвращенный терминалом и записанный в TCP-прокси, больше или равен SN ACK, подлежащего построению, это говорит о том, что TCP-прокси принял TCP ACK, отправленное терминалом, и что больше не нужно ACK строить, и поэтому этап S201 и последующие этапы не нужно повторять. Если максимальный SN для TCP ACK, возвращенный терминалом и записанный в TCP-прокси, меньше SN ACK, подлежащего построению, это говорит о том, что TCP-прокси не принял TCP ACK, возвращенное терминалом, и что ACK нужно построить, и поэтому осуществляется этап S206.

S206. Построить ACK и отправить его на сервер.

Если TCP-прокси не принял TCP ACK, возвращенное терминалом, TCP-прокси строит ACK активно и отправляет его на сервер. После приема ACK, сервер может скользить по окну для передачи новых данных.

SN построенного ACK равен длине пакета для TCP-пакета плюс SN TCP-пакета. Например, SN первого пакета данных равен 1, длина пакета первого пакета данных равна 1460, и поэтому SN построенного ACK равен 1461; SN второго пакета данных равен 1461, длина пакета второго пакета данных равна 1460, и поэтому SN построенного ACK равен 2921, и т.д. SN построенного ACK можно записывать на TCP-прокси.

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

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

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

S301. Принять пакет данных, переданный отправителем.

S302. Отправить принятый пакет данных получателю через протокольный уровень.

Объект расширения функции TCP принимает пакет данных, переданный отправителем, и отправляет пакет данных получателю через протокольный уровень. Объект расширения функции TCP может присутствовать в разных местах сети, в том числе, но без ограничения: интернете, базовой сети и RAN. Протокольный уровень также может присутствовать в разных местах сети. Например, протокольный уровень является уровнем RLC.

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

Между протокольным уровнем и получателем существует механизм подтверждения. После приема пакета данных от отправителя получатель возвращает информацию подтверждения пакета данных на протокольный уровень. Благодаря информации подтверждения протокольный уровень знает, какие пакеты данных верно приняты получателем, знает какие пакеты данных, переправленные объектом расширения функции TCP, верно приняты получателем, и может дополнительно получать информацию о таких пакетах данных. Информация о пакете данных может представлять собой SN пакета данных. Если пакет данных является TCP-пакетом, информация о пакете данных может дополнительно включать в себя TCP SN и длину пакета для TCP-пакета. Длину пакета и TCP SN TCP-пакета можно получить из информации заголовка пакета для TCP-пакета.

S304. Построить ACK, адресованное отправителю, согласно полученной информации о пакете данных.

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

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

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

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

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

S401. TCP-прокси принимает пакет данных, отправленный сервером.

S402. TCP-прокси пересылает принятый пакет данных на терминал.

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

S403. После приема уровнем RLC информации подтверждения пакета данных от оконечного устройства получить информацию о соответствующем пакете данных согласно информации подтверждения.

Благодаря информации подтверждения, принятой от оконечного устройства, уровень RLC знает, какие пакеты данных верно приняты оконечным устройством и какие пакеты данных от TCP-прокси приняты оконечным устройством, что позволяет получить информацию о соответствующем пакете данных. Информация о пакете данных может представлять собой SN пакета данных. Если пакет данных является TCP-пакетом, информация о пакете данных может дополнительно включать в себя SN и длину пакета для TCP-пакета.

S404. Принять решение, необходимо ли строить ACK, согласно полученной информации о пакете данных.

Для TCP ACK, отправленного оконечным устройством на TCP-прокси, TCP-прокси может записывать SN для TCP ACK. Информация подтверждения служит основой для получения соответствующей информации о пакете данных и определения SN ACK, подлежащего построению. Например, если SN первого пакета данных равен 1, и длина пакета равна 1460, SN ACK, подлежащего построению, равен 1461; SN второго пакета данных равен 1461, и SN ACK, подлежащего построению, равен 2921, и т.д.

SN для TCP ACK, возвращенный терминалом и записанный в TCP-прокси, можно сравнивать с SN ACK, подлежащего построению, для определения, необходимо ли строить ACK. TCP-прокси может записывать, по меньшей мере, один SN для TCP ACK, возвращенный терминалом. Максимальный SN для TCP ACK, записанный на TCP-прокси, сравнивается с SN ACK, подлежащего построению. Если максимальный SN для TCP ACK, возвращенный терминалом и записанный в TCP-прокси, больше или равен SN ACK, подлежащего построению, это говорит о том, что TCP-прокси принял TCP ACK, отправленное терминалом, и что больше не нужно ACK строить; если максимальный SN для TCP ACK, возвращенный терминалом и записанный в TCP-прокси, меньше SN ACK, подлежащего построению, это говорит о том, что TCP-прокси не принял ни одного TCP ACK, возвращенное терминалом, и что ACK нужно построить, и поэтому осуществляется этап S405.

S405. Построить ACK и отправить его на сервер.

Поскольку TCP-прокси не принял TCP ACK, возвращенное терминалом, TCP-прокси строит ACK активно и отправляет его на сервер. После приема ACK, сервер может скользить по окну для передачи новых данных.

ACK можно строить таким образом: если пакет данных является TCP-пакетом, информация о пакете данных дополнительно включает в себя TCP SN и длину пакета TCP-пакета, и поэтому SN построенного ACK может равняться TCP SN TCP-пакета плюс длина пакета для TCP-пакета. Например, SN первого пакета данных равен 1, длина пакета первого пакета данных равна 1460, и поэтому SN построенного ACK равен 1461; SN второго пакета данных равен 1461, длина пакета второго пакета данных равна 1460, и поэтому SN построенного ACK равен 2921, и т.д. Для других типов пакетов данных ACK можно строить иначе согласно конкретным условиям. Кроме того, если TCP-прокси принимает TCP ACK, возвращенное терминалом, TCP-прокси может сравнивать SN для TCP ACK, возвращенный терминалом, с SN для ACK, построенного на TCP-прокси. TCP-прокси может записывать более одного построенного ACK. SN для TCP ACK, возвращенный терминалом, можно сравнивать с максимальным SN построенного ACK. Если SN для TCP ACK, возвращенный терминалом, меньше или равен максимальному SN построенного ACK, это говорит о том, что TCP-прокси отправил соответствующее ACK на сервер, и TCP-прокси проигнорировал ACK, отправленное терминалом, вместо того, чтобы переправить ACK на сервер. Если SN для TCP ACK, возвращенный терминалом, больше максимального SN построенного ACK, TCP-прокси переправляет TCP ACK, возвращенное терминалом, на сервер и записывает SN для TCP ACK, возвращенный терминалом.

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

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

Блок приема 501 выполнен с возможностью приема пакета данных, переданного отправителем, и записи информации о принятом пакете данных.

После приема пакета данных от отправителя SN пакета данных записывается согласно порядку приема пакетов данных. SN может увеличиваться в возрастающем порядке. Например, первый принятый пакет данных идентифицируется по SN 1, и второй принятый пакет данных идентифицируется по SN 2, и т.д. Во избежание слишком длинных SN отсчет SN может начинаться заново, если SN достигает определенного значения. Например, если SN достигает 65535, отсчет SN может возобновляться с 1. Таким образом, можно учитывать большое количество пакетов данных. Если пакет данных является TCP-пакетом, нужно записывать длину пакета и SN TCP-пакета.

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

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

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

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

Отображение пакета данных отражает соответствующее отношение между пакетом данных на устройстве передачи данных и пакетом данных, принятым протокольным уровнем, и отображение пакета данных может представлять собой таблицу отображения. Отображение пакета данных можно генерировать следующим образом: поскольку блок приема 501 записывает информацию о принятом пакете данных, и протокольный уровень также записывает SN принятого пакета данных, который однозначно соответствует SN пакета данных, записанный TCP-прокси. Таким образом, если первый пакет данных, принятый TCP-прокси, идентифицируется по SN 1, первый пакет данных, принятый протокольным уровнем, также идентифицируется по SN 1, и т.д. Таким образом, порядок пакетов данных, записанных протокольным уровнем, соответствует порядку пакетов данных, записанных блоком приема 501, во взаимно-однозначном соответствии. Взаимно-однозначное соответствие называется отображением пакета данных.

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

Блок построения 504 выполнен с возможностью построения ACK, адресованного отправителю, согласно информации о пакете данных, найденной блоком поиска 503.

Если протокольный уровень принял информацию подтверждения от получателя, но устройство передачи данных не приняло ACK от получателя в ответ на пакет данных, можно определить, что получатель верно принял пакет данных, переданный отправителем, и блок построения 504 может построить ACK и передать его отправителю. ACK строится согласно информации о пакете данных, найденной блоком поиска 503. Информация о пакете данных может представлять собой SN пакета данных. Если пакет данных является TCP-пакетом, информация о пакете данных может включать в себя TCP SN и длину пакета для TCP-пакета. ACK можно строить согласно информации о пакете данных, найденной посредством отображения пакетов данных. Если пакет данных является TCP-пакетом, SN построенного ACK может быть равен TCP SN плюс длина пакета для TCP-пакета. Для других типов пакетов данных ACK можно строить иначе согласно конкретным условиям.

Блок построения 504 отправляет построенный ACK отправителю и может записывать SN построенного ACK.

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

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

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

Согласно другому варианту осуществления настоящего изобретения предусмотрено другое устройство передачи данных. Согласно фиг. 6 устройство может включать в себя блок приема 601, блок передачи 602, блок генерации 603, блок поиска 604, блок принятия решения 605, блок построения 606 и блок сравнения 607.

Блок приема 601 выполнен с возможностью приема пакета данных, переданного отправителем, и записи информации о принятом пакете данных.

Функции и процесс реализации блока приема 601 в основном такие же, как для блока приема 501 в предыдущем варианте осуществления, описанном выше.

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

Функции и процесс реализации блока передачи 602 в основном такие же, как для блока передачи 502 в предыдущем варианте осуществления, описанном выше.

Блок генерации 603 выполнен с возможностью генерации отображения пакета данных согласно информации о пакете данных, записанной блоком приема 601.

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

Протокольный уровень также записывает SN принятого пакета данных. Таким образом, если первый пакет данных, принятый блоком приема 601, идентифицируется по SN 1, первый пакет данных, принятый протокольным уровнем, также идентифицируется по SN 1, и т.д. Таким образом, порядок пакетов данных, записанных уровнем RLC, соответствует порядку пакетов данных, записанных TCP-прокси, во взаимнооднозначном соответствии. Взаимнооднозначное соответствие называется отображением пакета данных.

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

Функции блока поиска 604 в основном такие же, как у блока поиска 503 в предыдущем варианте осуществления, описанном выше.

Блок принятия решения 605 выполнен с возможностью принятия решения, необходимо ли строить ACK, согласно информации о пакете данных, найденной блоком поиска 604.

Для TCP ACK, отправленного получателем на устройство передачи данных, блок принятия решения 605 устройства передачи данных также записывает SN для ACK.

Информация о пакете данных может включать в себя SN пакета данных. Если пакет данных является TCP-пакетом, информация пакета данных может включать в себя длину пакета и SN TCP-пакета. Согласно найденной информации о пакете данных можно узнать SN ACK, подлежащего построению. Например, для TCP-пакета, если SN первого пакета данных равен 1, и длина пакета равна 1460, SN ACK, подлежащего построению, равен 1461; SN второго пакета данных равен 1461, и SN ACK, подлежащего построению, равен 2921, и т.д. Для других типов пакетов данных ACK можно строить другими способами.

SN для TCP ACK, возвращенный терминалом и записанный на блоке принятия решения 605, сравнивается с SN ACK, подлежащего построению, для определения нужно ли строить ACK. Блок принятия решения 605 может записывать, по меньшей мере, один SN для TCP ACK, возвращенный терминалом. Максимальный SN для TCP ACK, записанный на блоке принятия решения 605, сравнивается с SN ACK, подлежащего построению. Если максимальный SN для TCP ACK, возвращенный получателем и записанный на блоке принятия решения 605, больше или равен SN ACK, подлежащего построению, это говорит о том, что устройство передачи данных приняло TCP ACK, возвращенное получателем, и что ACK больше не нужно строить; если максимальный SN для TCP ACK, возвращенный получателем и записанный на блоке принятия решения 605, меньше SN ACK, подлежащего построению, это говорит о том, что устройство передачи данных не приняло ни одного TCP ACK, возвращенного получателем, и что ACK нужно построить.

Блок построения 606 выполнен с возможностью построения ACK и передачи его отправителю, если блок принятия решения 605 определяет, что ACK нужно строить.

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

SN построенного ACK равен длине пакета плюс SN TCP-пакета. Например, SN первого пакета данных равен 1, длина пакета первого пакета данных равна 1460, и поэтому SN построенного ACK равен 1461; SN второго пакета данных равен 1461, длина пакета второго пакета данных равна 1460, и поэтому SN построенного ACK равен 2921, и т.д. SN построенного ACK можно записывать на устройстве передачи данных.

Если устройство передачи данных принимает TCP ACK, возвращенное получателем, устройство передачи данных может решать, построил ли блок построения 606 соответствующее ACK и послал ли его отправителю, и пересылать TCP ACK отправителю, если ни одного такого ACK не было построено, или игнорировать TCP ACK, возвращенное получателем, если такое ACK было построено. Устройство передачи данных может дополнительно включать в себя блок сравнения 607. Блок сравнения 607 выполнен с возможностью сравнения SN для TCP ACK, возвращенного получателем, с SN построенного ACK, записанным на устройстве передачи данных.

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

Другое устройство передачи данных предусмотрено согласно варианту осуществления настоящего изобретения. Согласно фиг. 7 устройство может включать в себя второй блок приема 701, второй блок передачи 702, блок получения 703 и второй блок построения 704.

Второй блок приема 701 выполнен с возможностью приема пакета данных, переданного отправителем.

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

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

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

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

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

Если протокольный уровень принял информацию подтверждения пакета данных от получателя, но устройство передачи данных не приняло никакого ACK от получателя в ответ на пакет данных, можно определить, что получатель верно принял пакет данных, переданный отправителем, соответствующую информацию о пакете данных можно получить согласно информации подтверждения, принятой протокольным уровнем, и второй блок построения 704 может строить ACK и передавать его отправителю согласно информации подтверждения, принятой протокольным уровнем, и второй блок построения 704 может строить ACK и передавать его отправителю согласно информации о пакете данных. ACK можно строить согласно информации о пакете данных, полученной блоком получения 703. Если пакет данных является TCP-пакетом, SN построенного ACK равен SN плюс длина пакета для TCP-пакета. Для других типов пакетов данных ACK можно строить иначе.

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

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

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

Согласно другому варианту осуществления настоящего изобретения предусмотрено другое устройство передачи данных. Согласно фиг. 8 устройство может включать в себя второй блок приема 801, второй блок передачи 802, блок получения 803, второй блок принятия решения 805, второй блок построения 804 и второй блок сравнения 806.

Второй блок приема 801 выполнен с возможностью приема пакета данных, переданного отправителем.

Функции и процесс реализации второго блока приема 801 в основном такие же, как для второго блока приема 701 в предыдущем варианте осуществления, описанном выше.

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

Функции и процесс реализации второго блока передачи 802 в основном такие же, как для второго блока передачи 702 в предыдущем варианте осуществления, описанном выше.

Блок получения 803 выполнен с возможностью получения SN пакета данных согласно информации подтверждения пакета данных, и может быть дополнительно выполнен с возможностью получения длины пакета и TCP SN TCP-пакета согласно SN пакета данных.

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

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

Информация о пакете данных может включать в себя SN пакета данных. Таким образом, SN пакета данных можно получить согласно информации подтверждения. Если пакет данных является TCP-пакетом, длину пакета и SN TCP-пакета можно получить согласно SN пакета данных. SN ACK, подлежащего построению, можно получить согласно информации о пакете данных. Например, для TCP-пакета, если SN первого пакета данных равен 1, и длина пакета первого пакета данных равна 1460, SN ACK, подлежащего построению, равен 1461; SN второго пакета данных равен 1461, и SN ACK, подлежащего построению, равен 2921, и т.д. Для других типов пакетов данных ACK можно строить иначе.

Второй блок принятия решения 805 может решать, необходимо ли строить ACK, сравнивая SN для TCP ACK, возвращенный получателем, с SN ACK, подлежащего построению. Второй блок принятия решения 805 может записывать, по меньшей мере, один SN для TCP ACK, возвращенный терминалом. Второй блок принятия решения 805 может сравнивать максимальный SN для TCP ACK, возвращенный получателем, с SN ACK, подлежащего построению. Если максимальный SN для TCP ACK, возвращенный получателем, больше или равен SN ACK, подлежащего построению, это говорит о том, что устройство передачи данных приняло TCP ACK, возвращенное получателем, и что ACK больше не нужно строить; если максимальный SN для TCP ACK, возвращенный получателем, меньше SN ACK, подлежащего построению, это говорит о том, что устройство передачи данных не приняло ни одного TCP ACK, возвращенного получателем, и что ACK нужно построить.

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

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

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

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

Согласно другому варианту осуществления настоящего изобретения предусмотрен промежуточный NE. Согласно фиг. 9 промежуточный NE может включать в себя протокольный уровень 901 и устройство передачи данных 902. Протокольный уровень 901 может представлять собой любой протокольный уровень промежуточного NE при условии, что между протокольным уровнем и получателем существует механизм подтверждения. Согласно механизму подтверждения получатель возвращает информацию подтверждения на протокольный уровень после приема пакета данных. Устройство передачи данных 902 может представлять собой устройство, описанное согласно варианту осуществления, соответствующему фиг. 5 или фиг. 6. Протокольный уровень 901 и устройство передачи данных 902 совместно используют отображение пакета данных. В отношении способа генерации отображения пакета данных см. соответствующее вышеприведенное описание вариантов осуществления способа. После того как протокольный уровень 901 принимает информацию подтверждения от получателя, устройство передачи данных 902 может строить ACK и передавать его отправителю; или решать, необходимо ли строить ACK, и затем строить ACK и передавать его отправителю. Детали, касающиеся способа принятия решения, см. соответствующее вышеприведенное описание вариантов осуществления способа. Также необходимо определять, нужно ли пересылать отправителю ACK, отправленное получателем на устройство передачи данных 902. В отношении способа принятия решения см. соответствующее вышеприведенное описание вариантов осуществления способа.

Заметим, что вышеописанный промежуточный NE может представлять собой контроллер радиосети (RNC). В этом случае устройство передачи данных 902 может быть TCP-прокси, и протокольный уровень 901 может быть уровнем RLC.

Согласно вышеописанному варианту осуществления протокольный уровень 901 и устройство передачи данных 902 располагаются на одном и том же промежуточном NE. Легко понять, что устройство передачи данных 902 и протокольный уровень 901 могут располагаться на разных промежуточных NE при условии, что устройство передачи данных 902 может строить ACK согласно отображению пакетов данных между ними.

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

Согласно другому варианту осуществления настоящего изобретения предусмотрен промежуточный NE. Согласно фиг. 10 промежуточный NE может включать в себя протокольный уровень 1001 и устройство передачи данных 1002. Устройство передачи данных 1002 может представлять собой устройство, описанное согласно варианту осуществления, соответствующему фиг. 7 или фиг. 8. Протокольный уровень 1001 может представлять собой любой протокольный уровень промежуточного NE при условии, что между протокольным уровнем и получателем существует механизм подтверждения. Согласно механизму подтверждения получатель возвращает информацию подтверждения на протокольный уровень 1001 после приема пакета данных.

После того как протокольный уровень 1001 принимает информацию подтверждения, возвращенную получателем, устройство передачи данных 1002 получает информацию о пакете данных согласно информации подтверждения и строит ACK, адресованное отправителю, согласно информации о пакете данных. Устройство передачи данных 1002 может строить ACK и передавать его отправителю; или решать, нужно ли строить ACK, и затем, при необходимости, строить ACK и передавать его отправителю. Что касается деталей способа принятия решения, см. соответствующее вышеприведенное описание вариантов осуществления способа. Можно также принимать решение, нужно ли пересылать отправителю ACK, отправленное получателем, на устройство передачи данных 1002.

Заметим, что вышеописанный промежуточный NE может представлять собой RNC. В этом случае устройство передачи данных 1002 может быть TCP-прокси, и протокольный уровень 1001 может быть уровнем RLC.

Согласно вышеописанному варианту осуществления устройство передачи данных 1002 и протокольный уровень 1001 располагаются на одном и том же промежуточном NE. Легко понять, что устройство передачи данных 1002 и протокольный уровень 1001 могут располагаться на разных промежуточных NE.

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

Описанные здесь этапы способа или алгоритма можно реализовать аппаратными средствами или посредством программного модуля, выполняемого процессором, или обоими средствами. Программный модуль может располагаться в оперативной памяти (ОЗУ), компьютерной памяти, постоянной памяти (ПЗУ), электрически программируемом ПЗУ, электрически стираемом программируемом ПЗУ, в регистре, на жестком диске, сменном диске, незаписываемом компакт-диске (CD-ROM) или на носителе любого другого типа, известном в технике.

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

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

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

3. Способ передачи данных по п.1, в котором на этапе получения объектом расширения функции TCP информации о соответствующем пакете данных согласно информации подтверждения получают объектом расширения функции TCP порядковый номер (SN) соответствующего пакета данных, согласно информации подтверждения.

4. Способ передачи данных по п.3, в котором,
если пакет данных является пакетом протокола управления передачей (TCP), то на этапе получения объектом расширения функции TCP информации о соответствующем пакете данных, согласно информации подтверждения, дополнительно получают объектом расширения функции TCP длину пакета и TCP SN TCP-пакета, согласно SN соответствующего пакета данных.

5. Способ передачи данных по п.2, в котором на этапе записи объектом расширения функции TCP информации о принятом пакете данных записывают объектом расширения функции TCP порядковый номер (SN) принятого пакета данных, согласно порядку приема пакета данных.

6. Способ передачи данных по п.5, в котором пакет данных является TCP-пакетом, на этапе записи информации о принятом пакете дополнительно записывают объектом расширения функции TCP длину пакета и TCP SN TCP-пакета.

7. Способ передачи данных по п.4 или 6, в котором пакет данных является TCP-пакетом, на этапе формирования ACK формируют, объектом расширения функции TCP, ACK согласно длине пакета и TCP SN для TCP-пакета, причем SN сформированного ACK равен длине пакета плюс TCP SN.

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

9. Способ передачи данных по п.7, дополнительно содержащий этапы, на которых
сравнивают, объектом расширения функции TCP, SN для TCP ACK, возвращенного получателем, с максимальным SN сформированного ACK при приеме TCP ACK, возвращенного получателем, и
если SN для TCP ACK, возвращенного получателем, больше максимального SN для сформированного ACK, то посылают, объектом расширения функции TCP, TCP ACK, принятое от получателя, к отправителю; если SN для TCP ACK, возвращенного получателем, меньше или равен максимальному SN для сформированного ACK, то игнорируют, объектом расширения функции TCP, TCP ACK, принятое от получателя.

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

11. Объект расширения функции TCP по п.10, в котором блок приема дополнительно конфигурирован для записи информации о принятом пакете данных;
информация о пакете данных, записанная блоком приема, содержит порядковый номер (SN), указывающий порядок, в котором пакет данных принят объектом расширения функции TCP; если пакет данных является пакетом протокола управления передачей (TCP-пакетом), информация о пакете данных дополнительно содержит длину пакета и TCP SN,
блок формирования формирует ACK согласно длине пакета и TCP SN TCP-пакета, причем SN ACK равен длине пакета плюс TCP SN.

12. Объект расширения функции TCP по п.11, дополнительно содержащий
блок принятия решения, конфигурированный для принятия решения, необходимо ли формировать ACK, согласно информации о пакете данных, полученной блоком поиска, причем блок принятия решения решает, необходимо ли формировать ACK, путем
сравнения SN для ACK, являющегося результатом длины пакета плюс TCP SN соответствующего пакета данных, с максимальным SN для TCP ACK, возвращенного получателем, и
если максимальный SN для TCP ACK, возвращенного получателем, меньше SN для ACK, то формирования ACK, адресованного отправителю.

13. Объект расширения функции TCP по п.11 или 12, дополнительно содержащий
блок сравнения, конфигурированный для сравнения SN для TCP ACK, возвращенного получателем, с SN для ACK, сформированного блоком формирования, причем,
если SN для TCP ACK, возвращенного получателем, больше максимального SN сформированного ACK, то TCP ACK, принятое от получателя, передается отправителю, если SN для TCP ACK, возвращенного получателем, меньше или равен максимальному SN сформированного ACK, то TCP ACK, принятое от получателя, игнорируется.

14. Промежуточный сетевой элемент, конфигурированный для передачи данных между отправителем и получателем, причем промежуточный сетевой элемент (NE) содержит уровень управления радиоканалом и объект расширения функции TCP по любому из пп.10-13,
между уровнем управления радиоканалом и получателем существует механизм подтверждения; получатель возвращает информацию подтверждения на уровень управления радиоканалом после приема пакета данных; и
отображение пакета данных совместно используется между уровнем управления радиоканалом и объектом расширения функции TCP; после того, как уровень управления радиоканалом принимает информацию подтверждения, возвращенную получателем, объект расширения функции TCP формирует квитирование (ACK) и посылает ACK отправителю, согласно отображению пакетов данных.