Когда UPF получает пакет пользовательской плоскости, она не сразу решает, куда его переслать. Сначала необходимо определить, к какой PFCP-сессии относится пакет и какое правило обработки следует применить. В рамках правил PFCP на интерфейсе N4 эту первую стадию обработки выполняет PDR (Packet Detection Rule, правило обнаружения пакетов) . PDR указывает UPF, какие пакеты относятся к определённой категории трафика. После совпадения пакета UPF может применить связанные FAR, QER, URR и другие правила для пересылки, обеспечения QoS и формирования отчётности об использовании.

• Проще всего понять PDR, если разделить три разных задачи: PDR идентифицирует трафик, PDI задаёт условия совпадения, а FAR/QER/URR определяют, что происходит после совпадения. Такое разделение ролей делает обработку пакетов PFCP гораздо понятнее, чем попытка запомнить каждый отдельный IE.

Какую задачу решает PDR на интерфейсе N4?

N4 — это управляющий интерфейс между SMF и UPF в ядре 5G. SMF использует PFCP-сессии для установки в UPF правил обработки пользовательской плоскости, а PDR является типом правила, отвечающим за обнаружение и классификацию пакетов. PDR обычно создаётся при установлении PFCP-сессии, а затем может добавляться, удаляться или обновляться посредством PFCP Session Modification. Иными словами, классификация пакетов управляется правилами, которые SMF предоставляет в соответствии с текущей PDU Session, потоком трафика и требованиями к пересылке.

Одна PFCP-сессия может содержать несколько PDR. Например, для одной PDU Session обычно требуются отдельные правила для восходящего и нисходящего трафика. Дополнительные PDR могут понадобиться, если сессия включает несколько service data flow, разные QoS Flow или более детальную классификацию трафика. Поэтому PDR можно рассматривать как правило выбора трафика в UPF: оно определяет, какой тип пакета поступил, прежде чем другие правила решат, как этот пакет обрабатывать.

Как UPF находит подходящую PDR?

Обработка пакетов в UPF выполняется в определённой последовательности. После поступления пакета UPF сначала определяет соответствующую PFCP-сессию, а затем оценивает связанные с ней PDR. Если потенциально могут совпасть несколько PDR, UPF использует значение Precedence для определения их относительного приоритета. Меньшее значение Precedence означает более высокий приоритет, поэтому при поиске совпадения правила с более высоким приоритетом оцениваются раньше правил с более низким.

После совпадения PDR само правило PDR не выполняет все последующие операции обработки пакета. Вместо этого оно может ссылаться на другие правила PFCP:

• FAR (Forwarding Action Rule, правило действия пересылки): определяет, как должен быть обработан и переслан пакет, включая пересылку, отбрасывание, буферизацию или отправку к определённому интерфейсу назначения.

• QER (QoS Enforcement Rule, правило обеспечения QoS): применяет связанные с QoS механизмы, например gating, ограничение скорости и другие виды обработки трафика.

• URR (Usage Reporting Rule, правило отчётности об использовании): измеряет объём использования трафика и формирует информацию для тарификации, мониторинга или других задач, связанных с политиками.

Таким образом, общий путь обработки в UPF можно упростить до следующей схемы:
Определить PFCP-сессию → оценить PDR по Precedence → классифицировать пакет → применить FAR/QER/URR. Порядок имеет значение. FAR отвечает на вопрос, как следует обработать пакет, но сначала UPF должна с помощью PDR определить, к какому пакету или потоку трафика относится это действие.

Какие основные параметры содержит PDR?

Create PDR содержит ряд Information Element, однако для первоначального понимания механизма обнаружения пакетов достаточно меньшего набора. Эти параметры определяют, как идентифицируется правило, как выполняется сопоставление пакетов и какие последующие правила обработки связываются с результатом.

Среди этих параметров именно элемент, который фактически определяет, какие пакеты могут соответствовать PDR, — это PDI (Packet Detection Information). FAR ID и QER ID ссылаются на действия, выполняемые после классификации трафика; PDI содержит информацию, необходимую для самой классификации.

Как PDI задаёт условия сопоставления пакетов?

PDI можно понимать как набор условий обнаружения пакетов внутри PDR. Это не одно поле. PDI содержит несколько параметров, которые можно комбинировать для идентификации трафика по месту входа пакета в UPF, информации о туннеле, адресу UE, характеристикам сервисного потока и данным QoS. К распространённым параметрам PDI относятся:

• Source Interface: определяет логическую сторону, с которой поступает пакет, например Access для трафика со стороны доступа или Core для трафика, поступающего со стороны ядра или сети данных.

• Local F-TEID: может использоваться для сопоставления TEID и связанной адресной информации туннеля GTP-U, что особенно важно при обнаружении восходящего туннельного трафика.

• Network Instance: идентифицирует логическую сеть, настроенную в UPF, например сетевой экземпляр, связанный с Internet или IMS.

• UE IP Address: сопоставляет трафик по исходному или целевому IP-адресу UE в зависимости от направления пакета.

• Traffic Endpoint ID: идентифицирует конечную точку трафика, которая может использоваться в поддерживаемых сценариях оптимизации PDI.

• SDF Filter: обеспечивает более детальную фильтрацию по таким параметрам, как исходный и целевой адреса, протокол, порты и направление трафика.

• Application ID: может использоваться для идентификации трафика на уровне приложения, если UPF поддерживает необходимую функцию обнаружения приложений.

• QFI (QoS Flow Identifier): идентифицирует QoS Flow, связанный с пакетом.

• Source Interface Type: предоставляет дополнительную информацию об интерфейсе 3GPP, связанном с источником, например N3, N6 или N9.

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

Насколько детальной может быть классификация трафика с помощью SDF Filter?

Source Interface, F-TEID и UE IP Address могут быть достаточны для идентификации сессии или широкой категории трафика, но не всегда позволяют различить отдельные service data flow. Более точную классификацию обеспечивает SDF Filter . Его Flow Description может включать исходный IP-адрес, целевой IP-адрес, номер протокола, исходный порт, целевой порт и направление трафика. Эти поля позволяют UPF различать конкретные IP-потоки, а не обрабатывать все пакеты, связанные с одним UE, одинаково.

SDF Filter также может содержать дополнительную информацию для сопоставления:

• TOS / Traffic Class: сопоставляет поле Type of Service в IPv4 или Traffic Class в IPv6.

• Security Parameter Index (SPI): может использоваться при сопоставлении трафика, связанного с IPsec Security Association.

• Flow Label: сопоставляет Flow Label в заголовке IPv6.

• SDF Filter ID: идентифицирует связанный SDF Filter для управления и ссылок.

Так формируется многоуровневая модель классификации. Параметры PDI, такие как интерфейс, туннель и адрес UE, сначала могут сузить трафик до конкретного контекста, а SDF Filter — определить отдельные IP-потоки внутри этого контекста. Если поддерживается идентификация приложений, UPF может использовать дополнительный механизм классификации на уровне приложений, а не полагаться только на адреса и порты.

Чем отличаются PDR для uplink и downlink?

Сравнение восходящего и нисходящего трафика — один из самых наглядных способов понять работу PDR. Оба направления используют одинаковую общую структуру правил, но пакеты поступают в UPF через разные интерфейсы и поэтому требуют разных критериев обнаружения.

Для типичного восходящего трафика пакеты поступают в UPF со стороны радиодоступа. Поэтому PDI может использовать Source Interface = Access. Дополнительно правило может использовать Local F-TEID для идентификации туннеля GTP-U и UE IP Address для идентификации трафика UE. Типичная uplink-PDR может требовать:

• Source Interface равен Access;

• входящий пакет GTP-U соответствует указанному F-TEID, включая соответствующие TEID и адресную информацию;

• IP-адрес UE соответствует адресу, связанному с сессией.

Если условия выполнены, PDR считается совпавшей. Поскольку трафик по N3 обычно инкапсулирован в GTP-U, Outer Header Removal может указать UPF удалить внешние заголовки GTP-U/UDP/IP до обработки пакета в соответствии со связанной FAR.

Обнаружение downlink начинается с противоположного направления. Пакеты обычно приходят из сети данных к UPF, поэтому PDI может использовать Source Interface = Core. В этом случае такие параметры, как Network Instance и UE IP Address могут использоваться для определения PDU Session, к которой относится пакет. Типичная downlink-PDR может требовать:

• Source Interface равен Core;

• Network Instance соответствует требуемой логической сети, например «internet» или «ims»;

• назначение пакета соответствует IP-адресу UE, связанному с сессией.

После совпадения downlink-PDR связанная FAR определяет, как пакет должен быть переслан в сторону доступа, включая необходимое туннельное поведение. Таким образом, различие между uplink- и downlink-PDR отражает направление поступления пакетов в UPF и информацию, доступную для их идентификации.

Как совместно работают PDR, FAR, QER и URR?

PDR решает задачу идентификации пакета, но не представляет всю политику обработки пользовательской плоскости. PFCP разделяет обнаружение пакетов, пересылку, обеспечение QoS и измерение использования на разные типы правил. Такое разделение позволяет каждому правилу выполнять конкретную функцию, оставаясь частью одной PFCP-сессии.

PDR: Что это за трафик? (Обнаружение и классификация)
FAR: Что с ним делать и куда его направить? (Действие пересылки)
QER: Какую QoS-обработку применить? (Обеспечение QoS)
URR: Как измерять и отчитываться об использовании? (Отчётность об использовании)

Рассмотрим uplink-пакет, соответствующий PDR. После того как UPF определяет, к какому UE и сервисному потоку относится пакет, она может удалить требуемый внешний заголовок GTP-U, применить поведение пересылки, указанное FAR, обеспечить соответствующую QER и учитывать трафик в соответствии со связанной URR. Результат обнаружения пакета тем самым задаёт контекст для всех последующих операций.

С инженерной точки зрения PDR не следует рассматривать как изолированную политику пересылки. Это точка входа в набор правил пользовательской плоскости PFCP. Когда становится понятна связь между PDR для классификации, PDI для критериев сопоставления и FAR/QER/URR для последующей обработки , такие параметры, как Source Interface, F-TEID, UE IP Address и SDF Filter, намного проще понимать при реальном анализе сигнализации N4 и пакетов.

FAQ