简介这份《LTE抓包分析指导手册》是一份面向通信工程师、网络优化与维护人员的实操型PDF文档覆盖LTE网络中UU口、eNodeB及核心网三大环节的抓包准备与操作流程并针对抓包后的数据过滤、丢包乱序分析、无线侧BLER与丢包联合分析等关键场景给出具体方法适合从事4G网络故障排查、性能优化的初中级技术人员。资源包为单个PDF文件大小仅1.72MB便于下载阅读已有293人学习。手册从测试电脑与安卓手机两种方式讲解UU口抓包包含Wireshark与Shark.apk工具用法、ENB端抓包准备、核心网抓包方法以及IO Graphs、Apply as Filter等实用分析技巧能帮助读者快速掌握从抓包到定位问题的完整思路是一份接地气的实战参考资料。1. LTE 抓包分析是什么为什么它比看统计更接近真相终端显示的 RSRP 是 -85dBmSINR 是 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 接口镜像、以及路测软件的空中接口日志它们看到的协议层不一样适用场景也不一样。数据来源可看到的协议层常用工具典型定位场景终端诊断口日志RRC、NAS、MAC、RLC、PDCPQCAT Wireshark外场测试中的接入失败、切换失败、吞吐异常S1-MME/S1-U 接口镜像S1AP、NAS 透传、GTP-UWireshark 镜像口鉴权失败、附着流程被核心网拒绝路测软件空中接口数据PHY 测量量、部分 RRC鼎利 / Pioneer / QXDM覆盖空洞、干扰、邻区配置错误从这张表可以看出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基站回 RRCConnectionSetupUE 再回 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 指标很难发现。再看切换类问题过滤 MeasurementReporttshark -r lte_export.pcap -Y rrc-lte.rrc_MeasurementReport -T fields -e rrc-lte.measResultEUTRA结合测量配置里的 EARFCN、事件类型 A2/A3/A4 和上报周期能判断是测量控制漏配、异频频点错误还是邻区关系缺失。外场测试里这类问题高发MeasurementReport 的保留时长和上报间隔也直接反映终端测量行为是否符合预期。3.3 抓包时长与日志大小外场实测的采样原则诊断口日志记录的内容是事件驱动的业务类型不同日志大小差异很大。以下是我在多种终端上实测后得到的经验值不同平台会有浮动但数量级可供参考业务场景诊断口日志速率建议单次抓包时长信令事件类驻留、呼叫建立2~5 MB/min10~15 min吞吐与调度类FTP 下行测试10~30 MB/min5~10 min小包业务VoLTE、即时消息3~8 MB/min10~20 min如果日志文件过大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 Request0x42 是 Attach Accept0x43 是 Attach Complete0x44 是 Attach Reject。如果看到大量 0x41 和 0x42却很少见 0x43说明终端收到网络接纳响应后后续的默认承载激活流程没有走完此时要到 RRC 层看是否有 PDN Connectivity 相关信令再决定排查方向。RRC 层过滤主要配合流程使用常用的字段包括rrc-lte.rrc_ConnectionRequestRRC 连接请求rrc-lte.rrc_ConnectionSetupRRC 连接建立rrc-lte.rrc_ConnectionSetupCompleteRRC 连接建立完成rrc-lte.rrc_ConnectionReleaseRRC 连接释放rrc-lte.rrc_MeasurementReport测量报告这些字段在 Wireshark 的显示过滤表达式里可以直接输入不需要记枚举数字。实际分析时更建议先用 Wireshark 的 Filter Expression 按钮找到字段后再从枚举值列表里选择避免手滑打错字段名导致零结果。4.2 MAC 层调度参数的读法看清速率为什么上不去业务速率异常时转到 MAC 层。显示过滤器输入mac-lte后Packet Details 里重点读几个参数字段含义判读方向mac-lte.ueidUE 标识多 UE 同抓包时用来分用户mac-lte.rb_size本次调度的资源块大小数值突然变小说明调度受限mac-lte.harq_idHARQ 进程号持续占用同一进程说明重传频繁mac-lte.dl_harq_feedback下行 HARQ 反馈NACK 比例高空口解调质量差判断 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 确认Band下行频段MHzEARFCN 范围下行12110 - 21700 - 59931805 - 18801200 - 1949382570 - 262037750 - 38249402300 - 240038650 - 39649412496 - 269039650 - 41589把抓包里的 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 逐包翻。核心思路只有一条现场问题的优先级永远高于语法字段手册存在的意义就是让你下次少花五分钟去猜字段名。本文还有配套的精品资源点击获取