1、產(chǎn)品名稱Product name密級Confidentiality levelLTE TDD內(nèi)部公開產(chǎn)品版本Product versionTotal 60pages 共60頁LTE TDD問題定位和優(yōu)化指導(dǎo)書-接入篇本文介紹了用戶接入的流程和用戶接入失敗時(shí)問題定位的基本方法，常見問題排查方法部分主要面向網(wǎng)絡(luò)維護(hù)人員，介紹了一些常見問題的定位排查手段和方法，主要應(yīng)用場景為通過KPI指標(biāo)發(fā)現(xiàn)問題，通過CHR、告警日志、標(biāo)口跟蹤、UE側(cè)log進(jìn)行問題定位。概念和基本原理基本概念（1）用戶Attach流程：圖1 用戶接入流程（2）隨機(jī)接入流程介紹隨機(jī)接入過程的發(fā)生有以下五種場景：從空閑態(tài)轉(zhuǎn)到連接態(tài)的初

2、始接入；無線鏈接失敗后的接入；切換過程中的接入；當(dāng)UE處于連接態(tài)時(shí)下行數(shù)據(jù)到達(dá)時(shí)因?yàn)槟承┰蛐枰S機(jī)接入，如上行失步時(shí)有下行數(shù)據(jù)到達(dá)；當(dāng)UE處于連接態(tài)時(shí)上行數(shù)據(jù)到達(dá)時(shí)因?yàn)槟承┰蛐枰S機(jī)接入，如上行失步時(shí)有上行行數(shù)據(jù)到達(dá)；隨機(jī)接入分為競爭接入與非競爭接入兩種，其中競爭隨機(jī)接入適用于上述1、2、5三種場景，而非競爭隨機(jī)接入適用于3、4兩種場景。隨機(jī)接入基本流程如下：圖2 隨機(jī)接入流程圖（左：基于競爭的隨機(jī)接入 右：基于非競爭的隨機(jī)接入）接入流程話統(tǒng)介紹隨機(jī)接入話統(tǒng)隨機(jī)接入過程分為基于競爭的隨機(jī)接入和基于非競爭的隨機(jī)接入兩種基本過程。“RA測量(小區(qū))(RA.Cell)”統(tǒng)計(jì)小區(qū)內(nèi)不同隨機(jī)接入過程

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

4、的RRC信令消息，目的是通知UE RRC連接的建立結(jié)果及相關(guān)配置信息。RRC連接建立成功話統(tǒng)統(tǒng)計(jì)小區(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)計(jì)方法圖3 RRC建立統(tǒng)計(jì)點(diǎn)【A點(diǎn)】（1）指標(biāo)L.RRC.ConnReq.Att加1，不統(tǒng)計(jì)重發(fā)的次數(shù)。Case1：eNB下發(fā)RRC_Conn_Setup消息后，在T300定時(shí)器超時(shí)前，收到相

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

6、Conn_Setup_Cmp丟失不會觸發(fā)重建，發(fā)起重建的前提是安全已經(jīng)激活。（2）如果RRC Connection Request消息信元Establishment Cause為“emergency”，指標(biāo)L.RRC.ConnReq.Att.Emc加1。（3）如果RRC Connection Request消息信元Establishment Cause為“highPriorityAccess”，指標(biāo)L.RRC.ConnReq.Att.HighPri加1。（4）如果RRC Connection Request消息信元Establishment Cause為“mt-Access”，指標(biāo)L.RRC.

7、ConnReq.Att.Mt加1。（5）如果RRC Connection Request消息信元Establishment Cause為“mo-Singnalling”，指標(biāo)L.RRC.ConnReq.Att.MoSig加1。（6）如果RRC Connection Request消息信元Establishment Cause為“mo-Data”，指標(biāo)L.RRC.ConnReq.Att.MoData加1?！綛點(diǎn)】當(dāng)eNodeB下小區(qū)接收到UE發(fā)送的RRC Connection Request消息并下發(fā)RRC Connection Setup消息給UE時(shí)，指標(biāo)L.RRC.ConnSetup加1?！?/p>

8、C點(diǎn)】當(dāng)eNodeB收到UE返回的RRC Connection Setup Complete消息時(shí)統(tǒng)計(jì)相應(yīng)指標(biāo)，L.RRC.ConnReq.Succ加1。RRC Setup Success Rate計(jì)算）/(L.RRC.ConnReq.Att)*100%RRC連接建立失敗話統(tǒng)統(tǒng)計(jì)小區(qū)內(nèi)不同原因的RRC連接建立失敗的次數(shù)及總的RRC連接失敗次數(shù)。RRC Connection Reject消息是eNodeB發(fā)送給UE的RRC信令消息，目的是通知UE本次接入過程被eNodeB拒絕。ERAB承載建立嘗試話統(tǒng)統(tǒng)計(jì)小區(qū)E-RAB建立嘗試總次數(shù)。E-RAB建立過程一般由UE在需要向無線網(wǎng)絡(luò)申請服務(wù)時(shí)主動發(fā)起

9、，并通過初始UE上下文建立流程或E-RAB建立流程完成建立。E-RAB建立嘗試總次數(shù)用于統(tǒng)計(jì)UE發(fā)起的總的E-RAB建立嘗試次數(shù)。ERAB承載建立成功話統(tǒng)統(tǒng)計(jì)小區(qū)E-RAB建立成功總次數(shù)。E-RAB建立過程一般由UE在需要向無線網(wǎng)絡(luò)申請服務(wù)時(shí)主動發(fā)起，并通過初始UE上下文建立流程或E-RAB建立流程完成建立。E-RAB建立嘗試總次數(shù)用于統(tǒng)計(jì)UE發(fā)起的總的E-RAB建立成功次數(shù)。話統(tǒng)統(tǒng)計(jì)方法 圖4如 HYPERLINK mk:MSITStore:C:DOCUME1L001401LOCALS1Tempnotes6030C8eNodeB性能指標(biāo)參考.chm:/lte/lte-enodeb-perfo

10、rmance-counter-reference/MtType_12.html l MtType_12_fig1#MtType_12_fig1 3、4中A點(diǎn)所示，當(dāng)eNodeB收到來自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息時(shí)統(tǒng)計(jì)該指標(biāo)。如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息中要求同時(shí)建立多個(gè)E-RAB，則相應(yīng)指標(biāo)按各個(gè)業(yè)務(wù)的QCI分別進(jìn)行累加。ERAB Setup Success Rate計(jì)算公式）/()*100%ERAB承載建立失敗話統(tǒng)統(tǒng)計(jì)小區(qū)內(nèi)E-

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

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

13、的msg3的信道質(zhì)量和SRS的SINR是否較差（弱覆蓋），是否存在TOP用戶。（7）針對TOP站點(diǎn)進(jìn)行針對性的標(biāo)準(zhǔn)信令跟蹤、干擾檢測進(jìn)行分析。（8）如果標(biāo)準(zhǔn)信令和干擾檢測無異常，將一鍵式日志，標(biāo)口跟蹤，干擾檢測結(jié)果返回給開發(fā)人員分析。 詳細(xì)流程圖如下：圖5 接入問題優(yōu)化流程圖TOP小區(qū)篩選通過M2000導(dǎo)出全網(wǎng)每日話統(tǒng)文件，按照（）次數(shù)從高到低排序，結(jié)合接入成功率，選出TOP10站點(diǎn)接入成功率低的小區(qū)。 按照（L.E-RAB.AttEst-）次數(shù)從高到低排序，結(jié)合ERAB建立成功率選出TOP10 ERAB建立成功率低的站點(diǎn)。檢查TOP小區(qū)的狀態(tài)是否正常，可以在M2000上，通過MML命令“DS

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

15、失敗原因話統(tǒng)可以得出得出ERAB建立失敗原因分布：。初始上下文建立失敗的幾種現(xiàn)象：1 基站下發(fā)了RRC_SECUR_MODE_CMD消息,收到UE的RRC_SECUR_MODE_FAIL消息2 基站下發(fā)了RRC_SECUR_MODE_CMD消息,沒有收到UE的RRC_SECUR_MODE_CMP消息3 基站下發(fā)了RRC_CONN_RECFG消息,沒有收到UE的RRC_CONN_RECFG_CMP消息4 基站下發(fā)了RRC_UE_CAP_ENQUIRY消息,沒有收到UE的RRC_UE_CAP_INFO消息初始上下文建立請求消息超時(shí)，需要核心網(wǎng)側(cè)配合，查看核心網(wǎng)側(cè)在收到ENB傳遞的NAS Attac

16、h消息后的處理流程。初始上下文建立失敗需要檢查基站配置，查看告警，跟蹤Uu口，S1口進(jìn)行分析。TOP用戶分析通過CHR日志分析可以獲取RRC建立失敗和ERAB建立失敗TOP用戶的TMSI。在CHR數(shù)據(jù)中，可以通過TMSI來確定是否為同一個(gè)用戶，具體方法如下：當(dāng)前華為核心網(wǎng)TMSI分配的機(jī)制是對于同一個(gè)IMSI用戶，TMSI的右起第三個(gè)byte的數(shù)據(jù)進(jìn)行隨機(jī)賦值，即某用戶的TMSI中只有第三個(gè)字節(jié)的8bit發(fā)生變化（如AA * BB CC）就是同一用戶。如下圖所示，C0 * 00 05就是同一個(gè)用戶。使用INSIGHTSHARP工具分析同一TMSI用戶的多個(gè)接入流程，查看L2_SRB_LOG字段

17、記錄的接入時(shí)上行信道質(zhì)量DMRS_SINR和DMRS_RSRP，可以初步確認(rèn)用戶是否處于上行弱覆蓋區(qū)域：DMRS_SINR0db或DMRS_RSRPPRACH-PreambleID字段（示例中PreambleID=29，發(fā)送時(shí)刻的幀號為296，子幀號為3，下面用296.3描述幀號子幀號）。 圖22 UE側(cè)TTI跟蹤中RACH信息用LAE打開eNB CELL DT跟蹤文件，查看PreambleID為29的記錄。如果無法查找到，則表示eNB沒有檢測到PreambleID。（文件中PreambID、RID對應(yīng)的值為PreambleID）。如果找到相同的PreambleID，表明eNB收到了UE發(fā)送的

18、Preamble。如果幀號子幀號不匹配，說明這個(gè)記錄不是正確的記錄。如果eNB沒有收到Preamble ID，。確認(rèn)UE發(fā)射功率是否正常。核對PRACH配置是否正確。（2）核對eNB和UE的RAR消息，分析UE是否收到eNB發(fā)送的RAR消息。用LAE打開CELL DT跟蹤文件，查看PreambleID為29的RAR：通過LAE分析UE TTI跟蹤：如果UE檢測到RA-RNTI加擾的PDSCH且TTI與eNB側(cè)相對應(yīng)，表明UE收到了RAR消息。示例中RAR TTI為296.9。 圖23 UE下行接收RAR消息信息如果UE沒有收到RAR消息則通過UE TTI跟蹤的測量信息進(jìn)行進(jìn)一步分析：在UE接收

19、RAR消息前，TTI 跟蹤沒有記錄相關(guān)測量值，無法進(jìn)一步分析是什么原因?qū)е聼o法收到RAR消息。（3）核對UE和eNB MSG3消息，確認(rèn)eNB是否收到UE發(fā)送的MSG3消息。首先，通過UE OMT跟蹤可以確認(rèn)UE發(fā)送MSG3（RRC_CONN_REQ）。該信息表明了UE L3已經(jīng)發(fā)送了MSG3，但并不表明UE L1確實(shí)已經(jīng)將消息發(fā)送給了eNB，例如：最常見的，如果UE沒有接到UL GRANT，UE就無法發(fā)送MSG3?？梢酝ㄟ^UE TTI跟蹤進(jìn)行進(jìn)一步分析。UE在發(fā)送RACH后第1次上行PUSCH傳輸?shù)臄?shù)據(jù)就是MSG3消息，且Msg3是Tmp C-RNTI加擾的?？梢詮腢E TTI跟蹤觀察到上發(fā)

20、送了Tmp C-RNTI加擾的PUSCH:圖24 UE L1 TTI上行跟蹤信息eNB側(cè)查看是否收到Msg3：eNB一般在發(fā)送RAR后的10個(gè)TTI內(nèi)收到MSG3消息。如果MSG3 CRC錯(cuò)誤，可以比對一下MSG3的調(diào)度信息：ENB記錄的信息包括：RB0_RB1_Num（RB位置、RB數(shù)），Modu（調(diào)制方式），SRS（存在SRS指示）。UE側(cè)信息包括：Prb0/Prb1（RB位置），RbNum（RB數(shù)），調(diào)制方式，CellSrs/UESrs（存在SRS指示）如果MSG3 CRC錯(cuò)誤，通過測量值判斷是否是由于SINR低導(dǎo)致eNB無法解調(diào)：如果SINR低于-2dB，可認(rèn)為已經(jīng)低于解調(diào)門限。如果R

21、SRP低于-130dBm，可認(rèn)為接收功率接近低噪。如果RSRP值-SINR明顯高于低噪（-130dBm）可認(rèn)為干擾較大。（4）核對eNB和UE MSG4消息，確認(rèn)UE是否收到MSG4消息：1、確認(rèn)eNB下發(fā)了MSG4消息首先通過LMT UU口跟蹤可以查看L3是否發(fā)送了MSG4，具體查看方式如下：在UU口跟蹤中如果eNB收到MSG3（RRC_CONN_REQ）消息后，是否發(fā)送了MSG4（RRC_CONN_SETUP）。圖25對于MSG4為信令，在系統(tǒng)中其調(diào)度優(yōu)先級比較高，在通常情況下LMT上觀察到MSG4，就可以認(rèn)為eNB已經(jīng)發(fā)送給了UE。當(dāng)然，還可以通過以下方式確認(rèn)MSG4是否被調(diào)度：通過LA

22、E打開eNB IFTS跟蹤，查看TB0_RRC Message Type字段為RRC_CONN_SETUP的記錄。如下圖所示eNB在調(diào)度了Msg4。 圖26 ENB L2 TTI下行跟蹤信息如果eNB沒有下發(fā)MSG4消息，通過采集eNB CHR信息分析具體原因，建議交由研發(fā)人員進(jìn)行定位分析。2、確認(rèn)UE收到了MSG4：方法1：通過UE OMT查看UE是否收到MSG4（RRC_CONN_SETUP）。示例如下。圖27 MSG4指示如果UE沒有收到MSG4可以通過TTI跟蹤確認(rèn)是否是PDCCH檢測不到，還是PDSCH CRC錯(cuò)誤導(dǎo)致。通過UE的TTI跟蹤進(jìn)行核對。一般的，RAR消息后的第1個(gè)PDS

23、CH為MSG4調(diào)度，時(shí)刻點(diǎn)在收到RAR消息的20ms內(nèi)。如果在收到RAR消息較長時(shí)間內(nèi)沒有解到PDCCH，可認(rèn)為UE沒有檢測到PDCCH。如果UE沒有收到PDCCH，可根據(jù)記錄的RSRP、SINR、頻偏等測量量以及CCE個(gè)數(shù)等調(diào)度信息分析PDCCH漏檢。一般的，10M、20M帶寬下信令消息的PDCCH固定采用CCE個(gè)數(shù)為4進(jìn)行調(diào)度，PDSCH采用MCS=1階調(diào)度。一般的，當(dāng)SINR小于-5可認(rèn)為低于PDCCH（CCE=4）的解調(diào)門限。一般的，如果RSRP-SINR明顯高于UE底噪（-124dBm），可認(rèn)為干擾較大。如果UE收到PDCCH，可根據(jù)UE TTI跟蹤查看PUSCH CRC校驗(yàn)結(jié)果。下

24、面的示例中表示UE在接收到Msg4消息，且CRC正確。圖28 UE TTI下行跟蹤信息方法2：通過eNB側(cè)的控制信道PUCCH的上的ACK反饋信息進(jìn)行分析。協(xié)議規(guī)定eNB下發(fā)PDSCH，UE需要在4個(gè)TTI后（TDD反饋方式參看協(xié)議）反饋ACK信息，如果UE正確解到PDSCH，反饋ACK；如果解調(diào)錯(cuò)誤則反饋NACK。而ACK有兩種方式傳送，一種是隨路，也就是在PUSCH上傳輸；一種是PUCCH。一般的，如果反饋的為DTX，且ACKPWR接近低噪（-130dBm）或、ACKSINR為-10dB或更低，可認(rèn)為UE沒有收到PDCCH。注：ACKPwr為PUCCH RB導(dǎo)頻上的總功率，由于PUCCH

25、RB可能為多用戶碼分復(fù)用，所以可能出現(xiàn)ACK PWR功率較高，但SINR很低的情況，所以這里描述的在單用戶情況下有效。一般的，如果反饋的結(jié)果為NACK，可認(rèn)為UE PDSCH CRC錯(cuò)誤。PDSCH CRC錯(cuò)誤時(shí)，根據(jù)UE測量信息分析原因，如果SINR低于解調(diào)能力，排查是否是在小區(qū)邊界，導(dǎo)致接收信號功率過低排查是否存在鄰區(qū)干擾以下表示eNB在收到PUCCH上反饋的ACK。根據(jù)協(xié)議，bundling模式下的ACK應(yīng)該在反饋。圖29 PUCCH的ACK反饋3、核對UE和eNB MSG5消息，確認(rèn)eNB是否收到MSG5消息。1）確認(rèn)UE L3是否發(fā)送了MSG5消息。通過OMT空口信令跟蹤，查看UE是

26、否發(fā)送了MSG5（RRC_CONN_SETUP_CMP），如果界面顯示有MSG5消息，但并不表示UE已經(jīng)發(fā)送了MSG5給eNB。這是因?yàn)镸SG5為第1條上行動態(tài)調(diào)度，需要向eNB發(fā)送SRI請求，ENB收到SRI后才會給UE調(diào)度。如果開了預(yù)調(diào)度，也有可能不發(fā)送SRI。以下是預(yù)調(diào)度關(guān)閉的分析，預(yù)調(diào)度打開時(shí)可能沒有SRI。圖30 MSG5指示2） 確認(rèn)UE是否發(fā)送了SRI請求。通過UE L1 TTI上行跟蹤的SRI是否為“有”。下例所示，UE在發(fā)送了SRI請求。圖31 UE L1 TTI上行跟蹤3） 確認(rèn)eNB是否收到了SRI請求。通過eNB L1 TTI上行跟蹤觀察檢測到收到SRI跟蹤，如下例所示

27、，eNB在中檢測到了SRI說明eNB收到了SRI請求。圖32 eNB L1 TTI跟蹤確認(rèn)eNB是否進(jìn)行了上行調(diào)度。通過eNB L1 TTI下行跟蹤觀察是否發(fā)送了UL GRANT，或者通過eNB L1 TTI上行跟蹤觀察上行調(diào)度結(jié)果。協(xié)議規(guī)定ENB下發(fā)ULGANT后，UE會在4個(gè)TTI后（TDD為4個(gè)TTI后第一個(gè)上行TTI）在PUSCH上傳信息。所以下行跟蹤記錄的發(fā)送UL GRANT的時(shí)刻和上行跟蹤記錄的PUSCH調(diào)度信息會相差4個(gè)TTI。如圖所示，eNB在調(diào)度了UL Grant：圖33 eNB UL Grant指示確認(rèn)UE是否收到了UL GRANT，并正確發(fā)送了PUSCH。UE TTI上下

28、行跟蹤可以看到UE是否解到了UL GRANT和發(fā)送了PUSCH，協(xié)議規(guī)定UE在收到UL Grant的4TTI（TDD為4個(gè)TTI后第一個(gè)上行子幀）后發(fā)送上行PUSCH，所以UL Grant和上行PUSCH跟蹤信息會相差4個(gè)TTI。如圖所示，UE在收到了UL Grant：圖34 UE UL Grant接收指示確認(rèn)eNB是否收到MSG5，通過eNB上行TTI跟蹤分析上行接收情況，示例所示收到了PUSCH，并且CRC正確：圖35 上行PUSCH接收如果上行調(diào)度CRC錯(cuò)誤，可通過調(diào)度信息、DMRS測量、SRS測量等信息進(jìn)行分析。一般的，如果DMRS Rsrp（子載波級的eNB接收功率，）接近低噪（-1

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

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

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

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

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

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

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

36、開啟IFTS跟蹤,將跟蹤日志反饋給研發(fā)人員確認(rèn)問題的原因圖41 信令跟蹤樣例由UE主動發(fā)起的用戶正常釋放如果UE釋放是正常的關(guān)機(jī)所致,會由核心網(wǎng)主動發(fā)起UE_CONTEXT_REL_CMD,且釋放原因值為nas_detach.如下圖的跟蹤所示:圖42 信令跟蹤樣例S1接口異常問題定位S1接口異常通?？梢圆捎靡韵路绞竭M(jìn)行排查。圖43 S1接口異常排查思路首先DSP S1INTERFACE查看以下四個(gè)信息：S1InterfaceState（S1接口狀態(tài)），S1SctpLinkState（SCTP鏈路狀態(tài)），S1InterfaceIsBlock（S1接口是否處于閉塞狀態(tài)），MmeIsOverLoad

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

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

39、：是，轉(zhuǎn)（9）B：否，轉(zhuǎn)（5）MME是否回響應(yīng):A:是,轉(zhuǎn)(13)B:否,轉(zhuǎn)(10)通過DSP SCTPLINK查看SCTP鏈路狀態(tài)是否為閉塞狀態(tài),A:是,轉(zhuǎn)(11);B:否,轉(zhuǎn)(12)解閉塞;聯(lián)系MME維護(hù)人員,查詢是否MME故障回響應(yīng)S1_SETUP_FAIL,判斷當(dāng)前基站是否支持協(xié)議兼容,如果支持,通過MOD RRGLOBALSWITCH來修改相關(guān)協(xié)議版本,如果不支持,轉(zhuǎn)(17);通過UBL S1INTERFACE解閉塞;MME已經(jīng)處于過載狀態(tài),不允許用戶接入;請定位小區(qū)故障原因;請聯(lián)系研發(fā)人員；常見優(yōu)化方法優(yōu)化覆蓋從RRCConnReq重發(fā)次數(shù)來看，現(xiàn)網(wǎng)有下行SetUp丟失的情況。考慮

40、到現(xiàn)網(wǎng)部分場景覆蓋比較差，出現(xiàn)下行SetUp丟失的情況可能比較多。SetUp為動態(tài)調(diào)度，碼率17，相應(yīng)MCS=0，基于此，SetUp已經(jīng)以低階高功率發(fā)送，再優(yōu)化SetUp的意義不大，即使SetUp能發(fā)下來，后面的流程也很難走下去。因此，主要還是要優(yōu)化RF來優(yōu)化覆蓋，以提高接入成功率。MSG3受限的優(yōu)化方法若判斷MSG3受限，可以通過提高功率攀升步長和前導(dǎo)初始接收目標(biāo)功率值的方法提升MSG3成功率，修改命令為MOD RACHCFG，參數(shù)為PwrRampingStep和PreambInitRcvTargetPwr。Preamble的優(yōu)化如果定位發(fā)現(xiàn)可能是Preamble受限導(dǎo)致，可以將Preamb

41、le的Format格式設(shè)置為Format1、2、3，修改命令為MOD CELL，參數(shù)名稱為PreambleFmt。典型案例IPPATH配置不正確導(dǎo)致用戶接入后被釋放問題描述用戶無法接入，打開IFTS跟蹤顯示如下：圖44 IFTS跟蹤樣例問題分析通過IFTS跟蹤查看釋放前的消息中是否存在如下錯(cuò)誤“GTPU setup fail”。圖45 IFTS跟蹤樣例解決措施通過RMV IPPATH刪除錯(cuò)誤的IPPATH配置，通過ADD IPPATH添加正確的IPPATH。圖46 添加正確的IPPATHNcs值配置過小導(dǎo)致UE接入失敗問題描述案例一：上海外場兩個(gè)AWS站點(diǎn)在驗(yàn)證站間切換時(shí)，發(fā)現(xiàn)從發(fā)展站切換到乾昌站總是成功，而從乾昌站切換到發(fā)展站總是失敗，失敗原因?yàn)榍袚Q時(shí)UE隨機(jī)接入失敗。案例二：德國DD 800M項(xiàng)目，UE在距基站處初始接入失敗，現(xiàn)象與案例一相同。問題分析案例一：問題發(fā)生時(shí)UE每次上報(bào)隨機(jī)接入Preamble，都可以收到eNB的響