При поиске неисправностей в пользовательской плоскости 5G Core часто возникает следующая ситуация: UE зарегистрирован нормально, PDU Session установлена, PDR правильно определяет трафик, а FAR пересылает пакеты по ожидаемому маршруту, однако счетчики использования, видимые SMF, не меняются. События тарификации могут не срабатывать, а управление квотой — не реагировать в ожидаемый момент. Во многих случаях сама пересылка пакетов работает корректно. Не хватает механизма, который указывает UPF, как измерять использование пользовательской плоскости и когда передавать результат в плоскость управления. Таким механизмом является URR (Usage Reporting Rule) на интерфейсе N4.

URR не определяет, куда должны пересылаться пакеты, и не задает напрямую ограничения пропускной способности. Вместо этого она сообщает UPF, какой совпавший трафик следует измерять, как измерять его использование и при каких условиях результат измерения должен быть передан в плоскость управления. Таким образом, URR превращает трафик пользовательской плоскости из просто пересылаемого трафика в трафик, использование которого можно измерять. Фактическое измерение выполняет UPF, SMF задает условия отчетности через PFCP, а полученные Usage Reports формируют непрерывную петлю обратной связи между пользовательской плоскостью и плоскостью управления.

Какую задачу решает URR в системе правил N4?

Проще всего понять URR, если отделить ее ответственность от задач PDR, FAR и QER. Когда UPF получает пакет, PDR сначала определяет, к какому трафику он относится. После классификации пакета FAR решает, как его следует обработать и куда переслать. QER применяет необходимую обработку QoS. URR отвечает на другой вопрос: какой объем этого трафика фактически был использован?

Основные типы правил PFCP можно кратко представить так:

PDR: Что это за трафик?
FAR: Как следует обработать пакет и куда его переслать?
QER: Какую обработку QoS следует применить к этому трафику?
URR: Какой объем этого трафика уже использован и когда об этом использовании нужно сообщить?

URR должна быть связана с соответствующим PDR. Причина проста: UPF не может осмысленно измерить, «сколько пользователь израсходовал», не зная сначала, какие пакеты относятся к данному UE, сервису или потоку трафика. После того как PDR идентифицировал трафик, связанная с ним URR может измерять использование совпавших пакетов. Если PDU Session содержит несколько PDR, можно использовать разные URR для построения более детальных отношений измерения использования.

Поэтому первым вопросом при поиске неисправностей URR обычно должен быть не «Была ли URR сконфигурирована?», а «Какой PDR соответствует измеряемому трафику и на какой URR ID он ссылается?» Если эта связь отсутствует или задана неверно, последующие этапы измерения и отчетности не смогут работать ожидаемым образом.

Как URR определяет, что именно измеряет UPF?

URR — это не просто счетчик трафика. Одним из первых элементов, задаваемых в Create URR, является Measurement Method. Он указывает UPF, какой вид использования необходимо измерять. В зависимости от требований сервиса измерение может основываться на объеме трафика, времени или событиях.

Для типовых пакетных сервисов проще всего наблюдать измерение по объему. UPF может измерять объем трафика в восходящем направлении, нисходящем направлении и суммарный объем, а соответствующие поля Volume Measurement указывают, какие статистики включены. Объем накапливается в байтах, поэтому URR может измерять общее использование либо разделять трафик UL и DL в зависимости от конфигурации.

Если необходимая возможность активирована, в измерение можно включить и количество пакетов. Например, флаг MNOP в Measurement Information может потребовать от UPF измерять число пакетов в восходящем и нисходящем направлениях, а также их общее количество. В таком случае оператор видит не только число переданных байтов, но и количество пакетов, обработанных за интервал измерения.

Измерение по времени ориентировано на длительность сервиса. В зависимости от конфигурации могут использоваться такие параметры, как Time Threshold, Time Quota, Inactivity Detection Time и соответствующий механизм измерения времени. Измерение по событиям, напротив, может подсчитывать определенные сервисные события и формировать отчет при достижении заданного количества событий.

Таким образом, Measurement Method отвечает на фундаментальный вопрос URR: что означает «использование» для этого правила? Если сначала не определить это, при анализе сообщений PFCP легко перепутать Threshold, Quota и Reporting Trigger. Выбранный метод измерения напрямую влияет на тип счетчиков, которые ведет UPF, формат Usage Report и на то, как SMF интерпретирует результат.

Reporting Trigger определяет, когда UPF должна отправить отчет

Одного метода измерения недостаточно. Если UPF просто продолжает накапливать счетчики без какого-либо условия отчетности, для SMF не определен момент, когда он должен получить результат. Поэтому Reporting Triggers являются еще одной ключевой частью механизма URR.

Эти триггеры можно комбинировать в соответствии с политикой сети. PERIO используется для периодической отчетности. VOLTH означает, что отчет должен формироваться при достижении порога объема. TIMTH относится к порогу времени. START и STOPT могут запускать Usage Reports, когда UPF обнаруживает начало или прекращение трафика.

Другая группа триггеров теснее связана с управлением квотой. VOLQU относится к условиям квоты объема, TIMQU — к условиям квоты времени, а EVEQU — к условиям квоты событий. Quota Holding Time также может применяться, если квота уже предоставлена, но абонент не создает трафик пользовательской плоскости в течение заданного периода.

Особенно важно различать Threshold и Quota, поскольку в PFCP они служат разным целям и часто смешиваются при анализе трассировок:

Threshold прежде всего определяет, когда результат измерения должен быть передан, тогда как Quota ближе к понятию сколько ресурса еще доступно для использования. Если в трассировке PFCP видно только, что установлен VOLTH или VOLQU, но инженер не проверяет соответствующий параметр Threshold или Quota, легко неверно понять фактическую логику сервиса.

Например, если VOLTH настроен, но соответствующий Volume Threshold не задан корректно, у UPF отсутствует осмысленная граница трафика, при которой должен сработать ожидаемый отчет.

Как UPF отправляет результаты измерения использования в SMF?

Механизм URR образует полный цикл обратной связи через процедуру PFCP Session Report. После выполнения условия отчетности, заданного URR, UPF не обязательно ждать, пока SMF запросит счетчики. Она может отправить в SMF PFCP Session Report Request.

Если Report Type показывает, что сообщение содержит Usage Report, SMF может определить событие как отчет об использовании пользователем. При анализе особенно важны несколько полей. URR ID указывает, какое правило сформировало отчет. UR-SEQN задает номер последовательности Usage Report для этой URR. Usage Report Trigger объясняет причину формирования отчета.

Фактические измеренные значения затем появляются в полях, соответствующих Measurement Method. При измерении по объему Volume Measurement может содержать суммарное значение, а также значения восходящего и нисходящего использования. При измерении по времени важнее становится Duration Measurement. Поля Start Time, End Time, Time of First Packet и Time of Last Packet также помогают определить точный интервал измерения, охваченный отчетом.

Получение Usage Report не обязательно завершает процесс. В зависимости от логики сервиса SMF может продолжить работу, отправив PFCP Session Modification для обновления URR, например изменить порог отчетности, выделить новую квоту или изменить условия следующего отчета.

Полный процесс URR можно представить следующим образом:

SMF конфигурирует URR → UPF измеряет совпавший трафик → выполняется условие Reporting Trigger → UPF отправляет Usage Report → SMF обрабатывает результат использования → при необходимости URR обновляется.

Следовательно, отчетность об использовании — это не просто передача счетчика со стороны UPF. Это динамический процесс, в котором плоскость управления определяет политику измерения, пользовательская плоскость выполняет измерение, а результат непрерывно возвращается в плоскость управления. Проблема на любом этапе может привести к неточным значениям использования или отсутствующим отчетам.

Как Volume Threshold запускает фактический Usage Report?

Логику URR проще понять на конкретном примере трафика. Предположим, SMF создает URR во время PFCP Session Establishment и указывает UPF использовать измерение по объему для трафика, совпавшего с определенным PDR. В качестве Reporting Trigger активируется VOLTH.

Если Volume Threshold настроен для TOVOL со значением 10240 байт, это не означает, что пользователю разрешено израсходовать не более 10240 байт. Это означает следующее: когда измеренный суммарный объем восходящего и нисходящего трафика достигнет этого порога, UPF должна сформировать Usage Report.

Когда UE начинает генерировать трафик, UPF продолжает обычную пересылку пакетов и одновременно накапливает счетчики использования, заданные URR. При достижении накопленным объемом порога отчетности UPF отправляет PFCP Session Report Request. В Usage Report триггер VOLTH указывается как причина, а Volume Measurement содержит фактическое общее использование и соответствующие значения восходящего и нисходящего трафика.

Итоговое переданное значение не обязано останавливаться ровно на 10240 байтах. UPF проверяет порог во время обработки реальных пакетов, и один целый пакет может сразу увеличить накопленное использование со значения ниже порога до значения выше него. Поэтому Usage Report со значением немного выше настроенного Threshold не является противоречием.

Отсюда следует важный принцип анализа поведения URR: Threshold — это граница для формирования отчета, а не механизм, обрезающий измеренное значение до точного числа. Если одновременно настроена Quota, ее исчерпание может вызвать дополнительные управляющие действия, однако этот путь следует анализировать отдельно и не смешивать с простой отчетностью по порогу.

Поиск неисправностей URR должен идти по четырем уровням: связь, измерение, триггер и отчетность

Проблемы URR бывает трудно заметить, поскольку сам сервис пользовательской плоскости может выглядеть полностью исправным. UE получает доступ к сети, PDR корректно сопоставляет трафик, FAR продолжает пересылать пакеты, но счетчики использования во внутренних серверных системах остаются неверными, Usage Report не формируется либо ожидаемое событие в плоскости управления не происходит после достижения порога.

Поэтому поиск неисправностей URR не следует начинать с вопроса «Может ли пользователь получить доступ к сети?». Необходимо последовательно пройти всю цепочку измерения использования.

Сначала подтвердите связь PDR с URR

Сначала определите PDR, который фактически совпадает с трафиком, а затем проверьте связанный с ним URR ID. Одна PFCP Session может содержать несколько PDR и несколько URR. Анализ неправильной URR не объяснит текущие результаты использования, даже если все параметры этой URR выглядят корректными.

Типичная проблема возникает, когда условие совпадения PDR уже изменилось, а URR все еще связана с прежним PDR ID. В таком случае сам объект измерения уже не соответствует фактическому трафику.

Затем проверьте Measurement Method и направление

Проверьте, настроена ли URR на измерение Volume, Duration или Event. Если используется измерение по объему, также убедитесь, что правило измеряет требуемые Total, UL, DL или количество пакетов.

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

Проверьте Reporting Trigger и соответствующий Threshold

Если UPF не формирует отчет, выясните, какой триггер фактически запросила плоскость управления. Настройка VOLTH без подходящего Volume Threshold или ожидание периодических отчетов при неактивном PERIO могут привести к результатам, отличающимся от предполагаемого поведения сервиса.

Аналогично, отчетность по времени следует интерпретировать вместе с соответствующими параметрами измерения времени и условиями мониторинга, а не рассматривать один флаг триггера изолированно.

В конце проследите PFCP Session Report

После выполнения условия триггера проверьте, отправляет ли UPF ожидаемый Usage Report. Сопоставьте Report Type, URR ID, UR-SEQN и Usage Report Trigger с текущей PFCP Session.

Если UPF уже сформировала отчет, но новая квота, новый порог или последующее управляющее действие не появляются, поиск неисправности следует перенести в сторону SMF и дальнейшей логики плоскости управления, а не продолжать концентрироваться на счетчике UPF.

Если проблема связана с измерением до или после применения QoS, необходимо также проверить соответствующие флаги в Measurement Information и Usage Information. URR — это не просто одно изолированное число. Временное окно измерения, измеряемый трафик и этап обработки, на котором выполняется измерение, вместе влияют на то, как следует интерпретировать итоговое значение использования.

Во многих случаях «использование не сходится» не из-за неправильного счетчика UPF, а из-за несоответствия фактического охвата измерения ожидаемому охвату учета.

URR превращает трафик пользовательской плоскости в измеримую информацию для плоскости управления

PDR, FAR и QER в основном описывают, как пакеты идентифицируются, пересылаются и подвергаются обработке QoS внутри UPF. URR добавляет еще одну важную возможность: она позволяет плоскости управления знать, какой объем трафика пользовательской плоскости фактически был использован.

URR использует Measurement Method для определения области измерения, Reporting Trigger — для определения момента формирования отчета, а такие параметры, как Threshold, Quota и Monitoring Time, — для управления различными этапами измерения использования. После выполнения требуемого условия UPF передает результат обратно в SMF в составе PFCP Usage Report, после чего плоскость управления при необходимости может обновить URR или выполнить другое действие политики.

Поэтому наиболее практичный способ понять URR — не запоминать десятки Information Elements, а проследить одну полную цепочку:

PDR выбирает измеряемый трафик → URR определяет метод измерения → UPF непрерывно измеряет использование → Reporting Trigger определяет момент отчета → Usage Report возвращает результат в SMF → SMF при необходимости обновляет политику управления.

Когда эта цепочка понятна, такие параметры, как Volume Threshold, Volume Quota, Measurement Period, Monitoring Time и различные Reporting Triggers, перестают выглядеть отдельными несвязанными полями PFCP. Они становятся разными точками управления внутри единого механизма измерения и отчетности по использованию 5G.

Для сервисов, которым необходимы тарификация по фактическому использованию, управление квотой в реальном времени или корректировка политики в зависимости от потребления, этот механизм служит основой, благодаря которой пользовательская плоскость 5G способна не только пересылать трафик, но и быть измеримой и управляемой.

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