A接口与Abis接口信令一致性比较

A接口与Abis接口信令一致性比较

为了解OM C T YPE 110统计掉话次数的真实性，采集了某个B SC一个小时的A 接口信令，统计T CH的掉话次数，与110报告比较。

前期准备工作和结果

1.A接口统计的Cl ear Re que st消息数目与OM C T YPE 18报告所统计的Cle ar

Requ es t消息数目是一致的。

2.A接口统计的T CH掉话次数比OM C TY PE 110所统计的掉话次数多超过10个百

分点。

3.各Ab is统计的掉话次数与OMC TYP E 110相应小区所统计的掉话次数基本相等。

由上述3个结果可以推断出：Ab is与A接口在统计掉话次数上存在不一致的情况。即A接口统计的掉话次数要比A bis统计的掉话次数多超过10个百分点。

为了验证上述推论的正确性，我们采集了某个BS CA接口信令以及该BS C下的所有小区的Ab is信令，通过对比，希望发现两者在统计TC H掉话上的不同之处。

A接口与A bis接口信令一致性比较

主要思路

先来看看在A接口和Ab is接口上是如何判断TCH掉话的。由于系统掉话很少，为了简化分析，我们只讨论无线掉话和切换掉话，而不考虑系统掉话。

1.A接口

根据CMCC对话音信道掉话次数的定义，在A接口上统计无线掉话次数，应以AS SIGN MENT CO MP LET E后发生的CLEAR REQ UEST次数以及HAN DO VER CO MP LET E后发生的CLEAR REQ UEST次数为准。而CLEAR REQ UEST包含多个原因：

其中，“No r ad io r esourc e av a ilab le”为T CH拥塞造成，故不计为掉话。

所以，A接口统计掉话次数是除去“N o rad io r esourc e av a ilab le”的其它四种原因的CLEAR REQ UEST次数总和。无线掉话和切换掉话的Cause为Radio inte rface failure和R a dio i nte rface me ssage failure。

2.Ab is接口

根据O MC对无线掉话（MC736）和切换掉话（MC621）计数器的定义，若有以下两条信令在TCH上出现，计为掉话

1.CONNECT FAILURE INDICA TION: （Cause：radio link failure ）

2.Error indication 导致掉话。

通常的Cause为T200 expired （N200＋1）times。

所以，若在A接口上出现Cle ar Re que st（Cause为Ra dio i nte rfa ce failu re或Ra dio inte rfa ce me ssage failure），而在Abis上没有出现CONNECT FAILURE INDICATION: （Cause：radio link failure ）或Error indication（造成掉话）的情况，则认为是Abis接口与A接口统计掉话存在差别的原因。

分析结果

共出现3种异常流程，占到总掉话次数的10％

1.通话结束后A口出现clear request

手机在16：15：05，483时上发release complete消息，接着成功进行了一次BSC内的切换。MSC 没有回应clear command，而在10秒后，手机主动拆链，BSC向MSC发送clear request消息。正常情况下，在通话结束后，即MSC收到release complete消息后，应立即下发clear command拆链。目前这种情况主要原因是在通话结束后，MSC没有主动拆链，造成由手机释放链路，在A口上出现clear request 并记为掉话，而在abis口上，没有出现掉话信令，故不记为掉话。这类情况占到总掉话次数的5％。

解决建议:MSC收到release complete后，且在没有其他流程存在的前提下，尽快下发clear command 拆链，防止由手机释放链路造成在A口上出现clear request。

2.通话结束前，网络下发短消息，A口出现clear request

在13：15：32，950时，网络侧下发cpdata消息，说明有短消息下发给手机，而手机始终没有回应cpack消息。在13:15:35.368时，手机挂机，向网络发送DISC消息，网络回Release，在13：15：35.802手机发送Release Complete消息。由于MSC发现还有短消息的流程没有结束，故处于等待手机上发cpack的状态。等待的时长由一计时器控制。手机始终没有回cpack消息，最后由手机释放链路，在Abis上出现Release Indicator（SAPI＝0），时间为13：15：46.041。BSC在收到Release Indicator后向MSC发送Clear Request释放与MSC的连接，cause为radio interface failure，时间为13：15：46.069。

这种情况主要由于在通话结束后，还存在短消息的流程，所以MSC没有向BSC发送clear command 拆链，而由无线侧主动释放链路，故在A口上出现clear request，记为掉话。这类情况占到总掉话次数的3％。

针对这种情况，有以下几个疑问。

☐由手机主动拆链是否符合规范

☐网络是否支持通话流程和短消息流程同时存在，并且在通话结束后仍能保留短消息流程。

☐若在通话流程和短消息流程同时存在的情况下，手机不回cpack的原因

针对第一个问题，查找了呼叫释放的规范（call release）发现存在这种情况，见N0200。