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

1、TD-SCDMA网络基于客户感知的掉话率相关定时器优化分析郭 宝，李冶文（1：中国移动通信集团山西有限公司太原分公司   太原   030001）（2：中国移动通信有限公司网络部  北京 100033）   摘要 TD-SCDMA网络处于逐步完善覆盖的时期，为了更好地提升用户使用感知，需要网优工程师及时发现网络中的问题，尤其是严重影响客户感知的掉话问题。本文针对TD-SCDMA网络中掉话率相关定时器、计数器设置过大导致的“网管统计信息不准确”的问题进行优化分析，并提出一种切实有效的优化方法。1 引言在无线通信中，如

2、果链路突然失步，系统和终端侧会启动一个等待链路恢复的定时器，并按照设定的最大允许次数的计数器来进行恢复链路的尝试，这就是掉话率相关定时器、计数器。如果定时器、计数器设置过大，会发生系统一直在等待链路恢复，而用户早已不能忍受长时间等待主动挂机，这样会导致统计的掉话率指标无法真实反映网络质量。在进行网络优化前，需要建立面向客户感知的网络质量指标，需对掉话率相关的定时器、计数器进行修改，在无线侧链路失步等待最长不大于16 s。这样一来，之前被定时器所掩盖的网络掉话问题就普遍暴露出来，体现为“网管统计掉话率指标急剧恶化”。本文重点分析完成掉话率相关定时器修改后明显增加的无线链路失败类的掉话原因，并提出

3、一种切实有效的优化方法。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 Indi

4、cation发送的延迟，甚至是无法发送，最终造成RNC 误认为当前CCTRCH 上行无法恢复同步，从而导致发起链路重建或释放；设置得越小，NodeB 就越容易判断当前CCTRCH 上行重新同步，但同时就越增加降低当前CCTRCH 信道上行传输质量的风险。（2）连续不同步指示次数：N_OUTSYNC_IND，小区级参数，参数取值范围：1 256，物理单位：个。该参数被NodeB 用于检测UU 接口上行是否失步。该参数在检测上行同步过程中主要与参数“N_INSYNC_IND”配合使用。参数设置得过大，NodeB 要较长时间才能察觉CCTRCH 上行失步，此时间内相关资源无法及时释放，也无法发起恢复

5、操作或响应新的资源建立请求；参数设置得过小，很可能造成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 Fa

6、ilure 的Cell Update 消息通知RNC空中接口下行失步。T313 设置得过大，UE 要较长时间才能察觉RL 下行失步，此时间内相关资源无法及时释放，也无法发起恢复操作或响应新的资源建立请求；T313 设置得过小，很可能造成对RL 偶尔的闪断过于敏感，从而对本可以迅速自我恢复的RL 频繁上报Cell Update 消息，造成系统不必要的消息处理和流程开销。（4）N313 计数器为RNC级参数，N313 表示连接模式下UE 从L1 收到连续失步指示的最大次数，在SIB1 中广播。N313 设置得越大，UE 对RL 失步的判断就越不敏感，可能造成本来不可用的RL迟迟不能被上报RL 失步

7、进而无法触发后续的恢复或重建操作；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”，则停止并重置T

8、313。3 无线链路失败过程分析无线链路失败（radio link failure），当上行无线链路出现连续错帧时，NodeB上报Radio Link Failure Indication，RNC释放无线侧资源，释放原因即为：RlFail_Report。CS域此类掉话由上行干扰、弱覆盖导致，发生在PS域的RlFail掉话由用户行为的非正常断网导致。3.1 旧版上行RL Failure掉话机制某厂家TD设备旧版上行RL Failure的掉话机制，如图1所示。图1 老版本上行RL Failure机制ANodeB检测到N_OUTSYNC_IND次失步指示；B经过TRLFailure，NodeB仍未重

9、新检测到同步，NodeB向RNC发出RL Failure Indication；C经过RLRSTRTMR+T302×N302，RNC未收到RL Restore Indication，于是发出Iu Release Request，发生掉话。因此，上行RL Failure定时器总时长为：0.16×N_OUTSYNC_INDTRLFailureRLTSTRTMRT302×N302例如：N_OUTSYNC_IND=20，TRLFailure200，N_INSYNC_IND=1，RLTSTRTMR=10，N302=3，T302=4。那么：当NodeB检测到20次失步（每一个

10、检测周期160 ms，20×0.16=3.2 s）后，即启动TRLFailure；若在TRLFailure超时（200×0.120 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 Req

11、uest，该呼叫掉话。根据以上的设定，实际在该RL Failure掉话中，总共等待的时间是：20×0.16200×0.1+10+4×3=45.2 s。这里的掉话等待时间其实是RNC及CN的内部等待时间，并不是实际用户等待时间。通常情况下是主叫最多在十几秒后就主动挂断。其实整个过程，主叫先上行失步，此时已经与RNC失去联系，主叫不可能与CN取得联系。所以主叫挂断后是否记为掉话就看RNC和CN的掉话机制了。3.2 下行RL Failure掉话机制下行RL Failure的掉话机制，如图2所示。图2 下行RL Failure掉话机制(1)UE判断下行失步总时间0.16+

12、（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.01T313小区搜索T314。4 定时器修改后指标对比本文重点分析无线侧掉话率相关定时器，根据用户实际使用感受，要求上行或下行无线链路超时最长不超过16 s，统计为从第一个失步指示开始到RNC向CN发送“Iu Release Request”或“R

13、AB 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  掉话率相关定时器修改后的掉话率指标对

14、比详细分析CS域掉话原因，发现修改后原因为RNC请求释放电路域Iu连接对应的RAB数目，原因RlFail_Report引起的掉话次数从之前的6次急升为487次，占总掉话次数的76.6%。5 无线链路失败的优化分析5.1 新版本上行RL Failure掉话机制新版本上行RL Failure的掉话机制，如图3所示。图3 上行RL Failure机制ANodeB检测到N_OUTSYNC_IND次失步指示；B经过TRLFailure，NodeB仍未重新检测到同步，NodeB向RNC发出RL Failure Indication；C经过RLRSTRTMR+T302×N302，RNC未收到RL

15、Restore Indication，RNC向NodeB发送RL Del，要求NodeB关闭下行链路功率，以强迫UE进行Cell  Update；D经过ABNORMRETRIEVTMR，RNC判断UE进行Cell Update未成功，最终释放该呼叫。与老版本相比较，新版本在C点之后要求NodeB关闭下行链路，并启动ABNORMRETRIEVTMR定时器，以强迫UE自身通过Cell Update进行掉话挽救。5.2 RL Failure的优化分析老版本挽救RL Failure主要有以下2种途径。（1）收到NBAP_RL_Restore指示消息，恢复链路，如图4所示。RL Failure

16、后，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 掉话率相关定时器优化效果在新版本中，掉话率相关定时器参数引入了ABNORMRETRIEVTMR定时器，该参数启用后，RL Failure 3.4 s后（T302×N302+TRLRestore；1400×2+600=3 400 ms），会主动删掉RL。删除后，该链路下行没有发射功率，强迫UE发Cell Update。在现网性能报告统计中发现，修改ABNORM