（中國移動通信集團設(shè)計院有限公司陜西分公司，陜西 西安 710077）

1.測試分析工具

測試工具：Pilot Walktour軟件＋多普達PDA

分析工具：Pilot Navigator

2.測試方法

采用手機相互撥打的方式，手機撥叫、掛機采用手動方式，接聽采用自動方式。手機與測試儀表相連；定點CQT測試人員在每個測試點的不同位置做主叫、被叫各10次，每次通話時長45秒（人工控制），呼叫間隔15秒以上；出現(xiàn)未接通情況，應(yīng)間隔15秒以上進行下一次試呼；如出現(xiàn)掉話，則在掉話發(fā)生15秒后進行下一次試呼。

3.問題說明

在用鼎立后臺分析軟件Navigator對某市物業(yè)點進行移動2G語音CQT進行分析時，41個物業(yè)點共試呼897次，接通885次。其中有8個物業(yè)點的11次未接通出現(xiàn)相同原因：Event Details顯示Outgoing Blocked Call，Message顯示UL Disconnect，Message Details Browser的cause value顯示為Normal call clearing。如圖1所示：

圖1

該問題特點為：

（1）問題較普遍

物業(yè)點占未接通物業(yè)點的88.9%；未接通次數(shù)占總未接通次數(shù)的91.7%。

（2）信令顯示特殊

一般Disconnect信令為系統(tǒng)下發(fā)信令，此類問題卻顯示為上發(fā)信令。

（3）時間特殊

所有Disconnect問題均發(fā)生在Alerting之后的5-10秒內(nèi)。

4.信令分析

由表1可知：在主叫發(fā)起Channel Request（信道請求）和CM Service Request（CM業(yè)務(wù)請求）后，網(wǎng)絡(luò)會向主叫移動臺指配鏈路。一旦鏈路指配成功，網(wǎng)絡(luò)會指示被叫手機啟動告警（Alerting），然后指示連接被接受（Connect）。

而本問題中，在Alerting之后，出現(xiàn)了Disconnect，指示連接失敗。就該問題，筆者列舉出幾種可能原因，并逐一分析。

5.問題分析

5.1 測試軟硬件問題

首先，筆者懷疑是測試軟硬件出現(xiàn)不穩(wěn)定，導(dǎo)致測試中斷。

對比分析8個物業(yè)點的信令發(fā)現(xiàn)：Dis-connect之前Pilot Navigator顯示信令正常，未出現(xiàn)丟失信令等問題。

據(jù)測試人員反映：手機、電腦及其他配件在問題發(fā)生時未有死機或電池不足等現(xiàn)象。

由此可排除測試軟硬件問題。

圖2

表1 移動主叫的正常通話時主要信令流程

5.2 網(wǎng)絡(luò)問題

很多連接失敗是由于弱覆蓋、切換不成功導(dǎo)致，本問題出現(xiàn)的是否為連接過程中突然出現(xiàn)弱覆蓋，導(dǎo)致主叫無法繼續(xù)連接，或者突然進入切換區(qū)，出現(xiàn)切換失敗而引起的呢？

（1）覆蓋分析

圖2為問題物業(yè)點GSM Radio窗口視圖。

其中：

RxLevFULL：描述測量數(shù)據(jù)中的無線場強變化趨勢。

RxQualFULL：描述測量數(shù)據(jù)中的無線信道塊誤碼率變化趨勢。

RxLevSUB：描述測量數(shù)據(jù)在開通（DTX＝1）間歇發(fā)射條件下場強變化。

RxQualSUB：描述測量數(shù)據(jù)在開通（DTX＝1）間歇發(fā)射條件下塊誤碼

該物業(yè)點RxLevSUB為-65dBm，說明該物業(yè)點覆蓋較好。

（2）切換分析

圖3為Alerting時主叫小區(qū)信息窗口視圖。

圖3

圖4為Disconnect前主叫小區(qū)信息窗口視圖。

圖4

對比分析可得：連接失敗前主叫當前服務(wù)小區(qū)BCCH電平值均遠大于-90dBm，并且駐留在統(tǒng)一小區(qū)中，沒有切換發(fā)生。分析事件，Alerting到Disconnect期間，也沒有Cell reselect或者Handover出現(xiàn)。

另外，測試人員反映測試物業(yè)點周圍沒有強電、強磁、強輻射等干擾因素，屬于正常覆蓋區(qū)。

5.3 被叫問題

首先，被叫與主叫處于同一網(wǎng)絡(luò)同一無線環(huán)境，可排除被叫網(wǎng)絡(luò)問題。

信令顯示Alerting，說明主叫到被叫的鏈路沒有問題，從而也證明了網(wǎng)絡(luò)側(cè)正常。

我們對被叫可能存在的以下問題進行分析：

（1）被叫人為掛斷

若為被叫人為掛斷，則應(yīng)出現(xiàn)Call End事件，而不是Blocked Call事件。

（2）轉(zhuǎn)秘書臺或呼叫轉(zhuǎn)移

如果被叫轉(zhuǎn)秘書臺或呼叫轉(zhuǎn)移，會不會出現(xiàn)5-10秒振鈴后突然中斷呢？由于沒有被叫信令數(shù)據(jù)，筆者用手機進行了撥打測試，發(fā)現(xiàn)轉(zhuǎn)秘書臺振鈴時間均在20秒以上，而撥打呼叫轉(zhuǎn)移設(shè)置的手機也沒有突然中斷的現(xiàn)象。

（3）被叫接收短信或彩信

經(jīng)撥打測試，被叫接收短信或彩信過程中，也沒有出現(xiàn)5-10秒內(nèi)突然中斷的現(xiàn)象。

圖5

圖6

5.4 主叫問題

（1）主叫人為掛斷

主叫在振鈴5-10秒鐘主動掛斷，則應(yīng)出現(xiàn)Call End事件，而不是Blocked Call事件。

（2）主叫接收短信或彩信業(yè)務(wù)

a.短信業(yè)務(wù)

我們知道：SDCCH信道是負責短信業(yè)務(wù)和呼叫建立的。如果在起呼階段，主叫接收到短信，此時SDCCH被短信業(yè)務(wù)占用，也會導(dǎo)致連接失敗。

圖5為MS接收短信時的部分信令流程。

在MSC發(fā)送Paging CMD，尋呼MS后，MS請求SDCCH信道。此后，MS占用SDCCH接收短信業(yè)務(wù)。

圖6為主叫話音業(yè)務(wù)信令流程。

主叫從CM Service Request起，到Assignment Command，一直占用SDCCH信道，隨后釋放，并在Alerting和Connect時再次占用。

該問題中，主叫Alerting后顯示Disconnect，是否與短消息業(yè)務(wù)發(fā)生信道沖突呢？我們注意到：Disconnect也在SDCCH上傳送，這就說明，該問題發(fā)生時，SDHCCH并沒有被占用，所以，不會是與短消息沖突所致。并且，經(jīng)查閱相關(guān)資料發(fā)現(xiàn)：主叫在與短消息業(yè)務(wù)沖突時，由于SDCCH被占用，主叫接收不到下行響應(yīng)，通話狀態(tài)會由起呼直接轉(zhuǎn)為空閑模式（IDLE）。

b.彩信業(yè)務(wù)

圖7為彩信業(yè)務(wù)信令流程。

分析彩信業(yè)務(wù)信令發(fā)現(xiàn)：彩信業(yè)務(wù)占用的是PACCH，而不是SDCCH，不會引起本問題的發(fā)生。

（3）主叫呼叫設(shè)置

經(jīng)過以上各種分析，筆者認為：主叫測試手機的設(shè)置可能是本次問題出現(xiàn)的原因。經(jīng)查看測試手機發(fā)現(xiàn)：主叫手機的呼叫連接時長設(shè)置為15秒。為確定該分析，筆者做了以下測試：

a.連接時長設(shè)置為15秒，被叫不接聽

圖8為測試結(jié)果分析圖。

和出現(xiàn)問題時的測試結(jié)果一致。

b.連接時長設(shè)置為45秒，被叫不接聽

圖9為測試結(jié)果分析圖。

和出現(xiàn)問題時的測試結(jié)果一致，只是Alerting到Disconnect時間變?yōu)?8秒。

圖7

圖8

圖9

6.分析結(jié)論及解決方案

主叫手機的呼叫連接時長設(shè)置為15秒，除去信道請求、分配指令、CM業(yè)務(wù)請求時間，從Alerting到Disconnect大概為5-10秒（視網(wǎng)絡(luò)環(huán)境而定），這與從Pilot Navigator看到的信令時間相吻合。該問題的原因就是主叫手機的呼叫連接時長設(shè)置為15秒，被叫在15秒內(nèi)未接聽，導(dǎo)致主叫主動斷開連接，從而出現(xiàn)了Blocked Call。我們在連接時長設(shè)置為45秒的信令中驗證了這一結(jié)論。

問題分析后，筆者及時通知測試人員修改主叫手機連接時長設(shè)置為45秒，并在以后的測試中分析信令，發(fā)現(xiàn)該問題不再體現(xiàn)，確保了測試順利進行。

測試工具是網(wǎng)優(yōu)分析的基礎(chǔ)，在測試過程中，保證測試工具按照測試規(guī)范良好運行至關(guān)重要。同時，專業(yè)的知識儲備和豐富的分析經(jīng)驗是確保網(wǎng)優(yōu)分析質(zhì)量的關(guān)鍵因素。每一個問題都會有一種原因，也會有一套解決方案。我們只有真正掌握這門學(xué)問，才能在應(yīng)對問題時，真正立于不敗之地。