DT呼叫失敗原因分析

第15頁共15頁DT測試中呼叫建立失敗原因分析目錄TOC\o"1-2"\h\z概述 21.道路測試中成功的呼叫建立消息歷程 21.1手機(jī)做主叫的消息歷程 31.2手機(jī)做被叫的消息歷程 41.3被叫用戶沒有接通的消息歷程 51.4被叫用戶忙的消息歷程 61.5被叫用戶已關(guān)機(jī)或未應(yīng)答的消息歷程 72.道路測試中呼叫建立失敗的消息歷程 82.1SD擁塞的消息歷程 82.2TCH擁塞的消息歷程 92.3下行質(zhì)量差造成TCH接入失敗的消息歷程 102.4SDCCH掉話的消息歷程 112.5無效的呼叫 123.道路測試中呼叫建立失敗的主要原因 124．處理呼叫建立成功率低的流程圖 14結(jié)束語 15概述呼叫建立分析是移動通信網(wǎng)絡(luò)優(yōu)化的范疇之一。這里我們主要分析道路測試中測試系統(tǒng)采集的無線接口消息。對于不同的測試系統(tǒng)，其無線消息采集處理上有著些許的差異，但總體上都依據(jù)GSM規(guī)范制定。下面通過針對測試系統(tǒng)收集處理的信令消息分析，進(jìn)而查找呼叫建立失敗的原因。從道路測試的角度分析呼叫建立的過程，我們不僅要關(guān)注統(tǒng)計(jì)意義上的TCH分配過程；更重要還要從用戶感知上考慮，從RACH接入、SDCCH分配、TCH分配一直到用戶真正開始通話為止。從而完整的分析用戶呼叫直至通話的全過程。1.道路測試中成功的呼叫建立消息歷程道路測試中正常的呼叫建立過程，通過信令消息:AssignmentComplete體現(xiàn)了TCH信道的正常分配。而對于廣義上的呼叫建立，即有戶所感知而言，信令消息則對應(yīng)為：ConnectAcknowledge體現(xiàn)了用戶通話的開始。1.1手機(jī)做主叫的消息歷程TEMS測試系統(tǒng)1.2手機(jī)做被叫的消息歷程TEMS測試系統(tǒng)在成功的呼叫建立過程中，有一些呼叫對于用戶而言不能發(fā)生通話。我們以移動臺發(fā)起呼叫為例，在被叫用戶（固定網(wǎng)）不能接通、被叫移動用戶未開機(jī)、被叫用戶沒有接聽、被叫用戶正在通話等許多情況下，都不會發(fā)生用戶間的通話。但是，對于無線網(wǎng)絡(luò)而言，他們都屬于正常的呼叫信令接續(xù)。1.3被叫用戶沒有接通的消息歷程從上面的層3消息中，我們可以看到TCH信道的正常分配。之后，MSC沒有向移動臺發(fā)送Connect消息，而是發(fā)送了Disconnect消息。分析Disconnect消息中的CauseValue可以大致得出原因：MSC未能建立對外的連接，有可能是由于沒有可用的資源。1.4被叫用戶忙的消息歷程從上面的層3消息中，我們可以看到TCH信道的正常分配。之后，MSC沒有向移動臺發(fā)送Connect消息，而是發(fā)送了Disconnect消息。分析Disconnect消息中的CauseValue可以得出明確的原因：被叫用戶忙。1.5被叫用戶已關(guān)機(jī)或未應(yīng)答的消息歷程從上面的層3消息中，我們可以看到TCH信道的正常分配。之后，MSC沒有向移動臺發(fā)送Connect消息，而是發(fā)送了Disconnect消息。分析Disconnect消息中的CauseValue可以得出明確的原因：被叫用戶沒有應(yīng)答。2.道路測試中呼叫建立失敗的消息歷程對于道路測試中的呼叫建立失敗，不僅是針對TCH分配過程中的失敗，還涵蓋了包括RACH接入、SDCCH分配過程以及無效的呼叫等多種情況。而對于廣義上的呼叫建立，還包括了在TCH分配完成后，在移動臺發(fā)送ConnectAcknowledge消息之前，所發(fā)生的TCH掉話。下面我們從網(wǎng)絡(luò)中可能出現(xiàn)的一些引發(fā)呼叫建立失敗的原因入手，分析移動臺處于各種情況下，其信令消息的接續(xù)歷程。2.1SD擁塞的消息歷程從上面的層3消息中，我們可以看到SDCCH擁塞時，系統(tǒng)會向移動臺發(fā)送ImmediateAssignmentReject消息。比較Layer3消息中的Randomreference號碼，從而可以確定多個信道請求消息中，那一條由于SDCCH擁塞而被拒絕。2.2TCH擁塞的消息歷程從上面的層3消息中，我們可以看到TCH擁塞時，下行發(fā)出CallProceeding消息后，當(dāng)沒有TCH可用信道時，手機(jī)在排隊(duì)打開的情況下，在SDCCH上排隊(duì)等待，直到排隊(duì)時長終止。下行即發(fā)出ChannelRelease消息。2.3下行質(zhì)量差造成TCH接入失敗的消息歷程從上面的層3消息中，我們可以看到當(dāng)TCH擁塞和TCH分配失敗時，經(jīng)常可以看到移動臺回到SDCCH上發(fā)送AssignmentFailure消息，其描述多為：沒有無線資源、無線接口失敗以及協(xié)議錯誤。對于無線接口失敗，導(dǎo)致其發(fā)生的原因有多種。其中多數(shù)是由于硬件故障、干擾、信號阻擋等因素造成的。當(dāng)處理這類問題時，需要根據(jù)測試現(xiàn)場的周邊環(huán)境；小區(qū)相關(guān)性能統(tǒng)計(jì)；結(jié)合測試文件綜合加以考慮。2.4SDCCH掉話的消息歷程RF_LOSSES_SD是在SDCCH上的射頻掉話的數(shù)目。引起原因可能是覆蓋問題；同、鄰頻干擾問題；硬件問題等等，需要進(jìn)行實(shí)際的測試后，根據(jù)具體情況進(jìn)行分析。從呼叫建立的信令消息歷程上分析，我們可將SDCCH掉話分為:AssignmentCommand消息之前的SD射頻丟失和AssignmentCommand消息之后，TCH分配失敗后移動臺不能回到原SDCCH信道的掉話。從上面的層3消息中，我們可以看到AssignmentCommand消息之前的SD射頻丟失。2.5無效的呼叫在測試過程中，常能碰到一些由于人為因素造成的呼叫建立失敗。在這里我們將其統(tǒng)一歸為無效呼叫。下面列舉一些常見的現(xiàn)象：移動臺呼叫建立過程中的出現(xiàn)突然斷電。移動臺關(guān)機(jī)（IMSIdetach）移動臺呼叫建立過程中，在Setup消息之前，由于移動臺掛機(jī)等原因?qū)е乱苿优_發(fā)送CMServiceAbort消息，取消呼叫。移動臺道路測試過程中，由于人為設(shè)定撥叫等待時長，造成呼叫建立的信令接續(xù)不能完成。其中包括幾種情況：由于人為設(shè)定呼叫接續(xù)等待時長短于系統(tǒng)正常的呼叫建立時長，造成呼叫建立的信令接續(xù)不能完成。在結(jié)束一次通話后，由于跨越LAC區(qū)導(dǎo)致移動臺發(fā)起位置更新。在位置更新過程未完成時，人為設(shè)定撥叫等待時長到時，需進(jìn)行下一次呼叫，則會出現(xiàn)無法發(fā)起呼叫或被叫不再服務(wù)區(qū)的現(xiàn)象。由于LAC區(qū)規(guī)劃不合理，LAC交界處基站覆蓋調(diào)整不當(dāng)時，會導(dǎo)致移動臺在結(jié)束一次通話后，接連跨越LAC區(qū)，連續(xù)進(jìn)行位置更新。從而使人為設(shè)定撥叫等待時長超時，出現(xiàn)無法發(fā)起呼叫或被叫不再服務(wù)區(qū)的現(xiàn)象。測試設(shè)備軟件原因。某些測試系統(tǒng)，在結(jié)束一次通話后，移動臺進(jìn)行小區(qū)重選時，有時會出現(xiàn)短暫的脫網(wǎng)現(xiàn)象。從而導(dǎo)致人為設(shè)定撥叫等待時長超時，出現(xiàn)無法發(fā)起呼叫或被叫不在服務(wù)區(qū)的現(xiàn)象。3.道路測試中呼叫建立失敗的主要原因當(dāng)呼叫建立失敗時，基站通常送DISCONNECT消息到移動臺，DISCONNECT消息簡要的指示出呼叫建立失敗的不同原因。下面就是在道路測試期間經(jīng)常出現(xiàn)一些呼叫建立失敗的原因值詳細(xì)描述。CauseValue描述可能的原因CauseValue31“正常，未詳細(xì)說明”這原因通常報告一個正常的事件僅僅當(dāng)在正常的類別沒有另外的原因適用時。BSS（TCH擁塞）或MSC問題CauseValue34“沒有可用的電路/信道”(在AssignmentCommand前)這原因顯示有目前得不到適當(dāng)?shù)碾娐?隧道處理呼叫。TCH擁塞CauseValue34“沒有可用的電路/信道”(在AssignmentCommand后)這原因顯示有目前得不到適當(dāng)?shù)碾娐?隧道處理呼叫。MSC擁塞CauseValue41“暫時的失敗”(在AssignmentCommand前)這原因顯示網(wǎng)絡(luò)運(yùn)行異常,達(dá)到要求的情況不能持續(xù)一個長的時段，移動電臺可以很快地嘗試另一次的呼叫。BSS問題，尤其是硬件問題CauseValue41“暫時的失敗”(在AssignmentCommand后)這原因顯示網(wǎng)絡(luò)運(yùn)行異常,達(dá)到要求的情況不能持續(xù)一個長的時段，移動電臺可以很快地嘗試另一次的呼叫。MSC問題CauseValue42“交換設(shè)備擁塞”這原因顯示交換設(shè)備正處于高通信量的處理時期。MSC擁塞CauseValue44“請求電路/信道不可用”當(dāng)電路或信道請求的實(shí)體不能被另一邊接口提供時這原因被返還。BSS問題，尤其是CIC擁塞CauseValue111“協(xié)議錯誤，未詳細(xì)說明”這