案例一：分布问题导致下行呑吐率不达标问题

【故障类别】：分布系统

【现象描述】：宽窄巷子星巴克咖啡室分基站开通后，我们用B593S终端进行现场测试发现在RSRP和SINR极好的情况下下行吞吐率无法达到测试标准，查看基站配置为双流模式基站，下行呑吐率标准为50M以上，现场测试最高速率只能达到47M，具体情况如下：

下行呑吐率数据

【原因分析】：

1、通过测试数据分析发现该基站为双通道配置，两个通道口0和1在输出功率最大时相差32dBm,怀疑为双通道输出功率不一致导致下行速率无法达标，如下图所示：

可以看到两个通道的输出功率相差较大

【处理过程】：

1、而后后台配合我们将两个通道分别单开，测试其下行速率，如图：

通道口0

从上图可以看出通道口0由于输出功率低导致RSRP -100,下载速率平均只有36M;

通道口1

从上图可以看出通道口1输出功率正常，下载速率稳定在46M以上，以此确定该站的通道0输出功率问题导致下行呑吐率无法达标.

【建议与总结】：

该问题后经协商后由双通路改为单通路，并将通道0关闭处理，复测结果如下：

下图可以看出改为单流后下行呑吐率达到测试要求，下载速率稳定在46M以上.

案例二：基站热点区域异频优化案例

【故障类别】：参数类

【现象描述】：

高升桥室分站点热点区域优化，在对覆盖进行步测中发现，6F主要为2小区覆盖但受到3小区干扰下载速率不稳定；4\5F主要为3小区覆盖但受到1小区干扰下载速率不稳定；为此，将3小区频点由39050调整为39250（同1小区、2小区异频），调整后发现在原有的1、3小区切换点位置无法正常进行切换。

高升桥基站覆盖分布图：

5F同频切换点如图（中间电梯间仍然为1小区覆盖）：

【原因分析】：

通过分析，3小区调整为异频频点后同1小区发生的为异频切换，切换类型应为基于A4的切换，然在邻区列表中都一直无法检测异频邻区（后台已做异频邻区切换参数数据配置），进一步确定可能原因出现在终端未上报异频邻区测量，并观察信令及事件窗口，无A2事件相关消息。

由此，通知后台检测异频切换相关参数配置A2\A1\A4门限，发现后台配置均为默认值，均低于-100以下，门限设置过低，现场无法达到该门限值。

【处理过程】：

结合同频切换，在切换时，RSRP在-90dBm以上以及楼层覆盖情况，通知后台将A1停止异频测量门限配置为-75dBm，A2启动异频测量门限配置为-85dBm，A4异频切换门限配置为-90dBm后，异频切换正常，如下：

1、3小区间异频切换正常，同时由于进行异频的调整，该区域下载速率得到较大提升，达到预期优化效果。

【建议与总结】：在进行异频组网时，注意异频切换的相关参数配置。

案例三：合路接入TD分布系统故障导致下载速率不达标问题

【故障类别】：设备类

【现象描述】：

武侯办公区室分基站开通后，该基站为单小区配置基站，并下挂2个RRU，通过现场对2个RRU进行测试发现RRU1\RRU2的RSRP以及SINR都比较好，但是RRU2在测试过程中的Transmision Mode为TM2，Rank lndicator为Rank1，具体情况如下：

RRU1 Radio Paramrters

RRU1 RSRP走势图

RRU1 SINR走势图

RRU1下行吞吐率走势图

RRU2 Radio Paramrters

RRU2 RSRP走势图

RRU2 SINR走势图

RRU2下行吞吐率走势图

【原因分析】：

1、经过联系后台核查该小区下得2个RRU后台数据均配置的为双发双收；

2、核查工程安装图纸RRU1为独立的双通道配置、RRU2其中一路为独立的通道配置，另一路为与TD进行合路配置；

【处理过程】：

1、经过工程安装人员进行检查发现在耦合器与TD合路的接口未连接：

2、与工程安装人员取得联系了解该基站的安装情况得知由于在安装过程中工程队未找到设计图纸中的TD天线，因此RRU2只安装了一路天线，通过这一情况可以将问题定位为RRU2由于天线安装为单通道导致该RRU接收的为Rank1单流；

3、由于现场安装与设计不符合，因此告知安装人员对该RRU进行整改

4、通过安装人员整改后的复测观察，经过整改RRU2的Rank lndicator模式由Rank1变为Rank2，下载速率有了明显的提升，具体对比如下：

RRU2整改前Radio Paramrters

RRU2整改后Radio Paramrters

RRU2整改前下行吞吐率走势图

RRU2整改后下行吞吐率走势图

【 建议与总结】：

1、在工程安装过程中需要严格按照设计方案进行施工，如果再施工工程中由于其他因素导致无法按照设计方案完成需要及时反馈。

2、在进行室内分布系统测试过程中如果发现规划数据为双发双收，而实际测试为单发单收的情况，首先需要核查后台数据是否正常，在确保后台数据正常的情况下其次查看RB调用次数以及MCS调度阶数是否正常，如果未出现异常，那么问题就出现RRU至天线一侧，需要安装人员配合进行检查。

案例四：下行呑吐率“掉坑“毛刺问题

【故障类别】：传输

【现象描述】：

在CD LTE站点“CD分公司”单验过程中，该站5个RRU覆盖的平层，上行数据业务平稳正常，但下行数据业务速率呈现严重的“掉坑”毛刺问题，如例图：

对CD分公司的5个RRU覆盖平层进行测试，统计结果如下表：

【告警信息】：

框号为200的RRU的两个PATH存在1.5/1.6的驻波比

【原因分析】：

一、首先问题排查：

告警检查：

1. 检查eNodeB有无告警

2. 检查传输、CN有无告警

小区检查：

1. 检查待测试小区是否激活，确认小区状态

2. 检查基站标识、小区PCI是否正确，是否与工参一致

3. 检查小区天线权值是否配置，确认配置正确

4. 检查小区功率配置参数，确认是否因为特殊原因修改为低功率

传输检查：PING包，测试传输是否正常

终端检查：检查电脑是否已经进行了TCP窗口优化

二、空口无线质量：

（1）、下行SINR是否偏低：

1. 确认小区天线权值配置正确

2. 如果是外置天线，尝试拉大天线间距或更改两天线摆放位置

3. 更换测试地点

4. 排查干扰

（2）、下行MIMO模式是否正常：

1. 检查终端是否工作在TM3，RANK2

2. 检查基站license信息是否支持2x2 MIMO

3. 检查MIMO配置

4. 检查终端是否上报RANK2

5. 尝试固定TM3

（3）、下行调度次数是否足够：

1. 检查调度次数，是否满调度

2. 检查小区内是否单用户

3. 检查S1入口数据是否充足，是否上层给水量问题

4. 检查用户配置的AMBR和GBR是否大于空口速率

5. 检查DRX开关是否关闭

（4）、下行调度RB数是否足够：

1. 检查RB数是否足够

2. 检查频选调度是否关闭

3. 检查下行ICIC是否关闭

4. 检查Pa，Pb设置

（5）、查看下行MCS/BLER：

检查下行MCS是否高阶，下行BLER是否较小

（6）、查看空口信令：

检查空口信令是否有异常

三、判断是否为TCP问题

（1）、尝试UDP灌包

1. 如果无法UDP灌包，尝试多线程下载

2. 如果灌包或多线程下载时，流量明显高于TCP业务，进行TCP问题排查

3. 记录基站接收流量

【处理过程】：

对于以上下行呑吐率“掉坑、毛刺”问题，根据上述的原因分析步骤进行逐步核查：

1、告警核查：通过核查eNodeB、传输、CN告警信息，只有eNodeB侧存在驻波告警（框号为200的RRU的两个PATH存在1.5/1.6的驻波比），通过协调工程人员进行处理该RRU驻波比告警驻波（RRU型号为RRU3152e）：

楼层

RRU框号

小区

1F

206

1小区

2F

200

3F

201

4F

207

5F

202

通过对其中2楼天馈分布系统进行排查，框号为200的RRU的驻波比消除：1.3/1.1；驻波告警处理好之后，下行业务依然存在“掉坑”毛刺问题。

2、小区检查（子帧配置：1/7配比）、终端检查、空口无线质量检查，根据上述分析步骤逐步核查，通过网管（LMT）进行上行干扰检测以及无线空口质量排查，进行定点CQT测试，问题依然存在。

3、通过2副小天线分别接到RRU通道口进行验证测试，通过排除室分分布系统的问题，但通过现场选择好点（RSRP：-72.17dBm、RSRQ：35.63dB）测试验证，问题依然存在：

4、PING包，测试传输是否正常：

进行ping的命令操作（PING: SN=6, SRCIP='192.168.200.12', DSTIP='10.254.254.64', PKTSIZE=1460, ConTPING=DISABLE, TIMEOUT=5000, NUM=50, DSCP=18, APPTIF=NO;）

（1）未做业务测试时，ping操作（3次ping操作，每次ping“1460”数据包50次），无“ Request time out”问题现象；

（2）做业务测试时，ping操作（8次ping操作，每次ping“1460”数据包50次），无“ Request time out”问题现象。

5、判断是否为TCP问题，通过尝试UDP灌包

通过工具Wireshark抓包，文件处理，保存所需数据，打开数据，设置Wireshark，查看抓包统计，流量分析，查看专家信息，tcptrace图分析（发送窗口，接收窗口，RTT，重传等）

（1）使用Wireshark抓包（抓包操作步骤不详细阐述）

（2）对抓包文件进行处理，过滤TCP连接，保存所需数据

（3）重新打开保存后的文件，对Wireshark进行设置

（4）查看抓包统计

使用tcptrace图进行分析：正常情况下，如果TCP速率稳定，那么在TCP时序图上看到的将是一条笔直上升的斜线，它的斜率等于速率。tcptrace图中，中间黑色的粗线代表了发送的包，下方浅色的线代表上一个ACK确认的包序号，上方浅色的线代表TCP接收窗口，等于上一个TCP ACK序号加上win：

分析线段斜率发生变化的地方

观察线段是否有中断、重复、离散点等情况。直接点击tcptrace图中出问题的点在Wireshark包列表区中会直接跳转到对应的包。如下图，远离黑色线段主体的一小段黑色线段是重传包：

如下图，从图中可以看出，红色圈中的线段比较平，有较多的重传，需要点击进入Wireshark包列表区中分析重传的原因：

如果是重传很少或者没有重传，需要对发送和接收窗口进行分析。

通过对CD分公司LTE基站进行抓包分析，服务侧进行灌包测试：

服务器：iperf -c 10.255.255.14 -u -b 70M -i 1 -t 99999 -p 5012 -M 800B 备注：-M ：800、1000、1500

终端侧：iperf -s -u -i 1 -t 999 -p 5012

通过对该基站的抓包数据进行分析，FTP服务器到客户端存在丢包以及重传问题，导致速率波动及“掉坑”毛刺问题。

根据上述的分析排查，确定传输侧存在问题，协调传输侧进行相应的参数设置核查，经过传输侧核查分析结果：由于该LTE基站（成都分公司）PTN传输到核心机房较远且有2个PTN设备衔接而成，同时，在传输侧也存在一个传输带宽的限制（200M带宽限制）

一、通过传输侧进行修改测试验证：

（1）将PTN传输带宽不作限制，测试情况：

（2）传输侧进行带宽（900M、500M、300M）限制，测试情况如下图：

结论：对传输侧进行带宽限制后，为300M带宽时，下载速率存在严重的“毛刺”问题。

二、通过对传输侧带宽不作限制之后，测试效果达到（子帧配比：1/7的下载及上传速率要求且比较稳定）要求，但是通过对LTE的带宽需求分析，100M的足以满足需求，为何200M的带宽限制之后却会导致上述问题？

通过传输侧分析及最终的解决方案制定，通过在传输侧进行设置一定的缓存区：

（1）、传输侧对设置一定的缓存区（X值，X值设置传输同事未知会）、传输带宽设置为200M带宽限制（SINR：32.49dB；RSRP：-75dBm；PDCP Throughput DL：51.245 mbps）下载测试情况，如图（毛刺）：

（2）、传输侧对设置一定的缓存区（Y值，Y值设置传输同事未知会）、传输带宽设置为200M带宽限制（SINR：33.86 dB；RSRP：-77.01dBm；PDCP Throughput DL：58.428mbps）下载测试情况，如图（平稳）：

通过与传输侧协商，最终解决方案为设置一定的缓存区（Y值，Y值设置传输同事未知会），通过现场测试，效果达到预期测试标准，该下行下载业务的“掉坑”毛刺问题得到解决。

【建议与总结】：

对于一个问题的解决，需要协同产品、优化、传输、核心网等方面一起协同解决。