位置区寻呼性能评估.docVIP

位置区寻呼性能评估 配置与容量分析 天水网络位置区规模概述 （不包括TDRNC和中兴BSC） 天水网络配置如上图所示，共有3个MSC、8个位置区，每个BSC单独一个位置区，其中TISGS2和TISGS3下的位置区载波数较多，分别超过了1000块和900块。 共有2282个小区，7193块载波，其中载波数较小的LZGS31下的3个位置区的小区载波配置主要为4-9载波，同时也有相当部分的10-12载波的大配置小区；载波数较大的TISGS2和TISGS3下的5个位置区的小区载波配置主要为1-3载波，同时有一部分4-6载波的中等配置小区。 各小区详细配置见下附件： Um接口寻呼容量分析 Um接口下行方向时隙0上逻辑信道和物理信道的映射关系见下图1、图2。图中的CCCH由PCH和AGCH共用，PCH用于下发寻呼消息而AGCH用于下发立即指配消息。AGCH优先占用CCCH，但仍可通过设置AGBLK可以为AGCH预留专用的CCCH BLOCK。可以看出BCCHTYPE=NCOMB方式及COMB方式下分别有9个和3个CCCH BLOCK，该51复帧的周期约为0.2354s。 图表 1 NCOMB(非组合)方式 图表 2 COMB(组合)方式 寻呼消息中的用户信息可以为TMSI或IMSI，在数据业务通过CCCH下发寻呼时使用PTMSI。每个用于寻呼的CCCH BLOCK为一个PAGING BLOCK，对于不同种类的寻呼消息的承载能力如下图所示，由图可以看出，每个PAGING BLOCK最多可以承载4个TMSI/PTMSI的寻呼消息，或2个IMSI的寻呼消息。 用户属于哪个寻呼组又用户的IMSI和小区参数MFRMS设置共同决定，由于用户IMSI的随机性，各小区各寻呼组的寻呼负荷是不平均的。CCCH信道的寻呼组重复周期和个数由MFRMS决定，不同MFRMS下的寻呼组时间间隔和寻呼组数量如下表所示： 相似的，在语音业务时，AGCH占用CCCH BLOCK下发立即指派一般使用1个CCCH BLOCK下发1个用户立即指派消息，当使用立即指派扩展时，可以一次下发2个用户的立即指配消息，但此时只能分配2个用户在相同的SDCCH/4或SDCCH/8中；当数据业务通过CCCH下发PS立即指派消息时，1个CCCH BLOCK只能下发1个用户的立即指派消息。详细如下图所示： 图表 3 CCCH BLOCK 通过以上的介绍，可以了解到，Um接口的寻呼容量与寻呼使用IMSI和TMSI的比例有关，天水现网MSC的寻呼策略为1次寻呼使用TMSI寻呼，2次寻呼在整个MSC下使用IMSI寻呼。因此天水现网各个位置区下平均每个CCCH BLOCK承载的寻呼个数为(设一个CCCH BLOCK的容量为4)： 即：平均每CCCH BLOCK承载寻呼数=4/(1+IMSI寻呼占比) 其中： 因此天水现网Um接口寻呼容量的计算方法为: (每51复帧的CCCH块数 —AGCH预留块数)/0.2354*4/(1+IMSI寻呼占比) 根据3月17-19日、22日、23日5天的MSC寻呼统计计算各位置区的IMSI寻呼占比，最终计算得到天水各位置区的Um接口寻呼容量如下图： 根据Um接口的寻呼容量计算方法，由于IMSI寻呼占用CCCH BLOCK的容量较TMSI寻呼方式时大1倍，因此Um接口理论寻呼容量会随IMSI寻呼占比的升高而降低。 由上图可以看出，各位置区的寻呼容量基本都在40万/小时左右，其中TISGS3下的LAC=37767的IMSI寻呼占比最高，其平均寻呼容量在39万左右。 当Um接口的寻呼负荷为理论容量的50%时，寻呼拥塞和丢弃情况极少且BTS有足够的机会重发寻呼，此时的位置区寻呼性能处于较好水平。 根据与MSC寻呼统计相同日期的6六忙时BSC寻呼负荷统计，汇总得到各位置区寻呼负荷情况如下表：（包含数据业务寻呼） 由上图可以看到，各位置区寻呼负荷都在20万以下，最小寻呼负荷为最大寻呼负荷的50%到60%左右。由各位置区寻呼负荷最大值与理论Um接口寻呼容量的50%比较，如下表所示： 由上图可以看到，所有位置区寻呼负荷都小于计算得到的Um寻呼容量的50%，其中 LAC=37760和37766的最大寻呼负荷与理论容量较接近，其它位置区的寻呼负荷都在理论容量的75%以下，各位置区寻呼容量充足。 具体位置区Um接口寻呼容量计算方法请参考“附录1”；相关MSC和位置区的寻呼统计与寻呼容量计算结果详见以下附件： A-bis接口寻呼承载能力分析 出于网络安全的考虑，我们通常将Abis接口LAPD链路的信令负荷控制在50%以下，负荷高于60%将会存在较大的阻塞风险?寻呼消息(包括帧校验序列FCS和标头flags)字长为21Byte，按照常规情况考虑，LAPD链路信令负荷中60%为寻呼消息所贡献，那么，对