TD-SCDMA 关键指标主要有CS域无线接通率、PS域无线接通率、CS域无线掉话率、PS域无线掉话率、CS域3G切换至2G成功率、PS域3G切换至2G成功率。

如何提升这六大指标，请大家各抒已见！
掉话的处理一般有以下几点：
1、查硬件告警；（一般有哪些常见告警）
2、查载频时隙干扰，可以查看干扰电平值（判断是否有干扰的电平值门限是多少？），扫频，尝试关闭载频等方法来判定；（如何判断干扰是内部干扰还是外部干扰）
3、查RRC接入成功率，如果RRC成功率一样很低，则有可能是由于有弱覆盖，对于弱覆盖场景，可以先通过调整天馈及增加发射功率来改善覆盖，最后可尝试调整小区最低接入电平值（如何调，范围是多少），23G互操作门限值（哪些门限值，如何调整），来减少由于弱覆盖造成的掉话；
4、看切换成功率，观察是否由于切换失败导致掉话率高，如果是，提取切换统计数据，观察具体与哪几个小区切换失败次数多，调整天线，调整切换参数，优化切换带（哪些相关切换参数，参数的变动有什么影响）；
5、可以调整无线链路同步计数器，失步计数器，同步定时器，失步定时器等参数来控制掉话率（RNC级参数，慎调！）（这些计数器和定时器的详细情况是怎样）；
6、根据PCHR统计分析，掉话是否集中在某个或几个用户，分析是否终端问题导致掉话；

前面提到了无线链路的几个计数器和定时器：
1、T313定时器：
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重建失败率上升，业务被过早释放。
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；

7、N302计数器：
a、N302表示连接模式下允许UE发送CELL UPDATE/URA UPDATE消息的最大次数，在SIB1中广播；
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)超时；

上面提到的这些都是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，单位秒；

接通率KPI的指升主要有以下几个方面：
1、查询硬件告警；
2、查询UPPTS ISCP，如果UPPTS ISCP值大于-90dBm，可以尝试修改UPPTS位置，再观察有无改善；
3、统计接入时的RSCP值，观察有无弱场接入情况（需要用到PCHR工具）；
4、增加FPACH功率；
5、增加上行干扰余量；
6、如果是拥塞的话，需要扩容解决；

[ 本帖最后由 wangfangxin 于 2011-3-23 10:56 编辑 ]