ZXSDRBTS故障维护案例.ppt

,zxsdr bts故障维护案例,omcb与sdr站点不能建链（一）,故障现象 sdr基站运行正常，各单板通讯链路正常，ps、cs业务正常，但是sdr与omcb无法建链。 网络结构及ip设置如下图所示：,omcb与sdr站点不能建链（一）,问题分析 考虑到当前基站的业务运行正常，因此认为此时omcb至ibsc和ibsc至bts之间的物理链路正常。初步怀疑是参数设置有误。 排查步骤 检查基站运行情况，发现当前基站运行正常，无单板告警，排除相关单板故障的可能性； 检查同一ibsc下的其他bts，发现omcb至其他bts均无此问题，排除了前后软件版本问题； 通过内部命令(ip_pring_if)检查，确认配置的ip地址正确有效； 当前业务运行正常，说明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成功建链，问题解决。,omcb与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两种方式接入ibsc，具体配置信息如下： rpu虚地址为； omcb通过sbcx的eth4（00/24）和ipbb的端口1（00/24）连接； ipbb板的端口2作为fe方式的sdr的接入端口，ip地址为54/16； euip对基站的ip为118.0.siteid.100/24； 基站的ip地址为118.0.siteid.200/24； 1431单元为ipbb板，1112单元为euip板； 在ipbb上启用端口2，并配置ipbb端口2地址为54/16，将一sdr基站直接连接此端口，并将ip地址设置为118. 0.149.200/16，发现基站不能建链。使用笔记本电脑替代基站，对ipbb进行ping测试，发现链路不通。,omcb与sdr站点不能建链（二）,问题分析 首先对ipbb进行检查，发现正常。然后telnet到rpu上获取调试打印信息，发现有ip冲突的信息提示。因此怀疑是由于ipbb和euip的地址在同一网段造成的。 排查步骤 通过内网地址登陆到ipbb执行命令ip_print_if以查看ipbb网口信息，发现ipbb的2口没有ip地址； 通过内网地址telnet到rpu上，执行brs_memprintfshow命令，发现有指示ipbb和euip的网段在同一网段的错误（详细提示信息参见下图）：,omcb与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反构不成功，说明前台数据不能同步到后台，在链路通的情况下，很可能是ftp端口配置不正确所致。,前后台不能反构数据,排查步骤 首先检查omcb ip、ip abis、omcb channel ip设置，没有发现异常； 检查omcb ftp ip设置文件（perties），将perties 文件中相关基站对应的ip修改为omcb服务器地址； 使用root用户登录网管服务器，使用iptables -t nat l查看系统的ftp端口映射信息，发现tcp和udp没有端口号，初步定位为ftp端口设置没有成功； 查看系统的端口映射配置表(/etc/sysconfig目录下的iptables文件)，可以看到端口映射配置文件中保存了ftp端口，但用iptables t nat l命令查看，没有显示tcp和udp的端口号，说明端口映射配置文件中的端口配置没有生效。,前后台不能反构数据,排查步骤 重启iptables服务之后，再次查看系统的端口映射信息，发现tcp和udp均已经获取了端口号，同时前后台反构数据成功。下图为iptables服务重启前后两次的查询对比：,级联bbu参考时钟丢失告警,故障现象 某站点第三级bbu上报gps时钟参考源丢失告警。 问题分析 时钟问题一般与馈线、电源、数据配置等相关，首先对这些相关部位进行检查。 排查步骤 现场查看cc单板的ref指示灯的闪烁情况。慢闪：表示天馈短路； 使用lmt软件登录该站点查询告警，上报gps天馈断开的告警信息；,级联bbu参考时钟丢失告警,排查步骤 使用dms软件登录该站点的cc单板观察卫星跟踪情况，无可见卫星； 测试该站点的cc单板gps接头的电压，为5.4v，说明gps模块输出无问题； 更换该站点的级联方式，由三级改为二级，发现告警位置发生变化。三级的cc单板上报gps时钟参考源丢失告警。对调原来二级与三级之间的级联线，故障依旧，说明线缆没有问题； 检查数据配置，未发现异常； 对cc单板使用gpscfg命令进行设置gps数据的重新设置。之后，告警故障消失。,配置业务超限造成的载频闭塞,故障现象 某地bsc 3下v3基站站点为s4/4/5配置，采用sdr基站b8200+r8860替换割接到ibsc 37下。 传输割接完成上电后，sdr基站开始下载版本。下载版本完毕之后，后台有rpu配置失败告警，整个站点下3个小区信道均处于闭塞状态。 问题分析 造成载频闭塞的原因可能有2种： 数据配置不合法； 设备故障； 因此，我们应主要从这两方面来进行检查。,配置业务超限造成的载频闭塞,排查步骤 telnet到rru，输入showrru命令查看ru功放。发现ru功放已经关闭，没有功率输出； 复位ru和bbu，故障没有消失； 使用showiqcfg检查基站iq配置情况，发现该站点配置了13载频，但只有12载频与ubpg板有连接关系。由于每块ubpg只有12个iq通道，每个iq通道可以分配给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载频。同步后发现该小区出现数据配置不一致告警，该小区3块载频全部闭塞。 问题分析 修改数据之前，该站点运行正常，没任何告警。出现这样的情况很可能与调整的操作有关。,载频编号不一致导致的载频闭塞,排查步骤 将omcb和omcr数据重新检查，没有发现异常； 怀疑前台修改了配置数据，于是后台重新反构基站数据，也没有发现异常； 仔细核对omcb和omcr配置的数据，发现只有一处地方不一致，omcb中的载频编号与对应的omcr中收发信机编号不同，见下图所示：,载频编号不一致导致的载频闭塞,omcr中的小区数据配置,omcb中的无线资源数据配置,载频编号不一致导致的载频闭塞,排查步骤 将omcr中bcch载频和tch载频编号分别修改为1、2、3，使之与omcb中对应一致。之后执行增量同步操作，告警消失，小区载频解闭，业务恢复正常。 故障总结 在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网口和ipbb端口1通过网线直连。heart1网口地址为54，ipbb端口1地址为50。 问题分析 查询ipbb板的告警发现有大量重复性的端口断告警，怀疑网络端口设置或连接错误。,双sbcx导致的ipbb端口故障,排查步骤 中断heart1和ipbb的网线连接。将电脑连接至ipbb端口1，配置ip 00，ping 50成功； 将电脑连接至heart1口，电脑的本地连接时断时续，ping 54失败，由此定位故障点在heart1口； 重新连接heart1和ipbb端口1。telnet到sbcx，ping 54，一直正常；ping 50失败。以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口都不能用做其他用途。 更改配置之后，故障消失。 故障总结 不通版本的硬件设备及单板，在内部电路设计上往往有着差别微小的。因此应严格按照规范要求进行配置。,光纤交叉引起的切换故障,故障现象 某sdr站点替换原基站后，拨打测试正常，但路测时发现有大量切换掉话。 问题分析 切换掉话的原因很多，有参数设置原因，硬件故障或天馈连接等原因。需要根据情况逐一排查。 排查步骤 检查基站参数配置情况，发现跟割接前一致，因此排除此类故障； 检查站点，无任何告警，暂时认为硬件正常；,光纤交叉引起的切换故障,排查步骤 检查天馈连接（rru至天线），没有发现问题； 测试发现，在小区下直接拨打电话很正常，但切换有问题。经扫频发现，小区2下测到的小区3的信号更强。因此怀疑小区2和小区3的天馈接反了； 再次检查线缆连接，发现rru到天线的连接没有问题，但是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槽位）。 问题分析 此类故障比较复杂，原因可能是多方面的，需要耐心细致地逐步排查。,光纤交叉引起的切换故障,排查步骤 在omcb配置管理中，查询小区3的ru单板输出功率，发现该小区所有ru的输出功率均为“invalid”，同时发现在小区4中，也有部分ru存在同样问题； 因此，初步判断此为小区下无信号的原因，但后台没有任何告警。 从后台telnet到cc板，检查物理载波、逻辑载频和ubpg单板的对应关系，未发现异常； 在cc板通过showstateinfo 命令察看时隙状态正常，未发现异常； 从cc板rlogin到有故障的ru，输入showrru命令，看到“tssi：0.00”，说明rru未能正常获取到bbu配置的功率信息；,光纤交叉引起的切换故障,排查步骤 在故障ru板上，输入dreg命令，查看该ru上配置的频点信息，发现载波0的频点与中心频点的差值超过了5m（25个频点）。检查其它几个无功率的ru，也都发现了同样的问题。 因此可以初步判断是这个原因导致了ru没有功率输出。 因为当在单个ru上的频点范围超出10m时，就会导致ru功放关闭。 另外，检查中还发现在sa和se上都配置了干接点，且sa与se上配置的干接点