1、1.1 呼叫建立成功率1.1.1 指标计算公式呼叫建立成功率= 呼叫建立成功次数/ 呼叫尝试次数*100%1.1.2 指标意义该指标反映CDMA移动网无线系统业务信道分配成功（呼叫建立）的情况，包括主被叫、语音/数据业务等的呼叫建立情况。不包括短消息，不包括切换。1.1.3 对应测量子集指标项说明统计分CS（电路）及PS（分组）两个测量子集，以下以CS业务为例介绍。见 表4-2。表 Error! No text of specified style in document.-1 CS 呼叫建立性能主要指标列表测量子集 指标 指标类型 指标含义 指标单位自动重拨次数-CS 计算在电路域业务主叫接
2、入过程中 BSC收到 MS 重复发送的“Origination”消息的次数。 次A1 接口失败次数-CS 计算在电路域业务呼叫下 BSC 因未收到“Assignment Request”而造成呼叫建立失败的次数 次分配呼叫资源失败次数-CS 计算在电路域业务呼叫接入过程中，BSC 因分配呼叫资源失败而造成呼叫建立失败的次数 次捕获反向业务信道前导失败次数-CS 计算在电路域业务呼叫接入过程中 BSC在发送扩展信道指配消息后，没有接收到反向“TCH Preamble”的次数。 次CS 呼叫建立性能统计层 2 握手失败次数-CS 计算在电路域业务呼叫接入过程中，BSS 捕获到“TCH Preamb
3、le”后给手机发送“BS Ack Order”，却没有接收到反向“MS Ack Order”的次数。 次业务连接失败次数-CS 计算在电路域业务呼叫接入过程中，BSC 发送“Service Connect”消息之后却没有接收到“Service Connect Complete”消息的次数。次业务信道信令交互失败次数-CS 计算在电路域业务呼叫接入过程中，BSC 收到反向“TCH Preamble”后，在向 MSC 发送“Assignment Complete”之前出现的呼叫建立失败次数； 次指配尝试次数-CS 计算在电路域业务呼叫接入过程中BSC 发送信道指配的次数。 次业务信道准备好次数-C
4、S 计算在电路域业务呼叫接入过程中 BSC发送信道指配的次数。 次成功捕获反向业务信道前导次数-CS 计算在电路域业务呼叫接入过程中BSC 在发送扩展信道指配消息后成功接收反向“TCH Preamble”的次数。 次硬切换切入成功次数-CS 计算统计 IS95 和 IS2000 电路域业务的硬切换切入成功次数。 次尝试次数-CS 计算统计在电路域业务（不包括短消息）下 BSC 收到 “Origination”或“Page Response”的次数。 次建立成功次数-CS 计算在电路域业务呼叫接入过程中BSC 向 MSC 发送“Assignment Complete”的次数。 次建立成功率-CS
5、% 计算100*(建立成功次数-CS/尝试次数-CS) %提醒：业务信道信令交互失败次数-CS = 业务连接失败次数-CS + 层2握手失败次数-CS1.1.4 指标项分析当成功率低时，先重点关注并解决失败次数最多的指标。如各种失败次数都较均衡，可先关注捕获反向业务前导失败及业务信道信令交互失败指标。当其它失败原因较多时，可视为异常现象，可结合网络容量、单板配置、参数配置和告警信息进行分析。注意：与R001版本不同的是，呼叫建立失败中少了 “呼叫早释”的统计。现在的统计方法是：呼叫结束后判断呼叫释放原因是否为早释，如果是早释的话，不会统计这一次呼叫尝试。注意：当使用了MARKOV测试呼叫，而且
6、软参为“ 不使用MSC 参与”时，BSC不会收到MSC的指配请求，所以“指配尝试次数”不会被统计，而 BSC发送了ECAM/CAM， “业务信道准备好次数”会被统计，可能会造成话统结果中，“业务信道准备好次数”大于“指配尝试次数”的情况。另外，对于MARKOV测试呼叫是不会向MSC发送指配完成的，但是话统也统计上了“呼叫建立成功次数 ”。类似的测试呼叫还有TD_SO/ LOOPBACK呼叫。对于双载波基站，两载波采用硬指配的方式分配业务信道，其呼叫次数和建立成功次数，都统计在呼叫实际建立的载频上。也就是说，从基本载波接入的指配到叠加载波，话统都统计到叠加载波了。 A1接口失败次数A1接口失败次
7、数= 呼叫尝试次数 - 指配尝试次数。该指标可能因为A接口的失败、定时器设置不合理等造成。可以通过检查A 接口链路连接及告警，CCM_T_WT_ASSG_REQ定时器的长短来解决问题，如图4-1。再进一步，还可以通过CSL中的失败原因值分析是否存在其它异常。该失败次数不多时，可不重点关注。提醒：在C03以前版本中该失败原因称为MSC拒绝，从实际应用中通过CSL工具发现，发生MSC拒绝统计的绝大部分都是被叫移动台，原因是当主叫拨打被叫，MSC一方面对主叫回指配请求，一方面马上被叫下寻呼，当被叫回寻呼响应后，MSC发现此时主叫建立已经失败或已提前释放，于是给被叫方BSC下发disconnect拆除
8、被叫，此时被叫BSC释放被叫，失败原因为MSC拒绝（CSL中释放原因值为A13）。这种统计不合理的，因此在R003C03版本后，不再统计收到disconnect拆除的那部分呼叫，该指标将改为A1接口失败。其它的MSC的拒绝与MSC的处理机制相关，需要进一步由MSC上分析。 分配呼叫资源失败次数分配呼叫资源失败次数 = 指配尝试次数 - 业务信道准备好次数分配呼叫资源失败是指BSC申请各种呼叫所需资源过程的失败，包括无线资源、地面电路资源、各种硬件资源等，也就是从BSC 的CCM模块收到MSC 的“Assignment Request”一直到CCM 发送 ECAM消息期间的任一失败都认为是分配呼
9、叫资源失败。它与业务信道拥塞率统计中的拥塞总次数不同，业务信道拥塞是呼叫资源分配过程中RRM模块分配无线资源过程的失败，只是呼叫资源分配不成功中的一个部分。但业务信道拥塞率统计中还包括了切换的统计，这里只是呼叫建立。一般而言，呼叫资源的拥塞绝大部分应该在无线资源拥塞，这种拥塞的原因将在业务信道拥塞率统计中分析。如果统计的分配呼叫资源失败次数很多而业务信道拥塞统计很少，则我们可以排除无线资源拥塞的原因，剩下地面链路的拥塞或设备内部软硬件等的问题。在传输链路容量规划正确的情况下，传输链路的拥塞应该基本可以通过链路故障的告警排查。进一步可以从CSL的中得知具体的释放原因值，从设备内部进一步定位问题。
10、 捕获反向业务信道前导失败捕获反向业务信道前导失败次数 = 业务信道准备好次数 - 成功捕获反向业务信道前导次数。 业务信道信令交互失败业务信道信令交互失败次数 = 成功捕获反向业务信道前导次数 - 呼叫建立成功次数。业务信道信令交互失败与R001版本中的等待移动台响应超时统计是一样的。捕获反向业务信道前导失败与业务信道信令交互失败可以归为是无线链路的失败，区别在于业务信道交互时反向已是闭环功控过程，基站如果已解调反向业务信道也进入了前向功率控制过程。在现网中，捕获反向业务信道前导失败是呼叫建立不成功的最主要原因。1.1.5 可能导致呼叫建立失败的原因根据现网统计情况看，捕获反向业务前导失败及
11、业务信道信令交互失败是呼叫建立失败的主要原因。下面的分析主要针对这两个失败原因。当其它失败原因较多时，可视为异常现象，可结合网络容量、单板配置、参数配置和告警信息等进行分析。总的来看，造成上述两种失败可分为三种可能：前向信号差，手机没有收到前向消息或手机不能成功解调前向业务信道；反向信号差，手机发了TCH preamble或消息后基站不能接收；基站定时器等待超时。具体原因主要可能有：1 网络结构不合理网络结构的不合理造成的覆盖差或盲区，需要调整天馈甚至是站址来改善无线网络架构。2 功率控制参数设置不合理前向业务信道初始发射功率及前向业务信道最大发射功率设置过小，可能造成移动台无法正确解调前向业
12、务信道。进入前反向功控过程后，还有可能是由于前反向功控步长、频度、Eb/Nt设定等参数设置不合理造成业务信道解调的失败。3 接入参数设置不合理反向接入参数设置不合理可能造成移动台的发射功率偏低，不足以让系统解调，如NOM_PWR， INIT_PWR，PWR_STEP，RLGAIN_ADJ，RLGAIN_TRAF_PILOT 等。4 干扰原因。干扰包括CDMA系统自身的干扰以及来自外界的干扰，系统受到干扰，一般反向会表现为移动台发射功率高，前向表现为Rx高而Ec/Io差。系统自身的干扰需要综合考虑网络的质量容量覆盖等问题后加以调整。外界干扰可以通过干扰测试仪器检测并进一步定位清除。通过基站的RS
13、SI数据可以大致了解反向的干扰情况，一般情况下，网络负载时RSSI值也不应高于-90dBm。RSSI高于-90 dBm，特别是高于-80 dBm后会出现接入困难、掉话等情况。5 导频污染6 消息重发次数设置不合理前向消息的重发次数及重发间隔一般是可配置的，如果前向消息的重发次数太少或重发间隔太小，就难以起到消息重发在时间上的分集作用，不利于移动台接收该消息。我们系统的消息重发主要在LAC层实现，通过维护台命令：MOD LACCTRL，修改重发参数专用信道确认模式最大重传次数、专用信道非确认模式最大重传次数、公用信道确认模式最大重传次数、公用信道非确认模式最大重传次数可以分别控制各种消息的重发次
14、数。协议中已经规定了移动台侧的定时器长度，系统侧的消息重发次数和间隔应该与移动台相配合起来，才能使信令交互通畅。参见定时器设置不合理问题。7 前反向搜索窗设置不合理8 与切换的冲突。如果移动台在呼叫建立过程中服务小区信号变差，出现掉网，移动台迅速重新初始化或空闲切换到新的导频上，说明可能是接入与切换发生了冲突。这时，可能是：第一，呼叫建立过程与切换的冲突（新的导频在邻区列表中）。一种可能是服务小区的导频Ec/Io恶化很快（如5-6dB/S），而这时可切换区域太小，很有可能在正常的呼叫建立过程中就已经掉网了。另一种可能是呼叫建立速度太慢或移动台移动太快，即使在服务小区的导频Ec/Io恶化并不快，切换区域大小合理的情况下，也可能移动台到了服务小区边界呼叫建立还没完成造成掉网。当然，此时如果系统的接入切换开关是打开的，则不会存在这些问题。我们可以通过调整基站覆盖，调整切换区域，也可以通过调整接入参数、反向功率参数等使接入过程适当加快。第二，呼叫建立前没能空闲切换（新的导频不在邻区列表中）。如果一个强的可用导频不在邻区列表中，移动台需要但没能空闲切换到另一个强的导频上，移动台此时在强度已较差的服务导频上发起呼叫建立，就有可能出现掉网的情况。此时需要检查邻区关系，新增漏配邻区。9 定时器设置不合理
