4. N3接口协议栈：N3接口概述（GTP-U协议）

各位好，今天我们聊聊N3接口。这个接口在5G核心网里，地位相当特殊。它连接着基站（gNB）和用户面功能（UPF），说白了，就是用户数据进出的“高速公路”。

我刚开始接触5G核心网开发时，有个很深的体会：控制面的信令再复杂，最终目的都是为了给用户面铺路。而N3接口，就是这条路上最关键的一段。你想想看，用户的上网数据、语音通话、视频流，全都要经过它。

N3接口的核心协议，叫做GTP-U（GPRS Tunneling Protocol for User Plane）。这个名字有点长，但记住一点就行：它负责在基站和UPF之间，建立一个“隧道”，让用户数据安全、有序地传输。

核心要点：GTP-U协议是N3接口的“灵魂”。没有它，用户数据就像没有信封的信件，谁都能看，还容易丢。

4.1 GTP-U头部结构：TEID与序列号

GTP-U的头部，结构其实不复杂。但有两个字段，我必须重点讲：TEID（Tunnel Endpoint Identifier）和序列号。

TEID，隧道端点标识符。你可以把它想象成“门牌号”。每个用户会话，在基站和UPF上，都有一个唯一的TEID。数据包到了，UPF一看TEID，就知道该发给哪个用户。

我在项目中遇到过一个问题：两个用户会话的TEID配置重复了。结果呢？数据乱窜，用户A的视频流跑到了用户B的手机上。排查了好久，最后发现是配置脚本里写死了TEID，没做唯一性检查。嗯，这里要注意：TEID必须全局唯一，尤其是在同一个UPF下。

序列号，这个字段的作用，是保证数据包的顺序。GTP-U本身不保证顺序，但序列号可以让接收方知道，哪个包先来，哪个包后来。

你可能会问：“IP层不是有分片和重组吗？为什么还要序列号？” 问得好。IP层确实能重组，但GTP-U隧道里，数据包可能走不同的路径。序列号就是用来应对这种“乱序”情况的。

GTP-U头部的基本结构如下：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|版本号 | PT | * | E | S | PN |  消息类型  |  长度（不含头部） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           TEID                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   序列号（可选）   |   N-PDU号（可选） |  下一个扩展头类型    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

注意看，序列号和N-PDU号是可选的。它们只在特定标志位（S和PN）置1时才出现。我建议你在开发时，默认把序列号带上。虽然多占4个字节，但排查问题时，序列号能帮你省下大把时间。

4.2 GTP-U扩展头

GTP-U扩展头，是协议里一个很灵活的设计。它允许我们在标准头部之外，附加一些额外信息。比如：

  • PDU会话容器：携带QoS流标识（QFI），告诉UPF这个包属于哪个QoS流。
  • 用户面数据包标记：用于反射QoS（Reflective QoS）场景。
  • 服务体验指标：比如视频播放的卡顿次数，可以在这里传递。

扩展头的格式也很简单：每个扩展头都有一个“下一个扩展头类型”字段，指向下一个扩展头。最后一个扩展头，这个字段设为0。说白了，就是一个链表结构。

个人经验：扩展头虽然好用，但别滥用。每加一个扩展头，数据包就大一些，处理延迟也高一些。我一般只在需要传递QoS信息时，才加PDU会话容器扩展头。其他情况，能不加就不加。

4.3 用户面数据封装与解封装

这部分，是N3接口开发的核心操作。说白了，就是“打包”和“拆包”。

封装过程（基站侧）：

  1. 基站收到用户的上行数据（比如一个HTTP请求）。
  2. 基站给这个数据包，加上GTP-U头部（包含TEID、序列号等）。
  3. 再加上UDP头部（端口号2152，这是GTP-U的固定端口）。
  4. 最后加上IP头部，发往UPF。

解封装过程（UPF侧）：

  1. UPF收到UDP包，检查端口号是不是2152。
  2. 去掉UDP头部，露出GTP-U头部。
  3. 根据TEID，找到对应的用户会话。
  4. 去掉GTP-U头部，取出原始的用户数据包。
  5. 把数据包交给上层处理（比如转发到互联网）。

这个过程，看起来简单，但坑不少。我曾经遇到过一个性能问题：UPF在解封装时，每次都要遍历一个很大的TEID表，导致吞吐量上不去。后来改成哈希表，问题才解决。

避坑指南：我曾经在封装时，忘记设置GTP-U头部的长度字段。结果UPF收到包后，解析失败，直接丢弃。排查了半天，才发现是长度字段为0。记住：长度字段是头部之后的数据长度，不包括头部本身。

还有一个细节：GTP-U的UDP端口是2152。这个端口号，在防火墙和NAT配置里，一定要放行。否则，基站和UPF之间，数据包根本过不去。

好了，N3接口的GTP-U协议，今天就聊到这里。下一节，我们会深入GTP-U的扩展头，看看它到底能玩出什么花样。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →