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统计掉话差异中最为常见几种情况，实际中可能遇到其他原因造成的差异，需要我们认真分析，区别对待。