芯耀
2848
去年底我们项目组接了一个5G专网部署的需求，对方是工业园区，提出希望能将部分终端数据“就近出园区”而不是走公网出口。说白了，就是要搞UPF本地分流（Local Breakout）。
这个需求在5G里很典型，尤其是to B场景。但说实话，真正落地的时候，我还是遇到了不少麻烦，现在回头看，那次是我对UPF体系认识最完整、也最深刻的一次过程。
项目初期，按照规划设计，我们架了两个UPF：一个核心UPF（C-UPF）放在运营商核心机房，一个本地UPF（L-UPF）部署在园区边缘云节点，走MEC链路出口。终端通过配置不同的S-NSSAI + DNN，理论上可以选路走不同UPF。配置文档也准备好了，部署流程按部就班推进。
真正部署完，初步测试中发现，终端PDU session能成功建立，且AMF和SMF都能识别到LBO路径。但问题来了——终端能拿到地址，但完全ping不通园区内的服务器。
一开始我们怀疑是边缘UPF路由没打通，查路由表发现设备间互通没问题，MEC出口也通。后来我们切到UPF节点抓包，终于看到流量是进来了，但没有出UPF接口，卡在了转发层。
这个时候就有点懵了。抓了SMF日志，发现“UE下发的PDR和FAR”都正常配置，但UPF实际上并没有执行转发。最后还是请了厂家工程师来一起现场分析，他们一眼就看出问题：我们少了一条“本地路由策略匹配规则”，导致数据包命中了默认drop行为。
这个问题在文档里确实一笔带过，但在实际部署里非常关键。我们在UPF配置里补上静态策略，指定S-NSSAI + DNN组合对应的本地出口，重新加载配置后问题解决，终端终于能访问园区MEC业务了。
这个事情让我意识到一个以前没有重视的问题：UPF是“看似被SMF管控，实则有自己本地控制逻辑”的设备。它对PDR、FAR的解析执行必须依赖实际策略模块的匹配，尤其是分流场景下，不是“SMF下发了就一定能通”。
还有一个小插曲，就是在部署过程中，我们用来测试的工业模组支持Network Slicing，但默认只支持公网DNN，无法自动触发本地DNN切片。我们以为是切片配置不对，结果是终端模组APN写死，得手动进参数页添加新的APN profile。
这也是我做5G项目以来第二次被终端限制搞得焦头烂额，第一次是在VoNR测试时发现有的手机根本连不上gNB，只因为厂商没开放SA能力。
后来整个项目稳定后，园区提出希望根据不同的设备类型，走不同的UPF：比如摄像头走核心UPF，工业控制走边缘UPF。于是我们又加了一套基于IMSI前缀+UE IP范围+S-NSSAI匹配的智能策略。这个过程更复杂一些，但也更灵活。
现在再回看整个部署过程，我最大的感触就是：
1.UPF并不是一个被动转发设备，它的控制逻辑非常重要，尤其是在分流/分片场景下，必须与SMF策略保持一致。
2.终端模组的支持能力必须提前验证，不要等配置好了才发现“跑不起来”，这是部署项目最容易掉坑的地方。
3.园区类项目一定要有一个完整的流量链路视图，从终端到UPF再到MEC应用服务器，哪一步没通就得精确定位。
这次经历对我帮助很大，让我对UPF结构、F-TEID、GTP-U封装流程、路由策略等方面理解更深，也算是5G核心网体系下的一次“系统性学习”。
现在我们已经把这个方案推广到另一个工业园区，复用起来就轻松很多了。
如果你也在做5G LBO部署，或者正在啃UPF这块的技术细节，建议你一定要亲手部署至少一套完整路径，从AMF-SMF-UPF到终端业务服务，全部打通一遍，否则很多问题纸上永远看不到。
这就是我关于5G核心网UPF分流部署的实战记录，希望对同行朋友有一点借鉴价值。
如你也在做类似项目，欢迎交流讨论。写完这篇，我打算下一篇写写我们做VoNR部署时踩的切换坑，有兴趣的朋友可以留言。
如你需要，我可以继续以同样风格撰写更多适合【5G系统与核心网】板块的实战记录，包括：
-N2/N3接口故障引发的核心网拥塞
-一次SMF故障导致大面积PDU掉线的恢复过程
-VoNR注册不上的多源原因排查实录
