TD-RRC連接擁塞與無響應(yīng)專題處理思路

1、 中國移動(dòng)江蘇公司網(wǎng)絡(luò) PAGE 11RRC連接擁塞與無響應(yīng)處理思路目錄 TOC o 1-3 h z u HYPERLINK l _Toc294779718 RRC連接擁塞與無響應(yīng)處理思路 PAGEREF _Toc294779718 h 1 HYPERLINK l _Toc294779719 1.背景 PAGEREF _Toc294779719 h 1 HYPERLINK l _Toc294779720 2.RRC 連接過程的信令流程 PAGEREF _Toc294779720 h 1 HYPERLINK l _Toc294779721 3.RRC 失敗分析 PAGEREF _Toc29477

2、9721 h 3 HYPERLINK l _Toc294779722 3.1 RRC Connection Request N300+T300超時(shí)（數(shù)）-路測 PAGEREF _Toc294779722 h 4 HYPERLINK l _Toc294779723 3.1.1 信令流程階段 PAGEREF _Toc294779723 h 4 HYPERLINK l _Toc294779724 3.1.2 常見原因 PAGEREF _Toc294779724 h 5 HYPERLINK l _Toc294779725 3.1.3 解決辦法 PAGEREF _Toc294779725 h 5 HYP

3、ERLINK l _Toc294779726 3.2 RRC Connection Reject （Congestion） PAGEREF _Toc294779726 h 5 HYPERLINK l _Toc294779727 3.2.1 信令流程階段 PAGEREF _Toc294779727 h 5 HYPERLINK l _Toc294779728 3.2.2 常見原因 PAGEREF _Toc294779728 h 6 HYPERLINK l _Toc294779729 3.2.3 解決方法 PAGEREF _Toc294779729 h 7 HYPERLINK l _Toc29477

4、9730 3.3 RRC Connection Reject （Unspecified） PAGEREF _Toc294779730 h 8 HYPERLINK l _Toc294779731 3.2.1 信令流程階段 PAGEREF _Toc294779731 h 8 HYPERLINK l _Toc294779732 3.2.2 常見原因 PAGEREF _Toc294779732 h 9 HYPERLINK l _Toc294779733 3.2.3 解決方法 PAGEREF _Toc294779733 h 9 HYPERLINK l _Toc294779734 3.4 No Reply

5、原因造成RRC失敗 PAGEREF _Toc294779734 h 9 HYPERLINK l _Toc294779735 3.2.1 信令流程階段 PAGEREF _Toc294779735 h 9 HYPERLINK l _Toc294779736 3.2.2 常見原因 PAGEREF _Toc294779736 h 10 HYPERLINK l _Toc294779737 3.2.3 解決方法 PAGEREF _Toc294779737 h 11 HYPERLINK l _Toc294779738 4.總結(jié) PAGEREF _Toc294779738 h 11背景隨著TD-SCDMA網(wǎng)絡(luò)

6、六期工程接近尾聲，目前由于基站建設(shè)、基站故障等問題，給網(wǎng)絡(luò)優(yōu)化帶來了種種困難。本文圍繞南通處理RRC相關(guān)的部分問題，結(jié)合現(xiàn)場實(shí)際情況，為現(xiàn)場的網(wǎng)優(yōu)人員提供了處理RRC相關(guān)問題的解決思路。RRC 連接過程的信令流程UE處于空閑模式下，當(dāng)UE的非接入層請(qǐng)求建立信令連接時(shí)，UE將發(fā)起RRC連接建立過程。每個(gè)UE最多只有一個(gè)RRC連接。當(dāng)RNC接收到UE的RRC CONNECTION REQUEST消息，由其無線資源管理模塊RRM根據(jù)特定的算法(CAC算法)確定是接受還是拒絕該RRC連接建立請(qǐng)求，如果接受，則再判決是建立在專用信道還是公共信道。對(duì)于RRC連接建立在不同的信道，則RRC連接建立流程也不一

7、樣。這樣一來，對(duì)于RRC連接的信令過程可以大致分為以下幾個(gè)過程：呼叫接入控制過程（主要由UE發(fā)起請(qǐng)求，RNC來控制）無線鏈路的建立過程RRC建立完成過程RRC連接過程的基本信令流程如下圖：相對(duì)應(yīng)在信令跟蹤工具內(nèi)看到的過程如下圖（此為手動(dòng)信令跟蹤得來，沒有打開內(nèi)部消息跟蹤）：如果對(duì)應(yīng)的TKIT內(nèi)自動(dòng)生成的CT數(shù)據(jù)，則過程如下：圖中：FP為幀協(xié)議（Node B與RNC同步使用，此時(shí)的同步只是針對(duì)于用戶的新的無線鏈路的同步，并不是整個(gè)Node B與RNC的同步）RRC 失敗分析RRC連接失敗發(fā)生RRC連接建立的過程中，RRC連接一般發(fā)生在如下情況下：UE開機(jī)UE關(guān)機(jī)位置區(qū)更新UE進(jìn)行主叫業(yè)務(wù)UE進(jìn)行

8、被叫業(yè)務(wù)參考協(xié)議25331，RRC連接失敗的原因被分成了兩類：Unspecified（未定義）Congestion（擁塞）但在我司的RRC連接失敗的原因則根據(jù)信令過程，同時(shí)參考協(xié)議被分成了三類：Unspecified（未定義）Congestion（擁塞）NoReply（未響應(yīng)）在日常優(yōu)化的過程中，RRC連接失敗則增加了一種情況，變成了一種現(xiàn)象和三種原因，這新增的一種現(xiàn)象就是在路測中UE已經(jīng)發(fā)起了RRC Connection Request 但經(jīng)過T300超時(shí)并且N300超數(shù)，從而造成起呼失敗。但這種情況也有可能系統(tǒng)側(cè)已經(jīng)進(jìn)行了處理，RNC已經(jīng)下發(fā)了RRC Connection Setup但終端

9、沒有收到。（注：前兩種失敗的原因在信令表示中均表現(xiàn)為RRC Connection Reject，只是其Cause值不同，需要展開信令來看失敗的原因）下面針對(duì)各個(gè)階段的失敗，結(jié)合相關(guān)的信令與硬件組成，逐個(gè)分析各種失敗的原因。3.1 RRC Connection Request N300+T300超時(shí)（數(shù)）-路測UE一直上報(bào)RRC CONNECTION REQ, 但后臺(tái)信令跟蹤上看不到任何信令過程（使用RTV工具的小區(qū)信令跟蹤，不要使用IMSI進(jìn)行信令跟蹤，如果使用IMSI進(jìn)行信令的跟蹤，則有可能造成由于Common ID沒有下來而不顯示相關(guān)的信令，本原因針對(duì)系統(tǒng)側(cè)沒有收到任何信令的情況）。3.1

10、.1 信令流程階段發(fā)生失敗的信令階段如下圖所示（圖中標(biāo)注的 eq oac(,1)）：3.1.2 常見原因隨機(jī)接入過程出現(xiàn)問題，可能存在UpPCH的干擾，首先檢查NODEB的RACH統(tǒng)計(jì)有無上行數(shù)據(jù)包，如果沒有，但簽名個(gè)數(shù)與簽名碰撞個(gè)數(shù)一直在不停地增加，則可能存在上行UpPCH干擾?；蛘呤墙y(tǒng)計(jì)LMT對(duì)UpISCP的測量（其測量與在KPI內(nèi)統(tǒng)計(jì)的POS干擾統(tǒng)計(jì)一致，但精度更高，測量為500ms一次統(tǒng)計(jì)，取整個(gè)測量時(shí)段內(nèi)的平均值，而KPI統(tǒng)計(jì)的測量為15分鐘粒度取平均值）通過CT工具檢查UPPCH上的干擾通過性能統(tǒng)計(jì)，查看UPPOS上的UP干擾統(tǒng)計(jì)終端問題，重啟UE看能否接入Node B 問題：重啟

11、基站3.1.3 解決辦法對(duì)各地外場的數(shù)據(jù)分析后，Up干擾有兩大類型：出現(xiàn)干擾平臺(tái)（從當(dāng)?shù)卣麄€(gè)網(wǎng)絡(luò)來說，出現(xiàn)平臺(tái)的概率并不高），但除去干擾平臺(tái)后的干擾曲線基本正常，對(duì)于這類干擾通過基帶匹配是能判斷出干擾信號(hào)源構(gòu)成的，這樣基帶可以：（1）匹配出干擾源小區(qū)，網(wǎng)優(yōu)調(diào)整（方位角、俯仰角或擾碼、頻點(diǎn)）（2）基帶做干擾消除，以消除干擾。干擾曲線整體抬高（從當(dāng)?shù)卣麄€(gè)網(wǎng)絡(luò)來說，出現(xiàn)干擾曲線整體抬高的概率較高）。對(duì)于這種情況可以采集數(shù)據(jù)看看基帶匹配處理后的結(jié)果，需要以Upshifting的方式來克服此問題。6月6日南通二橋村，出現(xiàn)RRC建立失敗較多，經(jīng)監(jiān)測主要為存在上行UP干擾導(dǎo)致，由于二橋村站點(diǎn)在開通時(shí)UP初始

12、位置與其它站點(diǎn)不一致，經(jīng)Upshifting處理后恢復(fù)正常，RRC建立成功率為99.4%。3.2 RRC Connection Reject （Congestion）UE上報(bào)RRC CONNECTION REQ，但很快RNC就回了信令RRE Connection Reject，并且其所帶的Cause值為“Congestion”，產(chǎn)生這種原因主要是因?yàn)镽RM算法的進(jìn)行判決的結(jié)果，呼叫接納控制（CAC）是無線資源管理（RRM）中的一個(gè)重要組成部分。CACM模塊根據(jù)小區(qū)當(dāng)前的無線資源和負(fù)荷情況以及呼叫的服務(wù)質(zhì)量（QoS），按照一定的算法，對(duì)新的呼叫請(qǐng)求可能產(chǎn)生的負(fù)荷增加量進(jìn)行預(yù)測，然后依據(jù)一定的接入

13、準(zhǔn)則，決定對(duì)新的呼叫是允許接入還是拒絕接入。CAC的目的是在防止系統(tǒng)出現(xiàn)負(fù)荷過載和保證呼叫的服務(wù)質(zhì)量（QoS）的前提下，盡可能保證并提高系統(tǒng)的容量。3.2.1 信令流程階段信令發(fā)生的階段如下圖所示（圖中標(biāo)注的 eq oac(,2)）具體的信令節(jié)點(diǎn)如下：根據(jù)信令流程也就是說當(dāng)RL Setup Response已經(jīng)完成后，才會(huì)出現(xiàn)這種情況。3.2.2 常見原因1）資源不足：主要是信道資源、碼資源、功率資源等不足造成2）小區(qū)硬件故障：目前常見的RRU故障造成。3）CAC參數(shù)設(shè)置問題3.2.3 解決方法針對(duì)兩種不同的原因采用不同的措施來解決，下面分別進(jìn)行描述資源不足造成的失敗查看小區(qū)的話務(wù)量（PS業(yè)務(wù)

14、流量），看一下小區(qū)是不是真的存在資源不足（碼道資源）；通過LMT查看一下功率資源情況，是否存在TCP資源不足的問題。如果存在小區(qū)的話務(wù)量不多，而且TCP占用正常仍會(huì)出現(xiàn)擁塞造成的起呼失敗，同時(shí)又不存在任何告警信息，則在動(dòng)態(tài)數(shù)據(jù)庫管理中查看服務(wù)小區(qū)狀態(tài)，是不是存在載頻資源被閉塞的現(xiàn)象（在此處閉塞是不存在任何告警信息的）。如果是真正存在資源不足的情況，可以建議進(jìn)行擴(kuò)容。小區(qū)硬件故障一般存在兩種故障，一種是可以通過告警管理進(jìn)行顯示的故障，一種是小區(qū)本身沒有任何告警信息，屬于隱性故障。對(duì)于有告警存在的，解決之；如果不存在故障，不得己而為之的方法是對(duì)小區(qū)或RRU進(jìn)行重啟，以驗(yàn)證。海安明珠城有用戶反映，打

15、電話接通較差，經(jīng)核查此站存在射頻單元接口異常告警，后經(jīng)基站復(fù)位后告警消失，起呼正常。3.3 RRC Connection Reject （Unspecified）一旦RNC通過了CAC的驗(yàn)證，RNC會(huì)請(qǐng)求Node B配置相應(yīng)的無線鏈路資源，一般情況下最少建立一條無線鏈路，在這個(gè)過程中，由于各種不同的原因造成的失敗，RNC將給UE發(fā)送Cause為“Unspecified”的Reject。3.2.1 信令流程階段信令發(fā)生的階段如下圖所示（圖中標(biāo)注的 eq oac(,3)）根據(jù)信令流程也就是說出現(xiàn)RL Setup Failure的現(xiàn)象，才會(huì)出現(xiàn)這種情況。3.2.2 常見原因基站小區(qū)的故障造成。3.2

16、.3 解決方法解決基站小區(qū)的故障。經(jīng)查通州電大北存在板卡故障告警3.4 No Reply原因造成RRC失敗在CAC和RL Setup都已經(jīng)完成后，RNC將發(fā)送RRC Connection Setup 信令給UE，如果在規(guī)定的時(shí)間內(nèi)，沒有收到UE的RRC Connection Complete信令，那么系統(tǒng)側(cè)將會(huì)判斷本次RRC過程失敗，并且其原因值為“No Reply”3.2.1 信令流程階段信令發(fā)生的階段如下圖所示（圖中標(biāo)注的）根據(jù)信令流程也就是說出現(xiàn)在RNC發(fā)出了RRC Connection Setup信令后，并且在規(guī)定的時(shí)間內(nèi)沒有收到UE的回應(yīng)消息，才會(huì)出現(xiàn)這情況。從整個(gè)信令的流程來看，R

17、RC Connection Setup信令首先從RNC的控制面發(fā)出，經(jīng)過內(nèi)部處理，通過RNC與Node B之間的接口板，再經(jīng)過傳輸線路到Node B與RNC的接口板，然后在Node B內(nèi)部處理，再通過RRU經(jīng)Uu口到UE。在這個(gè)環(huán)節(jié)中每一個(gè)環(huán)節(jié)出現(xiàn)問題都會(huì)出現(xiàn)沒有響應(yīng)的現(xiàn)象。3.2.2 常見原因1）RNC硬件存在故障RNC內(nèi)部處理板或?qū)ν獾慕涌诎宕嬖趩栴}，不能正確地將RRC Connection Setup信令發(fā)送給Node B2）傳輸存在問題從RNC到Node B之間的傳輸存在問題，傳輸誤碼較大，丟包較多，造成不能正確地將RRC Connection Setup信令發(fā)送給Node B3）No

18、de B存在問題Node B的某個(gè)板子存在問題，有可能不能正確地接收RNC傳送來的信令，也可能不能將信令在FACH完整地傳送給RRU4）RRU存在問題RRU不能正確地接收UE上發(fā)的RRC Connection Setup Complete信令，或是不能正確地將RRC Connection Setup信令傳送給UE5）參數(shù)設(shè)置存在問題 主要是SCCPCH的功率參數(shù)設(shè)置存在問題，導(dǎo)致UE無法正確接收RRU傳來的信令。6）終端問題3.2.3 解決方法一般采用逐步判斷的方法來定位問題確定RNC已經(jīng)收到了RRC Connection Request請(qǐng)求，并且已經(jīng)發(fā)出了RRC Connection Setup 信令確定RNC內(nèi)部的各個(gè)處理板之間數(shù)據(jù)傳輸沒有出現(xiàn)問題，可以使用系統(tǒng)工具RDS進(jìn)行各個(gè)處理板之間數(shù)據(jù)包的傳輸統(tǒng)計(jì)，評(píng)估其丟包率。查看傳輸告