有信号不能正常呼叫问题分析.docVIP

有信号不能正常拨打问题分析

有信号但是不能正常拨打极其容易造成用户投诉，在临汾工程中，我们针对所遇到的有信号不能正常呼叫的现象进行了归类和分析，总结为以下几种情况：

七号信令模块吊死

10月16日早上8-9时，大量用户反映信号较好但是进行呼叫困难，通过分析话务报揭发现linfen22下所有小区的话务报告均不正常，表现为SDCCH占用时长均较长，大概在13-17秒左右；SDCCH试呼次数突增，SDCCH话务量较正常情况高5-6倍如下列图所示，TCH占用时长正常：

话务报告SDCCH占用情况

小区载频占用情况

SDCCH的占用异常不是局限于某个小区或者某块载频，而是整个BSC22下所有的小区的SDCCH异常但TCH占用正常。确定故障原因应该在负责信令传输和处理的七号信令模块上。由于SDCCH信令只在N7信令中继的第16时隙上传送，018报告无法统计该时隙的占用情况，因此也就不能确定具体故障中继或模块。在争得局方同意的前提下，我们重起了BSC侧所有的N7信令同时建议局方重起交换侧N7信令模块后，linfen22恢复正常。

TCUC吊死

一块TCUC可以MAP四个全速率载频或者两个半速率载频，相应地处理MAP在它上面载频的BCCH信令和SDCCH信令。临汾乡宁下宽井1、3小区为村通基站，在开启后长时间只有SDCCH占用；没有TCH占用，TCH分配失败率为100%，并且均为MC140A-MC140B-MC812由于系统原因造成的TCH准备失败。这两个小区均只有一块载频，并且他们的RSL对应同一块TCUC。用户投诉该小区覆盖区域有信号，但是不能正常呼叫。如下列图：

载频占用情况：

TCH分配失败：

重起这两个小区RSL对应的TCUC后，小区占用正常。

3、逻辑数据对应错误

正常情况下载频和RSL是一一对应的，但是在临汾的优化过程中，我们发现有个别小区会出现RSL和TRE对应关系错误，示意图如下：

正确的对应数据错误的对应数据

从OMCRUSD报告实时占用来看，该小区只能看到两块载频的对应情况，临汾在10月份后进行了大量的割接和扩容，不标准的割接和扩容操作流程，可能会导致上述现象，同时这些小区有用户投诉呼叫困难，在重新删创该小区的RSL后，小区恢复正常。

4、8版跨BSC割接小区后应该重起割接小区的BCCH对应TCUC

临汾市区于10月20日重新划分了LAC，并且调整了个别小区的BSC归属。10月21日有用户投诉信号较好，但是呼叫困难。投诉地点均为跨BSC割接小区的覆盖范围，通过分析这些小区的话务报告，我们发现这些小区的TCH分配失败率极高大约在80%以上，并且分配失败均为MC140A-MC140B-MC812由于系统原因造成的TCH准备失败。重起TCUC后小区指标恢复正常。后我们查阅了相关资料在《B8升版及维护考前须知》明确注明该考前须知如下列图：

交换侧和无线侧小区数据不对应

新开基站或割接基站后，及时关注这些基站的话务报告，如果发现该小区无占用，并且有用户投诉有信号但是无法正常呼叫，在确认无线侧没有问题后，应该检查交换数据。在临汾割接过程中，优化小组专门对交换和无线侧小区LAC设置不一样的小区进行了现场测试，测试结果显示做主叫时提示“网络不可及”做被叫提示“暂时无法接通”。如果交换机没有创小区的数据，从USD报告里可以看SDCCH的可用数和占用数会有明显异常。

中继占用不正常

如果中继占用不正常也会导致用户投诉呼叫困难，这类问题可以从018报告中分析C181E(NB_N7_ASS_FAIL_ReqTerResUnav/Alloc)，从话务报告来看，主要表达在TCH分配失败较高。从原始018报告中可以分析每条中继的占用情况，如果个别中继的占用次数〔C751〕和占用时长〔C750〕均为0，但是从交换和OMCR这些中继均为UNLOCK的并且状态正常，就会造成上述情况。同时这类问题也可以通过跟踪A接口信令，过滤CAUSE为RESOURCEUNAVILABLE的ASSIGNMENTFAILURE消息来确定此次分配失败占用的中继号和时隙来确认。

小区参数设置不当

在呼叫流程中BTS在收到MS上行发出的CHANNELREQUEST消息后，会根据测量的TA值决定是否向BSC发送CHANNELREQUIRED消息。这个过程中涉及到一个小区参数即RACH_TA_FILTER参数，如果测量的TA小于该参数那么进行下一步流程，反之那么忽略MS发出的CHANNELREQUEST消息。RACH_TA_FILTER参数设置过小或小区严重越区覆盖，就会造成有信号但是无法正常呼叫。这类问题相对容易解决，可以通过增大RACH_TA_F