《安徽公司QCHAT无线质量测评汇报.ppt》由会员分享，可在线阅读，更多相关《安徽公司QCHAT无线质量测评汇报.ppt（39页珍藏版）》请在三一文库上搜索。
1、0,安徽公司QCHAT无线质量测评汇报,目录,QCHAT不同寻呼策略指标对比,一,哪个模版能准确测出网络的真实性能？,准备工作,测试模板分析,测试模板的关键要素： 呼叫间隔时间 通话时长 连接超时时间,安徽测试模板调整： 为了确保每次呼叫能够采集QCHAT的完整信令，呼叫间隔由20秒调整为45秒； 鼎利连接超时的定义为主叫终端发送PPT EVENT到收到TonePlayed的间隔，与QCHAT被叫4.5秒超时的定义不一致（服务器发出ANNOUNCE到收到ANNOUNCE ACK的间隔），连接超时时间由5秒调整为15秒。,阿朗区测试情况分析滁州DT,寻呼策略配置： 四次寻呼，前两次为Last a
2、ctive set，后两次为last seen RNC，寻呼间隔1.5秒。,阿朗区测试情况分析合肥DT,寻呼策略配置： 四次寻呼，前两次为Last active set，后两次为last seen RNC，寻呼间隔1 秒。 QoSLicense配置： 优化前： RNC license上限控制数目是300，每个基站上限控制数目是12 优化后： RNC license上限控制数目是1000，基站281、62上限控制数目是14，其它基站12,阿朗区测试情况分析六安DT,寻呼策略配置： 优化前：四次寻呼，前两次为Last active set，后两次为last seen RNC，寻呼间隔2秒； 优化前
3、：四次寻呼，前两次为Last active set，后两次为last seen RNC，寻呼间隔1秒；,中兴区测试情况分析马鞍山DT,寻呼策略配置： 寻呼次数：2次； 寻呼间隔：1.5秒； 寻呼范围：3级， “邻区方式RU有效时间RUNLAvailableTime”与“子网方式RU有效时间RUSNAvailableTime”分别为1秒和10秒。,阿朗区测试情况分析CQT,CQT测试整体指标较好，失败原因与DT测试类似,目录,QCHAT不同寻呼策略指标对比,一,失败原因最多的为被叫寻呼不到，经过寻呼策略优化后，QoS OFF情况下已解决，但QoS ON的情况仍有出现，正在进一步分析优化中。,典型
4、事件分析分布六安,在QoS License优化后，失败原因最多的为由于DO信号质量问题切换至1X以及导频污染。,典型事件分析分布合肥,失败原因最多的为由于DO信号质量问题切换至1X以及寻呼过晚。,典型事件分析分布滁州,异常事件主要为掉话，其中基站主动下发Connection Close的占比较大，目前，正在进一步分析中。,典型事件分析分布马鞍山,1、SINR值连续4s低于-7dB，终端切换至1x导致掉话 本地网：合肥 发生次数：3（全部发生在OFF） 问题描述：起呼或通话中， SINR值连续4s低于-7dB ，继而切换至1X上。 问题分析：问题路段一般接收电平良好（RxAGC-75dBm），但
5、SINR值很低（普遍低于-7dBm），存在较强的导频污染。 解决办法：针对SINR值进行优化。 具体影响：造成呼叫失败或掉话。 影响指数：,合肥典型事件分析掉话,问题描述：MS由西向东行驶，RXAGC=-88.35dBm，SINR=-11dB，终端切换至1x上，导致掉话。 问题分析：图中所圈基站（站名：金牛）没有DO载波，导致该路段EVDO覆盖较差。 解决方法：增加金牛站的EVDO载波。,合肥典型事件分析掉话,2、子网边界处，导频污染严重，基站侧下发close，导致掉话 发生次数：2（全部发生在ON） 问题描述：处于子网边界，呼叫过程中有发生跨子网切换，导频污染严重，AN下发Connectio
6、nClose断开Connection，导致掉话。 问题分析：首先终端处于子网边界，跨子网切换时先要断开Connection易造成掉话；其次问题路段导频污染也较为严重。 解决办法：优化子网边界，减小子网间的重叠覆盖；针对导频污染进行优化。 具体影响：造成呼叫失败或掉话。 影响指数： ,合肥典型事件分析掉话,问题描述：问题路段处于ColorCode 2和4的交界处，导频污染较为严重，主被叫起呼前后都发生了的Session切换。,合肥典型事件分析掉话,合肥典型事件分析掉话,3、信号质量差，EVDO掉线导致掉话 发生次数：1（发生在OFF） 问题分析：无线信号质量差（SINR-4dB），终端搜索不到E
7、VDO导频，导致掉话（Reason：systerm lost）。 解决办法：针对无线参数SINR值进行优化。 具体影响：造成EVDO掉线。 影响指数：,合肥典型事件分析掉话,问题描述：MS由西向东行驶，在该路段发生EVDO掉线（Reason：systemlost）。 问题分析：该路段PN228和PN315之间存在干扰，信号较差，SINR值=-4.54dB，导致终端接收不到EVDO前向消息而掉线。 解决办法：调整天馈，针对SINR值进行优化。,合肥典型事件分析掉话,合肥典型事件分析呼叫失败,1、SINR值连续4s低于-7dB，终端切换至1x导致掉话 发生次数：8（在OFF发生6次，ON发生2次）
8、 问题描述：起呼或通话中， SINR值连续4s低于-7dB ，继而切换至1X上。 问题分析：问题路段一般接收电平良好（RxAGC-75dBm），但SINR值很低（普遍低于-7dBm），存在较强的导频污染。 解决办法：针对SINR值进行优化。 具体影响：造成呼叫失败或掉话。 影响指数：,问题描述： MS由南向北行驶，SINR值连续4s低于-7dB，终端切换至1x。 问题分析：该路段导频污染严重。 解决办法：逆时针调整PN255方位角15度，并适当增大其发射功率；适当降低PN87和PN423的发射功率。,合肥典型事件分析呼叫失败,2、导频污染严重导致被叫Connection建立失败 发生次数：7（
9、发生在OFF4次，ON3次） 问题描述：信号质量较差（SINR-6dB），扇区用户10。被叫收到寻呼消息后发送RU+CR，但未收到Ack，Connection建立失败。 问题分析：一是AN可能未收到被叫发送的RU+CR，二是AN收到后未做任何响应（这种可能性较小）。 解决办法：优化问题路段无线覆盖，对问题路段进行复测重现，如继续出现则需结合RNC进行分析。 具体影响：造成呼叫失败。 影响指数： ,合肥典型事件分析呼叫失败,问题描述：MS由西向东行驶，被叫收到寻呼消息后随即发送RU+CR，但AN未作任何响应。 问题分析：一是AN可能未收到被叫发送的RU+CR，二是AN收到后未做任何响应（这种可能
10、性较小）。 解决办法：调整PN441天馈，并适当增大PN441的发射功率，使其成为该路段主导频。对问题路段进行复测重现，如继续出现则需结合RNC进行分析。,合肥典型事件分析呼叫失败,3、被叫未收到寻呼消息 发生次数：3（ON发生2次，OFF发生1次） 问题描述：信号较差，被叫未收到寻呼消息。 问题分析：一种可能是AN下发了寻呼消息，但被叫未收到，这需要优化问题路段的信号质量；另一种可能是AN并没有下发寻呼消息（可能性较小），这要结合RNC进行分析。 解决办法：对问题路段进行无线优化，再进行复测重现，如果再次出现需结合RNC进行分析。 具体影响：造成呼叫失败。 影响指数：,合肥典型事件分析呼叫失
11、败,问题描述：主叫起呼后随即建立了EVDO Connection,但被叫一直未收到寻呼消息。 问题分析：问题路段处于315省道上，信号质量较差。一种可能是AN下发了寻呼消息，但被叫未收到，这需要优化问题路段的信号质量；另一种可能是AN并没有下发寻呼消息（可能性较小），这要结合RNC进行分析。 解决办法：针对该路段无线覆盖进行优化，增加PN294发射功率。对问题路段进行复测，如果重现则需结合RNC进行分析。,合肥典型事件分析呼叫失败,4、寻呼过晚 发生次数：3（在OFF发生1次，ON发生2次） 问题描述：从主叫起呼（发送DOS消息）到被叫收到寻呼消息超过5-6s，平台即判为未接通。 问题分析：阿
12、朗的寻呼策略是前两次都是“Last active set”，第三次才开始“Last seen RNC”，每次时间间隔1s。考虑到系统和空口时延，如果被叫离开了“Last active set”，被叫接收到寻呼消息的时间有可能超过5s。 解决办法：修改阿朗的第二次寻呼为“Last seen RNC” 。 具体影响：造成呼叫失败。 影响指数：,合肥典型事件分析呼叫失败,问题描述：主叫于9：28：56.879发送RU+CR+DOS，但被叫于9：29：05.716才收到寻呼消息 问题分析：被叫最近一次发送RU在09：26：23.704，“Last active set”是PN213和PN45。而从9：
13、28：56.879(主叫起呼时间)后，被叫就一直占用PN402。前两条寻呼消息都下发去了PN213和PN45，被叫只能接收到第三条寻呼消息“Last seen RNC”。 解决办法：更改阿朗设备的第二条寻呼消息为“Last seen RNC”。,合肥典型事件分析呼叫失败,合肥典型事件分析呼叫失败,5、AN拒绝终端QOS请求 发生次数：2（全部发生在ON） 问题描述：无线环境一般或较差，AN拒绝了终端的QOS请求。 问题分析：基站QOS licence不足。 解决办法：增加问题基站的QOS licence。 影响指数：,合肥典型事件分析呼叫失败,问题描述：主叫起呼发起RU+CR+DOS+RR（Q
14、OS请求），AN下发了Ack消息，随后下发ReservationReject+Connectiondeny拒绝了主叫的QOS请求。 问题分析：首先PN9的QOS权限不足；其次，PN9和PN372存在导频干扰。 解决办法：检查并增加“安徽医科大学新区北侧”的QOS权限；针对PN9和PN372之间的干扰进行优化。,合肥典型事件分析呼叫失败,开启QOS时接通率较低，29次呼叫失败中有19次发生在开发区，具有一定区域集中性。经过省网优中心、高通公司、阿朗公司的共同分析，确定问题原因是QoS License问题，详见案例。,合肥典型事件分析QoS License,目录,QCHAT不同寻呼策略指标对比,一
15、,寻呼策略阿朗（2/2）,寻呼次数：可设定，最多8次 对于BE寻呼，Last active set和last seen RNC最多各4次；对于QoS寻呼，active set和RNC寻呼的次数无限制，但总的寻呼次数是8次。 寻呼范围：the Last Active Set或the Last Seen RNC 对于BE寻呼，顺序上默认Last active set寻呼总是先于last seen RNC，除非不选择进行active set 寻呼。对于基于Qos的寻呼，在网管设置上没有先后顺序的限制，但逻辑上应该先进行last active set寻呼，除非不选择last active set 寻呼
16、。 寻呼间隔：默认值是2秒，对于BE寻呼在在0.110之间可设定，对于Qos寻呼，在0.1-5之间之间可设定。 实际2次寻呼消息之间的时间间隔取SCI与寻呼间隔两者之间的较大值，即基站在空口发送寻呼消息的间隔为max（寻呼间隔，寻呼周期SCI），例如，设定寻呼间隔=2秒，且SCI=9，那么RNC向BTS发送寻呼消息的间隔为5.12秒；如果SCI=5，那么RNC向BTS发送寻呼消息的间隔为2s。,the Last Active Set来自于AT之前最后一次上报的route update 消息。 系统记录AT上次上报的route update消息，并且通过Paging Escalation Tim
17、er控制，如果超出时限，则会扩大寻呼范围为last seen RNC。 Paging Escalation Timer，范围165536minutes 默认设置65536，目前不可修改。,寻呼策略阿朗（2/2）,寻呼策略中兴,AN采用分层寻呼机制，每层寻呼包含的载扇范围不同，共有三种不同层次的寻呼范围： 第一层寻呼（最近上报的有效激活集扇区寻呼） 当距上次终端与基站侧联系间隔t满足t 子网方式RU有效时间（默认10秒），使用第三层寻呼。,寻呼策略不同策略接通率对比,通过对市区QoS OFF状态下的不同寻呼策略接通率的对比发现： 中兴的寻呼策略，指标较好，策略较智能； 阿朗的寻呼策略，寻呼间隔设为1秒时明显优于其他设置。,感谢集团公司领导和兄弟公司同仁聆听 谢谢,