Когда UE переходит в CM-IDLE через доступ 3GPP, установленный сеанс PDU может сохраняться, хотя его соединение пользовательской плоскости деактивировано. Нисходящие пакеты по-прежнему могут поступать в UPF из сети данных через N6, даже если туннель N3 со стороны доступа, необходимый для немедленной доставки, недоступен. Буферизация позволяет сохранить часть трафика, пока плоскость управления пытается восстановить доставку.
На N4 функция SMF управляет UPF через PFCP. Правило действий буферизации (BAR) задаёт инструкции для связанных правил действий пересылки (FAR). Это важное различие: FAR выбирает буферизацию через Apply Action; BAR самостоятельно не сопоставляет пакеты и не запускает пейджинг. Состояние CM-IDLE также не гарантирует буферизацию каждого пакета или запуск пейджинга по каждому уведомлению.
PDR, FAR и BAR выполняют разные задачи
Правило обнаружения пакетов (PDR) определяет нужный трафик и ссылается на FAR. FORW запрашивает пересылку с применимыми Forwarding Parameters. BUFF запрашивает буферизацию. NOCP запрашивает уведомление плоскости управления о первом буферизованном нисходящем пакете; это действие уведомления, а не параметр выделения памяти.
В обычном случае BUFF/NOCP в 5GC отчёт формируется для первого нисходящего пакета каждого потока QoS для данной FAR. Каждый последующий пакет того же потока QoS не требует отдельного отчёта. Пакеты другого потока QoS или связанные с другой FAR могут вызвать дополнительные отчёты. Продлённая буферизация может изменять такое поведение уведомлений.
FAR может ссылаться на BAR через BAR ID. Одна BAR может обслуживать несколько связанных FAR, в том числе общий буфер сеанса PFCP. В TS 29.244 V18.7.0 разрешено создавать не более одной BAR на сеанс PFCP. Само создание BAR не доказывает её использование нисходящим трафиком: проверьте связь PDR с FAR и BAR ID в FAR.
Базовые этапы классификации и пересылки рассмотрены в связанных руководствах по обнаружению пакетов PDR на N4 и пересылке FAR и параметрам туннеля.
Что происходит при поступлении нисходящих данных в CM-IDLE?
Рассмотрим зарегистрированное UE с установленным сеансом PDU. Пока соединение пользовательской плоскости активно, UPF пересылает нисходящие пакеты к gNB. После деактивации соединения SMF обновляет соответствующие правила N4 и сведения о туннеле доступа. Для буферизации в UPF затронутая FAR может запросить BUFF и NOCP вместо немедленной пересылки. Это решение управления сеансом, а не самостоятельная реакция BAR на изменение радиосостояния.
Нисходящие данные поступают в UPF. Подходящая PDR и связанная FAR определяют их обработку.
При указании буферизовать и уведомлять UPF сохраняет данные и отправляет PFCP Session Report Request с Downlink Data Report. Отчёт идентифицирует соответствующие PDR; SMF может определить поток QoS по контексту PDR или Downlink Data Service Information.
SMF подтверждает отчёт сообщением PFCP Session Report Response и при необходимости обращается к AMF через Namf_Communication_N1N2MessageTransfer. AMF может запустить пейджинг и процедуру Service Request для восстановления соединения пользовательской плоскости.
После установления туннеля со стороны доступа SMF обновляет UPF, передавая действие пересылки и правильные параметры туннеля. Затем буферизованные пакеты могут пересылаться согласно новым инструкциям.
В TS 23.502 обмен уровня stage 2 называется Data Notification и Data Notification Ack. В захвате N4 используйте фактические названия сообщений PFCP и Downlink Data Report. Обозначение всего обмена как «DDN» удобно, но не превращает его в сообщение EPC Downlink Data Notification на S11.
Эта последовательность описывает типичный случай буферизации в UPF. TS 23.502 также допускает пересылку данных в SMF для буферизации при соответствующем указании. UE может находиться в CM-CONNECTED, тогда как конкретный сеанс PDU не имеет активного соединения пользовательской плоскости; RRC_INACTIVE также отличается от CM-IDLE. Тип доступа, MICO, расширенный DRX в режиме ожидания, ограничения пейджинга и известная недоступность могут изменять или исключать пейджинг. Прежде чем применять объяснение для режима ожидания, проверьте фактическое состояние сеанса и доступа.
Поля BAR необходимо читать в контексте процедуры
Следующие различия основаны на TS 29.244 V18.7.0, разделах 5.2.4, 7.5.2.6, 7.5.4.11 и 7.5.9.2. BAR не является универсальным контейнером, в котором при каждом обмене N4 должны присутствовать все возможные настройки буфера.
| Поле | Значение и условия |
|---|---|
| BAR ID | Идентифицирует BAR в сеансе PFCP. Ссылка FAR выбирает инструкции буферизации, связанные с этой BAR. |
| Suggested Buffering Packets Count | Поле, зависящее от поддержки UDBC, задаёт предлагаемое число пакетов UL/DL для буферизации в ожидании новых инструкций плоскости управления. Оно не описывает физическую ёмкость памяти UPF. При его передаче приведённые таблицы Create/Update BAR требуют отбрасывать пакеты, превышающие предел. |
| DL Buffering Suggested Packet Count | Другое поле: предлагаемое максимальное число нисходящих пакетов для продлённой буферизации в сеансе PFCP. Его нельзя смешивать с Suggested Buffering Packets Count. |
| DL Buffering Duration | Управляет продлённой буферизацией нисходящих данных. Передача в PFCP Session Report Response зависит от поддержки DLBD; через PFCP Session Modification — от поддержки DBDM и применимых условий. При начальном установлении оно присутствует не обязательно. |
| Downlink Data Notification Delay | Откладывает уведомление после поступления пакета, когда это применимо. Раздел 5.2.4 описывает его предоставление для EPC; появление в общей схеме BAR или декодированном групповом IE не означает, что это универсальный регулятор задержки пейджинга в 5GC. |
DL Buffering Duration влияет и на отчёты, и на хранение. В течение указанного периода продлённой буферизации дальнейшие уведомления о поступлении нисходящих данных обычно подавляются. При поддержке Extended DL Buffering Notification Control (EDBNC) и значении EDBN, равном 1, UPF вместо этого сообщает о первом буферизованном пакете каждого потока QoS для данной FAR в течение этого периода. Поэтому само наличие NOCP не доказывает необходимость следующего отчёта.
После завершения продлённой буферизации UPF прекращает применять DL Buffering Duration и DL Buffering Suggested Packet Count и удаляет эти параметры из BAR. Новые инструкции плоскости управления определяют, пересылать или отбрасывать уже сохранённые пакеты. Буферизация — временная обработка трафика, а не гарантированное хранение без потерь.
Почему трассировка может не показывать все параметры буферизации
Начните с полной истории сеанса PFCP. BAR могла быть создана при установлении или предыдущей модификации, а рассматриваемый обмен обновляет только FAR. Необязательные и зависящие от возможностей поля также не должны присутствовать в каждом сообщении. Отсутствие необязательного поля отличается от неразрешённой ссылки или отсутствия поля, обязательного при определённых условиях.
TS 29.244 допускает необязательную передачу параметров буферизации вместе с BUFF. Однако для изменения BAR в PFCP Session Report Response она должна быть предварительно предоставлена, пусть даже пустая, и связана с FAR. Локальные ограничения ресурсов UPF не заменяют связь BAR ID или поле, обязательное по применимой процедуре.
В разделе 5.2.4.3 описан более узкий вариант реализации: если UPF поддерживает настроенную продлённую буферизацию для APN/DNN и/или S-NSSAI и выполняются остальные указанные условия, плоскость управления может сама вести таймер, не передавая его UPF, сохраняя NOCP включённым для уведомлений о дополнительных потоках QoS. Это не общее разрешение заменять любые параметры BAR локальной конфигурацией.
При диагностике получите согласованные UP Function Features, предыдущие параметры BAR, текущие связи правил и соответствующие локальные настройки ресурсов. Это позволит отличить нормальное отсутствие необязательного параметра от неподдерживаемой функции, неполного захвата или реальной ошибки предоставления правил.
Проверка действия, буферизации, уведомления и восстановления
Задержка первого сообщения после бездействия, успешный пейджинг с потерей начальных пакетов или рост буферов UPF могут иметь разные причины. Проследите пакет и его состояние в плоскости управления по четырём этапам.
1. Подтвердите действие и подходящее правило
Проверьте, что нисходящие пакеты действительно достигают ожидаемой UPF и соответствуют правильной PDR. Проследите её FAR ID, проверьте Apply Action и успешный результат PFCP Session Modification. Если FAR продолжает пересылку по устаревшим данным туннеля доступа, сначала исследуйте обновления правил и туннеля, а затем корректируйте буферизацию.
2. Определите действующие инструкции буферизации
Разрешите ссылку BAR ID и проверьте последний Create BAR или Update BAR в нужном контексте сообщения. Различайте два поля числа пакетов и проверяйте поддержку функций. Сопоставьте настроенные пределы с реально сохранёнными и отброшенными пакетами; предлагаемое число не резервирует физическую память и не гарантирует сохранность каждого пакета до переподключения.
3. Проверьте отчёт и его обработку
Найдите PFCP Session Report Request, Downlink Data Report, PDR ID и соответствующий ответ. Проверьте область отчётности по потокам QoS, подавление уведомлений, продлённую буферизацию и возможную причину отказа. Если отчёт принят, но пейджинг не следует, исследуйте обмен SMF-AMF и условия доступности UE, прежде чем считать BAR неисправной.
4. Проверьте доставку после восстановления
После успешного Service Request убедитесь, что SMF восстанавливает FORW и текущие адрес и TEID со стороны доступа. Сравните входящие пакеты N6, выход N3 и счётчики буфера. Даже доступное UE может не получить данные, если FAR остаётся в BUFF, сведения о туннеле неверны, срок буферизации истёк или пакеты уже отброшены.
Частые вопросы
Требуется ли BUFF правило BAR для классификации пакетов?
Нет. PDR классифицирует трафик, а FAR запрашивает BUFF. BAR задаёт конкретные инструкции буферизации после предоставления и связывания; это не дополнительный классификатор пакетов.
Доказывает ли отсутствие Suggested Buffering Packets Count ошибку настройки?
Нет. Это поле зависит от поддержки UDBC и отличается от поля числа пакетов для продлённой нисходящей буферизации. Перед оценкой отсутствия проверьте контекст сообщения, согласованные функции и существующее состояние BAR.
Каждый ли Downlink Data Report вызывает пейджинг?
Нет. SMF и AMF применяют условия доступности, доступа и политики. Отчёт может привести к реактивации пользовательской плоскости, продлённой буферизации или обработке отказа; пейджинг — лишь возможная часть процедуры.
Почему пакеты могут теряться даже после успешного переподключения?
Буфер мог достичь предела или его срок мог истечь до восстановления. Также обновление FAR или туннеля может быть неполным. Успешное переподключение само по себе не подтверждает состав сохранённых пакетов или возобновление пересылки N3.
Источники
3GPP TS 29.244 V18.7.0: разделы 5.2.3–5.2.4, 7.5.2.6, 7.5.4.11, 7.5.8–7.5.9 и 8.2.28–8.2.30, 8.2.100 описывают обработку FAR/BAR, отчётность и информационные элементы буферизации.
3GPP TS 23.502 V18.9.0: раздел 4.2.3.3 описывает Network Triggered Service Request, уведомления о данных, исключения по доступности и продлённую буферизацию.
