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

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

Info

Publication number
RU2486698C2
RU2486698C2 RU2011107746/07A RU2011107746A RU2486698C2 RU 2486698 C2 RU2486698 C2 RU 2486698C2 RU 2011107746/07 A RU2011107746/07 A RU 2011107746/07A RU 2011107746 A RU2011107746 A RU 2011107746A RU 2486698 C2 RU2486698 C2 RU 2486698C2
Authority
RU
Russia
Prior art keywords
data
base station
size
station device
control device
Prior art date
Application number
RU2011107746/07A
Other languages
English (en)
Other versions
RU2011107746A (ru
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 Нек Корпорейшн
Publication of RU2011107746A publication Critical patent/RU2011107746A/ru
Application granted granted Critical
Publication of RU2486698C2 publication Critical patent/RU2486698C2/ru

Links

Images

Classifications

    • 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
    • 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
    • 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
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

Изобретение относится к системам связи. Технический результат заключается в усовершенствовании управления потоком данных. Мобильная система передачи данных включает в себя устройство управления и устройство базовой станции. Передачу данных между устройством управления и устройством базовой станции выполняют, используя размер данных фиксированной длины и размер данных переменной длины. Устройство управления передает информацию, обозначающую, имеет ли размер данных при передаче данных фиксированную длину или переменную длину. Устройство базовой станции принимает информацию из устройства управления. 7 н. и 18 з.п. ф-лы, 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-UM). Третий представляет собой прозрачный режим (RLC-ТМ).
В режиме RLC-AM, до 3 GPP Release 6, размер RLC PDU (модуль данных протокола) имел фиксированную длину, и данные пользователя сегментировали на уровне RLC.
Однако в 3 GPP Release 7 в HSDPA была введена функция, называемая Улучшенным уровнем 2. Для Узла B 12 используют протокол MAC-ehs, вместо протокола MAC-hs. Вместо сегментирования данных в соответствии с протоколом RLC в RNC 11 данные высокого порядка сегментируют в соответствии с протоколом MAC-ehs в Узле B 12, обеспечивая предоставление гибких данных RLC-AM с переменной длиной, в дополнение к RLC-AM с фиксированной длиной. В случае переменной длины, данные с максимальным размером RLC PDU, составляющим 1503 октета, передают из RNC 11 в Узел B 12.
Функциональный модуль 17 протокола MAC-d воплощает протокол MAC-d, который представляет собой одну из функций MAC, установленную в соответствии с 3GPP TS 25.321. Протокол MAC-d представляет собой часть протокола для уровня MAC, и весь протокол для уровня MAC включает в себя этот протокол MAC-d, и протокол MAC-hs или протокол MAC-ehs. Протокол MAC-d обеспечивает возможность мультиплексирования множества логических каналов из множества функциональных модулей 16 протокола RLC. Однако не выполняется какое-либо мультиплексирование логического канала, когда Узел B 12 использует MAC-ehs.
Функциональные модули 18 протокола фрейма воплощают функцию протокола фрейма HS-DSCH, установленную в 3GPP TS 25.435. Протокол фрейма HS-DSCH представляет собой протокол для выполнения генерирования и сегментирования фрейма HS-DSCH, используемого в HSDPA. Функциональные модули 18 протокола в RNC 11 генерируют фреймы данных для нисходящего канала передачи.
При высокоскоростной передаче данных с использованием 64QAM или MIMO, в качестве типа фрейма используется HS-DSCH DATA FRAME TYPE 2. В соответствии с этим функциональные модули 18 протокола фрейма генерируют фреймы данных для HS-DSCH DATA FRAME TYPE 2.
Кроме того, функциональные модули 18 протокола фрейма выполняют обработку для управления потоками между функциональными модулями 18 протокола фрейма и функциональными модулями 23 протокола фрейма в Узле B 12.
Например, после детектирования взаимных помех в радиоканале, недостаточной мощности передачи и/или перегрузки канала передачи для интерфейса Iub, функциональные модули 23 протокола фрейма в Узле B 12 передают HS-DSCH CAPACITY ALLOCATION TYPE 2 в функциональные модули 18 протокола фрейма в RNC 11, предоставляя, таким образом, инструкцию на подавление передачи фрейма данных по нисходящему каналу данных в RNC 11.
И, наоборот, в случае ослабления перегрузки и т.д., функциональные модули 23 протокола фрейма в Узле B 12 передают HS-DSCH CAPACITY ALLOCATION TYPE 2 в функциональные модули 18 протокола фрейма в RNC 11, разрешая, таким образом, увеличить передачу фрейма данных по нисходящему каналу передачи данных в RNC 11.
Инструкции по подавлению и увеличению фрейма данных по нисходящему каналу передачи данных заданы в соответствии с предписанием MAC-d/c длины PDU разрешением на передачу очередного пакета данных или интервала передачи.
Функциональные модули 18 протокола фрейма в RNC 11 передают данные по HS-DSCH DATA FRAME TYPE 2 в соответствии с длиной MAC-d/c PDU, разрешением на передачу очередного пакета данных или интервала передачи, предоставляемых в соответствии с HS-DSCH CAPACITY ALLOCATION TYPE 2, принятым из функциональных модулей 23 протокола фрейма в Узле B 12.
Оконечный модуль 19 пути передачи передает/принимает данные в формате, соответствующем носителю транспортирования по однонаправленному каналу передачи данных между RNC 11 и Узлом B 12 (интерфейс Iub) в/из оконечного модуля 20 пути передачи в Узле B 12. Для носителя транспортирования, например, используется ATM (асинхронный режим передачи) или IP (протокол Интернет).
Например, когда существуют две услуги пакетной передачи данных, имеются логические каналы для соответствующих услуг пакетной передачи данных. В функциональном модуле 17 протокола MAC-d эти логические каналы не мультиплексируют, и, таким образом, имеются также транспортные носители для соответствующих услуг пакетной передачи данных.
И снова обращаясь в фиг. 7, Узел B 12 включает в себя оконечный модуль 20 пути передачи, радиопередатчик/приемник 25, функциональный модуль 21 протокола NBAP и контроллер 22 вызова, которые включены в уровень управления, и функциональные модули 23 протокола фрейма и функциональный модуль 24 протокола MAC-ehs, которые включены в уровень пользователя.
Оконечный модуль 20 пути передачи обращен к модулю 19 завершения пути передачи в RNC 11 через пути передачи (интерфейс Iub) между Узлом B 12 и RNC 11, и передает/принимает данные в формате, соответствующем носителю транспортирования в/из оконечного модуля 19 пути передачи в RNC 11.
Функциональный модуль 21 протокола NBAP компилирует и анализирует сообщения протокола NBAP, передаваемые/принимаемые в/из RNC 11 под управлением контроллера 22 вызова.
Контроллер 22 вызова выполняет различного рода обработку в отношении управления вызовом. При управлении вызовом контроллер 22 вызова передает/принимает сообщения управления вызовом в/из RNC 11 или UE.
Функциональные модули 23 протокола фрейма, которые обращены к функциональным модулям 18 протокола фрейма в RNC 11, воплощают функцию протокола фрейма HS-DSCH. Более конкретно, функциональные модули 23 протокола фрейма принимают фрейм данных HS-DSCH DATA FRAME TYPE 2 в соответствии с протоколом фрейма HS-DSCH из функциональных модулей 18 протокола фрейма в RNC 11, получают MAC-d в фрейме, и передают данные MAC-d PDU в функциональный модуль 24 протокола MAC-ehs.
Кроме того, как описано выше, функциональные модули 23 протокола выполняют обработку для управления потоками, между функциональными модулями 23 протокола фрейма и функциональными модулями 18 протокола фрейма в RNC 11.
Функциональный модуль 24 протокола MAC-ehs сегментирует данные из RNC 11 и передает эти сегментированные данные в UE через радиопередатчик/приемник 25. В результате выполнения функциональным модулем 24 протокола MAC-ehs в Узле B 12 сегментирования данных, можно избежать неэффективного заполнения на уровне RLC в RNC 11.
Радиопередатчик/приемник 25, который соединен с UE через радиоканал, передает/принимает сообщения управления вызовом из контроллера 22 вызова и данные пользователя из функционального модуля 24 протокола MAC-ehs.
На фиг. 8 показана блок-схема последовательности операций, иллюстрирующая работу мобильной системы передачи данных в соответствии со вторым примерным вариантом осуществления. В мобильной системе передачи данных, в соответствии с настоящим примерным вариантом осуществления, когда радиоканал устанавливают, изменяют или добавляют уведомление о том, имеет ли размер RLC PDU фиксированную длину или переменную длину, предоставляют из RNC 11 в Узел B 12. На фиг. 8 иллюстрируется последовательность обработки, когда устанавливают радиоканал. Кроме того, здесь предоставлена работа системы, от момента, когда уведомление о том, имеет ли размер RLC PDU фиксированную длину или переменную длину, предоставляют из RNC 11 в Узел B 12, до момента, когда Узел B 12 выполняет управление потоками информации в соответствии с этим уведомлением.
На фиг.8 показан случай, в котором режим RLC представляет собой режим RLC-AM, контроллер 13 вызова в RNC 11 вначале определяет, является ли размер RLC PDU фиксированным или переменным (этап 101).
Если размер RLC PDU является фиксированным, контроллер 13 вызова устанавливает индикатор размера RLC, обозначающий, что размер RLC PDU имеет "фиксированную длину" в функциональных модулях 16 протокола RLC (этап 102). Далее контроллер 13 вызова устанавливает размер RLC PDU, как размер MAC-d PDU (этап 103). Кроме того, контроллер 13 вызова устанавливает индикатор размера RLC на "фиксированную длину" (этап 104).
В то же время, если на этапе 101 было определено, что размер RLC PDU является переменным, контроллер 13 вызова устанавливает индикатор размера RLC, обозначающий, что размер RLC PDU имеет "переменную длину", в функциональные модули 16 протокола RLC (этап 105). Затем контроллер 13 вызова устанавливает максимальное значение размера RLC PDU, как размер MAC-d PDU (этап 106). Кроме того, контроллер 13 вызова устанавливает индикатор размера RLC как "переменная длина" (этап 107).
Затем, после этапа 104 или 107, процессор 14 протокола управления вызовом компилирует сообщение NBAP RL SETUP REQUEST, в котором, например, установлено использование MIMO и 64QAM, индикатор размера MAC-d PDU и RLC (этап 108), и передает это сообщение в Узел B 12 (этап 109). Такой индикатор размера RLC обеспечивает возможность уведомления о том, имеет ли размер RLC PDU фиксированную длину или переменную длину, для предоставления из RNC 11 в Узел B 12.
На фиг.9 показана схема для описания обзора сообщения протокола NBAP. На фиг. 9 показано, что индикатор размера RLC, который представляет собой новый параметр, добавлен к схеме информационных элементов в 3GPP TS 25.433 9.2.1.311 A. Имеет ли размер RLC фиксированную длину или переменную длину, установлено в этом индикаторе.
После приема сообщения протокола NBAP, контроллер 22 вызова в Узле B 12 получает размер MAC-d PDU из сообщения (этап 110). Контроллер 22 вызова затем получает индикатор размера RLC и передает значение этого индикатора в управление потоками информации в функциональных модулях 23 протокола фрейма (этап 111). Кроме того, контроллер 22 вызова устанавливает информацию, относящуюся, например, к тому, используется или нет протокол MAC-ehs, в функциональном модуле 24 протокола MAC-ehs (этап 112).
Функциональные модули 23 протокола фрейма, которые выполняют управление потоками, начинают управление потоками после детектирования, например, перегрузки в радиоканале (этап 113). При управлении потоками информации, функциональные модули 23 протокола фрейма вначале проверяют индикатор размера RLC (этап 114).
Если размер RLC PDU имеет фиксированную длину, функциональные модули 23 протокола фрейма управляют другими параметрами при поддержании фиксированной длины MAC-d PDU Length IE (этап 115). Функциональные модули 23 протокола ограничивают, например, разрешение на передачу очередного пакета данных, интервал передачи или период повторения без изменений MAC-d PDU Length IE, вырабатывая, таким образом, меры противодействия перегрузке радиоканала.
В то же время, если на этапе 114 было определено, что размер RLC PDU имеет переменную длину, функциональные модули 23 протокола фрейма управляют различного рода параметрами, включенными в MAC-d PDU Length IE (этап 116).
Инструкцию управления потоками из функциональных модулей 23 протокола фрейма предоставляют в RNC 11 через сообщение HS-DSCH CAPACITY ALLOCATION TYPE 2 (этап 117). Функциональные модули 18 протокола в RNC 11 управляют передачей данных по нисходящему каналу в соответствии с инструкцией из функциональных модулей 23 протокола фрейма в Узле B 12 (этап 118).
Поскольку здесь иллюстрируется последовательность для случая, когда установлен радиоканал, индикатор размера RLC был установлен в сообщении NBAP RL SETUP REQUEST. Для другого примера, если добавлен радиоканал, индикатор размера RCL PDU может быть установлен в сообщении NBAP RL ADDITION REQUEST (запрос добавления радиоканала). Кроме того, если радиоканал изменяется, индикатор размера RCL PDU может быть установлен в сообщении NBAP RL RECONFIGURATION PREPARE (подготовка к изменению конфигурации радиоканала) или в сообщении 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 (25)

1. Мобильная система передачи данных, содержащая устройство управления, устройство базовой станции и терминал пользователя, в которой устройство управления передает сообщение запроса установки радио канала (RADIO LINK SETUP REQUEST), которое включает в себя информацию о формате размера, указывающую, имеет ли размер данных модуля данных протокола на уровне управления радиоканалом (RLC PDU) фиксированную длину или переменную длину; и
в которой устройство базовой станции принимает сообщение RADIO LINK SETUP REQUEST из устройства управления,
при этом терминал пользователя передает данные устройству управления через устройство базовой станции.
2. Мобильная система передачи данных по п.1, в которой устройство базовой станции включает в себя, по меньшей мере, одну очередь; и в которой информацию используют для этой очереди.
3. Мобильная система передачи данных по п.2, в которой информация и очередь ассоциированы друг с другом.
4. Мобильная система передачи данных по пп.1-3, в которой устройство базовой станции выполняет управление потоками при передаче данных на основе информации.
5. Мобильная система передачи данных по п.4, в которой управление потоками осуществляют так, что устройство базовой станции адаптивно изменяет множество элементов, включающих в себя разрешенный размер данных для данных, предназначенных для передачи из устройства управления в устройство базовой станции в соответствии со статусом передачи данных, и путем уведомления устройства управления об элементах, управляющих передачей данных из устройства управления; и
в которой, если информация, предоставляемая устройством управления, обозначает, что размер данных имеет фиксированную длину, устройство базовой станции фиксирует размер данных среди элементов управления потоками.
6. Мобильная система передачи данных по п.5, в которой элементы управления потоками информации включают в себя разрешенный интервал передачи фрейма данных и количество передач фрейма данных, разрешенное в пределах заранее заданного периода времени.
7. Мобильная система передачи данных по п.5,
в которой передача данных представляет собой HSDPA; и
в которой элемент, обозначающий размер данных при управлении потоками информации, представляет собой максимальную длину MAC-d/c PDU.
8. Мобильная система передачи данных по п.7, в которой другие элементы, кроме размера данных при управлении потоками, включают в себя, по меньшей мере, одно из разрешения HS-DSCH на передачу очередного пакета данных, интервала HS-DSCH и период повторения HS-DSCH.
9. Мобильная система передачи данных по п.4, в которой передача данных представляет собой передачу данных в направлении из устройства управления в устройство базовой станции;
в которой устройство базовой станции управляет передачей данных из устройства управления в устройство базовой станции, используя управление потоками на основе информации; и
в которой устройство управления передает данные в устройство базовой станции в формате размера данных, предусмотренном в устройстве базовой станции, через информацию в соответствии с управлением, из устройства базовой станции.
10. Мобильная система передачи данных по п.4,
в которой передача данных представляет собой передачу данных в направлении из устройства базовой станции в устройство управления;
в которой формат размера данных, предоставляемый устройством управления в устройство базовой станции через информацию, представляет собой формат, который является обще распознаваемым устройством управления и терминалом пользователя и который терминал пользователя применяет для передачи данных; и
в которой устройство базовой станции управляет передачей из терминала пользователя данных, предназначенных для передачи, в устройство управления через устройство базовой станции, с использованием управления потоками на основе информации.
11. Мобильная система передачи данных по п.10,
в которой, если размер данных имеет переменную длину, информация включает в себя минимальное значение размера данных; и
в которой, если размер данных имеет переменную длину, устройство базовой станции предоставляет для терминала пользователя разрешение на передачу данных в количестве, равном или превышающем количество, обеспечивающее передачу данных с минимальным значением размера данных.
12. Устройство управления для мобильной системы передачи данных, содержащее:
средство передачи сообщения запроса установки радио канала (RADIO LINK SETUP REQUEST), которое включает в себя информацию о формате размера, указывающую имеет ли размер данных модуля данных протокола на уровне управления радиоканалом (RLC PDU) фиксированную длину или переменную длину; и
средство передачи, предназначенное для передачи в устройство базовой станции сообщения RADIO LINK SETUP REQUEST,
причем средство передачи данных передает данные устройству управления через устройство базовой станции.
13. Устройство управления по п.12, в котором информацию используют для, по меньшей мере, одной очереди в устройстве базовой станции.
14. Устройство управления по п.13, в котором информация и очередь ассоциированы между собой.
15. Устройство базовой станции для мобильной системы передачи данных, устройство базовой станции, содержащее:
средство передачи сообщения запроса установки радио канала (RADIO LINK SETUP REQUEST), которое включает в себя информацию о формате размера,
указывающую, имеет ли размер данных модуля данных протокола на уровне управления радиоканалом (RLC PDU) фиксированную длину или переменную длину; и
средство приема, предназначенное для приема из устройства управления сообщения RADIO LINK SETUP REQUEST,
причем средство передачи данных передает данные устройству управления через устройство базовой станции.
16. Устройство базовой станции по п.15, содержащее, по меньшей мере, одну очередь, в котором информацию используют для очереди.
17. Устройство базовой станции по п.16, в котором информация и очередь ассоциированы друг с другом.
18. Устройство базовой станции по любому одному из пп.15-17, в котором средство передачи данных выполняет управление потоками при передаче данных на основе информации.
19. Способ управления передачей данных для мобильной системы передачи данных, включающей в себя устройство управления, устройство базовой станции и терминал пользователя, в котором устройство управления передает сообщение запроса установки радио канала (RADIO LINK SETUP REQUEST), которое включает в себя информацию о формате размера, указывающую, имеет ли размер данных модуля данных протокола на уровне управления радиоканалом (RLC PDU) фиксированную длину или переменную длину; и
в котором устройство базовой станции принимает сообщение RADIO LINK SETUP REQUEST из устройства управления, при этом терминал пользователя передает данные устройству управления через устройство базовой станции.
20. Способ управления устройством, содержащий этапы, на которых:
передают в устройство базовой станции сообщение запроса установки радио канала (RADIO LINK SETUP REQUEST), которое включает в себя информацию о формате размера, указывающую, имеет ли размер данных модуля данных протокола на уровне управления радиоканалом (RLC PDU) фиксированную длину или переменную длину,
принимают сообщение RADIO LINK SETUP REQUEST из устройства управления,
передают данные устройству управления через устройство базовой станции.
21. Терминал пользователя в мобильной системе передачи данных, которая содержит устройство управления и базовую станцию, терминал пользователя содержит:
средство передачи данных для передачи данных базовой станции, которая принимает сообщение запроса установки радио канала (RADIO LINK SETUP REQUEST), которое включает в себя информацию о формате размера, указывающую, имеет ли размер данных модуля данных протокола на уровне управления радиоканалом (RLC PDU) фиксированную длину или переменную длину;
причем средство передачи данных передает данные устройству управления через устройство базовой станции.
22. Терминал пользователя по п.21, в котором устройство базовой станции включает в себя, по меньшей мере, одну очередь, и в котором информация используется для этой очереди.
23. Терминал пользователя по п.22, в котором информация и очередь ассоциированы друг с другом.
24. Терминал пользователя по любому из пп.21 и 22, в котором устройство базовой станции выполняет управление потоками при передаче данных на основе информации.
25. Мобильная система передачи данных, содержащая устройство управления и устройство базовой станции,
в которой устройство управления передает сообщение запроса установки радио канала (RADIO LINK SETUP REQUEST), которое включает в себя информацию о формате размера, указывающую, имеет ли размер данных модуля данных протокола на уровне управления радиоканалом (RLC PDU) фиксированную длину или переменную длину; и
в которой устройство базовой станции принимает сообщение RADIO LINK SETUP REQUEST из устройства управления.
RU2011107746/07A 2008-08-01 2009-05-14 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством RU2486698C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2008-200277 2008-08-01
JP2008200277 2008-08-01
PCT/JP2009/058991 WO2010013526A1 (ja) 2008-08-01 2009-05-14 移動通信システム、制御装置、基地局装置、システム制御方法、および装置制御方法

Related Child Applications (2)

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

Publications (2)

Publication Number Publication Date
RU2011107746A RU2011107746A (ru) 2012-09-10
RU2486698C2 true RU2486698C2 (ru) 2013-06-27

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 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154993A RU2611721C1 (ru) 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154991A RU2635108C2 (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 After (5)

Application Number Title Priority Date Filing Date
RU2012135474/07A RU2529008C2 (ru) 2008-08-01 2012-08-17 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154993A RU2611721C1 (ru) 2008-08-01 2015-12-22 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством
RU2015154991A RU2635108C2 (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 Мобильная система передачи данных, устройство управления, устройство базовой станции, способ управления системой и способ управления устройством

Country Status (12)

Country Link
US (8) US9113392B2 (ru)
EP (5) EP2603035B1 (ru)
JP (11) JP5223922B2 (ru)
KR (7) KR101333855B1 (ru)
CN (5) CN102113369B (ru)
AU (1) AU2009277764B2 (ru)
BR (12) BR122015021023A2 (ru)
CA (1) CA2732689C (ru)
ES (5) ES2606179T3 (ru)
HK (1) HK1182871A1 (ru)
RU (6) RU2486698C2 (ru)
WO (1) WO2010013526A1 (ru)

Families Citing this family (14)

* 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.
BR122015021023A2 (pt) 2008-08-01 2019-08-27 Nec Corp estação base, dispositivo de controle, terminal e método
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 주식회사 팬택 무선통신 시스템에서 제어 정보의 다중 전송을 동적으로 제어하는 방법 및 장치
US9549339B2 (en) 2011-11-09 2017-01-17 Telefonaktiebolaget Lm Ericsson (Publ) Radio network node, network control node and methods therein
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 华为技术有限公司 通信的方法、网络设备和用户设备
US10329186B2 (en) 2015-12-21 2019-06-25 Corning Incorporated Borosilicate glasses with low alkali content
WO2018206855A1 (en) * 2017-05-12 2018-11-15 Nokia Technologies Oy Protocol data unit session splitting function and signalling
EP3911001A4 (en) * 2019-01-09 2022-03-16 Panasonic Intellectual Property Corporation of America BASE STATION, TERMINAL, TRANSMISSION METHOD AND RECEIVING METHOD

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 データ伝送方法及びデータ伝送装置
KR20030022929A (ko) * 2001-09-11 2003-03-19 한빛전자통신 주식회사 3지피피 시스템의 알엔씨에서 호 서비스 장치 및 방법
RU2263415C2 (ru) * 1999-10-19 2005-10-27 Телефонактиеболагет Лм Эрикссон (Пабл) Способ планирования передачи пакетов по сети универсальной системы мобильной связи
RU2305899C2 (ru) * 2003-12-22 2007-09-10 Самсунг Электроникс Ко., Лтд. Способ выбора формата передачи для оптимизации передачи данных в мобильной системе связи стандарта wcdma

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NZ232223A (en) 1989-01-27 1993-03-26 British Telecomm Alternate burst communication for cordless phones re-established after channel failure
FI104143B1 (fi) 1997-07-31 1999-11-15 Nokia Networks Oy Menetelmä tietoliikenneresurssien kontrolloimiseksi
CN1201526C (zh) * 2000-04-07 2005-05-11 诺基亚有限公司 固定大小的协议数据单元经过透明无线链路控制的传输
KR100446522B1 (ko) * 2001-07-06 2004-09-04 삼성전자주식회사 고속 순방향 패킷 접속 방식을 사용하는 통신시스템에서고속 매체 접속 제어 계층 엔터티 리셋 방법
CN100474975C (zh) * 2001-08-21 2009-04-01 诺基亚有限公司 通信网络内的数据传输
KR100747464B1 (ko) 2002-01-05 2007-08-09 엘지전자 주식회사 고속하향링크패킷접속（ｈｓｄｐａ）시스템을 위한타이머를 이용한 교착상황 회피방법
US7283508B2 (en) 2002-02-07 2007-10-16 Samsung Electronics Co., Ltd. Apparatus and method for transmitting/receiving serving HS-SCCH set information in an HSDPA communication system
TWI275272B (en) * 2002-05-10 2007-03-01 Interdigital Tech Corp Radio network controller and node-B
KR100876765B1 (ko) * 2002-05-10 2009-01-07 삼성전자주식회사 이동 통신 시스템에서 데이터 재전송 장치 및 방법
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
US7606238B2 (en) * 2003-06-11 2009-10-20 Ntt Docomo, Inc. Packet communication method, controller and mobile station
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
KR100520146B1 (ko) * 2003-12-22 2005-10-10 삼성전자주식회사 고속 순방향 패킷 접속 통신 시스템에서 데이터 처리장치및 방법
KR100617696B1 (ko) 2004-03-12 2006-08-28 삼성전자주식회사 무선 통신 시스템에서 연속된 데이터 유닛 수신 방법 및장치와 송신을 위한 데이터 유닛의 생성 방법 및 장치와그 데이터버스트 구조
CN1710829A (zh) * 2004-06-18 2005-12-21 北京三星通信技术研究有限公司 在wcdma系统的增强上行专用信道中支持低数据速率的方法
KR100678941B1 (ko) 2004-09-03 2007-02-07 삼성전자주식회사 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법및 그 방법을 이용하는 무선 디바이스
EP1643694A3 (en) 2004-09-30 2008-10-08 Samsung Electronics Co., Ltd. Method and apparatus for transmitting uplink nonscheduled data in a mobile communication system
DE602004010167T2 (de) 2004-12-15 2008-02-28 Matsushita Electric Industrial Co., Ltd., Kadoma Unterstützung für garantierten Bitratenverkehr für Uplink Übertragungen
KR100918435B1 (ko) * 2005-01-31 2009-09-24 삼성전자주식회사 무선 통신 시스템에서 데이터 트래픽 제어 시스템 및 방법
KR100762647B1 (ko) * 2005-03-31 2007-10-01 삼성전자주식회사 기지국 장치 및 이를 이용한 무선 자원 관리 방법
US8085657B2 (en) 2005-04-01 2011-12-27 Sony Corporation Flow control in a cellular communication system
EP1917751A4 (en) * 2005-08-26 2011-07-06 Ericsson Telefon Ab L M RIVER CONTROL AT 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 富士通株式会社 移動通信システム及びその通信方法
WO2008097486A2 (en) * 2007-02-02 2008-08-14 Interdigital Technology Corporation Method and apparatus for controlling a handover between utra r6 cells and r7 cells
US8503423B2 (en) * 2007-02-02 2013-08-06 Interdigital Technology Corporation Method and apparatus for versatile MAC multiplexing in evolved HSPA
MX2009008015A (es) * 2007-02-02 2009-09-04 Interdigital Tech Corp Metodo y aparato para mejorar rlc para tamaño de pdu de rlc flexible.
CN101606417B (zh) * 2007-02-06 2013-01-30 艾利森电话股份有限公司 灵活的无线电链路控制分组数据单元长度
JP4726820B2 (ja) 2007-02-20 2011-07-20 Ｙｋｋ株式会社 スライドファスナー用スライダー
CN101641897A (zh) * 2007-03-16 2010-02-03 交互数字技术公司 演进型hspa系统内部的应答模式无线电链路控制架构及方法
KR101115107B1 (ko) * 2007-03-16 2012-02-29 인터디지탈 테크날러지 코포레이션 무선 링크 제어 파라미터의 재구성을 지원하기 위한 무선 통신 방법 및 장치
CN101355547B (zh) * 2007-07-23 2011-06-15 鼎桥通信技术有限公司 一种媒体接入控制专用信道数据包大小的配置方法及装置
CN101355439B (zh) * 2007-07-27 2010-12-01 鼎桥通信技术有限公司 用户设备能力的控制方法、系统及无线网络控制器
KR101586550B1 (ko) * 2007-09-28 2016-01-20 라쿠텐 인코포레이티드 업링크 프로토콜 변경을 지원하기 위한 방법 및 장치
BR122015021023A2 (pt) 2008-08-01 2019-08-27 Nec Corp estação base, dispositivo de controle, terminal e método

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 データ伝送方法及びデータ伝送装置
RU2263415C2 (ru) * 1999-10-19 2005-10-27 Телефонактиеболагет Лм Эрикссон (Пабл) Способ планирования передачи пакетов по сети универсальной системы мобильной связи
KR20030022929A (ko) * 2001-09-11 2003-03-19 한빛전자통신 주식회사 3지피피 시스템의 알엔씨에서 호 서비스 장치 및 방법
RU2305899C2 (ru) * 2003-12-22 2007-09-10 Самсунг Электроникс Ко., Лтд. Способ выбора формата передачи для оптимизации передачи данных в мобильной системе связи стандарта wcdma

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TSG-RAN WG2 Meeting #48bis, Ericsson, User plane protocol enhancements, Tdoc R2-052508.10.2005,. http:// www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_48bis /Documents/R2-O52508.zip. 3GPP TS 34.108 V8.3.0, Common test environments for User Equipment (UE), Conformance testing, 06.2008, http://www.3gpp.org/ftp/Specs/archive/34_series/34.108/34108-830.zip. *

Also Published As

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

Similar Documents

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