1、常見問題的分析解決及預(yù)防 彭海玲,阿爾卡特基站典型故障分析,2 | Presentation Title | Month 2006,駐波比VSWR告警 2. 基站BTS數(shù)據(jù)下載不正常 3. 小區(qū)misalign 4.TCH分配失敗 RSL FLT 故障分析 規(guī)范化操作 OMC告警顯示 A925TC故障分析報告 BSC出現(xiàn)數(shù)據(jù)吊死處理方法 關(guān)于兩種觸發(fā)TCU Restart故障的情況說明,駐波比故障分兩種：,載頻（TRE）駐波比 天線（antenna）駐波比,載頻（TRE）駐波比,現(xiàn)象： TRE退服，不能正常工作； 影響： 如果小區(qū)載頻配置少，會引起擁塞，如此小區(qū)是單載頻的話，則這個 小區(qū)所覆蓋

2、的區(qū)域信號差或直接打不了電話，引起投訴. 問題的分析： 1. 載頻TRE硬件故障 2. TX CABLE壞引起 3. 合路器（ANC）由于某1路端口不正常引起 解決方法： 1. 首先調(diào)換TX CABLE,觀察故障是否有轉(zhuǎn)移來確認(rèn)TX CABLE是否好壞； 2. 更換載頻TRE； 3. 更換載頻連接合路器(ANC)的端口，如沒有端口，則需要更換合路器(ANC),天線（antenna）駐波比,現(xiàn)象： 小區(qū)退服，小區(qū)所有載頻退服，不能正常工作； 影響： 這個小區(qū)所覆蓋的區(qū)域信號差或直接打不了電話，引起投訴 問題的分析： 1. 合路器（ANC）硬件、避雷器故障 2. 饋線彎曲過大、變形及饋線與跳線的接

3、口是否擰好或進(jìn)水引起 3. 天線老化、損壞 4. 載頻（TRE）內(nèi)部故障及TX cable引起 5. 同頻或鄰頻干擾引起，主要是本小區(qū)的頻點 解決方法： 1. 用駐波比測試儀定位是不是由天饋部分引起的駐波比，天饋部分包含：天線、饋線、跳線、饋線與跳線接口 2. 更換合路器(ANC)，如是單載頻小區(qū)，調(diào)換TX CABLE及載頻來判斷硬件是否好壞； 3. 檢查邏輯數(shù)據(jù)有沒有錯誤；,問題分析：,BSC方面引起 1. 數(shù)據(jù)問題（數(shù)據(jù)配置不正確、創(chuàng)建時數(shù)據(jù)出現(xiàn)異常） 2. ABIS端口不正常 3. LIU板或TP板引起個別BTS數(shù)據(jù)下載不正常（情況極少） BTS方面引起 1. 數(shù)據(jù)配置問題 2. 硬件問

4、題，包含：SUMA、ANC、TRE、后背排線部分、XIBM(OUTC)、機(jī)框 傳輸問題 1. 傳輸連接問題 2. 傳輸誤碼 3. 傳輸幀丟失,解決方法：,1、傳輸方面： 檢查傳輸鏈路在對BTS和BSC自環(huán)及斷開的情況下是否都正常，如基站自環(huán)不正 常，需要一級一級的更換硬件（Eacb板、 Eacb 到SUMA板的連線、SUMA板）； 在BTS和BSC檢查傳輸有沒有誤碼及幀丟失的告警，如果有，則首先檢查BSC側(cè) 與BTS側(cè)的傳輸2M頭和連接BTS的9針串口是否有虛焊的情況，如都是正常的話 ，接下來就要檢查基 站接地、光端機(jī)接地是否良好，最好拿1根線把基站和光 端機(jī)的地線連接起來； 如傳輸還存在問題

5、，可以考慮更換光端機(jī)。,2、對于BSC方面： 檢查創(chuàng)建基站配置的數(shù)據(jù)是否正常 切換主用的SYS-CPR（OMCP），再重新下載數(shù)據(jù) 刪創(chuàng)基站的數(shù)據(jù) 在不同的LIU板上，重新創(chuàng)建BTS,3、對于BTS方面 更換SUM板； 拔出所有的硬件（ANC、TRE），不包含SUM板，從OMC-R上重新下數(shù)據(jù)，如果 還是不能下數(shù)據(jù)，則排除ANC/TRE所引起的問題，如果可以的下數(shù)據(jù)，則逐一 添加小區(qū)硬件來確認(rèn)是由那塊硬件所引起的； 確認(rèn)基站上的硬件沒有問題，可以更換基站機(jī)框上的后排線，在更換排線的同 時需檢查連接排線的電路板是否短路或損壞情況，在特定的情況下，可以把排 線上端的不連接機(jī)架背后的電路板，因為這塊

6、電路板有時會影響基站數(shù)據(jù)的下 載；,12 | Presentation Title | Month 2006,3,小區(qū)Misaligned問題,13 | Presentation Title | Month 2006,現(xiàn)象：小區(qū)的aligned status狀態(tài)為misaligned,在omcr上能夠發(fā)現(xiàn)小區(qū)上有“！”的 標(biāo)志，多發(fā)生于在對小區(qū)配置或參數(shù)進(jìn)行修改的過程中。 影響：小區(qū)及相關(guān)小區(qū)（例如同misaligned小區(qū)有切換關(guān)系的小區(qū)）無法繼續(xù)修改 參數(shù)，在割接過程中可能影響割接的進(jìn)度。 問題的分析： Omcr的數(shù)據(jù)庫同BSC的數(shù)據(jù)庫應(yīng)該保持一致，不管邏輯參數(shù)的修改（以 OMCR上設(shè)置的

7、為準(zhǔn)更新BSC的數(shù)據(jù)庫）還是LOGICAL AUDIT（以BSC數(shù)據(jù)庫為 準(zhǔn)，更新OMCR的數(shù)據(jù)庫）的過程，兩個數(shù)據(jù)庫之間都有一個同步的過程，若在 同步過程中發(fā)生了異常，則會使數(shù)據(jù)庫的更新無法實現(xiàn)，從而導(dǎo)致數(shù)據(jù)庫的不 一致。系統(tǒng)中存在一種misaligned機(jī)制，當(dāng)系統(tǒng)發(fā)現(xiàn)存在數(shù)據(jù)庫不同步時，在 小區(qū)上標(biāo)志出Misaligned的標(biāo)志，目的是提醒操作維護(hù)者數(shù)據(jù)修改（或者logical audit）沒有正常完成，需要后續(xù)工作來保證OMCR和BSC數(shù)據(jù)庫記錄的參數(shù)一 致。,解決方法：,我們根據(jù)misaligned出現(xiàn)的情況及cause，有如下辦法解決小區(qū)misaligned的問題： 1. Logi

8、cal audit時出現(xiàn)misaligned Logical audit時需要從BSC數(shù)據(jù)庫中提取邏輯參數(shù)，更新OMCR上數(shù)據(jù)庫中記錄的信息，如果更新時發(fā)生故障，一般是由OMCR和BSC連接故障引起的（有可能是邏輯鏈路）, 會引起對應(yīng)小區(qū)misaligned，現(xiàn)象和解決方法有兩種： 情況一： 如果在GSM alignment cause中顯示為“ lost of communication with BSC”。則需觀察此時BSC-OMC的連接狀況；如果連接問題得到解決，重新做 audit (或Upload Radio Parameter ）。 情況二： 如果在GSM alignment sta

9、tus cause中顯示為“job unsuccessfull received from the BSC”重新做 audit，如果一個BSC下有許多小區(qū) Misaligned，可以做 “Logical audit BSS”。,2. 參數(shù)修改（包括PRC/SC修改）時出現(xiàn)misaligned 邏輯參數(shù)修改時是以O(shè)MCR上的邏輯配置為準(zhǔn)，修改過程中需要更新對應(yīng)的BSC數(shù)據(jù)庫中的記錄，在更新失敗時，相應(yīng)小區(qū)/BSC會出現(xiàn)misaligned，大致有三種情況及其解決方法如下： 情況一： 如果在GSM alignment cause中顯示問題原因為“ lost of communication wit

10、h BSC”。則 需觀察此時BSC-OMC的連接狀況；如果連接問題得到解決，而該BSC下出現(xiàn)Misaligned 的 小區(qū)又很多 ，此時則需要通過對BSC做Force Config BSS或?qū)isaligned 的小區(qū)逐個來做Force Config 情況二： 如果在GSM alignment status cause中顯示為“job unsuccessfull received from the BSC”, 則需要做BSS Force Config (如果此時有許多小區(qū)Misaligned 則還需做 這些小區(qū)的 Force Config) 情況三： 如果執(zhí)行了Force Config后，小

11、區(qū)依然處于Misaligned的狀態(tài)，可能是由于BSC比較忙，可以等一段時間后再作，在少數(shù)情況下，需要通過PRC來刪創(chuàng)該小區(qū)解決misaligned。,說明：,1. misaligned發(fā)生小區(qū)修改參數(shù)后，一般可以通過“force Config”消除，其原理是讓OMCR 上記錄的參數(shù)強(qiáng)行同步到BSC數(shù)據(jù)庫中，由于“force Config”會要求BSC數(shù)據(jù)庫向OMCR 同步所有小區(qū)的參數(shù)，如小區(qū)參數(shù)，鄰小區(qū)參數(shù)等，BSC需要一段時間更新對應(yīng)數(shù)據(jù) 庫，“force Config” 需要一段時間，如果“force Config” 消除不了，則可以切換OMCP， 再做“force Config” 的

12、操作，如以上操作都不能解決，則需對BSC在omc-r上進(jìn)行刪創(chuàng)。 2. 由于參數(shù)修改時可能發(fā)生的問題很多，如OMCR和BSC的連接瞬間出現(xiàn)故障（可能是邏 輯鏈路），或者是相同操作在同一模塊上，導(dǎo)致BSC響應(yīng)混亂，或者BSC沒有足夠時間 響應(yīng)給連續(xù)的操作，等。就會出現(xiàn)misaligned，我們只能通過優(yōu)化OMCR到BSC的數(shù)據(jù) 更新流程，規(guī)范操作維護(hù)過程來減少出現(xiàn)的概率，同時通過正確的維護(hù)操作，提高解決 misaligned的速度。,預(yù)防措施,1. 建議每天或在大規(guī)模在數(shù)據(jù)的前后在OMCR上作Inconsistencies 檢查，以盡早發(fā)現(xiàn) 并糾正數(shù)據(jù)庫不一致的地方原因：提前發(fā)現(xiàn)并及時解決omc

13、r上數(shù)據(jù)庫中的不一致 有助于減少misaligned出現(xiàn)的概率 2. 建議操作維護(hù)人員在修改參數(shù)時出現(xiàn)misaligned后，及時消除； 原因：只有操作者明確是什么操作后出現(xiàn)misaligned，如果沒有時間處理，請做 好記錄后轉(zhuǎn)給他人處理，如操作的簡單目的描述，操作的時間等。 3. 建議操作維護(hù)人員在參數(shù)修改時，觀察RNUSM/BSSUSM “follow up”窗口中顯示其 他用戶的操作和本人操作的進(jìn)行過程，如果有其他用戶在對某網(wǎng)元操作，則等其 結(jié)束后再做，如果有關(guān)于本人操作不成功或不完全成功時，可能會導(dǎo)致OMCR和 BSC數(shù)據(jù)庫參數(shù)出現(xiàn)不一致，請先消除后再繼續(xù)操作； 原因：部分成功的操作

14、不會出現(xiàn)misaligned，但是由于數(shù)據(jù)庫更新沒有完全成 功，可能導(dǎo)致下次操作出現(xiàn)misaligned，絕對要避免對同一網(wǎng)元同時做右 沖突的操作;,4. 建議不要在對BTS做硬件維護(hù)或硬件配置修改時，同時對相應(yīng)小區(qū)修改邏輯參數(shù)； 原因：有時小區(qū)邏輯參數(shù)修改時也需要自動對硬件作操作，讓參數(shù)修改到BTS/小區(qū)中 ，如unmapped/mapped小區(qū)時需要對BTS O 5. 建議對多個小區(qū)修改邏輯參數(shù)，盡量用PRC方式，如果在SC中直接修改，對于和某個 小區(qū)有切換關(guān)系的小區(qū)，它的參數(shù)修改就要等前面小區(qū)結(jié)束后再進(jìn)行； 原因：參數(shù)修改時，需要更新OMCR上的數(shù)據(jù)庫和BSC的數(shù)據(jù)庫，邏輯參數(shù)修改時首

15、先更新OMCR上的數(shù)據(jù)庫，然后更新BSC的數(shù)據(jù)庫，由于更新BSC的數(shù)據(jù)庫需 要時間（更新DLS和網(wǎng)元中的記錄，如TCU，DTC等），連續(xù)的操作可能使后 一個操作無法及時更新BSC數(shù)據(jù)庫而出現(xiàn)misaligned。PRC操作時OMCR會安 排一個優(yōu)化的過程，而且PRC激活時會將相關(guān)小區(qū)狀態(tài)保留，杜絕其他的操 作同時進(jìn)行。,4,TCH分配失敗,現(xiàn)象：話務(wù)統(tǒng)計報告中TCH的分配失敗率偏高，分配失敗次數(shù)有時表現(xiàn)為某個特定的小區(qū)，有時表現(xiàn)為整個BSC下的所有小區(qū)。 影響：影響考核指標(biāo)，嚴(yán)重時有用戶投訴。 分析與解決： TCH分配失敗是在由TCH分配指派過程中發(fā)生異常而造成TCH無法分配的現(xiàn)象，造成TCH

16、分配失敗的現(xiàn)象主要有以下幾種原因： 1.TCH的資源擁塞 2.無線環(huán)境的原因 3.A接口的故障(通過018報告中，C181計數(shù)器能判斷） 4.相關(guān)硬件的原因（TCU, TRX等等） 5.基站割接過程中非規(guī)范的流程造成TCH分配失敗 6.系統(tǒng)的原因造成的TCH分配失敗 上述幾種情況是引起TCH分配失敗的可能原因，其中前3種情況一般可通過分析話務(wù)報 告，采用一般的優(yōu)化手段能夠定位及解決，這里主要分析后三種情況,相關(guān)硬件的原因：,1. 載頻或?qū)?yīng)TCU的硬件可能造成TCH的分配失敗 對于一些永久性的故障，維護(hù)人員往往能夠很快的定位并解決，而某些間歇性的故障 可能不易被某些維護(hù)人員發(fā)現(xiàn)。 2. 當(dāng)發(fā)現(xiàn)

17、有TCH分配失敗的現(xiàn)象，若在相關(guān)硬件上沒有發(fā)現(xiàn)相關(guān)的實時告警，則可以觀 察一段時間內(nèi)的歷史告警，通過歷史告警往往能夠發(fā)現(xiàn)相關(guān)載頻或其他相關(guān)硬件（如 TCU)的一些間歇性的告警，而這些間歇性的告警往往就是TCH分配失敗的主要原因。 此外，基站的一些配套模塊及設(shè)施異常，可能也是TCH分配失敗的間接原因，例如曾經(jīng) 有1個CASE,發(fā)現(xiàn)在基站割接至其他端口后往往能夠正常運(yùn)行一段時間，但持續(xù)一段時間后 就有TCH分配失敗的現(xiàn)象，排除所有直接相關(guān)的硬件，現(xiàn)象依舊。在發(fā)現(xiàn)基站的風(fēng)扇模塊 異常，解決后，TCH分配失敗的現(xiàn)象也隨之消失。該CASE中TCH分配失敗的現(xiàn)象其實是載 頻長期工作在高溫情況下（由于風(fēng)扇模

18、塊不能正常工作），發(fā)生性能異常所致，而割接 BTS的過程中，載頻停止工作了一段時間，因此剛開始工作時，由于工作溫度符合要求因 此不會馬上表現(xiàn)為異常，但在工作過程中，由于散熱效果不好，使其長時間工作于高溫狀 態(tài)下，因此影響性能，產(chǎn)生TCH分配失敗的現(xiàn)象,3. 基站割接過程中非規(guī)范的流程造成TCH分配失敗割接基站過程中的操作次序若 同正常流程不一致將造成TCH分配失敗。 基站割接基本流程： a) 檢查告警，狀態(tài) 計算ABIS容量（對G2 bsc） b) COPY BTS c) 創(chuàng)建備份PRC d) 創(chuàng)建工作PRC e) SHUT DOWN CELL f) 割接傳輸 g) UNLOCK BTS_O&

19、M,完成AUDIT h) 激活PRC,現(xiàn)場在基站割接過程中往往把激活PRC的步驟提前至割接傳輸之前，這樣在 割接完成后有可能造成TCH分配失敗的現(xiàn)象。 預(yù)防措施： 按正常的流程進(jìn)行割接基站 若按錯誤的順序先激活PRC再割接基站，需在割接完成后，對基站做RESET，或 對O&M做lock，unlock操作,系統(tǒng)原因造成的TCH分配失敗,由于發(fā)生系統(tǒng)內(nèi)部相關(guān)資源的錯誤指向，使得所有分配在錯誤資源上的鏈路建 立請求都會發(fā)生失敗，這就造成了TCH分配失敗的現(xiàn)象。 案例：某分配失敗高的基站在軟件中載頻的相關(guān)狀態(tài)異常 案例：某分配失敗高的基站在軟件中RSL同載頻的映射異常 案例：TRX同RSL的對應(yīng)關(guān)系不

20、同造成分配失敗，在工程及維護(hù)過程中注意規(guī)范化的操作能夠避免這種情況。,RSL FLT 故障分析,5,故障描述：,RSL FLT的情況大致分為兩種情況： 第一種是RSL占用正常，而在OMC-R側(cè)看到其狀態(tài)為FLT； 第二種是RSL占用不正常，而且OMC-R側(cè)的狀態(tài)也為FLT。 無論是第一種情況還是第二種情況，當(dāng)我們在OMC-R側(cè)發(fā)現(xiàn)RSL為FLT時，首先應(yīng) 當(dāng)在BSSUSM的UsoD窗口中檢查該RSL的實際占用，從而判斷是屬于以上的那種況。,故障分析：,在日常操作維護(hù)時，由于種種原因，會導(dǎo)致一些與Mapping相關(guān)的問題發(fā)生 ，RSL在 Abis和TCUC Mapping中所起到的作用非常重要而

21、導(dǎo)致的，RSL不光承接著TRE和TRX 與TCUC的對應(yīng)關(guān)系，同時RSL又基于TRE的信息一起與Abis有著對應(yīng)關(guān)系。所以許多 其它問題都會反映在RSL上 。 如果遇到第一種情況時，問題變得很簡單了，這說明RSL的使用正常，也就是BSC 的DLS層，BSC各級模塊層（BIUA，TCUC等）以及基站模塊層（SUM模塊）Mapping 是沒有問題的，此時問題處在OMC-R層，所以此時可以通過對該RSL的BSC作HW Audit和Alarm/State Audit更新OMC-R的數(shù)據(jù)，從而正確反映現(xiàn)網(wǎng)的情況。,如果是第二種情況時，問題的可能性比較多，一般這種情況多在網(wǎng)絡(luò)調(diào)整時發(fā)生， 因為在調(diào)整配置時

22、（以PRC修改方式為例），OMC-R首先更新OMC-R上的數(shù)據(jù)庫，然 后以命令模式的方式通知BSC逐步更新DLS中的內(nèi)容，在更新完DLS數(shù)據(jù)后BSC根據(jù)其 修改的內(nèi)容分別以Program Transmission的方式，通過Q1 Local Bus總線更新TSCA和 BIUA的數(shù)據(jù)；和以內(nèi)部同步消息的形式，通過DSN網(wǎng)絡(luò)通知相關(guān)TCUC模塊更新其內(nèi) 部數(shù)據(jù)。最后觸發(fā)BTS側(cè)更新其軟件配置，包括Abis Mapping，邏輯信道配置等等。 所有這些更新過程在正常情況下都是可以保證自動并正確執(zhí)行的，但是在某些特殊 情況下，比如BSC側(cè)的TSCA等模塊不好時，或當(dāng)同一個基站被連續(xù)修改，或大量修改 數(shù)

23、據(jù)通過不同終端并以各自獨立的命令模式通知BSC修改其數(shù)據(jù)時，或內(nèi)部進(jìn)程資源 無法釋放，或基站下載軟件時出現(xiàn)傳輸故障時會發(fā)生命令丟失或者消息錯誤和丟失， 以及數(shù)據(jù)無法正確或完整下載，從而無法保證所有的修改命令被正確實施。此時就會 出現(xiàn)諸如RSL 對應(yīng)錯誤或者RSL FLT的等等情況。,常用解決方法：,注意在執(zhí)行以下方法之前必須首先執(zhí)行BSS的HW Audit和Alarm/State Audit以確保 OMC-R與BSC DLS的數(shù)據(jù)一致；其次檢查BSC側(cè)和BTS側(cè)相關(guān)模塊的告警，確保這些模 塊工作正常，最后在基站側(cè)檢查其時隙分配情況是否與BSC側(cè)一致； TSCA模塊作Lock/Unlock：可以

24、觸發(fā)TSCA中的Abis Mapping與DLS同步。 BIUA模塊作Lock/Unlock：可以觸發(fā)BIUA中的Abis Mapping與TSCA中的數(shù)據(jù)同步。 TCUC Restart：可以同步TCUC模塊中的程序段和寄存器中的內(nèi)容一致。 TCUC Reset：可以同步TCUC模塊中的寄存器，程序段中的內(nèi)容與DLS一致。 更改載頻的邏輯信道配置：可能觸發(fā)TRX與RSL的對應(yīng)關(guān)系變化。 變更TRE的配置數(shù)目：可能觸發(fā)Abis Mapping和TCUC Mapping的變化，可以通過前后的Abis 和 TCUC Mapping來確認(rèn)。 更改Abis的復(fù)用方式：可以觸發(fā)Abis Mapping的

25、變化。 刪創(chuàng)小區(qū)：可能觸發(fā)TRX與RSL的對應(yīng)關(guān)系變化。 刪創(chuàng)基站：可能觸發(fā)Abis Mapping和TCUC Mapping的變化，可以通過前后的Abis 和 TCUC Mapping來確認(rèn)。 基站開關(guān)電：可以觸發(fā)Abis Mapping在BTS側(cè)的重新下載。 SYS-CPRC的切換：可以觸發(fā)BSC系統(tǒng)內(nèi)部的狀態(tài)更新。,6,規(guī)范化操作,規(guī)范化操作,現(xiàn)網(wǎng)經(jīng)常會在基站的配置調(diào)整過程中發(fā)現(xiàn)TRE/RSL對應(yīng)不上，小區(qū)出現(xiàn)TCH分 配失敗等現(xiàn)象，這種現(xiàn)象的出現(xiàn)同配置調(diào)整過程中沒有按照規(guī)范操作有很大關(guān) 系。嚴(yán)格按照配置調(diào)整手冊描述的步驟進(jìn)行操作，能最大限度的避免工程及維護(hù) 過程中出現(xiàn)的異常所有的網(wǎng)絡(luò)配

26、置調(diào)整的手冊都能夠在BSS CUSTOMER DOCUMENTATION中查閱到，這里簡單介紹一下現(xiàn)場經(jīng)常涉及到的操作及可能忽視 的地方。涉及如下操作： 1. 擴(kuò)容規(guī)范操作（以4頻點的BTS擴(kuò)容至5頻點為例） 2. 替換不同類型硬件的規(guī)范操作（已TRGM替換TRAGE為例）,擴(kuò)容的規(guī)范操作：,擴(kuò)容前檢查（OMCR上操作） 執(zhí)行Audit Alarm State 檢查相關(guān)網(wǎng)元的狀態(tài)及告警 檢查擴(kuò)容所需的資源（OMCR上操作） 檢查傳輸資源 檢查BTS機(jī)架容量 小區(qū)邏輯數(shù)據(jù)擴(kuò)容的準(zhǔn)備 創(chuàng)建備份PRC1(用于原來配置的備份） 創(chuàng)建擴(kuò)容PRC2（用于設(shè)置擴(kuò)容所需的邏輯數(shù)據(jù)） 在PRC2中設(shè)置擴(kuò)容所需的

27、邏輯數(shù)據(jù) 如頻點分配，跳頻序列調(diào)整，邏輯信道設(shè)置等相關(guān)擴(kuò)容數(shù)據(jù),硬件擴(kuò)容準(zhǔn)備(BTS 側(cè)操作） 執(zhí)行Start HW Configuration Modification。 插入載頻（TRE），ANY模塊，并連接相應(yīng)的射頻線。 硬件的配置調(diào)整（BTS側(cè)操作） EDIT SECTOR MAPPING(確認(rèn)的作用） Initialize Single TRE End Commission 結(jié)束硬件配置調(diào)整 Finish HW Configuration Modification（BTS 側(cè)操作） 等待omcr上HW AUDIT的結(jié)束，并觀察結(jié)果（OMC側(cè)操作） 檢查告警狀態(tài),邏輯數(shù)據(jù)調(diào)整 激活創(chuàng)建

28、的PRC 撥打測試，檢查狀態(tài)告警 注意點： 現(xiàn)場操作時，往往忽略BTS側(cè)相關(guān)命令的操作，只是在OMCR上完成數(shù)據(jù)后直 接在BTS上進(jìn)行硬件調(diào)整，這可能會引起B(yǎng)TS側(cè)同BSC側(cè)數(shù)據(jù)的不一致，造 RSL/TRE對應(yīng)不上，TCU分配失敗等異常,替換不同硬件類型的規(guī)范化操作,替換前檢查(omc上操作） Audit Alarm State 檢查替換前狀態(tài) Shut down 相應(yīng)的RSL（omc上操作） Lock 相應(yīng)的TRE（omc上操作） 通知基站側(cè)可進(jìn)行硬件的替換 基站側(cè)更換模塊（BTS側(cè)操作） 更換不同類型的硬件模塊（如用 TRGM替換TRAGE ） Start HW Configuration

29、 Modification Initialize Single TRE End Commissioning Finish HW Configuration Modification 等待OMCR上HW AUDIT結(jié)束 恢復(fù)通信 Unlock TRE Unlock RSL,注意事項： 不同類型的載頻替換現(xiàn)場往往采用尋常的更換tre更換流程，忽視rsl的 lock/unlock,基站側(cè)的終端上的配置調(diào)整,這可能導(dǎo)致BSC內(nèi)部相關(guān)數(shù)據(jù)的異常 而出現(xiàn)異常。,7,OMC告警顯示問題,現(xiàn)象：OMCR上個別告警沒有及時更新 OMCR上個別網(wǎng)元告警丟失，無法看到告警信息 影響：對于在OMCR上沒有產(chǎn)生告警的故

30、障無法及時發(fā)現(xiàn)及時處理 分析：BSS中有兩個隊列，分別更蹤著BSC/TC和BTS的所有網(wǎng)元的告警狀態(tài)，并 更新至SYS CPR(OMCP)中的告警文件中，OMCR從這兩個文件中同步BSS的 告警。若在OMCR上出現(xiàn)告警顯示異常時，我們需分析出故障點到底在哪 里？可能有如下三種情況： 1. 中的告警文件正常，OMC的相關(guān)進(jìn)程沒有正常接收到BSC發(fā)出的告警信息 2. 告警隊列中的告警信息沒有更新至SYS CPR(OMCP)中的告警文件 3. 告警隊列中沒有正常更新網(wǎng)元的告警狀態(tài),解決方法:,1. 對于第1種情況，由于SYS CPRC(OMCP)中的告警文件中有正常的告警信息 ，因此只要在OMCR上

31、對此網(wǎng)元做ALARM AUDIT即可使OMCR上的告警數(shù)據(jù) 庫重新同BSC上的告警文件取得同步，從而顯示正常的告警信息。 2. 對于第2種情況，由于SYS CPRC(OMCP)中的告警文件中沒有相關(guān)正常的告 警信息因此在OMCR上執(zhí)行ALARM AUDIT沒有用，需把SYS CPRC(OMCP)上 的告警文件刪除，此時系統(tǒng)會自動根據(jù)告警隊列中的告警信息重新生成正 常的告警文件，然后再OMCR上觸發(fā)ALARM AUDIT,則能重新顯示正確的告 警信息。 3. 對于第3中情況，由于告警隊列中異常，此時可對相關(guān)的模LOCK/UNLOCK 操作，觸發(fā)更新正常的告警狀態(tài)。,預(yù)防辦法：,保證BSC與OMC

32、-R連接的穩(wěn)定性 加強(qiáng)網(wǎng)絡(luò)維護(hù)，減少短時間內(nèi)頻繁告警的現(xiàn)象,問題描述：,據(jù)現(xiàn)場反應(yīng)，一個A925TC上部分MT120模塊出現(xiàn)重起的現(xiàn)象。 問題處理過程： 1. 在TAC遠(yuǎn)程支持下，現(xiàn)場工程師斷開SUBRACK3和SUBRACK4的架內(nèi)連線后，重起的模塊恢復(fù)正常。 2. TAC工程師在現(xiàn)場處理并收集信息。連接此前斷開的連線，模塊出現(xiàn)重起現(xiàn)象，由于時間緊迫，未能繼續(xù)處理下去，但是收集到了數(shù)據(jù)和告警。之后恢復(fù)到前一天狀態(tài)。 3. 根據(jù)收集到的信息及此前的處理操作，判斷為第四子架的TEI 74存在問題，經(jīng)過插拔后，連接背板連線，重起現(xiàn)象未再出現(xiàn)。為防止故障再次發(fā)生，更換了這個模塊。,故障分析：,操作分

33、析：根據(jù)TAC和現(xiàn)場工程師在故障發(fā)生后的操作來看，當(dāng)斷開第三和第四分架 的總線連接后，重起現(xiàn)象消除，可以確認(rèn)是由于總線上面或者是和總線相關(guān)的某些模 塊存在故障。 TAC工程師在現(xiàn)場收集了以下的信息進(jìn)行了分析： TC_TE DEC Files (subrack4 is isolated from subrack1/2/3,so there are two files) MT120 debug trace file (as the above) OMC-R的歷史告警,TC_TE_DEC FILE分析：,subrack1/2/3：通過TCTerminal 連接第一、二、三分架的任意一塊MT120上，

34、收集告警，均未發(fā)現(xiàn)有任何異常信息。 subrack4：通過TCTerminal連接第四分架上的任意一塊MT120上，收集告警，可以發(fā)現(xiàn)有多個模塊上存在fault in internal bus的告警，additional info為loss of clock。說明在這個分架上多個模塊都未能拾取到本架的時鐘消息*。 由于此時第三分架和第四分架之間總線已經(jīng)斷開，這些模塊無法獲得從上面下來的第一路總線上的時鐘消息，但是應(yīng)該拾取從本架的最右側(cè)模塊（TEI 74）產(chǎn)生的時鐘消息。同時，在TC-TE上一直無法獲得TEI 74的板子信息，用PC直接連到此模塊上也無法成功建立連接。,MT120 debug t

35、race file：,subrack1/2/3：通過debug線連接到第一、二、三分架的多個模塊上，收集trace，均 未發(fā)現(xiàn)有異常消息。,subrack4：通過 debug線連接到第四分架的多個模塊上，收集trace，發(fā)現(xiàn)有很多有關(guān) TCILB的警告(warning)，說明在這個分架總線上存在著錯誤消息，應(yīng)該是由某一個模 塊產(chǎn)生的.,根據(jù)上述TC-TE 和debug trace分析，可以確認(rèn)是由于第四分架上的某一模塊存在故 障。同時根據(jù)現(xiàn)象基本確定為TEI 74存在故障。 OMC-R的歷史告警： 根據(jù)歷史告警可以看到，在與故障發(fā)生的相應(yīng)的時間內(nèi)，部分mt120模塊存在 INT_BUS_FLT

36、_G25的告警，和TC-TE上第四分架上的模塊告警是一樣的。 結(jié)論： TEI 74模塊由于自身的原因產(chǎn)生了很多錯誤消息，發(fā)到了總線上，導(dǎo)致總線消 息的混亂，引起多個其他模塊的重起。,預(yù)防措施：,更換TEI 74；由TAC工程師帶回故障模塊，在ASB機(jī)房進(jìn)行模擬測試，以找出最終原因。 第一分架的最左一個槽位和第四分架的最右一個槽位上插上空的MT120模塊，以確保A925TC架出現(xiàn)類似問題時的內(nèi)部總線時鐘消息的正確性，從而提高總線的穩(wěn)定。 定期檢查MT120的模塊告警的狀態(tài)。 按照正確MT120擴(kuò)容流程來做，保證OMC顯示和TC上的實際硬件一致，以保證告警信息的正確解讀。,故障現(xiàn)象： 未刪除完相鄰

37、關(guān)系，在做DEL BTS的時候，因數(shù)據(jù)量過大，造成26個小區(qū)數(shù)據(jù)吊死， BSC在不停的做BSC DISCOVER操作中的AUDIT ALARM，BSC始終處于忙時，對BSC所 有的操作都不能執(zhí)行。 故障分析： 1、BSC上有異常告警； 2、因數(shù)據(jù)過多或進(jìn)程沖突，容易引起OMC-R上的數(shù)據(jù)與BSC的數(shù)據(jù)不同步； 3、OMC-R上數(shù)據(jù)有損壞；,故障解決方法：,1、在OMC-R上stop該BSC的進(jìn)程，再start進(jìn)程，做完這步觀察是否還出現(xiàn)上述的故障，如有進(jìn)行第2步； 2、在BSC上檢查有沒有異常告警，； 3、用BSC Termiral查看刪除的小區(qū)，在BSC上是否刪除； 4、如果BSC上無異常告警，所要刪除的BTS都已經(jīng)刪除，則說明BSC沒什么問題，就是OMCR上數(shù)據(jù)的問題，解決方法有刪創(chuàng)BSC、 5、刪創(chuàng)完BSC后，故障解決。 6、如果刪創(chuàng)不了BSC，則可以考慮聯(lián)系OMC-R工程師，刪創(chuàng)OMC-R上的RNIM數(shù)據(jù)庫； 7、上述方法如果未解決，可以重裝OMC-R。,刪創(chuàng)BSC注意事項：,1、如是現(xiàn)網(wǎng)的BSC，不能用REMOVE，而要用Fo