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

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

Иллюстрации

Показать все

Изобретение относится к мобильной связи, а именно к способу и устройству передачи данных. Техническим результатом является повышение производительности передачи данных по нисходящей линии связи. Технический результат достигается тем, что способ передачи данных содержит этапы, на которых принимают объектом расширения функции (ОРФ) протокола управления передачей (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, возвращенный терминалом.

Устройство передачи данных предусмотрено согласно варианту осуществления настоящего изобретения. Согласно фиг. 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 в основном такие же, как

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

Патент 2474059