LTE 最新网络优化案例

1、网优案例目录1分布问题导致下行呑吐率不达标问题32高升桥基站热点区域异频优化案例63合路接入TD分布系统故障导致下载速率不达标问题94下行呑吐率“掉坑“毛刺问题145B593 PDN拒绝问题216RSRP过高导致下载速率不稳定问题237外部小区及邻区冗余导致无法切换问题271 分布问题导致下行呑吐率不达标问题 题目：分布问题导致下行呑吐率不达标问题 故障类别：分布系统 关键字：B593S、下行呑吐率 现象描述：宽窄巷子星巴克咖啡室分基站开通后，我们用B593S终端进行现场测试发现在RSRP和SINR极好的情况下下行吞吐率无法达到测试标准，查看基站配置为双

2、流模式基站，下行呑吐率标准为50M以上，现场测试最高速率只能达到47M，具体情况如下：下行呑吐率数据 告警信息：无 原因分析：1、通过测试数据分析发现该基站为双通道配置，两个通道口0和1在输出功率最大时相差32dBm,怀疑为双通道输出功率不一致导致下行速率无法达标，如下图所示：可以看到两个通道的输出功率相差较大； 处理过程：1、而后后台配合我们将两个通道分别单开，测试其下行速率，如图：通道口0从上图可以看出通道口0由于输出功率低导致RSRP<-100,下载速率平均只有36M;通道口1从上图可以看出通道口1输出功率正常，下载速率稳定在46M以上，以此确定该站的

3、通道0输出功率问题导致下行呑吐率无法达标 建议与总结：该问题后经协商后由双通路改为单通路，并将通道0关闭处理，复测结果如下：下图可以看出改为单流后下行呑吐率达到测试要求，下载速率稳定在46M以上；2 高升桥基站热点区域异频优化案例 题目：高升桥基站热点区域异频优化案例 故障类别：参数类 关键字：异频切换  现象描述：高升桥室分站点热点区域优化，在对覆盖进行步测中发现，6F主要为2小区覆盖但受到3小区干扰下载速率不稳定；45F主要为3小区覆盖但受到1小区干扰下载速率不稳定；为此，将3小区频点由39050调整为39250（同1小区、2小区

4、异频），调整后发现在原有的1、3小区切换点位置无法正常进行切换。高升桥基站覆盖分布图：楼层11左侧电梯10右侧电梯987654321B1FB2F5F同频切换点如图（中间电梯间仍然为1小区覆盖）： 告警信息：无 原因分析：通过分析，3小区调整为异频频点后同1小区发生的为异频切换，切换类型应为基于A4的切换，然在邻区列表中都一直无法检测异频邻区（后台已做异频邻区切换参数数据配置），进一步确定可能原因出现在终端未上报异频邻区测量，并观察信令及事件窗口，无A2事件相关消息。由此，通知后台检测异频切换相关参数配置A2A1A4门限，发现后台配置均为默认值，均低于-100以下，门限设置过

5、低，现场无法达到该门限值。 处理过程：结合同频切换，在切换时，RSRP在-90dBm以上以及楼层覆盖情况，通知后台将A1停止异频测量门限配置为-75dBm，A2启动异频测量门限配置为-85dBm，A4异频切换门限配置为-90dBm后，异频切换正常，如下：1、3小区间异频切换正常，同时由于进行异频的调整，该区域下载速率得到较大提升，达到预期优化效果。 建议与总结：在进行异频组网时，注意异频切换的相关参数配置。3 合路接入TD分布系统故障导致下载速率不达标问题 题目：合路接入TD分布系统故障导致下载速率不达标问题 故障类别：设备类 关键字：双发双收

6、、TM2、TM3 现象描述：武侯办公区室分基站开通后，该基站为单小区配置基站，并下挂2个RRU，通过现场对2个RRU进行测试发现RRU1RRU2的RSRP以及SINR都比较好，但是RRU2在测试过程中的Transmision Mode为TM2，Rank lndicator为Rank1，具体情况如下：RRU1 Radio ParamrtersRRU1 RSRP走势图RRU1 SINR走势图RRU1下行吞吐率走势图RRU2 Radio ParamrtersRRU2 RSRP走势图RRU2 SINR走势图RRU2下行吞吐率走势图 告警信息：无 原因分析：1、经过联系后台

7、核查该小区下得2个RRU后台数据均配置的为双发双收；2、核查工程安装图纸RRU1为独立的双通道配置、RRU2其中一路为独立的通道配置，另一路为与TD进行合路配置；21、经过工程安装人员进行检查发现在耦合器与TD合路的接口未连接：2、与工程安装人员取得联系了解该基站的安装情况得知由于在安装过程中工程队未找到设计图纸中的TD天线，因此RRU2只安装了一路天线，通过这一情况可以将问题定位为RRU2由于天线安装为单通道导致该RRU接收的为Rank1单流；3、由于现场安装与设计不符合，因此告知安装人员对该RRU进行整改4、通过安装人员整改后的复测观察，经过整改RRU2的Rank lndicator模式由

8、Rank1变为Rank2，下载速率有了明显的提升，具体对比如下： RRU2整改前Radio Paramrters RRU2整改后Radio ParamrtersRRU2整改前下行吞吐率走势图RRU2整改后下行吞吐率走势图 建议与总结：1、在工程安装过程中需要严格按照设计方案进行施工，如果再施工工程中由于其他因素导致无法按照设计方案完成需要及时反馈。2、在进行室内分布系统测试过程中如果发现规划数据为双发双收，而实际测试为单发单收的情况，首先需要核查后台数据是否正常，在确保后台数据正常的情况下其次查看RB调用次数以及MCS调度阶数是否正常，如果未出现异常，那么问题就出现RRU至天线一侧，

9、需要安装人员配合进行检查。4 下行呑吐率“掉坑“毛刺问题题目：下行呑吐率“掉坑“毛刺问题故障类别：传输 关键字：掉坑、灌包、传输现象描述：在成都LTE站点“成都分公司”单验过程中，该站5个RRU覆盖的平层，上行数据业务平稳正常，但下行数据业务速率呈现严重的“掉坑”毛刺问题，如例图：对成都分公司的5个RRU覆盖平层进行测试，统计结果如下表：测试地点5个RRU覆盖5个平层（只解闭塞测试楼层RRU）下行吞吐量(Mbps)RSRP(dBm)SINR(dB)CQI PDSCH BLER（%）MCS (code 0) 每子帧平均RB数成都分公司1F42.8-68.1634.1614.55#DIV

10、/0!27.6164.16成都分公司2F42.49-79.1735.6314.450.2127.7163.41成都分公司3F44.48-65.334.7914.55#DIV/0!27.7365.64成都分公司4F44.34-64.1135.2414.82#DIV/0!27.866成都分公司5F43.44-63.4934.6314.421.1627.3565.87告警信息：框号为200的RRU的两个PATH存在1.5/1.6的驻波比原因分析：一、首先问题排查：告警检查： 1. 检查eNodeB有无告警 2. 检查传输、CN有无告警小区检查：1. 检查待测试小区是否激活，确认小区状态 2. 检查基

11、站标识、小区PCI是否正确，是否与工参一致 3. 检查小区天线权值是否配置，确认配置正确 4. 检查小区功率配置参数，确认是否因为特殊原因修改为低功率传输检查：PING包，测试传输是否正常终端检查：检查电脑是否已经进行了TCP窗口优化二、空口无线质量：（1）、下行SINR是否偏低：1. 确认小区天线权值配置正确2. 如果是外置天线，尝试拉大天线间距或更改两天线摆放位置3. 更换测试地点4. 排查干扰（2）、下行MIMO模式是否正常：1. 检查终端是否工作在TM3，RANK22. 检查基站license信息是否支持2x2 MIMO3. 检查MIMO配置4. 检查终端是否上报RANK25. 尝试固

12、定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. 如果灌包或多线程下载时，流

13、量明显高于TCP业务，进行TCP问题排查3. 记录基站接收流量处理过程：对于以上下行呑吐率“掉坑、毛刺”问题，根据上述的原因分析步骤进行逐步核查：1、告警核查：通过核查eNodeB、传输、CN告警信息，只有eNodeB侧存在驻波告警（框号为200的RRU的两个PATH存在1.5/1.6的驻波比），通过协调工程人员进行处理该RRU驻波比告警驻波（RRU型号为RRU3152e）：楼层RRU框号小区1F2061小区2F2003F2014F2075F202通过对其中2楼天馈分布系统进行排查，框号为200的RRU的驻波比消除：1.3/1.1；驻波告警处理好之后，下行业务依然存在“掉坑”毛刺问题。2、小区

14、检查（子帧配置：1/7配比）、终端检查、空口无线质量检查，根据上述分析步骤逐步核查，通过网管（LMT）进行上行干扰检测以及无线空口质量排查，进行定点CQT测试，问题依然存在。3、通过2副小天线分别接到RRU通道口进行验证测试，通过排除室分分布系统的问题，但通过现场选择好点（RSRP：-72.17dBm、RSRQ：35.63dB）测试验证，问题依然存在：4、PING包，测试传输是否正常：进行ping的命令操作（PING: SN=6, SRCIP="2", DSTIP="4", PKTSIZE=1460, C

15、ONTPING=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图分析（

16、发送窗口，接收窗口，RTT，重传等）（1） 使用Wireshark抓包（抓包操作步骤不详细阐述）（2） 对抓包文件进行处理，过滤TCP连接，保存所需数据 （3） 重新打开保存后的文件，对Wireshark进行设置（4） 查看抓包统计 使用tcptrace图进行分析：正常情况下，如果TCP速率稳定，那么在TCP时序图上看到的将是一条笔直上升的斜线，它的斜率等于速率。tcptrace图中，中间黑色的粗线代表了发送的包，下方浅色的线代表上一个ACK确认的包序号，上方浅色的线代表TCP接收窗口，等于上一个TCP ACK序号加上win：分析线段斜率发生变化的地方观察线段是否有中断、重复、离散点等情况。直

17、接点击tcptrace图中出问题的点在Wireshark包列表区中会直接跳转到对应的包。如下图，远离黑色线段主体的一小段黑色线段是重传包：如下图，从图中可以看出，红色圈中的线段比较平，有较多的重传，需要点击进入Wireshark包列表区中分析重传的原因：如果是重传很少或者没有重传，需要对发送和接收窗口进行分析。通过对成都分公司LTE基站进行抓包分析，服务侧进行灌包测试：服务器：iperf -c 4 -u -b 70M -i 1 -t 99999 -p 5012 -M 800B 备注：-M ：800、1000、1500终端侧：iperf -s -u -i 1 -t 999

18、 -p 5012通过对该基站的抓包数据进行分析，FTP服务器到客户端存在丢包以及重传问题，导致速率波动及“掉坑”毛刺问题。根据上述的分析排查，确定传输侧存在问题，协调传输侧进行相应的参数设置核查，经过传输侧核查分析结果：由于该LTE基站（成都分公司）PTN传输到核心机房较远且有2个PTN设备衔接而成，同时，在传输侧也存在一个传输带宽的限制（200M带宽限制）一、通过传输侧进行修改测试验证：（1）将PTN传输带宽不作限制，测试情况：测试地点下行吞吐量(mbps)上行行吞吐量(mbps)RSRP(dBm)SINR(dB)备注成都分公司1F58.38414.768-74.03434.806速率平稳，

19、无毛刺问题成都分公司2F57.98714.681-76.02934.9536速率平稳，无毛刺问题成都分公司3F59.22714.885-70.22933.796速率平稳，无毛刺问题成都分公司4F57.11514.778-70.2435.096速率平稳，无毛刺问题成都分公司5F58.97514.883-71.07134.622速率平稳，无毛刺问题（2）传输侧进行带宽（900M、500M、300M）限制，测试情况如下图：结论：对传输侧进行带宽限制后，为300M带宽时，下载速率存在严重的“毛刺”问题。二、通过对传输侧带宽不作限制之后，测试效果达到（子帧配比：1/7的下载及上传速率要求且比较稳定）要求

20、，但是通过对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 D

21、L：58.428mbps）下载测试情况，如图（平稳）： 通过与传输侧协商，最终解决方案为设置一定的缓存区（Y值，Y值设置传输同事未知会），通过现场测试，效果达到预期测试标准，该下行下载业务的“掉坑”毛刺问题得到解决。建议与总结： 对于一个问题的解决，需要协同产品、优化、传输、核心网等方面一起协同解决。5 B593 PDN拒绝问题题目：B593 PDN拒绝问题故障类别：终端 关键字：PDN拒绝现象描述： 在测试过程中，B593层三信令经常出现PDN拒绝问题，有时候会做不了业务告警信息：无原因分析：在页面中配置了非法APN所以一般就选择Auto APN即可，因为展厅环境没有VOIP，必须

22、要把WEBUI上的VOIP APN信息删除，否则会出现如下PDN建立被拒情况：处理过程：处理过程：在非连接模式，登录web界面，按照左边的导航，进入APN编辑页面，（该界面必须在插入硬卡的条件下才可以看到）将VOIP对应的APN设置为manual接入，并设置为disconnected状态。1、  首先将Voice Connect的连接模式设置为手动，然后点击 提交 按钮。2、如果连接状态变为 连接态，则接入成功。建议与总结：新到的CPE均需要修改6 RSRP过高导致下载速率不稳定问题 题目：RSRP过高导致下载速率不稳定问题 故障类别：终端类 关键字：B

23、593S、RSRP  现象描述：音乐公园室分基站开通后，我们用B593S终端进行现场测试发现在RSRP和SINR极好的情况下下行吞吐率出现比较明显和频繁的掉坑现象，下载速率极为不稳定并且在测试过程中较为频繁的出现终端脱网状态，具体情况如下：RSRP走势图SINR走势图下行吞吐率走势图BLER走势图 告警信息：无 原因分析：1、通过测试数据分析发现在每次下行吞吐率掉坑的时候均出现较高的BLER，初步怀疑现场存在外部干扰，但是通过在距离该处5M左右距离的地方再次进行测试RSRP、SINR、下行吞吐率均极为稳定，并且BLER值较低，从而排除了外部干扰的问题；2

24、、在测试的过程中我们发现在部分地点终端要出现脱网状态，并且该状态随着距离天线越近越出现频率越频繁，在我们走到天线正下方时候终端彻底脱离网，无法再次进行业务工作：可以看到在天线下方终端无信号；此时已经怀疑到终端接收能力问题，在联系相应人员后得知在输入电平最大值超过-25dbm时，会导致接收机前段的LNA等器件出现饱和失真，接收通道误码偏高，从而导致吞吐率不稳定； 处理过程：1、降低RS功率，在降低RS功率后进行复测，我们发现在测试点位置RSRP依然较高，吞吐率依旧无法稳定在峰值速率；2、增加10dbm衰减器从而再一次降低终端接收电平，本次调整后问题得到解决；复测结果：在进行以上两个步骤

25、的调整后进行复测，结果较为理想下载速率较为稳定，具体如下：PCI频点测试点1测试点2测试点3备注RSRPSINR下行吞吐率RSRPSINR下行吞吐率RSRPSINR下行吞吐率039050-48.9429.3156.78-58.2633.6556.75-52.7826.4613.07RS 152039050-64.5933.4257.71-72.4332.1158.78-68.8733.7758.87RS 62/增加10dbm衰减器RSRP走势图SINR走势图下行吞吐率走势图BLER走势图 建议与总结：在进行室内分布系统设计的时候不能一味的追求高RSRP，在RSRP过高（>-55

26、dbm）的时候终端的LNA等器件出现饱和失真，接收通道误码偏高，从而导致吞吐率不稳定，建议在进行室分系统设计的时候保证终端接收功率在-60dbm以下。7 外部小区及邻区冗余导致无法切换问题 题目：外部小区及邻区冗余导致无法切换问题 故障类别：参数类 关键字：E5776S、切换  现象描述：在对久远饮食基站进行单站点验证过程中，二环路由北向南行驶，终端占用英雄鱼头-3小区（PCI：138）频繁发起向久远饮食-1（PCI：374）的A3切换事件，但无法完成切换，导致掉线。 告警信息：SCTP链路故障告警 原因分析：1、核查英雄鱼

27、头-3小区邻区关系，已做久远饮食-1小区邻区数据，并对该站添加的久远饮食-1小区外部小区数据进行核查，外部小区无误；2、进一步对英雄鱼头基站外部小区和邻区数据进行核查，发现存在尖东望座站点相关数据，详细如下：该站点数据经核查为冗余数据，且同久远饮食基站存在相同的“基站标识”和“小区PCI”,小区标识不同。久远饮食基站信息如下：3、通过上述分析，初步判断为英雄鱼头-3小区向久远饮食-1小区发起的切换错发向了不存在的尖东望座基站，导致切换无法正常完成。 处理过程：1、 后台删除英雄鱼头邻区及外部小区中的尖东望座基站冗余数据；2、 现场进行复查，切换正常，如图： 建议与总结：1、

28、 明确切换数据查找流程：终端监测信号，上报目标小区PCIà基站判决符合切换条件，根据小区表、邻区表和外部小区表确定目标小区à通知目标基站准备，并向终端下发切换消息包含目标小区信息à终端根据收到的切换目标小区信息在目标小区进行接入2、 终端频繁发起A3切换请求，但是一直未发起切换，可能原因就有：一是没做邻区数据；二是外部小区属性错误；三是冗余数据导致切换消息错误发送；四是其他问题。本案例就是属于外部小区和邻区数据中存在冗余记录导致切换消息错误发送造成不能切换从而导致掉线。3、 后台需定期对冗余数据进行清除。8 MOD3干扰问题 题目：MOD3干扰问题

29、60;故障类别：干扰 关键字：下行呑吐率 现象描述：在东门桥测试,UE占用望园宾馆-1小区信号，RSRP为-82dBm，SINR为2dB，干扰较严重，下载速率低，具体情况如下：测试截图 告警信息：无 原因分析：在东门桥测试,UE占用望园宾馆-1小区信号，RSRP为-82dBm，SINR为2dB，干扰较严重，查看邻区列表中银杏大厦-1小区RSRP为-81dBm，与服务小区电平相当，且望园宾馆-1小区PCI=206，银杏大厦-1小区PCI=212,存在MOD3干扰，导致SINR较差。这两个站点为相邻站点，属于PCI规划不合理导致，通过对周围站点PCI分布分析

30、，调整PCI比较困难，所以通过RF优化问题解决 处理过程：通过对周围站点PCI分布分析，调整PCI比较困难，因此通过RF优化调整控制银杏大厦-1小区覆盖，银杏大厦-1小区下倾角从4度调整到7度，调整后该路段SINR从2db升高到12db，复测结果如下： 建议与总结：对MOD3干扰优化可以有如下措施：1、调整PCI优化调整；2、RF优化调整，控制邻区覆盖降低邻区RSRP；3、功率调整，控制邻区覆盖降低邻区RSRP等优化措施9 Mifi网络连接设置问题导致开机无服务 题目：Mifi网络连接设置问题导致开机无服务 故障类别：终端设置 关键字：无服务&

31、#160;现象描述：某地用户投诉4G信号差，无网络服务。 告警信息：无 原因分析：1、 投诉区域为网络覆盖盲区；2、 基站存在告警；3、 SIM卡数据问题；4、 终端设置问题； 处理过程：1、投诉用户为商用前VIP客户，首先确认投诉区域网络覆盖是否是无覆盖，通过现场测试覆盖较好，数据业务能满足用户需求，排除因为覆盖而引起的无信号问题。 RSRP SINR 下载速率 上传速率2、联系后台查询基站最近3天无告警；3、将用户mifi的SIM卡与测试SIM卡互换后，测试MIFI能正常入网，而用户MIFI仍然无服务，确定用户mifi问题。4、将用户MIFI连接电脑进入192

32、.168.1.1页面后发现用户mifi存在设置问题，具体设置如下：进入页面后，在连接设置里面，移动网络设置为“打开”。网络设置里面 网络首选方式为：仅4G 5、设置后重启，mifi正常搜索到4G网络，且连接外网正常； 建议与总结：网络无服务投诉基本可以分步排除，首先排除是否为覆盖方面引起的无信号（如：覆盖漏洞、基站告警引起的覆盖漏洞）；其次通过卡机互换确定是终端问题还是SIM数据问题，确定问题出现在那个环节，并分析处理。10 TAU更新失败问题 题目：TAU更新失败问题 故障类别：位置区域更新失败 关键字：位置区域更新 现

33、象描述：长呼测试时，在东华门街与东华正街交界处，出现一次TAU更新失败，具体情况如下：测试截图 告警信息：无 原因分析：通过对周围环境和测试数据分析，是由于远东百货-3小区（RSRP-96dbm）在东华门街信号突然高于茂业百货-3小区（RSRP-101dbm），所以UE从茂业百货-3切换到远东百货-3，之后一直占用远东百货-3小区，而切换到RSRP为-81dbm的华瑞商务楼-3小区，所以该路段RSRP一直下降到-141dbm而导致弱覆盖，且远东百货和华瑞商务楼不属于同一位置区，因此发起位置区域更新请求，但在发起位置区域更新请求时，已经是弱覆盖（RSRP-141dbm），所以

34、导致位置区域更新请求失败。 处理过程：添加远东百货-3和华瑞商务楼-3小区双向邻区关系，添加邻区后及时发起切换，避免由于弱覆盖导致位置区域更新失败。处理结果如下图所示： 建议与总结：由于远东百货是FAD天线不能调整，所以建议添加远东百货-3和华瑞商务楼-3小区双向邻区关系，添加邻区后及时发起切换，避免由于弱覆盖导致位置区域更新失败11 不同设备类型RRU，设备偏置不一致导致干扰，影响上行速率题目：不同设备类型RRU，设备偏置不一致导致干扰，影响上行速率故障类别：RRU设备 关键字：上行速率偏低、RRU、RRU偏置现象描述：“洲际酒店一-3”小区上行速率低（下行速率

35、正常），多次测试内基本都是小于3Mbps（该小区的两个RRU均是该现象）小区名称RSRP（dBm）SINR（dB）平均下子速率(Mbps)平均上传速率(Mbps)说明洲际酒店一-1-752749.38.2单流，上传下载均正常洲际酒店一-2-693481.36双流，下载正常、上传偏低洲际酒店一-3-7130.581.82.1双流，下载正常、上传不达标告警信息：无告警原因分析：11.1 前台测试数据分析从测试数据来看，RSRP为-76dBm，SINR为35dB，BLER为0%，CQI为14，无线环境很好，但是从测试数据来看，导致上传速率仅为2Mbps的直接原因是上行调度数在180左右，UL-MCS

36、期望阶数在7左右， UL-MCS阶数很低。11.2 后台干扰查询查询后台洲际酒店一-3小区上行无干扰，排除上行干扰导致上传速率低。11.3 设置CPE PUSCH最大发射功率验证设置CPE PUSCH最大发射功率为23后，上传平均速率为9.6Mbps，且很平稳，如下图：11.4 3小区RRU测试验证在洲际酒店一-3小区的RRU下直接连接2个室分天线，经测试，RSRP在-60dBm以上时，上传速率可以达到8.8Mbps，但是当RSRP低于-70dBm时，上传速率仅为2Mbps左右，如下图所示：RSRP小于-70dBm时，速率为2Mbps左右RSRP大于-60dBm时，速率为9Mbps左右11.5

37、 2、3小区互换光纤测试机房查看洲际酒店一3小区光纤位置，其中2、3小区光纤插在同一个LBBP单板上， 1小区单独插在一个单板上。由于设计小区为单流，2、3小区为双流，由于2、3小区上传速率差异较大，更换2、3小区光纤查看问题是否仍存在。经现场测试，2、3小区互换光纤后，原3小区覆盖楼层上传速率小于1Mbps，下载速率正常，如下：原3小区覆盖区域上传测试原3小区覆盖区域下载测试11.6 LBBP单板互换由于洲际酒店一-1小区在LBBP单板1上，洲际酒店一-2、3小区在LBBP单板2上，两块单板分别位于1、4号槽位。通过互换两块LBBP单板的位置，排查LBBP单板是否存在异常。经现场测试，更换L

38、BBP单板后测试结果与更换单板前测试结果一直，说明两块LBBP单板都没有问题。11.7 闭小区单独测试将洲际酒店一-1、2小区去激活，单独测试3小区上传速率为9.5Mbps,依次激活2小区，小区速率变化如下：步骤测试方案平均上传速率(Mbps)对比说明步骤1洲际酒店一-1、2小区均去激活，测试3小区上传速率9.5与测试1小区上传速率接近步骤2洲际酒店一-1去激活， 2小区激活，测试3小区上传速率7.5与测试2小区上传速率接近步骤3洲际酒店一-1、2小区均激活，测试3小区上传速率2.2与测试3小区上传速率接近步骤4洲际酒店一-1激活， 2小区去激活，测试3小区上传速率2.5与测试3小区上传速率接近步骤13测试3小区平均上传速率与分别于验证1、2、3小区平均上传速率结果相似（如问题现象）。洲际酒店一-3小区上传速率变化图11.8 闭RRU单独测试由于洲际酒店一的3个小区均级联2个RRU，结合上面闭小区的测试结果，进一步排查RRU级联对洲际酒店一-3小区上传速率是否存在影响。步