TD-SCDMA网络基于客户感知的掉话率相关定时器优化分析

TD SCDMATD SCDMA 网络基于客户感知的掉话率相关定时器优化分析网络基于客户感知的掉话率相关定时器优化分析 郭 宝 李冶文 1 中国移动通信集团山西有限公司太原分公司 太原 2 中国移动通信有限公司网络部 北京 摘要摘要 TD SCDMA 网络处于逐步完善覆盖的时期 为了更好地提升用户使用感知 需要网优工程师及时发现 网络中的问题 尤其是严重影响客户感知的掉话问题 本文针对 TD SCDMA 网络中掉话率相关定时器 计 数器设置过大导致的 网管统计信息不准确 的问题进行优化分析 并提出一种切实有效的优化方法 1 1 引言引言 在无线通信中 如果链路突然失步 系统和终端侧会启动一个等待链路恢复的定时器 并按照设定的最大 允许次数的计数器来进行恢复链路的尝试 这就是掉话率相关定时器 计数器 如果定时器 计数器设置 过大 会发生系统一直在等待链路恢复 而用户早已不能忍受长时间等待主动挂机 这样会导致统计的掉 话率指标无法真实反映网络质量 在进行网络优化前 需要建立面向客户感知的网络质量指标 需对掉话 率相关的定时器 计数器进行修改 在无线侧链路失步等待最长不大于 16 s 这样一来 之前被定时器 所掩盖的网络掉话问题就普遍暴露出来 体现为 网管统计掉话率指标急剧恶化 本文重点分析完成掉 话率相关定时器修改后明显增加的无线链路失败类的掉话原因 并提出一种切实有效的优化方法 2 2 掉话率定时器 计数器分析掉话率定时器 计数器分析 1 连续同步指示次数 N INSYNC IND 小区级参数 参数取值范围 1 256 物理单位 个 该参数被 NodeB 用于检测 UU 接口上行是否同步 当一个 CCTRCH 处于失步状态 NodeB 在连续收到 N INSYNC IND 个同步指示后将会判断当前 CCTRCH 已经 重新同步 NodeB 会上报 Radio Link Restore Indication 消息 并将当前 CCTRCH 状态置为同步状态 连续同步指示次数 设置得越大 NodeB 就越难 察觉 CCTRCH 上行重新同步 从而造成 Radio Link Restore Indication 发送 的延迟 甚至是无法发送 最终造成 RNC 误认为当前 CCTRCH 上行无法恢复同 步 从而导致发起链路重建或释放 设置得越小 NodeB 就越容易判断当前 CCTRCH 上行重新同步 但同时就越增加降低当前 CCTRCH 信道上行传输质量的 风险 2 连续不同步指示次数 N OUTSYNC IND 小区级参数 参数取值范围 1 256 物理单位 个 该参数被 NodeB 用于检测 UU 接口上行是否失步 该参数在检测上行同步过程 中主要与参数 N INSYNC IND 配合使用 参数设置得过大 NodeB 要较长时 间才能察觉 CCTRCH 上行失步 此时间内相关资源无法及时释放 也无法发起 恢复操作或响应新的资源建立请求 参数设置得过小 很可能造成 CCTRCH 上 行对偶尔的闪断过于敏感 从而对本可以迅速自我恢复的 CCTRCH 上行 RL Failure Indication 消息也判断为不同步 进入不同步的恢复等待流程 造成 系统不必要的消息处理和流程开销 3 T313 定时器为 RNC 级参数 参数取值范围 0 15 物理单位 s T313 是连接模式下 UE 检测无线链路失败的定时器 在 SIB1 中广播 当 UE 从 L1 检测到连续 N313 个失步指示后启动 T313 定时器 当 UE 从 L1 检测到连 续 N315 个同步指示后停止 T313 定时器 一旦 T313 超时 UE 上报原因值为 RL Failure 的 Cell Update 消息通知 RNC 空中接口下行失步 T313 设置得过 大 UE 要较长时间才能察觉 RL 下行失步 此时间内相关资源无法及时释放 也无法发起恢复操作或响应新的资源建立请求 T313 设置得过小 很可能造成 对 RL 偶尔的闪断过于敏感 从而对本可以迅速自我恢复的 RL 频繁上报 Cell Update 消息 造成系统不必要的消息处理和流程开销 4 N313 计数器为 RNC 级参数 N313 表示连接模式下 UE 从 L1 收到连续失 步指示的最大次数 在 SIB1 中广播 N313 设置得越大 UE 对 RL 失步的判断 就越不敏感 可能造成本来不可用的 RL 迟迟不能被上报 RL 失步进而无法触发 后续的恢复或重建操作 N313 设置得越小 越可以保证 RL 传输的可靠性 但 相应地也会增加可恢复性 RL 闪断的误判 从而可能导致 UE 频繁的上报原因值 为 RL Failure 的 Cell Update 消息 5 N315 计数器与定时器 T313 计数器 N313 结合使用 T313 为 CELL DCH 状 态失去同步后的等待时间 用于无线链路失败判决过程 在 CELL DCH 状态下 收到 L1 层连续 N313 个 out of sync 失步指示时 即表示已经建立的 DPCCH 物理信道可能失步 此时 UE 将启动 T313 如果在 T313 运行时间内 收到 L1 层连续 N315 个同步指示 in sync 则停止并重置 T313 3 3 无线链路失败过程分析无线链路失败过程分析 无线链路失败 radio link failure 当上行无线链路出现连续错帧时 NodeB 上报 Radio Link Failure Indication RNC 释放无线侧资源 释放原因 即为 RlFail Report CS 域此类掉话由上行干扰 弱覆盖导致 发生在 PS 域 的 RlFail 掉话由用户行为的非正常断网导致 3 13 1 旧版上行旧版上行 RLRL FailureFailure 掉话机制掉话机制 某厂家 TD 设备旧版上行 RL Failure 的掉话机制 如图 1 所示 图 1 老版本上行 RL Failure 机制 A NodeB 检测到 N OUTSYNC IND 次失步指示 B 经过 TRLFailure NodeB 仍未重新检测到同步 NodeB 向 RNC 发出 RL Failure Indication C 经过 RLRSTRTMR T302 N302 RNC 未收到 RL Restore Indication 于是 发出 Iu Release Request 发生掉话 因此 上行 RL Failure 定时器总时长为 0 16 N OUTSYNC IND TRLFailure RLTSTRTMR T302 N302 例如 N OUTSYNC IND 20 TRLFailure 200 N INSYNC IND 1 RLTSTRTMR 10 N302 3 T302 4 那么 当 NodeB 检测到 20 次失步 每一个检测周期 160 ms 20 0 16 3 2 s 后 即启动 TRLFailure 若在 TRLFailure 超时 200 0 1 20 s 前 NodeB 依旧没有检测到 N INSYC IND 1 个检测周期 160 ms 个同步帧 NodeB 即向 RNC 发出 RL Failure Indication RNC 收到该消息后 即启动 RLRSTRMR 若 RLRSTRTMR 超时 10 s 仍没有收到 NodeB 发出的 RL Restore 则再启动 N302 T302 共 12 s 若 RNC 依旧没有收到 NodeB 发出的 RL Restore 则最终 RNC 向 CN 发出 Iu Release Request 该呼叫掉话 根据以上 的设定 实际在该 RL Failure 掉话中 总共等待的时间是 20 0 16 200 0 1 10 4 3 45 2 s 这里的掉话等待时间其实是 RNC 及 CN 的内部等待时间 并不是实际用户等待时 间 通常情况下是主叫最多在十几秒后就主动挂断 其实整个过程 主叫先上 行失步 此时已经与 RNC 失去联系 主叫不可能与 CN 取得联系 所以主叫挂断 后是否记为掉话就看 RNC 和 CN 的掉话机制了 3 23 2 下行下行 RLRL FailureFailure 掉话机制掉话机制 下行 RL Failure 的掉话机制 如图 2 所示 图 2 下行 RL Failure 掉话机制 1 UE 判断下行失步总时间 0 16 N313 1 0 01 2 之后等待 T313 若没有检测到恢复 则 UE 开始进行小区搜索 并启动 T314 3 完成小区搜索后 UE 发起 Cell Update 4 对 CS 业务在 T314 超时前 若 Cell Update 没有成功 则 UE 放弃该呼叫 发生掉话 因此 下行 RL Failure 定时器总长 0 16 N313 1 0 01 T313 小区搜 索 T314 4 4 定时器修改后指标对比定时器修改后指标对比 本文重点分析无线侧掉话率相关定时器 根据用户实际使用感受 要求上行或 下行无线链路超时最长不超过 16 s 统计为从第一个失步指示开始到 RNC 向 CN 发送 Iu Release Request 或 RAB Release Request 的总时长 其中 N313 10 N315 4 N OUTSYNC IND 10 N INSYNC IND 4 上述掉话率相关定时器修改完成后 对修改前后每天 6 忙时的性能指标 进行 掉话率对比分析 如表 1 所示 在本次参数修改后 掉话率指标大幅恶化 由 0 09 急升到 0 45 从统计原因值可以看出 掉话原因值最多主要有两项 RNC 请求释放电路域 Iu 连接对应的 RAB 数目 原因 RlFail Report RNC 请求释放电路域 Iu 连接对应 的 RAB 数目 原因 RNLC UE Cell Update Time Out 表 1 掉话率相关定时器修改后的掉话率指标对比 详细分析 CS 域掉话原因 发现修改后原因为 RNC 请求释放电路域 Iu 连接对应 的 RAB 数目 原因 RlFail Report 引起的掉话次数从之前的 6 次急升为 487 次 占总掉话次数的 76 6 5 5 无线链路失败的优化分析无线链路失败的优化分析 5 15 1 新版本上行新版本上行 RLRL FailureFailure 掉话机制掉话机制 新版本上行 RL Failure 的掉话机制 如图 3 所示 图 3 上行 RL Failure 机制 A NodeB 检测到 N OUTSYNC IND 次失步指示 B 经过 TRLFailure NodeB 仍未重新检测到同步 NodeB 向 RNC 发出 RL Failure Indication C 经过 RLRSTRTMR T302 N302 RNC 未收到 RL Restore Indication RNC 向 NodeB 发送 RL Del 要求 NodeB 关闭下行链路功率 以强迫 UE 进行 Cell Update D 经过 ABNORMRETRIEVTMR RNC 判断 UE 进行 Cell Update 未成功 最终释 放该呼叫 与老版本相比较 新版本在 C 点之后要求 NodeB 关闭下行链路 并启动 ABNORMRETRIEVTMR 定时器 以强迫 UE 自身通过 Cell Update 进行掉话挽救 5 25 2 RLRL FailureFailure 的优化分析的优化分析 老版本挽救 RL Failure 主要有以下 2 种途径 1 收到 NBAP RL Restore 指示消息 恢复链路 如图 4 所示 RL Failure 后 NodeB 检测到连续的同步后 N INSYNC IND 目前配置为 4 也就是连续 4 个同步 向 RNC 发 RL RESTORE IND 此时链路恢复 新版本对掉话挽救机制进行了优化 原有的恢复机制保留 并在 RL Restore T302 N302 超时后不直接释放 Iu 而是删除 RL 上行在 RL Restore T302 N302 超时后删除 RL Radio Link Deletion Req 时启动 ABNORMRETRIEVTMR 定时器 当 RL 删除后 该链路下行没有发射功率 强迫 UE 发 Cell Update 尝试挽救掉话 6 6 掉话率相关定时器优化效果掉话率相关定时器优化效果 在新版本中 掉话率相关定时器参数引入了 ABNORMRETRIEVTMR 定时器 该参数 启用后 RL Failure 3 4 s 后 T302 N302 TRLRestore 1400 2 600 3 400 ms 会主动删掉 RL 删除后 该链路下行没有发射功率 强迫 UE 发 Cell Update 在现网性能报告统计中发现 修改 ABNORMRETRIEVTMR 定时