EDGE演示区域优化总结

上传人:tia****nde 文档编号:244927793 上传时间:2024-10-06 格式:PPT 页数:41 大小:1.67MB
返回 下载 相关 举报
EDGE演示区域优化总结_第1页
第1页 / 共41页
EDGE演示区域优化总结_第2页
第2页 / 共41页
EDGE演示区域优化总结_第3页
第3页 / 共41页
点击查看更多>>
资源描述
Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,Click to edit Master title style,杭州,EDGE,演示区域优化总结,杭州移动,&,摩托罗拉,联合优化小组,2007,年,5,月,31,日,会议安排,9,:,05-9,:,10,开场白,-,移动领导,9,:,10-9,:,40,优化效果及主要工作,-,顾贤琼,9,:,40-10,:,00,规划原则,-,刘明涛,休息,10,:,10-10,:,40,优化流程简介,-,陈锋,10,:,40-11,:,00,优化实施建议,-,顾贤琼,午休,13,:,00-13,:,45,信令分析,-,刘向东,13,:,45-14,:,30,参数优化,-,刘向东,14,:,30-15,:,00,功率控制,-,刘向东,15,:,00-15,:,30,统计分析,-,申坚,项目回顾,为配合杭州网络,EDGE,演示区域的优化工作:,1,、,5,月,15,日完成优化区域测试评估并杭州移动共同制定的优化计划。,2,、,5,月,18,日对优化区域的大部分小区开通了,EDGE,功能,,3,、,5,月,21,日完成了优化区域的初步的性能评估,4,、,5,月,25,日阶段性完成参数优化、,GB,分析、资源均衡等工作并与杭州移动组织阶段性交流会,5,、,5,月,31,日完成统计分析、,C/I,优化、覆盖优化等,6,、,6,月,6,日完成,BSC47,的,PRP,扩容及优化总结,7,、,6,月,12,日召开总结会及技术交流会,共涉及,3,个,LAC,区,,4,个,BSC,,,20,个基站,,32,个小区。,联合优化小组,项目总负责,:,卢赛刚(杭分)、岑曙伟(杭分)、,顾贤琼,性能统计负责,:,彭瑾(杭分)、蔡玮(杭分)、,刘明涛(专家组)、申坚(专家组)、齐元(专家组)、潘巍等,现场测试负责,:,楼哲午(杭分)、,陈锋、刘梦楠、朱宁等,信令数据分析,:,刘向东(专家组)、白华,测试范围(大关路上塘路绍兴路德胜路香积寺路及上塘办公楼),项目总结,效果评估,优化总结建议,后续规划建议,吞吐高效,-,吞吐量,忙时路测下载速率,闲时路测下载速率:,5/25,日,106kbit/s,;,5/31,日,139kbit/s,。,上塘办公楼,CQT,下载速率:,5/18,日,31kbit/s,;,5/23,日,150kbit/s,优化前后改善幅度约,116%,吞吐高效,-,编码效率,优化前平均,7.15,优化后平均,7.91,接入顺畅,资源有效,优化后信道拥塞明显减少,优化前负荷不均衡,优化后负荷均衡,项目总结,效果评估,优化工作总结,后续规划建议,GNOS,优化流程,主要问题,1,、网络负荷不均衡,2,、信道拥塞,3,、频率干扰(,C/I,差),4,、覆盖不合理,5,、,RAU,规划不合理,优化工作,信令分析,1,C,/I,优化,5,资源均衡,2,覆盖优化,3,统计分析,4,参数优化,6,信令分析,1,、,Attach,深层分析概述,统计结果分析,各原因值深层说明,2,、,MS,触发,De-attach,流程分析,3,、,RA,成功率分析,RA,成功率统计分析,原因值深层说明,4,、,PDP,激活流程分析,PDP,激活流程,PDP,激活流程的部分说明,5,、,PDP,去激活流程分析内容,PDP,去激活流程统计分析,PDP,去激活流程的一些说明,信令分析,GB,分析案例,路由更新失败率偏高,建议部分小区,LAC,区重新划分,资源均衡,相同,PRP,数,优化前,PRP,负荷最高达到,154,,平均负荷,70,优化后各,PRP,负荷几乎均衡,考虑到目前数据业务流量增长及信道拥塞,建议,BSC47,部分小区信道扩容并增加两块,PRP,。,资源均衡案例,1,(,28861,),优化前:各项无线指标均好,但下载速率只有,31.63kbps,;,优化后:下载速率达到,120kbps,。(,PRP,负荷均衡),资源均衡案例,2,优化前:信道拥塞率,3.63%,,时隙占用,1,2,个,下载速率约,30kbps,;,优化后:信道拥塞率,1.58%,,时隙占用,3,个以上下载速率约,100kbps,覆盖优化,优化前:覆盖过远,切换不及时,下载速率约,30kbps,;,优化后:覆盖合理,切换及时,下载速率约,120kbps,覆盖优化,-,案例,1,在实际的测试中,发现覆盖过远的小区涉及到覆盖大型居民小区,天线调整有可能引起投诉。所以我们只对该区域附近各个基站进行小区重选参数微调,从而改善数据业务的覆盖调整。,覆盖优化,-,案例,2,通过调整小区天线,使覆盖更合理并减少数据业务切换量。,统计分析,优化前后各方面指标均有提升,C/I,与编码速率关系,C/I-,优化前,优化前,优化前优化区域,C/I,约,20,左右;,左图红圈所示,C/I,差的区域。,C/I-,优化后,优化前,优化后优化区域,C/I,约,25.96,;,C/I,优化案例,C/I,小于,15dBm,,干扰严重,下行的误码率也很高,无线环境很差,直接导致,FTP,下载速率约,30kbit/s,。,C/I,大于,25dBm,,,FTP,下载速率约,120kbit/s,。,系统参数,TBF,相关参数。,EDGE,编码相关参数。,流控参数。,调度算法相关参数。,系统参数,参数,意义,gprs_sched_beta (TBF/schedule),TBF,调度算法,,2,表示优先保证高编码方式的用户的吞吐量,delay_ul_rel_dur(TBF),上行,TBF,延迟释放时间,delay_dl_rel_dur(TBF),下行,TBF,延迟释放时间,egprs_init_dl_cs(coding),下行,EDGE,初始速率,egprs_init_ul_cs(coding),上行,EDGE,初始速率,bep_period(coding),BEP,的报告周期,用于控制无线抖动。,bep_period2(coding),BEP,的报告周期,用于控制无线抖动。,n_avg_i (coding),eop_enabled,Gprs_smg30_t3192,max_ms_dl_buffer(,流控,),用于流控。,max_ms_dl_rate,(流控),tlli_blk_coding,(,coding,),RLC,控制帧的传送编码方式,,1,表示跟随数据编码的速率,,0,采用固定,CS2,或者,MCS3,方式,有助于提升数据传送速率。,bssgp_fc_period_c(,流控,),流控信息发送频率。,系统参数,参数,参数级别,系统缺省,推荐值,gprs_sched_beta,BSS,1,2,delay_ul_rel_dur,BSS,18(360ms),50,delay_dl_rel_dur,BSS,50,100 or 225,egprs_init_dl_cs,CELL,2(MSC3),6(MSC7),egprs_init_ul_cs,CELL,2(MSC3),5(MSC6),bep_period,CELL,0,4,bep_period2,CELL,15,12,gprs_t3192,CELL,500,1000,max_ms_dl_buffer,CELL,38400,64000,n_avg_i,CELL,2,4,tlli_blk_coding,CELL,0,1,项目总结,效果评估,优化总结建议,后续规划建议,二次(再)规划流程,再规划参数输入,再规划输出,1,、系统统计信息,2,、实际优化信息,摩托罗拉系统规划原则:,1,、,GPRS/EDGE,系统硬件资源配置原则,2,、,GPRS/EDGE,系统小区信到配置原则,3,、,GPRS/EDGE,系统各接口链路配置原,则,4,、规范定义性能指标,1,、硬件再规划,PRP,板卡的再配置,PMC,板卡的再配置,PDCH,信道的再分配,1,、链路再规划,GBL,信令链路的规划,GSL,信令链路的规划,RSL,信令链路的规划,再规划分析,1,、传输资源的规划,GDS(TRAU),接口资源的规划,ABIS,接口资源的规划,在本次杭州的演示区的优化过程中,随着用户对网络性能的更高要求,各种优化策略的实施必将引起系统的各类配置资源的重新调整,这些调整导致了系统原有的规划策略可能很难适应这种新的要求,这给系统带来了一些新的问题,例如,新的空口资源的变化是否与当前的硬件资源,链路资源,信令资源相匹配,为了解决这个问题我们将采用第二类的规划流程,其实这个流程是对现有网络的再规划过程。,再规划建议,时隙规划,1,未来预测,5,信令链路规划,2,硬件规划,3,传输资源配置,4,PDCH,规划,在杭州实际优化系统中我们也根据系统内小区的拥塞状况作了小区的信道调整,这仅是杭州优化经验调整,这对,EDGE,用户合理利用,PDCH,信道起到了很好的效果。具体的规划详述如下:,第一步:计算忙时该,BSC,下小区总的拥塞次数;,第二步:计算忙时该,BSC,下每小区总的拥塞比率;,第三步:根据现网配置原则拥塞比调整信道配置;,信令规划,第一 对每个,PCU,下的,GSL,(,GDS_LAPD,)进行估算,理论通过统计信息对,GSL,信令链路的规划一般应该遵循下列原则:,1,、,GSLnum=MAX(GSLrun_time,GSLinitial),系统初始化所需要的,GSLinit_time,为,6,。,2,、,GSLrun_time=GSLpaging+GSL rach,对于,GSLrach,的计算一般有两类情况:,第一类:采用,ONE PAHSE,接入时:,第二类:采用增强型,ONE PHASE,接入时:,3,、,4,、,通过这个方法可以对现网的,GSL,链路作一个科学的计算;,在实际的杭州,EDGE,优化区并未采用该原则进行,GSL,链路的计算,我们通过,GSL,链路的信令拥塞情况作为系统,GSL,信令个数进行评估,在此次评估中我们认为,LAPD_CONGESTION,统计不出现拥塞就不考虑系统,GSL,链路的扩容,因此在本次杭州演示区域内未进行,GSL,链路的规划。,硬件规划,-PRP,PRP,板数量,=ROUNDUP(,总的,PDTCH,时隙数,)/(120*n),0),注明:,n,是基于用户,Data,业务吞吐量的考虑而采用的时隙使用系数,n=25%,,,50%,,,75%,,,100%,=25%,时表示该,PRP,板支持,64K,数据信道;,=50%,时表示该,PRP,板支持,32K,数据信道;,=75%,时表示该,PRP,板支持,16K,数据信道;,=100%,时表示该,PRP,板支持,8K,数据信道;,本次杭州演示为例:,分别计算由于,CS34,信道和,EDGE,信道所需的,PRP,板数,CS34,信道所需的,PRP,数,=ROUNDUP(97/(120*50%),0)=2,EDGE,信道所需的,PRP,数,=ROUNDUP(178/(120*25%),0)=6,由此看到为达到上述要求我们需要,8,块,PRP,板。,但是根据该公式计算出来的,PRP,板数实际上是,PRP,板达到最佳性能所需的,PRP,板卡数。,原则,1,、,GDS,的容量:,一个,GDS TRAU,支持最多,124,个,16K PDCH,#16kbps TS+2x#32kbps TS+4x#64kbps=ROUNDUP(,#16kbps TS+2 x#32kbps TS+4 x#64kbps TS)/124,,,0,),原则,2,、,PMC,的容量:,一个,PMC NIB,支持一下组合:,124,个,16Kbps TRAU,,,62,个,32Kbps TRAU,,,62,个,64Kbps TRAU,#16kbps TS+2 x#32kbps TS+2 x#64kbps TS=ROUNDUP(,#16kbps TS+2 x#32kbps TS+2 x#64kbps TS)/12
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 图纸专区 > 课件教案


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!