您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 人事档案/员工关系 > 潜能挖掘和数据业务优化总结报告-空口寻呼容量优化专题
2013年5月10日空口寻呼容量优化专题总结报告寻呼概况分析:.............................................................................................112.2.2一周详细分析:.............................................................................................132.3LAC/RAC评估..............................................................................................................162.4寻呼优化.....................................................................................................................182.4.1参数优化.........................................................................................................192.4.2LAC/RAC优化..............................................................................................232.52013年寻呼负荷线性预测........................................................................................263.总结.................................................................................................................................27-3-1.概述1.1专题背景TD网络经过多期发展,在市场的终端推广机制下,TD用户数的稳步增长,再加上数据应用种类的不断丰富以及智能终端的普及,TD-SCDMA网络出现了业务处理能力和信令处理能力的非线性增长,对网络各环节的负荷带来挑战,其中PAGING寻呼容量的不足问题较为尖锐,直接影响用户感知、省公司和集团拉网结果,严重时给网络带来灾难式的影响。本文章主要从问题分析、解决方案和取得效果这三个方面,探讨了宁波大唐设备在TD-S网络寻呼负荷方面的评估和优化实践。1.2专项优化成果根据宁波网元参数配置,现时LAC与RAC配置一一对应,此总结报告下面将LAC/RAC简称为LAC。按现网寻呼周期640MS配置,现时最大支持22.5万次/小时/小区,考虑30%冗余量,最大约为15万次/小时/小区,将寻呼周期修改为320MS后,寻呼周期扩大一倍。1.参数修改效果5月3日对RNC1558的寻呼参数进行修改,效果如下:最忙时段LACRNCID2013-4-21~2013-4-265月4日5月5日5月6日UTRAN发起寻呼类型1次数拥塞次数拥塞率UTRAN发起寻呼类型1次数拥塞次数拥塞率UTRAN发起寻呼类型1次数拥塞次数拥塞率UTRAN发起寻呼类型1次数拥塞次数拥塞率550781558213526155727.29%16585040.00%16749440.00%16812440.00%1627214536148806.94%16593468124.11%16753236482.18%16903236422.15%2816213285159347.47%16564761403.71%16733993245.57%16812839842.37%参数修改后,同一LAC下的三套RNC中,1558基本未出现寻呼拥塞,而参数未进行修改的两套RNC忙时拥塞次数平均在4千次左右;RNC1558在参数修改后,LAC55078的最忙时段寻呼量约下降4.5万次,下降了原来的21%,现时最忙时约为16.9万次/小时/小区-4-2.效果推广宁波现时10套LAC忙时寻呼量超10万次/小时/小区,建议进行参数修改LACRNCUTRAN发起寻呼类型1次数5507815582459571627245957281624595755080156022736255081156113579855082156214995028171499502848149950550831563148572281814857255085156511112228491111225508816281499505508928511109165509116301096555509228541485723.LAC/RAC优化LAC55078下挂三套RNC,涉及小区超过1100个,周边LAC寻呼负荷平均在7万次/小时/小区,不适宜割接,建议此LAC进行分裂。1.3技术原理简介1.寻呼原理为了完成一次被叫业务(CS业务、PS业务和短信业务等),就需要网络侧对注册用户终端进行寻址和通知,这样的过程就是寻呼过程。在TD系统中,寻呼可以由CN发起也可以由RNC发起。CN发起的寻呼主要用于对用户进行寻址和通知,并建立相应的信令连接,以进行一次被叫业务(CS业务、PS业务和短信业务等);RNC发起的寻呼主要用于告知特定状态下的注册用户:系统消息更新(IDLE/CELL_PCH/URA_PCH状态),小区更新(CELL_PCH/URA_PCH状态)或者RRC连接释放(CELL_PCH/URA_PCH状态)。寻呼的类型分为寻呼类型1(PagingType1)和寻呼类型2(PagingType2)。如果被-5-寻呼的UE处于IDLE/CELL_PCH/URA_PCH状态,RNC将通过PCCH信道发一个寻呼类型1(PAGINGTYPE1)消息给此UE;如果被寻呼的UE处于CELL_FACH/CELL_DCH状态,RNC将通过DCCH信道发一个寻呼类型2(PAGINGTYPE2)消息给此UE。寻呼类型1(PagingType1)的寻呼子信道和相应的PICH/PCH块如下图:寻呼的范围分为位置区(LA)范围、路由区(RA)范围、UTRAN网络注册区(URA)范围和小区(Cell)范围。如果被寻呼的UE处于IDLE状态,RNC将在位置区或路由区范围寻呼该UE;如果被寻呼的UE处于Cell_PCH/Cell_FACH/Cell_DCH状态,RNC将在小区范围寻呼该UE;如果被寻呼的UE处于URA_PCH状态,RNC将在URA区范围寻呼该用户。寻呼过程如下图:-6-2.PCH信道寻呼容量计算首先需要明确寻呼容量的单位是个/时间/小区,也就是说衡量一个RNC支持多大的寻呼量是以小区为标准的,比如某RNC支持的寻呼容量应为XX个/小时/小区或者XX个/秒/小区。OMCR中提取的RNC级寻呼量是将该RNC下所有小区的寻呼容量相加得来的,随着小区数的不同,变化较大,不具有反映设备性能的统计意义。空口寻呼容量配置计算方法如下(以小区为参考单位):PCH寻呼能力计算公式为:Ntfs×RoundDown[(TBSize-7)/Lue]×Npch/(Nr×Tpbp)IMSI寻呼时,Ntfs×RoundDown[(TBSize-7)/72]×Npch/(Nr×Tpbp)=1×RoundDown[(240-7)/72]×8/(1×640)=24/(1*640)=18203TMSI/PTMSI寻呼时,Ntfs×RoundDown[(TBSize-7)/40]×Npch/(Nr×Tpbp)=1*RoundDown[(240-7)/40]×8/(1×640)=32765协议参数对应大唐参数英文名称说明备注参数位置现网常用配置NtfsTbListPCH传输格式中240bit块的个数(一个传输块个数一般配置为0、1。Ntf与PCH所在的SCCPCH的rTfsDynamic静态业务参数配置集-TFS半静态部分信息集-PCH93、94-TFS动1-7-寻呼子信道承载)码道数目相关。态部分信息TFSID为94的配置中,TBList中的{0,1},1表示1块。TbsizeTbSizePCH传输块大小rTfsDynamic静态业务参数配置集-TFS半静态部分信息集-PCH93、94-TFS动态部分信息-传输块大小240NpchNPch每个寻呼块配置的寻呼子信道数目协议规定Npch=8rCtrchPich小区级-载波级-下行信道集-SCCPCHI集-PICH信道-寻呼组数量8NrNumberOfPagingRetr重复因子相同寻呼的重发次数rProtocolRrcs协议过程参数表-RRC协议过程表-寻呼消息最大重传次数1TpbpRepetitionPeriodPICH的寻呼周期重复周期/Tpbp640ms/320msrCtrchSccpchSet小区集-载波-集-下行信道集-Sccpch集关系表中的物理信道重复周期(单位是10ms)640Lue该参数属于协议约定,不需要进行参数配置UE寻呼长度UE寻呼长度每个UE的“UE寻呼信息”包括几部分:寻呼原因、UE所在域(CS或者PS)、TMSI或者IMSI信息.该参数属于协议约定,不需要进行参数配置IMSI时,72bitTMSI时,40bit注:RoundDown为向下取整。如果空口环境不好,存在大量重传的时候,则上面的公式需要再除以(1+Nr),寻呼容量减半,通常情况下不考虑重传。3.空口寻呼受限计算对于短消息的寻呼,其寻呼过程与普通的话音业务寻呼相同,因此在计算时可以将短消息的话务量等同于话音业务的话务量进行合并计算,在下面的计算中按照现网配置来计算:-8-PICH:S
本文标题:潜能挖掘和数据业务优化总结报告-空口寻呼容量优化专题
链接地址:https://www.777doc.com/doc-2214947 .html