从抓包实战看LTE附着：用Wireshark一步步解析NAS和RRC信令
在移动通信网络优化和故障排查中，信令分析是最核心的技能之一。想象一下这样的场景：当用户投诉4G网络无法正常接入，或者切换频繁导致掉话时，作为网络工程师的你如何快速定位问题？答案往往藏在那些肉眼看不见的空中接口信令交互中。本文将带你走进LTE附着流程的微观世界，通过Wireshark抓包实战，还原手机从开机到成功接入网络的完整过程。
不同于教科书上的理论流程图，我们将使用真实的pcap文件（已随文提供），逐帧解析每个关键消息的二进制结构。你会发现，那些看似枯燥的协议规范在抓包文件中变得生动具体——从RRC Connection Request中的建立原因值，到Authentication Request中的RAND/AUTN参数，再到Initial Context Setup Request中的QCI承载质量标识，每个字段都直接影响着用户体验。准备好你的Wireshark软件，让我们开始这场技术探险。
1. 实验环境搭建与抓包准备
1.1 硬件与软件配置
要捕获真实的LTE空口信令，你需要以下实验环境配置：
- 软件无线电设备：USRP B210或BladeRF x40等支持LTE频段的SDR设备
- 测试终端：华为E398等4G USB Dongle，或root后的Android手机
- 核心网模拟器：OpenAirInterface或srsRAN提供的EPC模拟环境
- 抓包工具链：
# Ubuntu下安装必要工具 sudo apt install wireshark tshark lte-cell-scanner
提示：商业网络抓包需获得运营商授权，建议在实验室环境使用专用测试频段
1.2 Wireshark关键配置
针对LTE信令分析，需要对Wireshark进行特殊配置：
协议解码设置：
- 启用
3GPP RRC和NAS-EPS解码器 - 添加自定义端口：2152（GTP-U）、36412（S1AP）
- 启用
显示过滤规则：
# 筛选RRC和NAS消息 (rrc || nas-eps) && !(gtpv2 || s1ap)着色规则：
- 将
Authentication Request标记为红色 - 将
RRC Connection Setup Complete标记为绿色
- 将
2. RRC连接建立阶段解析
2.1 初始接入过程抓包
在Wireshark中打开提供的lte_attach.pcap文件，按时间排序后观察前10个报文：
| 帧号 | 时间差(ms) | 协议 | 消息类型 | 关键字段 |
|---|---|---|---|---|
| 1 | 0.000 | LTE RRC | RRC Connection Request | establishmentCause=mo-Signaling |
| 3 | 12.345 | LTE RRC | RRC Connection Setup | srb-ToAddModList=SRB1 |
| 5 | 15.678 | LTE RRC | RRC Connection Complete | dedicatedInfoNAS=AttachRequest |
典型问题定位：
- 如果看到重复的
RRC Connection Request但无响应，可能是：- 上行干扰导致基站未收到
- 基站侧准入控制拒绝
2.2 SRB承载建立细节
在RRC Connection Setup消息中，重点关注SRB1的配置参数：
// ASN.1解码示例 srb-Identity = 1 rlc-Config = am: { ul-AM-RLC = { t-PollRetransmit = ms45 pollPDU = p64 } } logicalChannelConfig = { ul-SpecificParameters = { priority = 3 prioritisedBitRate = kBps16 } }这些参数直接影响信令传输的可靠性。例如：
t-PollRetransmit设置过大会增加重传延迟priority值较低可能导致信令被数据业务阻塞
3. NAS层鉴权流程深度剖析
3.1 鉴权四步握手
过滤出nas-eps协议，观察鉴权流程的四个关键消息：
Authentication Request：
- RAND: 3f2a5c... (16字节随机数)
- AUTN: a87b41... (16字节认证令牌)
- KSI: 6 (密钥标识符)
Authentication Response：
- RES: d894f3... (8字节响应值)
注意：RES长度应与核心网预期的XRES一致，否则鉴权失败
3.2 安全模式协商
安全模式命令(SMC)中携带的算法选择：
| 算法类型 | 可选值 | 典型配置 |
|---|---|---|
| Ciphering | EEA0/1/2/3 | EEA2 (AES) |
| Integrity | EIA0/1/2/3 | EIA2 (AES) |
示例解码：
# Python解析SMC消息 smc_msg = { "security_algorithm": { "ciphering": "EEA2", "integrity": "EIA2" }, "nas_ksi": 6, "ue_security_capabilities": ["EEA2","EIA2","EEA1","EIA1"] }4. 承载建立与上下文激活
4.1 E-RAB建立过程
通过过滤s1ap协议观察承载建立：
Frame 123: S1AP InitialContextSetupRequest E-RABToBeSetupList = { id=5, qci=9, arp=8, gtp-tunnel = {sgw-ip=192.168.1.100, teid=0x42a3c1f} } Frame 156: S1AP InitialContextSetupResponse E-RABSetupList = { id=5, enb-ip=10.10.8.2, teid=0xb5d92e }QCI映射关系：
| QCI | 业务类型 | 优先级 | 时延要求(ms) |
|---|---|---|---|
| 5 | IMS信令 | 1 | 100 |
| 9 | 默认互联网业务 | 9 | 300 |
4.2 无线承载配置
最后阶段的RRC Connection Reconfiguration消息包含完整的无线资源配置：
<rrcConnectionReconfiguration> <srb-ToAddMod> <srb-Identity>2</srb-Identity> <rlc-Config>am</rlc-Config> </srb-ToAddMod> <drb-ToAddMod> <drb-Identity>1</drb-Identity> <qci>9</qci> <pdcp-Config> <discardTimer>ms100</discardTimer> </pdcp-Config> </drb-ToAddMod> </rrcConnectionReconfiguration>在实际项目中，我曾遇到因discardTimer设置过短导致视频卡顿的案例。通过抓包分析发现PDCP层丢包率异常升高，调整该参数后问题解决。这种细节只有在实际信令交互中才能观察到，设备厂商的默认配置并不总是适合所有场景。
