華為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負荷門限”值?！癈CCH負荷門限”對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技術文檔