基于呼叫失败信令分析的主叫用户提醒方案

江敏健

摘 要：本文通过采集现网信令数据，基于呼叫失败信令模型和呼叫失败原因值的分析成果，提出了一种对呼叫失败的手机用户进行友好提醒的方案，当客户呼叫失败时，可以向主叫用户下发短信，解释其呼叫失败的原因以及可以采取的改善行为，通过该方式来提升用户感知度。

关键词：信令分析；呼叫失败；感知；满意度

1 引言

信令分析是运营商网络故障定位的常用手段，近年来基于信令分析进行网络故障定位、隐患排查等项目也逐步在国内各运营商铺开，但从项目的成果看，大多停留在分析研究上，并未能将这些成果很好的落地。笔者从大量信令分析服务项目成果中进行总结与提炼，提出一种基于呼叫失败信令分析的提醒服务方案，旨在帮助运营商通过提升用户感知度，强化运营商的竞争力，达到用户、运营商双方得益的局面。

2 呼叫失败的现状

呼叫失败是指主叫用户拨打号码后，在还没有听到回铃音之前，由网络下发释放消息、中止呼叫。呼叫失败时，主叫用户一般都能听到网络下发的通知音解释本次呼叫未能接通的原因，但是還有相当数量的呼叫失败表现为主叫用户呼叫后直接返回待机状态，没有任何解释，这类呼叫失败现象会严重影响用户感知度，而且会造成其他负面后果，主要表现为以下两方面：

⑴用户会怀疑运营商的网络质量问题，对运营商失去信心，久而久之将极有可能导致用户流失；

⑵大量用户出现呼叫失败而又没有任何提示时，一般会继续多次拨打，存在着引发“雪崩效应”的隐患，使站点或交换机负荷过高而瘫痪，引发更为严重的通信故障。

事实上，这些呼叫失败并非都是网络质量问题导致。移动通信是一个复杂的系统，用户的行为、手机终端、业务功能等方面因素都有可能导致呼叫失败，但是对于用户来说，用户并不知道其呼叫失败的原因，用户在遇到呼叫失败时会迷惘，不知所措。所谓“知情就是力量”，不管是什么原因导致的呼叫失败，只要能第一时间告知用户，或许用户的感受、行为就能发生根本性的变化。

3 基于信令的呼叫失败分析

呼叫失败在信令流程中表现为用户发起“CM_SERVICE_REQUEST”消息后，在其后的流程中没有收到ALERTING、CONNECT、CONNECT_ACK等接通的消息，而由网络侧下发释放消息中止呼叫。

网络下发的释放消息一般有“CM_SERVICE_REJECT”和“DISCONNECT”两种，前者是在CM服务尚未建立就被网络中止呼叫，后者一般为CM服务建立后网络下发的释放消息，但这些释放消息都带有一个原因值，一般称为Cause值，指示了本次释放的原因，这些Cause值都可以在3GPP协议规范中找到其解释，有些解释很明显的指示了失败原因，如电路拥塞、无线资源不可用等，也有些解释比较笼统，如DTAP_CC层的Temporary failure、DTAP_MM层的Network failure等，从Cause的字面解释无法知道释放消息的真正原因，这时就需要根据本次呼叫失败的信令模型、用户行为、多接口关联等分析手段对呼叫失败进行原因追查。

3.1 基于信令的呼叫失败分析一般流程如下

⑴建立A接口呼叫失败的呼叫模型，即手机主叫发起CM SERVICE REQUEST，在A接口会话中，没有ALERTING、CONNECT，排除正常的呼叫终结Cause值。

⑵统计A接口上释放消息所带的Cause值，并进行数量的上排序。

⑶对数量较大、异常的Cause值进行原因追查，查询下放释放消息的前一条消息的详细内容，如仍无法明确原因则需要进行多接口关联，直至关联到被叫端无线侧，追踪下发释放消息的根节点，如在根节点仍无法明确原因，则需要查询用户行为，看是否由用户行为导致的呼叫失败。

⑷对明确原因的Cause提出优化建议及实施。

3.2 我们一般将呼叫失败原因归为四种类型

⑴由于无线环境质差导致的呼叫失败

⑵由于核心网存在隐患、故障引发的呼叫失败

⑶由于用户行为导致的呼叫失败

⑷由于用户终端导致的呼叫失败

基于信令分析的呼叫失败优化项目能对前两种原因引起的呼叫失败进行优化，而对于后两类原因只停留在分析研究上，其成果效益并不明显。

4 主叫用户提醒方案设计

4.1 呼叫失败提醒的设计框架

呼叫失败用户提醒的核心思想是将基于呼叫信令的分析成果进行落地，将研究成果真正惠及用户，其整体设计框架如下所示：

⑴当用户出现呼叫失败时，其信令数据被信令采集设备所采集、解码并存入信令数据库。

⑵信令系统对呼叫失败的会话进行建模，建模要点包括会话所包含的消息、释放消息携带的Cause值、释放消息出现的位置。

⑶将建立呼叫失败模型与呼叫失败模型库进行比较匹配，如果匹配成功，则根据呼叫失败模型库中对该呼叫失败模型的原因解释以及用户操作建议以短信的形式发送给用户。

⑷如果匹配不成功，则需要对该种类型的呼叫失败模型进行研究，追踪其失败原因，再将新的成果输入到呼叫失败模型库中去。

图中循环1是信令分析应用部分，即为用户提供呼叫失败提醒功能；循环2相当于一个改进系统，为系统提供持续动力，令整个呼叫失败提醒功能不断完善，不断适应复杂的环境。

4.2 方案拓扑结构

呼叫失败提醒方案是以信令分析为基础一种解决方案，需要对现网各接口进行信令搭接，其拓扑结构如下图：

信令搭接的涉及到的网络接口和协议有：

⑴Mc接口，主要采集BSSAP、RANAP、H.248、BICC协议的信令数据（适用于IP化软交换局）

⑵A接口，主要采集BSSAP协议的信令数据（适用于传统非软交换局）

⑶C接口（MSC-S＼MSC与LSTP的接口），主要采集MAP协议的信令数据

⑷A-bis接口，采集BSC侧以下的信令数据

信令采集系统通过IP网络与短信中心建立连接，为给用户下发短信建立通道。

4.3 应用案例

用户在某一建了MSC IN POOL的城市出现呼叫困难现象，而在其它非POOL城市则能正常使用。具体表现为每次呼叫需要重复拨7-8次才能呼叫成功，呼叫失败时手机显示“连接错误”。

信令系统捕捉到该用户的呼叫失败信令流程，如下所示：

用户在呼叫过程中收到网络下发CM_SERVICE_REJECT携带Dtap_Cause_4，协议规范解释为“IMSI UNKNOW IN VLR”。

系统将该呼叫失败模型与已知的呼叫失败模型库进行匹配，得到该呼叫失败的原因以及用户操作建议：

系统提取呼叫失败模型库中该呼叫失败的提醒短信内容，及时向主叫用户发送呼叫失败提醒短信。

上述案例为非网络质量导致的呼叫失败，如果没有呼叫失败用户提醒短信，用户会由于不知情而怀疑运营商的网络质量。呼叫失败用户提醒短信可以消除用户的疑惑，既让用户明白其呼叫失败并非网络原因，及时改变联系方式避免误事，又能让用户感受到运营商的贴心服务和技术含量，增加了用户对运营商的认同感与依赖度，可谓一举多得。

5 小结

通过对各类呼叫失败过程的信令监测，结合模型库数据的比对，分析呼叫失败的原因，通过短信方式将呼叫失败的原因、用户操作建议及时地送达客户，让客户感受到运营商的贴心服务，是一种“以人为本”的服务理念。在高速发展的移动通信市场上，运营商必须采用创新的手段为客户提供新的亮点，增强用户感知度、吸引用户、留住用户，方能在激烈的市场竞争中领先一步。

[参考文献]

[1]袁永福，洪烨.GSM手机引起用户感知度下降的原因.通信管理与技术，2008，（2）

[2]熊静.疑难问题定位与分析.

[3]黄成龙，杨文鹏.基于用户感知的GSM/CDMA网络监测及优化.移动通信，2009，（3）.