C&C08接通率解决案例二则

lijf2

第一章  湖南某局
1.1  拥塞问题的处理
1.1.1  故障现象
某局进行网络调整割入12个远端模块后，每日晚忙时话务量增大时，长途来话产生大量的SEC 消息，应答试呼比不到10%。

查看话务统计结果，发现一个无法说明的现象：
“承载对象话务统计--局向入局话务统计”（中继侧统计）的结果中在晚忙时长途来话有大量的本局拥塞，且有大量的呼叫转接次数；而“呼叫记录话务统计--组合对象条件话务统计”（在CCB 侧统计）的结果很正常。

初步判断是长途入局呼叫未到达呼叫处理部分CCB 侧 ，而在中继侧直接给长途局回送了SEC消息。咨询中研信令部同仁中继侧什么情况下会发生该现象，答复为：一般不会自己回，由CCB 侧的消息来决定回送何种局间消息，除非是共用内存空间不足，但一般情况下不会发生。

1.1.2  故障原因
经多方诊断发现问题出在交换机的“公共参数表上，“App参数表”的“公共参数表”中的13条记录的前后次序有误：

缺省记录顺序（主机默认次序）                                   该局记录顺序
     最大模块数                          63   最大模块数                           100
     普通消息包数目                 1600                 普通消息包数目                          1600
     超长消息包数目                 400                  CCB数目                                 1000
     CCB数目                                 1000                 CPU拥塞起始                          95
     CR数目                                 2000                 CPU过载起始                          90
     CPU拥塞起始                       95                           排队队列数目                            10
     CPU拥塞结束                       80                           AM光接口板类型0                      0
     CPU过载起始                       90                           AM光接口板类型1                      0
     CPU过载结束                         70                           超长消息包数目                          400
     排队队列数目                    10                           CR数目                                  2000
     排队队列单元数目            60                           CPU拥塞结束                          80
     AM光接口板类型0             0                            CPU过载结束                          70
     AM光接口板类型1             0                            排队队列单元数目                     60

由于该表为无关键域的有序表，主机只按默认顺序读取第2列的数值，因该局所有模块的CCB 数目错为95，CR 数目错为90 ，造成呼叫处理资源的严重不足，忙时产生拥塞；由于该局其他局向的话务量小得多，而长途晚忙时话务量增加5-6倍，CCB 资源严重不足，中继侧直接回送SEC 拥塞消息。
1.1.3  问题的解决
用 SQL 语句重新制作该表（BAM 库中的 tbl_PubParam表）的所有记录，格式转换所有数据，加载所有模块。
1.2  用户早释的处理
1.2.1  故障现象
该局晚忙时的拥塞处理完毕后，用户振铃早释比例却高达60%，应答率只有33%，局方对我方的说明（由用户原因产生）极其不满，要求大家进一步处理。
故障表象：早释由失败处理产生，由于该局作了大量的失败处理：对被叫欠费、呼入受限、终点故障、被叫停机作了无应答信号的送音处理，产生了大量的振铃早释。
1.2.2  故障原因及相应的处理
1、字冠问题造成了大量的振铃前早释
该局一个奇怪的现象就是除长途外的其他局向有大量的振铃前早释，跟踪信令终于发现问题：部分字冠在我局、各县EWSD局、市话汇接局间循环发送，额外增加了许多试呼次数，直到主叫听不到任何反应后挂机为止。

问题主要出在双方的大字冠上，我局主要有7个有问题的大字冠（本局都是千位局号，位于7#和4#上）：在 738#、746#、742#、790#、453#、454#、455# 七个字冠存在问题。

2、欠费用户无法呼入
共有五百多欠费用户，由于长途局送来的用户呼叫属性不对（应为0A，错为11），无法通过呼入权区分来话局向；但如果本局不做失败处理时会回送对局 SST 消息，对局一般对SST 都是给主叫送忙音，不利于接通率的提高。

3、删除大量的停机用户
该局有两万多实装用户，却放开所有四万个端口，其中有4800个端口为停机状态，除了真正的“用户终点故障”外，“用户停机”也对LOS 呼损有较大贡献，使得该局的LOS 呼损高达5-10% 。由于“ST设备表”修改后无法联机设定，只得逐条删除这四千个用户。

4、删除新开点处于故障态的用户
由于扩容一直进行中，有近1500左右用户数据已作，但相应RSA点却暂未开通，用户都处于故障态，呼入时回送LOS 消息，对局听忙音；与用户停机一样，容易造成恶性重拨。
5、删除所有呼入、呼出无权的用户
用户状态为“正常”（与欠费相对应）的用户，如果呼入无权，回送ACB消息，对局主叫用户一般也听忙音；无呼入、呼出权，该用户就没有存在的意义，删除后直接回送UNN消息。

经过上述处理后，该局的用户早释比例虽然仍然不低（主要是放开所有端口的原因），应答率已基本正常，在50-60%之间，早忙时低于晚忙时。
第二章  河南某局
2.1  故障现象及处理
2.1.1  久不应答比例异常：
由交换机拆线（久不应答）的长途呼叫比例高达5-15%显然不正常，只有一种可能性--交换机的超时拆线释放定时器被人为修改了（经查此定时器已从缺省值 90秒改为了30秒）。重新改回95秒（稍长于国标值，让长途局先拆线，避免我方先拆线后回 CFL 消息）。

在被叫不应答而拆线问题上的说法较为混乱，“久叫不应”和“振铃早释”在网管统计中的说法和C&C08 机话务统计中的说法有些差异：网管统计中“久叫不应”和“振铃早释”都包含在“久叫不应”中，强调的是被叫不应答； 而C&C08 机话务统计中“久叫不应”和“振铃早释”有不同含义----交换机拆线的叫“久叫不应”，交换机拆线前主叫挂机拆线的称为“振铃早释”，回铃音前主叫挂机拆线称为“用户早释”。

在C&C08 机中是无法通过失败处理对“久叫不应”、“振铃早释”、“用户早释”、“拨号中途放弃”、“拨号位间超时”等失败呼叫进行处理的，此时话路和信令通路都已拆除；好在除了“振铃早释”外，其它原因拆线的呼叫比例较低。
2.1.2   交换设备内部拥塞 SEC ：
通过跟踪长途局向的七号信令，发现问题主要出在50#模块；其第二个PCM 系统为故障态，对应的母局2#模块的PCM 却是正常空闲状态，且呼叫会占上该系统，用指定中继呼叫终于发现问题所在----中继电路数据已配置，PCM 系统被自环，被母局模块误认为空闲可用。

为避免同样问题的出现，将所有模块间未用PCM 系统的数据全部删除，扩容时可以用命令很方便地恢复或增加。
2.1.3   用户终点故障比例异常
本局呼叫终点故障的用户有语音提示，而局间回LOS 消息；对于LOS 消息对端局一般给主叫送忙音，造成主叫的恶性重拨。
       
删除全部位于扩容未通处于故障板位的用户。

删除所有呼入、呼出无权的用户：用户状态为“正常”（与欠费相对应）的用户，如果呼入无权，回送ACB消息，对局主叫用户一般也听忙音；无呼入、呼出权，该用户也就没有存在的意义，删除后直接回送UNN 空号消息。

产生“终点故障”的主要有二：外线问题，未挂好话机。
2.1.4   空错号比例异常：
各局字冠都比较粗，只到万位局号字冠，而本局使用的是千位局号，大量的空局号未被拦截。

发现21#字冠不细，重新细分了21#字冠为2107、2108、2109、211、212、213、216、217、218、219，避免210#字冠的循环。
       
细化本局字冠，从3位细分到4位，尽早对空号字冠进行拦截，并可减小主机的处理工作量。

发现长途局偶有03772xx 送到本局，为避免字冠的循环，将长途来话做落地处理。