河南移動GSM網絡LAC現狀分析及解決方案一個LA可能涵蓋數十個甚至數百個小區，所以發至BSC的尋呼信息數量可能會很驚人。 一、簡介良好的尋呼性能對于所有手機用戶是否能夠成功作被叫來說十分重要。這份文檔主要分析了我省LA位置區的尋呼性能尋呼成功率及承載能力，并針對問題LAC提出了規劃調整方案。尋呼性能分析主要評估了我省現網69個LA位置區的尋呼成功率及尋呼負荷，同時給出一些BTS尋呼容量及負荷的計算。此外，針對我省LAC現狀提出適當調整方案及今后的規劃建議。 。二、背景目前全省市場資費調整，全網話務量急劇增加，網絡容量滯后于實際話務量的增長，網絡容量問題突出暴露。由于LA話務量增長迅速，且部分地區LA劃分不均衡，使得這些LA下的BTS尋呼負荷及BSC負荷過高，導致手機無法被成功尋呼。我省鄭州、商丘、開封等地曾出現過由于BTS尋呼負荷過高，當大量短信群呼時，對網絡造成巨大沖擊，大量用戶打不成電話，給我們的網絡帶來了較大損失。因此，LAC的規劃問題目前已突出暴露出來，將LAC的優化及規劃提上緊急日程已毋庸置疑!LA代表一個位置區域，主要有以下兩項功能：1、在此區域內，網絡發起對某個手機的呼叫，此區域內所有的基站都會進行尋呼，因此假如一個LA涵蓋的基站數過多，用戶數過多，大量的尋呼將導致BTS尋呼負荷過載。2、手機進入一個新的LA服務范圍內，必須發起請求，更新HLR及VLR內的位置記錄，因此網絡的LA數過多，會造成手機頻繁的位置更新，浪費相應的信令資源。三、BTS尋呼容量的相關參數設置1、 尋呼原理分析當一個手機被尋呼時，MSC就會通過BSC向對應LAC范圍內的所有基站發出尋呼請求。一個LA可能涵蓋數十個甚至數百個小區，所以發至BSC的尋呼信息數量可能會很驚人。由于BTS必須通過有限的PCH信道向手機發送尋呼請求，因此，過大的LA可能導致BTS的尋呼負荷過載，結果造成信令擁塞及尋呼信息丟失。根據GSM的規范，CombinedBCCH/SDCCH小區，每個復幀傳送3個尋呼組，而Non-CombinedBCCH/SDCCH 小區, 每個復幀傳送9個尋呼組。尋呼組可作為尋呼信道 (PCH) 用來廣播尋呼請求，同時也可作為接入授權信道 (AGCH) 用來回應手機的接入請求(即分配SDCCH)。操作上，可將數個復幀組合在一起，形成一個尋呼周期，增加小區內的尋呼組數量。手機會周期性地監聽所屬的尋呼組，于是當手機作被叫時，會監測到基站發送的尋呼請求，并做出回應。尋呼組設置較多意味著手機在監測到正確的尋呼組之前需要等較長時間，這樣會增加尋呼的時間。尋呼組設置較少會由于手機較為頻繁地接聽尋呼組而縮短呼叫建立時長，缺點是手機會很費電。2、 尋呼組設置我們可以設置每個小區的尋呼組的數目，兩個參數決定了一個小區尋呼組的數量。這兩個參數是：NumberOfBlocksForAccessGran、BS_AG_BLKS_RES(0.7) 、 noOfMultiframesBetweenPaging, BS_PA_MFRMS (2 . 9)。以下NumberOfBlocksForAccessGrant簡寫為AG，noOfMultiframesBetweenPaging簡寫為MFR。 Combined BCCH/SDCCH 小區 AG =0 . 2 ，而 Non-Combined BCCH/SDCCH 小區 AG = 0 . 7 ，若使用CBCH，則AG= 1 . 7。這個參數定義了每個復幀內AGCH專用的尋呼組數量。它可以設成AG= 0 (即沒有專用的AGCH，所有的尋呼組由PCH和AGCH共享。)或 AG= 1 ( 即保留尋呼組作為AGCH專用信道)。用于AGCH的尋呼組數量取決于小區話務量。由于我省并未啟用 CBCH 功能，并且在Nokia GSM BSS9中，若沒有保留AGCH的情況下，AGCH的優先級高于PCH，因此盡管有需求，也可以將AG設為0。 MFR (2.9): 這個參數定義了BTS的尋呼周期,即同一尋呼組傳送尋呼請求的時間間隔。例如：MFR=9的意思是每一尋呼組，以每9個復幀的周期重復一次。也就是說屬于某一特定尋呼組的手機，必須每9個復幀監聽一次，也就是說監聽間隔時間大約是 2.1秒 (9 * 235.4 ms)。AG，MFR以及尋呼組的數量三者之間的關系如下：以我省個別地市為例計算小區尋呼組的數量1)CombinedBCCH/SDCCH小區：AG=2MFR=5尋呼組數量=(3- AG) * MFR = 5 個尋呼組2)Non-combinedBCCH/SDCCH小區：AG=2MFR=5尋呼組數量=(9- AG) * MFR = 35個尋呼組四、BTS 尋呼容量的計算考慮到SDCCH擁塞，一些小區配置為combinedBCCH/SDCCH，但將BCCH/SDCCH改為combined 后會減少每復幀周期的尋呼組的數量。如上計算，若使用non-combined，尋呼組的數量為35，而用combined 時只有5個尋呼組。以下主要針對combined配置進行深入分析。BTS通過尋呼組廣播尋呼請求。下面是一個尋呼請求可能的配置： 2 IMSIs 1 IMSI and 2 TMSIs 4 TMSIs對于現網中部分分公司設置的CombinedBCCH：每個復幀有3個尋呼組 (235 ms), 若AG = 2，每秒尋呼組的數量為：(2個AGCH-1個PCH)=1個PCH/0.235(每復幀)=4.25個尋呼組/ 秒 1每復幀尋呼組可以傳送4個TMSIpages或2個 IMSI pages 。假設25 % 用于IMSI，且沒有全網尋呼，每復幀尋呼組的尋呼數為：1TMSI尋呼占一個尋呼組的? ，1 IMSI 尋呼占? 。4個尋呼(100%)= 75%(TMSI) + 25%(IMSI)= 3 * ? + 1 * ?= 5/4 (所需尋呼組)所以，估計每尋呼組的尋呼數為：4/(5/4)=3.2 2 /即每尋呼組可尋呼3.2個手機/因此，對于CombinedBCCH/SDCCH小區，若AG=2,則每秒的尋呼數為： 4.25(尋呼組/秒)* 3.2(尋呼數/尋呼組)= 13.6 (尋呼數/秒) 3 上面計算了實際現網中AG=2時尋呼的容量，建議將AG由2設為0，這樣可以直接增加尋呼的容量，改善尋呼成功率。以下將計算AG的實際需求及將AG由2設為0之后尋呼容量的增長。例如：LAC=14384(洛陽10月28日忙時SDCCH分配次數最多的小區63131，SDCCH_ASSIGN = 5924)CI63131=5924SDCCHAssign (AGCH attempts)= 5924/3600= 1.64AGCH / s 4= 1.64*0.235= 0.38 /即每復幀用于 AGCH 的尋呼組為0.38個/ 這個計算結果說明AGCH的需求不足一個尋呼組，所以不需設置專用的AGCH，即可將AG設為0。如果將AG由2設為0，則尋呼組的數量將會增加：每秒尋呼組的數量：(0尋呼組用于AGCH，即3 尋呼組用于PCH)= 3個PCH/ 0.235(每復幀)=12.76 5考慮最差情況下，除去AGCH后，每秒實際剩下用于PCH的尋呼組數量=12.76-1.64=11.12 6因此，CombinedBCCH/SDCCH小區每秒尋呼數為：(若AG= 0) 11.12(尋呼組/秒) * 3.2 (尋呼數/尋呼組)= 35.58 7因此，7式(AG= 0)與 3 式相比(AG =2)可知，BTS 的尋呼容量可增加162%。五、BTS尋呼負荷的計算這部分更深層次分析了我省現網配置為CombinedBCCH/SDCCH和Non-combinedBCCH/SDCCH 的基站，以及這些基站尋呼負荷現狀。如下表 5.1所示。個別LAC內的BTS尋呼負荷已經超過100%。計算結果來自10月20日至10月28日222報告的尋呼試呼數。下面舉例說明BTS尋呼負荷的算法：例如：LAC=14357(10月20日至10月28日最忙時的尋呼試呼次數為)每秒尋呼試呼數=/3600=33.6 8對于CombinedBCCH/SDCCHBTS每秒尋呼數 3 = 13.6 (AG=2)，所以，對于CombinedBCCH/SDCCH若AG=1 ，每秒尋呼數=3 *2=27.2LAC14357的尋呼負荷為：=Sum(LAC內每秒尋呼數 /每秒系統允許尋呼 數) =(33.6/27.2)=1.235=123.5% 9注：尋呼負荷是指LAC范圍內每個BTS的尋呼負荷，而在此計算的尋呼負荷考慮的是LAC下最差BTS的情況，因此計算出的尋呼負荷僅為最差情況的估計。六、網絡LAC現狀及問題分析據表5.1分析可知，目前全省共有69個LA(截止10月20日止)，存在問題必須重新規劃的LA26個，這些LA的呼叫成功率均低于70%(70%為最低門限)。其中8個LA下BTS的尋呼負荷已超過90%，涉及新鄉、開封、商丘、許昌、南陽、平頂山分公司，情況較為嚴重。大部分LA下都帶了較多數量的BTS，這是造成這些LA尋呼負荷高的根本原因。個別LA下的BSC容量甚至幾乎滿配置，如新鄉BSC5(BSC容量為512，目前已高達502)。BSC及BTS信令負荷過高直接導致了所在LA尋呼成功率極低。此外，信令信道的配置方式也較大程度的制約了LAC本身尋呼的容量。對于同等條件下的兩個不同的LAC，采用Combined配置方式比采用Non-Combined配置方式的成功率低很多。如鄭州的14097的成功率為82.6%,而平頂山的14612的成功率僅為67.6%，關鍵原因就在于鄭州全網的信令信道的配置均為Non-Combined。目前我省尋呼負荷已基本接近容量極限，一旦負荷過載，當BTS尋呼緩沖區滿了之后，尋呼信息就會被刪除。這些可以明顯地從NetworkDoctor 186 報告中觀察到。尋呼緩沖區的計數器負責監測。BTS每30秒向BSC發送包含尋呼緩沖區的CCH_Load_Ind信息，然后BSC 將當前類似于Paging_Buffer_Size 的尋呼負荷送至統計單元，最小值由計數器3018來記錄。如果尋呼緩沖區 (計數器3018)的最小值 等于0，就會出現尋呼擁塞。然而，NetworkDoctor報告的數據是取每小時的平均值，因此，即時計數器3018的平均值不為0。從10月20日至10月28日的186報告分析可以看出，CombinedBTS的尋呼緩沖區較小。甚至有些BTS的尋呼緩沖區只有“1” 且被刪除的尋呼信息數量較高。這就是說在這個例子中當AG設為2時， BTS 已經達到容量的極限值。下面是10月24日忙時186 報告。 表5.2：例OMC110月24日BTS尋呼話務量現網風險分析：個別BSC的容量過高，會在不同程度上限制BSC的處理能力，進而影響到BSC的服務。嚴重時BSC會重啟，這樣整個BSC下所有的用戶全部不能正常使用。個別LAC尋呼負荷過載，重發次數瞬間成倍增加，導致A、Abis接口信令負荷過高，手機尋呼信息直接被刪除，造成接通率降低。從指標方面看，LAC規劃不合理直接影響全網SDCCH掉話率偏高，用戶感知是手機較難撥通。在LAC尋呼負荷過載的情況下，大量短信的沖擊足以造成BSC下的大面積用戶打不成電話。也就是說，尋呼負荷低的LAC承受短信沖擊的能力遠比負荷高的LAC強得多。七、LAC規劃調整方案八、總結及規劃建議目前我省現網尋呼性能整體水平較低。問題的根本原因是combinedBCCH/SDCCH基站產生的尋呼擁塞，且忙時部分LAC下的BTS尋呼負荷已接近滿載。這份LAC現狀及規劃報告提供了CombineBCCH/SDCCH基站的尋呼容量的計算方法，186報告也極好地證明了很多基站在緩沖區存在排隊的問題，或者說當隊列已滿時，情況更加嚴重，尋呼信息直接被刪除，以至于根本尋呼不到被叫手機。為盡快改變目前全網尋呼性能較差的現狀，改善尋呼成功率，在此提出以下規劃建議：由于AG的優先級較高，因此可通過計算得知AGCH的需求量，將combined基站的AG的值由2設為0。計算SDCCH 的話務量，對于低話務量的小區，將combined BCCH/SDCCH 的基站改為non-combined配置，這樣可以增加 至少190%的尋呼容量，同時制定擴容計劃。將MSC 的參數， Nu