A接口與Abis接口信令一致性比較

1、A接口與Abis接口信令一致性比較為了解OMC TYPE 110統(tǒng)計掉話次數(shù)的真實性，采集了某個BSC 一個小時的A接口信令，統(tǒng)計TCH的掉話次數(shù)，與110報告比較。前期準備工作和結(jié)果1. A接口統(tǒng)計的Clear Request消息數(shù)目與OMC TYPE 18報告所統(tǒng)計的Clear Request消息數(shù)目是一致的。2. A接口統(tǒng)計的TCH掉話次數(shù)比OMC TYPE 110所統(tǒng)計的掉話次數(shù)多超過10個百分點。3. 各Abis統(tǒng)計的掉話次數(shù)與OMC TYPE 110相應小區(qū)所統(tǒng)計的掉話次數(shù)基本相等。由上述3個結(jié)果可以推斷出：Abis與A接口在統(tǒng)計掉話次數(shù)上存在不一致的情況。即A接口統(tǒng)計的掉話次數(shù)要

2、比Abis統(tǒng)計的掉話次數(shù)多超過10個百分點。為了驗證上述推論的正確性，我們采集了某個BSCA接口信令以及該BSC下的所有小區(qū)的Abis信令，通過對比，希望發(fā)現(xiàn)兩者在統(tǒng)計TCH掉話上的不同之處。A接口與Abis接口信令一致性比較l 主要思路先來看看在A接口和Abis接口上是如何判斷TCH掉話的。由于系統(tǒng)掉話很少，為了簡化分析，我們只討論無線掉話和切換掉話，而不考慮系統(tǒng)掉話。1. A接口根據(jù)CMCC對話音信道掉話次數(shù)的定義，在A接口上統(tǒng)計無線掉話次數(shù)，應以ASSIGNMENT COMPLETE后發(fā)生的CLEAR REQUEST次數(shù)以及HANDOVER COMPLETE后發(fā)生的CLEAR REQUE

3、ST次數(shù)為準。而CLEAR REQUEST包含多個原因：原因Radio interface failureRadio interface message failureEquipment failureO&M interventionNo radio resource available其中，“No radio resource available”為TCH擁塞造成，故不計為掉話。所以，A接口統(tǒng)計掉話次數(shù)是除去“No radio resource available”的其它四種原因的CLEAR REQUEST次數(shù)總和。無線掉話和切換掉話的Cause為Radio interface fa

4、ilure和Radio interface message failure。2. Abis接口根據(jù)OMC對無線掉話（MC736）和切換掉話（MC621）計數(shù)器的定義，若有以下兩條信令在TCH上出現(xiàn)，計為掉話1. CONNECT FAILURE INDICATION: （Cause： radio link failure ）2. Error indication 導致掉話。通常的Cause為 T200 expired （N2001）times。所以，若在A接口上出現(xiàn)Clear Request（Cause為Radio interface failure或Radio interface messag

5、e failure），而在Abis上沒有出現(xiàn)CONNECT FAILURE INDICATION: （Cause： radio link failure ）或Error indication（造成掉話）的情況，則認為是Abis接口與A接口統(tǒng)計掉話存在差別的原因。l 分析結(jié)果共出現(xiàn)3種異常流程，占到總掉話次數(shù)的101. 通話結(jié)束后A口出現(xiàn)clear request手機在16：15：05，483時上發(fā)release complete消息，接著成功進行了一次BSC內(nèi)的切換。MSC沒有回應clear command，而在10秒后，手機主動拆鏈，BSC向MSC發(fā)送clear request消息。正常情況

6、下，在通話結(jié)束后，即MSC收到release complete消息后，應立即下發(fā)clear command拆鏈。目前這種情況主要原因是在通話結(jié)束后，MSC沒有主動拆鏈，造成由手機釋放鏈路，在A口上出現(xiàn)clear request 并記為掉話，而在abis口上，沒有出現(xiàn)掉話信令，故不記為掉話。這類情況占到總掉話次數(shù)的5。解決建議:MSC收到release complete后，且在沒有其他流程存在的前提下，盡快下發(fā)clear command拆鏈，防止由手機釋放鏈路造成在A口上出現(xiàn)clear request。2. 通話結(jié)束前，網(wǎng)絡下發(fā)短消息，A口出現(xiàn)clear request在13：15：32，950

7、時，網(wǎng)絡側(cè)下發(fā)cpdata消息，說明有短消息下發(fā)給手機，而手機始終沒有回應cpack消息。在13:15:35.368時，手機掛機，向網(wǎng)絡發(fā)送DISC消息，網(wǎng)絡回Release，在13：15：35.802手機發(fā)送Release Complete消息。由于MSC發(fā)現(xiàn)還有短消息的流程沒有結(jié)束，故處于等待手機上發(fā)cpack的狀態(tài)。等待的時長由一計時器控制。手機始終沒有回cpack消息，最后由手機釋放鏈路，在Abis上出現(xiàn)Release Indicator（SAPI0），時間為13：15：46.041。BSC在收到Release Indicator后向MSC發(fā)送Clear Request釋放與MSC的連

8、接，cause為radio interface failure，時間為13：15：46.069。這種情況主要由于在通話結(jié)束后，還存在短消息的流程，所以MSC沒有向BSC發(fā)送clear command拆鏈，而由無線側(cè)主動釋放鏈路，故在A口上出現(xiàn)clear request，記為掉話。這類情況占到總掉話次數(shù)的3。針對這種情況，有以下幾個疑問。¨ 由手機主動拆鏈是否符合規(guī)范¨ 網(wǎng)絡是否支持通話流程和短消息流程同時存在，并且在通話結(jié)束后仍能保留短消息流程。¨ 若在通話流程和短消息流程同時存在的情況下，手機不回cpack的原因針對第一個問題，查找了呼叫釋放的規(guī)范（call r

9、elease）發(fā)現(xiàn)存在這種情況，見 N0200。從上述信令流程可知，在網(wǎng)絡中存在這種呼叫釋放，它會在A接口出現(xiàn)Clear Request消息，被誤計為掉話，但它卻不是掉話。原因是通話結(jié)束后，即DISC，Release Complete后，由于MSC沒有向BSC發(fā)Clear Command，手機在等待超時后自行釋放鏈路，而并不是由于無線質(zhì)量惡化或切換導致掉話。所以OMC沒有把這種情況計為掉話。針對第二個問題，根據(jù)alcatel規(guī)范（詳見SMS point to point）網(wǎng)絡支持通話過程和短消息同時存在的情況，并且支持在通話結(jié)束后，仍保留信道用來傳送短消息的情況。那手機為什么不回cpack消息

10、？我們來看以下流程從信令上來看，網(wǎng)絡下發(fā)了cpdata，但手機沒有回cpack，而在Abis上也沒有無線環(huán)境惡化的信令存在。以下為包含測量報告的流程具體看一下測量報告中的內(nèi)容服務小區(qū)的上行接收電平為80dBm，上行質(zhì)量為0，下行接收電平為85dBm，下行質(zhì)量為0。無線環(huán)境正常。既然無線環(huán)境沒有任何問題，下發(fā)的短消息也應該被手機收到，而網(wǎng)絡也支持這種類型的短消息，手機不回cpack的原因只能是該種手機不支持這種類型的短消息。解決建議：這種情況主要由于某些手機不支持通話結(jié)束后的短消息，故不回應cpack，而MSC內(nèi)有相應的計時器來控制短消息的響應時間。對于cpdata為15秒。即若手機在15秒內(nèi)對

11、cpdata消息沒有應答，MSC會主動下發(fā)clear command進行拆鏈。由于手機在上發(fā)release complete后10秒鐘會主動拆鏈，所以MSC應在此之前下發(fā)clear command,才可以避免由手機來釋放鏈路。目前15秒鐘的設置可能過長。3. 通話和短消息流程都成功結(jié)束后，A口出現(xiàn)clear request這種情況主要由于在短消息流程結(jié)束后MSC沒有向BSC發(fā)送clear command拆鏈，而由手機主動釋放鏈路造成。這類情況占到總掉話次數(shù)的2。解決建議:在所有流程都結(jié)束的情況下MSC盡快下發(fā)clear command拆鏈，防止由手機釋放鏈路造成在A口上出現(xiàn)clear requ

12、est。l 西門子設備A口信令調(diào)查我們采集了西門子交換機，阿爾卡特BSS的A接口數(shù)據(jù)，也發(fā)現(xiàn)了類似的掉話流程從該流程可見：在09：20：38：621時手機上發(fā)assignment complete消息，成功占用了TCH，在09：21：03：300時，網(wǎng)絡在TCH信道上下發(fā)短消息，接著，手機掛機，網(wǎng)絡側(cè)在09：21：07:422時再次發(fā)送assignment request消息，分配信令信道，即接下去的短消息在信令信道上傳送，而阿爾卡特的信令流程為不分配信令信道，而直接在TCH上傳送短消息。由于手機沒有回cpack消息，在09：21：17.764時，BSS向MSC發(fā)送clear request消

13、息，拆除鏈路。這種情況占到總的TCH掉話次數(shù)的9。要點：¨ 在通話過程中，網(wǎng)絡下發(fā)短消息，alcatel設備與西門子設備的表現(xiàn)形式不同alcate設備通過保留已經(jīng)存在的TCH信道來傳送短消息，而西門子設備重新分配信令信道，使短消息在新分配的信令信道上傳送。¨ 在兩種設備下都出現(xiàn)了由于非常規(guī)短消息失敗造成的A接口掉話信令clear request（radio interface failure）。原因都是手機沒有回應cpack消息并超時后，造成的非正常拆鏈。不同的是，對于alcatel設備，clear request發(fā)生在TCH上，而對于西門子設備，發(fā)生在SDCCH上。¨ 對于西門子設備，雖然clear request發(fā)生在SDCCH上，但該消息與發(fā)生在TCH上的clear request完全一致，無法區(qū)分兩者。此外，在A口分配SDCCH的信令與分配TCH的信令相同，都為assignment request和assignment complete消息， 在assignment request