|
CCS_CALL_FAILURE in TGRP Description
Number of calls released after switching network through connection due to “call failure”. Trigger points
This counter is incremented upon receipt of RCF#31 (RF_NORMAL_UNSPECIFIED) for that particular trunk. As we know, CCS CALL FAILURE just appears on A interface. CC:O of A interface is for MTC and HO incoming, so RCF#31 should be in GSM4.08 CC cause. When MTC/HO release forward, RCF#31 caused by · forward release cause 31 · the BSSAP-LTG internal Failure cause31 · else undefined release cause When MTC release backward, RCF#31 caused by · 00000011 Message Type ASFAI (Assignment failure) Cause 00000100 IE Name Cause 0001010 Cause value radio interface fail-reversion to old ch 0------- Cause extension No Extension RR Cause 00010101 IE Name RR cause 01101111 RR Cause value Protocol error unspecified found DISC cause=9F(somewhere) · 00000011 Message Type ASFAI (Assignment failure) Cause 00000100 IE Name Cause 0001010 Cause value radio interface fail-reversion to old ch 0------- Cause extension No Extension RR Cause 00010101 IE Name RR cause 00000100 RR Cause value Abnormal release, no activity on radio path/ also 00 Norm Event found RELEASE cause=9F · after ALERT appears RELEASE 9F · BSC MSC Its sbsequent Inter MSC HO Back to MSCA HODET Release Complete Cause=9F |
 让我来解释一下：TGRP上的CCS_Call_Failure计数是在内部收到RCF#31被触发。当初(写这文是还是SR6)这个Counter只在A口对CC:O有计数。A口的CC:O统计针对的是MTC和HO incoming，所以RCF#31应该是GSM04.08的CC cause。 MTC/HO前向释放时，A口RCF#31只可能源于 前局释放过来的cause31； BSSAP-LTG内部错误产生的Cause31； 其它未定义的释放原因(以Cause31替代发送) 当MTC后向释放时，RCF#31可能的情况有： 1)某项目发现，BSC先回TCH分配失败指示有RR协议错误未定义，之后有DISC(Cause9F)(A口Cause9F触发内部RCF#31,触发计数) 2)BSC先回TCH分配失败，RR原因Abnormal release no activity on radio path/就算是00(normal event)，之后A口信令也发生RELEASE(Cause9F)(说明内部有RCF#31了啊) 3)A口信令发现MTC，有ALERT后的RELEASE(9F)，这种情况是TGRP CCS_Call_Failure计数原因 4)手机先切出局，又后续切回(不一定原处) 老BSC释放RR连接，以DISC(9F)发到MSC，MSC将把外部A口来的9F转换为内部RCF(31),从而触发Counter！ －－－－－－－－－－－－－－－－－－－ 我写这个的时候MSC还是SR6.0,现在都SR11了！我敢说很多还是他们不知道的。SR6的时候有内部文档(又长又臭)，明说A口来的9F内部转成RCF#31,又有另一文档明说RCF#31是CCS Call Failre的触发原因之一。所以要搞清那个counter就找找A口MTC/HO在什么情况有Cause 9F啊？！ 那些家伙说搞不懂Counter，其实根本不懂counter！！他们有仔细研究文档，将狗屁文档贯通起来并实际查找吗？没有！！ 所以他们封我做Counter之王，自以为信令很神圣，和我争优化话务统计重要还是信令重要。我都很无奈！领导也惶惑，其实都是烂货！ 我玩交换机入网测试；每天跟踪信令的时候，他们连TUP的IAI/IAM、CLF/CFL还分不清区别。我倒！ 所以你看到2000年外国大侠跑去成都写了25页报告，我只拜读5页，终于明白发出局间发出IAI等于TGRP CC:O计数。晕倒！交换机卖了几千个来证明这个最基本的Counter，这叫优化吗？？ 所以你看到2001年时尚少女去测SGSN Counter，结果将近一半的基本Counter不准！你相信德国人设计的东西就烂到这种程度，欧洲还用的很多吗？？测成这样，懂不懂通信或电子线路基本原理啊？？设备还怎么卖啊？？ 所以外行来充当通信界IT经理人(白领，我靠！)活生生就是把公司往死里整！ 现在SR11了，A口的CCS_Call_Failure又有几人能说清？？ |
