2. 核心网信令面与用户面：信令面协议栈（HTTP/2、PFCP、GTP-C）、用户面协议栈（GTP-U、UDP/IP）、N1/N2/N3/N4/N6接口详解
各位好，咱们今天聊聊核心网里最基础、也最绕不开的一个话题——信令面和用户面的分离。
说白了，5G核心网的设计哲学就是「控制与转发分离」。你想想看，信令面负责「动嘴皮子」，用户面负责「干苦力」。我刚开始接触5GC的时候，总觉得这两个平面就是简单的逻辑划分，直到有一次在现网排查一个VoNR语音断续的问题，才发现信令面和用户面在接口上的交互细节，才是真正的坑。
好，咱们直接进入正题。
2.1 信令面协议栈
信令面，也叫控制面。它承载的是NAS消息、会话管理、移动性管理等核心逻辑。我习惯把它比作「大脑」——它不直接传用户数据，但它决定数据怎么传、往哪传。
2.1.1 HTTP/2
5GC的SBI接口（基于服务的架构）全面拥抱了HTTP/2。为什么不用HTTP/1.1？因为HTTP/2支持多路复用、头部压缩、服务器推送。说白了，就是快。
我在项目中遇到过一个问题：AMF和SMF之间的通信突然变慢，抓包一看，HTTP/2的流ID冲突了。嗯，这里要注意，HTTP/2的流ID是单递增的，如果客户端和服务端对不上号，就会导致RST_STREAM帧满天飞。
2.1.2 PFCP
PFCP（Packet Forwarding Control Protocol）是SMF和UPF之间的「传话筒」。它负责告诉UPF：这个UE的包该怎么转发、要不要做QoS标记、要不要做GTP-U封装。
PFCP的消息类型不多，但每个都很关键。我列个表，你一看就明白：
| 消息类型 | 作用 | 我踩过的坑 |
|---|---|---|
| PFCP Session Establishment | 建立会话 | 有一次FAR规则没配全，导致UPF一直丢包 |
| PFCP Session Modification | 修改会话 | QoS变更时，BAR（Buffering Action Rule）没更新，语音包被缓存了 |
| PFCP Session Deletion | 删除会话 | UE频繁附着/去附着时，PFCP会话残留，UPF内存泄漏 |
我曾经在现网遇到过一个诡异的问题：用户上网正常，但VoNR语音不通。抓包发现PFCP的PDR（Packet Detection Rule）里，UL PDR和DL PDR的TEID配反了。你想想看，上行包被当成了下行包，语音能通才怪。
2.1.3 GTP-C
GTP-C是4G时代的「老将」，在5G里主要用于N4接口的某些场景（比如N4会话的建立和释放）。虽然5GC主推PFCP，但GTP-C并没有完全退役。
GTP-C的消息类型包括Create Session Request/Response、Modify Bearer Request/Response等。我个人的经验是，GTP-C的排查重点在于TEID的分配和释放。如果TEID分配冲突，会导致会话建立失败。
2.2 用户面协议栈
用户面，也叫数据面。它负责真正的用户数据传输——你的微信消息、抖音视频、网页浏览，全走用户面。
2.2.1 GTP-U
GTP-U是用户面的核心协议。它把用户IP包封装在GTP隧道里，在gNB和UPF之间传输。说白了，就是「包一层皮」。
GTP-U的头部包含TEID、序列号、扩展头等信息。TEID是关键——它标识了哪个UE的哪个会话。我在项目中遇到过一个问题：GTP-U的序列号回绕导致UPF丢包。嗯，这里要注意，GTP-U的序列号是16位的，如果流量太大，序列号会回绕，UPF需要正确处理。
2.2.2 UDP/IP
GTP-U是承载在UDP/IP之上的。UDP端口号2152是GTP-U的默认端口。为什么用UDP不用TCP？因为用户面追求低延迟，UDP不需要三次握手和重传，效率更高。
但UDP也有缺点——它不可靠。如果网络丢包，GTP-U不会自动重传。所以，用户面的质量很大程度上取决于底层IP网络的稳定性。我建议，排查用户面问题时，先看UDP的重传率和乱序率。
tcpdump -i any udp port 2152。然后分析GTP-U的TEID和序列号，判断是否有丢包或乱序。
2.3 N1/N2/N3/N4/N6接口详解
5GC的接口命名很直观——N1到N6，每个接口都有明确的职责。我画了一张图，帮你理清它们的关系：
好，咱们逐个接口过一遍。
2.3.1 N1接口
N1是UE和AMF之间的接口。它传输的是NAS消息——比如注册请求、服务请求、PDU会话建立请求。说白了，UE和核心网之间的「悄悄话」都走N1。
我在项目中遇到过一个问题：UE注册时，N1接口的NAS消息被gNB截断了。原因是gNB的NAS消息长度限制没配好。嗯，这里要注意，NAS消息的最大长度是65535字节，但gNB的配置可能更小。
2.3.2 N2接口
N2是gNB和AMF之间的接口。它传输的是NGAP消息——比如初始上下文建立请求、UE上下文释放请求。说白了，gNB和核心网之间的「握手」都走N2。
我曾经在现网遇到过一个经典问题：UE切换时，N2接口的Handover Required消息丢失，导致切换失败。抓包发现是SCTP的流ID冲突。你想想看，SCTP是多流传输的，如果流ID分配不当，消息就会乱序或丢失。
2.3.3 N3接口
N3是gNB和UPF之间的接口。它传输的是GTP-U数据包。说白了，用户数据从gNB到UPF，走的就是N3。
N3接口的排查重点在于GTP-U的TEID和序列号。我建议，如果用户上网慢，先看N3接口的GTP-U重传率。如果重传率超过1%，说明底层IP网络有问题。
2.3.4 N4接口
N4是SMF和UPF之间的接口。它传输的是PFCP消息。说白了，SMF通过N4告诉UPF：这个UE的包该怎么处理。
N4接口的排查重点在于PFCP的会话状态。我遇到过一个问题：SMF和UPF之间的PFCP心跳超时，导致UPF删除了所有会话。嗯，从那以后，我每次部署都会检查PFCP心跳间隔——默认是30秒，但有些场景需要调小。
2.3.5 N6接口
N6是UPF和DN（数据网络）之间的接口。它传输的是普通的IP包。说白了，用户数据从UPF到互联网，走的就是N6。
N6接口的排查重点在于NAT和防火墙。我建议，如果用户能上网但某些应用打不开，先看N6接口的NAT表项是否正常。我曾经遇到过一个案例：NAT表项老化时间太短，导致长连接被中断。
好，这一章的内容就到这里。记住，信令面和用户面的分离是5GC的核心设计，理解接口和协议栈是排查一切问题的基础。下一章咱们会深入N4接口的PFCP细节，到时候再聊。