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

A接口与Abis接口信令一致性比较 为了解OMC TYPE 110统计掉话次数的真实性，采集了某个BSC 一个小时的A接口信令，统计TCH的掉话次数，与110报告比较。 前期准备工作和结果 A接口统计的Clear Request消息数目与OMC TYPE 18报告所统计的Clear Request消息数目是一致的。 A接口统计的TCH掉话次数比OMC TYPE 110所统计的掉话次数多超过10个百分点。 各Abis统计的掉话次数与OMC TYPE 110相应小区所统计的掉话次数基本相等。 由上述3个结果可以推断出：Abis与A接口在统计掉话次数上存在不一致的情况。即A接口统计的掉话次数要比Abis统计的掉话次数多超过10个百分点。 为了验证上述推论的正确性，我们采集了某个BSCA接口信令以及该BSC下的所有小区的Abis信令，通过对比，希望发现两者在统计TCH掉话上的不同之处。 A接口与Abis接口信令一致性比较 主要思路 先来看看在A接口和Abis接口上是如何判断TCH掉话的。由于系统掉话很少，为了简化分析，我们只讨论无线掉话和切换掉话，而不考虑系统掉话。 A接口 根据CMCC对话音信道掉话次数的定义，在A接口上统计无线掉话次数，应以ASSIGNMENT COMPLETE后发生的CLEAR REQUEST次数以及HANDOVER COMPLETE后发生的CLEAR REQUEST次数为准。而CLEAR REQUEST包含多个原因： 原因 Radio interface failure Radio interface message failure Equipment failure OM intervention No radio resource available 其中，“No radio resource available”为TCH拥塞造成，故不计为掉话。 所以，A接口统计掉话次数是除去“No radio resource available”的其它四种原因的CLEAR REQUEST次数总和。无线掉话和切换掉话的Cause为Radio interface failure和Radio interface message failure。 Abis接口 根据OMC对无线掉话（MC736）和切换掉话（MC621）计数器的定义，若有以下两条信令在TCH上出现，计为掉话 CONNECT FAILURE INDICATION: （Cause： radio link failure ） Error indication 导致掉话。 通常的Cause为 T200 expired （N200＋1）times。 所以，若在A接口上出现Clear Request（Cause为Radio interface failure或Radio interface message failure），而在Abis上没有出现CONNECT FAILURE INDICATION: （Cause： radio link failure ）或Error indication（造成掉话）的情况，则认为是Abis接口与A接口统计掉话存在差别的原因。 分析结果 共出现3种异常流程，占到总掉话次数的10％ 通话结束后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。 通话结束前，网络下发短消息，A口出现clear request 在13：15：32，950时，网络侧下发cpdata消息，说明有短消息下发给手机，而手机始终没有回应cpack消息。在13:15:35.368时，手机挂机，向网络发送DISC消息，网络回Release，在13：15：35.802手机发送Release Complete消息。由于MSC发现还有短消息的流程没有结束，故处于等待手机上发cpack的状态。等待的时长由一计时器控制。手机始终没有回cpa