上个月帮一个做终端模组的客户看外场问题他们的LTE吞吐量测试结果怎么测都只有四十多Mbps换了好几个测试终端都跑不上来。最开始所有人都在怀疑是基站侧参数配错了结果排查到最后发现问题竟然出在灌包用的那台笔记本上——它的有线网卡更新驱动后速率协商掉到了百兆。干这行时间长了就会发现这类问题才是LTE吞吐量测试中最常见的坑你以为是空口问题实际上瓶颈往往在应用层甚至驱动层你拿到一个吞吐量数字却说不清它到底经过了哪几层链路、反映的是谁的性能。这篇文章就把LTE吞吐量测试这件事从头到尾梳理一遍从测试环境搭建、基站参数选择、灌包方法到速率不达标时的排查思路最后再聊聊最近比较热的LTE侧行链路资源池——很多做车联网测试的朋友最近都在关注这个方向它和传统LTE Uu口吞吐量测试的套路很不一样。文章适合两类人一类是刚接触通信测试、想系统理解吞吐量测试全流程的工程师另一类是已经在做外场或实验室测试但经常遇到“速率测不满”却不知道怎么定位问题的老手。1. 测试环境搭建基站参数与硬件链路是吞吐量的地基1.1 基站侧关键参数决定理论天花板LTE吞吐量测试的第一步不是插上终端就开始灌包而是先确定基站侧配置。很多人忽略了一个基本事实无线参数直接划定了吞吐量的理论上限它在测试之前就已经决定了这个测试“顶多能测到多少”。首先是带宽。LTE常见带宽有1.4MHz、3MHz、5MHz、10MHz、15MHz、20MHz对应RB资源块数分别是6、15、25、50、75、100。吞吐量测试一般首选20MHz带宽因为只有20MHz下才能验证100个RB全部调度时能达到的峰值性能。如果用的是10MHz带宽哪怕空口条件再好峰值吞吐量也只有20MHz的一半左右。其次是双工方式。FDD上下行使用不同频段、可以同时收发TDD则用同一频段分时收发。TDD模式的子帧配比和特殊子帧配置直接决定了下行和上行可用子帧的比例。比如常见的TDD配比2DSUDD一个5ms周期里只有3个下行子帧加2个特殊子帧特殊子帧里的DwPTS还能传数据但整体下行峰值速率会比FDD低不少。做TDD测试时必须先把子帧配比、特殊子帧配比如10:2:2、3:9:2记清楚否则测出来的上下行速率会跟你预期差一大截。再就是传输模式和MIMO配置。峰值吞吐量测试通常用TM3开环空间复用或TM8双流波束赋形这两种模式都支持双流并行传输相当于把下行速率翻倍。如果误配成TM2发射分集或TM1单天线端口最多只能走单流速率直接减半。终端侧的RI秩指示也要关注RI1代表终端只反馈单流信道状态即使基站想调度双流也没办法。调制方式是另一个关键变量。LTE的调制阶数从QPSK2bit/符号、16QAM4bit/符号到64QAM6bit/符号部分LTE-A Pro还支持256QAM8bit/符号。吞吐量测试时MCS调制编码策略直接对应调制方式和编码码率MCS越高每符号携带的比特数越多速率也越高。要让MCS打满前提是CQI信道质量指示足够高而CQI又依赖SINR。实测中想测出接近理论峰值的吞吐量SINR至少要到25dB以上。最后别忘了PDCCH和参考信号的开销。20MHz带宽、100个RB全部用于PDSCH只是理论值实际每子帧的控制区域PDCCH/PCFICH/PHICH和小区参考信号CRS会占用一部分资源。CFI1时控制区域占1个OFDM符号CFI3时占3个符号4天线端口场景下CRS开销更大。综合下来实际可用资源大约是理论资源的75%85%这就是为什么LTE FDD 20MHz带宽、2×2 MIMO、64QAM的下行理论峰值约100Mbps但现场实测能到8590Mbps就算很不错了。1.2 终端、服务器与传输链路经常被忽略的隐性瓶颈基站侧配置没问题不代表测试环境就合格了。终端、测试服务器、网线、网卡这些环节随便一处拉胯都会让最终测出来的吞吐量远远低于空口实际能力。终端侧要看几个硬指标终端支持的UE Category直接影响最大速率等级、天线是否双天线MIMO能不能跑满双流、是否支持256QAM等。现在很多手机终端默认开了省电模式或双卡双待副卡在驻网时会拉低主卡性能测试前最好把所有与业务无关的功能关掉SIM卡只用单卡数据业务跑到测试网络上。服务器侧最常见的坑是TCP窗口和CPU性能。用TCP灌包时吞吐量上限跟TCP接收窗口和RTT往返时延直接挂钩最大TCP吞吐量 ≈ TCP窗口大小 / RTT举个例子RTT为20msTCP窗口只有64KB时理论最大吞吐量约3.2MB/s也就是25Mbps左右窗口加到1MB才能跑满50Mbps以上。很多项目拿普通笔记本当服务器系统默认窗口小、CPU还在跑杀毒软件测出来的速率差是必然的。我曾经遇到一个案例客户反馈下行吞吐量只有理论的一半排查到服务器网卡管理软件里发现网线协商速率只有百兆而不是千兆。这种问题纯属环境问题但表现得特别像空口问题很容易让人走弯路。所以正式测试前建议先把“终端→服务器”这条传输链路的物理速率确认一遍有条件的话用测线仪或交换机管理页面查看协商状态。1.3 信道环境峰值速率测试为什么要在低衰落条件下进行吞吐量测试分两大类实验室测试和外场测试。实验室测试想要获得稳定可复现的峰值速率通常是把基站或综测仪和终端放在暗室里通过衰减器加入固定衰减保证接收信号稳定、SINR保持在25dB以上。外场测试则受真实信道环境影响很大多径衰落、干扰、移动速度都会让速率波动明显。我个人建议验证设备极限吞吐量时用室内固定衰减环境验证实际用户体验和覆盖能力时用外场路测。两者目的不同不要混为一谈。外场测吞吐量时如果SINR不稳定测出来的均值比理论峰值低30%50%是常态这不代表设备有问题而是信道条件决定的。2. 测试方法与KPI定义怎么测才是有意义的吞吐量2.1 分清峰值、均值与边缘吞吐量很多人说“测LTE吞吐量”但实际上吞吐量这个词至少可以拆成三种指标对应的测试方法和用途完全不同峰值吞吐量小区无负载、信道条件极佳、单终端独占全部资源时短时间内的最大吞吐量。用来验证基站的调度能力和终端的解调能力一般统计1秒窗口内的最大值多测几组取最大。均值吞吐量在一定的测试时长内如5分钟、10分钟持续灌包统计平均速率。用来评估用户的稳定体验抗衰落和调度波动影响。均值一般是峰值的60%80%。边缘吞吐量在小区边缘一般按RSRP或SINR阈值定义测试吞吐量反映覆盖边界用户的实际体验通常用5%分位或10%分位统计。主要用于网络规划和优化评估。三种指标对应完全不同的测试场景报告里不能笼统写“吞吐量多少多少”必须写明是哪种、在什么信道条件下统计的。2.2 灌包方式与工具参数配置吞吐量业务层灌包常用两种方式UDP灌包和TCP灌包。两者区别很大UDP不关心接收端是否收齐速率直接由发送速率决定适合评估空口承载能力。测试时如果UDP速率远大于实际最大吞吐量空口跟不上就会丢包所以UDP测试的结论要看“接收速率和丢包率”两组数据。TCP则保证可靠传输拥塞窗口、RTT、重传都会影响最终吞吐量更接近真实业务场景但引入的变数也更多。工具方面iperf是使用最广泛的免费灌包工具最基本的用法如下# 服务器端终端侧或PC侧 iperf3 -s # 客户端灌包发起端下行测试时是服务器侧发起下行 iperf3 -c 服务器IP -t 60 -i 1 -w 1M -P 1 # UDP模式下行测试 iperf3 -c 服务器IP -u -b 200M -t 60 -i 1参数说明-t 60表示测试60秒-i 1表示每秒打印一次速率-w 1M设置TCP窗口为1MB-P 1表示单连接。下行吞吐量测试是服务器作为客户端向终端发起灌包服务器→基站→终端上行则是终端发起、服务器接收。很多人搞反方向测下行实际变成了上行。另外一个常用手段是用FTP上传下载测试。它的优点是贴近真实业务缺点是FTP软件本身的缓冲设置、并发连接数会影响结果而且FTP传输有文件大小限制、磁盘I/O干扰等问题。实验室里我一般用iperf做主测工具FTP作为辅助验证。2.3 数据统计与有效样本处理吞吐量测试结果不是测完直接取个平均值就完事采样窗口、剔除异常样本、测试次数都有门道。我常用的做法是每秒输出一个速率采样点连续测35组每组60秒。统计时先看采样点分布如果出现个别极低的采样点比如掉了一个子帧或发生了切换这些点通常代表异常事件分析时单独标注不能混入正常统计中。峰值吞吐量取每组最大值再比较均值吞吐量取有效时间段内的平均。如果不同组之间峰值差异超过5%说明测试环境不稳定先查环境再继续测。还有一个容易被忽视的参数丢包率和BLER误块率。TCP灌包情况下空口BLER升高会导致RLC重传重传又挤占后续调度资源形成恶性循环。测试记录里除了速率一定要同步记录物理层的BLER、MCS、RB数和HARQ重传率这些是后期排查速率问题最重要的凭据。3. 速率上不去的完整排查链路从物理层到应用层3.1 为什么优先按协议栈从上往下排查遇到吞吐量不达标新手往往第一时间怀疑射频或天线问题然后去调基站的发射功率、换天线位置折腾半天一点进展都没有。我的经验恰恰相反先查应用层和网络层再往下走。理由很简单应用层的TCP窗口、网卡协商速率、服务器CPU这类问题占实际排查案例的一半以上而且定位成本极低、解决最快物理层问题要用仪表和日志分析定位成本高。一个完整的排查链路大致是应用层确认iperf/FTP软件配置、TCP窗口大小、并发线程数、磁盘I/O。传输层/网络层确认TCP重传率、丢包率、网络延迟确认灌包路径是否走错了网卡或路由。RLC层看RLC重传率如果是重传刷屏说明空口底层的误块率异常。MAC层看调度统计中的RB数、MCS、BLER、HARQ重传率、缓存状态。这里能直接判断“基站调度了多少资源”和“终端反馈的信道质量是否合理”。物理层看SINR、RSRP、RI、PMI、天线相关性。这一步才真正回到无线环境。每一层都有对应的日志和统计来源。基站侧可以用L3信令跟踪和MAC调度器统计终端侧用芯片日志QCAT、QxDM、辐记等抓底层信息测试仪表可以直接输出物理层参数。如果项目条件简陋至少也要拉到终端的芯片日志否则往下没法继续排查。3.2 一次实际排查案例吞吐量减半到底卡在哪一层去年有一个外场项目FDD 20MHz、2×2 MIMO、下行峰值理论100Mbps实际测出来稳定在4850Mbps正好一半。现场工程师判断是MIMO没有生效理由非常直接双流变单流可不就是一半吗但查了基站侧的TM模式配置明明是TM3终端反馈RI也一直是2说明终端认为信道支持双流基站也在双流调度。继续往下看MAC调度统计发现RB数基本占满MCS也正常在25左右BLER不到5%可吞吐量就是上不去。最后登录测试服务器一看iperf客户端显示单线程TCP发送TCP窗口只有64KB而此时RTT约25ms算下来最大吞吐量上限就是2.56MB/s约20Mbps——不对这个数字还不到50Mbps。再一看iperf窗口参数写到了128KB理论上限约41Mbps看来也不是这个数。最后发现是服务器网卡协商速率PCIe网卡显示连接速率是100Mbps full duplex而电脑的以太网属性里有个“EEE节能以太网”选项省电模式降了协商速度。如果实际只有100Mbps链路TCP吞吐量能到48Mbps已经是链路效率的极限附近了。把网卡调成千兆、固定全双工、关闭节能以太网后速率直接到了87Mbps。这个案例说明一个道理速率减半未必是空口双流问题应用层和链路层的因素会产生一模一样的表象。排查速度换算关系要先算清楚TCP窗口限制、链路协商速率限制、服务器CPU瓶颈、MCS限制每一项都有对应的“预设上限”哪一项最低最终速率就被它卡住。3.3 高频问题与对应定位手段速查表把常见问题和排查手段整理成表碰到类似情况可以直接按图索骥现象可能原因定位方法解决方向下行速率约为理论峰值的一半MIMO未生效RI1/单流调度查RI、PMI、CQI上报检查终端天线数量、天线接法、信道相关性速率上不去且MCS偏低SINR差、邻区干扰、模3干扰查SINR、RSRP、PCI调整PCI规划、加功率、消除干扰MCS正常但RB调度不满调度器限制、PDCCH资源紧张看MAC调度RB数、CFI排查PDCCH聚合级别、CCE资源占用BLER高、HARQ重传多覆盖差、干扰、终端移动过快查BLER、SINR、时延扩展优化覆盖、降低移动速度TCP灌包速率上不去TCP窗口过小、RTT过大算窗口/RTT上限调大iperf-w参数检查服务器网络栈服务器速率上不去且终端侧一样网卡协商速率低、CPU瓶颈查网卡速率、CPU占用换千兆网卡、关闭节能、卸载安全软件TDD测试速率远低于FDD子帧配比/特殊子帧配比影响查上下行时隙配比确认测试预期是否按配比计算过4. 从Uu口到侧行链路LTE侧行链路资源池对吞吐测试意味着什么4.1 什么是LTE侧行链路资源池最近圈子里“LTE侧行链路资源池”这个词讨论得比较多这跟车联网V2X测试需求增长直接相关。LTE在Release 14引入了完整的V2X侧行链路通信机制也就是常说的PC5接口上跑的LTE-V2X。和传统的Uu口基站与终端之间的接口不同侧行链路是终端与终端之间直接通信的链路数据不完全依赖基站中转。既然要直接通信就必须有一套资源分配规则来告诉每个终端在哪些时频资源上可以发送数据、哪些资源用于接收数据。这个规则定义下来的资源范围就是侧行链路资源池Sidelink Resource Pool。资源池在时域上通过一个bitmap位图来指示哪些子帧属于该资源池在频域上通过起始RB和子信道划分Subchannelization来界定。比如一个40bit的位图周期内某个bit为1表示对应子帧可用于侧行链路传输频域上则把资源池划分为多个subchannel每个subchannel包含若干连续的RB终端每次发送选择一个或多个subchannel。资源池的主要目的是把侧行链路通信限制在预定义的时频资源内避免与Uu口上下行业务、其他V2X业务产生冲突。配置方式分为网络配置和预配置两类处于网络覆盖内时基站通过SIB21下发射频资源池没有网络覆盖时比如地下车库、高速偏远路段终端用出厂预配置的资源池自主工作。4.2 Mode 3与Mode 4两种调度方式对吞吐量的影响LTE-V2X侧行链路定义了两种资源分配模式它们对吞吐量、时延和可靠性测试的影响差别非常大。Mode 3基站调度模式资源由基站统一分配基站在侧行链路资源池中为终端动态或半静态地调度PSCCHSCI控制信道和PSSCH数据信道资源。终端需要先跟基站建立RRC连接然后通过SL-RNTI接收调度指令。这种模式的优势是资源利用率高、碰撞概率低适用场景是有网络覆盖的城区。吞吐量测试时可以跟踪基站的侧行链路调度信令分析分配的资源大小和周期。Mode 4自主资源选择模式终端自己基于感知sensing机制选择资源典型方案是带着重传的半持续调度SPS。终端在资源池内监听信道占用情况选择未被占用的资源进行传输并且会在预设的时间间隔后重传同一数据包。Mode 4不依赖基站覆盖但对资源池配置的合理性非常敏感资源池太小、终端数量多时选择碰撞概率上升重传增多有效吞吐量下降。做侧行链路吞吐量测试时Mode 3通常能给出更稳定的吞吐量结果因为资源是基站按需分配的Mode 4的吞吐量则更依赖资源池大小、感知窗口和重传策略同一个终端的测试数据也可能有较大抖动。4.3 资源池参数如何决定侧行链路吞吐量上限了解LTE侧行链路吞吐量测试前首先要建立一个概念资源池的时域占比和频域宽度决定了吞吐量的理论天花板。假设一个侧行链路资源池只有每40个子帧中的10个子帧标记为可用bitmap占比25%频域上只划了20个RB那么无论采用多么高效的调度策略该资源池的容量上限也就是“25%的时域占比 × 20个RB对应的物理层速率”——如果跟一个占用100个RB、全部子帧可调度的Uu口20MHz载波比差距是非常大的。影响侧行链路吞吐量的关键参数主要包括资源池子帧位图周期与有效子帧占比有效子帧占比直接决定时间维度上的资源密度。子信道大小与数量subchannel划分越细调度越灵活小数据包传输效率越高subchannel越大单次传输可携带的数据量越大但空间复用效率可能下降。T-RPT传输资源图样每个MAC PDU允许占用的时域图样周期决定了数据重传的时隙安排。重传次数和重传间隔重传次数越多可靠性越高但对吞吐量的“消耗”也越多因为同一份数据占用了多次传输机会。子帧间隔TDD/双工方式侧行链路收发的时域分配会直接影响等效吞吐量。做测试时我建议先拿到完整的资源池配置再定预期值不要拿Uu口的理论峰值直接类比侧行链路。实际测试中可以用综测仪配合V2X协议分析功能抓取PSSCH上的数据流量按“有效传输时间窗口内的接收字节数”来统计侧行链路吞吐量。如果接触的测试场景比较基础还可以先忽略Mode 3/4的调度细节直接把资源池看成一个“为直连通信预留的传送带”传送带的长度时隙占比、宽度带宽/RB数和每次搬运货物的排布方式子信道、T-RPT、重传共同决定了这个传送带的吞吐能力。这样理解后再去啃3GPP TS 36.331里的sl-TxPoolSelectedNormal、sl-RxPool、sl-Subframe这些信令字段就不会觉得抽象了。我在实际测试中还有个体会侧行链路吞吐量测试的最大挑战不是“测出一个数”而是“保证测到的数真的来自目标资源池”。侧行链路是广播性质的发送环境里如果有其他V2X终端或干扰源吞吐量很可能被污染。测试前要把非目标终端设备关掉或隔离在屏蔽环境外同时确认测试终端绑定的是预期的资源池配置。这一点和Uu口吞吐量测试要关掉同频干扰小区的逻辑是一致的只是侧行链路上更容易忽视。