浅谈IPSTP信令翻转的原因.docVIP

浅谈IPSTP信令翻转的原因 运维中心浦东维护部 宋之峰 摘要： 主要是针对IPSTP在上海移动替换工程中发生的信令翻转，研究一下解决方案。 关键词： 64K信令、翻转 IPLSTP工程及信令翻转情况介绍介绍： 上海移动No.7信令网采用二三级信令网混合组网的方式，包括一对HSTP、3对LSTP和若干个SP点。省内各SP设备分别和LSTP、HSTP都有直达链路相连。LSTP负责疏通省内各移动网间的信令转接，HSTP负责省际信令转接。本次LSTP工程新建一个独立低级信令转接点LSTP2，使用的上海贝尔SG设备，采用同厂家新型STP（硬件型号：5020SG，软件版本：REL2.1）。直接替换现网S12 LSTP2。根据现网网络拓扑及拨测用例需求，选定部分网元搭建测试网络，在各测试网元与新LSTP2制作直达信令链路，均是64K信令和2M信令。各测试网元间的信令由新LSTP2转接。在用新LSTP2转接信令拨打测试中64K信令频繁发生翻转。就对这个现象做一个详细研究。 信令翻转解决方案： 1.1 64K翻转现象： 新建LSTP2与测试网元搭建完信令后，发现大量信令出现频繁的信令翻转， event=h1B。对这些翻转的信令统计之后发现都是64K信令。 1.2 原因分析: 经过分析系统日志，发现系统每秒上报了大量的传输告警。ALCATEL公司的IPSTP是由FES来处理MTP1-3层。有PIM处理MTP1和MTP2层的内容，有CIM来处理MTP3层的内容。因此PIM和CIM之间要建立SPC。由于IPSTP按照现网LSTP2的配置，创建完成了所有的信令。因此就是创建了所有SPC数据。由于这些承载这些信令2M传输都需要割接当晚才能够沟通，因此会产生大量的2M传输告警，同时这些传输告警会送至PIM板进行处理并上报。传输告警都是通过中断的方式上报的，需要占用buffer。PIM板上每个2M分配了1024个buffer， 每个2M LINK独享这1024个buffer， 每个64K link分配1024/32=32个buffer。2M link由于分配到的buffer数量大，而64K link分配到的buffer数量小，而系统每秒产生了大量的传输告警，产生了大量的中断占用buffer，由于2M link的buffer数量大，没有影响到MTP消息的分发时buffer的占用。64K link处理告警中断时，如果传输告警过多，占用buffer过多（30个），会影响分发MTP消息buffer缺乏，造成系统忙于处理传输事件，引起T7超时，造成LINK翻转。 综上说述，64K link翻转主要是由于传输告警较多，导致占用buffer过多，使得正常发送MTP消息时所需要的buffer缺乏所致。而2M link由于buffer分配得较多，因此不受影响。 1.3 信令翻转解决方案： 通过以上原因分析主要是由于传输告警引起64K link翻转。避免此问题的手段有两个： 对未调通或传输有告警的2M进行自环。 在FES上删除所有未调通或传输有告警局向的SPC数据。 以上解决方案解决了64K link翻转的原因。 1.4 位置更新导致信令翻转原因分析及解决方案： 解决了64k link频繁翻转现象后，继续进行后续测试。在测试中发现测试手机无法做位置更新。而且测试手机一旦做位置更新信令就会翻转。 经过统计发现发生翻转的信令还是64k link。对翻转的64k link做了信令跟踪，发现端局发送location update消息IPLSTP能正常转接到HLR，而HLR发送的ack消息IPLSTP则无法正常转发，会发送一个MSU ERROR消息，原因为length error。 经过对设备内部程序跟踪分析后发现，端局和IPLSTP之间都是64k link，而HLR和IPLSTP之间都是2M link。 64k link的协议中，信令单元的长度指示语为6个bit，可以直接表示的信令信息字段的长度为62字节，当信令消息字段的长度超过62字节时，LI可以设置为63。 2M link协议中由于链路上承载的信令业务量较高，为了加快消息定界处理，提高信号单元的处理速度，2M link的消息长度指示语改为9个bit，这样可以直接表示出消息长度，即可直接指示出MTP所支持的最大272个字节的业务信息字段。 由于HLR和IPLSTP之间是2M link信令消息字段的长度是9个bit，而端局与IPLSTP之间是64k link信令消息字段的长度是6个bit。新建LSTP2在处理长MTP消息转发时，会把该消息长度错当成一个LSSU消息，并通知硬件进行自动重发，因此导致程序把长度超过255的MTP消息的头部错当成一个SIOS消息发送给对方，从而引起链路翻转。 该现象的解决方案是通过修正MTP长