诺基亚设备7745告警

叶浩恩

你首先要明白7745告警的含义，7745告警在BSC参数上可以定义，目前SD定义为80%，TCH定义为20％，也就是说，SD信道时隙占用失败率为80％以上会触发告警，TCH的时隙占用失败率为20％以上会触发告警，对于半速率和全速率，还可根据附加码确定到某一个半速率时隙。如果一个载频的掉话虽然较高，但时隙均匀的掉话，是不会产生高掉话的。单时隙的掉话也只能说明这个载频的这个时隙的掉话率偏高，7745告警也只能给你定位问题的参考思路，更多情况下不是由于载频故障，而是由于其它原因导致的掉话。如果每个载频掉话均匀，你要考虑是整个扇区的问题，楼上说的先关BB观察是比较常用的方法。

给你个解决思路，先把本小区的跳频关了，然后再利用统计p_nbsc_underlay表中的相关counter，主要统计052003－052007这几个counter，看是哪个载频在掉话。另外，这个表中还有关于各个载频在空闲时隙的干扰情况的counter，也可以结合统计出来分析。
还有，P_NBSC_RX_STATISTICS 表中有各个载频0－7级的上、下行质量，可以对各个载频的质量进行统计分析，一般来说，这些counter结合起来基本就能分析出问题原因来了，另外还有7745告警等，可以结合起来看具体是哪个时隙。一般情况下，对于深入排查故障来说，跳频关掉比较好处理，在开跳频的情况下，分析起来比较困难
7745 CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD
信道失败率高于定义极限
告警含意
一个信道的通话连接故障率高于运行者定义的极限值。告警用于通信和信令信道的监控功能和发现可能的故障信道。
附加信息栏
1    指示告警出自TCH还是SDCCH信道
     01：业务信道
02：独立专业控制信道
2    指示在0时隙信道故障率是否高于定义值
     00：低于极限（无告警）
01：高于极限（由告警）
3    指示在1时隙信道故障率是否高于定义值
     00：低于极限（无告警）
     01：高于极限（由告警）
4    指示在2时隙信道故障率是否高于定义值
     00：低于极限（无告警）
     01：高于极限（由告警）
5   指示在3时隙信道故障率是否高于定义值
     00：低于极限（无告警）
     01：高于极限（由告警）
6    指示在4时隙信道故障率是否高于定义值
     00：低于极限（无告警）
     01：高于极限（由告警）
7    指示在5时隙信道故障率是否高于定义值
     00：低于极限（无告警）
     01：高于极限（由告警）
8    指示在6时隙信道故障率是否高于定义值
     00：低于极限（无告警）
     01：高于极限（由告警）
9    指示在7时隙信道故障率是否高于定义值移动通信,
     00：低于极限（无告警）
     01：高于极限（由告警）
10   高失败率的时隙
11   子信道定义TCH：
     00：TCH/H-子信道0
     01：TCH/H-子信道1
     02：TCH/F-子信道

子信道定义SDCCH：   
     00-07：SDCCH-子信道0-7
12   在测量时间内，TCH或SDCCH子信道因为故障而释放的数目在所有信道释放的数目的比例。

在信道发布信息中找出告警的原因。使用MML命令ERS来恢复信道，首先锁定，然后解锁。
    ZERS:<BTS>,<TRX>,<CH> ;    锁定
    ZERS:<BTS>,<TRX>,<CH>:U;    解锁
检查影响告警的参数设置是否合理。MML命令EEO显示无线网络监督参数值，EEN命令修改参数值。
Parameters, with their default values, affecting the alarm:
参数有它的默认值，它们影响告警：
     ZEEN: CSR：信道占用请求极限值（10）
           CNGS：SDCCH拥塞（失败）极限值（20％）
           CNGT：TCH 拥塞（失败）极限值（20％）
           PRDCNG：拥塞（失败）监测时长（120分）
老手建议
1．查看7745的附加信息栏内，如果第一项是02（代表有故障的是SDCCH信道），重启TRX，如果一小时后告警还会出现，执行第2步。

如果第一项是01 （代表有故障的是TCH信道），执行第2步。      
2．查看BSC中是否有关于这个TRX的2993告警。

如果有2993告警，将故障的TRX的TCH和TRX-SIG与其他的TRX互换，
如果告警出在新的TRX，转交运维或传输处理。

如果告警还出现在原TRX上，依照以下方法处理：
<1> 将TRUA更换
<2> 将故障载频的D-BUS线和时钟线互换。
<3> 将故障载频的背板与其他背板互换（更换时要注意更改TRX硬件跳线）

如果没有2993告警，执行第3步。
3．远端环测TRX
如果结果很差，更换新的TRX。
如果结果没有问题，查看统计数据：
<1>  干扰值，如果干扰强烈，那么不必去现场，转交网优处理。如果没有干扰继续下面的操作。
<2>  DL_Q0和UP_Q0的数据, 如果使用同一个合路器的TRX性能都较差，估计是合路器故障，现场使用MMI软件测试驻波比。如有故障，修复后载频会恢复。
如果不是同一个合路器的TRX性能差，估计是TRX故障，现场使用MMI软件环测。如有故障，更换新的TRX。

告警取消
如果告警不需要处理，你可以使用MML命令EOR取消告警。
在维护者的锁定解锁命令连接到BTS后或维护者在当前测量时间内解决了问题系统会自动取消告警

这个问题很古老了，NOKIA 的TRX经常会有。

以前在做NOKIA的工程时，我已经把这个问题提高到很高的层面的上去讨论了，得出的结论你可以参考一下：
1.先确定7745是TCH还是SDCCH的，如是是SDCCH的话，你就不用管设备了，叫网优去解决（我是做基站的，不管网优故障），网优的解决方法：换频点或关跳频等，结果我不太清楚

2.如果是TCH话，如果只是个别时隙有问题，或者每次出现的时隙都不同，你也可以不用管，叫机房把这个相关的参数（掉话率吧）设大一点。这种方法叫“自我欺骗法”

3.如果是很多时隙或固定时隙有问题，说明这个TRX有问题，换掉就能解决（这种情况一般站开起来十来分钟就会出现了）。

4.最雷人的解决方法：有问题就直接换掉TRX，再出现再换（这种服务就苦了做基站的）

结论：TRX实际是没有问题的，数据也是没有问题的，传输也是没有问题的，问题是NOKIA的TRX其本身就是有缺陷的，第1种方案就不说了。第2种方案因各地区的参数设置不同，但对于NOKIA设备，要把某些参数放宽，不能太严，因为NOKIA设备本身就达不到那么高的要求，第3种方案就没什么好说的，TRX坏了，第4种，我最常用的方法，因为这种方法不会让客户对你产生反感（如果你是做代维的或乙方的话），这种方法你换的TRX其实也没坏，可以用到其它站，它也许不会再出7745，更雷人的方法是把两个站的7745TRX对换，两个就都不出了……我对此很无语……结论是NOKIA TRX的兼容性和适应能力都是有待提高的。

有关TRX 7745的时隙定位和TCH、SDCCH的判别，上面有人提供了链接，可以去参考一下，我就不说了。