EDGE演示区域优化总结.ppt

《EDGE演示区域优化总结.ppt》由会员分享，可在线阅读，更多相关《EDGE演示区域优化总结.ppt（41页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、杭州杭州EDGEEDGE演示区域演示区域优化总结优化总结杭州移动杭州移动&摩托罗拉摩托罗拉联合优化小组联合优化小组20072007年年5 5月月3131日日会议安排会议安排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、完成优化区域测试评估并杭州移动共同制定的优化计划。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个小区。联合优化小组联合优化小组项目总负责项目总负责:卢赛刚（杭分）、岑曙伟（杭分）、顾贤琼性能统计负责性能统计负责:彭瑾（杭分）、蔡玮（杭分）、刘明涛（专家组）、申坚（专家组）、齐

3、元（专家组）、潘巍等现场测试负责现场测试负责:楼哲午（杭分）、陈锋、刘梦楠、朱宁等信令数据分析信令数据分析:刘向东（专家组）、白华测试范围（大关路上塘路绍兴路测试范围（大关路上塘路绍兴路德胜路香积寺路及上塘办公楼德胜路香积寺路及上塘办公楼）项目总结项目总结效果评估效果评估优化总结建议优化总结建议后续规划建议后续规划建议吞吐高效吞吐高效-吞吐量吞吐量忙时路测下载速率忙时路测下载速率闲时路测下载速率：5/25日106kbit/s106kbit/s；5/31日139kbit/s139kbit/s。上塘办公楼CQT下载速率：5/18日31kbit/s31kbit/s；5/23日150kbit/s150

4、kbit/s优化前后改善优化前后改善幅度约幅度约116%116%吞吐高效吞吐高效-编码效率编码效率优化前平均优化前平均优化后平均优化后平均接入顺畅接入顺畅资源有效资源有效优化后信道优化后信道拥塞明显减拥塞明显减少少优化前负荷不均衡优化后负荷均衡项目总结项目总结效果评估效果评估优化工作总结优化工作总结后续规划建议后续规划建议GNOS优化流程优化流程主要问题主要问题1、网络负荷不均衡2、信道拥塞3、频率干扰（C/I差）4、覆盖不合理5、RAU规划不合理优化工作优化工作信令分析信令分析1C/I优化优化5资源均衡资源均衡2覆盖优化覆盖优化3统计分析统计分析4参数优化参数优化6信令分析信令分析1 1、A

5、ttachAttach深层分析概述深层分析概述统计结果分析统计结果分析各原因值深层说明各原因值深层说明2 2、MSMS触发触发De-attachDe-attach流程分析流程分析3 3、RARA成功率分析成功率分析RARA成功率统计分析成功率统计分析原因值深层说明原因值深层说明4 4、PDPPDP激活流程分析激活流程分析PDPPDP激活流程激活流程PDPPDP激活流程的部分说明激活流程的部分说明5 5、PDPPDP去激活流程分析内容去激活流程分析内容PDPPDP去激活流程统计分析去激活流程统计分析PDPPDP去激活流程的一些说明去激活流程的一些说明信令分析信令分析GB分析案例分析案例路由更新失

6、败率偏高，建议部分小区LAC区重新划分 资源均衡资源均衡相同PRP数，优化前PRP负荷最高达到154，平均负荷70优化后各PRP负荷几乎均衡考虑到目前数据业务流量增长及信道拥塞，建议BSC47部分小区信道扩容并增加两块PRP。资源均衡案例资源均衡案例1（28861）优化前：各项无线指标均好，但下载速率只有；优化后：下载速率达到120kbps。（PRP负荷均衡）资源均衡案例资源均衡案例2优化前：信道拥塞率3.63%，时隙占用12个，下载速率约30kbps30kbps；优化后：信道拥塞率1.58%，时隙占用3个以上下载速率约100kbps100kbps覆盖优化覆盖优化优化前：覆盖过远，切换不及时，

7、下载速率约30kbps30kbps；优化后：覆盖合理，切换及时，下载速率约120kbps120kbps覆盖优化覆盖优化-案例案例1在实际的测试中，发现覆盖过远的小区涉及到覆盖大型居民小区，天线调整有可能引起投诉。所以我们只对该区域附近各个基站进行小区重选参数微调，从而改善数据业务的覆盖调整。覆盖优化覆盖优化-案例案例2通过调整小区天线，使覆盖更合理并减少数据业务切换量。统计分析统计分析优化前后各方面指标均有提升C/I与编码速率关系与编码速率关系C/I-优化前优化前优化前优化前优化前优化区域C/I约20左右；左图红圈所示C/I差的区域。C/I-优化后优化后优化前优化前优化后优化区域C/I约；C/

8、I优化案例优化案例C/I小于15dBm，干扰严重，下行的误码率也很高，无线环境很差，直接导致FTP下载速率约30kbit/s。C/I大于25dBm，FTP下载速率约120kbit/s120kbit/s。系统参数系统参数TBF相关参数。EDGE编码相关参数。流控参数。调度算法相关参数。系统参数系统参数参数意义gprs_sched_beta(TBF/schedule)TBF调度算法，调度算法，2表示优先保证高编码方式的用户的吞表示优先保证高编码方式的用户的吞吐量吐量delay_ul_rel_dur(TBF)上行上行TBF延迟释放时间延迟释放时间delay_dl_rel_dur(TBF)下行下行TB

9、F延迟释放时间延迟释放时间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_enabledGprs_smg30_t3192max_ms_dl_buffer(流控流控)用于流控。用于流控。max_ms_dl_rate（流控）（流控）tlli_blk

10、_coding（coding）RLC控制帧的传送编码方式，控制帧的传送编码方式，1表示跟随数据编码的速表示跟随数据编码的速率，率，0采用固定采用固定CS2或者或者MCS3方式，有助于提升数据方式，有助于提升数据传送速率。传送速率。bssgp_fc_period_c(流控流控)流控信息发送频率。流控信息发送频率。系统参数系统参数参数参数级别系统缺省推荐值gprs_sched_betaBSS12delay_ul_rel_durBSS18(360ms)50delay_dl_rel_durBSS50100or225egprs_init_dl_csCELL2(MSC3)6(MSC7)egprs_init

11、_ul_csCELL2(MSC3)5(MSC6)bep_periodCELL04bep_period2CELL1512gprs_t3192CELL5001000max_ms_dl_bufferCELL3840064000n_avg_iCELL24tlli_blk_codingCELL01项目总结项目总结效果评估效果评估优化总结建议优化总结建议后续规划建议后续规划建议二次（再）规划流程二次（再）规划流程再规划参数输入再规划输出1、系统统计信息2、实际优化信息摩托罗拉系统规划原则：1、GPRS/EDGE系统硬件资源配置原则2、GPRS/EDGE系统小区信到配置原则3、GPRS/EDGE系统各接口链

12、路配置原 则4、规范定义性能指标1、硬件再规划 PRP板卡的再配置 PMC板卡的再配置 PDCH信道的再分配1、链路再规划 GBL信令链路的规划 GSL信令链路的规划 RSL信令链路的规划 再规划分析1、传输资源的规划 GDS(TRAU)接口资源的规划 ABIS接口资源的规划 在本次杭州的演示区的优化过程中，随着用户对网络性能的更高要求，各种优化策略的实施必将引起系统的各类配置资源的重新调整，这些调整导致了系统原有的规划策略可能很难适应这种新的要求，这给系统带来了一些新的问题，例如，新的空口资源的变化是否与当前的硬件资源，链路资源，信令资源相匹配，为了解决这个问题我们将采用第二类的规划流程，其

13、实这个流程是对现有网络的再规划过程。再规划建议再规划建议时隙规划时隙规划1未来预测未来预测5信令链路规划信令链路规划2硬件规划硬件规划3传输资源配置传输资源配置4PDCH规划规划 在杭州实际优化系统中我们也根据系统内小区的拥塞状况作了小区的信道调整，这仅是杭州优化经验调整，这对EDGE用户合理利用PDCH信道起到了很好的效果。具体的规划详述如下：第一步：计算忙时该BSC下小区总的拥塞次数；第二步：计算忙时该BSC下每小区总的拥塞比率；第三步：根据现网配置原则拥塞比调整信道配置；信令规划信令规划第一 对每个PCU下的GSL（GDS_LAPD）进行估算理论通过统计信息对GSL信令链路的规划一般应该

14、遵循下列原则：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链路的扩容

15、，因此在本次杭州演示区域内未进行GSL链路的规划。硬件规划硬件规划-PRPPRP 板数量=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)=2EDGE信道所需的PR

16、P数=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(GDS_TRAU=ROUNDUP(#16kbps TS+2 x#32kbps TS+4 x#64kbps TS)/124#16kbps TS+2 x#32kbps TS+4 x#64kbps TS)/124，0 0)原则2、PMC 的容量：一个PMC NI

17、B支持一下组合：124个16Kbps TRAU，62个32Kbps TRAU，62个64Kbps TRAU#16kbps TS+2 x#32kbps TS+2 x#64kbps TS=ROUNDUP(=ROUNDUP(#16kbps TS+2 x#32kbps TS+2 x#64kbps TS)/124#16kbps TS+2 x#32kbps TS+2 x#64kbps TS)/124，0 0)在实际优化过程中发现，由于每PRP的实际分配的PDTCH信道的并不均匀，这可能导致部分小区的数据库配置信道并不能与GDS陆地时隙相匹配，使得这些小区的信道不可用。硬件规划硬件规划-GDS和和PMC硬件

18、规划硬件规划-GDS和和PMC 建议个根据EDGE信道和GPRS信道的比率合理配置每个PMC板上配置GDS链路，一般建议配置两条GDS 基站E1数=ROUNDUP(ROUNDUP(话音时隙话音时隙+CS1/2+CS1/2时隙数时隙数)*1/4+EDGE(64Kbps)*1/4+EDGE(64Kbps)时隙数时隙数*n+CS3/4n+CS3/4时隙数时隙数*1/2+n1/2+n个个RSL)/30)RSL)/30)注：n是由于VersaTRAU功能压缩(GSR8)系数取值范围（3/8-8/8）n的取值说明：实际上这个值说明了在空中EDGE信道与陆地接口之间做了一级交换机制，该值仅在GSR8版本中实

19、现。E1传输的配置(需要根据载频的具体配置来计算)：一般110个载频需要1个E1，1124个载频一般需要2个E1，但实际上需要根据载频的具体配置来计算：例如：某个基站配置为8+8+8的结构（每站3个小区每小区8个收发信机）(每个小区EDGE:13；GPRS CS3/CS4:43配置；6SD TS，2RSL)数据PDTCH 总时隙数:3cell*(8carrier*8ts-1 BCCH-6 SD)=171 话音时隙:171TS-12EDGE-21GPRS=138;所以所需的 E1数=ROUNDUP(138*1/4+12+21*1/2+2)=60时隙 即：2E1 传输资源配置传输资源配置-基本ABIS E1传输鉴于杭州EDGE系统的数据业务的区域性优化过程时间短，对于数据业务话务量统计数据量很少，因此对于未来的系统地进一步的规划很难评估，但是网络的发展一定是在持续的，因此这里应该有一个对未来网络容量有一些可衡量指标，用这些指标评估网络的增加。主要的衡量指标参考点：终端用户的增长；GPRS/EDGE信道的增长；基站内RSL信令增长；BSC与PCU之间的三类链路的增长；通过对上述的参考点的分析，可以得出系统业务的变化趋势，这是合理优化和调整未来网络结构的主要参考。上述仅考虑了数据业务的情况，在实际的发展评估中还需考虑语音业务的发展未来预测未来预测