手把手调试5G SMF：PDU会话修改全流程抓包分析（含N2/N4接口示例）-CSDN博客

手把手调试5G SMF：PDU会话修改全流程抓包分析（含N2/N4接口示例）

调试5G核心网，尤其是SMF（会话管理功能），最让人头疼的往往不是协议文本的晦涩，而是理论与抓包现实的“脱节”。你明明对着3GPP规范看懂了PDU会话修改的流程图，可一旦打开Wireshark，面对满屏的HTTP/2和PFCP报文，瞬间就迷失了方向——哪个消息对应流程图的哪一步？N2和N4接口的报文结构到底长什么样？参数填错了，信令流会在哪里断掉？

这篇文章，就是为你准备的实战地图。我们不空谈规范，而是直接动手，用一个可复现的实验环境，带你走通一次完整的PDU会话修改流程。我会把Wireshark抓包窗口和协议栈的交互一一对应，重点拆解N2（AMF-SMF）和N4（SMF-UPF）这两个关键接口的报文细节，并分享几个我实际排查中遇到的典型故障案例。目标很明确：让你下次再看到相关报文时，能立刻说出它的来龙去脉。

1. 实验环境搭建与抓包准备

在开始分析信令之前，一个稳定、透明的测试环境是前提。我推荐使用基于容器的开源5G核心网方案，例如open5gs或free5gc，它们模块清晰，易于部署和抓包。

注意：实验环境建议在隔离的网络或虚拟机中搭建，避免干扰生产网络。

我的实验拓扑很简单，但足以覆盖端到端流程：

UE模拟器：ueransim (模拟UE和gNodeB)
5G Core：open5gs (包含AMF、SMF、UPF、UDM等所有网元)
抓包点：我们需要在三个关键链路上部署抓包。
1. N1/N2接口：在AMF所在容器或主机上，抓取与gNodeB模拟器(ueransim-gnb)之间的流量。这里能看到NGAP和NAS消息。
2. N4接口：在SMF和UPF之间。这是PFCP协议的地盘，会话修改的重头戏在这里。
3. N11/N7接口：SMF与AMF（HTTP/2）、SMF与PCF（如果启用）之间的流量，用于观察服务化接口调用。

为了方便，我通常使用一个脚本，在宿主机上通过tcpdump同时抓取所有相关容器的网络流量，并保存为pcap文件，然后用Wireshark进行离线分析。下面是一个示例命令，抓取open5gs所有容器的流量：

# 找出所有open5gs相关容器的网络接口
docker ps --filter "name=open5gs" --format "{
  
  {.Names}}" | while read container; do
    if=$(docker inspect -f '{
  
  {.State.Pid}}' $container)
    sudo tcpdump -i any -w ${container}_trace.pcap host $(docker inspect -f '{
  
  {.NetworkSettings.IPAddress}}' $container) &
done

配置完成后，启动所有服务，让UE完成初始注册和PDU会话建立。确保在Wireshark中能看到基本的NGAP、NAS和PFCP报文，这是后续修改流程的基础。

2. 触发PDU会话修改：三种典型场景的抓包对比

PDU会话修改不会凭空发生，总得有个“扳机”。规范里提到了多种触发源，我们抓包时最常遇见的是以下三种，它们的起始点在抓包文件中截然不同。

2.1 UE发起的修改：从NAS层看起

这是最直观的场景。比如，UE上的一个应用需要更高的带宽，它会主动请求。在抓包中，你会首先在N1接口（承载于N2 NGAP消息中）看到一个UL NAS TRANSPORT消息，其内部包含一个PDU SESSION MODIFICATION REQUEST。

关键字段解析（在Wireshark中展开NAS-5GS消息）：

PDU session ID: 要修改的会话标识。
PTI (Procedure transaction identity): 本次修改事务的独立ID，用于匹配请求和响应。
5GSM capability: UE支持的会话管理能力。
核心部分：Extended protocol configuration options (EPCO) 或特定的 QoS rules container。这里会携带UE想要新增、修改或删除的QoS规则和包过滤器。

[示例] 一个请求新增QoS规则的NAS消息片段
5GSM Message Type: PDU session modification request (0xc9