RRC протокол




В данной заметке рассматривается протокол Radio Resource Control (RRC). Протокол RRC используется для передачи общей NAS (Non Access Stratum, см. тут) информации (информации, которая относится ко всем UE) и специальной (dedicated) NAS информации (информации, которая относится только к определенным UE). Кроме этого, для UE, которые находятся в состоянии RRC_IDLE (в idle mode), передаются нотификации о входящих звонках.

RRC протокол покрывает следующие функциональные области: RRC сообщения, адресованные определенному UE, передаются по SRB. Пройдя через уровни PDCP и RLC, эти сообщения попадают в логические каналы (см. организацию каналов в LTE тут). Либо в Common Control Channel (во время создания соединения), либо в Dedicated Control Channel (если UE находится в состоянии RRC_CONNECTED). Сообщения пейджинга и сообщения с системной информацией напрямую попадают в логические каналы - в Paging Control Channel и в Broadcast Control Channel, соответственно.

RRC сообщения канала CCCH передаются с помощью SRB0, канала DCCH - SRB1, низкоприоритетные RRC сообщения канала DCCH (эти сообщения могут содержать NAS информацию для отдельных UE) - SRB2. Все RRC сообщения канала DCCH имеют защиту целостности и зашифрованы на уровне PDCP (после активации защиты). Для надежной передачи этих сообщений на уровне RLC используется ARQ (Automatic Repeat reQuest) механизм. RRC сообщения канала CCCH не имеют защиты целостности, и при их передаче не используется ARQ. Отметим, что независимо от этого, NAS применяет защиту целостности и шифрование.

Передача системной информации

Системная информация организована с помощью системных информационных блоков (System Information Block, SIB), каждый из которых содержит набор функциональных параметров. Определены следующие типы SIB:
Для передачи системной информации используются 3 типа RRC сообщений: MIB сообщение, SIB1 сообщение и сообщения системной информации (System Information, SI). SI сообщений может передаваться несколько штук, при этом SI сообщение может содержать один или более SIB, которые имеют одинаковый период передачи. В таблице ниже приводится пример конфигурации процесса передачи системной информации.

System information scheduling

Управление соединениями в LTE

Управление соединениями включает в себя следующие области:
Защита информации в LTE организована так же, как в UMTS и GSM. В этой заметке не приводится подробного описания механизма защиты информации, такое описание появится попозже в отдельной заметке. Здесь отметим только то, что защита информации организуется двумя функциями: шифрование как контрольной информации (RRC), так и пользовательских данных (DRB); целостность данных, которая применяется только для контрольной информации.

Существует два уровня NAS состояний UE: EMM (EPS Mobility Management) состояние и ECM (EPS Connection Management) состояние. EMM состояние определяет зарегестрировано ли UE в MME или нет и может принимать одно из следующих значений: EMM-REGISTERED, EMM-DEREGISTERED. ECM состояние определяет в каком состоянии находится UE и принимает одно из двух следующих значений: ECM-CONNECTED, ECM-IDLE.
Переход из ECM-IDLE состояния в ECM-CONNECTED, кроме создания RRC соединения, включает в себя еще и создания S1 соединения (про S1 см. тут). При этом, RRC соединение создается перед созданием S1 соединения. Также отметим, что переход из ECM-IDLE состояния в ECM-CONNECTED занимает не более 100 мс. Процедура создания соединений будет описана в отдельной заметке.

Управление мобильностью в состоянии RRC_IDLE осуществляется UE (перевыбор ячейки), а в состоянии RRC_CONNECTED - E-UTRAN (хэндовер). Отметим, что механизмы, используемые в этих двух случаях, должны быть согласованы между собой. При выборе ячейки определяющим параметром является качество принимаемого сигнала. Потому что в случае выбора ячейки с не самым лучшим соотношением сигнал/шум (Signal to Noise Ratio, SNR) возможно существенное увеличение уровня интерференции для других ячеек.
В состоянии RRC_IDLE выбор частотного диапазона для процедуры перевыбора ячейки осуществляется на основе абсолютных приоритетов, который имеет каждый частотный диапазон. При одинаковых приоритетах у нескольких частотных диапазонов выбор диапазона осуществляется на основе качества принимаемого сигнала. Кроме этого, E-UTRAN может назначать приоритеты специфичные для UE, учитывая производительность UE или тип пользователя. UE не рассматривает частотные диапазоны, для которых не имеет значений приоритетов.
В состоянии RRC_CONNECTED E-UTRAN выбирает ячейку, в которую UE должно совершить хэндовер. Как и в случае состояния RRC_IDLE, E-UTRAN, кроме качества принимаемого сигнала, может учитывать производительность UE и тип пользователя. Хотя E-UTRAN может инициировать хэндовер, не имея информации об измерениях со стороны UE, (слепой хэндовер, blind handover), все-таки наиболее общий случай, когда UE предоставляет результаты измерений для списка кандидатов на целевую (target) ячейку (т.е. ту ячейку, куда будет выполняться хэндовер).
В LTE UE всегда закреплено за одной ячейкой, то есть переход из одной ячейки в другую осуществляется с помощью жестного хэндовера (hard handover). При этом, eNodeB, которая в данный момент обслуживает UE (source eNodeB), обменивается сообщениями с eNodeB, которая выбрана в роли целевой (target eNodeB), для того, чтобы целевая eNodeB выполнила необходимые приготовления для хэндовера. Также LTE поддерживает так называемый "forward" хэндовер, когда UE само решает перейти на обслуживание в другую ячейку. После переключения UE запускает процедуру пересоздания соединения только после того, как соединение с предыдущей ячейкой потеряно.

Межтехнологическая мобильность (inter-RAT mobility)

Технология LTE поддерживает как перевод UE на обслуживание в другие RAT (Radio Access Technology), так и в обратном направлении (из других RAT в LTE). Процедура хэндовера из других RAT в LTE практически совпадает с процедурой хэндовера внутри LTE. Наиболее существенным отличием является то, что в данном случае необходимо выполнить процедуру полной конфигурации AS (Access Security). Кроме этого, если в предыдущей технологии шифрование данных не использовалось, то LTE его в любом слечае будет использовать. Также E-UTRAN создаст SRB1, SRB2 и один или более DRB (как минимум один DRB, который соответствует EPS потоку по умолчанию).
Перевод UE из LTE в другую RAT может быть осуществлен либо с помощью хэндовера, либо с помощью процедуры Cell Change Order (CCO). Процедура CCO используется только для перевода UE в GERAN (GSM EDGE Radio Access Network). При этом перевод осуществляется только после активации защиты.

Настройка измерений (measurement) и отчетность (reporting)

E-UTRAN для управления мобильностью UE может сконфигурировать его так, чтобы оно отправляло информацию об измерениях. Определены следующие элементы для конфигурации UE:
  1. Объекты измерений. Здесь указываются частоты, на которых должны осуществляться измерения. Также возможно указание списка ячеек.
  2. Конфигурация отчетности. Тут задается тип отчетности периодический или событийный (event triggered), а также какую именно информацию должно отправлять UE.
  3. Особенности измерений. Здесь определяются подходящие объекты измерений и конфигурация отчетности.
  4. Конфигурация величины (quantity). Тут определяется какая фильтрация будет применяться для каждого измерения.
  5. Интервалы измерения. Тут определяются периоды времени, когда eNodeB не будет выделять нисходящий и восходящие ресурс UE, для того, чтобы оно смогло выполнить необходимые измерения.

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



Если вы не нашли интересующую вас информацию по LTE/LTE-A в этой статье, напишите мне об этом письмо на alexey.anisimov86@gmail.com. Я постараюсь ее добавить в кратчайшие сроки.

Valid HTML 4.01 Strict