TD-SCDMA无线网络优化案例分析课件

2023/11/11第1页TD-SCDMA无线网络优化案例分析2023/11/11第2页第六章：TD-SCDMA无线网络优化案例分析第四章：

TD-SCDMAKPI指标及问题分析第一章：

TD-SCDMA无线网络优化介绍第五章：

TD-SCDMA路测及分析软件的使用第六章：

TD-SCDMA无线网络优化案例分析第三章：

TD-SCDMA无线资源管理第二章：

TD-SCDMA信令基本流程2023/11/11第3页本章目标:1：熟悉TD-SCDMA弱覆盖引起掉话情况2：掌握TD-SCDMA乒乓切换引起掉话情况3：熟悉TD-SCDMA信号波动引起掉话情况4：掌握TD-SCDMA越区覆盖引起掉话情况5：熟悉TD-SCDMA干扰引起掉话情况6：了解TD-SCDMA其他案例本章培训目标2023/11/11第4页本章内容:1：TD-SCDMA弱覆盖引起掉话案例2：TD-SCDMA乒乓切换引起掉话案例3：TD-SCDMA信号波动引起掉话案例4：TD-SCDMA越区覆盖引起掉话案例5：TD-SCDMA干扰引起掉话案例6：TD-SCDMA其他案例7:本章练习本章培训内容2023/11/11第5页案例1－弱覆盖引起掉话

案例说明：此掉话点位于杏滨路的拐角处。杏滨站点的位置非常低，基本与水平面平行。所以对拐角点的覆盖很弱。而相邻小区杏林高浦2在此点方向上有遮挡。2023/11/11第6页问题所在点图中黑圈所示是易发生掉话的点。根据路测数据和实地勘查，分析发现，高浦2在测试路线方向上有遮挡，导致信号时强示弱，造成掉话。2023/11/11第7页解决方案新杏林是个塔站，站高很高。在路线上视距传输，没有遮挡，可以设计新杏林2作为此测试路线的主服务小区。因此做如下调整：降低高浦2小区的功率，以减小高浦2对此测试路线的影响。调整杏滨2到新杏林2的CIO（小区偏置）为6，加快杏滨2到新杏林2的切换速度，避免潜在的掉话。提高杏滨2天线的高度。杏滨2和新杏林2之间路口信号覆盖偏弱，可能会导致掉话，因此提高杏滨2天线的高度，加强该路口的覆盖。删去新杏林2与高浦1之间不合理邻区关系，避免切换到高浦1的背瓣。2023/11/11第8页效果评估调整后的路测结果如上图所示。从结果可以看出调整后，掉话点消失，切换正常。注：来回路测多次，故切换标识有多个。2023/11/11第9页案例2－乒乓切换引起掉话案例说明：此点位于杏林南路、杏林北路、杏林东路、杏林西路的交叉口。周围有杏西站，建行站，杏林信用社站，新杏林站。信号比较杂，干扰比较严重。2023/11/11第10页问题所在点

图中红色圈中是发生乒乓切换的区域，乒乓切换主要发生在杏林杏西2和建行2，信用社1以及新杏林3之间，尤其是在等红绿灯的时候。分析发现，发生乒乓切换的主要原因是该十字路口南北向和东西向的主导小区不突出，导致了乒乓切换，同时在路口南北向，尤其是路口南边，覆盖在-90dBm左右，容易发生掉话。2023/11/11第11页解决方案

考虑到附近建行的站点比较高（38m），而且距离路口不远，所以可以让建行2小区作为该十字路口的主服务小区，杏西2、信用社3和新杏林3分别在路口以西、路口以南、路口以东约20m~50m的地方发生切换，这样，车辆在南北和东西双向行驶路过该路口时，只发生两次切换，即使是等红灯的时候，也不会有乒乓切换。因此做如下调整：建行2的方位角由120度调整为150度，下倾角由8度压为10度。建行2的PCCPCH的功率调整为33dBm，DwPCH调整为36dBm。目的是加强十字路口的覆盖，同时控制其覆盖范围不要太远。建行2到杏西2的CIO调整为6。由于杏西2和建行2之间的切换带比较窄，为了能够从建行2快速切换到杏西2，调整该CIO为6。2023/11/11第12页效果评估

调整后的结果如上图。从上图可以看出，乒乓切换消除。由于在整个调试过程中，只存了一个log文件，而图中显示了调试过程中所有的切换，故在图中所标示的切换带之外还有一些切换。2023/11/11第13页案例3－信号波动引起掉话案例说明：建行到特运站之间的路线上有个桥。从路测结果来看，在桥上，建行1的信号有较大波动，在波动前特运2和建行1的信号相当，不满足切换条件。之后建行1突然有10db左右的衰减，信号变弱，造成切换困难，导致掉话。2023/11/11第14页问题所在点2023/11/11第15页问题所在点（续）2023/11/11第16页解决方案

从路测结果来看，在桥上，建行1的信号有较大波动，在波动前特运2和建行1的信号相当，不满足切换条件。之后建行1突然有10db左右的衰减，信号变弱，造成切换困难，导致掉话。因此做如下调整：调整了建行1到特运2的CIO（调为6），使其在建行1信号变差前，尽快由建行1切换到特运2。调整了特运2到建行1的CIO，将其调为－10，避免在其相反方向上由于建行1的信号波动导致误切、乒乓切换等现象的发生。2023/11/11第17页效果评估

从调整后的路测结果来看，调整后，在建行1信号变弱之前，终端就由建行1切换到特运2，避免了因切换造成的掉话现象的产生。2023/11/11第18页案例4－越区覆盖引起掉话案例说明：在特运，正新到二化的测试路线上，建行1的信号有时候很强，造成误切换到建行1导致掉话。实际上建行1到图中所示点距离为1.5公里，而在此处建行1的信号为－72dbm，信号非常强，说明建行1越区覆盖很严重。而且从路测结果上看，福太1的信号为－78dbm，福太2的信号为－72dbm，都非常强，会对此段测试路线造成很强干扰。

2023/11/11第19页解决方案

根据案例说明做如下调整：调整了特运2到建行1的CIO，将其调为－10，使其不容易切换到建行1。调整了建行1的方位角＆下倾角，降低建行1对此段路线上的干扰。压低了福太1、福太2的下倾角，降低福太1、福太2对此测试路段上的干扰。2023/11/11第20页效果评估

从路测结果上看，建行1、福太1、福太2在此段测试路线上的功率有不同程度的降低，相比调整前降了20db左右，对此段路线上的干扰减小了。2023/11/11第21页案例5－干扰引起掉话案例说明：厦门大桥的四周都是开阔的海面，信号的传输环境比较好，所以极易受到其他基站信号的干扰。在优化前，手机可以检测到诚毅学院、货运枢纽、集美航院、集美大社、集美、神山等6个站将近10个小区的导频信号，主导频不明确，终端在大桥上频繁发生切换，掉话率很高。2023/11/11第22页解决方案覆盖解决方案因为诚毅学院、货运枢纽两个站分别在厦门大桥的桥头，而且传播环境很好，所以决定以这两个站作为厦门大桥的主要覆盖小区。减小了诚毅学院2扇区和货运枢纽3扇区的天线倾角，增大了覆盖半径。在不影响其他基站覆盖的前提下，压低了主要干扰基站天线的倾角，并降低了神山3扇区的发射功率，以减小对大桥的干扰。在采取了这些措施后，手机在大桥上能够测到的主导频基本上就是诚毅学院2扇区和货运枢纽3扇区的信号。其他干扰信号明显降低。切换解决方案由于厦门大桥的距离非常长，将近2.5公里，诚毅学院2和货运枢纽3的信号在经过海面反射后，会形成越区覆盖，手机在大桥上还是会在这两个小区上有乒乓切换，为了平滑过渡，将诚毅学院2和货运枢纽3对对方小区的切换小区独立偏置CIO分别调整为－8和－6。目的是只有当目标小区的信号明显强于服务小区的信号后，网络侧才会发起切换。厦门大桥是厦门的交通枢纽，经常堵车，所以即使增大了切换的CIO，手机在堵车的情况下也经常发生乒乓切换，所以将切换触发时间从1.28秒增大为2.56秒。调整后，手机在堵车的情况下乒乓切换次数有下降。2023/11/11第23页效果评估

采取了以上措施后，大桥的通话效果得到了很明显的改善，乒乓切换次数大大降低。可以从优化前后的图例中看出优化结果。2023/11/11第24页案例6－测量方式影响

连雨第1小区存在7个异频邻小区，在图示红方块处6UE进行呼叫，UE上报测量报告状况如下：460058031201990无异频测量报告460058031201942正常460058031201976无异频测量报告460058031201957正常460058031201979正常460059031201946正常

问题现象：终端通过切换带时因为没有及时上报测量报告，没有正常切换导致掉话。原因分析：从同频网络转为N频点网络，邻小区数量增加，由于UE的测量能力有限，500ms的周期性测量经常丢失异频测量报告，网络性能因此受到影响。解决方法：将上报周期延长至1s；或将周期性测量上报改为事件触发上报。2023/11/11第25页案例7－出RNC切换成功率问题正常流程异常流程

问题现象：出RNC切换成功率低；问题分析及解决方法：出RNC切换成功率由低到高排名，发现国防大厦3的出RNC切换成功率只有60％；分析国防大厦3当天的Uu口trace，发现大部分失败的信令流程是：原RNC在发送relocationrequest消息后，CN回复失败信令：relocationpreparationfailure，原因是requestedinformationnotavailable。具体原因为位置更新中UE触发了出RNC切换，CN拒绝位置更新中的出RNC切换请求，导致出RNC切换失败。修改参数，使UE位置更新过程中的RRC连接进入FACH状态。问题解决：未出现位置更新过程中的出RNC切换请求，出RNC切换成功率提高。2023/11/11第26页案例8－部分终端PDP激活不成功异常流程

问题现象：部分终端PDP激活不成功；问题分析及解决方法：跟踪PDP激活不成功的单UEtrace；分析单UEtrace，发现PDP激活过程中RBsetup过程不成功，网络侧发送RBSETUPREQUEST消息后，终端未回复RBSETUPCOMPLETE消息，导致RA