LTE下行速率不达预期？Uu口、eNB与核心网三层联合抓包定位法

简介这是《LTE抓包分析指导手册》PDF文档面向通信网络优化、运维与测试工程师用于指导LTE网络中的UU口、ENB及核心网抓包准备工作与操作流程并给出数据分析与故障排查思路适合需要系统学习LTE信令和数据面抓包的初中级从业者。文档为单个PDF文件大小约1.72MB内容按概述、抓包前准备、抓包方法、数据分析四大模块组织结构清晰。手册详细介绍了UU口抓包中测试电脑与安卓系统手机两种操作方式并说明各自的前置条件与注意事项ENB侧和核心网侧的抓包准备与实施步骤也有专门讲解。数据分析部分重点涵盖单个业务线程的过滤方法、丢包与乱序分析工具IO GRAPHS、Apply as Filter的使用以及无线侧BLER与丢包联合分析方法可帮助读者定位空口与传输问题。目前已有293人学习该文档对从事LTE网络维护、优化与故障排查的专业人员是一份实用的参考文档。1. LTE速率不达预期时Uu口、eNB与核心网三层联合抓包才是正解外场测试最让人头疼的不是SINR差而是RSRP和SINR都很好、CQI还满格下行吞吐就是上不去。这时候如果手里只有路测软件和小区统计基本就是在猜。真正能把排查范围从“全网”缩到“某一个网元”的办法是同时在Uu口、eNB和核心网近S1接口抓包再把三份pcap按同一段业务做时间对齐看数据到底是在无线侧丢块还是在基站处理时乱序或者是核心网侧压根没送过来。这篇内容按一线工程师的实际操作流程展开读者对象是网优工程师、外场测试人员和核心网接口调测的人。准备工作到位的前提下半个工作日就能给出定位结论。2. 抓包前置检查终端ROOT、抓包容量上限与S1接口静态IP策略抓包这件事七成功夫在准备。Uu口、eNB、核心网三侧的接入方式完全不同前置条件的侧重点也不一样。下面按三侧分别展开。2.1 Uu口抓包的两种载体怎么选Uu口的抓包载体有两种测试电脑加Wireshark、安卓手机加Shark.apk。选型的逻辑很简单电脑方案控制力强能精确管理抓包文件的大小和保存路径手机方案部署快适合路测场景但前提是终端必须ROOT。需要特别提醒ROOT后的手机不再享受三包服务这个风险要在测试开始前和终端提供方确认清楚。测试电脑的选型有两个硬指标硬盘读取能力和CPU处理能力。LTE下行高速率时抓包文件的写入速度会直接决定能连续跑多久。手册里的建议是单次抓包不超过80万行大约对应800MB的数据量。超过这个量级电脑可能出现系统反应迟钝甚至无法停止抓包、无法保存的情况。这不是一个绝对阈值实际取决于电脑的磁盘写入速度和Wireshark渲染性能但在外场准备时按这个量级做测试计划是稳妥的。安卓方案的参数约束比电脑方案更严格。Shark.apk启动后Parameters里的内容不要改保持默认的-vv -s 0。这里的-s 0表示抓取完整数据包、不做截断对LTE这种大包长、高吞吐的场景很关键如果改成默认的96字节甚至更小TCP载荷被截掉后续分析丢包、乱序和重传时基本无据可查。2.2 eNB侧抓包前要确认的两个边界全量流量与抓包容量上限eNB侧抓包要在基站机房完成前置条件包括能进机房、准备一根较长的网线。还有一个容易被忽略的点eNB上抓取的是整个CC单板的报文不只是测试用户的数据。也就是说如果该站点下同时有其他商用用户跑业务抓包文件里会混入大量非测试流量数据量级远大于Uu口单用户抓包。这对分析阶段提出了一个要求必须能用过滤条件把测试用户的流量从全量报文中分离出来。常见的做法是用测试卡的IP地址作为过滤基准在抓包阶段就加上BPF过滤减少无用数据写入。我一般在eNB侧或核心网侧会用这样的命令tcpdump -i eth0 -s 0 -w /data/enb_lte_capture.pcap \ host 192.168.1.100 and (tcp or udp)这条命令的作用是在抓包阶段就把非目标IP的报文过滤掉-s 0表示抓完整包不截断-w指定输出文件名host 192.168.1.100按照测试卡的IP过滤(tcp or udp)排除ARP、ICMP等控制面的干扰报文。如果测试是纯下行FTP或者Speedtest还可以进一步限制端口范围来缩小文件体量。需要留意这个过滤一般在核心网侧或分流设备上做eNB侧如果是镜像口抓包通常拿不到这种定制过滤能力那就只能靠抓完后用Wireshark做显示过滤。2.3 核心网抓包的IP固定策略静态IP优先串行测试兜底核心网抓包的位置建议在近S1接口这个位置能同时看到S1-U用户面数据和S1-MME控制面信令。如果条件允许可以在其他接口也做镜像抓包用来进一步缩小排查范围。核心网侧的准备工作里最容易踩坑的是测试卡的IP地址不固定。手册里给了一个很实际的解决方案测试前为测试卡申请静态IP。如果来不及申请就在Uu口先抓包在不间断业务的情况下做多次串行测试观察核心网为终端分配的IP是否比较固定。如果比较固定可以不用静态IP但每次联合抓包前必须由Uu口先抓到测试卡的实际IP再把这个IP通知核心网侧做过滤设置。这个动作的顺序不能乱否则核心网侧过滤条件一错整轮测试全部白抓。抓包位置前置条件流量特征常见问题Uu口电脑Wireshark终端驱动、CPU/硬盘较强单用户体量可控超过80万行后卡死无法保存Uu口安卓Shark.apk终端已ROOT单用户文件名自动生成未ROOT时软件无法启动eNB侧机房权限、长网线整个CC板全量流量混入商用用户流量、文件过大核心网近S1接口测试卡IP固定或可确认多用户、多接口混合过滤条件错误导致数据无效3. 三侧抓包执行Wireshark、Shark.apk与抓包文件命名同步抓包执行阶段三侧不是各抓各的而是由Uu口统一协调节奏。Uu口获取测试卡IP后通知核心网侧设置过滤Uu口每完成一段测试立刻通知eNB侧和核心网侧保存抓包文件。一个细节是文件名要匹配例如同一段测试在三侧的文件名必须包含相同的时间戳和测试序号否则后续做时间对齐时非常痛苦。3.1 测试电脑上Wireshark的启动、停止和保存用测试电脑抓包时启动路径是Wireshark菜单-Capture-Interfaces在弹出的对话框里找到测试终端对应的Interface点击Start开始抓包。这里有个前置检查在浏览网页的情况下Packet列表应该有明显跳动如果没有说明终端驱动没被Wireshark识别到或者选错了网卡。测试完成后点红色停止按键结束抓包然后通过File-Save As保存文件。保存时注意不要修改默认的文件格式保持pcap格式后续用Wireshark命令行工具或新版软件打开都没问题。实际操作中我见过不少人把文件存成pcapng后又拿到老版本的抓包分析工具里打不开的情况。LTE高速率场景下抓包文件原本就大格式兼容性问题会浪费大量时间。3.2 安卓终端Shark.apk的参数约束与文件保存路径安卓手机方案中Shark.apk启动后直接点击Start就开始记录抓包文件以.pcap结尾文件名由软件自动生成不能自定义。停止后文件自动保存到SD卡根目录。这里有一个在外场经常遇到的问题SD卡容量的预估。如果测试任务较多建议每完成一段测试就立刻把pcap文件转移到测试电脑或U盘里避免SD卡写满导致后续数据丢失。Shark.apk内部封装的还是tcpdump那套逻辑-vv参数输出详细协议信息-s 0抓全包。这两个参数不要改特别是有新人加入测试队伍时要提前强调这一点。另外若安装后无法正常启动九成是因为终端没有ROOT换一台已ROOT的终端即可不需要在应用层面花时间排查。3.3 联合抓包的现场口令先报IP、逐段保存、文件名对应三层联合抓包能协同起来核心是两个口令级别的约定。第一Uu口先抓拿到测试卡IP后立刻通知核心网侧。核心网侧按这个IP配置过滤条件后开始抓包。如果核心网侧过滤设置晚于Uu口那么起始时间对不齐分析时无法判断丢包发生在哪一段。第二每一段测试结束后Uu口统一通知两侧保存文件文件名遵循统一规则。我常用的命名格式是uu_20240511_SiteA_DL_Round03.pcap enb_20240511_SiteA_DL_Round03.pcap cn_20240511_SiteA_DL_Round03.pcap这个命名里uu、enb、cn标记抓包位置20240511是测试日期SiteA是站点标识DL表示下行测试Round03是轮次编号。分析时按文件名配对三个文件放同一个目录一目了然。如果不想手工敲文件名也可以用tshark的环形缓冲能力提前规避长抓包导致文件过大的问题tshark -i Intel(R) Ethernet Connection \ -f ip host 192.168.1.100 \ -w uu_20240511_SiteA_DL_Round03.pcap \ -b filesize:100000 -b files:8这里的-b filesize:100000表示每个文件写到100MB就切换-b files:8表示最多保留8个文件老文件自动覆盖。这样即使测试时间超出了预期也不会出现单个pcap文件超过800MB导致Wireshark崩溃的情况。-f参数在抓包阶段先过滤IP能显著降低磁盘写入压力。4. Wireshark数据分析Follow TCP Stream线程识别与丢包乱序定位抓包完成后分析环节决定了整个测试产出的质量。这里先把口径对齐分析的对象是eNB侧全量抓包文件时需要先分离商用用户流量分析Uu口单用户抓包文件时重点是拆线程、看丢包乱序、结合BLER判断无线侧丢块。4.1 先用显示过滤器把测试用户从eNB全量流量里拎出来eNB侧抓包是整个CC板的流量商用用户的报文会混在里面。分离方法不复杂用测试卡的IP做显示过滤器即可ip.addr 192.168.1.100 (tcp.port 8080 || tcp.port 443)ip.addr匹配源或目的IPtcp.port进一步收敛到业务端口。如果测试用的是Speedtest通常还要看TCP的载荷方向用tcp.len 0排除纯ACK包减少列表里的噪声行。这个过滤条件写好后可以保存为Wireshark的显示过滤器预设后续每个pcap文件直接套用。过滤完成后通过Statistics-IO Graphs可以快速确认目标业务在哪个时间窗口内传输。以下图为例IO Graphs直方图中红色标注区域显示了下载业务阶段的有效数据量大约69000行。从这个总量可以判断业务是否完整释放如果文件后半段还有大量TCP重传说明下载还没结束就停止了抓包。4.2 单业务线程过滤IO Graphs看总量Follow TCP Stream拆线程很多测试是多线程并行比如Speedtest、FileZilla默认开多线程梳理每条线程的数据传输情况才能定位问题。这里介绍一个虽然繁琐但能彻底理解Wireshark功能项的拆法。第一步在数据传输过程中选中任意一行右键选择Follow TCP StreamWireshark会自动筛选出该行对应的整条TCP流。第二步通过File-Save As保存该流保存对话框里会显示这个流占整个抓包文件的比例。比如整个过程89780行该TCP流33434行占比约37%说明这次下载绝不可能是单线程。第三步回到Follow TCP Stream的过滤状态找到NO.编号不连续的位置比如第153行到第196行之间有数值跳跃点击红色标注的Clear返回之前的完整列表。第四步从第154行到195行之间选任意一行再次执行Follow TCP Stream保存后看到这次捕获的线程有35882行。第一次Follow拿到33434行第二次拿到35882行两者都不是全量89780行加起来接近总行数这足以证明业务使用双线程下载。这个判断方法的依据是同一个TCP连接在Wireshark里对应一条独立的流Follow TCP Stream按四元组过滤两个不同连接的报文字段不连续行号和源端口会出现明显断裂。4.3 丢包与乱序分析Tick interval调到0.1秒后再看IO Graphs丢包、乱序分析有两个互补的工具视角IO Graphs适合看整体趋势Apply as Filter适合精确定位问题行。先说IO Graphs。打开Statistics-IO Graphs在Filter字段填入需要的显示过滤器点击Graph调整图表曲线就能看到数据包下发与丢包乱序的对比情况。LTE网络速率较高建议把Tick interval从默认值改为0.1秒。原因是LTE的调度间隔是1ms0.1秒聚合能看到亚秒级的波动如果间隔过短则曲线毛刺多、视觉噪声大过宽则会把瞬时丢包淹没在整秒统计里。实操中常见的过滤器组合是这样的tcp.analysis.retransmission这个过滤器匹配所有TCP重传包。在IO Graphs里同时画两条曲线一条是所有下行数据包tcp.len 0另一条是tcp.analysis.retransmission。两条曲线的错峰关系可以直接看出重传是集中爆发还是持续分散。持续分散大概率指向链路本身的问题集中爆发则要结合时间点回看无线环境是否有突变。4.4 Apply as Filter快速暴露出重传、乱序和重复ACKIO Graphs看到异常后下一步是定位到具体的报文行。方法是找到任一丢包或乱序行在Wireshark标记为黑底红字的字段位置点击右键选择Apply as Filter-Selected就能把全部丢包乱序相关的报文筛选出来。除了单点操作更高效的方式是直接输入组合过滤器tcp.analysis.flags || tcp.analysis.retransmission || tcp.analysis.out-of-ordertcp.analysis.flags是Wireshark专家系统对TCP异常的总开关覆盖重传、乱序、重复ACK、零窗口等tcp.analysis.out-of-order单独标记乱序包。三条条件用逻辑或连接一次把异常行全部显示出来。筛选出这些行后按照时间戳排序观察异常包之间的间隔和数量就能初步判断丢包对吞吐的具体影响。过滤器表达式含义典型排查场景tcp.analysis.retransmissionTCP重传包确认是否发生实际丢包tcp.analysis.out-of-order到达顺序错乱的包判断是否存在乱序转发tcp.analysis.duplicate_ack重复ACK定位快重传触发点tcp.analysis.zero_window接收窗口为0排查接收端处理瓶颈tcp.analysis.flags上述异常的总开关快速筛选全部异常行4.5 BLER与Wireshark联合阅读无线丢块和传输丢包的区别Wireshark里看到丢包不能直接认定是空口问题。LTE空口的MAC层丢块和高层TCP丢包不是一回事需要结合DT软件的BLER数据做联合分析。DT软件里的BLER曲线可以精确到秒级反映的是PDSCH传输块的误块率。以手册里给出的案例为例DT软件显示当时BLER处于正常范围没有出现丢块而Wireshark里却存在丢包。将两个文件按时间对齐后发现丢包时间段与BLER抬升时间段并不重合因此可以排除无线侧丢块导致丢包的可能性把问题重心放回传输链路或核心网侧。判断思路反过来也成立如果丢包恰好发生在BLER异常抬升的时间窗口内那大概率是无线环境恶化导致传输块错误率上升进而引发RLC重传和TCP层的丢包感知。联合分析的关键是时间对齐。DT软件的时间戳和Wireshark的抓包时间戳之间有秒级偏差判断时不要精确到毫秒级对比而是看整体变化趋势的先后关系。另外BLER高但TCP无重传的场景也常见这说明RLC层的重传机制已经把丢块消解掉TCP层根本无感知这种情况下业务速率不会受太大影响。5. 三侧pcap时间对齐定位法与tshark快速收敛技巧最后这个技巧是前面所有分析能力的综合应用。拿到Uu口、eNB、核心网三份pcap后不要急着逐份分析先把三份文件按时间轴对齐按同一个IP、同一个TCP流的Sequence Number做对比就能直观看到问题最可能出在哪一侧。实操做法是在Wireshark里分别打开三个文件用同一个显示过滤器把测试用户的TCP流拎出来把窗口时间列调成统一的UTC格式找到三段业务的起始点。比对着看三份文件里TCP序列号的变化正常情况下Uu口的下行序号走势、eNB侧的下行序号走势、核心网侧的下行序号走势应当是同步递增的。如果Uu口出现乱序而核心网侧序号正常说明乱序发生在eNB到终端这一段如果核心网侧已经重传而Uu口正常则问题在核心网侧或传输链路。用tshark跑一个快速的每侧统计比肉眼翻包更快tshark -r uu_20240511_SiteA_DL_Round03.pcap \ -Y ip.addr192.168.1.100 tcp.analysis.retransmission \ -q -z io,stat,1-r指定读取的pcap文件-Y在读取时应用显示过滤器-q表示安静模式只输出统计结果-z io,stat,1按1秒为间隔输出流量统计。把三条命令分别改成三个文件路径输出结果放到一起对比重传集中出现在哪份文件问题就聚焦在哪一段。这个命令在Linux和Windows的Wireshark环境里都能跑适合现场快速出结论。如果eNB和核心网两个文件里统计出来的TCP序列号没有错位数据一致性良好那问题就完全落在无线侧后续优化方向直接指向覆盖、干扰和调度参数。本文还有配套的精品资源点击获取