吉林移動關(guān)于除夕夜短信重發(fā)問題分析[圖]

摘要：短信業(yè)務(wù)質(zhì)量問題是用戶經(jīng)常投訴的問題，如何準確分析定位短信業(yè)務(wù)問題是運營商網(wǎng)管維護部門非常關(guān)心的問題，本文給出了短信重發(fā)問題的分析定位過程，以及具體的解決方案。吉林移動的信令監(jiān)測系統(tǒng)由北京中創(chuàng)信側(cè)科技股份有限公司全面建設(shè)維護，本文詳細說明了監(jiān)測系統(tǒng)的應(yīng)用分析過程及解決過程。

1 短信業(yè)務(wù)故障描述

對于短信業(yè)務(wù)存在如下問題：

(1)用戶發(fā)送短信不成功，導(dǎo)致短信重發(fā)多次。

(2)用戶發(fā)送短信后，出現(xiàn)重復(fù)計費問題。

(3)用戶發(fā)送一條短信，接收方卻收到多次。

(4)短信發(fā)送接收時延太大，導(dǎo)致用戶抱怨。

本文對吉林移動在除夕當(dāng)晚20:00左右，交換機網(wǎng)管系統(tǒng)發(fā)現(xiàn)部分用戶發(fā)送一條短信，但提交多條情況，存在對用戶發(fā)送短信重復(fù)計費故障現(xiàn)象進行分析。由于短信業(yè)務(wù)流量急增，引發(fā)阿爾卡特HSTP2局和LSTP2局之間信令鏈路負荷過高，導(dǎo)致信令鏈路翻轉(zhuǎn)故障，已嚴重影響網(wǎng)絡(luò)運營質(zhì)量。由于信令翻轉(zhuǎn)過程中，丟失部分信令，導(dǎo)致短信重發(fā)現(xiàn)象。以下詳細說明通過交換機網(wǎng)管和信令監(jiān)測系統(tǒng)對該故障的跟蹤分析過程。

吉林移動的信令監(jiān)測系統(tǒng)由北京中創(chuàng)信測科技股份有限公司多年集中監(jiān)測建設(shè)并維護，本文詳細說明信令監(jiān)測系統(tǒng)的數(shù)據(jù)分析判斷操作應(yīng)用過程。

2 短信重發(fā)問題分析

2.1 短信中心局數(shù)據(jù)改進

針對短信中心下發(fā)短信機制，完善中興短信中心MSCID數(shù)據(jù)并核對業(yè)務(wù)負荷分擔(dān)機制；同時更改諾西短信中心短信下發(fā)機制：由號段作為發(fā)往LSTP局或HSTP局路由尋址的依據(jù)，改為號段結(jié)合MSCID做為下發(fā)消息路由尋址方式，此舉可有效解決短信大業(yè)務(wù)量情況下，HSTP局和LSTP局資源不足問題，同時協(xié)調(diào)諾西短信中心盡快完成HSU板(支持高速2M信令鏈路)的更換。目前已經(jīng)完成了中興短信中心的路由數(shù)據(jù)調(diào)整工作，已經(jīng)將諾西短信中心1的消息下發(fā)路由數(shù)據(jù)按照省內(nèi)送LSTP局，省際送HSTP局的原則設(shè)置完畢；在2月5日通過信令測試儀表跟蹤的方式對中興短信中心和諾西短信中心的路由數(shù)據(jù)進行驗證工作，目前路由數(shù)據(jù)已經(jīng)完全正確。諾西短信中心2將在硬件到貨后進行路由數(shù)據(jù)的設(shè)置工作并繼續(xù)進行掛表驗證工作。

2.2 對于短信一條多發(fā)情況分析

(1)移動用戶始發(fā)短消息流程(MO)

從圖1短消息MO流程可以看出短消息發(fā)送到短信中心后，短信中心需回送短消息證實消息。同時在A接口存在對應(yīng)發(fā)送短信過程。

圖1 移動用戶始發(fā)短消息流程

(2)短信重發(fā)MAP短信業(yè)務(wù)記錄分析

在吉林移動網(wǎng)站上隨機找到一組存在一條多發(fā)短信的記錄，同時重發(fā)短信按多條計費的情況(見圖2)。

圖2 短信重發(fā)MAP短信業(yè)務(wù)記錄分析

在中創(chuàng)信令集中監(jiān)測系統(tǒng)中，通過“MAP短信記錄”查詢MSC/SS端局到LSTP局的MAP信令中找到關(guān)聯(lián)的3條短信消息記錄，短信記錄中發(fā)送號碼為：1375630XXXX，短信接收號碼為：1381162XXXX

從圖3短信消息記錄列表中可以看出20:28和20:31這兩條消息是“未完”狀態(tài)，20:33分則是“完成”狀態(tài)。分別關(guān)聯(lián)提取“未完”狀態(tài)和“完成”狀態(tài)的信令過程消息，并進行對比。

圖3 短消息記錄列表

●圖4為“未完”狀態(tài)的信令流程，從信令中可以看出信令消息送往GT為8613800431500的短信中心，但此短信中心未回復(fù)證實消息。因此只有TC_BEGIN事務(wù)處理開始的記錄，沒有返回TC_END事務(wù)處理結(jié)束的證實消息。所以記錄顯示“未完”的過程結(jié)果。

圖4 “未完”狀態(tài)的信令流程

●圖5為“完成”狀態(tài)的信令流程，從信令過程時序圖中可以看出信令消息同樣送往GT為8613800431500的短信中心，但此次收到了短信回復(fù)證實消息，該消息包含在TC_END中，因此是完整的TC事務(wù)處理過程。

圖5 “完成”狀態(tài)的信令流程

由于短信中心未回復(fù)證實消息，最終導(dǎo)致MSC/SS端局等待短消息中心回復(fù)定時器超時，向手機下發(fā)失敗，部分手機在發(fā)送失敗后會重新發(fā)送該條短信，直到發(fā)送成功。

(3)短信重發(fā)A接口短信記錄分析

●短信中心未回復(fù)證實消息的A口短信發(fā)送信令流程(見圖6)

圖6 短信中心未回復(fù)證實消息的A口短信發(fā)送信令流程

圖6中“RP_ERROR”即說明RP_DATA發(fā)送后沒有收到RP_ACK消息，說明短信發(fā)送失敗，失敗原因是“網(wǎng)絡(luò)故障”。因此通過A接口也能定位用戶發(fā)送失敗的原因，但需要結(jié)合核心網(wǎng)MAP短信業(yè)務(wù)記錄，可準確定位是MSC/SS端局沒有發(fā)送短信，還是發(fā)送后沒有收到SMC的證實消息。因此對于監(jiān)測全面的端局，通過信令監(jiān)測系統(tǒng)數(shù)據(jù)記錄分析，可以快速定位故障發(fā)生的根源。

●短信中心回復(fù)證實消息的A口信令流程(見圖7)

圖7 短信中心回復(fù)證實消息的A口信令流程

以上是短信成功發(fā)送的過程，包含CP_DATA和CP_ACK各兩條，分別是CP_DATA中包含RP_DATA和RP_ACK消息，與MAP過程相似。CP為Control Protocol控制協(xié)議層，即A接口傳輸控制，如果出現(xiàn)CP_ERROR則說明在A接口傳輸控制存在問題，例如無線接口故障或無線接口消息故障。

通過A接口記錄與MAP記錄的結(jié)合分析，可以定位短信發(fā)送失敗是由于無線接口故障還是核心網(wǎng)傳輸故障。通過失敗原因的分析，結(jié)合用戶投訴，可以很快排除網(wǎng)絡(luò)運行故障。

3 初步結(jié)論：

(1)經(jīng)過理論分析，由于諾西短信中心采用號段作為發(fā)往LSTP局或HSTP局路由尋址的依據(jù)，而不是采用號段和MISCID結(jié)合的方式，致使短信中心給主叫用戶下發(fā)的應(yīng)答消息送到了HSTP2局—LSTP2局—端局，由于當(dāng)晚HSTP2局到LSTP2局從16:48到23:59信令鏈路一直發(fā)生翻轉(zhuǎn)，導(dǎo)致部分應(yīng)答消息丟失，端局未收到短信證實消息超時失敗，導(dǎo)致部分手機重新發(fā)送短信，造成短信一條多發(fā)情況，重復(fù)計費。

(2)交換與數(shù)據(jù)共同分析了諾西短信中心設(shè)備局數(shù)據(jù)結(jié)構(gòu)，認為現(xiàn)有路由數(shù)據(jù)結(jié)構(gòu)可以優(yōu)化，原則是省內(nèi)數(shù)據(jù)及MSCID指向LSTP，省際大匹配數(shù)據(jù)指向HSTP，所有數(shù)據(jù)指向信令匯接局HSTP/LSTP需要按照負荷分擔(dān)方式處理，數(shù)據(jù)支援室下一步會制定計劃整改。

4 應(yīng)用維護總結(jié)

對于網(wǎng)絡(luò)故障可通過交換機網(wǎng)管系統(tǒng)和信令監(jiān)測系統(tǒng)綜合分析；信令監(jiān)測系統(tǒng)可分析網(wǎng)絡(luò)故障給用戶帶來的直接影響，可分析到最直接的信令消息記錄；特別是在網(wǎng)絡(luò)傳輸備份的前提下，往往導(dǎo)致部分記錄出現(xiàn)失敗部分成功，這更要求我們對于網(wǎng)絡(luò)故障及時發(fā)現(xiàn)和排查，避免造成全局癱瘓的重大故障。

作者：姜萍 邵四清 來源：電信網(wǎng)技術(shù)

我推薦大家讀

輕松參與

VS

表達立場

這是垃圾文章