語音業(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

【資料目錄和簡(jiǎn)介】：

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



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







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



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

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

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



6附加說明
修改后，后臺(tái)統(tǒng)計(jì)中，CS掉話個(gè)數(shù)與CS掉話率都明顯變化。同時(shí)，PS掉線率沒有發(fā)生明顯改變。CS業(yè)務(wù)由兩個(gè)用戶共同完成，存在著對(duì)端主動(dòng)釋放的可能；而PS業(yè)務(wù)沒有可以主動(dòng)釋放的對(duì)端。
對(duì)于進(jìn)入RLC重傳、RLC復(fù)位流程的用戶而言，由于對(duì)端主動(dòng)釋放，從后臺(tái)觀察不統(tǒng)計(jì)為掉話，但是如果從前臺(tái)信令觀察，用戶仍然是一個(gè)異常釋放的過程。對(duì)于第三方測(cè)試，對(duì)端不會(huì)作主動(dòng)釋放，而且路測(cè)軟件是根據(jù)前臺(tái)信令進(jìn)行掉話判斷的，因而前面的討論，不再適用這種情況。
下表為部分CN定時(shí)器的名稱、觸發(fā)機(jī)制。
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