等待切换命令定时器优化探讨.docx

内部公开 Internal Use Only▲ PAGE 第PAGE 1页 以上所有信息均为中兴通讯股份有限公司所有，不得外传 All Rights reserved, No Spreading abroad without Permission of ZTE 等待切换命令定时器优化探讨 1概述 近期拉网测试中很容易出现切换“慢”、切换“拖一段时间”才能切换的问题，对拉网测试的SINR覆盖、掉话等性能造成影响。网管统计发现eNB间S1口小区间同频切换出准备失败（原因值等待切换响应定时器超时）占整个切换总次数比例高达0.5%以上。 2等待Handover Command超时的基本理论 2.1eNB间S1同频切换信令流程 eNB间同频切换信令流程见下图： 当源eNodeB接收到从UE来的测量报告消息，根据消息进行判决，如果条件满足eNodeB间S1切换，则触发UE在eNodeB间切换过程。 源eNodeB发送切换请求消息给MME，目标eNodeB接收到MME的Handover Request消息，进入资源准备。如果资源准备成功，给MME回复Handover Request Acknowledge。如果资源准备失败，则给MME回复Handover Failure。MME给资源eNodeB发送Handover Preparation Failure，切换准备过程结束。 源侧eNodeB接收到从MME来的Handover Command消息，则发起切换过程，给UE发送Handover Command(i.e.RRC Connection Reconfiguration)。 目标侧eNodeB接收到UE的RRC重配置完成后，发送Handover Notify消息给MME，指示UE已经成功切换到了目标小区。 MME接收到Handover Notify消息后，给源eNodeB发送UE Context Release Command消息，切换过程成功结束。 2.2切换准备失败——等待切换响应定时器超时 eNB间S1口小区间同频切换出准备失败次数，等待切换响应定时器超时。 数器采样点：见下图中的采样点5。即当源eNodeB给MME发送Handover Required消息时需要启动等待Handover Command消息定时器，如果定时器超时没有收到Handover Command消息，则统计为一次等待切换响应定时器超时的切换准备失败。 图 2-2? 等待切换响应定时器超时 2.3等待Handover Command消息定时器的理解 S1 HO时等待HO COMMAND的定时器默认设置为10000ms，见下图 S1 HO等待HO COMMAND定时器设置为10s，意味着在10s超时前，即使UE上报多次同频切换的MR消息，源基站也不会让UE进行第二次切换。 在切换准备阶段的源基站等待切换命令定时器超时期间，如果再收到同频切换的MR消息，源基站会将此MR缓存起来，在S1 HO等待HO COMMAND定时器超时后再发起缓存MR的切换流程，见下图： 基于上述理解，我们可以知道：在等待HO COMMAND定时器设置为10s（默认）的情况下，如果切换准备阶段出现等待HO COMMAND超时，UE侧通常会表现出切换会拖一段时间（大致10s左右），带来的影响是SINR变差、上传下载速率下降，严重时导致“掉话”。在等待HO COMMAND定时器超时短时间难以解决的情况下，等待HO COMMAND定时器设置越长，上述的影响就越大。 等待HO COMMAND超时问题通常原因在于S1链路不稳定或者MME侧处理异常，在短时间无法解决HO COMMAND超时的前提下，缩短等待HO COMMAND定时器有助于拉网测试时有助于覆盖和掉话性能的改善。 3等待HO COMMAND定时器优化 3.1等待HO COMMAND定时器优化方案 基于拉网测试中容易出现切换困难的现象（通常表现为切换会拖10s左右），另外从UDT信令跟踪中也会发现存在大量的这种等待HO COMMAND消息超时的问题，考虑通过优化等待HO COMMAND定时器来缓解这种切换“慢”的问题。 优化方案为：将【S1 HO时等待HO COMMAND定时器】从默认的10000ms优化为2000ms（见下图）。 3.2优化结果验证 S1切换等待HO COMMAND定时器优化后，从UDT信令跟踪看，与预期结果吻合，见下图： HO Command定时器优化对切换成功率基本无影响，但对DT测试的SINR覆盖以及掉话有好处。 2014年12月13日全网完成S1 HO时等待HO COMMAND定时器的修改。 下面是