PCU负荷评估方法介绍.docVIP

PCU负荷计算方法介绍 BSC概况 SABBSC1日话务和数据分别如下面图表所示： 从上面图表我们可以得到BSC话务和数据业务忙时，BSC的数据业务都是夜间较高。数据业务忙时总体出现在22：00-00:00时段。而话务最忙时出现在晚间21：00。 PCU，RPP，GSL使用率，T拥塞，P分配失败关系 GSL使用率是PCU的资源使用情况的最真实反映。随着EDGE业务的发展，GSL的使用越来越紧张，我们通过GSL的使用情况来评估PCU的负荷情况。 首选我们来看看各网元的曲线图（数据为3月6日－9日全天的各时段的平均） 从曲线图我们可以看到SABBSC1的PCU拥塞率都基本为0，而在数据忙时出现RPP的拥塞.从数据分析上可以看到RPP拥塞在GSL使用率上升到80左右的时候出现。随着GSL的使用率增大，RPP的拥塞率增大。 下面为PCU使用率和GSL使用率的计算公式： PCU拥塞率= 100 * FAILMOVECELL / (CELLMOVED[sum of cell] + FAILMOVECELL) GSL使用率= GSLUTIL/GSLSSCAN RPP拥塞率= 100 * ALLPDCHPCUFAIL / PCHALLATT[sum of cell] PDCH分配是PCU通过其下面某一RPP来实现的。当RPP存在拥塞的时候就有可能导致PDCH分配失败。但需要注意的是，ALLPDCHPCUFAIL并不能准确反映由于GSL资源紧张而导致用户无法获取足够PDCH的次数。这是因为任一小区的数据业务只能受某一个确定的RPP管理，当某个小区发生PDCH建立申请，但是对应的RPP由于资源不足无法满足这一需求，此时ALLPDCHPCUFAIL就会加1。虽然该COUNTER被触发计数，但此次PDCH建立申请并没有结束，系统会尝试将这一RPP中的某个小区移到别的RPP上去，以充分利用整个PCU的资源来满足此次申请，这被称为小区转移机制。如果此时其它RPP仍比较空闲，此次PDCH建立申请仍然可能成功。只有当PCU中所有的RPP处于资源紧张状态时，此次的PDCH建立申请才会失败，同时FAILMOVECELL加1。因此，小区转移机制其实是PCU内部的负载均衡方法。 根据经验认为当GSL使用率达到80的时候， RPP就会出现拥塞，同时此时的PCU也开始出现少量PCU拥塞，但这少量的PCU拥塞可以通过小区转移机制将这些PDCH分配申请转移到其它RPP板上面，用户的PDCH分配申请仍然可以得到满足。如果大部分的RPP都负荷过高就会导致PDCH分配失败。 RPP资源估算 PCU的处理能力问题，主要分为2个方面，一个是RPP对于PDCH信道数的处理能力，一个是RPP上所能支持的GSL设备数的多少。为了理解这两个方面，首先让我们认识一下RPP的内部结构： 可以看到，每个RPP里有8个DSP。每个DSP的处理能力是25个B-PDCH。每个G-PDCH/E-PDCH需要的处理能力是B-PDCH的1.5倍，因此，一个DSP的处理能力是25/1.5=16.7个G-PDCH/E-PDCH。在8个DSP中，只有6个DSP可以用来处理Abis，剩下2个只能用来处理Gb。这样，可以知道一个RPP对于PDCH的处理能力是25×6＝150个B-PDCH，或者150/1.5=100个E-PDCH/G-PDCH。 而GSL设备是RPP的业务处理单元，每个GSL设备能够处理1个16kbps业务，因此，对每个64kbps业务进行处理需要4个GSL设备。而每块RPP支持的GSL设备数却是受到RPP结构图中的DL2传输能力限制的，每个DL2时隙支持4个GSL设备。因为每块RPP有64个DL2时隙，除去用于同步的2个时隙，一块RPP板能够支持的GSL设备数量为：62*4=248，所以对16k（B-PDCH）的业务处理能力为248，对于64k（E-PDCH/G-PDCH）的业务为62。 综合两个限制，RPP对PDCH的处理能力如下表所示 所以我们可以通过网元的PDCH分配数来估算RPP的容量是否充足，由于在统计上虽然可以得出PDCH分配数，但不能准确的对BPDCH和EPDCH作出准确的区分。BPDCH是支持GPRS的PDCH信道，EPDCH是支持EDGE的PDCH信道。我们可以使用RLGRP指令得出PDCH分配总数，分别得到BPDCH和EPDCH。可以选择该网元数据忙时在不同时段（可以相隔5到15分钟）用指令RLGRP得出数据进行处理。 从GSL使用率我们已经得到RPP拥塞较大的网元，下面就以SABBSC1为例，计算其所需的RPP数目。目前SABBSC1的配置如下 RPP数——19个 PDCH总数——1266个 BPDCH分配数——514个 EPDCH分配数——752个 用RRGBP查得用于SABB