搜索
先讲一个故事，前几年处理一个AT&T的GPRS国际漫游投诉时，有一个客户（AT&T）使用Blackberry终端，到了中国不能收邮件。处理过程中，在核查双方的漫游数据及APN时，对方的一个工程师（一个华裔美国人）正好回国探亲，为这个投诉加入到我们的分析团队，逐级分析，直到最终解决问题。这个老美讲的一句话，影响很深：在美国，一定要positive.下面这篇论文，看起来很繁琐，实际上，是一种主动与被动的关系。简单来说，NodeB检测到上行失步，经过一个定时器后，还没有建立同步（TD-SCDMA是一个同步系统），之前的处理办法还是等，等UE建立同步，而新的解决办法是：RNC主动向NodeB发送删掉RadioLink的指令，要求NodeB关闭下行链路功率，以强迫UE进行CellUpdate。这个过程是一种典型主动与被动的处理过程。引申到日常的优化工作，我们网优工程师是否也应该考虑主动优化？谨以此文，向全国一线网优工程师致敬！TD-SCDMA网络基于客户感知的掉话率相关定时器优化分析郭宝，李冶文（1：中国移动通信集团山西有限公司太原分公司太原030001）（2：中国移动通信有限公司网络部北京100033）摘要TD-SCDMA网络处于逐步完善覆盖的时期，为了更好地提升用户使用感知，需要网优工程师及时发现网络中的问题，尤其是严重影响客户感知的掉话问题。本文针对TD-SCDMA网络中掉话率相关定时器、计数器设置过大导致的“网管统计信息不准确”的问题进行优化分析，并提出一种切实有效的优化方法。1引言在无线通信中，如果链路突然失步，系统和终端侧会启动一个等待链路恢复的定时器，并按照设定的最大允许次数的计数器来进行恢复链路的尝试，这就是掉话率相关定时器、计数器。如果定时器、计数器设置过大，会发生系统一直在等待链路恢复，而用户早已不能忍受长时间等待主动挂机，这样会导致统计的掉话率指标无法真实反映网络质量。在进行网络优化前，需要建立面向客户感知的网络质量指标，需对掉话率相关的定时器、计数器进行修改，在无线侧链路失步等待最长不大于16s。这样一来，之前被定时器所掩盖的网络掉话问题就普遍暴露出来，体现为“网管统计掉话率指标急剧恶化”。本文重点分析完成掉话率相关定时器修改后明显增加的无线链路失败类的掉话原因，并提出一种切实有效的优化方法。2掉话率定时器、计数器分析（1）连续同步指示次数：N_INSYNC_IND，小区级参数，参数取值范围：1～256，物理单位：个。该参数被NodeB用于检测UU接口上行是否同步。当一个CCTRCH处于失步状态，NodeB在连续收到“N_INSYNC_IND”个同步指示后将会判断当前CCTRCH已经重新同步，NodeB会上报RadioLinkRestoreIndication消息，并将当前CCTRCH状态置为同步状态。“连续同步指示次数”设置得越大，NodeB就越难察觉CCTRCH上行重新同步，从而造成RadioLinkRestoreIndication发送的延迟，甚至是无法发送，最终造成RNC误认为当前CCTRCH上行无法恢复同步，从而导致发起链路重建或释放；设置得越小，NodeB就越容易判断当前CCTRCH上行重新同步，但同时就越增加降低当前CCTRCH信道上行传输质量的风险。（2）连续不同步指示次数：N_OUTSYNC_IND，小区级参数，参数取值范围：1~256，物理单位：个。该参数被NodeB用于检测UU接口上行是否失步。该参数在检测上行同步过程中主要与参数“N_INSYNC_IND”配合使用。参数设置得过大，NodeB要较长时间才能察觉CCTRCH上行失步，此时间内相关资源无法及时释放，也无法发起恢复操作或响应新的资源建立请求；参数设置得过小，很可能造成CCTRCH上行对偶尔的闪断过于敏感，从而对本可以迅速自我恢复的CCTRCH上行RLFailureIndication消息也判断为不同步，进入不同步的恢复等待流程，造成系统不必要的消息处理和流程开销。（3）T313定时器为RNC级参数，参数取值范围：0~15，物理单位：s。T313是连接模式下UE检测无线链路失败的定时器，在SIB1中广播。当UE从L1检测到连续N313个失步指示后启动T313定时器。当UE从L1检测到连续N315个同步指示后停止T313定时器。一旦T313超时，UE上报原因值为RLFailure的CellUpdate消息通知RNC空中接口下行失步。T313设置得过大，UE要较长时间才能察觉RL下行失步，此时间内相关资源无法及时释放，也无法发起恢复操作或响应新的资源建立请求；T313设置得过小，很可能造成对RL偶尔的闪断过于敏感，从而对本可以迅速自我恢复的RL频繁上报CellUpdate消息，造成系统不必要的消息处理和流程开销。（4）N313计数器为RNC级参数，N313表示连接模式下UE从L1收到连续失步指示的最大次数，在SIB1中广播。N313设置得越大，UE对RL失步的判断就越不敏感，可能造成本来不可用的RL迟迟不能被上报RL失步进而无法触发后续的恢复或重建操作；N313设置得越小，越可以保证RL传输的可靠性，但相应地也会增加可恢复性RL闪断的误判，从而可能导致UE频繁的上报原因值为RLFailure的CellUpdate消息。（5）N315计数器与定时器T313、计数器N313结合使用，T313为CELL_DCH状态失去同步后的等待时间，用于无线链路失败判决过程。在CELL_DCH状态下，收到L1层连续N313个“outofsync”失步指示时，即表示已经建立的DPCCH物理信道可能失步，此时UE将启动T313，如果在T313运行时间内，收到L1层连续N315个同步指示“insync”，则停止并重置T313。3无线链路失败过程分析无线链路失败（radiolinkfailure），当上行无线链路出现连续错帧时，NodeB上报RadioLinkFailureIndication，RNC释放无线侧资源，释放原因即为：RlFail_Report。CS域此类掉话由上行干扰、弱覆盖导致，发生在PS域的RlFail掉话由用户行为的非正常断网导致。3.1旧版上行RLFailure掉话机制某厂家TD设备旧版上行RLFailure的掉话机制，如图1所示。图1老版本上行RLFailure机制A——NodeB检测到N_OUTSYNC_IND次失步指示；B——经过TRLFailure，NodeB仍未重新检测到同步，NodeB向RNC发出RLFailureIndication；C——经过RLRSTRTMR+T302×N302，RNC未收到RLRestoreIndication，于是发出IuReleaseRequest，发生掉话。因此，上行RLFailure定时器总时长为：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次失步（每一个检测周期160ms，20×0.16=3.2s）后，即启动TRLFailure；若在TRLFailure超时（200×0.1＝20s）前，NodeB依旧没有检测到N_INSYC_IND（1个检测周期160ms）个同步帧，NodeB即向RNC发出RLFailureIndication；RNC收到该消息后，即启动RLRSTRMR；若RLRSTRTMR超时（10s）仍没有收到NodeB发出的RLRestore，则再启动N302×T302（共12s）；若RNC依旧没有收到NodeB发出的RLRestore，则最终RNC向CN发出IuReleaseRequest，该呼叫掉话。根据以上的设定，实际在该RLFailure掉话中，总共等待的时间是：20×0.16＋200×0.1+10+4×3=45.2s。这里的掉话等待时间其实是RNC及CN的内部等待时间，并不是实际用户等待时间。通常情况下是主叫最多在十几秒后就主动挂断。其实整个过程，主叫先上行失步，此时已经与RNC失去联系，主叫不可能与CN取得联系。所以主叫挂断后是否记为掉话就看RNC和CN的掉话机制了。3.2下行RLFailure掉话机制下行RLFailure的掉话机制，如图2所示。图2下行RLFailure掉话机制(1)UE判断下行失步总时间0.16+（N313-1）×0.01；(2)之后等待T313，若没有检测到恢复，则UE开始进行小区搜索，并启动T314；(3)完成小区搜索后，UE发起CellUpdate；(4)对CS业务在T314超时前，若CellUpdate没有成功，则UE放弃该呼叫，发生掉话。因此，下行RLFailure定时器总长：0.16＋（N313-1）×0.01＋T313＋小区搜索＋T314。4定时器修改后指标对比本文重点分析无线侧掉话率相关定时器，根据用户实际使用感受，要求上行或下行无线链路超时最长不超过16s，统计为从第一个失步指示开始到RNC向CN发送“IuReleaseRequest”或“RABReleaseRequest”的总时长。其中，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_CellUpdate_TimeOut。表1掉话率相关定时器修改后的掉话率指标对比详细分析CS域掉话原因，发现修改后原因为RNC请求释放电路域Iu连接对应的RAB数目，原因RlFail_Report引起的掉话次数从之前的6次急升为487次，占总掉话次数的76.6%。5无线链路失败的优化分析5.1新版本上行RLFailure掉话机制新版本上行RLFailure的掉话机制，如图3所示。图3上行RLFailure机制A——NodeB检测到N_OUTSYNC_IND次失步指示；B——经过TRLFailure，NodeB仍未重新检测到同步，NodeB向RNC发出RLFailureIndication；C——经过RLRSTRTMR+T302×N302，RNC未收到RLRestoreIndication，RNC向NodeB发送RLDel，要求NodeB关闭下行链路功率，以强迫UE进行CellUpdate；D——经过ABNORMRETRIEVTMR，RNC判断UE进行CellUpdate未成功，最终释放该呼叫。与老版本相比较，新版本在C点之后要求NodeB关闭下行链路，并启动ABNORMRETRIEVTMR定时器，以强迫UE自身通过CellUpdate进行掉话挽救。5.2RLFailure的优化分析老版本挽救RLFailure主要有以下2种途径。（1）收到NBAP_RL_Restore指示消息，恢复链路，如图4所示。RLFailure后，NodeB检测到连续的同步后（N_INSYNC_IND，目前配置为4，也就是连续4个同步），向RNC发RL_RESTORE_IND，此时链路恢复。新版本对掉话挽救机制进行了优化，原有的恢复机制保留，并在RLRestore+T302×N302超时后不直接释放Iu，而是删除RL。上行在RLRestore+T302×N302超时后删除RL，RadioLinkDeletionReq时启动ABNORMRETRIEVTMR定时器，当RL删除后，该链路下行没有发射功率，强迫UE发CellUpdate，尝试挽救掉话。6掉话率相关定时器优化效果在新版本中，掉话率相关定时器参数引入了ABNORMRETRIEVTMR定时器，该参数启用后，RLFailure3.4s后（