资源描述
单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,MOT GSM,无线设备培训,BSC,告警和告警处理,覃道满,1,学习目标,掌握告警格式与组成,2,3,熟悉告警处理流程,学习内容,告警格式和组成,告警处理流程,BSC,非正常重启分析,简述,机房运行维护人员经常会碰到告警，有些告警是操作维护过程中自然产生的，有些告警是瞬时性的，不会影响系统正常运行，但大多数告警是会影响系统性能的，有的甚至会导致,BSS,复位，对移动通信系统造成严重影响。因此对于运维人员来说，了解告警系统，掌握一定的告警分析和处理技能，显得非常重要。,告警系统是为了故障定位，系统性能分析及方便维护而设置的。,告警信息可以在,OMCR,的告警窗口上显示，也可以在本地维护终端（,LMT,）上显示。,BSS,产生的告警信息，以字符的形式发往,OMCR,。,告警的种类和格式,告警可以分为硬件告警和软件告警两种：,硬件告警是由于,BSS,内的硬件故障所引起的告警。,软件告警是由,GPROC,检测到软件进程运行出错所引起的告警,只有,GPROC,设备（,BSP,，,CSFP,，,DHP,，,BTP,，,pool GPROC,）才会产生软件告警信息。,告警举例,#0,NEW,*,NONE,*.,CommuncationFailureEvent-,CAGE,- BSS0,1,(BSS0,1,:SITE-0:): 0 CAGE 1 - 30/03/1999 14:23:56.,18,Expansion KSWX Slot 22 Communication Failure - FMIC - Major - -/-.,(BSS01:SITE-0:):0 SITE Impacted to Major.,告警解析,#0,：告警,ID,NEW,：告警状态,NONE,：正在处理此告警的人员,CommuncationFailureEvent,：告警的类型,CAGE,：告警级,BSS0,1,(BSS0,1,:SITE-0:): 0 CAGE 1,：,发生告警的位置,30/03/1999 14:23:56,：告警发生时间,18,：告警编号,Expansion KSWX Slot 22,(,见框架配置表,),Communication Failure,：,告警描述,FMIC,：,告警的清除类型,Major,：,告警严重等级,(,主要告警,),(,BSS01:SITE-0:): 0 SITE Impacted to Major,:,告警附加信息,附,:BSC,机框配置图,告警编号,告警编号对于每种设备都有唯一的一个十进制数表示。每种设备的告警编号从,0,到,254,。,(,见附录,),对于不同的设备告警编号可能重复，但与设备相关的编号是唯一的。有些情况下同样的告警编号表示类似的告警。 例如,242,号告警表示设备退出服务,(MMSMTLRSL),。,告警消除类型,告警的清除类型可分为三类：,Intermittent,Fault Management Initiated Clear,（,FMIC,）,Operator Initiated Clear,（,OIC,）,Intermittent,表示告警是偶发性的，对系统没有危害。此告警发生后在,OMCR,会自动消除。当此类告警频繁产生时，会增加,OML,链路的负荷。我们可以使用,disp_throttle,命令来查看告警门限设置，还可用,chg_throttle,命令调节其门限值。,FMIC,告警的清除由系统的错误管理进程（,Fault Managerment Process,）自动进行。,FM,进程管理一张现有告警的列表，只有当告警产生的原因消失后,FM,才会产生,clear,消息将此告警从告警列表中删除。,OIC,需要由操作人员手动将告警清除。,FM,进程检测到告警产生并判断为,OIC,类型时，将此告警加入现有告警列表中。此后,FM,不再进行任何处理。当操作人员将告警产生的原因解决后，必须将此告警清除。,清除告警步骤,在,OMCR,和,BSC,上均能够清除告警。,OMCR,上清除告警按以下步骤进行,：,打开告警窗口，单击鼠标左键选中要清除的告警项,单击鼠标右键弹出快捷菜单,选择快捷菜单的“,Handle”,选择快捷菜单的“,Clear”,确认告警已被清除,在,BSS,上清除告警，先使用,disp_act_alarm,命令查看有哪些,OIC,告警。然后使用,del_act_alarm,命令将告警清除。清除命令如下,:,del_act_alarm ,(,只对,OIC,告警,),告警的类型,OMCR,将告警分成六种不同的类型，可以在,OMCR,的告警说明中找到,FailureEvents,字段，其为不同类型告警的名称。,附,:,告警类型表,类型,含义,举例,Communication,数据从一点传到另一点时发生错误而产生的告警,一般当信令丢失或呼叫建立出错时发生此种告警,1,、,mms syn loss,2,、,frame slip daily,3,、,bit error,4,、,dri-ctu activelinkcommunication failure(,critical,),Quality of Service,系统的服务质量下降时产生此告警,一般当消息响应超时或带宽减少时会发生此种告警：多见于时钟失锁,gclk_mcuf phase lock failure,（,major,）,Processing,当软件或进程出现错误时产生此告警,一般当进程数据被破坏或系统内存溢出时产生此种告警,dri-CTU channelcoder internal messageerror,intermittent,(,warning,),Equipment,当硬件出错时产生此告警。,一般当出现配置错误，传输、电源等问题时产生此种告警,dri standby link communication failure(,minor,),Environment,当设备所处的环境不利于正常工作时产生告警,一般当出现烟雾，火光被检测到时产生此种告警,Link,当,OMCR,与,BSS,间的,X.25,链路出现问题时产生此告警,告警的等级,影响,行动,举例,严重,(Critical),已经影响了系统的服务,应该立即采取措施,当系统的某一功能出现此种告警而退出服务，应立即将其恢复。,重大,(Major),已经影响了系统的服务,应该马上采取措施,系统的服务容量降低，此时应采取措施恢复容量。,较轻,(Minor),此错误不会对系统的服务造成影响,应采取措施减少更多的此类告警产生,当此种告警数量不断增加时，系统的容量可能受到影响。,警告,(Waring),潜在产生影响系统服务的告警的可能,如果必要应该进行必要的分析，采取措施避免产生更严重的告警,清除,(Clear),告警已经被清除,无,待定,(Investigate),表明此错误的等级无法确定，需要人工进一步分析,进一步查找原因,发现告警,第一种方法：,OMCR,桌面图形界面,GUI,上的,ALARM,按钮,在,OMCR,桌面图形界面,GUI,上双击告警按钮，打开告警窗口，可以看到所有网元（,NE,）的告警信息；,第二种方法：,通过,GUI,上的,EVENT MANEGMENT,点击,GUI,上的,EVENT MAMT,按钮，打开,Display Subscription List,窗口，选择窗口中告警中的一项，选择,open,按钮就打开告警窗口；,第三种方法：,打开,MAP,图，然后选中对应的单元节点,从,NETWORK MAP,上查看告警，单击,GUI,上的,NETWORK MAP,按钮，打开,MAP LIST,窗口，选定其中的一个网元，双击鼠标左键打开,MAP,窗口，在,MAP,图上用鼠标左键点击要查看的网络单元节点，选中后接点会变为紫色，单击鼠标右键在快捷菜单内选择,ALARM,项，此时会出现告警窗口显示此节点单元的所有告警。,用,disp_act_alarm,命令行查看告警,.,告警处理优先级别,我们可以根据告警的严重级别，以及出现告警的网元在系统中的重要性，对不同的告警情况进行相应的处理。在此我们提供一般原则下的优先级别。对于基站来说从,RXCDR,到,BSC,，再到,BTS,；信令链路按照,MTL,、,RSL,、,XBL,的次序；告警严重级别由高到低分别是,Critical,、,Major,、,Minor,、,Warning,、,Investigate,、,Clear,。在相同的告警级别中，,Critical,告警按照以下顺序,All RXCDR-All MTL -All BSC-All RSL-All BTS-All X.25 link-All other Critical alarms,。,Major,告警按照以下顺序,All RXCDR-All BSC-All BTS-All other Major alarms,。其它告警按照,Minor,、,Warning,、,Investigate,、,Clear alarms,的顺序进行处理。,附,:,告警优先级别图,告警处理优先级别,:,The sites,Remote Transcoder (RXCDR),Base Station Controller (BSC),Base Transceiver Station (BTS),The links,Message Transfer part Link (MTL),Radio Signalling Link (RSL),X.25 link,Critical,告警按照以下顺序：,All RXCDR - Critical alarms,All MTL - Critical alarms,All BSC - Critical alarms,All RSL - Critical alarms,All BTS - Critical alarms,All X.25 link - Critical alarms,All other Critical alarms,设备之间的从属关系（,parent-child,）,当某个设备或链路处于,OOS,等非正常状态时，不仅与起本身相关，而且与其上一级（,parent,）设备有关，对,parent,设备进行进行必要的处理是解决问题的重要手段。如果某个设备处于,OOS,等状态下，此设备下一级（,child,）设备将也不能正常工作。,Device,1,st,parent dev,2,nd,parent dev,3,rd,parent dev,4,th,parent dev,RSL,MMS,MSI,CAGE,CAB SITE BSS,MTL,MMS,MSI,CAGE,CAB SITE BSS,OML,MMS,MSI,TCU,DRI,CAB,SITE BSS,XBL,MMS,MSI,CAGE,CAB SITE BSS,告警处理的流程,查看告警,分清告警的级别,明确与告警有关的设备,根据告警手册或经验对告警进行处理,解决问题，消除告警,常见告警及其处理办法,常见告警及其处理方法,.doc,BSC,非正常重启分析,BSC,在网络中的位置和作用,重启分类,原因分析,实例分析,BSC,日常 维护应注意的事项,BSC,稳定运行的条件,BSC,在网络中的位置和作用,在,GSM,无线通信系统中，,BSC,作为基站控制器，是,BSS,子系统的关键节点，一套,BSC,管理几十个基站和,GPRS,网络关键节点,PCU,。,BSC,同时作为,GSM,语音业务和,GPRS,数据业务的无线关键设备，其作用可归纳为：无线管理、电路交换和接续以及协议转换。,BSC,重启，即,BSC,退出服务的过程，将中断,BSS,子系统目前正在进行的工作，受该,BSC,所控制的语音业务和数据业务将不能提供服务，影响相当严重。,附,:BSC,在网络中的位置图,BSC,在网络中的位置,:,MSC,XCDR,BSC,BTS2,BTS1,PCU,SGSN,G,P,R,S,G,S,M,重启原因分类,系统因故障自动重启,人为操作导致系统重启,重启原因分析,机房环境和动力。,BSC,硬件故障。,各种,LINK,的故障。,总线的,Failured,。,BSC,软件故障。,改变数据库和参数设置。,机房环境和动力,主要是频繁出现高温告警，或灰尘比较大，或电源供给中断或不稳定造成的。高温或灰尘比较大的时候，对那些运行时间已比较长的设备威胁比较大，当某个芯片因灰尘积累得比较多而又散热不充分时，芯片有可能因过热被烧毁，芯片所在的插板将会退出服务，当系统容错机制失效时，为了排除故障，系统将不可避免地自动重启，若系统不能自己排除故障，在人为干预之前，系统将会一直处于重启状态。,BSC,硬件故障,这里说的硬件主要是插在,BSC,机框中的各种插板，每个插板的功能不同，出现故障时对整个,BSC,的影响也是不同的。从机框的背板到插槽上的每一块插板的故障都有可能导致系统退出服务，特别是系统不能识别故障板件时，重启将不可避免地发生，其中,GPROC,（处理器板）、,GCLK,（时钟）、,LANx,和,KSWx,（时隙交换扩展板），因数量多或作用关键，出现故障时容易引起,BSC,的重启。这其中又以时钟板最为重要。,各种,LINK,的故障,与,BSC,相连的,LINK,有,MTL,、,RSL,、,OML,、,XBL,、,GSL,。对,BSC,影响最大的是,MTL,和,GSL,两种链路，有可能导致,BSC,自动重启或,BSC,中有死进程存在，有死进程时系统运行将非常缓慢，命令无法执行，需要人为重启,BSC,来清除。,总线的,Failured (1),PBUS,：,PBUS,即,Processor Bus,，它是,MCAP,总线在软件上的一种表示，负责,GPROC,与其他大的插板（,XCDR,、,GCLK,、,KSW,、,DRI,）之间的通信。,PBUS Device Failured,的原因可能是：,LANx,板,Faulty,；,某块板件故障。,可能是,FTP,（故障传输部分）和,FCP,（故障收集部分）之间的错误引起的。,第三种情况属于软件故障，需要人为重启,BSC,来重启这两个进程。,总线的,Failured (2),SBUS,：,SBUS,即,Serial Bus ,它上面的通信由,GPROC,控制，主要负责,GPROC,与小插板板（如,LANx,、,KSWx,、,CLKx,）之间的通信。每个机框的,SBUS,也是一主一备的，但它们被分配不同的任务，,Standby,不享有,Active SBUS,的功能。,当,SBUS failured,后，,BSC,有可能会重启，部分故障不会引起重启。重启结束后，如果,SBUS,仍然是不可用状态，那么就必须去检查具体原因了。,SBUS,有故障时，必须考虑所有被主,GPROC,控制的,SBUS,上的通信。导致,SBUS Failured,的原因有以下几种可能：,LANx,插板没有插到位，与背板的连接不正确，或光纤没有连接好或连接了错误的光纤。,LANx,插板,Failured,。,GPROC,板,Failured,，导致,SBUS,上的通信不正常。,BTC,板不能给背板供电。,总线的,Failured (3),TBUS,：,TBUS,即,TDM BUS,。它由,KSW,控制，每对,KSW,为系统提供,1024,个交换时隙，分配给其它大的插板如,GPROC,、,MSI,、,XCDR,、,KSW,使用，时隙可扩展和扩容。在,TDM,高速总线故障的情况下，系统的主用,TBUS,将会退出服务，系统将要求,TDM highway,做倒换，进而将会使所有机框里的的,TBUS,一起做倒换，如果此时备用的,TBUS,不可用，倒换将不能成功，机框将会退出服务，系统将会要求整个,BSC,重启。引起,TBUS Failured,的原因可能如下：,连接本地与远端,KSWx,的光纤有问题，或者断了。,KSWx,插板,Failured,。,KSW,插板故障或不可用。,总线的,Failured (4),CBUS,：,CBUS,即,Clock Distribution Bus,，通过此总线系统将时钟信号传送到机框背板。给各种大的插板,GPROC,、,KSW,、,MSI,、,XCDR,等插板提供时钟，,CBUS,在整个系统一主一备的。当主用的,CBUS,有故障时，系统会自动倒换到备用的,CBUS,，当然备用的,CBUS,在此时是必须可用的。当备用的,CBUS,不可用而系统倒换时，,BSC,将重启。引起,CBUS Disabled,的原因可能如下：,GCLK,板硬件故障。,扩展时钟信号的光纤有问题。,扩展时钟信号的,KSWx,插板和,CLKx,插板故障。,BSC,软件故障,GPROC,的内存问题。我们知道，,GPROC,在,BSC,中处于相当重要的位置是因为它担任了控制处理功能，,GPROC,的,CUP,也有一定的工作极限，当用作,BSP,的,GPROC,的,CPU,使用率达到,100%,，出现,BSP239 process safe test audit failure(,检测不到,BSP,板,),告警，此时软件故障可以称为进程吊死。遇到这种告警时，需要在,BSC,现场关掉,OML,，即将,Slot16,、,Slot14,板开关下置为 “,disable”,，重启,BSC,。为了节省故障恢复时间，可进入第,3,层，等待出现,waiting for OMC-R,的提示时输入如下命令：,Msg_send 80 0 0 0 1978h-,跳过从,OMC-R,下载数据以加快启动过程。,导致,BSC,重启的原因是因为,BSC,的,SSM,与,BTS,的,CRM,间通信量太大，使得产生的,SM SWFMs,过多所致。最直接的原因是基站的业务量太大，,TCH,拥塞所致。通过调整,cp_messages.c SWFMs,的量，可以解决此问题。为了减少此类故障的发生，建议用处理能力更强大的,GPROC3,做,BSP,，减少重启的可能，当,BSP,负荷很高时，可以考虑设置单独的,OMF,，把,OML,分离出去，降低,BSP,的负荷。在系统话务忙时避免执行大批量的命令，也可减少,BSP,重启的机会。降低单个,GPROC,的负荷，避免某个,GPROC,因负荷太大时自动重启后，负荷被其它,GPROC,分担后出现多米诺骨牌效应，最终导致整个,BSC,重启的悲剧的发生。,有时侯内存并没有问题而是当使用内存时,GPROC,被,locked,了。这时可有三种方法来处理：,将此可能故障的,GPROC,（,BSP,）与其它的,GPROC,交换，即使此,GPROC,再次重启，也不会使,BSC,重启。,换一块好的,GPROC,。,UNLOCK GPROC,改变数据库和参数设置,有时数据库某些参数做了改动后也需要,BSC,重启，才能正常工作或发生作用，特别是一些影响基站正常工作的参数，平时不要随意改动。另外还有可能因为本身新版本软件的缺陷也会偶尔出现问题，需要使,BSC,重启。,事例分析,(1),BSC,的,3,个,GPROCs(0116, 0117, 0118),在不同时间自动,reset,，造成,BSC reset,。,解决：,从收集的数据发现,MTL,不稳定，时好时坏，有告警产生。,CA,向,GPROC,发送,fast_reset,将,GPROC reset,。,因为,GPROC,控制的,MTL,和,RSL,负荷过大，使得,MTL,时好时坏。当一条,MTL,断了，造成其超负荷，就会使得其他,MTL,退出服务。这时可检查此,MTL,的统计数据，或检查,PGROC,的,CPU,的使用率。,因为处理能力的限制使得他们拒绝更多的消息进入。建议用户重新配置,BSC,的容量,;,如某,MSC,下只有某,BSC,范围电话难打，可考虑,reset_site bsc;,如只有部分,RSL,负荷过大，造成电话难大打，可,reassign lcf,。,事例分析,(2),Disable,第二个,GPROC,后,BSC reboot,解决：分析发现：发现,GCLK,退出服务， 使得,BSC reset,。因此使得,BSC reset,的原因不是,lock GPROC,。而是,GCLK,的故障产生的，及时处理,GCLK,的问题，以防再次,Reset BSC,。,BSC,日常维护的注意事项,(1),更换,MSI,板时，先用命令查看,MSI,板的工作状态，如果是未闭锁状态，则应该先将插板闭锁，替换后再解锁，避免在未闭锁状态下直接操作。,GPROC,板出现故障或告警需要拔出时，应该先重启此,GPROC,，确认,GPROC,不能恢复正常，再将,GPROC,的面板上的按键拨到,Disable,，再操作。,GCLK,板出现问题且需更换时，先倒换到备用,GCLK,，将面板上的按键拨到,Disable,后再操作。,安装扳子要到位，要确保插板与背板能连接正确，这样插板才能正常工作，也不会影响与其他插板之间的通信。,BSC,日常维护的注意事项,(2),要注意光纤的清洁，特别是与半尺寸板连接的光纤，如果光纤不干净也会导致插板,Disabled,，成为系统隐患。机柜和各种插板应定期按照规范进行清洗和除尘。,一些,GCLK,、,LANx,、,KSW,等设备的告警和某些死进程可能会使,GPROC,退出服务，特别注意,GPROC 245,号告警，此告警表示一个,GPROC,或,BTP,退出服务。如果主用的,BSP,出现此告警时，,BSC,已经重启了。如果一般的,GPROC,出现此告警，该板会重启，并会影响相应的信令链路，导致有关,BTS,退出服务。当在出现,GPROC 245,号告警前出现大量相关设备的告警时应该注意及时排除，以免引起,GPROC,重启。同时注意,CPU,工作时的负荷，超过,60%,或负荷值异常时，应该排查原因，适当地将工作量移到其他的,GPROC,上或换用处理能力更强的板件。,BSC,日常维护的注意事项,(3),注意日常的告警信息，经常用,disp_act_alarm,和,state 0 oos all,命令查看系统，发现有告警或不在服务状态的设备应该及时进行处理。要及时收集故障记录数据，因为系统的存储有一定的限度，到一定的时间或者一定的数量它就会被覆盖掉。,板件插错槽位会引起,BSC,不停的重启。小插板的螺丝一定要拧到位，以免留下隐患。,BSC,的每个机框至少要有,2,块,GPROC,板和,2,块,MSI,板处于正常状态，以避免当只有一块,GPROC,和一块,MSI,板时，如果其中的,GPROC,或,MSI,板有故障都会引起整个,BSC,重启。在更换,GPROC,和,MSI,板时要特别注意：保持最少有一块,GPROC,和,MSI,是,B-U,状态。如果连续更换,GPROC,（在其它,GPROC,还未恢复正常,B-U,状态时）板则整个,BSC,会重启。,BSC,日常维护的注意事项,(4),更换,BTC,（总线终结）时，只能一块一块地操作，操作之前，先将一个可用的,BTC,板替换与将更换的,BTC,板在同一个机框同一侧的,KSW,板，在状态正常后再开始之后的更换操作，并在所有的更换操作完成后，插回,KSW,板，恢复原状。,通过集中性预防性维护，可以及时发现系统隐患并加以排除，最大限度地提高现行系统设备的利用率，增强系统设备的可靠性，从而减轻平时日常维护的压力。此类维护有：定期进行主备用总线系统的倒换测试，以检验备用系统的可靠性；定期在合适的时间里主动重启设备，清除可能存在的死进程；周期性地对信令负荷和,GPROC,板的,CPU,负荷进行统计，对存在异常的,GPROC,板及时分析原因并采取适当措施；定期对,BSC,机房进行巡检，检查温度、湿度和电源系统，进行告警验证，使机房环境满足稳定运行的需要。,加强专业技能的培训和实践，提高维护人员的维护技能，尽量减少人为的操作失误。,BSC,稳定运行的条件,一是稳定的符合设备运行规范的机房环境，包括适宜的温度和湿度，坚固结实的房屋架构，机房位置没有水患和具有完善的报警和消防系统。,二是安全稳定的动力供给。包括满足要求的设备备品备件，多路供电技术和停电后快速的发电措施。,三是设备包括所有插板和连接光纤没有隐患或可能影响设备运行的告警存在，同时需要,24,小时的告警监控、齐全的备品和备件和及时的处理措施。,四是完善的操作维护和施工规范，完备的应急处理流程和措施。,五是建立一支具有一定维护技能的稳定的维护队伍也相当重要。,BSC,非正常重启案例,故障处理报告实录,.doc,习题,分析BSC产生X.25中断告警的原因。,中国联通有限公司广州分公司,覃道满编制,Thank You !,44,
展开阅读全文