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 arRequ 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。

从上述信令流程可知，在网络中存在这种呼叫释放，它会在A接口出现Clear Request消息，被误计为掉话，但它却不是掉话。

原因是通话结束后，即DISC，Release Complete后，由于MSC 没有向BSC发Clear Command，手机在等待超时后自行释放链路，而并不是由于无线质量恶化或切换导致掉话。

所以OMC没有把这种情况计为掉话。

针对第二个问题，根据alcatel规范（详见SMS point to point）网络支持通话过程和短消息同时存在的情况，并且支持在通话结束后，仍保留信道用来传送短消息的情况。

那手机为什么不回cpack消息？我们来看以下流程从信令上来看，网络下发了cpdata，但手机没有回cpack，而在Abis上也没有无线环境恶化的信令存在。

以下为包含测量报告的流程具体看一下测量报告中的内容服务小区的上行接收电平为－80dBm，上行质量为0，下行接收电平为－85dBm，下行质量为0。

无线环境正常。

既然无线环境没有任何问题，下发的短消息也应该被手机收到，而网络也支持这种类型的短消息，手机不回cpack的原因只能是该种手机不支持这种类型的短消息。

解决建议：这种情况主要由于某些手机不支持通话结束后的短消息，故不回应cpack，而MSC内有相应的计时器来控制短消息的响应时间。

对于cpdata为15秒。

即若手机在15秒内对cpdata消息没有应答，MSC会主动下发clear command进行拆链。

由于手机在上发release complete后10秒钟会主动拆链，所以MSC应在此之前下发clear command,才可以避免由手机来释放链路。

目前15秒钟的设置可能过长。

3.通话和短消息流程都成功结束后，A口出现clear request这种情况主要由于在短消息流程结束后MSC没有向BSC发送c lear command拆链，而由手机主动释放链路造成。

这类情况占到总掉话次数的2％。

解决建议:在所有流程都结束的情况下MSC尽快下发clear command拆链，防止由手机释放链路造成在A口上出现clear request。

西门子设备A口信令调查我们采集了西门子交换机，阿尔卡特BSS的A接口数据，也发现了类似的掉话流程从该流程可见：在09：20：38：621时手机上发assignment complete消息，成功占用了TCH，在09：21：03：300时，网络在TCH信道上下发短消息，接着，手机挂机，网络侧在09：21：07:422时再次发送assignment request消息，分配信令信道，即接下去的短消息在信令信道上传送，而阿尔卡特的信令流程为不分配信令信道，而直接在TCH上传送短消息。

由于手机没有回cpack 消息，在09：21：17.764时，BSS向MSC发送clear request消息，拆除链路。

这种情况占到总的TCH掉话次数的9％。

要点：☐在通话过程中，网络下发短消息，alcatel设备与西门子设备的表现形式不同alcate设备通过保留已经存在的TCH信道来传送短消息，而西门子设备重新分配信令信道，使短消息在新分配的信令信道上传送。

☐在两种设备下都出现了由于非常规短消息失败造成的A接口掉话信令clear request（radio interface failure）。

原因都是手机没有回应cpack消息并超时后，造成的非正常拆链。

不同的是，对于alcatel设备，clear request发生在TCH上，而对于西门子设备，发生在SDCCH上。

☐对于西门子设备，虽然clear request发生在SDCCH上，但该消息与发生在TCH上的clear request完全一致，无法区分两者。

此外，在A口分配SDCCH的信令与分配TCH的信令相同，都为assignment request和assignment complete消息，在assignment request消息中有一标志位来识别信道类型，SDCCH为signalling，TCH为speech。

而对于assignment complete 消息，两者没有任何区别。

☐据了解，OCEAN 公司统计A口掉话的方法是统计Assignment complete消息后发生的clear request消息的次数，所以，对于alcatel和西门子设备，由于非常规短消息失败造成的clear request消息都会记为掉话，且比例相近。