对MA5300掉线故障的

摘 要：ADSL宽带接入方式,作为国内现阶段较主流的互联网接入解决方案,DSLAM设备经常会出现所带用户掉线问题.本文将就此问题,以华为MA5300 DSLAM用户掉线为例,详细的介绍故障原因分析、处理以及后续建议.

关 键 词 ：DSLAM；掉线；分析；处理；建议

中图分类号：TP31 文献标识码：A

1.组网图

1.1 宏观组网图

1.2 近端组网图

2.故障现象

某局点下一MA5300下的部分ADSL用户,modem启动时不能够正常的同步,有时需要很长的时间,有时根本就启动不起来；对已经正常同步且已上网的用户,有时会发生掉线的现象.

3.测试处理过程

3.1 通过了解,从机房到用户端线路长度大约为2.5km,在MA5300侧查看线路的状况,发现线路的衰减的确很厉害,有的已经接近50了.

3.2 针对出现问题的用户端口,在EADB板侧进行拨号测试,发现modem可以正常拨号上网,经过一段时间的观察没有发现掉线的现象.

3.3 初步断定为线路的问题.针对出问题线路模板新建了与之对应的模板,在建立的过程中充分的考虑了线路的衰减和干扰问题,并将问题端口与新模板进行绑定.经过相当长时间的观察问题消失.

4.问题的延伸

线路相关的模板参数的设置看似很小的事情,但却有其很深的道理,现一一归纳如下.

4.1 noise margin －噪声容限（称为噪声余度更好一些）

线路激活时,在每一个子频带上根据其上的信噪比,3db等同一个比特,来决定承载的比特数.

但若完全的按照这种方法来决定承载的比特数,又会产生一个问题,那就是如果线路质量稍有所下降的话,就会产生误码,甚至还会导致线路的稳定性下降甚至掉线.

噪声余度的概念,就是先留了一定的余度,用来承载想象中可能出现的噪声.线路激活时,先把这部分的噪声余度减掉,然后再按3个db一个比特来决定能承载的比特数,这样就算线路质量有所下降,仍然能够满足线路稳定要求.

4.2 channel mode －通道模式,分为fast和interleed

fast模式即快速模式,纠错能力一般,但延迟较小,适用于那些对延迟敏感的业务 ,这里暂且不讨论.

interleed模式即交织模式,其相比fast模式抗干扰纠错能力较强,但相应的 延迟也是较大. interleed模式就是将线路上线性传递的数据变换为矩阵分散特性后传递出去,从而达到抗干扰,抗噪声的功能.也会出现下面两个问题.

①交织深度（延迟）设置的很低.这种情况下延迟比较低,下载速率较高.但也会出现这样一个问题,当有大量的突发干扰噪声发生时,线路上就会出现很多的错码,导致的后果就是下载的数据由于错误需要不停的重传,速度迅速下降.而若碰巧发生了下面的情况,即在用户上线的时候有大量的干扰,则传递到用户端的训练数据就会产生较多的误码,这将直接导致设备之间不能够很好的协商各种模式,直接表现就是用户端的ADSL modem不能够激活同步.

②相反的若交织深度设置的很大,此时线路的抗干扰性稳定性较好,不易受到噪声的影响,但也隐藏着一种危机,那就是用户有可能会被上层的BAS认证设备强行踢掉,导致用户经常掉线.

原因是：上层的BAS设备一般会过一段时间（一般为40s）,就向拨号用户发送一个ppp ECHO报文,用来确定用户是否还在线,若发三次都没有用户响应,BAS设备就认为用户已经下网,便将用户的状态调为不在线状态.事情就是这样发生的,由于交织深度很大,相应的延迟就很大,从而BAS设备发出的ECHO报文可能得不到及时的响应,当这种不响应发生三次时,用户便被踢掉了.

4.3 Parameters for rate －速率参数

线路实际激活时会在目标最大、最小速率范围之间通过某些算法进行计算,最后会以一个满足激活要求的最好速率进行激活（误比特率不大于10E-7）.

问题就是若目标速率设置的过大,比方说上行速率设置的过大,建立ADSL连接的过程中,计算得出的上行的速率大于配置的上行最大速率,端口就会无法激活,导致用户掉线.

4.4 Trellis coding － 格栅编码；bit swap －比特位交换

Trellis coding就是通过特殊的编码算法,达到较好的编码效益,以提高线路的信噪比.

bit swap主要作用是在子信道的内部进行比特分布的调整或功率调整.

但现在的问题是这些功能在ADSL标准里都是可选项,没有做严格的要求,导致在不同厂家不同设备相互配合上存在问题,若配合不好则会导致用户侧出现问题,甚至是上不了网.

5.故障处理后的归纳

MA5300用户侧掉线或modem同步困难,可从以下几个方面考虑,按出现的多少排列.

5.1 线路的问题.包括线路的长度,信号传送过程中衰减程度,局端侧是否存在一些高频的干扰源.

5.2 上层设备的问题.MA5300的上层设备一般为BAS设备,而BAS设备有时会发大量的控制或者查询测试报文,例如STP测试报文.若有大量这种报文发往MA5300时,MA5300的CPU就会用大量的时间来处理这些报文,从而导致CPU使用过高,进一步的结果就是的某些用户被MA5300强制掉线.

5.3 用户侧问题.用户侧的问题包括很多,如分离器的安装,线头的接触,modem的好坏,都有可能引起掉线或其他问题.事实上当用户侧的电压不稳定,时高时底,必将导致用户侧不停的掉线.

5.4 版本配套问题.如果遇到的问题用户为全部用户,或者说问题用户出现的很有规律,可以考虑一下版本配套的问题.业务单板和主机软件在版本不一致的情况下会造成多种奇怪问题,掉线就是其中的一个.

5.5 设备配合问题.事实上MA5300和它的终端modem的确存在这种问题.因为MA5300在和终端设备的协商过程中可能会出现一下问题,从而导致用户侧出现问题.这时的用户侧问题会很有规律性,一般表现在掉线的时间间隔固定或相差不大.

5.6 将设备进行重启.长时间的运行使程序产生了一定的混乱,会出现一些奇怪的现象.

6.处理意见

出现问题首先根据故障现象进行定位,若定出的问题为上面的某一个,便可对症下药,进行故障处理.