信令追踪在GSM网络维护中的作用


原作者: 冯先庆


  [摘要]:本文主要是通过对几次通信故障案例进行分析,强调对信令进行追踪的重要性,旨在加强对信令流程的重视,以此提高在日常的网络维护特别是故障抢修中进行故障定位的速度。


  随着移动通信的迅速发展,移动通信用户快速增加,移动通信的网络日趋复杂,网络的日常维护、网络故障的定位、网络故障的排除也日趋困难。一旦有通信故障,就会产生大面积的影响。就网络维护部门而言能否在出现通信故障时,快速定位故障点,从而在最短时间内排除故障,就显得日益重要。信令是建立通信的前提,信令就象网络的脉搏一样,通过对信令的分析可以洞察到网络中存在的问题,下面就对几次故障的处理过程与大家交流。


  案例一:


  1.故障现象


  大量用户申告手机很难打通。通过实际的拨测发现手机呼叫手机很难打通,手机呼叫固定电话无问题,固定电话呼叫手机很难打通。总结为手机为被叫时呼叫不畅。通过户外测试发现MSC/VLR所挂的3套BSC下均有此现象,初步定位为全网故障,而手机做为主叫和被叫在信令流程上的主要区别在于:被叫时比主叫时多了分配漫游号码、位置查询和PAGING的过程。


  2.故障的定位


  (1)。用信令仪表对A接口进行信令跟踪,因为在A接口是用TMSI进行呼叫接续,所以首先在HLR中查出测试手机对应的TMSI号码,对该TMSI进行跟踪。用该手机做被叫,发现每次呼叫不通时,均没有跟踪到信令流程,故障基本可以定位在交换侧。


  (2).用信令仪表对HLR与MSC/VLR间的C接口进行信令跟踪,对被叫手机进行跟踪,通过大量的信令跟踪,总结出每次呼叫失败时的信令流程如下:


HLR返回给发起呼叫MSC/VLR的消息Send Routing Information Ack的信令为:


════════〖 GSM MAP Part 〗═══


═01100100 100: Message Type:End


10100011 163: Element Type:


00000010 002: INVOKE ID TAG(ID=0x00 )


00100010 034: ERROR CODE[=34] System Failure


00000010 002: Network Resource:VLR


而被叫手机所在的MSC/VLR返回给HLR的消息Provide Roaming Number Ack为:


══════〖 GSM MAP Part 〗═══


01100100 100: Message Type:End


10100011 163: Element Type:


00000010 002: INVOKE ID TAG(ID=0x00 )


00100010 034: ERROR CODE[=34] Resource Limited


00000010 002: Network Resource:VLR


  结合上面的信令流程可以看出,有正常的位置查询流程。可以判断故障点在MSC/VLR,从MSC/VLR返回给HLR的消息Provide Roaming Number Ack的错误代码“ERROR CODE[=34] Resource Limited”可以看出是因为MSC/VLR没有成功给被叫手机分配漫游号码,导致发起呼叫的MSC/GMSC无法知道被叫手机的位置信息,从而无法进行呼叫的接续,导致电话不通。而主叫手机不用进行位置查询,不用分配漫游号码,所以手机呼叫固定电话时没有故障。


  3.解决方法:


  故障点判定以后,问题就可以迎刃而解了。在ALCATEL交换机中有一类负责手机漫游号码的分配的模块MRSACE,当该类模块资源不足或模块吊死时会分配不出漫游号码,从信令流程上也证实了这一点。将该类模块重新启动后,呼叫正常。


  案例二


  1. 故障现象


  大量用户反映手机拨打固定电话困难,要重拨几次才能打通。通过实地测试,发现存在该现象,而且在忙时,如下午6点左右下班时,该问题更加突出,但手机与手机没有该类问题。


  2. 故障定位


  当前的网络结构是:移动网与固定网通过移动关口局相连。从故障现象来看,问题应该出现在移动关口局或固定网方面。于是对移动关口局与固定关口局之间的信令进行追踪,发现手机呼叫固定电话不成功时的信令流程为:


移动GMSC 固定GMSC


-----------------à IAI


?---------------- CGC


-----------------à CLF


?---------------- RLG


  从以上信令流程可以判定,问题就出现CGC上,CGC表示电路拥塞,此次故障应该是对方中继电路问题。


3  . 解决方法


  经与对方联系,确定了以上判断,等对方将中继问题排除后,恢复。


  案例三


  1. 故障现象


  在对遵义的长途来话的呼损分析中发现,遵义MSC3的长途来话的呼损中总是存在一定1.3%左右的空号呼损。通过一段时间的观察,发现每次都有。


  2. 故障定位


  从GSM规范的接续流程分析,因为手机做被叫时,不是用手机号码进行接续,而是用交换机分配的一个临时漫游号码MSRN进行接续的,所以不可能是在被叫手机号码上出现问题。为了寻找问题所在,我决定从信令方面着手。用MPA7300信令仪对省会城市贵阳A1/A2到MSC3的信令进行了大量跟踪。发现了下面的信令流程:


TLink3A SLink3 01:07.990


BSN: 126 FSN: 94 MSU ISUP


23-255- 60 23-255- 1 7-27 IAM 13900087211 13033661232F


TLink4A SLink4 01:20.273


BSN: 100 FSN: 71 MSU ISUP


23-255- 1 23-255- 60 7-27 ACM 07902080


TLink4A SLink4 01:22.082


BSN: 102 FSN: 77 MSU ISUP


23-255- 1 23-255- 60 7-27 REL Unallocated (unassigned) number


TLink3A SLink3 01:22.169


BSN: 28 FSN: 104 MSU ISUP


23-255- 60 23-255- 1 7-27 RLC


  从以上信令流程可以看出,空号的原因就是由于被叫手机呼转到了一个空号上,从而产生了空号的呼损“Unallocated (unassigned) number”。


  3. 故障解决


  要解决该问题,原理上很简单,只要将被叫手机的呼转取消就可以了。但是从GSM规范中规定手机被叫时是以MSRN进行接续的(如以上信令中的13900087211),MSRN与手机号码之间没有固定的对应关系。如何找到被叫号码成了问题的关键。经过分析,决定对呼转的空号07902080进行跟踪。经过对相应局向信令进行了大量跟踪,发现如下的信令流程:


TLink1A SLink1 02:23.064


BSN: 115 FSN: 9 MSU ISUP


23-255- 0 23-255- 60 6-26 IAM 07902080 13908510777F 13508521349 13508521349


TLink2A SLink2 02:23.154


BSN: 9 FSN: 116 MSU ISUP


23-255- 60 23-255- 0 6-26 REL Unallocated (unassigned) number


TLink1A SLink1 02:23.297


BSN: 116 FSN: 10 MSU ISUP


23-255- 0 23-255- 60 6-26 RLC


  从信令可以看出主叫号码为13908510777,被叫号码为13508521349,呼转的空号为07902080。将被叫13508521349的呼转号码取消后即可。


  案例四


  1. 故障现象


  计费中心反映手机拨打北京1860不计费。


  2. 故障定位


  首先对该现象进行分析,手机打其它外地1860都可以正常计费,唯独对北京1860不计费,对计费分检系统而言,区别仅仅在费率区(区号不同)。而北京1860和北京普通号码是一样的,既然普通号码可以正常计费,那么1860也应该能正常计费,说明费率上没有问题。通过以上分析,决定从信令上查找原因。通过对北京的0101860进行追踪发现了如下的信令流程:


BSN: 118 FSN: 30 MSU ISUP


23-255- 1 23-255- 60 1-10 IAM 0101860 13508521010F


TLink1A SLink1 00:42.684


BSN: 32 FSN: 122 MSU ISUP


23-255- 60 23-255- 1 1-10 ACM


TLink1A SLink1 00:44.755


BSN: 32 FSN: 125 MSU ISUP


23-255- 60 23-255- 1 1-10 ANM


TLink1A SLink1 00:45.237


BSN: 32 FSN: 0 MSU ISUP


23-255- 60 23-255- 1 1-10 REL


TLink4B SLink4 00:45.276


BSN: 0 FSN: 33 MSU ISUP


23-255- 1 23-255- 60 1-10 RLC


  从信令流程上来看,没有任何问题,但是将ACM和ANM消息展开后,发现计费标识为01,即为不计费。这就是问题所在。


MESSTYPE : 06h = ACM


--- ACM ---


--- BACKW CALL ---


BA : ......01 = no charge



MESSTYPE : 09h = ANM


--- BACKW CALL ---


BA : ......01 = no charge


  3. 故障解决


  在交换机中将不计费改为计费后,恢复正常。


  结束语


  从以上案例可以看出,通过对信令进行追踪,对信令进行分析可以在较短的时间内定位故障点,为故障的解决赢得时间。从另一个角度来说这也要求我们维护人员要不断对各种信令规范进行学习,这样才能在实战中发挥作用。




摘自《通讯世界》


   

扫码关注5G通信官方公众号,免费领取以下5G精品资料
  • 1、回复“YD5GAI”免费领取《中国移动:5G网络AI应用典型场景技术解决方案白皮书
  • 2、回复“5G6G”免费领取《5G_6G毫米波测试技术白皮书-2022_03-21
  • 3、回复“YD6G”免费领取《中国移动:6G至简无线接入网白皮书
  • 4、回复“LTBPS”免费领取《《中国联通5G终端白皮书》
  • 5、回复“ZGDX”免费领取《中国电信5GNTN技术白皮书
  • 6、回复“TXSB”免费领取《通信设备安装工程施工工艺图解
  • 7、回复“YDSL”免费领取《中国移动算力并网白皮书
  • 8、回复“5GX3”免费领取《R1623501-g605G的系统架构1
  • 本周热点本月热点

     

      最热通信招聘

      最新招聘信息

    最新技术文章

    最新论坛贴子