寻呼空口信道容量及信道容量计算.docVIP

 目 录寻呼容量计算方法 2 1.1 现网理论容量计算 2 1.2 实际网络环境下的容量计算 3 2 寻呼容量扩容方案 3 2.1 寻呼拥塞产生的原因 3 2.2 寻呼容量预警机制 4 2.3 现网容量评估 4 2.4 空口寻呼扩容方案 5 2.4.1 方案原理 5 2.4.2 目标容量 6 3 FACH信道容量评估 7 寻呼容量计算方法 首先需要明确寻呼容量的单位是个/时间/小区，也就是说衡量一个RNC支持多大的寻呼量是以小区为标准的，比如某RNC支持的寻呼容量应为XX个/小时/小区或者XX个/秒/小区。 RNC设备支持的理论寻呼量为45万TMSI/小时/小区，实际每小区支持的寻呼容量则取决于空口的寻呼容量配置。 空口寻呼容量配置计算方法如下（以小区为参考单位）： PCH寻呼能力计算公式为：Ntfs×RoundDown[(TBSize-7)/Lue]×Npch/(Nr×Tpbp) IMSI寻呼时, Ntfs×RoundDown[(TBSize-7)/72]×Npch/(Nr×Tpbp) TMSI/PTMSI寻呼时，Ntfs×RoundDown[(TBSize-7)/40]×Npch/(Nr×Tpbp) 注：RoundDown为向下取整。 如果空口环境不好，存在大量重传的时候，则上面的公式需要再除以（1+Nr），寻呼容量减半，通常情况下不考虑重传。 现网理论容量计算 除西安网络进行寻呼信道扩容外，现网目前各项空口寻呼信道参数配置如下表： 协议参数 说明 备注 现网配置 Ntfs PCH传输格式中 240bit块的个数(一个寻呼子信道承载) 传输块个数 一般配置为0、1。Ntf与PCH所在的SCCPCH的码道数目相关。 1 Tbsize PCH传输块大小 　 240 Npch 每个寻呼块配置的寻呼子信道数目 协议规定Npch=8 8 Nr 重复因子 相同寻呼的重发次数 1 Tpbp PICH的寻呼周期 重复周期/ Tpbp 640ms/320ms 640 Lue UE寻呼长度 UE寻呼长度每个UE的“UE寻呼信息”包括几部分：寻呼原因、UE所在域（CS或者PS）、TMSI或者IMSI信息。注：该参数属于协议约定，不需要进行参数配置。 IMSI时，72bitTMSI时，40bit　 以现网常用配置为例，理论寻呼容量为： IMSI：37.5次/S/小区，37.5*3600=135000次/小时/小区 TMSI/PTMSI：62.5次/S/小区，62.5*3600=225000次/小时/小区 实际网络环境下的容量计算 如果核心网采用二、三次寻呼，且存在TMSI/IMSI混合出现的情况，则寻呼容量一般小于22.5万次/小时/小区。 华为局采用三次TMSI/TMSI/IMSI的方式进行寻呼消息下发； 爱立信局采用两次寻呼TMSI/IMSI的方式进行寻呼消息下发； 以TMSI/IMSI分别分布占比为98%和2%,考虑到调度丢失较多时造成二次、三次寻呼的突增因素，建议将TMSI和IMSI比例设置为9:1。 因此修正扩容后的混合下发长度为40*0.9+72*0.1=43.2 按照TMSI下发时每秒62.5个计算，混合下发时应为每秒62.5*（40/43.2）=58次/小区。 则一个小时内RNC能够支持的寻呼量为58次/秒/小区*3600秒=208800次/小时/小区 结论：由于目前寻呼模型下设备支持的寻呼容量为208800/h，考虑到70%的寻呼冗余，则最终呈现的寻呼容量为208800*0.7=146160次/小时/小区 寻呼容量扩容方案 寻呼拥塞产生的原因 在寻呼量没有到达门限时，仍然产生寻呼拥塞有以下两个原因： 寻呼信道1s内只能调度62.5个寻呼，如果CNLAC下发的寻呼量，则会导致，拥塞 TD网络中寻呼信道有8个寻呼IMSI过于集中，比如寻呼调度算法将同一时刻2个IMSI调度到一个寻呼子信道中，而每次只能发1个，这也会导致调度失败，引起拥塞。对应的解决方案是寻呼信道扩容，合理LAC规划、均匀放。 寻呼容量预警机制 当一周忙时最大寻呼量超过空口寻呼容量的70%，即进入黄色预警，考虑进行空口寻呼容量扩容或者LAC分裂 当一周忙时最大DT_寻呼拥塞率超过1%时，即进入黄色预警，考虑进行空口寻呼容量扩容或者LAC分裂 当一周忙时最大寻呼量超过空口寻呼容量的90%，即进入红色预警，必须尽快进行空口寻呼容量扩容或者LAC分裂。 注：以上扩容目标空口容量不能超过RNC设备支持的最大寻呼容量45万/小时/小区。 现网容量评估 现网中RNC2658忙时寻呼次数达到146798次，超过最大寻呼量超过空口寻呼容量的70%