建立成功率分析.docx

建立成功率分析.docx

《建立成功率分析.docx》由会员分享，可在线阅读，更多相关《建立成功率分析.docx（14页珍藏版）》请在冰豆网上搜索。

建立成功率分析

1.1.1系统呼叫建立

全网的CallSetUpSuccessrate平均为95.5%，为较好水平。

Figure1CallSetupandTraffic

Table1自贡SYSCall_setup_Suc

1.2呼叫建立性能

CallSetupSuccessRate（%）＝

（TOTAL_CALLS+CONGEST_ASSIGN_HO_SUC）*100

-------------------------------------------------------------------------------------------------

callattempts（CM_SERV_REQ_CALL+PAGE_RESPONSE+CM_REESTABLISH+

CM_SERV_REQ_EMERG+CM_SERV_REQ_SMS-SMS_INIT_ON_SDCCH）

将呼叫建立过程分为两段进行分析，分别是：

1）MA_REQ_TO_MSC_SUC：

MSC向BSC发出MA_REQ_FROM_MSC总次数

----------------------------------------------------------------------

BSS发往交换机的呼叫接入请求总次数

2）TCHASSIGNMENTSUCCESSRATE：

BSC发往的交换机的TCH分配成功总次数

-------------------------------------------------------------------------

MSC向BSC发出MA_REQ_FROM_MSC总次数

三者的趋势如下

Figure2CallSetupAnalyze

Table2CallSetupAnalyze

可见TCHASSIGNMENT的成功率较高，影响CallSetupSuccessRate的主要是MA_REQ_TO_MSC_SUC，而且CallSetupSuccessRate与MA_REQ_TO_MSC_SUC的起伏趋势基本一致。

总的CallSetupSuccessRate是较好的。

1.2.1MA_REQ_TO_MSC_SUC

在MS发向MSC的CM_SERVICE_REQUEST消息中包含：

主被叫电话，主被叫短信，被叫，位置更新等，而MSC发往BSS的MA_REQ_FROM_MSC只包含需要占用TCH的部分（通话）。

统计MS发往MSC的呼叫请求次数的计算公式如下：

Numberofcallattempts（呼叫请求次数）＝

CM_SERV_REQ_CALL+PAGE_RESPONSE+CM_REESTABLISH+

CM_SERV_REQ_EMERG+CM_SERV_REQ_SMS-SMS_INIT_ON_SDCCH

用这个结果和MA_REQ_FROM_MSC比较就得到了MA_REQ_TO_MSC_SUC的比率。

Table3CMServiceRequestAnalysis

可见损耗约有3.9%这是影响呼叫建立成功率的主要原因。

全网趋势如下

Figure3CallAttemptLost

对MA_REQ_TO_MSC_SUC的分析：

这一段的呼叫流程如下图所示

Figure4FlowChat

可见这一段由于包含了手机和交换机间的鉴权、加密等信息交换和交换机的处理，所花费的时间较长，而且由于用户的原因取消呼叫或SDCCH_RF_LOSS等原因，都会导致呼叫建立不成功。

交换机也会拒绝一些无效的呼叫，影响呼叫建立成功率。

主要的损失原因有以下4类：

1．MSC拒绝为手机分配信道

可能是非法用户或受到限制的MS请求在鉴权、加密过程中被MSC拒绝。

2．SDCCH的RF_LOSS

在流程的任何一步，由于丢失了SDCCH都会中断呼叫建立。

3．用户行为

在接通之前因为用户人为终止，如按下SEND后马上取消，也会导致呼叫建立失败。

4．BSS分配SD失败（SD拥塞）

SD拥塞而无法为申请接入的MS分配SDCCH。

统计见下表

Table4CallAttempt

MS发往BSC的CMservicerequest有302137条，BSC发往MSC的CON_REQ_TO_MSC有302127条，只损耗了10条，说明SDCCH的拥塞很小。

从OK_ACC_PROC中减去不需要分配TCH的request（短消息，LocationUpdate等）后计算出的OK_ACC_PROC_CALL为77372条。

MSC回应的MA_REQ_FROM_MSC有74349条，损失3032条。

BSS只对空中信号进行性能管理，因此没有手机与交换机之间的统计信息，而这些信息是通过BSS透明传送的。

为了完整理解呼叫建立失败的原因，必须包括DTAP信息，所有就要对A接口进行分析。

根据4-17日下午A接口的测试结果（BSC601）：

Table5A-interface

可见，用户放弃呼叫和SD_RF_LOSS是造成MA_REQ_TO_MSC_SUC较低的主要原因。

SD_RF_LOSS高的小区列表如下：

SDCCH拥塞较高的小区如下：

1.2.2TCHASSIGNMENTSUCCESS

全网平均为99.4%，为较高水平。

影响Tch_assign_successrate的主要因素如下：

1.MA_CMD_TO_MS_BLK:

----------------------0.12%

这一项主要指TCH拥塞。

2.ALLO_TCH_FAIL:

------------------------------0.17%

这一项主要指TCH拥塞，包括切换。

3.MA_FAIL_FROM_MS:

-------------------------0.55%

这一项主要指MS在指定的TCH上建立连接超时失败的次数，包含小区内切换。

4.SD_RF_LOSS:

-------------------------------------2.26%（影响整个呼叫建立过程）

这一项对呼叫建立成功率的影响主要在MA_REQ_TO_MSC_SUC阶段。

可见MA_FAIL_FROM_MS是分配失败的主要原因，而MA_FAIL_FROM_MS是无线环境所造成的，如果数量很大，则有可能是基站有硬件问题。

另外，TCH的拥塞也直接影响到TCH的分配成功率，特别是一些只有一个载频的扇区，特别容易因为话务量的波动产生拥塞。

1.2.3

各个BSC趋势

1.2.4典型案例分析

1.2.4.1

BSS601:

SITE-32十字口16973

这个站呼叫建立成功率由15日起突然变低，由统计看发现其MA_FAIL_FROM_MS突然增加很多，于是到现场调测，并未发现明显问题，5月22日锁住DRI21后，MA_FAIL_FROM_MS消失，呼叫建立成功率上升到90%以上，于是判断是载频硬件故障，换了DRI21后，MA_FAIL_FROM_MS与以前相当，呼叫建立成功率基本恢复正常。

1.2.4.2张家花园M16840

这个站的主要问题是TCH拥塞，略微影响了呼叫建立成功率，另外2个载频的PATH_BALANCE值约140，说明上下行损耗严重不平衡，原因在于加装了放大器，建议调小放大器增益，减小覆盖，让其他站分担其话务量。

1.2.4.3邓关16053

这个站在12和13日的MA_FAIL_FROM_MS很高，显著影响了呼叫建立成功率，通过重起基站和重调接收发射，从14日起MA_FAIL_FROM_MS基本消失。

相应的呼叫建立成功率由60%上升到了90%以上。

另外，该站的话务较大，SDCCH和TCH都有一定拥塞，也对呼叫建立成功率有一定影响，需考虑扩容。

1.2.4.4土地坡16013

这个站有明显的TCH拥塞，5月14日TCH拥塞很高时就明显导致呼叫建立成功率降低，同时也造成周围基站的切换成功率较低，需要考虑增加载频。

增加了一个载频后，TCH拥塞消失了，呼叫建立成功率基本保持到了95%以上。

1.2.4.5

这个站由统计看，影响Call_setup_success_rate的主要是SD_rf_loss高，再看载频统计，发现RTF21的IOI高，且RF_loss也高。

试将RTF21的频点由42改为12，SD_RF_LOSS明显减低，呼叫建立成功率升到97.87%。

但发现TCH掉话上升，取得载频统计如下:

可见产生IOI的原因应该不是频点的问题，怀疑DRI22有硬件问题。

于是更换DRI22,统计如下：

可见，所有RTF的IOI都很低，开始的IOI高是硬件问题造成的，同时RF_LOSS也消除了。

经过处理，呼叫建立成功率完全恢复正常。