绵阳移动TDLTE用户感知技术建议书

绵阳移动TD-LTE用户感知技术建议书汇源通信吉讯数码科技有限公司第） 改善话务热点的拓扑结构（调整扇区天线方位角）。典型案例弱覆盖问题描述：从优化平台看，该点附近小区存在较大比例的弱信号发起的呼叫统计。现场进行测试发现，测试车辆在紫金北路与庆春街交叉口行驶，终端占用D780093莲都天健电力实业F-2小区，RSRP在-100dBm左右，由于存在楼宇阻挡，导致弱覆盖，继续行驶信号恶化，会导线掉线。调整前覆盖图：问题分析：1、检查基站状态正常；2、核查邻区，未存在邻区漏配不切换的弱覆盖掉线；从实际地理位置分析，由于周围存在楼宇阻挡，天馈调整效果不大，后现场实际勘查发现D780128莲都佳禾酒店F-1小区天馈，可以通过调整D780128莲都佳禾酒店F-1小区天馈，加强问题路段覆盖。从现场实际地理位置分析，由于周围存在楼宇阻挡，天馈调整效果不大，后现场实际勘查发现D780128莲都佳禾酒店F-1小区天馈，可以通过调整D780128莲都佳禾酒店F-1小区天馈，将强问题路段覆盖。处理结果：后现场调整D780128莲都佳禾酒店F-1小区方位角21°调整为5°，机械下倾角5.2°整为8.4°，复测后问题路段得到解决。复测后如图：调整后，从优化平台看，可以明显看到附近小区的弱信号发起的呼叫统计比例明显下降。邻区漏配导致的掉线现象描述：从优化平台看，该点附近小区掉线率偏高。现场复测：0922分析切换TOP小区，发现鹤工农工商局家属楼-DLH-1小区掉线次数偏高，全天掉线次数分别为136次。原因分析：通过汇源优化平台对鹤工农工商局家属楼-DLH-1小区分析，发现该站切换均为小区内切换，无S1、X2切换存在；对该站3个小区邻区进行核查发现，该小区邻区配置错误，主要由于该站建设位置与原规划位置偏离较远，造成邻区配置不合理造成，如下图所示：解决方法：对鹤工农工商局家属楼-DLH-1邻区进行核查，添加部分邻区，添加后邻区如下图：邻区添加后，通过汇源优化平台对该小区进行分析发现，该小区全天掉线次数为0，邻区调整后效果显著，X2切换正常，S1切换次数较少且切换正常。从优化平台看，修改后该点附近小区掉线率明显好转。天线接反模三干扰掉线问题描述：从优化平台看，多个小区上下行MR数据显示SINR偏低。现场复测：在金湖中行L站点附近道路拉网测试发现该区域天线方位角逆时钟接反，导致周边道路SINR较差，出现了掉线现象。问题分析：优化过程中发现，UE占用金湖中行L站点附近可以明显发现该区域天线扇区接反，覆盖混乱，经过分析发现金湖中行L-3小区（PCI260）与中百一店L-3（PCI278）为模三干扰，同时金湖中行L-2（PCI259）与公安局L-3（PCI355）也为模3干扰。处理结果：经过开站工程师进入机房将尾纤调换后，覆盖明显合理改善，同时SINR也得到了提升，基本上达到了10~15db之间，没有再出现切换、覆盖混乱、掉线现象。从优化平台看，修改后MR数据得到较大改善。综合问题描述：自山西X地市ERAB掉线率从0.1%左右抬升到0.4%左右且比较稳定，如下图，指标恶化非常明显，和客户期望的指标0.22%差距比较大。运城：（8月14日）临汾：(7月30日)问题分析：从汇源优化平台统计，多地市多天分子（异常释放原因）各个counter的占比，详表如下：异常释放原因-运城次数占比Context.AttReleNBNbr.RadioInterfaceFailure(R026_024)[单位:次]7926012.74%Context.AttReleNBNbr.Unspecified(R026_025)[单位:次]6920.11%Context.AttReleNBNbr.OMIntervention(R026_037)[单位:次]5050.09%Context.AttReleNBNbr.UELostM1(R026_042)[单位:次]00Context.AttReleNBNbr.UELostN(R026_043)[单位:次]54149687.06%异常释放原因-临汾次数占比Context.AttReleNBNbr.RadioInterfaceFailure(R026_024)[单位:次]33998119.72%Context.AttReleNBNbr.Unspecified(R026_025)[单位:次]20920.12%Context.AttReleNBNbr.OMIntervention(R026_037)[单位:次]93070.54%Context.AttReleNBNbr.UELostM1(R026_042)[单位:次]103260.60%Context.AttReleNBNbr.UELostN(R026_043)[单位:次]136208179.02%根据UE-LOST占比，发现掉线率UElostN百分比占比超过80%，且主要是有R026_043（UELostN）这个counter导致，这也是导致指标恶化的最直接原因，所以解决R026_43这个counter问题是解决掉线率的主要方向。常规情况下：无线掉线率＝小区E-RAB异常释放总次数/(小区E-RAB异常释放总次数+小区E-RAB正常释放总次数)×100%无线掉线率公式：100*(#{R026_024}+#{R026_025}+#{R026_037}+#{R026_042}+#{R026_043})/(#{R026_013}+#{K005_010})掉线率公式中各个counter的含义：(红色字体为分母，黑色字体为分子，蓝色字体为升级后分子增加的counter，以上参考OMC上定义counter值)R026_024=Context.AttReleNBNbr.RadioInterfaceFailure=eNB发起上下文释放-空口过程失败R026_025=Context.AttReleNBNbr.Unspecified=eNB发起上下文释放-其他原因R026_037=Context.AttReleNBNbr.OMIntervention=eNB发起上下文释放-OMInterventionR026_42=Context.AttReleNBNbr.UELostM1(R026_042)=eNB发起上下文释放-UELostM1R026_43=Context.AttReleNBNbr.UELostN(R026_043)=eNB发起上下文释放-UELostNR026_013=Context.SuccInitalSetupNbr=eNB成功建立上下文的次数K005_010=CONTEXT.NbrLeft从公式来看，主要是OMIntervention和UE-lost，这也是指标恶化的主要原因。第一：OMIntervention（OM干预）。第二：UE-LOST。（UELostM1和UELostN）。处理结果：可以尝试将ACK激活检测异常次数门限由默认的100次修改到300，增加异常检测次数，等于是放宽了检测，只要PL不存在误检就可以，ACK激活检测异常恢复次数门限由默认的3次修改到2次。重庆验证结果如下：路测部分测试设置：ftp下载时间设置为3分钟，时间间隔20s。测试结果如下：测试范围参数配置FTP下载速率平均SINRSERVICE平均时延（ms）控制面时延（ms）同频切换平均时延平均车速（km/h）城口簇1M=300&N=22821.48623.5663.7747.3118.9城口簇1M=200&N=22921.83480.1681.85232.819.75城口簇1M=200&N=326.320.791636.649.18315.0216.35城口簇1M=300&N=328.622.051982.2765.41590.4316.8城口簇1M=100&N=330.520.661133.1744.92215.8519.6由此可知M=300&N=2时，整体时延最低。M=200&N=3对下载速率及平均SINR有较大影响。KPI部分参数配置无线接通率无线掉线率切换成功率ERAB掉线率RRC连接重建比率LTE_PDCP.UpPktDelayDlM=100&N=399.770.4799.650.4719.5850.4M=300&N=299.640.2799.6