Между полностью подключённым UE и полностью неактивным UE в 5G существует состояние, которое со стороны пользователя выглядит спокойным, но сохраняет техническое значение внутри NG-RAN. Это состояние называется RRC Inactive. Оно было добавлено в управление соединениями 5G для решения практической задачи: многим устройствам нужно быстро возвращаться к передаче данных, однако постоянное удержание всех устройств в RRC Connected приводило бы к расходованию ресурсов сигнализации, радиоресурсов и заряда аккумулятора.

Смартфон может проверять фоновые сообщения, датчик — передавать короткие пакеты данных, а приложение — ненадолго активироваться после длительного периода молчания. Такие модели трафика не всегда оправдывают полный переход в состояние ожидания с последующим выполнением всей процедуры установления соединения. RRC Inactive создаёт промежуточный уровень. UE может снизить активность, сохранить ключевой контекст и быстрее возобновить соединение при появлении восходящих или нисходящих данных.

Важно понимать, что RRC Inactive не равен RRC Idle. В RRC Idle UE с точки зрения ядра сети также находится в CM-IDLE. В RRC Inactive UE остаётся в CM-CONNECTED, а активная работа уровня RRC приостанавливается. gNodeB сохраняет контекст UE, UE сохраняет контекст AS, и сеть может вернуть UE в RRC Connected посредством процедуры возобновления, не начиная всё заново.

Зачем 5G нужен этот режим

Управление соединениями 5G должно одновременно обслуживать множество типов трафика. Некоторым службам необходимы высокая пропускная способность и непрерывное соединение. Другим достаточно короткого и редкого обмена данными. Некоторые терминалы долго не проявляют активности, но должны быстро отвечать, когда они нужны сети или приложению. Если все UE постоянно удерживать в RRC Connected, сеть будет нести ненужные управляющие издержки. Если все неактивные UE полностью переводить в RRC Idle, восстановление соединения станет медленнее и потребует больше сигнализации.

RRC Inactive сокращает этот разрыв. UE может прекратить активную обработку данных, характерную для RRC Connected, но важный контекст уровня доступа не удаляется. Благодаря этому последующая процедура возобновления быстрее восстанавливает соединение. С точки зрения пользователя устройство остаётся отзывчивым. С точки зрения сети активные ресурсы не удерживаются дольше необходимого.

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

С точки зрения архитектуры сети RRC Inactive также полезен тем, что переносит часть ответственности за мобильность и пейджинг на NG-RAN. AMF не нужно рассматривать каждое перемещение внутри локальной области уведомления RAN как событие мобильности ядра сети. gNodeB может эффективнее управлять контекстом UE и локальным пейджингом.

Как определяется этот режим

RRC Inactive обладает несколькими определяющими свойствами. Во-первых, UE по-прежнему считается находящимся в CM-CONNECTED. Это ключевое отличие от RRC Idle, где UE также находится в CM-IDLE. Связь с ядром 5G сохраняется, даже если RRC-соединение не передаёт активно обычные данные подключённого режима.

Во-вторых, этот режим в основном прозрачен для ядра сети. В обычной работе AMF не требуется напрямую управлять RRC Inactive так же, как это делает NG-RAN. Последний обслуживающий gNodeB сохраняет контекст UE и знает RAN Notification Area, к которой относится UE. Сохранение контекста обеспечивает быстрое восстановление.

В-третьих, UE и gNodeB сохраняют контекст уровня AS. Поскольку контекст уровня доступа не удаляется, при возобновлении обслуживания UE не требуется полностью новая настройка. Вместо этого UE может использовать процедуру RRC Resume для возврата в RRC Connected.

Переход в RRC Inactive выполняется сообщением RRC Release с конфигурацией приостановки. Поэтому этот режим обычно рассматривается вместе с процедурами приостановки и возобновления. Сеть освобождает активное RRC-соединение, но предписывает UE приостановить контекст, а не удалять его полностью.

Когда активность снова становится необходимой, UE может перейти из RRC Inactive в RRC Connected. Это происходит, когда у UE есть восходящие данные для передачи или когда оно получает RAN-пейджинг из-за нисходящих данных. Если неактивность длится слишком долго, UE Inactivity Timer на gNodeB может в итоге вызвать освобождение N2 и перевести UE в сторону RRC Idle и CM-IDLE.

Что UE может продолжать делать

RRC Inactive не означает, что UE полностью остановлено. Пока UE не работает активно в RRC Connected, несколько процедур остаются доступными. UE может выбирать PLMN, принимать широковещательную системную информацию, выполнять повторный выбор соты и отвечать на пейджинг, инициированный RAN. Эти функции позволяют UE оставаться доступным без полностью активного RRC-соединения.

Сеть также остаётся активной определённым образом. NG-RAN управляет RAN Notification Area, настраивает DRX для RAN-пейджинга и сохраняет контекст AS UE. gNodeB знает, к какому RNA относится UE, и может определить локальную область пейджинга, когда данные или сигнализация требуют возобновления работы UE.

Ещё один важный момент состоит в том, что в этой модели для UE могут сохраняться контексты соединений N2 и N3. Это имеет значение при поступлении нисходящих данных. UPF может по-прежнему знать адрес gNodeB и направлять данные последнему обслуживающему gNodeB. Затем gNodeB запускает пейджинг внутри настроенного RNA вместо полного запуска процедуры пейджинга ядра сети с нуля.

Эти сохраняемые элементы объясняют, почему RRC Inactive полезен, но одновременно сложнее простого режима ожидания. Сеть должна хранить достаточно контекста для быстрого восстановления, но не выделять настолько много активных ресурсов, чтобы состояние стало эквивалентно RRC Connected. Ценность режима заключается именно в этом балансе.

Как RNA управляет мобильностью

RNA означает RAN Notification Area. Это область уведомления на стороне RAN, используемая для UE в RRC Inactive. RNA состоит из нескольких сот, обычно в пределах одной Tracking Area. Когда UE перемещается внутри назначенного RNA, ему не нужно уведомлять сеть при каждой смене соты. Это позволяет избежать ненужной сигнализации при локальном перемещении.

RNA идентифицируется с помощью RNA ID. Идентификатор формируется из TAC и RAN Area Code. Диапазон RAN Area Code составляет от 0 до 255. На практике это даёт NG-RAN компактный способ определять локальные области, в которых неактивные UE могут перемещаться без частых обновлений.

Последний обслуживающий gNodeB назначает RNA ID через конфигурацию приостановки в сообщении RRC Release. Это важно, поскольку gNodeB, который последним обслуживал UE, отвечает за знание его RNA-контекста. Если позже поступят нисходящие данные, этот gNodeB сможет определить, как выполнять пейджинг UE в нужной области.

При определённых условиях UE всё же должно обновлять сеть. Если истёк периодический таймер обновления RNA или UE покинуло настроенный RNA, оно должно запустить процедуру обновления RNA. Это позволяет NG-RAN сохранять актуальное представление о локальной области UE, избегая чрезмерной сигнализации при обычных перемещениях внутри RNA.

Проектирование RNA влияет на эффективность пейджинга. Слишком маленький RNA может вызывать частые обновления при перемещении UE. Слишком большой RNA увеличивает нагрузку пейджинга, поскольку при поступлении нисходящих данных может потребоваться обращение к большему числу сот. Поэтому планирование должно учитывать модели мобильности, расположение сот, границы gNodeB и ожидаемое поведение служб.

Как доставляются нисходящие данные

Обработка нисходящих данных — один из наиболее наглядных примеров назначения RRC Inactive. Когда данные поступают от UPF, пока UE находится в RRC Inactive, они могут быть направлены последнему обслуживающему gNodeB. Затем gNodeB запускает пейджинг в RNA, поскольку знает, что UE неактивно, но локально доступно через пейджинг уровня RAN.

Если все соты RNA принадлежат последнему обслуживающему gNodeB, процедура сравнительно проста. gNodeB выполняет пейджинг UE в соответствующих сотах. UE принимает сообщение RAN Paging, запускает RRC Resume и возвращается в RRC Connected. После возобновления UE может получить нисходящие данные.

Если RNA содержит соты, обслуживаемые соседними gNodeB, последний обслуживающий gNodeB может использовать сигнализацию Xn. Он отправляет соседнему gNodeB сообщение XnAP RAN Paging, чтобы пейджинг выполнялся и в этих сотах. Благодаря этому область пейджинга соответствует RNA, а не ограничивается собственными сотами последнего gNodeB.

Та же общая логика применяется при поступлении от AMF нисходящей сигнализации, связанной с UE, за исключением случаев вроде UE Context Release Command, для которых используется другой путь обработки. Главное состоит в том, что NG-RAN может управлять пейджингом неактивного UE, не превращая его сразу в полноценный случай пейджинга ядра сети в режиме ожидания.

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

Как работают переходы возобновления

Переход из RRC Inactive в RRC Connected может быть инициирован UE или сетью. UE инициирует переход, когда у него есть восходящие данные или потребность в сигнализации. UE отправляет gNodeB запрос RRC Resume Request. Если текущий gNodeB не является последним обслуживающим gNodeB, перед завершением возобновления ему может потребоваться получить контекст UE у последнего gNodeB.

Типичная процедура, инициированная UE, может включать RRC Resume Request, Retrieve UE Context Request, Retrieve UE Context Response, RRC Resume и RRC Resume Complete. При смене обслуживающего gNodeB могут потребоваться дополнительные процедуры, например Xn-U Address Indication и Path Switch Request в сторону AMF. После переключения пути старый контекст при необходимости освобождается.

Переход, инициированный сетью, начинается иначе. Последний обслуживающий gNodeB получает нисходящие данные или соответствующую сигнализацию и запускает RAN-пейджинг. UE вызывается внутри RNA. После получения пейджинга UE возобновляет работу из RRC Inactive и возвращается в RRC Connected для обработки ожидающих данных или сигнализации.

Эти переходы разработаны как более лёгкие по сравнению с полным установлением соединения из режима ожидания. Однако они не являются простыми. Корректная работа зависит от сохранённого контекста, координации между gNodeB, переключения пути через AMF при необходимости и правильного освобождения контекста после создания нового обслуживающего пути.

Важен и путь по таймеру. Если UE остаётся неактивным дольше, чем допускает политика UE Inactivity Timer на gNodeB, сеть может перевести его в RRC Idle. Обычно это связано с освобождением N2 и изменением состояния ядра сети на CM-IDLE. После этого преимущества быстрого возобновления RRC Inactive больше не действуют.

Как AMF получает отчёты о состоянии

RRC Inactive часто называют прозрачным для ядра сети, однако это утверждение требует осторожного толкования. В общем случае AMF не управляет состоянием RRC UE напрямую так, как это делает NG-RAN. Однако AMF может запросить отчёты о переходах состояния RRC с помощью сигнализации NGAP.

AMF может включить параметр RRC Inactive Transition Report Request в такие сообщения, как Initial Context Setup Request или UE Context Modification Request. Если запрос настроен на отчёты о последующих переходах состояния, gNodeB должен сообщать, когда UE входит в RRC Inactive или выходит из него.

При изменении состояния gNodeB отправляет в AMF сообщение RRC Inactive Transition Report. Отчёт содержит значение RRC State, например Inactive или Connected. Этот механизм предоставляет AMF видимость по запросу, не меняя основного факта: поведением RRC Inactive управляет NG-RAN.

Такая отчётность полезна для координации сети, учёта политик и операционного мониторинга. Она также показывает, почему RRC Inactive нельзя упрощённо считать полностью невидимым для ядра сети. Точнее говорить, что состояние в основном управляется RAN, а AMF может получать сведения о переходах при заданных условиях.

Для инженерного анализа это различие важно. При сбое процедуры диагностика может потребовать проверки как поведения RAN, так и отчётности NGAP. Состояние UE, контекст gNodeB, конфигурация RNA, RAN-пейджинг, запрос отчёта AMF и обработка переключения пути могут повлиять на итоговый результат.

Часто задаваемые вопросы

Почему RRC Inactive не равен RRC Idle?

RRC Inactive сохраняет UE в CM-Connected и удерживает контекст уровня доступа, тогда как RRC Idle соответствует отношению ожидания с ядром сети, при котором восстановление соединения требует более тяжёлой процедуры.

Что запускает возобновление UE из RRC Inactive?

Возобновление может быть вызвано восходящими данными UE, потребностью UE в сигнализации или RAN-пейджингом из-за нисходящих данных либо поддерживаемой нисходящей сигнализации.

Почему RNA уменьшает сигнализацию?

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

Что происходит, если UE покидает свой RNA?

UE должно запустить процедуру обновления RNA, чтобы NG-RAN обновил сведения об области, используемые для локального пейджинга и доступности в неактивном состоянии.

Почему соседние gNodeB могут участвовать в пейджинге?

Если RNA включает соты соседних gNodeB, последний обслуживающий gNodeB может отправить XnAP RAN Paging, чтобы UE вызывалось и в этих соседних сотах.

Когда AMF узнаёт об изменениях состояния RRC?

AMF может получать отчёты о переходах, если запросил их через параметр RRC Inactive Transition Report Request в поддерживаемых процедурах NGAP.

RRC Inactive — одно из наиболее практичных улучшений управления соединениями 5G. Оно сохраняет достаточно контекста для быстрого возобновления, снижает ненужное использование активных ресурсов соединения, поддерживает локальное перемещение через RNA и позволяет NG-RAN эффективнее выполнять пейджинг. Его ценность заключается в балансе: быстрее возврата из полного режима ожидания, легче постоянного полного подключения и достаточно гибко для современных моделей мобильного трафика.