芯耀
168
去年底我們項目組接了一個5G專網(wǎng)部署的需求，對方是工業(yè)園區(qū)，提出希望能將部分終端數(shù)據(jù)“就近出園區(qū)”而不是走公網(wǎng)出口。說白了，就是要搞UPF本地分流（Local Breakout）。
這個需求在5G里很典型，尤其是to B場景。但說實話，真正落地的時候，我還是遇到了不少麻煩，現(xiàn)在回頭看，那次是我對UPF體系認識最完整、也最深刻的一次過程。
項目初期，按照規(guī)劃設計，我們架了兩個UPF：一個核心UPF（C-UPF）放在運營商核心機房，一個本地UPF（L-UPF）部署在園區(qū)邊緣云節(jié)點，走MEC鏈路出口。終端通過配置不同的S-NSSAI + DNN，理論上可以選路走不同UPF。配置文檔也準備好了，部署流程按部就班推進。
真正部署完，初步測試中發(fā)現(xiàn)，終端PDU session能成功建立，且AMF和SMF都能識別到LBO路徑。但問題來了——終端能拿到地址，但完全ping不通園區(qū)內的服務器。
一開始我們懷疑是邊緣UPF路由沒打通，查路由表發(fā)現(xiàn)設備間互通沒問題，MEC出口也通。后來我們切到UPF節(jié)點抓包，終于看到流量是進來了，但沒有出UPF接口，卡在了轉發(fā)層。
這個時候就有點懵了。抓了SMF日志，發(fā)現(xiàn)“UE下發(fā)的PDR和FAR”都正常配置，但UPF實際上并沒有執(zhí)行轉發(fā)。最后還是請了廠家工程師來一起現(xiàn)場分析，他們一眼就看出問題：我們少了一條“本地路由策略匹配規(guī)則”，導致數(shù)據(jù)包命中了默認drop行為。
這個問題在文檔里確實一筆帶過，但在實際部署里非常關鍵。我們在UPF配置里補上靜態(tài)策略，指定S-NSSAI + DNN組合對應的本地出口，重新加載配置后問題解決，終端終于能訪問園區(qū)MEC業(yè)務了。
這個事情讓我意識到一個以前沒有重視的問題：UPF是“看似被SMF管控，實則有自己本地控制邏輯”的設備。它對PDR、FAR的解析執(zhí)行必須依賴實際策略模塊的匹配，尤其是分流場景下，不是“SMF下發(fā)了就一定能通”。
還有一個小插曲，就是在部署過程中，我們用來測試的工業(yè)模組支持Network Slicing，但默認只支持公網(wǎng)DNN，無法自動觸發(fā)本地DNN切片。我們以為是切片配置不對，結果是終端模組APN寫死，得手動進參數(shù)頁添加新的APN profile。
這也是我做5G項目以來第二次被終端限制搞得焦頭爛額，第一次是在VoNR測試時發(fā)現(xiàn)有的手機根本連不上gNB，只因為廠商沒開放SA能力。
后來整個項目穩(wěn)定后，園區(qū)提出希望根據(jù)不同的設備類型，走不同的UPF：比如攝像頭走核心UPF，工業(yè)控制走邊緣UPF。于是我們又加了一套基于IMSI前綴+UE IP范圍+S-NSSAI匹配的智能策略。這個過程更復雜一些，但也更靈活。
現(xiàn)在再回看整個部署過程，我最大的感觸就是：
1.UPF并不是一個被動轉發(fā)設備，它的控制邏輯非常重要，尤其是在分流/分片場景下，必須與SMF策略保持一致。
2.終端模組的支持能力必須提前驗證，不要等配置好了才發(fā)現(xiàn)“跑不起來”，這是部署項目最容易掉坑的地方。
3.園區(qū)類項目一定要有一個完整的流量鏈路視圖，從終端到UPF再到MEC應用服務器，哪一步沒通就得精確定位。
這次經歷對我?guī)椭艽?，讓我對UPF結構、F-TEID、GTP-U封裝流程、路由策略等方面理解更深，也算是5G核心網(wǎng)體系下的一次“系統(tǒng)性學習”。
現(xiàn)在我們已經把這個方案推廣到另一個工業(yè)園區(qū)，復用起來就輕松很多了。
如果你也在做5G LBO部署，或者正在啃UPF這塊的技術細節(jié)，建議你一定要親手部署至少一套完整路徑，從AMF-SMF-UPF到終端業(yè)務服務，全部打通一遍，否則很多問題紙上永遠看不到。
這就是我關于5G核心網(wǎng)UPF分流部署的實戰(zhàn)記錄，希望對同行朋友有一點借鑒價值。
如你也在做類似項目，歡迎交流討論。寫完這篇，我打算下一篇寫寫我們做VoNR部署時踩的切換坑，有興趣的朋友可以留言。
如你需要，我可以繼續(xù)以同樣風格撰寫更多適合【5G系統(tǒng)與核心網(wǎng)】板塊的實戰(zhàn)記錄，包括：
-N2/N3接口故障引發(fā)的核心網(wǎng)擁塞
-一次SMF故障導致大面積PDU掉線的恢復過程
-VoNR注冊不上的多源原因排查實錄
