接通率指标提升优化手册RAB拥塞优化

大唐移动接通率指标提升优化手册RAB拥塞率指标的提升Build Excellent TD-SCDMA Network 9目 录1接通率指标定义和解释31.1 话音业务RRC和RAB建立成功率涉及的计数器31.2 接通率的计算公式31.3 指标的详细解释42 UE接入过程信令流程分析62.1 信令接入分析62.2 RAB拥塞过程分析72.3.1 Assignment Request发送给RNC后RNC直接返回失败81 RAB拥塞过程分析RAB过程是指CN给RNC下发了RAB Assignment Request消息后，RNC给CN回RAB Assignment Response消息前，具体流程如下图：从上图中可以看出CN给RNC下发了RAB Assignment Request消息后RNC直接回失败主要有以下几部分的原因：为UE申请无线资源失败、 Uu口RB建立、Iub口Radio Link重配置、Iu口Iuup建立或Gtpu建立过程；下面针对为UE申请无线资源过程中RRM分资源失败的情况给出解决办法，通过CDL记录的失败原因进行统计时可以按照RAB Setup Failure消息里的EventPara字段来统计。1.1 Assignment Request发送给RNC后RNC直接返回失败如果RNC内没有发起RAB的建立过程而直接给CN返回失败则需要检查RAB失败原因，如果原因为“RRM_ALLOCATE_RESOURECES_FAILURE”，则说明RRM分资源失败或小区拥塞。RRM进行资源分配的顺序依次是码需求、码判决和码分配，码需求主要是得到新用户或用户业务发生变化时总的需要的码资源情况；主要是查询相关静态配置得到。码判决是指用户接入或重配置时当前小区码资源（载波、时隙）能否接纳的判断；码分配是指业务建立、修改、删除时为用户分配新的物理信道和相关参数等。通俗来讲通俗来讲码需求就是得到本次请求（包括新请求业务和已有业务）需要的总的码资源，码判决是判断可以在哪些载波哪些时隙上接入，码分配就是具体的分配过程。只有前面的过程通过了才可能进行下一个过程的判断，即如果码需求阶段就失败了就不会再进行码判决的判断。所以RRM资源分失败也一般是这三个环节出了问题。码需求失败需要具体情况具体分析，不排除静态参数没有配置的因素。下面就目前外场出现较多的码分配失败和码判决失败问题给出解决办法。1.1.1码分配失败解决办法如果RRM_ALLOCATE_RESOURECES_FAILURE/RAB Setup Failure消息里的失败原因是码分配失败一般来说导致这种情况的原因有两个：参数错误、程序有BUG。可以按照下面方法首先排查是否参数设置错误：1、时隙格式配置错误，业务对应组合索引表中DL L1表中的Modulation、TfciBits、TpcSsBits配置不匹配。在QPSK方式下，TPC/SS不能为3，应该按照标参配置（目前为2）。标参之前有个版本配置错误了，已经修改过来了，但外场很多地方参数还是错误的。MuxIdx组合索引号13000静态(可创建、不可修改) Modulation调制方式010-QPSK, 1-8PSK静态(可创建、可修改) PuncturingLimit打孔限制015此参数限定了物理层的打孔数量。015对应于40.100%，即（40+N*4），N=015，步长为4。物理层被打孔的比特占总比特的百分比限制在如下范围：0(15*4)%，步长为4。静态(可创建、可修改) TfciBitsTFCI编码位数432TFCI编码位数。(4, 8, 16, 32)静态(可创建、可修改) TpcSsBitsTPC/SS编码位数048TPC/SS编码位数。(0, 2, 3,4, 8, 16, 32, 48)静态(可创建、可修改)  2、时隙类型是 “窗优化”，业务需要SF4或者SF1的码道时，会出现资源分配失败。如：上行按照32k接入，且32k+3.4k需要的码资源是SF4的码道；则会出现资源分配失败；业务上行按照32k接入有3种情况：申请的是32k；或者CAC表，定制速率设置的是32k；再或者CAC表没有设置承载速率但申请速率资源不足降速到32k。该参数在rCellTs表中，应该配置为0:该时隙SF不作限制; TsType时隙类型050: 0,1: 0,2: 0,3: 0,4: 0,5: 0,6: 0说明：上行公共信道所在时隙, 时隙类型配置需要与公共物理信道所用码道保持一致。0:该时隙SF不作限制;1:Midamble K = 8,该时隙的业务只采用SF=8,信令SF=16;2:Midamble K = 8,该时隙的业务只采用SF=2,信令SF=16;3:Midamble K = 8,该时隙的业务同时采用SF=8和SF=2,SF=2采用c2(1),信令SF=16;4:Midamble K = 8,该时隙的业务同时采用SF=8和SF=2,SF=2采用c2(2),信令SF=16;5: 窗优化分配类型；时隙类型限制仅针对UL时隙, DL不受影响。与物理层同频算法有关；只要邻小区跟当前小区有同频, 那么，该载频上就应有时隙类型限制。动态(可创建、可修改)3、HSDPA算法表中，打开了DPCH不连续开关可能会导致资源分配失败，对应BUGXA00028323 ，但是目前外场版本没有归并该BUG。具体表现为：不连续分配时，当接入用户多了（达到了复用的最大用户数）后，有用户进行了释放，再接入用户复用释放的码道时会导致码分配失败。应该将该参数配置为连续。 DpchContinueDistributeTagHSPA中DPCH是否采用不连续分配0101不连续分配；0连续分配。在不连续分配中，分给UE的上行速率不根据PS上行指派速率, 而是从PS下行指派速率得到；在连续分配中，上行配置根据PS上行指派速率和34.108中的上行配置。动态(可创建、可修改)1.1.2码判决失败解决办法如果RAB Setup Failure消息里的失败原因是码判决失败（包括载波判决失败，这里以上行独立载波判决失败为例）可以通过小区下五分钟上报一次的RRM性能统计消息Cell USER distributing查看资源使用情况：比如我们在2009-8-26 15:10发现有用户建立业务失败的情况，那么我们可以查看该时刻之前最后一次Cell USER distributing消息，上图给出的是2009-8-26 15:08:22时刻RRM上报的CDL信息，其中圆角矩形框里记录的是5分钟内小区内存在的HSDPA用户数，HSDPA_Max_User_Number是指5分钟内同时存在的最大HSDPA 用户数，此例为4说明5分钟内最多同时接入了4个HSDPA用户；HSDPA_Aver_User_Number是指5分钟内平均存在的HSDPA用户数，这里的平均是指5分钟内每10S就会统计一次在线HSDPA用户数，这些数的平均值乘以100就是5分钟内的HSDPA_Aver_User_Number，此例中为400。通过这些数据可以大体推断某一时段在线用户个数，结合CDL继续分析该时段内的确切在线用户数确定是否有挂用户的现象发生。另外可以通过下图查看资源占用情况，从而推断出是不是真的没有资源导致当前用户接入失败。下图中TimeSlot1BRUAverOccupiedNumber指5分钟内时隙1的BRU平均占用情况，是5分钟内每10S统计一次时隙1的BRU占用数目，这些数的平均值乘以100就是5分钟内的TimeSlot1BRUAverOccupiedNumber,此例中为1573；TimeSlot1BRUMaxOccupiedNumber是指5分钟内时隙1最大使用BRU数，此例中为16，说明5分钟内时隙1最多有16个BRU被占用。可以推断出时隙1的BRU基本上已被占用完，再有用户进来一般上行要接在时隙2上。其余各时隙同时隙1，不再赘述。如果在时隙2上接入失败需要查看RRC建立完成消息里带的UE能力，UE能力一般都是单时隙支持最多两个码道，此时如果业务也需要两个码道而SICH也配置在时隙2上时业务会接入失败。解决办法是如果业务需要SF8的两个码道，可以尝试修改为需要SF4的一个码道，但是时隙类型需要配置为不限制。还有一种方法是查看UE列表来推断码道占用情况建立业务的UE查看其在当前失败业务接入时已经挂机，或者通过该UE的最后一条Radio link Deletion Request消息判断它该时刻已经切出小区。如果已经挂机或切出小区可以不去管它，因为资源释放掉不会影响当前用户接入。对于没有挂机的用户，通过Radio link Reconfiguration Prepare消息查看其码道占用情况，切入小区的用户可以看到它的Radio link Setup Request消息，下图以Radio link Reconfiguration Prepare为例说明码道占用情况，如果码道全部被占用了就说明实在没资源接入属于正常失败，如果这种现象持续存在可以考虑向移动申请扩载频或加站解决。1.1.3 通过调整全网小区CAC算法的下行接入限速来提升小区对R4用户的接入能力目前全国各个项目配置的小区大都是2上4下，3个载波，其中2个H载波，一个R4载波， H载波为主载波示意图：R4载波为主载波示意图：一个下行384业务就可能把下行时隙占完，其它业务接不进来也是导致资源分配失败的原因之一。为了提升小区对R4用户的接入能力，建议把CAC表里的下行3类业务的默认承载速率都配置为128000，对于修改后R4下行还拥塞的，在移动扩容前就先调整到64000。DefaultBearRateforClass1RAB建立或重定位为1类用户定制的承载速率042949672950: 640001: 32000UINT32 arry(2)运营商在RAB建立时，为1类用户定制的承载速率。0表示不限制速率。0表示的是下行1表示的是上行动态(可创建、可修改)DefaultBearRateforClass2RAB建立或重定位为2类用户定制的承载速率042949672950: 640001: 32000UINT32 arry(2)运营商在RAB建立时，为1类用户定制的承载速率。0表示不限制速率。0表示的是下行1表示的是上行动态(可创建、可修改)DefaultBearRateforClass3RAB建立或重定位为3类用户定制的承载速率042949672950: 640001: 32000UINT32 arry(2)运营商在RAB建立时，为1类用户定制的承载速率。0表示不限制速率。0表示的是下行1表示的是上行动态(可创建、可修改)另外，在容量较高的情况下，时隙下的预留资源数可以考虑取0；TsReservedBruNum切换预留BRU数量01606: 0本时隙为切换预留的码的数量。说明：TS0不适用（TS0可设置为0）。主载波的TS建议按照标定配置。其他载波配置为0。动态(可创建、可修改)但是因为这些BRU是为提高切换成功率为切换预留的，如果改为0的话可能影响切换成功率。在容量降低时可以考虑再按照标定配置。1.2 NodeB Mac挂资源解决建议对于MAC挂资源问题可能之前机房同事理解不一致，为了避免误分析，再统一下确认方法：同时存在以下三条告警为MAC挂资源，即：RL接入失败、APB配置消息参数有误、MAC响应失败。对此问题青岛方面验证升级了13T、14T、14T3三个版本，其中13T升级站点较多（将近30个），其中升级站点中福州路爱尊客有过MAC挂资源复现（有一个MAC挂资源的BUG没有在这个版本中升级）；14T版本升级了两个站点：三建、少年宫。升级约有一周时间，没有复现MAC问题；14T3版本目前升级了两个站点：金马来、学苑宾馆。19号是升级第三天，未见上榜；从验证结果看MAC挂资源的问题可通过升级版本解决，鉴于14T3版本功能比较综合，也许是近期基站升级的最后大版本，因此建议将出现MAC挂资源的站点都升级到14T3。1.5 技术支持用户对此文档存在疑问时，请随时联系此篇文档的主作者。杨勇（13991352127 yangyong）李鹏（18887150046 lipeng5）附录 参数修改后RAB建立验证情况1. 昆明项目验证结果参数修改前的拥塞情况：参数修改后的拥塞情况：2. 贵阳项目验证结果效果：8月24日完成了全网修改，该类问题导致的RAB建立失败次数明显减少统计时间失败原因失败次数失败原因比例（当日）8月20日拥塞：其它原因16123.23%8月21日拥塞：其它原因17625.73%8月22日拥塞：其它原因15025.00%8月23日拥塞：其它原因11421.55%8月25日拥塞：其它原因182.86%参数修改情况详见3. 兰州项目验证结果日期编号失败原因失败次数失败原因比例备注8月8日2拥塞：上行码道需求失败00.00%3拥塞：下行码道需求失败00.00%4拥塞：IuB上行ATM资源不足00.00%5拥塞：小区状态错误00.00%6拥塞：其它原因00.00%8月20日2拥塞：上行码道需求失败00.00%3拥塞：下行码道需求失败00.00%4拥塞：IuB上行ATM资源不足00.00%5拥塞：小区状态错误00.00%6拥塞：其它原因20.27%8月28日2拥塞：上行码道需求失败00.00%3拥塞：下行码道需求失败265.86%384业务导致某小区拥塞4拥塞：IuB上行ATM资源不足00.00%5拥塞：小区状态错误20.45%6拥塞：其它原因71.58%9月1日2拥塞：上行码道需求失败00.00%3拥塞：下行码道需求失败20.09%4拥塞：IuB上行ATM资源不足00.00%5拥塞：小区状态错误00.00%6拥塞：其它原因140.62%兰州有极少数小区偶尔出现过因384业务接入导致的资源分配失败，会考虑对这些小区的下行进行限速，详见