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

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

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

- сохраняют несжатые данные в первом буфере беспроводного устройства; и

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

2. Способ по п.1, дополнительно содержащий этап, на котором:

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

3. Способ по п.1, дополнительно содержащий этапы, на которых:

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

- сохраняют сжатые данные во втором буфере; и

- передают хранящиеся сжатые данные от беспроводного устройства к базовой станции.

4. Способ по п.3, в котором сжатие содержит сжатие заголовков пакетов, образующих несжатые данные.

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

6. Беспроводное устройство для связи с базовой станцией, причем беспроводное устройство содержит:

- первый буфер для хранения несжатых данных; и

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

7. Беспроводное устройство по п.6, дополнительно содержащее:

- преобразователь для преобразования несжатых данных в сжатые данные; и

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

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

9. Беспроводное устройство по п.8, в котором сжатие заголовка зависит от информации обратной связи, принятой от базовой станции.

10. Беспроводное устройство по п.6, в котором отчет о состоянии буфера указывает объем несжатых данных, хранящихся в первом буфере.

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

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

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

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

15. Беспроводное устройство по п.6, в котором отчет о состоянии буфера указывает оценку объема сжатых данных, полученных из несжатых данных, хранящихся в первом буфере.

Описание изобретения к патенту

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

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

УРОВЕНЬ ТЕХНИКИ

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

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

Фиг.1 является блок-схемой, иллюстрирующей сетевую структуру усовершенствованной универсальной системы мобильной связи (E-UMTS). E-UMTS может также упоминаться как система LTE. Сеть связи широко развернута, чтобы обеспечить множество услуг связи, таких как передача голосовых и пакетных данных.

Как проиллюстрировано на фиг.1, сеть E-UMTS включает в себя усовершенствованную наземную сеть радиодоступа UMTS (E-UTRAN) и усовершенствованное пакетное ядро (EPC) и одно или более пользовательское оборудование. E-UTRAN может включать в себя один или более усовершенствованных узлов NodeB (eNodeB или eNB) 20 и большое количество единиц пользовательского оборудования (UE) 10, которые могут быть расположены в одной соте. Один или более шлюзов 30 компонента управления мобильностью E-UTRAN (MME)/эволюции системной архитектуры (SAE) могут быть размещены в конце сети и соединены с внешней сетью.

Используемый здесь термин "нисходящая линия связи" относится к связи от узла eNodeB 20 к UE 10, и термин "восходящая линия связи" относится к связи от UE к узлу eNodeB. UE 10 относится к оборудованию связи, носимому пользователем, и может также упоминаться как мобильная станция (MS), терминал (UT) пользователя, абонентская станция (SS) или беспроводное устройство.

Узел eNodeB 20 обеспечивает конечные пункты плоскости пользователя и плоскости управления для UE 10. Шлюз 30 MME/SME обеспечивает конечный пункт сеанса связи и функцию управления мобильностью для UE 10. Узел eNodeB и шлюз MME/SME могут быть соединены через интерфейс S1.

Узел eNodeB 20 обычно является неподвижной станцией, которая осуществляет связь с UE 10 и может также упоминаться как базовая станция (BS) или пункт доступа. В одной соте может быть развернут один узел eNodeB 20. Интерфейс для передачи трафика пользователя или трафика управления может быть использован между узлами eNodeB 20.

MME обеспечивает различные функции, включающие в себя распределение пейджинговых сообщений по узлам eNodeB 20, управление безопасностью, управление мобильностью в состоянии незанятости, управление однонаправленным каналом SAE, шифрование и защиту целостности сигнализации уровня, не связанного с предоставлением доступа (NAS). Хозяин шлюза SAE обеспечивает различные функции, включающие в себя завершение пакетов U-плоскости по причинам пейджинга и переключение U-плоскости, чтобы поддержать мобильность UE. Для ясности, шлюз 30 MME/SAE будет здесь упоминаться просто как "шлюз", но подразумевается, что этот объект включает в себя шлюз как MME, так и SAE.

Между узлом eNodeB 20 и шлюзом 30 через интерфейс S1 может быть подключено множество узлов. Узлы eNodeB 20 также могут быть соединены друг с другом через интерфейс X2, и соседние узлы eNodeB могут иметь структуру ячеистой сети, которая имеет интерфейс X2.

Фиг.2(a) является блок-схемой, изображающей архитектуру типичной сети E-UTRAN и типичной сети EPC. Как проиллюстрировано, eNodeB 20 может выполнять функции выбора шлюза 30, осуществляя маршрутизацию к шлюзу во время активации управления радиоресурсами (RRC), планирования и передачи пейджинговых сообщений, планирования и передачи информации широкополосного канала управления (BCCH), динамического распределения ресурсов для UE 10 как в восходящей, так и в нисходящей линиях связи, конфигурации и обеспечении измерений в узлах eNodeB, управления однонаправленным радиоканалом, управления радиодоступом (RAC) и управления мобильностью при подключениях в состоянии LTE_ACTIVE. В сети EPC и как отмечалось выше, шлюз 30 может выполнить функции создания пейджинга, управления состоянием LTE_IDLE, шифрования плоскости пользователя, управления однонаправленным каналом эволюции системной архитектуры (SAE), шифрования и защиты целостности сигнализации уровня, не связанного с предоставлением доступа (NAS).

Фиг.2(b) и 2(c) являются блок-схемами, изображающими протокол плоскости пользователя и стек протокола плоскости управления для E-UMTS. Как проиллюстрировано, уровни протокола могут быть разделены на первый уровень (LI), второй уровень (L2) и третий уровень (L3), основываясь на трех более низких уровнях стандартной модели взаимодействия открытых систем (OSI), хорошо известной в технике систем связи.

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

Уровень MAC уровня 2 (L2) обслуживает уровень управления радиолинией (RLC) (который является более высоким уровнем) через логический канал. Уровень RLC уровня 2 (L2) с надежностью поддерживает передачу данных. Следует отметить, что уровень RLC, проиллюстрированный на фиг.2(b) и 2(c), изображен так потому, если функции RLC реализуют и выполняют уровнем MAC, то сам уровень RLC не требуется. Уровень протокола конвергенции пакетных данных (PDCP) уровня 2 (L2) выполняет функцию сжатия заголовков, которая сокращает ненужную информацию управления таким образом, что данные, передаваемые, используя пакеты по Интернет протоколу (IP), такие как IPv4 или IPv6, могут эффективно быть посланы через радиоинтерфейс (беспроводной), который имеет относительно малую ширину полосы.

Уровень управления радиоресурсами (RRC), расположенный в самой нижней части третьего уровня (L3), определяется только в плоскости управления и управляет логическими каналами, транспортными каналами и физическими каналами в отношении конфигурации, реконфигурации и предоставления однонаправленных радиоканалов (RB). Здесь RB означает услугу, предоставленную вторым уровнем (L2) для передачи данных между терминалом и E-UTRAN.

Как проиллюстрировано на фиг.2(b), уровни RLC и MAC (заканчивающиеся в узле eNodeB 20 на стороне сети) могут выполнять такие функции, как планирование, автоматический запрос повторения (ARQ) и гибридный автоматический запрос повторения (HARQ). Уровень по протоколу PDCP (заканчивающийся в узле eNodeB 20 на стороне сети) может выполнять функции плоскости пользователя, такие как сжатие заголовков, защита целостности и шифрование.

Как проиллюстрировано на фиг.2(c), уровни RLC и MAC (заканчивающиеся в узле eNodeB 20 на стороне сети) выполняют те же самые функции, что и для плоскости управления. Как проиллюстрировано, уровень RRC (заканчивающийся в узле eNodeB 20 на стороне сети) может выполнять такие функции, как широковещание, пейджинг, управление подключением RRC, управление однонаправленным радиоканалом (RB), функции мобильности и управление измерениями и отчетность по результатам измерений на UE. Протокол управления NAS (заканчивающийся в MME шлюза 30 на стороне сети) может выполнять такие функции, как управление однонаправленным каналом SAE, аутентификацию, обращение с мобильностью для LTE_IDLE, создание пейджинга в LTE_IDLE и управление безопасностью для сигнализации между шлюзом и UE 10.

Протокол управления NAS может использовать три различных состояния: во-первых, состояние LTE_DETACHED, если нет никакого объекта RRC; во-вторых, состояние LTE_IDLE, если нет никакого соединения RRC в то время, когда хранится минимальная информация UE; и, в-третьих, состояние LTE_ACTIVE, если установлено соединение RRC. Кроме того, состояние RRC может быть разделено на два различных состояния, такие как RRC_IDLE и RRC_CONNECTED.

В состоянии RRC_IDLE UE 10 может принимать широковещательные передачи системной информации и пейджинговой информации, в то время как UE указывает прерывистый прием (DRX), конфигурированный посредством NAS, и UE распределило идентификацию (ID), которая однозначно идентифицирует UE в области слежения. Кроме того, в состоянии RRC-IDLE в узле eNodeB не хранят никакой контекст RRC.

В состоянии RRC_CONNECTED, UE 10 имеет соединение RRC E-UTRAN и контекст в E-UTRAN таким образом, что становится возможным передача и/или прием данных в сеть/из сети (узел eNodeB). Кроме того, UE 10 может послать отчет о качестве канала и информацию обратной связи в узел eNodeB.

В состоянии RRC_CONNECTED E-UTRAN знает соту, к которой принадлежит UE 10. Поэтому сеть может передавать данные к UE 10 и/или принимать данные от UE 10, сеть может управлять мобильностью (передачей обслуживания, хэндовером) UE и сеть может выполнить измерения в соте для соседней соты.

В режиме RRC_IDLE UE 10 определяет цикл пейджинга DRX (прерывистого приема). Конкретно, UE 10 контролирует пейджинговый сигнал в конкретном случае пейджинга для каждого цикла пейджинга DRX для конкретного UE.

Фиг.3 схематически иллюстрирует буферизацию трафика пользователя в восходящей линии связи на уровне 2 на стороне UE. Трафик плоскости пользователя, принимаемый от уровня 3, обычно состоит из IP-пакетов 50 с полезной нагрузкой 51 от верхних прикладных уровней, которая должна быть обработана логикой 55 уровня протокола PDCP. Эти пакеты 50 формируют блоки служебных данных (SDU) по протоколу PDCP, пересылаемые от верхних уровней и хранящиеся в буфере 56 по протоколу PDCP. Каждый пакет 50 имеет заголовок 52, который включает в себя IP-заголовок и, возможно, другие поля заголовка из протокола верхнего уровня, такого как протокол реального времени (RTF) в случае, например, приложения голосовых данных по IP-протоколу (VoIP).

Блоки 60, 70 данных по протоколу PDCP (PDU), созданные уровнем 55 PDCP, пересылают на уровень 80 RLC, где их хранят в буфере RLC 81. Каждый PDU 60, 70 PDCP имеет короткий заголовок 61, 71, включающий в себя порядковый номер PDCP и индикацию типа PDU.

Некоторые блоки PDU 60 по протоколу PDCP (указанные в коротком заголовке 61) переносят трафик пользователя, обычно в форме одного IP-пакета на каждый блок PDU. Заголовок 52 этого IP-пакета сжимают на уровне 55 PDCP (сжатый заголовок 62 показан на фиг.3) посредством алгоритма сжатия заголовков, называемого RoHC (устойчивое к ошибкам сжатие заголовка). Уровень PDCP может также шифровать данные пользователя и добавить код аутентификации сообщения для защиты целостности (MAC-I). Сжатие заголовка основано на том факте, что в IP-заголовке многие из полей не изменяются динамически. Например, во время вызова VoIP целевой IP-адрес и исходный IP-адрес обычно остаются неизменными. Таким образом, этот тип информации необходимо вводить, только когда она изменяется. Схемы RoHC, как известно в технике, могут использовать в своих интересах различные виды избыточности в заголовках протоколов. Смотрите, например, рабочие предложения (RFC) 4995, "The Robust Header Compression (ROHC) Framework", опубликованные в июле 2007 г. Целевой группой по техническим проблемам Интернета (IETF).

Другие PDU 70 по протоколу PDCP в восходящей линии связи (как указано в коротком заголовке 71) являются блоками PDU управления по протоколу PDCP, которые переносят такую информацию управления, как:

- отчет о состоянии пропущенных или подтвержденных блоков SDU по протоколу PDCP по нисходящей линии связи вслед за хэндовером. Такой отчет о состоянии используют равноправным уровнем протокола PDCP в узле eNodeB, обслуживающем новую соту, чтобы определить, какие блоки SDU по протоколу PDCP должны быть переданы заново; и

- информация управления сжатием заголовков, такая как встроеннные данные обратной связи RoHC, созданные алгоритмом сжатия заголовков, чтобы обеспечить ошибкоустойчивость процесса сжатия. Чтобы справиться со сценарием, где пакет, который указывает изменение в поле заголовка, пропущен, приемник может послать такую информацию обратной связи RoHC отправителю таким образом, что критическая информация, например обновления, повторяется. Таким образом, отправитель должен сжать заголовок настолько поздно, насколько возможно, чтобы удостовериться, что существует возможность отреагировать на принятую информацию обратной связи RoHC. На фиг.3 стрелка 82 обозначает обратную связь RoHC, принимаемую UE 10 по каналу нисходящей линии связи и доставляемую алгоритму RoHC уровня 55 по протоколу PDCP, исполняемому для передачи данных пользователя по восходящей линии связи.

Уровень 80 RLC обрабатывает блоки PDU по протоколу PDCP, чтобы управлять пересылкой данных в прозрачном, подтвержденном или неподтвержденном режиме и выполнять соответствующие процедуры автоматического запроса повторения (ARQ). Блоки PDU RLC для каждого логического канала передают на уровень 85 MAC, который добавляет информацию заголовка MAC и выполняет другие функции доступа к среде, такие как процессы планирования или гибридного ARQ (HARQ).

Одной из процедур сигнализации MAC, реализуемой в транспортных каналах восходящей линии связи, является процедура отчета о состоянии буфера. Она используется для обеспечения обслуживающего узла eNodeB 20 информацией об объеме данных восходящей линии связи, буферированных в UE 10. Такая информация, наряду с другой информацией, такой как приоритеты, назначенные различным логическим каналам, полезна для работы алгоритмов планирования в восходящей линии связи на уровне MAC узла eNodeB 20, чтобы определить, каким UE или логическим каналам должны быть предоставлены радиоресурсы в заданный срок. Информация о состоянии буфера указывает объем данных, доступных для передачи. В системе UMTS информация планирования указывает данные, хранящиеся в буфере 81 RLC, как проиллюстрировано блоком 84 на фиг.3, и уровень MAC просит уровень RLC отчитаться об объеме доступных данных таким образом, что отчет об объеме данных может быть сообщен в сеть в отчете о состоянии буфера (BSR), включенном в определенном PDU MAC в восходящей линии связи.

ОПИСАНИЕ ИЗОБРЕТЕНИЯ

Техническая проблема

В проекте LTE, однако, сжатие заголовков используется, чтобы уменьшить объем данных, применяя специальное кодирование IP-заголовка, как указано алгоритмом RoHC. Таким образом, объем данных, посланных равноправному объекту по протоколу PDCP, обычно больше, чем объем данных, посылаемых от PDCP к объекту RLC. Необходимость время от времени вставлять блок PDU управления по протоколу PDCP является другим источником ошибок.

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

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

ТЕХНИЧЕСКОЕ РЕШЕНИЕ

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

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

- хранят несжатые данных в первом буфере беспроводного устройства; и

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

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

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

- хранят сжатые данные во втором буфере; и

- передают сохраненные сжатые данные от беспроводного устройства к базовой станции.

В соответствии с другим вариантом осуществления, способ содержит этапы, на которых:

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

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

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

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

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

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

Дополнительно, информация о данных, доступных для передачи, может также быть послана от UE к сети в рамках других процедур и, в частности, процедур RRC плоскости управления. В частности, измерения объема трафика (TVM) могут быть запрошены узлом eNodeB, управляющим отчетами об измерениях UE. Такие измерения могут быть использованы, например, чтобы запустить изменение состояния для UE для обеспечения подходящего типа канала для передачи данных UE.

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

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

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

Отчет о состоянии буфера может также указывать объем данных, зависящий от размера дополнительных заголовков, добавленных для передачи блоков данных, считываемых из второго буфера, таких как заголовки RLC/MAC.

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

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

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

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

ПРЕИМУЩЕСТВА ИЗОБРЕТЕНИЯ

Настоящее изобретение обладает следующими преимуществами.

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

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

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

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

Фиг.1 является блок-схемой, иллюстрирующей сетевую структуру системы E-UMTS (или LTE).

Фиг.2(a), 2(b) и 2(c) являются блок-схемами, изображающими логическую архитектуру типичных сетевых объектов системы LTE (фиг.2(a)), стека протокола плоскости пользователя (U-плоскости) (фиг.2(b)) и стека протокола плоскости управления (С-плоскости) (фиг.2(c)).

Фиг.3 является схемой, иллюстрирующей расположение буфера относительно стеков протокола плоскости пользователя, изображенных на фиг.2(b).

Фиг.4 является схемой, иллюстрирующей расположение буфера относительно стеков протокола плоскости пользователя, изображенных на фиг.2(b) в варианте осуществления изобретения.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

Каждый раз, когда блок SDU 50 по протоколу PDCP (IP-пакет) считывают из буфера 56 по протоколу PDCP для преобразования в блок PDU 60 по протоколу PDCP, уровень 55 по протоколу PDCP извлекает его из буфера 56. Таким образом, буфер 56 по протоколу PDCP содержит в себе только пакеты пользователей, которые еще не были обработаны на уровне PDCP и, в частности, посредством алгоритма RoHC.

Пока блок SDU 50 по протоколу PDCP не был обработан на уровне 55 по протоколу PDCP, невозможно знать точный размер блока PDU 60 по протоколу PDCP, который будет ему соответствовать, потому что тот размер зависит от некоторой обратной связи RoHC, которую уровень 55 по протоколу PDCP может принимать от равноправного объекта по протоколу PDCP в узле eNodeB. Кроме того, трудно предугадать объем данных, которые будут добавлены в качестве блоков PDU 70 управления по протоколу PDCP (отчет о состоянии подтверждений после хэндовера и/или обратной связи RoHC для обратного направления). Однако, благодаря принципу позднего сжатия заголовка на уровне 55 по протоколу PDCP, данный уровень заполнения буфера 81 RLC может дать мало информации о фактическом объеме данных пользователей, в настоящее время стоящих в очереди для передачи на UE 10: буфер 56 по протоколу PDCP может быть почти пустым или может содержать в себе намного больше данных, чем буфер 56 RLC. Поэтому объем пакетных данных, стоящих в очереди в буфере 56 по протоколу PDCP, является важным параметром для надежного сообщения отчета о состоянии буфера UE.

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

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

Альтернативно, оценка коэффициента сжатия обеспечивается узлом eNodeB. Узел eNodeB может оценить этот коэффициент на основе степени сжатия, наблюдаемой на предыдущих PDU алгоритмом распаковки RoHC, работающим в объекте по протоколу PDCP узла eNodeB.

Когда коэффициент сжатия оценен локально в UE 10, представляющая интерес возможность состоит в том, чтобы сообщать отчет об объеме несжатых данных, содержащихся в буфере 56 по протоколу PDCP, на относительно высокой частоте, например, каждые 100 миллисекунд или около этого, и сообщать отчет о наблюдаемом коэффициенте сжатия на более низкой частоте, например каждую 1 секунду или 10 секунд. Узел eNodeB может затем оценить объем буферированных данных, которые должны быть приняты от UE, умножая последнее принимаемое значение буферного размера на последнее принимаемое значение коэффициента сжатия.

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

Другая возможность состоит в том, чтобы сообщить отчет только о размере данных, которые уже сжаты (блоки PDU 60 по протоколу PDCP), плюс информацию о данных, которые еще не были сжаты, такую как оценка сжатого размера блоков SDU по протоколу PDCP, для которых сжатие еще не было выполнено. Такая оценка может быть основана на данных UE или получена из значения степени сжатия, заданной узлом eNodeB 20. Это позволяет, например, в случае VoIP, если все доступные блоки SDU по протоколу PDCP уже сжаты и находятся в буфере 81 RLC, сообщать отчет о точном объеме данных, возможно, включающем в себя заголовок RLC и MAC.

В целом, оценка размера служебных данных за счет заголовков RLC/MAC может быть включена в BSR, что увеличивает точность отчета.

В типичном варианте осуществления UE сообщает отчет о несжатых данных узлу eNodeB, а именно размер содержимого буфера 56 по протоколу PDCP, а также сжатых данных, а именно размер содержимого буфера 56 RLC или только блоков 60 PDU данных пользователя. Схема планирования MAC в узле eNodeB может затем умножить размер несжатых блоков SDU по протоколу PDCP для каждого однонаправленного радиоканала, который еще не был сжат, на степень сжатия, заданную из узлом eNodeB, и добавить размер блоков PDU по протоколу PDCP, которые все еще ждут передачи, плюс, возможно, служебные сигналы для учета заголовка RLC/MAC.

В варианте осуществления, проиллюстрированном на фиг.4, отчете о состоянии буфера выполняется как функция управления доступом к среде (MAC). Следует понимать, что отчет о состоянии буфера может быть также передан как часть процедуры управления радиоресурсами (RRC).

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

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

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

Промышленная применимость

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