基于呼叫失败信令研究主叫用户提醒方案.docVIP

基于呼叫失败信令研究主叫用户提醒方案 　　摘 要：本文通过采集现网信令数据，基于呼叫失败信令模型和呼叫失败原因值的分析成果，提出了一种对呼叫失败的手机用户进行友好提醒的方案，当客户呼叫失败时，可以向主叫用户下发短信，解释其呼叫失败的原因以及可以采取的改善行为，通过该方式来提升用户感知度。 关键词：信令分析；呼叫失败；感知；满意度 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值、释放消息出现的位置。 ⑶将建立呼叫失败模型与呼叫失败模型库进行比较匹配，如果匹配成功，则根据呼叫