郭艷萍

【摘要】語音掉話是通信系統(tǒng)中常見的故障之一，它的出現(xiàn)嚴(yán)重影響了整個(gè)網(wǎng)絡(luò)的運(yùn)行質(zhì)量，在用戶方面的負(fù)面影響最為直接，容易引起用戶強(qiáng)烈投訴，對(duì)用戶滿意度指標(biāo)影響極大。本文重點(diǎn)講述如何從移動(dòng)核心網(wǎng)角度對(duì)掉話進(jìn)行分析，為無線環(huán)境掉話分析提供幫助。

【關(guān)鍵詞】核心網(wǎng)掉話分析

一、引言

掉話是指用戶通信過程中發(fā)生異常釋放，該問題是日常網(wǎng)絡(luò)優(yōu)化面臨的一個(gè)常見問題。概括來講掉話是由鄰區(qū)漏配、覆蓋問題、切換問題、干擾問題、流程交互問題等原因造成，通常掉話是通過無線側(cè)手段進(jìn)行分析，核心網(wǎng)也可以結(jié)合網(wǎng)優(yōu)掉話測(cè)試，跟蹤A/IU口全流程信令消息，通過對(duì)接口全流程信令消息的分析，協(xié)助查找掉話產(chǎn)生的原因。

二、異常拆線流程（掉話）

2G掉話流程：

通話過程中，MS未處于切換狀態(tài)，在A接口上采集到向BSC發(fā)送的Clear Command消息（原因值不為Handover successful），且未采集到“Clear Request”和“Disconnect”消息。

3G掉話流程：

通話過程中，MS未處于切換狀態(tài)，在IuCS口上采集到向RNC發(fā)送的Iu Release Command消息（原因值不為Successful Relocation），且未采集到“Clear Request”和“Disconnect”消息。

當(dāng)核心網(wǎng)MSC收到B側(cè)上報(bào)上來的clear request和release request消息，則統(tǒng)計(jì)一次掉話。

三、現(xiàn)網(wǎng)掉話分析案例

3.1性能統(tǒng)計(jì)分析

位置區(qū)粒度分析SERVER2下460018020位置區(qū)指標(biāo)變化較為明顯，如表1：

需要無線側(cè)配合進(jìn)一步排查原因。

3.2呼叫記錄捕捉

在本網(wǎng)內(nèi)進(jìn)行大量撥打測(cè)試，測(cè)試過程中發(fā)現(xiàn)的一次掉話：呼叫接通2秒后拆線，查看消息和話單記錄實(shí)際呼叫駐留在2G下：

無線側(cè)上報(bào)clear-request消息（如圖1所示）

消息中原因值為requested-terrestrial-resource-un- available（34）。

3.3呼叫話單記錄（如表2）

CV155CV_TERMINAL_ERROR系統(tǒng)定義的某些終端故障導(dǎo)致呼叫失敗。

需要無線側(cè)配合排查原因。無線側(cè)通過分析系統(tǒng)日志，發(fā)現(xiàn)BSC8的一塊GPUC單板存在異常，進(jìn)行更換。

更換單板前后話務(wù)統(tǒng)計(jì)對(duì)比，更換單板后掉話明顯下降，恢復(fù)正常如表3：

四、分析總結(jié)

結(jié)合以上故障案例，核心網(wǎng)層面可以通過以下方法進(jìn)行掉話分析：

4.2消息跟蹤

在測(cè)試過程中通過在華為MSC LMT對(duì)測(cè)試號(hào)碼的消息和日志跟蹤，實(shí)時(shí)捕捉到系統(tǒng)消息，配合問題定位。

4.3結(jié)合話單

我們一般通過話單中的diagnostic（診斷信息）來進(jìn)行判斷。當(dāng)diagnostic的值為009B的時(shí)候，我們可以判斷通話過程中發(fā)生了掉話，由于diagnostic和我們的內(nèi)部拆線原因值是對(duì)應(yīng)的，而009B對(duì)應(yīng)的內(nèi)部原因值是CV155，對(duì)應(yīng)到A/IU口，拆線原因即為CV27：終端故障。

4.4場(chǎng)景測(cè)試

實(shí)際對(duì)于掉話問題的測(cè)試過程，呼以叫模型不易太復(fù)雜，以免出現(xiàn)掉話后，較難定位問題點(diǎn)。實(shí)際測(cè)試過程以本地本網(wǎng)局內(nèi)（主被叫號(hào)碼均注冊(cè)在同一SERVER內(nèi)）、本地本網(wǎng)局間（主被叫號(hào)碼分別注冊(cè)在本地兩個(gè)SERVER上）為宜。

參考文獻(xiàn)

[1]華為MSOFTX3000操作手冊(cè)2011