UMG8900常见问题汇总.docx

UMG8900常见问题汇总.docx

《UMG8900常见问题汇总.docx》由会员分享，可在线阅读，更多相关《UMG8900常见问题汇总.docx（14页珍藏版）》请在冰豆网上搜索。

UMG8900常见问题汇总

1前言

在MGW的业务定位手段中，最常用的是H248消息跟踪、QAAL2消息跟踪、ATMUP消息跟踪、ContextID确定的呼叫跟踪。

各单板的串口调试命令能输出呼叫异常信息和数据统计，可以查到比较详细的错误原因，建议在跟踪无法定位时使用。

2各种业务与组网呼叫问题定位

1.通用问题

呼叫时直接失败，主叫听到忙音，没有H248消息到达MGW。

有如下可能情况：

1、各种组网，问题通常在于SX3000上的MGW状态为故障，导致呼叫无法进行。

常见故障原因：

1）SX3000与MGW的PPU之间的网线未连接；

2）PPU的网线被插在PPU的调试网口；

3）网络状况或者网口接触不良、网口工作模式（单双工/10M/100M）不匹配，导致误码率过高；

4）SX3000修改鉴权参数导致H248链路中断；

5）MGW上人为去激活网关后忘记重新激活；

6）MGWPPU单板与SoftX3000之间的IFM单板没有通过LANSWITCH相连，而是采用直接连接方式

常用定位手段：

1）在MML维护台使用命令DSPVMGW，检查网关状态是否业务态；

2）SX3000上DSPMGW，检查与MGW的网关状态是否一致；

3）在MGW和3000维护台上分别PING对方，检查MGW与SX3000的以太网连接是否正常；

4）DSPIPIF，检查PPU板的以太网口状态是否正常；

5）检查H248链路、VMGW、MGC配置数据；

解决：

1）保证MC接口物理连接正常，可PING通；

2）保证数据配置正确，网关激活。

2、UE做主叫，问题通常在于UE没有注册成功，导致无法发起呼叫。

常见故障原因：

1）RNC或NodeB故障，本地小区异常；

2）RNC与MGW之间的MTP3B链路中断；

3）SX3000与MGW之间的M3UA链路中断，中断原因与H248链路类似；

常用定位手段：

1）跟踪RNC的Uu接口，察看UE的上报消息是否到达RNC，确保NodeB没有问题；

2）跟踪RNC上的Iu接口，看RNC是否发出了消息，确保RNC没有问题；

3）检查MGW与RNC之间的MTP3B链路是否可用，如不可用，执行4、5；

4）检查RNC与A4L之间的光纤是否有未连接、光纤收发接反情况，观察LINK指示灯是否正常；

5）检查RNC与A4L的光模块单/多模式是否相同，如不同可能因误码率过高导致链路中断；

6）如果MTP3B链路可用，跟踪MTP3B接口，是否收到了SCCP报文，是否发送了SCCP报文；

7）跟踪M3UA接口，看SCCP报文是否转发到了SX3000，是否收到了SX3000的SCCP报文；

解决：

1）更换正确的光纤、做正确的连接；

2）保证MTP3B、M3UA数据配置正确。

3、PSTN做主叫，问题通常在于SX3000上MGW的时隙状态为故障。

常见故障原因：

1）E32与B-Switch之间E1线物理连接不正常；

2）E32与B-Switch之间E1端口参数配置不一致；

3）MGW未将TDM状态上报给SX3000；

4）SX3000与B-Switch之间的七号链路故障；

常用定位手段：

1）DSPE1PORT，查询MGW上的端口状态是否正常，如果不正常，执行2、3；

2）检查E32与B-Switch之间的E1连线是否存在断开、收发接反、端口接错；

3）检查E32与B-Switch之间的E1端口参数，帧格式是否相同，如果不知道B-Switch的设置，可以分别修改E32的设置为DOUBLE_FRAME或CRC4_MULTIFRAME试试，这两种是目前组网中用到过的；

4）LSTTDMIU，检查Tid与SX3000的配置是否一致；

5）在SX3000上DSPN7C，检查配置的时隙是否故障，如果与MGW上的状态不一致，尝试拔插E1线，使TDM端点状态重新上报；

6）如果重新上报SX仍然故障，在SX3000上DSPN7LNK，检查7号链路是否可用，如不可用，检查SX与B-Switch的物理连接；

解决：

1）MGW与B-Switch、SX与B-Switch之间的E1线做正确的连接；

2）MGW与B-Switch的E1端口参数配置正确；

3）拔插E1线重新上报TDM端点状态/使用DEAVMGW和ACTVMGW去激活再激活网关，刷新TDM端点状态；

4）复位SX3000的WCCU板或WCSU板，将端点全部重新初始化。

2.UE-UE局内呼叫问题

这种组网情况下通常只涉及到Iu接口的ATM承载，在UP版本为1或者放音时会用到TC，问题也通常与之有关。

1、呼叫失败，SX3000增加ATM端点后直接Sub端点，RNC上RAB指派失败，QAAL2跟踪发现ASU收到RNC的ERQ后回RLC。

常见故障原因：

1）RNC与MGW配置的PathId不一致；

2）MGW上没有配置QAAL2的用户数或者配置用户数已满；

3）MGW上该Path对应的PVC带宽已用尽；

4）UP版本为1时，CMU加分组TC失败，导致QAAL2超时释放；

5）信令PVC与承载PVC分布在不同光口上时，PathID对应的承载PVC所在光路故障，且打开了OAM开关导致PVC状态为故障；

常用定位手段：

1）分析RLC消息中携带的原因值，有些错误原因可以直接得到；

2）检查RNC与MGW配置的Path配置是否一致；

3）在UP版本为1时，检查TCU状态，或LSTTCALLOC检查是否配置了正确的TCU分配关系；

4）检查承载PVC所在光纤的连接状况；

解决：

1）修正QAAL2的Path配置、用户数配置；

2）修正TCU分配关系；

3）正确连接承载PVC所在光纤。

2、呼叫失败，SX3000增加ATM端点后直接Sub端点，RNC上RAB指派失败，QAAL2建链成功，MGW没有收到UP初始化报文。

常见故障原因：

1）RNC与MGW配置的PathId对应的PVC不一致，导致UP初始化报文被丢弃；

2）MGW上配置的承载PVC接收流量过小，并设置了UPC，导致丢包；

3）信令PVC与承载PVC分布在不同光口上时，PathID所对应的承载PVC关闭了OAM开关，且该承载PVC所在的光路故障；

常用定位手段：

1）对比RNC与MGW对同一条Path的承载PVC设置；

2）检查MGW的承载PVC流量设置；

3）检查承载PVC所在光口的光纤连接情况；

解决：

1）修正Path的PVC配置；

2）修正PVC的流量配置；

3）正确连接承载PVC所在光纤。

3、呼叫失败，SX3000增加ATM端点后直接Sub端点，RNC上RAB指派失败，QAAL2建链成功，MGW收到UP初始化报文，回NACK导致初始化失败。

常见故障原因：

1）SX3000上配置的RNC速率集合不是MGW配置RFCI集合的子集，UP初始化失败；

常用定位手段：

1）对比UP初始化报文中携带的速率与MGW上配置的RFCI集合；

解决：

1）修正SX3000的RNC速率设置或MGW的RFCI设置。

4、呼叫成功，主被叫NEC手机听到的是有规律的噪音。

常见故障原因：

1）SX3000上配置的RNC速率集合未包括12.2K，而NEC手机目前只支持12.2K；

2）SX3000上配置的RNC速率集合未包括0速率和静默帧，导致噪音；

3）SX3000上配置的RNC速率集合包括12.2K，但是配置速率过多，导致RAB指派时选择的速率集不包括12.2K；

常用定位手段：

1）检查MGW收到的UP初始化报文中携带的速率是否包含12.2K；

2）SX3000上LSTRNC，检查配置的速率中是否包括12.2K、0速率、静默帧，配置的速率是否过多；

解决：

1）修正SX3000的RNC速率设置。

3.UE-PSTN局内呼叫问题

1、呼叫失败，MGW上增加了ATM、TDM端点后向SX3000上报承载释放，释放原因为3。

常见故障原因：

1）MGW上配置的TCU分配关系不正确；

2）TCU板上TC资源不足；

3）SX3000上配置了使用EC，但TCU板上EC资源不足；

常用定位手段：

1）检查TCU分配关系设置；

2）查询TCU的TC/EC资源；

3）SX3000上LSTTG，查询EC的设置；

解决：

1）修正TCU分配关系设置；

2）增加TCU的单板或扣板；

3）SX3000上MODN7TG，关闭EC开关。

4.PSTN-PSTN局内呼叫问题

同上。

5.UE-UE局间呼叫问题

1、IP承载呼叫失败，MGW上增加了Iu侧ATM端点成功，CN侧增加IP端点失败。

常见故障原因：

1）RPU上的以太网连接故障或两端配置不一致导致虚拟媒体网关资源不可用；

2）MGW上设置的IP承载能力过小，或已用尽；

常用定位手段：

1）检查E8TF上的网线连接，PING测试连接状况；

2）检查两端RPU的IP掩码设置是否一致；

3）查询TCU的TC/EC资源；

解决：

1）正确连接RPU的接口板网线；

2）修正RPU的以太网设置；

3）修正IP承载能力设置。

2、呼叫失败，MGW上Iu侧主被叫ATM端点均上报承载建立，CN侧增加端点成功，然后向SX3000上报承载释放。

常见故障原因：

1）主被叫MGW上配置的RFCI集合不一致，导致核心网UP初始化失败；

常用定位手段：

1）LSTRFCI，检查RFCI集合设置；

2）跟踪CN侧的IP资源NBUP接口或ATMUP接口消息；

解决：

1）统一主被叫MGW的RFCI集合设置。

3、R4呼叫失败，UP版本2，MGW上所有端点均上报承载建立，然后被叫Iu侧端点向SX3000上报承载释放。

跟踪ATMUP，被叫ASU收到了UP初始化报文并回ACK，然后发出UP初始化报文并收到NACK。

常见故障原因：

1）主被叫RNC上配置的AMR速率集合不一致，导致被叫侧RFCI校正失败；

常用定位手段：

1）ATMUP接口跟踪，比较UP初始化报文中携带的RFCI集合、收发数目和应答报文；

2）SX3000上LSTRNC，检查RNC的AMR速率集合设置；

解决：

1）在SX3000上设置主叫RNC的AMR速率集为被叫RNC的子集。

6.UE-PSTN局间呼叫问题

1、R4呼叫失败，PSTN主叫，UP版本2，MGW的所有侧端点上报承载建立，然后被叫Iu侧端点向SX3000上报承载释放。

跟踪ATMUP，被叫ASU收到了UP初始化报文并回ACK，然后发出UP初始化报文并收到NACK。

常见故障原因：

1）主被叫MGW上配置的RFCI集合大于被叫RNC的速率集合，导致被叫侧RFCI校正失败；

常用定位手段：

1）ATMUP接口跟踪，比较UP初始化报文中携带的RFCI集合、收发数目和应答报文；

2）LSTRFCI，检查MGW的RFCI设置；

3）SX3000上LSTRNC，检查RNC的AMR速率集合设置；

解决：

1）在SX3000上设置被叫RNC的AMR速率集，等同或包括主叫MGW的RFCI集合；

2）MODRFCI，设置主叫MGW的RFCI集合为被叫RNC的子集。

7.PSTN-PSTN局间呼叫问题

同上。

8.UE-UEH324业务呼叫问题

1、呼叫失败，主叫UE直接挂断，RNC上RAB指派失败。

常见故障原因：

1）SX3000上配置的UP版本不是1，RNC不支持该版本下的透明数据业务；

2）RNC上没有打开CS域64K数据业务算法开关；

3）RNC上打开了AMRC算法开关；

常用定位手段：

1）SX3000上DSPMSFP，检查P99参数设置；

2）RNC上LSTCORRMALGOSWITCH，检查算法开关设置；

解决：

1）MODMSFP，修改SX3000的P99参数为“5”；

2）SETCORRMALGOSWITCH修改RNC算法开关，打开CS域64K数据业务，关闭AMRC。

2、呼叫失败，主被叫UE接听保持几秒后，UE主动释放，其间看不到对方图像。

常见故障原因：

1）RNC与MGW配置的Path对应PVC不一致（如果语音呼叫可通，则不存在这个问题）；

2）ASU的PVC流量参数设置过小，导致数据业务丢包；

3）IP承载时，RPU的用户数据报文流量参数设置过小，不能支持数据业务；

常用定位手段：

1）对比ASU光口接收的数据流量、实际转发的数据流量；

2）检查AAL2PATH设置、检查PVC流量参数表设置；

3）对比RPU收发数据流量，检查NPCAR设置；

解决：

1）修正ASU的AAL2PATH对应PVC设置；

2）修正PVC流量参数设置；

3）修正RPU的NPCAR设置，增大流量参数。

3具体问题集锦

9.Iu接口信令对接问题定位

1）SAAL链路状态异常，出现连续发送BGN和END报文，无接收报文

打开SAAL的跟踪，出现如下结果。

图1SAAL跟踪――连续发送BGN和END报文

查询SAAL链路状态，其SSCOP状态一般为Idle或OutgoingConnectionPending。

这种结果表明我们没有收到对端的报文。

一般原因是光纤未接好或双方的PVC数据配置不符合。

2）SAAL链路状态异常，链路校准和校验失败

从SAAL跟踪看，BGN与BGNAK交互完成，即SSCOP建链完成。

但是，在进行大量SD校验过程中链路断开。

该问题曾经出现在MGW与模拟RNC对接的过程中。

如果仔细阅读跟踪，发现出现4次丢包。

出现这个问题后，尝试将N1设置为10，大量减少验证包个数，链路可以正常建立。

说明与链路质量有关。

更换光纤也无作用，后来发现模拟RNC版本的问题。

升级版本之后，问题消失。

类似的问题还曾经出现在RNC与MGW的对接上，当时我们与RNC对接不起来，看跟踪是报文延迟过大，接收到的RNC的验证报文有问题。

碰到这种情况，还有一个方法就是在ASU单板的串口执行调试命令omactlpbkpm5351inter[portno]，进行相应光口的环回。

如果环回后我们的SAAL链路可以与自己建立连接，就至少说明问题不在MGW这边。

那次的问题是由8850引起的，复位8850后，连接就正常了。

3）SAAL链路正常一段时间后，突然断开，接着又正常，MTP3b链路不可用

链路正常的时间很多，但是即使没有跑业务，链路也会周期性的会断开。

这种情况下，查看MTP3b链路，发现MTP3b链路一直不可用。

出现这种情况的原因不是SAAL配置造成的，而是MTP3b的数据配置不对，需要核对双方的信令点以及链路SLC。

4）SAAL链路状态异常，不断发送BGN、END，同时收到对端的ER报文

现象与3.2.1相似但是会收到对端的ER报文。

这时标明双方的PVC数据是匹配的，但是对端的SAAL链路之上可能没有配置MTP3b链路，或者该MTP3b链路没有被激活。

该问题在我们的实验室环境出现过，定位了很长时间，后来发现RNC的MTP3b链路未被激活。

5）SAAL协议发送大报文的时候链路断开

广州与NOKIA对接的时候出现连续发送几个大报文的时候，SAAL链路突然断开。

跟踪如下图所示。

图2SAAL跟踪――发送大报文链路断开

从图中可以看到，我们连续发送了若干了大报文（128字节）后，收到了对方的END。

链路是对方断开的。

我们点击收到的END报文，解析结果如下。

图3SAALENDPDU解析结果

我们可以看到END报文最后几个域，其中“s”域的取值为1，表示是由对方的SSCOP释放的。

如果该值为0，表示是由SSCOP上层释放的（如MTP3b）。

参照协议，发现在链路正常情况下，SSCOP释放报文的唯一可能是NORESPONSE定时器超时。

估计是由于报文太大，导致NOKIA的RNC接收延时导致的。

因此让NOKIA延长其NORESPONSE定时器。

但是仍然会出现该情况。

后来，NOKIA定位发现在链路断开之前，他们的SSCOP收到了底层上报的错误。

这是NOKIA的私有接口。

因此我们估计与SAAL链路无关。

注意力开始集中到底层。

考虑到我们的信令PVC是不进行流控的，因此我们发送大包时，可能会导致突发的信元。

我们建议NOKIA放宽其流量参数，他们将CDVT增大后，问题就解决了。

该问题的定位说明，SAAL链路不正常，有时会是物理上和底层的问题。

需要根据跟踪和现象步步排查。

6）QAAL2建链失败，RNC收到MGW返回资源不可用应答

进行3G呼叫，如果出现呼叫失败，查看Iu接口QAAL2协议跟踪，发现MGW对于RNC的QAAL2ERQ消息回复了REL应答并且失败原因为“资源不可用”，那么一般来说存在可能如下几种情况：

1、使用QAAL2查看呼叫所在PATH状态的命令DSPAAL2PATH，如果PATH状态为Alarm状态，那么会导致QAAL2认为没有可用资源进行呼叫处理，因此回送了REL应答。

出现这种情况是因为AAL2PATH对应的PVC已经处于告警状态，问题产生的原因有以下几种：

1）检查该条PVC所在的光口光纤是否连接正常，是否存在光口告警，解决措施检查光纤是否正常，与对端RNC连接是否正常？

2）该条PVC对应的OAM开关是否打开，如果MGW开启OAM，RNC不支持OAM，那么同样会导致PVC告警

2、查看AAL2PATH可用带宽是否够用，使用DSPAAL2PATH命令可以看到该条PATH剩余的资源。

3、查看ATMVMGW虚拟媒体网关资源是否存在限制？

10.TDM相关问题

1）TNU半永久连接配置丢失

因为在实际开局中，经常采用半永久连接方式来组网，所以测试环境也采用了这种方式。

两个MSCServer之间使用No.7信令，信令所在电路与用户电路同属于一个中继E1。

两个MGW之间也就配置了一条E1电路，MGW和Server之间连接一条E1，MGW在对段MGW接口和到Server的接口上建立一条SPC连接，将信令配置到这个连接上。

在实际呼叫过程中，发现经过多次跨实验室网关间呼叫后，在进行呼叫，放音提示无可用通路，检查发现网关间电路全部故障。

定位过程

1、首先检查两边MGW的中间线连接情况，在网关上查询对应E1端口的电路状态，全部为正常。

2、然后检查Server的电路状态故障原因，发现Server上该连接对应的No.7信令故障。

3、因为这部分的连接在网关上采用SPC方式，先在MGW连接Server的E1端口上做外环回，Server上的链路状态为锁定。

取消外环，再在MGW上连接对端的MGW上设定内环，Server上的链路状态为失锁。

怀疑的焦点就确定在MGW上SPC连接丢失。

4、请来MGW的TNU开发人员定位，发现SPC连接已经不存在，删除SPC配置，重新连接后，电路状态恢复。

其后进行试呼数次，情况未复现，而环境中另外一个到CC08交换机的半永久连接一直正常，情况很是奇怪，初步确定为不可重现问题。

5、因为环境使用关系，过了几天之后，在这个环境进行几次跨网关呼叫后，问题复现，而且是在同一个SPC上，同样的环境，进行了MGW到CC08呼叫，一直正常无问题，开始怀疑在数据配置上有问题，检查数据发现，在Server上将信令链路所在电路也配置进了Server的可用电路当中，问题也就很明确了。

问题分析

其实问题的原因就是因为Server在配置的时候，将信令链路所在电路配置为可用。

在CC08交换机中，会自动将配置了信令链路的电路置为不可用，而在NGN环境中，信令与用户面分离，导致这两部分的数据没有直接关联，如果MGW采用了半永久连接，MGW自身是不知道传输的是信令还是用户数据。

当Server选路的时候，选择了传信令的电路，MGW会按照目标拓扑来进行改网，SPC就丢掉了。

问题解决

修改Server配置，将信令链路所在电路配置为不可用，问题不再出现。

2）E32单板出现滑帧告警或者半永久连接ISUP链路不通

问题/故障现象描述

UMG8900设备与SoftX3000联合组网作为2GBSC设备，或者UMG8900设备与其它设备之间建立TDM连接时，完成数据配置后，TDM时隙握手总是失败，或者频繁出现滑帧告警；

故障定位与分析

首先通过LMT系统的告警管理子系统与设备建立连接，观察是否有相关的告警信息。

UMG8900设备的LMT系统告警管理系统的告警提示中会频繁出现（中文环境）：

+++UMG89002003-03-3115:

33:

13

ALARM187036事件一般告警UMG89002409通讯系统

告警名称=误帧告警

模块号=71

定位信息=机框号=1,槽位号=14,板位置=后插,虚拟媒体网关号=NULL,板类型=MET32,板组号=14,端口号=0,误帧计数=3

---END

或者（英文环境）

+++UMG89002003-03-2211:

36:

25

ALARM179091eventminorUMG89002409communication

Alarmname=FrameError

ModuleNo.=71

Locationinfo=FrameNo.=1,SlotNo.=12,BoardPosition=back,VirtualmediagatewayNo.=NULL,BoardType=MET32,BoardNo.=12,PortNo.=0,FrameErrorCount=3

---END

…………

的提示。

根据告警台提供的告警信息可以看出，可能原因为帧头的CRC校验头类型不匹配。

在UMG8900的UI界面，输入MML查询命令：

DSPPORTSTAT:

FN=1,SN=14,PORT=0;

得到的查询结果如下：

工作模式=E1

发送线路编码方式=HDB3

接收线路编码方式=HDB3

环回模式=NOLOOP

发送帧格式=CRC4_MULTIFRAME

接收帧格式=CRC4_MULTIFRAME

系统侧Highway数据速率=16.384Mb/s

系统侧时钟频率=16.384MHz

…………

得到帧类型为CRC4_MULTIFRAME

查询与UMG8900设备组网的SoftX3000设备相应的配置，得到的帧类型为：

DOUBLE_FRAME

说明CRC不匹配是无法正确建立TDM连接的原因。

故障/问题定位

通过上面的分析可以确定，是由于UMG8900设备与SoftX3000设备的TDM帧类型设置不统一，可以修改UMG8900设备，也可以修改SoftX3000以保持一致，这里以修改UMG8900设备为例：

通过UI执行如下命令：

SETPORT:

FN=1,SN=15,PT=E1,FS=DOUBLE_FRAME,TXCS=HDB3,RXCS=HDB3;

修改帧类型为DOUBLE_FRAME

问题解决

建议与总结

在出现上述滑帧现象时，建议先检查CRC头是否连接的设备一致。