【資料名稱】：GSM優(yōu)化值班手冊

【資料作者】：jun

【資料日期】：2012/10/26

【資料語言】：中文

【資料格式】：DOC

【資料目錄和簡介】：

GSM優(yōu)化值班手冊
概述
針對網(wǎng)絡出現(xiàn)的各種問題，提供相關的建議解決方法。
嚴重問題
關注如下問題： TCH擁塞，SD擁塞，SD高掉話，高掉話，每線話務量高
請點擊相應的超連接，轉到本文檔的詳細說明部分進行處理。
TCH擁塞&每線高話務
擁塞原因：是否由于閉塞信道引起
緩解擁塞方法：
降低擁塞小區(qū)發(fā)射功率，同時提升共站及其它鄰小區(qū)的發(fā)射功率：修改指令ZEUG:BTS=*MAX(PMAX2)=*;
打開DR：查看指令ZEQO:BTS=**:CEL;修改指令ZEQF:BTS=**,DR=Y;
降低本小區(qū)切出門限PMRG、PRI(ZEAM:BTS=*AC=***,CI=***:MRG=*, PRI=*,;)
提高鄰小區(qū)切入門限PMRG、PRI(指令同上)
對于1800M小區(qū)，可降低或關閉C2：查看指令ZEQO:BTS=**:MIS;修改指令 ZEQM:BTS=*:I=*,REO=*;
關于7746擁塞告警：目前可實現(xiàn)部分BSC 30分鐘的監(jiān)測周期。
NOKIA 7746告警（5分鐘周期）以TCH擁塞率或SD擁塞率大于3%為門限，連續(xù)出現(xiàn)4次告警以上的，或在6次/小時以上的，即啟動流程
如需要臨時打開半速率提升容量，參見半速率調整傻瓜版
需要確定BSC是否有半速率的Feature

注意1:均衡后必須用ZEEI實時觀察用戶數(shù)是否下降，直到不擁塞為止。
注意2:如是重點通信保障地區(qū)，調整切換參數(shù)時，可根據(jù)《重點地區(qū)主控小區(qū)列表》挑選鄰區(qū)。
注意3:“PMAX2”
部分BSC安裝了支持EDGE功能的BSC軟件包，其1800M發(fā)射功率的參數(shù)發(fā)生變化，為PMAX1X00, 見下面的紅字部分，而舊版本是沒有這個參數(shù)的。在新版本的軟件包中，GSM900和DCS1800的發(fā)射功率分別由BS TX PWR MAX和BS TX PWR MAX1X00控制，對應參數(shù)為GSM900--PMAX,DCS1800--PMAX2。
示例：新版本POC數(shù)據(jù)修改指令：ZEUG:BTS=**:PMAX2=*;
POWER CTRL ENABLED .........YPOWER CONTROL INTERVAL ..... 01s
BS TX PWR MIN ....PEAK PWR - 30 dBBS TX PWR MAX ....PEAK PWR - 08dB
BS TX PWR OFFSET ........... 00 dB BS TX PWR MAX1X00 PEAK PWR - 08dB
POWER INCR STEP SIZE .......4 dBPOWER RED STEP SIZE ........2dB
……

SD擁塞
將TCH時隙改為SDCCH時隙，以增加SD的信道個數(shù)。在16K TRX信令速率下，每個TRX只能配1個SDCCH時隙(查看配置ZERO:BTS=**;閉站、閉載頻、修改指令ZERM:BTS=**,TRX=*:CH*=SDCCH;).如果誤配置為2個SDCCH時隙，可能會導致載頻不斷重起。在32K TRX信令速率下，每個TRX可以配2個SDCCH時隙(ZDSB:::PCM=*;查看是否為32K信令速率)
降低擁塞小區(qū)發(fā)射功率，同時提升共站及其它鄰小區(qū)的發(fā)射功率：修改指令ZEUG:BTS=*:PMAX(PMAX2)=*;
對于1800M小區(qū)，可降低或關閉C2：查看指令ZEQO:BTS=**:MIS;修改指令 ZEQM:BTS=*::PI=*,REO=*;
對于處于位置區(qū)交界的小區(qū)，提高自己及鄰區(qū)中屬于不同LAC的小區(qū)的HYS(HYS范圍0~14)，以減少位置更新次數(shù)，從而緩解SDCCH信道的擁塞：查看指令 ZEQO:BTS=**:RAD 修改指令ZEQG:BTS=**:HYS=*;
SD高掉話
評估中心提供的統(tǒng)計中SDCCH掉話高的定義是高于500次的SDCCH掉話，可以按照如下步驟進行處理：
原因分析：是否硬件故障導致某載頻SDCCH掉話高。
可進行重起載頻、倒換BCCH所在載頻、重起基站等操作：ZDTC:T****:AD; ZDTC:T****:WO;
如果仍未恢復，可稍降基站功率，將SDCCH掉話次數(shù)降低，避免影響網(wǎng)絡性能。
高掉話
評估中心提供的統(tǒng)計中高掉話的定義是高于100次。
高于100次的掉話主要是由于強干擾或嚴重的硬件故障，查看是否有大量7744、7745等告警，可暫時降功率緩解，但調整功率的幅度要兼顧客戶感知。
網(wǎng)絡監(jiān)控
RACH DELETE
關注BCSU_OVERLOAD_DELETED_RACH之Sum ，如果某個基站的該項數(shù)值大于600則應進行關注。
原因分析：當BTS話務量很高的情況下，BSC會啟動保護機制，對過多的RACH申請進行刪除，造成用戶短時間內無法通話。現(xiàn)象是BTS級統(tǒng)計在1小時內出現(xiàn)大量的RACH DELETE。
查看告警，是否有傳輸閃斷或其它的硬件故障
查看小區(qū)的參數(shù)設置并記錄，為下面的改動提供基礎(ZEQO:BTS=**:ALL;)
疏導BTS話務，防止擁塞(擁塞處理)
調整BTS參數(shù)RET(最大重傳次數(shù),RACH的控制參數(shù))，目前設置為4，可以調整為2 (ZEQM:BTS=**:RET=2;)
調整BTS參數(shù)SLO(發(fā)送分布時隙數(shù),接入算法)，目前設置為10，可以調整為12 (ZEQM:BTS=**:SLO=10;)
調整T3122，延長MS前次SDCCH申請被拒絕后接入保護時間，目前為6秒，最大可設置為10秒(ZEGT:T3122:1,10:;)
如果基站并沒有出現(xiàn)占用人數(shù)多，擁塞等告警，則可能是硬件掛起，重啟基站觀察。




PAGING DELETE
首先要區(qū)別是LAC下個別CELL出現(xiàn)尋呼刪除，還是LAC下所有（絕大多數(shù)）小區(qū)同時出現(xiàn)尋呼刪除，對于個別CELL的情況，主要分析是否小區(qū)的SDCCH業(yè)務量或者GPRS請求次數(shù)過大造成，其原因是AGCH的優(yōu)先級高于PCH，因此某些情況下會由于系統(tǒng)占用PCH信道發(fā)送AGCH導致尋呼刪除，此時主要方法是疏導話務，減少AGCH的業(yè)務量。還有就是軟硬件故障導致，此時需要對基站進行RESET，將故障消除。

對于LAC下絕大多數(shù)CELL同時出現(xiàn)尋呼刪除的情況，其引發(fā)原因主要是高業(yè)務量（尋呼量>10萬），或者短時間內大業(yè)務量造成（如：尋呼量<6萬，同時BMCC短信群發(fā)等）。對于前者可以讓運行維護中心集中監(jiān)控中心操作處理，對于后者由于大業(yè)務量是短時的，可以暫不做處理，但需要繼續(xù)觀察。

對于同一LAC下大量CELL的尋呼消息溢出數(shù)量大于尋呼消息總量的3%時，需要及時通知綜合部，由綜合部協(xié)調運維中心進行緊急處理，可以臨時關閉相關LAC的RE-PAGING參數(shù)，減少PAGING量。當尋呼消息溢出數(shù)量較少時，可暫時不做處理，但要及時的提取統(tǒng)計，觀察變化情況。對于尋呼消息溢出的情況，第二天要及時通知本部門和規(guī)劃部門，作出調整方案。

尋呼過載處理
當前一小時尋呼數(shù)大于14萬/小時或者尋呼溢出1000次/小時（小區(qū).平均）應按照以下步驟采取措施：
第一步：關閉MSC側的REPAGING參數(shù)（AT），運行維護中心集中監(jiān)控中心操作；
第二步：若調整后觀測還大于16萬/小時，關IMSI尋呼
關閉MT SMS repaging.(RTPMTS=NOT USED)
關閉MT CALL repaging.(RTPMTC=NOT USED)
運行維護中心集中監(jiān)控中心操作；
尋呼策略參考：
STRATEGYTMSI USAGETMSI PAGE REPETITION1ST PAGE & AT TIMES
REPAGE2ND PAGE &
AT TIMES REPAGE
1YESYESWITH TMSIWITH IMSI
2YESNOWITH TMSINO
3NOYESWITH IMSINO
4NoNoWITH IMSINO
第三步：繼續(xù)觀測,若出現(xiàn)尋呼量大于20萬：
網(wǎng)優(yōu)規(guī)劃中心準備割接方案，東區(qū)優(yōu)化中心實施無線覆蓋收縮方案，減少MSC周遍BTS的覆蓋范圍，降低MSC用戶數(shù)。
T3101超時
關注《T3101_LAC大于10表》中最后一項T3101%，該表顯示的是超過T3101超時超過10%的LAC，處理時要根據(jù)《T3101大于15表》中，屬于該LAC的T3101超時的Cell進行分析，T3101監(jiān)測立即分配過程。
原因分析：導致T3101超時的原因很多，在通信保障中要注意的是由于大業(yè)務量（下行主要是尋呼、上行主要是測量報告）造成的LAC級或BSC級的高T3101超時情況。日常網(wǎng)絡級T3101超時的比例在5%左右，當LAC級T3101超時比例超過15%（除去個別故障小區(qū)影響）時，可能有大量業(yè)務發(fā)生，需要疏導，防止情況進一步惡化。
T3101超時一般有兩種情況：
軟硬件故障：個別基站T3101超時情況嚴重，其他基站統(tǒng)計情況正常，對網(wǎng)路安全沒有嚴重影響。一般由于基站的軟、硬件故障導致，只需要多對發(fā)生問題的基站進行處理，根據(jù)實際情況對基站進行重起等操作，使其盡快恢復正常。
LAC尋呼量過大：LAC下所有基站T3101超時情況都比較嚴重，屬于普遍現(xiàn)象時，網(wǎng)絡有出現(xiàn)安全隱患的可能，需要及時處理。這種情況一般由于LAC尋呼量過大造成，需要及時的控制尋呼，具體手段可以參考尋呼溢出進行處理。
針對上行導致的情況，可提高BMA參數(shù)(BTS平均測量周期，取值范圍1~4，現(xiàn)網(wǎng)設置是1，1表示BTS對一個SACCH復幀周期的測量結果進行平均)，并進行話務疏導，降低上行的負荷(查看指令ZEQO:BTS=*:MIS;修改指令ZEQG:BTS=**:BMA=;)

為進行全面分析，需要的相關數(shù)據(jù)收集工作： 一般情況不需值班人員操作
核查前一時段LAC的尋呼量，并收集的LAPD負荷信息，檢查是下行導致還是上行導致。
統(tǒng)計每一條LAPD信令的流量：操作指令ZDMF; ZDSB:::PCM=**;
BCSU OVERLOAD
關注《AVERAGELOAD生成表》，統(tǒng)計項包括所有CPU負荷超過50％的BCSU列表，關鍵統(tǒng)計項名稱為AVERAGE LOAD。

話務原因造成BSC CPU LOAD高
BSC BCSU單元OVERLOAD可以通過2720、1014告警和BSC單元的負載統(tǒng)計發(fā)現(xiàn)，當BCSU單元的平均負荷超過定義的門限值時會發(fā)出2720告警和1014告警，統(tǒng)計中BCSU單元平均負荷超過NOKIA定義嚴重告警門限（60%）。
降低主要由過載BCSU控制的BTS的話務
均衡過載BCSU控制的TRX至其它低負載的BCSU
查看問題BCSU所帶的載頻：ZEEI:BTS=**;
查看還有空余TRX的BCSU：ZEEI::BCSU;
刪除載頻：ZERD:
建載頻，倒換BCSU：ZERC:
升高相關BCSU下BTS的BMA參數(shù)(BTS測量的平均周期)，降低BCSU負荷（BMA取值為1~4，現(xiàn)網(wǎng)設置為1，1表示BTS對一個SACCH復幀周期的測量結果進行平均)：
當60%<BCSU負荷<70%，建議BMA設為2；(ZEQM:BTS=**:BMA=2;)
當70%<BCSU負荷<80%，建議BMA設為3；(ZEQM:BTS=**:BMA=3;)
當80%<BCSU負荷<90%，建議BMA設為4；(ZEQM:BTS=**:BMA=4;)
下一時段根據(jù)統(tǒng)計情況，繼續(xù)修改BMA參數(shù)取值。
通過調整BSC所在LAC的PAGING參數(shù)和BSC下BTS的RET，SLO，BMA參數(shù)降低BCSU負荷。

非話務原因造成BSC CPU LOAD高
由于S10.5升級的軟件BUG造成BCSU某個進程產(chǎn)生的LOAD非常高，尤其對處理能力相對較弱的SUBRACK BSC影響嚴重，可能造成20%左右的負荷增加。
查看當前BCSU的LOAD
操作指令ZDOI：BCSU；
使用ZTVI指令恢復出問題的進程，此指令執(zhí)行時間較長
操作指令 ZTVI：48；

檢測辦法：通過SERVICE TERMINAL取TOP 20 進程，如果發(fā)現(xiàn)01B3 0000進程負荷較高，則可以確定。
ZDOI:BCSU;（實時觀測BCSU負荷）
ZDDS: BCSU, X;（“X”為BCSU號，進入SERVICE TERMINAL）
ZLE：X，TOPTENGX（X為菜單代碼，設一個未出現(xiàn)的即可）
XX-MAN: ZXR（“X”為上一條指令中的菜單代碼，可觀測到各進程的負荷情況。
注意：在話務負荷非常高的情況下，不要使用此指令，因為指令也會造成BCSU負荷增加，因此在話務負荷非常高的情況下使用可能發(fā)生危險�。。】梢蕴�過此項工作直接進行處理。
BSC_TR掉話大于15表
出現(xiàn)在該表中的BSC是在上一個統(tǒng)計時段TR掉話大于15個的。這個時候應該進入相關的BSC，使用如下命令查看ZAHP::NR=2993:; 來查看是哪些站出現(xiàn)這種問題。告警格式如下所示：
<HIST> BSC132MCMU-1TRANSM 2005-04-2614:08:50.97
**ALARM........RRM_BX
(0416) 2993 BTS AND TC UNSYNCHRONIZATION CLEAR CALLS ON ABIS INTERFACE
90d 10d 06 135d 20d 4d
其中紅色的90代表BTS號碼，黃色的10代表載頻號碼，紫色的6代表時隙。找到出問題的站后可以進行相關的操作：
考慮重啟該載頻
考慮關閉該載頻
考慮關閉該時隙
BSC Alarm 2133
現(xiàn)象：LAPD下行過負荷，BSC出現(xiàn)2133告警
建議：其原因一般是由于LAC下尋呼量過大造成，需要及時疏導話務，查找、解決造成尋呼量異常的原因，處理方法同尋呼過載。及時通過ZDMF指令收取相關LAPD的負載情況。
零起呼小區(qū)
關注《TCH試呼為0表_占用_》中的小區(qū)。

查看是否有無起呼的7738告警，或失敗率很高（高于60%）的7745告警。
對比頭一天同一時段以及當天10點的統(tǒng)計，看是否正常情況。
操作指令 ZEOH::BCF=**,NR=7738,NR=7745; ZEOL::NR=7738,NR=7745；
查看是否有7703(BCSU RESTARTED)BCSU重起的告警。因為BCSU的重起帶來的不是一個站的沒有起呼告警，可能會引起該BCSU下所帶的BCCH載頻均無法起呼。
處理方法
將基站重啟，或將BCCH載頻與其他載頻倒換，看是否7738告警會CANCEL，并觀察下一時段統(tǒng)計是否恢復正常。