做LTE吞吐量测试算是无线通信这一行最熟悉、也最容易吵起来的测试之一。同样一台终端、同一个基站有人能跑到90Mbps有人却死活卡在20Mbps最后还要回头怀疑是不是仪表坏了。先说个结论绝大多数情况下吞吐量上不去问题既不是“信号不够好”也不是“设备性能差”而是测试环节里某个不起眼的细节没卡死——参数没配全、服务器网口协商错了、TCP窗口压住了或者测试软件统计口径不对。这套东西看起来简单真正测准了需要把“无线理论极限、有线网络承载、终端调度能力”三件事同时打通。今天这篇就来完整拆一遍LTE吞吐量测试的来龙去脉把能抄的配置、能避免的坑全部摊开讲。1. 为什么吞吐量测试总在翻车理论瓶颈与实际瓶颈吞吐量尤其峰值吞吐量是衡量LTE系统性能最直观的核心指标运营商验收要看、设备商研发要看、终端芯片评估也要看。它反映的是无线侧用户面数据能跑多快单位是Mbps。一个完整吞吐量测试链路要经过“应用层、TCP/IP协议栈、PDCP、RLC、MAC、物理层”这些环节最后数据才落到空口上被终端接收。每一层都会引入开销和限制这也解释了为什么同一个吞吐量测试能被解读出完全不同的数值。先把这个关键认知掰开测试里看到的“速率曲线”从来不是单纯反映空口质量的曲线。无线环境好只是前提更重要的支撑来自以下几个因素基站侧调度给终端的RB资源够不够、满不满。调制编码方式MCS有没有被信道质量撑到高阶比如64QAM甚至256QAM。终端支持的是2层还是4层MIMO接收天线层数决定了空口并行通道数。核心网和测试服务器的有限网络链路——这是最容易被忽略的短板服务器网卡速率、TCP窗口、FTP软件配置都会成为隐形瓶颈。很多刚上手测试的朋友看到吞吐量往下掉第一反应就是拉出工具看SINR、看RSRP。但实际项目中我遇到过太多“无线指标完美速率反而垫底”的场景服务器网线可能只协商到了百兆FTP服务器磁盘IO撑不住写满测试电脑上开了个视频客户端抢占带宽。所以真正靠谱的流程是先隔离有线侧问题再分析无线侧因素最后再去定位上层协议栈的开销。这次分享我会从理论峰值怎么算开始然后完整跑一遍下行、上行吞吐量的实测流程再把侧行链路也叫直连链路资源池配置对测试数据产生的影响单独拿出来讲清楚这个点最近问的人特别多也是新版路测软件里最容易忽略的配置项。2. 动手前必须搞懂的下行吞吐量计算公式拿到任何一个LTE吞吐量测试任务第一件该做的事不是架好设备上场打流而是在纸上把理论峰值算清楚。没有这把尺子后面拿到多少数据都没法判断“好还是不够好”。2.1 时频资源基础RB、RE、子帧到底怎么组成LTE的无线资源是按“时域-频域”二维块分配的。频域上最小单位是15kHz的子载波时域上最小调度周期是1ms的TTI也就是一个子帧。一个PRB物理资源块在频域上占180kHz正好等于12个连续子载波时域上包含1ms也就是2个0.5ms时隙。常规循环前缀下每个时隙有7个OFDM符号所以1个PRB在1ms内总共承载的RE资源元素数量是每个时隙12个子载波 × 7个符号 84个RE一个子帧两个时隙84 × 2 168个RE这是最基础的底账所有峰值吞吐量计算都是从这个168开始的。2.2 下行峰值速率推导全过程拿最常见的20MHz带宽、2×2 MIMO、64QAM调制的普通FDD LTE配置来算一遍理论极限。20MHz带宽下可用PRB数为100个所以1ms内物理层RE总数 100个PRB × 168个RE 16800个RE但PDSCH物理下行共享信道承载用户数据的RE必须从这16800个里扣除各种公共开销小区参考信号Cell RS占用每个PRB约占用其中一部分REPDCCH控制信道通常一个子帧里前1~2个OFDM符号要留给控制区PSS/SSS主辅同步信号、PBCH物理广播信道也定期占用实际可用数据RE大约占总RE的75%~85%取83%且64QAM每个RE携带6bit、MIMO两层空间复用则每毫秒比特数 16800 × 83% × 6bit × 2层 ≈ 167,328 bits/ms换算成秒就是约167Mbps的理论物理层速率。扣掉卷积编码冗余、MAC层填充、CRC校验等开销后实际峰值一般在85%~90%之间也就是150Mbps上下。这个数值是20MHz带宽、64QAM双流下非常典型的LTE单用户峰值区间。不同配置组合下的理论峰值区间整理成了一张常用参考表带宽调制方式MIMO层数物理层峰值约实测典型值约10MHz64QAM2层75Mbps60~68Mbps15MHz64QAM2层110Mbps90~100Mbps20MHz64QAM2层150Mbps120~135Mbps20MHz256QAM2层200Mbps160~180Mbps20MHz256QAM4层400Mbps320~360Mbps注意如果你用的是TDD-LTE制式以上所有数值还要乘以子帧配比的下行占比系数。例如1:3配比模式下下行约占9个子帧中的7个含特殊子帧的DwPTS部分同样20MHz普通配置的典型吞吐量就只有FDD模式的70%~80%。2.3 为什么实测永远低于理论值开销量化很多人测完数据第一反应是“差得怎么这么多”。其实物理层理论值、MAC层吞吐量和应用层TCP吞吐量三者之间本来就存在一条明确的损耗链。无线侧固定开销CRS、PDCCH、PSS/SSS等平均吃掉15%~20%的RE。传输开销PDCP头、RLC头、MAC头在中间层逐级加封装。编码开销信道编码引入的冗余校验比特。反馈开销HARQ的ACK/NACK消耗PUCCH资源占用部分上行对下行也有间接限制。调度瑕疵边缘用户在调度周期里不可能每个TTI都得到满PRB分配MCS选择也不可能在瞬时全链路保持最高。在这套开销链路上真正到应用层能看到的峰值速率大约是物理层理论值的70%~85%。知道这个范围恰好能帮你快速分辨哪些损耗是正常的哪些是异常掉坑。3. 实测环境搭建参数、工具与拓扑的避坑指南理论算完后进入实操环境准备。吞吐量测试对环境的要求其实比做覆盖测试更苛刻因为它对资源完整度和信道稳定性的依赖度非常高。3.1 软硬件与测试工具准备服务器端建议准备一台性能冗余的台式机或笔记本配置至少千兆网卡直连近端交换机或直接拉线到核心网测试仪的对接端口。软件方面两种搭配都很常见最省事用Windows自带的IIS搭建FTP服务终端侧用FTP客户端多线程下载大文件。最推荐用iPerf3因为能自由调整TCP窗口、并发线程数、传输时间记录带宽曲线更精细适合抓问题。终端侧根据你的测试目标分两类玩法商用终端挂路测软件直接用主流工程手机比如各大品牌对应测试版本配合鼎利、CXT/CXA、QVoice这类路测工具好处是部署快坏处是看不到MAC层调度细节。测试UE前后台Logger高端实验室和基站厂商常用专业测试终端或采用高通平台的工程UE配QXDM等工具抓底层log能看到实时的MCS、RI、PRB占用、BLER等物理层关键参数。实操心得在外面跑外场吞吐测试我包里最少放两套手机一套是能抓log的工程机用于问题定位另一套是普通旗舰手机用来看真实用户体验速率。两个曲线对不上往往能发现芯片差异或终端调度算法偏好带来的性能差。3.2 无线参数固定清单测试前必须逐项核对吞吐量测试对复现性要求极高。下面这几项参数测试前一定要从基站配置和终端log两端去核对任意一项意外处于非预期状态最后测出来的数字都没法说明问题频点/PCI锁频测试时务必固定小区避免重选或切换导致统计中断。带宽确认是20MHz还是15MHz峰值差异极大差一个带宽目标值全变。传输模式常见TM3开环空间复用、TM4闭环空间复用和TM7/TM8波束赋形必须都明确。峰值吞吐量测试一般锁定TM3或TM4。上下行子帧配比TDDTDD制式下尤其关键比如特殊子帧配比10:2:2之类的配置会直接影响单子帧PDSCH可用符号数。调制方式实验室做极限验证时通常直接把MCS固定到28或更高档位对应256QAM测试外场验收则允许自适应MCS随信道质量变化。调度RB数固定全带宽或允许满调度根据测试目标二选一。3.3 端到端链路检查三件套任何一次测试开跑之前先用最基础的三件事验证整条链路是通的、是快的在测试电脑上ping服务器观察时延和丢包率时延大于20ms就说明中间环节绕路了。用本地网线直连千兆交换机跑三次iPerf打流确认有线TCP吞吐量最少能跑到900Mbps以上否则无线侧测出的所有数字都会被有线瓶颈压制。检查测试电脑上是否开启了大流量后台更新、杀毒软件实时扫描、系统自动更新这类隐藏抢带宽的应用。我见过太多“无线侧一切正常、速率始终少一半”的case最后都是后台软件在作怪。重要提醒笔记本电源管理里的“节能模式”和无线网卡的省电策略同样会造成吞吐量周期性掉坑。测试前统一设置为“高性能”模式关闭无关无线网卡的自动切换。4. 下行吞吐量测试完整实操流程单用户峰值场景下行吞吐量最常见的目标就是测“单用户峰值速率”这个场景能直接反映无线资源在最优条件下的极限承载能力。步骤看起来平淡无奇实际执行中的统计和控制细节才决定测试质量。4.1 多线程打流与统计口径选择启动服务端iPerfiperf3 -s终端侧发起下行打流测试一般建议加4到8个并发线程iperf3 -c 192.168.1.100 -t 120 -i 1 -P 8其中-t 120表示打流120秒-i 1每秒输出一次速率。多线程是实测必选项原因是单TCP连接的吞吐量很容易被收发缓冲区、拥塞窗口限制在两位数Mbps而移动网络时延比有线局域网高很多单连接根本撑不起高速率。用多线程并发可以把多窗口同时跑满逼近空口极限。留意这里的统计口径问题。用iPerf、FTP下载这类工具测出的是应用层TCP吞吐量而路测软件或QXDM工具直接读出的MAC调度速率属于无线层吞吐量。两者的差值就是TCP/IP协议栈以及空口重传产生的开销总和。通常MAC层速率100Mbps时TCP层实测80~90Mbps都算正常4.2 现场测试执行与数据记录要点实际外场测试时车辆停在弱干扰区域且保证RSRP在-85dBm以上终端保持静止状态锁定小区后按下自动测试脚本确认SINR稳定在25dB以上CQI上报值能顶到15对应64QAM或更高。检查log中RI秩指示是否稳定维持在2代表两层MIMO空间流正在同时传输。记录空口MAC层实时速率、应用层速率、MCS分配、PRB占用率。测试至少持续60秒以上峰值、平均值、边缘速率都单独统计。一套典型的单用户下行峰值测试数据长这样统计项数值RSRP-78dBmSINR28dB占用PRB98~100MCS档位27~28RI2MAC层平均速率142MbpsTCP应用层平均速率128Mbps上下行BLER0%~2%实操心得外场测吞吐量如果发现MCS经常掉到20以下而SINR又显示不差大可能是PDSCH受到了邻区下行干扰或者PCI混淆可以把邻区列表打出来清一遍再复测。这种“无线指标好、MCS反而低”的现象会直接浪费一下午的测试时间。4.3 服务器侧参数微调FTP或iPerf测试时记得同步调整服务器网卡上的TCP卸载参数、增大收发缓冲区sysctl -w net.core.rmem_max16777216 sysctl -w net.core.wmem_max16777216Windows服务器则在注册表里调整TCPWindowSize并关闭自动调谐限制。这些设置不调整多线程也救不回来——因为还是会撞到系统默认缓冲门槛上。5. 上行吞吐量测试的关键差异与操作要点上行吞吐量测试的思路和下行完全对称多这一步方向换了但内部机制完全不同不单独讲清楚绝对会测出错误结论。5.1 上行资源与调度的特殊约束LTE上行采用的是SC-FDMA单载波频分多址。相比下行OFDMA它最大的约束是单个终端在同一个TTI内只能分配到连续的PRB而且单用户最多只能使用100个PRB20MHz下且默认只能发送单流数据。也就是说上行天然没有MIMO双流带来的速率翻倍效应。加上调制方式通常最高支持至64QAM20MHz下单用户上行物理层理论峰值约为100PRB × 168RE × 83%可用率 × 6bit/符号 ≈ 83.6Mbps再扣掉上行链路独有的SRS探测参考信号、PUCCH反馈、随机接入开销后实测通常落在50~70Mbps之间这已经很优秀了。如果配置了上行256QAM部分Cat13以上终端支持理论上限会明显提高但必须确保终端和基站同时支持。5.2 上行测试实操与指标判断上行打流方向反过来服务器端改成客户端接收iperf3 -c 192.168.1.100 -t 120 -i 1 -P 8 -R终端侧在FTP工具里执行向服务器上传大文件同样保持多线程并发观察终端log里的PUSCH RB数、MCS、BSRBuffer Status Report缓存状态上报。判断上行速率有没有跑到极限重点看MCS是否顶格以及PUSCH占用RB是否接近全部分配。如果PRB占用只有一半但MCS已经很高说明调度器在功率受限或网络拥塞如果MCS一直上不去优先怀疑终端发射功率受限或者上行干扰偏高。常见问题上行测试中很容易看到速率起伏剧烈这多半和终端的PHR功率余量上报有关。当终端离基站较近、发射功率被压到很低时基站的调度MCS反而能顶满离基站远时功率余量不足只能回退MCS。所以测上行要尽量把终端放置位置控制住别一直移动。5.3 上下行吞吐量差异速查对比项下行上行多址方式OFDMASC-FDMA最大MIMO层数4层LTE-A1层典型20MHz峰值120~150Mbps50~70Mbps主要开销来源CRS、PDCCHSRS、PUCCH瓶颈判断看RI、MCS、PRB占用PUSCH RB、功率余量、MCS6. 测试中最容易踩的坑与排查实录接下来这一节是真正的价值点每个案例都是实际项目中反复踩过、甚至困扰了很多轮的教训。6.1 坑位一有线侧瓶颈伪装成无线问题典型的翻车现场测试终端离基站极近SINR高达30dBRI稳定2MCS顶格可TCP层速率死活只能跑60Mbps。逼到无线侧所有参数都快检查到物理层符号级了最后兴起看了一眼服务器网卡状态才发现链路线协商成百兆。网线质量差、笔记本网口脏、交换机单端口旧配置全都会导致协商速率掉档。拉开整个排查链条的正确顺序永远是自下而上的服务器和测试电脑用有线跑局域网iPerf先确认端到端TCP能达到900Mbps以上再走无线接入服务通过核心网回传段验证各段速率最后才在空口侧优化参数顺序颠倒排查效率极低而且极易把错误结论定到无线研发头上。6.2 坑位二TCP窗口和单线程限制另一个高发问题是测试时终端离基站空口条件极佳但速率曲线呈“锯齿状”每秒钟周期性冲到90Mbps后又掉回30Mbps。这种形状十有八九是TCP拥塞窗口在移动网络高时延环境下反复触顶回落。处理方案增加并发线程数-P 8甚至更大。拉大系统接收发送缓冲区。使用更高性能的TCP拥塞控制算法比如在Linux下切换到 BBRsysctl -w net.ipv4.tcp_congestion_controlbbr实测同样的优质空口单线程可能只有40Mbps改成8线程加BBR能稳定跑到130Mbps以上。6.3 坑位三DRX不连续接收导致周期性掉速做LTE吞吐量测试时如果终端周期处于RRC_IDLE状态或开启了DRX不连续接收吞吐量曲线会规律周期性地掉下去一段。DRX机制本身就是移动网络为了省电设计的调度和接收会按周期休眠对实时打流的影响非常明显。建议实验室极限测试务必在测试呼叫配置里关闭DRX或设置最短唤醒周期如果外场条件不允许关闭统计平均值时把周期性下降部分标注出来不要直接归为“无线抖动”。6.4 坑位四HARQ重传比例过高导致MCS虚高还有一次外场测log显示MCS一直在26以上BLER却在5%~10%徘徊速率也不尽如人意。最后发现问题不在MCS选择而在HARQ重传第一次传输解码失败的比例高重传不断占用新数据调度机会有效吞吐量大打折扣。排查思路是看MAC层的BLER统计如果BLER长期超过2%说明当前MCS选择过于激进或信道估计失准。同步确认HARQ反馈曲线里各进程的重传计数重传占比超过5%就需要调整MCS回退策略或检查PDSCH频选干扰。6.5 常见问题速查表现象优先排查点验证方式速率整体偏低服务器网卡协商速率/后台应用局域网iPerf打流对比速率锯齿形波动TCP窗口/线程数/拥塞算法调参后看曲线平滑度周期性掉坑DRX配置/测量间隙关闭DRX复测MAC层速率高但TCP低协议栈窗口/终端处理能力对比MAC/TCP统计无线指标好但MCS低邻区干扰/调度器CQI映射检查邻区列表与CQI上报值BLER偏高HARQ重传/信道估计分开统计首传/重传BLER7. 延伸侧行链路资源池对吞吐量测试的隐藏影响最后把最新的一个热点单独拎出来LTE侧行链路资源池对普通吞吐量测试的潜在干扰。V2X车联网场景下终端之间可以直接通过PC5接口通信也就是侧行链路传输模式不经过基站中转。公共安全、车联网通信里的PRS和直连数据都依赖这套机制。7.1 侧行链路资源池是什么侧行链路资源池就是给直连通信划分出来的一组时频资源块序列包括Sidelink ControlPSCCH和Sidelink DataPSSCH分别使用的资源集合。它可以配置成基站调度的模式Mode 3也可以由终端自主检测资源占用并选择避开冲突的模式Mode 4。资源池本身用一组参数定义子帧位图、起始RB、RB数量、跳频模式、循环周期等。7.2 它如何影响常规吞吐量测试结果如果测试环境中的基站和终端同时开启了侧行链路相关功能或者测试区域内其他V2X设备正在周期性占用侧行资源那对常规的单用户下行和上行吞吐量都会产生实际影响资源池占用了部分子帧PSSCH和PSCCH占用的时频资源不再参与常规蜂窝调度。资源池周期和蜂窝打流周期叠加后产生规律的周期性速率下跌。侧行链路的GNSS同步偏差会导致时域上的调度错位进一步影响同一子帧的蜂窝调度行为。如果你在吞吐量测试中发现曲线每隔固定周期就规律下跌建议去核查基站侧Sidelink的资源池配置是否开启尤其注意子帧位图中预留的子帧号。很多“无线参数全都正确速率还是周期波动”的疑难杂症根源就在这里。7.3 排查和处理方法测试前询问网络侧是否开启V2X或公共安全直连功能如果开了要求关闭或调整资源池位图避开测试子帧。查看小区SIB18/SIB19相关广播配置确认侧行链路资源池是否周期性广播。针对侧行链路占用的时频资源在统计时预留扣除避免把V2X预留开销误算成普通蜂窝吞吐量损失。实操心得跑车联网测试项目时曾经为了追一个“每100ms掉一次速”的现象浪费了整整两天。抓空口log发现PSSCH周期就卡在100ms确认是资源池子帧位图跟FTP打流数据包调度重叠把侧行链路关闭后蜂窝吞吐量曲线瞬间恢复顶格平滑。这个案例放到这里希望其他人不用再经历一次这么漫长的排查。测吞吐量这件事说到底是做“解耦”把无线、有线、协议栈、调度器逐层拉开才知道那个掉队的长板到底在哪一层。我个人在实际操作中最深的体会是测试方案里写清楚每个环节的质控点比多测十遍数据都有用。至少我现在每次拿到一套吞吐量测试结果都会先看一眼有没有配套的“局域网打流校准记录”和“无线参数固定清单”缺任何一样这个数据就不敢直接拿去下结论。最后再分享一个日常小技巧跑外场吞吐量测试时手机里用文件管理器打流的同时顺手录一条log和截图并保存一份测试点位的卫星地图截图。测完回看时这些辅助资料能帮你节省大量“当时环境到底是什么样”的扯皮时间。吞吐量测试的上限永远是协议频谱效率决定的理论值下限则由你的测试设计决定。多数时候我们不需要追求极限只需要保证每一次测试都能讲清楚“为什么是这个数”这就足够了。