GSM信令疑难问题分析

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