当UE在3GPP接入下进入CM-IDLE时，已经建立的PDU Session可以继续存在，而其用户面连接被去激活。即使无法使用即时交付所需的接入侧N3隧道，下行包仍可能从数据网络经N6到达UPF。在控制面尝试恢复交付期间，缓存可以暂时保留部分流量。
在N4接口上，SMF通过PFCP控制UPF。缓存动作规则（BAR）为关联的转发动作规则（FAR）提供缓存指令。必须区分两者：FAR通过Apply Action选择缓存；BAR不会独立匹配数据包或发起寻呼。CM-IDLE也不保证每个包都被缓存，或每次通知都会引发寻呼。
PDR、FAR和BAR承担不同职责
包检测规则（PDR）识别适用流量并引用FAR。FORW请求按适用的Forwarding Parameters转发，BUFF请求缓存。NOCP请求将首个被缓存的下行包通知控制面；它是通知动作，不是内存分配参数。
对于通常的5GC BUFF/NOCP情况，报告范围是某个FAR下每条QoS流的首个下行包。同一QoS流的后续包不需要逐包再次报告。属于另一条QoS流或关联到另一条FAR的包，可能产生额外报告。扩展缓存可以改变这种通知行为。
FAR可以通过BAR ID引用BAR。一条BAR可以服务于多条关联FAR，包括为PFCP Session共用一个缓存。在TS 29.244 V18.7.0中，每个PFCP Session最多可以创建一条BAR。仅看到创建BAR并不能证明下行流量使用了它：需要检查PDR到FAR的关系以及FAR的BAR ID。
有关基础分类与转发阶段，可参阅相关指南：N4接口上的PDR包检测以及FAR转发与隧道参数。
CM-IDLE期间下行数据到达后会发生什么？
以已注册且建立PDU Session的UE为例。用户面连接处于激活状态时，UPF将下行包转发至gNB。连接去激活后，SMF更新相应的N4规则和接入隧道信息。采用UPF缓存时，相关FAR可以请求BUFF和NOCP，而非立即转发。这是会话控制决策，不是BAR对无线状态变化作出的自主反应。
下行数据到达UPF。匹配的PDR及其关联FAR决定如何处理数据。
如果收到缓存并通知的指令，UPF缓存数据，并发送包含Downlink Data Report的PFCP Session Report Request。报告标识相关PDR；SMF可通过PDR上下文或Downlink Data Service Information确定QoS流。
SMF使用PFCP Session Report Response确认报告，并在适用时通过Namf_Communication_N1N2MessageTransfer联系AMF。AMF可以发起寻呼及Service Request流程，以恢复用户面连接。
接入侧隧道建立后，SMF向UPF更新转发动作和正确的隧道参数。随后，缓存包便可按照新指令转发。
TS 23.502将第2阶段的交互称为Data Notification和Data Notification Ack。在N4抓包中，应使用实际的PFCP消息名称和Downlink Data Report名称。将整段交互简称为“DDN”便于交流，但并不意味着它就是S11上的EPC Downlink Data Notification消息。
该顺序描述了常见的UPF缓存情况。TS 23.502也允许按指令将数据转发到SMF进行缓存。UE可能处于CM-CONNECTED，但某个PDU Session没有激活的用户面连接；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 | 标识PFCP Session内的BAR。FAR引用选择与该BAR关联的缓存指令。 |
| Suggested Buffering Packets Count | 依赖UDBC支持的字段，建议在等待控制面新指令期间缓存多少UL/DL包。它不代表UPF的物理内存容量。提供该字段时，所引用的Create/Update BAR表要求丢弃超过上限的包。 |
| DL Buffering Suggested Packet Count | 这是另一字段，表示建议在PFCP Session扩展缓存期间保留的最大下行包数量。不得与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则会在该期间报告某个FAR下每条QoS流的首个缓存包。因此，仅有NOCP不能证明此时应再次报告。
扩展缓存结束后，UPF停止应用DL Buffering Duration和DL Buffering Suggested Packet Count，并从BAR中删除这些参数。新的控制面指令决定已缓存包是被转发还是被丢弃。缓存是临时流量处理机制，不是保证无损的数据存储。
为什么信令中可能看不到全部缓存参数
应从完整的PFCP Session历史记录开始检查。BAR可能在会话建立或较早的修改中已创建，而当前分析的交互只更新FAR。可选字段以及依赖能力支持的字段，也不需要出现在每条消息中。缺少可选字段，与引用无法解析或缺少条件必选字段，是不同的问题。
TS 29.244允许在BUFF下选择性下发缓存参数。但是，要在PFCP Session Report Response中修改BAR，必须事先下发BAR并将其关联到FAR，即使BAR为空也如此。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、数据通知、可达性例外及扩展缓存。
