关于物业协调问题

htj-94-9

关于物业协调问题

物业的协调是我在实习当中遇到的问题之一各基站的分布很不均匀，有的在地下停车场，有的在各种建筑的天面，甚至有的还在住宅区的楼房里，故物业方面比较难于处理。在工作中由于物业问题的存在，会影响到整个工程的整体施工进度。
此问题在我实习初期非常棘手，由于经验不足，工作涉世未深等原因，面对这类问题难免不知所措。

来源与现状各基站分布很不均匀，广州这边有很多基站处在一些高楼大厦，而这些物业的管理制度又是很严格的，因此，到这些站点去，往往要到工程部、客服中心、保安部等部门去协调，有的站点甚至限制了维护人员进入的时间，给维护工作带来诸多不便。
思考及解决方案由于基站分布不均匀，更多是分布在一些管理严格的地方，如花园小区，会展中心以及高级酒店等，进去基站之前必须有相关的证明，还要申请，故必须提前拿好证明和工具，才能保证一旦有故障；能及时的进站解决问题。此外，有些私人住宅区的居民对自己生活的地方存在基站很不满，我们也必须事先跟他们的业主沟通协调，避免矛盾发生。

关于基站内部环境问题来源与现状基站内部环境的问题主要是因为基站是出于一个封闭的环境,机房建筑多以钢筋混凝土为骨架，再加上全封闭式的外装修，因此，基站里面，机架的散热性能减弱，基站时不时会有温度告警的情况发生，有时跑很远的路，就是为了解决一个温告问题，浪费了人力与物力。还有的是，机架的馈线接出去后，完全暴露在外面，有时下雨，馈线进水就有可能引起机架的问题。

思考及解决方案对于温告的问题，经过多次的维护，发现主要是因为这些基站里面的机架很多，周围的封闭环境使其散热的速度很慢，隔一段时间，基站室内温度达到某一个高度，就自然会引起环境监控系统的报警。
为了解决这问题，我们和老队员合力研究，最后终于提出我们的方案，首先是把那些经常发生温告的基站里的机架门打开，这样，避免了机架温度过高而引起机架的报警。接着，发现无论在多大的基站里，一般都只有配置两台空调，这对于大站来说是不够的，因此我们建议移动公司在大站里多配置一些空调，这样，基站温告发生的频率就没那么高了，虽然这方法也只是治标不治本，但的确节省了物力人力。
而对于馈线的问题，就简单多了，就是在馈线暴露在外面的部分，用一些材料保护起来，避免下雨天的时候，馈线进水。当然，在用这些保护材料时，要考虑到材料是否会对传输造成影响。

关于基站本身设备的各种问题来源与现状基站本身设备的问题是代维工作中最重要的，也是最经常要去面对的问题。首先必须了解基站大体上的设备有哪一些。M900/M1800 BTS、综合布线架、电力转换设备（作用是变压、交直流转换、设备配电等）、DDF架、ODF架、SDH设备（即光端机）、蓄电池、PIX盒（作用是机房环境检测告警）、空调、交流配电箱、机房环境控制系统、三相相序自动调整器。PDF光端机，并有逆变器支持PDF的断电-蓄电供电工作。这算是机房的基本设备配置。而这些设备也是平时经常出现故障的，其中在我实习期间最常涉及到的就是M900/M1800 BTS里的TRU,DXU，PSU等硬件引起的故障。以下举例说明我在代维中，解决这些故障的过程。

思考及解决方案关于CF2A57告警产生的原因及暂行消除方法近期BSC对部分网元基站的DXU软件版本进行了升级，而升级后的软件版本中添加了新的性能监测项，其中一项就是将TRU的RX A与RX B的接收电平进行对比。当两路接收电平的差值大于某个数值时，就会触发CF2A57告警。下面将介绍消除的方法过程：
首先，要使用34.9版本以上的OMT 软件，这样才能正确识别出升级后的DXU软件版本。连接OMT，读取IDB，然后如下图：

选择上方菜单的Maintenance项，出现下拉菜单后选择Monitor。

找到RF Loop Test Parameter项，打开并选择需要检测的TRU。

由于CF2A57一般会附带RX 2A6或2A5告警，而这两个告警会在具体的某个TRU上出现，例如：TRXC-0 RX2A6 CF2A57,那我们就选择TRXC-0进行检测。

添加到右边的框内，然后按Start monitor,会出现下图的检测画面：

（检测结果可能要等几分钟才出来的）
从检测结果可以得到RX A、B两路的接收电平，正常情况下应该是相等的。如果不相等，而且两者之间的差值大于6 dB（这是默认的告警门限值），就会触发CF2A57告警。

暂行的消除告警方法就是调高告警的门限值，操作如下：

进入Antenna System ANT 0的菜单选项，选择Antenna Supervision。

可以看到默认的门限值是6，而且是24小时之内出现大于门限值7000次就会出告警。这就是为什么CF2A57靠复位来消除之后要过好一段时间才会再出。

一般来说把门限值调到12就应该可以消除，如果不行的话就说明硬件上真的存在很大的性能隐患，需要彻底的检查相关的硬件，并更换才能消除，如TRU、CXU、CDU及之间的连线等。


PSU的排障方法在基站出现同PSU相关的告警后，到基站上观察PSU的状态，可能有如下两种情况：第一种是PSU亮红灯或不亮灯，第二种是PSU面板状态正常但可能存在故障。
针对第一种情况，首先检查PSU的-48V直流（PSU -48）或230交流（PSU 230）输入是否正常，可能存在输入开关跳脱或熔丝熔断的情况，如果排除上述情况，那么很可能是亮红灯或不亮灯的PSU存在故障，进行更换确认。对更换后的新PSU，应该先加-48V直流或230交流输入（下面的接头），再连接直流输出接头（上面的接头），否则容易导致新加的PSU因为直流电流倒灌的原因而再次损坏。
针对第二种情况，使用逐个排除的方法来找出存在故障但面板显示正常的PSU。满配置的PSU数量一共是4个，与ECU通过光纤串联在一起，形成一个环路。首先甩开左边第1个PSU，将剩下的3个PSU同ECU通过光纤串形连接，再观察基站的PSU相关告警是否消除，如果消除，则说明左边第1个PSU存在故障，进行更换；如果故障仍未消除，可将左边第2个PSU单独甩开，将剩下的3个PSU同ECU通过光纤串形连接，需注意的是从左边第1个PSU直接连接到第3个PSU的光纤需要换成长一点的光纤，再观察基站的PSU相关告警是否消除，以此类推，逐个排查PSU。除了上述方法，类似的，还可采用每个PSU单独同ECU串形连接，再观察基站告警是否消除的方法，逐一进行排查。还有一点需要说明的是，基站对PSU的识别并不是完全根据PSU的安装位置，例如最左边的PSU被识别为PSU-0，向右依次为PSU-1、PSU-2、PSU-3，实际上并不是这样的。基站识别PSU是通过光纤环路来识别的，不在这个环上的PSU将不被识别，同时针对这个不在环上的PSU基站也不会产生告警。光纤环路连接最左边的PSU被识别为PSU-0，然后依据光纤环路上的连接，向右依次识别为PSU-1、PSU-2等，例如PSU-0，它的实际安装位置可能是从最左边数第3个PSU。
有一个故障现象是某个PSU的架顶-48V输入接口因短路损坏严重，不能再使用，并且基站存在相应告警。消除告警的办法是在PSU与ECU的光纤环路中，甩开这个损坏严重的架顶-48V输入接口对应的PSU，再从IDB数据中删除多余的PSU（损坏的接口对应的）即可消除告警。

站点问题总结

目前我国所使用的基站都有集成化、专业化的特点，例如爱立信RBS200和RBS2000系列基站广泛应用于我国的GSM900MHz及GSM1800MHz通信系统。引起基站故障的原因很多，但是综合来分析引起基站故障的原因主要表现在以下几个方面：基站软件问题引起的故障；传输问题引起的故障；基站硬件引起的故障；各种干扰引起的故障；人为引起的基站故障等。

一、基站软件问题引起的故障

当RBS200基站发生故障时，应通知BSC的操作人员并要求解闭TRI基框的V.24端口，使用MML命令对BTS进行操作或使用本地维护终端LMT（维护人员一般没有软件，因为RBS200维护较简单，人工即可处理）。当RBS2000基站出现故障时，使用OMT观察告警信息、复位、拔插硬件板、检查软件设置及硬件故障等。首先收集告警信息，打印故障记录表和告警输出；其次进行故障定位，由故障表解码并查出具体故障或用RXEFP打印出故障码，1AXX，2AXX；再次，BSC与基站配合进行故障处理。BSC完成对TRI的闭塞/解闭等操作。

二、 硬件设备引起的基站故障
1．载频故障
对于RBS2000基站，如果某一套载频突然不能正常工作（HOLD不起来），硬件有红灯亮，DXU有Fault告警，不要到机房马上换TRU，因为告警有20%是虚告警，应该对TRU进行复位（按Reset按钮），通知机房对TRU进行解闭（HOLD）；解闭后如果还不能恢复正常，对DXU进行复位或通知机房对整个小区复位，重起整个小区的载频；如果仍不能恢复，通知机房关闭该载频（设为载频1）相邻的正常载频（设为载频2），更换两个载频，通知机房对两个载频进行重起，如果载频1工作正常，载频2工作不正常，确定载频1是好的，可能是CDU或连线出现故障，用OMT软件进行监控并读取代码查故障代码表，确定故障；如果载频2工作正常，载频1工作不正常，确定是载频1坏，更换新的载频。
2．话音处理模块故障

在话音信号传输和处理流程中，在下行方向，由BSC到BTS是2Mbit/s×N的光纤，到光端机分成2Mbit/s的PCM传输线，到DF加载监控信息后到基架顶输入口。话音信息来自TRI中的RTT，经过线接口总线LIB到达TRXC中。话音信息在BSC中的TRAU单元已经经过话音编码，且话音信息被放在LIB总线的TS1和TS2两个时隙中，所以在TRXC中，信息透明地交换到8个不同的SPP单元的内部LIB总线上，每个SPP在内部LIB总线上提取TS1、TS2时隙中自已的1/4时隙的话音信息，该时隙的比特率是16kbit/s，它分为13kbit/s的编码话音和3kbit/s的同步信息。每个SPP对话音信息进行信道编码、交织、加密和为空中接口形成Burst格式，并把已处理的信息放到内部TX总线上，信息在该总线上被送到TRXC中，TRXC把内部TX总线转换成TX总线，通过TX总线将信息传送到无线发射机RTX，在RTX中信号被调制成发射频率且信号被放大，最后通过发射天线发射出去。在话音信号处理上行方向上，接收天线接收到的信号送至无线接收机RRX，在RRX中信号被抽样和解调以进行进一步的数字处理，数字信息（两路分集接收设备RXDA和RXD）在RX总线上从每个分集接收机送往SPP，SPP完成Viterbi均衡、解密、反交织和韦特比解码。解码后的信号与BSC中TRAU的同步信息一起插入内部的LIB总线上指定的1/4时隙中，同时监控信息插入到PCM31时隙，然后送到TRXC，经LIB再送到TRI，最后送到BSC中。
又例如RBS200站（配置形式为3/3/3）出现故障，状态为A小区第三载波无法占用TCH信道（无法正常工作），小区其它两个载频工作正常。经分析导致故障产生的原因可能有两个方面，频率干扰和设备硬件故障。经中心机房更换频点及现场拨打测试，排除了干扰原因，所以该故障很可能是某个话音处理模块损坏造成的。因为A小区无法建立呼叫，该小区其它两个载频工作正常，就排除了公共硬件部分或O&M总线、TIB、TX总线损坏的可能性；又因RTX工作正常且下行链路工作正常，与相邻的一套载频更换RRX后，第三载频工作正常，由此判断RRX损坏，维护人员对该模块进行了更换，经过拨打测试后该套载频恢复正常，故障得以解决。
三、人为引起的基站故障

如某基站为RBS2000站，原配置形式为4/2/2，实际使用时为3/2/2，现扩为3/3/2。在交换侧维护人员发现对DXU灌入数据后，工作正常，但系统对新增加的载频却无法通信。维护人员向机房询问情况后，发现DXU有告警信息，用OMT测试，得到两个结果：CU到新扩TRU的连线有问题；L/R通信链路丢失。维护人员检查发现TRU的RXA、RXB连线都有松动，经处理后告警消失，但该TRU仍无法工作，再用OMT测试，告警L/R通信链路丢失，查询爱立信故障代码信息资料得知，该告警只是一个信息。因其它TRU工作正常，检查IDB数据无误，说明故障不是软件部分问题造成的，问题出在硬件部分。维护人员更换邻近的正常载频后，故障依旧。本站系统的构成采用了一个主架加一个扩展架，一个扇区采用两个交叉连接的CDU实现分集接收，两个机架6个CDU配置满为12个载频（4/4/4），新增的B扇区TRU应接到主架的第三CDU或扩展架的第四CDU上。维护人员对TRU到CU的连接进行检查，发现其接到了第二个CDU上，也就是接到A小区上，所以当对其解闭时由于接法上的错误导致BSC对该TRU无法正常操作，经过维护人员处理，故障消除，但此时DXU又出现Fault告警，该告警是因TRU更换位置后产生的，维护人员读IDB数据，对TRU重新配置安装后告警消除（或复位DXU ）