語音業(yè)務(wù)UCIU error專題分析.rar (522.28 KB) 語音業(yè)務(wù)UCIU error專題分析.rar (522.28 KB)【資料名稱】：語音業(yè)務(wù)UCIU error語音業(yè)務(wù)UCIU error

【資料作者】：中興

【資料日期】：2011

【資料語言】：中文

【資料格式】：DOC

【資料目錄和簡介】：

語音業(yè)務(wù)UCIU error
專題分析
1重要說明
1、本文討論的業(yè)務(wù)類型為CS業(yè)務(wù)，對于PS業(yè)務(wù)不適用；
2、本文討論的KPI為后臺網(wǎng)管CS掉話率統(tǒng)計結(jié)果；對于依靠前臺信令統(tǒng)計掉話的情況，本文涉及的方法、思路效果不大；
3、300版本升級后，切換超時掉話，作為掉話原因歸類為UCIU error掉話；但從信令分析中RNC的釋放原因是handover timeout；
2UCIU error掉話的表現(xiàn)形式
UCIU error表示RLC（無線鏈路控制層）不可恢復(fù)性錯誤。從結(jié)構(gòu)模型看，RLC層是比物理層高。發(fā)生UCIU error掉話，說明鏈路的RLC層出現(xiàn)故障。
RNC作UCIU error釋放，意味著下行鏈路的RLC發(fā)生了不可恢復(fù)性錯誤。以下為常見的UCIU error原因的釋放：



測量控制下發(fā)失敗導(dǎo)致的UCIU error掉話







直傳消息下發(fā)失敗導(dǎo)致的UCIU error掉話



掉話統(tǒng)計中歸類為UCIU error原因的切換超時掉話
特別說明
3UCIU error的發(fā)生機制與時延計算
1、當(dāng)RLC層發(fā)生傳遞失敗后，會首先進行重傳嘗試，如果重傳成功，鏈路的RLC層恢復(fù)；
2、當(dāng)重傳達到最大次數(shù)后RLC層仍沒有傳遞成功，發(fā)送端可發(fā)起RLC層的復(fù)位，恢復(fù)RLC的全部初始參數(shù)，如果復(fù)位能夠成功，那么RLC重新開始向接收端作重傳嘗試；
3、當(dāng)復(fù)位達到最大次數(shù)后，復(fù)位仍不成功，發(fā)送端認為RLC發(fā)生了不可恢復(fù)性錯誤。（UCIU error）
4、UCIU error的最大時延＝RLC層最大重傳次數(shù)*RLC層重傳間隔＋RLC層最大復(fù)位次數(shù)*RLC層復(fù)位間隔
例如：當(dāng)RLC最大重傳次數(shù)為40次；重傳間隔為140ms；RLC層復(fù)位7次；復(fù)位間隔為1s，那么UCIU error的最大時延為12.6秒；

4UCIU error對用戶的影響
當(dāng)CS業(yè)務(wù)中，通話的一端的RLC層在進行重傳、復(fù)位過程中，通話的對端會無法聽到任何聲音。如果用戶長時間不能聽到對端的聲音，會導(dǎo)致用戶感受急劇下降，從而主動發(fā)起釋放。
如果RLC層重傳、RLC層復(fù)位還在進行，這個時候通話的對端發(fā)起主動釋放，那么CN在主動釋放用戶的一側(cè)收到上行的disconnect后，對另外一側(cè)的用戶（正在RLC層重傳、RLC層復(fù)位）下發(fā)disconnect消息。由于下行鏈路的RLC層還沒有恢復(fù)正常，那么disconnect下發(fā)一定也不會成功。
如果RLC層始終沒有恢復(fù)，根據(jù)CN的處理機制，下發(fā)disconnect后，啟動T305；T305超時后下發(fā)RELEASE消息，并啟動T308；T308再次超時后，CN下發(fā)Iu release消息釋放業(yè)務(wù)。從網(wǎng)管統(tǒng)計角度觀察這屬于正常釋放不屬于掉話。
與此同時，RLC層的重傳和RLC的復(fù)位也在進行，如果UCIU error的最大時延達到最大，那么RNC將發(fā)起UCIU error原因的釋放。從后臺網(wǎng)管統(tǒng)計角度觀察，這屬于掉話。
上述兩個進程同步進行，先結(jié)束的流程，將決定了本次業(yè)務(wù)的釋放是否屬于掉話。

5CS掉話率的改善
根據(jù)上一節(jié)的分析，為了減少掉話率的發(fā)生，就要盡可能地讓對端釋放流程比UCIU error流程先結(jié)束。
對端釋放流程中，對端的忍耐時間因人而異，CN的T305和T308設(shè)置為最短時長，對端釋放流程先結(jié)束的可能性最大。
UCIU error流程中，增加RLC重傳階段的最大重傳次數(shù)、重傳間隔；增加RLC 復(fù)位階段的最大復(fù)位次數(shù)、復(fù)位間隔；UCIU error釋放流程后結(jié)束的可能性最大。
第3節(jié)提到的，切換超時掉話的情況，UCIU error的時延就不適用了，增加handover timeout時延，同樣可以起到減少后臺網(wǎng)管統(tǒng)計中切換超時的發(fā)生數(shù)量，從而改善掉話率的作用。
以下是某城市RNC4，切換超時時延、UCIU error時延增加后，后臺網(wǎng)管CS掉話率統(tǒng)計結(jié)果的變化走勢：



6附加說明
修改后，后臺統(tǒng)計中，CS掉話個數(shù)與CS掉話率都明顯變化。同時，PS掉線率沒有發(fā)生明顯改變。CS業(yè)務(wù)由兩個用戶共同完成，存在著對端主動釋放的可能；而PS業(yè)務(wù)沒有可以主動釋放的對端。
對于進入RLC重傳、RLC復(fù)位流程的用戶而言，由于對端主動釋放，從后臺觀察不統(tǒng)計為掉話，但是如果從前臺信令觀察，用戶仍然是一個異常釋放的過程。對于第三方測試，對端不會作主動釋放，而且路測軟件是根據(jù)前臺信令進行掉話判斷的，因而前面的討論，不再適用這種情況。
下表為部分CN定時器的名稱、觸發(fā)機制。
TIM
NUM.TIM VALSTATE OF CALLCAUSE OF STARTNORMAL STOPAT FIRST EXPIRYAT SECOND EXPIRY
T30330sCall initiatedCM SER RQ sentCALL PROC, or REL COMP receivedClear the callTimer is not restarted
T30530sDisconnect RequestDISC sentREL or DISC receivedREL sent.Timer is not restarted
T30830sRelease requestREL sentREL COMP or REL receivedRetrans. RELEASE restart T308Call ref. release
T310
Note 130sOutgoing call ProceedingCALL PROC receivedALERT,CONN, DISC or PROG rec.Send DISCTimer is not restarted
T31330sConnect RequestCONN sentCONNect ACKnowledge receivedSend DISCTimer is not restarted