0安徽公司安徽公司QCHATQCHAT无线质量测评汇报无线质量测评汇报 目录目录QCHAT测试情况一QCHAT典型事件分析二二QCHAT不同寻呼策略指标对比一哪个模版能准确测哪个模版能准确测出网络的真实性能出网络的真实性能？准备工作准备工作测试模板分析测试模板分析呼叫类型呼叫间隔时间（秒）通话时长（秒）连接超时时间（秒）集团推荐短呼20905长呼205安徽测试短呼459015长呼4515测试模版呼叫尝试次数（有网）呼叫成功次数呼叫成功率(%)呼叫间隔45s-呼叫超时5s-通话时长90s-ON63 48 76.19%呼叫间隔45s-呼叫超时15s-通话时长90s-ON63 59 93.65%测试模板的关键要素：测试模板的关键要素：呼叫间隔时间呼叫间隔时间通话时长通话时长连接超时时间连接超时时间安徽测试模板调整：安徽测试模板调整：为了确保每次呼叫能够采集QCHAT的完整信令，呼叫间隔由20秒调整为45秒；鼎利连接超时的定义为主叫终端发送PPT EVENT到收到TonePlayed的间隔，与QCHAT被叫4.5秒超时的定义不一致（服务器发出ANNOUNCE到收到ANNOUNCE ACK的间隔），连接超时时间由5秒调整为15秒。阿朗区测试情况分析阿朗区测试情况分析滁州滁州DTDT区域类型覆盖率呼叫尝试次数呼叫成功次数呼叫失败次数接通率掉话次数掉话率初始呼叫建立时延（s）呼叫建立初始媒体时延(s)通话中话权转换时延(s) 通话中媒体时延(s)市区短呼ON92.18%2822671594.68%10.38%1.8581.0560.1480.295短呼OFF92.64%2752552092.73%41.57%2.4571.0440.1050.31长呼ON97.60%880100.00%00.00%1.4280.8230.1030.315长呼OFF97.91%990100.00%222.22%1.7050.9360.1140.32国省道短呼OFF87.22%151144795.36%21.39%1.6741.0420.1310.329长呼OFF95.76%990100.00%00.00%1.2711.0540.4820.33寻呼策略配置：寻呼策略配置：四次寻呼，前两次为四次寻呼，前两次为Last active setLast active set，后两次为，后两次为last seen RNClast seen RNC，寻呼间隔，寻呼间隔1.51.5秒。秒。阿朗区测试情况分析阿朗区测试情况分析合肥合肥DTDT区域类型覆盖率呼叫尝试次数呼叫成功次数呼叫失败次数接通率掉话次数掉话率初始呼叫建立时延（s）呼叫建立初始媒体时延(s)通话中话权转换时延(s) 通话中媒体时延(s)市区短呼ON（优化前）91.47%3393102991.45%41.29%2.2991.0060.1350.292长呼ON（优化前）98.10%13130100.00%00.00%1.6991.260.1010.295短呼ON（优化后）91.60%2442331195.49%21.29%2.7460.8920.0910.279长呼ON（优化后）97.71%990100.00%00.00%2.0160.9830.2210.289短呼OFF 92.20%274269598.18%20.74%2.4050.9680.1260.313长呼OFF 98.28%550100.00%00.00%1.8580.9270.1090.341国省道、环城高速短呼OFF 87.21%185178796.22%00.00%2.0950.9830.1010.314长呼OFF 97.27%880100.00%112.50%2.6520.9330.0980.326寻呼策略配置：寻呼策略配置：四次寻呼，前两次为四次寻呼，前两次为Last active setLast active set，后两次为，后两次为last seen RNClast seen RNC，寻呼间隔，寻呼间隔1 1 秒。秒。QoSLicenseQoSLicense配置：配置：优化前：优化前： RNC license RNC license上限控制数目是上限控制数目是300300，每个基站上限控制数目是，每个基站上限控制数目是1212优化后：优化后： RNC license RNC license上限控制数目是上限控制数目是10001000，基站，基站281281、6262上限控制数目是上限控制数目是1414，其它基站，其它基站1212阿朗区测试情况分析阿朗区测试情况分析六安六安DTDT区域类型覆盖率呼叫尝试次数呼叫成功次数呼叫失败次数接通率掉话次数掉话率初始呼叫建立时延（s）呼叫建立初始媒体时延(s)通话中话权转换时延(s) 通话中媒体时延(s)市区 短呼OFF（优化前）93.03%1471024569.39%00%2.6850.9970.1120.319短呼OFF（优化后）94.34%233232199.57%00%2.5460.9770.1020.311短呼ON92.38%2822513189.01%10.40%2.870.9170.1050.282长呼ON97.56%98188.89%112.50%3.2420.9170.0910.283长呼OFF 98.34%220100%00%3.961.2240.1070.29国省道短呼OFF 91.89%452445798.45%00%1.9740.9750.1020.302长呼OFF 96.51%22220100%14.55%2.5190.9140.1010.259寻呼策略配置：寻呼策略配置：优化前：四次寻呼，前两次为优化前：四次寻呼，前两次为Last active setLast active set，后两次为，后两次为last seen RNClast seen RNC，寻呼间隔，寻呼间隔2 2秒；秒；优化前：四次寻呼，前两次为优化前：四次寻呼，前两次为Last active setLast active set，后两次为，后两次为last seen RNClast seen RNC，寻呼间隔，寻呼间隔1 1秒；秒；中兴区测试情况分析中兴区测试情况分析马鞍山马鞍山DTDT区域类型覆盖率呼叫尝试次数呼叫成功次数呼叫失败次数接通率掉话次数掉话率初始呼叫建立时延（s）呼叫建立初始媒体时延(s)通话中话权转换时延(s) 通话中媒体时延(s)市区 短呼ON91.56%301294797.67%103.74%1.5971.0540.1060.316短呼OFF93.60%255252398.82%41.59%1.3370.9320.2010.273长呼ON97.14%880100%00%1.1760.2370.0960.237长呼OFF96.70%880100%225.00% 1.1120.9440.1210.301国省道短呼OFF94.02%7975494.94%22.67%1.4660.8490.1030.29长呼OFF98.51%440100%125%1.0990.8510.3880.312寻呼策略配置：寻呼策略配置：寻呼次数：寻呼次数：2 2次；次；寻呼间隔：寻呼间隔：1.51.5秒；秒；寻呼范围：寻呼范围：3 3级，级， “ “邻区方式邻区方式RURU有效时间有效时间RUNLAvailableTimeRUNLAvailableTime”与与“子网方式子网方式RURU有效时间有效时间RUSNAvailableTimeRUSNAvailableTime”分别为分别为1 1秒和秒和1010秒秒。阿朗区测试情况分析阿朗区测试情况分析CQTCQT区域QoS类型覆盖率呼叫尝试次数呼叫成功次数呼叫失败次数接通率掉话次数掉话率初始呼叫建立时延（s）呼叫建立初始媒体时延(s)通话中话权转换时延(s) 通话中媒体时延(s)滁州市区CQT on 94.32% 478477199.79% 10.21% 1.46021.0217 0.08820.3049合肥市区CQT on 94.78% 1179 11592098.30% 20.17% 1.6130.9610.092 0.296六安市区CQT off 98.57% 5005000100.00% 00.00% 1.3450.9840.132 0.309安庆市区CQT on 98.30% 598592699.00% 101.67% 1.3171.0960.097 0.306CQTCQT测试整体指标较好，失败原因与测试整体指标较好，失败原因与DTDT测试类似测试类似目录目录QCHAT测试情况一QCHAT典型事件分析二二QCHAT不同寻呼策略指标对比一类型次数分类占比掉话（共3次）2切换未收到TCA消息 66.70%1弱覆盖(RX-90dBm)33.30%呼叫失败（共85次）54被叫未收到page消息 63.53%10未收到TCA消息 11.76%6弱覆盖(RX-90dBm) 7.06%6基站拒绝QOS请求 7.06%4导频污染 4.71%3AN拒绝Connection请求 3.53%1connection建立时间过长 1.18%1超过最大用户接入数 1.18%失败原因最多的为被叫寻呼不到，经过寻呼策略优化后，失败原因最多的为被叫寻呼不到，经过寻呼策略优化后，QoS OFFQoS OFF情况下已情况下已解决，但解决，但QoS ONQoS ON的情况仍有出现，正在进一步分析优化中。的情况仍有出现，正在进一步分析优化中。典型事件分析分布典型事件分析分布六安六安类型次数分类占比掉话（共6次）3SINR值连续4s低于-7dB，终端切换至1x50.00%2子网边界处，导频污染严重，基站侧下发close，导致掉话33.33%1EVDO掉线（systermlost）导致掉话16.67%呼叫失败（共23次）8SINR值连续4s低于-7dB，终端切换至1x 34.78%7导频污染严重导致被叫Connection建立失败30.44%3被叫未收到寻呼消息13.04%3寻呼过晚导致未接通13.04%2基站拒绝QOS请求8.70%在在QoS LicenseQoS License优化后，失败原因最多的为由于优化后，失败原因最多的为由于DODO信号质量问题切换至信号质量问题切换至1X1X以以及导频污染。及导频污染。典型事件分析分布典型事件分析分布合肥合肥类型次数分类占比掉话（共9次）9SINR值连续4s低于-7dB，终端切换至1x100%呼叫失败（共42次）16SINR值连续4s低于-7dB，终端切换至1x38.10%13寻呼过晚30.95%4AN对被叫EVDO请求未做任何响应9.52%4AN拒绝被叫Connection请求9.52%3被叫未收到寻呼消息，主叫提示被叫不在服务区7.14%1被叫未收到TCA2.38%1子网边界导致呼叫失败 2.38%失败原因最多的为由于失败原因最多的为由于DODO信号质量问题切换至信号质量问题切换至1X1X以及寻呼过晚。以及寻呼过晚。典型事件分析分布典型事件分析分布滁州滁州类型次数分类占比掉话（共19次）7AN下发connectionclose 36.84%4异频切换 21.05%4邻区漏配 21.05%2无主导频 10.53%2跨省切换 10.53%呼叫失败（共14次）5被叫未收到寻呼消息 35.71%4跨省市切换 28.57%2异频切换 14.29%2无主导频 14.28%1connection建立时间过长 7.14%异常事件主要为掉话，其中基站主动下发异常事件主要为掉话，其中基站主动下发Connection CloseConnection Close的占比较大，目的占比较大，目前，正在进一步分析中。前，正在进一步分析中。典型事件分析分布典型事件分析分布马鞍山马鞍山1、SINR值连续4s低于-7dB，终端切换至1x导致掉话本地网：合肥发生次数：3（全部发生在OFF）问题描述：起呼或通话中， SINR值连续4s低于-7dB ，继而切换至1X上。问题分析：问题路段一般接收电平良好（RxAGC-75dBm），但SINR值很低（普遍低于-7dBm），存在较强的导频污染。解决办法：针对SINR值进行优化。具体影响：造成呼叫失败或掉话。影响指数：合肥典型事件分析合肥典型事件分析掉话掉话问题描述：问题描述：MS由西向东行驶，RXAGC=-88.35dBm，SINR=-11dB，终端切换至1x上，导致掉话。问题分析：问题分析：图中所圈基站（站名：金牛）没有DO载波，导致该路段EVDO覆盖较差。解决方法：解决方法：增加金牛站的EVDO载波。合肥典型事件分析合肥典型事件分析掉话掉话2、子网边界处，导频污染严重，基站侧下发close，导致掉话发生次数：2（全部发生在ON）问题描述：处于子网边界，呼叫过程中有发生跨子网切换，导频污染严重，AN下发ConnectionClose断开Connection，导致掉话。问题分析：首先终端处于子网边界，跨子网切换时先要断开Connection易造成掉话；其次问题路段导频污染也较为严重。解决办法：优化子网边界，减小子网间的重叠覆盖；针对导频污染进行优化。具体影响：造成呼叫失败或掉话。影响指数： 合肥典型事件分析合肥典型事件分析掉话掉话问题描述：问题路段处于ColorCode 2和4的交界处，导频污染较为严重，主被叫起呼前后都发生了的Session切换。合肥典型事件分析合肥典型事件分析掉话掉话合肥典型事件分析合肥典型事件分析掉话掉话3、信号质量差，EVDO掉线导致掉话发生次数：1（发生在OFF）问题分析：无线信号质量差（SINR-75dBm），但SINR值很低（普遍低于-7dBm），存在较强的导频污染。解决办法：针对SINR值进行优化。具体影响：造成呼叫失败或掉话。影响指数：问题描述：问题描述： MS由南向北行驶，SINR值连续4s低于-7dB，终端切换至1x。问题分析：问题分析：该路段导频污染严重。解决办法：解决办法：逆时针调整PN255方位角15度，并适当增大其发射功率；适当降低PN87和PN423的发射功率。合肥典型事件分析合肥典型事件分析呼叫失败呼叫失败2、导频污染严重导致被叫Connection建立失败发生次数：7（发生在OFF4次，ON3次）问题描述：信号质量较差（SINR-6dB），扇区用户10。被叫收到寻呼消息后发送RU+CR，但未收到Ack，Connection建立失败。问题分析：一是AN可能未收到被叫发送的RU+CR，二是AN收到后未做任何响应（这种可能性较小）。解决办法：优化问题路段无线覆盖，对问题路段进行复测重现，如继续出现则需结合RNC进行分析。具体影响：造成呼叫失败。影响指数： 合肥典型事件分析合肥典型事件分析呼叫失败呼叫失败问题描述：问题描述：MS由西向东行驶，被叫收到寻呼消息后随即发送RU+CR，但AN未作任何响应。问题分析：一是AN可能未收到被叫发送的RU+CR，二是AN收到后未做任何响应（这种可能性较小）。解决办法：解决办法：调整PN441天馈，并适当增大PN441的发射功率，使其成为该路段主导频。对问题路段进行复测重现，如继续出现则需结合RNC进行分析。合肥典型事件分析合肥典型事件分析呼叫失败呼叫失败3、被叫未收到寻呼消息发生次数：3（ON发生2次，OFF发生1次）问题描述：信号较差，被叫未收到寻呼消息。问题分析：一种可能是AN下发了寻呼消息，但被叫未收到，这需要优化问题路段的信号质量；另一种可能是AN并没有下发寻呼消息（可能性较小），这要结合RNC进行分析。解决办法：对问题路段进行无线优化，再进行复测重现，如果再次出现需结合RNC进行分析。具体影响：造成呼叫失败。影响指数：合肥典型事件分析合肥典型事件分析呼叫失败呼叫失败问题描述：问题描述：主叫起呼后随即建立了EVDO Connection,但被叫一直未收到寻呼消息。问题分析：问题分析：问题路段处于315省道上，信号质量较差。一种可能是AN下发了寻呼消息，但被叫未收到，这需要优化问题路段的信号质量；另一种可能是AN并没有下发寻呼消息（可能性较小），这要结合RNC进行分析。解决办法：解决办法：针对该路段无线覆盖进行优化，增加PN294发射功率。对问题路段进行复测，如果重现则需结合RNC进行分析。合肥典型事件分析合肥典型事件分析呼叫失败呼叫失败4、寻呼过晚发生次数：3（在OFF发生1次，ON发生2次）问题描述：从主叫起呼（发送DOS消息）到被叫收到寻呼消息超过5-6s，平台即判为未接通。问题分析：阿朗的寻呼策略是前两次都是“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：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+RRRU+CR+DOS+RR（QOSQOS请求），请求），ANAN下发了下发了AckAck消息，随后下发消息，随后下发ReservationReject+ConnectiondenyReservationReject+Connectiondeny拒绝了主叫的拒绝了主叫的QOSQOS请求。请求。问题分析：首先问题分析：首先PN9PN9的的QOSQOS权限不足；其次，权限不足；其次，PN9PN9和和PN372PN372存在导频干扰。存在导频干扰。解决办法：检查并增加解决办法：检查并增加“安徽医科大学新区北侧安徽医科大学新区北侧”的的QOSQOS权限；针对权限；针对PN9PN9和和PN372PN372之间的干扰之间的干扰进行优化。进行优化。合肥典型事件分析合肥典型事件分析呼叫失败呼叫失败 开启QOS时接通率较低，29次呼叫失败中有19次发生在开发区，具有一定区域集中性。经过省网优中心、高通公司、阿朗公司的共同分析，确定问题原因是QoS License问题，详见案例。合肥典型事件分析合肥典型事件分析QoS LicenseQoS License目录目录QCHAT测试情况一QCHAT典型事件分析二二QCHAT不同寻呼策略指标对比一寻呼策略寻呼策略阿朗（阿朗（2/22/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 寻呼。寻呼间隔：默认值是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 Timer控制，如果超出时限，则会扩大寻呼范围为last seen RNC。 Paging Escalation Timer，范围165536minutes 默认设置65536，目前不可修改。寻呼策略寻呼策略阿朗（阿朗（2/22/2）寻呼策略寻呼策略中兴中兴 AN采用分层寻呼机制，每层寻呼包含的载扇范围不同，共有三种不同层次的寻呼范围：第一层寻呼（最近上报的有效激活集扇区寻呼） 当距上次终端与基站侧联系间隔t满足t 邻区方式RU有效时间（默认为1秒）时，使用第一层寻呼。第二层寻呼（邻区寻呼） 当距上次终端与基站侧联系间隔t满足：邻区方式RU有效时间t子网方式RU有效时间（默认10秒），使用第三层寻呼。寻呼策略寻呼策略不同策略接通率对比不同策略接通率对比马鞍山-1.5秒六安-2秒滁州-1.5秒六安-1秒合肥-1秒0.00%20.00%40.00%60.00%80.00%100.00%120.00%98.82%69.39%92.73%99.57%98.18%不同不同寻呼策略接通率呼策略接通率对比比通过对市区QoS OFF状态下的不同寻呼策略接通率的对比发现：中兴的寻呼策略，指标较好，策略较智能；阿朗的寻呼策略，寻呼间隔设为1秒时明显优于其他设置。感谢集团公司领导和兄弟公司同仁聆听感谢集团公司领导和兄弟公司同仁聆听谢谢谢谢