Патент на изобретение №2316906

(54) СПОСОБ ПЕРЕДАЧИ ПАКЕТНЫХ ДАННЫХ В СИСТЕМЕ СВЯЗИ

(57) Реферат:

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

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Поскольку технология мобильной связи продолжает развиваться, ожидается, что аппараты беспроводной связи станут более широко использоваться, чем обычные телефонные аппараты проводной связи. Однако аппараты проводной связи продолжают оставаться единственным средством при выборе терминалов для некоторых случаев применения. Например, технология мобильной радиосвязи значительно уступает существующим системам проводной связи по пропускной способности, когда речь идет о передаче больших объемов данных и голосовом графике между терминалами. Для решения этой проблемы было предложено несколько стандартов беспроводной связи. Один из таких стандартов, называемый IMT-2000 (Международная система мобильной связи-2000, примеч. перевод.), позволяет передавать большие объемы данных между терминалами, поэтому он быстро распространился во многих странах. Фактически, в настоящее время международное сотрудничество находится на пути к разработке для этой технологии единого стандарта.

Недавно это сотрудничество вылилось в инициативу, известную как Проект партнерства по разработке сетей третьего поколения (3GPP). Инициатива 3GPP была учреждена с целью стандартизации, помимо прочего, системы IMT-2000 третьего поколения, основанной на базе связи, принятой в Европе. В стандарт, известный как универсальная система подвижной связи (UMTS), внесли вклад многие национальные, международные и местные организации по стандартизации, в частности ТТА в Южной Коре, CWTS в Китае, Т1 в США и ARIB/TTC в Японии.

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

Проект 3GPP включает в себя пять групп по разработке технических условий (далее – группа TSG), каждая из которых занимается разработкой, утверждением и ведением стандартов в соответствующей области.

Группа, занимающаяся сетями радиодоступа (RAN) (далее группа – TSG-RAN) руководит разработкой функциональных требований и стандартов, необходимых для согласования беспроводных терминалов и сети наземного радиодоступа универсальной системы подвижной связи (далее – сеть UTRAN). Группа базовой сети (CN) (далее – группа TSG-CN) руководит разработкой функций базовой сети, а также требований и стандартов к интерфейсу, позволяющему сети UTRAN осуществлять доступ в базовую сеть с коммутацией каналов или базовую сеть с пакетной коммутацией.

Полный заголовок играет чрезвычайно важную роль в методе сжатия заголовка в известной базовой сети с пакетной коммутацией. Если полный заголовок не передан правильно, каждый пакет, принятый после него, не может быть развернут и не учитывается. Для решения этой проблемы при использовании протокола non-TCP, такого, как протокол UDP/IP (протокол дейтаграмм пользователя/Интернет-протокол – прим. перев.), в известной системе от передающей стороны требуется передавать пакет с полным заголовком, который может использоваться несколько раз для формирования контекста для принимающей стороны в пределах одного и того же потока данных в соответствии с определенными правилами.

В методе сжатия по протоколу non-TCP со сжатием заголовка, т.е. методе сжатия заголовка, используемом для протокола UDP/IP, пакет с полным заголовком передают, по меньшей мере, один раз в каждом экспоненциально увеличивающемся периоде, что называется сжатием с медленным стартом (CSS). В соответствии с алгоритмом медленного старта, если полная заголовочная информация изменяется или применяется иной метод сжатия заголовка, интервал передачи для одного и того же полного заголовка сокращается на начальной стадии и затем постепенно увеличивается.

На фиг.1 представлена схема, показывающая интервалы передачи при передаче полной заголовочной информации в соответствии со способом сжатия с медленным стартом. Как показано на схеме, интервалы передачи пакета с полным заголовком увеличиваются экспоненциально, а число пакетов со сжатым заголовком, передаваемых между соседними пакетами с полным заголовком (т.е. внутри каждого интервала) увеличивается в 1, 2, 4, 8,…раз. Интервал передачи не возрастает бесконечно, но сохраняется одним и тем же, когда достигает своего порогового значения, которое обычно устанавливается равным 256. Для справки, полные заголовки, передаваемые с помощью способа сжатия с медленным стартом, имеют одно и то же значение идентификатора контекста (CID) и номера поколения. То есть, пакет с полным заголовком передается в экспоненциально возрастающем периоде для потока пакетов с одним и тем же значением идентификатора контекста (CID) и номером поколения.

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

На фиг.2 представлена блок-схема известной системы пакетной передачи, в которой используется метод сжатия заголовка. Данная система включает в себя блок сжатия заголовка 10, обеспечиваемый на уровне протокола сходимости пакетных данных (PDCP) и сжимающий заголовок данных, принятых с верхнего уровня под управлением блока управления сжатием заголовка 12. Пакет с полным заголовком или пакет со сжатым заголовком, преобразованный блоком сжатия заголовка 10, передают на уровень протокола управления радиоканалом (RLC) через блок передачи данных 14. Блок передачи 16 уровня протокола управления радиоканалом (RLC), снабженный буфером, сохраняет пакет с полным заголовком или пакет со сжатым заголовком, полученный от блока передачи данных 14 протокола сходимости пакетных данных (PDCP), и/или передает его принимающей стороне.

Работа системы будет объяснена далее. Сначала, в случае использования протокола TCP со сжатием заголовка (TCP – транспортный протокол управления, примеч. перевод.) в качестве метода сжатия заголовка, передающая сторона ранее передает пакет с полным заголовком для потока пакетов, чтобы сформировать контекст на принимающей стороне. Затем передают один или более сжатых заголовков, в которых указаны различия между последующими пакетами.

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

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

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

На фиг.4 показана структура сжатого заголовка, используемого в протоколе UDP/IP. Как уже ранее обсуждалось, при осуществлении сжатия заголовка согласно протоколу UDP/IP для выделения потоков пакетов используется параметр поколения соответствующей заголовочной информации, а также значение идентификатора контекста (CID). Таким образом, сжатый заголовок содержит только поле идентификатора контекста (CID), поле поколения и поле контрольной суммы, а в результате имеет общую величину около 4-5 октетов.

В сжатом заголовке на фиг.4, если используется 8-битовый идентификатор контекста, нет необходимости в идентификаторе контекста CID(2), размещаемом в третьем октете. Если используется 16-битовый идентификатор контекста, то 8 битов выделяются для идентификатора контекста CID(l), а другие 8 битов – для идентификатора контекста CID(2). Принимая во внимание, что размер полного заголовка составляет 48 октетов, следует заметить, что такая же цель может быть достигнута путем передачи очень малого объема данных.

При передаче пакетных данных с использованием метода сжатия заголовка по протоколу TCP со сжатием заголовка, вытекающим из алгоритма сжатия заголовка по протоколу TCP/IP (RFC 2507 Compressed TCP), пакет с полным заголовком передают в первом пакете потока пакетов. Последующие пакеты передают со сжатым заголовком, содержащим лишь отличия от ранее переданных заголовков потока пакетов. Контекст потока пакетов постоянно обновляют относительно ранее принятых заголовков пакетов.

При передаче пакетных данных с использованием другого метода сжатия заголовка по протоколу TCP со сжатием заголовка, вытекающим из алгоритма сжатия заголовка по протоколу TCP/IP (RFC 2507 Compressed TCP nondelta), пакет с полным заголовком передают в первом пакете потока пакетов. Последующие пакеты передают со сжатым заголовком, содержащим лишь отличия от ранее переданных заголовков потока пакетов. Контекст потока пакетов постоянно обновляют относительно ранее принятого полного заголовка.

При передаче пакетных данных с использованием алгоритма сжатия заголовка по протоколу UDP/IP [протокол non-TCP со сжатием заголовка, Compression Slow Start (сжатие с медленным стартом, примеч. перевод.), далее обозначенное как CSS], пакеты с полным заголовком передают в первом пакете, а некоторые из последующих пакетов потока пакетов – в соответствии с заданным правилом. На фиг.5 показана последовательность действий известного способа передачи пакета с полным заголовком и пакета со сжатым заголовком в соответствии со способом CSS. На этой фигуре значение INT (значение интервала) показывает число пакетов со сжатым заголовком, которые могут быть переданы между двумя последовательно передаваемыми пакетами с полным заголовком, а значение CNT (значение счетчика) показывает число переданных пакетов со сжатым заголовком.

В соответствии с этим способом передают пакет со сжатым заголовком, а когда значения CNT и INT становятся одинаковыми, передают пакет с полным заголовком вместо пакета со сжатым заголовком. Значение INT обновляется в то время, когда должен передаваться полный заголовок. Когда значение INT достигает величины MaxINT, соответствующей пороговому значению интервала передачи, оно больше не возрастает, и сохраняется значение MaxINT. Процесс заканчивается, когда все данные в потоке пакетов переданы, или когда данные полного заголовка изменились. Теперь будет более подробно описан способ передачи.

Сначала минимальное число (INT) пакетов со сжатым заголовком, которые могут быть переданы между пакетами с полным заголовком, устанавливают на начальное значение, равное «1».

Когда начинается операция передачи пакета с заголовком, сначала передают пакет с полным заголовком (S80), а затем CNT, показывающий число переданных пакетов со сжатым заголовком, устанавливают на «0» (CNT=0) (881). Затем передают пакет со сжатым заголовком (S82) и затем – CNT, показывающий число переданных пакетов со сжатым заголовком, увеличивают на «1» (CNT=CNT+1) (883).

Далее значения INT и CNT сравнивают между собой (S84) и, если эти два значения отличаются, дополнительно передают пакет со сжатым заголовком, и повторно выполняют операции S82-S84. Если эти два значения одинаковы, проверяют, является ли значение INT больше чем MaxINT (в настоящем изобретении MaxINT=256) (S85). Если значение INT меньше MaxINT, выполняют повторно операции S80-S85 при увеличении значения INT с умножением на «2» (1, 2, 4, 8, 16,…, 256). Если, однако, значение INT равно или больше значения MaxINT, значение INT больше не увеличивают и сохраняют тот же интервал передачи.

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

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

Метод сжатия заголовка по протоколу TCP со сжатием заголовка, вытекающий из известного алгоритма сжатия заголовка по протоколу TCP/IP, также имеет ряд недостатков. Например, контекст пакета со сжатым заголовком восстанавливают на основе прямого или косвенного сравнения с полным заголовком. Если один из заголовков пакета в потоке не принят успешно или не принят успешно полный заголовок, несколько пакетов, следующих за этим пакетом, не могут быть восстановлены в данное время. То есть, в случае передачи пакетных данных с использованием метода сжатия заголовка по протоколу TCP со сжатием заголовка, когда пакет с полным заголовком или пакет со сжатым заголовком потерян, много времени у принимающей стороны занимает восстановление соответствующего контекста. Кроме того, передающая сторона не знает, что соответствующий контекст поврежден. Следовательно, последующие пакеты со сжатым заголовком передаются бесполезно, что ведет к бесполезному расходованию радиоресурсов. Если приемное устройство передает запрос на посылку пакета с полным заголовком передающему устройству немедленно, нагрузка на поток сообщений при запросе может быть чрезмерной для радиоканала.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В способе передачи пакетных данных согласно настоящему изобретению предпочтительно, когда уровень PDCP передает блок протокольных данных (PDU) уровня PDCP на уровень RLC, уровень PDCP выдает команду на уровень RLC проинформировать уровень PDCP о результате ошибки передачи на соответствующий блок протокольных данных.

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

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

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

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

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

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

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

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

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

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

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

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

В способе передачи пакетных данных согласно настоящему изобретению предпочтительно, когда уровень PDCP передает блок протокольных данных уровня PDCP на уровень RLC, уровень PDCP выдает команду на уровень RLC информировать уровень PDCP о результатах ошибки передачи на соответствующий блок протокольных данных (PDU).

В способе передачи пакетных данных согласно настоящему изобретению предпочтительно, когда уровень PDCP передает блок протокольных данных уровня PDCP на уровень RLC, уровень PDCP передает индикатор отчета по ошибке передачи вместе с соответствующим блоком протокольных данных (PDU).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

на фиг.4 представлена схема, иллюстрирующая структуру сжатого заголовка, используемого в протоколе UDP/IP;

на фиг.5 представлена последовательность действий способа передачи пакетов с полным заголовком и сжатым заголовком с использованием известного способа CSS;

на фиг.6 представлен чертеж, иллюстрирующий структуру сети в пакетном домене из числа сетевых структур, рекомендованных 3GPP;

на фиг.7 представлен чертеж, иллюстрирующий структуру протокола радиоинтерфейса между терминалом и сетью UTRAN (сетью наземного радиодоступа универсальной системы подвижной связи – примеч. перевод.) на основе сетевого стандарта радиодоступа 3GPP;

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

на фиг.9 представлен чертеж, иллюстрирующий структуру обычного заголовка, передаваемого при использовании протокола TCP/IPv6;

на фиг.10А представлен чертеж, иллюстрирующий структуру полного заголовка, передаваемого при использовании способа сжатия заголовка для протокола TCP/IPv6;

на фиг.10В и 10С показан формат протокола TCP со сжатием заголовка и формат протокола TCP nondelta со сжатием заголовка соответственно;

на фиг.11 представлен чертеж, иллюстрирующий структуру обычного заголовка, передаваемого при использовании протокола UDP/IPv6;

на фиг.12А представлен чертеж, иллюстрирующий структуру полного заголовка, передаваемого при использовании способа сжатия заголовка для протокола TCP/IPv6;

на фиг.12В и 12С показан формат протокола non-TCP со сжатием заголовка с 8-битовым идентификатором контекста (CID) и формат протокола non-TCP со сжатием заголовка с 16-битовым идентификатором контекста (СШ) соответственно;

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

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

на фиг.13С представлен чертеж, иллюстрирующий параметры, передаваемые между уровнем протокола PDCP и уровнем протокола RLC для выполнения команд отчета;

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

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

ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ПРИМЕРОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

На фиг.6 представлен чертеж, показывающий сетевую структуру домена с коммутацией пакетов, предложенного группой TSG-RAN и группой TSG-CN. В данной структуре сеть UTRAN содержит множество подсистем радиосети (RNS), каждая из которых включает в себя множество узлов В, соединенных с одним контроллером радиосети (RNC).

Базовая сеть (CN) имеет различную структуру в соответствии с принятым режимом коммутации (сеть с коммутацией пакетов или сеть с коммутацией каналов). В случае, когда в настоящем изобретении рассматривается сеть с коммутацией пакетов, базовая сеть предпочтительно включает в себя множество узлов обеспечения услуг GPRS (пакетной коммутации в сетях подвижной радиосвязи – примеч. перевод.) (далее – узлы SGSN) и один узел поддержки шлюза GPRS (далее – узел GGSN).

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

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

Маршрутная информация узлов SGSN, передаваемая из сети UTRAN в базовую сеть, и узел GGSN играют роль шлюза для пересылки информации из сети UTRAN в различные базовые сети, если пунктом назначения информации является сеть, отличная от текущей базовой сети.

Интерфейсы данных каждой части имеют различные обозначения, определяемые следующим образом. Интерфейс между абонентским оборудованием и узлами В обозначается как «Uu», интерфейс между узлами В и связанным с ними контроллером радиосети обозначается как «Iub», интерфейс между контроллерами радиосети обозначается как «Iur», интерфейс между контроллерами радиосети и узлами SGSN обозначается как «Iu», а интерфейс между узлами SGSN и узлом GGSN или между узлами SGSN обозначается как «Gn».

Общедоступная сеть с коммутацией пакетов (PDN) является основной сетью домена с коммутацией пакетов, поддерживающего соединение между различными сетями в области пакетных услуг. На фиг.6 показан пример структуры сети, в которой, в зависимости от выбора, может существовать интерфейс «Iur» между контроллерами радиосети другого узла SGSN. Кроме того, как вариант, может существовать интерфейс «Gn» между узлами SGSN.

Как видно из фиг.7 и фиг 8, сеть на фиг.6 имеет иерархическую структуру. На фиг.7 подробно показана иерархическая структура сети UTRAN или абонентского оборудования для поддержки интерфейса «Uu», являющегося радиоинтерфейсом. На этой фигуре плоскость пользователя (U-плоскость) представляет собой область, в которую передается информация о трафике пользователя, например о речевых сигналах или IP-пакете, а плоскость управления (С-плоскость) является областью, в которую передается управляющая информация, например, по техническому обслуживанию или управлению интерфейсом или вызовом.

U-плоскость включает в себя физический уровень (L1), являющийся первым уровнем, уровень протоколов сходимости пакетных данных (далее – уровень PDCP), уровень управления радиоканалом (далее – уровень RLC), уровень управления доступом к среде (далее – уровень MAC), а также уровень широковещательной/многоадресной рассылки (далее – уровень ВМС), являющийся вторым уровнем (уровнем канала передачи данных) из 7 уровней, определенных в рамках модели OSI (стандартной модели взаимодействия открытых систем).

С-плоскость включает в себя уровень управления радиоресурсами (далее – уровень RRC), уровень RLC, уровень MAC и уровень L1.

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

Уровень MAC обеспечивает услугу по перераспределению параметра MAC для распределения и перераспределения радиоресурса. Уровень MAC соединен с уровнем RLC через логический канал, а в соответствии с видом передаваемой информации предусмотрены различные логические каналы. В основном, при передаче информации в С-плоскости используется канал управления, а при передаче информации в U-плоскости используется канал трафика.

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

Размер блоков служебных данных уровня RLC регулируется на уровне RLC. Затем присоединяются заголовки, чтобы преобразовать блоки служебных данных в блоки протокольных данных для передачи на уровень MAC. Уровень RLC работает в трех режимах: прозрачном режиме, режиме без подтверждения и режиме с подтверждением, в соответствии со способом обработки блоков служебных данных уровня RLC. Буфер уровня RLC включен в уровень RLC для хранения блоков служебных данных уровня RLC или блоков протокольных данных уровня RLC.

Уровень PDCP является верхним уровнем уровня RLC, он позволяет эффективно передавать на уровень RLC данные, передаваемые по сетевому протоколу IP, например IPv4 или IPv6. Кроме того, уровень PDCP также уменьшает объем информации заголовка, которая не является необходимой для беспроводной сети, но может использоваться для проводных сетей, благодаря чему обеспечивается эффективность передачи данных. Данная функция, называемая сжатием заголовка, может использоваться для уменьшения объема используемой информации заголовка, например, в связи по протоколу TCP/IP. В иллюстративных целях уровень PDCP и уровень ВМС показаны расположенными на плоскости пользователя, поскольку они передают только данные пользователя.

Уровень RLC может принадлежать плоскости пользователя или плоскости управления, в соответствии с уровнем, подключенным к его верхней стороне. То есть, когда уровень RLC принимает данные от уровня RRC, он принадлежит плоскости управления, в других же случаях уровень RLC принадлежит плоскости пользователя. В общем, услуга по передаче данных пользователя, поставляемых с плоскости пользователя на верхний уровень уровнем L2, определяется как однонаправленный радиоканал (RB), а услуга по передаче управляющей информации, поставляемой уровнем L2 с плоскости управления на верхний уровень, определяется как однонаправленный радиоканал сигнализации (SRB).

Как дополнительно показано на фиг.7, и уровень RLC, и уровень PDCP могут включать в себя множество объектов. Это объясняется тем, что одно абонентское оборудование может иметь несколько однонаправленных радиоканалов, и, в общем случае, один объект уровня RLC и один объект уровня PDCP используются для одного однонаправленного радиоканала. Объекты уровня RLC и уровня PDCP на каждом уровне могут выполнять независимые функции.

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

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

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

Услуги, предоставляемые для абонентского оборудования, можно, в общем, разделить на услуги с коммутацией каналов и услуги с коммутацией пакетов. Услуга речевого вызова включена, например, в услугу с коммутацией каналов, а услуга Web-браузера через подключение к Интернету может быть включена в услугу с коммутацией пакетов. Услуга с коммутацией каналов подключена к сети UTRAN через центр коммутации подвижной связи (MSC) базовой сети, а услуга с коммутацией пакетов обеспечивается через узел SGSN базовой сети. Таким образом, точки доступа в базовую сеть, к которой подключена сеть UTRAN, отличаются в зависимости от типа обеспечиваемой услуги.

На фиг.8 приведена схема, показывающая пример структуры протоколов плоскости пользователя, которая может использоваться для обеспечения услуг с коммутацией пакетов в сети UMTS. Здесь узел SGSN поддерживает услугу с коммутацией пакетов, направляемую в сеть UTRAN, и обрабатывает функции управления мобильностью, например обновление области маршрутизации, регистрация информации о местоположении или вызов, и управления, связанного с безопасностью. Узел GGSN поддерживает подключение к различным сетям с коммутацией пакетов, например к сети Интернет. Теперь будет описан процесс передачи услуги с коммутацией пакетов от внешней сети с коммутацией пакетов к терминалу.

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

В то же время, протокол GTP-U (протокол туннелирования GPRS для плоскости пользователя), используемый для передачи IP-пакета капсулирует данные пользователя между сетью UTRAN и узлом SGSN или между узлом SGSN и узлом GGSN и туннелирует их. То есть, протокол GTP-U принимает пакет данных пользователя из внешней пакетной сети, определяет адрес назначения пакета и передает его в следующий пункт назначения согласно установленному пути.

Дейтаграммный протокол пользователя (протокол UDPyiP-протокол, широко используемый для пакетной передачи в проводной сети) расположен на нижнем уровне протокола GTP-U и поддерживает GTP-U-пакеты.

IP-пакет, передаваемый в контроллер радиосети UTRAN по протоколу GTP-U, передается на уровень PDCP, который уменьшает размер заголовка с помощью способа сжатия заголовка и передает результат на уровень RLC в форме блока протокольных данных уровня PDCP (=блоку служебных данных уровня RLC).

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

В абонентском оборудовании (или терминале) блок протокольных данных уровня PDCP передается через уровни MAC и RLC на уровень PDCP, и уровень PDCP абонентского оборудования восстанавливает информацию сжатого заголовка с целью получения первоначального IP-заголовка. Затем результирующий IP-пакет передается на IP-уровень.

Теперь будет описан способ сжатия заголовка, используемый уровнем PDCP по отношению к абонентскому оборудованию и сети UTRAN. При передаче IP-пакета и особенно при передаче IP-пакета через радиоинтерфейс причина, по которой заголовок следует сжимать, заключается в том, что размер заголовка IP-пакета не такой маленький, чтобы им пренебречь по сравнению с размером полезной нагрузки пакета.

Например, когда абонентское оборудование принимает данные от IP-сети, информация заголовка IP добавляется к каждому пакету, чтобы обеспечить маршрутизацию пакета в IP-сети. В то же время в случае протокола IPv4 присоединяется информация заголовка размером 24 октета, а в случае протокола IPv6 присоединяется информация заголовка размером 40 октетов. Если уровень протокола TCP уровня протокола UDP расположен выше уровня протокола IP, необходима дополнительная информация заголовка размером 24 и 8 октетов. Таким образом, в случае передачи пакета с использованием протокола TCP/IPv6, необходима информация заголовка размером, по меньшей мере, 64 октета на пакет, а в случае передачи пакета с использованием протокола UDP/IPv6, необходима информация заголовка размером, по меньшей мере, 48 октетов на пакет. Следует заметить, что в случае услуги VoIP (передача речи по IP-протоколу), когда пакет передается с использованием протокола UDP/IPv6, информация заголовка размером 48 октетов существенно больше по сравнению с полезной нагрузкой, которая измеряется лишь несколькими октетами (например, 20 октетов в случае, когда информация заголовка сжимается при 8 кбит/сек кодеком G.729).

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

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

На фиг.9 показано поле заголовка протокола TCP/IPv6, чтобы можно было понять принцип, лежащий в основе, и степень сжатия по способу сжатия заголовка. Вначале следует заметить, что как уже описано выше по отношению к обсуждению потока пакетов, поскольку поля протокола IPv6 и номера портов заголовка протокола TCP принадлежат к одному и тому же потоку пакетов, они могут считаться постоянными. На фиг.9 поле версии указывает на использование заголовка протокола IPv6, а следующее поле (NH) заголовка показывает, что информация заголовка, поступающая после заголовка протокола IPv6, является заголовком протокола TCP. В результате оба они могут считаться одинаковыми по отношению к соответствующему потоку пакетов.

Поле класса трафика показывает приоритет соответствующего пакета, а поле метки потока (FL) управляет пакетом в соответствии с приоритетом. В то же время, если значение метки потока установлено на значение, отличное от «0», поле класса трафика перед полем метки потока не изменяется. С другой стороны, если значение метки потока установлено на «0», поле класса трафика может быть изменено. Однако, т.к. пакеты, имеющие другое значение поля класса трафика, могут быть определены как принадлежащие к другому потоку пакетов, значения поля класса трафика и поля метки потока считаются неизменными в отношении одного потока пакетов.

Поле предела интервалов (HL) уменьшается на «1» каждый раз, когда проходится маршрутизатор в сети. Если значение поля предела интервалов становится равно «0», соответствующий пакет не учитывается. В общем случае, поскольку пакеты передаются в сети по одному и тому же пути, значение поля предела интервалов для конкретного потока пакетов также считается почти постоянным.

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

Если передаются пакеты, принадлежащие одному и тому же потоку пакетов, поля заголовка, содержащие неизменяющуюся информацию, большей частью соответствуют заштрихованным полям фиг.9. Более того, следует отметить, что подробные описания способов сжатия заголовка дано в официальных технических документах, относящихся к технологии Интернета, представленной IETF (проблемной группой проектирования Интернет – примеч. перевод.). Например, уровень протокола PDCP может использовать способ сжатия заголовка на основе документов RFC 2507 и RFC 3095. Что касается способа сжатия заголовка RFC 2507, то могут использоваться различные способы сжатия в зависимости от того, является ли протокол, расположенный выше уровня протокола IP, протоколом TCP или Non-TCP. Если протокол, расположенный выше уровня протокола IP, не использует протокол TCP, например это протокол UDP/IP, может использоваться способ сжатия по протоколу Non-TCP. Если протокол, расположенный выше уровня протокола IP, является протоколом TCP, он делится на протокол TCP со сжатием заголовка и протокол TCP nondelta со сжатием заголовка в соответствии со способом передачи переменного поля заголовка. Метод по протоколу TCP со сжатием заголовка представляет собой способ передачи значения разности между последовательными пакетами, но не пересылки всего значения поля. Это осуществляется исходя из концепции, что между переменными значениями полей заголовка существует небольшая разница. С другой стороны, метод по протоколу TCP nondelta со сжатием заголовка – это способ передачи переменного поля заголовка, как он есть.

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

Теперь будет описан метод сжатия заголовка, используемый для сжатия заголовка с применением протокола TCP со сжатием заголовка или протокола TCP nondelta со сжатием заголовка, например, протокола TCP/IP. Ранее указывалось, что был предложен способ сжатия заголовка, в котором пакет с полным заголовком передается первым в потоке пакетов. В соответствии с этим способом, т.к. в сети может быть более одного потока пакетов, идентификатор, указывающий контекст для каждого потока пакетов, может использоваться для выделения этих потоков. Идентификатор этого типа называется идентификатором контекста (CID). Во многих, если не во всех случаях, значение идентификатора контекста (CID) для пакета протокола TCP имеет длину 8 битов, и когда передается сжатый или полный заголовок, значение идентификатора контекста (CID) также должно быть передано. Переданная информация полного заголовка хранится принимающей стороной в соответствии со значением идентификатора контекста (CID), а когда пакет приходит, принимающая сторона для восстановления первоначальной информации заголовка считывает информацию полного заголовка на основе значения идентификатора контекста (CID).

На фиг.10А показана структура полного заголовка, передаваемого при использовании способа сжатия заголовка для протокола TCP/IPv6. В то же время, полный заголовок является одинаковым для протокола TCP со сжатием заголовка и протокола TCP nondelta со сжатием заголовка. Поскольку первоначальное поле заголовка протокола TCP/IPv6 не содержит поле идентификатора контекста (CID), невозможно вставить значение идентификатора контекста (CID). Поэтому необходимо найти соответствующее поле, в которое можно вставить значение идентификатора контекста (CID). Поскольку информация о существующем поле «длина полезной нагрузки» – это информация, которая может быть известна из нижнего уровня, соответствующее поле нет необходимости использовать. Следовательно, идентификатор контекста (CID) можно вставить в поле «длина полезной нагрузки» и передать.

На фиг.10В и 10С представлены форматы соответственно протокола TCP со сжатием заголовка и протокола TCP nondelta со сжатием заголовка, в соответствии с предпочтительным примером осуществления настоящего изобретения. Сжатый заголовок, сформированный методом по протоколу TCP со сжатием заголовка и передаваемый с использованием протокола TCP/IPv6, формируется в соответствии с незаштрихованными участками заголовка на фиг.10А. В то же время, из полей сжатого заголовка поле идентификатора контекста (CID) имеет фиксированное значение, а поле контрольной суммы имеет переменное значение, остальные поля представляют значение разности с предыдущим сжатым заголовком. Размер сжатого заголовка обычно равен 4-7 октетов.

При использовании для протокола TCP/IPv6 метода по протоколу TCP nondelta со сжатием заголовка, сжатый заголовок формируется в соответствии с незаштрихованными участками заголовка на фиг.10А, которые являются теми же самыми, что и в методе по протоколу TCP со сжатием заголовка. В то же время, из полей сжатого заголовка поле идентификатора контекста (CID) имеет фиксированное значение, а остальные поля имеют переменные значения. Т.к. все поля, кроме идентификатора контекста (CID), имеют переменные значения и переменные значения обычно содержат больше битов, чем значения разности, размер заголовка в соответствии с методом по протоколу TCP nondelta со сжатием заголовка больше размера заголовка в соответствии с методом по протоколу TCP со сжатием заголовка. Размер сжатого заголовка обычно составляет 17 октетов.

Протокол, не использующий протокол TCP, например протокол UDP/IP, сжимает заголовок с использованием способа по протоколу non-TCP со сжатием заголовка, аналогичного случаю протокола TCP/IP. Как и в случае протокола TCP/IP, чтобы использовать метод сжатия заголовка для конкретного потока пакетов, необходим процесс передачи пакета с полным заголовком в качестве первого пакета, а также необходимо включение идентификатора контекста (CID) для идентификации каждого потока пакетов. Значение идентификатора контекста (CID), которое обычно имеет величину в 8 битов или 16 битов, должно передаваться вместе со сжатым заголовком или полным заголовком.

В способе сжатия заголовка протокола UDP/IP вдобавок к значению идентификатора контекста (CID) используется поле поколения, указывающее поколение информации заголовка. Поле поколения показывает, насколько устарела информация заголовка, и оно всегда передается вместе со значением идентификатора контекста (CID).

На фиг.12А показана структура полного заголовка, передаваемого в соответствии с способом сжатия заголовка, используемым для пакета протокола UDP/IPv6. Как показано на фигуре, поскольку обычное поле заголовка протокола UDP/IPv6 (фиг.11) не содержит поле идентификатора контекста (CID) или поле поколения, значения идентификатора контекста (CID) и поколения вставляют в существующее поле «длина полезной нагрузки» или поле «длина» и затем передают. В случае использования 8-битового идентификатора контекста (CID) можно использовать только идентификатор контекста CID(1). В случае использования 16-битового идентификатора контекста (CID) можно использовать только идентификатор контекста CID(2), а часть поля длины полезной нагрузки используется для значения поколения.

Фиг.12В и 12С иллюстрируют соответственно формат протокола non-TCP со сжатием заголовка 8-битового идентификатора контекста (CID) и формат протокола non-TCP со сжатием заголовка 16-битового идентификатора контекста (CID) в соответствии с предпочтительным примером осуществления настоящего изобретения. Сжатый заголовок, передаваемый с использованием метода сжатия заголовка для протокола UDP/IPv6, формируется в соответствии с незаштрихованными участками заголовка, показанными на фиг.12А. Размер данного заголовка обычно составляет 4-5 октетов. В то же время, из полей сжатого заголовка поле идентификатора контекста (CID) и поле поколения имеют фиксированное значение, тогда как поле контрольной суммы имеет переменное значение. Настоящее изобретение представляет собой систему и способ управления передачей пакетов в системе связи, которые обеспечивают более быструю и эффективную передачу, чем другие предложенные системы. Настоящее изобретение достигает такого улучшения пропускной способности благодаря использованию схемы сжатия заголовка пакета, которая задает передачу пакета с одним полным или сжатым заголовком в соответствии с отчетом нижнего уровня, предпочтительно – без какого-либо запроса принимающей стороны. Предпочтительно это осуществляется на уровне протокола PDCP, а нижним уровнем является уровень протокола RLC. В дополнение к обычному способу при этом обеспечивается присоединение полного заголовка к пакету, запускаемое отчетом протокола RLC об ошибке передачи предыдущего пакета, а одна из схем запуска присоединения полного заголовка к пакету в соответствии с известным способом, например способом CSS, исключается отчетом протокола RLC об успешной передаче предыдущего пакета с полным заголовком, благодаря чему повышается эффективность и скорость передачи данных.

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

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

Хотя настоящее изобретение может быть применено к различным системам связи, включая проводные и беспроводные системы, оно идеально подходит для использования в системе мобильной радиосвязи, таких как система UMTS, которая передает пакеты в соответствии с протоколом, включающим в себя уровень сжатия заголовка и уровень канала передачи данных. При работе уровень сжатия заголовка генерирует и отправляет пакеты со сжатым и полным заголовком на уровень канала передачи данных для их передачи. В предпочтительных примерах осуществления настоящего изобретения одной из новых отличительных особенностей является определение одного из полных или сжатых заголовков в соответствии с отчетом нижнего уровня и, предпочтительно, независимо от какого-либо запроса приемного устройства. Определение осуществляется на уровне протокола PDCP, а нижним уровнем является уровень протокола RLC передающего устройства.

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

Другими словами, при использовании формата протокола TCP со сжатием заголовка (включая протокол TCP nondelta со сжатием заголовка), даже если приемное устройство (что означает уровень протокола PDCP приемного устройства) не запросило передачу пакета с полным заголовком, если любой блок служебных данных протокола RLC (такой же, как и блок протокольных данных протокола PDCP) отвергнут (это означает, что передача прошла неудачно), уровень протокола PDCP в следующий раз посылает пакет с полным заголовком. На фиг.13А графически иллюстрируется данная особенность предпочтительного примера осуществления изобретения в отношении передачи пакета со сжатым и полным заголовком. Как показано на фигуре, если уровень протокола RLC (например, передающего устройства) сообщает, что передача пакета прошла неудачно, уровень протокола PDCP (например, передающего устройства) посылает пакет с полным заголовком после истечения заданного отчетного времени.

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

Другими словами, при использовании формата протокола non-TCP со сжатием заголовка (Compression Slow Start (сжатие с медленным стартом, примеч. перевод.)), даже если приемное устройство (это означает уровень протокола PDCP приемного устройства) не запросило передачу пакета со сжатым заголовком вместо передачи пакета с полным заголовком, если блок служебных данных протокола RLC (такой же, как и блок протокольных данных протокола PDCP) удален из буфера протокола RLC, не будучи отвергнут (это означает, что передача прошла удачно), уровень протокола PDCP в следующий раз посылает пакеты со сжатым заголовком. После этого даже если приемное устройство (это означает уровень протокола PDCP приемного устройства) не запросило передачу пакета с полным заголовком, если любой блок служебных данных протокола RLC (такой же, как и блок протокольных данных протокола PDCP) отвергнут (это означает, что передача прошла неудачно), уровень протокола PDCP в следующий раз посылает пакет с полным заголовком.

На фиг.13В графически проиллюстрирована эта особенность предпочтительного примера осуществления изобретения применительно к передаче пакета со сжатым и с полным заголовком при использовании формата протокола non-TCP со сжатием заголовка для способа CSS. Как показано на фигуре, если уровень протокола RLC (в данном случае передающего устройства) сообщает, что передача пакета с полным заголовком прошла успешно, уровень протокола PDCP (в данном случае передающего устройства) после приема отчета протокола RLC не посылает пакет с полным заголовком с заданными интервалами: 1, 2, 4, 8 и т.д. Однако если уровень протокола RLC сообщает, что передача заданного сжатого пакета прошла неудачно, уровень протокола PDCP посылает пакет с полным заголовком после приема отчета протокола RLC.

Фиг.13С иллюстрирует параметры, передаваемые между уровнем протокола PDCP и уровнем протокола RLC для выполнения команд отчета. Как здесь показано, уровень протокола PDCP передает на уровень протокола RLC пакет, идентификатор пакета и параметр DiscardReq, который показывает, должен или нет объект, передающий на уровне протокола RLC, информировать верхние уровни об отвергнутом блоке служебных данных протокола RLC. Если необходимо, объект, передающий на уровне протокола RLC, уведомляет верхние уровни, когда блок служебных данных отвергнут. Только при работе в режиме с подтверждением приема параметр Status показывает, передан ли блок служебных данных протокола RLC успешно или он был отвергнут.

Настоящее изобретение особенно хорошо подходит для использования в домене с коммутацией пакетов, предложенном группой TSG-RAN и группой TSG-CN. Теперь будут обсуждаться подробные примеры осуществления настоящего изобретения.

На фиг.14 приведена блок-схема системы передачи пакета в соответствии с одним примером осуществления настоящего изобретения, которая включает в себя часть уровня протокола PDCP и часть уровня протокола RLC. Часть уровня протокола RLC содержит блок 20 выделения ошибки передачи, передающий блок 16 и блок управления передачей 18. Блок выделения ошибки передачи предпочтительно находится на уровне протокола RLC и выполняет две функции. Первая функция заключается в различении пакетных данных с ошибкой передачи среди пакетных данных, переданных через буфер. Вторая функция заключается в отправке информации обратной связи по каналу обратной связи 200 в блок управления сжатием заголовка 12. Блок выделения ошибки передачи также отправляет информацию на открытый уровень протоколов, которая указывает, что произошла ошибка передачи пакетных данных. Остальные элементы в системе могут быть аналогичны элементам известной системы передачи пакетных данных, показанной на фиг.2.

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

В то же время, блок выделения ошибки передачи 20 определяет, произошла ли ошибка при передаче пакета с уровня протокола RLC в приемное устройство, и передает информацию об ошибке передачи в блок управления сжатием заголовка 12 на уровне протокола PDCP по каналу 200. Информация об ошибке передачи предпочтительно включает в себя информацию об идентификаторе соответствующего пакета и/или индикатор ошибки передачи.

Уровень протокола PDCP управляет блоком сжатия заголовка 10, основываясь на информации об ошибке передачи, передаваемой с уровня протокола RLC. Более конкретно, если блок управления сжатием заголовка на уровне протокола PDCP принимает из блока 20 индикатор ошибки передачи, показывающий, что произошла ошибка передачи с уровня протокола RLC, блок управления 12 управляет блоком сжатия заголовка 10 с целью сжатия последующего пакета (и предпочтительно первого последующего пакета) с использованием того же идентификатора контекста (CID), что и идентификатор контекста (CID) пакета с ошибкой передачи, как пакета с полным заголовком, и передает его на уровень протокола RLC. Данный аспект изобретения может быть изменен несколькими путями.

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

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

В случае использования метода сжатия по протоколу non-TCP со сжатием заголовка в соответствии с настоящим изобретением результат передачи по блоку служебных данных протокола RLC, переданному с уровня протокола RLC, передается на уровень протокола PDCP, так что уровень протокола PDCP может эффективно управлять, периодически или непериодически, повторной передачей пакета с полным заголовком. Для этой цели уровень протокола RLC выполняет дополнительную функцию информирования о результате передачи блока протокольных данных протокола PDCP (например, блока служебных данных уровня протокола RLC), спускаемого с уровня протокола PDCP.

Теперь будет описана работа уровня протокола RLC. Уровень протокола RLC, который передает блоки служебных данных протокола RLC (=блокам протокольных данных протокола PDCP), передаваемых с уровня протокола PDCP, работает в одном из трех режимов: прозрачном режиме, режиме без подтверждения и режиме с подтверждением.

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

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

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

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

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

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

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

Для этой цели в соответствии с настоящим изобретением, когда результат передачи конкретного блока служебных данных протокола RLC подтверждается уровнем протокола RLC передающей стороны, уровень протокола RLC передающей стороны информирует уровень протокола PDCP передающей стороны об идентификационном номере и результате передачи соответствующего блока служебных данных протокола RLC. Результат передачи может быть выражен в информации об успешной передаче или информации о неудачной передаче. Информация об успешной передаче посылается на уровень протокола PDCP, когда уровень протокола RLC информируется, например, основываясь на принятом блоке протокольных данных состояния, указывающем что конкретный блок служебных данных протокола RLC был успешно передан. Информации о неудачной передаче посылается на уровень протокола PDCP, например, основываясь на принятом блоке протокольных данных состояния, указывающем, что конкретный блок служебных данных протокола RLC не был успешно передан и/или когда уровень протокола RLC отвергает один или более блоков служебных данных протокола RLC, которые не были переданы в течение длительного времени.

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

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

В случае, когда уровень протокола PDCP передает блок протокольных данных протокола PDCP, содержащий пакет с полным заголовком, на уровень протокола RLC, уровень протокола PDCP передает индикатор полного заголовка вместе с соответствующим блоком служебных данных протокола RLC (=блоку протокольных данных протокола PDCP), а уровень протокола RLC информирует уровень протокола PDCP о результатах передачи соответствующего блока служебных данных протокола RLC.

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

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

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

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

Уровень протокола PDCP передающей стороны предпочтительно проверяет, был или не был пакет с полным заголовком успешно передан, когда наступает время передачи полного заголовка при периодической или непериодической передаче данных способом CSS. После проверки, если хотя бы один пакет с полным заголовком был успешно передан, уровень протокола PDCP передающей стороны не передает другой пакет с полным заголовком для соответствующего потока пакетов. Вместо этого, после получения подтверждения о том, что пакет с полным заголовком был успешно передан с уровня протокола RLC передающей стороны, уровень протокола PDCP передает остальные пакеты в потоке как пакеты со сжатым заголовком без использования счетчика, такого как CNT или INT.

Теперь будет обсуждаться способ по настоящему изобретению по передаче пакетов в системе связи. В соответствии с настоящим изобретением пакеты со сжатым заголовком, передаваемые этим способом, могут включать в себя один из следующих видов заголовочной информации: по протоколу TCP со сжатием заголовка, по протоколу TCP nondelta со сжатием заголовка или по протоколу non-TCP со сжатием заголовка. Предпочтительно пакеты со сжатым заголовком соответствуют типам пакетов со сжатым заголовком RFC 2507, т.е., которые соответствуют протоколу RFC 2507 сжатия заголовков. Однако специалистам в данной области техники очевидно, что пакетные данные, передаваемые согласно настоящему изобретению, могут генерироваться с использованием, если желательно, других протоколов сжатия заголовка.

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

При инициализации передачи пакета, способ начинается с шага передачи уровнем протокола RLC пакета с полным заголовком на принимающее устройство (S90). Параметр CNT, показывающий текущий счет числа переданных пакетов со сжатым заголовком, затем устанавливается на значение «0» (CNT=’0′ (S91)). После этого уровень протокола RLC передает пакет (S92) со сжатым заголовком, и значение CNT увеличивается на «1» (CNT=CNT+1) (S93).

На следующем шаге уровень протокола RLC проверяет, одинаковы ли значения INT и CNT (S94). Если два значения различны, операции S92-S94 выполняются повторно. Если два значения одинаковы, уровень протокола RLC проверяет, является ли величина INT больше, чем MaxINT, что предпочтительно соответствует заданному пороговому значению, определяющему максимальное число пакетов со сжатым заголовком, которые должны быть переданы перед тем, как пакет с полным заголовком должен быть назначен для передачи.

Если значение INT меньше значения MaxINT, уровень протокола RLC определяет, передан ли пакет с полным заголовком успешно (S96). Определение может осуществляться, например, на основе информации, содержащейся в блоке протокольных данных состояния, передаваемом приемным устройством. Если определено, что пакет с полным заголовком передан успешно, уровень протокола RLC останавливает операцию подсчета пакетов со сжатым заголовком (S99) и все остальные пакеты в потоке данных передаются как пакеты со сжатым заголовком (8100 и 8101).

Если на операции S96 определено, что передача пакета с полным заголовком была неудачной, уровень протокола RLC непрерывно выполняет операции S90-S97 при увеличении значения INT на экспоненциальный множитель «2» (например, 1, 2, 4, 8, 16,…, 256) (см. операцию S97). Во время этих итераций, даже если значение INT становится больше значения MaxINT на операции S95, определяется, была ли успешной передача пакета с полным заголовком (S98). Если передача пакета с полным заголовком не была удачной, осуществляют работу после операции S90 по передаче пакета с полным заголовком. Если, однако, передача пакета с полным заголовком была успешной, осуществляют операции S99-S101, т.е. все остальные пакеты в потоке данных передаются как пакеты со сжатым заголовком.

Следует отметить, что примеры осуществления настоящего изобретения увязаны с техническими спецификациями 3GPP TS 25.322v4.2.0, озаглавленной «Спецификация протокола RLC», и TS 25.323v4.2-0, озаглавленной «Спецификация протокола PDCP», TS 25.323v4.3-0, TS 25.323v4.5.0 и TS 25.323v5.1-0, включая все дополнения и изменения к ним, содержание которых включено здесь для ссылки. Эти технические особенности изобретения можно представить следующим образом.

Управление передачей полного заголовка

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

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

Для потока по протоколу non-TCP, если протокол PDCP принимает от нижнего уровня информацию об успешной передаче пакета с полным заголовком, протокол PDCP может остановить отправку пакета с полным заголовком, который содержит такой же полный заголовок, как и ранее переданный.

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

Этот подход можно сформулировать следующим образом. В RFC 2507 декомпрессор может использовать способ Header Requests (Запросы заголовка) для восстановления поврежденного контекста. Но для восстановления контекста требуется много времени; декомпрессор обнаруживает поврежденный контекст, ждет, пока не будет обнаружено несколько поврежденных контекстов, затем формирует пакет CONTEXT_STATE, включающий в себя значения их идентификаторов контекста (CID), и посылает его в компрессор. На основе принятого пакета CONTEXT_STATE компрессор распознает, какие контексты повреждены, и передает пакет с полным заголовком для каждого поврежденного значения идентификатора контекста (CID). Во время восстановления контекста все сжатые пакеты значений идентификатора контекста (CID) будут в компрессоре отвергнуты. Быстрое восстановление поврежденного контекста имеет очень важное значение для повышения пропускной способности канала. Если учитывать характеристики протокола RLC, можно восстановить контекст намного быстрее, чем в способе Header Request (Запрос заголовка). В соответствии с настоящим изобретением, когда блок служебных данных протокола RLC отвергается, передающее устройство протокола RLC представляет информацию об отвергнутом блоке служебных данных верхнему уровню (уровню протокола PDCP). Используя эту информацию, протокол PDCP может распознать, какой контекст поврежден (т.е. какой блок служебных данных протокола RLC отвергнут), и передает следующий пакет, благодаря чему пропускная способность может быть значительно улучшена. Поврежденный контекст быстро обнаруживается, и дальнейшая потеря пакетов (в результате неправильного восстановления) предотвращается немедленной отправкой пакета с полным заголовком. В итоге, простое указание отвергнутого блока служебных данных может значительно улучшить пропускную способность.

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

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

Эти способы хорошо подходят для симплексного канала, поскольку компрессор не знает, успешно ли прошла передача полного заголовка или нет. Следовательно, они также хорошо подходят для режимов ТМ (прозрачный режим) и UM (без подтверждения приема) для протокола RLC. Однако, если используется режим AM (с подтверждением приема) для протокола RLC, то можно улучшить эффективность, не посылая успешно переданный полный заголовок. В режиме с подтверждением приема для протокола RLC имеются отчеты о состоянии от приемного устройства, информирующие отправителя сообщений об успешной или неудачной передаче каждого блока служебных данных протокола RLC (более конкретно, о состоянии каждого блока протокольных данных протокола RLC). Если блок служебных данных протокола RLC передан успешно, отправитель сообщений сообщает об этом верхнему уровню с помощью MUI (идентификатор единицы сообщения). В соответствии с настоящим изобретением, когда пакет с полным заголовком передан успешно, в компрессоре прекращается использование способа сжатия с медленным стартом и способа периодического обновления заголовка. Отправка того же полного заголовка, который был уже успешно передан, – это лишь бесполезное расходование радиоресурса, и для повышения пропускной способности этого следует избегать.

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

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

Формула изобретения

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

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

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

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

4. Способ по п.1, в котором информация с нижнего уровня относится к результату передачи одного или более пакетов.

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

6. Способ по п.1, в котором с пакетом с полным заголовком также передают идентификатор контекста, чтобы обеспечить идентификацию каждого пакетного потока.

7. Способ по п.1, в котором верхний уровень является частью уровня протокола сходимости пакетных данных, а нижний уровень является частью уровня управления радиоканалом.

8. Способ по п.1, в котором передающее устройство представляет собой сеть, а приемное устройство представляет собой терминал, или передающее устройство представляет собой терминал, а приемное устройство представляет собой сеть.

9. Способ по п.1, в котором пакеты являются частью потока протокола управления передачей в режиме без установления соединения (non-TCP).

10. Способ по п.9, в котором протокол управления передачей в режиме без установления соединения (non-TCP) является пользовательским дейтаграммным протоколом/Интернет-протоколом (UDP/IP).

11. Способ по п.1, в котором информацию об успешной передаче обеспечивают путем передачи сигнала подтверждения уровня управления радиоканалом.

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

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

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

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

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

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

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

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

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

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

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

23. Передающее устройство по п.14, в котором верхний уровень является частью уровня протокола сходимости пакетных данных, а нижний уровень является частью уровня управления радиоканалом.

24. Передающее устройство по п.14, в котором передающее устройство представляет собой сеть, а приемное устройство представляет собой терминал, или передающее устройство представляет собой терминал, а приемное устройство представляет собой сеть.

25. Передающее устройство по п.14, в котором пакеты являются частью потока протокола управления передачей в режиме без установления соединения (non-TCP).

26. Передающее устройство по п.25, в котором протокол управления передачей в режиме без установления соединения (non-TCP) является пользовательским дейтаграммным протоколом/Интернет-протоколом (UDP/IP).

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

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

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

РИСУНКИ