GSM信令疑難問題分析2004/12RNE疑難問題分析 主要內容切換問題分析切換成功率問題分析切換流程的特別案例高掉話案例分析高掉話小區案例一高掉話小區案例二BSC間切換流程MSCMSBTSservingBSCservingBTStargetMeasReportMeasResultHOAlarm&CandidateCellChannelActivationChannelActAck.HOCommandHOCommandHOAccessHODetectionSABMEstablishIndUAHandoverCompleteHandoverCompleteHOCompleteRFChannelReleaseRFCh.Rel.Ack.BSCtargetHORequired要求切出HORequest要求切入HORequestAck.HOCommandPhysInformation（SCCPConRequired）（SCCPConConf）.ClearCompleteSCCPReleasedSCCPRel.Cmp.切換成功率問題分析（一）

切換成功率問題分析案例：

從話務統計報告分析發現,某交換機下的所有BSC切換成功率明顯下降，詳細分析后發現，這些BSC的切入成功率很低，切出成功率正常；而與該交換機覆蓋區域相鄰的某些BSC切出成功率從94％下降到91％，切入成功率正常。 切出成功率低的BSC為BSC4-1（LAC為17313，屬于MSC4） 切入成功率低的BSC為BSC3-3（LAC為17329，屬于MSC3） 這兩個BSC的問題是否由同一個原因導致？分析思路切入成功率低的BSCA接口分析：

判斷切入到BSC3_3失敗的小區是否存在共性切換成功率問題分析（二）下表是對BSC3－3進行AGLEA處理后產生的切換分析（*.THO文件）切換成功率問題分析（三）從該表可見：BSC3_3的切出成功率正常（handoverrequired次數基本等于handovercommand次數）BSC3_3的切入準備正常（handoverrequest次數等于handoverrequestack次數）切入成功率非常低（handovercomplete次數遠小區handoverrequest次數）切入成功率低的小區都屬于BSC4_1疑問：BSC3_3對交換機的切入請求都能激活相應的信道，并給出正確的應答消息，為何切入成功率非常低?切出成功率低的BSCA接口分析：

判斷切換到哪些小區成功率低切換成功率問題分析（四）下表是對BSC4－1進行AGLEA處理后產生的切換分析（*.THO文件）切換成功率問題分析（五）從該表可見：BSC4_1的切入成功率正常（handoverrequest次數基本等于handoverrequest次數）交換機對BSC4_1發出的切出請求應答異常（handovercommand次數遠小于handoverrequired次數）當BSC4_1收到handovercommand以后，切出成功率非常高（handovercommand次數基本等于handoversuccess次數）切出成功率低的小區都屬于BSC3_3交換機對BSC4_1切出請求的應答率非常低，一旦交換機給出應答消息，切換成功率則非常高。因此可以判斷出該BSC正常，切出成功率低的問題應出在交換機或者切入BSC側。切換成功率問題分析（六）BSC4_1切出失敗的信令流程BSC4－1在切出時，一直收到交換機下發的handoverrequiredreject消息，很難完成切換。切換成功率問題分析（七）BSC3_3切入失敗的信令流程切換成功率問題分析（八）BSC3－3回應了horequestack，但MSC在180ms后，立即下發clearcommand消息拆鏈，原因為callcontrol。這是非常異常的情況。正常切入流程是BSC在分配完信道，即horequestack后，等待手機的接入，一般接入的時長為700－900ms。切換成功率問題分析（九）為了確認交換機的問題，進行了A口和E口的聯測。從信令流程可見：MSC4收到BSC3發出的Horequestack后，立即向MSC3發送abort消息，并向BSC4發Horeject消息，終止了切換流程。可見該切換問題主要集中在MSC。具體原因需要交換工程師的進一步分析。切換流程的特別案例（一）切換流程的特別案例

通常情況下，BSC內兩個小區之間發生切換，采用的是BSC內切換方式，即切換完成后，以handoverperformed方式通知MSC；而BSC間的兩個小區間發生切換，采用的是BSC間的切換方式，即以MSC為主控的方式。在實際A接口信令分析中，會發現有些BSC內的兩個小區之間發生切換，會采用BSC間的切換方式，是什么原因造成這種情況呢？

切換流程的特別案例（二）正常情況下的BSC間切換

切換流程的特別案例（三）BSC收到切換告警，需要進行BSC間的切換，向MSC發送HANDOVERREQUIRED消息，該消息中包含目標小區列表celllist1。目標小區列表中的小區數目，由

OMC－R參數N_PREFER_CELL決定。同時，T7和T_HO_REQ_LOST開始計數

由于某種原因（如沒有無線資源），MSC無法處理本次切換，故向BSC發HANDOVERREQUIREDREJECT消息，BSC把HANDOVERREQUIRED消息中的目標小區列表celllist1放入REJ_CELL_LIST中。

同時，計數器T_HO_REQ_LOST停止計數，而T7繼續運行

BSC又檢測到需要進行BSC間的切換，并且候選小區與上次的不同，為了加快切換速度，無需等到T7超時，BSC再次向MSC發送HANDOVERREQUIRED消息，該消息包含新的目標小區列表celllist2，并重新啟動計數器T_HO_REQ_LOST和T7

MSC再次回送HANDOVERREQUIREDREJECT消息，BSC把本次的目標小區列表celllist2放入REJ_CELL_LIST中。

同時，計數器T_HO_REQ_LOST停止計數，而T7繼續運行

切換流程的特別案例（四）在T7超時前，BSC再次收到切換告警，但是目標小區列表與上次的相同，且與REJ_CELL_LIST中的相同，所以BSC不會向MSC發送HANDOVERREQUIRED消息

T7超時，計數器T_HO_REQ_LOST清空

BSC再次收到切換告警，若需進行BSC間的切換，重復以上過程，若為BSC內的切換，觸發BSC內的切換過程。

切換流程的特別案例（五）重點一次BSC間切換的周期為T7，換句話說，只有當T7超時后，才認為本次BSC間的切換結束

在T7的周期內，由于BSC內部不間斷的進行切換判斷，檢查是否滿足切換條件，所以BSC內可能不斷會有新的切換告警產生，若切換告警附帶的候選小區與上次的相同，BSC不會再次發送HANDOVERREQUIRED，除非T7超時;若附帶的候選小區與上次的不同，為了加快切換的速度，BSC會再次向MSC發送HANDOVERREQUIRED，并且T7會重新開始計數

計數器T_HO_REQ_LOST主要監控MSC對HANDOVERREQUIRED的響應，若MSC向BSC回應HANDOVERCOMMAND或

HANDOVERREQUIREDREJECT消息，該計數器停止計數。若T7超時，計數器T_HO_REQ_LOST清空

OMC－R參數N_PREFER_CELL決定了HANDOVERREQUIRED消息中，目標小區的個數，若BSC發出HANDOVERREQUIRED后，收到MSC發送的HANDOVERREQUIREDREJECT消息，那么，小區列表中的小區被放入存儲器REJ_CELL_LIST中，在T7的周期內，這些小區不能作為切換的目標小區

切換流程的特別案例（六）INTERNALHANDOVERAFTEREXTERNALHANDOVER阿爾卡特BSC支持在特定的情況下，原本為BSC內的切換，通過BSC間的切換形式來實現。這種機制叫做INTERNALHANDOVERAFTEREXTERNALHANDOVER.目的：采樣這種切換機制的目的是在前次BSC間切換失敗的前提下，盡可能快的切向更好小區，而當MSC已對前次切換給出響應后，無需再回應余下的請求切換原理：BSC檢測到切換告警，且候選小區為其他BSC的小區，故觸發BSC間的切換，向MSC發送HANDOVERREQUIRED消息，T7開始計數。在T7的周期內，BSC再次收到切換告警，但候選小區為BSC內部小區，由于T7沒有超時，本次BSC間的切換還沒有結束，所有的目標小區都被認為是BSC外部小區，不考慮實際的小區歸屬情況，所以BSC再次向MSC發送HANDOVERREQUIRED消息，小區列表中的目標小區為BSC內的小區，T7重新開始計數。切換條件：前次HANDOVERREQUIRED消息中的celllist1為BSC外部小區，在T7的周期內，發起后續HANDOVERREQUIRED消息中的celllist2中為BSC內部小區

切換流程的特別案例（七）第一條切換請求中，目標小區為（6265，12307）為D網小區，手機沒有切換成功而回到舊信道

第二條切換請求中，目標小區為（6185，12418）為D網小區，被MSC拒絕

第三條切換請求中，目標小區為（6173，20547），為BSC內部小區，作為BSC外部小區切換，切換成功

高掉話小區案例（一）

高掉話小區案例一

話務統計報告分析發現：格林夢1的掉話情況較為嚴重和特殊，從下表話務指標的變化情況來看，在11月29日這天起，格林夢1的每線erlang數大大增加，而上下行的質量切換數量和PBGT的切換數量也急劇增加，由此反映出的問題是MC136的增加和MC21的增加。因此，我們可以把掉話的主要原因，歸結到話務量的急劇增加上來。下圖中紅色表示話務掉話比，綠色表示每線話務量：

高掉話小區案例（一） 通過180報告以及切換報告分析可知：大部分的話務是由普陽2，3通過PBGT的切換進入格林夢1，話務又從格林夢1以qual/lev，或PGBT的切換回到普陽2，3，因此問題在于普陽2，3為什么會啟動如此多的PBGT切換？信令分析 對普陽3小區Abis信令分析，查看切換方面的內容高掉話小區案例（一）

通過對一些電話做CALLTRACE我們可以發現,向格林夢1切換的數量非常多,而在切換前,目標小區的接收電平并不比服務小區高,即在并不需要切換的情況下觸發了切換,且這種情況非常普遍,這也是普陽3切換非常多而格林夢1的掉話非常多的原因高掉話小區案例（一） 正常情況下格林夢1應作為鄰小區包含在系統消息5中,(格林夢1的BCCH為83)才能實現普陽3向格林夢1的切換,但在普陽3的Abis信令數據中發現83頻點并沒有作為普陽3的鄰小區.卻多次發生了向格林夢1的切換,但沒有一次成功.高掉話小區案例（一）

由此,我們判斷為該小區的切換判斷機制出現混亂,造成切換異常,此外,通過核查OMC發現該小區的BSC與OMC數據不一致,我們刪創了普陽2,

普陽3與格林夢1后,問題解決。高掉話小區案例（二）高掉話小區案例二

趙青3小區的掉話率突然升高，從原來的0.18%左右上升到6%左右（忙時掉話46次左右）從OMC-R的統計報告分析來看，趙青3小區的掉話基本均為MC136掉話，即RadioLinkTimeOut掉話，而切換掉話基本沒有

高掉話小區案例（二）Abis信令分析：它們都是在電話接通（Connect