1. 项目概述：为什么“基于服务的网络架构”是5G核心网真正的分水岭
你可能已经听过太多次“5G比4G快十倍”“低时延”“海量连接”这类宣传语，但真正让5G从“更快的4G”蜕变为“新通信范式”的，不是空口速率的提升，而是背后那套彻底重构的核心网设计哲学——基于服务的网络架构（Service-Based Architecture，SBA）。这个词不是厂商PPT里的漂亮术语，它是运营商在现网升级中反复踩坑、推倒重来、最终不得不接受的底层事实。我参与过三个不同规模的5G核心网部署项目，从某高校实验室的小型验证环境，到某省级运营商的商用试点，再到某跨国企业的专网落地，每一次都绕不开SBA这个核心命题。它解决的不是“能不能连上”，而是“如何让网络像软件一样被灵活编排、按需调用、快速迭代”。传统4G核心网像一栋功能固定的办公楼：MME负责接入控制，SGW负责数据转发，PGW负责出口策略，各司其职，改一处牵全身；而SBA则像一个开放的App Store，每个网络功能（如AMF、SMF、UPF）都变成一个可独立开发、部署、升级、扩缩容的微服务，它们之间通过统一的HTTP/2接口通信，所有能力都以“服务”的形式注册、发现、调用。这意味着，当你需要为自动驾驶车辆部署超低时延切片时，系统不是去手动配置几十台设备，而是动态拉起一组专用的AMF+SMF+UPF实例，并将它们组合成一个逻辑服务链。这种转变，直接决定了5G能否支撑工业互联网、远程手术、AR协同等场景——这些需求对网络的要求，早已不是“通不通”，而是“能不能在毫秒级完成服务重组”。所以，如果你正在研究5G核心网，或者正面临网络升级选型，跳过SBA去谈性能指标，就像只看发动机转速不看变速箱结构就评价一辆车。本文不讲抽象定义，只拆解SBA在真实部署中怎么落地、哪些参数必须调、哪些坑我亲手填过、哪些文档里永远不写的细节，才是决定项目成败的关键。
2. SBA整体设计与思路拆解：从“烟囱式”到“服务化”的必然选择
2.1 为什么非得推翻重来？传统EPC架构的硬伤在哪
要理解SBA的价值，必须先看清它要替代的对象——4G时代的演进分组核心网（EPC）。EPC采用的是典型的“网元堆叠”模式：MME、HSS、SGW、PGW、PCRF等物理或虚拟网元，通过私有协议（如GTP-C、Diameter）点对点互联。这种架构在4G时代运行良好，但到了5G，它暴露出三个无法绕过的结构性缺陷：
第一是扩展性天花板。当某省运营商需要为智慧港口部署50个定制化网络切片时，传统方式意味着为每个切片复制一套MME+SGW+PGW的配置模板，再逐一手动绑定策略。实测下来，单个切片配置耗时平均47分钟，50个就是近40小时连续操作，且任何一处配置错误都会导致整套切片不可用。而SBA下，切片编排器只需向NRF（网络存储功能）发起一次服务发现请求，获取可用的AMF、SMF实例列表，再通过Nnssf接口下发切片策略，整个过程自动化完成，耗时压缩至90秒内。
第二是升级锁死效应。在EPC中，MME升级必须确保与所有关联的HSS、SGW版本兼容，否则信令交互就会中断。我们曾遇到一次MME补丁升级后，因HSS未同步更新，导致全省VoLTE用户注册失败，故障定位花了11小时。SBA则完全不同：每个服务（如UDM）提供清晰的RESTful API契约，只要API版本不变，内部实现可以任意重构——你可以把UDM从Java Spring Boot换成Go语言微服务，只要对外暴露的/udm-ue-contexts/{supi}/sm-data接口行为一致，上层AMF完全无感。
第三是能力复用率低下。EPC中，计费功能（PCRF）和策略控制（PCEF）深度耦合在PGW中，想单独为某个物联网应用启用新的QoS策略，就必须修改PGW镜像并全网推送。而在SBA中，PCF（策略控制功能）是一个独立服务，它通过Npcf接口为所有SMF、UPF提供统一策略决策。某制造企业上线AR远程指导系统时，仅需在PCF中新增一条“视频流优先级=5、最大时延=10ms”的策略规则，无需触碰任何其他网元。
提示：很多初学者误以为SBA只是“把网元拆小了”，这是根本性误解。SBA的核心不是粒度变小，而是通信范式革命——从“网元间私有信令交互”转向“服务间标准API调用”，这直接决定了网络是否具备软件定义的弹性。
2.2 SBA的七层服务化组件：谁在做什么，为什么这样分工
SBA并非简单地把EPC网元重命名，而是根据5G业务特征进行了功能解耦与重组。3GPP TS 23.501标准定义了7个核心服务化网元，它们共同构成SBA的骨架。下面我结合实际部署经验，说明每个组件的真实职责与设计逻辑：
AMF（接入和移动性管理功能）：它不再是MME的简单替代。AMF剥离了会话管理（交给SMF）、用户数据管理（交给UDM），专注处理NAS信令、安全锚点、移动性事件。关键设计点在于：AMF本身不存储用户上下文，所有UE状态都由UDM持久化，AMF只做轻量级会话代理。这使得AMF可以做到无状态横向扩展——我们在某专网项目中，将AMF实例从3个扩到12个，全程零业务中断，因为所有状态都在UDM中。
SMF（会话管理功能）：这是SBA中承上启下的枢纽。它接收来自AMF的PDU会话建立请求，向PCF获取策略，向UPF下发隧道信息，向UDM查询用户签约数据。SMF的“智能”体现在策略驱动：比如当用户进入高密度场馆，SMF会自动触发PCF下发“降低默认QoS等级”的指令，避免UPF资源过载。实测显示，SMF的策略决策延迟必须控制在15ms内，否则会影响PDU会话建立时延。
UPF（用户面功能）：这是唯一允许部署在边缘的网元。UPF不再像SGW/PGW那样集中部署，而是按需下沉到地市甚至园区机房。某车企工厂部署5G专网时，我们将UPF直接部署在车间交换机旁，使AGV小车的端到端时延从38ms降至8ms。UPF的部署位置不是技术问题，而是商业决策——它决定了谁为流量卸载付费。
UDM（统一数据管理）：相当于SBA的“中央数据库”。它存储用户永久标识（SUPI）、签约数据（如AMBR、QoS规则）、鉴权向量等。UDM必须支持强一致性读写，我们曾因选用最终一致性的Redis集群作为UDM后端，导致用户跨省漫游时出现鉴权失败，最终切换为CockroachDB才解决。
PCF（策略控制功能）：它的输入源有三个：UDM（用户签约）、AF（应用功能，如视频会议平台）、SMF（实时网络状态）。PCF的策略引擎必须支持动态规则加载，某直播平台要求“演唱会期间自动开启5G NR-U频段”，我们通过PCF的动态策略API，在活动开始前2小时推送新规则，无需重启服务。
AUSF（认证服务器功能）：专责5G-AKA鉴权流程。它与UDM协作生成鉴权向量，但自身不存密钥。安全设计要点是：AUSF必须部署在硬件安全模块（HSM）保护的环境中，我们曾因测试环境未启用HSM，导致AUSF日志泄露Kausf密钥，被安全团队一票否决。
NRF（网络存储功能）：SBA的“服务注册中心”。所有服务启动时向NRF注册自身IP、端口、支持的服务接口及负载权重；其他服务通过NRF发现可用实例。NRF的健康检查机制至关重要——我们设置NRF每5秒向UPF发送心跳，若连续3次无响应，则将其从服务列表剔除，避免SMF调用到已宕机的UPF。
2.3 服务化接口的底层逻辑：为什么必须用HTTP/2而非传统信令
SBA规定所有服务间通信必须使用HTTP/2 over TLS，这常被质疑“信令协议为何不用更轻量的UDP”。答案藏在三个刚性需求里：
首先是多路复用（Multiplexing）。HTTP/2允许单个TCP连接上并发传输多个请求/响应流。在高并发场景下，这比Diameter协议的“每个事务一个TCP连接”节省90%以上连接数。某省运营商峰值注册用户达200万/秒，若用Diameter，光是TCP连接就需消耗16TB内存，而HTTP/2将连接数压至2万以内。
其次是头部压缩（HPACK）。5G信令中大量重复字段（如UE ID、时间戳），HTTP/2的HPACK算法可将典型NAS消息头从128字节压缩至18字节。我们在抓包分析中发现，SMF向UPF下发的PFCP Session Establishment Request消息，启用HPACK后，网络带宽占用下降63%。
最后是服务发现友好性。HTTP/2的ALPN（应用层协议协商）机制，使NRF能精确识别服务类型。当AMF向NRF查询“可用的SMF实例”时，NRF返回的JSON中不仅包含IP地址，还携带"service-api": "nsmf-pdusession"字段，AMF据此知道该实例支持PDU会话管理API。这种语义化描述，是私有信令协议无法提供的。
注意：HTTP/2并非银弹。我们曾因忽略TLS握手开销，在边缘UPF上部署HTTP/2服务时，发现首包延迟突增40ms。解决方案是启用TLS会话复用（Session Resumption），将握手耗时从300ms降至20ms。
3. 核心细节解析与实操要点：从理论到现网落地的关键跨越
3.1 NRF服务注册与发现的实操陷阱
NRF看似只是个注册中心，但在真实部署中，它是SBA稳定性的“心脏起搏器”。我见过太多项目卡在NRF环节，不是因为配置错误，而是对服务生命周期的理解偏差。
首先，服务注册不是“一劳永逸”。每个服务（如AMF）必须周期性向NRF发送PUT /nnrf-nfm/v1/nf-instances/{nfInstanceId}心跳，缺省间隔为30秒。但这个值不能随意调大——某项目为降低NRF负载，将心跳设为120秒，结果当AMF实例因GC暂停3秒时，NRF误判其宕机并剔除，导致该AMF管辖的所有UE掉线。正确做法是：心跳间隔 ≤ 服务最大容忍中断时间 × 0.7。例如，若业务要求AMF中断不超过10秒，则心跳必须≤7秒。
其次，服务发现的“权重”字段常被滥用。NRF返回的实例列表中，每个条目含"priority": 1, "weight": 50字段。很多人以为weight越大越优先，其实这是轮询算法的权重系数。当SMF向NRF查询UPF时，NRF返回两个实例：UPF-A（weight=50）、UPF-B（weight=100），那么SMF后续10次请求中，约7次发给UPF-B，3次发给UPF-A。但若UPF-B因负载过高开始丢包，NRF不会自动降权——它只管注册状态，不管服务质量。因此，我们强制在SMF中嵌入自适应负载均衡模块：SMF持续监控每个UPF的PFCP Heartbeat响应时间，若某UPF连续5次响应>50ms，则临时将其weight设为0，直到恢复。
最后，NRF自身的高可用极易被忽视。NRF必须部署为集群，但3GPP未规定集群同步机制。我们测试过三种方案：
- 方案A：NRF节点间用Raft共识算法同步注册表。优点是强一致，缺点是写入延迟高（平均120ms），导致服务注册慢；
- 方案B：NRF节点共享一个PostgreSQL数据库。优点是读取快，但单点数据库成为瓶颈；
- 方案C：NRF节点本地缓存+异步广播。这是我们最终采用的方案：每个NRF节点维护本地注册表，服务注册时同步写入本地+广播变更事件，其他节点异步更新。实测注册延迟<15ms，且单节点故障不影响服务发现。
实操心得：NRF的
/nnrf-nfm/v1/nf-instances接口返回的"nfStatus": "REGISTERED"状态，不代表该服务100%可用。必须配合/nnrf-nfm/v1/health-check主动探测，这才是生产环境的黄金准则。
3.2 PFCP协议在UPF-SMF交互中的深度解析
PFCP（Packet Forwarding Control Protocol）是SBA中用户面控制的“神经中枢”，它定义了SMF如何指挥UPF建立、修改、删除数据隧道。很多工程师只关注PFCP消息格式，却忽略了其背后的时序约束与容错机制。
PFCP会话建立流程看似简单：SMF发Session Establishment Request→ UPF回Session Establishment Response。但真实网络中，这个过程充满不确定性。UPF可能因CPU过载无法及时响应，或SMF发送的Request消息因网络抖动丢失。PFCP为此设计了三重保障：
第一是事务ID（Sequence Number）机制。每个PFCP消息含8字节Sequence Number，UPF收到重复Sequence Number的消息时，必须重发上次响应，而非重新处理。这解决了网络重传导致的重复创建问题。我们在某项目中故意制造网络丢包，发现UPF对同一Sequence Number的Request响应时间稳定在8ms，而重新处理则需42ms。
第二是心跳保活（Heartbeat Request/Response）。SMF与UPF建立TCP连接后，每30秒互发Heartbeat。若一方连续3次未收到响应，则断开连接并触发重连。关键点在于：Heartbeat消息不携带业务数据，但必须走相同TCP连接。我们曾因防火墙策略错误，只放行PFCP数据端口（8805），未放行Heartbeat端口，导致UPF在3分钟后被SMF标记为“失联”，引发大规模会话中断。
第三是会话状态同步（Association Setup）。UPF首次上线时，必须与SMF执行Association Setup流程，交换双方支持的PFCP版本、TEID范围、缓冲区大小等能力。这里有个致命细节：UPF上报的"recoveryTime"字段，表示其从故障中恢复所需的最长时间（单位秒）。SMF必须将此值纳入会话重建超时计算——若UPF上报recoveryTime=120，则SMF在UPF失联后，需等待至少120秒才触发会话迁移，否则可能造成“双UPF同时转发”导致数据乱序。
常见误区：认为PFCP是“单向控制协议”。实际上，UPF可通过
Error Indication消息主动通知SMF异常，如"cause": "USER_PLANE_NOT_AVAILABLE"。我们正是利用此机制，在UPF检测到本地存储满时，主动向SMF上报错误，SMF随即触发会话迁移，避免用户业务中断。
3.3 安全架构中的AUSF-UDM协同机制
5G鉴权比4G复杂得多，核心在于引入了SUCI（Subscription Concealed Identifier）机制，防止IMSI在空口明文传输。这要求AUSF与UDM必须紧密协同，而协同的可靠性直接决定用户能否开机即连网。
SUCI解密流程如下：UE发送SUCI（含加密的SUPI）→ AMF转发给AUSF → AUSF向UDM请求解密密钥Ksuci → UDM返回Ksuci → AUSF解密得SUPI → AUSF生成鉴权向量AV。这个链条中，UDM返回Ksuci的延迟是关键瓶颈。我们实测发现，当UDM后端数据库响应时间>200ms时，用户开机附着时延从1.2秒飙升至8.7秒。
解决方案不是简单加数据库缓存，而是重构密钥分发路径。我们采用“预计算+分级缓存”策略：
- 第一级：UDM内存缓存最近10万个SUPI对应的Ksuci，命中率92%；
- 第二级：UDM部署Redis集群缓存热点SUPI（如某大型企业员工号段），TTL设为1小时；
- 第三级：对冷数据，UDM启用异步解密队列，将耗时操作放入后台线程池，前端立即返回“密钥生成中”，AMF收到后启动10秒等待窗口。
更关键的是AUSF的密钥轮换机制。Ksuci密钥必须定期更新（3GPP建议每90天），但轮换不能影响在线用户。我们的做法是：UDM生成新旧两套Ksuci，AUSF在解密时先试用新密钥，失败则自动回退到旧密钥。轮换窗口期设为7天，期间所有新注册用户用新密钥，老用户仍可用旧密钥，平滑过渡。
警告：AUSF与UDM间的Nausf-UEAuthentication接口必须启用双向mTLS认证。我们曾因测试环境为图省事关闭mTLS，导致AUSF日志中明文记录Kausf密钥，被安全扫描工具直接标为“严重漏洞”。
4. 实操过程与核心环节实现：手把手搭建可验证的SBA最小系统
4.1 环境准备与工具链选型
搭建SBA验证环境，首要原则是用生产级组件，而非玩具模拟器。我们放弃Open5GS等教学框架，选择以下经商用验证的开源组件：
- 核心网服务：Free5GC v3.2.1（符合3GPP R15/R16）
- UPF：UERANSIM UPF（轻量级，支持PFCP 1.1）
- NRF：ETCD v3.5.9（作为NRF后端，因其强一致性和成熟运维生态）
- 信令跟踪：Wireshark 4.0.8（需编译PFCP插件）
- 压力测试：Gatling 3.8.3（自定义5G NAS/PFCP协议脚本）
硬件配置按最小可行原则：
- 控制面（AMF/SMF/UDM/AUSF/PCF/NRF）：4核8G虚拟机×1台
- 用户面（UPF）：4核16G虚拟机×1台（需开启SR-IOV）
- 终端模拟：UERANSIM v3.2.0（运行在另一台4核8G机器）
注意：Free5GC的Docker Compose部署脚本默认将所有服务暴露在localhost，这会导致UPF无法被AMF发现。必须修改
free5gc-compose.yaml中各服务的network_mode: "host"，并为UPF单独配置extra_hosts: ["amf:192.168.10.10"]，其中192.168.10.10为AMF宿主机IP。
4.2 关键配置文件详解与参数调优
SBA的稳定性高度依赖配置文件的精准设置。以下是Free5GC中三个核心配置文件的实战调优要点：
1.free5gc/config/free5gc.conf（全局配置）
nrf.uri = "https://192.168.10.10:7777"：必须用HTTPS，且IP为NRF宿主机真实IP，不能写localhost；amf.n2InterfaceAmfIpAddress = ["192.168.10.10"]：AMF监听N2接口的IP，必须与gNB配置的AMF地址一致；smf.upfSelection = "static"：初期调试用静态UPF选择，避免NRF服务未就绪导致SMF启动失败。
2.free5gc/config/udm.yaml（UDM配置）
database.type = "cockroachdb"：必须指定CockroachDB，MySQL不支持UDM所需的分布式事务；database.url = "postgresql://root@192.168.10.10:26257/udm?sslmode=disable"：注意端口26257是CockroachDB默认端口，非5432；security.encryption.key = "32-byte-aes-key-here"：AES密钥必须32字节，我们用openssl rand -hex 32生成。
3.upf/config/upf.yaml（UPF配置）
pfcp.bindAddr = "192.168.10.20"：UPF监听PFCP的IP，必须与SMF配置的UPF地址一致；gtpu.bindAddr = "192.168.10.20"：GTP-U数据面IP，需与SMF的smf.upf[0].gtpuAddr匹配；pdr.poolSize = 10000：PDR（Packet Detection Rule）池大小，初始设10000，每增加1000个并发用户需+1000。
实操技巧：Free5GC的日志级别默认为INFO，但排查PFCP问题必须设为DEBUG。在
free5gc/config/free5gc.conf中添加log.level = "debug"，并在smf.yaml中设置log.file = "/var/log/free5gc/smf.log"，否则日志会刷屏且难以定位。
4.3 端到端流程验证与关键日志解读
完成部署后，必须验证三个黄金流程：用户注册、PDU会话建立、服务发现。以下是每个流程的验证方法与日志关键点：
流程1：UE注册（AMF-AUSF-UDM协同）
- 步骤：启动UERANSIM UE，执行
./build/ueransim/nr-gnb -c config/gnb.yaml &；UE侧运行./build/ueransim/nr-ue -c config/ue.yaml； - 验证点：查看AMF日志中是否出现
[INFO] Handle NAS Registration Request from [imsi-208930000750000]； - 关键日志：在AUSF日志中搜索
"event":"suci_decryption_success"，确认SUCI解密成功；在UDM日志中搜索"event":"udm_get_subscription_data"，确认签约数据查询完成。
流程2：PDU会话建立（SMF-UPF-PFCP）
- 步骤：UE注册成功后，UERANSIM自动发起PDU会话请求；
- 验证点：Wireshark过滤
pfcp && ip.addr == 192.168.10.20，应看到Session Establishment Request/Response； - 关键日志：SMF日志中
"event":"smf_pcf_selection"确认PCF策略获取成功；UPF日志中"event":"upf_session_established"确认隧道创建完成。
流程3：服务发现（NRF注册验证）
- 步骤：在AMF容器内执行
curl -k https://192.168.10.10:7777/nrf/nfm/v1/nf-instances?nf-type=SMF； - 验证点：返回JSON中
"nfInstanceID"字段必须存在，且"nfStatus"为"REGISTERED"； - 关键日志：NRF日志中
"event":"nrf_nf_registration"确认AMF注册成功。
排查捷径：当流程卡住时，不要盲目查所有日志。按“失败点反向追溯”：若UE卡在Registration Accept，先查AMF日志；若AMF无日志，则查gNB是否成功发送Initial UE Message；若gNB日志正常，则查AMF与NRF网络连通性（
telnet 192.168.10.10 7777）。
5. 常见问题与排查技巧实录：那些文档里绝不会写的血泪教训
5.1 “UE注册失败：Cause #22” 的真实原因与根治方案
几乎所有新手都会遇到UE注册失败，AMF日志显示Cause #22 (MAC failure)。官方文档解释为“鉴权失败”，但实际原因千差万别。我们整理出TOP3真实原因及对应解法：
原因1：SUCI解密密钥不匹配
现象：AMF日志出现[ERROR] SUCI decryption failed for imsi-208930000750000；
根因：UDM中存储的Ksuci密钥与AUSF配置的密钥不一致；
解法：在UDM数据库中执行SELECT * FROM subscription_data WHERE supi = 'imsi-208930000750000';，确认authenticationManagementField字段值；在AUSF配置文件中核对security.kausf值，二者必须完全相同。
原因2：时钟不同步导致SQN失效
现象：AMF日志显示[WARN] SQN is too old or replayed；
根因：UE与AUSF服务器时间差超过10秒（3GPP规定SQN有效期为10秒）；
解法：在所有节点（UE模拟器、AMF、AUSF、UDM）执行sudo timedatectl set-ntp true，并用chrony同步到同一NTP服务器。
原因3：AMF配置的PLMN与UE不匹配
现象：AMF日志无SUCI相关错误，但直接返回Cause #22；
根因：UE配置的plmn-id（如20893）与AMF配置的amf.plmnList不包含该PLMN；
解法：编辑free5gc/config/amf.yaml，在plmnList中添加- mcc: "208" mnc: "93"。
独家技巧：用UERANSIM自带的
nas_logger工具捕获UE侧NAS消息。在UE启动时添加--nas-logger参数，生成nas_log.txt，其中REGISTRATION REQUEST消息的5GS registration type字段若为0x01（initial registration），而AMF返回REGISTRATION REJECT，则100%是上述三类问题之一。
5.2 “SMF无法发现UPF” 的网络层排查清单
SMF日志持续报错[ERROR] Failed to discover UPF via NRF，这是SBA部署中最顽固的问题。我们总结出一份按优先级排序的排查清单：
| 排查层级 | 检查项 | 命令/方法 | 正常表现 | 异常处理 |
|---|---|---|---|---|
| L1：网络连通性 | SMF与NRF TCP端口通吗？ | telnet 192.168.10.10 7777 | Connected | 检查防火墙sudo ufw status，开放7777端口 |
| L2：NRF服务状态 | NRF进程是否运行？ | ps aux | grep nrf | 显示nrf-server进程 | 重启NRF：docker-compose restart nrf |
| L3：UPF注册状态 | UPF是否成功注册到NRF？ | curl -k https://192.168.10.10:7777/nrf/nfm/v1/nf-instances?nf-type=UPF | 返回含"nfType":"UPF"的JSON | 检查UPF日志"event":"upf_nrf_registration_success" |
| L4：SMF配置 | SMF配置的NRF地址是否正确？ | 查smf.yaml中nrf.uri | 值为https://192.168.10.10:7777 | 修改后重启SMF：docker-compose restart smf |
| L5：证书信任 | SMF是否信任NRF证书？ | curl -v -k https://192.168.10.10:7777/nrf/health | 返回{"status":"OK"} | 将NRF证书nrf.pem拷贝到SMF容器/etc/ssl/certs/，重启 |
血泪教训：某次故障排查耗时6小时，最终发现是L5层问题——SMF容器内没有安装
ca-certificates包，导致无法验证NRF的自签名证书。解决方案：在SMF Dockerfile中添加RUN apt-get update && apt-get install -y ca-certificates。
5.3 “UPF数据面不通” 的PFCP深度诊断法
即使PFCP会话建立成功，用户仍无法上网，这是最棘手的问题。我们开发了一套PFCP四层诊断法：
第一层：PFCP信令层
用Wireshark抓取UPF的8805端口，过滤pfcp && pfcp.message_type == 1（Session Establishment Request），确认SMF是否发出请求；若无此包，问题在SMF侧。
第二层：GTP-U隧道层
在UPF上执行sudo tcpdump -i any port 2152 -w gtpu.pcap，过滤GTP-U端口2152，确认是否有GTP-U数据包流入；若无，检查SMF下发的F-SEID（F-TEID）是否与UPF配置的gtpu.bindAddr匹配。
第三层：路由转发层
在UPF上执行ip route show table all \| grep "via"，确认是否存在指向UE IP段的路由；若无，检查SMF是否下发了正确的PDR（Packet Detection Rule）和FAR（Forwarding Action Rule）。
第四层：内核转发层
执行sudo sysctl net.ipv4.ip_forward，确认值为1；执行sudo iptables -t nat -L POSTROUTING，确认存在SNAT规则；若缺失，手动添加：sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/16 -o eth0 -j MASQUERADE。
终极武器：在UPF上运行
sudo ./upf -c config/upf.yaml -debug，开启UPF调试模式，日志中会输出每条PDR的匹配计数。若某PDR的matchCount始终为0，说明UE流量根本未到达UPF，问题必在gNB或传输网。
6. 性能调优与生产化加固：从实验室Demo到商用承载的跨越
6.1 并发用户数突破10万的SMF优化实践
当SMF需要支撑10万级并发UE时，原生Free5GC的默认配置会迅速崩溃。我们通过三项关键优化，将SMF单实例承载能力提升至12.8万UE：
优化1：异步PFCP处理
Free5GC默认PFCP消息处理是同步阻塞的。我们将SMF的PFCP Handler改为协程池模式：启动16个goroutine工作池，每个池处理2000个PFCP会话。修改smf/pfcp_handler.go，在HandlePfcpMessage函数中加入go pfcpWorker.Process(msg)。实测PFCP响应延迟从180ms降至22ms。
优化2：UDM查询缓存
SMF每建立一个PDU会话，需向UDM查询用户签约数据。我们将UDM查询封装为带TTL的LRU缓存，缓存键为SUPI+sliceId，TTL设为300秒（用户签约数据极少变更）。缓存命中率91%，UDM数据库QPS从8000降至720。
优化3：UPF连接复用
SMF与UPF间TCP连接默认每会话新建一个。我们启用HTTP/2连接池，单个TCP连接复用处理1000个PFCP会话。在smf/upf_client.go中配置http2.Transport.MaxConcurrentStreams = 1000。UPF侧连接数从10万降至100，内存占用下降76%。
注意：以上优化需修改Free5GC源码，我们已将补丁提交至GitHub仓库，分支名为
smf-scale-100k。生产环境务必使用此分支，而非官方master。
6.2 高可用部署中的NRF集群故障转移实测
NRF单点部署是生产环境的定时炸弹。我们构建了3节点NRF集群（nrf-0、nrf-1、nrf-2），并进行故障注入测试：
场景1：单节点宕机
kill掉nrf-0进程，观察SMF服务发现：3秒内NRF集群自动选举新leader，SMF在5秒内完成服务重发现，无会话中断。场景2：网络分区
用iptables隔离nrf-0与nrf-1的通信，nrf-0进入partitioned状态。此时nrf-1与nrf-2组成多数派，继续提供服务。SMF向nrf-0
