Технические вопросы и ответы: Как BAR на интерфейсе N4 управляет буферизацией нисходящих пакетов и уведомлением о данных, когда UE находится в режиме CM-IDLE?
Когда UE переходит в режим CM-IDLE, его PDU-сессия не исчезает. Однако путь пользовательской плоскости N3, ранее использовавшийся для пересылки нисходящего трафика, может больше не быть активным. Если в этот момент из внешней сети поступают новые данные, пакеты все еще могут достигать UPF, но их нельзя немедленно переслать в gNB через N3, как это было бы в режиме CM-CONNECTED. Поэтому UPF должен определить, следует ли буферизовать пакеты, сколько пакетов можно сохранить, как долго они могут оставаться в буфере и когда необходимо уведомить плоскость управления о поступлении нисходящих данных.
В рамках правил PFCP на интерфейсе N4 BAR (Buffering Action Rule) предоставляет правила для такого поведения буферизации. Однако BAR не решает самостоятельно, должна ли происходить буферизация. Действие буферизации запускается Apply Action в FAR, а BAR определяет, как эта буферизация должна выполняться. Это различие принципиально важно для понимания взаимосвязи между FAR и BAR.
BAR определяет, как UPF буферизует пакеты
Когда UPF получает пакет, он сначала использует PDR для идентификации трафика, а затем следует FAR, на которую ссылается эта PDR, чтобы определить следующее действие. Если FAR требует обычной пересылки, UPF пересылает пакет в соответствии с параметрами пересылки. Если Apply Action в FAR содержит BUFF, пакет не отправляется немедленно в направлении интерфейса назначения, а вместо этого попадает в процесс буферизации.
Именно здесь становится важной BAR. FAR может ссылаться на BAR, которая указывает UPF, как следует буферизовать затронутые пакеты. Эту связь можно резюмировать так:
PDR идентифицирует пакет → FAR выбирает BUFF/NOCP → BAR определяет поведение буферизации.
Распространенное заблуждение — рассматривать BUFF и BAR как одно и то же. Это не так. BUFF отвечает на вопрос: «Должен ли этот пакет быть буферизован сейчас?» BAR отвечает на вопрос: «После того как выбрана буферизация, при каких условиях пакет должен быть буферизован?» Если смотреть только на BUFF в FAR, не проверяя связанную BAR или локальную конфигурацию буферизации UPF, мы получим лишь часть картины поведения пользовательской плоскости.
NOCP также обычно ассоциируется с этим сценарием. Когда UPF буферизует нисходящие пакеты, NOCP может потребовать, чтобы UPF уведомил плоскость управления о поступлении нисходящих данных, чтобы SMF мог инициировать следующие процедуры плоскости управления. Таким образом, буферизация и уведомление происходят как две скоординированные задачи: пользовательская плоскость временно удерживает пакеты, в то время как событие сообщается плоскости управления.
Наиболее типичный сценарий BAR возникает после перехода UE в режим CM-IDLE
Роль BAR легче всего понять, когда UE переходит из CM-CONNECTED в CM-IDLE. Предположим, что UE уже завершил регистрацию и установление PDU-сессии. Пока он подключен, путь пользовательской плоскости N3 доступен, и UPF может пересылать нисходящие пакеты напрямую в gNB.
После периода неактивности сторона доступа может освободить соединение, и UE переходит в режим CM-IDLE. PDU-сессия остается, но ранее активный путь пересылки пользовательской плоскости N3 больше не доступен немедленно. Внешние серверы не обязательно осведомлены об этом изменении состояния, поэтому новые нисходящие IP-пакеты все еще могут поступать в UPF через N6.
Это создает ключевую проблему: UPF получил данные, но в настоящее время у него нет пригодного для использования пути N3, по которому можно было бы доставить их в UE.
На этом этапе SMF обновляет правила пользовательской плоскости через N4, чтобы соответствующая FAR переключилась с немедленной пересылки на поведение буферизации. В типичном случае BUFF и NOCP включаются в Apply Action, а FORW больше не используется как текущее действие нисходящего трафика. Когда поступают новые нисходящие пакеты, UPF удерживает их в соответствии с применимой политикой буферизации и сообщает о поступлении нисходящих данных в SMF.
После получения уведомления SMF может координировать действия с AMF для запуска процедур, необходимых для того, чтобы UE снова стал достижимым, включая пейджинг, где это применимо. Как только UE возвращается в состояние, в котором может передаваться трафик пользовательской плоскости и восстанавливается путь N3, SMF снова обновляет правила UPF, чтобы обработка нисходящего трафика изменилась с буферизации на пересылку. Буферизованные пакеты затем могут продолжить движение к UE.
Таким образом, BAR — это не просто статическое правило выделения памяти. Ее истинное назначение — помочь пользовательской плоскости преодолеть временной период, в течение которого нисходящие пакеты уже поступили, но немедленная пересылка еще невозможна.
Ключевые параметры BAR определяют границы буферизации
Буферизация не может продолжаться бесконечно. Если бы UPF было разрешено удерживать неограниченный объем нисходящих данных для недостижимого UE, память пользовательской плоскости могла бы расходоваться без необходимости. Поэтому BAR задает границы поведения буферизации. В зависимости от процедуры PFCP и возможностей UPF они могут включать идентификатор BAR, лимиты количества пакетов, длительность буферизации и параметры задержки уведомления.
Идентификатор BAR (BAR ID)
Идентификатор BAR уникально идентифицирует правило буферизации в рамках PFCP-сессии и позволяет соответствующей FAR ссылаться на правильную BAR. При устранении неполадок само по себе наличие Create BAR не доказывает, что правило влияет на анализируемый трафик. Следует также проверить соответствующую FAR, чтобы подтвердить, на какой идентификатор BAR она фактически ссылается.
Предлагаемое количество пакетов для буферизации (Suggested Buffering Packets Count)
Предлагаемое количество пакетов для буферизации указывает, сколько пакетов рекомендуется буферизовать UPF для соответствующего трафика. После превышения предложенного лимита дополнительные пакеты могут быть отброшены. Этот параметр контролирует границу емкости буферизации, а не время буферизации.
Его наличие также зависит от поддержки функций UPF. Если поле не отображается в трассировке PFCP, это само по себе не доказывает отсутствие контроля буферизации. При анализе также следует учитывать, поддерживает ли UPF соответствующую возможность и используются ли вместо этого локальные параметры буферизации.
Длительность буферизации нисходящих данных (DL Buffering Duration)
Длительность буферизации нисходящих данных определяет период, в течение которого нисходящие пакеты могут продолжать находиться в буфере UPF в рамках применяемой процедуры. Это отражает важный принцип проектирования: буферизация задумана как временный механизм на время восстановления доставки пользовательской плоскости, а не как постоянное хранилище пакетов.
Если UE остается недостижимым в течение длительного периода, процесс буферизации нуждается в определенном условии завершения; в противном случае ресурсы пользовательской плоскости могут оставаться занятыми бесконечно.
Задержка уведомления о нисходящих данных (Downlink Data Notification Delay)
В поддерживаемых процедурах и комбинациях возможностей задержка уведомления о нисходящих данных может управлять тем, как долго UPF ждет после получения первого нисходящего пакета, прежде чем уведомить плоскость управления. Этот параметр влияет на когда отправляется уведомление, а не на то, должен ли пакет быть буферизован.
Поэтому его поведение следует интерпретировать в контексте конкретной процедуры PFCP, реализации сети и возможностей UPF, а не выводить только из названия параметра.
Почему полные параметры BAR иногда отсутствуют в трассировках PFCP?
Это один из самых легких моментов для неправильной интерпретации при анализе BAR. Количество пакетов для буферизации, длительность буферизации и другие параметры буферизации не всегда должны динамически предоставляться через N4. Операторы или поставщики оборудования также могут настраивать политики буферизации локально в UPF.
При такой реализации SMF может потребоваться только динамически изменить действие FAR. Например, после перехода UE в режим CM-IDLE SMF может использовать модификацию PFCP-сессии, чтобы обновить соответствующую FAR до BUFF/NOCP. Как только UPF увидит действие буферизации, он сможет применить локально настроенные ограничения на количество пакетов и длительность.
Поэтому следующее наблюдение в трассировке не является автоматически ненормальным:
FAR запрашивает BUFF, но сообщения PFCP не содержат полных параметров BAR, ожидаемых инженером.
Следует проверить как минимум два дополнительных вопроса: использует ли UPF локально настроенные значения буферизации, и поддерживает ли UPF динамическое предоставление соответствующих параметров BAR. В противном случае различие в реализации можно ошибочно принять за отсутствующее правило от SMF.
Локальная конфигурация также может иметь практические преимущества. Она может уменьшить часть сигнализации N4 и учитывать различия в возможностях между реализациями UPF. Компромисс заключается в том, что часть поведения буферизации больше не полностью видна в одной трассировке PFCP, поэтому устранение неполадок в мультивендорной среде может потребовать как анализа сигнализации, так и проверки локальной конфигурации UPF.
Как следует понимать поток PFCP при поступлении нисходящих данных в режиме CM-IDLE?
BAR легче понять, если вернуть ее в полную процедуру, а не анализировать как изолированный информационный элемент.
Пока UE находится в режиме CM-CONNECTED, путь N3 доступен, и UPF пересылает нисходящие пакеты в соответствии с обычной FAR. После периода неактивности соединение со стороны доступа освобождается. Как только SMF узнает, что состояние соединения пользовательской плоскости изменилось, он использует модификацию PFCP-сессии для обновления соответствующих правил UPF.
Важный момент: PDU-сессия не была удалена. Вместо этого текущий путь пользовательской плоскости нисходящего трафика временно недоступен для немедленной доставки. Поэтому соответствующая FAR может перейти в режим буферизации, включив BUFF и необходимое действие уведомления плоскости управления, в то время как BAR или локальная конфигурация UPF предоставляет детальные условия буферизации.
Когда интернет-сервер или приложение впоследствии отправляет новые нисходящие данные, пакеты сначала поступают в UPF. UPF использует PDR для идентификации трафика, затем применяет связанную FAR. Поскольку текущее действие больше не является FORW, пакеты буферизуются. Одновременно UPF сообщает о поступлении нисходящих данных в SMF через механизм отчетов PFCP.
Затем SMF координирует действия с процедурами на стороне AMF, чтобы UE снова стал достижимым и путь пользовательской плоскости можно было восстановить. Как только пересылка N3 снова становится доступной, FAR на N4 снова обновляется для обычной пересылки, и UPF может продолжить доставку нисходящего трафика в UE.
Общую логику можно резюмировать так:
UE переходит в CM-IDLE → N3 временно недоступен → SMF обновляет FAR/BAR → Нисходящие данные достигают UPF → UPF буферизует и сообщает → Плоскость управления восстанавливает достижимость UE → N3 восстанавливается → FAR возвращается к пересылке.
Таким образом, BAR управляет поведением пользовательской плоскости в период, когда данные уже поступили, но путь доставки еще не вернулся.
Устранение неполадок BAR должно следовать четырем шагам: действие, буферизация, уведомление и восстановление
Проблемы, связанные с BAR, редко проявляются как явная «ошибка BAR». Чаще симптом заключается в том, что первый нисходящий трафик после перехода UE в неактивное состояние ведет себя ненормально. Приложение может нормально работать в активном состоянии, но после периода бездействия следующее сообщение приходит с заметной задержкой. В другом случае UE может быть успешно пейджингован и переподключен, однако первые несколько нисходящих пакетов уже потеряны.
Эти проблемы можно анализировать в четыре этапа.
Шаг 1: Подтвердите, что FAR действительно перешла в режим буферизации
Начните с FAR, на которую ссылается соответствующая нисходящая PDR, и подтвердите, что ожидаемая модификация PFCP-сессии произошла после перехода UE в режим CM-IDLE. Проверьте, изменилось ли Apply Action с обычного поведения FORW на действия BUFF и уведомления, ожидаемые для этого сценария.
Если FAR по-прежнему пытается пересылать пакеты в направлении пути пользовательской плоскости, который больше не пригоден для использования, проблема в первую очередь не связана с BAR.
Шаг 2: Определите, какие правила буферизации применяет UPF
Проверьте идентификатор BAR, на который ссылается FAR, затем изучите соответствующие параметры Create BAR или Update BAR. Если трассировка PFCP не содержит полных параметров буферизации, продолжите проверку локальной конфигурации буферизации UPF и поддерживаемых возможностей.
Если лимит количества пакетов слишком мал, некоторые из первых нисходящих пакетов могут быть отброшены до того, как UE снова станет достижимым. Если наблюдаемое поведение буферизации существенно отличается от ожиданий, следует также проверить саму ассоциацию BAR.
Шаг 3: Подтвердите, что UPF сообщил о поступлении нисходящих данных
Сама по себе буферизация пакетов не восстанавливает связь с UE. Если плоскость управления не знает о поступлении новых нисходящих данных, последующая процедура пейджинга или восстановления пользовательской плоскости не будет инициирована. Поэтому в трассировке следует проверить наличие соответствующего отчета PFCP Session Report и корректную обработку со стороны SMF.
Если пакеты уже буферизованы в UPF, но за этим не следует никакая процедура плоскости управления, устранение неполадок должно перейти от параметров BAR к пути отчетности UPF-SMF и последующим процедурам SMF.
Шаг 4: Подтвердите, что пересылка возобновляется после восстановления пользовательской плоскости
После того как UE снова становится достижимым, убедитесь, что SMF корректно обновляет правила N4, чтобы нисходящая FAR переключилась с буферизации на обычную пересылку и были восстановлены требуемые параметры пересылки N3.
Если пейджинг успешен и UE вернулся, но FAR остается в режиме BUFF, система может войти в состояние, при котором UE достижим, а пакеты продолжают оставаться в UPF. Поэтому устранение неполадок BAR должно продолжаться до тех пор, пока путь пересылки пользовательской плоскости не будет полностью восстановлен.
Основная ценность BAR
В рамках правил PFCP BAR не участвует в каждом обычно пересылаемом пакете так же, как PDR и FAR. Ее важность становится наиболее заметной в конкретной, но критической ситуации: сессия все еще существует, но текущий путь пользовательской плоскости не может немедленно доставить вновь поступившие нисходящие данные.
FAR меняет действие обработки пакетов с FORW на BUFF, BAR определяет границы буферизации, UPF временно удерживает пакеты и сообщает об их поступлении, а функции плоскости управления, такие как SMF и AMF, координируют восстановление достижимости UE. Вместе эти механизмы преодолевают переход от временной недоступности доставки обратно к активному пути пользовательской плоскости.
Поэтому BAR не следует понимать только как «Buffering Action Rule = правило буферизации пакетов». Более полезная интерпретация: BAR указывает UPF, как управлять нисходящими пакетами, которые уже поступили, пока путь доставки пользовательской плоскости временно недоступен. Как только BAR рассматривается вместе с CM-IDLE, FAR BUFF/NOCP, отчетом PFCP Session Report и последующими процедурами пейджинга и восстановления пользовательской плоскости, ее роль на интерфейсе N4 становится гораздо яснее.
Часто задаваемые вопросы
В чем разница между BAR и BUFF в FAR?
BUFF — это Apply Action в FAR, указывающая, что совпадающие пакеты должны быть буферизованы вместо немедленной пересылки. BAR определяет, как эта буферизация должна выполняться, например, ограничения на количество пакетов, длительность буферизации или другие применимые условия. Проще говоря, FAR решает, что буферизация требуется, а BAR определяет, как выполняется буферизация.
Может ли BAR работать независимо от FAR?
BAR не следует рассматривать как независимое правило сопоставления пакетов. Пакет сначала сопоставляется с помощью PDR, которая ссылается на соответствующую FAR. Когда эта FAR требует буферизации и ссылается на применимую BAR, параметры BAR затем используются для управления тем, как эти пакеты буферизуются.
Почему нисходящие пакеты просто не отбрасываются, когда UE переходит в режим CM-IDLE?
Режим CM-IDLE не означает, что PDU-сессия была удалена. Внешние приложения могут продолжать отправлять данные, в то время как путь доставки пользовательской плоскости лишь временно недоступен. Кратковременная буферизация позволяет сохранить часть этого нисходящего трафика, пока плоскость управления восстанавливает достижимость UE, помогая уменьшить нарушение непрерывности работы приложений.
Означает ли отсутствие предлагаемого количества пакетов для буферизации, что BAR неправильно настроена?
Не обязательно. Появление этого параметра зависит от процедуры PFCP, возможностей UPF и реализации. Ограничения на количество пакетов и другое поведение буферизации могут также настраиваться локально в UPF, поэтому следует проверить поддержку возможностей, ассоциацию BAR и конфигурацию буферизации на стороне оборудования.
Почему UE по-прежнему не получает данные, хотя UPF буферизовал нисходящие пакеты?
Буферизация — лишь часть процедуры. UPF также должен сообщить о поступлении нисходящих данных в SMF, плоскость управления должна инициировать процедуры, необходимые для восстановления достижимости UE, а SMF должен обновить FAR и параметры пересылки N3, как только путь пользовательской плоскости снова станет доступен. Сбой на любом из этих этапов может привести к тому, что пакеты останутся в буфере или в конечном итоге будут отброшены.
