3G尋呼量較少網(wǎng)絡(luò)下尋呼成功率指標(biāo)較低問題分析專題（精編版）

1、3g尋呼量較少網(wǎng)絡(luò)下尋呼成功率指標(biāo)較低問題分析專題擬制王雨坤、金一、王育偉日期2011-3-11評審人批準(zhǔn)簽發(fā)日期日期日期目錄一、背景介紹 .3二、故障現(xiàn)象描述 .3三、原因分析及定位 .4四、處理方法介紹 .12五、經(jīng)驗總結(jié) .122 / 122專業(yè)進取協(xié)作共享一、背景介紹隨著全省 3g 網(wǎng)絡(luò)建設(shè)步伐的加快，各地3g 網(wǎng)絡(luò)覆蓋范圍快速增加，緊跟建設(shè)步伐的網(wǎng)絡(luò)優(yōu)化活動也大規(guī)模開展。鹽城公司在本地的3g 網(wǎng)絡(luò)優(yōu)化過程中遇到了一些端局下3g 尋呼成功率較低問題。例如在njgs24 等 2/3g 融合端局， 在 3g 無線覆蓋水平明顯較2g 存在較大差距的情況下，從端局話務(wù)統(tǒng)計上看， 3g 網(wǎng)絡(luò)的尋

2、呼成功率明顯偏低，本文就此問題進行了分析。本專題主要包含如下內(nèi)容：現(xiàn)象描述原因分析與定位處理方法介紹 經(jīng)驗總結(jié)二、故障現(xiàn)象描述對象實例開始時間iu 口第一次發(fā)尋呼次數(shù)iu 口第一次尋呼響應(yīng)次數(shù)iu 接口重復(fù)發(fā)尋呼次數(shù)iu 口重復(fù)尋呼響應(yīng)次數(shù)一次尋呼成功率3g 尋呼成功率3 / 123端局接入 rnc 數(shù)據(jù)增加后，近日交換側(cè)指標(biāo)監(jiān)控發(fā)現(xiàn)，建湖 njgs24 下一個 rnc 下掛的 5 個 3g lac 的尋呼成功率較低，最低的甚至為 0。相關(guān)的統(tǒng)計指標(biāo)如下。46000d1552011-3-8 18:9.23%19.23%46000d1552011-3-8 19:0080682800.00%0.0

3、0%46000d1552011-3-8 20:.88%5.88%46000d1552011-3-8 21:.70%3.70%46000d1562011-3-8 18:3185.03%85.63%46000d1562011-3-8 19:083.62%83.62%46000d1562011-3-8 20:0188.43%89.26%46000d1562011-3-8 21:67.02%70.21%46000d1572011-3-8 18:.70%8.70%46000d1572011-3-8 19:0070682800.00%0.00%46000d1572011-3-8 20:.00%0.00%4

4、6000d1572011-3-8 21:.00%0.00%46000d1582011-3-8 18:.45%3.45%46000d1582011-3-8 19:6.36%36.36%46000d1582011-3-8 20:5.38%15.38%46000d1582011-3-8 21:3.33%13.33%46000d1592011-3-8 18:.70%8.70%46000d1592011-3-8 19:0070682800.00%0.00%46000d1592011-3-8 20:.00%0.00%46000d1592011-3-8 21:.70%3.70%表 13 月 8 日晚間尋呼統(tǒng)

5、計表從上表中，我們可以得出一個規(guī)律：1、iu 口的第一次尋呼次數(shù)低。 5 個 lac 中只有 1 個覆蓋縣城的 lac 的一次尋呼次數(shù)達到 100 次以上，其他鄉(xiāng)鎮(zhèn)的 lac 一次尋呼次數(shù)都在 30 次一下， 甚至有的一個晚忙時只有 7 次。2、重復(fù)尋呼次數(shù)遠遠高于一次尋呼總次數(shù)。3、一次尋呼次數(shù)越多的 lac ，它的尋呼成功率越高。這 5 個 lac 中，次數(shù)較多的成功率越高， 次數(shù)越少成功率越低。例如 d156,3 個時段的成功率在 80 以上，其他 4 個 lac 最高的只有 36，最低的只有 0。下面是市區(qū)一個端局下的 3g lac 尋呼指標(biāo)統(tǒng)計：對象實例開始時間iu 口第一次發(fā)iu

6、口第一次響應(yīng)iu 接口重復(fù)發(fā)iu 口重復(fù)響應(yīng)一次尋呼成功率3g尋呼成功率46000d1542011-3-8 18:49113389.89%93.42%46000d1542011-3-8 19:8897492.68%96.00%46000d1542011-3-8 20:2518392.41%96.37%表 2尋呼較多的一個lac 的成功率統(tǒng)計從上表可以看出，市區(qū)的一個lac 下的尋呼次數(shù)在達到幾千次后，一次尋呼成功率的指標(biāo)明顯高于尋呼次數(shù)只有幾十次的鄉(xiāng)鎮(zhèn)覆蓋區(qū)的lac 。三、原因分析及定位分析指標(biāo)偏低可能出現(xiàn)的原因：核心網(wǎng)和無線側(cè)關(guān)于尋呼相關(guān)的軟參設(shè)置不合理； 實際尋呼次數(shù)與端局話統(tǒng)的數(shù)據(jù)有誤差

7、；無線環(huán)境特別惡劣，造成尋呼得不到用戶終端的響應(yīng)； 其他可能性，如核心網(wǎng)統(tǒng)計指標(biāo)點的定義問題等。4 / 124根據(jù)可能存在的原因，我們一一進行了核查與分析，具體如下：1、核心網(wǎng)和無線側(cè)尋呼參數(shù)設(shè)置核查圖 1尋呼策略5 / 125檢查端局的尋呼策略設(shè)置。結(jié)果顯示與2g網(wǎng)絡(luò)下的設(shè)置情況一致，語音業(yè)務(wù)和短信均采用3 次尋呼， 前兩次為本 lac尋呼， 第三次為全網(wǎng)尋呼。 尋呼時長分別為 6、6、4，采用 tmsi、imsi 、tmsi方式。交換側(cè)核心參數(shù)檢查無問題。圖 2周期性位置更新配置無線側(cè)反饋 rnc配置檢查也無問題：網(wǎng)元指令內(nèi)容lst fcmsgqthd查詢消息包隊列占用率流量控制門限lst

8、 tfrc查詢面向 rnc 的基本信道配置算法參數(shù)lst fccputhd查詢 cpu 占用率流量控制門限r(nóng)nc 級小區(qū)級lst tdpucfgdata查詢 dpu 配置數(shù)據(jù)lst tstatetimer查詢呼叫流程狀態(tài)保護定時器lst fcsw查詢流量控制開關(guān)lst tpch查詢尋呼信道lst tpich查詢尋呼指示信道表 3 rnc 配置查詢指令具體查詢結(jié)果可參考以下附件，重點部分已經(jīng)用黃色標(biāo)注。rnc尋呼相關(guān)軟參 .x ls2、實際尋呼次數(shù)與端局話統(tǒng)的數(shù)據(jù)是否有誤差在統(tǒng)計指標(biāo)異常低的情況下， 通常會對用戶感知造成較為明顯的影響，但是一直未收到用戶投訴。 因此判斷是否有可能是統(tǒng)計數(shù)據(jù)存在異

9、常？為了驗證具體的統(tǒng)計值是否有異常，我們在端局上定義了15 分鐘的統(tǒng)計報告，同時打開了端局 iu 口的信令跟蹤，現(xiàn)場安排人員配合測試。注：由于本局3g用戶數(shù)量較少， 所以打開了 iu 口進行 paging消息的跟蹤，如用戶量較大需要視實際情況決定是否進行相應(yīng)操作。我們在開始信令跟蹤前發(fā)現(xiàn)2g的全網(wǎng)尋呼對 3g的尋呼跟蹤有一定影響，便在開始跟蹤前關(guān)閉了全網(wǎng)尋呼。對象實例開始時間iu 口第一iu 口第一iu 接口重iu 口重復(fù)一次尋呼次發(fā)次響應(yīng)復(fù)發(fā)響應(yīng)成功率46000d1552011-3-9 16:30761085.71%46000d1562011-3-9 16:3039345287.18%460

10、00d1572011-3-9 16:3031274187.10%46000d1582011-3-9 16:301091090.00%46000d1592011-3-9 16:30431075.00%表 4 9日下午配合信令跟蹤統(tǒng)計尋呼次數(shù)通過信令跟蹤發(fā)現(xiàn)在15 分鐘內(nèi)，端局統(tǒng)計到的尋呼次數(shù)與信令消息中的數(shù)量相同，從而驗證了端局統(tǒng)計數(shù)據(jù)無異常。下面是信令跟蹤截圖：6 / 126圖 3 15 分鐘統(tǒng)計報告中相應(yīng)的尋呼信令3 、無線環(huán)境特別惡劣，造成尋呼得不到用戶終端的響應(yīng)尋呼成功率低的問題， 通常在核心網(wǎng)尋呼參數(shù)無異常的情況下， 無線環(huán)境是最重要的影響因素。 無線網(wǎng)優(yōu)人員首先檢查了該地區(qū)的無線網(wǎng)絡(luò)

11、覆蓋情況， 可以排除在無線覆蓋方面存在有嚴(yán)重影響尋呼成功率的因素。為了驗證網(wǎng)絡(luò)覆蓋情況，我們協(xié)調(diào)無線優(yōu)化廠家安排現(xiàn)場測試，并確保在各lac下均進行呼叫測試。結(jié)果顯示被叫接通率很高， 未出現(xiàn)被叫接通率低的情況，由此我們排除了無線環(huán)境特別惡劣造成尋呼得不到用戶終端響應(yīng)的可能性。4、其他可能性本地發(fā)現(xiàn)除了一個njgs24端局的 3g尋呼指標(biāo)較低外，本地的 10 個下掛 rnc 的端局中還有很多的端局有同樣的情況。但是覆蓋市區(qū)的3 個端局的 3g尋呼成功率明顯高于其他覆蓋鄉(xiāng)鎮(zhèn)的端局。本地 10 套端局， 4 套采用的 atm對接， 6 套采用 ip 方式接入核心網(wǎng)，均存在指標(biāo)較差的情況。是否是什么軟參

12、設(shè)置不一樣造成指標(biāo)出現(xiàn)如此大的差異呢？我們本地的所有端局進行了軟件比對，結(jié)果顯示一致。至此，我們的分析好像陷入了困境。但是，我們在查詢統(tǒng)計報告時發(fā)現(xiàn) 了一點問題。7 / 127次發(fā)次響應(yīng)發(fā)響應(yīng)呼次數(shù)46000d1552011-3-10 11:001000146000d1552011-3-10 11:152000246000d1562011-3-10 11:00343300146000d1562011-3-10 11:15403710246000d1572011-3-10 11:001000146000d1572011-3-10 11:152000246000d1582011-3-10 11:0

13、01000146000d1582011-3-10 11:154200246000d1592011-3-10 11:001000146000d1592011-3-10 11:1520002表 5統(tǒng)計表對象實例開始時間iu 口第一iu 口第一iu 口重復(fù)iu 口重復(fù)全網(wǎng)尋上表中可以看到， 在進行統(tǒng)計前我們已經(jīng)將本局的全網(wǎng)尋呼進行了關(guān)閉。但是在統(tǒng)計表中確發(fā)現(xiàn)了有全網(wǎng)尋呼次數(shù)。而且發(fā)現(xiàn)了這 5 個 lac的全網(wǎng)尋呼次數(shù)相同，業(yè)務(wù)量小的 d155/d157/d158/d159的一次尋呼次數(shù)相同， 且都等于全網(wǎng)尋呼次數(shù)。那么，否可以理解為：在 11：00 的這個時段， d155/d157/d158/d15

14、9 這 4 個 lac的真正一次尋呼次數(shù)應(yīng)該為0，統(tǒng)計到的一次尋呼次數(shù)應(yīng)該是全網(wǎng)尋 呼的次數(shù)。那么在已經(jīng)關(guān)閉了全網(wǎng)尋呼的情況下，為何又會產(chǎn)生全網(wǎng)尋呼呢？通過查詢資料，了解到華為端局交換機在“用戶數(shù)據(jù)修復(fù)”時會向全網(wǎng)發(fā)送paging。那么究竟在哪些情況下會出現(xiàn)“用戶數(shù)據(jù)修復(fù)”呢。主要內(nèi)容可概括為：在vlr 中沒有相關(guān)用戶數(shù)據(jù)，但是被叫歸屬hlr中存儲的 vlrnb指向了本 vlr，并向本vlr來請求漫游號碼，這時vlr會向本端局下的所有位置區(qū)發(fā)paging消息，以便獲取被叫號碼的位置信息后進行其他后續(xù)流程。為了驗證我們的分析， 我們分析了表 5 同時段的 iu 口 paging消息，在 15 分

15、鐘內(nèi)確實發(fā)現(xiàn)了1 次全網(wǎng)尋呼消息：8 / 128圖 4用戶數(shù)據(jù)恢復(fù)過程中下發(fā)的全網(wǎng)paging消息其 中 只 包 含 了 被 叫 的imsi號 碼 ， 給 出 的pagingcause為:terminating-conversational-call。正常情 況下的paging消息 應(yīng)該會 包含 有被叫的imsi,tmsi ， lai和pagingcause:terminating-low-priority-signalling。具體信令打開如下：圖 5 正常 paging消息解析9 / 129那么究竟在什么場景下會出現(xiàn)用戶數(shù)據(jù)丟失，還需要vlr下發(fā) paging消息進行用戶數(shù)據(jù)修復(fù)的呢？我們

16、模擬了一種情況，就是 vlr在刪除用戶數(shù)據(jù)后， 相關(guān)的 purge消息未能正常發(fā)送到hlr，導(dǎo)致 hlr中登記信息不準(zhǔn)確。我們在端局上進行了驗證，首先在端局上使用del ms命令刪除 vlr中的被叫用戶信息，注意 pruge選項需要選擇“否” ，也就是不通知 hlr。圖 6在端局中刪除用戶數(shù)據(jù)具體指令為： delms: unt=msisdnf, lag=no此; 時進行呼叫該號碼，我們在信令消息中獲取到了相關(guān)信令，驗證了我們的分析是正確的。10 / 1210圖 7呼叫過程中主叫的setup消息圖 8呼叫過程中的paging消息正如前面跟蹤到的用于用戶數(shù)據(jù)修復(fù)paging消息內(nèi)容，在 vlr清除

17、用戶數(shù)據(jù)，并且不通知hlr的情況下，用戶再次被叫時，原被叫端局就會發(fā)全網(wǎng)尋呼。11 / 1211四、處理方法介紹鑒于初步分析的結(jié)果，我們判斷此問題應(yīng)該是在所有華為端局下，3g 覆蓋用戶較少的端局上普遍存在的現(xiàn)象。我們對其他地市的3g尋呼指標(biāo)也進行了比較：發(fā)響應(yīng)數(shù)46000d1642011-3-10 3:003835767046000d1652011-3-10 3:0021697046000d1662011-3-10 3:0010697046000d1672011-3-10 3:0010697046000d1682011-3-10 3:00106970對象實例開始時間iu 口第一次iu 口第一次iu 口重復(fù)發(fā)全網(wǎng)尋呼次表 6其他地市端局下3g 尋呼指標(biāo)由表 6 可以看出，在 3 點鐘這個時段確實是出現(xiàn)了一次由于用戶數(shù)據(jù)修復(fù)而發(fā)起的全網(wǎng)尋呼。如果排除這次尋呼，實際的3g尋呼指標(biāo)是正常的。至此，對于 3g局下尋呼成功率低的問題我們找出了真正的原因。就是在用戶量較少的情況下，由于“用戶數(shù)據(jù)修復(fù)”發(fā)起的全網(wǎng)尋呼次數(shù)，