异常RRC及RAB建立失败案例分析

刘中国

（中国联通福建分公司，厦门 361009）

在一次WCDMA网络的重大演唱会保障期间,重点保障小区出现了大量接入失败，其中RRC和RAB建立成功率大幅下降，并伴随着RTWP较大抬升。由于保障前进行了充分的软硬件扩容，CE资源、Iub传输资源、功率资源均不会出现受限问题，但在用户集中业务冲击下，还是出现了大量RRC及RAB接入失败。通过性能指标分析原因统计发现重保基站下（Node B Id=4113）部分小区大量RRC和RAB建立失败都集中在Iub Fail上，怀疑Iub口资源有关，但该站的传输资源已扩容到60G。具体原因分析如下。

1 RRC建立失败

1.1 WBBP板NBAP信令处理负荷原因

通过对后台信令数据分析，并用Callfault工具中对于RRC失败原因打点，可以看到41133小区绝大多数的失败都是RL Setup Failure，而失败的主要原因是MISC ERROR，从错误代码解析出真正的原因为Iub interface ctrl proc overload。这个原因表示基站的CPU资源过载。

首先回顾一下RRC建立的流程，从RRC建立信令流程可以看出，在UE发送RRC connection request后，RNC要求Node B建立无线链路，在Iub口资源建立完成后RNC才能下发RRC connection setup消息，由于RRC建立过程中RL的建立需要NBAP信令来处理，占用NBAP处理负荷，当WBBP板因NBAP处理负荷不足时，RL建立过程就会失败，造成RRC建立失败。

从表1 41133小区接入失败统计来看，因基站的CPU资源过载造成的数据业务RRC建立失败次数最多。

Node B的基带板（WBBP）中的CPU资源，是用于处理NBAP消息，按照基带板的规格，处理能力也是有限的。其处理能力主要通过NBAP消息的数量来评估，公式如下：

表1 41133小区接入失败统计

通常现网的一块WBBP板能同时处理45条NBAP消息，2块只能处理100条消息。从拥塞站点的NBAP消息计算来看，忙时平均处理负荷都已经达到了90条以上，因此在业务突发高峰WBBP板已经完全无法承受。

从表2中可以看出Node B的NBAP处理负荷主要受RL Setup、RL Add、RL Recfg 3个方面因素影响，其中RL Setup、RL Recfg分别在RRC和RAB的建立过程中，而RL Add主要影响在软切换过程中，针对RL Add流程，如果基站NBAP信令处理负荷不足将使RL Add过程无法进行，即如法进行软切换，这样将会导致干扰增加，为了满足已有业务的最低解调门限，UE必须提升自身发射功率。

由于整个基站WBBP板只有2块（12个小区），当基站的NBAP处理能受限时，即使所带的个别小区业务负载不高但仍然可能出现RRC接入失败的情况，这也就是所有小区的RRC建立成功率都低于90%的原因。

1.2 解决办法

按照厂家目前基站规格，CNBAP处理能力最大只能支持100条，即使继续增加基带板也无法再增加处理能力，因此对于目前基站CPU过载的情况只能有下面两种处理方法。

系统版本升级，在R13版本对Node B的CPU资源进行了优化，最大可以支持170条。

采用多基站覆盖，通过其他基站来业务分担。

2 RAB建立失败

2.1 WBBP板NBAP信令处理负荷原因

当业务在RRC建立成功后进入RAB指配阶段，从统计可知，几个重点小区CS域RAB建立基本没有失败，而PS RAB建立失败次数较多，造成这种情况的原因是按照多载波策略，F2载波、F3载波主要承载PS业务，CS业务主要承载在F1载波。PS业务RAB建立失败以HSDPA、HSUPA、HSDPA_HSUPA组合业务及R99失败为主。原因分析如下。

表2 Node B NBAP信令处理负荷统计

2.1.1 Iub interface ctrl proc overload

PS域RAB建立失败中HSDPA_HSUPA组和业务失败占绝大多数，从Callfault中对于HSDPA_HSUPA的RAB建立失败原因的打点，可以看到41133小区绝大多数的失败都是RL Setup Failure引起的，从错误代码解析出原因为Iub interface ctrl proc overload。这个原因表示基站的基站CPU资源过载，与RRC建立失败原因一致。

首先看下RAB分配流程，如图1，RAB分配过程中主要涉及3条NBAP处理信令，分别是图1中第3、4、7条信令，主要是完成SRNC向所控制的Node B发送无线链路重配置准备消息RADIO LINK RECONFIGURATION PREPARE，请求所控制的Node B准备在已有的无线链路上增加一条（或多条）承载RAB的专用传输信道（DCH）.再Node B分配相应的资源后，向所属的SRNC发送无线链路重配置准备完成消息RADIO LINK RECONFIGURATION READY，通知SRNC无线链路重配置准备完成，最后SRNC向所控制的Node B发送无线链路重配置执行消息RADIO LINK RECONFIGURAT ION COMMIT。当RAB指配流程中发生因NBAP处理负荷不足造成RL重配置失败或者同步失败时，RAB流程失败。

2.1.2 解决办法

参照RRC建立失败结论，在受限于Node B所能处理的最大NBAP信令处理能力时，最好的办法就是升级到RNC版本到RAN13。

图1 RAB建立中NBAP过程

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

2.2.1 Requested Configuration Not Supported

在对RAB建立异常小区进行分析时，除了Iub interface ctrl proc overload原因外，经分析还存在大量的Requested configuration not supported原因造成的失败。

将两种失败原因进行统计，发现Node B CPU过载导致的RAB建立失败133次，而请求配置不支持导致的RAB建立失败高达5134次(占失败比例的97.47%)。

由Iub_interface_ctrl_proc_overload导致的RAB建立失败在上面RRC建立失败已做分析，那Iub_interface_requested_configuration_not_supported原因是如何产生；核查参数设置发现保障小区HSDPA准入用户数为64个，HSUPA准入用户数为48个，即HSUPA业务第49个用户接入时，RNC将进行准入判决，拒绝该用户接入，因此对保障小区的HSUPA准入用户数设置为48个，将允许更多HSUPA用户数接入，但在保障中忽略了一个问题，当ERGCHEHICH CODENUM=1时，Node B侧E-RGCH信道只能承载20个用户，即使RNC将第21个HSUPA用户准入，该信道也不能承载，所以ERGCHEHICHCODENUM=1信道配置不足是导致HSPA业务RL SETUP失败的主要原因，最终体现在Iub口请求配置不支持。

2.2.2 解决办法

在HSUPA准入用户数设置超过20时，要修改E-RGCH信道个数，ERGCHEH-ICHCODENUM=2或3。

2.3 多载波组网策略设置不当原因

2.3.1 DRD(直接重试)流程失败

为了更好的理解DRD流程失败原因，介绍下RAB DRD流程，首先H业务在F1载波上发起RRC建立，然后通过RAB阶段的负载平衡DRD算法到F2、F3载波，RB Setup小区在F1载波下发，但RB Setup Complete消息在F2上回复。 对于HSDPA业务的RAB建立失败，从统计来看建立失败原因值为RB_WAIT_UE _RBCFG_TIMEOUT。也就是说UE在第一载波上收到RB SETUP请求，但没有RB定时器超时前在第二载波上回复RBSETUP COMPLETE消息，造成RB建立失败。

在现网的双载频方案中，业务采用基于功率的负载平衡的DRD进行分担（LDBDRDSWITCHHSDPA=ON,LDBDRDCHOICE=User Number），同时F1载波去激活HSDPA与HSUPA业务功能，当H业务从F1小区接入后，会按照用户数通过负载平衡DRD盲切换到F2或F3载波，并在F2或F3小区上进行业务。

从后台跟踪的信令回放，RNC在F1载波下发RB Setup 消息5s（RB setup定时器）中后仍没有在F2载波收到来自UE的回复RB Setup Complete消息，所以Iub口请求释放，原因值为RB WAIT UE RB CFG TIMEOUT。但出现RB建立超时的原因不确定，重新分析后台小区监控数据发现在演唱会期间20点左右，主用小区(F2、F3载波)的RTWP均在-61dBm左右，说明F2、F3载波上行负载偏高。如表3所示。

重新回到双载波组网策略上看，首先采用基于功率的负载平衡DRD算法（LDBDRDSWITCHHSDPA=ON, LDBDRDCHOICE=User Number），同时F1载波去激活HSDPA与HSUPA业务，这种方式说明仅仅F2、F3支持HSPA业务，在进行H业务时只按用户数在F2、F3载波间均衡，没有考虑下行功率资源负载情况，更未考虑上行负载情况。其次，DRD流程是在RB建立过程中进行的，UE在F1小区收到建立RB，要在F2小区回RB建立完成，此时，据厂家确认，在F2载波回复RB建立完成消息时，并未考虑F2载波的负载，如上行RTWP.只是在RB建立的时候会携带上行最大的发射功率Maximum allowed UL TX power，给出最大使用的功率范围，所以，当在UE接入到F2小区时，并未考虑F2载波的负载情况来看调整对应的UE发生功率，因此在F2载波RTWP在-60dBm时，仍以在F1载波所使用的UE功率，必然造成RNC成功收到上行RB Setup Complete消息的概率大大降低，导致RAB建立失败。

表3 实时监控RTWP指标

2.3.2 解决办法

在多载波策略中，关闭基于负载平衡DRD算法，开启基于业务优先级的DRD算法和基于测量的DRD功能，使得多载波业务建立时充分考虑载波间的负载情况，降低DRD流程失败概率。

3 结束语

重点保障基站大量业务突发，对网络冲击很大，往往出现不可预知的非常规问题。本文中分析的接入性能变差原因主要是WBBP板处理负荷及信道配置不足、多载波组网策略不当等原因造成的，这几种造成RRC及RAB建立失败的问题都非常规性原因，希望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监控和优化指导书[深圳][Z]. 深圳：华为技术有限公司，2008.