第一篇：LTE投訴故障問題總結

維護部

近期LTE故障投訴問題匯總

維護部近期多次接到4G網絡故障投訴，故障現象多為反映信號時有時無、上不了網等。現場測試發現投訴人所在地均已做LTE網絡覆蓋，已通過驗收，且日常巡檢測試覆蓋區域網絡信號強度均正常，以中關村大廈，融科資源大廈以及清華同方科技大廈,為例：

后臺查詢，該站點設備無告警、無駐波、小區配置正常、發射功率均正常，現場去測試，2G信號，TD信號都沒有問題，分布完好。

現場使用電腦終端測試，發現投訴和其他站點投訴類型相同，均由如下兩種情況導致：

1）:現場確實測不到LTE信號，或者時有時無，可能接收到室外大站信號。如圖通過后臺，要求將該站點所有RU重啟，15分鐘之后，信號都恢復，手機使用也正常。

編寫部門：維護部

第1頁

共3頁

日期：2014-7-16

維護部

編寫部門：維護部

第2頁

共3頁

日期：2014-7-16

維護部

2）現場用LTE終端測試，信號，場強，速率都正常，但是投訴人的手機在3G或2G網絡上面，一直切不到4G網絡。將投訴人手機重啟之后，恢復正常。手動選擇網絡-China Mobile.移動4G現處于建設期，目前的完善程度并不是很高，在正常通話時，網絡會切換到2G網絡，來完成語音通信，通話結束后，再次恢復到4G網絡，但并不是直接就恢復到4G，而是先會跳轉至2G網，再恢復3G，最后跳至4G，整個過程基本需要2-3分鐘，或者更久，甚至直接一直保持在2G或3G網絡上面，從而造成客戶通話后使用不了LTE網絡，最后導致用戶的投訴。

編寫部門：維護部

第3頁

共3頁

日期：2014-7-16

第二篇：LTE常見故障總結

LTE-FZHA（RL25）常見故障總結

目錄

LTE-FZHA（RL25）常見故障總結............................................................................................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時鐘盒閃斷，時鐘信號不正常，無法識別RRU...............................................8 20.Failure in optical RP3 interface（2000）.....................................................................8 21.光纖交叉連接..............................................................................................................8 22.基站始終無法建立S1連接，只到configed狀態....................................................9 23.GPS時鐘盒閃斷，時鐘信號不正常，無法識別RRU...............................................9 24.某一個小區的RRU無法識別.....................................................................................9 25.BBU版本無法識別....................................................................................................10 26.校準初步排查............................................................................................................10 27.本地IP地址和路由正常，ping不通MME和網關................................................11 28.TRS文件始終無法生效.............................................................................................11 29.三種疑難告警............................................................................................................12 30.遠程ping不通基站...................................................................................................12 31.風扇告警....................................................................................................................12 32.BTSlog有link消息，但是pinger始終不亮............................................................12 33.駐波問題....................................................................................................................13 34.pinger正常，但是SM里小區顯示橙黃色告警.....................................................13 35.幾個特列....................................................................................................................13 36.FOSI 和FOSN的光功率范圍....................................................................................13 37.不同頻段RRU類型...................................................................................................13 1 38.MAC綁定及載波沖突...............................................................................................14 39.傳輸不通....................................................................................................................14 40.升級完成后出現駐波告警........................................................................................14 1.System module failure(0010)引起原因：

由于天氣溫度過高或者機房溫度過高，導致BBU的熱量散發不出去，引起的告警，一般表現是第三小區掛死，嚴重的可能會整站掛死，甚至會燒壞BBU。抑或是光模塊出現問題導致出現此告警。處理方法：

1、由于是高溫引起，基站要降溫并重啟BBU.若是BBU長期處于高溫狀態，會導致BBU內部的芯片燒壞，到最后只能替換BBU

2、若是因為光模塊導致，則可以更換光模塊，則可以解決此問題。

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

1、高溫導致比較常見，由于高溫時間過長，光模塊過熱，導致BBU和RRU失去連接，而后會出現此告警。

2、時鐘盒出現故障。

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

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

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

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

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

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

1、高溫導致小區掛死，軟重啟后會出現此告警

2、高溫導致基站自動重啟出現此告警 處理發法：

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

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

1、高溫導致光模塊過熱，跟光纖的連接中斷

2、光纖沒有插好

3、光纖斷了

4、RRU壞了

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

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

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

3、更換損壞的光纖

4、更換RRU

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

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

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

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

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

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

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

基站運行一段時間由于自身問題導致，在此也說不清楚為什么會出現此問題，最大的可能性就是BBU加載好的文件一般存儲在它的FLASH芯片里面，運行一段時間后文件出錯，未能成功讀取到SCFC文件，導致基站出現此告警

處理方法：

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

1、光模塊損壞導致輔口讀不到光纖消息

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

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

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

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

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

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

1、高溫導致小區兩光纖傳輸中斷，BBU讀不到RRU消息

2、高溫導致小區兩光模塊出現問題

處理方法：

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

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

1、BUS線沒有插好

2、BBU內部主板的問題 處理方法：

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

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

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

1、光模塊損壞導致

2、RRU出現故障導致

處理方法：

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

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

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

1、高溫導致供給FBBA的電流減少，導致功率不足

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

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

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

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

引起原因：

GPS時鐘盒工作不正常

處理方法：

1、重啟時鐘盒

2、拔插連接BBU和時鐘盒的時鐘線

13.X2 interface setup failure（6304）

引起原因：

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

處理方法：

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

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

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

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

1、刪除鄰區關系

2、是鄰小區正常工作

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

1、FSMF和FBBA之間連接不好導致

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

1、重啟BBU

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

3、更換FBBA板件

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

1、機房或者綜合柜溫度過高

2、BBU風扇轉速過快或者過慢

處理方法：

1、檢查機房空調是否正常工作，溫度是否正常。

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

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

17.VSWR（1838）

引起原因：

1、RRU內部的耦合器脫落，倒是發射端口出現駐波

2、天線跟BBU內的Vendor文件不匹配，出現駐波

3、饋線頭子沒有做好，進水了，出現駐波

4、饋線有問題，出現駐波

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

1、對于RRU損壞導致的駐波，則更換RRU，只能如此解決

2、若是天線和Vendor文件不匹配導致的告警，則更換相對應的Vendor文件

3、進水了則需要晾干或者更換饋線

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

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

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

1、軟件問題

2、硬件問題

處理方法：

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

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

對于此告警，實在是難以有一個定論，曾經研發的人為此告警一天打了5個補丁還是解決不了，到現在也不知道怎么辦，只有不停的更換軟件包，更換硬件，更換光模塊來消除此告警。

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

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

20.Failure in optical RP3 interface（2000）

引起原因：此告警基本是因為溫度過高，但是光模塊還能工作，但又受到影響，出現的告警，或者是光模塊故障導致

解決辦法：

1、更換光模塊

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

21.光纖交叉連接

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

對于這種情況，基站無告警，但對于第一、二小區的業務測試會造成影響。原因可能是第一小區的輔光纖與第二小區的主光纖交叉錯接。1、3、4代表主光口

22.基站始終無法建立S1連接，只到configed狀態

這種情況一般是基站發了S1連接請求，但是核心網側沒有回，在SM里面會有6308的告警（S1 interface setup failure），這個時候我們會誤認為是核心網側沒有配這個站的數據或沒配對，其實核心網側不需要配置任何數據。所有的information都由ENB上報。下面是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正常接入網絡，MME側就能看見有關的信息。所以，基站側開通時，不外乎2個問題：

1.傳輸不通：需要核對傳輸側數據是否配對。比如：ENB IP地址，網關，S1-C控制地址，VLAN ID等。

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

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

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

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

24.某一個小區的RRU無法識別

現象是：該小區的RRU能ping通，但是在BTSlog里面無法讀出RRU的版本，SiteManger里面也無法識別RRU。

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

圖1-1 該小區RRU啟動log 而正常RRU啟動log里面，應為如圖1-2所示的信息：

圖1-2 正常RRU啟動log 對比可以看出，原因應該是productCode和Serial number丟失造成。在RRU里面，使用eeprom命令，手動寫入productCode和Serial number，重啟基站后，小區恢復正常。

25.BBU版本無法識別

BBU版本無法識別主要表現在SM讀到的版本為“?”，這個問題也是在1800之后出現的，主要是因為往BBU里傳文件時出錯引起系統切換，重啟后就識別不到版本了。

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

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

26.校準初步排查

如果發現某個小區的校準有問題，比如說2小區的校準有問題，那么我們更換小區110 和小區2的光纖位置（也就是OptIF1和OptIF3更換，OptIF2和OptIF6更換），看看校準不好的小區是否有變化：

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

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

Timeoff 波動不要太大，能穩定就可以

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

27.本地IP地址和路由正常，ping不通MME和網關

先檢查光電轉換器上面是否有5個綠燈。如果電口燈未亮，檢查eNB到光電轉換器的網線；

如果光口燈未亮，檢查光電轉換器到PTN的光纖是否連接正確； 如果1000M燈未亮，檢查網線的質量；

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

28.TRS文件始終無法生效

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

此時可以嘗試重刷PS來解決，生效后BBU上的傳輸指示燈會變綠！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的數據線或直接更換BBU 30.遠程ping不通基站

遠程ping不通有以下幾種可能：（1）網管IP沒配或配錯

（2）該站之前正常，但是后來上站發現vlan數據又被做到PTN2-5口，導致遠程ping不通；

（3）光電轉換器到BBU的網線有問題，諾西采購的這批網線還不如地攤上賣的靠譜，運行一段時間后，竟然會導致傳輸中斷

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

（5）基站正常運行一段時間后TRS文件丟失（6）PTN被托管了

（7）機房斷電、BBU或光電轉換器被下電

以上可能大多數都需去現場結合實際情況來判斷，并采取相應的解決方法！

31.風扇告警

風扇告警可能是風扇過速、低速或不轉，一半是風扇本身的問題，可以通過更換風扇來解決，一半是由于BBU出了問題，而不轉也可能是因為風扇電源未插好。

另外有些風扇告警時有時無，需結合實際情況來判斷。

32.BTSlog有link消息，但是pinger始終不亮

這個問題在18630版本下很常見，據說是因為該版本對光口質量要求高，因為我試過將版本降到16200時問題就消失了，升上來后又復現了，解決方法如下：

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

（3）單獨上電問題小區

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

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

（1）跳線未插或未插好

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

（4）Vendor文件沒有和天線型號對應

SM里面顯示的某通道駐波比告警是指RRU上對應的某通道，不是天線的，而校準+1則和RRU對應！

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

岳峰鎮臺中這個站之前很正常，運行一段時間后二小區無法識別，遠程重啟基站后該小區報4064告警。

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

35.幾個特列

（1）金榜食府->溫度告警->整站掛掉 :溫度過高會導致光口異常，小區退服；

（2）傳輸數據做好后，PTN網管確認vlan、ip也添加了，但是就是ping不通網關：后來才知道對應的網關沒添加；

（3）有個小區始終不報link消息：后來發現是RRU側光纖未插；

（4）瑯岐便攜->將BBU下電6-8分鐘后，pinger能正常識別，但是SM識別不到該小區->重啟幾次后SM能識別，但是報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后傳輸需在網管做一個MAC地址的綁定

鐵路旅社：TD第三小區11個載波，所以LTE的第三小區只能到configing狀態，到不了configed的狀態，也ONair不了！

39.傳輸不通

1，網管IP沒配或配錯，按規劃重新做數據； 2，該站之前正常，但是后來上站發現vlan數據又被做到PTN2-5口，導致遠程ping不通，將PTN尾纖插到正確位置；

3，光電轉換器到BBU的網線有問題，直接更換； 4，PTN上的光模塊出問題，直接更換；

5，基站正常運行一段時間后TRS文件丟失，重做數據； 6，PTN被托管，聯系PTN側處理；

7，機房斷電、BBU或光電轉換器被下電、空開跳閘，上電或聯系移動處理；

40.升級完成后出現駐波告警

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

第三篇：LTE填空題總結

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

4、隨機接入實現的基本功能：申請上行資源、與eNodeB間的上行時間同步。

5、RLC實體傳輸數據有三種模式：透明模式（TM）、無確認模式（UM）、確認模式（AM）。

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

1、室內覆蓋指標要求_90_%的區域達到_-105__dBm以上。

2、室內單點測試中好點下行測試要求TM3達到_50__Mbps，TM1達到__35__Mbps。

3、室內信號泄漏到室外指標要求為__建筑物外10m要求滿足室外室內信號

比>10dB,或者室內信號<-110dBm __。

4、室內小區基本參數核查包括__PCI、頻點、BW、子幀配置、天線間距、CELL ID、eNB ID、TAC等____。

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

1.CMCC測試規范規定，計算賦型增益時需要用到的數據有CRS RSRP和DRS RSRP

2.中移動TD-LTE試驗局要求默認采用上下行配置 1，特殊子幀配置 7

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

1.無線網絡規劃結束后應輸出文檔

2.OFDMA從頻域對載波資源劃分成多個正交的載波，小區內間無干擾，同頻組網時，不同小區使用相同時頻資源，存在小區間干擾。

3.影響小區吞吐量主要因素有，發射功率，其它

4.鏈路預算包括上下鏈路的發射機的各項和損耗，接收機的各項增益和損耗，以及各項增益和最大路徑損耗

5.PDSCH信道的TM3模式在信道質量好的時候為，信道質量差的時

候回落到單流波束賦型。

6.LTE組網中，如果采用室外D頻段組網，一般使用的時隙配比為，特

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

第四篇：LTE學習總結-速率問題定位(前臺)

速率不達標問題分析（前臺）

測試中問題定位

測試時發現下載速率不達標需關注項：

1、RSRP（參考信號接收功率）

在LTE中表示接收信號強度，測試時一般要求達到-75dBm.如達不到需重新找點，則要求RSRP盡量大于-85dBm。找點時最好在天線主打方向無阻擋位置。

主要用來衡量下行參考信號的功率，和WCDMA中CPICH的RSCP作用類似，可以用來衡量下行的覆蓋。區別在于協議規定RSRP指的是每RE的能量，這點和RSCP指的是全帶寬能量有些差別。

2、SINR（信干噪比）

表示LTE中的信號質量，好點要求大于22。是對速率影響最大的因素。

若RSRP大于-85dBm而SINR不達標，則看鄰區列表內鄰區信息，看是否有較強鄰區信號干擾，若有的話，可以通知后臺閉塞鄰區或本站其他小區后測試。

3、Transmission傳輸模式

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

4、PDCCH ULDL Grant Count（上下調度次數）

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

5、BLER（誤碼率）

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

6、Rank Indication（秩指示）

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

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

8、Antenna Measurement（天線端口測量）

9、MCS（調制階數）

9、MIMO（多發多收）

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

項目重大故障及用戶投訴處理辦法

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

項目重大故障及用戶投訴處理辦法 總則

為加大管理力度，提高項目實施與維護工作的流程化和規范化，控制和減少各類項目事故和用戶投訴的發生，保證項目質量，提升用戶滿意度，樹立公司良好的用戶形象，公司決定下發項目重大故障及用戶投訴處罰管理辦法，要求公司各事業部、各大區與分公司學習和貫徹執行。關于項目故障和用戶投訴的級別

關于項目故障和用戶投訴的級別，分為以下五級：

1.用戶通報：指在用戶內部公司層面進行公開通報。

2.重大投訴：指用戶內部雖未公開通報，但用戶向公司領導層進行書面或口頭投訴、或者用戶向銷售、項目管理部和大區總經理進行書面投訴。

3.一般投訴：指用戶內部雖未公開通報，但用戶直接向銷售、項目管理部和大區總經理進行口頭投訴。

4.內部一級故障：指用戶雖未投訴，但造成用戶核心業務受到影響30分鐘以上（含30分鐘），包括用戶業務中斷、計費損失、重大保障不力和重大財產損失等。

5.內部二級故障：指用戶雖未投訴，但造成用戶業務受到影響而影響范圍在30分鐘以下或用戶業務雖未受到影響但自身系統宕機或中斷服務2小時以上的（含2小時）或公司資產受到重大損失或者項目上線后系統中重復發生宕機、中斷服務不足2小時的重大故障。關于項目故障的責任認定

關于項目故障的責任認定，分為以下五種 項目重大故障及用戶投訴處理辦法

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

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

3.實施設計問題：造成項目故障的原因在于項目組的實施或設計方案（合同方案存在問題暫不屬于項目組責任，但項目組有識別合同技術方案是否存在問題的責任和義務）。

4.產品問題：造成項目故障的原因在于項目中公司產品或第三方產品、設備自身存在問題，但當事人響應處理不及時、不到位。5.第三方因素：造成項目故障原因的在于第三方，但當事人響應處理不及時、不到位。關于用戶投訴的原因

關于用戶投訴的原因，分為以下五種：

1.項目故障：由于項目出現故障導致用戶投訴，而故障的責任認定見第三部分的四類責任定義。

2.項目進度：由于項目進度存在問題導致用戶投訴。3.項目質量：由于項目質量存在問題導致用戶投訴。

4.項目管理能力和水平：由于項目管理能力和水平的問題導致用戶投訴。

5.項目組服務態度和水平：由于項目組服務態度和水平的問題導致用戶投訴。關于項目故障和用戶投訴的通報機制

1.責任人（或第一知曉人）應在發現后第一時間立即通知項目經理（或維護類項目維護負責人，本辦法中提到的項目經理統指項目經理或維護類項目維護負責人）。

2.項目經理在得知事件后應第一時間立即口頭通知主管銷售和事業部技術 項目重大故障及用戶投訴處理辦法

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

總監或項目總監，在4個小時內負責向主管銷售、行業經理、部門經理、技術總監、公司項目總監、大區項目總監、項目管理部、大區技術總監、大區總經理和事業部總經理進行郵件通報事故概況，并電話通知部門經理和行業經理。

3.對于除內部一般事故外的其他性質的項目事故，由技術總監或項目總監負責立即向公司CSO和CTO進行口頭和郵件上報。

4.由銷售受理的用戶投訴，需及時通知項目經理進行跟進處理，并通知事業部主管項目領導和項目管理部。

5.由項目管理部受理的用戶投訴，需及時通知項目經理、銷售和事業部主管項目領導，由項目經理跟進處理。

6.由大區總經理受理的用戶投訴，需及時通知主管銷售，由主管銷售及時通知項目經理、銷售和事業部主管項目領導，由項目經理跟進處理，處理結果要上報大區總經理。

7.由公司領導層受理的用戶投訴，可由公司領導層通知項目管理部，由項目管理部負責通知項目經理、主管銷售和事業部總經理進行跟蹤處理，處理結果要上報公司領導。關于項目故障和用戶投訴的處理機制

1.項目經理為事故處理的第一責任人，由項目經理組織協調相關人員進行跟蹤處理：控制事故影響，恢復受損系統和業務，最后進行事故分析、處理、匯報和總結。

2.項目經理需要會同項目組和事業部分析事故原因，給出解決辦法、后續避免措施和本次事故的處理決定，生成故障分析報告。

3.故障分析報告報主管銷售和項目總監（技術總監）協商確定；對于用戶通報類事故和重大投訴，向用戶提交的故障分析報告，需郵件向事業部總經理和公司CTO報批，并同時口頭通知。

4.項目故障分析報告經審批后，由項目經理和主管銷售向用戶進行書面回復和正式口頭匯報。項目重大故障及用戶投訴處理辦法

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

5.由項目經理協調項目組總結故障原因與處理過程，形成項目事故案例庫，上報給事業部質管部門。

6.事業部質管部門審定后向事業部內部進行全員發布，并把事故案例上報項目管理部。

7.項目管理部根據案例特點選擇定向或向公司范圍進行事故案例發布（發布案例的用戶名、責任人等匿名處理），并由項目管理部整理匯總形成公司事故案例庫。其中對于涉及公司產品問題，由項目管理部向產品管理及公共研發部進行通報。關于項目故障和用戶投訴的處罰辦法

7.1 處罰原則

1.差異化原則：依據故障級別和責任認定、投訴內容進行差異化處罰。其中：針對投訴內容不是“項目故障”的用戶一般投訴，如果用戶不做處罰的明確要求，第一次公司內部不做罰款處理，如果同一項目組再發生同類投訴則進行罰款處理。

2.責任共擔原則：與項目事故和用戶投訴相關的項目組和事業部人員或大區人員責任共擔，依當事責任人歸屬技術事業部或大區進行責任共擔，涉及人員包括：

1)相關當事人（歸屬事業部）→項目經理→事業部部二級部門經理（含行業經理）→部門技術總監（含項目總監）

2)相關當事人（歸屬大區）→項目經理→大區技術經理。

3.同類事故性質加罰原則：對于在公司事故案例庫內發布的事故，如果重復發生處罰力度加罰一倍。

4.瞞報或不及時上報加重處罰原則：對于事故責任人和項目經理發生瞞報或不及時上報事故的，按照最高處罰標準進行處罰（即故障等級認定為由于低級錯誤導致的用戶通報）。

5.項目經理崗位津貼罰沒原則：依據故障級別和責任認定、投訴內容，決 項目重大故障及用戶投訴處理辦法

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

定事故或用戶投訴發生當月項目經理津貼是否罰沒，如果需要罰沒但當月已發的，則下月項目經理崗位津貼罰沒（屬于補罰）。

6.當事人與項目經理當期績效降級或限級原則：依據故障級別和責任認定、投訴內容，對當事人及項目經理的當期績效進行降級或限級。7.降低項目獎金標準原則：依據故障級別和責任認定、投訴內容，降低該項目項目獎金的標準。

8.累加原則：罰款和降低項目獎金標準的額度按照事故和用戶投訴發生次數進行累加計算。

7.2 處罰標準

依據故障級別和責任認定、用戶投訴內容決定責任人、項目經理、二級部門經理（含行業經理或大區技術經理）、部門技術總監（含項目總監）的處罰決定以及項目經理崗位津貼是否罰沒、項目獎金基準折扣、當事人的績效評定和事故通報范圍等，具體處罰標準詳見下表（附件：項目重大故障及用戶投訴處罰標準.xlsx）。項目重大故障及用戶投訴處理辦法

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

7.3 處罰執行機構

1.罰款：由事業部、大區和項目管理部聯合執行。

1)由主管項目的事業部領導制定事業部內受罰當事人的罰款結果，涉及用戶通報和重大投訴的處罰決定事業部需要與主管銷售、公司CTO進行溝通確定，然后郵件通知當事人和項目管理部；由大區技術總監制定大區內受罰當事人的罰款結果，涉及用戶通報和重大投訴的處罰決定需要與主管銷售、公司CTO進行溝通確定，然后郵件通知當事人和項目管理部。

2)當事人到項目管理部進行書面簽字或對處罰結果進行郵件確認（如果事業部或大區發出處罰郵件通知單后7個工作日內當事人不做郵件回復視作同意處罰決定），如果當事人不接受，可向事業部、大區或項目管理部提出郵件上訴，由事業部主管領導、大區技術總監和項目管理部協調處理。

3)項目管理部按月把處罰結果匯總報人力資源部執行。

2.通報：公司范圍由項目管理部負責；事業部范圍由事業部主管項目副總負責。項目重大故障及用戶投訴處理辦法

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

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

3.不及時：含義是“沒有在規定和容許的時限內上報、響應或處理”。其中：不及時上報是指：“雖在公司知道前上報，但沒有在規定和容許的時限內上報”。生效日期

本辦法自發布之日起生效。

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

2011年