Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством

Иллюстрации

Показать все

Изобретение относится к мобильным системам передачи данных и включает в себя устройство управления и устройство базовой станции. Технический результат заключается в повышении эффективности использования системных ресурсов. Передачу данных между устройством управления и устройством базовой станции выполняют, используя размер данных фиксированной длины и размер данных переменной длины. Устройство управления передает информацию, обозначающую, имеет ли размер данных при передаче данных фиксированную длину или переменную длину. Устройство базовой станции принимает информацию из устройства управления. 5 н. и 9 з.п. ф-лы, 13 ил.

Реферат

Область техники, к которой относится изобретение

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

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

В 3GPP (Проект Партнерства 3-го поколения) был принят стандарт HSDPA (высокоскоростной пакетный доступ для нисходящего канала) для мобильной передачи данных W-CDMA (широкополосный многостанционный доступ с кодовым разделением каналов) (см. непатентный документ 1). В HSDPA используют протокол MAC-hs или протокол MAC-ehs для уровня MAC (управление доступом к среде передачи). HSDPA поддерживает высокоскоростную пакетную передачу данных по нисходящему каналу из RNC (контроллер радиосети) в UE (оборудование пользователя) через Узел-B. При передаче данных HSDPA управление потоками выполняют между RNC (контроллер радиосети) и Узлом-B (базовой станцией).

При управлении потоками Узел-B уведомляет RNC о возможностях передачи данных, и RNC передает данные в пределах этой возможности передачи данных в Узел-B. Здесь, Узел-B определяет возможность передачи данных, учитывая, например, пропускную способность радиоканала, отчет о качестве продукта, предоставляемый UE, приоритет, назначенный на несущую частоту, и состояние пути передачи между RNC и Узлом-B как параметры. Уведомление о пропускной способности при передаче данных предоставляют через управляющее сообщение протокола фрейма, называемое CAPACITY ALLOCATION.

При передаче данных HSDPA существуют три типа случаев, рассматриваемых как режимы передачи данных. Параметры, соответствующие каждому случаю, установлены в RNC и в Узлах B.

На фиг. 1 показана блок-схема, иллюстрирующая пример установки параметров для соответствующих случаев HSDPA. На фиг. 1 показаны примеры установки параметров для соответствующих случаев 1-3. Случай 1 уже был определен в 3GPP Release 5 и далее, и все случаи 2 и 3, как ожидается, будут определены в 3GPP Release 7 и далее.

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

В протоколе MAC-hs не используются ни 64QAM (квадратурная амплитудная манипуляция), ни MIMO (множество входов - множество выходов).

В случае 2, размер RLC PDU имеет фиксированную длину, как и в случае 1, но протокол MAC-ehs используется для уровня MAC. В протоколе MAC-ehs можно использовать 64QAM и MIMO. Также в MAC-ehs, используется способ передачи, называемый Улучшенным Уровнем 2 при передаче данных по нисходящему каналу.

64QAM, которая представляет собой один из способов цифровой модуляции, выражает 64 значения через комбинацию восьми типов фазы и восьми типов амплитуды. MIMO представляет собой технологию передачи данных по радиоканалам для расширения полосы пропускания при передаче данных, используя множество антенн одновременно. В улучшенном уровне 2, протокол MAC-ehs, предусмотренный в Узле B, сегментирует данные пользователя. Улучшенный уровень 2 обеспечивает более эффективную передачу данных по сравнению со способом передачи, в котором данные пользователя разделяют на фиксированную длину в RLC.

В случае 3, размер RLC PDU имеет переменную длину, и для уровня MAC используется протокол MAC-ehs. В этом случае Узел B обозначает максимальную длину размера RLC PDU. RNC может выбирать размер RLC PDU в пределах диапазона, равного или меньше, чем максимальная длина, назначенная Узлом B. При управлении потоками Узел-B может управлять максимальным значением размера RLC PDU.

При управлении потоками в 3 GPP Release 7, в котором был введен протокол MAC-ehs, используется формат, называемый CAPACITY ALLOCATION TYPE 2 (выделение пропускной способности, тип 2), вместо формата, называемого CAPACITY ALLOCATION TYPE 1 (выделение пропускной способности, тип 1), который используется в 3 GPP Release 5.

В пределах фрейма в CAPACITY ALLOCATION TYPE 2 Узел B может управлять следующими четырьмя элементами:

(1) Максимальная длина MAC-d/c PDU (длина MAC-d PDU).

(2) Разрешение на передачу очередного пакета данных HS-DSCH (количество MAC-d PDU, которое может быть передано в течение времени интервала передачи в HS-DSCH).

(3) Интервал HS-DSCH (длительность, в течение которой передают количество MAC-d PDU, обозначенное в соответствии с разрешением на передачу очередного пакета данных HS-DSCH).

(4) Период повторения HS-DSCH (величина подсчета повторений, обозначающая количество повторений упомянутой выше длительности).

Например, когда в радиоканале возникает перегрузка, длина MAC-d/c PDU (максимальная длина MAC-d/c PDU) может быть уменьшена или количество разрешений на передачу очередного пакета данных HS-DSCH может быть уменьшено для уменьшения объема данных, передаваемых по нисходящему каналу. HS-DSCH (высокоскоростной нисходящий совместно используемый канал) представляет собой канал, совместно используемый для множества передач данных HSDPA.

Как описано выше, в случаях 2 и 3, которые должны быть определены в GPP Release 7 и далее, можно использовать 64QAM и MIMO, которые могут не использоваться в и перед 3GPP Release 6.

Между случаями 2 и 3, которые должны быть определены 3 GPP Release 7 и далее, существует различие, состоящее в том, имеет ли размер RLC PDU фиксированную длину или переменную длину.

В случае 3, поскольку размер RLC PDU является переменным, максимальное значение размера RLC PDU может изменяться в диапазоне, равном или меньше 1504 октетов при управлении потоками. В результате такого управления потоками может быть обеспечена более эффективная передача данных в соответствии с изменением состояния передачи данных.

В то же время, случай 2 обеспечивает возможность использования 64QAM и MIMO при управлении потоками, используя существующий и простой алгоритм с фиксированным размером RLC PDU, как в случае 1.

Список литературы

Непатентная литература

Непатентная литература 1: 3GPP TS 25.308 V8.2.0 (2008-05), High Speed Downlink Packet Access (HSDPA), Overall description, Stage 2 (Release 8)

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

Техническая задача

Для применения 64QAM или MIMO необходимо использовать протокол MAC-ehs. В случае, когда используется протокол MAC-ehs, размер RLC PDU может иметь фиксированную длину или переменную длину, и, таким образом, для обеспечения работы RLC необходимо установить размер RLC PDU так, чтобы он имел фиксированную длину или переменную длину.

Однако в протоколе NBAP (Узел B, Часть приложения, 3GPP TS25.433), который представляет собой текущий протокол управления вызовом, RNC не может уведомлять Узел B о том, имеет ли размер RLC PDU фиксированную длину или переменную длину. На фиг. 2 показана блок-схема, иллюстрирующая параметры протокола NBAP. Эта блок-схема представляет собой блок-схему, показанную в 3GPP TS 24.4339.2.1.31IA. Как показано на фиг. 2, можно видеть, что отсутствует информационный элемент, уведомляющий об установке, имеет ли размер RLC PDU фиксированную длину или переменную длину, и, таким образом, уведомление о такой установке не может быть предусмотрено в протоколе NBAP. Следовательно, существует проблема, состоящая в том, что несоответствие в состояниях установки, имеет ли размер RLC PDU фиксированную длину или переменную длину, может возникать между RNC и Узлом B.

Когда используется протокол MAC-ehs, текущий NBAP предполагает, что формат IE размера HS-DSCH MAC-d PDU имеет "гибкий размер MAC-d PDU". Следовательно, RNC устанавливает размер RLC PDU так, чтобы он имел фиксированную длину, и узел-B устанавливает размер RLC PDU так, чтобы он имел переменную длину, в результате чего может возникнуть несоответствие в состояниях между RNC и Узлом B.

Если размер RLC PDU установлен так, чтобы он имел переменную длину, Узел B может передавать инструкцию на изменение размера RLC PDU в RNC при управлении потоками. Однако RNC не может изменить размер RLC PDU, поскольку размер RLC PDU установлен так, чтобы он имел фиксированную длину.

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

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

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

В примере на фиг. 3 размер RLC PDU составляет 82 байта, используется протокол MAC-ehs и используется MIMO и 64QAM.

В этом случае, расширенный IE с максимальным размером MAC-d PDU NBAP, который обозначает максимальное значение размера MAC-d PDU, установлен как 82 байта.

Как показано в последовательности на фиг. 4, вначале RNC устанавливает размер RLC PDU так, чтобы он имел фиксированную длину (этап 901). Когда используется MAC-ehs, не выполняют какое-либо логическое мультиплексирование канала на уровне MAC-d и, таким образом, не предусматривают заголовок MAC-d. В соответствии с этим, в данном примере, размер MAC-d PDU равен размеру RLC PDU (этап 902).

RNC подготавливает сообщение NBAP: RL SETUP REQUEST (запрос установки радиоканала) (этап 903), и передает это сообщение в узел B (этап 904). Такое сообщение NBAP: RL SETUP REQUEST, включает в себя расширенный IE с максимальным размером MAC-d PDU NBAP, установленный на 82 байта, что представляет собой максимальное значение размера MAC-d PDU.

В результате приема сообщения NBAP: RL SETUP REQUEST, Узел B распознает, что максимальное значение размера MAC-d PDU составляет 82 байта (этап 904) и устанавливает это максимальное значение вместе с информацией о 64QAM, MIMO и MAC-ehs (этап 905).

После установления HSDPA начинается управление потоками.

Здесь предполагается, что Узел B принимает решение установить размер MAC-d PDU на размер, меньший, чем 82, байта при управлении потоками информации, учитывая загруженность радиоканала (этап 908). Узел B устанавливает максимальное значение размера MAC-d PDU как новое значение, меньшее, чем 82 байта (этап 909), и передает фрейм управления HS-DSCH CAPACITY ALLOCATION TYPE 2, включающий в себя расширенный IE с максимальным размером MAC-d PDU, в котором было установлено это значение, в RNC (этап 910). Такой фрейм представляет собой фрейм, используемый для Узла B, для уведомления RNC об информации управления по управлению потоками. Примеры информации управления при управлении потоками включают в себя длину MAC-d/c PDU, разрешения на передачу очередного пакета данных и интервал передачи.

Поскольку размер RLC PDU установлен как фиксированная длина, RNC не может передавать данные с длиной, короче, чем эта фиксированная длина, в результате чего передача данных останавливается (этап 911).

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

Решение задачи

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

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

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

в которой устройство базовой станции принимает информацию из устройства управления.

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

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

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

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

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

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

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

в котором устройство базовой станции принимает информацию из устройства управления.

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

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

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

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

На фиг. 2 показана схема, иллюстрирующая параметры в протоколе NBAP.

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

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

На фиг. 5 показана блок-схема, иллюстрирующая конфигурацию RNC 11 в соответствии с первым примерным вариантом осуществления.

На фиг. 6 показана блок-схема, иллюстрирующая конфигурацию Узла B 12 в соответствии с первым примерным вариантом осуществления.

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

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

На фиг. 9 показана схема, предназначенная для описания общего содержания сообщения протокола NBAP.

На фиг. 10 показана схема, иллюстрирующая пример изменения 3GPP TS 25.433.

На фиг. 11 показана схема, иллюстрирующая пример HS-DSCH DATA FRAME TYPE 2 в соответствии с третьим примерным вариантом осуществления.

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

На фиг. 13 показана схема, иллюстрирующая пример определения формата размера HS-DSCH MAC-d PDU в соответствии с четвертым примерным вариантом осуществления.

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

Примерные варианты осуществления будут подробно описаны со ссылкой на чертежи. Система радиопередачи данных, описанная как примерный вариант осуществления, представляет собой мобильную систему передачи данных W-CDMA в соответствии с 3GPP.

(Первый примерный вариант осуществления)

На фиг. 5 иллюстрируется конфигурация RNC 11 в соответствии с первым примерным вариантом осуществления.

Как показано на фиг. 5, RNC 11 включает в себя коммуникатор 11A, который осуществляет обмен данными с устройством базовой станции, используя размер данных фиксированной длины и размер данных переменной длины, и передатчик 11B, который обеспечивает уведомление о (переданной) информации, указывающее, имеет ли размер данных переданных данных фиксированную длину или переменную длину, в устройство базовой станции (Узел B 12).

В соответствии с этим, в настоящем примерном варианте осуществления, уведомление об информации, обозначающей, является ли размер данных при передаче данных фиксированным или переменным (информация идентификации), может быть предоставлено из RNC 11 в Узел B 12.

На фиг. 6 иллюстрируется конфигурация Узла B 12 в соответствии с первым примерным вариантом осуществления.

Как показано на фиг. 6, Узел B 12 включает в себя приемник 12B, который принимает информацию, обозначающую, имеет ли размер данных при передаче данных фиксированную длину или переменную длину, из устройства управления (RNC 11), и коммуникатор 12A, который выполняет обмен данными с устройством управления, используя размер данных фиксированной длины и размер данных переменной длины.

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

(Второй примерный вариант осуществления)

На фиг. 7 показана блок-схема, иллюстрирующая конфигурацию системы мобильной связи в соответствии со вторым примерным вариантом осуществления. Настоящий примерный вариант осуществления представляет собой вариант осуществления конфигурации RNC 11 в соответствии с первым примерным вариантом осуществления, показанным на фиг. 5, и конфигурации Узла B 11 в соответствии с первым примерным вариантом осуществления, показанным на фиг. 6. Как показано на фиг. 7, мобильная система передачи данных в соответствии с настоящим примерным вариантом осуществления включает в себя RNC 11 и Узел B 12. RNC 11, который соединен с CN (базовой сетью) и Узлом B 11 (не показан), управляет Узлом B 12, обеспечивая передачу данных пользователя через UE (не показано). Узел B 12, который соединен с UE (не показано) через радиоканал, передает данные пользователя между UE и RNC 11.

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

RNC 11 предоставляет уведомление о (переданной) информации идентификации, обозначающее, установлен ли размер передаваемых данных для данных нисходящего канала как фиксированная длина или переменная длина для Узла B 12. Уведомление, представляющее эту информацию идентификации, предоставляют посредством сообщения в соответствии с протоколом управления вызовом, завершаемым RNC 11 и Узлом B 12.

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

Узел B 12 работает на основе информации идентификации, предоставляемой RNC 11. Например, Узел B 12 выполняет управление потоками информации при передаче данных на основе информация идентификации. При управлении потоками информации, Узел B 12 адаптивно изменяет множество элементов в соответствии со статусом передачи данных и уведомляет RNC 11 об этих элементах.

RNC 11 передает данные нисходящего канала передачи данных в Узел B 12 в пределах объема ограничений, наложенных предусмотренными элементами, и в соответствии с форматом размера данных нисходящего канала передачи, предоставляемым в Узел B 12 через информацию идентификации (то есть имеет ли размер передаваемых данных нисходящего канала фиксированную длину или переменную длину). Следовательно, количеством данных нисходящего канала и т.п. можно соответствующим образом управлять в соответствии со статусом передачи данных, обеспечивая правильные меры противодействия, например, перегрузке.

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

Если информация идентификации, предоставляемая RNC 11, обозначает, что размер передаваемых данных имеет фиксированную длину, Узел B 12 выполняет управление потоками с фиксированным размером передаваемых данных среди этих элементов.

В настоящем примерном варианте осуществления информация идентификации может представлять собой, например, однобитную информацию. Более конкретно, бит "1" обозначает, что размер RLC PDU имеет переменную длину, и бит "0" обозначает, что размер RLC PDU имеет фиксированную длину.

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

Кроме того, если уведомление о том, имеет ли размер передаваемых данных фиксированную длину или переменную длину, предоставляют из RNC 11 в Узел B 12, когда устанавливают радиоканал, Узел B 12 выполняет управление потоками с фиксированным размером данных передачи на основе результата распознавания, совместно используемого с RNC 11, немедленно после установления радиоканала. Аналогично, если уведомление о том, имеет ли размер передаваемых данных фиксированную длину или переменную длину, будет предоставлено, когда радиоканал изменяют или добавляют, Узел B 12 может выполнять управление потоками с фиксированным размером передаваемых данных непосредственно после изменения или добавления радиоканала.

Как снова показано на фиг. 7, RNC 11 включает в себя оконечный модуль 19 пути передачи, контроллер 13 вызова и процессор 14 протокола управления вызовом, которые включены в уровень управления, оконечный модуль 15 интерфейса Iu, функциональные модули 16 протокола RLC, функциональный модуль 17 протокола MAC-d и функциональные модули 18 протокола фрейма, которые включены в уровень пользователя.

Контроллер 13 вызова выполняет различного рода обработку в отношении управления вызовом. Управление вызовом включает в себя установление вызова в случае возникновения исходящего вызова из UE или входящего вызова в UE и разъединение установленного вызова. Управление вызовом также включает в себя установление и разъединение передачи данных HSDPA с помощью UE. При управлении вызовом, контроллер 13 вызова передает/принимает сообщения управления вызовом в/из Узла B 12, UE или CN.

Процессор 14 протокола управления вызовом компилирует и анализирует сообщения в соответствии с протоколом NBAP, который представляет собой протокол управления вызовом, совместно используемый с Узлом B 12, под управлением контроллера 13 вызова.

Например, когда устанавливают передачу данных HSDPA, контроллер 13 вызова передает/принимает сообщение протокола NBAP в/из Узла B 12 через процессор 14 протокола управления вызовом для выполнения установок для MIMO, 64QAM или MAC-ehs.

Оконечный модуль 15 интерфейса Iu завершает интерфейс Iu в CN. Более конкретно, оконечный модуль 15 интерфейса Iu обеспечивает, например, функции PDCP (протокола схождения пакетных данных), установленного в 3GPP TS 25.323, протокола уровня пользователя Iu, установленного в 3GPP TS 25.415, и протокола GTP-U, обозначенного в 3GPP TS 29.060.

Для примера нисходящего канала передачи данных оконечный модуль 15 интерфейса Iu извлекает RLC PDU из сигнала нисходящего канала, принятого из CN высокого порядка через интерфейс Iu, и передает RLC PDU в функциональные модули 16 протокола RLC. Для примера восходящего канала передачи данных оконечный модуль 15 интерфейса Iu передает данные восходящего канала передачи из функциональных модулей 16 протокола RLC в CN через интерфейс Iu.

Функциональные модули 16 протокола RLC обеспечивают функцию RLC, установленную в 3 GPP TS 25.322. Функция RLC представляет собой функцию, которая выполняет различного рода обработку, относящуюся к управлению радиоканалом. Функциональные модули 16 протокола RLC выполняют обработку данных, переданных/принятых UE, в соответствии с протоколом RLC, посредством функции RLC. Три типа режимов определены в способе передачи RLC. Первый представляет собой признанный режим (ниже сокращенно называется RLC-AM). Второй режим называется непризнанным режимом (RLC-UM). Третий представляет собой прозрачный режим (RLC-ТМ).

В режиме RLC-AM, до 3 GPP Release 6, размер RLC PDU (модуль данных протокола) имел фиксированную длину, и данные пользователя сегментировали на уровне RLC.

Однако в 3 GPP Release 7 в HSDPA была введена функция, называемая Улучшенным уровнем 2. Для Узла B 12 используют протокол MAC-ehs вместо протокола MAC-hs. Вместо сегментирования данных в соответствии с протоколом RLC в RNC 11 данные высокого порядка сегментируют в соответствии с протоколом MAC-ehs в Узле B 12, обеспечивая предоставление гибких данных RLC-AM с переменной длиной, в дополнение к RLC-AM с фиксированной длиной. В случае переменной длины данные с максимальным размером RLC PDU, составляющим 1503 октета, передают из RNC 11 в Узел B 12.

Функциональный модуль 17 протокола MAC-d воплощает протокол MAC-d, который представляет собой одну из функций MAC, установленную в соответствии с 3GPP TS 25.321. Протокол MAC-d представляет собой часть протокола для уровня MAC, и весь протокол для уровня MAC включает в себя этот протокол MAC-d и протокол MAC-hs или протокол MAC-ehs. Протокол MAC-d обеспечивает возможность мультиплексирования множества логических каналов из множества функциональных модулей 16 протокола RLC. Однако не выполняется какое-либо мультиплексирование логического канала, когда Узел B 12 использует MAC-ehs.

Функциональные модули 18 протокола фрейма воплощают функцию протокола фрейма HS-DSCH, установленную в 3GPP TS 25.435. Протокол фрейма HS-DSCH представляет собой протокол для выполнения генерирования и сегментирования фрейма HS-DSCH, используемого в HSDPA. Функциональные модули 18 протокола в RNC 11 генерируют фреймы данных для нисходящего канала передачи.

При высокоскоростной передаче данных с использованием 64QAM или MIMO в качестве типа фрейма используется HS-DSCH DATA FRAME TYPE 2. В соответствии с этим, функциональные модули 18 протокола фрейма генерируют фреймы данных для HS-DSCH DATA FRAME TYPE 2.

Кроме того, функциональные модули 18 протокола фрейма выполняют обработку для управления потоками между функциональными модулями 18 протокола фрейма и функциональными модулями 23 протокола фрейма в Узле B 12.

Например, после детектирования взаимных помех в радиоканале недостаточной мощности передачи и/или перегрузки канала передачи для интерфейса Iub функциональные модули 23 протокола фрейма в Узле B 12 передают HS-DSCH CAPACITY ALLOCATION TYPE 2 в функциональные модули 18 протокола фрейма в RNC 11, предоставляя, таким образом, инструкцию на подавление передачи фрейма данных по нисходящему каналу данных в RNC 11.

И наоборот, в случае ослабления перегрузки и т.д. функциональные модули 23 протокола фрейма в Узле B 12 передают HS-DSCH CAPACITY ALLOCATION TYPE 2 в функциональные модули 18 протокола фрейма в RNC 11, разрешая, таким образом, увеличить передачу фрейма данных по нисходящему каналу передачи данных в RNC 11.

Инструкции по подавлению и увеличению фрейма данных по нисходящему каналу передачи данных заданы в соответствии с предписанием MAC-d/c длины PDU разрешением на передачу очередного пакета данных или интервала передачи.

Функциональные модули 18 протокола фрейма в RNC 11 передают данные по HS-DSCH DATA FRAME TYPE 2 в соответствии с длиной MAC-d/c PDU, разрешением на передачу очередного пакета данных или интервала передачи, предоставляемых в соответствии с HS-DSCH CAPACITY ALLOCATION TYPE 2, принятым из функциональных модулей 23 протокола фрейма в Узле B 12.

Оконечный модуль 19 пути передачи передает/принимает данные в формате, соответствующем носителю транспортирования по однонаправленному каналу передачи данных между RNC 11 и Узлом B 12 (интерфейс Iub) в/из оконечного модуля 20 пути передачи в Узле B 12. Для носителя транспортирования, например, используется ATM (асинхронный режим передачи) или IP (протокол Интернет).

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

И снова обращаясь в фиг. 7, Узел B 12 включает в себя оконечный модуль 20 пути передачи, радиопередатчик/приемник 25, функциональный модуль 21 протокола NBAP и контроллер 22 вызова, которые включены в уровень управления, и функциональные модули 23 протокола фрейма и функциональный модуль 24 протокола MAC-ehs, которые включены в уровень пользователя.

Оконечный модуль 20 пути передачи обращен к модулю 19 завершения пути передачи в RNC 11 через пути передачи (интерфейс Iub) между Узлом B 12 и RNC 11 и передает/принимает данные в формате, соответствующем носителю транспортирования в/из оконечного модуля 19 пути передачи в RNC 11.

Функциональный модуль 21 протокола NBAP компилирует и анализирует сообщения протокола NBAP, передаваемые/принимаемые в/из RNC 11 под управлением контроллера 22 вызова.

Контроллер 22 вызова выполняет различного рода обработку в отношении управления вызовом. При управлении вызовом контроллер 22 вызова передает/принимает сообщения управления вызовом в/из RNC 11 или UE.

Функциональные модули 23 протокола фрейма, которые обращены к функциональным модулям 18 протокола фрейма в RNC 11, воплощают функцию протокола фрейма HS-DSCH. Более конкретно, функциональные модули 23 протокола фрейма принимают фрейм данных HS-DSCH DATA FRAME TYPE 2 в соответствии с протоколом фрейма HS-DSCH из функциональных модулей 18 протокола фрейма в RNC 11, получают MAC-d в фрейме и передают данные MAC-d PDU в функциональный модуль 24 протокола MAC-ehs.

Кроме того, как описано выше, функциональные модули 23 протокола выполняют обработку для управления потоками между функциональными модулями 23 протокола фрейма и функциональными модулями 18 протокола фрейма в RNC 11.

Функциональный модуль 24 протокола MAC-ehs сегментирует данные из RNC 11 и передает эти сегментированные данные в UE через радиопередатчик/приемник 25. В результате выполнения функциональным модулем 24 протокола MAC-ehs в Узле B 12 сегментирования данных можно избежать неэффективного заполнения на уровне RLC в RNC 11.

Радиопередатчик/приемник 25, который соединен с UE через радиоканал, передает/принимает сообщения управления вызовом из контроллера 22 вызова и данные пользователя из функционального модуля 24 протокола MAC-ehs.

На фиг. 8 показана блок-схема последовательности операций, иллюстрирующая работу мобильной системы передачи данных в соответствии со вторым примерным вариантом осуществления. В мобильной системе передачи данных, в соответствии с настоящим примерным вариантом осуществления, когда радиоканал устанавливают, изменяют или добавляют, уведомление о том, имеет ли размер RLC PDU фиксированную длину или переменную длину, предоставляют из RNC 11 в Узел B 12. На фиг. 8 иллюстрируется последовательность обработки, когда устанавливают радиоканал. Кроме того, здесь предоставлена работа системы от момента, когда уведомление о том, имеет ли размер RLC PDU фиксированную длину или переменную длину предоставляют из RNC 11 в Узел B 12, до момента, когда Узел B 12 выполняет управление потоками информации в соответствии с этим уведомлением.

На фиг. 8 показан случай, в котором режим RLC представляет собой режим RLC-AM, контроллер 13 вызова в RNC 11 вначале определяет, является ли размер RLC PDU фиксированным или переменным (этап 101).

Если размер RLC PDU является фиксированным, контроллер 13 вызова устанавливает индикатор размера RLC, обозначающий, что размер RLC PDU имеет "фиксированную длину" в функциональных модулях 16 протокола RLC (этап 102). Далее контроллер 13 вызова устанавливает размер RLC PDU как размер MAC-d PDU (этап 103). Кроме того, контроллер 13 вызова устанавливает индикатор размера RLC на "фиксированную длину" (этап 104).

В то же время, если на этапе 101 было определено, что размер RLC PDU является переменным, контроллер 13 вызова устанавливает индикатор размера RLC, обозначающий, что размер RLC PDU имеет "переменную длину", в функциональные модули 16 протокола RLC (этап 105). Затем контроллер 13 вызова устанавливает максимальное значение размера RLC PDU, как размер MAC-d PDU (этап 106). Кроме того, контроллер 13 вызова устанавливает индикатор размера RLC как "переменная длина" (этап 107).

Затем, после этапа 104 или 107, процессор 14 протокола управления вызовом компилирует сообщение NBAP RL SETUP REQUEST, в котором, например, установлено использование MIMO и 64QAM, индикатора размера MAC-d PDU и RLC (этап 108), и передает это сообщение в Узел B 12 (этап 109). Такой индикатор размера RLC обеспечивает возможность уведомления о том, имеет ли размер RLC PDU фиксированную длину или переменную длину для предоставления из RNC 11 в Узел B 12.

На фиг. 9 показана схема для описания обзора сообщения протокола NBAP. На фиг. 9 показано, что индикатор размера RLC, который представляет собой новый параметр, добавлен к схеме информационных элементов в 3GPP TS 25.433 9.2.1.311 A. Имеет ли размер RLC фиксированную длину или переменную длину, установлено в этом индикаторе.

После приема сообщения протокола NBAP, контроллер 22 вызова в Узле B 12 получает размер MAC-d PDU из сообщения (этап 110). Контроллер 22 вызова затем получает индикатор размера RLC и передает значение этого индикатора в управление потоками информации в функциональных модулях 23 протокола фрейма (этап 111). Кроме того, контроллер 22 вызова устанавливает информацию, относящуюся, например, к тому, используется или нет протокол MAC-ehs в функциональном модуле 24 протокола MAC-ehs (этап 112).

Функциональные модули 23 протокола фрейма, которые выполняют управление потоками, начинают управление потоками после детектирования, например, перегрузки в радиоканале (этап 113). При управлении потоками информации, функциональные модули 23 протокола фрейма вначале проверяют индикатор размера RLC (этап 114).

Если размер RLC PDU имеет фиксированную длину, функциональные модули 23 протокола фрейма управляют другими параметрами при поддержании фиксированной длины MAC-d PDU Length IE (этап 115). Функциональные модули 23 протокола ограничивают, например, разрешение на передачу очередного пакета данных, интервал передачи или период повторения без изменений MAC-d PDU Length IE, вырабатывая, таким образом, меры противодействия перегрузке радиоканала.

В то же время, если на этапе 114 было определено, что размер RLC PDU имеет переменную длину, функциональные модули 23 протокола фрейма управляют различного рода параметрами, включенными в MAC-d PDU Length IE (этап 116).

Инструкцию управления потоками из функциональных модулей 23 протокола фрейма предоставляют в RNC 11 через сообщение HS-DSCH CAPACITY ALLOCATION TYPE 2 (этап 117). Функциональные модули 18 протокола в RNC 11 управляют передачей данных по нисходящему каналу в соответствии с инструкцией из функциональных модулей 23 протокола фрейма в Узле B 12 (этап 118).

Поскольку здесь иллюстрируется последовательность для случая, когда установлен радиоканал, индикатор размера RLC был установлен в сообщении NBAP RL SETUP REQUEST. Для другого примера, если добавлен радиоканал, индикатор размера RCL PDU может быть установлен в сообщении NBAP RL ADDITION REQUEST (запрос добавления радиоканала). Кроме того, если радиоканал изменяется, индикатор размера RCL PDU может быть установлен в сообщении NBAP RL RECONFIGURATION PREPARE (подготовка к изменению конфигурации радиоканала)