異常RRC及RAB建立失敗案例分析

劉中國

（中國聯(lián)通福建分公司，廈門 361009）

在一次WCDMA網(wǎng)絡(luò)的重大演唱會保障期間,重點(diǎn)保障小區(qū)出現(xiàn)了大量接入失敗，其中RRC和RAB建立成功率大幅下降，并伴隨著RTWP較大抬升。由于保障前進(jìn)行了充分的軟硬件擴(kuò)容，CE資源、Iub傳輸資源、功率資源均不會出現(xiàn)受限問題，但在用戶集中業(yè)務(wù)沖擊下，還是出現(xiàn)了大量RRC及RAB接入失敗。通過性能指標(biāo)分析原因統(tǒng)計(jì)發(fā)現(xiàn)重保基站下（Node B Id=4113）部分小區(qū)大量RRC和RAB建立失敗都集中在Iub Fail上，懷疑Iub口資源有關(guān)，但該站的傳輸資源已擴(kuò)容到60G。具體原因分析如下。

1 RRC建立失敗

1.1 WBBP板NBAP信令處理負(fù)荷原因

通過對后臺信令數(shù)據(jù)分析，并用Callfault工具中對于RRC失敗原因打點(diǎn)，可以看到41133小區(qū)絕大多數(shù)的失敗都是RL Setup Failure，而失敗的主要原因是MISC ERROR，從錯誤代碼解析出真正的原因?yàn)镮ub interface ctrl proc overload。這個原因表示基站的CPU資源過載。

首先回顧一下RRC建立的流程，從RRC建立信令流程可以看出，在UE發(fā)送RRC connection request后，RNC要求Node B建立無線鏈路，在Iub口資源建立完成后RNC才能下發(fā)RRC connection setup消息，由于RRC建立過程中RL的建立需要NBAP信令來處理，占用NBAP處理負(fù)荷，當(dāng)WBBP板因NBAP處理負(fù)荷不足時，RL建立過程就會失敗，造成RRC建立失敗。

從表1 41133小區(qū)接入失敗統(tǒng)計(jì)來看，因基站的CPU資源過載造成的數(shù)據(jù)業(yè)務(wù)RRC建立失敗次數(shù)最多。

Node B的基帶板（WBBP）中的CPU資源，是用于處理NBAP消息，按照基帶板的規(guī)格，處理能力也是有限的。其處理能力主要通過NBAP消息的數(shù)量來評估，公式如下：

表1 41133小區(qū)接入失敗統(tǒng)計(jì)

通常現(xiàn)網(wǎng)的一塊WBBP板能同時處理45條NBAP消息，2塊只能處理100條消息。從擁塞站點(diǎn)的NBAP消息計(jì)算來看，忙時平均處理負(fù)荷都已經(jīng)達(dá)到了90條以上，因此在業(yè)務(wù)突發(fā)高峰WBBP板已經(jīng)完全無法承受。

從表2中可以看出Node B的NBAP處理負(fù)荷主要受RL Setup、RL Add、RL Recfg 3個方面因素影響，其中RL Setup、RL Recfg分別在RRC和RAB的建立過程中，而RL Add主要影響在軟切換過程中，針對RL Add流程，如果基站NBAP信令處理負(fù)荷不足將使RL Add過程無法進(jìn)行，即如法進(jìn)行軟切換，這樣將會導(dǎo)致干擾增加，為了滿足已有業(yè)務(wù)的最低解調(diào)門限，UE必須提升自身發(fā)射功率。

由于整個基站W(wǎng)BBP板只有2塊（12個小區(qū)），當(dāng)基站的NBAP處理能受限時，即使所帶的個別小區(qū)業(yè)務(wù)負(fù)載不高但仍然可能出現(xiàn)RRC接入失敗的情況，這也就是所有小區(qū)的RRC建立成功率都低于90%的原因。

1.2 解決辦法

按照廠家目前基站規(guī)格，CNBAP處理能力最大只能支持100條，即使繼續(xù)增加基帶板也無法再增加處理能力，因此對于目前基站CPU過載的情況只能有下面兩種處理方法。

系統(tǒng)版本升級，在R13版本對Node B的CPU資源進(jìn)行了優(yōu)化，最大可以支持170條。

采用多基站覆蓋，通過其他基站來業(yè)務(wù)分擔(dān)。

2 RAB建立失敗

2.1 WBBP板NBAP信令處理負(fù)荷原因

當(dāng)業(yè)務(wù)在RRC建立成功后進(jìn)入RAB指配階段，從統(tǒng)計(jì)可知，幾個重點(diǎn)小區(qū)CS域RAB建立基本沒有失敗，而PS RAB建立失敗次數(shù)較多，造成這種情況的原因是按照多載波策略，F(xiàn)2載波、F3載波主要承載PS業(yè)務(wù)，CS業(yè)務(wù)主要承載在F1載波。PS業(yè)務(wù)RAB建立失敗以HSDPA、HSUPA、HSDPA_HSUPA組合業(yè)務(wù)及R99失敗為主。原因分析如下。

表2 Node B NBAP信令處理負(fù)荷統(tǒng)計(jì)

2.1.1 Iub interface ctrl proc overload

PS域RAB建立失敗中HSDPA_HSUPA組和業(yè)務(wù)失敗占絕大多數(shù)，從Callfault中對于HSDPA_HSUPA的RAB建立失敗原因的打點(diǎn)，可以看到41133小區(qū)絕大多數(shù)的失敗都是RL Setup Failure引起的，從錯誤代碼解析出原因?yàn)镮ub interface ctrl proc overload。這個原因表示基站的基站CPU資源過載，與RRC建立失敗原因一致。

首先看下RAB分配流程，如圖1，RAB分配過程中主要涉及3條NBAP處理信令，分別是圖1中第3、4、7條信令，主要是完成SRNC向所控制的Node B發(fā)送無線鏈路重配置準(zhǔn)備消息RADIO LINK RECONFIGURATION PREPARE，請求所控制的Node B準(zhǔn)備在已有的無線鏈路上增加一條（或多條）承載RAB的專用傳輸信道（DCH）.再Node B分配相應(yīng)的資源后，向所屬的SRNC發(fā)送無線鏈路重配置準(zhǔn)備完成消息RADIO LINK RECONFIGURATION READY，通知SRNC無線鏈路重配置準(zhǔn)備完成，最后SRNC向所控制的Node B發(fā)送無線鏈路重配置執(zhí)行消息RADIO LINK RECONFIGURAT ION COMMIT。當(dāng)RAB指配流程中發(fā)生因NBAP處理負(fù)荷不足造成RL重配置失敗或者同步失敗時，RAB流程失敗。

2.1.2 解決辦法

參照RRC建立失敗結(jié)論，在受限于Node B所能處理的最大NBAP信令處理能力時，最好的辦法就是升級到RNC版本到RAN13。

圖1 RAB建立中NBAP過程

2.2 HICH信道與RGCH信道配置原因

2.2.1 Requested Configuration Not Supported

在對RAB建立異常小區(qū)進(jìn)行分析時，除了Iub interface ctrl proc overload原因外，經(jīng)分析還存在大量的Requested configuration not supported原因造成的失敗。

將兩種失敗原因進(jìn)行統(tǒng)計(jì)，發(fā)現(xiàn)Node B CPU過載導(dǎo)致的RAB建立失敗133次，而請求配置不支持導(dǎo)致的RAB建立失敗高達(dá)5134次(占失敗比例的97.47%)。

由Iub_interface_ctrl_proc_overload導(dǎo)致的RAB建立失敗在上面RRC建立失敗已做分析，那Iub_interface_requested_configuration_not_supported原因是如何產(chǎn)生；核查參數(shù)設(shè)置發(fā)現(xiàn)保障小區(qū)HSDPA準(zhǔn)入用戶數(shù)為64個，HSUPA準(zhǔn)入用戶數(shù)為48個，即HSUPA業(yè)務(wù)第49個用戶接入時，RNC將進(jìn)行準(zhǔn)入判決，拒絕該用戶接入，因此對保障小區(qū)的HSUPA準(zhǔn)入用戶數(shù)設(shè)置為48個，將允許更多HSUPA用戶數(shù)接入，但在保障中忽略了一個問題，當(dāng)ERGCHEHICH CODENUM=1時，Node B側(cè)E-RGCH信道只能承載20個用戶，即使RNC將第21個HSUPA用戶準(zhǔn)入，該信道也不能承載，所以ERGCHEHICHCODENUM=1信道配置不足是導(dǎo)致HSPA業(yè)務(wù)RL SETUP失敗的主要原因，最終體現(xiàn)在Iub口請求配置不支持。

2.2.2 解決辦法

在HSUPA準(zhǔn)入用戶數(shù)設(shè)置超過20時，要修改E-RGCH信道個數(shù)，ERGCHEH-ICHCODENUM=2或3。

2.3 多載波組網(wǎng)策略設(shè)置不當(dāng)原因

2.3.1 DRD(直接重試)流程失敗

為了更好的理解DRD流程失敗原因，介紹下RAB DRD流程，首先H業(yè)務(wù)在F1載波上發(fā)起RRC建立，然后通過RAB階段的負(fù)載平衡DRD算法到F2、F3載波，RB Setup小區(qū)在F1載波下發(fā)，但RB Setup Complete消息在F2上回復(fù)。 對于HSDPA業(yè)務(wù)的RAB建立失敗，從統(tǒng)計(jì)來看建立失敗原因值為RB_WAIT_UE _RBCFG_TIMEOUT。也就是說UE在第一載波上收到RB SETUP請求，但沒有RB定時器超時前在第二載波上回復(fù)RBSETUP COMPLETE消息，造成RB建立失敗。

在現(xiàn)網(wǎng)的雙載頻方案中，業(yè)務(wù)采用基于功率的負(fù)載平衡的DRD進(jìn)行分擔(dān)（LDBDRDSWITCHHSDPA=ON,LDBDRDCHOICE=User Number），同時F1載波去激活HSDPA與HSUPA業(yè)務(wù)功能，當(dāng)H業(yè)務(wù)從F1小區(qū)接入后，會按照用戶數(shù)通過負(fù)載平衡DRD盲切換到F2或F3載波，并在F2或F3小區(qū)上進(jìn)行業(yè)務(wù)。

從后臺跟蹤的信令回放，RNC在F1載波下發(fā)RB Setup 消息5s（RB setup定時器）中后仍沒有在F2載波收到來自UE的回復(fù)RB Setup Complete消息，所以Iub口請求釋放，原因值為RB WAIT UE RB CFG TIMEOUT。但出現(xiàn)RB建立超時的原因不確定，重新分析后臺小區(qū)監(jiān)控?cái)?shù)據(jù)發(fā)現(xiàn)在演唱會期間20點(diǎn)左右，主用小區(qū)(F2、F3載波)的RTWP均在-61dBm左右，說明F2、F3載波上行負(fù)載偏高。如表3所示。

重新回到雙載波組網(wǎng)策略上看，首先采用基于功率的負(fù)載平衡DRD算法（LDBDRDSWITCHHSDPA=ON, LDBDRDCHOICE=User Number），同時F1載波去激活HSDPA與HSUPA業(yè)務(wù)，這種方式說明僅僅F2、F3支持HSPA業(yè)務(wù)，在進(jìn)行H業(yè)務(wù)時只按用戶數(shù)在F2、F3載波間均衡，沒有考慮下行功率資源負(fù)載情況，更未考慮上行負(fù)載情況。其次，DRD流程是在RB建立過程中進(jìn)行的，UE在F1小區(qū)收到建立RB，要在F2小區(qū)回RB建立完成，此時，據(jù)廠家確認(rèn)，在F2載波回復(fù)RB建立完成消息時，并未考慮F2載波的負(fù)載，如上行RTWP.只是在RB建立的時候會攜帶上行最大的發(fā)射功率Maximum allowed UL TX power，給出最大使用的功率范圍，所以，當(dāng)在UE接入到F2小區(qū)時，并未考慮F2載波的負(fù)載情況來看調(diào)整對應(yīng)的UE發(fā)生功率，因此在F2載波RTWP在-60dBm時，仍以在F1載波所使用的UE功率，必然造成RNC成功收到上行RB Setup Complete消息的概率大大降低，導(dǎo)致RAB建立失敗。

表3 實(shí)時監(jiān)控RTWP指標(biāo)

2.3.2 解決辦法

在多載波策略中，關(guān)閉基于負(fù)載平衡DRD算法，開啟基于業(yè)務(wù)優(yōu)先級的DRD算法和基于測量的DRD功能，使得多載波業(yè)務(wù)建立時充分考慮載波間的負(fù)載情況，降低DRD流程失敗概率。

3 結(jié)束語

重點(diǎn)保障基站大量業(yè)務(wù)突發(fā)，對網(wǎng)絡(luò)沖擊很大，往往出現(xiàn)不可預(yù)知的非常規(guī)問題。本文中分析的接入性能變差原因主要是WBBP板處理負(fù)荷及信道配置不足、多載波組網(wǎng)策略不當(dāng)?shù)仍蛟斐傻模@幾種造成RRC及RAB建立失敗的問題都非常規(guī)性原因，希望3G保障引以為戒。

[1] 3GPP TS 25.331: RRC Protocol Specification[S].

[2] 3GPP TS 25.433 UTRAN Iub interface Node B Application Part (NBAP)Signaling[S].

[3] 胡文蘇. WCDMA KPI監(jiān)控和優(yōu)化指導(dǎo)書[深圳][Z]. 深圳：華為技術(shù)有限公司，2008.