Смартфон уже может показывать значок 5G, но веб-страницы при этом по-прежнему не загружаются. В такой ситуации первым делом обычно проверяют процедуру Registration: завершилась ли 5G-AKA? Был ли получен Registration Accept? Истек ли T3512? После этих проверок процедура Registration может выглядеть полностью нормальной, а передача данных всё равно не работать.
Во многих случаях проблема связана не с Registration, а с PDU Session. Registration отвечает на вопрос: «Может ли UE зарегистрироваться в 5GS?». PDU Session Establishment отвечает на следующий: «Может ли UE фактически получить доступ к сети передачи данных?». В статье последовательно рассматривается вся процедура установления PDU-сессии: как UE запрашивает сессию, как AMF выбирает SMF, как SMF получает данные подписки и политики, как настраивается UPF и как в итоге формируется туннель N3.
После завершения 5GS Registration у AMF уже есть идентификатор пользователя, контекст мобильности, безопасности и соответствующие данные подписки. Однако успешная регистрация не означает, что путь пользовательской плоскости уже создан. У UE всё ещё может отсутствовать активный путь к Интернету или корпоративной сети передачи данных.
PDU Session Establishment переводит UE из состояния «зарегистрировано» в состояние «может передавать прикладной трафик». UE запрашивает сессию, сеть выбирает SMF и UPF, получает данные подписки, связанные с DNN и S-NSSAI, запрашивает политику сессии, устанавливает правила PFCP в UPF и координирует с gNB создание туннеля N3. В конце процедуры UE получает IP-адрес, правила QoS и путь пользовательской плоскости к Data Network.
Процедуру легче понять, если не рассматривать её как одно изолированное сообщение NAS. Одновременно происходят три процесса: управление сессией, управление политиками и настройка ресурсов пользовательской плоскости. В конечном итоге они сходятся в работоспособной PDU Session.
Функциональная граница между PDU-сессией и регистрацией в 5GS
В 5GC разделение между Registration и PDU Session однозначно: Registration устанавливает регистрацию в сети, а PDU Session — подключение для передачи данных.
Registration определяет, может ли UE войти в 5GS. AMF проверяет идентификатор UE, выполняет аутентификацию, устанавливает защиту NAS, получает связанные с мобильностью данные подписки и формирует контекст, необходимый для RM (Registration Management) и CM (Connection Management). После завершения этих шагов между UE и ядром сети устанавливаются отношения управления.
PDU Session связана непосредственно с услугой передачи данных. Если UE нужен доступ в Интернет, соединение IMS или частная корпоративная сеть, одной Registration недостаточно. Сеть должна определить, какой DNN использовать, какой S-NSSAI применяется, какой SMF будет управлять сессией, какой UPF будет передавать пользовательский трафик и какие параметры QoS и полосы пропускания разрешены.
Сравнение с EPC помогает запомнить различие. В LTE используются понятия PDN Connection и EPS Bearer. В 5GC эта модель заменена на PDU Session + QoS Flow. После установления PDU Session сеть формирует правила QoS и ресурсы QoS Flow вместо Default EPS Bearer, характерного для LTE.
Ещё один важный момент: PDU Session необязательно должна устанавливаться одновременно с первоначальной Registration. UE может завершить Registration и оставаться без PDU Session до тех пор, пока приложению действительно не понадобится передача данных. Например, устройство может зарегистрироваться при включении, а PDU Session будет создана только через полчаса, когда пользователь запустит видеоприложение.
Это различие полезно при анализе трассировки. Если Registration завершилась успешно, а PDU Session Establishment — нет, повторная проверка 5G-AKA, Registration Accept или T3512 обычно не решит проблему передачи данных, поскольку анализ выполняется не в той процедуре.
DNN, S-NSSAI и тип запроса в запросе PDU-сессии
PDU Session Establishment начинается с сообщения NAS, отправленного UE. PDU Session Establishment Request не просто сообщает ядру сети: «Мне нужен доступ к данным». Информационные элементы в запросе влияют на последующий выбор NF и настройку сессии.
Типичный начальный запрос может содержать PDU Session ID, Request Type, PDU Session Type, SSC Mode, DNN и S-NSSAI.
PDU Session ID позволяет различать несколько сессий одного и того же UE. Одно UE может одновременно поддерживать несколько PDU Sessions — например, одну для доступа в Интернет, а другую для частной корпоративной сети. SUPI идентифицирует абонента, но сам по себе не определяет, какая именно PDU Session обрабатывается в данный момент.
DNN определяет Data Network, к которой UE хочет получить доступ. Операторский доступ в Интернет, IMS и корпоративные сети могут использовать разные DNN. DNN также участвует в последующем выборе SMF, выборе UPF и принятии политических решений.
S-NSSAI связывает сессию с определённым Network Slice. AMF и SMF должны определить, соответствует ли запрошенный slice подписке пользователя, запрошенному DNN и возможностям развернутой сети.
Request Type указывает контекст запроса. Помимо новой PDU Session, процедура может быть связана с существующей сессией, изменением доступа или сценарием экстренной службы. Поэтому при анализе трассировки наличие PDU Session Establishment Request нельзя автоматически считать одним и тем же сценарием во всех случаях.
Наиболее распространённый вариант — Initial Request: UE уже завершило Registration и теперь создаёт новую PDU Session для конкретного DNN. Выбор SMF, получение данных подписки из UDM, управление политикой PCF и создание ресурсов UPF выполняются на основе этого контекста сессии.
Выбор SMF и создание SM Context со стороны AMF
NAS-сообщение управления сессией от UE сначала поступает в gNB, а затем через NGAP вместе с информацией доступа, такой как NR-CGI и TAI, пересылается в AMF. gNB не принимает решений по управлению PDU Session; он передаёт NAS-информацию в ядро сети.
После получения запроса AMF должен определить SMF, способный обслуживать запрошенные S-NSSAI и DNN.
В сервис-ориентированной архитектуре 5GC AMF может использовать NRF для обнаружения NF. Критерии обнаружения могут включать тип целевого NF, требуемый сервис Nsmf_PDUSession, S-NSSAI, DNN и обслуживающий PLMN. NRF возвращает кандидатов SMF, после чего AMF выбирает фактически обслуживающий SMF в соответствии с политикой сети.
Затем AMF вызывает сервис PDU Session в SMF для создания SM Context. Помимо SUPI, PDU Session ID, DNN и S-NSSAI, запрос содержит исходный PDU Session Establishment Request от UE в виде N1 SM information.
С этого момента центр управления сессией перемещается от AMF к SMF. AMF продолжает отвечать за доступ и мобильность и пересылать сигнализацию N1 SM между UE и SMF, однако именно SMF принимает решения о том, как создаётся PDU Session, какой UPF выбирается, какие политики применяются и как настраиваются правила пользовательской плоскости.
При поиске неисправностей важно учитывать практический момент: количество транзакций NRF в коммерческой сети может не совпадать в точности с эталонной диаграммой сигнализации. Результаты NF discovery могут кэшироваться, может использоваться статическая конфигурация или маршрутизацию сервисов может выполнять SCP. Важнее не наличие конкретного запроса NRF в трассировке, а то, поддерживает ли выбранный SMF требуемые DNN, S-NSSAI и сервисные возможности.
Данные подписки UDM и обработка политики сессии PCF
После того как SMF понимает, какой тип сессии запрашивает UE, он всё ещё не может сразу создать пользовательскую плоскость. Сначала необходимо определить, какой тип PDU Session абонент действительно имеет право устанавливать.
В типичной процедуре SMF находит подходящий UDM, регистрируется как SMF, обслуживающий SUPI и PDU Session, и получает Session Management Subscription Data, связанные с запрошенными S-NSSAI и DNN.
Данные подписки могут содержать разрешённый PDU Session Type, SSC Mode, Session-AMBR и настройки QoS по умолчанию. Эти значения задают абонентские границы для сессии. Например, если UE запрашивает IPv4 PDU Session, SMF всё равно должен проверить, разрешает ли DNN такой PDU Session Type и допустим ли запрошенный SSC Mode.
SMF также может подписаться на изменения данных SM-подписки. Если соответствующая подписка управления сессией позднее изменяется в UDM, UDM может уведомить обслуживающий SMF через зарегистрированный Callback URI.
Если развертывание использует динамический SM Policy Control, SMF выбирает PCF и устанавливает SM Policy Association. SMF передаёт такие данные контекста, как SUPI, PDU Session ID, DNN, S-NSSAI, местоположение UE и подписанные параметры QoS. Затем PCF возвращает разрешённую политику сессии, которая может содержать Session-AMBR, QoS по умолчанию и другие применимые правила политики.
Этот этап можно рассматривать как сведение параметров сессии:
Запрос услуги UE → ограничения подписки UDM → авторизация политики PCF → SMF окончательно определяет параметры управления сессией
Правила QoS и пересылки, которые позднее устанавливаются в UPF, формируются на основе этих результатов.
Установление N4-сессии и установка правил пользовательской плоскости в UPF
После определения параметров сессии SMF выбирает UPF, способный обслуживать запрошенные DNN, S-NSSAI и местоположение UE, а затем устанавливает PFCP Session через интерфейс N4.
PFCP Session Establishment Request — один из наиболее важных этапов процедуры PDU Session Establishment. До этого момента сеть в основном работала с абстрактными требованиями к услуге. На N4 эти требования преобразуются в правила, которые UPF может применять к реальным пользовательским пакетам.
SMF может установить в UPF правила PDR, FAR, QER и URR:
PDR: определяет, как UPF идентифицирует пакеты, относящиеся к PDU Session или конкретному потоку трафика;
FAR: задаёт действие для совпавших пакетов, например пересылку, отбрасывание, буферизацию или другое применимое действие;
QER: применяет требуемые механизмы QoS в UPF;
URR: определяет требования к измерению и отчётности по использованию пользовательской плоскости.
Эти правила не следует считать четырьмя независимыми функциями. Вместе они определяют обработку трафика в UPF. PDR распознаёт поток пакетов и ссылается на соответствующие FAR, QER и URR, чтобы UPF понимал, куда направлять пакеты, какие механизмы QoS применять и нужно ли учитывать объём использования.
Когда UPF принимает PFCP Session Establishment, он возвращает свой F-SEID и созданные параметры пользовательской плоскости. Один из наиболее важных результатов — адрес пользовательской плоскости на стороне UPF и TEID, используемые для N3.
Однако в этот момент нисходящий путь может быть ещё не завершён, поскольку gNB ещё не закончил выделение ресурсов N3. Поэтому PDU Session Establishment не заканчивается одним запросом PFCP. Процедура должна дождаться завершения настройки пользовательской плоскости со стороны RAN.
Сигнализация N1/N2 завершает создание туннеля N3 и настройку QoS Flow
После подготовки ресурсов на стороне UPF SMF должен вернуть через AMF два разных набора информации.
Первый — N1 SM information, который в итоге доставляется UE. Он содержит PDU Session Establishment Accept вместе с параметрами, необходимыми UE после установления сессии, включая PDU Session Type, SSC Mode, DNN, S-NSSAI, IP-адрес UE, Session-AMBR и правило QoS по умолчанию.
Второй — N2 SM information, предназначенный для gNB. Он сообщает RAN, какая PDU Session создаётся, какие QoS Flows задействованы и какие IP-адрес UPF и TEID необходимо использовать на N3.
AMF отправляет в gNB по NGAP PDU Session Resource Setup Request. gNB выделяет необходимые радиоресурсы и ресурсы N3 и передаёт PDU Session Establishment Accept в UE.
После настройки ресурсов gNB возвращает PDU Session Resource Setup Response, содержащий его собственный адрес пользовательской плоскости N3 и TEID, а также информацию об успешно созданных QoS Flows.
Здесь важно учитывать временную последовательность. Когда SMF первоначально создавал PFCP Session, он уже знал информацию N3 на стороне UPF, но мог ещё не знать окончательные параметры туннеля на стороне gNB. После того как gNB возвращает свой адрес N3 и TEID, AMF передаёт эти сведения SMF. Затем SMF использует PFCP Session Modification, чтобы обновить соответствующий FAR в UPF и обеспечить инкапсуляцию нисходящих пакетов в правильный туннель GTP-U в сторону gNB.
После этого восходящий и нисходящий пути пользовательской плоскости полностью сформированы:
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
Поэтому само по себе получение PDU Session Establishment Accept ещё не доказывает правильность всех элементов пользовательской плоскости. Параметры туннеля N3, PFCP Session Modification и итоговые правила UPF необходимо дополнительно проверять по фактической пересылке пакетов.
Поиск неисправностей сигнализации при установлении PDU-сессии
PDU Session Establishment задействует множество сетевых функций. Если при поиске неисправности сравнивать каждое сообщение начиная с первого пакета, анализ быстро становится запутанным. Эффективнее разделить процедуру на несколько контрольных точек и последовательно сужать область неисправности.
Проверьте, что запрос сессии корректно поступает в AMF
Сначала убедитесь, что UE завершило требуемую 5GS Registration. Затем проанализируйте PDU Session Establishment Request и проверьте корректность PDU Session ID, Request Type, DNN, S-NSSAI, PDU Session Type и SSC Mode. Если запрос уже на входе содержит недопустимый параметр, исправные SMF и UPF не смогут создать ожидаемую сессию.
Проверьте, что SMF создаёт корректный SM Context
Далее убедитесь, что AMF выбирает подходящий SMF и Create SM Context завершается успешно. Цель состоит не просто в поиске сообщения NRF в трассировке, а в подтверждении того, что выбранный SMF поддерживает требуемые DNN, S-NSSAI и сервисные возможности.
Затем проверьте, разрешают ли данные SM-подписки, возвращённые UDM, запрошенную PDU Session и соответствует ли политика PCF ожидаемой конфигурации QoS.
Проверьте полноту ресурсов UPF и N3
Если плоскость управления уже вернула PDU Session Establishment Accept, но UE по-прежнему не передаёт данные, анализ следует перенести на N4 и N3.
Проверяйте в следующей последовательности:
успешно ли выполняется PFCP Session Establishment и создаёт ли UPF соответствующую сессию;
соответствуют ли PDR, FAR, QER и другие правила ожидаемому направлению трафика;
возвращает ли gNB свой IP-адрес пользовательской плоскости N3 и TEID;
обновляет ли SMF UPF информацией о туннеле gNB через PFCP Session Modification;
появляются ли на N3 пакеты GTP-U с ожидаемым TEID;
может ли UPF успешно отправлять и принимать трафик к целевой Data Network через N6.
Такая последовательность помогает сузить проблему до NAS, SBI, N4, N3 или пересылки пакетов в UPF вместо того, чтобы рассматривать весь 5GC как одну неразделённую область неисправности.
Часто задаваемые вопросы
Почему UE может завершить регистрацию 5G, но всё равно не иметь доступа в Интернет?
Registration устанавливает контекст доступа, идентификации, безопасности и мобильности между UE и 5GC. Она не создаёт пользовательский путь передачи данных автоматически. Для доступа UE к Интернету или другой Data Network всё ещё требуется PDU Session, чтобы SMF мог настроить параметры сессии, ресурсы UPF и пользовательскую плоскость N3.
Всегда ли PDU Session устанавливается при включении UE?
Нет. PDU Session может быть установлена примерно одновременно с Registration, но также может инициироваться позже, когда UE действительно понадобится услуга передачи данных. 5GS позволяет UE оставаться зарегистрированным без активной PDU Session, поэтому завершение Registration и PDU Session Establishment не следует считать одним и тем же событием.
Гарантирует ли успешный PDU Session Establishment доступ UE в Интернет?
Нет. Один только PDU Session Establishment Accept на уровне NAS не является достаточным подтверждением работоспособности передачи данных. Реальный пользовательский трафик также зависит от туннеля N3 между gNB и UPF, правил PDR/FAR/QER в UPF, соединения N6 и целевой Data Network. UE может получить IP-адрес, а пересылка пользовательского трафика при этом оставаться некорректной.
Почему PFCP Session Modification выполняется после PFCP Session Establishment?
При создании первоначальной PFCP Session в UPF gNB может ещё не завершить выделение ресурсов N3, поэтому SMF может не знать окончательный IP-адрес пользовательской плоскости gNB и TEID. После того как gNB возвращает эти значения в PDU Session Resource Setup Response, SMF обновляет соответствующие правила UPF через PFCP Session Modification, чтобы нисходящий трафик передавался через правильный N3 GTP-U-туннель.
QFI в PDU Session и QER на интерфейсе N4 — это одно и то же?
Нет. QFI идентифицирует QoS Flow в 5GS, тогда как QER — это QoS Enforcement Rule, настраиваемое SMF в UPF через N4. QER участвует в применении QoS и при необходимости может быть связано с QFI, однако сам QFI не является QER, и эти понятия нельзя считать взаимозаменяемыми.
