关于TD定时器

1、T313定时器：
1
a、T313是连接模式下UE检测无线链路失败的定时器，在SIB1中广播。
b、当UE从L1检测到连续N313个失步指示后启动T313定时器。当UE从L1检测到连续N315个同步指示后停止T313定时器。
c、一旦T313超时，UE上报原因值为RL FAILURE的CELL UPDATE消息通知RNC空中接口下行失步。
d、T313设置的过大，UE要较长时间才能察觉RL下行失步，此时间内相关资源无法及时释放，也无法发起恢复操作或响应新的资源建立请求。
e、T313设置的过小，很可能造成对RL偶而的闪断过于敏感，从而导致频繁对本可以迅速自我恢复的RL上报CELL UPDATE消息，造成系统不必要的消息处理和流程开销。
f、一般设置为3，单位为S
2、N313计数器：
a、N313表示连接模式下UE从L1层收到连续失步指示的最大次数，在SIB1中广播
b、N313设置的越大，UE对RL失步的判断就越不敏感，可能造成本来不可用的RL迟迟不能被上报RL失步进而无法触发后续的恢复或重建操作
c、N313设置的越小，越可以保证RL传输的可靠性，但相应的也会增加可恢复性RL闪断的误判，从而可能导致UE频繁的上报原因值为RL FAILURE的CELL UPDATE消息；
d、一般设置为10，单位为次；
3、T314定时器：
a、当RL下行失步满足无线链路失败准则，UE发送了原因值为RL FAILURE的CELL UPDATE消息后，若当前存在与T314定时器关联的无线承载，则UE需要启动T314定时器。当小区更新过程完成后停止T314。
b、在业务对应的T314超时之前，如果由CELL UPDATE CONFIRM配置的无线链路建不成功，则还可以重发CELL UPDATE消息，进行无线链路的重建(重发CELL UPDATE消息和等待响应的保护机制由T302和N302联合完成)，基于此目的，配置T314应大于T302×N302。
c、一旦T314超时，则相应的业务RB就被删除。
d、T314设置的过大，UE要较长时间才能将已无法恢复的RL的相应业务资源释放，此时间内相关资源吊死，无法分配给其他业务使用。
e、T314设置的过小，如上文所述，很可能造成无法与T302和N302的正确配合工作，从而导致RL重建失败率上升，业务被过早释放。m
f、一般设置为12，单位12S；
4、T315定时器：
a、当RL下行失步满足无线链路失败准则，UE发送了原因值为RL FAILURE的CELL UPDATE消息后，若当前存在与T315定时器关联的无线承载，则UE需要启动T314定时器。当小区更新过程完成后停止T315。
b、在业务对应的T315超时之前，如果由CELL UPDATE CONFIRM配置的无线链路建不成功，则还可以重发CELL UPDATE消息，进行无线链路的重建(重发CELL UPDATE消息和等待响应的保护机制由T302和N302联合完成)，基于此目的，配置T315应大于T302×N302。
c、一旦T315超时，则相应的业务RB就被删除。
d、T315设置的过大，UE要较长时间才能将已无法恢复的RL的相应业务资源释放，此时间内相关资源吊死，无法分配给其他业务使用。
e、T315设置的过小，如上文所述，很可能造成无法与T302和N302的正确配合工作，从而导致RL重建失败率上升，业务被过早释放。
f、一般设置为180，单位S
注：这里有个问题，T314与T315分别对应什么业务，为什么会相差这么大？
5、N315定时器：
a、N315表示连接模式下在T313定时器启动期间UE从L1接收到连续同步指示的最大次数，在SIB1中广播。
b、N315设置的越大，越可以保证RL恢复下行同步的可靠性，但相应的也会增加导致T313超时的风险，一旦T313超时，就会触发RL FAILURE原因的小区更新流程；
c、N315设置的越小，越增加判断RL下行恢复可用的风险，造成本来没有正确恢复下行同步的RL被认为成功恢复的误判可能性就越大，但由此导致的T313超时的风险会越小。
d、一般设置为4，单位次；
6、T302定时器：
a、UE在发送CELL UPDATE/URA UPDATE消息后启动T302定时器，并将记录CELL UPDATE/URA UPDATE消息发送次数的计数器V302累加1；在收到CELL UPDATE CONFIRM/URA UPDATE CONFIRM消息后停止T302；
b、一旦T302定时器超时，UE检查计数器V302，若V302 <= N302，则重发CELL UPDATE/URA UPDATE，否则进入空闲模式；
c、T302设置的过大，会增大UE小区更新/URA更新流程平均时延
d、T302设置的过小，会影响UE小区更新/URA更新流程成功率；
e、一般设置为1400，单位ms；
N302计数器：
a、N302表示连接模式下允许UE发送CELL UPDATE/URA UPDATE消息的最大次数，在SIB1中广播；3q5Q'd:Q/T/B"j
b、N302设置的越大，在无线网络较差的情况下对提高小区更新/URA更新流程成功率会有益处，但占用相应信道时间比较长，增加网络负载；
c、N302设置的越小，占用的相应信道时间会越少，但会降低小区更新/URA更新流程成功率；
d、一般设置为2，单位次；
了解了这次计数器和定时器之后，我们可以想象一下，一次掉话/掉线是怎么样的一个过程呢？
首先UE检测到了N313（10）次失步指示，启动了T313（3S），在T313时间内，UE没有检测到N315(4)次同步指示，T313超时了，UE发送CELL UPDATE消息，原因值为RL FAILURE，同时启动了T302(1400ms)，V302加1，T302超时，UE没有收到CELL UPDATE CONFIRM消息，检测V302，若V302 <= N302(2)，则重发CELL UPDATE，否则进入空闲模式；
这里有一个问题，好像T314、T315没有起到作用；
我理解是这样的，RNC在发送了CELL UPDATE CONFIRM之后，如果重配置的无线链路建不成功，在T314/T315时间内，该业务的无线资源不会被释放，直至T314(12S)/T315(180S)超时；17:46 2012-2-23
上面提到的这些都是RNC级的参数，不知道有没有一些小区级的参数，功控类的参数，对掉线掉话率有影响呢？欢迎大家讨论！
8、N_INSYNC_IND/连续同步指示次数
a、该参数被NodeB用于检测UU接口上行是否失步；
b、当CCTRCH处于同步状态，NodeB在连续收到“N_OUTSYNC_IND”个失步指示后会启动T_RLFAILURE定时器；在连续收到“N_INSYNC_IND”个同步指示后会停止和复位T_RLFAILURE定时器；
c、一旦T_RLFAILURE定时器超时，NodeB会上报RADIO LINK FAILURE INDICATION消息通知RNC空中接口上行失步，并将当前CCTRCH状态置为失步状态
d、当一个CCTRCH处于失步状态，NodeB在连续收到“N_INSYNC_IND”个同步指示后将会判断当前CCTRCH已经重新同步，NodeB会上报RADIO LINK RESTORE INDICATION消息，并将当前CCTRCH状态置为同步状态；
e、“连续同步指示次数”设置的越大，NodeB就越难察觉CCTRCH上行重新同步，从而造成RADIO LINK RESTORE INDICATION发送的延迟，甚至是无法发送，最终造成RNC误认为当前CCTRCH上行无法恢复同步，从而发起链路重建或释放；
f、“连续同步指示次数”设置的越小，NodeB就越容易判断当前CCTRCH上行重新同步，但同时就越增加当前CCTRCH信道上行传输质量的风险；
g、一般设置为4，单位次；
9、连续不同步指示次数/ NOUTSYNCIND
a、该参数被NodeB用于检测UU接口上行是否失步；
b、本参数在检测上行同步过程中的功能和作用请参见“N_INSYNC_IND”一节中的描述；
c、“连续不同步指示次数”设置的过大，NodeB要较长时间才能察觉CCTRCH上行失步，此时间内相关资源无法及时释放，也无法发起恢复操作或响应新的资源建立请求；
d、“连续不同步指示次数”设置的过小，很可能造成对CCTRCH上行偶而的闪断过于敏感，从而导致频繁对本可以迅速自我恢复的CCTRCH上报RL FAILURE INDICATION消息，造成系统不必要的消息处理和流程开销；
e、一般设置为10,单位次；
10、无线链路失败定时器时长/ TRLFAILURE
a、该参数被NodeB用于检测UU接口上行是否失步；
b、本参数在检测上行同步过程中的功能和作用请参见“N_INSYNC_IND”一节中的描述；
c、一般设置为51，单位秒；