網(wǎng)絡優(yōu)化工作交接文檔

工作文檔交接------DESSIE網(wǎng)優(yōu)部分KPI提取BSC級KPI（BSC14&BSC15&BSC41）BSC級KPI是對全網(wǎng)整體的一個觀察，主要觀察一些主要KPI值，CS（SDCCHcongestion,TCHcongestion,TCHcalldroprate,Handoverinsuccessfulrate,Handoveroutsuccessfulrate,CSSR）PS(PDTCHestablishsuccessfulrate,TBFuplinkcongestionrate,TBFdownlinkcongestionrate,TBFuplinkdroprate,TBFdownlinkdroprate)2)CELL級KPI（BSC14&BSC15&BSC41）CELL級KPI是針對壞小區(qū)來進行篩選和分析的，從BSC級KPI中找出了不理想的KPI值，在CELL級里面針對這些KPI來篩選壞小區(qū)，進行分析。KPI優(yōu)化SDCCHcongestionrate分析SDCCH真擁塞（基站提供的SDCCH容量與實際用戶占用的容量相符合）添加SDCCH信道調整空閑模式下的CRO,PT值（CRO值不建議調過大，一般設置為5~6）調整T3122值（默認值為10，一般調整為30，要保持3個小區(qū)一致）調整T3212（此參數(shù)必須與MSC設置一致，不然會造成用戶不在服務區(qū)或者提示關機）調整Rxlevaccessmin，一般情況調整為12~15，默認值為10。調整最大重傳次數(shù)Mretrans（默認值為2），擁塞的情況下可以調整為0.打開指派排隊功能。SDCCH假擁塞（基站提供的SDCCH容量與實際用戶占用的容量不符合）這種情況一般是基站存在故障，造成了SDCCH可用率低，一般是由于基站告警，傳輸故障，市電原因造成的。TCHcongestionrate分析TCH真擁塞（基站提供的TCH容量與實際用戶占用的容量相符合）開啟小區(qū)的半速率（BSC級半速率已經(jīng)打開），調整Hrths(默認值為60)此值調整越小，用戶感知度會較低，根據(jù)小區(qū)擁塞情況來定。空閑模式下調整CRO,PT值，呼叫過程中調整PBGT來緩解擁塞，調整過程不提倡兩極化。（默認值為30，代表的含義：如A小區(qū)-B小區(qū)行走的過程中，B小區(qū)比A小區(qū)高6個dB情況下，會發(fā)起PBGT切換，已24作為一個標準）調整Rxlevaccessmin來縮小基站的覆蓋范圍，適當?shù)臏p少話務量，一般調整為12~15調整宏微切換門限，一般情況下載1800M和900M共站的情況下調整，DESSIE城區(qū)基站的話務量不高，不需要分擔話務。調整小區(qū)載頻級的最大發(fā)射功率，不建議調整過大（這種情況是在分擔話務不明顯或者基站為孤站才進行調整，DESSIE區(qū)域大部分基站為孤站，需要根據(jù)實際情況來調整）E1資源不夠，基站為S6/6/6或者S8/8/8的配置，但僅1對E1資源，這種情況下，建議擴容傳輸載頻配置不高，而基站話務量高，建議擴容板件TCH假擁塞TCH頻點干擾引起的擁塞率高，用naster軟件來分析頻點是否存在干擾。硬件故障引起的擁塞率高，造成TCH可用率不高市電原因引起的TCH可用率低，我們提取的KPI力度至少為15分鐘，在晚忙時如果沒有達到15分鐘的力度，KPI顯示TCH可用率可能為0%傳輸故障，基站存在高誤碼告警或者lapdjam告警會造成小區(qū)SD和TCH都高度擁塞TCHcalldrop分析（提取RMMcalldropmeasure）引起掉話的主要是三種原因：lapd引起的掉話，TCH切換引起的掉話，無線鏈路超時引起的掉話，提取RMMcalldropmeasure分析LAPD引起的掉話：DESSIE區(qū)域近期由于市電，微波IDU,ODU故障引起的掉話多切換引起的掉話：解決切換問題，TCH掉話自然減少了，同時看切換的小區(qū)是否擁塞，擁塞的情況下同樣會造成用戶無法返回原信道造成掉話。無線鏈路超時引起的掉話：一般情況下是由于基站覆蓋，頻點干擾，或者是參數(shù)設置問題。就掉話問題，DESSIE區(qū)域的KPI一般保持正常，但市電和傳輸故障對掉話影響較大，主要關注基站告警,頻點干擾引起的掉話，檢查頻點規(guī)劃。參數(shù)設置是否合理：功率控制參數(shù)里面的最大和最小發(fā)射功率，1800M默認設置為0,11,900M默認設置為5,16.最小接入電平是否設置過小。呼叫被強制占用（這種情況在呼叫的過程中會引起B(yǎng)lockcall）定時器設置：T3103（切換過程TCH信道保留定時器），此定時器設置太長將大大浪費系統(tǒng)資源，但設置太短又不能保證切換的完全建立所需的時間，如果失敗將導致掉話，建議該值設置為5s。RLTimeout鏈路故障計數(shù)器，設置過小，會增大掉話率（一般此值不建議修改）上下行鏈路是否平衡。TCHassignmentfailurerate分析（提取TRXmeasurement）硬件故障，DTRUG存在顯性故障，這種問題容易判斷合路器問題，一般情況下，不僅僅是單個載頻故障，連接到同一合路器上的載頻會出現(xiàn)同樣的情況天饋線接反，結合DT測試和KPI判斷分析頻點干擾結合DT測試和網(wǎng)優(yōu)軟件分析，看是否存在同頻現(xiàn)象TRX隱性故障提取載頻級的測量報告，觀察載頻占用的總時長和占用的次數(shù)，兩者相除為平均占用的時長，如果占用時長過短，如：5s,7s,等等，則載頻存在故障，同時觀察TCH/H,TCH/F分派成功率是否正常。射頻連線故障這種需要上站檢查基站的射頻連線，結合后臺數(shù)據(jù)配置看前后臺配置是否一致，主要看TX連接。覆蓋問題這種情況也是需要做DT測試來排查問題的，一般情況下，可以根據(jù)觀察其他的KPI指標來判斷。5）Handoversuccessfulrate分析（提取adjacentcellmeasurement）1)請求N次，成功0次a.檢查是否存在同頻同BSIC現(xiàn)象，或者同頻同BCC，主要現(xiàn)象在城區(qū)內b.基站時鐘是否同步，看CMB板是否存在故障c.檢查基站時鐘同步方式是否一致（網(wǎng)同步和內同步）這種情況下在DT測試的過程中會發(fā)現(xiàn)呼叫建立成功率也會受到影響。d.檢查基站的載頻是否存在高溫告警，一般會造成小區(qū)中斷，導致連續(xù)切換失敗2）請求N次，成功M次a.從點對點的切換測量中分析，看哪種原因引起的切換多，如：上行質量，下行質量，上行強度，下行強度（緊急切換），在切換控制的參數(shù)里面可以調整相應的參數(shù)值，一般情況下，上下行強度默認值為16,（表示在-94情況下會發(fā)起緊急切換）一般我們調整上行強度為8~10，下行強度調整為10~12，來減少切換請求次數(shù)。b.檢查PBGT切換參數(shù)（在小區(qū)的鄰接參數(shù)里面設置），看參數(shù)設置是否兩極化，同樣可以調整切換的優(yōu)先級，同時可以調整切換懲罰時間（默認值為7）一般可以修改為15~25.c.檢查基站是否存在告警，如：PA3dB,VSWR等等告警d.鄰區(qū)關系是否正常（重點檢查BSC41的鄰區(qū)關系）e.解碼錯誤，這種情況只有在DT測試過程中會發(fā)現(xiàn)，TEMS軟件解碼錯誤會造成切換失敗。d.越區(qū)覆蓋造成的切換差，典型的現(xiàn)象是孤島效應。f.上下行鏈路是否平衡，主要是由于合路器問題造成的。關于切換中有種問題需要重點關注，撥打免費909或者444444時切換不正常，而主被叫呼叫過程中切換正常，這種情況是由于核心網(wǎng)數(shù)據(jù)配置中，呼叫前切換未開啟。6)CSSR分析1）首先觀察影響CSSR的相關的KPI，DESSIE區(qū)域一般是由于SDCCH擁塞，TCH擁塞，SDCCH激活成功率，SDCCH指派，TCH指派，TCH掉話，傳輸故障引起的CSSR不理想，可以有針對性的來觀察這些指標著個排查。2）如果一些指標從OMCR里面無法取出來觀察，可以從MINOS里面提取指標觀察，查看基站話務量是否正常，如：SDCCH話務量正常，而TCH話務量為0，看基站的數(shù)據(jù)配置是否正常，正常的情況下，檢查傳輸，看傳輸是否存在lapdjam告警，檢查數(shù)據(jù)配置里面的OMU配置。3）SDCCH和TCH擁塞對CSSR的影響較大，這種情況下，首先解決擁塞問題。4）SDCCH指派不理想，后面會做分析。5）TCH指派不理想，這種情況前面已經(jīng)提到了遇到的問題6）參數(shù)設置是否合理，如：Rxlevaccessmin，是否設置過大，載頻級對應的TSC是否設置一致，CRO是否設置過大，造成用戶不在服務區(qū)。7）頻繁的位置更新。8）硬件故障，看基站是否存在顯隱性故障。7）SDCCH指派分析（提取TRXmeasure）1)同頻同BSIC，前面已做過說明。2）TA_Allowed是設置過大（設置過大的話，導致過多的RACH信道接入，這種情況一般是由于孤站引起的）3）覆蓋是否不理想（可能由于硬件故障引起的）4）傳輸是否正常（DESSIE區(qū)域傳輸故障的問題多）5）跨LAC區(qū)域的位置更新，一般調整CRH（默認值為4，可以調整為7）或者調整T3212（與MSC設置一致，一般不建議調整）8）上下行質差分析1）頻點干擾2）切換不及時（切換緩慢，造成用戶長期占用在質差壞的小區(qū)）3）硬件故障（包括DTRUG和CDU故障）4）天饋接反5）規(guī)劃是否合理DT測試部分：涉及到城區(qū)DT測試，VIP站點測試，割接測試，單站測試，PAT站點測試。KPI的算法定義：CSSR算法定義：Handoverfailurenumber算法定義:ULRQ-3算法定義：([C100030066(NumberofsampleswithULRQ=0)]+[C100030067(NumberofsampleswithULRQ=1)]+[C100030068(NumberofsampleswithULRQ=2)]+[C100030069(NumberofsampleswithULRQ=3)])/([C100030066(NumberofsampleswithULRQ=0)]+[C100030067(NumberofsampleswithULRQ=1)]+[C100030068(NumberofsampleswithULRQ=2)]+[C100030069(NumberofsampleswithULRQ=3)]+[C100030070(NumberofsampleswithULRQ=4)]+[C100030071(NumberofsampleswithULRQ=5)]+[C100030072(NumberofsampleswithULRQ=6)]+[C100030073(NumberofsampleswithULRQ=7)])報告輸出：主要有優(yōu)化日報，TOPN英文周報，維護周報網(wǎng)優(yōu)部分遺留問題：SDCCH擁塞小區(qū)統(tǒng)計：SDCCH擁塞率基本保持正常，沒有長期擁塞的小區(qū)，主要是由于從DESSIE往首都方向，從DESSIE往MEKELE方向的光纜不穩(wěn)定，造成大部分基站SDCCH擁塞，傳輸穩(wěn)定的情況下，保持正常。TCH擁塞小區(qū)統(tǒng)計：SEMERA區(qū)域下的部分基站由于高話務量，導致TCH長期擁塞，如：Asiyta_02_G，ASAITA_D，Dubti_01_G高話務地區(qū)，但E1資源不夠，建議擴容。Logya_01_G擁塞的原因是由于周邊愛立信站點斷站導致的。SENBETE_01_G擁塞是由于基站存在駐波比告警，造成TCH可用率低。Degan_01_G由于基站故障造成TCH擁塞。無線分區(qū)TITA_G由于高山站點越區(qū)覆蓋造成TCH話務量高，建議擴容。KOBO_03_G_3由于基站越區(qū)覆蓋造成TCH擁塞，現(xiàn)已擴容解決。R3-5-2_G擁塞的原因是高話務低配置，建議擴容。MERSA_02_G，MERSA_01_G擁塞的原因是由于市電原因導致的。18_R3_06_G擁塞是由于高話務低配置導致的。TCH掉小區(qū)統(tǒng)計：WELDIYA_03_G由于基站閃斷頻繁造成LAPD掉話，建議微波人員檢查。DESSIE,WAREHOUSE_D切換引起的掉話多，現(xiàn)已解決。之前由于微波傳輸引起的LAPD掉話的站點，在進行割接后問題得到解決。切換失敗次數(shù)較多小區(qū)統(tǒng)計：DESSIE城區(qū)內部分小區(qū)的鄰區(qū)關系不全導致切換成功率不理想，建議對全網(wǎng)鄰區(qū)進行檢查，檢查是否存在單向鄰區(qū)關系，同時有基站DESSIE,WAREHOUSE_D_2由于存在NCEND/4故障，導致切入不理想，建議更換板件。ZTE與NOKIA站點切換問題，由于NOKIA站點覆蓋遠，站點擁塞率高，ZTE與之的切換不理想，建議聯(lián)系NOKIA工程師共同解決。如：KEMISE_01_G與NOKIA站點切換不理想。BSC14下的FILAKIT_01_G_2和BSC15下站點19_R3_09_G_1CDU存在故障，導致切入成功率不理想，建議更換板件。TCH指派不理想小區(qū)：BSC14下站點FILAKIT_01_G_2和