當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、資料通知、可達性例外及擴展緩衝。
