企业官网建设流程全解析

简介：这份《LTE抓包分析指导手册》是一份面向通信工程师、网络优化与维护人员的实操型PDF文档，覆盖LTE网络中UU口、eNodeB及核心网三大环节的抓包准备与操作流程，并针对抓包后的数据过滤、丢包乱序分析、无线侧BLER与丢包联合分析等关键场景给出具体方法，适合从事4G网络故障排查、性能优化的初中级技术人员。资源包为单个PDF文件，大小仅1.72MB，便于下载阅读，已有293人学习。手册从测试电脑与安卓手机两种方式讲解UU口抓包，包含Wireshark与Shark.apk工具用法、ENB端抓包准备、核心网抓包方法，以及IO Graphs、Apply as Filter等实用分析技巧，能帮助读者快速掌握从抓包到定位问题的完整思路，是一份接地气的实战参考资料。

1. LTE 抓包分析是什么，为什么它比看统计更接近真相

终端显示的 RSRP 是 -85dBm，SINR 是 18dB，从网管指标看信道质量很好，实际速率却掉到几百 kbps。翻统计、查终端 Log，只能得到"结果异常"四个字，很难定位是调度问题、重传问题还是 RRC 流程卡在某个环节。抓包分析是把结论从"指标"拉回"逐帧对话"的手段：从终端的空中接口日志读 RRC 和 NAS 信令，从 MAC 层看调度与重传，必要时再到 S1 接口看核心网侧的交互。这本手册的实操路径，是把"拿到日志文件→导出 pcap→过滤协议字段→对齐时间与结论"切成四段逐一展开，适配外场测试工程师、协议栈开发、无线网络优化以及 CPE 或 LTE 无线路由器类设备的联调人员。新手能照着步骤跑通一条完整流程，熟手可以直接翻到信令过滤与频段判读部分。

2. 抓什么：LTE 各接口与抓包数据的三种来源

2.1 控制面与用户面：抓包前先想清楚这一帧走哪条路

LTE 协议栈的分层决定了抓包分析"能看见什么"。空口上分为 PHY、MAC、RLC、PDCP、RRC、NAS 六层，RRC 和 NAS 属于控制面，承载信令；业务数据经 DRB 承载，在 PDCP 层做头压缩和加密之后才交给 RLC、MAC 发送。抓包时，控制面信令有完整的 ASN.1 语法定义，Wireshark 能逐字段解析；用户面的 IP 包经过加密和压缩，在 pcap 里往往只剩下密文，无法直接还原 HTTP 请求或 VoIP 报文。因此在外场测试里，抓包的优先目标是控制面流程，用户面质量问题更多靠 MAC 调度统计来反推。

实际抓包中，需要先明确数据源。最常见的三种来源是终端诊断口日志、S1 接口镜像、以及路测软件的空中接口日志，它们看到的协议层不一样，适用场景也不一样。

从这张表可以看出，Wireshark 抓包以及分析在不同的上游数据源里承担不同职责：终端侧日志用于解释终端行为，S1 接口用于解释网络行为，两者必须结合流程时序一起看才能逼近真相，而不是只拿着某一侧数据下结论。

2.2 终端侧日志与 Wireshark 可视化的关键在 Uu 接口

实践中，外场问题大多靠 Uu 接口日志定位。获取成本低是它最大的优势：一台手机或模组开启诊断端口，用 USB 连接笔记本，QCAT 这类工具就能记录 Modem 和 LTE 协议栈的内部事件。诊断口日志通常在终端硬件内部就完成了协议层收包，不会因为网络环境或传输链路抖动丢失关键信令。另一个优势是时间戳精度高，事件顺序就是协议栈真实处理顺序，Wireshark 画出的分组列表可以直接当时间线使用。

缺点是原始数据格式不开放。QCAT 的核心功能之一是"翻译"日志，把厂商私有的二进制数据转换成标准 pcap。转换时建议把 MAC-LTE、RLC-LTE、PDCP-LTE、RRC-LTE、NAS-EPS 五层全部选上，不要只勾"信令层"。转换完后在 Wireshark 里过滤时，如果发现只有 RRC 没有 NAS，多数是导出时漏掉了 NAS-EPS 层；反过来，把整个诊断日志不分层全部导出，Wireshark 里会出现大量无法识别的未知协议，反而增加筛选成本。转换不是越全越好，够用即可。

2.3 S1 接口镜像抓包：适合定位核心网侧流程

控制面 S1AP 承载在 SCTP 之上，默认端口 36412；用户面 GTP-U 承载在 UDP 之上。在 S1-MME 链路汇聚交换机上配置镜像口，从镜像口接出的流量进入 Wireshark 后能直接解码 S1AP。这个方法的最大价值在于：S1AP 消息里携带的 NAS-PDU 是透传的，当终端侧 NAS 因为加密不可读时，S1 侧能看到明文，特别适合定位鉴权失败、附着流程被核心网拒绝这类问题。对 CPE、无线路由器等形态的终端，S1 侧抓包也能绕过终端厂商日志不开放的限制。

抓包前先与核心网同事确认 S1 链路位置和业务是否经过该节点，避免抓错物理链路。用以下命令快速确认 pcap 里 S1AP 流程数量：

tshark -r s1iface.pcap -Y "s1ap" -T fields -e frame.time_relative -e s1ap.ProcedureCode | head -40

这条命令把每条 S1AP 消息的帧相对时间和过程码字段打印出来，按过程码归组，就能看出控制面流程集中在哪一类。ProcedureCode 的枚举含义可以在 Wireshark 图形界面点开任意一条 s1ap 消息查看，例如 UEContextReleaseRequest、InitialContextSetup 等，不需要死记数字。

2.4 抓包前把时间和锚点先定好

抓包分析有个容易被忽略的前置动作——确定时间锚点。终端日志、测试软件、网管统计三套时间系统往往不同步，慢几秒或快几秒都正常。外场测试前约定一个统一动作：测试开始时把终端切一次飞行模式，或者在测试软件里打个事件标记，记为 T0。分析时先找到 T0 对应的包，再把 Wireshark 时间显示切换为 Seconds Since Beginning，后面所有分析都在同一时间基准上进行。以上四种数据源和处理思路，构成了后续转换与分析的基础，下一章从具体工具操作开始落地。

3. 从空口日志到可分析的 pcap：外场日志的转换与打开

3.1 用 QCAT 把 modem 日志转成 Wireshark 能打开的 pcap

上一章提到的不开源日志格式，在大多数高通平台终端上表现为 .qmdl 或 .dbl 文件。QCAT 打开后，工具会自动解析出一份"Log Packet"列表和协议树；要让 Wireshark 打开，必须先做一次格式转换，而不是直接在 Wireshark 里打开原始日志。QCAT 的导出入口通常位于 File 菜单下的 Export / Export to Wireshark。导出对话框里，重点是勾选协议层范围：MAC-LTE、RLC-LTE、PDCP-LTE、RRC-LTE、NAS-EPS 五层全选；如果日志里含有 PDCP 密钥且调试环境允许暴露，再勾选解密选项，导出的 pcap 就能直接显示明文 NAS。

导出后建议先用 capinfos 对 pcap 做一次快速体检：

capinfos lte_export.pcap

重点看三项输出：Packet count、Duration、Data rate。Packet count 为零但文件有大小，说明导出的层级选错；Duration 明显短于实际测试时长，说明日志记录过程中存在断点，后续分析要避开断点区间，否则会把"日志缺失"误判成"长时间无信令"。文件里出现大量 Malformed Packet 时，优先怀疑导出的协议层与实际抓包层不匹配，而不是工具坏了。

3.2 外场路测数据的读取：定位"有信号却上不了网"

外场测试中最多的报告是"有信号、上不了网"。用 Wireshark 打开 pcap 后，先按时间线找 RRC 状态迁移：UE 从 IDLE 发起业务，先发 RRCConnectionRequest，基站回 RRCConnectionSetup，UE 再回 RRCConnectionSetupComplete，随后 NAS 层才继续承载 Service Request。任何一段缺失都能指出方向：没有 RRC Setup Request，是上行覆盖或随机接入问题；有 Request 没有 Setup，是下行覆盖或 eNodeB 准入问题；Setup 完成但 NAS 无后续，方向转向核心网或传输链路。

tshark -r lte_export.pcap -Y "rrc-lte.rrc_ConnectionRequest" -T fields -e frame.number -e rrc-lte.establishmentCause

这条命令把每条 RRCConnectionRequest 的帧号和 establishmentCause 打出来。establishmentCause 常见取值有 mo-Data、mt-Access、emergency、mo-VoiceCall，通过这个字段可以判断终端发起会话的意图与网络接纳策略是否冲突。例如出现大量 mt-Access 被 RRC Reject，多半是寻呼与接入拥塞联合造成的问题，单看 RSRP 指标很难发现。

再看切换类问题，过滤 MeasurementReport：

tshark -r lte_export.pcap -Y "rrc-lte.rrc_MeasurementReport" -T fields -e rrc-lte.measResultEUTRA

结合测量配置里的 EARFCN、事件类型 A2/A3/A4 和上报周期，能判断是测量控制漏配、异频频点错误，还是邻区关系缺失。外场测试里这类问题高发，MeasurementReport 的保留时长和上报间隔也直接反映终端测量行为是否符合预期。

3.3 抓包时长与日志大小：外场实测的采样原则

诊断口日志记录的内容是事件驱动的，业务类型不同，日志大小差异很大。以下是我在多种终端上实测后得到的经验值，不同平台会有浮动，但数量级可供参考：

如果日志文件过大，QCAT 支持按测试软件的事件标记分段导出，保留标记前后各 1 分钟即可。抓包分析的目的不是让日志越长越好，而是让每个标记区间对应一个待验证的假设。吞吐测试想确认上下行调度，就多留 MAC 和 RLC 层；信令流程验证，则把 RRC 和 NAS 层保留完整，其他层可以精简。

4. Wireshark 抓包分析 LTE 信令的三组过滤与参数

4.1 NAS 与 RRC 过滤：快速筛出关键信令流程

打开 pcap 后第一件事，是确认有没有 NAS 消息。显示过滤器直接输入nas-eps，如果一条都没有，回第 3 章检查导出层级；如果有，按消息类型做一次分布统计，能快速判断 Attach 流程卡在哪一步：

tshark -r lte_export.pcap -Y "nas-eps" -T fields -e nas-eps.msg_type | sort | uniq -c | sort -rn

统计结果的行数在 20 种之内。0x41 对应 Attach Request，0x42 是 Attach Accept，0x43 是 Attach Complete，0x44 是 Attach Reject。如果看到大量 0x41 和 0x42，却很少见 0x43，说明终端收到网络接纳响应后，后续的默认承载激活流程没有走完，此时要到 RRC 层看是否有 PDN Connectivity 相关信令，再决定排查方向。

RRC 层过滤主要配合流程使用，常用的字段包括：

• rrc-lte.rrc_ConnectionRequest：RRC 连接请求
• rrc-lte.rrc_ConnectionSetup：RRC 连接建立
• rrc-lte.rrc_ConnectionSetupComplete：RRC 连接建立完成
• rrc-lte.rrc_ConnectionRelease：RRC 连接释放
• rrc-lte.rrc_MeasurementReport：测量报告

这些字段在 Wireshark 的显示过滤表达式里可以直接输入，不需要记枚举数字。实际分析时更建议先用 Wireshark 的 Filter Expression 按钮，找到字段后再从枚举值列表里选择，避免手滑打错字段名导致零结果。

4.2 MAC 层调度参数的读法：看清速率为什么上不去

业务速率异常时转到 MAC 层。显示过滤器输入mac-lte后，Packet Details 里重点读几个参数：

判断 HARQ 重传占比可以按进程统计：

tshark -r lte_export.pcap -Y "mac-lte" -T fields -e mac-lte.harq_id -e mac-lte.dl_harq_feedback | awk '{print $2}' | sort | uniq -c

输出里 ACK 和 NACK 的计数对比，直接影响后续判断。Wireshark 的频率分布视图也可以看，但命令行更适合批量处理多个 pcap。进一步看调度分布，使用 Statistics → LTE → MAC Statistics，按子帧画出 DL/UL grant 和重传分布。如果看到子帧序列中 grant 周期性消失，方向指向 TDD 上下行配比或 eNodeB 调度器限制，而不是单纯弱覆盖。只有当 RSRP、SINR 同时很差且 HARQ 重传率很高时，才能放心把问题归因到空口质量，否则继续往调度器配置和传输侧排查。

4.3 从 EARFCN 看 lte band：频点信息的实际判读

另一类高频问题是"指标不错但 band 不对"。在 Wireshark 里找到 RRCConnectionSetup 或 RRCConnectionReconfiguration，展开 measConfig → measObjectToAddModList → MeasObjectEUTRA，里面的 dl-CarrierFreq 就是 EARFCN。通过 EARFCN 可以查表直接推算 band，也可以结合 SIB1 里的 freqBandIndicator 确认：

把抓包里的 EARFCN 与规划的 band 对照，能识别两类问题：终端占用了异频频点，或者站上配置的 band 与设备能力不匹配。lte band 判读这一步在外场测试里几乎是"最后一锤"：频率看错了，后面的优化动作全部白做。批量提取 EARFCN 可以用：

tshark -r lte_export.pcap -Y "rrc-lte" -T fields -e rrc-lte.measObjectEUTRA.dl_CarrierFreq | sort -u

注意：不同 Wireshark 版本对嵌套字段名有差异，如果这条命令输出为空，先在 GUI 里点开一个 RRC 包，在 Details 面板里复制实际字段名再替换。不要凭记忆敲字段，这是抓包分析里最常见的时间浪费。

4.4 排查 NAS 加密后的消息不可读现象

外场调试中经常碰到一种情况：Attach 完成之后的所有 NAS 消息在 Wireshark 里显示为 Undecoded 或只有长度没有内容。这是正常的，LTE 空口在 AS 安全激活后会对 NAS 消息做加密和完整性保护，终端诊断日志如果没有记录密钥，Wireshark 就解析不出正文。此时不要怀疑工具出了问题，更不要花几个小时查"解密配置"。优先做两步：第一步回退到 RRC 层，看 RRCConnectionReconfiguration 何时下发、UE 是否回复完成，流程完整性靠 RRC 判断；第二步找 S1 接口镜像包，S1 侧 NAS-PDU 是透传的，可以直接读取明文格式的 NAS 内容。两相对照，即可绕过加密障碍，还原完整信令流程。

5. 验证与排错技巧：时间对齐、加密状态与快速判读

5.1 时间对齐：把空口事件和网络侧统计拼到一张图

外场测试的原始日志里，终端时间来自 GPS 或网络授时，测试软件是 PC 时间，网管平台又是服务器时间，三个时间源不对齐，做相关性分析毫无意义。T0 锚点法最实用：终端开机后第一次 Attach 完成的时间记为 T0，测试软件和网管查询里都记录同一时刻。Wireshark 里把时间显示格式切成 Seconds Since Beginning，后续所有秒值都相对 T0 对齐。对齐后，把 MAC 调度分布和网管导出的上行干扰统计画在同一张坐标图上，看异常时间段是否重合。比如 MAC 层出现连续空子帧的时间点，恰好对应网管里干扰抬升的时间窗，问题基本可以锁定在干扰而非终端。

5.2 加密与完整性保护的判断：NAS 消息为什么解不开

Wireshark 中某个 NAS 消息显示为 plain NAS，或者 payload 只有长度没有内容，大概率是加密后的数据。LTE 空口在 AS 安全激活后对 NAS 和用户面做加密（EEA）和完整性保护（EIA），如果抓包日志没有记录密钥，Wireshark 只能保留消息头里的类型字段。判断流程是否正常，不依赖 NAS 明文也能完成：看 RRC 层的 SecurityModeCommand、SecurityModeComplete 是否成对出现，再看后续 RRCConnectionReconfiguration 是否正常完成。这两个点只要对了，NAS 正文即使不可读，流程主路径也没有断。Wireshark 的 Preferences → Protocols → LTE RRC 里可以配置密钥，但外场并非总能拿到合法密钥，优先选择 S1 接口对照，比死磕解密高效得多。

5.3 存一个自己的 LTE 抓包分析过滤按钮

每次在 Wireshark 里手工输入一大串显示过滤条件并不高效，尤其在外场测试时，环境嘈杂、时间紧张。建议把常用的过滤条件保存为 Filter Expression Button，用时一键切换：

frame.protocols contains "nas-eps" || frame.protocols contains "rrc-lte"

这行过滤把控制面信令全部保留，去掉 MAC 调度噪声。另一个值得养成习惯的动作是记录"三件套"：当时用的 tshark 命令、Wireshark 过滤条件、判定结论。每处理完一类问题，把这三项记在一个 Markdown 文件里。下次遇到同一类故障，直接复制命令批量跑完再人工复核，不需要重新打开原始 pcap 逐包翻。核心思路只有一条：现场问题的优先级永远高于语法字段，手册存在的意义，就是让你下次少花五分钟去猜字段名。

本文还有配套的精品资源，点击获取