Типичный сценарий поиска неисправности в сети 5G сначала выглядит простым: UE успешно регистрируется, PDU Session устанавливается, IP-адрес назначается правильно, однако веб-доступ не работает и даже обычный Ping не проходит. Захват пакетов может показывать трафик, поступающий в UPF по N3, но соответствующий пакет не выходит по ожидаемому пути. Если анализ ограничивается только сигнализацией AMF и результатом установления PDU Session, реальную причину бывает трудно локализовать.
Успешное установление PDU Session не означает автоматически, что путь пересылки пользовательской плоскости работает. После получения пакета UPF сначала использует PDR для идентификации трафика, а затем применяет связанную FAR (Forwarding Action Rule, правило действия пересылки) , чтобы определить дальнейшее действие: переслать, отбросить, буферизовать или продублировать пакет. FAR также может задавать интерфейс назначения и необходимость создания внешнего заголовка туннеля GTP-U.
С точки зрения диагностики это различие полезно: PDR отвечает на вопрос «К какой сессии и какому потоку трафика относится этот пакет?», а FAR отвечает на вопрос «Пакет уже идентифицирован — что теперь должна сделать с ним UPF?» Если процедуры управляющей плоскости выглядят нормальными, но пользовательский трафик по-прежнему не проходит, FAR на интерфейсе N4 становится важной точкой проверки.
Почему успешная PDU Session не гарантирует связность пользовательской плоскости?
Завершение процедуры PDU Session Establishment подтверждает только инициализацию необходимых ресурсов сессии управляющей плоскости. Реальный прикладной трафик по-прежнему зависит от полного пути пользовательской плоскости, включающего gNB, N3, UPF и N6.
Для типичной Internet PDU Session восходящий трафик идёт от UE к gNB, инкапсулируется в туннель GTP-U и поступает в UPF по N3. UPF должна удалить соответствующий внешний заголовок туннеля, идентифицировать трафик и переслать исходный пакет в сеть данных. В нисходящем направлении всё происходит наоборот: трафик поступает в UPF с N6, UPF определяет соответствующую PDU Session, получает информацию о туннеле пользовательской плоскости gNB, добавляет требуемый внешний заголовок GTP-U и отправляет пакет к gNB по N3.
Такое поведение пересылки не появляется автоматически только потому, что PDU Session создана. SMF должна через N4 установить в UPF соответствующие правила PFCP. PDR определяет совпадающий трафик, а FAR задаёт действие пересылки после его классификации. Для корректной обработки пользовательской плоскости необходимы оба типа правил.
Если вся сигнализация управляющей плоскости выглядит нормальной, но сервис недоступен, проблему можно свести к двум основным вопросам:
Правильно ли PDR идентифицирует текущий трафик?
После идентификации пакета содержит ли связанная FAR правильные параметры обработки и пересылки?
Проверка связи между PDR и FAR часто эффективнее, чем многократный просмотр всей процедуры установления PDU Session с самого начала.
Что на самом деле FAR указывает делать UPF?
FAR — это правило пересылки в рамках PFCP. SMF устанавливает его в UPF через N4, а связь с трафиком создаётся через FAR ID, на который ссылается PDR. Когда пакет совпадает с этой PDR, UPF выполняет поведение обработки, заданное указанной FAR.
FAR может содержать несколько Information Elements. Для диагностики пользовательской плоскости особенно важны следующие поля:
| Параметр FAR | Основная функция |
|---|---|
| FAR ID | Уникально идентифицирует экземпляр FAR, чтобы PDR могла ссылаться на правильное правило пересылки |
| Apply Action | Определяет базовое действие над пакетом: пересылку, отбрасывание, буферизацию или дублирование |
| Forwarding Parameters | Определяет назначение, Network Instance, туннельную инкапсуляцию и другие параметры, используемые при пересылке |
| Duplicating Parameters | Определяет, как должна пересылаться дублированная копия пакета при включённом дублировании трафика |
| BAR ID | Ссылается на правило Buffering Action Rule, используемое для управления буферизацией пакетов |
На практике Apply Action и Forwarding Parameters — два элемента, которые чаще всего путают. Apply Action отвечает «Какое действие нужно выполнить?», а Forwarding Parameters отвечает «Если пакет пересылается, как и куда его нужно отправить?»
Наличие флага FORW в Apply Action само по себе не доказывает, что нисходящий путь полностью сформирован. Destination Interface, Network Instance, информация Outer Header Creation и другие связанные параметры пересылки также должны быть корректными.
Как Apply Action определяет первый шаг обработки пакета?
Apply Action представлен набором битовых флагов, которые указывают UPF, какие базовые операции нужно применить к совпавшим пакетам. Эти флаги не являются просто взаимоисключающими вариантами; их смысл следует интерпретировать в контексте PFCP-сессии и конкретного сервисного сценария.
DROP: Отбросить совпавший пакет.
FORW: Переслать пакет согласно применимым Forwarding Parameters.
BUFF: Буферизовать пакет вместо немедленной пересылки.
NOCP: Используется в сценариях буферизации для уведомления управляющей плоскости при поступлении нисходящих данных, которые требуется буферизовать.
DUPL: Создать отдельную копию пакета и обработать её согласно Duplicating Parameters.
Зачем нужны BUFF и NOCP?
Типичный случай возникает, когда UE находится в состоянии idle и немедленный нисходящий путь пользовательской плоскости недоступен. Нисходящий трафик уже может поступить в UPF, но пока не может быть доставлен UE. UPF может буферизовать пакет и при необходимости использовать связанный механизм уведомления управляющей плоскости, чтобы инициировать последующие процедуры, например paging или восстановление пути пользовательской плоскости.
BUFF только указывает, что буферизация необходима. Детали её выполнения связаны с BAR, поэтому при диагностике нельзя опираться только на флаг BUFF.
Почему DUPL — это не просто «ещё раз переслать пакет»?
DUPL создаёт отдельную копию пакета. Исходный пакет продолжает идти по обычному пути обработки, а дублированная копия независимо управляется через Duplicating Parameters. Для копии могут использоваться другой Destination Interface, другая конфигурация внешнего заголовка, Transport Level Marking или Forwarding Policy.
Поэтому нельзя автоматически считать, что зеркальный или дублированный трафик проходит тем же путём, что и исходный сервисный трафик. Параметры дублирования необходимо проверять отдельно.
Как Forwarding Parameters определяют фактическое направление пакета?
Если Apply Action содержит FORW, именно Forwarding Parameters определяют реальный путь пересылки. При диагностике проблем пользовательской плоскости особенно важны несколько полей.
Destination Interface
Destination Interface определяет логический интерфейс, в сторону которого UPF должна отправить пакет после обработки. В типичном нисходящем сценарии он устанавливается в Access, что означает пересылку пакета к gNB. Восходящий трафик обычно направляется в сторону Core.
Неверный Destination Interface может вызвать труднообнаружимую неисправность: PDR совпадает корректно, но пакет отправляется в неправильный логический интерфейс, а управляющая плоскость может не показывать явной ошибки.
Network Instance
Network Instance определяет логический сетевой контекст, используемый для пересылки. Он особенно важен в системах с несколькими DNN, слайсами или сетями данных, где трафик должен оставаться разделённым.
При диагностике связности N6 или услуг частной сети недостаточно проверить физическую достижимость. Network Instance в FAR также должна соответствовать конфигурации UPF. Несоответствие может помешать маршрутизации трафика в ожидаемый сетевой контекст.
Outer Header Creation
Outer Header Creation — один из ключевых параметров нисходящей пересылки по N3. Пакет, поступающий в UPF с N6, содержит исходную полезную нагрузку UE. Перед отправкой к gNB по N3 UPF должна добавить требуемую внешнюю инкапсуляцию GTP-U/UDP/IP.
Outer Header Creation предоставляет необходимые для этого сведения, включая адрес пользовательской плоскости gNB, TEID туннеля N3 и тип внешнего заголовка.
Во многих случаях, когда нисходящий трафик достигает UPF, но соответствующий пакет не появляется на N3, причиной оказывается отсутствующая или неверная информация в этой части FAR, например неправильный TEID или адрес gNB.
Другие Forwarding Parameters
Forwarding Parameters также могут включать Redirect Information, Transport Level Marking, Forwarding Policy, Header Enrichment, Linked Traffic Endpoint ID, Proxying, Destination Interface Type и другие необязательные сведения.
Transport Level Marking можно использовать для применения требуемой DSCP-маркировки к пересылаемым пакетам. Forwarding Policy может ссылаться на политику пересылки, настроенную локально в UPF. Header Enrichment поддерживает дополнительную обработку заголовков в соответствующих сервисах. Не каждая FAR содержит все эти Information Elements; фактическое содержимое зависит от сигнализации PFCP и требований сервиса.
Почему нисходящая FAR может обновляться после установления сессии?
Во время первоначальной процедуры PDU Session Establishment SMF может создать первые PDR и FAR в UPF. Однако в этот момент gNB ещё может не завершить выделение ресурсов нисходящей пользовательской плоскости N3. Поэтому окончательный TEID туннеля и адрес пользовательской плоскости gNB могут быть ещё недоступны SMF.
После того как gNB выделит эти ресурсы и соответствующая информация пользовательской плоскости N3 станет доступна SMF, SMF может отправить PFCP Session Modification , чтобы обновить существующую FAR в UPF необходимыми параметрами нисходящего туннеля.
Обновлённая нисходящая FAR может включать следующую ключевую информацию пересылки:
Destination Interface = Access, что означает пересылку в сторону доступа;
применимую Network Instance;
Outer Header Creation = GTP-U/UDP/IPv4 или другой подходящий тип внешнего заголовка;
IP-адрес пользовательской плоскости N3 gNB и выделенный TEID туннеля.
Поэтому при диагностике нельзя останавливаться на изучении только PFCP Session Establishment Request. Первоначальная FAR может содержать лишь базовое действие пересылки, а сведения, необходимые для построения реального нисходящего туннеля N3, могут быть добавлены позже через PFCP Session Modification.
Если проигнорировать это последующее обновление, нормальный поэтапный процесс установки правил легко принять за отсутствующую или неполную конфигурацию FAR.
Как FAR отправляет нисходящий трафик обратно в туннель N3?
Прослеживание полного пути нисходящего пакета помогает лучше понять роль FAR.
Пакет от внешнего сервера поступает в UPF через N6. UPF использует PDR, чтобы идентифицировать трафик и связать его с правильной PDU Session, после чего считывает FAR, на которую ссылается эта PDR.
Если Apply Action содержит FORW, UPF анализирует Forwarding Parameters. Destination Interface, установленный в Access, означает, что пакет нужно отправить в сторону радиодоступа. Outer Header Creation содержит адрес туннеля gNB и TEID, необходимые для формирования внешнего заголовка GTP-U. Затем UPF инкапсулирует исходный пакет и отправляет его к gNB по N3.
Полный путь можно представить так:
Нисходящий пакет поступает по N6 → PDR определяет трафик UE → FAR применяет FORW → UPF получает параметры туннеля N3 gNB → UPF создаёт внешний заголовок GTP-U → пакет отправляется к gNB по N3.
Это также поясняет различие между FAR и GTP-U. GTP-U — туннельный протокол, переносящий пользовательские данные, а FAR — правило принятия решения в UPF, которое определяет нужно ли создавать внешний туннельный заголовок, какие сведения о туннеле использовать и какой логический интерфейс должен получить пакет.
Следовательно, неправильный TEID в захвате N3 — лишь видимый симптом. Диагностика должна продолжаться в сторону управляющей плоскости: правильную ли информацию пользовательской плоскости выделил gNB? Корректно ли её получила SMF? Была ли она затем записана в соответствующую FAR посредством обновления N4?
Как использовать FAR для диагностики PDU Session, которая установлена, но не имеет передачи данных?
Если регистрация UE нормальна и PDU Session установлена, но сервис всё ещё не работает, диагностику можно вести по фактической последовательности обработки пакетов в UPF, а не повторять всю процедуру регистрации с самого начала.
Практическая последовательность проверки FAR выглядит так:
Убедиться, что пакет достигает UPF. Если на N3 или N6 пакет не поступает, проблема находится выше по пути до FAR, и сначала нужно проверить UE, gNB или транспортный тракт.
Убедиться, что PDR совпадает с пакетом. FAR не получает трафик для обработки, если пакет сначала не идентифицирован связанной PDR.
Проверить FAR ID, на который ссылается PDR. Убедиться, что правильно распознанный пакет не связан с неправильным правилом пересылки.
Проверить Apply Action. Определить, настроено ли поведение FORW, DROP, BUFF или комбинация применимых флагов.
Проверить Destination Interface и Network Instance. Убедиться, что пакет отправляется в правильном логическом направлении и сетевом контексте.
Проверить Outer Header Creation. Для нисходящего трафика N3 проверить адрес gNB, TEID и тип внешнего заголовка.
Просмотреть сообщения PFCP Session Modification. Не ограничиваться первоначальным Create FAR. Убедиться, что информация о туннеле gNB впоследствии была обновлена в UPF.
Сопоставить захваты пакетов N3 и N6. Сравнить поведение, ожидаемое по правилам PFCP, с пакетами, фактически переданными UPF.
Главное преимущество этого подхода в том, что правила управляющей плоскости и захваты пользовательской плоскости могут взаимно подтверждать друг друга. Сигнализация PFCP показывает, как UPF должна переслать пакет, а захваты N3 и N6 показывают, что UPF фактически сделала.
Если эти два представления расходятся, область неисправности обычно можно сузить до трёх вариантов: неправильное предоставление правил N4, неправильное выполнение правил в UPF или проблема в транспортном пути пользовательской плоскости. Это намного эффективнее, чем без чёткого направления проверять всё ядро 5G.
FAQ
В чём основное различие между FAR и PDR?
PDR выполняет обнаружение и классификацию пакетов, отвечая, например, к какой сессии и потоку трафика относится пакет. FAR определяет, что произойдёт после совпадения, включая способ обработки пакета и направление его пересылки. PDR ссылается на соответствующую FAR через FAR ID.
Почему пересылка может не работать, даже если Apply Action содержит FORW?
FORW только указывает, что должна выполняться пересылка. Её успешность по-прежнему зависит от связанных Forwarding Parameters. Если Destination Interface, Network Instance или данные Outer Header Creation заданы неверно, пакет может не достигнуть ожидаемого назначения. Типичный пример — неправильный TEID N3 или адрес пользовательской плоскости gNB.
Почему в первой FAR при PFCP Session Establishment иногда отсутствует полная информация о туннеле N3?
Установление PDU Session — многоэтапная процедура. При создании первоначальной PFCP-сессии gNB может ещё не выделить окончательные ресурсы нисходящей пользовательской плоскости N3. После появления адреса туннеля gNB и TEID SMF может обновить FAR через PFCP Session Modification. Поэтому при диагностике необходимо анализировать не только первоначальное сообщение установления, но и последующие обмены N4.
Как связаны Outer Header Creation и PDR Outer Header Removal?
Они применяются к противоположным направлениям туннельной обработки. Для восходящего трафика, поступающего с N3, Outer Header Removal удаляет соответствующий внешний заголовок GTP-U. Для нисходящего трафика, выходящего из UPF к N3, Outer Header Creation в FAR предоставляет информацию для формирования нового внешнего заголовка GTP-U. Вместе они обеспечивают оба направления инкапсуляции и декапсуляции туннеля пользовательской плоскости.
Если TEID на N3 неверен, нужно ли сосредоточить диагностику только на GTP-U?
Нет. Захват пакетов N3 показывает только то, что используемый TEID неправильный. Информация о туннеле формируется в gNB, обрабатывается SMF и затем через N4 устанавливается в FAR. Поэтому для поиска реальной причины необходимо проследить выделение ресурсов в gNB, информацию, полученную SMF, и обновление FAR в процедуре PFCP Session Modification.
