Типичный случай диагностики пользовательской плоскости 5G сначала может показаться запутанным: PDU Session успешно установлена, UE получил IP-адрес, PDR соответствует ожидаемому трафику, FAR содержит FORW, и пакеты даже могут начать проходить. Тем не менее пользователь сталкивается с буферизацией видео, неожиданно низкой скоростью загрузки или трафиком, работающим только в одном направлении.
В такой ситуации проверка только PDR и FAR может не выявить причину. Проблема может быть связана не с тем, был ли трафик идентифицирован или куда был перенаправлен пакет, а с тем, какую QoS-политику UPF применил после разрешения пересылки. В рамках PFCP-правил на интерфейсе N4 QER (QoS Enforcement Rule, правило применения QoS) отвечает за реализацию этих QoS-политик в UPF. Оно может разрешать или запрещать прохождение трафика, ограничивать скорость uplink или downlink, связывать трафик с QoS Flow и применять маркировку транспортного уровня. Поэтому для понимания полного поведения пользовательской плоскости PDR, FAR и QER нужно рассматривать совместно.
Почему QER по-прежнему нужен, если PDR и FAR уже работают?
Проще всего понять QER, если разделить обязанности разных правил UPF.
PDR сначала отвечает на вопрос «Что это за трафик?». Для обнаружения и классификации пакетов используются условия PDI, IP-адрес UE, F-TEID и SDF Filter. После идентификации трафика FAR отвечает на следующий вопрос: «Что нужно сделать с этим пакетом и куда его следует переслать?»
Но разрешение пересылки пакета не означает, что он может передаваться без ограничений. Если сеть должна управлять скоростью, управление пропусканием, связью с QoS Flow или маркировкой транспортного уровня, UPF обязана применить связанный QER.
Поэтому типичную последовательность обработки можно упростить так:
PDR определяет трафик → FAR задаёт действие пересылки → QER применяет QoS-политику.
Эти правила не заменяют друг друга, а работают совместно. Пакет может корректно соответствовать PDR и быть разрешён FAR, но при этом оставаться ограниченным скоростью или условиями управление пропусканием, определёнными QER. Без QER UPF может знать, что пакет следует переслать, но не будет иметь такой же информации о том, как этот трафик должен обрабатываться с точки зрения QoS.
Когда устанавливается QER и почему он может обновляться позже?
QER обычно передаётся SMF в UPF во время PFCP Session Establishment как часть правил пользовательской плоскости для PDU Session. Это не QoS-правило, которое UPF самостоятельно создаёт после наблюдения за трафиком. Управляющая плоскость определяет требуемое QoS-поведение, а UPF применяет полученное правило.
QER не обязательно остаётся неизменным в течение всей жизни сессии. Если политика меняется во время активного сервиса, SMF может обновить существующий QER посредством PFCP Session Modification. Изменения политики подписки, приложения или других решений управляющей плоскости могут привести к новым ограничениям скорости, другим состояниям Gate, изменению связи с QoS Flow или другим QoS-параметрам.
Поэтому диагностика не должна останавливаться на первоначальном Create QER. Если проблема QoS возникает после того, как сессия уже некоторое время работала, нужно также изучить последующие Update QER и сравнить их с исходными значениями.
С точки зрения управляющей плоскости QoS-политика, используемая SMF, может поступать из локальной конфигурации или из информации политики, связанной с PCF. Когда политика достигает интерфейса N4, она представлена в виде PFCP-правил, которые UPF может применять. В зависимости от дизайна сервиса QoS может применяться на уровне PDU Session, QoS Flow или к более конкретному SDF- либо прикладному трафику.
Как Gate Status может блокировать трафик, даже если сессия выглядит нормально?
Gate Status — один из самых прямых параметров QER, поскольку он может немедленно изменить разрешение на прохождение трафика.
Состояния Gate для uplink и downlink могут управляться независимо. Если Gate имеет состояние OPEN, трафику в этом направлении разрешено продолжать передачу. Если он CLOSED, трафик в этом направлении блокируется правилом QoS.
Типичная последовательность диагностики может выглядеть так:
PDU Session успешно установлена;
UE получил IP-адрес;
PDR совпадает корректно;
FAR содержит FORW;
Но прикладной трафик всё равно не работает.
В этот момент следует проверить UL Gate и DL Gate в связанном QER. Поскольку направления управляются независимо, один Gate может быть OPEN, а другой CLOSED. Симптом может выглядеть как односторонняя проблема пользовательской плоскости: UE получает downlink-трафик, но не может успешно отправлять uplink-трафик, либо наоборот.
Именно поэтому QER является правилом применения QoS, а не просто описательным QoS-атрибутом. Его настройки напрямую определяют, разрешено ли конкретному трафику проходить через UPF.
Что контролируют MBR, GBR и Packet Rate?
Gate Status отвечает на вопрос «Может ли трафик проходить?». Параметры скорости отвечают на другой вопрос: «Сколько трафика может пройти и с какой скоростью?». QER может применять ограничения как по битрейту, так и по частоте пакетов.
Максимальный битрейт (MBR)
MBR задаёт максимальный битрейт соответствующего трафика и может настраиваться отдельно для uplink и downlink. В среде 5GC ограничение может относиться к уровню сессии, определённому QoS Flow или более конкретному потоку в зависимости от конструкции правил.
Если пользователь нормально получает доступ к сервису, но пропускная способность постоянно упирается примерно в один и тот же предел, MBR связанного QER — один из параметров, которые следует проверить.
MBR легко спутать с ёмкостью радиосети. Хорошие радиусловия и достаточная транспортная полоса не гарантируют, что приложение сможет использовать всю физическую ёмкость. Если UPF должна применять более низкий MBR, пропускная способность пользовательской плоскости останется ограниченной этим значением. Поэтому при низкой пропускной способности следует проверять QoS-правила N4, а не только радиопроизводительность.
Гарантированный битрейт (GBR)
GBR описывает гарантированный битрейт для трафика, требующего определённого уровня гарантии ресурсов. Он также может задаваться отдельно для uplink и downlink.
GBR может быть важен для сервисов, которым требуется более предсказуемая производительность, например для некоторых голосовых, видео или других чувствительных к QoS приложений реального времени. Его не следует рассматривать как отдельное число; нужно учитывать соответствующий QoS Flow и общую QoS-политику.
Концептуально MBR определяет верхнюю границу разрешённой скорости, а GBR описывает требование гарантированной скорости, связанное с политикой сервиса.
Частота пакетов
Некоторые типы трафика нельзя адекватно описать только битрейтом. QER также может содержать параметры Packet Rate, ограничивающие число пакетов, разрешённых за определённый период.
Это важно для нагрузок, создающих много мелких пакетов, например DNS-транзакций, IoT keepalive или трафика сигнального характера. Общий битрейт может оставаться относительно низким, тогда как число пакетов в секунду становится высоким. В таких случаях проверка только MBR может не объяснить наблюдаемое QoS-поведение.
При достижении ограничения Packet Rate пользователь может заметить увеличение задержки, более медленные ответы или неудачные запросы, хотя суммарное потребление полосы выглядит умеренным.
Что делают QFI, Flow Level Marking и PPI в QER?
QER — это больше, чем ограничитель скорости. Помимо Gate Status, MBR и GBR, он может содержать параметры, связанные с идентификацией QoS Flow и обработкой пакетов. Вместе они помогают определить обработку трафика в пользовательской плоскости.
QoS Flow Identifier (QFI)
QFI идентифицирует QoS Flow. Одна PDU Session может содержать несколько QoS Flows, чтобы разные типы сервисного трафика получали разную QoS-обработку.
С точки зрения пользовательской плоскости QFI показывает, с каким QoS Flow связан пакет. В QER этот идентификатор может использоваться для связи соответствующего поведения QoS с нужным QoS Flow.
Если QFI, связанный с правилом, не соответствует задуманному дизайну сервиса, трафик может быть связан с неожиданным QoS Flow, даже если параметры скорости выглядят корректно. Это может привести к обработке ресурсов, отличающейся от предусмотренной сервисом.
DL Flow Level Marking
QER может указать UPF применить маркировку уровня потока к downlink-трафику, например установить значение DSCP для IP-транспортной сети.
Эта маркировка не определяет, к какому 5G QoS Flow относится пакет. Она влияет на то, как пакет может идентифицироваться и обрабатываться после попадания в IP-транспортную сеть.
Если маркировка транспортного уровня неверна, 5G QoS может быть настроен правильно, но нижележащая транспортная сеть всё равно будет обрабатывать пакет с непредусмотренным приоритетом.
Paging Policy Indicator (PPI)
PPI связан с обработкой пейджинг-политики для downlink-трафика. QER может предоставлять соответствующую информацию в применимых сценариях пересылки, чтобы разные типы трафика обрабатывались по-разному при участии пейджинг.
Для UE, который сейчас не находится в активном состоянии пользовательской плоскости, разные типы downlink-трафика могут иметь различные последствия для пейджинг. PPI предоставляет информацию, используемую в таком дифференцированном подходе.
Averaging Window
Ограничение скорости не всегда может основываться на мгновенном наблюдении одного пакета. Averaging Window определяет временное окно, в котором оценивается поведение, связанное с битрейтом.
Более короткое окно быстрее реагирует на всплески трафика, а более длинное создаёт более сглаженное среднее и может иначе допускать короткие всплески. Поэтому анализ QER не должен ограничиваться QER ID и MBR. Итоговое QoS-поведение может зависеть от совместной работы нескольких параметров.
Как использовать сообщения PFCP для проверки того, что QER работает ожидаемым образом?
Наиболее полезный подход к анализу QER — не запоминать каждый информационный элемент, а связывать PFCP-правило с фактическим симптомом сервиса.
Например, Create QER может содержать:
QER ID = 1;
UL Gate = OPEN;
DL Gate = OPEN;
UL MBR = 100000 kbps;
DL MBR = 150000 kbps.
Эти значения приведены только как пример, но показывают важный момент: OPEN Gate не означает отсутствие QoS-ограничений. Трафику может быть разрешено проходить, но он всё равно будет ограничиваться MBR.
Практическая последовательность диагностики может включать следующие шаги:
Сначала определить PDR. Определить, какая PDR действительно соответствует проблемному трафику. Если выбрана неправильная PDR, ожидаемый QER не будет применён корректно.
Проверить QER ID, на который ссылается PDR. Не следует без контекста проверять все QER в PFCP-сессии. Сначала нужно определить QER, который фактически связан с анализируемым трафиком.
Проверить Create QER и Update QER. Убедиться, не было ли текущее активное правило изменено позднейшим PFCP Session Modification. QoS-проблема может быть внесена последующим обновлением, а не первоначальной настройкой сессии.
Проверить Gate Status. Отдельно проверить состояния Gate для uplink и downlink. Закрытый Gate только в одном направлении может привести к одностороннему отказу сервиса.
Проверить MBR, GBR и Packet Rate. Сравнить настроенные ограничения с наблюдаемой пропускной способностью или поведением пакетов, особенно если сервис постоянно упирается примерно в фиксированную скорость.
Проверить QFI и другие QoS-параметры. Убедиться, что ожидаемый QoS Flow, маркировка и параметры, связанные с пейджинг, соответствуют дизайну сервиса.
Сравнить правило с реальным трафиком пользовательской плоскости. PFCP показывает, что UPF должна применять; тесты пропускной способности и захваты пакетов показывают, что произошло фактически. Разница между этими двумя представлениями часто является самым полезным диагностическим признаком.
Этот метод надёжнее, чем изолированное толкование одного поля QER. PFCP-сигнализация показывает, что UPF должна применять, а тестирование пользовательской плоскости показывает фактически наблюдавшийся результат. Сопоставление этих представлений — ключ к определению того, ведёт ли себя QER как задумано.
FAQ
В чём основное различие между QER и FAR?
FAR главным образом определяет, как обрабатывать совпавший пакет и куда его пересылать, включая действия FORW, DROP или BUFF. QER применяет QoS-поведение, такое как управление пропусканием, ограничения скорости, связь с QoS Flow и маркировка транспортного уровня. Оба правила обычно работают после того, как PDR идентифицировала трафик. Упрощённо: FAR определяет куда и как пересылается пакет, а QER определяет какая QoS-обработка применяется к этому трафику.
Почему пропускная способность пользователя может оставаться низким, когда Gate Status имеет OPEN?
OPEN означает только, что трафик в этом направлении разрешён. Он не отменяет другие QoS-ограничения. Нужно продолжать проверять MBR, GBR, Packet Rate и связанный QoS Flow. Если MBR настроен ниже доступной радио- или транспортной ёмкости, пропускная способность останется ограниченной, даже когда оба Gate полностью открыты.
Можно ли создать QER только во время PFCP Session Establishment?
Нет. QER можно создать во время PFCP Session Establishment, а затем изменить через PFCP Session Modification. Если QoS-поведение меняется после запуска сессии, нужно анализировать последующие Update QER, а не только первоначальный Create QER.
QFI и QER — одно и то же?
Нет. QFI — идентификатор QoS Flow, а QER — правило применения QoS, исполняемое UPF. QER может содержать или ссылаться на информацию QFI, чтобы конкретная QoS-обработка была связана с соответствующим QoS Flow. QFI определяет какой QoS Flow участвует, а QER задаёт как к трафику применяется QoS-контроль.
Почему трафик всё ещё может не работать, если PDR совпадает, а FAR разрешает пересылку?
Потому что обработка пользовательской плоскости не обязательно заканчивается на FAR. После разрешения пересылки связанный QER всё ещё может применять Gate Status, MBR, GBR, Packet Rate или другие QoS-ограничения. Поэтому при диагностике PDR, FAR и QER нужно рассматривать как непрерывную цепочку обработки. Несоответствие на любом из этапов может повлиять на конечный результат сервиса.
