МОБИЛЬНАЯ СИСТЕМА ПЕРЕДАЧИ ДАННЫХ, УСТРОЙСТВО УПРАВЛЕНИЯ, УСТРОЙСТВО БАЗОВОЙ СТАНЦИИ, СПОСОБ УПРАВЛЕНИЯ СИСТЕМОЙ И СПОСОБ УПРАВЛЕНИЯ УСТРОЙСТВОМ Российский патент 2017 года по МПК H04L29/00 

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

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

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

В 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-UМ). Третий представляет собой прозрачный режим (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 (подготовка к изменению конфигурации радиоканала) или в сообщении RL RECONFIGURATION REQUEST (запрос изменения конфигурации радиоканала).

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

Кроме того, в мобильной системе передачи данных, в соответствии с настоящим примерным вариантом осуществления, протокол MAC-ehs может использоваться, даже если размер RLC PDU имеет фиксированную длину, обеспечивая поддержку совместимости с системой, использовавшейся до 3GPP Release 7. Например, когда выполняют изменение обслуживающей ячейки в результате перемещения UE из области, обслуживаемой Узлом B до 3 GPP Release 7, в область, обслуживаемую Узлом B 12 в соответствии с 3 GPP Release 7 и далее, размер RLC PDU может поддерживаться так, чтобы он имел фиксированную длину. При этом нет необходимости запрашивать обработку RLC, что обеспечивает уменьшение потери данных среди пользователей более высокого порядка (например, UE).

Информация идентификации размера RLC PDU (индикатор размера RLC PDU) используется Узлом B 12 для установки очереди приоритетов. Например, Узел B 12 выполняет управление потоками информации для каждой очереди приоритета, используя информацию идентификации. Детали этого примера будут описаны ниже.

Узел B 12, после приема данных пользователя по нисходящему каналу передачи данных из RNC 11, выполняет оценку общих индикаторов приоритета канала (CmCH-PIs) среди данных MAC-d PDU, и выделяет данные MAC-d PDU в очереди приоритета, ассоциированные с соответствующими данными MAC-d PDU. Здесь такие CmCH-PIs ассоциируют не только с очередями приоритета в Узле B 12, но также и с информацией идентификации размера RLC PDU. Поэтому информация идентификации размера RLC PDU оказывает влияние на выбор длины MAC-d PDU (максимальная длина MAC-d/c PDU) при управлении потоками информации, выполняемом для каждой очереди приоритетов.

Как описано выше, имеет ли длина MAC-d PDU переменную длину или фиксированную длину, можно выбирать для каждой очереди приоритетов, и, таким образом, Узел B 12 может выполнять управление потоками информации для каждой очереди приоритетов, другими словами, в соответствии с ассоциированным приоритетом (CmCH-PI).

CmCH-PI соответствует индикатору приоритета планирования, предоставляемому через NBAP на фиг. 9. CmCH-PI устанавливают и обновляют с помощью RNC 11. Очередь приоритетов представляет собой область сохранения (буфер), в которой временно содержатся данные пользователя, передаваемые по нисходящему каналу из RNC 11. В каждой очереди приоритетов учитываются требования QoS. Примеры требований QoS включают в себя класс трафика и частоту пиков при передаче данных.

Пример изменения 3GPP TS 25.433 в отношении информации идентификации размера RLC PDU, то есть формат размера RLC PDU в приведенном выше описании представлен на фиг. 10.

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

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

Возможные конкретные примеры будут описаны ниже. После приема сообщений 1-3, Узел B 12 детектирует "ненормальное состояние", то есть ненормальный запрос установки, и отбрасывает этот запрос из RNC 11 для отмены процедуры.

1. СООБЩЕНИЕ RL SETUP REQUEST

(1) Если сообщение RADIO LINK SETUP REQUEST (запрос установки радиоканала), принятое из RNC, включает в себя информационный элемент, формат размера DL RLC PDU для очереди с заранее заданным приоритетом, в которой размер RLC PDU был установлен так, что он имеет переменную длину, и информационный элемент, формат размера HS-DSCH MAC-d PDU, который имеет значение, обозначающее, что размер MAC-d PDU имеет фиксированную длину, Узел B передает сообщение RADIO LINK SETUP FAILURE для отмены процедуры запроса из RNC в RNC.

(2) Если сообщение RADIO LINK SETUP REQUEST, принятое из RNC, не включает в себя информационный элемент, Maximum MAC-d PDU Size Extended, для заранее заданной очереди приоритетов, и информационный элемент DL RLC PDU Size Format, который имеет значение, обозначающее, что размер RLC PDU имеет переменную длину, Узел B передает сообщение RADIO LINK SETUP FAILURE (неудачная установка радиоканала), для отброса процедуры запроса из RNC.

(3) Если сообщение RADIO LINK SETUP REQUEST, принимаемое из RNC, включает в себя информационный элемент формата размера HS-DSCH MAC-d PDU Size Format, в котором размер MAC-d PDU был установлен так, что он имеет переменную длину и не включает в себя информационный элемент, DL RLC PDU Size Format, Узел B передает сообщение RADIO LINK SETUP FAILURE для отброса процедуры запроса из RNC.

2. Сообщение RL ADDITION REQUEST

(1) Если сообщение RADIO LINK ADDITION REQUEST (запрос добавления радиоканала), принятое из RNC, включает в себя информационный элемент DL RLC PDU Size Format для заранее заданной очереди приоритетов, в которой размер RLC PDU был установлен так, чтобы он имел переменную длину, и информационный элемент HS-DSCH MAC-d PDU Size Format имел значение, обозначающее, что размер MAC-d PDU имеет фиксированную длину, Узел B передает сообщение RADIO LINK ADDITION FAILURE (неудачное добавление радиоканала) для отброса процедуры запроса из RNC в RNC.

(2) Если сообщение RADIO LINK ADDITION REQUEST, принятое из RNC, не включает в себя информационный элемент Maximum MAC-d PDU Size Extended для заранее заданной очереди приоритетов и информационный элемент DL RLC PDU Size Format имеет значение, обозначающее, что размер RLC PDU имеет переменную длину, Узел B передает сообщение RADIO LINK ADDITION FAILURE для отброса процедуры запроса из RNC.

(3) Если сообщение RADIO LINK ADDITION REQUEST, принятое из RNC, включает в себя информационный элемент HS-DSCH MAC-d PDU Size Format, в котором размер MAC-d PDU был установлен так, чтобы он имел переменную длину, но не включал в себя информационный элемент DL RLC PDU Size Format, базовая станция передает сообщение RADIO LINK ADDITION FAILURE, для отброса процедуры запроса из RNC.

3. Сообщение RL RECONFIGURATION REQUEST

[1] При повторной установке синхронного радиоканала:

(1) Если имеется очередь приоритетов, которая установлена так, что размер RLC PDU имеет переменную длину и не был установлен для использования Maximum MAC-d PDU Size Extended, в новой конфигурации, Узел B передает в RNC сообщение RADIO LINK RECONFIGURATION FAILURE (неудачное изменение конфигурации радиоканала) для отброса процедуры запроса из RNC.

(2) Если существует очередь приоритетов, в которой соответствующий контекст передачи данных узла B был установлен так, что размер MAC-d PDU имеет фиксированную длину и размер RLC PDU имеет переменную длину в новой конфигурации, Узел B передает в RNC сообщение RADIO LINK RECONFIGURATION FAILURE для отброса процедуры запроса из RNC.

(3) Если соответствующий контекст передачи данных узла B был установлен так, что размер MAC-d PDU имеет переменную длину, и не включает в себя информационный элемент, DL RLC PDU Size Format, для заранее заданной очереди приоритета в новой конфигурации, Узел B передает в RNC сообщение RADIO LINK RECONFIGURATION FAILURE, для отброса процедуры запроса из RNC.

[2] При повторном установлении асинхронного радиоканала:

(1) Если существует очередь приоритетов, которая была установлена так, что размер RLC PDU имеет переменную длину, и не была установлена для использования Maximum MAC-d PDU Size Extended в новой конфигурации, Узел B передает в RNC сообщение RADIO LINK RECONFIGURATION FAILURE для отброса процедуры запроса из RNC.

(2) Если существует очередь приоритетов, для которой соответствующий контекст передачи данных Узла B был установлен так, что размер MAC-d PDU имеет фиксированную длину, и размер RLC PDU имеет переменную длину, в новой конфигурации, Узел B передает в RNC сообщение RADIO LINK RECONFIGURATION FAILURE для отброса процедуры запроса из RNC.

(3) Если соответствующий контекст передачи данных Узла B был установлен так, что размер MAC-d PDU имеет переменную длину, и не включает в себя информационный элемент формат размера DL RLC PDU Size Format для заранее заданной приоритетной очереди в новой конфигурации, Узел B передает в RNC сообщение RADIO LINK RECONFIGURATION FAILURE для отброса процедуры запроса из RNC.

Здесь контекст передачи данных узла B представляет собой термин, определенный в 3GPP, и относится к информации данных (контекст), управляемой для каждого мобильного устройства (UE).

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

В описанном выше втором примерном варианте осуществления, как показано на фиг. 8, был описан пример, в котором уведомление, содержащее индикатор размера RLC, который обозначает, имеет ли размер RLC PDU фиксированную длину или переменную длину, предусмотрен через сообщение протокола NBAP. Однако настоящее изобретение не ограничивается этим. Третий примерный вариант осуществления будет описан со ссылкой на пример, в котором расширен запасной бит в HS-DSCH DATA FRAME TYPE 2, в соответствии с протоколом фрейма HS-DSCH, который определен в TS 25.435, и уведомление об индикаторе размера RLC предоставляют посредством одного бита.

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

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

На фиг. 12 показана блок-схема последовательности операций, иллюстрирующая операции мобильной системы передачи данных в соответствии с третьим примерным вариантом осуществления. Как показано на фиг. 12, контроллер 13 вызова в RNC 11 вначале определяет, является ли размер RLC PDU фиксированным или переменным (этап 201). Если размер RLC PDU является фиксированным, контроллер 13 вызова устанавливает индикатор размера RLC, обозначающий, что размер RLC PDU имеет "фиксированную длину", в функциональных модулях 18 протокола фрейма (этап 202). В то же время, если было определено на этапе 201, что размер PDU RLC является переменным, контроллер 13 вызова устанавливает индикатор размера RLC, обозначающий, что размер RLC PDU имеет "переменную длину", в функциональных модулях 18 протокола фрейма (этап 202).

После этого при передаче фрейма данных HS-DSCH DATA FRAME TYPE 2, функциональные модули 18 протокола фрейма в RNC 11 вставляют индикатор размера RLC во второй бит от бита наивысшего порядка в четвертом октете во фрейме (этап 204).

После приема фрейма данных, HS-DSCH DATA FRAME TYPE 2 функциональные модули 23 протокола в Узле-B 12 получают индикатор размера RLC из фрейма, и применяют это значение индикатора для управления потоками (этап 205).

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

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

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

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

Как описано выше, в соответствии с настоящим примерным вариантом осуществления, RNC 11 предоставляет уведомление в виде индикатора размера RLC PDU в Узел B 12 через HS-DSCH DATA FRAME TYPE 2, и после приема HS-DSCH DATA FRAME TYPE 2 Узел B 12 динамически управляет индикатором размера RLC PDU в соответствии с уведомлением через фрейм. Таким образом, настоящий примерный вариант осуществления обеспечивает возможность динамического управления тем, имеет ли размер RLC PDU фиксированную длину или переменную длину.

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

Описанный выше второй примерный вариант осуществления был описан на примере, в котором индикатор размера RLC добавляют к информации потока HS-DSCH MAC-d, как показано на фиг. 9. Однако настоящее изобретение не ограничивается этим. Четвертый примерный вариант осуществления будет описан на примере, в котором "Фиксированный размер MAC-d PDU для MAC-ehs" добавлен, как новое значение для формата размера HS-DSCH MAC-d PDU.

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

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

Для значений формата размера HS-DSCH MAC-d PDU, 3GPP уже был предусмотрен индексированный размер MAC-d PDU для MAC-hs и гибкий размер MAC-d PDU для MAC-ehs. Настоящий примерный вариант осуществления предназначен для введения нового "фиксированного размера MAC-d PDU для MAC-ehs" для MAC-ehs, размер RLC PDU которого имеет фиксированную длину.

В соответствии с настоящим примерным вариантом осуществления, когда формат размера HS-DSCH MAC-d PDU для канала транспортирования HS-DSCH установлен, как "гибкий размер MAC-d PDU", размеры RLC PDU для всех потоков MAC-d в канале транспортирования HS-DSCH имеют переменную длину.

Кроме того, когда формат размера HS-DSCH MAC-d PDU для канала транспортирования HS-DSCH установлен, как "фиксированный размер MAC-d PDU", размеры RLC PDU для всех потоков MAC-d в канале транспортирования HS-DSCH имеют фиксированную длину.

Информация потока HS-DSCH MAC-d, используемая во втором примерном варианте осуществления, представляет собой информационный элемент, обозначающий свойство каждого логического канала, отображаемого в очереди приоритетов. Уведомление в виде индикатора размера RLC PDU через информацию потока HS-DSCH MAC-d обеспечило индикацию того, имеет ли размер RLC PDU фиксированную длину или переменную длину для каждого логического канала. Другими словами, можно смешивать логические каналы, размер RLC PDU которых имеет фиксированную длину, и логические каналы, размер RLC PDU которых имеет переменную длину.

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

В соответствии с настоящим примерным вариантом осуществления, управление о том, имеет ли размер RLC PDU фиксированную длину или переменную длину, может осуществляться каналом транспортирования HS-DSCH, что обеспечивает упрощение обработки в RNC 11 и в Узле B 12 по сравнению со вторым примерным вариантом осуществления.

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

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

В 3GPP Release 8, для HSUPA введен протокол MAC-i/MAC-is для того, чтобы сделать возможным использовать размер RLC PDU с переменной длиной. В 3GPP, в дополнение к протоколу MAC-i/MAC-is, который введен в Release 8, определен протокол MAC-e/MAC-es.

Протокол MAC-i/MAC-is и протокол MAC-e/MAC-es являются взаимно исключающими: только один из протокола MAC-i/MAC-is или протокола MAC-e/MAC-es присутствует в UE. Если размер RLC PDU установлен так, что он имеет переменную длину, необходимо использовать протокол MAC-i/MAC-is.

Кроме того, в протоколе RRC между RNC и UE, информация отображения RB Mapping Info (3 GPP TS 25.331) обеспечивает уведомление о том, имеет ли размер RLC PDU фиксированную длину или переменную длину, и, кроме того, в случае переменной длины, обеспечивает уведомление о минимальном значении и максимальном значении размера RLC PDU.

В то же время протокол NBAP между RNC и Узлом B обеспечивает только предоставление из RNC в Узел B уведомления о максимальном значении размера MAC-d PDU (расширенный IE с максимальным размером MAC-d PDU NBAP) для каждого логического канала, отображаемого в потоке MAC-d. Обычно не выполняют логическое мультиплексирование канала в протоколе MAC-d, и, таким образом, размер MAC-d PDU может быть таким же, как и размер RLC PDU.

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

При передаче данных HSUPA Узел B может использовать MAC-i/MAC-is, и может рассмотреть возможность использования максимального значения размера RLC PDU при его управлении потоками информации. Однако в текущем протоколе NBAP невозможно уведомить, имеет ли размер RLC PDU каждого логического канала, который должен быть мультиплексирован, фиксированную длину или переменную длину, и, если размер RLC PDU имеет переменную длину, невозможно уведомить наименьшее значение размера RLC PDU. Вследствие этого возникает несоответствие в состоянии в отношении размера RLC PDU между Узлом B и RNC, и UE, что может привести к тому, что разрешение становится невозможным соответствующим образом предоставить из Узла B в UE.

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

Кроме того, бывают случаи, когда только незначительное преимущество может быть обеспечено путем установки размера RLC PDU с переменной длиной, такие, как сигналы управления (DCCH: выделенный канал управления). Поэтому в некоторых случаях предпочтительно, чтобы размер RLC PDU данных пользователя при услуге пакетной передачи данных был установлен с переменной длиной, в то время как размер RLC PDU сигнала управления был установлен с фиксированной длиной. В этих случаях, для сигнала управления, предпочтительно использовать MAC-i/MAC-is, в то время как размер RLC PDU установлен с фиксированной длиной; однако в текущем NBAP уведомление о такой установке не может быть предусмотрено.

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

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

Более конкретно, например, Узел B предоставляет UE разрешение, достаточное для передачи данных, с размером RLC PDU, который больше, чем минимальное значение размера RLC PDU, для предотвращения возникновения события, в котором UE, которому предоставлено разрешение, не может передавать данные.

Мобильная система передачи данных, в соответствии с настоящим примерным вариантом осуществления, аналогична системе в соответствии со вторым примерным вариантом осуществления, представленным на фиг. 7, включая в нее RNC 11 и Узел B 12. Однако поскольку настоящий примерный вариант осуществления фокусируется на передаче данных по восходящему каналу передачи данных, функциональный модуль 17 протокола MAC-d и функциональный модуль 24 протокола MAC-ehs не нужны, вместо этого необходим функциональный модуль протокола, воплощающий протокол MAC-i и протокол MAC-is.

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

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

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

В настоящей заявке заявлено преимущество приоритета на основе заявки № 2008-200277 на японский патент, поданной 1 августа 2008 г., полное раскрытие которой приведено здесь в качестве ссылочного материала.

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

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

приемник, который принимает сообщение RADIO LINK ADDITION REQUEST (запрос добавления радиоканала), включающее в себя информацию о формате размера блока данных протокола (PDU) уровня управления радиоканалом (RLC), от устройства управления,

при этом если сообщение RADIO LINK ADDITION REQUEST не включает в себя информацию о максимальном расширенном размере PDU протокола MAC-d уровня управления доступом к среде передачи (МАС) для очереди приоритетов и упомянутая информация о формате размера указывает, что размер PDU RLC является переменным, базовая станция отклоняет процедуру добавления радиоканала.

2. Базовая станция по п.1, при этом базовая станция отклоняет процедуру добавления радиоканала, используя сообщение RADIO LINK ADDITION FAILURE (неудачное добавление радиоканала).

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

принимают сообщение RADIO LINK ADDITION REQUEST (запрос добавления радиоканала), включающее в себя информацию о формате размера блока данных протокола (PDU) уровня управления радиоканалом (RLC), от устройства управления,

отклоняют процедуру добавления радиоканала, если сообщение RADIO LINK ADDITION REQUEST не включает в себя информацию о максимальном расширенном размере PDU протокола MAC-d уровня управления доступом к среде передачи (МАС) для очереди приоритетов и упомянутая информация о формате размера указывает, что размер PDU RLC является переменным.

4. Способ по п.3, в котором базовая станция отклоняет процедуру добавления радиоканала, используя сообщение RADIO LINK ADDITION FAILURE (неудачное добавление радиоканала).