第一篇:LTE每天學習總結—TDD-LTE幀結構詳解
LTE幀結構圖解
幀結構總圖:
1、同步信號(下行)1-
1、PSS(主同步信號)
P-SCH(主同步信道):UE可根據P-SCH獲得符號同步和半幀同步。PSS位于DwPTS的第三個符號。占頻域中心6個RB。
2、SSS(輔同步信號)
S-SCH(輔同步信道):UE根據S-SCH最終獲得幀同步,消除5ms模糊度。SSS位于5ms第一個子幀的最后一個符號。也占頻域中心6個RB,72個子載波,2、參考信號 2-
2、下行
2-1-
1、CRS(公共參考信號)
時域(端口0和1的CRS位于每個slot第1和倒數第3個符號,端口2和3位于每個slot第2個符號)頻域(每隔6個子載波插入1個)位置:分布于下行子幀全帶寬上
作用:下行信道估計,調度下行資源,切換測量
2-1-
2、DRS(專用參考信號)
位置:分布于用戶所用PDSCH帶寬上
作用:下行信道估計,調度下行資源,切換測量
2、上行
2-2-
1、DMRS(解調參考信號)
在PUCCH、PUSCH上傳輸,用于PUCCH和PUSCH的相關解調,可能映射到以下幾個位置:
1、PUSCH 每個slot(0.5ms)一個RS,第四個OFDM symbol
2、PUCCH-ACK 每個slot中間三個OFDM symbol為RS
3、PUCCH-CQI 每個slot兩個參考信號
2-2-
2、SRS(探測參考信號)
可以在普通上行子幀上傳輸,也可以在UpPTS上傳輸,位于上行子幀的最后一個SC-FDMA符號,eNB配置UE在某個時頻資源上發送sounding以及發送sounding的長度。、Sounding作用:
上行信道估計,選擇MCS和
上行頻率選擇性調度 TDD系統中,估計上行信道矩陣H,用于下行波束賦形 Sounding周期:
由高層通過RRC 信令觸發UE 發送SRS,包括一次性的SRS 和周期性SRS 兩種方式 周期性SRS 支持2ms,5ms,10ms, 20ms, 40ms, 80ms, 160ms, 320ms 八種周期 TDD系統中,5ms最多發兩次
3、下行物理信道
1、PBCH(物理廣播信道)
頻域:對于不同的系統帶寬,都占用中間的1.08MHz(72個子載波)
時域:映射在每5ms 無線幀的subframe0的第二個slot的前4個OFDM符號上 周期:40ms。每10ms重復發送一次,終端可以通過4次中的任一次接收解調出BCH
采用QPSK調制方式,MIB在PBCH上傳輸,包含了接入LTE系統所需要的最基本的信息:系統帶寬、系統幀號(SFN)、PHICH配置、天線數目。
2、PCFICH(物理層控制格式指示信道)
指示PDCCH的長度信息(1、2或3),在子幀的第一個OFDM符號上發送,占用4個REG,均勻分布在整個系統帶寬。
采用QPSK調制,攜帶一個子幀中用于傳輸PDCCH的OFDM符號數,傳輸格式。
3、PHICH(物理HARQ指示信道)
PHICH的傳輸以PHICH組的形式,PHICH組的個數由PBCH指示。
采用兩種長度半靜態可配的方式:對MBSFN子幀,PHICH長度在1個和2個OFDM符號之間半靜態選擇:對非MBSFN子幀,PHICH長度在 1個和3個OFDM符號之間半靜態選擇。采用BPSK調制,傳輸上行信道反饋信息。
和PCFICH一樣,PHICH也盡可能均勻分布在6個PRB所在的帶寬內,兩個相鄰的PHICH REG之間相隔6個REG,另外,在時域上,PHICH也盡可能分散到控制區域所在的所有符號,以PHICH長度為3為例,因此3個PHICHREG分別位于3個符號。如果PHICH長度為2,則3個PHICHREG有1個位于第1符號,有2個位于第2符號。
4、PDCCH(物理下行控制信道)頻域:占用所有的子載波
時域:占用每個子幀的前n個OFDM符號,n<=3 PDCCH的信息映射到控制域中除了參考信號、PCFICH、PHICH之外的RE中,因此需先獲得PCFICH和PHICH的位置之后才能確定其位置,基本單位為CCE。
用于發送上/下行資源調度信息、功控命令等,通過下行控制信息塊DCI承載,不同用戶使用不同的DCI資源
4、上行物理信道
1、PRACH(物理隨機接入信道)頻域:1.08MHz帶寬(72個子載波),與PUCCH相鄰
時域:位于UpPTS(format 4)及普通上行子幀中(format 0~3)。每10ms無線幀接入0.5~6次,每個子幀采用頻分方式可傳輸多個隨機接入資源。
2、PUCCH(上行物理控制信道)
傳輸上行用戶的控制信息,包括CQI, ACK/NAK反饋,調度請求等。
一個控制信道由1個RB pair組成,位于上行子幀的兩邊邊帶上,在子幀的兩個slot上下邊帶跳頻,獲得頻率分集增益 通過碼分復用,可將多個用戶的控制信息在同一個PDCCH資源上發送。
第二篇:LTE每天學習總結-問題分析(接入-華為)
LTE接入問題分析
1.隨機接入流程
(1)用戶Attach流程:
UERRC CONN SETUP REQE-NODEBMMERRC CONN SETUPRRC CONN SETUP CMPINITIAL UE MESSAGE直傳過程(鑒權、業務協商)INITIAL UE CONTEXT SETUP REQRRC SECURITY MODE CMDRRC SECURITY MODE CMPRRC CONN RECFGRRC CONN RECFG CMPINITIAL UE CONTEXT SETUP RSP直傳過程(業務協商、流程通知)SAEB SETUP REQRRC CONN RECFGRRC CONN RECFG CMPSAEB SETUP RSP
(2)隨機接入流程介紹
隨機接入過程的發生有以下五種場景:
1、從空閑態轉到連接態的初始接入;
2、無線鏈接失敗后的接入;
3、切換過程中的接入;
4、當UE處于連接態時下行數據到達時因為某些原因需要隨機接入,如上行失步時有下行數據到達;
5、當UE處于連接態時上行數據到達時因為某些原因需要隨機接入,如上行失步時有上行行數據到達;
隨機接入分為競爭接入與非競爭接入兩種,其中競爭隨機接入適用于上述1、2、5三種場景,而非競爭隨機接入適用于3、4兩種場景。
隨機接入基本流程如下:
UEeNB1Random Access PreambleUEeNBRandom Access Response20RA Preamble assignment3Scheduled TransmissionRandom Access Preamble1Contention Resolution42Random Access Response 圖2 隨機接入流程圖(左:基于競爭的隨機接入 右:基于非競爭的隨機接入)
2.常見問題簡單排查方法
2.1基本定位思路
接入失敗通常有三大類原因:無線側參數配置問題、信道環境影響以及核心網側配置問題。因此遇到無法接入的情況,可以大致按以下步驟進行排查。(1)通過話統分析是否出現接入成功率低的問題,當前RRCeRAB接通率指標一般為98%,也可根據局點對接入成功率指標的特殊要求啟動問題定位。
(2)確認是否全網指標惡化,如果是全網指標惡化,需要檢查操作,告警,是否存在網絡變動和升級行為。
(3)如果是部分站點指標惡化,拖累全網指標,需要尋找TOP站點。
(4)查詢RRC連接建立和ERAB建立成功率最低的TOP10站點和TOP時間段。(5)查看TOP站點告警,檢查單板狀態,RRU狀態,小區狀態,OM操作,配置是否異常。
(6)提取CHR日志,分析接入時的msg3的信道質量和SRS的SINR是否較差(弱覆蓋),是否存在TOP用戶。
(7)針對TOP站點進行針對性的標準信令跟蹤、干擾檢測進行分析。
(8)如果標準信令和干擾檢測無異常,將一鍵式日志,標口跟蹤,干擾檢測結果返回給開發人員分析。
詳細流程圖如下:
開始Y全網話統分析,是否達標?N是否全網指標惡化?YN檢查告警,操作,是否存在網絡變動和升級操作。按照接入失敗次數和接入成功率確認TOP站點NTOP站點告警,操作,狀態,配置是否異常Y告警恢復,評估操作影響和升級影響告警,操作和配置恢復后KPI恢復正常?N根據CHR確認是否弱覆蓋?NYY根據信令跟蹤確認是否終端問題,核Y心網問題,ENB配置問題YN解決問題,KPI恢復?Y問題定位結束N優化覆蓋提交接入問題排查交付件供研發人員分析2.1.1、TOP小區篩選
通過M2000導出全網每日話統文件,按照(L.RRC.ConnReq.Att-L.RRC.ConnReq.Succ)次數從高到低排序,結合接入成功率,選出TOP10站點接入成功率低的小區。
按照(L.E-RAB.AttEst-L.E-RAB.SuccEst)次數從高到低排序,結合ERAB建立成功率選出TOP10 ERAB建立成功率低的站點。
檢查TOP小區的狀態是否正常,可以在M2000上,通過MML命令“DSP CELL”能查看到小區的總體信息。
如果小區狀態顯示不是“正常”,可以按如下方法進行簡單排查: 如果存在S1鏈路異常告警,請檢查S1鏈路配置是否正確。如果存在RSSI/RSRP通道不平衡,需要檢查天饋互調干擾,如果存在駐波告警,需要通過DSP TXBRANCH,DSP RXBRANCH查看RRU發射和接收通道狀態。
如果存在小區不可用告警,需要返回主控和基帶板一鍵式日志。
2.1.2、TOP小區話統分析
通過RRC建立失敗話統可以得出TOP小區RRC建立失敗原因分布:
L.RRC.SetupFail.NOReply多為弱覆蓋或終端異常;L.RRC.Setup.ResFail由小區資源分配失敗導致。
通過ERAB建立失敗原因話統可以得出得出ERAB建立失敗原因分布:
L.E-RAB.FailEst.RNL的統計包含了指標L.E-RAB.FailEst.NoRadioRes、L.E-RAB.FailEst.SecurModeFail及指標L.E-RAB.FailEst.NoReply的統計情況。
初始上下文建立失敗的幾種現象: 基站下發了RRC_SECUR_MODE_CMD消息,收到UE的RRC_SECUR_MODE_FAIL消息 UE SecurityModeCommand EUTRAN SecurityModeFailure 2 基站下發了RRC_SECUR_MODE_CMD消息,沒有收到UE的RRC_SECUR_MODE_CMP消息 3 基站下發了RRC_CONN_RECFG消息,沒有收到UE的RRC_CONN_RECFG_CMP消息 基站下發了RRC_UE_CAP_ENQUIRY消息,沒有收到UE的RRC_UE_CAP_INFO消息
初始上下文建立請求消息超時,需要核心網側配合,查看核心網側在收到ENB傳遞的NAS Attach消息后的處理流程。
初始上下文建立失敗需要檢查基站配置,查看告警,跟蹤Uu口,S1口進行分析。
2.1.3、TOP用戶分析
通過CHR日志分析可以獲取RRC建立失敗和ERAB建立失敗TOP用戶的TMSI。在CHR數據中,可以通過TMSI來確定是否為同一個用戶,具體方法如下:
當前華為核心網TMSI分配的機制是對于同一個IMSI用戶,TMSI的右起第三個byte的數據進行隨機賦值,即某用戶的TMSI中只有第三個字節的8bit發生變化(如AA ** BB CC)就是同一用戶。如下圖所示,C0 ** 00 05就是同一個用戶。
使用INSIGHTSHARP工具分析同一TMSI用戶的多個接入流程,查看L2_SRB_LOG字段記錄的接入時上行信道質量DMRS_SINR和DMRS_RSRP,可以初步確認用戶是否處于上行弱覆蓋區域:
DMRS_SINR<0db或DMRS_RSRP<-131dbm可以認為終端處于弱覆蓋區域。
圖6 CHR字段說明截圖 2.1.4、TOP小區跟蹤
通過話統分析出TOP小區和TOP時間段后,在對應的小區和時間段,打開Uu口,S1口,X2口跟蹤,查看接入流程在哪一步失敗。
通過TOP用戶的TMSI在核心網側獲取到IMSI,可以啟動該用戶的全網跟蹤
2.1.5、TOP小區環境干擾分析
通過頻譜掃描儀功能查看下行是否存在鄰區干擾、外部系統干擾等。通過ENB小區干擾檢測的性能跟蹤分析是否存在上行干擾。如存在外部干擾或鄰區干擾,需要進行干擾源排查。
3.配置類問題排查 UE配置問題
1.華為Test UE頻點配置
針對我司UE,檢查頻點配置是否與eNB一致,如果頻點不正確,UE表現為小區搜索失敗。
圖7 測試UE頻點配置
2.E398/E392 Attach類型設置
LTE核心網通常沒有配置CS域的通道,只有PS域。當E398 Attach類型為CS&PS combined attach時,就會導致只Attach了PS域,CS域一直附著失敗,UE最終被釋放掉。將E398的Attach方式修改為PS_ONLY可以解決此問題。
圖8 Attach信令截圖
3.終端規格問題
以E398s/E392u為例,只支持Band38和Band40,如果小區設置為其他頻帶,終端將無法接入。
另外,需要確認部分終端對無線層加密算法的支持程度,如果小區配置中使用了終端不支持算法進行加密和完整性保護,終端可能會出現接入失敗。
以海思芯片為例,通過Histudio在NV項中找到UE_NET_CAPABILITY項查看加密及完整性算法。
ucEeaCap: 加解密算法。ucEiaCap: 完整性保護算法。
高位3個Bit從高到底分別代表NULL、SNOW3G、AES算法 與協議24301中表9.9.3.34.1是一致。
1代表支持,0代表不支持。
比如上圖中ucEeaCap與ucEiaCap的值都為0xe0代表NULL、SNOW3G與AES算法都 支持。
如果需要更改,比如需要設置UE可支持的加密算法為AES算法,其它兩種算法不支持,則可設置ucEiaCap=0x20 換算成二進制為0010,表示只支持AES算法。
目前UE對三種算法都支持,所以不管在測試還是商用使用過程中,建議按照默認設置,不要更改這些值。
ENB配置問題
1.PDCCH符號數配置問題
測試局點為了盡可能提高下行吞吐率,PDCCH通常固定1符號,但在20M帶寬以下,可能出現無法接入的問題。
10M小區,PDCCH固定1符號,總共能使用的CCE個數為8個,受上下行配比約束,下行最多能用5個,而10M小區公共信令的聚合級別為8,需要8個,因此CCE資源受限所以接入不了
5M小區,PDCCH固定1符號,總共能使用的CCE個數為3,同樣由于CCE資源受限接入不了
15M小區,PDCCH固定1符號,總共能使用的CCE個數為12,受上下行配比約束,下行最多能用8個,PDCCH功控開關關閉時可以接入。
圖9 PDCCH符號數配置
2.IPPATH配置問題
基站在完成了安全的配置與UE能力的獲取后并向小區申請資源,會向TRM申請GTPU資源,如果申請資源失敗則會向核心網返回初始上下文建立失敗響應INIT_CONTEXT_SETUP_FAIL;原因值填寫transport resource unavailable(0);如下圖所示;
跟蹤如下所示:
圖10 初始上下文建立失敗響應信令截圖
在這種情況下,對照開站summary首先查看一下MML中的IPPATH是否配置正確,如果已經配置正確,則查看請初始上下文建立請求消息(INIT_CONTEXT_SETUP_REQ消息)中transportlayeraddress的信元值是否為配置的IPPATH值,如果不一樣則需要確認一下是我們配置錯誤還是核心網填寫錯誤。同時查看路由信息配置是否正確,如果IPPATH正確,但路由錯誤,同樣會出現傳輸資源不可用的錯誤信息。如果以上都不符合則需要把IFTS打開,將跟蹤發給研發人員來確認問題的原因;
圖11 初始上下文建立請求消息信令
第三篇:LTE每天學習總結—鄰區添加步驟
LTE實戰
QQ:21825402
LTE鄰區添加步驟
1、同頻鄰區添加
1.1、系統內同頻eNodeB內小區鄰區
在MML命令行輸入:ADD EUTRANINTRAFREQNCELL
圖 1 增加鄰區
1.2、系統內同頻eNodeB間小區鄰區
系統內同頻eNodeB間小區鄰區關系的建立,需要先創建EUTRAN外部小區關系 在MML命令行輸入: ADD EUTRANEXTERNALCELL
圖 2 增加外部小區
注意:EUTRAN外部小區信息一定要正確,基站通過增加這些信息來維護鄰區關系,如果小區信息有錯誤,會導致切換失敗。
LTE實戰
QQ:21825402 創建完外部小區關系后,開始增加EUTRAN同頻鄰區關系 在MML命令行輸入:ADD EUTRANINTRAFREQNCELL
圖 3 增加鄰區
2、異頻eNodeB鄰區添加
首先確認異頻開關是否打開
系統內異頻eNodeB間小區鄰區關系的建立,第一步需要添加異頻LTE鄰區頻點; 在MML命令行輸入:ADD EUTRANINTERNFREQ
圖 1 增加異頻鄰區頻點
第二步增加外部小區,與增加同頻外部小區MML命令相同,ADD EUTRANEXTERNALCELL; 注意輸入正確的“下行頻點”;
LTE實戰
QQ:21825402
圖 2 增加異頻外部小區
第三步增加鄰區關系,MML命令為:ADD EUTRANINTERFREQNCELL
圖 3 增加異頻鄰區
現網特別注意,需修改異頻頻點小區重選優先級為7 最后調整門限
LTE實戰
QQ:21825402
3、增加4G-3G鄰區
第一步增加UTRAN鄰區頻點,MML命令為:ADD UTRANNFREQ
圖 1 增加UTRAN鄰區頻點
第二步增加UTRAN外部小區,MML命令為:ADD UTRANEXTERNALCELL
圖 2 增加UTRAN外部小區
第三步增加UTRAN鄰區關系,MML命令為:ADD UTRANNCELL
圖 3 增加UTRAN鄰區
第四步配置重選數據,MML命令為:MOD CELLRESEL
LTE實戰
QQ:21825402
現網配置異系統測量啟動門限為25 第五步創建小區重選,MML命令為:ADD CELLRESELUTRAN
4、增加4G-2G鄰區
1)執行ADD GERANNFREQGROUP命令,創建GERAN相鄰頻點組。
2)執行ADD GERANNFREQGROUPARFCN命令,創建GERAN BCCH相鄰頻點。
LTE實戰
QQ:21825402
3)執行ADD GERANEXTERNALCELL命令,創建GERAN外部小區。
4)執行ADD GERANNCELL命令,創建GERAN鄰區關系。
第四篇:LTE每天學習總結—基本過程(下行同步)
1.小區搜索
1.1 開機
UE開機在可能存在LTE小區的幾個中心頻點上接收信號(PSS),以接收信號強度來判斷這個頻點周圍是否可能存在小區,如果UE保存了上次關機時的頻點和運營商信息,則開機后會先在上次駐留的小區上嘗試;如果沒有,就要在劃分給LTE系統的頻帶范圍內做全頻段掃描,發現信號較強的頻點去嘗試
1.2 PSS檢測
進行5MS時隙同步,檢測CELLID 然后在這個中心頻點周圍收PSS(主同步信號,對于FDD,PSS在slot0和slot10的倒數第一個OFDM符號上;SSS在slot0和slot10的倒數第二個OFDM符號上。對于TDD,PSS在slot2和slot12的第二個OFDM符號上;SSS在slot1和slot11的倒數第一個OFDM符號上。),它占用了中心頻帶的6RB,因此可以兼容所有的系統帶寬,信號以5ms為周期重復,在子幀#0發送,并且是ZC序列,具有很強的相關性,因此可以直接檢測并接收到,據此可以得到小區組里小區ID,同時確定5ms的時隙邊界,同時通過檢查這個信號就可以知道循環前綴的長度以及采用的是FDD還是TDD(因為TDD的PSS是放在特殊子幀里面,位置有所不同,基于此來做判斷)由于它是5ms重復,因為在這一步它還無法獲得幀同步
1.3 SSS檢測
進行10MS同步,檢測CELL GroupID、幀同步
5ms時隙同步后,在PSS基礎上向前搜索SSS,SSS由兩個端隨機序列組成,前后半幀的映射正好相反,因此只要接收到兩個SSS就可以確定10ms的邊界,達到了幀同步的目的。由于SSS信號攜帶了小區組ID,跟PSS結合就可以獲得物理層ID(CELL ID),這樣就可以進一步得到下行參考信號的結構信息。PSS在每個無線幀的2次發送內容一樣,SSS每個無線幀2次發送內容不一樣,通過解PSS先獲得5ms定時,通過解SSS可以獲得無線幀的10ms定時。因為先解析PSS獲得5ms定時,在解析SSS時根據FDD和TDD其位置不同可以確定是FDD模式還是TDD模式。再者,不管系統帶寬是多少,PSS和SSS都在在系統帶寬中間的6個RB上發送,在帶寬內對稱發送,所以通過解PSS和SSS可以獲得頻域同步。通過解PSS可以獲得物理層小區ID,通過解SSS可以獲得小區的組ID,二者組合就可以獲得當前小區的物理小區ID。
1.4 DL-RS 時隙與頻率精確同步
在獲得幀同步以后就可以讀取PBCH了,通過上面兩步獲得了下行參考信號結構,通過解調參考信號可以進一步的精確時隙與頻率同步,同時可以為解調PBCH做信道估計了。
1.5 PBCH 獲得系統帶寬,PHICH資源、天線數、SFN(系統幀號)
PBCH在子幀#0的slot #1上發送,就是緊靠PSS,通過解調PBCH,可以得到系統幀號和帶寬信息,以及PHICH的配置以及天線配置。系統幀號以及天線數設計相對比較巧妙: SFN(系統幀數)位長為10bit,也就是取值從0-1023循環。在PBCH的MIB(master information block)廣播中只廣播前8位,剩下的兩位根據該幀在PBCH 40ms周期窗口的位置確定,第一個10ms幀為00,第二幀為01,第三幀為10,第四幀為11。PBCH的40ms窗口手機可以通過盲檢確定。而天線數隱含在PBCH的CRC里面,在計算好PBCH的CRC后跟天線數對應的MASK進行異或 至此,UE實現了和ENB的定時同步(MIB傳輸周期為40ms,在一個周期內,PBCH信道分布在每個無線幀的#0子幀內,占據第二個slot的前4個符號位置;頻域與PSS和SSS信號一樣,占據中心的1.08MHz,即頻域中心的6RB)
LTE系統消息相關資料
LTE每天學習總結—系統消息.docx
1.6 PDSCH 接受SIB消息
要完成小區搜索,僅僅接收PBCH是不夠的,因為PBCH只是攜帶了非常有限的系統信息,更多更詳細的系統信息是由SIB攜帶的,因此此后還需要接收SIB(系統信息模塊),即UE接收承載在PDSCH上的BCCH信息。為此必須進行如下操作:
1)接收PCFICH,此時該信道的時頻資源可以根據物理小區ID推算出來,通過接收解碼得到PDCCH的symbol數目;
2)在PDCCH信道域的公共搜索空間里查找發送到SI-RNTI(無線網絡標識符)的候選PDCCH,如果找到一個并通過了相關的CRC校驗,那就意味著有相應的SIB消息,于是接收PDSCH,譯碼后將SIB上報給高層協議棧;
3)不斷接收SIB,上層(RRC)會判斷接收的系統消息是否足夠,如果足夠則停止接收SIB至此,小區搜索過程才差不多結束
第五篇: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。