HC-UE連續(xù)發(fā)多次測量報告問題分析報告

HC_UE連續(xù)發(fā)多次測量報告問題分析報告-PAGE1-HC_UE連續(xù)發(fā)多次測量報告問題分析報告版權(quán)所有大唐移動通信設(shè)備有限公司本資料及其包含的所有內(nèi)容為大唐移動通信設(shè)備有限公司(大唐移動)所有,受中國法律及適用之國際公約中有關(guān)著作權(quán)法律的保護。未經(jīng)大唐移動書面授權(quán)，任何人不得以任何形式復(fù)制、傳播、散布、改動或以其它方式使用本資料的部分或全部內(nèi)容，違者將被依法追究責(zé)任。

目錄TOC\o"2-3"\h\z\t"標(biāo)題1,1"1. 問題現(xiàn)象描述 32. 數(shù)據(jù)呈現(xiàn)及數(shù)據(jù)附件 43. 分析推理過程 54. 問題結(jié)論、優(yōu)化措施、優(yōu)化前后效果對比 105. 總結(jié)該類問題一般分析優(yōu)化思路 10問題現(xiàn)象描述某日測試中，UE2在RNC390的申泉-3（CPI97，UARFCN10120）上起呼，做CS長保業(yè)務(wù)，呼叫號碼為12121，UEID=17306，行駛方向如圖中紅色箭頭所示。UE在切換到雅典-1（CPI61，UARFCN10088）后，由于信號強度的變化，上報了7條2AMeasurementReport，但是一直沒有收到網(wǎng)絡(luò)側(cè)的重配命令，38秒后收到disconnect，隨后釋放RRC連接。圖表SEQ圖表\*ARABIC1Analysis窗口圖表SEQ圖表\*ARABIC2信令窗口分析推理過程空口沒有看到切換命令，那么RNC是否發(fā)出了切換命令呢？這就需要借助calltrace看網(wǎng)絡(luò)側(cè)有沒有下發(fā)切換命令。查看RNC390在16時的trace（按照UEID過濾，UEID=17306）：圖表SEQ圖表\*ARABIC3calltrace截圖從上圖可以知：UE在成功切換到雅典-1（CELLID=401）之后，網(wǎng)絡(luò)側(cè)下發(fā)測量控制后到收到CN的DIRECTTRANSFER(DISCONNECT)之間的2分2秒內(nèi)沒有任何信令過程。網(wǎng)絡(luò)側(cè)看不到測量報告，有沒有可能是空口有問題導(dǎo)致測量報告沒有發(fā)上去呢？從空口信令（圖表2）和網(wǎng)絡(luò)側(cè)的trace數(shù)據(jù)（圖表3）看不到失步和層二的錯誤，所以可以排除空口的問題。既然不可能是空口的問題，那么問題出在哪里呢？這就需要看測量報告消息是如何發(fā)送的。我們來分析一下一條測量報告消息是如何發(fā)送到RNC的：測量報告消息是RRC層的消息，UE的RRC層把這個消息發(fā)送給底層，經(jīng)過底層的多次分段/組裝和處理后經(jīng)過空口發(fā)給網(wǎng)絡(luò)側(cè)，網(wǎng)絡(luò)側(cè)對接收到的數(shù)據(jù)進(jìn)行組裝/分段和處理后發(fā)給高層，這些數(shù)據(jù)發(fā)到RRC層后就是可以通過信令解析工具（LDT）解析為測量報告消息。RRC層下面就是RLC層，RLC層的功能實體分為UMRLC實體、TMRLC實體和AMRLC實體，分別對應(yīng)RLC-UM、RLC-TM和RLC-AM模式的數(shù)據(jù)。MeasurementReport消息是RLC-AM模式消息。RLC-AM模式的發(fā)送機制為：發(fā)送端在發(fā)送一個數(shù)據(jù)以后會等待接收端返回的確認(rèn)，發(fā)端通過這個確認(rèn)來判斷先前發(fā)送的數(shù)據(jù)是否在對端已經(jīng)完整的接收從而決定是否進(jìn)行重傳：如果完整并正確接收就從發(fā)端的重傳buffer中刪除對應(yīng)的數(shù)據(jù)；如果對端沒有完整并正確的接收，就需要重傳對應(yīng)的數(shù)據(jù)。如果達(dá)到重傳的最大次數(shù)，某一個數(shù)據(jù)還是沒有得到對端的確認(rèn)的話，RLC層就不再重傳數(shù)據(jù)包，而是啟動一個reset過程：啟動reset重傳定時器；向?qū)Χ税l(fā)送一個reset消息，等待對端對reset的確認(rèn)。收到確認(rèn)就認(rèn)為鏈路恢復(fù)了，重新開始數(shù)據(jù)的傳輸。如果reset定時器超時沒有收到確認(rèn)會根據(jù)設(shè)定的reset最大次數(shù)進(jìn)行下一次的reset（同時重啟reset重傳定時器）?？紤]最差的情形：reset的次數(shù)達(dá)到最大值且reset重傳定時器超時仍沒有得到接收端的確認(rèn)，發(fā)送端RLC控制實體就會認(rèn)為鏈路不能再恢復(fù)，從而向RRC層上報不可恢復(fù)錯誤（UE檢測到這個錯誤指示就會進(jìn)行小區(qū)重搜，觸發(fā)RLC不可恢復(fù)錯誤原因的小區(qū)更新。RNC檢測到這個錯誤指示就會觸發(fā)RNC向CN發(fā)Iureleaserequest。）。RLC層通過這樣的機制就可以保證RLC-AM模式的數(shù)據(jù)在兩個對等的RLC層之間可靠的傳輸。以MeasurementReport為例，典型的RLC-AM模式消息其傳輸數(shù)據(jù)流如下圖所示：圖表SEQ圖表\*ARABIC4RLC-AM消息傳輸模式本案例中由于在收到DISCONNECT消息之前UE和RNC都沒有物理層失步和RLC不可恢復(fù)錯誤的相關(guān)消息出現(xiàn)，因此可以認(rèn)為UE底層與RNC底層之間的傳輸是可靠的。也就是說測量報告消息不可能在UE的RLC層到RNC的RLC層之間丟失?，F(xiàn)在的情況是：我們通過Outum/Analysis在UE的RRC層看到了MeasurementReport消息，但是從calltrace看在RNC的RRC層沒有收到。如下圖所示：圖表SEQ圖表\*ARABIC5測量報告?zhèn)鬏斢缮蠄D可以看出，只要是UE的RRC到RLC出現(xiàn)問題或者RNC的RLC到RRC之間出現(xiàn)問題都有可能導(dǎo)致我們看到的這個現(xiàn)象的發(fā)生，因此根據(jù)現(xiàn)有的數(shù)據(jù)無法深入定位RNC有沒有收到測量報告消息?；氐娇湛诘南⒋翱?，看到disconnect之后的釋放過程比較異常：本次空口的釋放過程：圖表SEQ圖表\*ARABIC6本次釋放信令過程正常的網(wǎng)絡(luò)側(cè)釋放過程：圖表SEQ圖表\*ARABIC7網(wǎng)絡(luò)側(cè)釋放的正常流程對上述過程說明如下：CN下發(fā)disconnect消息，同時啟動NAS層定時器T305；UE收到RNC轉(zhuǎn)發(fā)的disconnect消息后：停止所有正在運行的呼叫控制定時器；向網(wǎng)絡(luò)回release消息；啟動NAS層定時器T308；CN在T305超時之前收到UE的release消息：停止T305及其它正在運行的呼叫控制定時器；下發(fā)releasecomplete消息；釋放MM連接；進(jìn)入空閑態(tài)。UE在T308超時之前收到CN的releasecomplete消息，停止T308和其它正在運行的呼叫控制定時器；釋放MM連接；進(jìn)入空閑態(tài)。網(wǎng)絡(luò)側(cè)釋放過程中定時器超時的處理：CN側(cè)T305超時，下發(fā)release消息，同時啟動T308；UE側(cè)T308超時，重傳release消息，同時重啟T308，T308第二次超時，釋放MM連接，UE進(jìn)入空閑態(tài)。相關(guān)定時器的設(shè)置：T305（網(wǎng)絡(luò)側(cè)）：30s協(xié)議規(guī)定值；T308（網(wǎng)絡(luò)側(cè)）：10s運營商設(shè)置值；T308（UE側(cè)）：30s協(xié)議規(guī)定值；本案例中的網(wǎng)絡(luò)側(cè)的釋放過程：圖表SEQ圖表\*ARABIC8本次網(wǎng)絡(luò)側(cè)釋放過程對照空口和網(wǎng)絡(luò)側(cè)信令（圖6和圖8），本次釋放的信令流程如下：CN下發(fā)disconnect，同時啟動等待定時器NAS層的T305，等待UE的release消息；UE收到disconnect，向網(wǎng)絡(luò)側(cè)回release消息，同時啟動NAS層定時器T308，等待網(wǎng)絡(luò)側(cè)的releasecomplete消息；CN的T30530s超時沒有收到UE的release，下發(fā)DIRCETTRANSFER（release），同時啟動NAS定時器T308，給計數(shù)器置1；UET30830s超時未收到release消息，釋放MM鏈接，啟動一個10s定時器，定時器超時上發(fā)SignallingConnectionReleaseIndication消息；CN的T308定時器超時，下發(fā)一條DLDIRCETTRANSFER（release）消息，計數(shù)器加1；UE收到release消息，上發(fā)RRCstatus消息指示UE沒有與CN的CS連接；CN的T308再次超時，計數(shù)器為2，發(fā)Iureleasecommand消息釋放Iu信令連接；RNC釋放RRC連接（未能收到UE發(fā)的RRCConnectionReleaseComplete消息）；UE收到RRCConnectionRelease消息，向網(wǎng)絡(luò)回RRCConnectionReleaseComplete消息。根據(jù)協(xié)議，disconnect、release、RRCConnectionRelease(DL-DCCH)、SignallingConnectionReleaseIndication和RRCstatus都采用RLC-AM傳送。由此可以看出釋放過程中UE發(fā)送的RLC-AM消息（release、SignallingConnectionReleaseIndication）在RNC的RRC層沒有收到，導(dǎo)致了CN側(cè)對應(yīng)的定時器超時。綜合前述測量報告消息RNC的RRC層收不到和上述異常釋放過程兩個情況，我們可以得出一個規(guī)律：從UE的RRC層發(fā)出的RLC-AM消息都到不了RNC的RRC層。我們可以定位問題是發(fā)生在UE的RRC層到RLC層和/或RNC的RLC的到RRC的這兩個地方。由于不能解析UE層二的消息和RNC的層二的消息，無法進(jìn)行深層次的定位。問題結(jié)論、優(yōu)化措施、優(yōu)化前后效果對比問題結(jié)論：本案例中從Uu口看到手機多次上報測量報告，沒有收到網(wǎng)絡(luò)側(cè)的響應(yīng)，最后網(wǎng)絡(luò)側(cè)釋放。通過對測量報告消息的發(fā)送機制以及后面釋放過程中的異?，F(xiàn)象的分析可以定位到UE的RRC層到RLC層和/或RNC的RLC層到RRC層的傳遞可能有問題。優(yōu)化措施：由于網(wǎng)優(yōu)日常的數(shù)據(jù)采集工具只能解析UE和RNC的RRC層以上信令，因此本案例的更進(jìn)一步定位需要RNC研發(fā)和UE研發(fā)支持。總結(jié)該類問題一般分析優(yōu)化思路在這個案例中，我們從空口看到UE多次上報測量報告網(wǎng)絡(luò)沒有處理，最后網(wǎng)絡(luò)側(cè)釋放。通過查看RNC的calltrace發(fā)現(xiàn)RNC的RRC層沒有收到測量報告，進(jìn)一步對空口的LOG和網(wǎng)絡(luò)側(cè)的calltrace消息進(jìn)行對比，我們發(fā)現(xiàn)UE在切換到雅典-1后所有上行的AM信令都到不了RNC的RRC層，由于AM模式是一種需要對端對接收的消息進(jìn)行確認(rèn)的一種傳輸模式，結(jié)合底層沒有失步以及重傳定時器超時的情況，我們認(rèn)為UE的RLC層到RNC的RLC層之間是沒有問題的，問題有可能出現(xiàn)在UE的RRC層到RLC層和/或RNC的RLC層到RRC層，更進(jìn)一步的定位需要終端和RNC的研發(fā)抓取底層的消息來分析。本案例中問題發(fā)生在UE內(nèi)部處理或者是在RNC內(nèi)部的處理上，屬于設(shè)備問題，日常的網(wǎng)優(yōu)工作很少能遇到這樣的情況，不作為日常優(yōu)化問題定位要考慮的方面。但是考慮到TD目前的設(shè)備尚不成熟，因此建議現(xiàn)階段在問題定位中對于所有可能的地方都要考慮到，盡可能的發(fā)現(xiàn)設(shè)備與終端存在的問題，促進(jìn)設(shè)備與終端的日趨成熟。從空口看到測量報告發(fā)出去后沒有收到切換命令的問題，依據(jù)網(wǎng)絡(luò)側(cè)RRC層有沒有收到可以分為兩個方面：RNC的RRC層沒有收到