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

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