安徽公司QCHAT无线质量测评汇报

0,安徽公司QCHAT无线质量测评汇报,目录,QCHAT不同寻呼策略指标对比,一,哪个模版能准确测出网络的真实性能？,准备工作,测试模板分析,测试模板的关键要素：呼叫间隔时间通话时长连接超时时间,安徽测试模板调整：为了确保每次呼叫能够采集QCHAT的完整信令，呼叫间隔由20秒调整为45秒；鼎利连接超时的定义为主叫终端发送PPTEVENT到收到TonePlayed的间隔，与QCHAT被叫4.5秒超时的定义不一致（服务器发出ANNOUNCE到收到ANNOUNCEACK的间隔），连接超时时间由5秒调整为15秒。,阿朗区测试情况分析滁州DT,寻呼策略配置：四次寻呼，前两次为Lastactiveset，后两次为lastseenRNC，寻呼间隔1.5秒。,阿朗区测试情况分析合肥DT,寻呼策略配置：四次寻呼，前两次为Lastactiveset，后两次为lastseenRNC，寻呼间隔1秒。QoSLicense配置：优化前：RNClicense上限控制数目是300，每个基站上限控制数目是12优化后：RNClicense上限控制数目是1000，基站281、62上限控制数目是14，其它基站12,阿朗区测试情况分析六安DT,寻呼策略配置：优化前：四次寻呼，前两次为Lastactiveset，后两次为lastseenRNC，寻呼间隔2秒；优化前：四次寻呼，前两次为Lastactiveset，后两次为lastseenRNC，寻呼间隔1秒；,中兴区测试情况分析马鞍山DT,寻呼策略配置：寻呼次数：2次；寻呼间隔：1.5秒；寻呼范围：3级，“邻区方式RU有效时间RUNLAvailableTime”与“子网方式RU有效时间RUSNAvailableTime”分别为1秒和10秒。,阿朗区测试情况分析CQT,CQT测试整体指标较好，失败原因与DT测试类似,目录,QCHAT不同寻呼策略指标对比,一,失败原因最多的为被叫寻呼不到，经过寻呼策略优化后，QoSOFF情况下已解决，但QoSON的情况仍有出现，正在进一步分析优化中。,典型事件分析分布六安,在QoSLicense优化后，失败原因最多的为由于DO信号质量问题切换至1X以及导频污染。,典型事件分析分布合肥,失败原因最多的为由于DO信号质量问题切换至1X以及寻呼过晚。,典型事件分析分布滁州,异常事件主要为掉话，其中基站主动下发ConnectionClose的占比较大，目前，正在进一步分析中。,典型事件分析分布马鞍山,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易造成掉话；其次问题路段导频污染也较为严重。解决办法：优化子网边界，减小子网间的重叠覆盖；针对导频污染进行优化。具体影响：造成呼叫失败或掉话。影响指数：,合肥典型事件分析掉话,问题描述：问题路段处于ColorCode2和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进行分析。具体影响：造成呼叫失败。影响指数：,合肥典型事件分析呼叫失败,问题描述：主叫起呼后随即建立了EVDOConnection,但被叫一直未收到寻呼消息。问题分析：问题路段处于315省道上，信号质量较差。一种可能是AN下发了寻呼消息，但被叫未收到，这需要优化问题路段的信号质量；另一种可能是AN并没有下发寻呼消息（可能性较小），这要结合RNC进行分析。解决办法：针对该路段无线覆盖进行优化，增加PN294发射功率。对问题路段进行复测，如果重现则需结合RNC进行分析。,合肥典型事件分析呼叫失败,4、寻呼过晚发生次数：3（在OFF发生1次，ON发生2次）问题描述：从主叫起呼（发送DOS消息）到被叫收到寻呼消息超过5-6s，平台即判为未接通。问题分析：阿朗的寻呼策略是前两次都是“Lastactiveset”，第三次才开始“LastseenRNC”，每次时间间隔1s。考虑到系统和空口时延，如果被叫离开了“Lastactiveset”，被叫接收到寻呼消息的时间有可能超过5s。解决办法：修改阿朗的第二次寻呼为“LastseenRNC”。具体影响：造成呼叫失败。影响指数：,合肥典型事件分析呼叫失败,问题描述：主叫于9：28：56.879发送RU+CR+DOS，但被叫于9：29：05.716才收到寻呼消息问题分析：被叫最近一次发送RU在09：26：23.704，“Lastactiveset”是PN213和PN45。而从9：28：56.879(主叫起呼时间)后，被叫就一直占用PN402。前两条寻呼消息都下发去了PN213和PN45，被叫只能接收到第三条寻呼消息“LastseenRNC”。解决办法：更改阿朗设备的第二条寻呼消息为“LastseenRNC”。,合肥典型事件分析呼叫失败,合肥典型事件分析呼叫失败,5、AN拒绝终端QOS请求发生次数：2（全部发生在ON）问题描述：无线环境一般或较差，AN拒绝了终端的QOS请求。问题分析：基站QOSlicence不足。解决办法：增加问题基站的QOSlicence。影响指数：,合肥典型事件分析呼叫失败,问题描述：主叫起呼发起RU+CR+DOS+RR（QOS请求），AN下发了Ack消息，随后下发ReservationReject+Connectiondeny拒绝了主叫的QOS请求。问题分析：首先PN9的QOS权限不足；其次，PN9和PN372存在导频干扰。解决办法：检查并增加“安徽医科大学新区北侧”的QOS权限；针对PN9和PN372之间的干扰进行优化。,合肥典型事件分析呼叫失败,开启QOS时接通率较低，29次呼叫失败中有19次发生在开发区，具有一定区域集中性。经过省网优中心、高通公司、阿朗公司的共同分析，确定问题原因是QoSLicense问题，详见案例。,合肥典型事件分析QoSLicense,目录,QCHAT不同寻呼策略指标对比,一,寻呼策略阿朗（2/2）,寻呼次数：可设定，最多8次对于BE寻呼，Lastactiveset和lastseenRNC最多各4次；对于QoS寻呼，activeset和RNC寻呼的次数无限制，但总的寻呼次数是8次。寻呼范围：theLastActiveSet或theLastSeenRNC对于BE寻呼，顺序上默认Lastactiveset寻呼总是先于lastseenRNC，除非不选择进行activeset寻呼。对于基于Qos的寻呼，在网管设置上没有先后顺序的限制，但逻辑上应该先进行lastactiveset寻呼，除非不选择lastactiveset寻呼。寻呼间隔：默认值是2秒，对于BE寻呼在在0.110之间可设定，对于Qos寻呼，在0.1-5之间之间可设定。实际2次寻呼消息之间的时间间隔取SCI与寻呼间隔两者之间的较大值，即基站在空口发送寻呼消息的间隔为max（寻呼间隔，寻呼周期SCI），例如，设定寻呼间隔=2秒，且SCI=9，那么RNC向BTS发送寻呼消息的间隔为5.12秒；如果SCI=5，那么RNC向BTS发送寻呼消息的间隔为2s。,theLastActiveSet来自于AT之前最后一次上报的routeupdate消息。系统记录AT上次上报的routeupdate消息，并且通过PagingEscalationTimer控制，如果超出时限，则会扩大寻呼范围为lastseenRNC。PagingEscalationTimer，范围165536minutes默认设置65536，目前不可修改。,寻呼策略阿