LTE專項(xiàng)問題定位總結(jié)報(bào)告接入成功率較低

1、LTE R3.0專項(xiàng)問題定位總結(jié)報(bào)告之“接入成功率較低”LTE R3.0技術(shù)文檔V1.02011年10月11日修訂歷史記錄日期版本作者備注編制姓名簽字日期電話薛旭2011-10-11審查姓名簽字日期電話審核姓名簽字日期電話批準(zhǔn)姓名簽字日期電話文檔評(píng)審負(fù)責(zé)人： 參加評(píng)審人員： 目錄1引言41.1編寫目的41.2預(yù)期讀者41.3參考資料42問題描述42.1問題背景42.2問題現(xiàn)象73問題定位過程73.1定位思路73.2定位過程84問題分析與總結(jié)105附錄125.1文檔附件125.2OMCR-CT碼流12第一次初始附著碼流12UE插拔后，第二次發(fā)起附著13RRC連接重建流程141 引言1.1 編寫目

2、的本文檔對(duì)LTE R3.0項(xiàng)目測試過程中“終端接入成功率較低”問題的解決過程進(jìn)行了詳細(xì)的描述，并針對(duì)各種可能的場景給出了基本的定位方法，為后續(xù)測試過程中終端接入失敗問題的定位提供參考。1.2 預(yù)期讀者本文檔的讀者是LTE R3.0項(xiàng)目軟件開發(fā)人員、軟件測試人員、測試線支持人員以及相關(guān)的系統(tǒng)測試人員。1.3 參考資料1. TD-LTE eNodeB R3.0 系統(tǒng)流程設(shè)計(jì)說明書.doc2. TD-LTE eNodeB高層軟件架構(gòu)設(shè)計(jì)說明書-控制面.doc3. 基帶專項(xiàng)問題定位總結(jié)報(bào)告-消息3譯碼錯(cuò)誤率高.doc2 問題描述2.1 問題背景本專項(xiàng)測試的目的是解決終端初始接入時(shí)的各種問題，提高UE接

3、入成功率，因此本文提供的分析以接入場景為基礎(chǔ)。圖2-1描述了初始附著流程的關(guān)鍵步驟：當(dāng)終端在目標(biāo)小區(qū)成功駐留后，就可以發(fā)起隨機(jī)接入請(qǐng)求，即發(fā)送Msg1(Random Access Preamble)，eNodeB的BB檢測并處理完P(guān)RACH后會(huì)將每個(gè)用戶的前導(dǎo)碼序列指示(PreambleIndex)、定時(shí)提前量(TA)、用戶標(biāo)識(shí)(RA_RNTI)、Prach接收功率(PrachPower)幾個(gè)關(guān)鍵參數(shù)傳到UP MAC；然后由UP MAC調(diào)度DL-SCH (物理層鏈路依次為PDCCH和PDSCH)將隨機(jī)接入響應(yīng)消息Msg2(Random Access Response)反饋給終端，消息中至少包括

4、檢測出的PreambleIndex、TA、用于指示Msg3資源的調(diào)度授權(quán)信息和分配臨時(shí)用戶標(biāo)識(shí)(TC-RNTI)；而后，終端完成上行發(fā)射時(shí)間調(diào)整和功控，并根據(jù)小區(qū)系統(tǒng)信息和調(diào)度授權(quán)信息在UL-SCH(物理層鏈路為PUSCH)上發(fā)送無線鏈路連接請(qǐng)求，即Msg3(RRC Connection Request)。對(duì)eNodeB側(cè)來說，UP MAC會(huì)在下發(fā)Msg2后通過上行接收請(qǐng)求幀指示BB接收PUSCH，其中請(qǐng)求幀的配置參數(shù)要與發(fā)給終端的Msg2中調(diào)度授權(quán)信息一致。當(dāng)BB根據(jù)指示接收并處理完P(guān)USCH后，將譯碼后數(shù)據(jù)和CRC校驗(yàn)結(jié)果反饋到UP MAC，并由UP MAC解復(fù)用之后給CP RRC層，CP

5、根據(jù)實(shí)際情況指示UP和BB建立用戶，待建立用戶成功之后下發(fā)Msg4(RRC Connection Setup)。UP MAC分配Msg4資源后，指示給BB通過空口下發(fā)給UE。UE收到Msg4后，為了發(fā)送Msg5（RRC Connection Setup Complete）而上報(bào)SR，請(qǐng)求上行資源。eNB側(cè)MAC完成上行資源調(diào)度后，通過DCI0指示給UE。然后UE將Msg5協(xié)同Attach Request NAS消息一起上發(fā)到eNB CP。eNB CP收到Msg5后，向MME發(fā)起初始UE流程，其中攜帶Attach Request消息。MME收到UE的附著請(qǐng)求后，兩者之間通過上下行直傳消息完成NA

6、S鑒權(quán)和加密過程。之后，MME向CP發(fā)送初始上下文建立請(qǐng)求，同時(shí)攜帶了Attach Accept消息。按照MME指示CP需要獲取UE能力傳遞給MME，然后CP進(jìn)行網(wǎng)絡(luò)側(cè)和UE之間的加密過程。MME與UE、eNB與UE之間的通道都完成加密過程后，CP通過RRC連接重配進(jìn)行SRB2和默認(rèn)DRB的建立，并通過RRC連接重配消息將Attach Accept消息帶給UE。UE完成建立SRB2和DRB流程后，給eNB側(cè)發(fā)送RRC連接重配完成響應(yīng)，并通過Attach Complete消息指示MME完成Attach流程。注：1. 圖2-1中將NAS消息的傳遞過程簡化，實(shí)際需要MAC不斷的進(jìn)行資源調(diào)度。2. 圖

7、中將CP對(duì)L2的配置和重配流程簡化，實(shí)際需要CP對(duì)L2的各層（MAC、RLC、PDCP）依次進(jìn)行操作。圖2-1 UE初始附著信令流程2.2 問題現(xiàn)象在專項(xiàng)問題定位測試線，反復(fù)進(jìn)行終端附著去附著操作，以及插拔操作。出現(xiàn)多次附著失敗，可以分為6種：1) 多次附著去附著后，UE無法收到消息2（RAR），捕包工具OMCR-CT抓不到任何消息；2) 終端發(fā)起RRC連接重建后，不斷發(fā)送位置區(qū)更新請(qǐng)求；3) UE發(fā)起RRC連接重建，流程完成后CP將其釋放。4) 出現(xiàn)現(xiàn)象4后，UE再次發(fā)起附著，CP會(huì)拒絕；5) RRC連接重建成功后，UE或再次發(fā)起RRC連接重建請(qǐng)求， eNB側(cè)CP發(fā)送拒絕消息；6) eNB側(cè)

8、多次向MME發(fā)送初始上下文消息，但MME未收到。3 問題定位過程3.1 定位思路根據(jù)UE附著接入流程以及本次專項(xiàng)測試的問題定位經(jīng)驗(yàn)，UE附著失敗的問題主要可以歸結(jié)為以下幾種原因：1) UE反復(fù)附著去附著后，UP MAC在處理消息1時(shí)，分配Temp UE ID失敗，導(dǎo)致Msg2下發(fā)失??；2) 由于eNB發(fā)送的系統(tǒng)信息中的PLMN ID與核心網(wǎng)的PLMN不一致，導(dǎo)致UE不斷發(fā)起TAU；3) CP處理RRC連接重建時(shí)，對(duì)UE上下文的處理存在問題，導(dǎo)致UE若再次接入會(huì)被拒絕，若再次重建則會(huì)重建拒絕。4) 由于eNB與MME之間的S1鏈路出現(xiàn)閃斷，導(dǎo)致MME收不到eNB發(fā)送的S1AP消息；基于以上4種可

9、能的原因，針對(duì)目前出現(xiàn)的不同現(xiàn)象來分別分析，確定了每種現(xiàn)象的定位思路：Ø 現(xiàn)象1測試時(shí)，抓取BB對(duì)于Msg1Msg5的統(tǒng)計(jì)Log，和UP MAC的Log，并結(jié)合OMCR-CT捕包工具。如果捕包工具上沒有任何碼流，再查看BB和MAC的Log。若發(fā)現(xiàn)BB收到多次Msg1，但是收不到消息2，并且MAC Log中存在處理消息1時(shí)分配Temp UE ID失敗指示，則可以確定是由于原因1導(dǎo)致接入失敗。Ø 現(xiàn)象2當(dāng)服務(wù)小區(qū)質(zhì)量低于規(guī)定門限時(shí)，UE會(huì)重新進(jìn)行小區(qū)搜索，并接收系統(tǒng)信息，若系統(tǒng)信息中的TAI不在核心網(wǎng)下發(fā)的TAI List中時(shí)，UE會(huì)主動(dòng)上報(bào)TAU請(qǐng)求。如果UE不斷地上報(bào)TAU

10、，說明eNB側(cè)配置的PLMN ID與核心網(wǎng)下發(fā)的不一致，此時(shí)需要檢查eNB側(cè)的PLMN配置。Ø 現(xiàn)象3eNB執(zhí)行RRC連接重建流程，若將UE釋放，說明eNB側(cè)的處理中出現(xiàn)錯(cuò)誤導(dǎo)致。抓取OMCR-CT碼流，檢查重建流程哪里出現(xiàn)錯(cuò)誤。（本次測試出現(xiàn)的是PDCP重激活失?。?#216; 現(xiàn)象4eNB側(cè)CP處理RRC連接重建時(shí)，沒有將原有的C-RNTI對(duì)應(yīng)的標(biāo)志位清空，但MAC釋放掉原C-RNTI后，UE再次附著時(shí)會(huì)將該C-RNTI再分配。因此CP RRC判斷RRC連接建立請(qǐng)求消息中的C-RNTI時(shí)，發(fā)現(xiàn)對(duì)應(yīng)資源已經(jīng)占用，從而發(fā)送拒絕消息。Ø 現(xiàn)象5eNB側(cè)CP處理RRC連接重建時(shí)

11、，沒有將新的C-RNTI與對(duì)應(yīng)的UE資源相關(guān)聯(lián)，因此CP根據(jù)RRC連接重建消息中的C-RNTI查找UE失敗，從而發(fā)送重建拒絕消息。Ø 現(xiàn)象6從OMCR-CT捕包工具發(fā)現(xiàn)，UE不斷地發(fā)起附著，信令流程到eNB給MME發(fā)送初始上下文，并且反復(fù)以上流程，但從MME側(cè)的碼流沒有發(fā)現(xiàn)eNB側(cè)發(fā)送的此消息。則可以確定是eNB和MME之間的鏈路存在問題。3.2 定位過程 此次專項(xiàng)測試中出現(xiàn)的問題集中在UP MAC的接入過程，和CP對(duì)RRC連接重建處理流程?，F(xiàn)象6出現(xiàn)一次之后沒有再次復(fù)現(xiàn)，因此重點(diǎn)分析現(xiàn)象15的定位過程。Ø 現(xiàn)象1使用創(chuàng)意視訊的P3A數(shù)據(jù)終端進(jìn)行測試，反復(fù)附著去附著后，發(fā)現(xiàn)

12、接入失敗。查看UE側(cè)Log顯示，接收Msg2（RAR）超時(shí)，并且反復(fù)出現(xiàn)。1629EL1C: MSG1 target preample rx pow is 541629EL1C: prach_cfg_id is 51629EL1C: power ramp is41629EL1C: rach ctrl at 537, sf is 71629EL1C: ra_rnti: 31629EL1C: n_ra_prb: 61629EL1C: preample_format: 01629EL1C: RA response timer is 211632EL1C: RAR expire at sfn=539,

13、 sf=8抓取UP MAC的69號(hào)窗口的Log，李昂發(fā)現(xiàn)臨時(shí)UE ID耗盡，查看Msg3和Msg4的計(jì)數(shù)器計(jì)數(shù)，發(fā)現(xiàn)不一致。查看CCCH（消息4）相關(guān)計(jì)數(shù)器，發(fā)現(xiàn)消息4比消息3計(jì)數(shù)器正好少50個(gè)（臨時(shí)UE ID的總數(shù)），懷疑CCCH消息沒有及時(shí)發(fā)送給MAC。由于MAC維護(hù)臨時(shí)UE ID是基于CCCH消息的HARQ反饋的，CCCH消息的缺失就會(huì)導(dǎo)致臨時(shí)UE ID 的掛死，李昂加入競爭決議定時(shí)器機(jī)制，用來維護(hù)臨時(shí)UE ID和消息4的重調(diào)度。但加入此機(jī)制后問題1依舊復(fù)現(xiàn)，查看UP Trace發(fā)現(xiàn)在隨機(jī)接入過程中經(jīng)常出現(xiàn)解復(fù)用模塊的告警，經(jīng)閆英杰和李昂確認(rèn)，此時(shí)解復(fù)用模塊與隨機(jī)接入模塊之間接口UE I

14、D參數(shù)傳遞錯(cuò)誤，導(dǎo)致在收到包含CRNTI MAC CE的消息3后（如果消息3中不包含CCCH消息或信令消息，CP不會(huì)發(fā)送消息4，能夠解釋為何CCCH消息比MSG3少）無法釋放臨時(shí)臨時(shí)UE ID導(dǎo)致資源耗盡。修改后能夠正常釋放臨時(shí)UE ID。李昂和閆英杰分析，此時(shí)消息3為“上行數(shù)據(jù)到達(dá)”場景下的消息3。為何初始隨機(jī)接入過程中會(huì)走到“上行數(shù)據(jù)到達(dá)”？李昂初步懷疑UE有消息5之后的消息需要上報(bào)，而此時(shí)UE的TA定時(shí)器已經(jīng)超時(shí)，經(jīng)過安思麒，李昂，和閆英杰確認(rèn)，此時(shí)消息3中包含需要傳遞給RLC層的數(shù)據(jù)包，拆包后發(fā)現(xiàn)此包為UE上報(bào)的狀態(tài)PDU（NACK），MAC解復(fù)用模塊修改傳遞級(jí)別，使在線非激活用戶的狀

15、態(tài)PDU也能傳遞給RLC層。至于UE TA模塊為何會(huì)超時(shí)，需要進(jìn)一步加以分析。ER SFN:0687 | SubSFN:0 | CCIdx:0 | CUIdx:0012 | MacRandomAccess:2116 | RarInDemux:None | ClearCrnti:None | TempUeid:12 | NULL:None | ER SFN:0687 | SubSFN:0 | CCIdx:0 | CUIdx:0012 | MacRandomAccess:2122 | RarInDemux:None | ClearUeCtx:None | TempUeid:12 | NULL:No

16、ne |測試過程中發(fā)現(xiàn)消息3的誤碼率偏高，李昂和務(wù)志坤修改消息3分配資源的方式和RU個(gè)數(shù)，使消息3對(duì)應(yīng)的短截調(diào)制編碼方式可配，最小為3。同時(shí)支持最大給MSG3分配2個(gè)RU。經(jīng)過驗(yàn)證，為提高M(jìn)SG3的解碼成功率有一定幫助。至此，現(xiàn)象1的問題定位完畢。Ø 現(xiàn)象2從OMCR-CT上查看碼流，可以看到UE不斷地發(fā)起TAU流程。分析TAU Request攜帶的Last visited registered TAI，得到PLMN ID為001 01，而核心網(wǎng)在Attach Accept中攜帶的PLMN ID為460 00，查看LMT-B中配置的MNC和MCC全為1，此配置錯(cuò)誤導(dǎo)致UE在服務(wù)小區(qū)服

17、務(wù)質(zhì)量太差，重新搜索小區(qū)接收SIB1消息時(shí)，會(huì)得到錯(cuò)誤的PLMN ID，因此會(huì)發(fā)起TAU。將eNB配置參數(shù)MNC修改為460、MCC修改為1后問題解決。反復(fù)發(fā)起TAU時(shí)，查看小區(qū)信號(hào)質(zhì)量很差，從而觸發(fā)UE的重新搜索小區(qū)流程。王亮從RRU輸出的功率看出現(xiàn)10db的跳變，將RRU的功率檢測關(guān)掉后，沒有再次出現(xiàn)此現(xiàn)象。問題2解決。至此，現(xiàn)象2的問題定位結(jié)束。Ø 現(xiàn)象3分析OMCR-CT的碼流，發(fā)現(xiàn)在完成RRC重建流程之后，對(duì)eNB CP對(duì)PDCP重激活流程中，PDCP返回失敗，從而導(dǎo)致CP發(fā)起UE釋放。PDCP同事查看代碼，發(fā)現(xiàn)按照當(dāng)前的重建流程，在重激活時(shí)，SRB2的狀態(tài)不正確導(dǎo)致PDC

18、P返回激活失敗。該問題是由前期切換測試修改代碼引入，現(xiàn)已修改。Ø 現(xiàn)象4抓取MCB板10號(hào)窗口的Log，發(fā)現(xiàn)當(dāng)UE再次接入時(shí)，攜帶的C-RNTI（MAC分配）相關(guān)的UE上下文不為空，從而導(dǎo)致CP將其拒絕。此C-RNTI時(shí)RRC連接重建使用的C-RNTI，CP在處理重建消息時(shí)，需要更新C-RNTI，將原C-RNTI對(duì)應(yīng)的標(biāo)志位置為空。但從Log分析，確定是在重建時(shí)沒有正確處理C-RNTI更新過程。分析CP RRC連接重建流程，發(fā)現(xiàn)在更新C-RNTI時(shí)，沒有將原C-RNTI對(duì)應(yīng)的標(biāo)志位置為0。重建失敗會(huì)給UP MAC發(fā)送釋放UE請(qǐng)求，MAC將原C-RNTI回收再利用，因此UE再次接入時(shí)，

19、使用回收的C-RNTI。由于CP此時(shí)該C-RNTI標(biāo)志位為1，從而接入失敗。CP修改RRC連接重建流程代碼后，問題解決。至此，現(xiàn)象4的問題定位結(jié)束。Ø 現(xiàn)象5 分析MCB板10號(hào)窗口的Log，UE第二次發(fā)起RRC連接重建請(qǐng)求時(shí)，CP通過C-RNTI沒有找到對(duì)應(yīng)的UE上下文，從而發(fā)送RRC重建拒絕。經(jīng)過分析，此問題的出現(xiàn)是由于在第一次重建時(shí)，沒有將新的C-RNTI與對(duì)應(yīng)的UE上下文關(guān)聯(lián)導(dǎo)致。修改CP代碼后問題解決。 至此，現(xiàn)象5的問題定位完畢。4 問題分析與總結(jié)本專項(xiàng)測試過程中，發(fā)生接入失敗的問題主要集中在UP MAC的隨機(jī)接入過程和CP RRC層RRC連接重建的處理流程：當(dāng)出現(xiàn)接入失

20、敗問題時(shí)，首先查看OMCR-CT碼流，分析信令流程：1) 如果沒有收到Msg3，則需要分析UP MAC和BB的Log。BB的分析可以參考附件基帶專項(xiàng)問題定位總結(jié)報(bào)告-消息3譯碼錯(cuò)誤率高.doc文檔中的說明進(jìn)行定位；UP MAC的Log通過在CPB板69號(hào)窗口抓取，按照現(xiàn)象1的定位過程進(jìn)行定位。2) 如果收到Msg3，并且附著成功后發(fā)起了RRC連接重建，并反復(fù)出現(xiàn)TAU過程。則需要查看LMT-B中“小區(qū)RRM參數(shù)1èPLMN配置”中的MNC和MCC配置是否正確。應(yīng)該按下圖配置：3) 如果RRC連接重建失敗，并CP發(fā)起了UE釋放，則需要確認(rèn)重建流程走到哪一步了，根據(jù)實(shí)際情況定位。若PDC

21、P重激活響應(yīng)消息中Result為1，則表示返回失敗響應(yīng)，此時(shí)原因大致可以確定為PDCP維護(hù)的SRB或DRB狀態(tài)不正確導(dǎo)致，需要PDCP同事結(jié)合狀態(tài)機(jī)轉(zhuǎn)換機(jī)制分析重建流程是否正確。4) 如果RRC連接重建失敗，eNB和MME釋放UE后，UE再次發(fā)起附著失敗，則需要查看MCB板10號(hào)窗口的Log，查找顯示為Error的Trace，若存在“GRMCOMM_AllocUeId(): GRM_UE_CTXT exists by C-RNTI ”，則需要CP同事確認(rèn)當(dāng)前MCB版本是否解決了RRC連接重建處理有誤的問題。5) 如果信令流程中發(fā)現(xiàn)已經(jīng)發(fā)送了Msg4，但CP因沒有收到UE發(fā)送的Msg5，而等待超

22、時(shí)將UE釋放。此時(shí)需要UP確認(rèn)是否將Msg4調(diào)度給UE，并確認(rèn)UE是否收到Msg4以及是否發(fā)送了Msg5。該問題出現(xiàn)不多，后續(xù)測試中沒有復(fù)現(xiàn)。6) 如果UE反復(fù)附著，一般是因?yàn)樾^(qū)信號(hào)質(zhì)量不穩(wěn)，導(dǎo)致UE掉話重新進(jìn)行小區(qū)搜索并附著。并反復(fù)進(jìn)行該過程。本專項(xiàng)測試發(fā)現(xiàn)的問題已經(jīng)定位并解決，并且接入成功率達(dá)到95%以上，但還存在一些在本次測試沒有出現(xiàn)的場景和問題，有待解決和定位。一旦出現(xiàn)，按照本文總結(jié)的經(jīng)驗(yàn)和定位方法，也是不難定位的。5 附錄5.1 文檔附件1基帶專項(xiàng)問題定位總結(jié)報(bào)告-消息3譯碼錯(cuò)誤率高5.2 OMCR-CT碼流OMCR-CT碼流顯示了CP高層的板間消息交互過程。5.2.1 第一次初始附著碼流關(guān)于附著流程的描述請(qǐng)參見2.1節(jié)。消息4消息5消息35.2.2 UE插拔后，第二次發(fā)起附著數(shù)據(jù)卡終端附著成功后，直接拔掉，此時(shí)eNB和MME都不知道該UE已經(jīng)不在線了，仍然都保存著該UE的上下文。當(dāng)UE再次發(fā)起附著時(shí)，由于MAC又重新為其分配了新的C-RNTI，并且CP只是根據(jù)C-RNTI來判斷UE是否已經(jīng)存在，而不對(duì)IMSI進(jìn)行檢查，所以eNB是無法得知