ran故障处理流程

《ran故障处理流程》由会员分享，可在线阅读，更多相关《ran故障处理流程（60页珍藏版）》请在金锄头文库上搜索。

1、RAN故障处理,RAN 6.0,Page 2,现场开局或维护工程师时经常会遇到各种各样的RAN设备调试问题，如何定位问题？如何解决问题？本课程为大家介绍了RAN故障的主要分类和处理流程,前 言,Page 3,学习完此课程，您将会： 掌握RAN故障处理的流程和方法 掌握RAN设备常见故障的定位方法,目 标,Page 4,内容介绍,第1章 故障处理的一般流程 第2章 RNC常见故障分析 第3章 NodeB 常见故障分析,Page 5,故障处理概述,故障处理的一般流程 信息收集 在处理故障前，一般需要收集必要的故障信息 故障判断 在获取故障信息后，需要对故障现象有一个大致的定义，以确定故障的范围与种

2、类 故障定位 故障定位是“从众多可能原因中找出故障原因”的过程 故障排除 故障排除是指采取适当的措施或步骤清除故障、恢复系统的过程。如检修线路、更换单板、修改配置数据、倒换系统、复位单板等,Page 6,故障处理概述,故障的分类,Page 7,故障处理概述,故障定位常用手段 查看告警、指示灯和错误提示 RAN设备为每一条告警提供了丰富的告警处理的操作步骤，按照告警处理的详细操作步骤可以排除大部分故障 接口和协议跟踪 业务演示辅助分析 仪器、仪表辅助分析 性能测量辅助分析 测试辅助分析 对比/互换 主备倒换/复位,Page 8,故障处理概述,当设备出现异常时，而现场又无法及时定位解决，往往需要求

3、助后方技术支持。这就需要现场搜集尽可能多的相关信息，信息越全面，对问题的定位越有利，可以减少定位人员与现场操作人员之间的交互，以便快速定位解决问题。 告警信息 主机错误日志 BAM错误日志 维护台操作日志 自诊断输出信息 单用户的CDR（呼叫数据记录）信息 标准接口信令跟踪消息 数据配置信息,Page 9,故障处理一般流程,发现故障：多种途径、越早越好 判断故障：确定故障位置、范围、种类 定位故障：确定故障原因 解决故障：清除故障、恢复系统,故障处理一般流程,Page 10,故障处理一般流程,告警： 反映系统的“硬伤” 话务统计： 全面的系统监控 用户投诉： 越少越好 全面巡检： 设备“体检”

4、,发现故障的途径,Page 11,故障处理一般流程,RNC故障一般是全网性故障，影响多个基站或所有基站 NodeB故障一般只影响本基站覆盖区域或周边基站切换指标 判断是否为NodeB故障的方法 新开局或扩容时，可以通过“替换法”快速定位是否是RNC问题导致NodeB故障 维护期间，除了数据修改发生错误外，其他RNC故障一般不会对单个NodeB造成影响,故障范围判断,Page 12,故障处理一般流程,RAN侧问题 传输类故障 小区类故障 业务类故障 链路类故障 对接类故障 时钟类故障 天馈类故障,操作维护问题 OMC类故障 加载类故障 网络优化问题 接入类故障 掉话类故障 拥塞类故障 切换类故障

5、,常见故障种类,Page 13,故障处理一般流程,告警信息分析 包含故障或异常现象的具体描述、可能的发生原因、有哪些修复建议等等，涉及硬件、链路、中继、CPU负荷等RAN的各个方面，是进行故障分析和定位的重要依据之一 指示灯状态分析 反映诸如端口、电路、链路、光路、节点、主备用等的工作状态，常常与告警信息分析配合使用 话务统计分析 定位、解决网络问题（尤其是呼叫问题）最有效的手段,故障定位的常用方法,Page 14,故障处理一般流程,仪器、仪表辅助分析 以直观、量化的数据直接反映故障的本质 主要仪器有：信令分析仪、误码仪、测试手机、天馈分析仪等 接口跟踪 利用跟踪的结果，常常可以直接得到呼叫失

6、败的原因，找出问题的症结所在，或者从中得到启发，为后续分析提供宝贵的思路 业务测试 判断RAN侧的业务处理功能和相关设备是否正常最直接的方法,故障定位的常用方法,Page 15,故障处理一般流程,对比/互换 对比：将故障的部件或现象与正常的部件或现象进行比较分析，查出不同点，从而找出问题的所在，一般适用于故障范围单一的场合 互换：将处于正常状态的部件（如单板、光纤，甚至整个基站等）与可能故障的部件对调，比较对调后二者运行状况的变化，以此判断故障的范围或部位，一般适用于故障范围复杂的场合 倒换/复位：只能作为应急措施，迫不得已时谨慎使用 相对于其他方法而言，倒换或复位不能对故障的原因进行精确定位

7、 倒换或复位后，故障现象一般难以在短期内重现，从而容易掩盖故障的本质，给设备的安全、稳定运行带来隐患,故障定位的常用方法,Page 16,故障处理一般流程,联系华为技术支持热线：8008302118（中国） 0755 28560998 填写GCRMS问题单 反馈问题的时候，请注意提供或收集以下信息 局点的详细名称（全称） 联系人姓名、电话号码 故障发生的具体时间 故障现象的详细描述 告警文件、接口跟踪文件、话统结果等原始信息 NodeB的软件版本 故障后已采取的措施和结果 问题的级别及希望解决的时间,故障定位的常用方法,Page 17,小结,故障处理的一般流程 发现故障判断故障定位故障解决故障

8、 故障定位的主要方法 解决一般故障 告警信息分析、指示灯分析 对比/互换 解决复杂故障 话务统计分析、仪器分析 接口跟踪、业务测试 紧急恢复系统 倒换/复位,Page 18,内容介绍,第1章 故障处理的一般流程 第2章 RNC常见故障分析 第3章 NodeB 常见故障分析,Page 19,内容介绍,第3章 RNC常见故障分析 3.1 操作维护类故障 3.2 加载类故障 3.3 接口链路类故障 3.4 业务类故障,Page 20,操作维护类故障,BSC6810操作维护系统组成 操作维护类故障指用户在安装和使用BAM软件、LMT软件过程中发生的故障,Page 21,操作维护类故障,BAM故障的一般

9、分析思路 当BAM运行正常且各模块启动方式为“自动”的情况下，主用BAM服务器上安全监控管理器应该显示各个模块已启动. 当BAM软件的某些模块状态不正常时，可以通过查看运行日志的方法进行故障定位，各模块运行日志存放在BAM软件安装目录下的Serviceslog中 例:D:WCDMARNCBAMVersionAServicesLog 打开各模块的调试窗口，查看调试信息,Page 22,操作维护类故障Case1,重新安装驱动程序后BAM运行异常 故障现象 BAM软件安装，并且运行正常之后 然后重新安装了网卡的驱动程序，发现BAM程序运行异常 故障定位及处理 安装BAM时记录了安装网卡的标识，这个标

10、识是安装网卡驱动程序时分配的，当BAM程序启动运行时会读取这个网卡标识，并根据网卡标识从网卡中读取IP地址，当重新安装网卡驱动后，网卡的标识会重新分配，这时BAM读取的还是以前的网卡标识，所以找不到网卡，读取IP也就失败 重新安装网卡驱动后，需要使用BAM设置工具更新网卡标识,Page 23,内容介绍,第3章 RNC常见故障分析 3.1 操作维护类故障 3.2 加载类故障 3.3 接口链路类故障 3.4 业务类故障,Page 24,内容介绍,第3章 RNC常见故障分析 3.1 操作维护类故障 3.2 加载类故障 3.3 接口链路类故障 3.4 业务类故障,Page 25,接口链路类故障,Iub

11、接口协议栈结构,Page 26,接口链路类故障,Iu-CS接口协议栈结构,Page 27,接口链路类故障,Iu-PS接口协议栈结构,Page 28,接口链路类故障,光口的扰码开关未打开导致IU接口的信令链路不通 故障现象 某局，RNC版本是BSC6810V200R009ENGC01B065+SP02与CS核心网对接时，SAALLNK不通。当RNC和CS直连时，跟踪SAAL信令，发现只有进RNC的消息，没有出RNC的消息. 故障定位及处理 检查RNC侧和CN侧的光扣板的类型，确定两者是一致的。 直接用光纤连接RNC和MGW，但问题依旧。 检查RNC侧和CN侧的数据配置是一致的。 自环时跟踪SAA

12、L，现象也是只有进RNC的消息，没有出RNC的消息，即4个BGN,一个END。所以可以断定应该是RNC侧的问题。 仔细回想和CN对接的整个过程，当BSC6810V200R009ENGC01B065升级SP01补丁的时候，和CN 对接是成功的并可以打通电话。但是当升级SP02补丁后才出现上述描述的问题。所以怀疑SP02补丁是否有限制。 询问研发，才知道当升级SP02补丁的时候承载CS的接口板相应的光口属性中的扰码开关必须是打开的。而查看本RNC的光口属性，扰码开关是关闭的，所以用命令SET OPT修改光口属性中扰码开关为ON，修改完后对接成功可以打通电话。,Page 29,接口链路类故障,SAA

13、L链路CDVT配置太少导致Iu接口信令链路闪断 故障现象 SAAL链路断了在1s之内又恢复，一天会发生好多次 故障定位及处理 SAAL链路丢包的主要原因有：光纤接头脏、光纤接头连接不好、时钟问题和两端流量配置不一致等；如果丢包严重就会导致SAAL断链，由于设置了紧急验证所以断链后又能马上建链成功，所以就出现了信令链路闪断 由于链路只是单向丢包，所以首先怀疑流量配置问题，检查RNC和CN的流量配置发送流量类型都为RTVBR、峰值速率和平均速率等都相同，只有CDVT配置不一样，CN配置为300000，而RNC配置为10240，CDVT的单位是0.1s，即RNC的CDVT只有1ms，怀疑是ATM信元

14、时延抖动导致链路丢包，把RNC侧的CDVT换成102400（即10ms）后丢包现象消失，问题解决,Page 30,内容介绍,第3章 RNC常见故障分析 3.1 操作维护类故障 3.2 加载类故障 3.3 接口链路类故障 3.4 业务类故障,Page 31,业务类故障,BSC6810 光口 匹配 RAB 失败 故障现象 数据配置完成后，RNC和核心网间可以收发信令，但是信令到RAB指派时，RNC响应失败，原因为： iu-transport-connection-failed-to-establish . RNC上有两条告警： Higher Order Path Trace Identifier

15、Mismatch Regeneration Section Trace Identifier Mismatch,Page 32,业务类故障,故障定位及处理 因为信令可以收发，就没有考虑到光口物理配置的问题。但是从RAB指派失败的原因看，问题还是出在传输层。目光返回到RNC的光口告警上。 BSC6800的光口设置用SET OPT命令，只能选择SDH或者sonet. 而6810的SET OPT命令中可以设置J0/J1的格式以及发送内容。 通过与核心网接口格式比对发现：BSC6810的缺省配置是16字节，但是发送内容都是“空”；核心网的J0/J1均为16字节，而发送字为“MGW SDH DEFAUL

16、T”。这与BSC6810缺省配置不同。 将OPT格式改为与核心网配置一致后，问题解决。,Page 33,业务类故障,SAAL链路CDVT配置太少导致Iu接口信令链路闪断 故障现象 某局点需要进行CS域2Gto3G切换，现场使用BSC6810和iDBS。在测试过程中发现切换失败。期间RAN侧没有收到任何切换相关的信令。 故障定位及处理 由于没有收到来自2G的切换信令，问题可能出在GSM侧和核心网侧。现场没有Probe等路测工具进行路测，但核心网使用的是华为G9设备，于是要求核心网同事跟踪了A口、IU口以及其它相关接口的信令. 在A口信令中看到GSM侧上报了handover required，里面包含切换原因值和切换目标LAI与RNC ID，但是紧接着核心网回复了handover required reject，原因值是invalid cell。由此可见GSM侧能够正常触发切换流程，只是在核心网处理过程中被拒绝。在检查handover required内容时发现RNC ID错误，因为GS