ASB无线网络事业部交流稿BSS部分

ASB无线网络事业部交流稿（BSS部分）,典型案例分析,典型案例分析,本节根据中国移动Alcatel无线网络的特点，就BSS方面的几个典型的问题，进行了详尽的分析，并给出了解决方案以及预防措施。衷心希望通过此次技术探讨和交流，能够对提高双方的技术水平，对中国移动的网络建设维护起到积极的作用。,第一部分BSCX.25和OSI_CPR问题处理第二部分CellMisaligned或Inconfig问题分析及解决方法第三部分ALCATELGSM无线话务报告丢失问题分析第四部分关于空闲ASMB在OMCR上显示告警的消除第五部分关于Qmux故障处理,典型案例分析,典型案例分析第一部分BSCX.25和OSI_CPR问题处理,自从BSSB6.2版本以来,出现了诸多BSC的OSI_CPR模块的故障。OSI_CPR模块的主要作用是联系BSC与OMC-R，因而若该模块发生故障，必将严重影响OMC-R对BSS系统的操作与维护。现就此问题将现场的故障处理情况予以分析和总结,希望给现场以后处理类似问题以借鉴。,BSC,OSI-CPRC,OMC-R,ROUTER,ASMB,ASMC,MSC,TC,典型案例分析第一部分BSCX.25和OSI_CPR问题处理,问题分类：【1】由OSI_CPR问题引起的X.25故障：OSI_CPRFOS告警为：OV_RELC，无法通过INIT命令来解决问题。【2】由传输路径上的问题引起的X.25时隙问题：OSI_CPR无告警，但路由器中显示其时隙状态为DOWN。,典型案例分析第一部分BSCX.25和OSI_CPR问题处理,【1】由OSI_CPR问题引起的X.25故障一般表现为：出现故障的BSC都无硬件问题（能够通过HWTEST）。BSC的一块或两块OSI_CPR状态FOS，告警为OV_RELC;对模块INIT后,模块可以到IT状态但不稳定，自动RESET3次后又变为FOS状态；使用VERIFY命令结果相同。通过对各种实例的处理和分析，该问题分又可以分为以下两种情况：【1.1】两块OSI_CPR同时FOS，BSC与OMC-R中断连接【1.2】一块OSI_CPRFOS状态，常规操作无法解决问题,1.1首先，断开A接口中Trunk2和6,问题原因：由于误操作造成，在信道配置中将CBC设成了CBH解决方法：修改DLS中相关Relation，BOOTBSC。预防方案：做好DLS的备份工作，严格按照手册修改数据。由于该问题频繁发生，在B7.2版本中完善了该机制，保证在无操作是，不再发生问题。,如果问题依旧（B6）,典型案例分析第一部分BSCX.25和OSI_CPR问题处理,问题原因：一般由于A接口模块故障造成，包括ASMC、ATBX、ASMB、及交换模块等解决方法：无线侧检查ASMC,ATBX,ASMB的时隙分配是否正确，同时要求MSC工程师配合检查,如果问题解决,1.2首先，断开A接口中Trunk2和6,问题表现：INIT模块后CPR可以IT，但之后模块马上自动RESET，三次后CPRFOS；问题原因：一般由于BTS_ADAPTOR的状态异常，BSC告警异过多，引起OSI_CPR负荷过重，导致此问题发生解决方法：通过BSCTERMINAL对BSC进行观察，Lock所有状态不正常的BTS_ADAPTOR，该问题一般能解决；对于BSC出现频繁告警的模块(如:RA:VSWR等)暂时LOCK，等CPR恢复后再打开，并解决其告警。*,如果问题依旧,问题原因：由于A接口模块造成，包括：ASMC、ATBX、ASMB、及交换模块问题引起，其中较多发生的是由于ATBX的SETTING错误。解决方法：可以UPLOADATBX的MAPPINGFILE，观察31TS便知。如发现出错，可以通过重新SETTING来解决问题,如果问题解决,典型案例分析第一部分BSCX.25和OSI_CPR问题处理,*另外值指出的是，若发现BTS_ADAPTOR的状态异常，特别是在OMC-R上显示状态为MSA，在BSCTerminal上显示状态不稳定的模块，还会引起其他多种问题，如：PRC激活时TCUFLT；切换SYS_CPR，BSC不稳定等等.其根本原因由于BTS_ADAPTOR状态FLT，当CPR有动作时，与问题BTS_ADAPTOR相关的TCU，DTC等网元的状态亦会随之刷新，导致大量的内部MSG送往CPR，使其不堪重负。当然对于其他模块如果也有类似现象。因此，防患于未然，及时发现问题并予以解决是网络维护的重中之重。,典型案例分析第一部分BSCX.25和OSI_CPR问题处理,【2】由传输路径上的故障引起的X.25链路问题，表现为：OSI_CPR无告警，但路由器中显示时隙状态为DOWNOSI_CPR的X.25显示X.25不通问题原因：一般是由.路径上传输模块的相应时隙故障引起的，分下列几种情况：解决方法：TC模块问题：在ATR2/6模块上观察到无话务占用的情况，RESETATBX/MT120即可；ASMB/ASMC的相应时隙异常占用，插拔后即可；交换的SPC模块问题，对SPC进行重新删创或RESET相应模块即可；,典型案例分析第一部分BSCX.25和OSI_CPR问题处理,现将上述的X.25问题的分析小结如下：第一类问题问题原因：操作不当注意事项：因此操作人员应该严格按操作流程，谨慎对网络进行操作，避免出现故障;第二类问题问题原因：由于传输模块中对应的时隙状态异常引起。注意事项：在设备开通之初，必须对各个传输模块作正确的设置（SETTING）在日常维护中，应通过OMC-R对X.25的时隙状态进行经常性的观察，发现问题及时处理，以避免问题的积累。,典型案例分析第一部分BSCX.25和OSI_CPR问题处理,相关知识：从ALCATEL无线软件B6.2版本开始，BSC系统的数据库开始更灵活的开放给用户，这使得用户可以更便捷地进行网络配置上的更改。ALCATEL的网络配置数据库主要存放在OMC_DataBase，BSC_DLS,以及基站相关控制模块中。由于各数据库之间的联系，可能会受到外部（比如说传输问题），或内部（比如说OMC进程，BSC负荷）的影响，导致各数据库间的数据内容不一致；为此在ALCATEL无线B6.2版本之后，系统为了保证监控设备（OMCR）与控制设备（BSC）之间的数据准确同步而引入的一种机制（Misaligned）。当小区出现Misaligned时，说明OMCR和BSC之间的存在不同的数据。触发Misaligned机制的情况有很多种，其中包括X25连接不好，基站传输不稳定，PRC激活的小区数量过大等等。ALCATEL在无线B7版本中，对系统内部消息同步机制进行了修改和完善，系统模块间的消息处理量有了相当的减少，这从而减少了由于模块负荷过高而造成Misaligned的触发。但是我们还是认为：减少Misaligned出现的次数，一方面必须从日常维护着手，消除设备中存在的大量的传输告警，另一方面，在进行网络配置修改时，必须严格按照相关手册进行操作。,典型案例分析第二部分CELL/BSCMISALIGNED问题分析及处理,典型案例分析第二部分CELL/BSCMISALIGNED问题分析及处理,问题描述问题症状:当激活一个PRC或者在SC窗口中，直接进行在线网络配置修改时，某个小区出现Misaligned。问题分析:在该小区上，单击右键激活的弹出窗口中，执行“ShowAlignmentStatusCause”功能，用户可以观察到引起Misaligned的具体原因。解决方法情况一：如果在GSMalignmentcause中显示问题原因为“lostofcommunicationwithBSC”。则需观察此时BSC-OMC的连接状况；如果连接问题得到解决，而该BSC下出现Misaligned的小区又很多，此时则需要通过对BSC做ForceConfigBSS另外还需要做小区的ForceConfig。情况二：如果在GSMalignmentstatuscause中显示为“jobunsuccessfullreceivedfromtheBSC”,则需要做BSSForceConfig(如果此时有许多小区Misaligned则还需做这些小区的ForceConfig),情况三：如果执行了ForceConfig后，小区依然处于Misaligned的状态。此时则必须通过PRC来删创该小区。,情况四：如果由于”ThereisacommunicationproblemwithBSC”原因引起Misaligned，而且执行Cell/BSC/BSSForceConfig后，小区或BSC依然保持Misaligned状态；但此时OMC与BSC的连接正常。通常操作中，该BSC可能需要很长时间，去响应OMC发出的逻辑数据修改等命令。在这种情况下，则需要调整相关的logicalparm_modify参数的时间值，来改善响应速度：fromshorttomedium（如果BSC的响应时间超过3分钟）fromshorttolong（如果BSC的响应时间超过5分钟）fromshorttoveryLong（如果BSC的响应时间超过15分钟）BSSIM进程需要重启一次（stoppedandstarted），目的是为了使修改启效。如果以上操作无法解决问题，请联系ALCATEL的技术支持人员解决。,典型案例分析第二部分CELL/BSCMISALIGNED问题分析及处理,典型案例分析第二部分CELL处于InConfig状态的分析及处理,问题分析:在该小区被修改时，相关的RNIM进程Crashed或被中止。这导致了RNIMSC无法接收到修改操作的结束信息，从而导致了该小区一直处于等待状态。,问题描述问题症状:小区AlignmentStatus状态一直处于InConfig状态（在RNUSM中该小区上出现沙漏标记）,解决方法1）首先在SC窗口中编辑任意一个小区。2）修改任何一个可修改的参数（除了GPRS参数），然后激活所修改的内容（APPLY）。此时状态变为Aligned；如果没有，则需要在DSMUSM中重启（Stop/Start）相关的RNIMSC进程。3）重新将参数改回到先前值。或者只删除一条切换关系中的切出关系，然后等待队列的状态将先变为等待结束，随后有变为等待队列状态。之后可以简单地重新加上切换关系，该问题就会解决。,典型案例分析第二部分CELL处于InConfig状态的分析及处理,什么是无线话务报告？无线话务统计报告（下称话务报告）是由网管系统(NMC)从设备提供商的操作维护中心(OMC-R)系统上采集的文本，包含了用于衡量无线网络话务质量的计数器。话务报告中的各个计数器是对无线部分（BSS）的各种Telecom行为进行测量，或累加或采样，由BSC中央处理模块定时收集所有计数器的统计值，再发送到OMC-R上。OMC-R在收到BSC的原始统计报告（二进制格式文件）后，将对其进行文件格式的转换，最终生成了符合中国移动集团公司要求的话务统计报告（文本文件格式）。,典型案例分析第三部分无线话务报告丢失问题的分析和解决方案,LDC,OSI-CPRC,OMCR,DCN,BSC,X,典型案例分析第三部分无线话务报告丢失问题的分析和解决方案,PC,用户,OMC-R和BSC的典型连接拓朴图如下：,当BSC的性能统计报告通过DCN（DigitalCommunicationNetwork）传给OMC-R主机后，才由OMC-R作数据的后处理工作（格式转换）。而DCN只是个逻辑概念，它是由Cisco路由器、PCMCable、MSC的半永久连接链路、第三方传输设备、TC等组合起来的一个传输网络，具体涉及的传输设备比较多，连接方式非常灵活，所以情况也就可能比较复杂。,一种较为简单的连接方式,典型案例分析第三部分无线话务报告丢失问题的分析和解决方案,通过对案例进行分析，我们总结出以下几种典型情况：【1】问题原因：相关传输模块不稳定导致BSC和OMC-R连接中断；或者是BSC产生过多的告警而且没有及时处理，导致BSC和OMC-R链路过忙，无法正常响应OMC-R或BSC发出的请求等.解决方法：消除网络中的告警，尤其时大量重复且频繁出现的告警。【2】问题原因：由于BSC内部资源的匮乏引起，如BSC相关网元存储异常（一般指OSI-CPR）；解决方法：插拔OSI-CPRC模块，释放其内部资源。,典型案例分析第三部分无线话务报告丢失问题的分析和解决方案,【3】问题原因：由于文件传输机制上的缺陷，在某种突发情况时，BSC的OSI-CPR无法响应OMC-R传送文件的请求，话务报告文件无法被上传到OMC-R，滞留在BSC的OSI-CPR中；解决方法：在B72应用的网络中，OMC-R中应用了重传机制，当话务报告因某种原因没有被传送到OMC-R时，系统自动启动重传机制，把文件从BSS传送到OMC-R。合理设置参数，可以在最大程度上确保话务报告文件不丢失。具体参数为/alcatel/omc3/bsscomm/conf/param.cfg中maxNbOfFtamRetrans为确保话务报告文件不丢失，我们建议将重传次数从2调整到7。【4】由于其他原因引起的极个别的案例（如相应的数据库/进程被重新启动，BSC网元重新启动或退出服务，人为干预等）。,典型案例分析第三部分无线话务报告丢失问题的分析和解决方案,网管发现报告丢失时，可以遵循以下思路来寻找问题的症结：,典型案例分析第三部分无线话务报告丢失问题的分析和解决方案,我们在日常维护工作中会时常遇到空闲的ASMB模块上的告警消除不了，例如：AIS2M等等。根据这种情况我们制定了一套较为有效的解决方法，可以消除此类告警信息。,典型案例分析第四部分关于空闲ASMB在OMCR上显示告警的消除,【1】：检查BSC后面板相应的HW位置是否已经自环，如没有，做自环。如下图1（可以参照其它已经自环或者已经放置HW线的位置）：,典型案例分析第四部分关于空闲ASMB在OMCR上显示告警的消除,【2】：在OMCR上的BSSUSM的MAINView窗口中打开A/AterMux窗口，如下图2,典型案例分析第四部分关于空闲ASMB在OMCR上显示告警的消除,在对相应的AterMuxConnection做以下操作2.1InhibitAlarmReportingonBSCSide2.2InhibitAlarmReportingonTCSide2.3InhibitAlarmReportingonAllATps2.4LockAllAterTps操作结束后，如下图3（图中对应的是第10块ASMB）,【3】：用LMTCTB7.2终端对相应的ASMB重新做setting，如下图4,典型案例分析第四部分关于空闲ASMB在OMCR上显示告警的消除,3.1Setting所用download的文件用所附的文件，所附Setting文件名为：C20040826101852n3.2下载结束后，重新设定Qmux地址，BSC的Qmux地址表如表1,典型案例分析第四部分关于空闲ASMB在OMCR上显示告警的消除,典型案例分析第五部分关于Qmux故障处理,BSS的版本升到B6之后,所有的传输模块全部成为MO，所有SETTING均由TSC通过Qmux总线进行下载。所以每个传输模块都非常重要，若TSC或BIUA不正常将导致SETTING文件无法下载到BTS,BTS就无法顺利开启；另外B6以后各种传输的配置和参数都可通过OMC_R进行修改，若模块的工作不正常也将导致参数的无法修改给工作带来很大麻烦。本文档将就关于此类问题作出细致的分析和探讨，将告警的简单处理流程归纳如下，并描述了一些现场遇到的一些有特点的问题。,LOCALQ1告警的处理流程：RemoteQ1告警的处理流程：注1：A-bis问题一般有两种:1）某路传输中间链路有环路,可通过观察BTS状态:某个BTSOMLFLT而传输无告警,断开该传输2）是传输时隙的设置问题,特别是出现在A-bis上使用时隙复用设备的地方,由于时隙在复用时占用Qmux的时隙,这只能通过修改设置来解决。另外有时在较多BTS中找出个别有故障的BTS十分困难，可以在晚间无话务时逐步断开BTS传输直到告警消失，在逐步恢复，过程中便可准确找出故障BTS然后解决之。注2：B6对于G3BTS可将传输配置模式改为OML，再LOCKBTSADAPTOR,ResetOMU后再UNLOCKADAPTOR。,典型案例分析第五部分关于Qmux故障处理,1电缆问题引起ASMBLOCALQ1告警描述：某地BSC41第3分架ASMB3、4FLT，该BSC为CONFIG5，上半部无模块，将下半架的Q1输出线直接连到故障的ASMB输入口问题解决，确认问题在上半架的连线中一一检查BSC背板的LOCALQ1线(由于Q1线是串联的所以必须逐个检查)，发现其中有一根中断，焊接恢复后问题解决。总结：一般的电缆故障较为明显，但此例由于上半架无模块所以前面无告警，而ASBM的Q1输入电缆是有上半架迂回连接，所以应先屏蔽上半架（跳线），从而找出故障点。2综合问题描述：某两地BSCQ1告警处理，其中1BSC问题较为复杂：1BSC第1架的所有传输模块有LOCAL的Q1告警，并且所有电缆及模块地址均无故障，由于Q1的LOCALBUS都是串联所以应从头查起，由于是第1架，所以将TSC出来的口用1根好电缆直接跳到BIUA1且断开其与后面传输板的连接线（排除COMMTSU处电缆及背板及后面传输板对总线的影响），此时BIUA1恢复，然后逐步恢复后面的连线，过程中发现1PLUG插错位置（由于定位片出错所以之前未发现），连接好所有接线后现在仅有两块ASMB不好，经过换板问题解决。总结：此BSC共有3个问题：1、TSC到BIUA之间可能存在的物理连接问题，2、PLUG位置问题，3、ASMB模块问题。三者综合使问题判断困难，不过由于LOCALBUS的连接较为灵活可通过改变其连接方式以判断问题所在；,典型案例分析第五部分关于Qmux故障处理,3LOCAL告警后面模块影响前面模块:描述：BSC中两块BIUA板状态不正确,用终端观察其状态为FLT,通过差拔、换板、RESETTSC等操作后问题依旧，后通过观察BSC中共有4块传输板有告警且所有故障板正好为在一条QILOCAL总线上的四块连续的四块板：判断应该为背板连线不好，经检查电缆正确；接下来分析应该处于四块模块的第一块的连线有问题，便于通过交叉替换未发现输入电缆故障，致使问题解决变的很困难；若前面无故障，会不会是后面有问题，遂断开输出电缆，BIUA变IT，插上后BIUAFLT使问题集中到3电缆和两块ASMB，更换ASMB后问题依然，便判定输出电缆有问题。总结：检查电缆时断开输出电缆是很有必要的，可屏蔽后面问题影响的可能性。由于B6所有传输板的软件均由BSC通过Q14TSC模块故障引起BIUA故障：描述：某地遇到BSC4一块BIUAFOS,告警为DOWNLOADFAIL其下挂有4BTS,1BTSRSL全部FLT,另1BTS/RSL有两根FLT，其他正常。故障发生有一段时间了，在更换BIUA、TCU、RESETTSC等各种操作后问题依然，所以问题显得较棘手。经了解此BIUA原先正常，再则该BIUA下有BTS正常工作所以其背板连线应无故障，分析后怀疑两点：1）由于BIUA已换过，结合其告警类型，焦点落在它的上级模块TSC上，与其