智能网处理能力研究

张真

中国移动福建公司网管中心，福州 350000

智能网处理能力研究

张真

中国移动福建公司网管中心，福州 350000

本文重点阐述通过tpmC计算智能网系统支持CAPS和用户数的两个公式，并简要介绍系统处理能力等相关知识。

SAU；SCU；CAPS；Erl；(TPSR)TPS；tpmC

引言

目前由于智能网经过多年的发展，系统经过了长期的演变，在处理能力上可能发生了比较大的变化，某省出现了智能网的限呼情况，需要分析系统当前的处理能力，到底可以支撑多少CAPS。本文重点是讨论如何计算分析智能网处理能力，以及计算系统支持CAPS和用户数的两个公式。

1 基本知识

这里面只作最基本的介绍，如果想深入了解这几个知识的概念，可查阅相关文档：

CAPS： CAPS每秒试呼次数，是话务模型中最为主要的一个评测指标，用于评测用户呼叫的频繁程度。这里面要有一个基本的认识，CAPS是试呼次数，要包括没有接通通话的部分，从智能网出的话单来统计CAPS是不正确的。

TPS(TPSR)：每秒处理事务数（每呼叫占用的事务数），每个呼叫的平均事务数与具体的业务相关，该数值可以通过具体的业务特性使用到的SIB数，以及这些SIB使用的TPS来进行准确计算，计算过程很复杂，但是大家要了解TP的意思，因为业务的升级，可能导致TPS的变化，在计算某个业务的时候，也只是给了一个数值，但实际不同的版本，TPS值应该不同，最准确的TPS可能只有厂家那里有。

tpmC: 度量小型计算机在复杂事务处理环境下处理能力的单位,这些数值是各个外购件厂家提供。该数值对于计算设备的容量及其重要，通过它和TPS之间的换算，即可得到系统的处理能力。

2 智能网性能分析的整体思路

性能分析主要从SAU + SCP两个方面进行考虑。

2.1 SAU侧分析

2.1.1 链路负荷：SAU侧的一个比较关键的指标，就是链路负荷和链路分担是否平均。对于这两个指标可以通过话务统计来确定，一般对于SAU的链路负荷，单项可达到0.8Erl,双向可达到0.6Erl，如果负荷在接近该值的之前就可以考虑扩容，但是由于两个信铃点之间最多只能开16条LINK，所以SAU和其它网元之间的信令链路并不是可以无限扩展的，在解决这个问题中，常用多信令点技术，这个知识一定要掌握。另外要注意个别链路出现高负荷，是否是负荷不均？负荷不均可能和多种因素有关，常见的有：链路选择码是否正确，模块分配是否合理，链路寻址方式是否正确。

可能导致链路不均衡的几个例子：

例如：

1）一个链路集内不是2的幂次方的链路数，这样就会导致链路不均衡，如：3条链路。

2）链路选择码设置不正确，如：一个链路集内有8条链路，但是链路选择码却没有选择三个1，而选择了其它的情况。

3）模块分配不均衡，如：一个四个模块的SAU，其中1、2模块和两个STP都开通了4个链路，但是3、4模块却只和其中一个STP开通了链路。

4）寻址方式不合理，如：SAU和两个STP共开通32条链路，SAU设置的寻址方式为DPC＋SSN或DPC+OLD_GT，当DPC不是直连的信令点，需通过LSTP转接的情况，由于7号信令消息中SLS的限制，只能使用16条链路，SAU到LSTP的32条链路只能用16条，而且是固定的16条链路，所以会造成链路负荷不均。

2.1.2 对话号调整：对话号其实和SCP侧相关联。但是要注意的是，如果SAU该模块没有开通链路（或者该模块开通链路，但是因为某种原因而没有被充分利用），那么该模块的对话号就不能被对外利用，例如：一个8模块SAU,每个模块对话号15000，但是只有四个模块开通了链路，那么实际上对外的对话号只是15000×4，现网出现过因为这种原因，导致限呼的情况。那么对话号数怎么确定呢？一个最简单的计算公式 对话号＝2 * 自动机数＝2 * CAPS数 * 平均通话时长。

例如：一套智能网支持CAPS最大为500CAPS，预计平均通话时长为 100S，那么这个系统设置自动机数至少要大于50000，也就是说如果该SCP启动了10个SCF，那么SCF设置的SLPI 至少大于5000，对话号就要设置100000。

2.2 SCP侧分析

1）对话号与自动机：这里面就不过多说明，与SAU侧相关，见SAU侧分析。

2）I/O瓶颈： 在很多的情况，系统没有达到设计的容量，可能和I/O等存储设备相关，如I/O的占用也可能因为硬盘出现故障，数据库性能下降等原因导致。

3）scf/sdf进程个数： 如果是SCP(SCDU)模式的设备，更关心scf进程，如果是SDU设备，那么就要更关心sdu进程。我们这里只说明scf进程，scf进程的个数，直接导致并行访问I/O和业务处理的能力，所以进程的个数也直接影响系统处理能力。一个进程实际上只能使用到1个CPU资源，如果进程数不够，则对于多CPU资源的主机将得不到充分的利用，因此应该首先保证SCF个数>=CPU个数。但是进程数不是越多越好，因为关系到manager进程的分发能力和内存的占用情况，可以通过下面几个公式来计算scf个数。

从CPU个数上计算： scf个数 >= cpu个数

从内存占用上来看： scf个数 <（MEMSIZE－800M）/ 每个SCF的内存占用量－1可以通过查看SCU和SDU用户pipe目录下的文件大小，关注MAN_SCF和MAN_SDF打头的文件变化，大致判断SCF个数和SDF个数配置是否足够。如果这些文件多次查看都不为0，并且经常性的达到1K以上，那么可以说明SCF或者SDF个数配置少了，需要增加。否则，可以认为目前的话务量SCF和SDF个数的配置还是可以满足的。

4）根据tpmC进行计算系统处理能力，前面的几个因素，是要大家了解，一个系统的处理能力和很多方面要关，但是这部分是我们本文重点说明的部分，说明如何根据公式和经验来分析系统。

3 如何根据tpmC进行分析计算

3.1 如何计算设备承载的用户数。

在计算一个系统能够承载的用户数的时候，首先要有个感性认识，一个系统能够承载多少用户，是与用户的使用行为有关系的。影响系统承载能力的几个因素， 设备的tpmC、用户的话务模型（每用户话务量、平均通话占用时长）、业务单次呼叫消耗的TPS。

例如：一套设备（8CPU/4G），上面只承载IP17951业务，计算承载的用户数。建议的标准话务模型为：

每用户话务量 0.012Erl， 平均占用时长 200s

IP17951单次呼叫处理消耗10.2 TPS。

设备（8CPU/4G）的tpmC 是49300

下面是计算过程：

每 万 用 户 T P S ＝(10000*0.012/200)*10.2=6.12

折算设备（8CPU/4G）的tpmC＝6.12*9/0.7=79

总万用户数= 49300/79= 624

那么从这个计算过程中，大家可能还会发现上面红色的部分，9 代表什么意思，其中9为折算因子，不同机型折算因子不同，老机器的折算因子一般IBM取7，HP取9，新机器一般需要取到11左右。0.7代表什么意思，0.7是一个经验值，也就是意味着总处理能力的70%为可用处理能力。

那么最后公式就如下：

用户数＝ (tpmC*平均占用时长*0.7)/ (每用户话务量 * 单次呼叫消耗的TPS * 9)

通过上面的分析，我们就会发现，影响用户数不确定的因素，实际上就是用户行为部分，因为我们无法真正掌握用户的行为，也就是用户的平均占用时长，用户的话务量，我们无法控制用户单位时间内是拨打一个电话，还是两个电话，特别是节假日的时候，到底取什么样的话务模型？

那么现在我们再看一个有趣的现象，根据公式，为什么平均占用时长越长，反而可承载的用户数越多？

举一个例子： 有两类用户A/B，这两类用户都是10000人，而且两类用户一天内总的通话时长都是10000小时，但是A类用户每次通话都是1分钟，B类用户通话都是10分钟，那么哪类用户对于系统影响大，这个问题我估计大家都能回答正确，那就是A类用户，因为A类用户的呼叫次数高。

所以现在我们来分析，呼叫次数和呼叫占用时长这两个因素对于系统的影响，首先要明确智能网SCP和信令网是有比较大的区别，智能网的占用更多的考虑是对于CPU占用和I/O瓶颈的影响，那么呼叫次数的多少，对于这些资源影响是巨大的，因为一次呼叫，无论通话时间的长短，访问数据库的次数几乎是不变的，也就是从这个角度考虑，呼叫占用时间长短对于系统的影响很小。但是呼叫占用时长对于智能网到底有哪些影响呢，首先最直观的对于系统的自动机个数和对话号个数影响很大（前面说明过），另外系统需要保存这些通话信息，通话时间长，对于内存存在一定影响。但是总体来说，呼叫占用时长对于系统的影响较呼叫次数影响小很多。

那么肯定就会有人想到了，呼叫占用时长对于系统多少还是有一点影响，哪怕就是没有影响，那么也不会因为通话占用时间长，反而能够支持的用户数越大呀？

那么现在我们就要看一看所谓的话务模型，话务模型是有两个因素组成：每用户话务量，平均占用时长。

大家对于平均占用时长很好理解，那么每用户话务量是什么呢？

话务量 ＝ 单位时间平均发生的呼叫次数 * 每次呼叫的平均占用时长

如果单位时间为小时，即小时呼，又名Erl(爱尔兰）,话务量是交换机负荷很重要的指标，就相当于CAPS对于SCP的重要性。

那么现在就很好理解了，如果在话务量一定的情况下，平均占用时长越大，会出现呼叫次数越小，这样就会出现可支持的用户数越多，如果在平均占用时长一定的情况下，话务量越大，呼叫次数会越大，这样就会出现可支持的用户数越少。

备注：这里面说明的平均占用时长和用户数的变化，只是针对于计算公式来说明，因为我们在计算用户数的时候，经常会让用户提供平均占用时长和话务量这两个参数，如果用户提供的平均占用时长越大，计算出来的用户数就会越大，就是因为已经确定了话务量一定。但是实际在现网中，话务量和通话时长都是在变化的，所以不能认为通话时长越长对于智能网处理性能越有力，而是通话时长越长，实际上肯定是对于智能网的负荷进行加重，其中实际影响最大的就是系统的对话号和自动机。

3.2 如何计算设备承载的最大CAPS

在分析之前，我们先看一个案例，某省某节假日系统出现了动态限呼，限呼的时候发现CAPS已经高达400多，再仔细检查，发现平时CAPS几乎不超过80，今日在CAPS达到210CAPS的时候开始出现限呼，局方要求进行分析，市场产品部做了如下分析：

首先进行从智能网侧进行限呼时段话务统计：

统计时间：××月×日 18：16～20：30 限呼日期

话单数 总通话时长（秒） 平均通话时长（秒）

业务113446038594391 87

业务215585 3198993 205

统计时间： ××月×日 18：16～20：30 平时日期

话单数 总通话时长（秒） 平均通话时长（秒）

业务115829236459472230

业务2376387348937195

然后根据公式：

CAPS = 用户数×平均话务量/平均占用时长

这样计算最后得出的结论是，这个节假日设备肯定不正常，因为根据公式计算，节假日的CAPS应该比平时还小，在计算的时候，平均占用时长直接根据话单里面统计的时长进行计算，话务量直接根据总通话时长进行评估。那么设备异常的结论，从下面分析得出：

首先用户数没有大的变化，所以不会因为用户数导致CAPS有大的变化。

其次：平均话务量，根据平时的话单数和节假日的话单数对比，却发现节假日的话单数反而少，所以认为平均话务量少了，这个因素会导致CAPS变小。

再次：平均占用时长参数，节假日的平均占用时长还变长了，那么同样会导致CAPS变少。

所以最后的结论，认为系统的确当时有莫名其妙的问题，需要用服和研发继续分析。

对于这个案例和这个想法，看到这里大家是否有什么想法？

a) 首先大家认为公式是否有错误？我认为是没有错误的，那么究竟问题在哪里？

可能对于智能网比较了解一点人，都会知道，用户的平均话务量能够根据话单来进行说明吗，肯定不能，因为在限呼的时候，有很多通话根本就没有接续，根本不会有话单，还有即使在平时，也不是所有的呼叫都会产生话单。在平时或许可以拿话单的多少来衡量话务量，但是在限呼的时候和平时对比，这就完全错误了。

b) 为什么明明话务量那么大，结果却出现了话单很少，问题究竟在哪里？

那么首先要对静态和动态限呼的原理有所了解，静态限呼完全是根据系统当前设定的CAPS来决定是否抛弃呼叫，但是动态限呼，却是根据系统的响应时间，这样的结果就可能导致出现一个恶性循环的情况，系统反应越慢，结果可能导致用户呼叫接入的次数越多，这样就可能导致整个系统处于一种极度过负荷状态，最后结果都可能导致一个呼叫都无法接通。

那么我们现在看一看系统支持的CAPS的计算公式：

系统支持的CAPS＝设备支持的tpmC*0.7/（单次呼叫的TPS*9)

其中9为折算因子，不同机型折算因子不同，老机器的折算因子一般IBM取7，HP取9，新机器一般需要取到12左右。

tpmC值是恒定的，每一个业务的一个版本CAPS的TPS也是恒定的，所以设备支持的CAPS和话务模型无关，只和业务有关。

举例子：

IP17951单次呼叫处理消耗10.2 TPS。

建议的标准话务模型为：

每用户话务量 0.012Erl

平均占用时长 200s

那么现在看一套 8CPU ,4G内存的设备，它可支持的TPMC是49300。设备支持的tpmC，和CPU的个数关系很大，可以认为CPU个数和tpmc成线性增长，另外tpmC和CPU的主频也关系很大。

那么这套设备支持IP17951的CAPS＝49300*0.7/10.2*9 =375CAPS

所以现在我们就分析一下影响系统支持最大CAPS的几个因素和系统支持最大CAPS之间的关系：

从这里面看到不同的业务装载在同样型号的设备下，支持的CAPS是不一样的，因为每个业务单次呼叫消耗的TPS差别很大。同时我们现在考虑的只是TPMC，往往系统处理能力还和磁盘的I/O关系很大，很多情况下，因为I/O成为瓶颈，结果导致系统无法达到处理的CAPS值。从这里我们也看到了系统支持的最大CAPS几乎和话务模型是没有关系的，那么现在我们怎么理解这个公式：

CAPS = 用户数×平均话务量／平均占用时长

从这个公式好像感觉CAPS是应该和话务模型有关系呀，仔细琢磨一下，就应该明白了正是因为这个公式里面CAPS实际上已经是一个不变的恒量了，导致用户数直接和话务模型有关。

4 总结

系统支持用户数＝ (tpmC*平均占用时长*0.7)/ (每用户话务量 * 单次呼叫消耗的TPS * 折算因子)

系统支持的CAPS＝设备支持的tpmC*0.7/（单次呼叫的TPS*折算因子)

[1]杨杨，程京.一种非公平条件下的多SCP智能网过载控制算法[J].科学技术与工程，2006（13）：1970～1972.

[2]廖建新，王晶，郭力.移动智能网[M].北京：北京邮电大学出版社，2000.

[3]叶奕亮.智能网过载控制的研究[J].广东通信技术，2008（12）：45～49.

[4]郭军雷.浅谈通信业智能网的发展和趋势[J].商情，2011（21）：177～177.

[5]张奇支，廖建新，马旭涛，雷正雄.移动智能网多业务环境下SCP过载控制研究[J].计算机应用研究，2006（6）：254～257.

[6]王玉龙，廖建新.移动智能网SCP多业务环境下的过载控制研究[J].电子学报，2005（10）：1849～1852.

10.3969/j.issn.1001-8972.2012.17.037

张真 性别 男，1980年生，福建福州人，学历（本科），工程师，现任职于中国移动福建公司网管中心，从事通信网络研究以及维护工作。