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

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

Info

Publication number
RU2611721C1
RU2611721C1 RU2015154993A RU2015154993A RU2611721C1 RU 2611721 C1 RU2611721 C1 RU 2611721C1 RU 2015154993 A RU2015154993 A RU 2015154993A RU 2015154993 A RU2015154993 A RU 2015154993A RU 2611721 C1 RU2611721 C1 RU 2611721C1
Authority
RU
Russia
Prior art keywords
size
mac
rlc
pdu
radio channel
Prior art date
Application number
RU2015154993A
Other languages
English (en)
Inventor
Йосио УЕДА
Садафуку ХАЯСИ
Original Assignee
Нек Корпорейшн
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Нек Корпорейшн filed Critical Нек Корпорейшн
Application granted granted Critical
Publication of RU2611721C1 publication Critical patent/RU2611721C1/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H04L47/365—Dynamic adaptation of the packet size
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/02—Access restriction performed under specific conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/02—Access restriction performed under specific conditions
    • H04W48/06—Access restriction performed under specific conditions based on traffic conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/29—Control channels or signalling for resource management between an access point and the access point controlling device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/12—Interfaces between hierarchically different network devices between access points and access point controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/12—Access point controller devices

Abstract

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

Description

Область техники, к которой относится изобретение
Настоящее изобретение относится к мобильной системе передачи данных, предназначенной для передачи данных, используя размер данных с фиксированной длиной или переменной длиной.
Уровень техники
В 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 г., полное раскрытие которой приведено здесь в качестве ссылочного материала.

Claims (40)

1. Базовая станция, содержащая:
приемник, который принимает сообщение RADIO LINK RECONFIGURATION REQUEST (запрос переконфигурирования радиоканала), включающее в себя информацию о формате размера блока данных протокола (PDU) уровня управления радиоканалом (RLC), от устройства управления,
при этом если в новой конфигурации содержится очередь приоритетов, которая установлена таким образом, что размер PDU RLC является переменным, и не установлена для использования максимального расширенного размера PDU протокола MAC-d уровня управления доступом к среде передачи (MAC), базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE (неудачное переконфигурирование радиоканала).
2. Базовая станция по п. 1, при этом если в новой конфигурации содержится очередь приоритетов, для которой контекст передачи данных Узла В (Node В) установлен таким образом, что размер PDU MAC-d является фиксированным и размер PDU RLC является переменным, базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE.
3. Базовая станция по п. 1 или 2, при этом информация о формате размера PDU RLC включает в себя информацию, указывающую, является ли размер PDU RLC фиксированным.
4. Базовая станция по п. 1, при этом информация о формате размера PDU RLC используется для очереди приоритетов.
5. Базовая станция по п. 1, при этом сообщение RADIO LINK RECONFIGURATION REQUEST передается, когда процедура переустановления асинхронного радиоканала инициируется.
6. Устройство управления, содержащее:
передатчик, который передает сообщение RADIO LINK RECONFIGURATION REQUEST (запрос переконфигурирования радиоканала), включающее в себя информацию о формате размера блока данных протокола (PDU) уровня управления радиоканалом (RLC), на базовую станцию,
при этом если в новой конфигурации содержится очередь приоритетов, которая установлена таким образом, что размер PDU RLC является переменным, и не установлена для использования максимального расширенного размера PDU протокола MAC-d уровня управления доступом к среде передачи (MAC), базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE (неудачное переконфигурирование радиоканала).
7. Устройство управления по п. 6, при этом если в новой конфигурации содержится очередь приоритетов, для которой контекст передачи данных Узла В (Node В) установлен таким образом, что размер PDU MAC-d является фиксированным и размер PDU RLC является переменным, базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE.
8. Устройство управления по п. 6 или 7, при этом информация о формате размера PDU RLC включает в себя информацию, указывающую, является ли размер PDU RLC фиксированным.
9. Устройство управления по п. 6, при этом информация о формате размера PDU RLC используется для очереди приоритетов.
10. Устройство управления по п. 6, при этом сообщение RADIO LINK RECONFIGURATION REQUEST передается, когда процедура переустановления асинхронного радиоканала инициируется.
11. Терминал, содержащий:
средство связи, которое осуществляет связь с базовой станцией, которая принимает сообщение RADIO LINK RECONFIGURATION REQUEST (запрос переконфигурирования радиоканала), включающее в себя информацию о формате размера блока данных протокола (PDU) уровня управления радиоканалом (RLC), от устройства управления,
при этом если в новой конфигурации содержится очередь приоритетов, которая установлена таким образом, что размер PDU RLC является переменным, и не установлена для использования максимального расширенного размера PDU протокола MAC-d уровня управления доступом к среде передачи (MAC), базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE (неудачное переконфигурирование радиоканала).
12. Терминал по п. 11, при этом если в новой конфигурации содержится очередь приоритетов, для которой контекст передачи данных Узла В (Node В) установлен таким образом, что размер PDU MAC-d является фиксированным и размер PDU RLC является переменным, базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE.
13. Терминал по п. 11 или 12, при этом информация о формате размера PDU RLC включает в себя информацию, указывающую, является ли размер PDU RLC фиксированным.
14. Терминал по п. 11, при этом информация о формате размера PDU RLC используется для очереди приоритетов.
15. Терминал по п. 11, при этом сообщение RADIO LINK RECONFIGURATION REQUEST передается, когда процедура переустановления асинхронного радиоканала инициируется.
16. Система мобильной связи, содержащая:
базовую станцию; и
устройство управления, при этом
устройство управления включает в себя передатчик, который передает сообщение RADIO LINK RECONFIGURATION REQUEST (запрос переконфигурирования радиоканала), включающее в себя информацию о формате размера блока данных протокола (PDU) уровня управления радиоканалом (RLC), на базовую станцию,
если в новой конфигурации содержится очередь приоритетов, которая установлена таким образом, что размер PDU RLC является переменным, и не установлена для использования максимального расширенного размера PDU протокола MAC-d уровня управления доступом к среде передачи (MAC), базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE (неудачное переконфигурирование радиоканала).
17. Система мобильной связи по п. 16, при этом если в новой конфигурации содержится очередь приоритетов, для которой контекст передачи данных Узла В (Node В) установлен таким образом, что размер PDU MAC-d является фиксированным и размер PDU RLC является переменным, базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE.
18. Система мобильной связи по п. 16 или 17, при этом сообщение RADIO LINK RECONFIGURATION REQUEST передается, когда процедура переустановления асинхронного радиоканала инициируется.
19. Способ, содержащий этапы, на которых:
принимают сообщение RADIO LINK RECONFIGURATION REQUEST (запрос переконфигурирования радиоканала), включающее в себя информацию о формате размера блока данных протокола (PDU) уровня управления радиоканалом (RLC); и
отклоняют процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE (неудачное переконфигурирование радиоканала), если в новой конфигурации содержится очередь приоритетов, которая установлена таким образом, что размер PDU RLC является переменным, и не установлена для использования максимального расширенного размера PDU протокола MAC-d уровня управления доступом к среде передачи (MAC).
20. Способ по п. 19, дополнительно содержащий этап, на котором отклоняют процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE, если в новой конфигурации содержится очередь приоритетов, для которой контекст передачи данных Узла В (Node В) установлен таким образом, что размер PDU MAC-d является фиксированным и размер PDU RLC является переменным.
21. Способ, содержащий этап, на котором:
передают сообщение RADIO LINK RECONFIGURATION REQUEST (запрос переконфигурирования радиоканала), включающее в себя информацию о формате размера блока данных протокола (PDU) уровня управления радиоканалом (RLC), на базовую станцию,
при этом если в новой конфигурации содержится очередь приоритетов, которая установлена таким образом, что размер PDU RLC является переменным, и не установлена для использования максимального расширенного размера PDU протокола MAC-d уровня управления доступом к среде передачи (MAC), базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE (неудачное переконфигурирование радиоканала).
22. Способ по п. 21, в котором если в новой конфигурации содержится очередь приоритетов, для которой контекст передачи данных Узла В (Node В) установлен таким образом, что размер PDU MAC-d является фиксированным и размер PDU RLC является переменным, базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE.
23. Способ, содержащий этап, на котором:
осуществляют связь с базовой станцией, которая принимает сообщение RADIO LINK RECONFIGURATION REQUEST (запрос переконфигурирования радиоканала), включающее в себя информацию о формате размера блока данных протокола (PDU) уровня управления радиоканалом (RLC),
при этом если в новой конфигурации содержится очередь приоритетов, которая установлена таким образом, что размер PDU RLC является переменным, и не установлена для использования максимального расширенного размера PDU протокола MAC-d уровня управления доступом к среде передачи (MAC), базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE (неудачное переконфигурирование радиоканала).
24. Способ по п. 23, в котором если в новой конфигурации содержится очередь приоритетов, для которой контекст передачи данных Узла В (Node В) установлен таким образом, что размер PDU MAC-d является фиксированным и размер PDU RLC является переменным, базовая станция отклоняет процедуру переустановления асинхронного радиоканала, используя сообщение RADIO LINK RECONFIGURATION FAILURE.
RU2015154993A 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством RU2611721C1 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008-200277 2008-08-01
JP2008200277 2008-08-01

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
RU2013108898/07A Division RU2574345C2 (ru) 2008-08-01 2013-02-27 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством

Publications (1)

Publication Number Publication Date
RU2611721C1 true RU2611721C1 (ru) 2017-02-28

Family

ID=41610236

Family Applications (6)

Application Number Title Priority Date Filing Date
RU2011107746/07A RU2486698C2 (ru) 2008-08-01 2009-05-14 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2012135474/07A RU2529008C2 (ru) 2008-08-01 2012-08-17 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154991A RU2635108C2 (ru) 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154993A RU2611721C1 (ru) 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154994A RU2613334C1 (ru) 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154992A RU2635548C2 (ru) 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством

Family Applications Before (3)

Application Number Title Priority Date Filing Date
RU2011107746/07A RU2486698C2 (ru) 2008-08-01 2009-05-14 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2012135474/07A RU2529008C2 (ru) 2008-08-01 2012-08-17 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154991A RU2635108C2 (ru) 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством

Family Applications After (2)

Application Number Title Priority Date Filing Date
RU2015154994A RU2613334C1 (ru) 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154992A RU2635548C2 (ru) 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством

Country Status (12)

Country Link
US (8) US9113392B2 (ru)
EP (5) EP2315471B1 (ru)
JP (11) JP5223922B2 (ru)
KR (7) KR101497853B1 (ru)
CN (5) CN104301940B (ru)
AU (1) AU2009277764B2 (ru)
BR (12) BR122015007062A2 (ru)
CA (1) CA2732689C (ru)
ES (5) ES2635430T3 (ru)
HK (1) HK1182871A1 (ru)
RU (6) RU2486698C2 (ru)
WO (1) WO2010013526A1 (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2742348C1 (ru) * 2017-05-12 2021-02-05 Нокиа Текнолоджиз Ой Функция и сигнализация разбиения сеанса протокольных блоков данных

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2393373A1 (en) * 2002-07-15 2004-01-15 Anthony Gerkis Apparatus, system and method for the transmission of data with different qos attributes.
CA2732689C (en) 2008-08-01 2014-10-28 Nec Corporation Mobile communication system, control device, base station device, system control method and device control method
TWI423710B (zh) * 2010-10-15 2014-01-11 Acer Inc 行動通訊裝置、系統、以及連線建立方法
CN102469631B (zh) * 2010-11-05 2016-07-06 中兴通讯股份有限公司 Ue能力的发送方法、传递方法和系统及无线网络控制器
KR20120120775A (ko) * 2011-04-25 2012-11-02 주식회사 팬택 무선통신 시스템에서 제어 정보의 다중 전송을 동적으로 제어하는 방법 및 장치
IN2014KN01157A (ru) 2011-11-09 2015-10-16 Ericsson Telefon Ab L M
CN103297211B (zh) * 2012-02-29 2016-01-20 华为技术有限公司 单独的上行高速专用物理控制信道的建立方法及装置
CN103162024A (zh) * 2013-03-25 2013-06-19 中联重科股份有限公司 输送管
KR101438630B1 (ko) 2013-04-15 2014-09-05 현대자동차 주식회사 선택적 촉매 환원(scr) 시스템의 우레아 분사 노즐의 막힘 방지 방법
CN105471763B (zh) * 2014-09-04 2020-09-15 中兴通讯股份有限公司 控制报文传输方法及装置
WO2017028017A1 (zh) * 2015-08-14 2017-02-23 华为技术有限公司 通信的方法、网络设备和用户设备
CN108602711B (zh) 2015-12-21 2021-09-10 康宁股份有限公司 低碱金属含量的硼硅酸盐玻璃
JP7429197B2 (ja) * 2019-01-09 2024-02-07 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 基地局、端末、送信方法及び受信方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001103093A (ja) * 1999-09-30 2001-04-13 Sharp Corp データ伝送方法及びデータ伝送装置
US20060072503A1 (en) * 2004-09-30 2006-04-06 Samsung Electronics Co., Ltd. Method and apparatus for transmitting uplink non-scheduled data in a mobile communication system
WO2006103136A1 (en) * 2005-04-01 2006-10-05 Ipwireless Inc Flow control in a cellular communication system
RU2322761C1 (ru) * 2004-03-12 2008-04-20 Самсунг Электроникс Ко., Лтд. Передатчик и приемник для пакета данных в системе беспроводной связи

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NZ232222A (en) 1989-01-27 1993-03-26 British Telecomm Alternate burst communication for cordless phones: burst formats
FI104143B1 (fi) 1997-07-31 1999-11-15 Nokia Networks Oy Menetelmä tietoliikenneresurssien kontrolloimiseksi
GB2355623B (en) * 1999-10-19 2003-07-16 Ericsson Telefon Ab L M Packet transmission in a UMTS network
ES2442871T3 (es) * 2000-04-07 2014-02-14 Core Wireless Licensing S.à.r.l. Transmisión de unidades de datos de protocolo a través del control de enlace de radiocomunicaciones transparente
RU2242092C2 (ru) * 2001-07-06 2004-12-10 Самсунг Электроникс Ко., Лтд. Способ установки в исходное состояние объекта уровня управления доступом к среде в системе связи с широкополосным множественным доступом с кодовым разделением каналов, использующей высокоскоростной пакетный доступ к нисходящей линии связи
WO2003019960A1 (en) * 2001-08-21 2003-03-06 Nokia Corporation Transmission of data within a communications network
KR20030022929A (ko) * 2001-09-11 2003-03-19 한빛전자통신 주식회사 3지피피 시스템의 알엔씨에서 호 서비스 장치 및 방법
KR100747464B1 (ko) 2002-01-05 2007-08-09 엘지전자 주식회사 고속하향링크패킷접속（ｈｓｄｐａ）시스템을 위한타이머를 이용한 교착상황 회피방법
KR100547845B1 (ko) 2002-02-07 2006-01-31 삼성전자주식회사 고속 순방향 패킷 접속 방식을 사용하는 통신 시스템에서서빙 고속 공통 제어 채널 셋 정보를 송수신하는 장치 및방법
KR100876765B1 (ko) * 2002-05-10 2009-01-07 삼성전자주식회사 이동 통신 시스템에서 데이터 재전송 장치 및 방법
TWI540863B (zh) * 2002-05-10 2016-07-01 無線創新信號信託公司 以容量分佈為基礎之認識流控制
FR2850828B1 (fr) 2003-01-31 2005-04-29 Evolium Sas Procede pour la gestion de la qualite de service dans un systeme de radiocommunications mobiles
CN101335922B (zh) * 2003-06-11 2012-09-12 株式会社Ntt都科摩 数据包通信方法以及控制装置
KR100516554B1 (ko) * 2003-08-25 2005-09-22 삼성전자주식회사 고속 순방향 패킷 접속 통신 시스템에서 프로토콜 데이터유닛 처리 방법
WO2005053170A2 (en) 2003-11-24 2005-06-09 Interdigital Technology Corporation Method and apparatus for compiling a protocol data unit
KR100539930B1 (ko) * 2003-12-22 2005-12-28 삼성전자주식회사 부호분할다중접속 이동통신시스템에서 데이터 전송 최적화를 위한 전송 포맷 선택 방법
KR100520146B1 (ko) * 2003-12-22 2005-10-10 삼성전자주식회사 고속 순방향 패킷 접속 통신 시스템에서 데이터 처리장치및 방법
CN1710829A (zh) * 2004-06-18 2005-12-21 北京三星通信技术研究有限公司 在wcdma系统的增强上行专用信道中支持低数据速率的方法
KR100678941B1 (ko) 2004-09-03 2007-02-07 삼성전자주식회사 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법및 그 방법을 이용하는 무선 디바이스
EP1672941B1 (en) 2004-12-15 2007-11-14 Matsushita Electric Industrial Co., Ltd. Support of guaranteed bit-rate traffic for uplink transmissions
KR100918435B1 (ko) 2005-01-31 2009-09-24 삼성전자주식회사 무선 통신 시스템에서 데이터 트래픽 제어 시스템 및 방법
KR100762647B1 (ko) 2005-03-31 2007-10-01 삼성전자주식회사 기지국 장치 및 이를 이용한 무선 자원 관리 방법
WO2007024168A1 (en) * 2005-08-26 2007-03-01 Telefonaktiebolaget L M Ericsson (Publ) Flow control in umts
CN100442773C (zh) * 2005-11-07 2008-12-10 华为技术有限公司 通过高速下行分组接入技术hsdpa传输ip报文的方法
KR101216751B1 (ko) 2006-02-07 2012-12-28 엘지전자 주식회사 이동 통신 시스템에서 식별자를 이용한 충돌 회피 방법
CN100426799C (zh) * 2006-02-28 2008-10-15 华为技术有限公司 一种高速下行包接入硬切换方法和系统
CN101039170B (zh) * 2006-03-15 2011-08-03 华为技术有限公司 支持数据包重传分割级联的方法
JP2007300508A (ja) 2006-05-01 2007-11-15 Ntt Docomo Inc 基地局、移動局および通信方法
JP4923849B2 (ja) * 2006-08-21 2012-04-25 富士通株式会社 無線受信装置
JP4781939B2 (ja) 2006-08-21 2011-09-28 富士通株式会社 無線通信装置
JP5140975B2 (ja) * 2006-09-14 2013-02-13 富士通株式会社 移動通信システム及びその通信方法
US8503423B2 (en) * 2007-02-02 2013-08-06 Interdigital Technology Corporation Method and apparatus for versatile MAC multiplexing in evolved HSPA
AU2008214411B2 (en) * 2007-02-02 2012-02-02 Interdigital Technology Corporation Method and apparatus for controlling a handover between UTRA R6 cells and R7 cells
TWI452885B (zh) * 2007-02-02 2014-09-11 Interdigital Tech Corp 可變ｒｌｃ ｐｄｕ大小之增強ｒｌｃ方法及裝置
EP2299639A3 (en) * 2007-02-06 2011-05-11 Telefonaktiebolaget L M Ericsson (Publ) Method and device for high speed downlink packet access
JP4726820B2 (ja) 2007-02-20 2011-07-20 Ｙｋｋ株式会社 スライドファスナー用スライダー
BRPI0808308A2 (pt) * 2007-03-16 2014-07-01 Interdigital Tech Corp Arquitetura de controle de link de reconhecimento de moto de rádio e método de sistema de hspa evoluído.
AU2008227111B2 (en) * 2007-03-16 2011-09-01 Interdigital Technology Corporation Wireless communication method and apparatus for supporting reconfiguration of radio link control parameters
CN101355547B (zh) * 2007-07-23 2011-06-15 鼎桥通信技术有限公司 一种媒体接入控制专用信道数据包大小的配置方法及装置
CN101355439B (zh) * 2007-07-27 2010-12-01 鼎桥通信技术有限公司 用户设备能力的控制方法、系统及无线网络控制器
KR101586550B1 (ko) * 2007-09-28 2016-01-20 라쿠텐 인코포레이티드 업링크 프로토콜 변경을 지원하기 위한 방법 및 장치
CA2732689C (en) 2008-08-01 2014-10-28 Nec Corporation Mobile communication system, control device, base station device, system control method and device control method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001103093A (ja) * 1999-09-30 2001-04-13 Sharp Corp データ伝送方法及びデータ伝送装置
RU2322761C1 (ru) * 2004-03-12 2008-04-20 Самсунг Электроникс Ко., Лтд. Передатчик и приемник для пакета данных в системе беспроводной связи
US20060072503A1 (en) * 2004-09-30 2006-04-06 Samsung Electronics Co., Ltd. Method and apparatus for transmitting uplink non-scheduled data in a mobile communication system
WO2006103136A1 (en) * 2005-04-01 2006-10-05 Ipwireless Inc Flow control in a cellular communication system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2742348C1 (ru) * 2017-05-12 2021-02-05 Нокиа Текнолоджиз Ой Функция и сигнализация разбиения сеанса протокольных блоков данных
US11576222B2 (en) 2017-05-12 2023-02-07 Nokia Technologies Oy Protocol data unit session splitting function and signaling

Also Published As

Publication number Publication date
KR101450489B1 (ko) 2014-10-15
ES2606634T3 (es) 2017-03-24
CN103476063A (zh) 2013-12-25
EP2600650B1 (en) 2016-09-07
US20150036491A1 (en) 2015-02-05
CN104301941A (zh) 2015-01-21
BR122014019674A2 (pt) 2016-02-10
CN103476063B (zh) 2016-08-10
RU2613334C1 (ru) 2017-03-16
BR122015007063A2 (pt) 2016-02-10
CN104301940A (zh) 2015-01-21
EP2603035B1 (en) 2014-08-06
BRPI0911022A2 (pt) 2015-12-29
EP2600651B1 (en) 2016-09-07
KR101450488B1 (ko) 2014-10-13
JP6248991B2 (ja) 2017-12-20
KR20140146223A (ko) 2014-12-24
RU2012135474A (ru) 2014-02-27
BR122015021031A2 (pt) 2019-08-27
KR20120123728A (ko) 2012-11-09
KR20130036339A (ko) 2013-04-11
US9565121B2 (en) 2017-02-07
EP2315471A1 (en) 2011-04-27
JP5263432B2 (ja) 2013-08-14
CA2732689A1 (en) 2010-02-04
JP5700148B2 (ja) 2015-04-15
EP2315471A4 (en) 2012-10-24
CN104301942A (zh) 2015-01-21
RU2635108C2 (ru) 2017-11-09
JP5783316B2 (ja) 2015-09-24
KR20130041213A (ko) 2013-04-24
CN104301941B (zh) 2018-04-20
AU2009277764A1 (en) 2010-02-04
US20140140299A1 (en) 2014-05-22
US20160197838A1 (en) 2016-07-07
AU2009277764B2 (en) 2014-12-04
KR20110038161A (ko) 2011-04-13
JP5495199B2 (ja) 2014-05-21
KR101333855B1 (ko) 2013-11-27
US20180013622A1 (en) 2018-01-11
BR122015021029A2 (pt) 2019-08-27
JP2014140206A (ja) 2014-07-31
JP2013211923A (ja) 2013-10-10
EP2605578A1 (en) 2013-06-19
ES2632397T3 (es) 2017-09-12
RU2013108898A (ru) 2014-09-10
US9247485B2 (en) 2016-01-26
CA2732689C (en) 2014-10-28
KR101497891B1 (ko) 2015-03-03
RU2015154991A (ru) 2017-06-27
US9113392B2 (en) 2015-08-18
CN104301940B (zh) 2018-04-24
JPWO2010013526A1 (ja) 2012-01-05
JP2012239206A (ja) 2012-12-06
CN102113369B (zh) 2016-06-08
CN104301942B (zh) 2018-04-03
KR101497853B1 (ko) 2015-03-04
EP2603035A1 (en) 2013-06-12
BR122015007062A2 (pt) 2016-02-10
JP6624183B2 (ja) 2019-12-25
ES2606179T3 (es) 2017-03-23
WO2010013526A1 (ja) 2010-02-04
EP2600650A1 (en) 2013-06-05
US20140369306A1 (en) 2014-12-18
US9247486B2 (en) 2016-01-26
JP2014060743A (ja) 2014-04-03
BR122015021026A2 (pt) 2019-08-27
BR122015021024A2 (pt) 2019-08-27
US20170099186A1 (en) 2017-04-06
KR20130093158A (ko) 2013-08-21
RU2529008C2 (ru) 2014-09-27
RU2011107746A (ru) 2012-09-10
KR101450487B1 (ko) 2014-10-13
EP2315471B1 (en) 2017-04-05
US9787541B2 (en) 2017-10-10
US20150036490A1 (en) 2015-02-05
US20110122802A1 (en) 2011-05-26
JP2013009376A (ja) 2013-01-10
JP2015233309A (ja) 2015-12-24
RU2486698C2 (ru) 2013-06-27
JP5354128B2 (ja) 2013-11-27
BR122015021028A2 (pt) 2019-08-27
JP5338999B2 (ja) 2013-11-13
JP5223922B2 (ja) 2013-06-26
US10404536B2 (en) 2019-09-03
BR122013013478A2 (pt) 2016-02-10
JP2018050326A (ja) 2018-03-29
US9307480B2 (en) 2016-04-05
HK1182871A1 (en) 2013-12-06
JP5403118B2 (ja) 2014-01-29
EP2605578B1 (en) 2017-05-03
KR101377836B1 (ko) 2014-03-26
BR122015021023A2 (pt) 2019-08-27
ES2635430T3 (es) 2017-10-03
JP2015043613A (ja) 2015-03-05
RU2015154992A (ru) 2017-06-23
US9072029B2 (en) 2015-06-30
JP2013211924A (ja) 2013-10-10
ES2493169T3 (es) 2014-09-11
KR20130036340A (ko) 2013-04-11
JP2013138494A (ja) 2013-07-11
EP2600651A1 (en) 2013-06-05
CN102113369A (zh) 2011-06-29
RU2635548C2 (ru) 2017-11-14
JP5403181B2 (ja) 2014-01-29
BR122015007068A2 (pt) 2019-08-20

Similar Documents

Publication Publication Date Title
RU2611721C1 (ru) Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2574345C2 (ru) Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
AU2014246623B2 (en) Mobile communication system, control device, base station device, system control method and device control method