《ZXSDR BTS故障维护案例.ppt》由会员分享，可在线阅读，更多相关《ZXSDR BTS故障维护案例.ppt（29页珍藏版）》请在三一办公上搜索。
1、,ZXSDR BTS故障维护案例,OMCB与SDR站点不能建链（一）,故障现象SDR基站运行正常，各单板通讯链路正常，PS、CS业务正常，但是SDR与OMCB无法建链。网络结构及IP设置如下图所示：,OMCB与SDR站点不能建链（一）,问题分析考虑到当前基站的业务运行正常，因此认为此时OMCB至iBSC和iBSC至BTS之间的物理链路正常。初步怀疑是参数设置有误。排查步骤检查基站运行情况，发现当前基站运行正常，无单板告警，排除相关单板故障的可能性；检查同一iBSC下的其他BTS，发现OMCB至其他BTS均无此问题，排除了前后软件版本问题；通过内部命令(ip_pring_if)检查，确认配置的I
2、P地址正确有效；当前业务运行正常，说明iBSC的RPU配置没有问题；,OMCB与SDR站点不能建链（一）,排查步骤从OMCB和BTS侧向对方ping IP地址，都是在最后一步阻止，怀疑作为网关的RPU功能异常；在OMCB侧ping IPBB的OMCB接口、BTS接口、RPU虚地址，均通达；而ping SDR的IP地址，则不通；检查配置数据，在BSC全局资源中，发现OMCB channel IP 参数设置成了OMCB的IP。而另一个局跟这个配置相同，也是OMCB的IP，但OMCB可以建链。将OMCB channel IP 参数设置与IP ABIS一致后，SDR与OMCB成功建链，问题解决。,OM
3、CB与SDR站点不能建链（一）,故障总结对于OMCB Channel IP，要求该参数在SDR中的设置要与BSC全局资源中的设置一样。本例中，由于错误地将操作维护网关的地址配置为IP Abis地址，又把OMCB Channel IP地址配成了OMCB的地址，因此两个地址不匹配导致了前后台的无法建链。至于另外一个配置相同的iBSC，为何依然能够成功能够建链？是因为另外的iBSC采用用E1传输，OMCB Channel IP 地址的配置不影响建链。而对于采用了FE传输的iBSC，则该参数必须正确设置。,OMCB与SDR站点不能建链（二）,故障现象某站点SDR基站，通过EUIP+DTB、IPBB两种
4、方式接入iBSC，具体配置信息如下：RPU虚地址为118.0.0.1；OMCB通过SBCX的eth4（139.0.0.100/24）和IPBB的端口1（139.0.0.200/24）连接；IPBB板的端口2作为FE方式的SDR的接入端口，IP地址为118.0.0.254/16；EUIP对基站的IP为118.0.siteid.100/24；基站的IP地址为118.0.siteid.200/24；1431单元为IPBB板，1112单元为EUIP板；在IPBB上启用端口2，并配置IPBB端口2地址为118.0.0.254/16，将一SDR基站直接连接此端口，并将IP地址设置为118.0.149.20
5、0/16，发现基站不能建链。使用笔记本电脑替代基站，对IPBB进行ping测试，发现链路不通。,OMCB与SDR站点不能建链（二）,问题分析首先对IPBB进行检查，发现正常。然后telnet到RPU上获取调试打印信息，发现有IP冲突的信息提示。因此怀疑是由于IPBB和EUIP的地址在同一网段造成的。排查步骤通过128.0.78.1内网地址登陆到IPBB执行命令ip_print_if以查看IPBB网口信息，发现IPBB的2口没有IP地址；通过内网地址telnet到RPU上，执行Brs_MemPrintfShow命令，发现有指示IPBB和EUIP的网段在同一网段的错误（详细提示信息参见下图）：,O
6、MCB与SDR站点不能建链（二）,排查步骤分析发现IPBB的网口2的IP和EUIP是在同一网段内的，将IPBB网口2的IP地址改为118.0.149.254/24，SDR的IP改为118.0.149.200/24，则站点建链成功。故障排除。同时，在IPBB上重新执行命令ip_print_if，发现端口2恢复正常。,前后台不能反构数据,故障现象某站点SDR站点前台不能反构数据至后台，提示如下错误：于此同时，发现SDR基站运行正常，没有告警信息，且与后台的通信链路顺畅。问题分析SDR站点前后台可以建链，说明物理链路正常。后台OMCB反构不成功，说明前台数据不能同步到后台，在链路通的情况下，很可能是
7、FTP端口配置不正确所致。,前后台不能反构数据,排查步骤首先检查OMCB IP、IP Abis、OMCB Channel IP设置，没有发现异常；检查OMCB FTP IP设置文件（deploy-030womcb.properties），将deploy-030womcb.properties 文件中相关基站对应的IP修改为OMCB服务器地址；使用root用户登录网管服务器，使用iptables-t nat L查看系统的FTP端口映射信息，发现tcp和udp没有端口号，初步定位为ftp端口设置没有成功；查看系统的端口映射配置表(/etc/sysconfig目录下的iptables文件)，可以看到
8、端口映射配置文件中保存了ftp端口，但用iptables t nat L命令查看，没有显示tcp和udp的端口号，说明端口映射配置文件中的端口配置没有生效。,前后台不能反构数据,排查步骤重启iptables服务之后，再次查看系统的端口映射信息，发现TCP和UDP均已经获取了端口号，同时前后台反构数据成功。下图为iptables服务重启前后两次的查询对比：,级联BBU参考时钟丢失告警,故障现象某站点第三级BBU上报GPS时钟参考源丢失告警。问题分析时钟问题一般与馈线、电源、数据配置等相关，首先对这些相关部位进行检查。排查步骤现场查看CC单板的REF指示灯的闪烁情况。慢闪：表示天馈短路；使用LMT
9、软件登录该站点查询告警，上报GPS天馈断开的告警信息；,级联BBU参考时钟丢失告警,排查步骤使用DMS软件登录该站点的CC单板观察卫星跟踪情况，无可见卫星；测试该站点的CC单板GPS接头的电压，为5.4V，说明GPS模块输出无问题；更换该站点的级联方式，由三级改为二级，发现告警位置发生变化。三级的CC单板上报GPS时钟参考源丢失告警。对调原来二级与三级之间的级联线，故障依旧，说明线缆没有问题；检查数据配置，未发现异常；对CC单板使用GpsCfg命令进行设置GPS数据的重新设置。之后，告警故障消失。,配置业务超限造成的载频闭塞,故障现象某地BSC 3下V3基站站点为S4/4/5配置，采用SDR基
10、站B8200+R8860替换割接到iBSC 37下。传输割接完成上电后，SDR基站开始下载版本。下载版本完毕之后，后台有RPU配置失败告警，整个站点下3个小区信道均处于闭塞状态。问题分析造成载频闭塞的原因可能有2种：数据配置不合法；设备故障；因此，我们应主要从这两方面来进行检查。,配置业务超限造成的载频闭塞,排查步骤Telnet到RRU，输入showrru命令查看RU功放。发现RU功放已经关闭，没有功率输出；复位RU和BBU，故障没有消失；使用ShowIQCfg检查基站IQ配置情况，发现该站点配置了13载频，但只有12载频与UBPG板有连接关系。由于每块UBPG只有12个IQ通道，每个IQ通道
11、可以分配给1个载频，因此UBPG的最大承载能力是12个载频；临时删除1个载频，使之在UBPG的承载范围内。在执行增量同步后，载频解闭，业务恢复正常。,载频编号不一致导致的载频闭塞,故障现象某一新建SDR站点配置3个载频，收发信机1为BCCH载频，收发信机2、收发信机3为TCH载频。在进行拨测时发现小区BCCH载频频点有干扰，优化工程师建议调整BCCH载频和TCH载频频点。于是后台将原来的BCCH载频（收发信机1）删除，再重新创建新的TCH载频（收发信机4），将收发信机2调整为BCCH载频。调整后收发信机2为BCCH载频，收发信机3、收发信机4为TCH载频。同步后发现该小区出现数据配置不一致告警
12、，该小区3块载频全部闭塞。问题分析修改数据之前，该站点运行正常，没任何告警。出现这样的情况很可能与调整的操作有关。,载频编号不一致导致的载频闭塞,排查步骤将OMCB和OMCR数据重新检查，没有发现异常；怀疑前台修改了配置数据，于是后台重新反构基站数据，也没有发现异常；仔细核对OMCB和OMCR配置的数据，发现只有一处地方不一致，OMCB中的载频编号与对应的OMCR中收发信机编号不同，见下图所示：,载频编号不一致导致的载频闭塞,OMCR中的小区数据配置,OMCB中的无线资源数据配置,载频编号不一致导致的载频闭塞,排查步骤将OMCR中BCCH载频和TCH载频编号分别修改为1、2、3，使之与OMCB
13、中对应一致。之后执行增量同步操作，告警消失，小区载频解闭，业务恢复正常。故障总结在SDR基站中，由于引入了OMCB，因此在进行配置数据的修改时，要兼顾OMCR和OMCB，避免二者出现不一致引起故障。,双SBCX导致的IPBB端口故障,故障现象在某工程现场，工程师为了调试其中一块SBCX板，将其插入正在运行的BSC控制框的1，2槽位。同时在该BSC的3，4槽位仍然插有属于它的SBCX板。在新插入SBCX后，原本正常运行的该BSC下的所有SDR基站都与OMCB断链。本局因为下挂SDR基站，需要配置OMCB服务器地址，现场选择的是SBCX的eth1网卡，对应RSVB的Heart1网口。Heart1网
14、口和IPBB端口1通过网线直连。Heart1网口地址为139.1.0.254，IPBB端口1地址为139.1.0.250。问题分析查询IPBB板的告警发现有大量重复性的端口断告警，怀疑网络端口设置或连接错误。,双SBCX导致的IPBB端口故障,排查步骤中断Heart1和IPBB的网线连接。将电脑连接至IPBB端口1，配置IP 139.1.0.200，ping 139.1.0.250成功；将电脑连接至Heart1口，电脑的本地连接时断时续，ping 139.1.0.254失败，由此定位故障点在Heart1口；重新连接Heart1和IPBB端口1。telnet到SBCX，ping 139.1.0.
15、254，一直正常；ping 139.1.0.250失败。以root用户登录并重启网络服务，ping测试结果不变；将1，2槽位的SBCX拔出，发现IPBB端口连接成功，所有SDR基站OMCB建链成功；再次插入此SBCX，上电成功后再次出现IPBB端口断告警；,双SBCX导致的IPBB端口故障,排查步骤检查控制框背板的PCB时，发现该背板的版本为BCTC 060201。经过咨询了解到，060201以上版本的背板已经把1、2槽位和3、4槽位的HEART1、2网口内部互连了，因此主备槽位的SBCX板HEART1、2口都不能用做其他用途。更改配置之后，故障消失。故障总结不通版本的硬件设备及单板，在内部电
16、路设计上往往有着差别微小的。因此应严格按照规范要求进行配置。,光纤交叉引起的切换故障,故障现象某SDR站点替换原基站后，拨打测试正常，但路测时发现有大量切换掉话。问题分析切换掉话的原因很多，有参数设置原因，硬件故障或天馈连接等原因。需要根据情况逐一排查。排查步骤检查基站参数配置情况，发现跟割接前一致，因此排除此类故障；检查站点，无任何告警，暂时认为硬件正常；,光纤交叉引起的切换故障,排查步骤检查天馈连接（RRU至天线），没有发现问题；测试发现，在小区下直接拨打电话很正常，但切换有问题。经扫频发现，小区2下测到的小区3的信号更强。因此怀疑小区2和小区3的天馈接反了；再次检查线缆连接，发现RRU到
17、天线的连接没有问题，但是2个小区BBU到RRU的光纤接反了；调整光线连接，故障消失，业务正常。故障总结BBU到两个RRU的光纤接反，导致2个小区实际覆盖的范围和邻区关系发生了变化，从而引起大量切换掉话问题。此类故障和天馈的接错类似。,光纤交叉引起的切换故障,故障现象某BS8800站点的小区3下手机无信号，且后台无任何告警信号，动态管理中显示该小区的TRX、信道均为解闭状态。该BS8800配置较大，尤其是3、4 小区，其中小区3有11个载频，配置了4块RSU60（主机架的3、4、5、6槽位）；小区4有13块载频，配置了5块RSU60（辅机架的2、3、4、5、6槽位）。问题分析此类故障比较复杂，原
18、因可能是多方面的，需要耐心细致地逐步排查。,光纤交叉引起的切换故障,排查步骤在OMCB配置管理中，查询小区3的RU单板输出功率，发现该小区所有RU的输出功率均为“Invalid”，同时发现在小区4中，也有部分RU存在同样问题；因此，初步判断此为小区下无信号的原因，但后台没有任何告警。从后台Telnet到CC板，检查物理载波、逻辑载频和UBPG单板的对应关系，未发现异常；在CC板通过ShowStateInfo 命令察看时隙状态正常，未发现异常；从CC板rlogin到有故障的RU，输入showrru命令，看到“TSSI：0.00”，说明RRU未能正常获取到BBU配置的功率信息；,光纤交叉引起的切换
19、故障,排查步骤在故障RU板上，输入dreg命令，查看该RU上配置的频点信息，发现载波0的频点与中心频点的差值超过了5M（25个频点）。检查其它几个无功率的RU，也都发现了同样的问题。因此可以初步判断是这个原因导致了RU没有功率输出。因为当在单个RU上的频点范围超出10M时，就会导致RU功放关闭。另外，检查中还发现在SA和SE上都配置了干接点，且SA与SE上配置的干接点编号有重复，因此导致在频点超出范围时RU无法正常上报告警；尝试删除部分干接点配置后，发现有告警信息上报；,光纤交叉引起的切换故障,排查步骤调整该站点的频率配置，并重新分配跳频序列，故障消失，业务正常。故障总结当小区中的频率配置比较复杂时，需要仔细检查每个RU中的频点范围是否超出10M带宽。如果小区设置了跳频，那么每个TRX是没有固定频点的，此时为了保证每个RU上分配的频点不超范围，可以通过合理配置跳频序列来实现，以保证每个跳频序列中的频点范围不超过10M。逻辑频点对应的RU是系统自动分配的，对于有多个RU的小区，要想人为把某些频点配置到某个RU上，可以利用多载频联合组号来实现。,
