目 录
一、吞吐量异常表现
1.1 吞吐量一般观察应用层的吞吐量或者MAC层的吞吐量：
1.2 异常主要有2种表现：
二、吞吐量异常定位方法
2.1 吞吐量异常定位思路
2.2 调度次数不足定位方法
2.3 RB个数不足定位方法
2.4 灌包不足定位、解决方法
2.5 开户速率和进入eNB的流量不足定位、解决方法
2.6 闭环功控，ICIC特性对RB数影响
2.7 本小区内多用户做业务
2.8 MCS阶数偏低定位、解决方法
2.9 检测干扰
2.10 UE主分集不平衡
2.11 UE能力限制
2.12 误码率过高定位、解决方法
2.13 传输模式异常定位、解决方法
2.14 非空口问题定位、解决方法
2.15 下行吞吐量基线参考
2.16 上行吞吐量基线参考
2.17 上行吞吐量理论分析
2.18 相关工具的使用和信息获取-UE Probe
2.19 相关工具的使用和信息获取-eNB M2000
2.20 下行MCS阶数偏低---下行SNR偏低&CRC异常
2.23 上行反馈异常
2.24 通道校正不过
2.25 BF吞吐量异常
2.26 UE侧AMBR折算方法





一、吞吐量异常表现


1.1 吞吐量一般观察应用层的吞吐量或者MAC层的吞吐量：


1.2 异常主要有2种表现：

1 吞吐量波动大（通过Netmeter等吞吐量统计直观观察）

>>存在掉坑、裂缝等异常表现


>>终端不动，出现超过50%的波动


2 吞吐量偏低

>>峰值吞吐量

>>定点吞吐量


二、吞吐量异常定位方法



2.1 吞吐量异常定位思路

步骤1：检查基站告警及基本参数的检查

1）当吞吐量出现异常时，首先需要导出基站告警日志看是否存在硬件上的故障或者S1告警及闪断等。

2）其次进行基本参数检查，分eNB侧和终端侧。

>>eNB侧主要和基线参数进行核对，商用网络如果出现参数和基线参数不一致的情况，需要查清为什么会出现该种情况；

>>终端侧参数检查：主要是PC窗口的大小，会影响TCP业务；


步骤2：空口/非空口问题隔离定位


1）判断是否是TCP问题

>>最简单的方法－UDP灌包

>>尝试多线程下载或同时下载多个文件

(1)若吞吐率明显要大于TCP业务吞吐率，则判断为TCP问题，进入TCP问题排查；

(2)若吞吐率与TCP业务基本持平，或者比TCP还低，则进入空口问题排查；



步骤3：空口问题定位、解决方法

1）当出现吞吐量异常，且基本确定为空口问题时，主要从下面几个方面进行分析定位，其中调度次数不足和调度RB不足可以合并定位，定位顺序从左至右。


2.2 调度次数不足定位方法


如何判断调度次数过低

>>通过终端监测工作获得（1s统计一次）

>>通过eNB的监测工具获得（1s统计一次）

单用户场景用户调度次数取决于TDD上下行配比，可以直接观察Probe显示的DL Grant Count/ UL Grant Count ；


下行当观察到的总量持续<用户调度次数*5%，认为下行调度次数不足；

上行因为HARQ时，调度器不需要下发ULGrant，所以一般ULGrant在理论总数的90%以上都是正常的；

多用户场景如果默认频分调度且UE能力不受限，此时每个TTI只调度1个用户，此时用户调度次数= Grant Num/小区用户数，其中Grant Num与单用户时相同，取决于TDD上下行配比。





2.3 RB个数不足定位方法


如何判断RB个数过小

上行在闭环功控的条件下，在路损超过120dB~125dB的条件下上行开始缩小调度的RB个数，此时MCS阶数大概在3~5阶左右，在路损小于120dB情况下，几乎都应该以满RB调度；


下行几乎都应该是满RB调度；

上图为终端Probe显示的结果，RB数=Total Code0RBCount/Code0Count



上图为M2000中的RB数观察方法，RB利用率跟踪项中的等效RB使用数


2.4 灌包不足定位、解决方法

如果DL/UL Grant个数小于理论总数的60% ，一般是由于灌包不足引起的，这种情况在大带宽峰值测试下特别常见。

解决方法：使用多线程灌包或者更换性能更好的便携。

灌包命令如下：

Iperf –c xx.xx.xx.xx –u –b 100M –t 99999 –i 1 –P 2

xx.xx.xx.xx表示目的IP，根据实际情况输入。P表示线程数，注意，要大写。

2.5 开户速率和进入eNB的流量不足定位、解决方法

1 检查开户速率，看是否是由开户速率过低造成吞吐率问题，开户速率至少要超过期望速率。如下图所示，该图表示上下行开户速率都为20k，开户速率显然太小，不能满足LTE要求。在UE侧也可以观察。





2 其次下行需要查看从S1口过来的入口数据是否充足：


这个例子是一个下行灌包50M的例子，看红色框里面的数值“6199732字节/秒”换算成M就是6199732*8/1000/1000 = 49.597856M。实际上这个流量就是我们收到的，从核心网到GE口的流量。这个能够证明流量是否足够。



2.6 闭环功控，ICIC特性对RB数影响

1 上行闭环功控

>>如果不生效，中远点速率较低，RB个数远低于闭环理论值，但是近点能达到峰值；

>>比如：在RSRP=-100dBm的时候，如果闭环功控在起作用，对于20M带宽，有近90个RB；对于10M带宽，有40个RB左右。与之相比，开环功控最多只有10个左右。

>>对于我司UE，打开Probe的Power Control，其中SumFiValue不等于-1即为闭环。

2 ICIC

>>上下行都有ICIC开关，首先确认开发是否打开，然后在信令中搜索包含MeasurementConfig 的RRC ConndectionReconfiguration消息，如果消息中的reportOnLeave字段取值为True，表明触发了ICIC A3测量。


2.7 本小区内多用户做业务



如果本小区存在其他用户在做业务的时候，观测单UE的RB将会减小，因此在测试之前应该先检查小区内是否存在其他用户，测试过程中也应该注意是否有其他用户接入。下面为只有一个用户时的显示结果：


2.8 MCS阶数偏低定位、解决方法


如何判断MCS阶数过低

>>MCS阶数是否合理在拉距的条件下较难判断。

>>上行在路损超过120dB~125dB缩RB的时候一般维持3~5阶数，但是随着RB不能再缩小，其MCS阶数也会降低。比较方便的方法是排除法：在UE以满功率（23dBm）发送的条件下，如果调度次数和RB个数都比较正常但总吞吐率偏低，那么可以认为问题出在MCS阶数上。

>>下行均衡后SNR偏低，导致下行吞吐量偏低。

>>下行CRC异常，导致AMC将下行阶数调整下来。

>>上行反馈异常，导致AMC的异常调整，导致下行阶数偏低。


2.9 检测干扰


1 上行干扰可以在M2000上观测判断：

>>UE未接入情况下（所有UE关机，小区里没有业务），打开M2000的“小区性能检测”，选择“干扰检测”，查看RSSI值，在没有干扰的时候，约等于－119＋10log(RB个数)，在内场差距1dB以上，在外场差距在3dB以上即认为存在干扰，需要检查干扰。干扰一般来自邻区或者是异系统干扰（比如2G或3G系统）

2 下行干扰可以在UE侧Probe上观测判断：

>>在Detected Cell中看是否有多个小区，且超过1个小区的RSRP和本小区的RSRP差在3dB之内。如果是，则表明存在较强的邻区干扰。

>>在检测到的邻区当中，不能出现和本小区PCI相同的邻区。

>>查看下行各子带CQI是否有某一段CQI的值特别低的，如果存在，说明存在较严重的窄带干扰。

3 解决方法：

>>较强的邻区干扰只有通过调整天线方向角等来解决。

>>严重的窄带干扰通过扫频，找出干扰源，进行排除。






2.10 UE主分集不平衡

主分集不平衡，会严重影响我们的测试结果，如下为一次测试数据的结果：由于主集（Antenna0）比分集（Antenna1）小了近5dB，在显示RSRP的时候显示的是最强信号的RSRP,但是UE发送信息是从主集发送的，算路损的时候也是以主集为主。这样实际上行的信道质量就比显示的RSRP小很多。可以通过2个办法解决该问题：

>>在测试有外置天线的时候摆弄主分集天线，在测试内置天线UE的时候可以改变UE位置使其主分集相对平衡，

>>吞吐率曲线不用RSRP，改用路损VS吞吐率


2.11 UE能力限制

1 UE能力查看方法：在UU口跟踪消息”RRC_UE_CAP_INFO”里查找。我司UE可以从OMT查询得到。目前市场上一般的商用终端为CAT3 UE；

2 对于上行来说，CAT 5 UE 最高能达到28阶，CAT 3和CAT 4 UE只能达到24阶。




2.12 误码率过高定位、解决方法

峰值场景不能收敛到0%，非峰值场景下行BLER持续高于15%；如果存在MCS阶数为0的时候，误码率较高也可以认为是正常现象。


2.13 传输模式异常定位、解决方法

传输模式主要是针对下行：


>>初始接入是TM2模式，之后根据信道环境切换到TM3或者TM7，当出现终端失步、切换、重建时，会重新进入TM2模式。MIMO模式从空口消息进行观察，如图：


>>下行MIMO模式异常，主要体现在UE上报的Rank是否合理及上报反馈是否存在异常。正常情况，收发相关性小于0.5 AvgSNR大于15dB时，系统可以使用双码字。如果没有使用，需要查看UE上报的Rank及eNB收到的Rank，并采集相关数据反馈分析。




2.14 非空口问题定位、解决方法

1 检查TCP参数

>>操作系统：如果是Windows XP则继续，如果是Vista、Win7或其它操作系统，则跳过本步骤；

>>查看/设置TCP参数

(1) 在发送方和接收方都通过DrTCP工具，在Adapter Settings中找到对应网卡，按如下设置：



(2) 在发送方再利用工具TCP parameter setting.reg进行修改，双击导入；

(3) 以上两步操作完后再统一正常重启电脑，这样配置才能生效。如果服务器侧无法修改，则只修改UE PC。

>>如果修改了TCP参数问题依旧，则继续下一步的判断



2用TTI跟踪TCP问题定位模块进行分析

>>如何进行TTI跟踪？

(1)首先要确保TCP链接所使用的端口号已经加到算法模块的白表中(默认已经添加FTP数据链端口20，iperf则需要手动添加5001端口)。

(2)使用LST TPEALGO:;检查端口号，使用MOD TPEALGO:;添加对应端口号。

(3)然后可以启动TTI跟踪了，登陆M2000，依次选择菜单Monitor -> Signaling Trace -> Signaling Trace Management 打开信令跟踪页面，选择Information Collection -> IFTS Trace 启动IFTS跟踪。按照提示填写相应信息，一定要勾选L2 Performance，并在MAC Layer Trace Field中填写132，此为TCP问题定位模块的ID号，点击Finish启动跟踪即可。

注意：顺序是，启动TTI跟踪后，再重新接入UE，再进行TCP业务。

>>跟踪数据如何解析，解析结果如何看？

使用LAE解析IFTS跟踪文件，解析和分析方法参加文档LAE案例(TCP)。

>>若按推荐操作仍旧没能解决问题，则抓取数据反馈回厂家。


3 TTI数据的常见解析结果：

>>CRC_ERR: 数据包有CRC错，若出现在Server->eNB PDCP之间，则核心网或S1的传输设备有较大概率出现硬件故障，建议检查S1的各传输设备是否有告警；若出现在UE->eNB PDCP之间，则可能是UE硬件故障，尝试更换UE；

>>WIN_SHRINK：接收窗口收缩，若频繁出现该事件，或者对应的通告窗口为0，则表示接收方的电脑硬件性能不行，数据包无法从TCP层往应用层递交，建议更换接收方的电脑；

>>RSV_DUPACK：收到重复ACK，一般在丢包或者乱序的场景才会触发；当重复ACK数在10以下则一般为是乱序，而大于10则一般为丢包；根据异常位置的判断，去检查相应位置的设备或传输；

>>LINK_TIMEROUT：数传中断时间超过500ms，查看当前包方向，如为下行，则表示问题出现在下行，在500ms内没有收到下行的任何数据包和ACK；上行也是一样；

>>PACKET_DISORDER：数据包乱序，查看出现异常的位置，检查相应位置的设备和传输；



2.15下行吞吐量基线参考

1 下行MIMO 2port场景理论峰值基线：


24T4R(2Port,PSD)，BW=20MHz，SA2，SSP7，Cat5终端(TUE)，TM2/3/7自适应，CFI=3：






2.16 上行吞吐量基线参考



单用户上行理论峰值吞吐率基线


20M带宽下，单用户上行吞吐率参考曲线（配比二、4T单用户最大50RB）


2.17 上行吞吐量理论分析


1. 上行单用户峰值吞吐率:必须同时具备以下四个条件：

1）对于CAT5 UE MCS选择到最高28阶，对于CAT4 和CAT3 UE MCS选择到最高24阶，有部分为23阶（协议最大TBS限制导致降阶）。


2）UE分配到最多RB个数（单用户最大可用RB个数＝总的RB个数－PUCCH RB个数，实际调度RB数还要满足235法则。235法则指的是：单用户PUSCH调度RB个数必须是2，3，5的倍数）。


注：上表是在PDCCH符号数固定为3的前提下给出，4T和8T场景下，目前版本需考虑单用户最大RB产品能力限制，4T最大50RB、8T最大36RB：

3）上行调度次数充足，ULGrant次数在不同配比情况按下表：



4）IBLER少于1%.

2. 上行定点吞吐率偏低

与峰值吞吐率类似，上行定点吞吐率偏低的定位也需要从RB数目、MCS阶数、上行调度次数和误码率四个方面进行。

2.18 相关工具的使用和信息获取-UE Probe




2.19 相关工具的使用和信息获取-eNB M2000



在M2000里面点监测：

”小区性能监测”：查看RB利用率，总吞吐率，小区干扰监测，用户数；

“用户性能监测”：查看Power Headroom，信道质量，吞吐率，MCS阶数统计，误码率；


2.20 下行MCS阶数偏低---下行SNR偏低&CRC异常(1)

下行SNR偏低&CRC异常主要由下面5点导致，排查顺序从左至右。


2.21 下行MCS阶数偏低---下行SNR偏低&CRC异常(2)

下行相关性高



观察：

RxChCorFactor和TxChCorFactor两个值均大于0.5，则表明收发相关性较高，越接近1，相关性越高，解调性能越差。

解决方法：

实验室：

（1）修改组网，使得主分集分路进行连接。

（2）VAM的内部连接也需要采用分路的方法进行。

（3）排查实验室干扰，当干扰大于信号时，会出现两路信号的相关性较大的情况。

外场：

（1）直达径场景，一般相关性较高，避免直达径的地方。

（2）外置天线可以拉大天线间距或使其两天线垂直摆放。


2.22 下行MCS阶数偏低---下行SNR偏低&CRC异常(3)


RRU相关信号处理出现异常


（1）RRU的通道不平衡会导致终端的解调能力下降，导致MCS偏低，可以通过下面的方法来观察。


观察两天线接收的RSRP差，当两根天线差值持续在5dB以上时，认为通道不平衡，需要通过调整终端天线来解决。


（2）终端入口功率一般在-50dBm~-90dBm，如果入口功率超过-50dBm容易导致削波，使得下行SNR偏低；如果入口功率低于-90dBm，也会使得下行SNR偏低，影响下行性能。可通过Probe显示的RRU Measurement观察终端接收的功率。


该问题在实验室，通过调整中间的路损来解决。

在外场，通过调整站间距和基站的功率配比来解决，但此问题需反馈回总部相关人员进行分析和优化。

（3）RRU的发射时延不一致，频谱泄露，本振泄露及RRU内部模块存在问题，需要通过采集基带数据，发回厂家进行分析，具体采数方法见后。


2.23 上行反馈异常


1. 如果通过前面几点的排查，发现下行调度次数，调度RB数，MIMO模式均没有问题，且BLER收敛也正常，调度MCS也调度在正常范围。但是下行流量仍出现异常，如下所示：

2. 此种情况，基本可判定为反馈通道出现了问题，即将ACK/NACK错解成了NACK/ACK/DTX。反馈通道的问题，即数据采集可以参考上行PUCCH和PUSCH的问题定位进行处理。


2.24 通道校正不过

1.通道校正不过，传输模式就不会切换到TM7或TM8；

>>通道校正指示CEI=False时要排查是发通道校正不过还是收通道校正不过，可通过在M2000上MML命令导出DBG日志log，利用InsightSharp查看通道校正指示和收、发通道校正的CINR。

2.解决方法

>>如果收发通道校正中固定为某一个天线端口的CINR低于门限值，则很有可能是该天线通道口损坏；

>>如果发通道校正通过，而收通道校正不过，则很有可能是外部干扰导致的；

>>RRU入口和出口功率是否平衡：

a.基带到RRU的入口功率查询（在[DigitPwr Info]里查看TxComB ）： boardEnvShow

b.RRU出口功率查询： bdrfpmPrintRfStatus（查看对应使用的物理天线端口的HPA Power)

>>准确定位方法是通过在eNB基带采集DSP空口数据进行定位；


2.25 BF吞吐量异常


检查DRS SINR是否偏低，SRS配置是否正常，相关性测量；

>>SRS配置可以通过Probe中跟踪“RRC Parameters”查看获取SRS带宽、周期等信息；

>>相关性测量部分，UE侧通过Probe查看收发相关性；


>>需要采集数据时可通过M2000的IFTS跟踪，MAC布控33/40/49/55/67/224/160/43。



2.26 UE侧AMBR折算方法


LTE协议对APN-AMBR在空口下发的转换，取消了十进制转换，引入了2个8bit扩展位，并且对于不同区间的速率值使用不同的换算公式。协议对于AMBR换算描述如下：


本文以下行的octet3，octet5，octet7为例，上行与下行转换方法一致。

AMBR转换遵从以下准则：

1. octet5为0且octet7为0，直接参考octet3的值，转换公式见表2

2. octet7为0，octet5不为0，直接参考octet5最终转换值，转换公式见表2


3. octet7不为0，直接参考octet7的值，转换公式见表2

表2