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

江敏健

摘 要：本文通過采集現(xiàn)網(wǎng)信令數(shù)據(jù)，基于呼叫失敗信令模型和呼叫失敗原因值的分析成果，提出了一種對呼叫失敗的手機用戶進行友好提醒的方案，當(dāng)客戶呼叫失敗時，可以向主叫用戶下發(fā)短信，解釋其呼叫失敗的原因以及可以采取的改善行為，通過該方式來提升用戶感知度。

關(guān)鍵詞：信令分析；呼叫失敗；感知；滿意度

1 引言

信令分析是運營商網(wǎng)絡(luò)故障定位的常用手段，近年來基于信令分析進行網(wǎng)絡(luò)故障定位、隱患排查等項目也逐步在國內(nèi)各運營商鋪開，但從項目的成果看，大多停留在分析研究上，并未能將這些成果很好的落地。筆者從大量信令分析服務(wù)項目成果中進行總結(jié)與提煉，提出一種基于呼叫失敗信令分析的提醒服務(wù)方案，旨在幫助運營商通過提升用戶感知度，強化運營商的競爭力，達到用戶、運營商雙方得益的局面。

2 呼叫失敗的現(xiàn)狀

呼叫失敗是指主叫用戶撥打號碼后，在還沒有聽到回鈴音之前，由網(wǎng)絡(luò)下發(fā)釋放消息、中止呼叫。呼叫失敗時，主叫用戶一般都能聽到網(wǎng)絡(luò)下發(fā)的通知音解釋本次呼叫未能接通的原因，但是還有相當(dāng)數(shù)量的呼叫失敗表現(xiàn)為主叫用戶呼叫后直接返回待機狀態(tài)，沒有任何解釋，這類呼叫失敗現(xiàn)象會嚴(yán)重影響用戶感知度，而且會造成其他負面后果，主要表現(xiàn)為以下兩方面：

⑴用戶會懷疑運營商的網(wǎng)絡(luò)質(zhì)量問題，對運營商失去信心，久而久之將極有可能導(dǎo)致用戶流失；

⑵大量用戶出現(xiàn)呼叫失敗而又沒有任何提示時，一般會繼續(xù)多次撥打，存在著引發(fā)“雪崩效應(yīng)”的隱患，使站點或交換機負荷過高而癱瘓，引發(fā)更為嚴(yán)重的通信故障。

事實上，這些呼叫失敗并非都是網(wǎng)絡(luò)質(zhì)量問題導(dǎo)致。移動通信是一個復(fù)雜的系統(tǒng)，用戶的行為、手機終端、業(yè)務(wù)功能等方面因素都有可能導(dǎo)致呼叫失敗，但是對于用戶來說，用戶并不知道其呼叫失敗的原因，用戶在遇到呼叫失敗時會迷惘，不知所措。所謂“知情就是力量”，不管是什么原因?qū)е碌暮艚惺?，只要能第一時間告知用戶，或許用戶的感受、行為就能發(fā)生根本性的變化。

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

呼叫失敗在信令流程中表現(xiàn)為用戶發(fā)起“CM_SERVICE_REQUEST”消息后，在其后的流程中沒有收到ALERTING、CONNECT、CONNECT_ACK等接通的消息，而由網(wǎng)絡(luò)側(cè)下發(fā)釋放消息中止呼叫。

網(wǎng)絡(luò)下發(fā)的釋放消息一般有“CM_SERVICE_REJECT”和“DISCONNECT”兩種，前者是在CM服務(wù)尚未建立就被網(wǎng)絡(luò)中止呼叫，后者一般為CM服務(wù)建立后網(wǎng)絡(luò)下發(fā)的釋放消息，但這些釋放消息都帶有一個原因值，一般稱為Cause值，指示了本次釋放的原因，這些Cause值都可以在3GPP協(xié)議規(guī)范中找到其解釋，有些解釋很明顯的指示了失敗原因，如電路擁塞、無線資源不可用等，也有些解釋比較籠統(tǒng)，如DTAP_CC層的Temporary failure、DTAP_MM層的Network failure等，從Cause的字面解釋無法知道釋放消息的真正原因，這時就需要根據(jù)本次呼叫失敗的信令模型、用戶行為、多接口關(guān)聯(lián)等分析手段對呼叫失敗進行原因追查。

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

⑴建立A接口呼叫失敗的呼叫模型，即手機主叫發(fā)起CM SERVICE REQUEST，在A接口會話中，沒有ALERTING、CONNECT，排除正常的呼叫終結(jié)Cause值。

⑵統(tǒng)計A接口上釋放消息所帶的Cause值，并進行數(shù)量的上排序。

⑶對數(shù)量較大、異常的Cause值進行原因追查，查詢下放釋放消息的前一條消息的詳細內(nèi)容，如仍無法明確原因則需要進行多接口關(guān)聯(lián)，直至關(guān)聯(lián)到被叫端無線側(cè)，追蹤下發(fā)釋放消息的根節(jié)點，如在根節(jié)點仍無法明確原因，則需要查詢用戶行為，看是否由用戶行為導(dǎo)致的呼叫失敗。

⑷對明確原因的Cause提出優(yōu)化建議及實施。

3.2 我們一般將呼叫失敗原因歸為四種類型

⑴由于無線環(huán)境質(zhì)差導(dǎo)致的呼叫失敗

⑵由于核心網(wǎng)存在隱患、故障引發(fā)的呼叫失敗

⑶由于用戶行為導(dǎo)致的呼叫失敗

⑷由于用戶終端導(dǎo)致的呼叫失敗

基于信令分析的呼叫失敗優(yōu)化項目能對前兩種原因引起的呼叫失敗進行優(yōu)化，而對于后兩類原因只停留在分析研究上，其成果效益并不明顯。

4 主叫用戶提醒方案設(shè)計

4.1 呼叫失敗提醒的設(shè)計框架

呼叫失敗用戶提醒的核心思想是將基于呼叫信令的分析成果進行落地，將研究成果真正惠及用戶，其整體設(shè)計框架如下所示：

⑴當(dāng)用戶出現(xiàn)呼叫失敗時，其信令數(shù)據(jù)被信令采集設(shè)備所采集、解碼并存入信令數(shù)據(jù)庫。

⑵信令系統(tǒng)對呼叫失敗的會話進行建模，建模要點包括會話所包含的消息、釋放消息攜帶的Cause值、釋放消息出現(xiàn)的位置。

⑶將建立呼叫失敗模型與呼叫失敗模型庫進行比較匹配，如果匹配成功，則根據(jù)呼叫失敗模型庫中對該呼叫失敗模型的原因解釋以及用戶操作建議以短信的形式發(fā)送給用戶。

⑷如果匹配不成功，則需要對該種類型的呼叫失敗模型進行研究，追蹤其失敗原因，再將新的成果輸入到呼叫失敗模型庫中去。

圖中循環(huán)1是信令分析應(yīng)用部分，即為用戶提供呼叫失敗提醒功能；循環(huán)2相當(dāng)于一個改進系統(tǒng)，為系統(tǒng)提供持續(xù)動力，令整個呼叫失敗提醒功能不斷完善，不斷適應(yīng)復(fù)雜的環(huán)境。

4.2 方案拓撲結(jié)構(gòu)

呼叫失敗提醒方案是以信令分析為基礎(chǔ)一種解決方案，需要對現(xiàn)網(wǎng)各接口進行信令搭接，其拓撲結(jié)構(gòu)如下圖：

信令搭接的涉及到的網(wǎng)絡(luò)接口和協(xié)議有：

⑴Mc接口，主要采集BSSAP、RANAP、H.248、BICC協(xié)議的信令數(shù)據(jù)（適用于IP化軟交換局）

⑵A接口，主要采集BSSAP協(xié)議的信令數(shù)據(jù)（適用于傳統(tǒng)非軟交換局）

⑶C接口（MSC-S＼MSC與LSTP的接口），主要采集MAP協(xié)議的信令數(shù)據(jù)

⑷A-bis接口，采集BSC側(cè)以下的信令數(shù)據(jù)

信令采集系統(tǒng)通過IP網(wǎng)絡(luò)與短信中心建立連接，為給用戶下發(fā)短信建立通道。

4.3 應(yīng)用案例

用戶在某一建了MSC IN POOL的城市出現(xiàn)呼叫困難現(xiàn)象，而在其它非POOL城市則能正常使用。具體表現(xiàn)為每次呼叫需要重復(fù)撥7-8次才能呼叫成功，呼叫失敗時手機顯示“連接錯誤”。

信令系統(tǒng)捕捉到該用戶的呼叫失敗信令流程，如下所示：

用戶在呼叫過程中收到網(wǎng)絡(luò)下發(fā)CM_SERVICE_REJECT攜帶Dtap_Cause_4，協(xié)議規(guī)范解釋為“IMSI UNKNOW IN VLR”。

系統(tǒng)將該呼叫失敗模型與已知的呼叫失敗模型庫進行匹配，得到該呼叫失敗的原因以及用戶操作建議：

系統(tǒng)提取呼叫失敗模型庫中該呼叫失敗的提醒短信內(nèi)容，及時向主叫用戶發(fā)送呼叫失敗提醒短信。

上述案例為非網(wǎng)絡(luò)質(zhì)量導(dǎo)致的呼叫失敗，如果沒有呼叫失敗用戶提醒短信，用戶會由于不知情而懷疑運營商的網(wǎng)絡(luò)質(zhì)量。呼叫失敗用戶提醒短信可以消除用戶的疑惑，既讓用戶明白其呼叫失敗并非網(wǎng)絡(luò)原因，及時改變聯(lián)系方式避免誤事，又能讓用戶感受到運營商的貼心服務(wù)和技術(shù)含量，增加了用戶對運營商的認同感與依賴度，可謂一舉多得。

5 小結(jié)

通過對各類呼叫失敗過程的信令監(jiān)測，結(jié)合模型庫數(shù)據(jù)的比對，分析呼叫失敗的原因，通過短信方式將呼叫失敗的原因、用戶操作建議及時地送達客戶，讓客戶感受到運營商的貼心服務(wù)，是一種“以人為本”的服務(wù)理念。在高速發(fā)展的移動通信市場上，運營商必須采用創(chuàng)新的手段為客戶提供新的亮點，增強用戶感知度、吸引用戶、留住用戶，方能在激烈的市場競爭中領(lǐng)先一步。

[參考文獻]

[1]袁永福，洪燁.GSM手機引起用戶感知度下降的原因.通信管理與技術(shù)，2008，（2）

[2]熊靜.疑難問題定位與分析.

[3]黃成龍，楊文鵬.基于用戶感知的GSM/CDMA網(wǎng)絡(luò)監(jiān)測及優(yōu)化.移動通信，2009，（3）.