TDLTE優(yōu)化-接入

1、內(nèi)部公開confidentiality levelTDLTE接入性能優(yōu)化2014-01-21華為機密，未經(jīng)許可不得擴散第2頁,共49頁Page 2 , Total49本文介紹了用戶接入的流程和用戶接入失敗時問題定位的基本方法，常見問題排查方法部分主要面向網(wǎng)絡(luò)維護人員，介紹了一些常見問題的定位排查手段和方法，主要應(yīng)用場景為通過KPI指標發(fā)現(xiàn)問題，通過CHR、告警日志、標口跟蹤、UE側(cè)log進行問題定位。1 概念和基本原理1.1 基本概念（1）用戶Attach流程：圖1 用戶接入流程（2）隨機接入流程介紹隨機接入過程的發(fā)生有以下五種場景：1、 從空閑態(tài)轉(zhuǎn)到連接態(tài)的初始接入；2、 無線鏈接失敗后的接

2、入；3、 切換過程中的接入；4、 當UE處于連接態(tài)時下行數(shù)據(jù)到達時因為某些原因需要隨機接入，如上行失步時有下行數(shù)據(jù)到達；5、 當UE處于連接態(tài)時上行數(shù)據(jù)到達時因為某些原因需要隨機接入，如上行失步時有上行行數(shù)據(jù)到達；隨機接入分為競爭接入與非競爭接入兩種，其中競爭隨機接入適用于上述1、2、5三種場景，而非競爭隨機接入適用于3、4兩種場景。隨機接入基本流程如下：圖2 隨機接入流程圖（左：基于競爭的隨機接入 右：基于非競爭的隨機接入）1.2 接入流程話統(tǒng)介紹1.2.1 隨機接入話統(tǒng)隨機接入過程分為基于競爭的隨機接入和基于非競爭的隨機接入兩種基本過程?！癛A測量(小區(qū))(RA.Cell)”統(tǒng)計小區(qū)內(nèi)不同

3、隨機接入過程的前導(dǎo)接收次數(shù)、RAR發(fā)送次數(shù)以及競爭過程中的Contention Resolution發(fā)送次數(shù)，用于分析隨機接入的負載、成功率等相關(guān)情況。1.2.2 RRC連接建立請求話統(tǒng)統(tǒng)計eNodeB內(nèi)各小區(qū)收到的RRC的建立請求次數(shù)。RRC Connection Request消息是UE向eNodeB發(fā)送的第一條RRC信令消息，目的是請求建立一條RRC連接。1.2.3 RRC連接建立嘗試話統(tǒng)統(tǒng)計小區(qū)內(nèi)不同類型RRC的建立嘗試次數(shù)，即eNodeB響應(yīng)UE的RRC Connection Request消息并下發(fā)RRC Connection Setup消息的次數(shù)。RRC Connection S

4、etup消息是eNodeB發(fā)送給UE的RRC信令消息，目的是通知UE RRC連接的建立結(jié)果及相關(guān)配置信息。1.2.4 RRC連接建立成功話統(tǒng)統(tǒng)計小區(qū)內(nèi)不同類型RRC的建立成功次數(shù)，即eNodeB收到UE的RRC Connection Setup Complete的次數(shù)。RRC Connection Setup Complete消息是UE發(fā)送的RRC信令消息，目的是通知eNodeB本次RRC連接建立完成，并攜帶NAS信令信息以及PLMN的選擇信息。話統(tǒng)統(tǒng)計方法圖3 RRC建立統(tǒng)計點【A點】（1）指標L.RRC.ConnReq.Att加1，不統(tǒng)計重發(fā)的次數(shù)。Case1：eNB下發(fā)RRC_Conn_

5、Setup消息后，在T300定時器超時前，收到相同的UeID發(fā)起的RRC_Conn_Req（Setup丟失，UE MAC沖突解決定時器超時后重發(fā)RRC_Conn_Req，UeID不變），記為一次重發(fā)RRC_Conn_Req消息。Case2：T300超時后，UE仍未收到RRC_Conn_Setup，UE重新搜網(wǎng)，發(fā)起初始接入，UeID是取0239的隨機值或上層下發(fā)的TMSI。eNB側(cè)記為新的一次初始接入，L.RRC.ConnReq.Att加1。Case3：發(fā)起Attach后會啟動T3410定時器。如果UE發(fā)出RRC_Conn_Setup_Cmp后，ENB沒有收到，UE會在定時器超時后重新發(fā)起At

6、tach，ENB側(cè)記為新的一次初始接入；RRC_Conn_Setup_Cmp丟失不會觸發(fā)重建，發(fā)起重建的前提是安全已經(jīng)激活。（2）如果RRC Connection Request消息信元Establishment Cause為“emergency”，指標L.RRC.ConnReq.Att.Emc加1。（3）如果RRC Connection Request消息信元Establishment Cause為“highPriorityAccess”，指標L.RRC.ConnReq.Att.HighPri加1。（4）如果RRC Connection Request消息信元Establishment Ca

7、use為“mt-Access”，指標L.RRC.ConnReq.Att.Mt加1。（5）如果RRC Connection Request消息信元Establishment Cause為“mo-Singnalling”，指標L.RRC.ConnReq.Att.MoSig加1。（6）如果RRC Connection Request消息信元Establishment Cause為“mo-Data”，指標L.RRC.ConnReq.Att.MoData加1。【B點】當eNodeB下小區(qū)接收到UE發(fā)送的RRC Connection Request消息并下發(fā)RRC Connection Setup消息給U

8、E時，指標L.RRC.ConnSetup加1?！綜點】當eNodeB收到UE返回的RRC Connection Setup Complete消息時統(tǒng)計相應(yīng)指標，L.RRC.ConnReq.Succ加1。RRC Setup Success Rate計算RRCSetupSuccessRate=（L.RRC.ConnReq.Succ）/(L.RRC.ConnReq.Att)*100%1.2.5 RRC連接建立失敗話統(tǒng)統(tǒng)計小區(qū)內(nèi)不同原因的RRC連接建立失敗的次數(shù)及總的RRC連接失敗次數(shù)。RRC Connection Reject消息是eNodeB發(fā)送給UE的RRC信令消息，目的是通知UE本次接入過程被

9、eNodeB拒絕。1.2.6 ERAB承載建立嘗試話統(tǒng)統(tǒng)計小區(qū)E-RAB建立嘗試總次數(shù)。E-RAB建立過程一般由UE在需要向無線網(wǎng)絡(luò)申請服務(wù)時主動發(fā)起，并通過初始UE上下文建立流程或E-RAB建立流程完成建立。E-RAB建立嘗試總次數(shù)用于統(tǒng)計UE發(fā)起的總的E-RAB建立嘗試次數(shù)。1.2.7 ERAB承載建立成功話統(tǒng)統(tǒng)計小區(qū)E-RAB建立成功總次數(shù)。E-RAB建立過程一般由UE在需要向無線網(wǎng)絡(luò)申請服務(wù)時主動發(fā)起，并通過初始UE上下文建立流程或E-RAB建立流程完成建立。E-RAB建立嘗試總次數(shù)用于統(tǒng)計UE發(fā)起的總的E-RAB建立成功次數(shù)。話統(tǒng)統(tǒng)計方法 圖4如3、4中A點所示，當eNodeB收到來

10、自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息時統(tǒng)計該指標。如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息中要求同時建立多個E-RAB，則相應(yīng)指標按各個業(yè)務(wù)的QCI分別進行累加。ERAB Setup Success Rate計算公式ErabSetupSuccessRate=（L.E-RAB.SuccEst）/(L.E-RAB.AttEst)*100%1.2.8 ERAB承載建立失敗話統(tǒng)統(tǒng)計小區(qū)內(nèi)E-RAB不同原因值的建立失敗次數(shù)。E-RAB是承載用戶業(yè)務(wù)數(shù)據(jù)的接入層

11、承載，它在小區(qū)內(nèi)的建立成功率，直接反映了小區(qū)為用戶提供E-RAB連接建立的能力。E-RAB建立失敗統(tǒng)計，可以反映出網(wǎng)絡(luò)中各種原因的E-RAB建立失敗的分布情況。1.3 工具簡介（1）KPI話統(tǒng)記錄用于統(tǒng)計RRC建立成功率，ERAB建立成功率，失敗原因等信息（M2000,國內(nèi)OMC920）。（2）標準信令跟蹤（eNB UU口跟蹤、eNB S1口跟蹤、eNB X2口、UE OMT信令跟蹤）可以獲取信令消息交互情況。適用于進行簡單問題排查（LMT或M2000，國內(nèi)OMC920）。2 常見問題簡單排查方法2.1 基本定位思路接入失敗通常有三大類原因：無線側(cè)參數(shù)配置問題、信道環(huán)境影響以及核心網(wǎng)側(cè)配置問題

12、。因此遇到無法接入的情況，可以大致按以下步驟進行排查。（1）通過話統(tǒng)分析是否出現(xiàn)接入成功率低的問題，當前RRCeRAB接通率指標一般為98%，也可根據(jù)局點對接入成功率指標的特殊要求啟動問題定位。（2）確認是否全網(wǎng)指標惡化，如果是全網(wǎng)指標惡化，需要檢查操作，告警，是否存在網(wǎng)絡(luò)變動和升級行為。（3）如果是部分站點指標惡化，拖累全網(wǎng)指標，需要尋找TOP站點。（4）查詢RRC連接建立和ERAB建立成功率最低的TOP10站點和TOP時間段。（5）查看TOP站點告警，檢查單板狀態(tài)，RRU狀態(tài)，小區(qū)狀態(tài)，OM操作，配置是否異常。（6）提取CHR日志，分析接入時的msg3的信道質(zhì)量和SRS的SINR是否較差（

13、弱覆蓋），是否存在TOP用戶。（7）針對TOP站點進行針對性的標準信令跟蹤、干擾檢測進行分析。（8）如果標準信令和干擾檢測無異常，將一鍵式日志，標口跟蹤，干擾檢測結(jié)果返回給開發(fā)人員分析。 詳細流程圖如下：圖5 接入問題優(yōu)化流程圖2.1.1 TOP小區(qū)篩選通過M2000導(dǎo)出全網(wǎng)每日話統(tǒng)文件，按照（L.RRC.ConnReq.Att-L.RRC.ConnReq.Succ）次數(shù)從高到低排序，結(jié)合接入成功率，選出TOP10站點接入成功率低的小區(qū)。 按照（L.E-RAB.AttEst-L.E-RAB.SuccEst）次數(shù)從高到低排序，結(jié)合ERAB建立成功率選出TOP10 ERAB建立成功率低的站點。檢查

14、TOP小區(qū)的狀態(tài)是否正常，可以在M2000上，通過MML命令“DSP CELL”能查看到小區(qū)的總體信息。如果小區(qū)狀態(tài)顯示不是“正?！?，可以按如下方法進行簡單排查：如果存在S1鏈路異常告警，請檢查S1鏈路配置是否正確。如果存在RSSI/RSRP通道不平衡，需要檢查天饋互調(diào)干擾，如果存在駐波告警，需要通過DSP TXBRANCH，DSP RXBRANCH查看RRU發(fā)射和接收通道狀態(tài)。如果存在小區(qū)不可用告警，需要返回主控和基帶板一鍵式日志。2.1.2 TOP小區(qū)話統(tǒng)分析通過RRC建立失敗話統(tǒng)可以得出TOP小區(qū)RRC建立失敗原因分布：L.RRC.SetupFail.NOReply多為弱覆蓋或終端異常；

15、L.RRC.Setup.ResFail由小區(qū)資源分配失敗導(dǎo)致。通過ERAB建立失敗原因話統(tǒng)可以得出得出ERAB建立失敗原因分布：L.E-RAB.FailEst.RNL的統(tǒng)計包含了指標L.E-RAB.FailEst.NoRadioRes、L.E-RAB.FailEst.SecurModeFail及指標L.E-RAB.FailEst.NoReply的統(tǒng)計情況。初始上下文建立失敗的幾種現(xiàn)象：1 基站下發(fā)了RRC_SECUR_MODE_CMD消息,收到UE的RRC_SECUR_MODE_FAIL消息2 基站下發(fā)了RRC_SECUR_MODE_CMD消息,沒有收到UE的RRC_SECUR_MODE_CM

16、P消息3 基站下發(fā)了RRC_CONN_RECFG消息,沒有收到UE的RRC_CONN_RECFG_CMP消息4 基站下發(fā)了RRC_UE_CAP_ENQUIRY消息,沒有收到UE的RRC_UE_CAP_INFO消息初始上下文建立請求消息超時，需要核心網(wǎng)側(cè)配合，查看核心網(wǎng)側(cè)在收到ENB傳遞的NAS Attach消息后的處理流程。初始上下文建立失敗需要檢查基站配置，查看告警，跟蹤Uu口，S1口進行分析。2.1.3 TOP用戶分析通過CHR日志分析可以獲取RRC建立失敗和ERAB建立失敗TOP用戶的TMSI。在CHR數(shù)據(jù)中，可以通過TMSI來確定是否為同一個用戶，具體方法如下：當前華為核心網(wǎng)TMSI分

17、配的機制是對于同一個IMSI用戶，TMSI的右起第三個byte的數(shù)據(jù)進行隨機賦值，即某用戶的TMSI中只有第三個字節(jié)的8bit發(fā)生變化（如AA * BB CC）就是同一用戶。如下圖所示，C0 * 00 05就是同一個用戶。使用INSIGHTSHARP工具分析同一TMSI用戶的多個接入流程，查看L2_SRB_LOG字段記錄的接入時上行信道質(zhì)量DMRS_SINR和DMRS_RSRP，可以初步確認用戶是否處于上行弱覆蓋區(qū)域：DMRS_SINR<0db或DMRS_RSRP<-131dbm可以認為終端處于弱覆蓋區(qū)域。圖6 CHR字段說明截圖2.1.4 TOP小區(qū)跟蹤通過話統(tǒng)分析出TOP小區(qū)和

18、TOP時間段后，在對應(yīng)的小區(qū)和時間段，打開Uu口，S1口，X2口跟蹤，查看接入流程在哪一步失敗。通過TOP用戶的TMSI在核心網(wǎng)側(cè)獲取到IMSI，可以啟動該用戶的全網(wǎng)跟蹤2.1.5 TOP小區(qū)環(huán)境干擾分析通過頻譜掃描儀功能查看下行是否存在鄰區(qū)干擾、外部系統(tǒng)干擾等。通過ENB小區(qū)干擾檢測的性能跟蹤分析是否存在上行干擾。如存在外部干擾或鄰區(qū)干擾，需要進行干擾源排查。2.2 配置類問題排查2.2.1 UE配置問題1.華為Test UE頻點配置針對我司UE，檢查頻點配置是否與eNB一致，如果頻點不正確，UE表現(xiàn)為小區(qū)搜索失敗。圖7 測試UE頻點配置2.E398/E392 Attach類型設(shè)置LTE核心

19、網(wǎng)通常沒有配置CS域的通道，只有PS域。當E398 Attach類型為CS&PS combined attach時，就會導(dǎo)致只Attach了PS域，CS域一直附著失敗，UE最終被釋放掉。將E398的Attach方式修改為PS_ONLY可以解決此問題。圖8 Attach信令截圖3.終端規(guī)格問題以E398s/E392u為例， 只支持Band38和Band40，如果小區(qū)設(shè)置為其他頻帶，終端將無法接入。另外，需要確認部分終端對無線層加密算法的支持程度，如果小區(qū)配置中使用了終端不支持算法進行加密和完整性保護，終端可能會出現(xiàn)接入失敗。以海思芯片為例，通過Histudio在NV項中找到UE_NET_

20、CAPABILITY項查看加密及完整性算法。ucEeaCap: 加解密算法。ucEiaCap: 完整性保護算法。高位3個Bit從高到底分別代表NULL、SNOW3G、AES算法與協(xié)議24301中表9.9.3.34.1是一致。1代表支持，0代表不支持。比如上圖中ucEeaCap與ucEiaCap的值都為0xe0代表NULL、SNOW3G與AES算法都 支持。如果需要更改，比如需要設(shè)置UE可支持的加密算法為AES算法，其它兩種算法不支持，則可設(shè)置ucEiaCap0x20 換算成二進制為0010，表示只支持AES算法。目前UE對三種算法都支持，所以不管在測試還是商用使用過程中，建議按照默認設(shè)置，不要

21、更改這些值。2.2.2 ENB配置問題1.PDCCH符號數(shù)配置問題測試局點為了盡可能提高下行吞吐率， PDCCH通常固定1符號，但在20M帶寬以下，可能出現(xiàn)無法接入的問題。10M小區(qū)，PDCCH固定1符號，總共能使用的CCE個數(shù)為8個，受上下行配比約束，下行最多能用5個，而10M小區(qū)公共信令的聚合級別為8，需要8個，因此CCE資源受限所以接入不了5M小區(qū)，PDCCH固定1符號，總共能使用的CCE個數(shù)為3，同樣由于CCE資源受限接入不了15M小區(qū)，PDCCH固定1符號，總共能使用的CCE個數(shù)為12，受上下行配比約束，下行最多能用8個，PDCCH功控開關(guān)關(guān)閉時可以接入。圖9 PDCCH符號數(shù)配置2

22、.IPPATH配置問題基站在完成了安全的配置與UE能力的獲取后并向小區(qū)申請資源,會向TRM申請GTPU資源,如果申請資源失敗則會向核心網(wǎng)返回初始上下文建立失敗響應(yīng)INIT_CONTEXT_SETUP_FAIL;原因值填寫transport resource unavailable(0)；如下圖所示；跟蹤如下所示:圖10 初始上下文建立失敗響應(yīng)信令截圖在這種情況下,對照開站summary首先查看一下MML中的IPPATH是否配置正確,如果已經(jīng)配置正確,則查看請初始上下文建立請求消息(INIT_CONTEXT_SETUP_REQ消息)中transportlayeraddress的信元值是否為配置的

23、IPPATH值,如果不一樣則需要確認一下是我們配置錯誤還是核心網(wǎng)填寫錯誤。同時查看路由信息配置是否正確，如果IPPATH正確，但路由錯誤，同樣會出現(xiàn)傳輸資源不可用的錯誤信息。如果以上都不符合則需要把IFTS打開,將跟蹤發(fā)給研發(fā)人員來確認問題的原因；圖11 初始上下文建立請求消息信令3 問題定位和性能優(yōu)化3.1 問題定位流程詳述3.1.1 UE無法駐留小區(qū)問題定位指導(dǎo)以O(shè)MT跟蹤的TUE信令為例，分析定位方法如下。UE首先進行小區(qū)搜索，通過UE OMT的層間消息和關(guān)鍵事件消息查看是否成功駐留到小區(qū)。OMT中出現(xiàn)如下消息表示用戶能駐留到小區(qū)，否則為UE無法駐留到小區(qū)。圖12 UE OMT關(guān)鍵時間跟

24、蹤消息如果UE無法駐留到小區(qū)，通過OMT空口消息跟蹤查看用戶是否能收到系統(tǒng)消息。（1）確認UE是否能搜索到小區(qū)。通過OMT的層間消息跟蹤察看“ID_RRC_PHY_CELL_SEARCHING_IND”消息；打開消息，usCellNumber表示UE搜索到的小區(qū)數(shù)，接下去的列表中顯示了小區(qū)ID、RSRP等信息。圖13 UE OMT空口消息跟蹤信息如果小區(qū)數(shù)為0或者搜索到的小區(qū)ID不是目標小區(qū)的小區(qū)ID，則說明沒有搜索到小區(qū)。Ø 一般的，可能是小區(qū)覆蓋太差導(dǎo)致的，可以通過重新選點、核查覆蓋參數(shù)的方式進行排查。Ø 一般的，可能是頻點等配置參數(shù)不正確導(dǎo)致，確認一下頻點或者重新配置

25、一下頻點。具體查看方式如下：圖14 UE OMT配置窗口（2）確認一下是否收到系統(tǒng)消息，判斷是那條消息的問題。RRC_MASTER_INFO_BLOCK表示MIB消息。RRC_SIB _TYPE1、RRC_SYS_INFO為SIB消息。圖15 UE OMT消息跟蹤消息（3）如果能收到系統(tǒng)消息，而用戶沒有發(fā)起MM_ATTACH_REQ。Ø 一般的，可能是用戶配置了手動ATTACH模式，請修改為Auto模式，或手動進行ATTACH操作。圖16Ø 一般的，可能是小區(qū)被禁止，小區(qū)禁止信息在SIB1中，且為可選項，如果沒有小區(qū)禁止信息，可認為小區(qū)未禁止。圖17 協(xié)議36331 6.3

26、.1中小區(qū)禁止的消息描述Ø 一般的，可能是S準則判決沒通過，導(dǎo)致用戶無法駐留到小區(qū)。協(xié)議規(guī)定了小區(qū)駐留電平，如果用戶測量到小區(qū)的信道強度一段時間內(nèi)小于小區(qū)配置的駐留電平，UE L3會發(fā)起小區(qū)重選，重新選擇可駐留的小區(qū)。設(shè)置小區(qū)駐留門限是為了保障用戶在小區(qū)中能正常開展業(yè)務(wù)的一個門限值，一般的，如果小區(qū)信號低于該門限值，可認為用戶已經(jīng)不能維持正常的業(yè)務(wù)了，即使駐留在小區(qū)也沒有實際意義。在實際系統(tǒng)中為了到達用戶會在網(wǎng)絡(luò)中“永存”等考慮可能會將該值設(shè)置為較低。 小區(qū)駐留門限配置可以從SIB3消息中獲取，具體的查看方式如下，q-RxLevMin就是小區(qū)最小駐留電平，其單位為2dB。示例中的最小

27、駐留門限為-128dBm。圖18 UE OMT消息跟蹤在UE接收完系統(tǒng)消息后，UE L3會指示UE L1進行小區(qū)RSRP的測量，L3收到L1的測量信息后進行S準則的判決。通過UE OMT層間消息跟蹤可查看UE的接收功率，具體查看方式如下，“ID_RRC_PHY_CELLSEARCH_MEAS_IND”中包含了頻點、小區(qū)ID、RSRP等信息。由于為內(nèi)部接口消息，RSRP需要通過公式轉(zhuǎn)換得到，具體公式如下：實際的RSRP=上報的RSRP/256 - 93.3 - 18 - 21.1, 24.1, 27.1, 30.1, 33.1, 33.1（根據(jù)帶寬選擇1.4M，3M，5M，10M，15M，20M

28、），示例中的RSRP =15038/256-93.3-18-30.1 = -82dBm。圖19 UE OMT消息跟蹤Ø 如果RSRP不滿足S門限，說明信號覆蓋較差，通過選點和覆蓋核查解決；Ø 如果無法重新選點考慮降低駐留門限進行測試；Ø 如果小區(qū)RSRP高于駐留門限但仍無法駐留，則請聯(lián)系IOT人員協(xié)助定位。3.1.2 隨機接入過程問題定位指導(dǎo)隨機接入過程是指UE發(fā)送Preamble到eNB收到MSG5的過程。該過程問題定位主要通過eNB小區(qū)跟蹤、eNB L1 TTI跟蹤、eNB UU口跟蹤、UE TTI跟蹤、UE OMT信令跟蹤、UE OMT層間消息進行對比分析。

29、以下為用戶Attach流程中隨機接入的時序圖，供參考。由于上下行調(diào)度都是eNB控制的，其下行傳輸?shù)男畔⒍紱]有嚴格的限制，一般只要滿足定時器不超時即可，而UE側(cè)上下行資源都是eNb控制，所以對UE上行發(fā)送會有嚴格的時序控制（ACK信息反饋是4個TTI，UL Grant到上行發(fā)PUSCH是4個TTI，SRI必須在分配的資源上發(fā)，發(fā)MSG3是收到RAR后的6、7個TTI發(fā)）。隨機接入時序圖問題1：UE發(fā)起了Attach，而UE沒有收到RAR消息；UE發(fā)起了Attach，而UE卻沒有發(fā)送RAR_SETUP_REQ；UE發(fā)起了Attach，而eNB沒有收到MSG3消息；1、問題確認確認UE發(fā)起了ATTA

30、CH，通過UE OMT的空口消息進行確認。圖202、確認UE是否收到RAR消息，出現(xiàn)Mac recv rar succ表示UE已經(jīng)收到RAR消息。圖21如果UE沒有收到RAR消息，一般的，UE OMT或串口出現(xiàn)如下打印1） 出現(xiàn)RAR超時：該信息表示UE沒有收到RAR的DL Grant。（OMT查看）2） 出現(xiàn)RAR CRC錯：該信息表示UE收到了RAR的DL Grant，但是PDSCH出現(xiàn)CRC錯。（OMT查看）3） 出現(xiàn)RAR匹配失敗，并出現(xiàn)超時。該信息表明UE收到了RAR消息，但與發(fā)送的PREAMBLE信息不匹配，該信息并不包含自己的RAR信息。UE在發(fā)送RAR消息后，會一直去盲檢PDC

31、CH。如果有多個UE同時發(fā)起RAR信息，而eNB并不是同時調(diào)度RAR信息；或者如果UE在發(fā)Preamble的時刻有其他UE同時接入或存在RACH虛警，而eNB沒有檢測到該UE的Preamble信息（具體原因有很多，包括信道原因、發(fā)射功率等）；或者eNB檢測Preamble錯誤，此時就會出現(xiàn)RAR不匹配等信息。（提交研發(fā)通過串口查看）比較容易出現(xiàn)的是Preamble錯誤，而且引起Preamble錯誤的原因為UE位置或eNB上下行通道時延不對齊導(dǎo)致，該問題的典型現(xiàn)象為eNB檢測到的Preamble ID與UE實際發(fā)送的Preamle ID相差1。一般的，可以通過設(shè)置eNB接入范圍規(guī)避。如果需要進一

32、步定位和確認問題可以通過以下方式，核對eNB和UE的TTI級信息進行進一步定位。（1）核對UE和eNB的Preamble信息，分析eNB是否收到了UE發(fā)送的Preamble ID。具體查看方式如下：用LAE打開UE TTI跟蹤文件。查看L2->PRACH->PreambleID字段（示例中PreambleID=29，發(fā)送時刻的幀號為296，子幀號為3，下面用296.3描述幀號子幀號）。 圖22 UE側(cè)TTI跟蹤中RACH信息用LAE打開eNB CELL DT跟蹤文件，查看PreambleID為29的記錄。Ø 如果無法查找到，則表示eNB沒有檢測到PreambleID。（文

33、件中PreambID、RID對應(yīng)的值為PreambleID）。Ø 如果找到相同的PreambleID，表明eNB收到了UE發(fā)送的Preamble。如果幀號子幀號不匹配，說明這個記錄不是正確的記錄。如果eNB沒有收到Preamble ID，。Ø 確認UE發(fā)射功率是否正常。Ø 核對PRACH配置是否正確。（2）核對eNB和UE的RAR消息，分析UE是否收到eNB發(fā)送的RAR消息。用LAE打開CELL DT跟蹤文件，查看PreambleID為29的RAR：Ø 通過LAE分析UE TTI跟蹤：n 如果UE檢測到RA-RNTI加擾的PDSCH且TTI與eNB側(cè)相對

34、應(yīng)，表明UE收到了RAR消息。示例中RAR TTI為296.9。 圖23 UE下行接收RAR消息信息n 如果UE沒有收到RAR消息則通過UE TTI跟蹤的測量信息進行進一步分析：u 在UE接收RAR消息前，TTI 跟蹤沒有記錄相關(guān)測量值，無法進一步分析是什么原因?qū)е聼o法收到RAR消息。（3）核對UE和eNB MSG3消息，確認eNB是否收到UE發(fā)送的MSG3消息。首先，通過UE OMT跟蹤可以確認UE發(fā)送MSG3（RRC_CONN_REQ）。該信息表明了UE L3已經(jīng)發(fā)送了MSG3，但并不表明UE L1確實已經(jīng)將消息發(fā)送給了eNB，例如：最常見的，如果UE沒有接到UL GRANT，UE就無法發(fā)

35、送MSG3。可以通過UE TTI跟蹤進行進一步分析。UE在發(fā)送RACH后第1次上行PUSCH傳輸?shù)臄?shù)據(jù)就是MSG3消息，且Msg3是Tmp C-RNTI加擾的?？梢詮腢E TTI跟蹤觀察到492.7上發(fā)送了Tmp C-RNTI加擾的PUSCH:圖24 UE L1 TTI上行跟蹤信息eNB側(cè)查看是否收到Msg3：eNB一般在發(fā)送RAR后的10個TTI內(nèi)收到MSG3消息。n 如果MSG3 CRC錯誤，可以比對一下MSG3的調(diào)度信息：u ENB記錄的信息包括：RB0_RB1_Num（RB位置、RB數(shù)），Modu（調(diào)制方式），SRS（存在SRS指示）。u UE側(cè)信息包括：Prb0/Prb1（RB位置）

36、，RbNum（RB數(shù)），調(diào)制方式，CellSrs/UESrs（存在SRS指示）n 如果MSG3 CRC錯誤，通過測量值判斷是否是由于SINR低導(dǎo)致eNB無法解調(diào)：u 如果SINR低于-2dB，可認為已經(jīng)低于解調(diào)門限。u 如果RSRP低于-130dBm，可認為接收功率接近低噪。u 如果RSRP值-SINR明顯高于低噪（-130dBm）可認為干擾較大。（4）核對eNB和UE MSG4消息，確認UE是否收到MSG4消息：1、確認eNB下發(fā)了MSG4消息首先通過LMT UU口跟蹤可以查看L3是否發(fā)送了MSG4，具體查看方式如下：在UU口跟蹤中如果eNB收到MSG3（RRC_CONN_REQ）消息后，是

37、否發(fā)送了MSG4（RRC_CONN_SETUP）。圖25對于MSG4為信令，在系統(tǒng)中其調(diào)度優(yōu)先級比較高，在通常情況下LMT上觀察到MSG4，就可以認為eNB已經(jīng)發(fā)送給了UE。當然，還可以通過以下方式確認MSG4是否被調(diào)度：Ø 通過LAE打開eNB IFTS跟蹤，查看TB0_RRC Message Type字段為RRC_CONN_SETUP的記錄。如下圖所示eNB在299.5調(diào)度了Msg4。 圖26 ENB L2 TTI下行跟蹤信息n 如果eNB沒有下發(fā)MSG4消息，通過采集eNB CHR信息分析具體原因，建議交由研發(fā)人員進行定位分析。2、確認UE收到了MSG4：Ø 方法1：

38、通過UE OMT查看UE是否收到MSG4（RRC_CONN_SETUP）。示例如下。圖27 MSG4指示n 如果UE沒有收到MSG4可以通過TTI跟蹤確認是否是PDCCH檢測不到，還是PDSCH CRC錯誤導(dǎo)致。通過UE的TTI跟蹤進行核對。一般的，RAR消息后的第1個PDSCH為MSG4調(diào)度，時刻點在收到RAR消息的20ms內(nèi)。如果在收到RAR消息較長時間內(nèi)沒有解到PDCCH，可認為UE沒有檢測到PDCCH。ü 如果UE沒有收到PDCCH，可根據(jù)記錄的RSRP、SINR、頻偏等測量量以及CCE個數(shù)等調(diào)度信息分析PDCCH漏檢。u 一般的，10M、20M帶寬下信令消息的PDCCH固定

39、采用CCE個數(shù)為4進行調(diào)度，PDSCH采用MCS=1階調(diào)度。一般的，當SINR小于-5可認為低于PDCCH（CCE=4）的解調(diào)門限。u 一般的，如果RSRP-SINR明顯高于UE底噪（-124dBm），可認為干擾較大。ü 如果UE收到PDCCH，可根據(jù)UE TTI跟蹤查看PUSCH CRC校驗結(jié)果。下面的示例中表示UE在299.5接收到Msg4消息，且CRC正確。圖28 UE TTI下行跟蹤信息Ø 方法2：通過eNB側(cè)的控制信道PUCCH的上的ACK反饋信息進行分析。協(xié)議規(guī)定eNB下發(fā)PDSCH，UE需要在4個TTI后（TDD反饋方式參看協(xié)議36.213）反饋ACK信息，如

40、果UE正確解到PDSCH，反饋ACK；如果解調(diào)錯誤則反饋NACK。而ACK有兩種方式傳送，一種是隨路，也就是在PUSCH上傳輸；一種是PUCCH。n 一般的，如果反饋的為DTX，且ACKPWR接近低噪（-130dBm）或、ACKSINR為-10dB或更低，可認為UE沒有收到PDCCH。注：ACKPwr為PUCCH RB導(dǎo)頻上的總功率，由于PUCCH RB可能為多用戶碼分復(fù)用，所以可能出現(xiàn)ACK PWR功率較高，但SINR很低的情況，所以這里描述的在單用戶情況下有效。n 一般的，如果反饋的結(jié)果為NACK，可認為UE PDSCH CRC錯誤。u PDSCH CRC錯誤時，根據(jù)UE測量信息分析原因，

41、如果SINR低于解調(diào)能力，l 排查是否是在小區(qū)邊界，導(dǎo)致接收信號功率過低l 排查是否存在鄰區(qū)干擾以下表示eNB在300.2收到PUCCH上反饋的ACK。根據(jù)協(xié)議36.213，bundling模式下299.5的ACK應(yīng)該在300.2反饋。圖29 PUCCH的ACK反饋3、核對UE和eNB MSG5消息，確認eNB是否收到MSG5消息。1）確認UE L3是否發(fā)送了MSG5消息。通過OMT空口信令跟蹤，查看UE是否發(fā)送了MSG5（RRC_CONN_SETUP_CMP），如果界面顯示有MSG5消息，但并不表示UE已經(jīng)發(fā)送了MSG5給eNB。這是因為MSG5為第1條上行動態(tài)調(diào)度，需要向eNB發(fā)送SRI請

42、求，ENB收到SRI后才會給UE調(diào)度。如果開了預(yù)調(diào)度，也有可能不發(fā)送SRI。以下是預(yù)調(diào)度關(guān)閉的分析，預(yù)調(diào)度打開時可能沒有SRI。圖30 MSG5指示2） 確認UE是否發(fā)送了SRI請求。通過UE L1 TTI上行跟蹤的SRI是否為“有”。下例所示，UE在300.3發(fā)送了SRI請求。圖31 UE L1 TTI上行跟蹤3） 確認eNB是否收到了SRI請求。通過eNB L1 TTI上行跟蹤觀察檢測到收到SRI跟蹤，如下例所示，eNB在300.3中檢測到了SRI說明eNB收到了SRI請求。圖32 eNB L1 TTI跟蹤4） 確認eNB是否進行了上行調(diào)度。通過eNB L1 TTI下行跟蹤觀察是否發(fā)送了U

43、L GRANT，或者通過eNB L1 TTI上行跟蹤觀察上行調(diào)度結(jié)果。協(xié)議規(guī)定ENB下發(fā)ULGANT后，UE會在4個TTI后（TDD為4個TTI后第一個上行TTI）在PUSCH上傳信息。所以下行跟蹤記錄的發(fā)送UL GRANT的時刻和上行跟蹤記錄的PUSCH調(diào)度信息會相差4個TTI。如圖所示，eNB在300.6調(diào)度了UL Grant：圖33 eNB UL Grant指示5） 確認UE是否收到了UL GRANT，并正確發(fā)送了PUSCH。UE TTI上下行跟蹤可以看到UE是否解到了UL GRANT和發(fā)送了PUSCH，協(xié)議規(guī)定UE在收到UL Grant的4TTI（TDD為4個TTI后第一個上行子幀）后

44、發(fā)送上行PUSCH，所以UL Grant和上行PUSCH跟蹤信息會相差4個TTI。如圖所示，UE在300.6收到了UL Grant：圖34 UE UL Grant接收指示6） 確認eNB是否收到MSG5，通過eNB上行TTI跟蹤分析上行接收情況，示例所示301.2收到了PUSCH，并且CRC正確：圖35 上行PUSCH接收Ø 如果上行調(diào)度CRC錯誤，可通過調(diào)度信息、DMRS測量、SRS測量等信息進行分析。n 一般的，如果DMRS Rsrp（子載波級的eNB接收功率，）接近低噪（-130dBm），說明接收功率很低。u 一般的，需要通過UE發(fā)送功率和UE路損推算接收到的RSRP是否合理。

45、UE發(fā)射功率可以這樣估算：Pwr = P0 + alpha * 下行PL + f(i) + 10logM。其中P0、Alpha可通過系統(tǒng)消息獲取、PL可通過路損計算得到（PL=RS-下行RSRP），系統(tǒng)f（i）=-1，M為調(diào)度的RB個數(shù)。如果計算得到的Pwr大于UE最大發(fā)射功率，則Pwr=Ue最大發(fā)射功率。ENB接收功率RSRP=Pwr 10log(12*M) 上行PL。u 一般的，如果RSRP-SINR明顯高于低噪，說明有較大干擾。請排查環(huán)境是否存在干擾源或其他干擾因素。u 一般的，如果下行RSRP為中近點，而上行接收的RSRP接近底噪（-130dBm），可能為UE沒有發(fā)送數(shù)據(jù)，如果UE跟蹤

46、顯示UE發(fā)了數(shù)據(jù)，可以分析一下UE和eNB的資源配置（RB位置和RB數(shù)等配置信息）。u 一般的，還可以分析一下SRS測量得到的TA是否合理。如果MCS階數(shù)很高，而TA提前，比較容易造成CRC錯誤。3.1.3 安全模式、RB重配問題定位指導(dǎo)MME無響應(yīng)或MME主動發(fā)起的釋放造成的用戶釋放一般是基站發(fā)起INIT_UE_MSG后,等待核心網(wǎng)的初始上下文建立請求消息超時(即核心網(wǎng)沒有下發(fā)初始上下文請求消息),然后由基站主動發(fā)起的用戶釋放, 在這種情況下需要跟核心網(wǎng)側(cè)維護人員確認一下為什么沒有發(fā)起初始上下文建立請求消息；另一種情況是基站發(fā)起INIT_UE_MSG后,核心網(wǎng)立即下發(fā)了釋放消息UE_CONT

47、EXT_REL_CMD,在這種情況下,首先確認一下INIT_UE_MSG中的PLMNID與基站側(cè)的配置是否一致,如果不一致,需要重新配置后再接入；如果已經(jīng)一致,則需要跟核心網(wǎng)側(cè)維護人員確認一下核心網(wǎng)下發(fā)釋放消息的原因；具體顯示的跟蹤樣例如下所示:圖36 信令跟蹤樣例UE無響應(yīng)造成用戶釋放一般UE無響應(yīng)造成的釋放有四種情況:1、 基站下發(fā)了RRC_CONN_SETUP消息沒有收到UE的RRC_CONN_SETUP_CMP消息;2、 基站下發(fā)了RRC_SECUR_MODE_CMD消息沒有收到UE的RRC_SECUR_MODE_CMP消息;3、 基站下發(fā)了RRC_UE_CAP_ENQUIRY消息沒有

48、收到UE的RRC_UE_CAP_INFO消息;4、 基站下發(fā)了RRC_CONN_RECFG消息沒有收到UE的RRC_CONN_RECFG_CMP消息;因為第一種情況正處于RRC連接建立狀態(tài),所以不需要回核心網(wǎng)響應(yīng),其它三種情況都需要回核心網(wǎng)初始上下文建立失敗響應(yīng)(即消息INIT_CONTEXT_SETUP_FAIL);在發(fā)生了上述四種情況后,需要在UE那里確認一下基站側(cè)下發(fā)的這條消息(比如RRC_CONN_SETUP)UE的跟蹤上是否收到,如果沒有收到,則需要查一下基站發(fā)出的這條消息在基站的L2處是否收到并下發(fā)給了UE,并查看一下基站發(fā)出的這條消息UE的L2是否收到并傳遞給了UE的L3;如果U

49、E的L3收到了這條消息,則需要查看一下UE是否發(fā)出響應(yīng)基站的消息(比如RRC_CONN_SETUP_CMP);跟蹤樣例如下所示:圖37 信令跟蹤樣例上圖是因為沒有收到UE的RRC_SECUR_MODE_CMP消息導(dǎo)致超時造成的用戶釋放;無線資源申請失敗導(dǎo)致用戶釋放基站在完成了安全的配置與UE能力的獲取后會向小區(qū)申請資源,如果申請失敗,則會向核心網(wǎng)返回初始上下文建立失敗響應(yīng)INIT_CONTEXT_SETUP_FAIL;原因值一般會填寫radio resource not available(25);如下圖所示;在這種情況下,一般都是向小區(qū)申請資源失敗導(dǎo)致的初始上下文建立失敗;一般可以先導(dǎo)出MM

50、L的參數(shù)配置,然后與默認參數(shù)進行對比,查看一下是否一些與小區(qū)相關(guān)的參數(shù)配置錯誤（可以與基線比較，參數(shù)相關(guān)參見基線參數(shù)配置，參數(shù)基線可以從隨版本發(fā)布的文檔包獲?。?如果參數(shù)沒有問題,則請把IFTS打開,將跟蹤反饋給研發(fā)人員確認問題的原因；跟蹤如下所示:圖38 信令跟蹤樣例GTPU資源申請失敗基站在完成了安全的配置與UE能力的獲取后并向小區(qū)申請資源,會向TRM申請GTPU資源,如果申請資源失敗則會向核心網(wǎng)返回初始上下文建立失敗響應(yīng)INIT_CONTEXT_SETUP_FAIL;原因值一般會填寫transport resource unavailable(0);如下圖所示;跟蹤如下所示:圖39 信令

51、跟蹤樣例在這種情況下,首先查看一下MML中的IPPATH是否配置正確,如果已經(jīng)配置正確,則查看請初始上下文建立請求消息(INIT_CONTEXT_SETUP_REQ消息)中transportlayeraddress的信元值是否為配置的IPPATH值,如果不一樣則需要確認一下是我們配置錯誤還是核心網(wǎng)填寫錯誤。如果以上都不符合則開啟IFTS跟蹤,將跟蹤日志反饋給研發(fā)人員確認問題的原因；圖40 信令跟蹤樣例由基站主動發(fā)起的用戶釋放如果UE釋放是由基站主動發(fā)起的，則一般是基站先發(fā)起UE_CONTEXT_REL_REQ消息,如下所示,如果以上都不符合則開啟IFTS跟蹤,將跟蹤日志反饋給研發(fā)人員確認問題的

52、原因圖41 信令跟蹤樣例由UE主動發(fā)起的用戶正常釋放如果UE釋放是正常的關(guān)機所致,會由核心網(wǎng)主動發(fā)起UE_CONTEXT_REL_CMD,且釋放原因值為nas_detach.如下圖的跟蹤所示:圖42 信令跟蹤樣例3.1.4 S1接口異常問題定位S1接口異常通?？梢圆捎靡韵路绞竭M行排查。圖43 S1接口異常排查思路（1） 首先DSP S1INTERFACE查看以下四個信息：S1InterfaceState（S1接口狀態(tài)），S1SctpLinkState（SCTP鏈路狀態(tài)），S1InterfaceIsBlock（S1接口是否處于閉塞狀態(tài)），MmeIsOverLoad（MME是否處于過載狀態(tài)），主要

53、情況分為以下四種，1) S1SctpLinkState為異常，轉(zhuǎn)（2）； 2) S1SctpLinkState為正常，S1InterfaceState為異常，轉(zhuǎn)（7）；3) S1SctpLinkState為正常，S1InterfaceState為正常，S1InterfaceIsBlock處于閉塞,轉(zhuǎn)(14)；4) S1SctpLinkState為正常，S1InterfaceState為正常，MmeIsOverLoad處于過載(15)；（2） DSP SCTPLINK查看SCTP鏈路狀態(tài)是否OK，A：是，轉(zhuǎn)（5）B：否，轉(zhuǎn)（3）（3） 查看ENODEB與MME連接的網(wǎng)線是否插好，端口是否與配置的

54、SCTP端口號一致:A：插好且一致，轉(zhuǎn)（4）B：沒有插好或不一致，請將網(wǎng)線插到配置的位置;（4） 打開LMT上的SCTP跟蹤，查看SCTP跟蹤中是否與MME正常通信A：正常通信，轉(zhuǎn)（5）B：不正常通信，轉(zhuǎn)（6）（5） RMV S1INTERFACEID刪除該S1接口重新添加一遍，再查看S1接口信息，如果仍然有問題，轉(zhuǎn)(17)；（6） 聯(lián)系ROSA的同事定位問題原因，如果時間緊急，請刪除該SCTP鏈路后重新添加，再轉(zhuǎn)（4）；（7） 如果是ENODEB系統(tǒng)首次起來，查看小區(qū)：DSP CELL，判斷小區(qū)是否OK：A：是，轉(zhuǎn)（8）B：否，轉(zhuǎn)（16）（8） 打開LMT跟蹤的S1接口跟蹤，查看S1接口是否

55、持續(xù)向MME發(fā)送S1_SETUP_REQ消息:A：是，轉(zhuǎn)（9）B：否，轉(zhuǎn)（5）（9） MME是否回響應(yīng):A:是,轉(zhuǎn)(13)B:否,轉(zhuǎn)(10)（10） 通過DSP SCTPLINK查看SCTP鏈路狀態(tài)是否為閉塞狀態(tài),A:是,轉(zhuǎn)(11);B:否,轉(zhuǎn)(12)（11） 解閉塞;（12） 聯(lián)系MME維護人員,查詢是否MME故障（13） 回響應(yīng)S1_SETUP_FAIL,判斷當前基站是否支持協(xié)議兼容,如果支持,通過MOD RRGLOBALSWITCH來修改相關(guān)協(xié)議版本,如果不支持,轉(zhuǎn)(17);（14） 通過UBL S1INTERFACE解閉塞;（15） MME已經(jīng)處于過載狀態(tài),不允許用戶接入;（16） 請

56、定位小區(qū)故障原因;（17） 請聯(lián)系研發(fā)人員；3.2 常見優(yōu)化方法3.2.1 優(yōu)化覆蓋從RRCConnReq重發(fā)次數(shù)來看，現(xiàn)網(wǎng)有下行SetUp丟失的情況。考慮到現(xiàn)網(wǎng)部分場景覆蓋比較差，出現(xiàn)下行SetUp丟失的情況可能比較多。SetUp為動態(tài)調(diào)度，碼率<0.117，相應(yīng)MCS=0，基于此，SetUp已經(jīng)以低階高功率發(fā)送，再優(yōu)化SetUp的意義不大，即使SetUp能發(fā)下來，后面的流程也很難走下去。因此，主要還是要優(yōu)化RF來優(yōu)化覆蓋，以提高接入成功率。3.2.2 MSG3受限的優(yōu)化方法若判斷MSG3受限，可以通過提高功率攀升步長和前導(dǎo)初始接收目標功率值的方法提升MSG3成功率，修改命令為MOD RACHCFG，參數(shù)為PwrRampingStep和PreambInitRcvTargetPwr。3.2.3 Preamble的優(yōu)化如果定位發(fā)現(xiàn)可能是Preamble受限導(dǎo)致，可以將Preamble的Format格式設(shè)置為Format1、2、3，修改命令為MOD CELL，參數(shù)名稱為