UMTS RNC外场故障排查指导(传输承载相关)TD 版本

                    设备分册

文档名称： 

资料版本：

产品版本：

共     页

(包括封面)

                             拟  制                    

                             审  核                     

                             标准化                     

             批  准                     

中兴通讯股份有限公司

修改记录

声  明

本资料著作权属中兴通讯股份有限公司所有。未经著作权人书面许可，任何单位或个人不得以任何方式摘录、复制或翻译。

侵权必究。

和是中兴通讯股份有限公司的注册商标。中兴通讯产品的名称和标志是中兴通讯的专有标志或注册商标。在本手册中提及的其他产品或公司的名称可能是其各自所有者的商标或商名。在未经中兴通讯或第三方商标或商名所有者事先书面同意的情况下，本手册不以任何方式授予阅读者任何使用本手册上出现的任何标记的许可或权利。

本产品符合关于环境保护和人身安全方面的设计要求，产品的存放、使用和弃置应遵照产品手册、相关合同或相关国法律、法规的要求进行。

由于产品和技术的不断更新、完善，本资料中的内容可能与实际产品不完全相符，敬请谅解。如需查询产品的更新情况，请联系当地办事处。

参考资料：

《RNC用户面调试手册》

《RNC用户面RNLC-RNLU 内部消息Bitmap定义(3.07.310版本)》

目 录

第1章 业务质量相关的故障分析和处理    vi

1.1 一般性排查思路    vi

1.1.1 常见故障现象    vi

1.1.2 准备知识    vi

1.1.3 故障处理建议    xii

1.2 CS业务典型案例    xii

1.2.1 CS语音呼叫接通后单通或者双方都没有声音    xii

1.2.2 CS语音呼叫后出现杂音，或者语音质量很不好，出现水泡声或者金属音    xiii

1.2.3 可视电话图像不清晰，或者出现马赛克严重。    xiv

1.3 PS业务典型案例    xv

1.3.1 PS激活后Ping PDN地址不通 或者下载无速率，但UE不掉话    xv

1.3.2 PS激活后，UE反复上Cellupdate 或者 RNLU上报UciuError掉话    xvi

1.3.3 灌包速率稳定，但是无法达到期望速率    xvii

1.3.4 灌包速率稳定，但Ftp下载或者 Ftp 上传 速率很低或者没有速率    xviii

1.3.5 灌包速率不稳    xviii

传输承载相关的故障分析和处理

摘要

本章介绍了传输承载类故障的常见原因、故障原因分析和故障处理方法等。请再参考完业务相关故障章节后参考本章节。

一般性排查思路

常见故障现象

承载的问题就是找到不通的位置或者丢包的位置。

这些问题很多同承载网相关。这里先介绍一些排查过程中要用到的准备知识和常见排查手段：包括逐段环和逐段PING，传输告警处理，镜像抓包，内部媒体面检测，媒体面单用户跟踪等。

逐段环回和逐段PING操作

传输问题定位，最主要就是找出问题段 （比如不通的段或者丢包的段），或者设备定界。对于ATM网络来说最常见的手段就是逐段环，对于IP网络来说就是逐段PING。

环回的工程应用方法参见[1],RNC提供环回的操作指导参见[2.]

传输告警

传输不通或者不稳，会造成承载底层丢包。此时RNC和NODEB等一般都有告警。请先消除相关告警，RNC告警手册参见文档[3]

内部媒体面检测

内部媒体面检测常用来检测RNC内部板和板间，框和框间媒体面是否通畅。包括

1.内部媒体面检测： 用于接口板之间

2.DSP媒体面检测： 用于用户板和接口板间，用户板和用户板之间

这条所有研发，测试，工程同事都需要作为基本技能掌握。

外部交换机抓包和UE抓包

1.外部交换机抓包是丢包和乱序界定网元的必须方法。各类交换机路由器抓包原理类似，都是进行端口映射，将报文复制一份到目的端口，送到测试PC的wireshark分析。具体命令需要参考交换机的手册

2.UE用wireshark抓包也是判断网络侧是否有乱序的一个手段。网络侧乱序会导致FTP单线程下载速率上不去

内部GUIM镜像抓包

一般网元外交换机抓包是推荐方法，内部GUIM镜像抓包是保留方法。GUIM内部抓包的方法法能判断RNC内部是否有流程处理或者硬件问题导致的丢包，也能辅助判断RNC外部传输网是否有丢包。但有一定风险，一般不用，用时请联系研发制定策略。参见文档[4]

单用户（承载通道）跟踪

能在RNC内部跟踪某个UE用户，在接口板和处理板上对报文个数进行统计，辅助判断某个用户或者某个小区的一些问题。

手册待补充。

SLA的IPPD方法

SLA的IPPD是IP网络性能监测的一种方法，也能辅助判断传输组网是否通畅，具有ping 和traceroute的功用。

指导手册待补充。

KPI 性能统计

KPI性能统计是对诊断测试任务中 建立对承载底层重要统计的跟踪任务，将底层协议栈报文数据统计和一些异常统计送到后台来分析。

指导手册待补充。

故障处理建议

请在业务定位后，特别是信令跟踪分析及用户面处理完毕后再参考本手册。

请特别关注问题相关的传输告警。

ATM组网下传输承载典型案例

OMCB通道PING不通

【故障现象】：

开站和升级过程中，从OMCB 服务器 PING NODEB操作维护IP，PING不通。NODEB版本无法加载。

【排查思路】：

排查OMCB 不通，首先是排查出不通的段。

有两点很重要：一是确认该站的传输情况，看RNC 到NODEB的传输是否存在不通；二是确认OMCB不通的范围，比如是RNC范围，IUB接口板范围，还是单站范围。通过范围来辅助判断不通的段是GIPI到OMCB SRV段 还是IUB口传输段。

图1.1 OMCB通道连接示意图

【建议步骤】：

1）确定该站传输是否通，IMA组状态是否可用

A: 如果IMA组状态异常

看是否有对应站点的 LIF,LODS，IMA组不可用等告警。请先处理传输和IMA问题，参见传输和IMA章节：

B: 如果IMA组状态可用。

可进一步获取这些信息：检查 NODEB 是否已通过BOOTP获得操作维护IP，或者该站信令链路是否已通来确认IMA组状态确实正常。IMA组状态可用一般需要重点排查RNC的配置和OMCB SRV的配置。请继续下面步骤2。

2）确认OMCB不通的范围，并检查相应配置。

A: 整个RNC范围内 OMCB通道不通。

        需要重点检查 OMCB配置 和 充当OMCB通道的GIPI配置。

●从 OMCB  SRV PING  OMCB 通道的GIPI接口地址。如果PING 通且不丢包，转B处理；如果PING不通或者有丢包继续下面检查。

●检查GIPI接口地址和OMCB接口地址，是否在一个网段;掩码设置是否一致。

●检查GIPI 接口 和OMCB （一般是SBCX网口）及中间的交换机物理连接是否正确，网线连接是否接触不稳定。

●检查GIPI 网口等是否UP

●如果OMCB SRV 和GIPI间连接没问题，可以尝试倒换OMCB 通道的GIPI

●进行内部媒体面检测，确保GIPI 到 ATM接口板的内部媒体面检测通畅。

●进行上述处理后，问题还未解决，联系研发处理。

B: 单个站点 OMCB通道不通。

既然传输可用，此处需要重点排查此站点相关的配置。

●OMCR上 检查到该站点的IPOA是否配置，IP地址是否正确对应NODEB的操作维护IP。

●OMCR上 检查到该站点操作维护IP 是否配置了下一跳为端口的路由，端口的架/框/槽是否正确。另外需要特别关注SDTA/APBI的 IMA端口和路由端口号的对应关系：V3版本中，SDTA/APBI的端口编号中考虑光口，所有IMA端口对应的编号在路由配置中从5开始，即IMA端口号14，对应路由的端口5，依次类推。APBE和IMAB由于分别只有光口或IMA端口，则没有这种换算关系。

●复位这个站点的IMA组，待IMA组重启状态可用后观察问题是否解决

●继续上面排查后问题还未解决，请联系研发处理。

C: 整个IUB口单板或者整个光口 OMCB通道不通

●更换光模块，光纤

●更换IUB口单板

●进行了上叙排查后，如果还是整块IUB接口板上所有IPOA通道都不通。可能是硬件问题，请联系开发排查。

IUB口传输（IMA）不通

【故障现象】：

1.IMA组状态异常，IMA端口及PVC 状态异常，信令和用户面数据都不通

2.IMA组状态正常，个别IMA链路状态异常。

【排查思路】：

导致IMA异常的传输问题主要包括： 不通（虚接，漏接），错接，错配，半对接半自环。无论何种情况 都需要逐段来看，并且最好逐段进行环回。

1.IMA组状态异常

（1）工程开通阶段 IMA组状态异常，一般是传输不通。请参考1.1.2 准备知识中的 逐段环回依次进行RNC系统侧环回，NODEB 侧局方DDF架物理E1向RNC远端环回，NODEB CC板向RNC远端环回通过RNC的 IMA组的状态来判断传输不通的段

（2）查看 RNC,NODEB是否有告警。参考告警手册处理

2.IMA组状态正常，组内个别E1 不通

一般来说个别IMA链路不通，而整个IMA组状态可用的问题。基本是对应的E1不通，或者接错。

可以把这条E1从原RNC的IMA组中暂时剔除。然后增加一个测试IMA组，将这个E1加进来。再参考1.1.2中逐段环回的方法进行排查。

3.其他情况

信令SCCOP链路不通（控制面不通）

【故障现象】：

1.SCCOP链路不通，TNL同事已经确认认为需要承载同事继续辅助排查的情况。

2.承载信令的链路不通导致的IUB口小区不能建立

3.承载信令的链路不通导致的IUPS PDP激活失败

【排查思路】：

SCCOP链路不通，有可能是TNL层的问题，也有可能是底层传输的问题。这里假设TNL已确认无问题，只讨论底层传输相关问题。

1.通过OMCR上或者 接口板上SscsLinkInfo 查看对应局向的SCOOP链路状态持续不通的原因。

即Data Transfer Ready 请传输信令同事排查，其他状态请继续下面步骤。

2.AtmlmShowPvcByStatus确认 对应SCCOP链路的PVC状态是否正常

Stat 等于0表示PVC状态正常，转步骤3处理；stat状态等于其他值表示PVC状态不正常，转5处理。

3.检查对应PVC的外部VPI/VCI，PVC类型（一般为CBR），PCR参数是否两侧设备一致。若不一致，则改为一致；否则继续排查。

4. 在 UCOM端口 观察 SCCOP 是否发出了报文。SDTA/APBE_2 上 多次使用 MCS_APP_UCOMStatsPrn 查看rcvXmtSSCOPPktsDown 和xmt SSCOP  up 项是否增长。rcvXmtSSCOPPktsDown 不增长表示 SCCOP没有报文发出，需要TNL继续定位；xmt SSCOP  up项不增长表示对方没有应答，请联系TNL同事查看（APBE和IMAB 使用 MCS_C5_UCOMStatsPrn 查看CPU -> C5E的xmit SSCOP 和C5E -> CPU的recv SSCOP）.

5.PVC状态异常，则检查端口是否正常。AtmlmShowPort 查看phy status是否OK。状态OK则联系研发排查。异常则继续处理。

6.如果是IMA的，则查看IMA组状态机是否异常，见1.2.2节IUB口传输不通。

7.如果是ATM/SDH的，则光口状态不对。请先查看 SDH/SONET相关告警，并排查光模块，光纤等。并且尝试本端自环，查看端口和PVC状态是否正常。如果本端自环正常，则请和对端设备核对SDH/SONET相关参数。包括SDH/SONET模式，是STM-1还是信道化E1（CSTM-1）等。

IUB 公共信道建立失败

【故障现象】：

●公共信道建立失败：用户面发送给控制面的CchuInitRSP消息中，指示的错误码为7004。指示FP同步失败。

或者通过在RUB上运行ShowCfpStat，看到用户面的FP层在公共信道上只有发送没有接收。

VTCD->ShowCfpStat

         ………………………

*---------------------------Control Frms Info-------------------------*

* Pch Fp recv Node Sync num: 0 * Pch Fp send Node Sync num: 563 *

* Pch Fp recv Tran Sync num: 0 * Pch Fp send Tran Sync num:  0 *

【原因分析】：

图2控制面公共信道建立流程

对于承载通道来说，公共信道建立 可以理解为RNC FP帧和NODEB的交互的过程。数据流方向为：[RNC:  RUB<> GUIM<>(跨框GUIM)<>ATM接口板]  <>   [NODEB],.

如果FP帧同步失败，则公共信道建立失败。在传输开通的前提上（IMA组正常），其主要原因有：

1）RNC和NODEB之间AAL2 PVC的对接参数错误

2）RNC内部:RUB和IUB口的接口板RAP之间媒体流数据不通

3）RNC和此NODEB对应的路径（TrPath）没有配置

4）RNC 内部CS接续异常 

5）NODEB侧的问题

【排查方法】：

如果 OMCB通道已通，建议确认NODEB侧是否收到同步帧，确定是上行丢包还是下行，以便缩小范围。下面就主要原因给出排查方法。

1.RNC和NODEB之间AAL2 PVC的对接参数错误

●检查RNC和NODEB的PVC对接参数，确认每一条对接的AAL2 PVC中RNC配置的外部VPI/VCI(CVPI和CVCI)（即和NODEB约定的VPI和VCI）是否和NODEB配置的一致。或者是否符合工程的数据标配基线。

●检查PVC状态是否OK。前台命令为AtmlmShowPvcBystatus，STAT 0为OK。STAT 为其他值为异常。一般是IMA端口不正常。BOPHY为外部端口，APBE:4-7; APBE_2 :10-13. B0_VPI/B0_VCI为外部VPI/VCI

●检查下2边的PVC类型和带宽情况是否匹配

2.RNC内部:RUB和IUB口的接口板RAP之间媒体流数据不通

这里主要考虑一些连接及硬件故障问题。

●在接口板和RUB间进行DSP媒体流测试。注意同框和跨框都发起。

●尝试倒换GUIM

●如果内部DSP媒体流测试不通，则检查UIM间的GUIM配置，光纤连接情况及光纤模块等

●尝试更换单板。

●进行上述步骤，内部媒体面依然不通，联系研发处理

3.RNC和此NODEB对应的路径（TrPath）没有配置

这个情况较少。局向路径在IUB局向是必配的。请依据IUB口PVC标配工具配置路径和PVC

4.RNC 内部CS接续异常

如果FP 帧，NODEB侧确认回了应答，而RUB没有收到，则需考虑在RAP上丢失的可能。

参见附录《RMP微码子系统调试手册（RAP_APP）.doc》4.2.2 节AAL2入网元流水线，查看是否有CS接续失败统计。

APBE_2->MCS_APP_AAL2StatsPrn

Vc2IpTblErr         : 0          //cs 接续关系表异常

5.NODBE侧问题

如果确认NODEB侧收到FP帧，而没有回FP应答，则需要在NODEB侧排查。

IUCS IUUP初始化帧超时

【故障现象】：

●IUUP初始化超时：在IUUP建立过程中，用户面给控制面返回失败，错误原因为3014（ASN1V_err_IuupInitExceedMaxTimes），即IUUP初始化超时。

【原因分析】：

对于承载，IUUP初始化失败类似于IUB口公共信道建立失败

数据流方向为：[RNC:  RUB<> GUIM<>(跨框GUIM)<>ATM接口板]  <>   [CN(MGW/MSC)],.

在传输开通的前提上，其主要原因有：

1）RNC和CN之间AAL2 PVC的对接参数错误

2）查看PVC 状态是否正常。不正常，一般是端口状态不正常，则需要看光口是否有告警。排查光纤，光模块等

前台命令为AtmlmShowPvcBystatus，BOPHY为外部端口，APBE:4-7; APBE_2 :10-13. B0_VPI/B0_VCI为外部VPI/VCI

3）RNC内部:RUB和IUB口的接口板RAP之间媒体流数据不通

4）RNC和此CN对应的路径（TrPath）没有配置

5）RNC 内部CS接续异常 

6）CN侧的问题

【排查方法】：

参见 IUB口公共信道建立失败，不再赘述。

PS PING包不通或者PING大包不通

【故障现象】：

1)PDP激活成功后，从UE ping 1000字节长度以下的小包不通，显示“Request timed out.”。或者FTP无速率

2)PING小包可以PING通，但PING 1432 字节以上大包不通，或者某段不通。

【排查思路】：

PDP激活成功后，小包不通，则是PS用户面不通。需要重点排查接口地址，PVC对接，IPOA，GTPU 地址，路由等配置情况.以及传输网是否通畅。

手机PING小包，大包不通。则主要考虑IP的分片重组，以及传输网/PDN 是否了报文大小等情况。

 PING 包不通排查

请逐步检查以下配置。

（1）保证PDP激活正常，保证ping的目的地址正确，保证终端支持该业务。

（2）检查两端的AAL5 DATA的PVC配置是否一致，重点检查外部端口是否正确、外部VPI和外部VCI等配置是否和对端一致。

前台命令为AtmlmShowPvcBystatus，BOPHY为外部端口，APBE:4-7; APBE_2 :10-13. B0_VPI/B0_VCI为外部VPI/VCI

（3）检查接口板的接口板IP配置是否正确。接口板的端口号是否正确，端口是否UP。

端口没有UP，则该光口没有点亮。重点检查光纤，光模块和SDH/SONET模式两边设备是否一致。

（4）检查VTCD上的业务IP的配置

下面红色部分即为本端的业务IP，这个参数是需要和CN对接的。

（5）检查本端的路由配置：

在ATM接口板上执行list可以查看相应的路由信息，路由信息里应该包含了GTPU业务IP的路由和APBE的接口路由，及对端的GTPU业务IP的路由信息。如果没有本端的GTPU业务路由信息，则检查RPU上的虚接口IP配置是否正确；如果没有APBE的路由信息，用ip_print_if来检查APBE的端口状态和接口IP的配置情况，还需要检查配置接口IP选择的端口和实际使用的端口是否一致。如果对端的GTPU业务IP和接口IP不在同一网段，还需要在RNC侧配置对应的静态路由信息，网络前缀为对端的GTPU地址，下一跳为对端的接口板的接口IP。

我们主要关注下面红色方框里面的三种路由信息，特别是本端业务IP对应的路由。下面例子中

10.8.47.74为本端接口地址，10.8.47.3为对端接口地址。

138.1.1.74 为本端GTPU地址

200.47.0.0 为对端GTPU地址

Dstip ：200.47.0.0/16  nexthop 10.8.47.3 为配置到SGSN 用户面的路由。

（6）检查本端的IPOA配置：

主要检查 对方接口地址 和 PVC的对应关系。

以APBE为例：执行MCS_C5_IPOACfgShow，可以查看APBE上生效的IPOA信息是否正确。其中红色方框为下一跳IP，蓝色方框里面的VPI/VCI为RNC侧AAL5 DATA业务所配置的PVC，请注意VPI/VCI 为内部VPI/VCI。该表表示所有下一跳为10.8网段而且tos为0的PS报文都会选择内部VPI/VCI=1/47的PVC发送给对端。

    APBE_2/SDTA上对应查看IPOA的命令为MCS_APP_IpoaCfgShow

（7）CN侧配置和RNC侧配置是对等的。需同样检查CN侧接口地址， PVC，IPOA，静态路由等的配置是否正确，这个可以请CN的维护人员协助检查。

（8）如果配置正确请联系研发人员排查。

 PING 大包不通排查

大包问题比较复杂，一般需要考虑 PDN,CN,IU口传输，RNC等设备对分片重组的支持情况及传输网上是否有IP分片乱序、超时的情况发生。

（1）首先要保证小包能ping通，然后再排查ping大包不通的问题。如果ping 小包也不通（典型32字节）请参考1.2.6.1

（2）OMCR确保配置了重组 GIPI单板

APBE上查看重组GIPI单板配置

APBE_2/SDTA 上使用McsAppShowReassembleRUIBIP 查看

（3）检查重组GIPI的外部IP分片重组统计

用命令Mcs_Reass_Dbg检查是否收到外部分片报文，外部重组是否成功。由于该命令是每次清零，所以必须连续查看统计，注意观察红色部分的统计是否增长。

常见有外部重组超时（extern packets for time out），则有可能是IU口下行分片丢失。转步骤（4），没有则直接转步骤（6）进行IU口交换机抓包确认

（4）倒换重组GIPI 和GUIM

出现IU口外部IP分片重组超时后，先排除RNC问题。可分别倒换重组GIPI,重组GIPI所在框的GUIM,IU口接口板所在框的GUIM。

若问题恢复，则联系研发排查单板硬件问题。未恢复继续

（5）从IU 口ATM 接口板向 重组GIPI做内部媒体面测试。

若内部媒体面不通，联系研发解决。若通畅，则IU口丢失分片在外部。

（6）IU 口交换机抓包。

  各种组网，各类交换机抓包原理一样，操作上略有不同，可依据交换机型号，联系研发指定抓包策略。

IP组网下传输承载典型案例

PS业务，根据RNC的信令跟踪(包括RNLC-RNLU内部消息)，基本上就能定位一般的问题或者定位问题所在的网元。

HSDPA单线程下载速率低

【故障现象】：

FTP单线程下载速率低，或者出现掉沟 等不稳定的情况。业务已经确认上层无问题，并大概定位出是IUB口还是IU口问题。

【排查思路】：

HSDPA下载速率低原因可能是多方面的，需要逐步逐层定位：首先根据信令跟踪和UE抓包进行分析，在控制面和用户面分析确认后，需进一步确认底层承载是否有问题时再参考下文。

FTP基于的TCP是可靠的面向连接的运输层服务，IP层的丢包和乱序会导致速率下降。对于承载来说，主要是确认底层是否丢包和乱序，以及找到丢包和乱序的位置。

排查这个问题请先让用户面基本确认是IU口问题还是IUB口问题，然后分别处理。

如果是IU口则先网元内，再网元外的步骤来排除丢包和乱序。最终都通过抓包确认。

【IU口排查 处理建议】：

如果用户面确认是IU口问题，常见的乱序是传输设备的路径负荷分担引起的；常见的丢包是IU口分片丢失导致RNC IP重组失败引起的。这些在定位问题时，都要优先考虑。

1）UE 抓包。

通过WIRESHARK可以看到【TCP Out Of Order】或者【TCP Retransmission】,则有丢包重传或者乱序的情况。

2）RNC有无外部IP分片重组错误

在重组GIPI上，输入命令Mcs_Reass_Dbg，下面红字任意一项增长都是IP外部重组失败。请接续步骤3，没有增长则跳往步骤5

MNIC_2_23XX->Mcs_Reass_Dbg

    ~~~~~~~~~~~~~~~~ MCS REASSEMBLED PACKET COUNT ~~~~~~~~~~~~~~~

    0x281a       Count of successfully reassembled local packets(after reassembl

ed)

    0x0          Count of not frag local packets

    0x507c       Count of received extern packets to reassemble

    0x0          Count of discarded extern packets for offset error

    0x0          Count of discarded extern packets for table collusion

    0x0          Count of discarded extern packets for frag repeat

    0x4b         Count of discarded extern packets for time out

    0x0          Count of discarded extern packets for oversize

    0x0          Count of discarded extern packets for ring null

3）倒换重组GIPI和GUIM

在OMCR上分别倒换重组GIPI,资源框的GUIM。问题解决，则一般是GIPI或者GUIM的硬件问题，请则联系研发确认；问题未解决，继续往下

4）内部媒体面检测

在OMCR上 从IU 口 GIPI分别向重组GIPI发起内部媒体面检测，向RUB发起DSP媒体面检测。多做几次，有报文丢失则联系研发，无报文丢失则继续下面步骤。 

5）IU口交换机抓包

这是确认IU口问题导致DPA速率上不去的最终也是最直接手段。可以联系局方在传输设备上做端口映射抓取和分析IU口下行报文，看是否有报文丢失和乱序。

6）GUIM端口映射抓取IU口报文

这是步骤5 暂时不能操作的保留手段。请联系研发操作。但是最终还是要通过 步骤5的 IU口外部抓包来确认。

【IUB口排查 处理建议】

IUB口 RNC是发送方，一般确认反压等无问题后。则需要NODEB协助处理。

1）确认路径带宽。

主要看对应站点的路径配置是否正确，若是IP OVER E1的话，查看路径可用带宽配置情况，确认路径配置带宽要和物理带宽相符。

2）IUB口传输情况。

查看NODEB各层是否有丢包。

3）NODEB级联的情况。

如果下级NODEB速率有问题，一级NODEB速率无问题。则联系NODEB研发排查一级NODEB转发是否有丢包。

OMCB通道不通

典型的OMCB通道组网方式：

OMCB通道不通，故障一般分两种：OMCB Svr 到对应网关ping不通；OMCB Svr 到对应NodeB地址Ping不通。这两种情况一般都是和组网配置有关系，要重点检查配置。

1、Ping OMCB svr网关不通：

检查PC OMCB Svr和作为OMCB Svr 网关的GIPI上的接口IP地址配置是否正确；

检查两者到对端的MAC地址是否学习到。PC机上使用 rap –a命令查看；GIPI上使用Np_Arp _Display 查看。

如果没有对应的MAC地址，要检查一下两者之间的连接以及连线是否正常。

如果在GIPI上使用ip_print_if看到对应端口处于Down状态，肯定是端口配置或网线没有连接好。

2、Ping 网关地址通，Ping NodeB地址不通

首先确保OMCB Svr 和网关之间是相通的

检查RNC上OMCB Svr IP以及RNC对NodeB暴露的IP地址是否配置以及配置是否正确（后台全局补充配置查看或前台GIPI单板上使用Np_OMCB_IP_Display查看）；

如果NodeB的IP地址和GIPI出接口的IP地址不在同一网段，检查RNC上是否配置了到NodeB地址的静态路由（后台查看或GIPI上使用List命令查看）；

检查GIPI和NodeB连接的接口的MTU值，查看Ping包的大小是否大于该值，目前的版本不支持OMCB类型的分片包。

偶联建立失败

SCTP偶联数据处理流程概述

IUB口，偶联的发起者是RCB板上的Nblomm进程，在IU/IUR口是RSP板上的M3UA模块中的UAM模块。发起者给SSM发偶联建立请求（EV_SSM_StartReq）消息，请求建立偶连，消息中携带有偶连ID。SSM收到消息后给SCTP先后发送实例初始化请求（InitiateReq）和偶联建立请求（AssociateReq），SCTP收到偶联建立请求后会向对端发INIT请求，此消息被封装成Packet包，Rsp上面的Ip模块根据对端偶联Ip地址查找路由根据结果转发到对应接口板（GIPI），接口板根据内部参数区携带的下一跳Ip地址封装MAC报文并发送到对端。

接口板接收到对端的Sctp报文，查找路由判断是否是本网元路由，根据目的Ip地址和Sctp端口查找信令分发表获取Sctp所在的模块号，根据模块号查找模块映射表获取到Rsp的控制面MAC地址，封装成RawIp报文发送到Rsp，Rsp的Ip模块解析出Sctp报文转发到Sctp模块处理。流图如下所示：

Nblomm和M3UA主要看打印。典型问题排查如下：

偶联不通一般都是RNC配置或组网配置以及连线的问题，可能是出在Iu口也可能出在Iub以及Iur口，承载类型为Ip。

首先可以在Rsp上使用SsmState查看偶联目前的出于什么状态，如下stt_show_sctp显示发送了初始化帧：

MPX86_2->stt_show_sctp

              ………                               ………………

           sentHeartBeat: 0                        recvHeartBeat:  0        

        sentHeartBeatAck: 0                      recvHeartBeatAck:   0      

                sentInit: 129                            recvInit:0             

             sentInitAck: 0                             recvInitAck: 0              

         sentCookie_Echo: 0                           recvCookie_Echo:0           

           ………                                       ………

再确认一下对端是否收到Rnc的Sctp数据包，如果没有收到就参考.1和5；收到并且回了响应但是Rsp上的stt_show_ip没有收到Sctp报文参考2、3、4。

如果不能确认对端状况，就依照下面要求逐一进行排查。

1    出网元路由问题

原因

一般是因为对端的偶联地址和接口板地址不在同一个网段，而Rnc网元内没有配置静态路由。

现象

对端没有收到Rnc发过去的Sctp相关报文。使用Rsp上面的stt_show_ip显示查找路由失败：

routing:                        2558674

  |__(route):

    |__direct:                  2558674

  |__(error):

    |__no route:                  23455

在Rsp上面使用list命令没有到对端网元的路由。

解决方法

检查到对端网元的路由配置，如果没有配置，添加配置。

2入网元路由问题

原因

一般是因为对端配置本端偶联Ip错误，或者本端的偶联Ip不是本网元的地址，例如不是Rpu或者Rsp上配置的地址

现象

对端接收到Rnc发过去的Sctp相关报文，并且发回了响应。但在Rsp上面使用stt_show_ip显示没有Sctp报文的相关统计

============== Deliver  ==============

(protocol):

  |__SCTP:                       0

(nonstandard):

如果为0使用stt_show_ip命令时看不到这一项的，此处只是演示一下

接口板Ruib上使用McsTransShow由查找路由失败的统计。

dwCOMM_IN_NOT_LOCAL_NET          : 14502;

解决方法

检查到对端网元的偶联配置或者本端的偶联Ip地址配置信息。

3信令分发表问题

原因

一般是因为本端或对端的偶联Ip或者端口号配置错误引起

现象

Rsp上面的SsmState显示偶联建链失败：

Assoc:  2 AssocState: 3 AssocID_SCTP:65535 InstanceID:  0 Module:127 UserType: 15

对端接收到Rnc发过去的Sctp相关报文，并且发回了响应。使用Rsp上面的stt_show_ip显示没有Sctp报文的相关统计

============== Deliver  ==============

(protocol):

  |__SCTP:                       0

(nonstandard):

如果为0使用stt_show_ip命令时看不到这一项的，此处只是演示一下

接口板Ruib上使用McsTransShow有查找信令转发表失败的统计。

dwCOMM_IN_SEARCH_MODULE_NUM_ERR  : 14502;

解决方法

接口板Ruib上是根据收到的Sctp报文的目的Ip和目的端口号来查找信令分发表的，所以需要检查到对端网元的偶联配置或者本端的偶联配置是否正确。

4模块映射表问题

原因

一般是因为Rnc网元配置的模块号没有上电，或者模块配置错误导致数据包发到其他的单板上了

现象

Rsp上面的SsmState显示偶联建链失败：

Assoc:  2 AssocState: 3 AssocID_SCTP:65535 InstanceID:  0 Module:127 UserType: 15

对端接收到Rnc发过去的Sctp相关报文，并且发回了响应。使用Rsp上面的stt_show_ip显示没有Sctp报文的相关统计

============== Deliver  ==============

(protocol):

  |__SCTP:                       0

(nonstandard):

如果为0使用stt_show_ip命令时看不到这一项的，此处只是演示一下

Ruib上使用McsTransShow查找信令转发表失败的统计。

dwGET_MODULE_IP_ERR              :         1452;

这说明配置到模块没有上电

如果Rsp上面的stt_show_ip显示的SCTP包数为0，Ruib上McsTransShow显示的dwGET_MODULE_IP_ERR也为0，登陆到其他的Rsp上却发现stt_show_ip显示的SCTP包数不为0，则说明配置模块号错误。

解决方法

检查偶联配置的模块号是否正确

5Arp问题

原因

一般是因为Rnc接口板上没有学习到对端网元或者对应下一跳的Mac地址

现象

在接口板Ruib上使用McsTransShow有查找Arp失败的统计。

dwOARP_PKT_TO_ARM                :      6916

使用Np_Arp_Display显示没有对应下一跳的Mac地址。这说明接口板没有学习到对应下一跳的mac

解决方法

检查一下，接口板的地址和对应下一跳的Ip地址是否在同一个网段，以及和接口板相连的节点之间网线是否插好。对应端口是出于UP可用状态（可在接口板上使用ip_print_if,查看端口是否UP，接口地址配置是否正确）。

公共信道反复删建

【故障现象】：

打开信令跟踪，发现公共信道反复删建。

【排查思路】：

这种情况，一般偶联已经是协商成功。因此首先是排查传输问题。

公共信道反复删建，反映在传输层的问题就是上、下行的UDP报文转发失败。

0、首先检查rub单板的DSP的业务ip是否已经配置好。

1、在RUB和IUB接口板之间做媒体面检查。

如果检查通过，继续（2）的检查。

如果检查失败，可以通过倒换UIM（GUIM），或通过其它的媒体面检查组合来定位，是RUIB,RUB还是UIM的问题

2、如果IUB口和NODE B是非直连的组网方式，检查到NODE B的路由是否已经配置并生效。以上两步都检查通过，下行传输通道基本检查完成。

3、在两端版本支持IP通道检查的情况，分别在接口板和RUB板做IP通道检查。根据相应的检查结果，如果检查通过， 请根据信令跟踪的结果反馈给用户面和承载的开发人员处理。

如果检查不通过，需要进一步查看shell统计。转4处理。

4、如果是RACH信道建立失败，RNC侧需要检查的是接口板是否已经获取到IPUDP的配置表。这个需要通过shell命令来查看。

A)先查看接口板的统计：

MNIC_2_23XX->McsTransStatShow

蓝色部分为上行UDP报文统计，如果统计为0，说明没有收到NODE B的节点同步报文。

绿色部分为下行UDP报文统计，如果统计为0，检查RUB板是否已经发出FP同步帧，转(B)继续排查。

如果上述统计都不为0，继续看该统计的后面部分：

如果红色部分不为0，则检查IPUDP配置表。如果没发现问题，继续：

dwIPUDP_TAB_L1_LOOKUP_ERR 不为0， 打开信令跟踪，查看cciu建立时带给NODE B的业务IP是否正确？

dwIPUDP_TAB_L2_LOOKUP_ERR 不为0，检查DSP的UDP端口号配置是否正确。

如果上述两项检查都没问题，请将统计反馈给承载科开发人员处理。

B)查看RUB板的统计：

由于外场组网比较复杂，首先需要确认小区建立的哪个DSP上，然后根据ROS和RNLU提供的相关排查手册进行排查。

RUB上两个帮助命令：

RnluHelp

McsHelp

附录

附录 1 ATM网络逐段环回和逐层环回指导

附录 2 RNC传输环回操作指导

附录 3 告警处理手册

附录 4 GUIM抓包指导