第一篇：LTE投訴故障問題總結(jié)

維護(hù)部

近期LTE故障投訴問題匯總

維護(hù)部近期多次接到4G網(wǎng)絡(luò)故障投訴，故障現(xiàn)象多為反映信號(hào)時(shí)有時(shí)無、上不了網(wǎng)等。現(xiàn)場(chǎng)測(cè)試發(fā)現(xiàn)投訴人所在地均已做LTE網(wǎng)絡(luò)覆蓋，已通過驗(yàn)收，且日常巡檢測(cè)試覆蓋區(qū)域網(wǎng)絡(luò)信號(hào)強(qiáng)度均正常，以中關(guān)村大廈，融科資源大廈以及清華同方科技大廈,為例：

后臺(tái)查詢，該站點(diǎn)設(shè)備無告警、無駐波、小區(qū)配置正常、發(fā)射功率均正常，現(xiàn)場(chǎng)去測(cè)試，2G信號(hào)，TD信號(hào)都沒有問題，分布完好。

現(xiàn)場(chǎng)使用電腦終端測(cè)試，發(fā)現(xiàn)投訴和其他站點(diǎn)投訴類型相同，均由如下兩種情況導(dǎo)致：

1）:現(xiàn)場(chǎng)確實(shí)測(cè)不到LTE信號(hào)，或者時(shí)有時(shí)無，可能接收到室外大站信號(hào)。如圖通過后臺(tái)，要求將該站點(diǎn)所有RU重啟，15分鐘之后，信號(hào)都恢復(fù)，手機(jī)使用也正常。

編寫部門：維護(hù)部

第1頁

共3頁

日期：2014-7-16

維護(hù)部

編寫部門：維護(hù)部

第2頁

共3頁

日期：2014-7-16

維護(hù)部

2）現(xiàn)場(chǎng)用LTE終端測(cè)試，信號(hào)，場(chǎng)強(qiáng)，速率都正常，但是投訴人的手機(jī)在3G或2G網(wǎng)絡(luò)上面，一直切不到4G網(wǎng)絡(luò)。將投訴人手機(jī)重啟之后，恢復(fù)正常。手動(dòng)選擇網(wǎng)絡(luò)-China Mobile.移動(dòng)4G現(xiàn)處于建設(shè)期，目前的完善程度并不是很高，在正常通話時(shí)，網(wǎng)絡(luò)會(huì)切換到2G網(wǎng)絡(luò)，來完成語音通信，通話結(jié)束后，再次恢復(fù)到4G網(wǎng)絡(luò)，但并不是直接就恢復(fù)到4G，而是先會(huì)跳轉(zhuǎn)至2G網(wǎng)，再恢復(fù)3G，最后跳至4G，整個(gè)過程基本需要2-3分鐘，或者更久，甚至直接一直保持在2G或3G網(wǎng)絡(luò)上面，從而造成客戶通話后使用不了LTE網(wǎng)絡(luò)，最后導(dǎo)致用戶的投訴。

編寫部門：維護(hù)部

第3頁

共3頁

日期：2014-7-16

第二篇：LTE常見故障總結(jié)

LTE-FZHA（RL25）常見故障總結(jié)

目錄

LTE-FZHA（RL25）常見故障總結(jié)............................................................................................1

1.System module failure(0010)........................................................................................3 2.BTS reference clock missing(1898)................................................................................3 3.Configuration error: Unit initialization failure(0012).....................................................3 4.Configuration error: Not enough HW for LCR(1868).....................................................4 5.Configuration error: Power level not supported(4008).................................................4 6.Cell configuration data distribution failed(6253)..........................................................4 7.Failure in optical RP3 interface(4064)...........................................................................5 8.Failure in optical RP3 interface(0010)...........................................................................5 9.Baseband bus failure(3020,1906).................................................................................5 10.RF module failure(6259，1911、1711、1712)..........................................................5 11.Cell power failure(4090)..............................................................................................6 12.GPS Receiver alarm: Control Interface not available（4011）..................................6 13.X2 interface setup failure（6304）.............................................................................6 14.Transport layer connection failure in X2 interface.......................................................6 15.Failure in replaceable baseband unit...........................................................................7 16.Temperature alarm(0002)............................................................................................7

17.VSWR（1838）............................................................................................................7 18.Failure in optical RP3 interface(2004).........................................................................8 19.GPS時(shí)鐘盒閃斷，時(shí)鐘信號(hào)不正常，無法識(shí)別RRU...............................................8 20.Failure in optical RP3 interface（2000）.....................................................................8 21.光纖交叉連接..............................................................................................................8 22.基站始終無法建立S1連接，只到configed狀態(tài)....................................................9 23.GPS時(shí)鐘盒閃斷，時(shí)鐘信號(hào)不正常，無法識(shí)別RRU...............................................9 24.某一個(gè)小區(qū)的RRU無法識(shí)別.....................................................................................9 25.BBU版本無法識(shí)別....................................................................................................10 26.校準(zhǔn)初步排查............................................................................................................10 27.本地IP地址和路由正常，ping不通MME和網(wǎng)關(guān)................................................11 28.TRS文件始終無法生效.............................................................................................11 29.三種疑難告警............................................................................................................12 30.遠(yuǎn)程ping不通基站...................................................................................................12 31.風(fēng)扇告警....................................................................................................................12 32.BTSlog有l(wèi)ink消息，但是pinger始終不亮............................................................12 33.駐波問題....................................................................................................................13 34.pinger正常，但是SM里小區(qū)顯示橙黃色告警.....................................................13 35.幾個(gè)特列....................................................................................................................13 36.FOSI 和FOSN的光功率范圍....................................................................................13 37.不同頻段RRU類型...................................................................................................13 1 38.MAC綁定及載波沖突...............................................................................................14 39.傳輸不通....................................................................................................................14 40.升級(jí)完成后出現(xiàn)駐波告警........................................................................................14 1.System module failure(0010)引起原因：

由于天氣溫度過高或者機(jī)房溫度過高，導(dǎo)致BBU的熱量散發(fā)不出去，引起的告警，一般表現(xiàn)是第三小區(qū)掛死，嚴(yán)重的可能會(huì)整站掛死，甚至?xí)龎腂BU。抑或是光模塊出現(xiàn)問題導(dǎo)致出現(xiàn)此告警。處理方法：

1、由于是高溫引起，基站要降溫并重啟BBU.若是BBU長期處于高溫狀態(tài)，會(huì)導(dǎo)致BBU內(nèi)部的芯片燒壞，到最后只能替換BBU

2、若是因?yàn)楣饽K導(dǎo)致，則可以更換光模塊，則可以解決此問題。

2.BTS reference clock missing(1898)引起原因：一般導(dǎo)致此故障有兩個(gè)原因：

1、高溫導(dǎo)致比較常見，由于高溫時(shí)間過長，光模塊過熱，導(dǎo)致BBU和RRU失去連接，而后會(huì)出現(xiàn)此告警。

2、時(shí)鐘盒出現(xiàn)故障。

3、時(shí)鐘線與GPS頭的連接線接頭（避雷器接口）沒有做好，接收不到時(shí)鐘信號(hào)。

4、時(shí)鐘線和時(shí)鐘盒的連接不好。處理方法：

1、高溫引起，基站要降溫，等待一段時(shí)間后并重啟BBU.2、時(shí)鐘盒故障，更換時(shí)鐘盒；

3、GPS線頭沒有接好，重新做一下從GPS引下來的饋線到避雷器的頭子，使其能夠正常接觸。

4、若是時(shí)鐘線損壞，則更換時(shí)鐘線；若是時(shí)鐘線和時(shí)鐘盒接頭沒有接好，則接好接頭。

3.Configuration error: Unit initialization failure(0012)引起原因：

1、高溫導(dǎo)致小區(qū)掛死，軟重啟后會(huì)出現(xiàn)此告警

2、高溫導(dǎo)致基站自動(dòng)重啟出現(xiàn)此告警 處理發(fā)法：

1、高溫引起，基站要降溫并重啟BBU。

2、重新COMISSION基站，即重新把基站的集成文件（SCFC）和傳輸文件（Config）重新傳入BBU內(nèi)，重啟后一般可以恢復(fù)正常。4.Configuration error: Not enough HW for LCR(1868)引起原因：以3小區(qū)基站配置來說明，由于集成文件已經(jīng)配置好了，若是某一小區(qū)丟失或兩個(gè)、三個(gè)小區(qū)的RRU都識(shí)別不到，則會(huì)出現(xiàn)此告警。

1、高溫導(dǎo)致光模塊過熱，跟光纖的連接中斷

2、光纖沒有插好

3、光纖斷了

4、RRU壞了

5、SCFC文件配置有問題 處理方法：

1、高溫引起，基站要降溫并重啟BBU。

2、將光纖拔下來，重新插好

3、更換損壞的光纖

4、更換RRU

5、重新配置SCFC文件，如果是二小區(qū)的基站，不能將SCFC文件做成三小區(qū)的配置，否則也會(huì)出此告警。

5.Configuration error: Power level not supported(4008)引起原因：

1、BBU上的FSMF到FBBA之間的電源連接線沒有插好，導(dǎo)致供電不足

2、BBU自身的問題 處理方法：

1、重新拔插這些電源線，使之接觸正常

2、說是BBU自身的問題，則是有些可以不用拔插，直接重啟基站就可以解決此問題。

6.Cell configuration data distribution failed(6253)引起原因：

基站運(yùn)行一段時(shí)間由于自身問題導(dǎo)致，在此也說不清楚為什么會(huì)出現(xiàn)此問題，最大的可能性就是BBU加載好的文件一般存儲(chǔ)在它的FLASH芯片里面，運(yùn)行一段時(shí)間后文件出錯(cuò)，未能成功讀取到SCFC文件，導(dǎo)致基站出現(xiàn)此告警

處理方法：

由于重啟基站后此問題即可消失，所以一般處理的方式為重啟基站，在重啟的過程中，基站會(huì)重新讀取索引目錄Filedirectory，重新加載基站的配置文件，此過程會(huì)擦除原先在Flasn里面的數(shù)據(jù)，這樣基站就能正常工作了。7.Failure in optical RP3 interface(4064)引起原因：

1、光模塊損壞導(dǎo)致輔口讀不到光纖消息

2、溫度過高，導(dǎo)致輔口光模塊故障，讀取不到光纖消息

3、輔口的光纖斷了 處理方法：

1、更換輔口的光模塊，問題得到解決

2、下電直接重啟，或是下電后將光模塊拔出，冷卻一陣再插入卡槽內(nèi)，加好光纖，加電起來后此告警消失

3、光纖損壞導(dǎo)致此問題，需要更換光纖，此問題最為麻煩，需要工程隊(duì)配合，一般更換光纖后都能好（前提是把1、2都做過一遍了，告警得不到解決的情況下，更換光纖）。

8.Failure in optical RP3 interface(0010)引起原因：

1、高溫導(dǎo)致小區(qū)兩光纖傳輸中斷，BBU讀不到RRU消息

2、高溫導(dǎo)致小區(qū)兩光模塊出現(xiàn)問題

處理方法：

此問題處理的方法一般為下點(diǎn)重啟，問題都可以得到解決，但是如果機(jī)房或者綜合柜的溫度還是很高的話，過不了多久，大概10分鐘左右，此告警還會(huì)出現(xiàn)，所以需要做的是打開綜合柜的門，進(jìn)行散熱處理，或是增加空調(diào)設(shè)備，降低室內(nèi)溫度，如果基站在室外，則沒有什么好的辦法，只能將BBU拿出來，放在綜合柜外面。

9.Baseband bus failure(3020,1906)引起原因：

1、BUS線沒有插好

2、BBU內(nèi)部主板的問題 處理方法：

1、重新拔插BUS線，使之連接正常

2、BBU內(nèi)部主板的問題有的可以通過下電重啟解決此問題，但是有的只能更換BBU，此問題才能得到解決。

10.RF module failure(6259，1911、1711、1712)引起原因：

1、光模塊損壞導(dǎo)致

2、RRU出現(xiàn)故障導(dǎo)致

處理方法：

1、若是告警號(hào)為1711（主）或1712（輔），則分別更換主輔側(cè)的光模塊即可解決問題。

2、告警號(hào)為1911或者是6259的時(shí)候，則需要更換RRU，一般都可以解決此類故障。

11.Cell power failure(4090)引起原因：

1、高溫導(dǎo)致供給FBBA的電流減少，導(dǎo)致功率不足

2、Vendor文件不匹配 處理方法：

1、高溫引起，基站要降溫并重啟BBU

2、更換跟天線匹配的正確的Vendor文件

12.GPS Receiver alarm: Control Interface not available（4011）

引起原因：

GPS時(shí)鐘盒工作不正常

處理方法：

1、重啟時(shí)鐘盒

2、拔插連接BBU和時(shí)鐘盒的時(shí)鐘線

13.X2 interface setup failure（6304）

引起原因：

X2鏈路連接建立失敗，需要建立X2鏈路連接

處理方法：

1、如果鄰基站存在，則鄰基站好了以后，此告警自然消失

2、如果鄰基站不存在，則需要在鄰區(qū)關(guān)系表里面講此鏈路的連接配置刪除，既可以消除此告警。

14.Transport layer connection failure in X2 interface 引起原因：

鄰小區(qū)沒有Onair,即基站未能正常起來工作 處理方法：

1、刪除鄰區(qū)關(guān)系

2、是鄰小區(qū)正常工作

15.Failure in replaceable baseband unit 引起原因：

1、FSMF和FBBA之間連接不好導(dǎo)致

2、FBBA硬件問題 處理方法：

1、重啟BBU

2、檢查FSMF和FBBA之間的連線

3、更換FBBA板件

16.Temperature alarm(0002)引起原因：

1、機(jī)房或者綜合柜溫度過高

2、BBU風(fēng)扇轉(zhuǎn)速過快或者過慢

處理方法：

1、檢查機(jī)房空調(diào)是否正常工作，溫度是否正常。

2、檢查綜合柜是否散熱良好

3、檢查BBU的風(fēng)扇轉(zhuǎn)速是否正常，一般可以看到此類告警，若是不正常，則需要更換風(fēng)扇。

17.VSWR（1838）

引起原因：

1、RRU內(nèi)部的耦合器脫落，倒是發(fā)射端口出現(xiàn)駐波

2、天線跟BBU內(nèi)的Vendor文件不匹配，出現(xiàn)駐波

3、饋線頭子沒有做好，進(jìn)水了，出現(xiàn)駐波

4、饋線有問題，出現(xiàn)駐波

5、光模塊也會(huì)導(dǎo)致駐波（很少見，我沒見過，但是聽說過）處理方法：

1、對(duì)于RRU損壞導(dǎo)致的駐波，則更換RRU，只能如此解決

2、若是天線和Vendor文件不匹配導(dǎo)致的告警，則更換相對(duì)應(yīng)的Vendor文件

3、進(jìn)水了則需要晾干或者更換饋線

4、饋線有問題則直接更換

5、光模塊有問題，可以通過更換光模塊來解決。

18.Failure in optical RP3 interface(2004)引起原因：

1、軟件問題

2、硬件問題

處理方法：

1、更換軟件版本，此告警有的基站可以消失

2、更換硬件，此告警可以消失

對(duì)于此告警，實(shí)在是難以有一個(gè)定論，曾經(jīng)研發(fā)的人為此告警一天打了5個(gè)補(bǔ)丁還是解決不了，到現(xiàn)在也不知道怎么辦，只有不停的更換軟件包，更換硬件，更換光模塊來消除此告警。

19.GPS時(shí)鐘盒閃斷，時(shí)鐘信號(hào)不正常，無法識(shí)別RRU 正常情況下，小的時(shí)鐘盒信號(hào)燈為常綠，如果出現(xiàn)綠色指示燈不斷閃爍則GPS信號(hào)不正常。

如果燈閃的情況為一長二短，則為GPS饋線短路，如果燈閃的情況為一長一短，則為GPS饋線開路。

20.Failure in optical RP3 interface（2000）

引起原因：此告警基本是因?yàn)闇囟冗^高，但是光模塊還能工作，但又受到影響，出現(xiàn)的告警，或者是光模塊故障導(dǎo)致

解決辦法：

1、更換光模塊

2、下電重啟，若是基站處于正常溫度下，則可以保持正常，不再出此告警。

21.光纖交叉連接

對(duì)于室外型宏基站（FZHA，s111），開通后正常的FZHA的框號(hào)為1.1.1、1.3.1、1.4.1(normal FZHA rack no.png)。已發(fā)現(xiàn)有部分基站開通后的FZHA的框號(hào)為1.1.1、1.2.1、1.3.1(abnormal FZHA rack no.png)。

對(duì)于這種情況，基站無告警，但對(duì)于第一、二小區(qū)的業(yè)務(wù)測(cè)試會(huì)造成影響。原因可能是第一小區(qū)的輔光纖與第二小區(qū)的主光纖交叉錯(cuò)接。1、3、4代表主光口

22.基站始終無法建立S1連接，只到configed狀態(tài)

這種情況一般是基站發(fā)了S1連接請(qǐng)求，但是核心網(wǎng)側(cè)沒有回，在SM里面會(huì)有6308的告警（S1 interface setup failure），這個(gè)時(shí)候我們會(huì)誤認(rèn)為是核心網(wǎng)側(cè)沒有配這個(gè)站的數(shù)據(jù)或沒配對(duì)，其實(shí)核心網(wǎng)側(cè)不需要配置任何數(shù)據(jù)。所有的information都由ENB上報(bào)。下面是MME的輸出：

MCC MNCENB ID ENB IP S1 CONN AMOUNT === === ===== ======================================= 460 08 13 172.16.2.16 3 460 08 106 172.16.2.137 0 460 08 108 172.16.2.139 16 S1口通了之后，ENB正常接入網(wǎng)絡(luò)，MME側(cè)就能看見有關(guān)的信息。所以，基站側(cè)開通時(shí)，不外乎2個(gè)問題：

1.傳輸不通：需要核對(duì)傳輸側(cè)數(shù)據(jù)是否配對(duì)。比如：ENB IP地址，網(wǎng)關(guān)，S1-C控制地址，VLAN ID等。

2.傳輸通了，S1口不通：需要核對(duì)ENB側(cè) MCC,MNC,ENBID是否正確。特別是ENBID，不能與其它站沖突。截止到現(xiàn)在，99%的ENB S1口不通，是由于ENBID沖突造成的。SCTP的端口號(hào)36412如果都是諾西的設(shè)備，就不會(huì)出問題。

總之，在ENB接入EPC的過程中，MME只是起著等待接入，接入確認(rèn)的作用。

23.GPS時(shí)鐘盒閃斷，時(shí)鐘信號(hào)不正常，無法識(shí)別RRU 正常情況下，時(shí)鐘盒信號(hào)燈為常綠，如果出現(xiàn)綠色指示燈不斷閃爍則GPS信號(hào)不正常。如果燈閃的情況為一長二短，則為GPS饋線短路；如果燈閃的情況為一長一短，則為GPS饋線開路。這兩種情況一般只需重做GPS頭子就行。

還有一種情況是燈閃的時(shí)間間隔相同，則為時(shí)鐘盒模式選擇錯(cuò)誤，只需把時(shí)鐘盒上的模式開關(guān)撥到GNSS就行。

24.某一個(gè)小區(qū)的RRU無法識(shí)別

現(xiàn)象是：該小區(qū)的RRU能ping通，但是在BTSlog里面無法讀出RRU的版本，SiteManger里面也無法識(shí)別RRU。

既然小區(qū)光纖同步?jīng)]問題，而BTSlog和SM卻又同時(shí)識(shí)別不到RRU的版本，按照RL15時(shí)的經(jīng)驗(yàn)只可能是RRU的productCode丟失，所以從RRU里面，通過log –a提取RRU的log（F01_startup.zip和F01_runtime.zip），從該RRU的啟動(dòng)log里面，可以看到如圖1-1顯示的信息：

圖1-1 該小區(qū)RRU啟動(dòng)log 而正常RRU啟動(dòng)log里面，應(yīng)為如圖1-2所示的信息：

圖1-2 正常RRU啟動(dòng)log 對(duì)比可以看出，原因應(yīng)該是productCode和Serial number丟失造成。在RRU里面，使用eeprom命令，手動(dòng)寫入productCode和Serial number，重啟基站后，小區(qū)恢復(fù)正常。

25.BBU版本無法識(shí)別

BBU版本無法識(shí)別主要表現(xiàn)在SM讀到的版本為“?”，這個(gè)問題也是在1800之后出現(xiàn)的，主要是因?yàn)橥鵅BU里傳文件時(shí)出錯(cuò)引起系統(tǒng)切換，重啟后就識(shí)別不到版本了。

對(duì)此嘗試過很多手段，包括重升PS、重傳fs1、重灌基站包和重刷flash都不行。既然這個(gè)問題是系統(tǒng)切換時(shí)造成的那能不能再讓它切換一次？于是問研發(fā)要了一條關(guān)于切換的命令，具體步驟如下：

1)通過將FileDirectory里面的“?”寫回版本號(hào)，再放回flash里面 2)保證備區(qū)的FileDirectory里版本號(hào)不是“?” 3)在FCTB里執(zhí)行命令：uboot_env get，查看正在運(yùn)行的區(qū)域，如果是fs1，則執(zhí)行命令: uboot_env set active_partition=2，將系統(tǒng)切換至fs2 4)重啟BBU，重啟后一般情況下能恢復(fù)正常版本，不行的話可以再次嘗試以上方法。

26.校準(zhǔn)初步排查

如果發(fā)現(xiàn)某個(gè)小區(qū)的校準(zhǔn)有問題，比如說2小區(qū)的校準(zhǔn)有問題，那么我們更換小區(qū)110 和小區(qū)2的光纖位置（也就是OptIF1和OptIF3更換，OptIF2和OptIF6更換），看看校準(zhǔn)不好的小區(qū)是否有變化：

（1）如果校準(zhǔn)不好的小區(qū)變到了第1小區(qū)，那么可能是RRU或者射頻連線的問題（2）如果校準(zhǔn)不好的小區(qū)還是第2小區(qū)，那么可能就是eNB的問題 對(duì)于(1)類問題，我們要繼續(xù)看看是哪個(gè)path有問題，如下面的log：

AntIdx(7)值偏大，則須檢查對(duì)應(yīng)第8通道的跳線是否接好。如果所有path都不好的話，則可以嘗試sitemanager block、unblock這個(gè)小區(qū)，看是否恢復(fù)正常，如果沒有校準(zhǔn)打印，則直接重啟。以下是各個(gè)參數(shù)的定義：

Timeoff 波動(dòng)不要太大，能穩(wěn)定就可以

Ampratio 是原始天線信號(hào)計(jì)算出的天線x對(duì)參考天線的幅度比 Finalampratio 是最后ULPHY給出的調(diào)整幅度比，不會(huì)>1 Maxtxantampratio 是7組幅度比中最大值，代表了RRU 8個(gè)通道之間幅度的差異

27.本地IP地址和路由正常，ping不通MME和網(wǎng)關(guān)

先檢查光電轉(zhuǎn)換器上面是否有5個(gè)綠燈。如果電口燈未亮，檢查eNB到光電轉(zhuǎn)換器的網(wǎng)線；

如果光口燈未亮，檢查光電轉(zhuǎn)換器到PTN的光纖是否連接正確； 如果1000M燈未亮，檢查網(wǎng)線的質(zhì)量；

如果指示燈都正常的話，則致電PTN工程師核對(duì)PTN的端口和傳輸數(shù)據(jù)，尤其是VLAN和容量。

28.TRS文件始終無法生效

當(dāng)傳完fs1文件或升完級(jí)后，TRS文件在SM里始終無法sending出去，將其上傳至runfs1trs_datadb根目錄下重啟基站也不生效；

此時(shí)可以嘗試重刷PS來解決，生效后BBU上的傳輸指示燈會(huì)變綠！29.三種疑難告警

（1）Cell power failure 原因：RF received low power from BTS 解決方法：1.Check Pmax and txPowerScaling value 2.Check vendor file 3.Replace FSMF or FBBA（2）RF module failure 原因：LNA burned 解決方法：Replace RRU HW或BBU HW或FBBA（3）Baseband bus failure 原因：基帶總線配置被硬件，軟件，DSP或LTX拒絕 解決方法：更換BBU到兩塊FBBA的數(shù)據(jù)線或直接更換BBU 30.遠(yuǎn)程ping不通基站

遠(yuǎn)程ping不通有以下幾種可能：（1）網(wǎng)管IP沒配或配錯(cuò)

（2）該站之前正常，但是后來上站發(fā)現(xiàn)vlan數(shù)據(jù)又被做到PTN2-5口，導(dǎo)致遠(yuǎn)程ping不通；

（3）光電轉(zhuǎn)換器到BBU的網(wǎng)線有問題，諾西采購的這批網(wǎng)線還不如地?cái)偵腺u的靠譜，運(yùn)行一段時(shí)間后，竟然會(huì)導(dǎo)致傳輸中斷

（4）PTN上的光模塊突然之間出問題了

（5）基站正常運(yùn)行一段時(shí)間后TRS文件丟失（6）PTN被托管了

（7）機(jī)房斷電、BBU或光電轉(zhuǎn)換器被下電

以上可能大多數(shù)都需去現(xiàn)場(chǎng)結(jié)合實(shí)際情況來判斷，并采取相應(yīng)的解決方法！

31.風(fēng)扇告警

風(fēng)扇告警可能是風(fēng)扇過速、低速或不轉(zhuǎn)，一半是風(fēng)扇本身的問題，可以通過更換風(fēng)扇來解決，一半是由于BBU出了問題，而不轉(zhuǎn)也可能是因?yàn)轱L(fēng)扇電源未插好。

另外有些風(fēng)扇告警時(shí)有時(shí)無，需結(jié)合實(shí)際情況來判斷。

32.BTSlog有l(wèi)ink消息，但是pinger始終不亮

這個(gè)問題在18630版本下很常見，據(jù)說是因?yàn)樵摪姹緦?duì)光口質(zhì)量要求高，因?yàn)槲以囘^將版本降到16200時(shí)問題就消失了，升上來后又復(fù)現(xiàn)了，解決方法如下：

（1）整站下電（2）更換光模塊

（3）單獨(dú)上電問題小區(qū)

（4）將問題小區(qū)一根光纖拔掉 33.駐波問題

駐波問題很常見，主要有以下幾種：

（1）跳線未插或未插好

（2）RRU耦合器脫落，導(dǎo)致駐波固定在RRU某一通道（3）天線問題

（4）Vendor文件沒有和天線型號(hào)對(duì)應(yīng)

SM里面顯示的某通道駐波比告警是指RRU上對(duì)應(yīng)的某通道，不是天線的，而校準(zhǔn)+1則和RRU對(duì)應(yīng)！

34.pinger正常，但是SM里小區(qū)顯示橙黃色告警

岳峰鎮(zhèn)臺(tái)中這個(gè)站之前很正常，運(yùn)行一段時(shí)間后二小區(qū)無法識(shí)別，遠(yuǎn)程重啟基站后該小區(qū)報(bào)4064告警。

上站下電重啟基站后該小區(qū)光纖同步正常，但是SM里小區(qū)顯示橙黃色告警，更換BBU側(cè)光模塊后問題依舊，最后更換RRU側(cè)光模塊問題解決。

35.幾個(gè)特列

（1）金榜食府->溫度告警->整站掛掉 :溫度過高會(huì)導(dǎo)致光口異常，小區(qū)退服；

（2）傳輸數(shù)據(jù)做好后，PTN網(wǎng)管確認(rèn)vlan、ip也添加了，但是就是ping不通網(wǎng)關(guān)：后來才知道對(duì)應(yīng)的網(wǎng)關(guān)沒添加；

（3）有個(gè)小區(qū)始終不報(bào)link消息：后來發(fā)現(xiàn)是RRU側(cè)光纖未插；

（4）瑯岐便攜->將BBU下電6-8分鐘后，pinger能正常識(shí)別，但是SM識(shí)別不到該小區(qū)->重啟幾次后SM能識(shí)別，但是報(bào)RP3-2000:更換光模塊后問題解決。

36.FOSI 和FOSN的光功率范圍

（1）RTXM228-601 輸出光功率:-8.2dBm~+0.5dBm（FOSN）輸入光功率：-14.4dBm~+0.5dBm（2）RTXM228-618 輸出光功率:-5.2dBm~+0.5dBm（FOSI）輸入光功率：-14.4dBm~+0.5dBm 37.不同頻段RRU類型

室分只有一種頻段：

E頻段，2.3G(6通道FZNC 和2通道FZND)宏站有兩種頻段：

F頻段，1.9G(8通道FZFA和8通道FZFD)13 D頻段，2.6G(8通道FZHA)38.MAC綁定及載波沖突

更換BBU后傳輸需在網(wǎng)管做一個(gè)MAC地址的綁定

鐵路旅社：TD第三小區(qū)11個(gè)載波，所以LTE的第三小區(qū)只能到configing狀態(tài)，到不了configed的狀態(tài)，也ONair不了！

39.傳輸不通

1，網(wǎng)管IP沒配或配錯(cuò)，按規(guī)劃重新做數(shù)據(jù)； 2，該站之前正常，但是后來上站發(fā)現(xiàn)vlan數(shù)據(jù)又被做到PTN2-5口，導(dǎo)致遠(yuǎn)程ping不通，將PTN尾纖插到正確位置；

3，光電轉(zhuǎn)換器到BBU的網(wǎng)線有問題，直接更換； 4，PTN上的光模塊出問題，直接更換；

5，基站正常運(yùn)行一段時(shí)間后TRS文件丟失，重做數(shù)據(jù)； 6，PTN被托管，聯(lián)系PTN側(cè)處理；

7，機(jī)房斷電、BBU或光電轉(zhuǎn)換器被下電、空開跳閘，上電或聯(lián)系移動(dòng)處理；

40.升級(jí)完成后出現(xiàn)駐波告警

此故障出現(xiàn)在最新升級(jí)的版本247_16，升級(jí)完成后，由于Vendor文件未能同步更新名稱，導(dǎo)致出現(xiàn)駐波，這時(shí)候就需要通過Fileziler登陸到BBU里面，將Vendor文件的后面幾位改成升級(jí)以后版本的名稱，比如說升級(jí)前，Vendor名稱為vendor_GZ818630，這時(shí)候就需要該為vendor_GZ824716。

第三篇：LTE填空題總結(jié)

3.UE通過E-UTRAN廣播消息獲取AS和NAS系統(tǒng)消息。

4、隨機(jī)接入實(shí)現(xiàn)的基本功能：申請(qǐng)上行資源、與eNodeB間的上行時(shí)間同步。

5、RLC實(shí)體傳輸數(shù)據(jù)有三種模式：透明模式（TM）、無確認(rèn)模式（UM）、確認(rèn)模式（AM）。

6、LTE測(cè)量分為3類：同頻測(cè)量(Intra frequency measurement，不需要改變收發(fā)頻率）、異頻測(cè)量(Inter frequency measurement，需要改變收發(fā)頻率）、異技術(shù)測(cè)量(Inter-RAT measurement，需要改變收發(fā)頻率）

1、室內(nèi)覆蓋指標(biāo)要求_90_%的區(qū)域達(dá)到_-105__dBm以上。

2、室內(nèi)單點(diǎn)測(cè)試中好點(diǎn)下行測(cè)試要求TM3達(dá)到_50__Mbps，TM1達(dá)到__35__Mbps。

3、室內(nèi)信號(hào)泄漏到室外指標(biāo)要求為__建筑物外10m要求滿足室外室內(nèi)信號(hào)

比>10dB,或者室內(nèi)信號(hào)<-110dBm __。

4、室內(nèi)小區(qū)基本參數(shù)核查包括__PCI、頻點(diǎn)、BW、子幀配置、天線間距、CELL ID、eNB ID、TAC等____。

5、子幀配置1的上下行時(shí)隙配置為__DSUUD___。

1.CMCC測(cè)試規(guī)范規(guī)定，計(jì)算賦型增益時(shí)需要用到的數(shù)據(jù)有CRS RSRP和DRS RSRP

2.中移動(dòng)TD-LTE試驗(yàn)局要求默認(rèn)采用上下行配置 1，特殊子幀配置 7

3.目前TD-LTE所用的頻段為 Band 38 和Band 40。

1.無線網(wǎng)絡(luò)規(guī)劃結(jié)束后應(yīng)輸出文檔

2.OFDMA從頻域?qū)d波資源劃分成多個(gè)正交的載波，小區(qū)內(nèi)間無干擾，同頻組網(wǎng)時(shí)，不同小區(qū)使用相同時(shí)頻資源，存在小區(qū)間干擾。

3.影響小區(qū)吞吐量主要因素有，發(fā)射功率，其它

4.鏈路預(yù)算包括上下鏈路的發(fā)射機(jī)的各項(xiàng)和損耗，接收機(jī)的各項(xiàng)增益和損耗，以及各項(xiàng)增益和最大路徑損耗

5.PDSCH信道的TM3模式在信道質(zhì)量好的時(shí)候?yàn)?，信道質(zhì)量差的時(shí)

候回落到單流波束賦型。

6.LTE組網(wǎng)中，如果采用室外D頻段組網(wǎng)，一般使用的時(shí)隙配比為，特

殊時(shí)隙配比為10:2:2；如果采用室外F頻段組網(wǎng)，一般使用的時(shí)隙配比為3:1:1，特殊時(shí)隙配比為3:9:2。

第四篇：LTE學(xué)習(xí)總結(jié)-速率問題定位(前臺(tái))

速率不達(dá)標(biāo)問題分析（前臺(tái)）

測(cè)試中問題定位

測(cè)試時(shí)發(fā)現(xiàn)下載速率不達(dá)標(biāo)需關(guān)注項(xiàng)：

1、RSRP（參考信號(hào)接收功率）

在LTE中表示接收信號(hào)強(qiáng)度，測(cè)試時(shí)一般要求達(dá)到-75dBm.如達(dá)不到需重新找點(diǎn)，則要求RSRP盡量大于-85dBm。找點(diǎn)時(shí)最好在天線主打方向無阻擋位置。

主要用來衡量下行參考信號(hào)的功率，和WCDMA中CPICH的RSCP作用類似，可以用來衡量下行的覆蓋。區(qū)別在于協(xié)議規(guī)定RSRP指的是每RE的能量，這點(diǎn)和RSCP指的是全帶寬能量有些差別。

2、SINR（信干噪比）

表示LTE中的信號(hào)質(zhì)量，好點(diǎn)要求大于22。是對(duì)速率影響最大的因素。

若RSRP大于-85dBm而SINR不達(dá)標(biāo)，則看鄰區(qū)列表內(nèi)鄰區(qū)信息，看是否有較強(qiáng)鄰區(qū)信號(hào)干擾，若有的話，可以通知后臺(tái)閉塞鄰區(qū)或本站其他小區(qū)后測(cè)試。

3、Transmission傳輸模式

傳輸模式現(xiàn)在用的有TM2（發(fā)射分集）、TM3（開環(huán)空間復(fù)用）、TM7（單流波束賦形）、TM8（雙流波束賦形）。一般測(cè)試時(shí)好點(diǎn)都為TM3.如果在TM2可能為無線環(huán)境不好，在TM7或TM8可能雖然RSRP和SINR都好但不在天線主打方向（站下小區(qū)背后或小區(qū)副瓣方向）。

4、PDCCH ULDL Grant Count（上下調(diào)度次數(shù)）

LTE每秒調(diào)度次數(shù)，由于調(diào)度周期為1MS，所以調(diào)度次數(shù)為每秒1000次，正常情況下單用戶調(diào)度次數(shù)都要在900以上。

5、BLER（誤碼率）

正常情況下為10%以下，如果RSRP大于80dBm并且SINR大于22情況下BLER大于10%，則很有可能是外部干擾，可以讓后臺(tái)看一下底噪和上下行干擾。

6、Rank Indication（秩指示）

正常情況下好點(diǎn)都應(yīng)該為Rank2（雙流）狀態(tài)。如果RSRP大于80dBm并且SINR大于22還在Rank1（單流）狀態(tài)，有可能是天線問題（天線不支持雙流）或傳輸問題。

7、PDSCHPUSCH RB Number(下上行可用RB數(shù))

8、Antenna Measurement（天線端口測(cè)量）

9、MCS（調(diào)制階數(shù)）

9、MIMO（多發(fā)多收）

第五篇：重大故障及用戶投訴處理辦法

項(xiàng)目重大故障及用戶投訴處理辦法

北京神州泰岳軟件股份有限公司

項(xiàng)目重大故障及用戶投訴處理辦法 總則

為加大管理力度，提高項(xiàng)目實(shí)施與維護(hù)工作的流程化和規(guī)范化，控制和減少各類項(xiàng)目事故和用戶投訴的發(fā)生，保證項(xiàng)目質(zhì)量，提升用戶滿意度，樹立公司良好的用戶形象，公司決定下發(fā)項(xiàng)目重大故障及用戶投訴處罰管理辦法，要求公司各事業(yè)部、各大區(qū)與分公司學(xué)習(xí)和貫徹執(zhí)行。關(guān)于項(xiàng)目故障和用戶投訴的級(jí)別

關(guān)于項(xiàng)目故障和用戶投訴的級(jí)別，分為以下五級(jí)：

1.用戶通報(bào)：指在用戶內(nèi)部公司層面進(jìn)行公開通報(bào)。

2.重大投訴：指用戶內(nèi)部雖未公開通報(bào)，但用戶向公司領(lǐng)導(dǎo)層進(jìn)行書面或口頭投訴、或者用戶向銷售、項(xiàng)目管理部和大區(qū)總經(jīng)理進(jìn)行書面投訴。

3.一般投訴：指用戶內(nèi)部雖未公開通報(bào)，但用戶直接向銷售、項(xiàng)目管理部和大區(qū)總經(jīng)理進(jìn)行口頭投訴。

4.內(nèi)部一級(jí)故障：指用戶雖未投訴，但造成用戶核心業(yè)務(wù)受到影響30分鐘以上（含30分鐘），包括用戶業(yè)務(wù)中斷、計(jì)費(fèi)損失、重大保障不力和重大財(cái)產(chǎn)損失等。

5.內(nèi)部二級(jí)故障：指用戶雖未投訴，但造成用戶業(yè)務(wù)受到影響而影響范圍在30分鐘以下或用戶業(yè)務(wù)雖未受到影響但自身系統(tǒng)宕機(jī)或中斷服務(wù)2小時(shí)以上的（含2小時(shí)）或公司資產(chǎn)受到重大損失或者項(xiàng)目上線后系統(tǒng)中重復(fù)發(fā)生宕機(jī)、中斷服務(wù)不足2小時(shí)的重大故障。關(guān)于項(xiàng)目故障的責(zé)任認(rèn)定

關(guān)于項(xiàng)目故障的責(zé)任認(rèn)定，分為以下五種 項(xiàng)目重大故障及用戶投訴處理辦法

北京神州泰岳軟件股份有限公司

1.低級(jí)失誤：造成項(xiàng)目故障的原因在于責(zé)任人的操作失誤或過失。2.管理問題：造成項(xiàng)目故障的原因在于責(zé)任人不遵守公司、部門和項(xiàng)目組的各類管理規(guī)范。

3.實(shí)施設(shè)計(jì)問題：造成項(xiàng)目故障的原因在于項(xiàng)目組的實(shí)施或設(shè)計(jì)方案（合同方案存在問題暫不屬于項(xiàng)目組責(zé)任，但項(xiàng)目組有識(shí)別合同技術(shù)方案是否存在問題的責(zé)任和義務(wù)）。

4.產(chǎn)品問題：造成項(xiàng)目故障的原因在于項(xiàng)目中公司產(chǎn)品或第三方產(chǎn)品、設(shè)備自身存在問題，但當(dāng)事人響應(yīng)處理不及時(shí)、不到位。5.第三方因素：造成項(xiàng)目故障原因的在于第三方，但當(dāng)事人響應(yīng)處理不及時(shí)、不到位。關(guān)于用戶投訴的原因

關(guān)于用戶投訴的原因，分為以下五種：

1.項(xiàng)目故障：由于項(xiàng)目出現(xiàn)故障導(dǎo)致用戶投訴，而故障的責(zé)任認(rèn)定見第三部分的四類責(zé)任定義。

2.項(xiàng)目進(jìn)度：由于項(xiàng)目進(jìn)度存在問題導(dǎo)致用戶投訴。3.項(xiàng)目質(zhì)量：由于項(xiàng)目質(zhì)量存在問題導(dǎo)致用戶投訴。

4.項(xiàng)目管理能力和水平：由于項(xiàng)目管理能力和水平的問題導(dǎo)致用戶投訴。

5.項(xiàng)目組服務(wù)態(tài)度和水平：由于項(xiàng)目組服務(wù)態(tài)度和水平的問題導(dǎo)致用戶投訴。關(guān)于項(xiàng)目故障和用戶投訴的通報(bào)機(jī)制

1.責(zé)任人（或第一知曉人）應(yīng)在發(fā)現(xiàn)后第一時(shí)間立即通知項(xiàng)目經(jīng)理（或維護(hù)類項(xiàng)目維護(hù)負(fù)責(zé)人，本辦法中提到的項(xiàng)目經(jīng)理統(tǒng)指項(xiàng)目經(jīng)理或維護(hù)類項(xiàng)目維護(hù)負(fù)責(zé)人）。

2.項(xiàng)目經(jīng)理在得知事件后應(yīng)第一時(shí)間立即口頭通知主管銷售和事業(yè)部技術(shù) 項(xiàng)目重大故障及用戶投訴處理辦法

北京神州泰岳軟件股份有限公司

總監(jiān)或項(xiàng)目總監(jiān)，在4個(gè)小時(shí)內(nèi)負(fù)責(zé)向主管銷售、行業(yè)經(jīng)理、部門經(jīng)理、技術(shù)總監(jiān)、公司項(xiàng)目總監(jiān)、大區(qū)項(xiàng)目總監(jiān)、項(xiàng)目管理部、大區(qū)技術(shù)總監(jiān)、大區(qū)總經(jīng)理和事業(yè)部總經(jīng)理進(jìn)行郵件通報(bào)事故概況，并電話通知部門經(jīng)理和行業(yè)經(jīng)理。

3.對(duì)于除內(nèi)部一般事故外的其他性質(zhì)的項(xiàng)目事故，由技術(shù)總監(jiān)或項(xiàng)目總監(jiān)負(fù)責(zé)立即向公司CSO和CTO進(jìn)行口頭和郵件上報(bào)。

4.由銷售受理的用戶投訴，需及時(shí)通知項(xiàng)目經(jīng)理進(jìn)行跟進(jìn)處理，并通知事業(yè)部主管項(xiàng)目領(lǐng)導(dǎo)和項(xiàng)目管理部。

5.由項(xiàng)目管理部受理的用戶投訴，需及時(shí)通知項(xiàng)目經(jīng)理、銷售和事業(yè)部主管項(xiàng)目領(lǐng)導(dǎo)，由項(xiàng)目經(jīng)理跟進(jìn)處理。

6.由大區(qū)總經(jīng)理受理的用戶投訴，需及時(shí)通知主管銷售，由主管銷售及時(shí)通知項(xiàng)目經(jīng)理、銷售和事業(yè)部主管項(xiàng)目領(lǐng)導(dǎo)，由項(xiàng)目經(jīng)理跟進(jìn)處理，處理結(jié)果要上報(bào)大區(qū)總經(jīng)理。

7.由公司領(lǐng)導(dǎo)層受理的用戶投訴，可由公司領(lǐng)導(dǎo)層通知項(xiàng)目管理部，由項(xiàng)目管理部負(fù)責(zé)通知項(xiàng)目經(jīng)理、主管銷售和事業(yè)部總經(jīng)理進(jìn)行跟蹤處理，處理結(jié)果要上報(bào)公司領(lǐng)導(dǎo)。關(guān)于項(xiàng)目故障和用戶投訴的處理機(jī)制

1.項(xiàng)目經(jīng)理為事故處理的第一責(zé)任人，由項(xiàng)目經(jīng)理組織協(xié)調(diào)相關(guān)人員進(jìn)行跟蹤處理：控制事故影響，恢復(fù)受損系統(tǒng)和業(yè)務(wù)，最后進(jìn)行事故分析、處理、匯報(bào)和總結(jié)。

2.項(xiàng)目經(jīng)理需要會(huì)同項(xiàng)目組和事業(yè)部分析事故原因，給出解決辦法、后續(xù)避免措施和本次事故的處理決定，生成故障分析報(bào)告。

3.故障分析報(bào)告報(bào)主管銷售和項(xiàng)目總監(jiān)（技術(shù)總監(jiān)）協(xié)商確定；對(duì)于用戶通報(bào)類事故和重大投訴，向用戶提交的故障分析報(bào)告，需郵件向事業(yè)部總經(jīng)理和公司CTO報(bào)批，并同時(shí)口頭通知。

4.項(xiàng)目故障分析報(bào)告經(jīng)審批后，由項(xiàng)目經(jīng)理和主管銷售向用戶進(jìn)行書面回復(fù)和正式口頭匯報(bào)。項(xiàng)目重大故障及用戶投訴處理辦法

北京神州泰岳軟件股份有限公司

5.由項(xiàng)目經(jīng)理協(xié)調(diào)項(xiàng)目組總結(jié)故障原因與處理過程，形成項(xiàng)目事故案例庫，上報(bào)給事業(yè)部質(zhì)管部門。

6.事業(yè)部質(zhì)管部門審定后向事業(yè)部內(nèi)部進(jìn)行全員發(fā)布，并把事故案例上報(bào)項(xiàng)目管理部。

7.項(xiàng)目管理部根據(jù)案例特點(diǎn)選擇定向或向公司范圍進(jìn)行事故案例發(fā)布（發(fā)布案例的用戶名、責(zé)任人等匿名處理），并由項(xiàng)目管理部整理匯總形成公司事故案例庫。其中對(duì)于涉及公司產(chǎn)品問題，由項(xiàng)目管理部向產(chǎn)品管理及公共研發(fā)部進(jìn)行通報(bào)。關(guān)于項(xiàng)目故障和用戶投訴的處罰辦法

7.1 處罰原則

1.差異化原則：依據(jù)故障級(jí)別和責(zé)任認(rèn)定、投訴內(nèi)容進(jìn)行差異化處罰。其中：針對(duì)投訴內(nèi)容不是“項(xiàng)目故障”的用戶一般投訴，如果用戶不做處罰的明確要求，第一次公司內(nèi)部不做罰款處理，如果同一項(xiàng)目組再發(fā)生同類投訴則進(jìn)行罰款處理。

2.責(zé)任共擔(dān)原則：與項(xiàng)目事故和用戶投訴相關(guān)的項(xiàng)目組和事業(yè)部人員或大區(qū)人員責(zé)任共擔(dān)，依當(dāng)事責(zé)任人歸屬技術(shù)事業(yè)部或大區(qū)進(jìn)行責(zé)任共擔(dān)，涉及人員包括：

1)相關(guān)當(dāng)事人（歸屬事業(yè)部）→項(xiàng)目經(jīng)理→事業(yè)部部二級(jí)部門經(jīng)理（含行業(yè)經(jīng)理）→部門技術(shù)總監(jiān)（含項(xiàng)目總監(jiān)）

2)相關(guān)當(dāng)事人（歸屬大區(qū)）→項(xiàng)目經(jīng)理→大區(qū)技術(shù)經(jīng)理。

3.同類事故性質(zhì)加罰原則：對(duì)于在公司事故案例庫內(nèi)發(fā)布的事故，如果重復(fù)發(fā)生處罰力度加罰一倍。

4.瞞報(bào)或不及時(shí)上報(bào)加重處罰原則：對(duì)于事故責(zé)任人和項(xiàng)目經(jīng)理發(fā)生瞞報(bào)或不及時(shí)上報(bào)事故的，按照最高處罰標(biāo)準(zhǔn)進(jìn)行處罰（即故障等級(jí)認(rèn)定為由于低級(jí)錯(cuò)誤導(dǎo)致的用戶通報(bào)）。

5.項(xiàng)目經(jīng)理崗位津貼罰沒原則：依據(jù)故障級(jí)別和責(zé)任認(rèn)定、投訴內(nèi)容，決 項(xiàng)目重大故障及用戶投訴處理辦法

北京神州泰岳軟件股份有限公司

定事故或用戶投訴發(fā)生當(dāng)月項(xiàng)目經(jīng)理津貼是否罰沒，如果需要罰沒但當(dāng)月已發(fā)的，則下月項(xiàng)目經(jīng)理崗位津貼罰沒（屬于補(bǔ)罰）。

6.當(dāng)事人與項(xiàng)目經(jīng)理當(dāng)期績效降級(jí)或限級(jí)原則：依據(jù)故障級(jí)別和責(zé)任認(rèn)定、投訴內(nèi)容，對(duì)當(dāng)事人及項(xiàng)目經(jīng)理的當(dāng)期績效進(jìn)行降級(jí)或限級(jí)。7.降低項(xiàng)目獎(jiǎng)金標(biāo)準(zhǔn)原則：依據(jù)故障級(jí)別和責(zé)任認(rèn)定、投訴內(nèi)容，降低該項(xiàng)目項(xiàng)目獎(jiǎng)金的標(biāo)準(zhǔn)。

8.累加原則：罰款和降低項(xiàng)目獎(jiǎng)金標(biāo)準(zhǔn)的額度按照事故和用戶投訴發(fā)生次數(shù)進(jìn)行累加計(jì)算。

7.2 處罰標(biāo)準(zhǔn)

依據(jù)故障級(jí)別和責(zé)任認(rèn)定、用戶投訴內(nèi)容決定責(zé)任人、項(xiàng)目經(jīng)理、二級(jí)部門經(jīng)理（含行業(yè)經(jīng)理或大區(qū)技術(shù)經(jīng)理）、部門技術(shù)總監(jiān)（含項(xiàng)目總監(jiān)）的處罰決定以及項(xiàng)目經(jīng)理崗位津貼是否罰沒、項(xiàng)目獎(jiǎng)金基準(zhǔn)折扣、當(dāng)事人的績效評(píng)定和事故通報(bào)范圍等，具體處罰標(biāo)準(zhǔn)詳見下表（附件：項(xiàng)目重大故障及用戶投訴處罰標(biāo)準(zhǔn).xlsx）。項(xiàng)目重大故障及用戶投訴處理辦法

北京神州泰岳軟件股份有限公司

7.3 處罰執(zhí)行機(jī)構(gòu)

1.罰款：由事業(yè)部、大區(qū)和項(xiàng)目管理部聯(lián)合執(zhí)行。

1)由主管項(xiàng)目的事業(yè)部領(lǐng)導(dǎo)制定事業(yè)部內(nèi)受罰當(dāng)事人的罰款結(jié)果，涉及用戶通報(bào)和重大投訴的處罰決定事業(yè)部需要與主管銷售、公司CTO進(jìn)行溝通確定，然后郵件通知當(dāng)事人和項(xiàng)目管理部；由大區(qū)技術(shù)總監(jiān)制定大區(qū)內(nèi)受罰當(dāng)事人的罰款結(jié)果，涉及用戶通報(bào)和重大投訴的處罰決定需要與主管銷售、公司CTO進(jìn)行溝通確定，然后郵件通知當(dāng)事人和項(xiàng)目管理部。

2)當(dāng)事人到項(xiàng)目管理部進(jìn)行書面簽字或?qū)μ幜P結(jié)果進(jìn)行郵件確認(rèn)（如果事業(yè)部或大區(qū)發(fā)出處罰郵件通知單后7個(gè)工作日內(nèi)當(dāng)事人不做郵件回復(fù)視作同意處罰決定），如果當(dāng)事人不接受，可向事業(yè)部、大區(qū)或項(xiàng)目管理部提出郵件上訴，由事業(yè)部主管領(lǐng)導(dǎo)、大區(qū)技術(shù)總監(jiān)和項(xiàng)目管理部協(xié)調(diào)處理。

3)項(xiàng)目管理部按月把處罰結(jié)果匯總報(bào)人力資源部執(zhí)行。

2.通報(bào)：公司范圍由項(xiàng)目管理部負(fù)責(zé)；事業(yè)部范圍由事業(yè)部主管項(xiàng)目副總負(fù)責(zé)。項(xiàng)目重大故障及用戶投訴處理辦法

北京神州泰岳軟件股份有限公司 名詞釋義

1.第一時(shí)間：含義為“從時(shí)間序列看為知道情況后的下一個(gè)動(dòng)作（除非下一個(gè)動(dòng)作能夠立即避免故障影響擴(kuò)大化）”。例如故障發(fā)生在凌晨2:00，甚至2:01就應(yīng)該上報(bào)，而不是要等到上班時(shí)間（9:00）再上報(bào)。2.瞞報(bào)：含義是“知道故障發(fā)生，并且故障危害的容忍時(shí)間和規(guī)定的上報(bào)時(shí)限已過，而在公司知道前項(xiàng)目組還未上報(bào)”。

3.不及時(shí)：含義是“沒有在規(guī)定和容許的時(shí)限內(nèi)上報(bào)、響應(yīng)或處理”。其中：不及時(shí)上報(bào)是指：“雖在公司知道前上報(bào)，但沒有在規(guī)定和容許的時(shí)限內(nèi)上報(bào)”。生效日期

本辦法自發(fā)布之日起生效。

北京神州泰岳軟件股份有限公司

2011年