【资料名称】：BSC6000传输设备故障导致传输呼建成功率下降问题阶段性分析报告

【资料作者】：匿名

【资料日期】：2010年9月

【资料语言】：中文

【资料格式】：DOC

【资料目录和简介】：

问题描述:
7月16日上午，客户收到用户投诉，并且发现一些小区的呼建成功率下降。怀疑问题是由于当天凌晨0:20产生的传输故障导致。然而在传输问题消失以后，有一些小区仍然存在呼建成功率低的问题。在CNRC值班工程师的建议下，晚上22:00时客户关掉了ITS功能从而触发所有基站的重启，随后问题消失。

分析进展:
1.问题在现场的现象:
最初怀疑呼建成功率的下降是由时隙不可用导致。在监控窗口观察到一些不可用的时隙。在研究不可用时隙的规律并分析了数据库配置以后，发现这些不可用的时隙是打开ITS（FR 25262）功能以后的正常现象。以下面的截图26号站为例进行说明：


(1)
数据库的配置如下图所示：



(2)

上边的TRX是carrier A,下边的TRX是carrier B。 在carrier A的时隙为PDTCH的时候，在B边对应的时隙会被置成不可用，这是符合设计的现象。

从图1可以看到carrier 3的6和7时隙是OOS的状态。carrier 3是carrier B, 对应的carrier A是TRX0. 可以看到TRX0上的6和7时隙都是PDTCH, 所以carrier3上的6和7时隙OOS是正常的. carrier 6 timeslot 6 and 7也是同样情况, 对应的carrier 1上的6和7时隙是PDTCH. TRX 9的6和7时隙对应在carrier 2的6和7时隙 is PDTCH, 同样的carrier 11的4时隙, 对应的carrier A，TRX10’的4时隙也是PDTCH. 所以所有的OOS时隙都是在打开ITS功能以后正常的时隙OOS.

ITS引起的OOS只会对DCR有影响，不会对呼建成功率造成影响。 BSC 不会发送assignment command 消息给这样OOS了的时隙, 所以也不会收到assignment. I.E., 所以这个问题是不会跟ITS相关的。我们认为ITS伴随的所有小区的重启是解决了问题的原因。


2. 从alarm日志可以看到， 0框24槽和18槽，1框的18槽中的GOIUB板爆出了告警：20240 Tributary Unit Alarm Indication Signal (TUAIS)。报告警时间00:20:29，清告警时间00:21:15. 这导致了基站到这些板子上传输的中断。相关基站可以看到LAPD OML Fault。7/16/2010 0:20出现， 7/16/2010 0:21消失。

所有基站的恢复时间是 00:21.
然而, 368条 RSL disconnected告警中, 只有 69条 alarms自动清除； 42 条被配置清除，是从10:30 到12:00由客户重启基站的操作导致。23， 6， 8号站等。257条 RSL 在19:00点钟收集这次告警的时候仍然是disconnect的状态。. (附件是19:00收集的告警日志)

3. 虽然从截图的检测窗口看到时隙状态时正常的。（图 (1) 所示14:57）.

然而从BTS的调测窗口可以看到有一些RSL不在工作状态。并且从统计可以看到, 因为RSLs不工作导致了56和 57号站的呼叫建立成功率下降。
26号站 小区55 的ARSL状态:
B-U means busy unblocked.
ARSL 0 0 0 B-UNO REASON16/0700:20:51 None
ARSL 0 3 0 B-UNO REASON07/0703:59:50 None
ARSL 0 4 0 B-UNO REASON16/0700:20:52 None
ARSL 0 5 0 B-UNO REASON16/0700:20:52 None



26号站小区56的 ARSL状态:
B-U是正常工作状态，E-U是配置了的但是没有在工作。.
ARSL 1 1 0 B-UNO REASON16/0700:20:51 None
ARSL 1 6 0 B-UNO REASON07/0704:00:00 None
ARSL 1 7 0 B-UNO REASON16/0700:20:51 None
ARSL 1 8 0 E-UNO REASON16/0700:20:50 None


26号站小区 57的 ARSL 状态:
ARSL 2 2 0 B-UNO REASON07/0703:58:07 None
ARSL 2 9 0 B-UNO REASON07/0703:59:56 None
ARSL 2 10 0E-UNO REASON16/0700:20:50 None
ARSL 2 11 0E-UNO REASON16/0700:20:51 None


从上述发现我们认为问题的发生是因为:
在RSL是E-U但是时隙是INS的状态的时候,因为SDCCH是正常状态, 所以assignment命令会占用 DRI’s RSL是E-U的时隙. 但是因为实际上时隙不可用，所以TCH assignment会失败, 导致CSSR降低.

我们在华为开了ticket，在等他们对下面问题进行答复:
-BSC是知道那些RSL仍然在disconnect状态的情况下. BSC会不会OOS相关RSL上的所有时隙. 如果会的话为什么在检测窗口没有看到这样的现象? 如果不会的话，是不是BSC仍然会在这些时隙上分assignment?
-从log里是否可以看到为什么有一些RSL不能自动回复。

4. 从BTS测我们由已有的数据得不到更多的信息。问题已经消失，并且没有提供出根本原因的信息。并且在发生问题的时候很多跟CSSR相关的BIN值没有打开。因为触发点是不容易得到的，所以也没有有效的DCP可以提供。

所以目前可以得到的结论是在某特定情况下，RSL从BSC看是E-U的。如果RSL是好的，则不应该出现现在的问题。目前希望从华为可以得到更多解释。

建议:

1.重启基站可以解决问题
客户在白天的时候已经重启了部分基站，从日志来看这些基站问题已经恢复，CSSR也已经变好。晚上关闭ITS触发了所有气站的重启，然后所有基站的问题都得到恢复。所以ITS本身的开和关跟这个事情无关，伴随的基站的重启是恢复问题的原因。
2.在LMT上观测RSL告警和检测RSL工作状态。
RSL可以显示哪些信令链路出现了故障，如果RSL出现问题，那么信令的传输可能会中断，相关时隙也会OOS，进而会导致拥塞。
下边查看RSL状态的方法：


选择所有基站并点Query键查看所有基站的RSL状态。

3.打开ITS功能。
ITS功能与EDGE能力有关，如果关掉这个功能，EDGE能力就会丢失，客户同样会有投诉，因为下载速率会慢。像我们提到的，这次的问题跟ITS没有关系，所以建议重新打开ITS功能。 如果客户对此有质疑，可以建议先打开一些基站进行观察，观察到没有问题之后打开所以基站的ITS。

[ 本帖最后由 fwj129 于 2011-11-9 10:18 编辑 ]