210组呼业务失败的分析与处理

发布时间:  2014-06-16 浏览次数:  535 下载次数:  5
问题描述
XX铁路进行最后的动态验收,在A车站测试210组呼失败概率和组呼建立时间。6月13日早上7点30分,发起VGCS组呼,发现在A小区下有呼叫建立失败异常事件。6月14日上午10点37分,在A小区再次测试VGCS组呼业务,依然有呼叫失败事件。
告警信息
处理过程
控制邻区电平在当前小区的覆盖,修改 “小区重选偏移”即CRO(Cell Reselect Offset),合理设置该参数,可以减少切换次数,利于指配MS到当前更好的小区。同时,测试组呼期间,禁止其他用户发起组呼。通过采取上述措施,210组呼顺利通过验收。
根因
分析6月12日的CS单用户跟踪的信令,发现是核心网下发的终端消息是这个业务类型不支持,导致呼叫建立失败。如图1所示。

                                               图1. 呼叫建立失败的消息类型解析
进一步查看6月13日的终端在该小区的组呼上报的测量报告,可以看出在当前A小区下发起VGCS组呼业务一直是成功的,后来小区重选至B小区才呼叫建立失败。而B小区作为车站邻区,核心网并未配置组呼业务的相关数据,因此才下发了“service-option-not-support”终端消息。如图2所示。

                                                                                        图2. 终端组呼成功后上报的测量报告解析
再次分析6月14日CS单用户跟踪的信令,发现是10点28分核心网下了busy,然后拆线导致终端的呼叫建立失败。也就是说,连续两天呼叫建立失败的原因是不同的。如图3所示。

                                                         图3. 终端消息类型为busy
进一步分析核心网信令,通过查询话单,发现10点28分有尾号为5813的其他号码发起过VGCS组呼,时长达42秒,也就是说发起组呼的号码并非是只有9212的测试号码,而是还有车站其他终端。VGCS允许用户建立到属于某一指定服务区和组识别号(Group ID)的一组用户的呼叫,呼叫期间所有的调度员都可以发言,但是所有的业务用户抢占一个上行通道。其他业务用户只有当上行空闲时才可以继续抢上行的操作。如图4所示。

                                                                                                                    图4.核心网信令解析的话单查询结果
综上分析,此次A车站验收210组呼时,发起呼叫建立失败原因值有两个:(1)VGCS组呼在A小区挂机后再次呼叫,此时小区重选已经至B小区,而B小区并非车站,没有配置组呼数据,导致呼叫建立失败。(2)终端在A小区测试组呼挂机后,恰好有其他终端发起了长时间的组呼,由于上行信道一直被抢占,所以也导致了呼叫建立失败。
建议与总结
210组呼作为验收项目之一,指标要求很严格。在动态验收过程中,要提醒车站其他工作人员做好配合工作。同时,我们自己也要和核心网厂家多配合沟通,方便双方将问题定位。

END