CE利用率过高或CE拥塞的优化案例 WCDMA 拥塞
周口分公司WCDMA网CE资源扩容报告_2012年10月26日

河南联通周口分公司CE资源拥塞处理报告周口W网优小组2012-10-29【摘要】从今年9月份学校开学以来,在河南周口联通市场部推行各大高校校园促销活动的带动下,周口联通WCDMA网络话务量和数据流量呈现持续增长的势头,在今年中秋节前夕话务量和数据流量均创历史新高。
随着用户量增长速度加快,特别是PS业务的迅猛发展,这就引起部分热点地区局部拥塞,主要分布在联通局点办公楼、火车站、商务区、高校园区等,主要资源受限在于CE资源和码资源,其次是功率资源和传输资源。
本报告讲解由于CE资源拥塞导致RAB建立成功率低,经过扩BPC基带处理板和重启NodeB之后仍无效果,还需要修改“NodeB上下行CE个数”参数的案例。
【关键词】CE资源RAB建立BPC基带处理板【名词解释】CE资源:将每一个资源单位称为CE(即Channel Element),CE的定义为:处理12.2k业务需要占用的资源。
CE属于逻辑概念,非物理属性,其他业务占用的资源都按照CE进行折算。
以基带处理板BPC板为例,它的容量为:192个上行CE和192个下行CE。
中兴BPC基带处理板处理能力如下表所示:中兴BPC基带处理板各种业务的资源消耗如下表所示:【现象描述】9月17日在分析周口WCDMA质差小区时,发现周口师范学院5号楼3小区出现在“RAB建立成功率质差小区”项,而在9月18号发现周口师范学院5号楼3个小区均出现在“RAB建立成功率质差小区”项。
在周口WCDMA以往出现过的质差小区项中,已有两个月没在该项中发现质差小区;通过分析该站点的覆盖性质(高校站点)、近期话务量的变化和RAB建立阻塞的具体原因,最终确认由于CE资源拥塞,造成RAB大量指配失败,引起RAB建立成功率质差。
通过对该站点扩充BPC板,修改NodeB侧上下行CE个数参数并重启NodeB最终使问题得到了解决。
【问题分析】9月17日正常提取质差小区考核项指标,发现ZKWZ0317_2周口师范学院5号楼_3出现在RAB建立成功率质差小区之列,9月18日提取质差小区指标,发现ZKWZ0317_0周口师范学院5号楼_1、ZKWZ0317_1周口师范学院5号楼_2、ZKWZ0317_2周口师范学院5号楼_3均出现在RAB建立成功率质差小区之列。
载波扩容方案

WCDMA双载波扩容方案目录一、CE资源的扩容方案 (1)1.Node B 硬件容量概述 (1)2.现网CE配置方案 (1)3.S111高配置基站CE的详细配置 (2)4.判断CE拥塞的指标 (2)二、码资源的扩容方案 (3)1.码资源概述 (3)2.码资源利用率的算法 (4)3.判断码拥塞的指标 (4)三、结论: (4)1.资源受限判断 (4)2.数据分析 (4)一、CE资源的扩容方案1.Node B 硬件容量概述NodeB中最重要的硬件资源就是可以使用的CE数量,CE是位于FlexiBTS中的系统模块的DSP,用于基带处理。
上下行各一个CE可以对应一个AMR用户的上行和下行容量,CE 的升级步长为1。
NodeB的硬件端口拥塞将显示NodeB硬件资源的不足。
每一类RAB的建立都需要不同数量的CE资源,因此没有足够的CE数将导致新业务无法建立,这也意味着硬件资源拥塞。
2.现网CE配置方案3.S111高配置基站CE 的详细配置每个基站固定分配给HSDPA 72*3=216个CE ,这216个CE 固定被HSDPA 单独占用,且HSDPA 不能占用除此以外的CE 资源;除了固定分配给HSDPA 的216个CE 之外,剩余的CE 由R99和HSUPA 共享使用。
其中HSUPA 最多能占用4.判断CE 拥塞的指标判断CE 拥塞观察两种指标:主动测量指标和被动测量指标。
主动测量指标来考量CE 的占用情况:上行CE 占用率以及下行CE 占用率。
当占用率超过70%时,建议进行CE 扩容。
被动测量指标有以下几种:由于基站能力导致RRC 建立失败的百分比、基站能力导致实时RAB 建立失败的百分比、基站能力导致PS 建立失败的百分比、基站能力导致HSDPA 建立失败的百分比、基站能力导致HSUPA 建立失败的百分比。
取11月13号晚8点到9点的数据,可以看到当平均CE占用率超过70%时候,将会出现CE的不足而导致的业务建立失败。
G国V运营商UTRAN项目搬迁后CE拥塞导致客户投诉案例分析

G国V运营商UTRAN项目搬迁后CE拥塞导致客户投诉案例分析无线网络规划部侯昌洪/46867【摘要】V运营商是全球最大移动运营商之一,其专业水平和国际化是毋庸臵疑的,对网络质量相当重视. 2007年底我司获得V运营商在G国子网UTRAN搬迁合同,2008年6月开始实施搬迁.搬迁第一个cluster后,网络出现大面积CE(信道单元)拥塞,添加CE后网络恢复正常.但是在随后3个月内该问题不断升级,最后导致客户从低层到高层的总投诉,最后我司不得不承诺赠送部分CE资源直3个月直到升级新的设备为止. 为什么一个看似简单的问题出现如此严重的后果呢? 本文对前期准备,中期实施和后期解决的全过程进行了回顾,分析总结了该问题发生的根源,希望对其他项目有借鉴作用.【关键字】网络设计、UTRAN、Cluster、CE(信道单元) 、搬迁、话务模型、Traffic背景众所周知, V运营商是全球第一大移动运营商, 在全球有很多子网, G国就是其中一个子网之一. 2007年底我司获得V运营商在G国子网UTRAN搬迁合同. 中标后, 2008年2月至4月我司根据客户提供的数据进行了网络设计, 输出了站点CE, IUB等资源配臵等信息. 客户根据我们网络设计配臵向我司进行了设备采购. 2008年6月搬迁第一个cluster后出现大面积因为网络Traffic增加导致CE资源不够的拥塞. 我们临时给客户进行了扩容, 但是市场要求客户必须付款才能进行后续站点的CE扩容. 由于客户前期是根据我们的网络设计进行购买的(虽然我们在做网设时多次提醒市场和客户, 根据客户提供的话务模型无法得出正确的配臵, 不能作为硬件采购的参考. 但是都没有引起市场和客户的重视.), 这个时候客户就不干了, 问题不断升级,最后导致客户从低层到高层的总投诉,最后我司不得不承诺赠送部分CE资源直3个月直到升级新的设备为止. 为什么一个看似简单的问题出现如此严重的客户投诉后果呢?分析1. 对搬迁后网络话务量估计不足搬迁前网络只支持voice, VP, PS R99, HSDPA1.8M和部分HSDPA3.6M业务. 而搬迁后除了支持上述业务外, 全面支持HSDPA3.6M和HSUPA2M业务, 特别是HSUPA业务需要消耗非常多的CE资源. 搬迁前, 我们向客户索要搬迁前网络信息和客户的市场销售策略, 迟迟没有得到客户的回应, 所以对现网话务量估计不足, 没有预先知道HSUPA用户会在搬迁后大量增加. 所以在第一个cluster搬迁后, 由于HSUPA用户的大量增加, 消耗了非常多的CE资源, 导致很多站点出现严重的CE拥塞. 打开HSUPA DCCC算法后, 部分站点CE拥塞问题解决, 但是这是以牺牲用户感受为代价的.2. 话务模型不准导致网络设计结果不准确搬迁前根据合同我们需要对未来网络做一个详细的设计, 得出站点资源配臵供客户采购参考. 客户给我们提供了分阶段站点数量, 站型, 大致用户数和话务模型等信息. 我们根据客户提供信息计算出站点资源配臵根本无法达到要求, 不能当作客户购买硬件配臵的参考. 我们技术人员多次知会市场和客户,指出是因为客户给的话务模型中HSUPA吞吐率过低, 而HSUPA又需要消耗很多的CE资源, 所以计算出来的配臵严重偏低,不能作为采购参考,对未来网络配臵无法起到指导作用. 如果按照计算出来的配臵购买硬件, 后续会出现严重CE拥塞问题. 但是这个问题没有引起市场和客户的足够重视, 最后还是按照客户给的原始数据得出的低配臵进行设备销售的.3. 市场销售不够灵活首先客户给的话务模型不准, 导致网络设计出来的配臵严重偏低, 市场和客户都知道这个问题,但是市场还是按照网设结果进行设备销售. 如果市场在销售上灵活一些, 明确告知客户网设结果不准, 在硬件配臵时至少应该留一定的余量, 这样也会一定程度的减少问题的发生. 另外在搬迁后发生CE拥塞, 我们不应该急于让客户重新购买CE进行扩容. 由于客户是按照我们推荐配臵购买的CE资源,刚用上就发生拥塞而且需要扩容,对于谁来说都难以接受.前车之鉴,后世之师1. 网络参数设臵一定要合理网络参数在搬迁前一定要进行映射,和严格评审. 有些默认参数不一定是最优参数, 要考虑现网情况进行优化设臵.2. 网络设计一定要准确首先应该确保网络设计输入参数的准确性和前瞻性,能很好的反映未来网络的发展趋势, 具有一定的容量. 在确认客户给的信息不准的情况下,一方面继续向客户索要进一步的数据, 说明信息不准的后果;另一方面一定要坚持不要提交不准确的结果,即使提交也要严重申明不能作为配臵参考.3. 销售策略要灵活如有由于客户提供信息不准确,导致计算配臵很低,跟实际情况严重不一致时. 向客户推荐设备配臵时就应该对客户进行预警,明确提出需要一定的余量.4. 灵活应对客户投诉针对客户不断升级的投诉,一方面从技术层面解决一些问题,如打开HSUPA DCCC算法开关,很多站点CE拥塞问题减少或者没有拥塞问题了,减少了拥塞站点的数量;然后先扩容拥塞站点,再对客户进行引导, 让客户再进行购买.。
关于WCDMA基站CE容量和扩容的相关问题

爱立信现网中各种配置的CE数如下:S111高配硬件384/256 (下行/上行)license 144/240 (下行/上行) 中配硬件384/256 (下行/上行)license 96/144 (下行/上行)低配硬件384/128 (下行/上行)license 48/112 (下行/上行)在CE受限的经典场景中(不考虑传输受限于功率受限的场景):12.2kbps(语音)承载对应的等效CE数为1,64kbps(视频)承载对应的等效CE数为7,144kbps(R99)承载对应的等效CE数为13,384kbps(R99)承载对应的等效CE数为 22 ,关于计算是考虑WCDMA是自干扰系统,做出10%的系统预留,以防止拥塞导致容量迅速枯竭;经典软切换比例为20-40%(max),此时最小系统容量:144/2/1/3=24路12.2kbps 话音【144CE*(100%-10%-40%)/1CE每话音/3扇区】但是实际情况每个小区容量并不是非常均衡的所以在CE受限的场景中一个高配基站(不考虑扇区)可以同时容纳72路至130路话音。
相比之下R99体系下PS业务对CE的消耗是相当可观,在一个CE受限的场景中一个高配基站可以容纳4个PS384 业务(计算略)。
当前PS业务绝大多数都已经承载在HSPA上了,在10个码字的场景中:理想情况时候采用1/1卷积(理想无线环境不能实现):3.84Mc*4bit/16*10=9.6Mbps信噪比相对较好终端采用3/4卷积:3.84Mc*4bit/16*10*3/4=7.2Mbps【3.84Mc"码片速率"*4"sf16,2∧4=16"*10个码字/16码树*3/4卷积】但是大多数时候由于无线环境不尽理想,仅能采用1/2卷积时:3.84Mc*4bit/16*10/2=4.8Mbps当然10共享个码字,也不会给一个用户全部占用。
在HSPA中更多时候是功率受限的场景。
电信项目功率拥塞问题解决一例200905

电信项目功率拥塞问题解决一例问题类型:功率拥塞问题原因:载频闭塞排查人员:裴宇地点:国内电信项目吉林四平业务区时间:20090420提交人员:裴宇审核人员:1.问题描述14日接到投诉说四平BSC1在话务忙时存在功率拥塞现象,对四平BSC1的性能进行统计,发现拥塞问题确实存在,对近来几天的统计如下表所示:2.处理过程对各单站的小区拥塞次数进行统计,发现14日话务忙时的功率拥塞主要来自于四平BSC1的129号水泥厂基站。
该站的拥塞和话务量统计如下所示,语音和数据业务均存在拥塞,并且数据业务拥塞比较严重:很小,按理说不至于导致功率拥塞(尤其是该站的第三扇区)。
对水泥厂基站的发送功率进行定标并查询,一切正常;在对水泥厂基站检查后未发现问题的情况下,回过头来对129号站的地理位置进行确认分析,发现该站为一双载频基站,并且在其第三扇区的方向存在另一个站点公主岭良种厂基站,从地理位置上来看,水泥厂第三扇区和公主岭良种厂基站存在切换关系,按理说两个基站间会对其周围的话务量进行分担,如果水泥厂基站产生功率拥塞,通常公主岭良种厂基站也应该存在相同的功率拥塞现象。
图一水泥厂基站地理分布图对公主岭良种厂基站的话务量和拥塞情况进行统计,发现该站的话务量也很小,并且没有任何功率拥塞,统计如下:在业务观察的时候奇怪的事情发生了,发现在209公主岭良种厂基站的所有语音业务均在201载频起呼,283载频没有一例语音业务产生(四平地区所有双载频配置的都是283载频承载语音业务,201载频承载数据业务)。
业务观察如下图所示:图二后台语音业务的业务观察再次对209号公主岭良种厂的话务量情况按载频分别进行统计,发现该站的第一载频(283载频)没有任何话务量,而语音和数据业务的话务量都集中到了第二载频上(201载频)。
对209号公主岭良种厂的双载频的无线参数配置进行检查,一切正常;对该站的两个载频的发射功率进行检查,也一切正常;最终在对后台动态管理里的资源管理功能进行查看时发现,209号公主岭良种厂基站三个扇区的地第一载频被闭塞掉了。
07-WCDMA网络优化案例探讨

WCDMA无线网络优化案例探讨中兴通讯学院课程内容覆盖优化案例 导频污染优化案例 邻区配置优化案例 切换优化案例 小区选择和重选优化 呼通率优化案例 掉话率优化案例1覆盖优化案例覆盖优化依据无线覆盖好体现为EC和EC/IO指标均好覆盖优化案例覆盖优化的主要手段优先通过调整天线方位角和下倾角来改善局部地区覆 盖 调整基站发射功率 调整基站站高 必要时需要迁站,加站或减站2覆盖优化案例覆盖优化案例1从路测的数据分析可以看 到,东湖路一段(图中A 区域)UE接收功率在 -85dBm以下。
对应于东湖路上UE接收功 率较弱的区域(图中A区 域),导频信号质量也很 差,Ec/Io<-13dB覆盖优化案例覆盖优化案例1-续问题分析:对路测数据进行回放分析,发现东湖路上信号覆盖不好的一 段,是由署前路基站第三扇区(扰码438)的旁瓣来覆盖。
而 规划设计覆盖该区域的署前路基站第二扇区(扰码437)信号 却很弱,无法进入激活集,到楼顶天面上发现署前路基站第 二扇区(扰码437)正前方建筑密集阻挡严重,影响了该扇区 的覆盖。
而东湖基站第一扇区(扰码439)天线的正前方几十 米处也被一排高层住宅完全遮挡,也无法覆盖到东湖路的该 段区域。
3覆盖优化案例覆盖优化案例1-续解决措施:将署前路第二扇区方位角由原 来的240度调整为230度,以增 强对东湖路该路段的覆盖。
• 优化后效果: 天线方向角调整过后,进 行路测验证效果。
从路测 数据的分析可以看到,东 湖路该路段的导频覆盖明 显改善。
覆盖优化案例覆盖优化案例24覆盖优化案例覆盖优化案例2-续问题分析:A点距离Sousse2站点大约2.7公里。
A点是一个上城间公路的入 口,有大约90度的拐弯,Erriadh TT基站228小区的信号因为受 到遮挡突然变弱。
B点距离CTT Skanes站点2km左右。
B点所在的沿海道路海拔比 CTT Skanes站点的低,这样CTT Skanes站点332小区的信号要穿 透路边许多2~3层的房子才能被手机接收。
CDMA网络拥塞问题分析和解决方案指导书
CDMA网络拥塞分析和解决方案指导书中国电信集团公司2010年12月目录一、概述 (3)二、网络产生拥塞的原因 (3)2.1BTS侧 (3)2.1.1 物理信道资源不足 (4)2.1.2 逻辑业务信道资源不足 (4)2.1.3 基站前向功率不足 (4)2.1.4 寻呼信道资源不足 (5)2.1.5 接入信道资源不足 (5)2.2传输侧 (6)2.3BSC侧 (6)三、拥塞的发现及预测 (6)3.1日常监控 (6)3.2阶段性系统负荷分析 (7)3.2.1 现网负荷分析 (8)3.2.2 用户发展引起的负荷增长及拥塞预测 (8)四、拥塞解决方案 (8)4.1W ALSH码资源不足 (8)4.2CE资源不足 (9)4.3前向功率不足 (10)4.4寻呼信道资源不足 (10)4.5接入信道资源不足 (11)4.6传输链路资源不足 (12)4.7BSC各板件资源不足 (12)五、突发高话务拥塞预测及解决方案 (12)5.1大型集会及活动突发高话务 (12)5.2节假日期间短信突发高话务 (13)一、概述拥塞是所有具备承载业务功能的无线网络系统中常见的问题,是引起网络质量和用户感知下降的重要原因之一。
拥塞对用户感知的影响,主要体现在:呼入呼出困难、多次拨打才可接通、有信号但是无法起呼、容易掉话、通话质量较差等方面。
当前正处在用户快速增长的时期,网络负荷不断增加,如果不注意进行网络的负荷及拥塞分析,容易发生大面积的拥塞事故。
因此,必须采取措施进行拥塞的预防与控制。
本指导书通过分析网络产生拥塞的原因,给出了进行拥塞分析的常用方法,并针对各种拥塞场景给出了解决思路。
各省可参照进行相关的分析及处理,预防及解决网络的拥塞问题,改善网络质量,提升用户感知。
二、网络产生拥塞的原因CDMA用户的一次呼叫,需要涉及BTS的Walsh码、CE、前向功率、公共信道开销等资源;需要涉及传输链路资源;需要涉及BSC 中信令处理板、声码器等资源。
WCDMA网络分组RAB指配失败分析与优化
WCDMA网络分组RAB指配失败分析与优化文章主要介绍了WCDMA网络中分组RAB指配的各种失败原因,并针对网络中出现较多的失败分析问题所在,总结出有效的优化方法,以降低现网RAB指配失败次数,提升RAB指配成功率和3G PDP激活指标,进而有效提升用户感知。
【摘要】【关键词】WCDMA RAB指配 Iub口 CE资源 3G PDP激活柯利忠 吴宁泉 唐志超 中国联合网络通信有限公司深圳分公司1 前言随着3G业务的发展,WCDMA用户和流量均出现飞速增长,WCDMA无线接入网资源日趋紧张,期间无线侧进行持续扩容,从增加室内外站点到全网的单载波进行双载波扩容,有效地缓和了用户和流量快速增长带来的冲击。
然而全网仍有较多的分组无线承载RAB指派失败,经常造成3G PDP激活成功率大幅波动,影响网络质量。
为此,笔者通过长期问题跟踪和接口数据抓取分析,定位现网RAB指配失败问题,针对性地进行持续优化,取得了显著的效果。
本文总结了相关优化分析和案例供参考。
2 RAB指配信令流程RAB(Radio Access Bearer)是指用户平面的承载,用于U E和C N之间传送语音数据及多媒体业务。
UE和CN之间的RRC连接建立完成后,才能建立RAB。
RAB建立由CN发起,UTRAN执行,通过RAB指配信令流程,无线侧完成CN(SGSN)到终端的用户面承载资源的建立,建立的承载对应一个RAB ID,之后才能进行上下行数据包传送等业务。
RAB建立基本过程如图1所示:图1 RAB建立基本过程收稿日期:2012-07-03责任编辑:袁婷 *****************图2 现网某忙时接口抓取分析RAB 失败原因值统计根据现网IuPS口数据抓取分析,出现较多的标准原因值有无线接口建立过程失败(14)、UE发起信令连接释放导致(40)、UE无线连接失败(46)等,出现最多的非标准原因值(厂家自定义值)是134和130,且这部分失败次数出现更多。
4G优化案例:“Y.K”多手段应对四大高负荷场景优化解决方案
“Y.K”多手段应对四大高负荷场景优化解决方案XXXX年XX月目录“Y.K”多手段应对四大高负荷场景优化解决方案 (3)一、问题描述 (3)二、分析过程 (4)2.1高负荷优化思路 (4)2.2Y(优化):参数优化调整原则 (4)2.2.1 射频优化调整 (4)2.2.2 参数优化调整 (5)2.2.3 功能算法调整 (5)2.3K(扩容):扩容优化原则 (6)2.3.1 小区载频扩容 (6)2.3.2 新建站扩容 (6)2.3场景分类以及调整方案 (6)2.3.1 网络资源不足小区 (6)2.3.2 PRB利用率低小区 (7)2.3.3 高用户数小区 (7)2.3.4 低用户高流量小区 (7)三、解决措施 (8)3.1网络资源不足优化案例 (8)3.2高用户数小区优化案例 (9)3.3低用户高流量小区优化案例 (10)四、经验总结 (12)“Y.K”多手段应对四大高负荷场景优化解决方案XX【摘要】随着4G网络覆盖的不断完善,用户规模的不断扩大,热点区域小区负荷也逐渐升高,“高业务”、“高负荷”已成为4G网络的痛点。
在此背景下,负荷均衡功能能够一定程度上解决该问题,该功能根据服务小区和邻区负荷状态以及覆盖上的具体情况,驱使合适的用户切换去另外的相对空闲的小区上继续进行业务,这样能够更加有效地使用系统资源,以提高系统的容量和稳定性。
本文对四大高负荷场景的优化方案进行了研究和论证,在充分利用现网硬件资源的同时,使小区实现负荷均衡,有效提升网络质量和优化感知。
同时,通过论证“Y.K”优化手段在LTE网络高负荷下的有效性,总结优化经验,促进网优工作高效开展。
【关键字】4G高负荷、高负荷场景优化、负荷均衡【业务类别】参数优化一、问题描述XX电信现网随着4G用户增多,无线资源利用率越来越高,小区高负荷情况加剧,影响4G用户感知;而盲目扩容导致资源浪费,不符合客户提出精准投资的理念。
需对现网各载波间不均衡的场景进行参数优化,使得资源充分被利用。
4G优化案例:分场景优化CCE分配机制,缓解网络拥塞问题
分场景优化CCE分配机制,缓解网络拥塞问题XXXX 年XX 月目录一、概述 (3)二、优化原理和机制 (4)2.1PDCCH信道介绍 (4)2.2 PDCCH链路自适应机制 (4)2.3 PDCCH功率控制算法 (8)三、优化方案 (10)3.1优化思路分析 (10)3.2场景划分及优化参数 (14)四、优化效果呈现 (16)4.1场景1指标对比 (17)4.2场景3指标对比 (18)4.3参数配置建议 (19)五、总结及经验推广 (20)分场景优化CCE分配机制,缓解网络拥塞问题XX【摘要】随着4G用户及业务的快速增长,LTE的网络负荷越来越重,部分区域已经出现了拥塞,平时我们很重视PRB和功率的拥塞情况。
但其实CCE的拥塞带来问题更加严重。
CCE 承载着上下行调度、功控指令、HARQ等控制信息,CCE拥塞会影响到资源的分配,甚至VoLTE掉话等情况,严重影响LTE用户特别是VoLTE用户的感知体验。
特别是800M小区,由于带宽资源的限制,有相当一部分小区存在PDCCH信道拥塞、CCE分配失败的问题。
本文根据PDCCH链路自适应机制及PDCCH功率控制算法,对苏州800M小区CCE拥塞率、聚合度及MR指标分析,根据场景的不同,采用不同的优化措施,使CCE拥塞问题得到的缓解,整体网络质量也得到了明显的改善。
【关键字】CCE拥塞,VoLTE,PDCCH【业务类别】参数优化,优化方法一、概述随着近年来电信4G用户及VoLTE业务呈现爆发式增长,800M网络面临的容量压力前所未有,提高资源利用效率解决网络容量问题成为工作的重中之重;从目前对XX 电信LTE网络资源的评估分析来看,某些热点话务区域PDCCH信道容量已成为瓶颈,CCE资源不足已经严重影响到了LTE用户特别是VoLTE用户的感知体验。
为了提升LTE网络性能和用户感知,本文从LTE PDCCH下行控制信道的原理基础入手,对PDCCH链路自适应算法、PDCCH功率控制算法、PDCCH容量分配算法的实现方法、算法过程及演进过程进行了研究,并结合XX 电信LTE现网800M站点的PDCCH信道容量受限问题进行了基于算法层面的优化探索,得到了较好的成果,PDCCH容量问题得到较大程度的缓解,网络性能提升明显。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
3)NodeB LEVEL:打开SET LDCALGOPARA: LdcSwitch=NODEB_CREDIT_LDR_SWITCH-1;
2、V29 / V210 /V110版本
MOD TYPRABDCCCMC: RabIndex=45, Direction=UPLINK, Event4aThd=D6K;//假设45是交互业务128kbps的索引,修改4A门限为6K
对于HSUPA BE业务,可以修改4A门限,通过调整不同速率的HSUPA DCCC threshold rate ratio实现,比如:
CE LDR分三种,开关控制如下:
1)Local CELL LEVEL:打开ADD CELLALGOSWITCH: NBMLdcAlgoSwitch=CELL_CREDIT_LDR-1;和SET LDCALGOPARA: LdcSwitch=LC_CREDIT_LDR_SWITCH-1;
2)Local CELL GROUP LEVEL:打开ADD NODEBALGOPARA: NodeBLdcAlgoSwitch=LCG_CREDIT_LDR-1;和SET LDCALGOPARA: LdcSwitch=LCG_CREDIT_LDR_SWITCH-1;
3)NodeB LEVEL:打开ADD NODEBALGOPARA: NodeBLdcAlgoSwitch=NODEB_CREDIT_LDR-1;和SET LDCALGOPARA: LdcSwitch=NODEB_CREDIT_LDR_SWITCH-1;
对于Local CELL LEVEL,V29或者V210或者V110版本,如果本地小区UL / DL剩余的CE资源对应的SF大于Ul LDR Credit SF reserved threshold/Dl LDR Credit SF reserved threshold(ADD CELLLDR),则触发Local CELL LEVEL CE LDR。作者王德凯工号34754
所属办事处/片区
NTS交付管理部部
产品名称
无线
编写日期
2009/6/29
产品版本
BSC6810and BSC6800
审核人
案例名称:
CE利用率过高或CE拥塞的优化案例
现象描述:
CE上行或者下行利用率过高;
话统统计中出现RRC或者RAB的CE拥塞
告警信息:
检查RNC和NodeB没有与之相关的异常告警
4、HSUPA PHASE II,若HSUPA激活动态CE license,则SET CACALGOSWITCH中HsupaCeConsumeSelection选择GBR,HSUPA业务的BE RATE REDUCTION不起作用;
如果使用GBR进行CE消耗,则CE LDR不选择HSUPA用户进行降速率;如果使用MBR进行CE消耗,则在HSUPA动态信道配置DCCC开关打开的情况下,CE LDR会选择HSUPA用户进行降速率。(相对3、4点)
表1V29或者V210或者V110版本CE LDR的触发动作
Note:
1、DCH业务的BE RATE REDUCTION,必须打开DCCC开关;
2、HSUPA PHASE I,HSUPA业务的BE RATE REDUCTION,必须打开DCCC和HSUPA DCCC开关;
3、HSUPA PHASE II,HSUPA业务的BE RATE REDUCTION,必须打开DCCC和HSUPA DCCC开关,并且SET CACALGOSWITCH中HsupaCeConsumeSelection选择MBR;
5、
CE拥塞时,建议打开NodeB level的CE LDR开关。
上述的CE准入算法和CE LDR算法要起作用,NodeB必须有CE license,否则这两个算法不起作用,因为NodeB没有配置CE license,NodeB上报给RNC的CE数是Unlimited。
因此,在NodeB没有配置CE license,或者NodeB已经配置CE License,CE准入和CE LDR算法开关已经打开,这时上行或者下行CE资源仍然受限,可以考虑修改DCH BE业务的上行或者下行初始接入速率,DCH BE业务的上行或者下行DCCC门限速率、中间速率。
SET FRC: HsupaInitialRate=D32;//修改HSUPA BE业务上行的初始接入速率
SET EDCHRATEADJUSTSET: EdchRateAdjustSet=Rate_64Kbps-1&Rate_128Kbps-1&Rate_608Kbps-1;//修改HSUPA DCCC的速率集
SET EDCHTHDRATERATIO: RatioForRate128=100;//修改128kbps的门限速率比例为100%。
建议与总结:
无
附件:
相关资料:
对于Local CELL GROUP LEVEL或者NodeB LEVEL,V29或者V210或者V110版本,如果本地小区UL / DL剩余的CE资源对应的SF大于Ul LDR Credit SF reserved threshold/Dl LDR Credit SF reserved threshold(ADD NODEBLDR),则触发Local CELL GROUP LEVEL或者NodeB LEVEL CE LDR。
如果客户不同意修改DCCC速率集,那么可以通过提高改DCCC的4A门限来限制用户的升速。
对于DCH BE业务,可以修改4A门限,4A门限默认是1K,具体每种速率的门限修改为多少,需要进行测试确定。比如:
MOD TYPRABDCCCMC: RabIndex=43, Direction=UPLINK, Event4aThd=D2K;//假设43是交互业务32kbps的索引,修改4A门限为2K
RNC V210版本:
SET FRC: UlBeTraffInitBitrate=D32;//修改DCH BE业务上行的初始接入速率
SET DCCC: UlDcccRateThd=D32, LittleRateThd=D32, UlRateUpAdjLevel=3_Rates, UlRateDnAdjLevel=3_Rates, UlMidRateCalc=HAND_APPOINT, UlMidRateThd=D64;//修改DCH BE业务的上行DCCC门限速率,DCCC速率级别及中间速率
原因分析:
无
处理过程:
1、V18版本
CE LDR分三种,开关控制如下:
1)CELL LEVEL:打开ADD CELLALGOSWITCH: NBMLdcAlgoSwitch=CELL_CREDIT_LDR-1;和SET LDCALGOPARA: LdcSwitch=LC_CREDIT_LDR_SWITCH-1;
RNC V29版本:
SET FRC: UlBeTraffInitBitrate=D32;//修改DCH BE业务上行的初始接入速率
SET DCCC: UlDcccRateThd=D32, LittleRateThd=D32, UlRateAdjLevel=3_Rates, UlMidRateCalc=HAND_APPOINT, UlMidRateThd=D64;//修改DCH BE业务的上行DCCC门限速率,DCCC速率级别及中间速率
默认DCH BE业务的上行和下行初始接入速率均为64kbps,DCH BE业务的上行和下行DCCC门限速率均为64kbps,可以考虑将DCH BE业务的上行和下行初始接入速率修改为32kbps,DCH BE业务的上行和下行DCCC门限速率修改为32kbps。如果原来DCCC速率是两级,建议修改为三级,这时DCCC速率为{32kbps, 64kbps, 384kbps}或者{32kbps, 128kbps, 384kbps}。脚本如下:
同样对于HSUPA业务,也可以调整HSUPA BE业务的初始接入速率和HSUPA DCCC速率。修改时,可以参考表2和表3中HSUPA典型业务速率与扩频因子的对应关系以及不同扩频因子消耗的CE数。HSUPA BE业务上行的初始接入速率从64kbps修改32kbps,只能节省0.5个CE,因此一般不建议修改。