A接口信令统计掉话和OMCR统计掉话差异一例_鹿勇.doc

A接口信令统计掉话和OMCR统计掉话差异
CMCC要求各分公司比较A接口信令统计掉话和网关指标统计掉话的一致性，以确定网关指标统计的得正确性。CMCC要求使用COMPASS仪表，任选一个小时和BSC，对这个BSC的A接口挂表进行测试，并根据CMCC对A口掉话的定义（Assignment complete和 handover complete 之后出现的clear request 消息）统计出信令掉话和网关统计的掉话的次数进行比较，分析两者之间的差异产生的原因。要求差异不超过±5%。
通过各地大量对比结果来看，A接口统计的掉话和OMCR统计的掉话，存在着不固定的差异，或者A接口信令统计得掉话多于OMCR，或者OMCR统计的掉话多于A接口的信令统计，而且差异的比例也不固定。例如：下表是某个地区一个BSC 的对比结果
BSC
跟踪时间
统计时间段
A接口统计掉话
OMCR统计掉话
误差
BSC3
2004-11-18
16:00-17:00
246
283
-13.07%
BSC3
2004-11-18
17:00-18:00
253
266
-4.89%
BSC3
2004-11-18
18:00-19:00
253
257
-1.56%
BSC3
2004-11-18
19:00-20:00
234
232
0.85%
BSC3
2004-11-18
20:00-21:00
153
157
-2.55%
BSC3
2004-11-19
18:00-19:00
208
206
0.96%
BSC3
2004-11-19
19:00-20:00
161
161
0.00%
BSC3
2004-11-19
20:00-21:00
144
153
-5.88%
BSC3
2004-11-19
21:00-22:00
123
105
14.63%
BSC3
2004-11-19
22:00-23:00
66
61
7.58%
BSC3
2004-11-20
8:00-9:00
224
136
39.29%
BSC3
2004-11-20
9:00-10:00
315
249
20.95%
BSC3
2004-11-20
10:00-11:00
288
246
14.58%
BSC3
2004-11-21
12:00-13:00
893
488
45.35%
BSC3
2004-11-21
13:00-14:00
388
302
22.16%
BSC3
2004-11-21
14:00-15:00
277
269
2.89%
BSC3
2004-11-21
15:00-16:00
262
278
-5.76%
BSC3
2004-11-21
16:00-17:00
263
273
-3.66%
BSC3
2004-11-21
17:00-18:00
205
230
-10.87%
BSC3
2004-11-21
18:00-19:00
175
202
-13.37%
合计

5131
4554
11.2%
误差率计算公式：│A－B│/max(A,B)
A: A接口统计掉话次数
B： OMC统计掉话次数

通过上表可以看出，即便是同一个BSC在不同测试时段误差也不是固定的。不同地区产生误差的原因也不尽相同，下面是几种较为常见的情况：

u A接口信令统计掉话次数大于OMC统计掉话次数的情况
ü 由于通话过程伴随异常的短信流程
这种情况对误差的影响与这时段的短信量成正比，短信量越多，存在这种流程的数量就越多，误差也越大。
通话过程中伴随短信的流程完全符合GSM规范，但是由于个别类型的手机在通话结束后无法回应确认消息，造成网络侧等待手机回应，最后由手机侧主动释放链路的情况，在A口上会出现clear request消息，而Abis口为正常释放流程，因此OMC不记为掉话，这就产生了误差。
下图所示为通话过程中同时出现短消息流程的情况，即：手机在成功占用TCH后收到网络侧下发的短消息CPDAT，接着手机挂机，手机始终没有向网络侧回应CPACK，而网络侧持续等待，并保留TCH信道。经过10秒（release complete到clear request），手机侧计时器超时后，由手机主动拆除链路，故在A口上出现了clear request消息，记为一次掉话；同时在空中接口和abis接口的链路释放流程却属于正常释放，所以OMCR不会统计为掉话。

通过修改交换机计时器TC1N，可以基本消除这种流程。该计时器即为网络等待手机侧回CPACK消息的时长，若使该计时器设置值小于手机侧等待网络侧Clear Command消息的时长，则可触发网络侧主动拆链，从而避免目前的手机侧主动拆链导致A口统计为掉话的现象。
ü 通话结束后，交换机无法主动释放资源，而由BSC侧释放
这种流程的数量随话务量的上升而增多。当话务量上升，某些交换资源开始无法主动释放，随着话务量越来越高，无法主动释放的资源也越来越多，随着话务量的渐渐减小，无法主动释放的资源也越来越少。这些资源需要通过无线侧主动发起clear request消息拆除链路才能释放，因此从误差的变化走势看，误差是逐步增高后，再慢慢减少。

上图为这种情况的例子：在通话结束后，MSC没有立即向BSC下发clear command消息拆除A口链路，手机在等待10秒钟后主动拆除无线链路，BSC通过clear request请求MSC拆除A口链路。由于在空中接口和Abis口的链路释放流程属于正常释放，并不是掉话造成的链路释放，所以OMC不计为掉话。

u A接口信令统计掉话次数小于OMC统计掉话次数
这种情况比较普遍，误差最大时，信令统计掉话次数要比OMC统计少20％，目前发现这与控制切换掉话的计时器T3103，T8，以及交换机中的某一个计时器配合有关。
由于OMC统计切换掉话MC621是以BSC内的三个计时器超时为触发条件，而并非信令触发就会造成此种情况。为此我们介绍一下BSC触发切换掉话的计时器：
T3103：
定义：用来控制BSC内的不同小区切换，该计时器超时，记为掉话
触发条件：BSC下发handover command消息
停止条件：BSC收到handover failure或handover complete
T8：
定义：用来控制不同BSC间的小区切换，该计时器超时，记为掉话
触发条件：服务BSC下发handover command消息
停止条件：服务BSC收到handover failure消息或BSC收到MSC发送的clear command（cause：handover successful）
T3107：
定义：用来控制小区内的切换，该计时器超时，记为掉话。
触发条件：BSC下发Assignment command消息
停止条件：BSC收到assignment failure或assignment complete

从阿尔卡特区域的参数设置来看，不允许小区内的切换，所以切换掉话就是T3103和T8超时的次数之和。当计时器T3103或T8超时后，BSC会向MSC发送clear request，原因为radio interface message failure。同时在阿尔卡特交换机有一计时器（作用是当一方挂机后，多长时间交换机向BSC发送Clear Command 命令主动拆链）。如果两个计时器配合不合理，就会出现下面这种情况。
当交换机的计时器超时，向BSC放松Clear Command消息动拆除了链路；而BSC一侧只能等待T8或T3103超时，BSC才会做相应处理（通常上发Clear Request）。而此时而此时BSC早已收到交换机下发的Clear Command消息，因此不会上发Clear Request 消息，从而A接口不会统计为掉话，而OMC将会统计成切换掉话。从而造成了A接口统计的掉话少于OMC统计的掉话。
我们可以通过减小T8、T3103和交换侧计时器的时间上的差距，来减少此情况造成的A接口和OMC统计掉话的差异。

以上介绍的是各地A接口和OMCR统计掉话差异中最为常见几种情况，实际中可能遇到其他原因造成的差异，需要我们认真分析，区别对待。