简介《LTE抓包分析指导手册》是一份面向通信网络工程师、优化与运维人员的实战型文档系统讲解LTE UU口、ENB及核心网场景下的数据包捕获与分析方法。手册首先梳理抓包前的准备工作区分测试电脑与安卓手机两种UU口抓包方式前者通常需要安装Wireshark等工具并将网卡设为监听模式后者常需Root权限配合ADB或专用抓包应用同时介绍了ENB侧通过基站维护终端或北向日志、核心网侧通过信令跟踪配置来获取数据的要点。抓包方法部分按UU口、ENB、核心网三个环节给出具体启动与保存流程。数据分析是重点章节不仅演示了基于IP、端口或协议标志的单业务过滤还专门讲解丢包与乱序分析方法包括IO Graphs可视化、Apply as Filter二次筛选以及无线侧BLER与丢包联合定位的思路便于定位空口质量、拥塞和时序异常。资料为单个PDF文件大小1.72MB目录层级分明可快速按需查阅。已有294人学习适合具备一定LTE基础、希望深入掌握抓包排障技能的从业者参考。1. 为什么“速率不达标”要同时抓三个接口的包做 LTE 网络优化的人基本都遇到过这种场景无线环境测试下来 SINR 不错、CQI 也正常但用户下行速率就是到不了预期。光看路测软件已经不够用了因为速率上不去可能压根不是空口的问题而是终端处理能力、传输质量或者核心网侧丢包导致的。这份《LTE 抓包分析指导手册》讲的就是怎么用 Wireshark 在 Uu 口、eNB、核心网三侧同时抓包把数据包从空口走到核心网的每一跳都记录下来。准备工作到位的前提下半天就能定位到具体是哪个网元的问题而不是对着参数瞎猜。适合做 LTE 网优、投诉处理、外场测试的从业者照着复现。2. 抓包前的准备工作选型、ROOT 与静态 IP 三个前置条件三侧联合抓包看着是拿起 Wireshark 就能干的事但真正跑过外场的人都清楚准备工作没做足到了现场就是反复返工。手册把准备工作单独拉了一章而且每个位置给的侧重点都不一样这里拆开讲。2.1 测试电脑选型为什么先看硬盘和 CPU再看软件配置手册里对测试电脑的要求反复强调了两点硬盘读取能力强、CPU 处理能力优。这不是客套话是有实际原因的。Wireshark 抓包时会把网卡收到的所有报文先缓存到内存里再实时做协议解析和界面刷新CPU 弱了界面会一卡一卡地跳停止抓包时要把缓存写盘几十万行数据对应几百 MB 的 pcap 文件硬盘写入慢就直接假死。手册给了一个关键经验值每次录取的行数尽量不超过 80 万行大约是 800M 的数据量。超过这个量级系统反应会变得迟钝严重时甚至无法停止抓包导致文件保存不下来。这里要说明一下80 万行是个参考阈值不是硬性上限取决于测试电脑的配置。我的习惯是保守一点按每段业务 20 到 30 万行就主动 Stop 一次并保存宁可多存几个文件也不要一把梭抓到电脑死机。软件层面有两样东西必装Wireshark 和测试终端驱动比如 MIFI 的驱动。装完驱动后打开 Wireshark 的 Capture Interfaces 对话框确认能找到测试终端对应的 Interface并且浏览器跑流量时能看到 Packets 在跳。这一步很多新手会翻车——界面里看不到终端网卡不是 Wireshark 坏了而是驱动没装或者设备没被系统识别。另外手册在概述里特意提到终端 CPU 处理能力对 RTT 时延的影响这也是选测试终端时要考虑的因素终端处理不过来TCP ACK 就回得慢RTT 抖动大速率自然上不去。外场测试用的手机尽量选 CPU 强一点的型号别拿低端机凑数。2.2 安卓手机的 ROOT 前提与 Shark.apk 启动失败排查Uu 口抓包的另一种方式是安卓手机装 Shark.apk。这里有一个绕不开的前提手机必须 ROOT。手册写得比较直接——安卓系统开发商以及终端厂商禁止用户 ROOT 手机ROOT 后的手机将不再享受三包服务。所以用安卓抓包之前先和终端厂商确认好 ROOT 政策或者干脆准备一台专用的测试机别拿同事的私人手机去 ROOT。Shark.apk 装好后如果无法正常启动最大概率的原因就是终端没有 ROOT。这个判断逻辑很简单Shark 需要通过 root 权限访问网卡接口去抓原始报文权限不够就直接起不来。另外一点容易被忽视安装后不要修改 Parameters 里的内容手册明确要求保持-vv -s 0。-s 0表示 snaplen 设为 0也就是抓取完整的数据包而不做截断如果把这个值改成小字节数抓下来的包只有包头没有载荷后续分析 TCP 数据流时什么都看不出来-vv是让抓包进程输出更详细的日志。这两个参数在多个版本的安卓抓包工具里都是默认行为改了就埋雷。至于用 3 类还是 4 类终端Cat.3 / Cat.4手册说视现场需求而定。Cat.4 终端下行支持到 150MbpsCat.3 是 100Mbps如果测试目标是验证 150Mbps 级别的峰值速率用 Cat.3 终端本身就是瓶颈这个选型在测试方案阶段就要定好。2.3 核心网抓包的前置协调静态 IP 申请与串行测试兜底核心网侧的抓包准备工作手册给的思路很务实。核心网流量大不可能全量抓包必须按测试终端的 IP 做过滤所以第一步是确定测试卡被分配到的 IP 地址。最优做法是提前为测试卡申请静态 IP如果来不及申请手册给了替代方案——先在 Uu 口抓包在不断链的情况下做多次串行测试确认核心网分配给终端的 IP 是否比较固定。如果固定就可以不申请静态 IP每次联合抓包前由 Uu 口先抓一段拿到 IP 后通知核心网侧按这个地址设置过滤。这个协调流程是联合抓包的起点顺序错了后面全乱。实际操作中我一般让 Uu 口先启动抓包跑几十秒业务从 pcap 里直接读出测试终端的 IP然后把过滤条件发给核心网侧同事。核心网侧用的过滤条件就是标准的 BPF 语法示例tcp and host 10.21.3.108这段过滤的意思很直接只抓与 10.21.3.108 这个 IP 相关的 TCP 报文把其它用户流量全部丢掉。如果测试业务集中在某个端口可以继续追加端口条件比如and tcp port 80。注意这里的 IP 一定要用 Uu 口 pcap 里实际看到的地址不要用测试卡资料里登记的号——LTE 核心网分配地址时可能和你预期的不一样以实测为准。核心网抓包的位置也有讲究手册建议至少在近 S1 接口抓包有余力的话再在其它接口同时抓进一步缩小排查范围。S1 接口是 eNB 和核心网之间的边界在这里抓包能区分问题出在空口以下还是核心网以上是联合抓包布局里承上启下的关键位置。3. 三侧抓包方法Uu 口统一协调文件命名匹配是底线准备做完了接下来是具体的抓包操作。手册把三侧的抓包方法分开讲但有一个总体的协调原则抓包工作由 Uu 口统一协调。原因很直观——只有 Uu 口能看到测试终端实际拿到的 IP只有 Uu 口知道业务是从什么时候开始、什么时候结束的所以 Uu 口天然是联合抓包的指挥位。3.1 Wireshark 抓包启动、停止、保存三步与数据量控制测试电脑上 Wireshark 抓包的流程手册写得很细归纳下来就是三步。第一步打开 Capture Interfaces找到测试终端对应的 Interface确认 Packets 在跳后点 Start 启动抓包。第二步测试任务完成后点工具栏上的停止按钮红色方块停止抓包。第三步File → Save As输入文件名并保存。保存这一步有个细节手册用红色标注强调Save As 对话框里的保存范围不要改动保持默认的全量包。有人习惯在显示过滤的状态下直接顺手把 Save As 里的范围改成“仅显示内容”这样保存下来的文件就不是全量数据而是过滤后的子集后面想换一种分析角度就只能重新抓包了。全量保存过滤分析这是抓包数据管理的基本纪律。文件名的规范在第三侧协调里更重要。Ui口每一段测试结束都要及时通知 eNB 侧和核心网侧保存抓包文件并且需要注意文件名的匹配。我的习惯是统一命名格式日期_站点_业务段_接口比如20250115_HZ001_UE1_DL1_UU.pcapUu 口、eNB、核心网三段文件名用同一个业务段标识事后整理时按文件名就能把三份文件对应起来。3.2 Shark.apk 抓包默认参数别手改安卓端用 Shark.apk 抓包操作上比 Wireshark 更简单。启动 Shark点击 Start 就开始记录抓包数据测试完成后点击 Stop抓包文件自动保存到 SD 卡根目录。这里有一个和 Wireshark 不太一样的地方pcap 文件名由软件自动生成无法自定义。所以安卓抓包时更要做好时间记录——几点几分开始、几点几分停止业务段编号记在测试本上后续按时间戳去对应三侧文件。前面说过Parameters 里的-vv -s 0不要动。安卓抓包最容易出的问题就是有人觉得默认参数不够“专业”去改它结果抓下来的包要么只有包头要么抓包进程异常退出。这个参数组合是经过了大量外场验证的保持原样就好。另外 Shark 抓包也需要手机 CPU 撑得住高速下行时 CPU 弱的手机会丢包或者界面卡死选型时注意。3.3 eNB 与核心网抓包协调顺序与保存时机eNB 侧抓包的准备工作手册讲了三个要点确保能进机房、准备一根较长的网线、选一台高配测试电脑。最后一条特别强调——在 eNB 上抓取的报文是整个 CC 单板的也就是说只要这个站点下不止测试用户一个人在跑业务抓到的数据就是全站点所有用户的混合流量数据量会非常大。eNB 侧抓包同样受 80 万行的限制约束抓之前心里要有数抓包时间控制好。核心网侧因为厂家设备差异具体的抓包操作方法没法统一写但无线侧需要配合的工作是明确的协调顺序如下Uu 口先启动抓包跑一小段业务确认测试终端的 IP 地址。Uu 口把 IP 通知核心网侧核心网设置过滤条件后启动抓包。eNB 侧同步启动抓包全量抓包不做 IP 过滤。每一段测试完成Uu 口立即通知 eNB 侧和核心网侧保存文件。三侧文件按约定的命名规范保存业务段编号保持一致。这个顺序里最容易乱的是第 4 步。Uu 口测完一段如果忘记第一时间通知另外两侧保存等业务切到下一段再想起来前面那段就白抓了。我见过不止一次外场因为这个原因返工所以后来强制规定Uu 口侧 Stop 抓包和通知两侧保存之间间隔不能超过十秒。4. 抓包数据分析方法从单线程过滤到丢包乱序定位抓包文件拿到手只是第一步分析才是重头戏。手册这一章写了三个分析方法单个业务线程的过滤、丢包/乱序分析、无线侧 BLER 与丢包的联合分析。这三个方法层层递进从把数据拆开到找异常再到定位异常原因。4.1 单个业务线程过滤IO Graphs 定位 Follow TCP Stream从抓包数据里筛出单次业务线程是所有分析的前提。手册列了两种典型场景。场景一eNB 的抓包数据是整个站点的里面既有测试用户的流量也有普通商用用户的流量需要分离出来。场景二大部分测试是多线程并行进行的比如 Speedtest、FileZilla 这种工具一跑就是好几条 TCP 线程同时下载需要把每条线程的数据传输情况单独梳理。过滤方法手册推荐了一套完整流程。先点 Statistics → IO Graphs观察有效数据的范围。手册给的例子里从 IO Graphs 上红色标注的位置能看到下载业务阶段约有 69000 行。这个步骤的作用是先定位出哪一段是实质性的下载阶段避免把业务建立和释放阶段的零散报文也算进来。定位到下载阶段后选择数据传输过程中的任意一行点击鼠标右键在弹出的菜单里点击 Follow TCP Stream。这一步是 Wireshark 里非常核心的一个功能它会自动按当前行所属 TCP 流的五元组源 IP、源端口、目的 IP、目的端口、协议做过滤把这条线程的完整数据流单独拎出来。之后点 File → Save As可以看到该业务线程占整个抓包文件的情况。手册给的数字很有代表性过滤出的线程有 33434 行整个抓包文件 89780 行。行数对比一眼就能看出来——这次抓包测试不是单线程单线程情况下这两者应该非常接近。注意这里的行数对比不需要严格相等因为 Follow TCP Stream 只保留该流的报文主文件里的 DNS、握手包、其它线程的报文都不会出现在过滤结果里所以后者一定比前者小。差距越大说明并行线程越多或额外流量越多。4.2 双线程业务判断两次 Follow TCP Stream 的对比方法手册在这个例子里继续深入给了一个判断多线程的具体技巧。在 Follow TCP Stream 过滤出的视图里找到一处不连续的 NO.比如第 153 到 196 行之间存在跳号。这说明这条 TCP 流的报文中间被其它线程的报文插入了也就是说主文件里这个时间段内不止一条流在跑。这时候点击界面上的 Clear 按钮回到执行 Follow TCP Stream 之前的状态。Cler 的作用是清掉当前的过滤条件让主文件恢复全量显示。然后选择第 154 到 195 行之间的任意一行再次执行 Follow TCP Stream这次捕捉到的线程有 35882 行。结合两次 Follow TCP Stream 的结果就能下结论这个业务是使用双线程进行下载的。原理很简单——第一次过滤出的某一条流有 33434 行主文件下载阶段 69000 行中间有大量缺口第二次过滤出另一条流有 35882 行这两条流的报文在时间上交替出现所以主文件里的 NO. 会跳号。两条流的行数加起来约 69000 行和 IO Graphs 观察到的下载阶段总量对得上说明没有其它大的流量源就是双线程。这个方法比直接看 IO Graphs 判断并发线程数要准确得多。IO Graphs 只能看到流量有明显的波峰叠加看不出具体有几条 TCP 流在跑而 Follow TCP Stream 是把每条流的报文明细摆出来数都数得清。手册里说这种方法虽然较为繁琐但能够帮助大家更全面地了解 Wireshark 的功能子项确实是这么回事。走一遍这个流程对 TCP 流、五元组、显示过滤这些概念的理解都会深一层。4.3 丢包/乱序分析IO Graphs 与 Apply as Filter 两条路径丢包和乱序是速率问题分析里最常碰到的两种异常手册给了两种分析方法。第一种是用 IO Graphs 可视化。点 Statistics → IO Graphs在 Filter 后面填写丢包和乱序的分析条件然后点 Graph 生成曲线就能看到数据包的下发与丢包/乱序的对比情况。这里要特别提醒的是手册标注的建议由于 LTE 网络速率较高把 Tick interval 从默认值修改为 0.1 秒。默认的 1 秒颗粒度太粗了LTE 峰值速率下一秒钟可能传了好几万个包丢包和重传都集中在几百毫秒内发生1 秒的柱子会把异常平均掉看起来一切正常。改成 0.1 秒才能看到瞬时异常。Filter 里填什么字段手册原文没有给出具体的字段名我这里补充一个常见做法。Wireshark 的专家系统里有两个现成的分析字段一个判断丢包一个判断乱序tcp.analysis.lost_segment tcp.analysis.out-of-order前者标记疑似丢包的报文段后者标记乱序到达的报文。把这两个字段分别填到 IO Graphs 的 Filter 里可以很直观地看到丢包和乱序在哪个时间点集中爆发以及它们和数据下发曲线之间的对应关系。第二种方法是 Apply as Filter。找到任一丢包或乱序的行找到 Wireshark 界面里对应的标注位置点击鼠标右键菜单里点 Apply as Filter → SelectedWireshark 会以当前选中行的特征为条件自动生成过滤表达式把所有同类型的异常行都筛出来。这个方法适合在大文件里先看到一处异常然后全局筛查这种情况是否普遍存在。两种方法的定位不同。IO Graphs 适合看分布——异常是分散的还是集中的持续多久Apply as Filter 适合看明细——异常行的具体序列号、时间戳、涉及哪些 IP。我的习惯是两个配合用先 IO Graphs 看整体轮廓再 Apply as Filter 把异常行拉出来逐一核对。4.4 无线侧 BLER 与丢包联合分析Uu 口抓包的同时为了核实丢包是否和无线丢块有关手册给出的方法是同时使用 DT 软件抓取 LOG 做联合分析。DT 软件就是外场常用的路测软件可以记录无线侧的 BLER、SINR、MCS 等空口指标Wireshark 记录的则是 TCP/IP 层的丢包和重传。两者结合才能判断丢包到底是空口丢块导致的还是传输或核心网侧的问题。分析逻辑其实很朴素把 DT 软件里 BLER 恶化的时间段和 Wireshark 里丢包集中的时间段对齐看它们是否吻合。手册给的例子里DT 软件 BLER 分析显示无线侧没有明显问题Wireshark 里的丢包发生在 BLER 正常的时段结论就是这次丢包不是由无线丢块导致的。这里要强调时间对齐的准确性DT LOG 和 Wireshark 抓包可能用的是不同的时钟源分析前先把两个文件的时间基准校准否则容易出现错位误判。比较稳妥的做法是抓包电脑和 DT 软件用同一台电脑或者抓包前先统一对时。BLER 这个指标在外场容易被误读。BLER 高不等于一定丢包因为无线侧有 HARQ 重传机制第一次传输失败后可能通过快速重传补回来用户面根本感知不到反过来BLER 正常但 TCP 层持续丢包大概率是传输网络或者核心网侧的故障。带着 BLER 去看 Wireshark能少走很多弯路。5. 常见问题与避坑记录从数据采不到到乱序误判三侧联合抓包这套流程我在外场跑过很多轮也见过各种稀奇古怪的翻车方式。这里把高频问题按采集侧和分析侧分开整理每条都说清楚现象、原因和解决办法。5.1 采集侧文件保存失败、Shark 闪退与网卡不识别问题一停止抓包后 Wireshark 长时间无响应保存对话框一直不出来。现象是抓包过程中电脑明显变慢点击 Stop 后界面卡死等几分钟还是没有反应。原因是抓包文件行数超过了电脑的处理能力接近或超过 80 万行的上限Wireshark 在把大量缓存数据写入磁盘时撑不住了。解决方法是抓包前按业务段规划好停止点每段控制在 20 到 30 万行就主动保存不要一段业务从头录到尾同时外场备一台 CPU 和硬盘性能更好的电脑作为备用抓包机。问题二Shark.apk 点击后闪退或者一直停在启动界面。现象是应用装好了但点击没有任何反应或者启动页卡住不动。原因是终端没有 ROOTShark 拿不到抓包所需的系统权限起不来。解决办法是先确认手机 ROOT 状态换一台已 ROOT 的测试机如果现场确实没有 ROOT 机就改用测试电脑加 MIFI 的方案做 Uu 口抓包。另外牢记 ROOT 后手机不再享受三包服务用之前和终端厂商确认政策避免后续扯皮。问题三Capture Interfaces 里找不到测试终端的网卡。现象是 Wireshark 的接口列表里只有以太网卡和无线网卡没有 MIFI 对应的 Interface。原因是测试终端的驱动没有安装或者设备连接后没有被操作系统正确识别。解决方法是先装好驱动确认电脑网络连接成功然后重新打开 Capture Interfaces 对话框正常情况下应该能看到新增的 Interface。判断是否可用的办法是浏览网页看该 Interface 的 Packets 计数是否在增长。问题四eNB 抓包文件大得离谱电脑完全带不动。现象是抓了不到十分钟文件行数已经几十万行打开文件和分析操作都变得非常慢。原因是 eNB 上抓的是整个 CC 单板的流量站点下所有商用用户的业务都混在里面除非测试时恰好没有其它用户否则数据量一定爆炸。解决方法是抓包前和现场确认站点负载情况尽量选业务低峰期测试抓包完成后第一时间按测试用户 IP 做过滤把副本单独保存出来再分析原始大文件归档不动。5.2 分析侧乱序误判、时间段对不上与双线程误判问题五把乱序当丢包结论下偏了。现象是看到 Wireshark 里有大量重传标记和乱序标记直接得出“网络丢包严重”的结论。原因是 LTE 高带宽场景下 TCP 乱序其实挺常见多路径传输或者中间设备缓存抖动都可能导致报文顺序变化但乱序不等于丢包丢了包才需要重传。解决方法是把tcp.analysis.lost_segment和tcp.analysis.out-of-order分开过滤单独看只有确认序列号缺失且伴随重传才能定性丢包同时结合 IO Graphs 看异常时间分布别被单一条目带偏。问题六三侧抓包文件时间对不上没法联合分析。现象是 Uu 口、eNB、核心网三个文件的行数和趋势都对不太上同一段业务在不同文件里出现的时间点差了几秒甚至几十秒。原因是三台抓包设备的时钟没有统一而且各侧保存文件的时机不同步。解决方法是抓包前先把所有设备的时间校准到同一个时间源抓包过程中由 Uu 口统一协调每段业务结束时立即通知另外两侧保存文件文件名带上业务段编号。时间基准统一三侧文件才能像拼图一样对得上。问题七Follow TCP Stream 看到 NO. 不连续直接判定丢包。现象是过滤出的 TCP 流里序号有明显跳号以为这段传输丢了大量报文。原因是没有先确认业务是否多线程多线程并行下载时主文件里各条线程的报文是交替排列的Follow TCP Stream 过滤后看到的 NO. 缺口可能只是其它线程的报文插了进来不是真正的序列号丢失。解决方法是先按第 4 章的方法做两次 Follow TCP Stream 对比判断业务是否是多线程确认单线程后再结合tcp.analysis.lost_segment看丢包避免误判。6. 让三份 pcap 对上话问题归属判断与验证技巧联合抓包分析最后一步是把三侧文件放到一起做归属判断。我从手册的方法里提炼了一个简单的问题归属表外场可以直接对照着看现象问题归属下一步动作Uu 口丢包且同一时段 BLER 高无线侧查覆盖、干扰、调度参数整改后复测Uu 口丢包但 BLER 正常传输或核心网侧核对核心网侧 pcap 是否同样丢包Uu 口正常但核心网侧有重传S1 接口或核心网检查 S1 传输质量与核心网处理能力Uu 口乱序但无丢包传输路径或终端查中间设备缓存换高 CPU 终端对比判断顺序我习惯固定成三步先对时间再对 IP最后对趋势。时间对齐确认三份文件描述的是同一段业务IP 对齐确认过滤条件没有抓错用户趋势对齐是看 IO Graphs 里数据下发曲线的形状是否吻合——核心网发得出、eNB 进得来、Uu 口收不全问题就在空口或终端Uu 口收得到但速率上不去再看 RTT 和重传是不是终端 CPU 拖了后腿。实际验证时还有一个好用的技巧以 Uu 口文件为基准把下载阶段的行数和吞吐画出来然后在 eNB 文件和核心网文件里分别统计同一时段的流量三个数字对比差在哪一跳一目了然。这个方法不依赖高级工具纯手工也能算但对理解端到端路径非常有帮助。从那以后我每次做三侧联合抓包都强制自己先走一遍这套规矩Uu 口统一协调、每段结束三侧同步保存、文件名带业务段编号、分析前先看 BLER 再看丢包、最后按归属表下结论。这套流程虽然土但能帮我在半天时间内把“无线环境良好但速率不达标”的问题定位到具体网元。希望帮到你。本文还有配套的精品资源点击获取