Server小區(qū)數(shù)據(jù)缺失分析

王曉娜 許鵬翔

【摘要】本文以移動通信用戶在某3G小區(qū)做主叫時連續(xù)多次失敗為案例，通過信令分析手段對其進行深入分析，通過歸納總結(jié)出小區(qū)數(shù)據(jù)漏定義場景下的用戶模型，并對全網(wǎng)進行核查分析，為后續(xù)該類問題的排查提供了依據(jù)。

【關(guān)鍵詞】主叫呼叫連續(xù)失敗信令分析小區(qū)數(shù)據(jù)

一、問題描述

本文以移動通信網(wǎng)中發(fā)現(xiàn)用戶投訴在某3G小區(qū)做主叫時連續(xù)多次失敗，通過在信令查詢系統(tǒng)上查詢用戶呼叫記錄，發(fā)現(xiàn)用戶連續(xù)5次主叫失敗后呼叫正常，失敗原因均顯示為：RANAP（MSC->RNC）：IU RELEASE COMMAND（Normal Release），而查詢用戶HLR及VLR數(shù)據(jù)正常。

二、問題分析及定位

在信令查詢系統(tǒng)上查詢用戶幾次呼叫失敗的信令流程均一致，如下圖異常流程所示。查詢該小區(qū)其它用戶正常的主叫流程，對兩個呼叫流程進行對比發(fā)現(xiàn)，異常流程中RNC發(fā)起CM_SERVICE_REQUEST之后24秒核心網(wǎng)側(cè)就發(fā)起IU_REL_CMD拆除呼叫流程，而正常流程中核心網(wǎng)側(cè)會發(fā)起鑒權(quán)流程。

查詢異常流程中IU_REL_CMD攜帶的原因碼為normal release，并且查詢到RNC發(fā)送的CM_SERVICE_REQUEST中攜帶上來的LAI/SAI分別為A61E/5A3E。

在用戶登記的局點上查詢小區(qū)數(shù)據(jù)表發(fā)現(xiàn)該局點沒有該小區(qū)數(shù)據(jù)，另外從用戶的呼叫記錄中發(fā)現(xiàn)用戶5次主叫失敗都是在該小區(qū)，而之后發(fā)起主叫成功則是在另外的小區(qū)。為重現(xiàn)該故障場景，將用戶遷移到該局點下并重選到該小區(qū)，用戶做主被叫均失敗，重選到臨近小區(qū)則呼叫正常，初步確定為該局點小區(qū)數(shù)據(jù)缺漏導致用戶業(yè)務(wù)異常，經(jīng)補全數(shù)據(jù)后業(yè)務(wù)恢復正常。

考慮到核心組pool之后可能存在個別server漏定義小區(qū)數(shù)據(jù)的情況，而舊版本的設(shè)備并沒有很好的檢測機制對該隱患進行預警，借這個案例，利用信令分析系統(tǒng)進行業(yè)務(wù)異常場景的分析，在呼損分析找出對應(yīng)的呼損點。

在正常的局點呼損分析中，CM_SERVICE_REQUEST節(jié)點釋放消息為IU_RELEASE_COMMAND（原因值83）的數(shù)量很少，如果該釋放原因值的比例比較大并且呼叫失敗的記錄都是同一個小區(qū)，則很大可能為小區(qū)數(shù)據(jù)缺失引起，如下圖所示：

通過呼損記錄發(fā)現(xiàn)該3G小區(qū)的失敗呼叫場景與用戶投訴一致，另外發(fā)現(xiàn)另一小區(qū)B也存在該失敗場景，經(jīng)核查數(shù)據(jù)確認B小區(qū)數(shù)據(jù)也存在漏定義的情況。

三、解決措施及效果

在本案例中，我們可以通過補全小區(qū)數(shù)據(jù)來恢復業(yè)務(wù)。另外，本案例通過對用戶投訴場景的分析和歸納總結(jié)，提出一種利用呼損分析來查找疑似漏定義數(shù)據(jù)小區(qū)的方法，并且利用該方法對現(xiàn)網(wǎng)進行全網(wǎng)分析，挖掘出異常小區(qū)并補全數(shù)據(jù)，避免用戶投訴。

四、結(jié)論

綜上所述，移動通信用戶在某3G小區(qū)做主叫時連續(xù)多次失敗，通過信令分析手段進行分析用戶失敗的呼叫信令最終發(fā)現(xiàn)是由于一個局點漏定義小區(qū)數(shù)據(jù)導致，通過歸納總結(jié)小區(qū)數(shù)據(jù)漏定義場景下的用戶模型，對全網(wǎng)進行核查分析，挖掘小區(qū)數(shù)據(jù)漏定義的網(wǎng)絡(luò)隱患，對后續(xù)該類問題的排查提供了依據(jù)。