网优案例目录1分布问题导致下行呑吐率不达标问题 (3)2高升桥基站热点区域异频优化案例 (6)3合路接入TD分布系统故障导致下载速率不达标问题 (9)4下行呑吐率“掉坑“毛刺问题 (14)5B593 PDN拒绝问题 (21)6RSRP过高导致下载速率不稳定问题 (23)7外部小区及邻区冗余导致无法切换问题 (27)1 分布问题导致下行呑吐率不达标问题象描述：宽窄巷子星巴克咖啡室分基站开通后，我们用B593S终端进行现场测试发现在RSRP和SINR极好的情况下下行吞吐率无法达到测试标准，查看基站配置为双流模式基站，下行呑吐率标准为50M以上，现场测试最高速率只能达到47M，具体情况如下：下行呑吐率数据可以看到两个通道的输出功率相差较大；处1、而后后台配合我们将两个通道分别单开，测试其下行速率，如图：理过程：通道口0从上图可以看出通道口0由于输出功率低导致RSRP<-100,下载速率平均只有36M;通道口1从上图可以看出通道口1输出功率正常，下载速率稳定在46M以上，以此确定该站的通道0输出功率问题导致下行呑吐率无法达标建议与总结：该问题后经协商后由双通路改为单通路，并将通道0关闭处理，复测结果如下：下图可以看出改为单流后下行呑吐率达到测试要求，下载速率稳定在46M以上；2 高升桥基站热点区域异频优化案例程：结合同频切换，在切换时，RSRP在-90dBm以上以及楼层覆盖情况，通知后台将A1停止异频测量门限配置为-75dBm，A2启动异频测量门限配置为-85dBm，A4异频切换门限配置为-90dBm后，异频切换正常，如下：1、3小区间异频切换正常，同时由于进行异频的调整，该区域下载速率得到较大提升，达到预期优化效果。
3 合路接入TD分布系统故障导致下载速率不达标问题述：武侯办公区室分基站开通后，该基站为单小区配置基站，并下挂2个RRU，通过现场对2个RRU进行测试发现RRU1\RRU2的RSRP以及SINR都比较好，但是RRU2在测试过程中的Transmision Mode为TM2，Rank lndicator为Rank1，具体情况如下：RRU1 Radio ParamrtersRRU1 RSRP走势图RRU1 SINR走势图RRU1下行吞吐率走势图RRU2 Radio ParamrtersRRU2 RSRP走势图RRU2 SINR走势图RRU2下行吞吐率走势图1、经过工程安装人员进行检查发现在耦合器与TD合路的接口未连接：2、与工程安装人员取得联系了解该基站的安装情况得知由于在安装过程中工程队未找到设计图纸中的TD天线，因此RRU2只安装了一路天线，通过这一情况可以将问题定位为RRU2由于天线安装为单通道导致该RRU接收的为Rank1单流；3、由于现场安装与设计不符合，因此告知安装人员对该RRU进行整改4、通过安装人员整改后的复测观察，经过整改RRU2的Rank lndicator模式由Rank1变为Rank2，下载速率有了明显的提升，具体对比如下：RRU2整改前Radio Paramrters RRU2整改后Radio ParamrtersRRU2整改前下行吞吐率走势图RRU2整改后下行吞吐率走势图4 下行呑吐率“掉坑“毛刺问题现象描述：在成都LTE站点“成都分公司”单验过程中，该站5个RRU覆盖的平层，上行数据业务平稳正常，但下行数据业务速率呈现严重的“掉坑”毛刺问题，如例图：对成都分公司的5个RRU覆盖平层进行测试，统计结果如下表：测试地点5个RRU覆盖5个平层（只解闭塞测试楼层RRU）下行吞吐量(Mbps) RSRP(dBm) SINR(dB) CQI PDSCH BLER（%）MCS (code 0) 每子帧平均RB数成都分公司1F 42.8 -68.16 34.16 14.55 #DIV/0! 27.61 64.16 成都分公司2F 42.49 -79.17 35.63 14.45 0.21 27.71 63.41 成都分公司3F 44.48 -65.3 34.79 14.55 #DIV/0! 27.73 65.64 成都分公司4F 44.34 -64.11 35.24 14.82 #DIV/0! 27.8 66 成都分公司5F 43.44 -63.49 34.63 14.42 1.16 27.35 65.87楼层 RRU 框号 小区1F 206 1小区 2F 200 3F 201 4F 207 5F202通过对其中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包列表区中分析重传的原因：如果是重传很少或者没有重传，需要对发送和接收窗口进行分析。
通过对成都分公司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传输带宽不作限制，测试情况：测试地点下行吞吐量(mbps) 上行行吞吐量(mbps) RSRP(dBm) SINR(dB) 备注成都分公司1F 58.384 14.768 -74.034 34.806 速率平稳，无毛刺问题成都分公司2F 57.987 14.681 -76.029 34.9536 速率平稳，无毛刺问题成都分公司3F 59.227 14.885 -70.229 33.796 速率平稳，无毛刺问题成都分公司4F 57.115 14.778 -70.24 35.096 速率平稳，无毛刺问题成都分公司5F 58.975 14.883 -71.071 34.622 速率平稳，无毛刺问题（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值设置传输同事未知会），通过现场测试，效果达到预期测试标准，该下行下载业务的“掉坑”毛刺问题得到解决。
5 B593 PDN拒绝问题在页面中配置了非法APN——所以一般就选择Auto APN即可，因为展厅环境没有VOIP，必须要把WEBUI上的VOIP APN信息删除，否则会出现如下PDN建立被拒情况：处理过程：2、如果连接状态变为连接态，则接入成功。
6 RSRP过高导致下载速率不稳定问题音乐公园室分基站开通后，我们用B593S终端进行现场测试发现在RSRP和SINR极好的情况下下行吞吐率出现比较明显和频繁的掉坑现象，下载速率极为不稳定并且在测试过程中较为频繁的出现终端脱网状态，具体情况如下：RSRP走势图SINR走势图下行吞吐率走势图BLER走势图1、通过测试数据分析发现在每次下行吞吐率掉坑的时候均出现较高的BLER，初步怀疑现场存在外部干扰，但是通过在距离该处5M左右距离的地方再次进行测试RSRP、SINR、下行吞吐率均极为稳定，并且BLER值较低，从而排除了外部干扰的问题；2、在测试的过程中我们发现在部分地点终端要出现脱网状态，并且该状态随着距离天线越近越出现频率越频繁，在我们走到天线正下方时候终端彻底脱离网，无法再次进行业务工作：可以看到在天线下方终端无信号；此时已经怀疑到终端接收能力问题，在联系相应人员后得知在输入电平最大值超过-25dbm 时，会导致接收机前段的LNA等器件出现饱和失真，接收通道误码偏高，从而导致吞吐率不稳定；0 39050 -48.94 29.31 56.78 -58.26 33.65 56.75 -52.78 26.46 13.07 RS 1520 39050 -64.59 33.42 57.71 -72.43 32.11 58.78 -68.87 33.77 58.87 RS 62/增加10dbm 衰减器RSRP走势图SINR走势图下行吞吐率走势图BLER走势图7 外部小区及邻区冗余导致无法切换问题述：在对久远饮食基站进行单站点验证过程中，二环路由北向南行驶，终端占用英雄鱼头-3小区（PCI：138）频繁发起向久远饮食-1（PCI：374）的A3切换事件，但无法完成切换，导致掉线。