RU2303858C2 - Способ передачи пакетных данных в системе связи - Google Patents

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

Info

Publication number
RU2303858C2
RU2303858C2 RU2004119304A RU2004119304A RU2303858C2 RU 2303858 C2 RU2303858 C2 RU 2303858C2 RU 2004119304 A RU2004119304 A RU 2004119304A RU 2004119304 A RU2004119304 A RU 2004119304A RU 2303858 C2 RU2303858 C2 RU 2303858C2
Authority
RU
Russia
Prior art keywords
packet
header
full
transmission
layer
Prior art date
Application number
RU2004119304A
Other languages
English (en)
Other versions
RU2004119304A (ru
Inventor
Сеунг-Джун ЙИ (KR)
Сеунг-Джун Йи
Вун-Ёнг Ё (KR)
Вун-ёнг Ё
Со-Ёнг ЛИ (KR)
Со-ёнг ЛИ
Original Assignee
Эл Джи Электроникс Инк.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020010074774A external-priority patent/KR100765122B1/ko
Priority claimed from KR10-2001-0073640A external-priority patent/KR100425745B1/ko
Application filed by Эл Джи Электроникс Инк. filed Critical Эл Джи Электроникс Инк.
Publication of RU2004119304A publication Critical patent/RU2004119304A/ru
Application granted granted Critical
Publication of RU2303858C2 publication Critical patent/RU2303858C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/325—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Abstract

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

Description

ОБЛАСТЬ ТЕХНИКИ. К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Настоящее изобретение относится в основном к области передачи пакетных данных в системе связи и, более конкретно, к системе и способу передачи пакетных данных, содержащих заголовочную информацию.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
Поскольку технология мобильной связи продолжает развиваться, ожидается, что аппараты беспроводной связи станут более широко использоваться, чем обычные телефонные аппараты проводной связи. Однако аппараты проводной связи продолжают оставаться единственным средством при выборе терминалов для некоторых случаев применения. Например, технология мобильной радиосвязи значительно уступает существующим системам проводной связи по пропускной способности, когда речь идет о передаче больших объемов данных и голосовом трафике между терминалами. Для решения этой проблемы было предложено несколько стандартов беспроводной связи. Один из таких стандартов, называемый 1МТ-2000 (Международная система мобильной связи-2000, примеч. перевод.), позволяет передавать большие объемы данных между терминалами, поэтому он быстро распространился во многих странах. Фактически, в настоящее время международное сотрудничество находится на пути к разработке для этой технологии единого стандарта.
Недавно это сотрудничество вылилось в инициативу, известную как Проект партнерства по разработке сетей третьего поколения (3GPP). Инициатива 3GPP была учреждена с целью стандартизации, помимо прочего, системы 1МТ-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(1), а другие 8 битов - для идентификатора контекста CID(2). Принимая во внимание, что размер полного заголовка составляет 48 октетов, следует заметить, что такая же цель может быть достигнута путем передачи очень малого объема данных.
При передаче пакетных данных с использованием метода сжатия заголовка по протоколу TCP со сжатием заголовка, вытекающим из алгоритма сжатия заголовка по протоколу TCP/IP (RFC 2507 Compressed TCP), пакет с полным заголовком передают в первом пакете потока пакетов. Последующие пакеты передают со сжатым заголовком, содержащим лишь отличия от ранее переданных заголовков потока пакетов. Контекст потока пакетов постоянно обновляют относительно ранее принятых заголовков пакетов.
При передаче пакетных данных с использованием другого метода сжатия заголовка по протоколу TCP со сжатием заголовка, вытекающим из алгоритма сжатия заголовка по протоколу TCP/IP (RFC 2507 Compressed TCP nondelta), пакет с полным заголовком передают в первом пакете потока пакетов. Последующие пакеты передают со сжатым заголовком, содержащим лишь отличия от ранее переданных заголовков потока пакетов. Контекст потока пакетов постоянно обновляют относительно ранее принятого полного заголовка.
При передаче пакетных данных с использованием алгоритма сжатия заголовка по протоколу UDP/IP (протокол non-TCP со сжатием заголовка, Compression Stow Start (сжатие с медленным стартом, примеч. перевод.) далее обозначенное как CSS) пакеты с полным заголовком передают в первом пакете, а некоторые из последующих пакетов потока пакетов - в соответствии с заданным правилом. На фиг.5 показана последовательность действий известного способа передачи пакета с полным заголовком и пакета со сжатым заголовком в соответствии со способом CSS. На этой фигуре значение INT (значение интервала) показывает число пакетов со сжатым заголовком, которые могут быть переданы между двумя последовательно передаваемыми пакетами с полным заголовком, а значение CNT (значение счетчика) показывает число переданных пакетов со сжатым заголовком.
В соответствии с этим способом передают пакет со сжатым заголовком, а когда значения CNT и INT становятся одинаковыми, передают пакет с полным заголовком вместо пакета со сжатым заголовком. Значение INT обновляется в то время, когда должен передаваться полный заголовок. Когда значение INT достигает величины MaxINT, соответствующей пороговому значению интервала передачи, оно больше не возрастает, и сохраняется значение MaxINT. Процесс заканчивается, когда все данные в потоке пакетов переданы, или когда данные полного заголовка изменились. Теперь будет более подробно описан способ передачи.
Сначала минимальное число (INT) пакетов со сжатым заголовком, которые могут быть переданы между пакетами с полным заголовком, устанавливают на начальное значение, равное «1».
Когда начинается операция передачи пакета с заголовком, сначала передают пакет с полным заголовком (S80), а затем CNT, показывающий число переданных пакетов со сжатым заголовком, устанавливают на «0» (CNT=0) (S81). Затем передают пакет со сжатым заголовком (S82) и затем - CNT, показывающий число переданных пакетов со сжатым заголовком, увеличивают на «1» (CNT=CNT+1) (S83).
Далее значения 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 со сжатием заголовка 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В и 12C показан формат протокола non-TCP со сжатием заголовка с 8-битовым идентификатором контекста (CID) и формат протокола non-TCP со сжатием заголовка с 16-битовым идентификатором контекста (CID) соответственно;
на фиг.13А графически показаны особенности предпочтительного примера осуществления настоящего изобретения по отношению к передаче пакета со сжатым и полным заголовком при использовании передачи по протоколу TCP;
на фиг.13В графически показаны эти особенности предпочтительного примера осуществления настоящего изобретения по отношению к передаче пакета со сжатым и полным заголовком при использовании передачи по протоколу non-TCP;
на фиг.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 принимает пакет данных пользователя из внешней пакетной сети, определяет адрес назначения пакета и передает его в следующий пункт назначения согласно установленному пути.
Дейтаграммный протокол пользователя (протокол UDP)/IP-протокол, широко используемый для пакетной передачи в проводной сети, расположен на нижнем уровне протокола 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, а уровень протокола 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), и все остальные пакеты в потоке данных передаются как пакеты со сжатым заголовком (S100 и S101).
Если на операции 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, включая все дополнения и изменения к ним, содержание которых включено здесь для ссылки. Эти технические особенности изобретения можно представить следующим образом:
Управление передачей полного заголовка
Передача пакета с полным заголовком может управляться информацией нижнего уровня.
Для потока по протоколу ТСР, если протокол 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, но может быть применено к системе передачи пакетных данных любого типа.
Очевидно, что изложенные выше примеры осуществления и преимущества даны лишь для наглядности и не могут рассматриваться как ограничивающие данное изобретение. Настоящее наставление может быть легко применено к другим типам устройств. Описание данного изобретения носит иллюстративный характер и не ограничивает объем формулы изобретения. Специалисту в данной области техники понятно, что возможно множество альтернативных вариантов, модификаций и изменений. В формуле изобретения пункты, содержащие конструктивно-функциональные признаки, предназначены для охвата описанной в ней структуры, как выполняющие рассмотренные функции, и не только структурных эквивалентов, но также и эквивалентных структур.

Claims (22)

1. Способ работы передающего устройства, имеющего протокол связи с верхним уровнем и нижним уровнем, используемый для управления передачей полного заголовка при передаче пакетов данных приемному устройству, содержащий управление с помощью указанного передающего устройства передачей пакета с полным заголовком посредством информации с нижнего уровня, за счет чего, если верхний уровень получает с нижнего уровня информацию о передаче с ошибкой, по меньшей мере, одного пакета, верхний уровень отправляет приемному устройству следующий пакет как пакет с полным заголовком, при этом информация о передаче с ошибкой указывает, что нижний уровень отверг, по меньшей мере, один пакет.
2. Способ по п.1, в котором информация о передаче с ошибкой включает идентификатор, используемый для указания, по меньшей мере, одного пакета, который был отвергнут нижним уровнем, при этом, по меньшей мере, один пакет представляет собой блоки служебных данных для управления радиоканалом.
3. Способ по п.1, в котором нижний уровень работает в прозрачном режиме, режиме без подтверждения приема или режиме с подтверждением приема.
4. Способ по п.1, в котором отправку следующего пакета как пакета с полным заголовком осуществляют независимо от какого-либо запроса от приемного устройства.
5. Способ по п.1, в котором верхний уровень получает информацию с нижнего уровня при доставке параметра, указывающего, требуется ли нижнему уровню информировать верхний уровень об отвергнутом пакете.
6. Способ по п.1, в котором информация с нижнего уровня относится к результату передачи каждого пакета.
7. Способ по п.1, в котором с пакетом с полным заголовком также передают идентификатор контекста, чтобы обеспечить идентификацию каждого пакетного потока.
8. Способ по п.1, в котором верхний уровень является частью уровня протокола сходимости пакетных данных, а нижний уровень является частью уровня управления радиоканалом.
9. Способ по п.1, в котором передающее устройство представляет собой сеть, а приемное устройство представляет собой терминал, или передающее устройство представляет собой терминал, а приемное устройство представляет собой сеть.
10. Способ по п.1, в котором пакеты являются частью потока протокола управления передачей.
11. Передающее устройство с протоколом связи, используемым для управления передачей пакета с полным заголовком при передаче пакетов данных приемному устройству, содержащее верхний уровень для управления передачей пакета с полным заголовком посредством информации с нижнего уровня, за счет чего, если верхний уровень получает с нижнего уровня информацию о передаче с ошибкой, по меньшей мере, одного пакета, верхний уровень отправляет следующий пакет как пакет с полным заголовком, при этом информация о передаче с ошибкой указывает, что нижний уровень отверг, по меньшей мере, один пакет.
12. Передающее устройство по п.11, в котором верхний уровень содержит компрессор заголовков, который получает пакетный поток и выдает пакеты с полными заголовками и пакеты со сжатыми заголовками; передатчик данных, который доставляет на нижний уровень пакеты с полными заголовками и пакеты со сжатыми заголовками, полученными от компрессора заголовков; и блок управления сжатием заголовков, который получает информацию с нижнего уровня для управления компрессором заголовков с целью обеспечения выхода пакетов с полными заголовками или пакетов со сжатыми заголовками, предназначенных для доставки передатчиком данных.
13. Передающее устройство по п.11, в котором нижний уровень содержит блок передачи, снабженный буфером, который получает и сохраняет пакеты с полными заголовками и пакеты со сжатыми заголовками, доставленные с верхнего уровня; блок выделения ошибки передачи, который обеспечивает верхнему уровню информацию о передаче с ошибкой, по меньшей мере, одного пакета из пакетного потока; и блок управления передачей, который управляет блоком передачи, снабженным буфером, чтобы передать приемному устройству пакеты с полными заголовками и пакеты со сжатыми заголовками.
14. Передающее устройство по п.11, в котором информация о передаче с ошибкой включает идентификатор, используемый для указания, по меньшей мере, одного пакета, который был отвергнут нижним уровнем, при этом, по меньшей мере, один пакет представляет собой блоки служебных данных для управления радиоканалом.
15. Передающее устройство по п.11, в котором нижний уровень работает в прозрачном режиме, режиме без подтверждения приема или режиме с подтверждением приема.
16. Передающее устройство по п.11, в котором отправку следующего пакета как пакета с полным заголовком осуществляют независимо от какого-либо запроса от приемного устройства.
17. Передающее устройство по п.11, в котором верхний уровень получает информацию с нижнего уровня при доставке параметра, указывающего, требуется ли нижнему уровню информировать верхний уровень об отвергнутом пакете.
18. Передающее устройство по п.11, в котором в котором информация с нижнего уровня относится к результату передачи каждого пакета.
19. Передающее устройство по п.11, в котором с пакетом с полным заголовком также передают идентификатор контекста, чтобы обеспечить идентификацию каждого пакетного потока.
20. Передающее устройство по п.11, в котором верхний уровень является частью уровня протокола сходимости пакетных данных, а нижний уровень является частью уровня управления радиоканалом.
21. Передающее устройство по п.11, в котором передающее устройство представляет собой сеть, а приемное устройство представляет собой терминал, или передающее устройство представляет собой терминал, а приемное устройство представляет собой сеть.
22. Передающее устройство по п.11, в котором пакеты являются частью потока протокола управления передачей.
RU2004119304A 2001-11-24 2002-11-23 Способ передачи пакетных данных в системе связи RU2303858C2 (ru)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR74774/2001 2001-11-24
KR73640/2001 2001-11-24
KR1020010074774A KR100765122B1 (ko) 2001-11-24 2001-11-24 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법
KR10-2001-0073640A KR100425745B1 (ko) 2001-11-24 2001-11-24 패킷의 헤더압축을 지원하는 통신 시스템에서 패킷의전송방법

Related Child Applications (1)

Application Number Title Priority Date Filing Date
RU2006107113/09A Division RU2316906C2 (ru) 2001-11-24 2002-11-23 Способ передачи пакетных данных в системе связи

Publications (2)

Publication Number Publication Date
RU2004119304A RU2004119304A (ru) 2005-05-10
RU2303858C2 true RU2303858C2 (ru) 2007-07-27

Family

ID=26639481

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2004119304A RU2303858C2 (ru) 2001-11-24 2002-11-23 Способ передачи пакетных данных в системе связи

Country Status (12)

Country Link
US (4) US7486699B2 (ru)
EP (2) EP1968277B1 (ru)
JP (2) JP4309118B2 (ru)
AT (2) ATE502472T1 (ru)
AU (2) AU2002353634B2 (ru)
DE (2) DE60229482D1 (ru)
MA (1) MA27160A1 (ru)
MX (1) MXPA04006224A (ru)
RU (1) RU2303858C2 (ru)
UA (1) UA82886C2 (ru)
WO (1) WO2003047189A1 (ru)
ZA (1) ZA200404748B (ru)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2464742C2 (ru) * 2008-04-04 2012-10-20 Квэлкомм Инкорпорейтед Выборочное установление однонаправленного канала в расширенном универсальном наземном радиодоступе (e-utra) и расширенной пакетной системе (eps)
RU2504087C2 (ru) * 2007-10-04 2014-01-10 Нокиа Сименс Нетворкс Ой Способ и устройство для уменьшения системных издержек
RU2687217C1 (ru) * 2018-06-20 2019-05-07 Открытое Акционерное Общество "Информационные Технологии И Коммуникационные Системы" Способ предотвращения фрагментации TCP/IP-пакетов при использовании VPLS в сети с коммутацией пакетов

Families Citing this family (124)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7376879B2 (en) * 2001-10-19 2008-05-20 Interdigital Technology Corporation MAC architecture in wireless communication systems supporting H-ARQ
DE60229482D1 (de) * 2001-11-24 2008-12-04 Lg Electronics Inc Verfahren zur Übertragung von Paketdaten in komprimierter Form in einem Kommunikationssystem
KR100889864B1 (ko) * 2002-08-14 2009-03-24 엘지전자 주식회사 멀티미디어 데이터의 압축 전송 방법 및 시스템
US7266121B2 (en) * 2002-12-27 2007-09-04 Nokia Corporation Flow labels
US8254372B2 (en) 2003-02-21 2012-08-28 Genband Us Llc Data communication apparatus and method
CN1768511B (zh) * 2003-04-09 2010-12-01 日本电气株式会社 无线电网络控制设备及其使用的qos控制方法
US7065087B2 (en) * 2003-07-08 2006-06-20 Cisco Technology, Inc. Performing compression of user datagram protocol packets
US7317724B2 (en) * 2003-07-08 2008-01-08 Cisco Technology, Inc. Performing compression of user datagram protocol packets
CN100461874C (zh) * 2003-10-30 2009-02-11 美商内数位科技公司 无线存取承载管理器实施架构及封包数据收敛协议方法
US7990865B2 (en) 2004-03-19 2011-08-02 Genband Us Llc Communicating processing capabilities along a communications path
US8027265B2 (en) 2004-03-19 2011-09-27 Genband Us Llc Providing a capability list of a predefined format in a communications network
KR101048256B1 (ko) 2004-03-31 2011-07-08 엘지전자 주식회사 이동통신 시스템의 중요도에 따른 데이터 전송방법
US8018945B2 (en) * 2004-04-29 2011-09-13 Interdigital Technology Corporation Method and apparatus for forwarding non-consecutive data blocks in enhanced uplink transmissions
IL162306A0 (en) * 2004-06-02 2005-11-20 Eci Telecom Ltd Method for header compression in packet based telecommunication systems
US7558289B1 (en) * 2004-06-17 2009-07-07 Marvell International Ltd. Method and apparatus for providing quality of service (QOS) in a wireless local area network
US7463602B2 (en) * 2004-09-13 2008-12-09 Research In Motion Limited Configuring signaling radio bearer information in a user equipment protocol stack
US7729346B2 (en) * 2004-09-18 2010-06-01 Genband Inc. UMTS call handling methods and apparatus
US7830864B2 (en) 2004-09-18 2010-11-09 Genband Us Llc Apparatus and methods for per-session switching for multiple wireline and wireless data types
EP1803310B1 (en) * 2004-10-22 2015-12-23 Genband US LLC Mobility management apparatus and methods
CN100518180C (zh) * 2004-12-03 2009-07-22 华为技术有限公司 一种实现分组数据聚合协议功能的系统及方法
US20060139869A1 (en) * 2004-12-29 2006-06-29 Matusz Pawel O Extended compression arrangements within telecommunication systems and associated methods
CN100459710C (zh) * 2005-03-17 2009-02-04 华为技术有限公司 一种数据流头压缩中的全头包发送方法
US8228926B2 (en) * 2005-04-12 2012-07-24 Genband Us Llc Dynamic loading for signaling variants
US8483173B2 (en) 2005-05-31 2013-07-09 Genband Us Llc Methods and systems for unlicensed mobile access realization in a media gateway
US7961739B2 (en) * 2005-07-21 2011-06-14 Genband Us Llc Systems and methods for voice over multiprotocol label switching
US7792150B2 (en) 2005-08-19 2010-09-07 Genband Us Llc Methods, systems, and computer program products for supporting transcoder-free operation in media gateway
US7907609B2 (en) 2006-01-06 2011-03-15 Qualcomm, Incorporated Method and apparatus for enhancing RoHC performance when encountering silence suppression
US7835346B2 (en) * 2006-01-17 2010-11-16 Genband Us Llc Methods, systems, and computer program products for providing transcoder free operation (TrFO) and interworking between unlicensed mobile access (UMA) and universal mobile telecommunications system (UMTS) call legs using a media gateway
KR101265643B1 (ko) 2006-08-22 2013-05-22 엘지전자 주식회사 무선 통신 시스템에서의 핸드오버 수행 및 그 제어 방법
KR101387500B1 (ko) 2006-08-22 2014-04-21 엘지전자 주식회사 무선 통신 시스템에서의 제어정보 전송 및 수신 방법
US8750334B2 (en) 2006-10-02 2014-06-10 Motorola Mobility Llc Link layer assisted robust header compression context update management
WO2008041823A2 (en) 2006-10-02 2008-04-10 Lg Electronics Inc. Methods for transmitting and receiving paging message in wireless communication system
WO2008054119A2 (en) 2006-10-30 2008-05-08 Lg Electronics Inc. Methods for transmitting access channel message and response message, and mobile communication terminals
JP4523072B2 (ja) 2006-10-30 2010-08-11 エルジー エレクトロニクス インコーポレイティド 上り接続のリディレクション方法
EP2084928B1 (en) 2006-10-30 2017-08-23 LG Electronics Inc. Method of performing random access in a wireless communication system
KR100938754B1 (ko) 2006-10-30 2010-01-26 엘지전자 주식회사 비연속 수신을 이용한 데이터 수신 및 전송 방법
EP2108193B1 (en) 2006-12-28 2018-08-15 Genband US LLC Methods, systems, and computer program products for silence insertion descriptor (sid) conversion
US7729380B2 (en) * 2007-01-21 2010-06-01 Motorola, Inc. Method and device for selectively transmitting voice bursts and regenerated header bursts
WO2008111822A2 (en) * 2007-03-15 2008-09-18 Lg Electronics Inc. A method for transmitting/receiving data in a mobile communication system
US8774125B2 (en) * 2007-03-15 2014-07-08 Lg Electronics Inc. Method of managing data blocks during handover
KR20080087747A (ko) * 2007-03-26 2008-10-01 한국전자통신연구원 무선 패킷 통신 시스템 및 그 무선자원 할당방법
PL2145418T3 (pl) 2007-04-11 2016-09-30 Sposób i urządzenie w systemie telekomunikacyjnym
US8040806B2 (en) 2007-04-30 2011-10-18 Lg Electronics Inc. Methods of generating data block in mobile communication system
KR101386812B1 (ko) 2007-04-30 2014-04-29 엘지전자 주식회사 헤더 필드 존재 지시자를 이용한 효율적인 데이터 블록송수신방법
KR101455999B1 (ko) * 2007-04-30 2014-11-03 엘지전자 주식회사 무선 통신 시스템에서의 데이터 블록 생성 방법
KR101458641B1 (ko) 2007-04-30 2014-11-05 엘지전자 주식회사 Ｍｂｍｓ를 지원하는 무선통신 시스템에서 데이터 전송방법
US8027363B2 (en) 2007-04-30 2011-09-27 Lg Electronics Inc. Method of transmitting data in a wireless communication system
WO2008133481A1 (en) 2007-04-30 2008-11-06 Lg Electronics Inc. Method for performing an authentication of entities during establishment of wireless call connection
KR101469281B1 (ko) 2007-04-30 2014-12-04 엘지전자 주식회사 무선단말의 상태 전환 방식
KR101464748B1 (ko) 2007-04-30 2014-11-24 엘지전자 주식회사 무선단말의 측정보고 기동방식
KR20080097338A (ko) 2007-05-01 2008-11-05 엘지전자 주식회사 불연속 데이터 송수신 방법
KR100917205B1 (ko) * 2007-05-02 2009-09-15 엘지전자 주식회사 무선 통신 시스템에서의 데이터 블록 구성 방법
US20080273482A1 (en) * 2007-05-02 2008-11-06 Lg Electronics Inc. Uplink access method for receiving a point-to-multipoint service
US20080273503A1 (en) * 2007-05-02 2008-11-06 Lg Electronics Inc. Method and terminal for performing handover in mobile communications system of point-to-multipoint service
WO2008136598A1 (en) 2007-05-03 2008-11-13 Lg Electronics Inc. Method of data processing in a wireless communication system
KR101486352B1 (ko) 2007-06-18 2015-01-26 엘지전자 주식회사 무선 통신 시스템의 단말에서의 상향링크 동기 상태 제어방법
KR101341515B1 (ko) 2007-06-18 2013-12-16 엘지전자 주식회사 무선 통신 시스템에서의 반복 전송 정보 갱신 방법
WO2008156308A2 (en) 2007-06-18 2008-12-24 Lg Electronics Inc. Paging information transmission method for effective call setup
KR101470638B1 (ko) 2007-06-18 2014-12-08 엘지전자 주식회사 이동통신 시스템에서의 무선자원 향상 방법, 상태정보 보고방법 및 수신장치
US8139524B2 (en) 2007-06-18 2012-03-20 Lg Electronics Inc. Control channel reception method for receiving broadcast or multicast service
KR101526971B1 (ko) 2007-06-18 2015-06-11 엘지전자 주식회사 방송 또는 멀티캐스트 서비스 송수신 방법 및 단말
HUE033683T2 (en) 2007-06-18 2017-12-28 Lg Electronics Inc Procedure for performing user device upload direction connection synchronization in a wireless communication system
WO2008156314A2 (en) 2007-06-20 2008-12-24 Lg Electronics Inc. Effective system information reception method
KR101448644B1 (ko) 2007-06-20 2014-10-13 엘지전자 주식회사 이동 통신 시스템에서의 데이터 전송 방법
JP4957419B2 (ja) * 2007-07-10 2012-06-20 ソニー株式会社 無線通信装置、無線通信システム、無線通信方法及びプログラム
EP2186247A4 (en) 2007-08-10 2014-01-29 Lg Electronics Inc METHOD FOR CONTROLLING HARQ OPERATION WITH DYNAMIC RADIO RESOURCE ALLOCATION
KR101514841B1 (ko) 2007-08-10 2015-04-23 엘지전자 주식회사 효율적인 랜덤 액세스 재시도를 수행하는 방법
KR101479341B1 (ko) 2007-08-10 2015-01-05 엘지전자 주식회사 Ｍｂｍｓ 서비스를 제공하는 무선 통신 시스템에서효율적인 수신 방법
KR101490253B1 (ko) 2007-08-10 2015-02-05 엘지전자 주식회사 무선 통신 시스템에서의 제어정보 전송 및 수신 방법
WO2009022840A2 (en) 2007-08-10 2009-02-19 Lg Electronics Inc. Methods of setting up channel in wireless communication system
US8488523B2 (en) * 2007-08-14 2013-07-16 Lg Electronics Inc. Method of transmitting and processing data block of specific protocol layer in wireless communication system
KR100907978B1 (ko) 2007-09-11 2009-07-15 엘지전자 주식회사 이동통신 시스템에서 ｐｄｃｐ 계층의 상태보고 전송 방법 및 수신장치
KR101461970B1 (ko) 2007-09-13 2014-11-14 엘지전자 주식회사 무선 통신 시스템에서의 폴링 과정 수행 방법
KR100937432B1 (ko) * 2007-09-13 2010-01-18 엘지전자 주식회사 무선 통신 시스템에서의 무선자원 할당 방법
KR101479340B1 (ko) * 2007-09-18 2015-01-06 엘지전자 주식회사 무선통신 시스템에서 셀 재선택 과정을 수행하는 방법
KR101435844B1 (ko) 2007-09-18 2014-08-29 엘지전자 주식회사 무선 통신 시스템에서의 데이터 블록 전송 방법
KR101513033B1 (ko) 2007-09-18 2015-04-17 엘지전자 주식회사 다중 계층 구조에서 ＱｏＳ를 보장하기 위한 방법
KR101396062B1 (ko) * 2007-09-18 2014-05-26 엘지전자 주식회사 헤더 지시자를 이용한 효율적인 데이터 블록 전송방법
KR101591824B1 (ko) 2007-09-18 2016-02-04 엘지전자 주식회사 무선 통신 시스템에서의 폴링 과정 수행 방법
US8687565B2 (en) 2007-09-20 2014-04-01 Lg Electronics Inc. Method of effectively transmitting radio resource allocation request in mobile communication system
EP2168270B1 (en) 2007-09-20 2016-02-17 LG Electronics Inc. A method for handling correctly received but header compression failed packets
KR101387537B1 (ko) 2007-09-20 2014-04-21 엘지전자 주식회사 성공적으로 수신했으나 헤더 압축 복원에 실패한 패킷의 처리 방법
TWM357138U (en) 2007-09-28 2009-05-11 Interdigital Patent Holdings Wireless transmit receive unit
AR068651A1 (es) * 2007-10-01 2009-11-25 Inter Digital Patent Holding I Metodo y aparato para mejorar varias operaciones pdcp y capa 2
KR20090041323A (ko) 2007-10-23 2009-04-28 엘지전자 주식회사 데이터 블록 구성함에 있어서 단말의 식별 정보를 효과적으로 전송하는 방법
KR101487557B1 (ko) * 2007-10-23 2015-01-29 엘지전자 주식회사 공통제어채널의 데이터를 전송하는 방법
KR20090043465A (ko) 2007-10-29 2009-05-06 엘지전자 주식회사 무선 베어러 타입에 따른 오류 해결 방법
JP5082768B2 (ja) * 2007-10-29 2012-11-28 富士通株式会社 移動通信システム、移動通信方法、無線基地局装置、および端末
JP4814864B2 (ja) * 2007-11-26 2011-11-16 日本放送協会 パケット多重化装置及びパケット多重化プログラム
US8059651B2 (en) * 2007-12-17 2011-11-15 Motorola Solutions, Inc. Method for recovering lost header
WO2009096731A2 (en) * 2008-01-31 2009-08-06 Lg Electronics Inc. Method for signaling back-off information in random access
EP3410623B1 (en) 2008-01-31 2021-07-28 LG Electronics Inc. Method for sending status information in mobile telecommunications system and receiver of mobile telecommunications
KR101594359B1 (ko) 2008-01-31 2016-02-16 엘지전자 주식회사 랜덤 접속에서 백오프 정보를 시그널링하는 방법
KR101531419B1 (ko) * 2008-02-01 2015-06-24 엘지전자 주식회사 시간동기 타이머의 만료 시 상향링크 ｈａｒｑ의 동작 방법
US20090207739A1 (en) * 2008-02-01 2009-08-20 Sung-Duck Chun Mobile communication system and method for transmitting pdcp status report thereof
US9008004B2 (en) * 2008-02-01 2015-04-14 Lg Electronics Inc. Method for sending RLC PDU and allocating radio resource in mobile communications system and RLC entity of mobile communications
US8958411B2 (en) 2008-03-17 2015-02-17 Lg Electronics Inc. Method of transmitting RLC data
KR101163275B1 (ko) 2008-03-17 2012-07-05 엘지전자 주식회사 Ｐｄｃｐ 상태 보고 전송 방법
JP5066064B2 (ja) * 2008-11-28 2012-11-07 日本放送協会 一方向伝送路に用いる送信端末、受信端末及び伝送システム
WO2010064831A2 (en) * 2008-12-01 2010-06-10 Samsung Electronics Co., Ltd. Method and system for optimizing measurement reporting mechanism in a layered protocol wireless network
KR101521886B1 (ko) * 2009-01-23 2015-05-28 삼성전자주식회사 이동통신 시스템에서 지티피 처리를 위한 장치 및 방법
US8908541B2 (en) 2009-08-04 2014-12-09 Genband Us Llc Methods, systems, and computer readable media for intelligent optimization of digital signal processor (DSP) resource utilization in a media gateway
US8140709B2 (en) * 2009-08-07 2012-03-20 Alcatel Lucent Two stage internet protocol header compression
US20110149848A1 (en) * 2009-08-17 2011-06-23 Qualcomm Incorporated Header compression for relay nodes
CN102056235B (zh) * 2009-11-09 2017-04-26 华为技术有限公司 一种数据传输方法、设备和系统
WO2012141648A2 (en) 2011-04-12 2012-10-18 Telefonaktiebolaget L M Ericsson (Publ) A method and system for transmitting data from a radio network controller to a user equipment
CN102761905B (zh) * 2011-04-26 2016-03-30 华为技术有限公司 消息处理方法、设备及系统
JP2013047931A (ja) * 2011-07-28 2013-03-07 Mitsubishi Electric Corp 運転支援システム
US20140098745A1 (en) * 2012-10-04 2014-04-10 Qualcomm Incorporated Method and system for compressing data packets in lte evolved multicast broadcast multimedia service
AU2013327902A1 (en) * 2012-10-12 2015-04-02 Sony Corporation Electronic device, composite-stream transmission method, and program
CN105659567B (zh) * 2014-01-14 2019-03-12 Lg 电子株式会社 发送广播信号的装置、接收广播信号的装置、发送广播信号的方法以及接收广播信号的方法
CN105659612B (zh) * 2014-03-11 2018-12-28 Lg 电子株式会社 发送/接收广播信号的方法和设备
EP3016432B1 (en) * 2014-10-30 2018-07-04 Vodafone IP Licensing limited Content compression in mobile network
CN105812087B (zh) 2014-12-30 2019-09-24 中兴通讯股份有限公司 一种无线通信网络中数据传输方法和装置
CN106161370B (zh) * 2015-04-08 2021-03-23 中国移动通信集团公司 一种媒体编码的调整方法及终端
US11400248B2 (en) 2015-06-23 2022-08-02 Simplicity Airway, Inc. Positive pressure ventilation elbow and related masks, systems, and methods
US10432761B2 (en) * 2017-01-18 2019-10-01 Qualcomm Incorporated Techniques for handling internet protocol flows in a layer 2 architecture of a wireless device
US10237784B2 (en) * 2017-03-24 2019-03-19 Motorola Mobility Llc Split bearer packet data converge protocol protocol data unit routing
US10567070B2 (en) * 2017-04-02 2020-02-18 Ahmad Jalali Air to ground network for broadband access to aerial platforms
CN109040081B (zh) * 2018-08-10 2020-08-04 哈尔滨工业大学（威海） 一种基于bwt的协议字段逆向分析系统及方法
KR20200089095A (ko) 2019-01-16 2020-07-24 삼성전자주식회사 차세대 이동통신 시스템에서 하위계층 전송결과에 의한 패킷 삭제를 수행하는 방법 및 장치
CN111869183A (zh) * 2019-02-14 2020-10-30 联发科技股份有限公司 简单的以太网报头压缩
CN112351459A (zh) * 2019-08-09 2021-02-09 夏普株式会社 Pdcp实体发送端/接收端的执行方法、pdcp实体及通信设备
CN110602073B (zh) * 2019-09-02 2021-05-18 西安电子科技大学 基于信息论的无人机飞控协议字段划分方法

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63114438A (ja) 1986-10-31 1988-05-19 Nec Corp 階層化通信制御装置
JPS63248254A (ja) 1987-04-02 1988-10-14 Nec Corp 通信制御装置
EP0654199B1 (en) 1993-06-10 1999-05-26 Sony Corporation Rational input buffer arrangements for auxiliary information in video and audio signal processing systems
JP2002516042A (ja) 1996-01-31 2002-05-28 イプシロン ネットワークス インコーポレイテッド 伝送ネットワークにおいてパケットの経路指定とスイッチングとの間をダイナミックにシフトする改良された方法及び装置
JPH10254689A (ja) * 1997-03-14 1998-09-25 Hitachi Ltd クライアント・サーバシステムのアプリケーション構成設計支援方式
US6032197A (en) * 1997-09-25 2000-02-29 Microsoft Corporation Data packet header compression for unidirectional transmission
GB2341059A (en) * 1998-08-28 2000-03-01 Nokia Oy Ab Internet protocol flow detection
US6707819B1 (en) * 1998-12-18 2004-03-16 At&T Corp. Method and apparatus for the encapsulation of control information in a real-time data stream
FI107000B (fi) * 1999-02-17 2001-05-15 Nokia Mobile Phones Ltd Otsikon pakkaaminen reaaliaikaisissa palveluissa
US6198735B1 (en) 1999-05-20 2001-03-06 Motorola, Inc. Method for retransmitting a data packet in a packet network
US6680955B1 (en) * 1999-08-20 2004-01-20 Nokia Networks Oy Technique for compressing a header field in a data packet
US6882637B1 (en) * 1999-10-14 2005-04-19 Nokia Networks Oy Method and system for transmitting and receiving packets
US6542931B1 (en) * 1999-11-05 2003-04-01 Nokia Corporation Using sparse feedback to increase bandwidth efficiency in high delay, low bandwidth environment
US6711164B1 (en) * 1999-11-05 2004-03-23 Nokia Corporation Method and apparatus for performing IP-ID regeneration to improve header compression efficiency
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
FI110831B (fi) * 1999-12-31 2003-03-31 Nokia Corp Menetelmä tiedonsiirron tehostamiseksi ja tiedonsiirtoprotokolla
FI112305B (fi) * 2000-02-14 2003-11-14 Nokia Corp Datapakettien numerointi pakettivälitteisessä tiedonsiirrossa
GB0004178D0 (en) * 2000-02-22 2000-04-12 Nokia Networks Oy Integrity check in a communication system
DE10008148A1 (de) * 2000-02-22 2001-08-23 Bosch Gmbh Robert Verfahren zum Betreiben eines Mobilfunknetzes
EP1146713B1 (en) 2000-03-03 2005-04-27 NTT DoCoMo, Inc. Method and apparatus for packet transmission with header compression
JP3730835B2 (ja) * 2000-03-03 2006-01-05 株式会社エヌ・ティ・ティ・ドコモ パケット伝送方法、中継装置およびデータ端末
JP2001320422A (ja) 2000-03-03 2001-11-16 Ntt Docomo Inc ヘッダ圧縮を伴うパケット伝送のための方法および装置
US7136377B1 (en) * 2000-03-31 2006-11-14 Cisco Technology, Inc. Tunneled datagram switching
FI109255B (fi) * 2000-04-07 2002-06-14 Nokia Corp Datapakettien numerointi pakettivälitteisessä tiedonsiirrossa
US20010055298A1 (en) * 2000-05-10 2001-12-27 John Baker Apparatus and system to provide wireless data services through a wireless access integrated node
JP3936290B2 (ja) * 2000-08-14 2007-06-27 ノキア コーポレイション モード選択手順を備えた通信システム及びその方法
FI113323B (fi) * 2000-08-21 2004-03-31 Nokia Corp Datapakettinumeroiden synkronointi pakettivälitteisessä tiedonsiirrossa
US6967964B1 (en) * 2000-10-03 2005-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Context identification using header compression key at link layer
US6618397B1 (en) * 2000-10-05 2003-09-09 Provisionpoint Communications, Llc. Group packet encapsulation and compression system and method
US20020064164A1 (en) * 2000-10-06 2002-05-30 Barany Peter A. Protocol header construction and/or removal for messages in wireless communications
FI110739B (fi) * 2000-10-18 2003-03-14 Nokia Corp Otsikkokenttien kompressoinnin määrittäminen datapakettiyhteydelle
US7069495B2 (en) * 2000-10-30 2006-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Bit error resilience for an internet protocol stack
US7136395B2 (en) * 2000-11-30 2006-11-14 Telefonaktiebolaget L M Ericsson (Publ) Method and system for transmission of headerless data packets over a wireless link
FI111777B (fi) * 2001-01-16 2003-09-15 Nokia Corp IP-datan siirtäminen tietoliikennejärjestelmässä
FI118244B (fi) * 2001-06-27 2007-08-31 Nokia Corp Otsikkokenttien kompressiotunnisteen välittäminen datapakettiyhteydellä
US6874113B2 (en) * 2001-09-17 2005-03-29 Interdigital Technology Corporation Radio resource control-service data unit reception
DE60229482D1 (de) * 2001-11-24 2008-12-04 Lg Electronics Inc Verfahren zur Übertragung von Paketdaten in komprimierter Form in einem Kommunikationssystem
US7031736B2 (en) * 2001-12-03 2006-04-18 Nokia Corporation Method and apparatus of header compression for broadcast services in radio telecommunication system
DE60312432T2 (de) * 2002-05-10 2008-01-17 Innovative Sonic Ltd. Verfahren zur bestimmten Auslösung einer PDCP-Sequenznummern-Synchronisierungsprozedur
US7920590B2 (en) * 2002-07-12 2011-04-05 Spyder Navigations L.L.C. Wireless communications system having built-in packet data compression and support for enabling non-standard features between network elements
US7286536B2 (en) * 2002-10-28 2007-10-23 Nokia Corporation Method and system for early header compression

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2504087C2 (ru) * 2007-10-04 2014-01-10 Нокиа Сименс Нетворкс Ой Способ и устройство для уменьшения системных издержек
RU2464742C2 (ru) * 2008-04-04 2012-10-20 Квэлкомм Инкорпорейтед Выборочное установление однонаправленного канала в расширенном универсальном наземном радиодоступе (e-utra) и расширенной пакетной системе (eps)
US8780814B2 (en) 2008-04-04 2014-07-15 Qualcomm Incorporated Selective bearer establishment in E-utran/EPS
US9307565B2 (en) 2008-04-04 2016-04-05 Qualcomm Incorporated Selective bearer establishment in E-UTRAN/EPS
RU2687217C1 (ru) * 2018-06-20 2019-05-07 Открытое Акционерное Общество "Информационные Технологии И Коммуникационные Системы" Способ предотвращения фрагментации TCP/IP-пакетов при использовании VPLS в сети с коммутацией пакетов

Also Published As

Publication number Publication date
EP1315356B1 (en) 2008-10-22
ATE502472T1 (de) 2011-04-15
AU2002353634A1 (en) 2003-06-10
US8351376B2 (en) 2013-01-08
MA27160A1 (fr) 2005-01-03
JP4309118B2 (ja) 2009-08-05
US7656902B2 (en) 2010-02-02
US20070153788A1 (en) 2007-07-05
JP2003229925A (ja) 2003-08-15
EP1968277A1 (en) 2008-09-10
US20090141715A1 (en) 2009-06-04
US7486699B2 (en) 2009-02-03
ZA200404748B (en) 2005-11-30
ATE412299T1 (de) 2008-11-15
EP1315356A3 (en) 2006-03-22
US20100135216A1 (en) 2010-06-03
AU2006201242B2 (en) 2009-03-19
JP2009005376A (ja) 2009-01-08
US20030123485A1 (en) 2003-07-03
RU2004119304A (ru) 2005-05-10
EP1315356A2 (en) 2003-05-28
US7623549B2 (en) 2009-11-24
JP4808749B2 (ja) 2011-11-02
MXPA04006224A (es) 2004-10-11
DE60229482D1 (de) 2008-12-04
DE60239500D1 (de) 2011-04-28
AU2002353634B2 (en) 2006-04-27
UA82886C2 (en) 2008-05-26
WO2003047189A1 (en) 2003-06-05
AU2006201242A1 (en) 2006-04-13
EP1968277B1 (en) 2011-03-16

Similar Documents

Publication Publication Date Title
RU2303858C2 (ru) Способ передачи пакетных данных в системе связи
US9635142B2 (en) Bi-directional packet data transmission system and method
EP1362446B1 (en) Transfer of ip data in communications system, using several logical connections for compressed fields on the basis of different contexts
EP1405472B1 (en) Transmission of compression identifier of headers on data packet connection
EP1329078B1 (en) Defining header field compression for data packet connection
KR100896484B1 (ko) 이동통신시스템에서 데이터 전송 무선통신방법 및 무선통신장치
EP1337124A2 (en) Context relocation method
EP1372310A1 (en) Apparatus and method for communicating data using header compression
KR20090062758A (ko) 이동통신 시스템에서의 핸드오버 방법 및 장치
RU2316906C2 (ru) Способ передачи пакетных данных в системе связи
KR100765122B1 (ko) 패킷의 헤더압축을 지원하는 통신 시스템에서전체헤더패킷과 압축헤더패킷의 전송 제어 장치와 방법

Legal Events

Date Code Title Description
PC41 Official registration of the transfer of exclusive right

Effective date: 20200723