河南移動(dòng)GSM網(wǎng)絡(luò)LAC現(xiàn)狀分析及解決方案

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