网优案例
目录
1 2 3 4 5 6 7
分布问题导致下行呑吐率不达标问题 ................................................................................... 3 高升桥基站热点区域异频优化案例 ....................................................................................... 6 合路接入TD分布系统故障导致下载速率不达标问题 .......................................................... 9 下行呑吐率“掉坑“毛刺问题 ............................................................................................. 14 B593 PDN拒绝问题 ............................................................................................................... 21 RSRP过高导致下载速率不稳定问题 ................................................................................... 23 外部小区及邻区冗余导致无法切换问题 ............................................................................. 27
1 分布问题导致下行呑吐率不达标问题
题分布问题导致下行呑吐率不达标问题 目: 故障类分布系统 别: 现宽窄巷子星巴克咖啡室分基站开通后,我们用B593S终端进行现场测试发现在RSRP和SINR极好 关键字: B593S、下行呑吐率 象描的情况下下行吞吐率无法达到测试标准,查看基站配置为双流模式基站,下行呑吐率标准为50M以述: 上,现场测试最高速率只能达到47M,具体情况如下: 下行呑吐率数据 告警信无 息: 原因分析: 1、通过测试数据分析发现该基站为双通道配置,两个通道口0和1在输出功率最大时相差32dBm,怀疑为双通道输出功率不一致导致下行速率无法达标,如下图所示:
可以看到两个通道的输出功率相差较大; 处理过程: 1、而后后台配合我们将两个通道分别单开,测试其下行速率,如图: 通道口0 从上图可以看出通道口0由于输出功率低导致RSRP<-100,下载速率平均只有36M;
通道口1 从上图可以看出通道口1输出功率正常,下载速率稳定在46M以上,以此确定该站的通道0输出功率问题导致下行呑吐率无法达标 建总结: 该问题后经协商后由双通路改为单通路,并将通道0关闭处理,复测结果如下: 议与下图可以看出改为单流后下行呑吐率达到测试要求,下载速率稳定在46M以上;
2 高升桥基站热点区域异频优化案例
题高升桥基站热点区域异频优化案例 目: 故障类别: 现象描高升桥室分站点热点区域优化,在对覆盖进行步测中发现,6F主要为2小区覆盖但受到3小区干扰下载速率不稳定;4\\5F主要为3小区覆盖但受到1小区干扰下载速率不稳定;为此,将3小区频点由39050调整为39250(同1小区、2小区异频),调整后发现在原有的1、3小区切换点位置无法高升桥基站覆盖分布图: 参数类 关键字: 异频切换 述: 正常进行切换。 楼层 11 10 9 8 7 6 左侧电梯 5 4 3 2 1 B1F B2F 右侧电梯 5F同频切换点如图(中间电梯间仍然为1小区覆盖):
告警信息: 原因分通过分析,3小区调整为异频频点后同1小区发生的为异频切换,切换类型应为基于A4的切换,然在邻区列表中都一直无法检测异频邻区(后台已做异频邻区切换参数数据配置),进一步确定可能原因出现在终端未上报异频邻区测量,并观察信令及事件窗口,无A2事件相关消息。 0以下,门限设置过低,现场无法达到该门限值。 处理过程: 结合同频切换,在切换时,RSRP在-90dBm以上以及楼层覆盖情况,通知后台将A1停止异频测量门限配置为-75dBm,A2启动异频测量门限配置为-85dBm,A4异频切换门限配置为-90dBm后,异频切换正常,如下: 无 析: 由此,通知后台检测异频切换相关参数配置A2\\A1\\A4门限,发现后台配置均为默认值,均低于-10 1、3小区间异频切换正常,同时由于进行异频的调整,该区域下载速率得到较大提升,达到预期优化效果。 建
在进行异频组网时,注意异频切换的相关参数配置。
议与总结:
3 合路接入TD分布系统故障导致下载速率不达标问题
题合路接入TD分布系统故障导致下载速率不达标问题 目: 故障类别: 现象描述: 武侯办公区室分基站开通后,该基站为单小区配置基站,并下挂2个RRU,通过现场对2个RRU进行测试发现RRU1\\RRU2的RSRP以及SINR都比较好,但是RRU2在测试过程中的Transmision Mode为TM2,Rank lndicator为Rank1,具体情况如下: 设备类 关键字: 双发双收、TM2、TM3 RRU1 Radio Paramrters RRU1 RSRP走势图
RRU1 SINR走势图 RRU1下行吞吐率走势图 RRU2 Radio Paramrters
RRU2 RSRP走势图 RRU2 SINR走势图 RRU2下行吞吐率走势图 告警信息: 原因
1、经过联系后台核查该小区下得2个RRU后台数据均配置的为双发双收; 2、核查工程安装图纸RRU1为独立的双通道配置、RRU2其中一路为独立的通道配置,另一路为与
无 分析: 2 1、经过工程安装人员进行检查发现在耦合器与TD合路的接口未连接: 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至天线一侧,需要安装人员配合进行检查。
4 下行呑吐率“掉坑“毛刺问题
题目: 下行呑吐率“掉坑“毛刺问题 故障类别: 传输 现象描述: 关键字: 掉坑、灌包、传输 在成都LTE站点“成都分公司”单验过程中,该站5个RRU覆盖的平层,上行数据业务平稳正常,但下行数据业务速率呈现严重的“掉坑”毛刺问题,如例图: 对成都分公司的5个RRU覆盖平层进行测试,统计结果如下表: 测试地点 成都分公司1F 成都分公司2F 成都分公司3F 成都分公司4F 成都分公司5F 5个RRU覆盖5个平层(只解闭塞测试楼层RRU) 下行吞吐量(Mbps) RSRP(dBm) SINR(dB) 42.8 42.49 44.48 44.34 43.44 -68.16 -79.17 -65.3 -64.11 -63.49 34.16 35.63 34.79 35.24 34.63 CQI PDSCH BLER(%) MCS (code 0) 每子帧平均RB数 14.55 14.45 14.55 14.82 14.42 #DIV/0! 0.21 #DIV/0! #DIV/0! 1.16 27.61 27.71 27.73 27.8 27.35 64.16 63.41 65.64 66 65.87 告警信息: 框号为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):
楼层 1F 2F 3F 4F 5F RRU框号 206 200 201 207 202 1小区 小区 通过对其中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\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传输带宽不作限制,测试情况:
测试地点 成都分公司1F 成都分公司2F 成都分公司3F 成都分公司4F 成都分公司5F 下行吞吐量(mbps) 上行行吞吐量(mbps) RSRP(dBm) SINR(dB) 58.384 57.987 59.227 57.115 58.975 14.768 14.681 14.885 14.778 14.883 -74.034 -76.029 -70.229 -70.24 -71.071 34.806 34.9536 33.796 35.096 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拒绝问题
题目: B593 PDN拒绝问题 关键字: 故障类别: 终端 PDN拒绝 现象描述: 在测试过程中,B593层三信令经常出现PDN拒绝问题,有时候会做不了业务 告警信息: 无 原因分析: 在页面中配置了非法APN——所以一般就选择Auto APN即可,因为展厅环境没有VOIP,必须要把WEBUI上的VOIP APN信息删除,否则会出现如下PDN建立被拒情况: 处理过程: 处理过程: 在非连接模式,登录web界面,按照左边的导航,进入APN编辑页面,(该界面必须在插入硬卡的条件下才可以看到) 将VOIP对应的APN设置为manual接入,并设置为disconnected状态。 1、 首先将Voice Connect的连接模式设置为手动,然后点击 提交 按钮。
2、如果连接状态变为 连接态,则接入成功。 建议与总结: 新到的CPE均需要修改
6 RSRP过高导致下载速率不稳定问题
题目: RSRP过高导致下载速率不稳定问题 关键字: B593S、RSRP 故障类别: 终端类 现象描述: 音乐公园室分基站开通后,我们用B593S终端进行现场测试发现在RSRP和SINR极好的情况下下行吞吐率出现比较明显和频繁的掉坑现象,下载速率极为不稳定并且在测试过程中较为频繁的出现终端脱网状态,具体情况如下: RSRP走势图 SINR走势图 下行吞吐率走势图
BLER走势图 告警信息: 无 原因分析: 1、通过测试数据分析发现在每次下行吞吐率掉坑的时候均出现较高的BLER,初步怀疑现场存在外部干扰,但是通过在距离该处5M左右距离的地方再次进行测试RSRP、SINR、下行吞吐率均极为稳定,并且BLER值较低,从而排除了外部干扰的问题; 2、在测试的过程中我们发现在部分地点终端要出现脱网状态,并且该状态随着距离天线越近越出现频率越频繁,在我们走到天线正下方时候终端彻底脱离网,无法再次进行业务工作: 可以看到在天线下方终端无信号; 此时已经怀疑到终端接收能力问题,在联系相应人员后得知在输入电平最大值超过-25dbm时,会导致接收机前段的LNA等器件出现饱和失真,接收通道误码偏高,从而导致吞吐率不稳定; 处理过程: 1、降低RS功率,在降低RS功率后进行复测,我们发现在测试点位置RSRP依然较高,吞吐率依旧无法稳定在峰值速率; 2、增加10dbm衰减器从而再一次降低终端接收电平,本次调整后问题得到解决; 复测结果:在进行以上两个步骤的调整后进行复测,结果较为理想下载速率较为稳定,具体如下: 测试点1 下行RSRP SINR 吞吐率
RSRP SINR 测试点2 测试点3 PCI 频点 下行吞吐率 RSRP SINR 下行吞吐率 备注
0 39050 -48.94 29.31 56.78 -58.26 33.65 56.75 -52.78 26.46 13.07 RS 152 RS 62/增0 39050 -64.59 33.42 57.71 -72.43 32.11 58.78 -68.87 33.77 58.87 加10dbm衰减器
RSRP走势图 SINR走势图 下行吞吐率走势图
BLER走势图 建议与总结: 在进行室内分布系统设计的时候不能一味的追求高RSRP,在RSRP过高(>-55dbm)的时候终端的LNA等器件出现饱和失真,接收通道误码偏高,从而导致吞吐率不稳定,建议在进行室分系统设计的时候保证终端接收功率在-60dbm以下。
7 外部小区及邻区冗余导致无法切换问题
题外部小区及邻区冗余导致无法切换问题 目: 故障类别: 现在对久远饮食基站进行单站点验证过程中,二环路由北向南行驶,终端占用英雄鱼头-3小区(PCI:象描述: 参数类 关键字: E5776S、切换 138)频繁发起向久远饮食-1(PCI:374)的A3切换事件,但无法完成切换,导致掉线。
告警信息: 原1、核查英雄鱼头-3小区邻区关系,已做久远饮食-1小区邻区数据,并对该站添加的久远饮食-1小区因分外部小区数据进行核查,外部小区无误; 2、进一步对英雄鱼头基站外部小区和邻区数据进行核查,发现存在尖东望座站点相关数据,详细如SCTP链路故障告警 析: 下: 该站点数据经核查为冗余数据,且同久远饮食基站存在相同的“基站标识”和“小区PCI”,小区标识不同。久远饮食基站信息如下:
3、通过上述分析,初步判断为英雄鱼头-3小区向久远饮食-1小区发起的切换错发向了不存在的尖东望座基站,导致切换无法正常完成。 处1、 后台删除英雄鱼头邻区及外部小区中的尖东望座基站冗余数据; 理过程: 2、 现场进行复查,切换正常,如图: 建1、 明确切换数据查找流程:终端监测信号,上报目标小区PCI基站判决符合切换条件,根据小区议与总结: 表、邻区表和外部小区表确定目标小区通知目标基站准备,并向终端下发切换消息包含目标小区信息终端根据收到的切换目标小区信息在目标小区进行接入 2、 终端频繁发起A3切换请求,但是一直未发起切换,可能原因就有:一是没做邻区数据;二是外部小区属性错误;三是冗余数据导致切换消息错误发送;四是其他问题。本案例就是属于外部小区和邻区数据中存在冗余记录导致切换消息错误发送造成不能切换从而导致掉线。 3、 后台需定期对冗余数据进行清除。
8 MOD3干扰问题
题MOD3干扰问题 目: 故障类别: 干扰 关键字: 下行呑吐率 现象在东门桥测试,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分布分析,调整PCI比较困难,所以通过RF优化问题解决 处理通过对周围站点PCI分布分析,调整PCI比较困难,因此通过RF优化调整控制银杏大厦-1小区覆过程: 盖,银杏大厦-1小区下倾角从4度调整到7度,调整后该路段SINR从2db升高到12db,复测结果如下:
建议对MOD3干扰优化可以有如下措施:1、调整PCI优化调整;2、RF优化调整,控制邻区覆盖降低与总邻区RSRP;3、功率调整,控制邻区覆盖降低邻区RSRP等优化措施
结:
9 Mifi网络连接设置问题导致开机无服务
题目: Mifi网络连接设置问题导致开机无服务 关键字: 无服务 故障类别: 终端设置 现象描述: 某地用户投诉4G信号差,无网络服务。 告警信息: 无 原因分析: 1、 投诉区域为网络覆盖盲区; 2、 基站存在告警; 3、 SIM卡数据问题; 4、 终端设置问题; 处理过程: 1、投诉用户为商用前VIP客户,首先确认投诉区域网络覆盖是否是无覆盖,通过现场测试覆盖较好,数据业务能满足用户需求,排除因为覆盖而引起的无信号问题。 RSRP SINR 下载速率 上传速率 2、联系后台查询基站最近3天无告警; 3、将用户mifi的SIM卡与测试SIM卡互换后,测试MIFI能正常入网,而用户MIFI仍然无服务,确定用户mifi问题。 4、将用户MIFI连接电脑进入192.168.1.1页面后发现用户mifi存在设置问题,具体设
置如下: 进入192.168.1.1页面后,在连接设置里面,移动网络设置为“打开”。
网络设置里面 网络首选方式为:仅4G 5、设置后重启,mifi正常搜索到4G网络,且连接外网正常; 建议与总网络无服务投诉基本可以分步排除,首先排除是否为覆盖方面引起的无信号(如:覆盖漏洞、结: 基站告警引起的覆盖漏洞);其次通过卡机互换确定是终端问题还是SIM数据问题,确定问题出现在那个环节,并分析处理。
10 TAU更新失败问题
题TAU更新失败问题 目: 故障类别: 现象描述: 长呼测试时,在东华门街与东华正街交界处,出现一次TAU更新失败,具体情况如下: 位置区域更新失败 关键字: 位置区域更新 测试截图 告警信息: 原因分通过对周围环境和测试数据分析,是由于远东百货-3小区(RSRP-96dbm)在东华门街信号突然高于茂业百货-3小区(RSRP-101dbm),所以UE从茂业百货-3切换到远东百货-3,之后一直占用远东百货-3小区,而切换到RSRP为-81dbm的华瑞商务楼-3小区,所以该路段RSRP一直下降到-1但在发起位置区域更新请求时,已经是弱覆盖(RSRP-141dbm),所以导致位置区域更新请求失败。 处理过程: 添加远东百货-3和华瑞商务楼-3小区双向邻区关系,添加邻区后及时发起切换,避免由于弱覆盖导致位置区域更新失败。处理结果如下图所示: 无 析: 41dbm而导致弱覆盖,且远东百货和华瑞商务楼不属于同一位置区,因此发起位置区域更新请求,
建议与总结:
由于远东百货是FAD天线不能调整,所以建议添加远东百货-3和华瑞商务楼-3小区双向邻区关系,添加邻区后及时发起切换,避免由于弱覆盖导致位置区域更新失败
11 不同设备类型RRU,设备偏置不一致导致干扰,影响上行速率
题目: 不同设备类型RRU,设备偏置不一致导致干扰,影响上行速率 故障类别: RRU设备 关键字: 上行速率偏低、RRU、RRU偏置 现象描述: “洲际酒店一-3”小区上行速率低(下行速率正常),多次测试内基本都是小于3Mbps(该小区的两个RRU均是该现象) 小区名称 洲际酒店一-1 洲际酒店一-2 洲际酒店一-3 RSRP(dBm) -75 -69 -71 SINR(dB) 27 34 30.5 平均下子速率(Mbps) 49.3 81.3 81.8 平均上传速率(Mbps) 8.2 6 2.1 说明 单流,上传下载均正常 双流,下载正常、上传偏低 双流,下载正常、上传不达标 告警信息: 无告警 原因分析: 11.1 前台测试数据分析 从测试数据来看,RSRP为-76dBm,SINR为35dB,BLER为0%,CQI为14,无线环境很好,但是从测试数据来看,导致上传速率仅为2Mbps的直接原因是上行调度数在180左右,UL-MCS期望阶数在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 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单板是否存在异常。 经现场测试,更换LBBP单板后测试结果与更换单板前测试结果一直,说明两块LBBP单板都没有问题。 11.7 闭小区单独测试 将洲际酒店一-1、2小区去激活,单独测试3小区上传速率为9.5Mbps,依次激活2小区,小区速率变化如下: 步骤 步骤1 步骤2 步骤3 步骤4 测试方案 洲际酒店一-1、2小区均去激活,测试3小区上传速率 洲际酒店一-1去激活, 2小区激活,测试3小区上传速率 洲际酒店一-1、2小区均激活,测试3小区上传速率 洲际酒店一-1激活, 2小区去激活,测试3小区上传速率 平均上传速率(Mbps) 9.5 7.5 2.2 2.5 对比说明 与测试1小区上传速率接近 与测试2小区上传速率接近 与测试3小区上传速率接近 与测试3小区上传速率接近 步骤1~3测试3小区平均上传速率与分别于验证1、2、3小区平均上传速率结果相似(如问题现象)。
洲际酒店一-3小区上传速率变化图 11.8 闭RRU单独测试 由于洲际酒店一的3个小区均级联2个RRU,结合上面闭小区的测试结果,进一步排查RRU级联对洲际酒店一-3小区上传速率是否存在影响。 步骤 步骤A 步骤B 步骤C 步骤D 测试方案 洲际酒店一-1、2小区级联的第二个RRU均连接时,测试3小区第二个RRU覆盖区域上传速率 断开洲际酒店一-1小区级联的第二个RRU,测试3小区第二个RRU覆盖区域上传速率 断开洲际酒店一-1、2小区级联的第二个RRU,测试3小区第二个RRU覆盖区域上传速率 连接洲际酒店一-1、2小区级联的第二个RRU,测试3小区第二个RRU覆盖区域上传速率 平均上传速率(Mbps) 1.2 7.5 9.6 0.5 说明 与闭小区测试的步骤3上传速率接近 与闭小区测试的步骤2上传速率接近 与闭小区测试的步骤1上传速率接近 与闭小区测试的步骤3上传速率接近 11.9 灌包测试 从便携机向服务器上行灌包,在服务器端抓包,结果如下。可见当“洲际酒店-3”小区频点为39050时,UDP和TCP上行速率都有问题,而当“洲际酒店-3”小区频点为39250时,上行速率都正常(灌包操作是在3小区第2个RRU的覆盖范围内进行), (1)频点为39050的UDP灌包和TCP灌包
UDP TCP (2)频点为39250的UDP灌包 (3)频点为39250的TCP灌包 11.10 更换“洲际酒店-3”的两个RRU(验证测试RRU不存在问题) 根据前面的定位,怀疑“洲际酒店-3”的两个RRU有问题,所以用两个正常的3152RRU替换原来的RRU,然后进行下面的测试。 对经过室分分布系统后出来的信号进行测试,分别在“洲际酒店-3”频点为39050和39250情况下对“洲际酒店-3”速率进行
测试;直接在RRU(“洲际酒店-3”的第2个RRU)上连接天线(不经过分布系统),分别在“洲际酒店-3”频点为39050和39250情况下对“洲际酒店-3”速率进行测试。 经分布 洲际酒店-3的频点 39050 39250 39050 RRU连天线 39250 RSRP(dBm) -67 -62 -81 -75 -61 -80左右 -70左右 -60左右 SINR(dB) 32.5 36.75 32.75 35 36.5 35左右 35左右 35左右 DL(Mbps) 80 80 80 80 80 80 80 80 UL(Mbps) 2.2 7.5 0.6 1.5 7.7 7.5 7.5 7.5
11.11 向研发提供测试数据、OMC信令跟踪文件、干扰日志以及基站日志信息,研发测给出双模RRU3151e-fae、3161e-fae和3152e共覆盖时上行速率异常,需要对3152e型号RRU帧偏置进行修改。 处理过程: 由于3151e-fae、3161e-fae是双模RRU,为了和TDS空口同步,作了空口提前,而老款和新款RRU3152e是单模RRU,所以未作空口提前,从而会造成RRU3151e或RRU3161e小区和3152e小区空口对不齐,3151e的下行子帧干扰3152e的上行子帧,引起3152e下的上行速率波动。故只要存在共覆盖场景,必须手动配置3152e的帧偏置。 无线产品侧通过串口对3152e类型的RRU进行修改帧偏置,测试效果正常。 建议与总 对于上下行速率问题,根据项目组的《上下行吞吐率问题定位规定动作以及相应的_new.xlsx》的Check List逐步进行验证排结: 查。
因篇幅问题不能全部显示,请点此查看更多更全内容