2. LTE协议栈全景：用户面与控制面，各层功能与数据封装流程
做LTE抓包分析，第一件事不是急着开工具，而是先把协议栈这张地图刻在脑子里。我见过太多人拿着抓包文件一头扎进去，结果连当前报文是控制面还是用户面都分不清——嗯，那基本就是在浪费时间。
说白了，LTE协议栈就两条主线：用户面管数据怎么传，控制面管信令怎么走。两条线共用底层，但到了上层就各走各的路。今天我们就把它彻底拆开来看。
核心观点：抓包时你看到的每一个IP包，最终都要经过用户面协议栈的层层封装；而每一次切换、附着、寻呼，背后都是控制面信令在忙碌。两条线缺一不可。
2.1 用户面协议栈：数据是怎么从基站到手机的？
用户面，也叫U-Plane。它的任务很单纯——把用户的数据包（比如你在刷的视频、发的）从核心网一路送到终端，或者反过来。我习惯把它叫做「数据管道」。
来看这张图，我手绘的，你感受一下层级关系：
你看，UE和eNB之间走的是空口协议栈，eNB和S-GW之间走的是GTP-U隧道。这两段用的协议完全不同，抓包时一定要区分清楚。
2.2 各层功能拆解：每一层在干什么？
我按从下往上的顺序来讲，这样更符合数据封装的实际流程。
2.2.1 L1（物理层）
物理层负责最底层的比特传输。调制、编码、MIMO、资源映射，全在这层。抓包时你基本看不到L1的原始数据，因为抓包工具拿到的已经是MAC层交上来的东西了。但你要知道——L1决定了你能跑多快。
2.2.2 MAC层（媒体接入控制）
MAC层干三件事：调度、HARQ、随机接入。说白了就是「谁什么时候发数据、发错了怎么重传、新设备怎么接入」。我在项目中遇到过一个问题：某次路测发现下行速率忽高忽低，抓包一看，MAC层的调度请求频繁超时——原来是上行资源分配出了问题。
抓包小技巧：在Wireshark里过滤 mac-lte，可以看到MAC层的调度信息和HARQ反馈。这对排查空口质量问题非常有用。
2.2.3 RLC层（无线链路控制）
RLC有三种模式：TM（透传）、UM（非确认）、AM（确认）。你想想看，如果传的是VoLTE语音包，延迟敏感但可以容忍少量丢包，那就用UM模式；如果是下载文件，一个比特都不能丢，那就用AM模式加自动重传。
我建议你在分析RLC层时，重点关注序列号（SN）和重传次数。曾经有一次，我排查一个「下载速度慢」的问题，发现RLC层AM模式下的重传率高达15%——空口质量差得离谱。
2.2.4 PDCP层（分组数据汇聚协议）
PDCP负责三件事：头压缩（ROHC）、加密、完整性保护。抓包时你会发现，PDCP层的PDU里，用户面的IP头被压缩得只剩几个字节——这就是ROHC的功劳。
嗯，这里要注意：PDCP层的序列号是抓包分析中非常关键的字段。切换发生时，PDCP SN的连续性直接决定了数据会不会丢。
2.2.5 上层（应用层）
到了应用层，就是纯IP包了。HTTP、FTP、VoLTE的RTP流，全在这里。抓包分析到这一层，基本就是传统的IP网络分析思路了。
2.3 控制面协议栈：信令是怎么走的？
控制面，也叫C-Plane。它的任务是传递信令——附着、去附着、切换、寻呼、承载建立……所有管理性的消息都走这条路。
控制面和用户面最大的区别在于：控制面多了一层RRC和NAS。RRC是空口的信令管家，NAS是核心网和终端之间的信令通道。
控制面协议栈里，S1-AP和NAS是抓包分析的重头戏。S1-AP负责eNB和MME之间的信令交互，NAS则承载了核心网和终端之间的认证、安全、承载管理消息。
2.4 数据封装流程：一个IP包是怎么发出去的？
我拿一个最简单的场景举例：手机发一个HTTP请求到互联网。你想想看，这个IP包从应用层一路往下，每一层都干了什么？
| 层级 | 输入 | 处理动作 | 输出 |
|---|---|---|---|
| 应用层 | HTTP请求 | 封装为TCP/IP包 | IP包（含TCP头+HTTP头+载荷） |
| PDCP | IP包 | 头压缩（ROHC）、加密、加PDCP头 | PDCP PDU |
| RLC | PDCP PDU | 分段/级联、加RLC头 | RLC PDU |
| MAC | RLC PDU | 复用、加MAC头、调度 | MAC PDU（传输块） |
| L1 | 传输块 | 编码、调制、映射到资源块 | 空口信号 |
你看，每一层都在加头、做处理。抓包时你看到的每一个PDU，都是经过层层封装后的结果。反过来，接收端就是一层层解封装。
避坑指南：我曾经在分析一个VoLTE掉话问题时，只盯着应用层的SIP信令看，死活找不到原因。后来才发现，问题出在RLC层的分段上——一个大的PDCP PDU被分成了多个RLC段，其中一段在空口丢了，导致整个PDU无法重组。所以，抓包分析一定要有「跨层思维」。
2.5 用户面 vs 控制面：关键差异一览
为了方便你快速对照，我整理了一张表：
| 对比维度 | 用户面（U-Plane） | 控制面（C-Plane） |
|---|---|---|
| 主要功能 | 传输用户数据（IP包） | 传输信令（NAS、RRC、S1-AP） |
| 关键协议 | PDCP、RLC、MAC、GTP-U | NAS、RRC、S1-AP、SCTP |
| 传输层 | UDP（GTP-U隧道） | SCTP（S1-MME接口） |
| 抓包关注点 | GTP-U TEID、PDCP SN、RLC重传 | RRC消息类型、NAS PDU、S1-AP过程 |
| 典型问题 | 吞吐量低、时延大、丢包 | 附着失败、切换失败、寻呼无响应 |
我个人习惯在抓包时，先通过IP地址和端口号快速判断当前报文属于哪个面。用户面的GTP-U通常用UDP 2152端口，控制面的S1-AP用SCTP 36412端口——记住这两个端口号，能帮你省不少时间。
2.6 小结：抓包前必须想清楚的事
协议栈全景图，说白了就是你抓包时的「导航地图」。没有这张图，你看到的只是一堆十六进制字节流；有了它，你才能知道每一层在干什么、每一段数据从哪里来、到哪里去。
我建议你下次打开Wireshark时，先问自己三个问题：
- 当前报文是用户面还是控制面？
- 它经过了哪些协议层的封装？
- 如果出了问题，最可能出在哪一层？
想清楚这些，你的抓包分析才算真正开始。