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

1、A接口与Abis接口信令一致性比较为了解OMC TYPE 110统计掉话次数的真实性，采集了某个BSC 一个小时的A接口信令，统计TCH的掉话次数，与110报告比较。前期准备工作和结果1. A接口统计的Clear Request消息数目与OMC TYPE 18报告所统计的Clear Request消息数目是一致的。2. A接口统计的TCH掉话次数比OMC TYPE 110所统计的掉话次数多超过10个百分点。3. 各Abis统计的掉话次数与OMC TYPE 110相应小区所统计的掉话次数基本相等。由上述3个结果可以推断出：Abis与A接口在统计掉话次数上存在不一致的情况。即A接口统计的掉话次数要

2、比Abis统计的掉话次数多超过10个百分点。为了验证上述推论的正确性，我们采集了某个BSCA接口信令以及该BSC下的所有小区的Abis信令，通过对比，希望发现两者在统计TCH掉话上的不同之处。A接口与Abis接口信令一致性比较l 主要思路先来看看在A接口和Abis接口上是如何判断TCH掉话的。由于系统掉话很少，为了简化分析，我们只讨论无线掉话和切换掉话，而不考虑系统掉话。1. A接口根据CMCC对话音信道掉话次数的定义，在A接口上统计无线掉话次数，应以ASSIGNMENT COMPLETE后发生的CLEAR REQUEST次数以及HANDOVER COMPLETE后发生的CLEAR REQUE

3、ST次数为准。而CLEAR REQUEST包含多个原因：原因Radio interface failureRadio interface message failureEquipment failureO&M interventionNo radio resource available其中，“No radio resource available”为TCH拥塞造成，故不计为掉话。所以，A接口统计掉话次数是除去“No radio resource available”的其它四种原因的CLEAR REQUEST次数总和。无线掉话和切换掉话的Cause为Radio interface fa

4、ilure和Radio interface message failure。2. Abis接口根据OMC对无线掉话（MC736）和切换掉话（MC621）计数器的定义，若有以下两条信令在TCH上出现，计为掉话1. CONNECT FAILURE INDICATION: （Cause： radio link failure ）2. Error indication 导致掉话。通常的Cause为 T200 expired （N2001）times。所以，若在A接口上出现Clear Request（Cause为Radio interface failure或Radio interface messag

5、e failure），而在Abis上没有出现CONNECT FAILURE INDICATION: （Cause： radio link failure ）或Error indication（造成掉话）的情况，则认为是Abis接口与A接口统计掉话存在差别的原因。l 分析结果共出现3种异常流程，占到总掉话次数的101. 通话结束后A口出现clear request手机在16：15：05，483时上发release complete消息，接着成功进行了一次BSC内的切换。MSC没有回应clear command，而在10秒后，手机主动拆链，BSC向MSC发送clear request消息。正常情况

6、下，在通话结束后，即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

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

8、接，cause为radio interface failure，时间为13：15：46.069。这种情况主要由于在通话结束后，还存在短消息的流程，所以MSC没有向BSC发送clear command拆链，而由无线侧主动释放链路，故在A口上出现clear request，记为掉话。这类情况占到总掉话次数的3。针对这种情况，有以下几个疑问。¨ 由手机主动拆链是否符合规范¨ 网络是否支持通话流程和短消息流程同时存在，并且在通话结束后仍能保留短消息流程。¨ 若在通话流程和短消息流程同时存在的情况下，手机不回cpack的原因针对第一个问题，查找了呼叫释放的规范（call r

9、elease）发现存在这种情况，见 N0200。从上述信令流程可知，在网络中存在这种呼叫释放，它会在A接口出现Clear Request消息，被误计为掉话，但它却不是掉话。原因是通话结束后，即DISC，Release Complete后，由于MSC没有向BSC发Clear Command，手机在等待超时后自行释放链路，而并不是由于无线质量恶化或切换导致掉话。所以OMC没有把这种情况计为掉话。针对第二个问题，根据alcatel规范（详见SMS point to point）网络支持通话过程和短消息同时存在的情况，并且支持在通话结束后，仍保留信道用来传送短消息的情况。那手机为什么不回cpack消息

10、？我们来看以下流程从信令上来看，网络下发了cpdata，但手机没有回cpack，而在Abis上也没有无线环境恶化的信令存在。以下为包含测量报告的流程具体看一下测量报告中的内容服务小区的上行接收电平为80dBm，上行质量为0，下行接收电平为85dBm，下行质量为0。无线环境正常。既然无线环境没有任何问题，下发的短消息也应该被手机收到，而网络也支持这种类型的短消息，手机不回cpack的原因只能是该种手机不支持这种类型的短消息。解决建议：这种情况主要由于某些手机不支持通话结束后的短消息，故不回应cpack，而MSC内有相应的计时器来控制短消息的响应时间。对于cpdata为15秒。即若手机在15秒内对

11、cpdata消息没有应答，MSC会主动下发clear command进行拆链。由于手机在上发release complete后10秒钟会主动拆链，所以MSC应在此之前下发clear command,才可以避免由手机来释放链路。目前15秒钟的设置可能过长。3. 通话和短消息流程都成功结束后，A口出现clear request这种情况主要由于在短消息流程结束后MSC没有向BSC发送clear command拆链，而由手机主动释放链路造成。这类情况占到总掉话次数的2。解决建议:在所有流程都结束的情况下MSC尽快下发clear command拆链，防止由手机释放链路造成在A口上出现clear requ

12、est。l 西门子设备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消

13、息，拆除链路。这种情况占到总的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