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

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

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

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

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

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

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

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

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

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

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

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

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

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