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

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 4dB 终端搜索不到EVDO导频 导致掉话 Reason systermlost 解决办法 针对无线参数SINR值进行优化 具体影响 造成EVDO掉线 影响指数 合肥典型事件分析 掉话 问题描述 MS由西向东行驶 在该路段发生EVDO掉线 Reason systemlost 问题分析 该路段PN228和PN315之间存在干扰 信号较差 SINR值 4 54dB 导致终端接收不到EVDO前向消息而掉线 解决办法 调整天馈 针对SINR值进行优化 合肥典型事件分析 掉话 合肥典型事件分析 呼叫失败 1 SINR值连续4s低于 7dB 终端切换至1x导致掉话发生次数 8 在OFF发生6次 ON发生2次 问题描述 起呼或通话中 SINR值连续4s低于 7dB 继而切换至1X上 问题分析 问题路段一般接收电平良好 RxAGC 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 1 10之间可设定 对于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 范围1 65536minutes默认