发布时间 : 星期六 文章OMCR统计在GSM网络优化中的应用更新完毕开始阅读6e0834ee551810a6f524860f
OMCR统计在GSM网络优化中的应用
序言
一．目的
在OMCR的各项应用中，统计管理程序是一个非常重要的应用程序。通过对网络中固定时段（通常为1小时）内各种事件的采样，再通过系统预设的或根据需要设置的公式的计算，来衡量一个网络的运行状况，无须测打就可发现问题，还可以发现部分连测打都无法发现的问题。所以，如果能很好地将统计应用到网络优化中去，可以起到事倍功半的作用。 二．内容范围
这篇文章的将主要集中在对统计的应用上，而不会对统计管理程序的使用、MOTOROLA统计方法作太多的介绍，关于统计管理程序的使用请参考《统计管理程序用户手册》，大家也可以参考MOTOROLA用户手册中的《GSM
statistics application》。所以本文的重点是介绍如何将统计数据应用到实际的网络优化中，如何通过分析指标发现问题。 三． 方式与方法
本文将把呼叫流程分为各个阶段，对各阶段所涉及到的统计逐一说明，并介绍如何将各统计结合成为比较直观的、具有可衡量性的公式，对各指标的合理取值给出经验范围。
RACHAGCHAGCHSDCCH1. SDCCH 的分配和占用
GSM网络为空闲模式下的手机提供的所有服务的都必须从SDCCH上发起。手机通过RACH向基站发起服务请求，基站从AGCH上给手机指定SDCCH，手机占上SDCCH，向网络发出服务连接请求。这就是完整的SDCCH的占用过程。图1.1包含了成功和失败的分配SDCCH，成功和失败的占用SDCCH，以及重发SDCCH请求的过程。 BSCBTSMSL1ABISRRSMCRMSMSSMMTP/MSC channal T3120request ok_acc_proc_suc_rach (could be decoded) access_per_rach (all received) channelrequest inv_est_cause_on_rach(included phantom) channelimmediate assign.request chan_req_cause_atmpt (1510) \rejectchannelT3126 start T3122required received expire T3122 channalchannelrequestassigned alloc_sdcch RSS channel activation channel activetion acknowledge immediate assignmentimmediatecommand start T3101 assignment access_per_agch (how many im_assign_cmd/rej was sent out, 1 msg may include upto 2 MS) expire T3101 chan_req_ms_failL2 SABMestabish indiction T3230L3 (intial msg)CM service request stop T3101T303UA ok_acc_proc (SDCCH)ms_access_by_type (1510) initial L3 information CM Service request
1．1．SDCCH接通失败率
Sdcch connect fail rate = (ok_acc_proc_suc_rach - conn-req-to-msc) / ok_acc_proc_suc_rach * 100
ok_acc_proc_suc_rach为BTS在RACH上解码的channel request 消息，conn-req-to-msc为A接口上从BSC发往MSC的 connect request 消息。如果，值指很大，则说明SDCCH的分配或占用存在较大问题。这里面可能的原因很多，按流程分大致是以下几类。
注：以下所描述的公式均只在SDCCH handover被禁止的情况下才适用。
1．2．RACH内部失败率
Rach internal error rate = (ok_acc_proc_suc_rach – chan_req_cause_atmpt) / ok_acc_proc_suc_rach * 100
正常系统的这个值应该等于零，前后两者的差值应该近似等于统计表inv_est_cause_on_rach，表示手机的cause发错。如果前后差值远远大于inv_est_cause_on_rach，则需要检查RSL的稳定性。另外，由于同频干扰产生的phantom rach也会造成此现象发生。
1．3．SDCCH 的分配成功率/ SDCCH 的分配失败率(SDCCH拥塞率)
sdcch alloc suc rate = alloc_sdcch / chan_req_cause_atmpt *100
sdcch alloc fail rate = alloc_sdcch_fail / chan_req_cause_atmpt *100
CRM在收到channel request消息后，若成功分配出SDCCH，则记alloc_sdcch，若无SDCCH可分配，即SDCCH发生拥塞，则记alloc_sdcch_fail（在没有SDCCH切换时，alloc_sdcch_fail = chan_req_ms_blk），两者之和就等于chan_req_cause_atmpt。
所以，正常情况下SDCCH的分配成功率等于100%，alloc_sdcch_fail 应等于零。若存在较大的alloc_sdcch_fail ，说明SDCCH拥塞严重，常用的解决方法是： a. 增加SDCCH数目
b. 减小该cell的C1（增大rxlev_access_min） c. 采用动态分配SDCCH的算法
1．4．SDCCH的占用成功率/ SDCCH的占用失败率
sdcch access suc rate = ok_acc_proc / alloc_sdcch *100
sdcch access fail rate = chan_req_ms_fail_roll / alloc_sdcch *100
在BSC分配了SDCCH以后，通过AGCH发给手机，手机占上SDCCH，通过SDCCH向MSC发出CM3消息，就记ok_acc_proc ；如果手机超时（T3101）没有占上SDCCH，或者由于AGCH上的干扰，手机没有收到immediate assignment 消息最后超时，则CRM释放SDCCH，记chan_req_ms_fail_roll，同时在载频的统计上，该载频的对应时隙也将记一次chan_req_ms_fail。
通常情况下，SDCCH占用失败率为10%，由于BCCH上的同频干扰（有时几个同频的CELL能同时收到一个手机的RACH，称为phantom效应），但部分基站高达30%，那就有问题了。可能，需要检查频率干扰或着是SDCCH所在的载频的path_balance。关于path_balance的统计，本文稍后会作消息介绍。
从1.2 到1.4的三个统计值分别衡量了SDCCH请求（RACH），SDCCH分配（AGCH）和SDCCH占用（SDCCH）三个阶段的指标。由于ok_acc_proc和conn_req_to_msc只是在BSC内部两个不同进程上坐的统计，所以一般应该完全相等，否则，BSC的软件就有问题了。到此，手机向MSC发出了第一条消息。
1．5．SDCCH的种类分布
ok_acc_proc=cm_reestablish + cm_serv_req_call +
cm_serv_req_emerg + cm_serv_req_sms + cm_serv_req_supp + imsi_detach + location_update + page_response
在手机通过SDCCH发上来的CM3 service 消息中，包含了8种service 类型，分别是主叫、被叫、紧急呼叫，位置更新（包括开机）、关机、呼叫重建立、短消息业务、补充业务。图1.2为杭州BSC1的SDCCH种类分布情况：
SDCCH TYPE0"'%0%1%1%2G%图1.2
上图为杭州SDCCH分布，各地由于用户习惯的不同该分布回略有不同，一般位置更新的比例不应该大于50%，但部分LAC边界的小区位置更新比例可能高达60% 以上，也属于正常范围。主叫的数量一般大于被叫。通过对SDCCH的种类分布的统计分析，我们可以发现各种业务的分布合理性。如果发现哪中service为0，则说明该业务未被激活，需要查原因。
1．6．A接口上的SCCP联路的建立失败率
SCCP connect fail rate = conn_refused / conn_req_to_msc * 100
手机和交换机需要建立SCCP联路后才可以保证手机和交换机之间的可靠的DTAP消息，建立过程是由BSC通过A接口发出SCCP的联路建立请求Connection Request 消息，CR中带有source sccp reference code，交换机中的SCCP程序接到请求后分配SCCP资源，然后在A接口上发回一个联路建立证实Connection Confirm消息，CC中有交换机分配的source sccp reference code，同时将BSC发来的sccp
reference code 作为 destination sccp reference code发回。经过这样两个消息和source 与destination两个sccp reference code，一条可靠的SCCP联路就建立了。该次服务剩下的所有的DTAP消息都
cm_reestablish cm_serv_req_call cm_serv_req_emerg cm_serv_req_sms cm_serv_req_supp imsi_detach location_updatepage_response