华为CCCH资源不足引起数据业务不畅问题分析解决方法

邓金荣

【摘要】 本文从一个全业务客户感知监测平台发现的问题入手，介绍了从核心网到无线侧分析排查和解决的方法，并探讨了华为设备普遍存在的TBF建立成功率偏低的优化思路，提出了在现有资源不足的情况下，如何提升华为数据业务性能，同对对合理利用新设备的特点进行针对性的优化，提升设备利用率提出了较好的建议。

【关键词】 全业务客户感知监测平台 TBF建立成功率 CCCH过载

一、问题描述

在全业务客户感知监测平台中，发现某地市的燎原基站晚上20点到凌晨1点的时间段内数据业务（彩信、WAP首页访问、PDP激活）成功率偏低，且22点到23点情况特别严重，WAP首页访问成功率仅为67.24%，PDP激活成功率67.92%。

二、问题分析

1、行为分析。对拨测号码彩信的ilog数据进行分析，发现虽然彩信发送失败，但该号码仍然可以收到PUSH短信，而在核心网对发送方进行抓包可以得到如下信息：（1）网关的响应非常慢。用TCP连接网关3次才能连上，正常的连接时候应该在1秒以内，这里耗时用了12秒。说明数据网络可能存在问题（拥塞或者丢包）或者彩信服务器这个时刻的压力运作不正常。但由于其它测试点正常，可以排除第二个原因。（2）正常情况下，发送方收到网络的确认信息才算是发送成功（MMS m-send-conf），但是这里发送方并没有收到网络的确认消息，被叫方却收到了PUSH短信，说明在彩信服务器已收到发生请求并回送确认，但是发送方并未收到确认信息导致多次重发。

2、号码定位。根据提供的测试卡号码，在Msofx3000上查找到该拨测号码锁定在燎原基站第三小区。在M2000上看燎原3的相关性能指标，发现该小区TBF建立成功率偏低，且失败次数全部都集中在“手机无响应导致下行GPRS TBF建立失败次数”上。平均每时段失败次数达到4158次。分析S62燎原3一天内的指标变化情况，发现MS无响应次数随着业务流量上升而增大，在晚忙时22：00时最大，达到6703次以上，是闲时的100倍以上。手机无响应导致下行TBF建立失败主要包括了在CCCH上发起的下行TBF建立失败和在PACCH上发起的下行TBF建立失败两种情况。而通过相关测量结果显示，燎原3小区PACCH上的下行支配成功率正常，都保持在90%以上。而CCCH上的下行指配成功率偏低，每小时CCCH下行指配成功率仅为52.07%。因此，怀疑存在CCCH信道拥塞的可能，进一步分析流控测量相关的话统指标“呼叫相关测量（CALL）→流控测量<小区>→Abis接口分组CCCH负载指示消息上报次数”，发现“Abis接口分组CCCH负载指示消息上报次数”非常多，在话务忙时为92次，数据业务忙时达到126次。根据寻呼原理可以知道，BTS把下行CCCH（PCH信道）上的来自BSC的寻呼消息分别存放在接收缓冲队列中，当接收缓冲队列的长度超过一定门限时就认为下行CCCH过载。因此可以初步判定该小区存在CCCH拥塞。

三、解决思路

针对CCCH拥塞问题，可进行以下优化调整：（1）提高“CCCH负荷门限”值。“CCCH负荷门限”对Abis接口分组CCCH负载指示消息上报次数比较少的小区有效果。此参数设置过小，Abis接口上的信令流量增加，加大系统的负担；设置过大，BSC不能对BTS发生的异常情况做及时处理。目前默认设置该值为80%，我们尝试将该值修改到100%，观察后发现没有明显改善效果。（2）扩容CCCH信道。扩容CCCH信道，即为S62燎原3增加1个BCH信道。因为默认情况下，一个小区只配置一个主BCCH，这样有“1个非组合的CCCH”，那么CCCH在一个BCCH复帧中的消息块数就为9。如果再增加配置1个BCH信道，就有“2个非组合的CCCH”，那么CCCH在一个BCCH复帧中的消息块数就为18，很大程度上提高了CCCH的容量。为S62燎原3增加1个BCH信道后，“Abis接口分组CCCH负载指示消息上报次数”明显减少，同时“MS无响应导致下行GPRS TBF建立失败次数”也明显减少，问题基本解决。优化后，手机无响应导致下行GPRS TBF建立失败次数在数据业务忙时，从优化前最高峰的6703次，下降到209次。而TBF建立成功率也由优化前的69%提升到98%。

四、经验总结

华为内置PCU相较外置PCU，容量更大性能更好，但由于刚刚引入，大部分参数仍按照设备入网时的默认设置，仍有较大的提升空间，因此需要进行针对性的研究和优化，挖掘设备优势，提高网络性能，从而改善用户的数据业务使用感受。

参 考 文 献

[1] 《GSM移动通信网络优化》

[2] 华为BSC6000技术文档