第一篇：OMC告警總結

1: BCC+NCC+BCCH TRX FREQUENCY NOT UNIQUE IN ADJACENCY DEFINITIONS

鄰區存在同頻同BSIC

2: FLEXI MULTIRADIO CAPACITY LICENCE EXCEEDED

容量不夠

3：AMR HR TRX CAPACITY LICENCE EXCEEDED

半速率容量不夠

4: TOO MANY TCHS IN ONE SIGNALLING UNIT

BCSU不夠

5：BSS-SYSTEM HAS NO RESOURCES FOR REQUESTED TASK

系統正在請求

6：BTS HANDOVER CONTROL PARAMETERS NOT FOUND IN DATABASE

功控參數沒加

第二篇：海爾OMC理論

海爾OMC理論

來自海爾的經驗——OMC理論

（1）什么是OEC理論

《札記?大學》中有段佳話：“茍日新，日日新，又日新”，其核心內容直指“OMC”。“OEC”的內容為：O——Overall全方位；E——Every每人、Everyday每天、Everything每件事；C——Control控制、Clear清理。“OEC”管理法也可以表示為：日事日畢、日清日高，即：每天的工作每天完成，每天工作要清理并要每天有所提高。

（2）“OEC”包含著三個基本原則

① 閉環原則。即凡事都要講究善始善終，班組工作也是如此。無論是生產任務，還是班務管理，都必須有一個計劃——實施——檢查——總結的全過程，同時將其有效的落實到班組中的每個人、每件事和每一天，通過設定目標、指定措施和方法、付諸實施、逐一檢查、糾正和改進計劃及修正目標，使班組日常工作中的每件事情都處于受控狀態，使班組的整體工作不斷完善，達到持續提高、螺旋式上升的目的。

② 比較分析原則。班組工作要適時進行總結和分析。縱向與本班組以往的工作狀況相比，橫向與并行班組相比、與同類型班組相比、與相關部門班組相比、與其他員工相比，挖掘不足，尋求發展，充分認識到沒有比較就沒有提高、沒有比較就沒有發展的道理。

③ 不斷優化的原則。班組工作永無止境，要及時找出薄弱環節，加以分析并及時整改，以期待提高整個班組的生產和管理水平。

（3）體系構成：目標體系——日清體系——激勵機制

首先確定目標“OEC”管理法實際上是一個目標管理體系，總目標是“日高”，即通過工作的不斷完善使班組管理水平、班組生產水平以及班組長、班組成員個人綜合素質持續提高，最終實現使企業取得最佳經濟效益的總目標。

其次，“日清”是完成目標的基礎工作即通過當天的工作當天完成，不拖延、不滯后，使得班組日常工作的每一件事達到有序狀態和受控狀態。達到“日高”的目標和鞏固“日清”的基礎又是通過在每天的日常工作中，全面管理班組里每個人、每件事的具體行為過程而完成的。

最后，日清的結果必須與正負激勵掛鉤才有效。

小看板：“如果我們把一塊錢人民幣存到銀行里，以利滾利的方式計算利息，即便利息率僅僅為1%，那么70年后，一塊錢就會變成兩塊錢。”

管理工作的難點在于做到持續的實施和改進，而海爾“OEC”管理法正是解決了這個問題，把所有的目標分解到每個人身上，每個人的目標每天都有新的提高，這樣就可以使整個工作不斷改進，績效有條不紊地持續增長。

小看板：美國企業管理學家戴明博士有句明言：“每天進步1%”。

“勿以善小而不為”。萬通董市長馮侖曾說過：“管理公司要求有家庭主婦的心態。你每天都打掃衛生，看看池子里的水是否干凈，碗碟有沒有洗好，桌子有沒有擦干凈??。只有這樣的心態，才能管好公司。”海爾經過多年經驗總結出來的“OEC”管理，正是強調了這種一點一滴勤于積累的方式。其只要內涵和精髓在于將“日事日畢、日清日高”滲透到企業的各項工作中去，全方位地對每人、每天、每件事進行控制和清理，每天有所提高，促使企業、企業的生命存在于細節之中，這種看得見、摸的著的管理方法、細節上的創新，實現了基礎管理的精細化和規范化、科學化和標準化、目標化和效率化

第三篇：OMC日常操作指令

日常維護操作指令

一、查詢小區狀態...........................................................................................................................2

二、查詢載波狀態...........................................................................................................................3

三、去激活/激活小區.....................................................................................................................4

1、去激活小區.........................................................................................................................4

2、激活小區.............................................................................................................................4

四、查詢NODEB信息.....................................................................................................................5

五、查詢基站傳輸狀態...................................................................................................................5

六、查詢基站SCTP鏈路狀態.........................................................................................................7

七、OMC查詢告警.........................................................................................................................8

1.瀏覽當前告警...................................................................................................................8 2.查詢告警日志.................................................................................................................11

八、設置和查詢工程狀態.............................................................................................................11 1.設置工程狀態.................................................................................................................11 2.查詢工程狀態.................................................................................................................12

一、查詢小區狀態

通過DSP TCELL:DSPT=BYCELL;命令查詢小區狀態，如下圖：

按小區查詢：通過小區ID查詢小區狀態。

按NODEB查詢：通過NODEBNAME,對該站點下所有小區進行查詢。按小區狀態查詢：根據小區不同狀態進行查詢。

按默認值查詢：選擇任何一種查詢類型，如果不填寫后邊的參數，例如：按小區查詢，不填寫小區ID，那么會默認對全網所有小區進行查詢。

一般情況下，選擇按NODEB查詢，如下圖：

需要填寫相應NODEB名稱，執行后，如下圖：

通過查詢結果可看出此站點包括三個小區，然后觀察操作狀態，操作狀態為可用時小區正常，為不可用時小區異常，下邊還會對小區狀態進行補充說明。（例如：2405小區，操作狀態不可用，狀態說明解釋為小區未激活，這時小區處于一個未激活的狀態導致小區操作狀態為不可用）

操作狀態取值為：可用 不可用

狀態說明為：小區建立且可用 小區建立且不可用 小區未建立 小區未激活等

二、查詢載波狀態

通常情況下，小區如果操作狀態為不可用，那么該小區下所有載波狀態均為不可用，在此我們只針對，小區可用且載波異常的站點進行該項查詢。通過DSP TCARRIER:;命令查詢載波狀態，如下圖：

小區標識：針對特定小區進行載波狀態查詢 載波索引：針對特定載波進行載波狀態查詢 載波狀態：針對特定狀態進行載波狀態查詢

默認：如果某一項不選擇，則默認為全包含，例如：填寫小區ID情況下，不填寫后兩項，那么會對該小區下所有載波進行查詢，并返回可用的以及不可用的載波的狀態 一般情況下，我們會針對小區查詢，如下圖：

執行結果如下圖：

從執行結果中，我們可以得知該小區所有載波的頻點值以及載波當前狀態。載波狀態為載頻已建立并當前可用為正常，其余所有值均為異常。

三、去激活/激活小區

1、去激活小區

命令為DEA TCELL:;，需要填寫小區ID,如下圖：

執行完畢后，該小區狀態為小區未激活。

2、激活小區

命令為ACT TCELL:;，需要填寫小區ID，如下圖：

四、查詢NODEB信息

LST TNODEB該命令用來查詢NODEB的配置信息。

在查詢類型里可以選擇是按照NODEBID還是NODEB名稱來查詢。上圖為選擇按照NODEBID來查詢，在后面NODEB標識里面輸入相應ID即可。查詢的結果里面包含了該基站的所有信息，在這些信息里面我們常用到的有基的ESN,SCTPLNK,基站IP地址,VLANID,所在接口板等。電子串號是基站的ESN號，每個站點唯一，可由基站督導提供或者使用命令“DSP ELABEL:DEVTYPE=SUBRACK,CN=0,SRN=0;”在基站上查詢。

五、查詢基站傳輸狀態

IP傳輸對RNC來說相對比較簡單，只需要與傳輸側核對光口和VLAN ID無誤即可。

1.查詢基站IP地址和VLAN ID，使用LST TNODEB命令，輸入NODEB ID，返回結果有縱表和橫表兩種顯示方式，這里為了方便截圖，使用縱表方式；

2.查詢RNC聚合組，使用命令LST ETHTRKIP查看RNC上承載IP基站的接口板的聚合組配置IP地址，每個聚合組單獨配置在一個光口上。如圖中，聚合組號為0,1,2分別代表接口板0,1,2三個光口。

3.根據基站IP和聚合組地址判斷基站所在光口，每個聚合組為一個掩碼為/25的地址段，基站IP地址在哪個IP段，即基站承載在該光口上。如上圖，基站IP為10.95.92.49，在10.95.92.1/25這個地址段內，即說明基站承載在0號光口； 4.檢查IP基站傳輸是否對通：PING命令

如下圖，源IP為ETHTRKIP,目的IP為基站IP,使用Ping命令時，連續返回4個數據包，無丟包現象，表示傳輸已通。

如下圖，源IP為ETHTRKIP,目的IP為基站IP,使用Ping命令時，連續返回4個數據包，全部丟失，表示傳輸中斷或者未通。

六、查詢基站SCTP鏈路狀態

DSP SCTPLNK該命令用來查詢SCTP鏈路狀態。

從LST TNODEB命令中可以查詢出該基站子系統的框號，槽號，SCTP鏈路號，一般每個站點有4條SCTPLNK。

在查詢SCTP鏈路狀態時，可以通過反復執行命令，觀察返回結果中狀態改變時間，來確定SCTP鏈路是否閃斷。如狀態改變時間一直不變，說明SCTP鏈路穩定建立，沒有故障；

七、OMC查詢告警

查詢告警主要通過OMC進行，一般指查詢當前告警和告警日志

1.瀏覽當前告警

登陸OMC，進入應用中心，右鍵點擊“故障管理”，彈出如下界面：

選擇告警瀏覽中“瀏覽當前告警”，進入當前告警查詢界面：

如果有告警模板的話，可直接點擊按“模板過濾”選擇“打開”進入告警模板界面，打開自己的模版。

如果沒有模板可以選擇“過濾”進入告警設置界面自定義要查看告警；告警設置界面如下圖：

在基本設置中選擇告警級別，一般全選，狀態中選擇未確認未清除和已確認未清除，維護狀態全選；“告警名稱”勾選后可單獨瀏覽指定告警，如小區退服等；

完成設置后進入告警源選擇界面，選擇“自定義選擇”，點擊左下角“增加”按鈕，可以按照網元或者網元類型查詢：

如查詢全網所有基站當前告警，可按照選擇按照“網元類型“瀏覽，將網元類型中的TDNodeB和NodeB530移到右側已選類型中，點擊確定即可。如查詢全部RNC告警可單獨選擇TD-RNC；

這里需要注意，基站告警中不包含小區退服和NODDED退服，如要查看這兩種告警，需選擇網元類型為TD-RNC;；可在“基本設置”，按“告警名稱”單獨查看這兩種告警；

如查詢指定基站告警，可進入告警源選擇界面，選擇“自定義選擇”，點擊左下角“增加”按鈕，選擇按照“網元”查詢告警：進入如下界面

將需要的網元移至“已選對象”下，點擊確定即可；對網元操作是可選擇“單個選中”或者“級聯選中”，如選擇RNC51，單個選中時表示只選擇RNC51，級聯選中時包含RNC51及RNC51下掛所有基站。

保存告警模版

在對“基本設置”和“告警源”設置完畢后，可點擊左下角“保存模版“保存，這樣后期查詢告警可直接打開模版瀏覽；但要注意，如果選擇按網元瀏覽時，新入網基站并不會自動創建的以保存的模版中，保存模版時最好按照網元類型選擇；

2.查詢告警日志

查詢告警日志與瀏覽當前告警基本相同,登入OMC后，右鍵點擊“故障管理“，選擇“查詢告警日志”，進入以下界面：

查詢告警日志需要選擇告警發生時間，有兩種方式：按照“發生時間”或者按照“最近的”時間來。如上圖個圈紅部分。其他設置通瀏覽當前告警。

八、設置和查詢工程狀態

1.設置工程狀態

登陸OMC，在應用中心中右鍵點擊“配置管理”彈出下拉菜單，界面如下：

點擊菜單中設置“工程狀態”，進入如下界面：

點擊設置工程狀態按鈕，上圖紅色圓圈中按鈕，進入工程狀態設置界面：勾選要設置工程狀態的網元，在設置界面右上角選擇要設置成的工程狀態。點擊確定執行；如果需要批量操作時可通過做上角“導入導出“圖標批量操作。

工程狀態設置時間長度有兩種方式：立即執行和定時執行；

選擇“立即執行”默認結束時間到2037年，后期需要手動將網元恢復普通狀態；

選擇“定時執行”可根據需求設置工程狀態時間長度，到期后網元狀態自動變為普通。

2.查詢工程狀態

登陸OMC點擊設置“工程狀態”按鈕，進入工程狀態設置界面：勾選要的網元，確定執行即可返回查詢結果，界面如下：

查詢基站狀態時會返回邏輯和物理兩種狀態，邏輯指RNC上NODDED狀態，物理狀態即基站本身狀態。

第四篇：4G常見告警解析及常用操作

4G重要告警解析

一、影響小區發射的告警

1.ReachabilityProblem（基站退服或脫管）? Alarm Code：ReachabilityProblem ? 告警影響：eNode B 設備監控失去

? 告警原因分析：導致該告警的原因主要體現在三個方面：電源、傳輸、主控卡(C板)故障: 1)電源:交流停電等，此時應該有相關環境告警上傳； 2)傳輸：傳輸斷

3)主控卡故障：主控卡出現掉死、無法正常啟動、不斷重啟等故障；

? 告警解決方法：電源或傳輸問題，請相關人員解決；如果是主控卡故障，需要維護人員上站解決；更換主控卡后，需要先問網管人員要一個Yang WO文件重新下軟件并導入WO文件激活。

2．CB INIT FAILURE(C板初始化失敗)? Alarm Code：IK4004001 ? 告警影響：整站退服，設備可監控； ? 告警原因分析：C板故障或者高溫導致

? 告警解決方法：需上站下電重啟設備，或熱插拔C板，若故障依舊需要更換C板，更換流程請參考ReachabilityProblem（基站退服或脫管）

3.NO CONTACT TO BOARD（B板退服）? Alarm Code：IK4009041 ? 告警影響：整站退服，小區不發射；

? 告警原因分析：若基站無C板或者GPS告警的話，則是B板故障

? 告警解決方法：網管重啟基站不管用的話，需要上站更換，更換B板會自動下軟件，基站側不需要做任何操作，大概需要10分鐘左右

4.LTECellAdminDown(小區退服)? Alarm Code：LTECellAdminDown ? 告警影響： 相應小區退服；

? 告警原因分析：一般都是由于基站硬件告警或者小區被lock所致

? 告警解決方法：首先排除小區或基站是否被locked，其次查看是否有導致小區退服的硬件告警

5.NO CONTACT TO BOARD（RRH脫離）? Alarm Code：IK4009138 ? 告警影響：某個RRH對應的小區不發射

? 告警原因分析：造成此告警的原因可能是電源，光纖及RRH故障

? 告警解決方法：需下站查看電源及RRH和C板連接的光纖衰耗，如果兩種情況都正常的話，就要考慮RRH本身的問題了，最好的方法是塔上和別的正常小區做對調來排查

6.CB LOS LOF CPRIPORT *（某個小區RRH脫離）? Alarm Code：IK4004030 ? 告警影響：對應小區不發射

? 告警原因分析：造成此告警的原因可能是電源，光纖及RRH故障

? 告警解決方法：需下站查看電源及RRH和C板連接的光纖衰耗，如果兩種情況都正常的話，就要考慮RRH本身的問題了，最好的方法是塔上和別的正常小區做對調來排查

7.CB ALL CPRIPORTS FAILED(所有小區不RRH脫離)? Alarm Code：IK4004061 ? 告警影響：所有小區不發射

? 告警原因分析：造成此告警的原因可能是電源，光纖及RRH故障

? 告警解決方法：需下站查看電源及RRH和C板連接的光纖衰耗，如果兩種情況都正常的話，就要考慮RRH本身的問題了，最好的方法是塔上和別的正常小區做對調來排查

8.CB TRANS RX LOS CPRIPORT *(某個RRH脫離)? Alarm Code：IK4004042 ? 告警影響：造成此告警的原因可能是電源，光纖及RRH故障

? 告警原因分析：RRH掉電、不加電，RRH掉死，光纖故障，CCM板卡故障等原因都會出現RRH脫離告警；

? 告警解決方法：需下站查看電源及RRH和C板連接的光纖衰耗，如果兩種情況都正常的話，就要考慮RRH本身的問題了，最好的方法是塔上和別的正常小區做對調來排查 ；

9.CB GPS ANT

? Alarm Code：IK4004082 ? 告警影響：GPS時鐘不同步，長期告警會造成整站退服 ? 告警原因分析：GPS天線安裝問題或者接頭等問題

? 告警解決方法：檢查GPS天線及各個接頭，告警同時會伴隨產生以下告警IK4004012，IK4004014，IK4004157（GPS鎖衛星失敗）

10.ANTENNA_PORT TX VSWR THRESH2（2級駐波）? Alarm Code：IK4011011 ? 告警影響：小區不發射

? 告警原因分析： 天饋接口問題

? 告警解決方法：下站基站饋線頭是否松動或者進水等等

11.ANTENNA_PORT GAIN CONTROL TX（天線口傳輸主分支增益已經超出范圍）

? Alarm Code：IK4011005 ? 告警影響：小區不發射

? 告警原因分析： RRH硬件故障

? 告警解決方法：step1：SAM側重啟該RRH。Step2：重啟不能恢復的安排上站更換RRH。12.ANTENNA_PORT RF OUTPUT OVRDRV TX（天線口射頻在輸出端功放過大）

? Alarm Code：IK4011006 ? 告警影響：小區不發射

? 告警原因分析： RRH硬件故障，或者天饋系統問題

? 告警解決方法：step1：SAM側重啟該RRH。Step2：重啟不能恢復的安排代維上站檢查饋線或更換RRH。

13.ANTENNA_PORT TX FAIL（天線口傳輸鏈路發生故障且端口射頻傳輸不可用）

? Alarm Code：IK4011004 ? 告警影響：小區不發射

? 告警原因分析： RRH硬件故障，或者天饋系統問題

? 告警解決方法：step1：SAM側重啟該RRH。Step2：重啟不能恢復的安排代維上站檢查饋線或更換RRH。

14.S1 SCTP ASSOCIATION DOWN（ENB和MME的S1端口連接失敗）? Alarm Code：IK4009046 ? 告警影響：所有小區不發射

? 告警原因分析： 一般此告警產生原因都是傳輸問題

? 告警解決方法：首先檢查eNodeb側數據配置是否正常，若正常請安排傳輸排查，此告警產生會伴隨IK4306099這個告警號，以及MMEAccessDown的告警。

二．不影響小區發射的告警

16.ANTENNA_PORT TX VSWR THRESH1(一級駐波)? Alarm Code：IK4011010 ? 告警影響：不影響小區發射，影響業務 ? 告警原因分析： 天饋接口問題

? 告警解決方法：下站基站饋線頭是否松動或者進水等等

17.DBU RUC FAN FAULT MAJOR

(風扇告警)? Alarm Code： IK4005052； ? 告警影響：影響基站散熱

? 告警原因分析：機房溫度過高，或者基站設備安裝位置不通風 ? 告警解決方法：解決室內溫度問題 18.CB OVER TEMP MAJOR，CB OVER TEMP CRITICAL

(C板高溫)? Alarm Code： IK4004117，IK4004118； ? 告警影響：影響基站散熱

? 告警原因分析：機房溫度過高，或者基站設備安裝位置不通風 ? 告警解決方法：解決室內溫度問題

第五篇：基站告警,分析報告

通信故障分析報告

2G基站的告警故障分析報告

故障單位： 巴州 分公司 故障編號：[2013]BZ0077號 上報人員： 故障級別：其他故障 代維單位：

一、故障時間、地點、影響范圍

故障發生時間（以網管時間為準）： 故障最終修復時間（以網管時間為準）： 故障處理人員 故障歷時： 故障地點： 中斷電路數量： 業務影響范圍： 客戶投訴情況：無

二、故障申報處理情況

故障過程的簡要描述：

1、日00：30，網管值班人員在監控上發現多個2G、3G基站告警。這些閃斷基站附近2G、3G業務中斷，網管機房通知代維公司。代維公司人員接到機房通知后立即趕往2G、3G閃斷基站處查看，最終確定造成斷站原因為陽霞縣基站市電停電，導致其下掛的多個2G、3G基站斷站，于01:56代維人員發電后業務恢復，故障歷史86分鐘。

故障申報情況：

申報時間：2014年3月5日00:30 申報對象：故障現象、故障定位和故障排除經過：（1）、故障現象：

（2）、故障定位： 3個3G、8個2G基站

2、（3）、故障排除經過：，網管值班人員在監控上發現多個2G、3G基站告警。這些閃斷基站附近2G、3G業務中斷，網管機房通知代維公司。代維公司人員接到機房通知后立即趕往2G、3G閃斷基站處查看，最終確定造成斷站原因為陽霞縣基站市電停電，導致其下掛的多個2G、3G基站斷站，于01:56代維人員發電后業務恢復，故障歷史86分鐘。

3、故障現場情況：

4、故障處理后涉及的資料、臺帳更新情況： 無

三、故障損失估算：

1、本次故障造成的直接損失：合計約 元。包含以下內容：

2、本次故障造成的間接損失：合計約 元。

1）根據中斷的電路數量計算： 個2M，中斷時長 分鐘，按照10元/2M.分鐘（長途電路）計算損失，合計間接損失 元。

2）根據中斷的基站數量計算（按照系統劃分）： 個基站，中斷時長 分鐘，依據每小時平均話務量 愛爾蘭，按照 元/愛爾蘭計算損失，合計間接損失 元。3）用戶感知角度：無 4）公司形象角度：無 5）其他后勤保障方面：無

3、本次故障造成的經濟損失合計約 元。

四、故障原因分析

故障發生原因：陽霞縣基站市電停電

1、故障的經驗教訓總結

此次故障為陽霞縣基站市電停電，導致其下掛的多個2G、3G基站斷站。代維人員急時趕至斷站現場查明斷站原因偉市電停電后，立即發電，業務恢復正常。今后隨時待命，出現斷站現象用最快的速度趕至斷站現場，查明原因，解決問題，力保公司損失降到最低。