TD-SCDMA Iu口常见故障处理指导书_R1.1

故障排查

TD-SCDMA Iu口常见故障处理指导书

R1.1

故障排查

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

适用对象：基站侧开通人员

故障排查

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

关于这篇文档 摘要

故障排查

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

目录

1 2 3

前言 .................................................................................................................................... 1 IU口协议层次 外场经常出现的故障处理判断 . 3.1

信令方面故障 . 3.1.1 信令链路不通故障 3.1.2 进行业务时信令连接建立异常 3.1.3 信令流程异常 . 3.2

用户面方面异常导致业务 3.2.1 业务RAB ......................... 14 3.2.2 CS域SMAFAILPS原因导致掉话次数过多

17

4

IU口故障案例集锦 4.1 4.2 4.3 4.4 4.5 4.6 .................................................................. 20 核心网问题引发CS .............................................................. 21 ....................................................... 21 .......................................................... 21 ............................................................................ 21 MTP3链路瞬断的案例 ................................................................. 21 CS业务跨RNC切换失败的案例 ............................................. 22

故障排查

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

1

前言

本文档主要对Iu口常见故障进行处理过程进行描述，用于Iu口异常情况的处理排查指导。

由于Iu口故障大多涉及到对端CN网元，在排查处理过程中需要CN协助排查，而且就近期发生几起故障来看，大都问题都是CNCN的原理，通过文档的故障现象，在初步排除了RNC的现象和处理方式要求CN侧进行协助排查。

主要内容分为，MTP3B链路故障，SCCP 避免不必要的纠纷。

2

Iu

Iu进行对接。 方式，采用ATM方式进行对接的Iu口协议栈如下图所示

故障排查

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

故障排查

3.

从协议层次上看，对接过程中容易出现问题的，主要在底层对接和上层对接参数配置配置过程。就具体表现而言。

ATM方式下，配置PVC，SSCOP，MTP3B,SCCP层，容易出现对接故障，其中又以MTP3B和SCCP层最容易发生故障，对用户面而言，也时有出现AAL2，ATM层以及ALCAP层面的故障。

IP方式方式下，主要是IP层，SCTP层和MU3A以及SCCP层容易出现问题，对用户面主要是GTPU和IuuP较容易出现故障

通过的RNC而言，出现问题主要集中在RNC的硬件单板和目前外场发生几起故障均是由于CN侧的问题（CN导致RNC档通过一些简单故障案例，判断故障发生在侧，通过对端的协查快速解决故障。

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

3

动态管理主要观察看Iu

3.1

3.1.1

信令链路不通故障

【故障现象】通过动态管理观察7号信令不可达。

故障排查

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

从N7号信令来看，不通有两方面的原因

MTP3B层信令链路不通

信令点码等双方配置不一致，7号路由RNC

3.1.1.1 MTP3B信令链路不通：

在动态管理中，可以看到MTP3链路的链路状态为业务中断状态，对业务层是超出服务状态。

MTP3B链路状态为在配置管理中配置的宽带信令链路。改故障在开通或者升级乃至正常运行时时有发生。

如果在开通RNC时出现该现象，则需从对接参数，物理光口收发检查。

数据配置有，PVC，SLC参数

故障排查

光口检查SD灯是否常亮，对端是否收发光。

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

如果在升级后或者正常运行时出现MTP3B状态为中断，需要判断故障是在ABPE还是在CN侧。有效解决方式为环回。即在ABPE单板上将该信令链路的光纤进行环回测试。

环回时动态管理中看到MTP3链路状态为服务状态和链路就绪状态交替出现（服务状态时长大约是5秒，链路就绪状态大约1秒，二者交替出现），说明APBE单板工作正常。此时需CN侧进行排查是否对端硬件故障导致链路不通。

如果环回后MTP3B状态不变，则可能原因为APBE换。

已发生该现象的有：

2009年3月天津升级后RNC18MTP3BAPS保护，但在ODF架上对CNRNC升级过程中复位重启后导致CN

2009年4月西宁RNC正常，放通MTP3B侧接口单板挂死导致链路不通。

3.1.1.2 信令点不可达

从上图可以看到，MTP3B链路状态为服务状态，MTP3B链路状态（业务）为超出服务状态，该状态说明底层MTP3B链路状态是OK的，但对上层业务状态不通。从这个现象看应为信令点码双方参数配置不一致。或7号路由RNC侧没有配置。

故障排查

信令点码参数有:信令点码，信令子业务类型。双方应取值相同。 7号路由RNC没有配置。如果在RNC侧不配置7号路由参数，MTP3B上层业务就会不通。

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

曾经出现过的局点有：青岛，嘉兴

【解决措施】7号链路组配置和7号路由数据进行配置。3.1.2

SCCP层。对于单个用户进行业务呼叫，SCCP层的连接。影响SCCPRNCID，MCC，MNC，LAC，RAC，SAC.

SCCP层不通问题需注意与CN核对这些对接参数。

根据信令表现现象不同，主要分为以下几个方面。

故障排查

3.1.2.1

UE初始消息超时释放

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

UE初始消息直传消息发出去后过了10层建立业务信令连接超时导致RRC数双方是否按照数据规划规范进行配置。 【解决措施】 1. 2.

信令点不可达时按照

信令点可达时RNCCNCN

3.1.2.2 UE

故障排查

从信令跟踪上，初始UE消息发往CN后在1秒内马上就RRC连接释放，这个现象故障主要在RNC与2G的核心网对接时时有发生。大多为CN侧没有配置该小区ID导致。

曾经发生的局点有：厦门，乌鲁木齐，云南等地

关于SAC（服务区码），根据中移的规范要求,SAC配置为与CELLID相同，如果对方CN配置SAC不一致，则会有该现象。

【解决措施】CN排查SAC是否与我方RNC配置一致。或者2G配置我方小区ID

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

3.1.2.3 UE初始消息发出后

CN回复拒绝消息。

从信令上看，初始CN回复拒绝消息，说明SCCP层是通RNC和CNMCC，MNC，LAC等参数。

CN没有配置位置区）

MCC，MNC以及LAC是否配置以及配置与是否一致。

3.1.3 信令流程异常

信令流程异常现象是指在业务过程中由于各种原因导致业务无法正常进行，涉及到CN相关的目前外场经常遇到以下两种情况：

CN的license没有更新导致业务释放。

CN没有配置AMR语音制定为12.2K导致语音业务无法做通。

下面分别就这两种现象进行说明

故障排查

3.1.3.1

CN的licenese开关没有更新导致业务释放

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

该故障从信令上看，UE就下发了释放消息给UE，从信令流程上看，是先对UEIu口和Iub口的正常释放。

CN向UE发起释放消息。 CN对接时时有发生。当一套新的RNC接入CN时，license进行更新，以便容纳更多的RNC用户进行业务。如果对方没有更新，则新RNC业务上去后会被CN拒绝。 出现过该现象的局点有：宁夏，贵州，湖北

涉及CN厂家：华为

【解决措施】CN更新license开关

3.1.3.2 CN没有配置AMR语音速率为12.2K

导致无法打通语音电话，但是视频电话可以打通

故障排查

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

通过信令可以看到RAB指派建立后，IuupRNC和CN之间的对接是没问题的。当RNC向这个时候CN突然下发NAS DISCONNECT的原因为，是核心网主动IU口资源和相应的RRC在RAB12.2K的语音业务

进行视频电话户呼叫，发现视频电话可以做通，说明Iu口参数对接没有问题。问题可能在CN侧参数设置问题，CN对其配置的AMR编码格式修改为只支持12.2K业务后业务正常。

出现该问题的局点有，河南

故障排查

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

对应CN厂家：诺西

【解决措施】出现12.2K业务无法打通，但是视频电话可以做通的，一般均为CN侧对AMR编码格式配置问题，只配置12.2K业务即可解决。

3.1.3.3 CN的SCCP子模块吊死导致跨RNC CS业务切换失败

RNC边界切换单向失败，具体表现为RNC365切RNC363正常，但是RNC363不能切换至RNC365，RelocationRequiredRelocationPreparationFailure，原因值为365 363切换成功的信令：

363 365

出现上述问题可能原因可大致归为三类： 1.

中间传输设备故障导致RNC和CN间数据包收发异常（可通过在RNC Iu出口和CN Iu入口挂表或抓包定位，会影响正常业务）

故障排查

2. 3.

RNC发送CN的RelocationRequired消息异常

CN内部MGW和MSCServer间消息转发或解码RelocationRequired消息异常

第一类情况可能性最小，传输如果出现问题，故障表现应该多样而不是单一切换失败，又由于顾及到业务会受影响，并且挂表或抓包不能最终定位问题，只是界定故障责任方的一种手段，局方不同意挂表，此类可能性暂时保留

第二类情况从信令上看，RNC收到了UERelocationRequired，核心网收到了应，切换成功和切换失败的RelocationRequired

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

RNC发送RelocationRequired消息异常的可能。

第三类情况通过CN收到的码流多出一段重复码流：

故障排查

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

分析RNC(Cn包括了RNC的码流并且重复了一段),Relocation Required消息错，CN解释 CNSCCP（Signaling 信令连接控制部分）某一子模块吊死，不响应相关信

厂家：阿尔卡特

【解决措施】核心网侧复位该子模块后，现场多次测试，CS跨RNC切换正常。

3.2 用户面方面异常导致业务

外场经常出现用户面指派失败的故障，导致业务无法进行。

故障排查

用户面的故障一般跟用户面配置的对接参数有关，比如配置的AAL2的PVC以及PATHID，ATM地址等与对端配置不一致。或者由于用户面ALCAP处理两端不一致导致。

以及IUUP版本模式不正确导致用户面初始化失败。

用户面处理异常导致的业务不正常外场经常出现，尤其在开通阶段、割接、以及RNC或CN做了一些用户面参数配置等操作。

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

故障排查

【处理流程】 1.

SCPI 判断要建立RAB，就向RPM进程发RAB建立EV_SCPI_RPM_SETUP消息，RPM 收到后创建一个新的处理实例RPI，然后把RAB建立消息交给RPI 实例来处理。 2. 3.

RPI 向用户面PM_U发送IuUP建立请求消息。

IuUP建立成功后PM_U向RPI返回建立完成响应，并带回PDCP处理板的IP地址和IuUP Channel ID等参数。 4.

RPI将传输层地址Binding ID、前后向传输数据包大小、速率以及RDMP的IP地址和IuUP Channel ID，请求A2SP申请IP地址和Channel ID（接口详见《块接口设计》）设置定时器等待建立结果。 5. 6. 7. 8.

传输层建立成功后，将分配的IP等参数返回给RPI。 RPI向PM_U发配置消息，将Channel ID带给IuUP。 IuUP收到后通过PM_U

RPI将RAB的完消息返回给SCPI，设定时器)进入PreServing状态。 RAB指派处理流程的第2，3，4步出现异常。 ，3，4处理步骤，数据和配置相关的主要为 1. 3.

AAL2条数配置不一致 双方ATM地址配置不一致

RNC的A2SP发起向对端的建链过程失败。

TD-SCDMA Iu口常见故障处理指导书 内部公开▲

因此定位故障应从如下几个方面来进行判断： 1. 2.

结合性能统计检查数据配置

通过打印观察处理流程具体哪一步出现异常了。

下面就这两方面的情况进行判断：

本文来源：https://www.bwwdw.com/article/smji.html