首页 UMG8900故障诊断指导书

UMG8900故障诊断指导书

举报
开通vip

UMG8900故障诊断指导书UMG8900故障诊断指导书 目 录 1.1.1 H248链路故障 ................................................................................................................. 3 1.1.2 H248链路闪断 ................................................................................................

UMG8900故障诊断指导书
UMG8900故障诊断指导书 目 录 1.1.1 H248链路故障 ................................................................................................................. 3 1.1.2 H248链路闪断 ................................................................................................................. 5 1.1.3 M3UA链路故障 ................................................................................................................ 6 1.1.4 M3UA链路闪断 ................................................................................................................ 8 1.1.5 MTP3链路故障 ................................................................................................................ 9 1.1.6 MTP3链路闪断 .............................................................................................................. 11 1.1.7 M3UA目的实体不可达 .................................................................................................... 12 1.1.8 MTP3目的信令点不可达 ................................................................................................. 13 1.1.9 MGW退出业务态 ........................................................................................................... 14 1.1.10 SCTP链路拥塞 ............................................................................................................ 15 1.1.11 SX3000电路不空闲 ...................................................................................................... 16 1.1.12 M3UA链路负荷分担不均匀 ........................................................................................... 18 1.1.13 MTP3链路负荷分担不均匀............................................................................................ 18 1.1.14 信令通,语音双不通(许多电话)................................................................................. 20 1.1.15 信令通,语音双不通(个别电话随机出现) ................................................................... 23 1.1.16 信令通,语音单通(许多电话) .................................................................................... 25 1.1.17 信令通,语音单通(个别电话随机出现)....................................................................... 26 1.1.18 用户听见自己的声音..................................................................................................... 27 1.1.19 电话接通后语音质量不好 .............................................................................................. 29 1.1.20 呼叫接续失败............................................................................................................... 29 1.1.21 用户通话过程中电话掉线 .............................................................................................. 31 1.1.22 资源占有率过高 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 ..................................................................................................... 32 1.1.23 呼叫日志分析............................................................................................................... 32 1.1.24 M3UA链路双活 ............................................................................................................ 33 1.1.25 UMG到主用Server的链路断掉后,无法正常注册备Server ............................................ 33 1.1.26 双归属倒换后呼叫不能接续........................................................................................... 34 1.1.27 双归属倒换后M3UA链路不能激活................................................................................ 35 1.1.28 E1端口对接故障........................................................................................................... 36 1.1.29 E1误帧告警 ................................................................................................................. 37 1.1.30 HRB GE接口故障 ........................................................................................................ 37 1.1.31 VPU丢包告警 .............................................................................................................. 38 1.1.32 MPU信令面不通........................................................................................................... 38 1.1.33 时钟故障 ..................................................................................................................... 39 1.1.34 单板CPU占用率过高................................................................................................... 40 1.1.35 单板无法启动............................................................................................................... 40 1.1.36 业务框整框故障 ........................................................................................................... 41 1.1.37 LMT响应速度很慢 ........................................................................................................ 41 1.1.38 无法登录维护台 ........................................................................................................... 42 1.1.39 单板电压告警............................................................................................................... 42 1.1.40 单板风扇框故障 ........................................................................................................... 43 1.1.1 H248链路故障 故障现象 告警台显示“信令链路告警”,并指示是PPU单板产生的告警。 可能的原因有: 原因一 H248心跳SX3000没响应。 原因二 SX3000双归属状态异常,拒绝网关的建链请求 原因三 SCTP长时间拥塞。 原因四 IP网络风暴 原因五 故障原因 IP网络不通 原因六 IP地址冲突、MAC地址冲突,导致报文收发异常 原因五 配置操作原因: 集中转发配置关系不对,导致报文无法转发到PPU单板。 MPU板的路由配置得不对,导致目的不可达。 SCTP/H248 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 相关参数配置错误,。 H248链路双归属的MGC主从搞反。 去激活网关后没有激活网关。 故障处理方式与步骤: 步骤一 若H248的链路故障不能恢复。在维护台用PING命令选中PPU单板。从PPU单板PING对端的IFM单板。如果不能PING通,走步骤二。如果可以PING通走,步骤三 步骤二 在维护台从MPU集中转发单板PING对端SX3000的IFM单板。如果能PING通,内部转发存在问题,请通知研发人员定位。。如果还是不能PING,从MPU单板PING和IFM对接的S3526的接口地址。若不能PING通,信令面IP网络问题,和数通人员联系定位。如果能PING通IFM对接的S3526的接口地址,但是不能PING通IFM,请和Sx3000人员联系,可能是IFM单板问题。 步骤三 若以前业务都已经开通H248链路都正常,中途出现的H248链路故障可直接跳过此步。若是第一开通请注意检查以下各项: 1、 配置错误,LST SCTPINIT检查校验方式是否和Sx3000一致都为 CRC32。LST H248PARA检查编码为二进制,传输类型为SCTP,权 鉴类型为不使用。 2、 LST MGC检查主备MGC是否搞反。导致向备用的SX3000注册,而 Sx3000因双归属没有倒换而拒绝注册。 3、 若所有的H248链路都没有激活,DSP VMGW显示网关状态为未注册 态。执行DEA VMGW之后,执行ACT VMGW。再查看链路是否能激 排除故障 活。 步骤四 查看告警台H248链路故障前是否存在SCTP拥塞的告警。而且PPU的CPU占用率比较高。通过DSP IPIF查看IP接口瞬间流量是否非常大,确认是否存在网络风暴。不符合此条进入步骤五。 步骤五 LST SYSLOG 单板选择PPU单板,起始时间可以选择H248链路故障告警时间的前几分钟。查看日志是否有知识因H248心跳不通而拆除链路的日志。如有说明SX3000没有及时响应H248的心跳报文。联系Sx3000定位。 同时注意系统日志中是否有SCTP上报的错误。把这些信息发给研发人员分析定位。 步骤六 在Sx3000上对故障的链路进行SCTP的跟踪,打PPU的调试和日志开关。 。把跟踪消息发给研发人员分析定位。 步骤七 如果告警上看到H248链路故障之后,自己自动恢复了。属于H248链路闪断的情况。注意收集当时的所有告警信息,并按步骤五中指示收集日志信息。同时联系Sx3000人员收集SX3000的告警和日志等相关信息。把这些信息发给研发人员事后分析定位链路闪断的原因。 提示: 如果您仍然无法排除故障~请做好故障信息 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 并及时与负责该大区的研发人员取得联系。 1、 链路闪断,不影响当前的业务。只要收集定位信息,不要做其他操作。 2、 若所有的链路都故障,网关退出业务态。可以DEA VMGW之后ACT 应急建议 VMGW。 3、 以上都不能解决问题。参考Sx3000的处理措施。 1.1.2 H248链路闪断 告警台显示“信令链路告警”,并指示是PPU单板产生的告警。但告警很故障现象 快就可以恢复。 可能的原因有: 原因一 网络风暴 原因二 IP网络传输质量非常差,H248消息大量丢包。 原因三 故障原因 Sx3000不能正常响应MGW的H248的心跳报文。 原因四 链路负荷太重导致SCTP严重拥塞丢包。 原因五 IP地址冲突,MAC地址冲突。 原因六 以前碰到过Sx3000的IFM问题导致闪断。 故障处理方式与步骤: 步骤一 查看告警台,H248闪断前,是否有STCP的严重拥塞告警。若有LST SYSLOG收集对应PPU的系统日志和当时的所有告警信息。发给研发人员定位闪断的真正原因。 步骤二 如果链路始终在不断的闪断,通DSP IPIF和查看PPU的CPU占用率的方法确认是否存在网络风暴。若有网络风暴,联系数通人员排除。 步骤三 链路始终在不断的闪断,且没有网络风暴,从PPU单板PING对端IFM单板。报文数选择64。检查是否有大量的丢包现象。同时通过LST SYSLOG查看PPU的系统日志,证实是否存在心跳丢失现象。 步骤四 排除故障 若所有链路都在闪断,通过DSP VMGW检查当前正在注册的MGC是否主用MGC。若是备用MGC,要考虑Sx3000可能因双归属倒换没有激活,而不接收MGW的注册。联系Sx3000人员定位。 步骤五 检查本地或对端的局域网是否存在IP地址冲突,MAC地址冲突。 步骤六 LST SYSLOG查看PPU的SCTP断链原因。提供给研发人员定位。 步骤七 从Sx3000上查看SCTP的统计信息,查看是否存在大量的重传消息。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 1、 链路闪断,并能自动恢复。不影响当前的业务。只要收集定位信息, 不要做其他操作。 2、 若链路在不断的闪断,和研发人员联系。 应急建议 3、 以上都不能解决问题。参考Sx3000的处理措施。 1.1.3 M3UA链路故障 告警台显示“M3UA链路故障告警”,并指示是SPF单板产生的告警。且故障现象 长时间没有恢复 可能的原因有: 原因一 Sx3000上去激活了该链路 原因二 IP承载网不通 原因三 用于承载M3UA的SCTP长时间拥塞 故障原因 原因四 SPF单板的集中转发关系配置不正确 原因五 MPU板的路由配置不正确,导致到目的IP不通。 原因六 MGW和Sx3000上M3UA的配置不一致,四元组不一致。 故障处理方式与步骤: 步骤一 若M3UA的链路故障不能恢复。在维护台用PING命令选中SPF单板。从SPF单板PING对端的IFM单板。如果不能PING通,走步骤二。如果可以PING通走,步骤四 步骤二 在维护台从MPU集中转发单板PING对端SX3000的IFM单板。如果能PING通,内部转发存在问题,请通知研发人员定位。,很可能是集中转发配置问题。如果不能PING通,走步骤三。 步骤三 从MPU单板PING和IFM对接的S3526的接口地址。若不能PING通,信令面IP网络问题,和数通人员联系定位。如果能PING通IFM对接的S3526的接口地址,但是不能PING通IFM,请和Sx3000人员联系,可能是IFM单板问题。 步骤四 告警台上注意观察是否出现SCTP的拥塞且没有恢复的情况。有拥塞,通过DSP IPIF的查看收发包和检查CPU占用率的方式确认是否存在网络风排除故障 暴。若没有拥塞,进入步骤五 步骤五 检查Sx3000上是否去激活了此M3UA链路。 步骤六 对新开局点,注意检查Sx3000和TMG上的M3UALNK的配置是否一致。主要是关注四元组的一致性(本地IP、远端IP、本地PORT、远端PORT) 由于配置链路较多,一定要认真逐条检查。 步骤七 LST SYSLOG查看SPF的SCTP断链原因。提供给研发人员定位。 步骤八 从Sx3000上查看SCTP的统计信息,查看是否存在大量的重传消息。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 1、 如链路一直故障,没有定位的思路。请根据实际的情况考虑:倒换MPU 单板,再复位SPF单板。 应急建议 2、 参考Sx3000的处理措施,确认Sx3000是否启动保护集中,关闭链路。 1.1.4 M3UA链路闪断 告警台显示“M3UA链路故障告警”,并指示是SPF单板产生的告警。且故障现象 可以在短时间内恢复 可能的原因有: 原因一 网络风暴 原因二 UMG和SX3000之间的IP承载网传输质量非常差,时断时通 故障原因 原因三 Sx3000不能正常响应MGW的H248的心跳报文。 原因四 SCTP严重拥塞丢包 故障处理方式与步骤: 步骤一 查看告警台,M3UA闪断前,是否有STCP的严重拥塞告警。若有LST SYSLOG收集对应SPF的系统日志和当时的所有告警信息。发给研发人员定位闪断的真正原因。 步骤二 如果链路始终在不断的闪断,通DSP IPIF和查看SPF的CPU占用率的方法确认是否存在网络风暴。若有网络风暴,联系数通人员排除。 步骤三 链路始终在不断的闪断,且没有网络风暴,从SPF单板PING对端IFM单板。报文数选择64。检查是否有大量的丢包现象。 步骤四 排除故障 查看H248链路是否也存在闪断或故障的现象。若H248和M3UA链路同时出现闪断,那么很可能就是信令IP承载网的问题。 步骤五 LST SYSLOG查看PPU的SCTP断链原因。提供给研发人员定位。 步骤六 从Sx3000上查看SCTP的统计信息,查看是否存在大量的重传消息。和Sx3000配合一起定位 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 1、 链路闪断,并能自动恢复。不影响当前的业务。只要收集定位信息, 不要做其他操作。 应急建议 2、 若链路在不断的闪断,和研发人员联系,根据实际情况可以考虑:倒 换MPU单板,再复位SPF单板。 3、 和Sx3000配合一起定位解决。 1.1.5 MTP3链路故障 告警台显示“MTP3链路故障告警”,并指示是SPF单板产生的告警。且故障现象 长时间没有恢复 可能的原因有: 原因一 用于承载MTP3信令链路的E1故障。 原因二 时钟信号不好导致E1有误帧或滑码。 原因三 第一次开通时碰到的问题参照《UMG与端局对接操作指导文档》。 故 障 原 因 原因四 E1环回 原因五 链路码和链路发送码不一致 原因六 内部半永久连接不正常。 故障处理方式与步骤: 步骤一 使用"LST N7LNK"可以得到MTP3链路对应的MTP2链路号,再使用"LST MTP2LNK"可以知道该MTP3链路承载在哪个E1上。再查看此E1是否出现了传输故障。没有故障进入步骤二 步骤二 查看告警台是否出现了时钟丢失告警。DSP CLK 分别查询主备时钟单板是否是否正常。主备时钟同时出现丢失,应检查外部时钟是否正确输入。若主时钟丢失,备时钟正常,先检查BITS时钟输入线是否连接正常,之后可以考虑倒换CLK单板。 步骤三 查看E32和SPF所在框的NET时钟是否有NET时钟告警,也可以通过DSP NETCLKSIG查询业务框的验证NET时钟是否正常。若不正常,注意检查CLK单板的时钟分发线和NET时钟线是否插好插紧。 步骤四 排除时钟的原因之后,可以通过指定链路方式来跟踪MTP3的消息进一步定位问题所在。若跟踪的显示收到LINK_OUT_OF_SERVICE,进入步骤五。若跟踪到LINK_IN_SERVICE消息,进入步骤六。 步骤五 若跟踪的显示收到LINK_OUT_OF_SERVICE,说明是传输未对接好,导致MTP2没有定位成功。可以通过LOP E1内环链路对应的E1端口。如果内环之后,能跟踪到LINK_IN_SERVICE消息,可以进一步说明TMG设备内部没有问题。导致MTP2不能起来可能的原因是:E1端口故障、两端设备的E1传输顺序对错、两端的数据配置到同一E1的不同时隙等等。 若内环还收不到LINK_IN_SERVICE消息,说明TMG内部的板半永久存在问题。可以通过删除链路,再增加链路的方法解决问题。完成定位之后,排除故障 注意记得要取消内环回。 步骤六 若跟踪消息显示收到了LINK_IN_SERVICE。表明MTP2是可以定位成功的。正常情况应该是能发SLTM收到SLTA,收到SLTM发送SLTA。如果跟踪显示只有SLTM的收发,没有SLTA的消息。双击收发的SLTM消息分别查看其中的OPC和DPC是否期望的信令点编码,若不是期望值,就是配置问题。若收发SLTM的信令点都是期望值,但发现Send OPC = Receive OPC,且Send DPC = Receive DPC。收到的SLTM和发送的SLTM消息一模一样。说明传输出现了环回,可能是端口的软件环回,也可能是传输的物理环回。可以通过DSP E1LOP检查是否存在软件环回,若不存在就是物理传输环回。 步骤七 若跟踪消息显示有收发的SLTM,同时有单侧的SLTA消息。首先查看消息中的OPC和DPC是否是期望的信令点。很可能是一侧的N7三层的信令点数据配置错误。若信令点配置两端设备都没有问题。进入步骤七 步骤八 LST N7LNK查看链路码和链路发送码是否一致。不一致比较进行修改,让发送链路码和链路码一样,同时和对端的端局的链路码保持一致。 注意: CLK时钟单板的倒换操作~是指在LMT的面板通过CLK单板点右键的选择倒换菜单。和直接CLK复位有很大的差别。时钟CLK单板只能通过倒换方式才能真正是CLK时钟进行倒换。而不是简单的复位主用CLK的方式。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 1、 利用RMV N7LNK和RMV MTP2LNK把故障的链路删除,再从新配置 一遍。 应急建议 2、 检查TDM级连是否正常,不正常可以考虑TDM级连倒换。 1.1.6 MTP3链路闪断 告警台显示“MTP3链路故障告警”,并指示是SPF单板产生的告警。而故障现象 在短时间内可以恢复 可能的原因有: 原因一 时钟丢失或时钟不稳。 原因二 故E1帧失步,滑码。 障原因三 原 内部8260、8611有问题,会导致闪断 因 原因四 对端设备断链。 原因五 内部半永久连接不正常,有较大的误码。 故障处理方式与步骤: 步骤一 查看告警台是否出现了时钟丢失告警。DSP CLK 分别查询主备时钟单板是否是否正常。主备时钟同时出现丢失,应检查外部时钟是否正确输入。若主时钟丢失,备时钟正常,先检查BITS时钟输入线是否连接正常,之后可以考虑倒换CLK单板。 步骤二 查看E32和SPF所在框的NET时钟是否有NET时钟告警,也可以通过DSP NETCLKSIG查询业务框的验证NET时钟是否正常。若不正常,注意检查CLK单板的时钟分发线和NET时钟线是否插好插紧。 步骤三 若BITS时钟丢失,锁定的是线路时钟。由于有些链路时钟不能提供二级时钟精度,可以考虑修改三级时钟。 排除故障 步骤四 若还不能解决,利用LST SYSLOG查询TNU/NET/CLK/E32单板的系统日志。联系研发人员研发人员定位。 步骤五 和对端设备联系一起定位。 注意: CLK时钟单板的倒换操作~是指在LMT的面板通过CLK单板点右键的选择倒换菜单。和直接CLK复位有很大的差别。时钟CLK单板只能通过倒换方式才能真正是CLK时钟进行倒换。而不是简单的复位主用CLK的方式。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 1、 若BITS时钟丢失,锁定的是线路时钟。由于有些链路时钟不能提供二 级时钟精度,可以考虑修改三级时钟。 应急建议 2、 倒换CLK时钟单板。 3、 利用RMV N7LNK和RMV MTP2LNK把故障的链路删除,再从新配置 一遍 1.1.7 M3UA目的实体不可达 告警台显示“M3UA目的实体不可达”,并指示是SPF单板产生的告警。故障现象 而且长时间内不可以恢复 可能的原因有: 原因一 故所有的M3UA链路故障,具体原因参考“M3UA链路故障”小节。 障原因二 原 双归属倒换后SX3000没有激活链路。 因 原因三 没有添加到此目的实体相应的M3UA路由 故障处理方式与步骤: 步骤一 参考参考“M3UA链路故障”小节,排除M3UA链路。原因较多不再重述。 若不成功,进入步骤二 步骤二 检查此M3UA目的实体是否为直达实体,是否添加的相应的M3UA路由。 排除故障 步骤三 在Sx3000上M3UA对应的SCTP链路,查看Sx3000是否向MGW发起 建链。若没有请联系Sx3000人员定位。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研 发人员取得联系。 应急建议 尽快恢复一条M3UA链路 1.1.8 MTP3目的信令点不可达 告警台显示“MTP3目的信令点不可达”,并指示是SPF单板产生的告警。故障现象 而且长时间内不可以恢复 可能的原因有: 原因一 所有的MTP3链路故障,具体原因参考“MTP3链路故障”小节。 故原因二 障到目的信令点通过HSTP的迂回路由没有配置。 原 原因三 因 到HSTP通过另一HSTP的迂回路由没有配置。 原因四 对端设备故障,或数据配置丢失删除。 故障处理方式与步骤: 步骤一 直连的目的信令点。先检查直连链路为什么不能激活,再检查到HSTP的链路为什么不能激活。参考“MTP3链路故障”小节,排除MTP3链路故障。原因较多不再重述。 步骤二 对非直连的信令点,检查到HSTP是否有链路激活。若没有,先排除链路故障。若有激活的链路,检查是否有通过HSTP到目的信令点的路由。若没有就应该添加配置。 排除故障 步骤三 确保到HSTP通过另一HSTP的迂回路由已经配置,从而保证两个HSTP到端局的链路负荷均分。 步骤四 和对端设备或HSTP确认,对端设备是否故障。对端局原有的数据配置被删除或异常丢失。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 应急建议 尽量恢复一条MTP3的直达链路或到HSTP的链路 1.1.9 MGW退出业务态 故障现象 告警台显示“MGW退出业务告警” 可能的原因有: 原因一 信令IP承载网络不通。 原因二 故Sx3000不响应MGW的H248心跳报文。 障原因三 原 集中转发出现异常。 因 原因四 由于Sx3000的双归属状态未发生改变,不接收MGW的注册。 原因五 所有的H248链路故障,参考H248链路故障原因 故障处理方式与步骤: 步骤一 从MPU单板PING对端的IFM单板。验证IP信令承载网是否有问题。若不通,联系数通人员定位解决。若可以PING通,进入步骤二 步骤二 从PPU单板PING对端的IFM单板。若不通,很可能是集中MPU出现了问题。可以考虑倒换MPU单板。若可以PING通。 步骤三 打开MGW的H248跟踪,检查SX3000是否没有对MGW的H248链路心跳进行响应。若没有,联系Sx3000的人员定位。 排除故障 步骤四 观测告警台有MGW退出业务态告警,同时有H248链路在不断的闪断。打开MGW的H248消息跟着,查看Sx3000是否正确响应MGW的注册请求。若没有,说明Sx3000不接收MGW的注册。查看SX3000的双归属状态是否正确。 步骤五 若MGW显示处于业务态,但Sx3000显示非Normal。请联系Sx3000人员的定位。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 1、 DEA VMGW去激活当前网关,再ACT VMGW激活当前使用的网关。 2、 通过SET VMGW把链路心跳时长设置未0,关闭H248的链路心跳。 排除链路不响应的原因。 应急建议 3、 人工完成Sx3000的双归属切换。 4、 和Sx3000一起配合,尽快恢复一条H248链路。 5、 倒换MPU单板。 1.1.10 SCTP链路拥塞 故障现象 告警台出现“SCTP链路拥塞告警” 可能的原因有: 原因一 IP承载网络劣化,网络质量下降,导致报文丢失和拥塞。 原因二 网络风暴。 故原因三 障链路负荷不均匀。个别链路负荷太重。 原 原因四 因 承载业务的链路负荷太重,已经接近极限。 原因五 Sx3000的配置的SCTP接收缓冲区过小。 原因六 SCTP协议栈出问题,拥塞窗口自动调整失效。 故障处理方式与步骤: 步骤一 从PPU/SPF单板PING对端的IFM单板。验证IP信令承载网是否有丢包现象。若有,联系数通人员定位解决。 步骤二 DSP IPIF查看IP报文统计信息,是否增长的非常快。同时PPU的CPU占用率比正常情况高出很多。判断是否有网络风暴的存在。 步骤三 若出现有些链路拥塞,而有些正常时。Mc接口的链路拥塞,通过性能台,查看各PPU处理的H248报文数是否相当。M3UA链路拥塞,注意查看各排除故障 SPF的转发报文是否相当。是存在有个别的PPU/SPF负荷过高。 步骤四 根据性能台话统的结果。和各单板的性能指标比较,确认是否因业务量太大已经接近单板处理能力的极限。 步骤五 LST SYSLOG查看PPU/SPF的日志信息,发给研发人员定位。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 1、 放大Sx3000的配置的SCTP接收缓冲区。 2、 增加链路条数,达到间接放大SCTP的缓冲区的目的。 应急建议 3、 增加PPU/SPF处理单板。 1.1.11 SX3000电路不空闲 故障现象 Sx3000上动态查询电路状态显示不空闲,是Fault或Unkown。 可能的原因有: 原因一 E1端口故障。 原因二 M3UA链路双活。 故 原因三 障 原目的信令点不可达。 因 原因四 网关退出业务态。 原因五 对端局数据配置错误,或未配置。ISUP电路配成TUP电路。 故障处理方式与步骤: 步骤一 若Sx3000查询到,一个TMG下属的所有电路都不空闲。应检查TMG的状态是否未注册态,在Sx3000上MGW是否为Normal。 步骤二 若到某一个局向的所有电路都不空闲,注意查看是否到此端局目的信令点不可达。 步骤三 若到有些端局的部分电路为FAULT,在TMG上找到对应的物理E1。检查E1是否物理故障。 步骤四 如果到某些局向的部分电路为Unkown,在TMG上查看M3UA链路是否到排除故障 主备MGC出现了双活。导致主用Sx3000的电路复位消息发送到备用的Sx3000上。从而造成电路状态不可知。 步骤五 和对端局链路,确认是否存在数据配置错误,或未配置。ISUP电路配成TUP电路等等。 步骤六 和Sx3000的人员联系定位解决。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 以上步骤无法排除故障,可以根据实际情况: 应急建议 1、 在Sx3000上复位电路。 1.1.12 M3UA链路负荷分担不均匀 SPF的各单板的CPU占用率不相同。性能台话统各单板对应的M3UA链故障现象 路的接收和发送的消息数有比较大的差别。 可能的原因有: 原因一 故链路掩码配置错误。 障原因二 原 路由掩码配置错误。 因 原因三 Sx3000和端局选择电路CIC不均匀。导致链路负荷不均衡。 故障处理方式与步骤: 步骤一 从性能台话统查看各单板对应的M3UA链路的接收和发送的消息数。找出负荷较大的链路号。 步骤二 LST M3UADE检查用于选择同一目的实体的不同路由的“链路选择掩码”是否为15。若不为15,请恢复为缺省的15。 步骤三 排除故障 LST M3UALKS检查用于选择同一链路集中不同链路的“链路选择掩码”是否为缺省的15。若不是请修改为15。 步骤四 从SX3000上查看相关的话统,查看到相关局向的CIC是否均匀。不均匀请联系Sx3000人员修改。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 应急建议 1.1.13 MTP3链路负荷分担不均匀 SPF的各单板的CPU占用率不相同。性能台话统各单板对应的MTP3链路故障现象 的接收和发送的消息数有比较大的差别。 可能的原因有: 原因一 链路掩码配置错误。 故原因二 障路由掩码配置错误。 原 原因三 因 Sx3000和端局选择电路CIC不均匀。导致链路负荷不均衡。 原因四 N7链路优先级配置错误 故障处理方式与步骤: 步骤一 从性能台话统查看各单板对应的MTP3链路的接收和发送的消息数。找出负荷较大的链路号。发送不均衡走步骤二,接受不均衡走步骤五 步骤二 LST N7DSP检查用于选择同一目的实体的不同路由的“链路选择掩码”是否为15。若不为15,请恢复为缺省的15。 步骤三 LST N7LKS检查用于选择同一链路集中不同链路的“链路选择掩码”是否为缺省的15。若不是请修改为15。 步骤四 排除故障 LST N7LNK检查到同一端局的所有直达链路的优先级是否一样。 步骤五 和端局联系,确认端局的发送的ISUP消息是负荷均匀在所有MTP3链路上的。一起定位原因。 步骤六 从SX3000上查看相关的话统,查看到相关局向的CIC是否均匀。不均匀请联系Sx3000人员修改。 提示: 如果您仍然无法排除故障~请做好故障信息记录并及时与负责该大区的研发人员取得联系。 1、 只要保证到同一端局的不同MTP3链路负荷是均衡就可以。到不同端 局,由于受业务量大小的影响,链路负荷不均衡是比较正常的。若因应急建议 此原因导致SPF的CPU占用率有较大的差别,也可以考虑调整各SPF 上的链路分布。 1.1.14 信令通,语音双不通(许多电话) 根据语音不通的影响面,分为: 1 某个UMG下带的用户信令通,语音双不通(IP侧有问题的可能性比较大)。 故障现象 2 某个UMG下挂的某个局向的用户信令通,语音双不通(TDM侧有问题的 可能性比较大)。 3 某两个UMG之间的电话语音总是双不通(IP侧有问题的可能性比较大)。 一路电话电话接通后,语音面的流程如下,分省际电话(包括省际固话和省际联通)和省内电话。 省际电话的语音面流程如下(譬如用户从1框14槽E32接进来,从2框8槽HRU出去,VPU和HRU都在2框),为TDM-IP的电话,UMG内部如果E32和VPU不在同一个框,需要走TDM级连,如果VPU和HRU不在同一个框,需要走GE级连。 E32 TCLU TNU 端局 等 (1) NET VPU TCLU BLU HRU 另一个UMG 光口局 省内电话的语音面流程如下(譬如用户从1框14槽E32接进来,从2框8槽E32出去,为TDM-TDM的电话,UMG内部如果两个局向所接的E32不在同一个框,需要走TDM级连,TDM-TDM电话不需要VPU,HRU单板参与。 故障原因 E32 TCLU TNU 端局 等 (1) E32 TCLU BLU 关口局 上图中任何一段出现问题都会导致语音有问题(包括语音双不通、单通、噪音),出问题时需要使用环回或录音的方法逐段(呼叫经过的两个UMG都需要)进行排查。 可能的原因有: 原因一 SX3000上的CIC与UMG上的TID对应关系错误。 原因二 传输连线错误(一般都是两根线都接错了)。 原因三 GE接口故障(此时已经在线的呼叫出现语音双不通,新的呼叫无法上线)。 原因四 承载网有问题,双不通。 原因五 级连连线错误。 故障处理方式与步骤: 排除故障 步骤一 如果是某个UMG下挂的用户基本上都是信令通语音双不通的现象,基本可 以确定是IP侧承载网的问题。请在UMG8900的维护台上使用PING命令,从HRU板PING全国其他UMG的GE口的IP地址,检测承载网是否正常(注意:PING之前请确认各UMG HRU板的缺省路由已经添加)。如果PING不通,请分段进行检测。首先PING和UMG直连的NE40的接口地址,如果不通,请使用DSP IPIF查看UMG8900上GE接口状态。如果为Down,请确认光纤连接是否有松动的情况,UMG和NE40上光口的协商方式配置是一致的,并尝试倒换HRU单板恢复故障。如果UMG上GE口是UP的,而有PING不通对端的UMG,请联系承载网相关人员处理。 步骤二 如果是某个UMG下的某个局向大部分电话出现信令通语音双不通的现象,基本可以确定是TDM侧的问题。请在UMG的面板上查看到局向的E1状态是否正常,使用DSP E1LOP查看E1是否存在环回的情况。 步骤三 检查SX3000上CIC与UMG的对应关系,检查步骤如下: 1 根据UMG下挂的局向,在SX3000上使用LST N7TKC查询到这些局向的中继电路及其对应的TID。 2 在UMG上使用LST TDMIU显示出TID和各物理单板板组号的对应关系。 3 在UMG上使用DSP BRD显示出板组好和单板框槽号的对应关系。 4 根据上述三步的信息得到SX3000上配置的CIC和UMG上物理时隙的对应关系。 步骤四 检查对端局与SX3000上CIC的配置,确认同一个CIC是否对应到了同一个E1的同一个时隙。 步骤五 以上方法无法定位时,可以打一路测试电话进行定位(如果打一次没有出现语音双不通,多打几次)。呼叫测试电话前请打开SX3000的用户接口跟踪(跟踪H248和ISUP,BICC的消息)。电话接通后让其一直在线。查看SX3000上跟踪到H248消息(ADD REPLY消息),获得此次呼叫的context id。在UMG上使用DSP CTXINFO获取此次呼叫相关的端点信息。确认TDM端点在哪块E32(或S2L)的哪个时隙上,IP端点在哪个VPU上。使用DSP VPURTP查看该呼叫RTP报文的统计信息,如果报文很少,说明是IP侧的问题,请使用PING命令逐段检测。使用LOP E1命令在该呼叫所在的E1上进行外环回,请TDM侧的用户听回声,如果能听到自己的声音,说明TDM侧没问题。否则TDM侧有问题,请按照步骤三、步骤四检查数据,并确认端局/关口局没有问题。 步骤六 如果确认TDM侧,IP都没有问题,可能是UMG内部处理有问题,请检查级联联线,各级联接口指示灯的状态,各级联单板的运行状态。同时请及时与UMG研发人员联系。 步骤七 语音问题(包括后面的单通/噪音问题)也可以使用录音的方法进行定位,由于需要使用调试台,不建议技术支援的兄弟使用,如需使用请UMG的研发人员联系,具体使用方法参见如下文档: 步骤八 如果定位到是UMG内部处理的问题,可以打开UMG的调试台,登录到对应的VPU上,使用VPU的环回命令进行定位,步骤如下: 1执行 CP showcall 命令,查询上下文ID对应呼叫分配的TCCB索引cbindex以及Flowid。 2执行 chn showcb tc cbindex<0~2047> M,查询该TCCB分配的TC资源在哪个DSP芯片的哪个通道上,即获得该呼叫分配的TC标识 Dspid,Chnid。 3执行NP VPU readbyflowid flowid lag2ipflowinfo 命令可以查询到IP 端点配置的信息。 4执行tc chnstat flowid dspid chnid 命令可以查询到该呼叫TC的收发报文统计信息。 5执行TC dsploop chip 2 chn chn 命令,通过电话试听是否可以清晰听见自己说话的声音。如果可以听到自己声音,说明TDM端点正常,问题可能出现在IP端点侧。如果仍然没有声音或是噪声,说明噪声来源在TDM侧。如果TDM侧有问题,请于UMG研发人员联系。 注:回环测试完毕后,需要执行tc dsploop chip 0 chn chn 命令解除环回设置。 6执行TC chnstat flowid chip chn 命令,查看分配TC的统计信息,重点关注BadFrame 计数和NoFrame 计数,多执行几次,如果错误统计不断增长,则故障主要在IP侧。 7 如果故障在IP侧,请用调试台登录0框的主用NET板,使用mntquery gepacket all定位内部GE的问题(能看到Hello报文、G729报文、G711报文在GE面的收发统计信息)。也可以使用LOP GE定位HRU和VPU之间GE通道的好坏。 应急建议 如果对外GE接口有故障,倒换HRU单板,看能否恢复故障。 1.1.15 信令通,语音双不通(个别电话随机出现) 故障现象 随机出现个别用户电话接通后语音双不通的情况 可能的原因有: 原因一 SX3000上的CIC与UMG上的TID对应关系错误。 原因二 传输连线错误(一般是收发两根线都接错了)。 原因三 故障原因 ADD FRM中级联板组号配置错误,应当与ADD FRMLNK中的配置的BLU的板组号一致。 原因四 同一路呼叫在两个UMG上使用的编解码类型不一样(SX3000下发得不一致)。 故障处理方式与步骤: 步骤一 请做好用户访谈(或自己反复拨打),联系几个出现过语音双不通的用户,当其电话再次出现语音双不通时,请其不要挂电话(同时用其他方式联系到被叫,让其不挂电话),联系相关人员进行问题定位。 步骤二 使用DSP CONTMOUT根据时长显示目前在线的用户,多查几次(譬如用户在线30秒、1分钟、5分钟),判断出话音双不通的呼叫,获得其端点信息(一个TDM端点,一个IP端点或者两个TDM端点)。 步骤三 DSP TDMSTAT根据TDM端点的TID获取到Context ID。 步骤四 DSP CTXINFO获取到会话信息和相关的端点索引。 步骤五 DSP TERMINFO根据端点索引获取到端点的进一步信息(譬如IP端的IP地址和端口号)。 步骤六 DSP VPUOLUSE获取IP端点的详细信息(譬如编解码类型),需要确认与对端UMG设备的分配的编解码类型,打包时长是否一致。如果编解码类型不一致,说明SX3000下发的编解码类型不一致,请检查SX3000上的排除故障 配置。如果打包时长不一致,请使用LST TCPARA检查UMG上的配置。 步骤七 DSP VPURTP获取该路呼叫RTP统计信息,连续获取几次,如果两个UMG的发送都正常,基本上没有收到多少RTP报文,说明承载网有问题,请使用PING进一步进行定位并与承载网的相关人员联系。如果没有RTP报文发送出去,请与UMG的研发人员联系。 步骤八 如果确认IP侧没有问题,那么可以确认是TDM侧有问题或内部处理有问题。请使用LOP E1环回该呼叫的TDM端点所在的E1,用户听回声,如果听不到回声,说明TDM侧有问题,请检查SX3000上CIC与UMG上TID的对应关系以及传输联线是否正确。 注:环回后一定注意取消环回。 步骤九 请用LST FRM检查级联板组号配置是否正确,必须和ADD FRMLNK配置的BLU的板组号一致。 步骤十 请检查内部级连联线,级联接口指示灯,级连单板(BLU TCLU TNU NET)运行状态,使用LOP GE检查从VPU到HRU的内部GE 通道是否正常,并与研发人员联系。 应急建议 1.1.16 信令通,语音单通(许多电话) 根据语音单通的影响面,分为: 1 某个UMG下带的用户信令通,语音单通(IP侧有问题的可能性比较大)。 故障现象 2 某个UMG下挂的某个局向的用户信令通,语音单通(TDM侧有问题的可能性比较大)。 3 某两个UMG之间的电话语音总是单通(IP侧有问题的可能性比较大)。 语音面的流程参考语音双不通的案例,定位语音单通问题的方法和定位语音双不通问题的方法类似,可以采用分段环回或录音的方法。 可能的原因有: 故障原因 原因一 承载网单通。 原因二 传输连线错误(导致单通一般是收发两根线接错了一根)。 故障处理方式与步骤: 步骤一 承载网单通的问题可以在UMG8900的维护台上使用PING命令进行定位。1 从HRU板PING全国其他UMG的GE口的IP地址,检测承载网是否正常(注意:PING之前请确认各UMG HRU板的缺省路由已经添加),如果PING不通,则承载网络可能是单通或者双不通。 2 如果PING不通,请分段进行检测。首先PING和UMG直连的NE40的接口地址,如果不通,请使用DSP IPIF查看UMG8900上GE接口状态。如果为Down,请确认光纤连接是否有松动的情况,并尝试倒换HRU单板恢复故障。具体进一步定位请与研发人员联系。 3 如果能PING通,说明UMG到NE40的GE连接是好的,可以继续PING 和NE40相连的NE80的接口地址等,并联系承载网的相关人员进行定位。 如下图(两个大区UMG通过承载网的连接图)。 NE40-1 NE80-1 UMG1 排除故障 NE40-2 NE80-2 UMG2 步骤二 检查SX3000上CIC与UMG的对应关系,检查步骤如下: 1 根据UMG下挂的局向,在SX3000上使用LST N7TKC查询到这些局向的中继电路及其对应的TID。 2 在UMG上使用LST TDMIU显示出TID和各物理单板板组号的对应关系。 3 在UMG上使用DSP BRD显示出板组好和单板框槽号的对应关系。 4 根据上述三步的信息得到SX3000上配置的CIC和UMG上物理时隙的对应关系。 步骤三 检查对端局与SX3000上CIC的配置,确认同一个CIC是否对应到了同一个E1的同一个时隙。 步骤四 以上方法无法定位时,可以打一路测试电话进行定位(如果打一次没有出现语音单通,多打几次)。 1 呼叫测试电话前请打开SX3000的用户接口跟踪(跟踪H248和ISUP,BICC的消息)。电话接通后让其一直在线。 2 查看SX3000上跟踪到H248消息(ADD REPLY消息),获得此次呼叫的context id。 3 在UMG上使用DSP CTXINFO获取此次呼叫相关的端点信息。确认TDM端点在哪块E32(或S2L)的哪个时隙上,IP端点在哪个VPU上。 4 使用DSP VPURTP查看该呼叫RTP报文的统计信息,如果报文很少,说明是IP侧的问题,请使用PING命令逐段检测。 5 使用LOP E1命令在该呼叫所在的E1上进行外环回,请TDM侧的用户听回声,如果能听到自己的声音,说明TDM侧没问题。否则TDM侧有问题,请按照步骤二、步骤三检查数据,并确认端局/关口局有没有问题。 注:环回后一定注意取消环回。 步骤六 如果确认TDM侧,IP都没有问题,可能是UMG内部处理有问题,请检查级联联线,各级联接口指示灯的状态,各级联单板的运行状态。使用LOP GE检查VPU和HRU间内部GE通道是否正常。同时请及时与UMG研发人员联系。 应急建议 1.1.17 信令通,语音单通(个别电话随机出现) 故障现象 随机出现个别用户电话接通后语音单通的情况 可能的原因有: 原因一 SX3000上的CIC与UMG上的TID对应关系错误。 原因二 故障原因 传输连线错误。 原因三 ADD FRM中级连板组号应当与ADD FRMLNK中的配置一致。请用LST FRM和LST FRMLNK检查这两个配置。FRM配错了将导致GE面有问题,FRMLNK配错了将导致TDM平面有问题。 故障处理方式与步骤: 步骤一 请做好用户访谈(或自己反复拨打),联系几个出现过语音单通的用户,当其电话再次出现语音单通时,请其不要挂电话(同时用其他方式联系到被叫,让其不挂电话),联系相关人员进行问题定位。 步骤二 使用DSP CONTMOUT根据时长显示目前在线的用户,多查几次(譬如用户在线30秒、1分钟、5分钟),判断出话音单通的呼叫,获得其端点信息(一个TDM端点,一个IP端点或者两个TDM端点)。 如果是自己反复拨打,可以在SX3000上打开用户接口跟踪,直接获取到Context ID。 步骤三 DSP TDMSTAT根据TDM端点的TID获取到Context ID。 步骤四 DSP CTXINFO获取到会话信息和相关的端点索引。 步骤五 DSP TERMINFO根据端点获取到端点的进一步信息(譬如IP端的IP地址和端口号)。 步骤六 DSP VPUOLUSE获取IP端点的详细信息(譬如编解码类型),需要确认 排除故障 与对端UMG设备的分配的编解码类型,打包时长是否一致。如果编解码类型不一致,说明SX3000下发的编解码类型不一致,请检查SX3000上的配置。如果打包时长不一致,请使用LST TCPARA检查UMG上的配置。 步骤七 DSP VPURTP获取该路呼叫RTP统计信息,连续获取几次,如果两个UMG的发送都正常,基本上没有收到什么RTP报文,说明承载网有问题,请使用PING进一步进行定位并与承载网的相关人员联系。如果没有RTP报文发送出去,请与UMG的研发人员联系。 步骤八 如果确认IP侧没有问题,那么可以确认是TDM侧有问题或内部处理有问题。请使用LOP E1外环回该呼叫的TDM端点所在的E1,用户听回声,如果听不到回声,说明TDM侧有问题,请检查SX3000上CIC与UMG上TID的对应关系以及传输连线是否正确。 注:环回后一定注意取消环回。 步骤九 请用LST FRM检查级联板组号配置是否正确,必须和ADD FRMLNK配置的BLU的板组号一致。 步骤十 请检查内部级连连线,级联接口指示灯,级联单板(BLU TCLU TNU NET)运行状态。使用LOP GE检查VPU和HRU间的内部GE通道是否正常。并与研发人员联系。 应急建议 1.1.18 用户听见自己的声音 故障现象 呼叫接通后,一侧用户或两侧用户同时听见自己的声音。 可能的原因有: 原因一 传输环回。 原因二 故障原因 E1端口软件环回。 原因三 承载网有环路。 故障处理方式与步骤: 步骤一 打开告警台,观察是否有E1端口环回告警,如果有,使用LOP E1将环回取消。如果环回取消后,用户依然听到自己的声音,请按下述步骤处理。 步骤二 请做好用户访谈(或自己反复拨打),联系几个出现过听见自己声音的用户,当其电话再次出现此现象时,请其不要挂电话(同时用其他方式联系到被叫,让其不挂电话),联系相关人员进行问题定位。 步骤三 使用DSP CONTMOUT根据时长显示目前在线的用户,多查几次(譬如用户在线30秒、1分钟、5分钟),判断出话音单通的呼叫,获得其端点信息(一个TDM端点,一个IP端点或者两个TDM端点)。 如果是自己反复拨打,可以在SX3000上打开用户接口跟踪,直接获取到Context ID。 步骤四 DSP TDMSTAT根据TDM端点的TID获取到Context ID。 步骤五 DSP CTXINFO获取到会话信息和相关的端点索引。 排除故障 步骤六 DSP TERMINFO根据端点获取到端点的进一步信息(譬如IP端的IP地址和端口号)。 步骤七 使用LOP E1内环回该呼叫的TDM端点所在的E1,用户听不到自己的声音了,说明回声是由TDM侧产生的,请检查SX3000上CIC与UMG上TID的对应关系以及传输连线是否正确。 注:环回后一定注意取消环回。 步骤八 请用LST FRM检查级联板组号配置是否正确,必须和ADD FRMLNK配置的BLU的板组号一致。 步骤九 请检查内部级连连线,级联接口指示灯,级联单板(BLU TCLU TNU NET)运行状态,并于研发人员联系。 步骤十 除上述办法外,可以使用录音的办法进行定位。 应急建议 1.1.19 电话接通后语音质量不好 故障现象 电话接通后语音质量不好,如有噪音、流水声、马蹄声、断继感、回音等。 可能的原因有: 原因一 同一种编解码类型在两个UMG上配置的打包时长不一致。 原因二 时钟丢失或者时钟不稳。 原因三 承载网丢包,有丢包告警。 故障原因 原因四 E32误帧或滑码。 原因五 TC有问题。 原因六 用户使用的话机有问题。 故障处理方式与步骤: 步骤一 查看告警台,如果丢包告警,DSP VMGWRSC查看当前在线的用户数,看 是否超过了 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 的Erl数(0.7)。同时通知相关人员查看承载网的网管,看承 载网有无相关告警产生。 步骤二 DSP CLK查看时钟状态是否为跟踪太,且主用时钟为2Mbits时钟。DSP NETCLKSIG查看各框NET板的时钟是否正常。如果时钟有问题,请参照 相关章节排除时钟故障。 排除故障 步骤三 查看有无E32误帧或滑码的事件告警。一两个这种告警可以不用处理,如 果很多,对话音质量有影响,参照相关章节进行处理。 步骤四 LST TCPARA查看打包时长在该路呼叫所经过的两个UMG上配置是否一 致。如果不一致使用MOD TCPARA修改为一致。 步骤五 参照语音单通或双不通的定位方法,使用环回等进一步定位哪段有问题。 应急建议 1.1.20 呼叫接续失败 故障现象 呼叫接续失败 可能的原因有: 原因一 CMU不在资源组。 原因二 没有VPU在资源组。 原因三 没有可用的TC资源。 原因四 IP承载不可用 原因五 故障原因 E1故障。 原因六 呼叫量太大,SX3000开始了流控。 原因七 M3UA链路双活(参考相关故障诊断处理)。 原因八 所有M3UA链路故障(参考相关故障诊断处理)。 原因九 所有H248链路故障(参考相关故障诊断处理)。 故障处理方式与步骤: 步骤一 打开SX3000的用户接口跟踪,跟踪H248,ISUP,BICC等消息。 步骤二 分析跟踪到的消息。 1 看端局有没有送过来IAM消息。如果没有收到IAM消息,请打开UMG上的MTP3、M3UA跟踪(话务量很低时才能打开),观察MTP3上能否能跟到该用户的IAM消息。如果没有,说明端局没有送IAM消息过来,请与局方联系解决。 2 如果MTP3上跟到了,M3UA上没有跟到,请LST M3UADE看目的信令点编码有没有配错,应当设置为SX3000的信令点编码,LST OFI STP功能需要使能。如果M3UA上跟到了IAM消息,说明SX3000收到IAM消息后没有交给高层(如ISUP)处理,请联系SX3000相关人员解决。 步骤三 排除故障 如果有H248增加端点,修改端点失败的消息(观察H248的Reply消息),与网关有关。如果增加TDM端点失败,LST RSPRSC检查CMU是否已配置到资源组中,检查E1状态是否正常。如果增加IP端点失败,请检查是否有可用TC资源(在面板上用右键查询),IP承载是否正常(DSP BEARREL检查承载是否使能)。 步骤四 如果SX3000收到了BICC回的ACM消息,并没有给端局回ACM消息,请在SX3000上使用DSP M3DE检查端局的目的信令点是否可达。如果不可达,请检查SX3000上是否配置了到该端局M3UA路由(DSP M3RT)。 步骤五 查询SX3000上WCCU板的CPU占有率,如果稳定在一个比较高的值,说明SX3000已经开始了流控,对部分入局呼叫不再处理,造成呼叫接续失败。 应急建议 1.1.21 用户通话过程中电话掉线 故障现象 用户通话过程中电话掉线 可能的原因有: 原因一 E1故障。 原因二 故障原因 删除承载关系。 原因三 其他(需要跟踪到其信令才能分析到)。 故障处理方式与步骤: 步骤一 如果有用户反馈经常掉线,可以在SX3000打开针对此用户的用户接口跟踪,根据抓到的信令分析其呼叫过程中出现掉线的原因。 步骤二 如果有UMG通过H248上报的TDM端点故障引起掉线的消息,请查询UMG的历史告警,确认是E1故障引起的。E1故障的原因请参考相关的案排除故障 例进行诊断。 步骤三 如果有UMG通过H248上报的IP端点故障引起掉线的消息,请查询UMG的操作日志,确认有无删除承载关系的操作。 步骤四 其他问题请与UMG的研发人员联系。 应急建议 1.1.22 资源占有率过高分析 故障现象 TC的资源占有率过高。 可能的原因有: 原因一 有资源吊死。 故障原因 原因二 话务量大。 故障处理方式与步骤: 步骤一 使用DSP CONTMOUT查询超过某一时间的会话(如3600秒)。如果超长会话很多,说明有资源吊死的情况。 步骤二 具体定位一个会话是否已吊死,可以根据该会话中的TDM端点对应的排除故障 SX3000上的CIC状态是否为占用来判断,如果SX3000上CIC的状态为“占用”,则该会话为超长会话,如果为“空闲”则为资源吊死。 步骤三 查看话统,确认此时是否话务量很大。如果话务量,确认此时有无出现丢包告警,如果出现,查看新建呼叫的IP端点使用的编解码是否为G.729,如果为G.711,请与SX3000相关人员联系。 应急建议 1.1.23 呼叫日志分析 故障现象 LST LOG查询呼损日志有记录存在 请看呼损日志分析专用文档。 故障原因 排除故障 应急建议 1.1.24 M3UA链路双活 UMG告警台上没有M3UA链路故障告警。 故障现象 UMG上所有M3UA链路处于激活状态。 如果UMG注册在备用Server上,基本所有的呼叫能够正常接续。 可能的原因有: 原因一 故障原因 主备用SX3000的双归属状态都是Active(可以使用DSP DHSTA查询, 具体怎么出现的请与SX3000的研发人员联系)。 故障处理方式与步骤: 步骤一 使用DSP M3UALNK查询所有M3UA链路状态,确认是否都是激活态。 排除故障 步骤二 在目前不工作的SX3000上去激活到此UMG的M3UA链路。 应急建议 在不工作的SX3000上去激活M3UA链路 1.1.25 UMG到主用Server的链路断掉后,无法正常注册备Server UMG处于退出业务态。 故障现象 所有H248链路处于故障态(可以看告警台)。 可能的原因有: 原因一 主备Server之间的心跳是好的,SX3000并没有进行双归属倒换,但是UMG 到主用Server的所有H248链路故障。 故障原因 原因二 备用Server上的配置数据(包括H248,SCTP)与UMG上的配置数据不 一致。 故障处理方式与步骤: 步骤一 查询主备SX3000的双归属状态(使用DSP DHSTA),确认SX3000是否发生了双归属倒换。 步骤二 如果SX3000发生了双归属倒换,UMG无法正常注册到备用Server,请按如下步骤定位: 1 通过PPU PING SX3000的接口地址。 2 如果不通,通过MPU PING SX3000的接口地址。如果还不通,说明承载网或SX3000有问题。 3 通过其他的UMG PING SX3000的地址,如果能通,说明SX3000没有排除故障 问题,请与承载网相关人员联系。 4 如果还是不通,请与承载网或SX3000的相关人员联系。 步骤三 1 如果能PING通,请检查SX3000和UMG上的配置数据是否一致。 2 LST SCTPINIT校验和算法应当是CRC32。 3 LST H248PARA应当使用二进制编码、不使用鉴权。 4 LST H248LNK检查本地IP,本端端口,远端IP,远端端口四元组是否与SX3000上的配置一致。 步骤四 如果通过MPU可以PING通,通过PPU PING通,说明UMG的集中转发有问题,请与UMG的研发人员联系。 应急建议 如果定位到是集中转发的问题,倒换一下MPU板看故障是否能够恢复。 1.1.26 双归属倒换后呼叫不能接续 故障现象 发生双归属倒换后某UMG下挂的用户电话无法接续 双归属倒换包括几个部分: 1 Mc接口倒换到备用Server上,即UMG注册到备用Server上并处于业务态(可以用DSP VMGW命令查询)。 2 备用Server激活了所有到UMG的M3UA链路,同时到主用Server的M3UA不能处于激活状态(即不能有双活的情况)。 3 备用Server接管所有以前主用Server管理的ISUP电路,倒换完成后应当处于空闲态。 4 BICC能正常倒换,此部分和UMG不相关,请参考SX3000的相关 资料 新概念英语资料下载李居明饿命改运学pdf成本会计期末资料社会工作导论资料工程结算所需资料清单 。 故障原因 上述任何一步有问题都会导致双归属倒换后电话不能正常接续。 原因一 UMG没有处于业务态。 原因二 M3UA链路没有正常激活。 原因三 SX3000上的电路没有空闲。 故障处理方式与步骤: 步骤一 DSP VMGW检查UMG是否处于业务态,如果没有处于业务态,请参考相关案例进行诊断。 步骤二 DSP M3UALNK检查M3UA链路是否已激活并且没有双活的情况出现,如果M3UA链路没有激活或出现双活的情况,请参考相关案例进行诊断。 排除故障 步骤三 请确认SX3000上到该UMG下挂的局的电路是否已经空闲,如果没有空闲,请SX3000的相关人员联系。 步骤四 如果前述三个步骤没有问题,请打开SX3000的用户接口跟踪,打一路电话,定位电话不能接续的原因,具体过程请参考“电话不能正常接续”故障诊断案例。 应急建议 1.1.27 双归属倒换后M3UA链路不能激活 故障现象 发生双归属倒换后某UMG下挂的用户电话无法接续 可能的原因有: 原因一 承载网有问题。 原因二 故障原因 集中转发有问题。 原因三 SX3000没有激活链路。 原因三 SX3000和UMG上的配置不一致。 故障处理方式与步骤: 步骤一 通过MPU PING SX3000的地址,如果不能PING通,请检查承载网,网络连线,SX3000是否有问题。 步骤二 通过SPF PING SX3000的地址,如果不能通而通过MPU可以PING通过,说明集中转发有问题,请使用LST IPFWD确认集中转发是否已经配置。如果已经配置还存在问题,请用DSP IPFWD查看转发报文统计信息,同时排除故障 请与UMG研发人员联系。 步骤三 打开SX3000 SCTP跟踪,观察是否有Init报文发出,如果没有,说明SX3000没有激活链路,请在SX3000上使用ACT M3LNK激活M3UA链路。 步骤四 LST SCTPINIT校验和算法应当是CRC32。LST M3UALNK四元组(本地IP,本端端口,远端IP,远端端口)的配置要与SX3000一致。 应急建议 如果定位到是集中转发的问题,倒换一下MPU板看故障是否能够恢复。 1.1.28 E1端口对接故障 故障现象 E1端口对接故障 可能的原因有: 原因一 时钟故障:包括(时钟源与CLK单板之间的配线连接故障、CLK与NET单板之间的时钟配线故障) 故障原因 原因二 配置错误:包括(两端设备的帧格式和线路编码格式) 原因三 传输故障:E1电缆收发是否接反 故障处理方式与步骤: 步骤一 使用DSP E1PORT查看故障端口告警信息,根据告警信息来确定故障原因。正常情况下所有告警都应该是OFF。如果有故障为ON,请参考下面说明: 一下故障首先都要确认时钟是否正常。 LOS:红色告警,表示信号丢失,原因是传输故障、两端设备线路码型不一致。请确认传输是正常的,线路码型是否和对方设置成一致。 AIS:蓝色告警,原因是检测到对端设备故障。请和端局维护人员联系。 RRA:黄色告警,原因是检测到对方发过来的告警信息,指示对方不可用。请和端局维护人员联系。 LFA:帧丢失告警,原因是时钟故障或者两端线路码型不一致。请检查两端线路码型是否设置成一致。 LMFA:复帧丢失告警,原因是两端设备帧格式设置不一致。请检查两端两端帧格式是否一致。 步骤二 排除故障 查看告警台是否有关于时钟的告警。如果有频偏告警或者NET检测时钟异常,参考时钟故障部分说明。 步骤三 在DDF架上将故障端口环回,看是否还有告警,如果还存在告警,复位该端口,如果还不行,证明此端口已经损坏。只有更换单板。注意解除环回。 步骤四 执行:LOP E1: FN=xx, SN=xx, LOC=PORT, MODE=OUTLOP, PN=xx;确认对端设备是否还存在故障。如果故障,联系对方解决。 执行:LOP E1: FN=xx, SN=xx, LOC=PORT, MODE=DELLOP, PN=xx;解除端口环回状态。 步骤五 使用DSP E1PORT查看E1端口配置信息(帧格式、线路编码格式)是否与对端一致。如果不一致,与对方协商成一致的配置。 步骤六 检查E1电缆收发是否接反。 应急建议 1.1.29 E1误帧告警 故障现象 E1误帧告警 可能的原因有: 原因一 时钟故障:包括(时钟源与CLK单板之间的配线连接故障、CLK与NET故障原因 单板之间的时钟配线故障) 原因二 配置错误:包括(两端设备的帧格式和线路编码格式) 故障处理方式与步骤: 步骤一 首先观察告警台上误帧上报的频率和误帧的数量,如果上报频率很低(几 分钟报一次)、误帧数量比较少(少于20),可以不需要特别处理。 排除故障 步骤二 如果误帧频繁上报并且误帧数量比较大(20个以上),需要按照上例进行 检查,着重检查时钟部分。 应急建议 1.1.30 HRB GE接口故障 故障现象 HRB频繁倒换,告警台上出现GE接口故障 可能的原因有: 原因一 UMG8900 GE协商方式与NE40设置不一样。 原因二 故障原因 ADD GWADDDR配置丢失或者没有配置。 原因三 光纤故障。 故障处理方式与步骤: 步骤一 执行:LST IPIF: IFT=GE, BT=HRB, BN=xx, IFN=xx;查看HRB GE自协商 参数是否禁止;如果没有禁止,执行:MOD IPIF: IFT=GE, BT=HRB, BN=xx, IFN=xx, AUTONEGO=NO; 在NE40上查看GE端口自协商是否禁止;正确为自协商禁止。 排除故障 步骤二 执行:LST GWADDR: BT=HRB, BN=xx;查看是否设置了GWADDR。 步骤三 将GE光口用光纤自环,观察是否还用告警存在。如果还有告警,请立即更 换MG1O单板。 应急建议 1.1.31 VPU丢包告警 故障现象 告警台上出现VPU丢包告警 可能的原因有: 原因一 承载网质量下降。 故障原因 原因二 带宽不足导致丢包。 故障处理方式与步骤: 步骤一 首先观察是否仅仅有少量的丢包现象,一般是由于HRB或者BLU倒换导致的,可以不需要处理。 步骤二 排除故障 如果是大面积丢包告警,执行PING: BT=HRB, BN=xx, NUM=xx, IP="x.x.x.x", PKTSIZE=32, TIMEOUT=3000; IP地址选取对方网关的HRB的地址,如果存在丢包,一方面联系承载网网管查找故障原因,同时启动SX3000限呼策略。 应急建议 1.1.32 MPU信令面不通 故障现象 电话打不通 可能的原因有: 原因一 MPU路由丢失 故障原因 原因二 内部FE拥塞或者故障。 故障处理方式与步骤: 步骤一 执行:LST ROUTE: BT=MPU, BN=0; 检查MPU路由是否设置。如果丢失,请执行:ADD ROUTE: BT=MPU, BN=0, DSTIP="0.0.0.0", DSTMASK="0.0.0.0", RTTYPE=NEXTHOP, PREF=60, FLAG=NORMAL, NEXTHOP=x.x.x.x; 增加路由设置。 步骤二 排除故障 执行:PING: BT=MPU, BN=0, NUM=4, IP=x.x.x.x, PKTSIZE=32, TIMEOUT=3000; IP地址为SX3000的IFM地址。检查信令承载网是否故障。 步骤三 连续多次执行:DSP IPIF: IFT=ETH, BT=MPU, BN=0, IFN=0; 检查是否有报文收发。 如果步骤二和三出现故障,请采取倒换MPU应急。 应急建议 倒换MPU。 1.1.33 时钟故障 故障现象 告警台上出现时钟相关告警、通话有杂音、单通或者通话中断、链路闪断 可能的原因有: 原因一 时钟源故障。 原因二 故障原因 时钟锁相故障。 原因三 时钟传输故障。 故障处理方式与步骤: 首先简单说明一下UMG8900的时钟设计方案。 时钟参考源(2MBITS、线路恢复时钟)―――CLK――NET――各业务单板。 CLK单板对时钟参考源进行锁相跟踪,将跟踪的结果通过时钟分发线送到各个NET单板,NET单板上的时钟锁相部分将clk送来的时钟进行锁相和分频,通过背板向各个业务单板提供所需要的时钟。 步骤一 检查CLK的锁相是否正确。 执行:DSP CLK: SN=X; 检查主备CLK单板锁相是否处于跟踪状态。 跟踪状态:此为正常状态,说明时钟质量正常,达到2级钟质量。 保持状态:此为不正常状态,说明2MBITS可能丢失,可能正在搜寻线路恢复时钟为时钟源。这种状态可能会影响业务。 快捕状态:此为不正常状态,说明2MBITS可能丢失,现在整处于锁线路恢复时钟的过程中,这种状态可能会影响业务。 自由振荡:在T局中,此为不正常状态,请使用MOD CLKSRC命令修改时钟源为外同步参考时钟。这种状态可能会影响业务。 如果发生2MBITS时钟丢失,时钟锁相状态的迁移是跟踪――保持――快排除故障 捕――跟踪。这个过程可能需要10几分钟。 如果时钟锁相状态长时间不能恢复到跟踪状态,请检查2MBITS时钟线缆是否连接正常、提供线路时钟的接口单板是否故障、接口单板到CLK单板的时钟接线是否正常。如果都没有问题,请及时联系研发人员。 步骤二 检查NET单板的锁相是否正确。 在时钟锁相状态处于跟踪的条件下,执行:DSP NETCLKSIG: FN=x, SN=x;,查看NET时钟锁相是否正确。如果锁相丢失,先要找出哪块NET板上的时钟是主用,观察NET板上CLK1_IN和CLK0_IN两个网口的橙色指示灯,两橙色等同时亮的那块NET单板为时钟主用单板,一个亮一个灭的为备用。 然后倒换NET板时钟部分,只能通过掰动时钟主用的NET板的拉手条,才能倒换NET板时钟部分。请注意掰动拉手条后要迅速将拉手条复员到原来的位置。 步骤三 检查各业务单板是否获取正确的时钟。 如果NET板时钟锁相正常,业务单板出现时钟故障,只能重新插拔单板。如果仍然无法解决,请更换业务单板。 应急建议 1.1.34 单板CPU占用率过高 故障现象 查询CPU占用率,结果偏高 可能的原因有: 原因一 资源配置不合理 原因二 调试信息打开后没有关闭 原因三 故障原因 存在网络风暴 原因四 启动了跟踪任务 原因五 告警和日志很多。 故障处理方式与步骤: 步骤一 执行LST RSCGRP:;命令,查看资源分配是否在同一个资源池中。 步骤二 排除故障 关闭各单板的调试信息开关。 步骤三 关闭跟踪任务。 应急建议 1.1.35 单板无法启动 故障现象 单板无法启动 可能的原因有: 原因一 根据不通的单板类型有相应的诊断方法。 故障原因 原因二 FLASH死锁。 故障处理方式与步骤: 步骤一 如果备用OMU无法启动,原因可能是主备OMU文件不同步。 步骤二 E32、SPF单板无法启动,原因是时钟信号丢失,自检不通过,请查看串口 消息。 排除故障 步骤三 G10单板接口故障,HRU无法启动。 步骤四 VPU上扣板没有扣好,导致VPU无法启动。 步骤五 CXE16芯片故障,导致NET单板自检不通过,无法启动。 应急建议 更换故障单板 1.1.36 业务框整框故障 故障现象 整框无法正常启动 可能的原因有: 原因一 级联网口故障。 故障原因 原因二 故障插框的MPU单板故障或者无法启动。 故障处理方式与步骤: 步骤一 观察级联网口的状态是否正常,正常情况下,级联网口应该是绿灯亮,黄 灯闪烁。 如果不正常,可能接口发生故障或者单板故障,请更换单板或者网线尝试排除故障 是否可以解决。 步骤二 如果级联正常,并且故障插框与级联插框之间的网口正常情况下,MPU单 板无法启动,请更换MPU单板。 步骤三 检查主控框OMU 的LANSWITCH是否正常。应急采用复位OMU LAN。 应急建议 复位OMU LAN,一次只能复位一个LAN。 1.1.37 LMT响应速度很慢 故障现象 下发MML命令,长时间得不到响应,或者响应很慢。 可能的原因有: 原因一 存在未返回的命令。 故障原因 原因二 OMU CPU占用率很高。 原因三 维护网络有丢包。 故障处理方式与步骤: 步骤一 查看状态栏是否存在未返回的命令,等待有所的命令执行完成后再执行其 它的命令。 排除故障 步骤二 查看OMU CPU的占用率,看是否过高。 步骤三 执行PING命令,ping OMC接口地址看是否存在丢包。 应急建议 1.1.38 无法登录维护台 故障现象 无法登录维护台 可能的原因有: 原因一 网络通信故障,即LMT所在主机与UMG8900设备主机之间网络通信不正故障原因 常。可能存在IP地址冲突。 原因二 登录到UMG8900主机的LMT系统已经超过最大限制。 故障处理方式与步骤: 步骤一 在LMT安装的PC机上执行PING命令,观察是否可以PING通UMG8900 设备主机的OMC接口,如果不通,请检查网络连接是否正确,网络通信环 境是否正常。 步骤二 排除故障 请检查LMT系统的工作站设置中是否正确添加了要登录的设备主机OMC 接口IP地址信息,如果没有,请添加后重新登录。 步骤三 检查连接到UMG8900设备主机的LMT数量是否已经超过或者达到系统的 最大限制数量(6个),如果是,请稍后再登录主机。 应急建议 重新启动计算机,重新登录。 1.1.39 单板电压告警 单板处于故障状态,单板拉手条上的热插拔指示灯(蓝色)常亮。 故障现象 如果是OMU/MPU单板反复启动。 可能的原因有: 原因一 单板出现低压或者高压告警。 故障原因 原因二 MBUS故障。 原因三 单板硬件故障。 故障处理方式与步骤: 步骤一 如果是OMU/MPU单板,可以通过超级终端登录到单板的调试串口,观察 输出的调试信息,如果出现: SELF POWER OFF BY LOW VOLT 或者 SELF POWER OFF BY HIG VOLT 排除故障 这样的自检信息。 说明单板为低压或者高压故障,一般可以先通过更换单板排除。 步骤二 如果是其它类型单板,登录与之同框的OMU/MPU单板的串口,执行MNT MBUSINFO命令,查看是否存在与故障单板对应的信息。如果没有,定位 为MBUS故障,更换mbus扣板。如果有记录,单板处于下电状态,只有 更换故障单板。 应急建议 更换故障单板 1.1.40 单板风扇框故障 维护台面板上显示风扇框故障、设备面板指示灯状态为不闪烁或者闪烁不故障现象 正常(正常状态为1s亮1s灭)。 可能的原因有: 原因一 故障原因 风扇框故障。 原因二 连接风扇框的串口监控线或者内部线缆连接不正确。 故障处理方式与步骤: 步骤一 将确认为好的风扇框插入显示故障的风扇框位置,观察是否正常,如果正排除故障 常,请更换坏的风扇框。如果不行,走下步。 步骤二 请检查串口监控线、内部线缆连接是否可靠,重新插拔风扇框。 应急建议 更换风扇框,确保温度不会太高。
本文档为【UMG8900故障诊断指导书】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
下载需要: 免费 已有0 人下载
最新资料
资料动态
专题动态
is_212655
暂无简介~
格式:doc
大小:115KB
软件:Word
页数:60
分类:
上传时间:2017-09-28
浏览量:20