PDU-сессия может уже некоторое время работать нормально: UE получил IP-адрес, пользовательский тракт N3 активен, а трафик приложений передается как ожидается. Затем условия обслуживания меняются. Может потребоваться снизить ранее разрешенную скорость передачи данных, назначить определенному потоку QoS иной 5QI или ограничить максимальную скорость сессии значением 10 Mbps.
В такой ситуации 5GC не требуется разрывать и заново создавать всю PDU-сессию. Существующая сессия может оставаться активной, а изменяются только затронутые правила QoS, параметры потоков QoS или политики применения на пользовательской плоскости. Для этого и используется PDU Session Modification.
Отличие от PDU Session Establishment достаточно простое. Процедура установления создает сессию, которой ранее не существовало, а процедура модификации изменяет уже активную сессию. Поэтому основными становятся вопросы не о том, как был выбран SMF или первоначально создан UPF, а о том, что вызвало изменение, как SMF получает новую политику, что должны обновить UE и gNB и действительно ли новая политика QoS применяется в UPF.
Область применения модификации PDU-сессии
У PDU Session Modification есть важное предварительное условие: целевая PDU-сессия уже должна существовать. UE, SMF, PCF и соответствующий контекст RAN уже связаны с этой сессией, а пользовательская плоскость обычно работает.
Цель процедуры модификации — изменить параметры, не прерывая активную сессию. Один из наиболее распространенных примеров связан с QoS. Существующему потоку QoS может потребоваться другой 5QI, MBR, MFBR или иной разрешенный параметр. Изменение политики также может потребовать обновить ограничение скорости, уже применяемое в UPF.
Модификацию QoS нельзя понимать как простое изменение одного поля NAS. Одно обновление QoS может затронуть три разные части системы:
Сторона UE: UE должен получить новое правило QoS или новые параметры потока QoS;
Сторона RAN: gNB может потребоваться изменить соответствующий ресурс PDU-сессии или ресурсы потока QoS;
Сторона UPF: если меняется применение правил на пользовательской плоскости, соответствующие правила PFCP необходимо обновить через N4.
Поэтому PDU Session Modification лучше рассматривать как оперативную реконфигурацию активной сессии. Идентификатор сессии остается прежним, а изменения применяются к существующему PDU Session ID и связанным с ним потокам QoS.
Необходимо учитывать и важную границу. PDU Session Modification может изменять существующий поток QoS, а в подходящих сервисных сценариях также использоваться для создания нового потока QoS в рамках той же PDU-сессии. Например, политика приложения для вызова VoNR может потребовать дополнительный поток с определенными характеристиками QoS. Однако здесь рассматривается именно изменение параметров существующего потока QoS, а не создание нового.
Основные причины модификации сессии
Одно из ключевых отличий от PDU Session Establishment состоит в том, что инициатором может быть не только UE. Активная PDU-сессия может быть перенастроена из-за запроса UE, изменения сетевой политики, обновления данных подписки или изменения радиусловий.
Типичные источники запуска можно разделить на пять категорий:
По инициативе UE: UE отправляет PDU Session Modification Request, запрашивая изменение QoS или других параметров сессии;
По инициативе PCF: меняется управление политиками, например при достижении порога использования сеть снижает разрешенную скорость либо политика приложения требует другого QoS;
По инициативе UDM: изменяются данные подписки управления сессией, например уровень обслуживания абонента или профиль QoS, предусмотренный подпиской;
По инициативе SMF: SMF принимает решение перенастроить сессию согласно локальной политике, конфигурации сети или текущему состоянию сессии;
Событие, связанное с RAN: gNB сообщает о радиусловиях или доступности ресурсов, после чего SMF определяет необходимость изменения параметров сессии.
Все эти причины в конечном итоге сходятся в SMF, поскольку именно SMF хранит контекст управления PDU-сессией и преобразует новые требования к услуге или политике в параметры, которые могут применить UE, RAN и UPF.
При поиске неисправностей PDU Session Modification не следует начинать непосредственно с PDU Session Modification Command и двигаться дальше. Полезнее определить самое раннее управляющее событие, вызвавшее изменение. Если первым событием был UE Modification Request, процедура инициирована UE. Если PCF передает новую политику в SMF через Notification URI, изменение вызвано политикой. Если первой появляется информация об обновлении подписки UDM, анализ следует продолжать по цепочке изменения подписки.
Модификация PDU-сессии по инициативе UE
Процедуру по инициативе UE проще всего представить как случай, когда приложению требуется другой QoS.
Предположим, что UE использует PDU Session ID 5, а один из его потоков QoS по-прежнему работает с исходной конфигурацией. У приложения появляется новое требование к услуге, и UE запрашивает другие параметры QoS, отправляя PDU Session Modification Request.
Сообщение NAS сначала проходит через gNB к AMF. Затем AMF обновляет существующий SM Context в SMF. На сервисном интерфейсе AMF использует:
POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
Это отличается от Create SM Context. SM Context уже существует; теперь сеть обновляет контекст существующей сессии.
Запрос UE может содержать Requested QoS Rules, Requested QoS Flow Descriptions и связанные Packet Filters. После получения запроса SMF должен определить, может ли сеть разрешить требуемое изменение. Если для сессии используется динамическое управление политиками, SMF также передает запрос услуги в PCF для авторизации.
Например, если UE запрашивает 5QI 8 для определенного потока, SMF может вызвать сервис PCF SM Policy Control для изменения текущей Policy Association. PCF оценивает политику абонента, правила услуги и текущие условия сети, после чего возвращает фактически разрешенные параметры QoS.
Важно различать: параметры QoS, запрошенные UE, не обязательно совпадают с теми параметрами QoS, которые будут применяться в итоге. UE формулирует требование к услуге, а окончательные параметры должны быть разрешены SMF и PCF.
После определения разрешенных параметров SMF формирует два типа информации:
N1 SM: PDU Session Modification Command, передающий UE новые параметры, связанные с QoS;
N2 SM: информация для процедуры PDU Session Resource Modify, указывающая gNB изменить соответствующие ресурсы потока QoS.
AMF передает информацию N2 в gNB по NGAP и пересылает UE содержащийся в N1 PDU Session Modification Command.
После настройки соответствующих ресурсов gNB возвращает PDU Session Resource Modify Response. Когда UE принимает новые параметры, он отправляет по NAS PDU Session Modification Complete.
Только получив соответствующие результаты выполнения, SMF может подтвердить, что новые параметры сессии перешли от стадии авторизации политики к фактическому применению на стороне доступа и UE.
Сетевая модификация QoS по инициативе PCF
Сетевая модификация следует другой логике. UE не запрашивал новый QoS; изменение начинается на уровне управления политиками.
Рассмотрим пример с порогом использования. У пользователя уже есть активная PDU-сессия, и он непрерывно передает данные. PCF требует, чтобы сессия передавала или контролировала информацию об использовании. Когда накопленное использование достигает заданного порога, политика может снизить максимальную скорость сессии или соответствующего потока до 10 Mbps.
Затем PCF уведомляет SMF через Notification URI, зарегистрированный при создании SM Policy Association. Уведомление содержит новую SM Policy Decision, например обновленный MBR и соответствующий Policy Control Trigger.
С точки зрения SMF это не создание новой сессии, а изменение PDU-сессии, которая остается действующей и активной.
Если новую скорость необходимо применять в UPF, SMF отправляет через N4 PFCP Session Modification Request. Соответствующий QER можно обновить, например установив MBR равным 10 Mbps. Новое ограничение скорости начинает действовать на пользовательской плоскости только после принятия изменения UPF.
Не следует путать два разных значения слова «Modification»:
PDU Session Modification: общая процедура 5GS для изменения активной PDU-сессии;
PFCP Session Modification: конкретная процедура управления N4, используемая SMF для обновления правил пользовательской плоскости в UPF.
Они работают на разных уровнях. PDU Session Modification может включать PFCP Session Modification, но наличие одного сообщения модификации PFCP не означает завершения всей процедуры модификации PDU-сессии.
После того как UPF начинает применять новый QER, SMF может все еще требоваться обновить RAN и UE. Информация N1/N2 передается через AMF, gNB получает PDU Session Resource Modify Request, а UE — PDU Session Modification Command.
Когда gNB завершает обновление радиоресурсов, а UE принимает новые параметры QoS, обе стороны возвращают результаты выполнения. Затем SMF может сообщить PCF об успешном результате, чтобы система политик знала, что решение QoS действительно было применена, а не просто сохранена как решение политики.
Согласованная модификация через N1, N2 и N4
Один из наиболее запутанных аспектов PDU Session Modification состоит в том, что одно и то же изменение QoS может одновременно породить процедуры модификации в NAS, NGAP и PFCP.
Логика становится понятнее, если разделить эти три пути.
N1 обновляет параметры сессии UE
N1 SM передает информацию управления сессией между UE и SMF. После того как сеть решает изменить сессию, SMF отправляет UE через AMF PDU Session Modification Command.
UE обновляет локальные параметры PDU-сессии и подтверждает принятие сообщением PDU Session Modification Complete.
N2 обновляет ресурсы RAN
Если необходимо изменить радиоресурсы, связанные с потоком QoS, SMF формирует соответствующую информацию N2 SM и передает ее gNB через AMF. gNB изменяет ресурсы потока QoS с помощью процедуры PDU Session Resource Modify и возвращает результат, включая успешно измененные QFI, если применимо.
N4 обновляет правила применения в UPF
Если изменение влияет на пересылку пользовательского трафика или применение QoS, SMF обновляет соответствующие правила UPF посредством PFCP Session Modification.
Изменение ограничения скорости может потребовать обновления QER. Другие изменения политики могут затрагивать PDR, FAR или иное правило пользовательской плоскости. Конкретные правила зависят от услуги и политики управления; PDU Session Modification не обязательно переписывает все правила PFCP.
Полное изменение QoS можно представить так:
Политика / запрос UE
→ SMF пересчитывает параметры сессии
→ N4 обновляет применение правил в UPF
→ N2 обновляет ресурсы gNB
→ N1 обновляет параметры UE
→ каждая сторона подтверждает результат
Точный порядок сообщений может различаться в зависимости от причины и изменяемых параметров. При поиске неисправностей не нужно требовать, чтобы каждый сценарий содержал абсолютно одинаковую последовательность сообщений. Гораздо важнее подтвердить, что каждая точка выполнения, где требуется изменение, действительно получает и применяет новые параметры.
Завершение модификации и поиск неисправностей сигнализации
У проблем PDU Session Modification есть особенность, отличающая их от ошибок установления сессии: PDU-сессия может оставаться активной, и пользователь может продолжать передавать данные, хотя фактический QoS не соответствует ожидаемой политике.
Например, политика может требовать снижения скорости до 10 Mbps, PCF уже мог выдать новое решение политики, но реальный тест пропускной способности по-прежнему показывает значительно более высокую скорость. Сам факт существования PDU-сессии не доказывает успешность модификации. Необходимо определить, на каком этапе новые параметры перестали применяться.
Для практической диагностики можно использовать следующие контрольные точки:
Определить источник изменения: выяснить, было ли первым событием UE Modification Request, PCF Notification, изменение данных UDM или событие на стороне SMF/RAN;
Проверить решение SMF: подтвердить, что SMF принял запрос и PCF вернул ожидаемое решение политики;
Проверить применение на N4: если UPF должен применять новый QoS, убедиться, что PFCP Session Modification завершилась успешно и соответствующие параметры QER действительно изменились;
Проверить выполнение на N2: убедиться, что gNB получил PDU Session Resource Modify Request и вернул успешно измененные потоки QoS;
Проверить подтверждение на N1: убедиться, что UE получил PDU Session Modification Command и вернул PDU Session Modification Complete;
Проверить результат услуги: подтвердить, что реальный трафик теперь соответствует обновленной скорости, QoS или политике обслуживания.
Если PCF уже разрешил 10 Mbps, но QER в UPF все еще содержит прежний MBR, анализ следует сосредоточить на пути SMF–N4. Если UPF уже применяет новую скорость, но поток QoS в gNB продолжает использовать старые параметры, требуется дальнейшая проверка процедуры N2 Resource Modify. Если сетевая сторона выполнила все необходимые изменения, но UE так и не возвращает Modification Complete, следует проверить NAS, чтобы определить, были ли приняты новые правила QoS.
Название одного из сообщений также может вводить в заблуждение. В некоторых диаграммах используется выражение «PDU Session Modification Command Ack» для обозначения шага подтверждения UE. Однако в сигнализации 5GSM NAS фактическое сообщение, которое UE отправляет после принятия PDU Session Modification Command, называется PDU Session Modification Complete. Поэтому при анализе пакетов следует ориентироваться на реальный NAS Message Type.
Такой послойный подход к поиску неисправностей намного эффективнее, чем начинать анализ заново с Registration Request. PDU-сессия уже существует. Проблема состоит в том, что активная сессия не была согласованно обновлена в соответствии с новой политикой. Поэтому область поиска должна оставаться сосредоточенной на текущем SM Context, политике, QoS Flow и применении правил пользовательской плоскости.
Часто задаваемые вопросы
Назначает ли PDU Session Modification новый IP-адрес для UE?
Обычная модификация QoS обновляет существующую PDU-сессию и ее потоки QoS, а не создает всю сессию заново. Изменение других атрибутов зависит от конкретного сценария, но изменение только таких параметров, как 5QI или MBR, не следует считать новой процедурой PDU Session Establishment.
Всегда ли PDU Session Modification инициируется UE?
Нет. UE может запросить изменение через PDU Session Modification Request, но сетевая модификация также может быть вызвана изменением политики PCF, обновлением данных подписки UDM, локальным решением SMF или событием, связанным с RAN. Обычно SMF координирует необходимые обновления между UE, RAN и UPF.
В чем разница между PDU Session Modification и PFCP Session Modification?
PDU Session Modification — это общая процедура 5GS для изменения активной сессии, которая может затрагивать UE, RAN, SMF, PCF и пользовательскую плоскость. PFCP Session Modification выполняется непосредственно через интерфейс N4 между SMF и UPF и изменяет конкретные правила пользовательской плоскости в UPF. Вторая процедура может быть частью первой, но они не равнозначны.
Если QER уже обновлен, почему gNB и UE также требуют изменений?
QER управляет применением QoS в UPF, но поток QoS определяется не только на уровне UPF. UE может потребоваться новое правило QoS или описание потока, а RAN — соответствующая корректировка радиоресурсов. Поэтому некоторые изменения QoS требуют согласованности N1, N2 и N4. Обновление только UPF не означает завершения всей процедуры PDU Session Modification.
Может ли PDU Session Modification добавить новый поток QoS?
Да. PDU Session Modification может обновлять параметры существующего потока QoS, а в подходящих сценариях также использоваться для создания нового потока QoS в той же PDU-сессии. Например, сервис VoNR, инициируемый приложением, может потребовать дополнительный поток QoS с определенным 5QI. Такой сценарий отличается по сервисному контексту от простого обновления существующего потока и его лучше анализировать отдельно.
