NSN基站常见告警说明及处理

NSN基站常见告警说明及处理

1前几代移动通信技术1G2G3G4G第一代移动通信系统第1代移动通信系统（1G）是模拟式通信系统，模拟式是代表在无线传输采用模拟式的FM调制，将介于300Hz到3400Hz的语音转换到高频的载波频率MHz上。第四代移动通信系统4G包括TD-LTE和FDD-LTE两种制式，是集3G与WLAN于一体，并能够快速传输数据、高质量、音频、视频和图像.4G能够以100Mbps以上的速度下载，并能够满足几乎所有用户对于无线服务的要求第二代移动通信系统从1G跨入2G的分水岭则是从模拟调制进入到数字调制，第二代移动通信具备高度的保密性，系统的容量也在增加，同时能够提高多种业务服务。但那个时代GSM的网速仅有9.6KB/s第三代移动通信系统国际电信联盟（ITU）发布了官方第3代移动通信（3G）标准IMT-2000（国际移动通信2000标准）。3G存在四种标准式，分别是CDMA2000，WCDMA，TD-SCDMA，WiMAX。1G->4G：以业务能力或某典型技术来区分。5G：业务驱动数据-量、密度、大数据。连接-量、密度、物联网。体验-随时随地、快速、可靠、低成本移动通信跨代演进中国策略：3G形成突破、4G国际同步、5G引领全球未来触手可及融合演进创新无所不在的服务多领域跨界融合多系统融合多层次/多连接融合多模多业务对于终端的影响先进天线技术更智能化的的网络管理和无线资源管理新的频谱使用新的空口传输技术新的网络架构5G总体愿景5G国际影响5G国际影响5G指标需求/5G之花2G-4G-5G网络架构2G4G5G组网方式NSA优势：•上市时间早，标准更成熟•投资少：4G核心网升级即可•覆盖优势：利用4G网络扩大5G覆盖范围SA优势：•组网简单：只需要NGC和5G基站，无需EPC•5G业务体验更好：高可靠低时延性能方面比NSA好在GSM移动网络系统中，数量最多的网元是基站，出现故障最多的也是基站。而基站工作性能的好坏直接影响整个网络的整体质量。基站的各种软硬件故障直接影响多项网络指标，如掉话率、接通率、载频完好率，切换成功率及TBF掉线率等。基站在网络中起着重要的作用。网络优化是在整个网络相对稳定的情况下进行的，因此关注基站工作状态也是网优的日常工作之一。告警影响117000#~~7999#告警是针对BTS出的告警，是我们日常需要关注的。8000#~~8999#告警是针对传输出的告警2000#~~2999#告警是针对BSC级出的告警告警类型12告警显示13告警参考手册的使用主要是通过查询“故障告警表”，查出跟故障相应的告警号、告警名及告警原因，再根据告警表中的指导一步步排除故障，下表是“故障告警表”的结构。告警参考手册的使用147801告警7801有两种：本地连接和远程连接。此告警无需任何操作，属于提示性告警，连接设备断开告警自动消除。151.7600、7601、7602是BCF（机柜）级的告警，告警的严重等级（7600为最严重告警，7601为重要告警，7602为提示性告警）2.7603、7604、7605是BTS（扇区）级的告警，告警的严重等级（7603为最严重告警，7604为重要告警，7605为提示性告警）3.7606、7607、7608是TRX（载频）级的告警，告警的严重等级（7606为最严重告警，7607为重要告警，7608为提示性告警）4.许多BCF级的告警由BTS级告警引起，许多BTS级告警又是由于TRX级告警引起，所以BTS级的告警是最常见的。76**告警级别167607告警17一、

告警意义：该告警主要告诉我们在载频中出现严重错误。二、站型分析：FLEXIBTS硬件数据库有误会导致7607，这和ULTRASITE有很大的区别，ULTRASITE数据库做错甚至不做都不会引起此类告警。原因是FLEXIBTS需要通过硬件数据库激活某些内部开关及功能，数据库连线如果跟实际不一致，将直接影响其功能，产生告警，所以FLEXIBTS的硬件数据库必须跟实际完全一致。MCPA触发的7607告警与FLEXIBTS有很大的区别，MCPA没有合路器，集成度更高，在FLEXIBTS中传送数据的多根射频线、BUS线，演进到MCPA中，集成在一根光纤中传送数据。处理7607（TRXOPERATIONDEGRADED）告警的主要方法-118处理7607（TRXOPERATIONDEGRADED）

告警的主要方法-2三、处理方法如下：测量天馈驻波比在合理范围内。检查与射频单元各板件间的链接头是否紧固。检查SFP光纤模块（安装是否规范、型号单模或者多模、工作状态、收发是否正常、光功率是否正常）、光纤型号（单模或多模）。近端重启射频模块。检查基站硬件数据库配置（必要时重做）。排除以上故障，更换有故障的射频模块或者耦合器等故障板件。19统计原理：OMC统计每个载频的时隙的信道失败率，对TCH时隙，如果失败率超过20%，对SDCCH时隙，失败率超过80%，则会出7745告警，统计时长为1个小时，该告警只能在BSC上看到，通过BSC告警的增补信息，可以看到具体是哪个时隙故障率高，是TCH还是SDCCH信道以及失败率最高值。告警分析：

该告警属于统计类综合告警，指出信道占用的失败率高于指定的值，并没有指出造成该结果的原因，所以需要综合分析该告警的原因。处理7745（CHANNELFAILURERATEABOVEDEFINEDTHRESHOLD）告警的办法及建议-120告警的含义:在一个信道中，呼叫因失败而终止的比例超出了门限值。该告警用来监控话务和信令信道的功能，并检测可能出故障的信道。补充信息字段:第1字段:标志掉话告警是关于TCH信道还是SDCCH信道，01—TCH信道，02--SDCCH信道第2～9字段:标志0～7时隙掉话率是否高出定义的门限值，00--低于门限值(无告警)，01--高出门限值(告警)。第10字段:故障率最高的时隙。第11字段:子信道标识，对于TCH信道告警:00--半速率TCH子信道0，01--半速率TCH子信道1，02--全速率TCH信道；对于SDCCH信道告警:00～07--SDCCH子信道1～8。第12字段:指定信道中，监测期间因故障造成的TCH或SDCCH子信道释放占全部信道释放的比例。处理7745（CHANNELFAILURERATEABOVEDEFINEDTHRESHOLD）告警的办法及建议-2217745告警22造成该告警原因非常多，主要有以下：基站伴随有其它硬件告警：如7744干扰、7746拥塞这种是最好解决的，只要有针对性的解决了硬件告警，7745告警就能消除。基站无硬件告警，但是硬件或软件确实存在问题，往往伴随上下行质量差大致有以下可能情况：①载频性能下降，但是还未到出告警的程度，例如发射功率偏低等。②RTC的接收故障，但是没有相应告警。③四代站BB2x性能下降，有可能造成通话质量差甚至掉话，无告警。④四代站机柜内RF连线不紧或者接口损坏，这种情况也不一定有告警。⑤基站的同步设置不对会造成切换掉话。⑥载频Bus线不紧也有可能掉话。⑦a-bis口时隙设置有误,TCH时隙跟BSC不一致会产生大量掉话。⑧极少数发生过设备造成干扰，无告警，但产生7745掉话。处理7745（CHANNELFAILURERATEABOVEDEFINEDTHRESHOLD）告警的办法及建议-323处理7745告警的办法及建议：天馈问题：天馈线驻波比偏高，四代站没有天馈监视模块，没有相应告警；五代站有VSWR监控模块，但是驻波比没有超过设定的告警触发值。传输问题：曾经发生过微波传输引起的7745告警，换光端机后问题解决。其它问题：网络信号差造成弱覆盖引起的7745告警。干扰造成的掉话。频率规划不合理。直放站等干扰。塔放造成的干扰。其它干扰源。处理7745（CHANNELFAILURERATEABOVEDEFINEDTHRESHOLD）告警的办法及建议-424五代站RDIV参数设置错误会产生大量7745及掉话，对四代站及五代站宽带合路器的站，该参数没打开对性能有一定影响，但不会直接产生7745掉话，但是对五代站RTC合路器的情况，如果该参数不设，将会产生大面积7745掉话，其原因跟大合路器的原理有关，RDIV参数关闭会造成部分载频两路接收都很差，直接产生掉话，原始该参数是关闭的，开通五代站时一定要打开。处理7745（CHANNELFAILURERATEABOVEDEFINEDTHRESHOLD）告警的办法及建议-525通过前面提到的可能出现7745告警原因分析，比较难处理的是没有其他硬件告警的7745，针对这部分7745的处理主要方法有以下：仔细检查基站同步设置，确保没有问题。仔细检查传输时隙分配，确保跟BSC一致。确保BSC的RDIV参数为“Y”。再次检查机柜内连线（包括Bus线）连接可靠。检查天馈线驻波比。检查天线的方位角、倾角等安装工艺指标是否存在问题。检查硬件数据库和实际是否一致。处理7745（CHANNELFAILURERATEABOVEDEFINEDTHRESHOLD）告警的办法及建议-626处理7745最常用的方法就是通过互换出7745的载频跟没出7745的载频、连线、合路器、天馈线，观察7745是否跟着走，判断是否设备本身问题，注意：首先建议用互换的方式，即好的跟坏的换，不要直接用新的换，这样做虽然麻烦一点，但思路清晰，结果容易说明问题，直接拿新的换由于不能百分百保证新板件一定没问题，所以换过后的结果没有百分百的说服力.为了思路清晰，最好载频、连线、合路器、天馈线分别换.如果7745的结果跟着硬件走，说明是硬件问题，不跟着走，说明跟本次互换的硬件无关。处理7745（CHANNELFAILURERATEABOVEDEFINEDTHRESHOLD）告警的办法及建议-727告警的含义:基站中由于拥塞被拒绝信道占用的请求与所有信道请求之间的比例超出定义的告警门限。该告警用来监控基站的话务量。拥塞对象：01=SDCCH02=TCH03=扩展小区SDCCH04=扩展小区TCH拥塞的原因:高话务量。基站过覆盖。硬件问题。LAC区域规划不合理，导致过多的位置更新或过多的paging消息(SDCCH拥塞)。处理7746(CHCONGESTIONINBTSABOVEDEFINEDTHRESHOLD)告警的办法及建议-1287746告警29如果发现小区拥塞，首先要查看硬件告警，检查小区每线话务量，确定是否基站故障导致拥塞。对于拥塞小区解决办法只有两大类:降低小区吸收的话务量。增加小区承载能力。处理7746(CHCONGESTIONINBTSABOVEDEFINEDTHRESHOLD)告警的办法及建议-230处理7746(CHCONGESTIONINBTSABOVEDEFINEDTHRESHOLD)告警的办法及建议-3TCH拥塞的解决办法：增加容量的办法有:扩容(增加载频)、打开半速率、增加新站。降低话务量的办法有:降低基站天线高度，增大下倾角。使用DR（定向重传）。减小基站覆盖范围，增大最小接入电平值(RXP)，降功率(PMAX)。使用C2。减小小区过载门限值BLT(BTS负荷门限)调整邻区参数使得邻区不容易切换进来(SL，PMRG，OF，PRI，DRT)。31处理7746(CHCONGESTIONINBTSABOVEDEFINEDTHRESHOLD)告警的办法及建议-4SDCCH拥塞小区的解决办法增加容量的办法有:增加SDCCH时隙。扩容(增加载频)使用动态SDCCHLAPD信令由16K改为32K减少SDCCH话务量的方法:减少小区覆盖范围减少位置更新的次数(增大HYS，增大周期位置更新的周期PER)。32告警意义：OMC统计到BTS无话务，告警增补信息指出告警的原因

1=SDCCH无话务2=TCH无话务3=SDCCH和TCH均无话务10=没有GPRS话务故障可能的原因：基站本身问题（硬件或软件设置）。A-bis口设置问题。BSC参数的调整。统计时长过短（可通过参数调整），确实没有话务。处理方法：现场拨打测试话音及数据业务，测试正常的基本都不是设备问题，另外由于在BSC上设置参数控制话务量的分配，常对开通EDGE分离模式的站，EDGE小区数据业务优先，所以大部分没有话务属于正常现象。对拨测不正常的站检查基站软硬件设置，一般比较容易找出问题。7738（BTSWITHNOTRANSACTIONS）告警处理337738告警34断站的标志告警就是7767BCCHMISSING（BCCH信道丢失），随后还会相继出现7700基站OMU信令初始化、7701BCF基站主控板初始化、7708载频重启。如下几种情况会引起断站:由BCCH载频故障引起的断站，主要告警表现为：7606告警，随后会出现基站重启的一系列告警，如：7767、7701、7708等。8***系列告警，一般是传输质量差告警（例如误码高等），错误累计到一定程度就会引起传输失败（7704PCMFAILURE），从而导致基站信令中断（7706BTSO&MLINKFAILURE），基站重启。由传输引起的基站断站，查看历史告警时一般没有别的传输告警（8***系列告警），直接出现（7704PCMFAILURE），从而引起基站重启的一系列告警，如：7767、7706、7708。基站维护人员人为关闭基站（在基站锁扇区等），监控会出现7710告警，相继出现7767。基站断电，如果是交流站，没有蓄电池，也会出现断站，这是首先应该有外部电源告警，然后出现断站的其他告警。基站主控单元BOI或ESM（五代站）故障也会造成断站，并且没有伴随告警，OMUlink直接吊死。BSC方面的故障也有可能造成断站，例如BCSU重启。关于断站故障35告警查看（MML命令）查看告警的常用MML命令有以下几个:查看BTS当前告警:

ZEOL:BCFIDENTIFICATION:BTSALARMNUMBER，ALARMCLASS；

例如:ZEOL:21:NR=7745；查看BCF号为21、告警号为7745、且未被cancel的告警；ZE