EDGE演示区域优化总结

会计学1EDGE演示区域优化总结项目回顾为配合杭州网络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个小区。

第1页/共40页联合优化小组项目总负责: 卢赛刚（杭分）、岑曙伟（杭分）、顾贤琼性能统计负责: 彭瑾（杭分）、蔡玮（杭分）、刘明涛（专家组）、申坚（专家组）、齐元（专家组）、潘巍等现场测试负责:楼哲午（杭分）、陈锋、刘梦楠、朱宁等信令数据分析:刘向东（专家组）、白华第2页/共40页测试范围（大关路－上塘路－绍兴路－德胜路－香积寺路及上塘办公楼）第3页/共40页项目总结效果评估优化总结建议后续规划建议第4页/共40页吞吐高效-吞吐量忙时路测下载速率闲时路测下载速率：5/25日106kbit/s；5/31日139kbit/s。上塘办公楼CQT下载速率：5/18日31kbit/s；5/23日150kbit/s优化前后改善幅度约116%第5页/共40页吞吐高效-编码效率优化前平均7.15优化后平均7.91第6页/共40页接入顺畅第7页/共40页资源有效优化后信道拥塞明显减少优化前负荷不均衡优化后负荷均衡第8页/共40页项目总结效果评估优化工作总结后续规划建议第9页/共40页GNOS优化流程第10页/共40页主要问题1、网络负荷不均衡2、信道拥塞3、频率干扰（C/I差）4、覆盖不合理5、RAU规划不合理第11页/共40页优化工作信令分析1C/I优化5资源均衡2覆盖优化3统计分析4参数优化6第12页/共40页信令分析1、Attach深层分析概述

统计结果分析

各原因值深层说明2、MS触发De-attach流程分析3、RA成功率分析

RA成功率统计分析

原因值深层说明4、PDP激活流程分析

PDP激活流程

PDP激活流程的部分说明5、PDP去激活流程分析内容

PDP去激活流程统计分析

PDP去激活流程的一些说明第13页/共40页信令分析第14页/共40页GB分析案例路由更新失败率偏高，建议部分小区LAC区重新划分第15页/共40页资源均衡相同PRP数，优化前PRP负荷最高达到154，平均负荷70优化后各PRP负荷几乎均衡考虑到目前数据业务流量增长及信道拥塞，建议BSC47部分小区信道扩容并增加两块PRP。第16页/共40页资源均衡案例1（28861）优化前：各项无线指标均好，但下载速率只有31.63kbps；优化后：下载速率达到120kbps。（PRP负荷均衡）第17页/共40页资源均衡案例2优化前：信道拥塞率3.63%，时隙占用1－2个，下载速率约30kbps；优化后：信道拥塞率1.58%，时隙占用3个以上下载速率约100kbps第18页/共40页覆盖优化优化前：覆盖过远，切换不及时，下载速率约30kbps；优化后：覆盖合理，切换及时，下载速率约120kbps第19页/共40页覆盖优化-案例1在实际的测试中，发现覆盖过远的小区涉及到覆盖大型居民小区，天线调整有可能引起投诉。所以我们只对该区域附近各个基站进行小区重选参数微调，从而改善数据业务的覆盖调整。第20页/共40页覆盖优化-案例2通过调整小区天线，使覆盖更合理并减少数据业务切换量。第21页/共40页统计分析优化前后各方面指标均有提升第22页/共40页C/I与编码速率关系第23页/共40页C/I-优化前优化前优化前优化区域C/I约20左右；左图红圈所示C/I差的区域。第24页/共40页C/I-优化后优化前优化后优化区域C/I约25.96；第25页/共40页C/I优化案例C/I小于15dBm，干扰严重，下行的误码率也很高，无线环境很差，直接导致FTP下载速率约30kbit/s。C/I大于25dBm，FTP下载速率约120kbit/s。

第26页/共40页系统参数TBF相关参数。EDGE编码相关参数。流控参数。调度算法相关参数。第27页/共40页系统参数参数意义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_enabledGprs_smg30_t3192max_ms_dl_buffer(流控)用于流控。max_ms_dl_rate（流控）tlli_blk_coding（coding）RLC控制帧的传送编码方式，1表示跟随数据编码的速率，0采用固定CS2或者MCS3方式，有助于提升数据传送速率。bssgp_fc_period_c

(流控)流控信息发送频率。第28页/共40页系统参数参数参数级别系统缺省推荐值gprs_sched_betaBSS12delay_ul_rel_durBSS18(360ms)50delay_dl_rel_durBSS50100or225egprs_init_dl_csCELL2(MSC3)6(MSC7)egprs_init_ul_csCELL2(MSC3)5(MSC6)bep_periodCELL04bep_period2CELL1512gprs_t3192CELL5001000max_ms_dl_bufferCELL3840064000n_avg_iCELL24tlli_blk_codingCELL01第29页/共40页项目总结效果评估优化总结建议后续规划建议第30页/共40页二次（再）规划流程再规划参数输入再规划输出1、系统统计信息2、实际优化信息摩托罗拉系统规划原则：1、GPRS/EDGE系统硬件资源配置原则2、GPRS/EDGE系统小区信到配置原则3、GPRS/EDGE系统各接口链路配置原则4、规范定义性能指标1、硬件再规划

PRP板卡的再配置

PMC板卡的再配置

PDCH信道的再分配1、链路再规划

GBL信令链路的规划

GSL信令链路的规划

RSL信令链路的规划

再规划分析1、传输资源的规划

GDS(TRAU)接口资源的规划

ABIS接口资源的规划

在本次杭州的演示区的优化过程中，随着用户对网络性能的更高要求，各种优化策略的实施必将引起系统的各类配置资源的重新调整，这些调整导致了系统原有的规划策略可能很难适应这种新的要求，这给系统带来了一些新的问题，例如，新的空口资源的变化是否与当前的硬件资源，链路资源，信令资源相匹配，为了解决这个问题我们将采用第二类的规划流程，其实这个流程是对现有网络的再规划过程。第31页/共40页再规划建议时隙规划1未来预测5信令链路规划2硬件规划3传输资源配置4第32页/共40页PDCH规划在杭州实际优化系统中我们也根据系统内小区的拥塞状况作了小区的信道调整，这仅是杭州优化经验调整，这对EDGE用户合理利用PDCH信道起到了很好的效果。具体的规划详述如下：第一步：计算忙时该BSC下小区总的拥塞次数；第二步：计算忙时该BSC下每小区总的拥塞比率；第三步：根据现网配置原则拥塞比调整信道配置；第33页/共40页信令规划第一对每个PCU下的GSL（GDS_LAPD）进行估算理论通过统计信息对GSL信令链路的规划一般应该遵循下列原则：1、GSLnum=MAX(GSLrun_time,GSLinitial)系统初始化所需要的GSLinit_time为6。2、GSLrun_time=GSLpaging+GSLrach对于GSLrach的计算一般有两类情况：第一类：采用ONEPAHSE接入时：第二类：采用增强型ONEPHASE接入时：3、4、通过这个方法可以对现网的GSL链路作一个科学的计算；在实际的杭州EDGE优化区并未采用该原则进行GSL链路的计算，我们通过GSL链路的信令拥塞情况作为系统GSL信令个数进行评估，在此次评估中我们认为LAPD_CONGESTION统计不出现拥塞就不考虑系统GSL链路的扩容，因此在本次杭州演示区域内未进行GSL链路的规划。第34页/共40页硬件规划-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信道所需的PRP数=ROUNDUP(178/(120*25%),0)=6由此看到为达到上述要求我们需要8块PRP板。但是根据该公式计算出来的PRP板数实际上是PRP板达到最佳性能所需的PRP板卡数。第35页/共40页原则1、GDS的容量：一个GDSTRAU支持最多124个16KPDCH#16kbpsTS+2x#32kbpsTS+4x#64kbps<=124x(GDS_TRAU)GDS_TRAU>=ROUNDUP((#16kbpsTS+2x#32kbpsTS+4x#64kbpsTS)/124，0)原则2、PMC的容量：一个PMCNIB支持一下组合：124个16KbpsTRAU，62个32KbpsTRAU，62个64KbpsTRAU#16kbpsTS+2x#32kbpsTS+2x#64kbpsTS<=124x(PMC数)PMC数>=ROUNDUP((#16kbpsTS+2x#32kbpsTS+2x#64kbpsTS)/124，0)在实际优化过程中发现，由于每PRP的实际分配的PDTCH信道的并不均匀，这可能导致部分小区的数据库配置信道并不能与GDS陆地时隙相匹配，使得这些小区的信道不可用。硬件规划-GDS和PMC第36页/共40页硬件规划-GDS和PMC

建议个根据EDGE信道和GPRS信道的比率合理配置每个PMC板上配置GDS链路，一般建议配置两条GDS第37页/共40页

基站E1数=ROUNDUP((话音时隙+CS1/2时隙数)*1/4+EDGE(64Kbps)时隙数*n+CS3/4时隙数*1/2+n个RSL)/30)注：n是由于VersaTRAU功能压缩(GSR8)系数取值范围（3/8-8/8）n的取值说明：实际上这个值说明了在空中EDGE信道与陆地接口之间做了一级交换机制，该值仅在GSR8版本中实现。E1传输的配置(需要根据载频的具体配置来计算)：一般1～10个载频需要1个E1，11～24个载频一般需要2个