智能網(wǎng)處理能力研究

張真

中國移動福建公司網(wǎng)管中心，福州 350000

智能網(wǎng)處理能力研究

張真

中國移動福建公司網(wǎng)管中心，福州 350000

本文重點闡述通過tpmC計算智能網(wǎng)系統(tǒng)支持CAPS和用戶數(shù)的兩個公式，并簡要介紹系統(tǒng)處理能力等相關(guān)知識。

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

引言

目前由于智能網(wǎng)經(jīng)過多年的發(fā)展，系統(tǒng)經(jīng)過了長期的演變，在處理能力上可能發(fā)生了比較大的變化，某省出現(xiàn)了智能網(wǎng)的限呼情況，需要分析系統(tǒng)當(dāng)前的處理能力，到底可以支撐多少CAPS。本文重點是討論如何計算分析智能網(wǎng)處理能力，以及計算系統(tǒng)支持CAPS和用戶數(shù)的兩個公式。

1 基本知識

這里面只作最基本的介紹，如果想深入了解這幾個知識的概念，可查閱相關(guān)文檔：

CAPS： CAPS每秒試呼次數(shù)，是話務(wù)模型中最為主要的一個評測指標(biāo)，用于評測用戶呼叫的頻繁程度。這里面要有一個基本的認(rèn)識，CAPS是試呼次數(shù)，要包括沒有接通通話的部分，從智能網(wǎng)出的話單來統(tǒng)計CAPS是不正確的。

TPS(TPSR)：每秒處理事務(wù)數(shù)（每呼叫占用的事務(wù)數(shù)），每個呼叫的平均事務(wù)數(shù)與具體的業(yè)務(wù)相關(guān)，該數(shù)值可以通過具體的業(yè)務(wù)特性使用到的SIB數(shù)，以及這些SIB使用的TPS來進(jìn)行準(zhǔn)確計算，計算過程很復(fù)雜，但是大家要了解TP的意思，因為業(yè)務(wù)的升級，可能導(dǎo)致TPS的變化，在計算某個業(yè)務(wù)的時候，也只是給了一個數(shù)值，但實際不同的版本，TPS值應(yīng)該不同，最準(zhǔn)確的TPS可能只有廠家那里有。

tpmC: 度量小型計算機在復(fù)雜事務(wù)處理環(huán)境下處理能力的單位,這些數(shù)值是各個外購件廠家提供。該數(shù)值對于計算設(shè)備的容量及其重要，通過它和TPS之間的換算，即可得到系統(tǒng)的處理能力。

2 智能網(wǎng)性能分析的整體思路

性能分析主要從SAU + SCP兩個方面進(jìn)行考慮。

2.1 SAU側(cè)分析

2.1.1 鏈路負(fù)荷：SAU側(cè)的一個比較關(guān)鍵的指標(biāo)，就是鏈路負(fù)荷和鏈路分擔(dān)是否平均。對于這兩個指標(biāo)可以通過話務(wù)統(tǒng)計來確定，一般對于SAU的鏈路負(fù)荷，單項可達(dá)到0.8Erl,雙向可達(dá)到0.6Erl，如果負(fù)荷在接近該值的之前就可以考慮擴容，但是由于兩個信鈴點之間最多只能開16條LINK，所以SAU和其它網(wǎng)元之間的信令鏈路并不是可以無限擴展的，在解決這個問題中，常用多信令點技術(shù)，這個知識一定要掌握。另外要注意個別鏈路出現(xiàn)高負(fù)荷，是否是負(fù)荷不均？負(fù)荷不均可能和多種因素有關(guān)，常見的有：鏈路選擇碼是否正確，模塊分配是否合理，鏈路尋址方式是否正確。

可能導(dǎo)致鏈路不均衡的幾個例子：

例如：

1）一個鏈路集內(nèi)不是2的冪次方的鏈路數(shù)，這樣就會導(dǎo)致鏈路不均衡，如：3條鏈路。

2）鏈路選擇碼設(shè)置不正確，如：一個鏈路集內(nèi)有8條鏈路，但是鏈路選擇碼卻沒有選擇三個1，而選擇了其它的情況。

3）模塊分配不均衡，如：一個四個模塊的SAU，其中1、2模塊和兩個STP都開通了4個鏈路，但是3、4模塊卻只和其中一個STP開通了鏈路。

4）尋址方式不合理，如：SAU和兩個STP共開通32條鏈路，SAU設(shè)置的尋址方式為DPC＋SSN或DPC+OLD_GT，當(dāng)DPC不是直連的信令點，需通過LSTP轉(zhuǎn)接的情況，由于7號信令消息中SLS的限制，只能使用16條鏈路，SAU到LSTP的32條鏈路只能用16條，而且是固定的16條鏈路，所以會造成鏈路負(fù)荷不均。

2.1.2 對話號調(diào)整：對話號其實和SCP側(cè)相關(guān)聯(lián)。但是要注意的是，如果SAU該模塊沒有開通鏈路（或者該模塊開通鏈路，但是因為某種原因而沒有被充分利用），那么該模塊的對話號就不能被對外利用，例如：一個8模塊SAU,每個模塊對話號15000，但是只有四個模塊開通了鏈路，那么實際上對外的對話號只是15000×4，現(xiàn)網(wǎng)出現(xiàn)過因為這種原因，導(dǎo)致限呼的情況。那么對話號數(shù)怎么確定呢？一個最簡單的計算公式 對話號＝2 * 自動機數(shù)＝2 * CAPS數(shù) * 平均通話時長。

例如：一套智能網(wǎng)支持CAPS最大為500CAPS，預(yù)計平均通話時長為 100S，那么這個系統(tǒng)設(shè)置自動機數(shù)至少要大于50000，也就是說如果該SCP啟動了10個SCF，那么SCF設(shè)置的SLPI 至少大于5000，對話號就要設(shè)置100000。

2.2 SCP側(cè)分析

1）對話號與自動機：這里面就不過多說明，與SAU側(cè)相關(guān)，見SAU側(cè)分析。

2）I/O瓶頸： 在很多的情況，系統(tǒng)沒有達(dá)到設(shè)計的容量，可能和I/O等存儲設(shè)備相關(guān)，如I/O的占用也可能因為硬盤出現(xiàn)故障，數(shù)據(jù)庫性能下降等原因?qū)е隆?/p>

3）scf/sdf進(jìn)程個數(shù)： 如果是SCP(SCDU)模式的設(shè)備，更關(guān)心scf進(jìn)程，如果是SDU設(shè)備，那么就要更關(guān)心sdu進(jìn)程。我們這里只說明scf進(jìn)程，scf進(jìn)程的個數(shù)，直接導(dǎo)致并行訪問I/O和業(yè)務(wù)處理的能力，所以進(jìn)程的個數(shù)也直接影響系統(tǒng)處理能力。一個進(jìn)程實際上只能使用到1個CPU資源，如果進(jìn)程數(shù)不夠，則對于多CPU資源的主機將得不到充分的利用，因此應(yīng)該首先保證SCF個數(shù)>=CPU個數(shù)。但是進(jìn)程數(shù)不是越多越好，因為關(guān)系到manager進(jìn)程的分發(fā)能力和內(nèi)存的占用情況，可以通過下面幾個公式來計算scf個數(shù)。

從CPU個數(shù)上計算： scf個數(shù) >= cpu個數(shù)

從內(nèi)存占用上來看： scf個數(shù) <（MEMSIZE－800M）/ 每個SCF的內(nèi)存占用量－1可以通過查看SCU和SDU用戶pipe目錄下的文件大小，關(guān)注MAN_SCF和MAN_SDF打頭的文件變化，大致判斷SCF個數(shù)和SDF個數(shù)配置是否足夠。如果這些文件多次查看都不為0，并且經(jīng)常性的達(dá)到1K以上，那么可以說明SCF或者SDF個數(shù)配置少了，需要增加。否則，可以認(rèn)為目前的話務(wù)量SCF和SDF個數(shù)的配置還是可以滿足的。

4）根據(jù)tpmC進(jìn)行計算系統(tǒng)處理能力，前面的幾個因素，是要大家了解，一個系統(tǒng)的處理能力和很多方面要關(guān)，但是這部分是我們本文重點說明的部分，說明如何根據(jù)公式和經(jīng)驗來分析系統(tǒng)。

3 如何根據(jù)tpmC進(jìn)行分析計算

3.1 如何計算設(shè)備承載的用戶數(shù)。

在計算一個系統(tǒng)能夠承載的用戶數(shù)的時候，首先要有個感性認(rèn)識，一個系統(tǒng)能夠承載多少用戶，是與用戶的使用行為有關(guān)系的。影響系統(tǒng)承載能力的幾個因素， 設(shè)備的tpmC、用戶的話務(wù)模型（每用戶話務(wù)量、平均通話占用時長）、業(yè)務(wù)單次呼叫消耗的TPS。

例如：一套設(shè)備（8CPU/4G），上面只承載IP17951業(yè)務(wù)，計算承載的用戶數(shù)。建議的標(biāo)準(zhǔn)話務(wù)模型為：

每用戶話務(wù)量 0.012Erl， 平均占用時長 200s

IP17951單次呼叫處理消耗10.2 TPS。

設(shè)備（8CPU/4G）的tpmC 是49300

下面是計算過程：

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

折算設(shè)備（8CPU/4G）的tpmC＝6.12*9/0.7=79

總?cè)f用戶數(shù)= 49300/79= 624

那么從這個計算過程中，大家可能還會發(fā)現(xiàn)上面紅色的部分，9 代表什么意思，其中9為折算因子，不同機型折算因子不同，老機器的折算因子一般IBM取7，HP取9，新機器一般需要取到11左右。0.7代表什么意思，0.7是一個經(jīng)驗值，也就是意味著總處理能力的70%為可用處理能力。

那么最后公式就如下：

用戶數(shù)＝ (tpmC*平均占用時長*0.7)/ (每用戶話務(wù)量 * 單次呼叫消耗的TPS * 9)

通過上面的分析，我們就會發(fā)現(xiàn)，影響用戶數(shù)不確定的因素，實際上就是用戶行為部分，因為我們無法真正掌握用戶的行為，也就是用戶的平均占用時長，用戶的話務(wù)量，我們無法控制用戶單位時間內(nèi)是撥打一個電話，還是兩個電話，特別是節(jié)假日的時候，到底取什么樣的話務(wù)模型？

那么現(xiàn)在我們再看一個有趣的現(xiàn)象，根據(jù)公式，為什么平均占用時長越長，反而可承載的用戶數(shù)越多？

舉一個例子： 有兩類用戶A/B，這兩類用戶都是10000人，而且兩類用戶一天內(nèi)總的通話時長都是10000小時，但是A類用戶每次通話都是1分鐘，B類用戶通話都是10分鐘，那么哪類用戶對于系統(tǒng)影響大，這個問題我估計大家都能回答正確，那就是A類用戶，因為A類用戶的呼叫次數(shù)高。

所以現(xiàn)在我們來分析，呼叫次數(shù)和呼叫占用時長這兩個因素對于系統(tǒng)的影響，首先要明確智能網(wǎng)SCP和信令網(wǎng)是有比較大的區(qū)別，智能網(wǎng)的占用更多的考慮是對于CPU占用和I/O瓶頸的影響，那么呼叫次數(shù)的多少，對于這些資源影響是巨大的，因為一次呼叫，無論通話時間的長短，訪問數(shù)據(jù)庫的次數(shù)幾乎是不變的，也就是從這個角度考慮，呼叫占用時間長短對于系統(tǒng)的影響很小。但是呼叫占用時長對于智能網(wǎng)到底有哪些影響呢，首先最直觀的對于系統(tǒng)的自動機個數(shù)和對話號個數(shù)影響很大（前面說明過），另外系統(tǒng)需要保存這些通話信息，通話時間長，對于內(nèi)存存在一定影響。但是總體來說，呼叫占用時長對于系統(tǒng)的影響較呼叫次數(shù)影響小很多。

那么肯定就會有人想到了，呼叫占用時長對于系統(tǒng)多少還是有一點影響，哪怕就是沒有影響，那么也不會因為通話占用時間長，反而能夠支持的用戶數(shù)越大呀？

那么現(xiàn)在我們就要看一看所謂的話務(wù)模型，話務(wù)模型是有兩個因素組成：每用戶話務(wù)量，平均占用時長。

大家對于平均占用時長很好理解，那么每用戶話務(wù)量是什么呢？

話務(wù)量 ＝ 單位時間平均發(fā)生的呼叫次數(shù) * 每次呼叫的平均占用時長

如果單位時間為小時，即小時呼，又名Erl(愛爾蘭）,話務(wù)量是交換機負(fù)荷很重要的指標(biāo)，就相當(dāng)于CAPS對于SCP的重要性。

那么現(xiàn)在就很好理解了，如果在話務(wù)量一定的情況下，平均占用時長越大，會出現(xiàn)呼叫次數(shù)越小，這樣就會出現(xiàn)可支持的用戶數(shù)越多，如果在平均占用時長一定的情況下，話務(wù)量越大，呼叫次數(shù)會越大，這樣就會出現(xiàn)可支持的用戶數(shù)越少。

備注：這里面說明的平均占用時長和用戶數(shù)的變化，只是針對于計算公式來說明，因為我們在計算用戶數(shù)的時候，經(jīng)常會讓用戶提供平均占用時長和話務(wù)量這兩個參數(shù)，如果用戶提供的平均占用時長越大，計算出來的用戶數(shù)就會越大，就是因為已經(jīng)確定了話務(wù)量一定。但是實際在現(xiàn)網(wǎng)中，話務(wù)量和通話時長都是在變化的，所以不能認(rèn)為通話時長越長對于智能網(wǎng)處理性能越有力，而是通話時長越長，實際上肯定是對于智能網(wǎng)的負(fù)荷進(jìn)行加重，其中實際影響最大的就是系統(tǒng)的對話號和自動機。

3.2 如何計算設(shè)備承載的最大CAPS

在分析之前，我們先看一個案例，某省某節(jié)假日系統(tǒng)出現(xiàn)了動態(tài)限呼，限呼的時候發(fā)現(xiàn)CAPS已經(jīng)高達(dá)400多，再仔細(xì)檢查，發(fā)現(xiàn)平時CAPS幾乎不超過80，今日在CAPS達(dá)到210CAPS的時候開始出現(xiàn)限呼，局方要求進(jìn)行分析，市場產(chǎn)品部做了如下分析：

首先進(jìn)行從智能網(wǎng)側(cè)進(jìn)行限呼時段話務(wù)統(tǒng)計：

統(tǒng)計時間：××月×日 18：16～20：30 限呼日期

話單數(shù) 總通話時長（秒） 平均通話時長（秒）

業(yè)務(wù)113446038594391 87

業(yè)務(wù)215585 3198993 205

統(tǒng)計時間： ××月×日 18：16～20：30 平時日期

話單數(shù) 總通話時長（秒） 平均通話時長（秒）

業(yè)務(wù)115829236459472230

業(yè)務(wù)2376387348937195

然后根據(jù)公式：

CAPS = 用戶數(shù)×平均話務(wù)量/平均占用時長

這樣計算最后得出的結(jié)論是，這個節(jié)假日設(shè)備肯定不正常，因為根據(jù)公式計算，節(jié)假日的CAPS應(yīng)該比平時還小，在計算的時候，平均占用時長直接根據(jù)話單里面統(tǒng)計的時長進(jìn)行計算，話務(wù)量直接根據(jù)總通話時長進(jìn)行評估。那么設(shè)備異常的結(jié)論，從下面分析得出：

首先用戶數(shù)沒有大的變化，所以不會因為用戶數(shù)導(dǎo)致CAPS有大的變化。

其次：平均話務(wù)量，根據(jù)平時的話單數(shù)和節(jié)假日的話單數(shù)對比，卻發(fā)現(xiàn)節(jié)假日的話單數(shù)反而少，所以認(rèn)為平均話務(wù)量少了，這個因素會導(dǎo)致CAPS變小。

再次：平均占用時長參數(shù)，節(jié)假日的平均占用時長還變長了，那么同樣會導(dǎo)致CAPS變少。

所以最后的結(jié)論，認(rèn)為系統(tǒng)的確當(dāng)時有莫名其妙的問題，需要用服和研發(fā)繼續(xù)分析。

對于這個案例和這個想法，看到這里大家是否有什么想法？

a) 首先大家認(rèn)為公式是否有錯誤？我認(rèn)為是沒有錯誤的，那么究竟問題在哪里？

可能對于智能網(wǎng)比較了解一點人，都會知道，用戶的平均話務(wù)量能夠根據(jù)話單來進(jìn)行說明嗎，肯定不能，因為在限呼的時候，有很多通話根本就沒有接續(xù)，根本不會有話單，還有即使在平時，也不是所有的呼叫都會產(chǎn)生話單。在平時或許可以拿話單的多少來衡量話務(wù)量，但是在限呼的時候和平時對比，這就完全錯誤了。

b) 為什么明明話務(wù)量那么大，結(jié)果卻出現(xiàn)了話單很少，問題究竟在哪里？

那么首先要對靜態(tài)和動態(tài)限呼的原理有所了解，靜態(tài)限呼完全是根據(jù)系統(tǒng)當(dāng)前設(shè)定的CAPS來決定是否拋棄呼叫，但是動態(tài)限呼，卻是根據(jù)系統(tǒng)的響應(yīng)時間，這樣的結(jié)果就可能導(dǎo)致出現(xiàn)一個惡性循環(huán)的情況，系統(tǒng)反應(yīng)越慢，結(jié)果可能導(dǎo)致用戶呼叫接入的次數(shù)越多，這樣就可能導(dǎo)致整個系統(tǒng)處于一種極度過負(fù)荷狀態(tài)，最后結(jié)果都可能導(dǎo)致一個呼叫都無法接通。

那么我們現(xiàn)在看一看系統(tǒng)支持的CAPS的計算公式：

系統(tǒng)支持的CAPS＝設(shè)備支持的tpmC*0.7/（單次呼叫的TPS*9)

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

tpmC值是恒定的，每一個業(yè)務(wù)的一個版本CAPS的TPS也是恒定的，所以設(shè)備支持的CAPS和話務(wù)模型無關(guān)，只和業(yè)務(wù)有關(guān)。

舉例子：

IP17951單次呼叫處理消耗10.2 TPS。

建議的標(biāo)準(zhǔn)話務(wù)模型為：

每用戶話務(wù)量 0.012Erl

平均占用時長 200s

那么現(xiàn)在看一套 8CPU ,4G內(nèi)存的設(shè)備，它可支持的TPMC是49300。設(shè)備支持的tpmC，和CPU的個數(shù)關(guān)系很大，可以認(rèn)為CPU個數(shù)和tpmc成線性增長，另外tpmC和CPU的主頻也關(guān)系很大。

那么這套設(shè)備支持IP17951的CAPS＝49300*0.7/10.2*9 =375CAPS

所以現(xiàn)在我們就分析一下影響系統(tǒng)支持最大CAPS的幾個因素和系統(tǒng)支持最大CAPS之間的關(guān)系：

從這里面看到不同的業(yè)務(wù)裝載在同樣型號的設(shè)備下，支持的CAPS是不一樣的，因為每個業(yè)務(wù)單次呼叫消耗的TPS差別很大。同時我們現(xiàn)在考慮的只是TPMC，往往系統(tǒng)處理能力還和磁盤的I/O關(guān)系很大，很多情況下，因為I/O成為瓶頸，結(jié)果導(dǎo)致系統(tǒng)無法達(dá)到處理的CAPS值。從這里我們也看到了系統(tǒng)支持的最大CAPS幾乎和話務(wù)模型是沒有關(guān)系的，那么現(xiàn)在我們怎么理解這個公式：

CAPS = 用戶數(shù)×平均話務(wù)量／平均占用時長

從這個公式好像感覺CAPS是應(yīng)該和話務(wù)模型有關(guān)系呀，仔細(xì)琢磨一下，就應(yīng)該明白了正是因為這個公式里面CAPS實際上已經(jīng)是一個不變的恒量了，導(dǎo)致用戶數(shù)直接和話務(wù)模型有關(guān)。

4 總結(jié)

系統(tǒng)支持用戶數(shù)＝ (tpmC*平均占用時長*0.7)/ (每用戶話務(wù)量 * 單次呼叫消耗的TPS * 折算因子)

系統(tǒng)支持的CAPS＝設(shè)備支持的tpmC*0.7/（單次呼叫的TPS*折算因子)

[1]楊楊，程京.一種非公平條件下的多SCP智能網(wǎng)過載控制算法[J].科學(xué)技術(shù)與工程，2006（13）：1970～1972.

[2]廖建新，王晶，郭力.移動智能網(wǎng)[M].北京：北京郵電大學(xué)出版社，2000.

[3]葉奕亮.智能網(wǎng)過載控制的研究[J].廣東通信技術(shù)，2008（12）：45～49.

[4]郭軍雷.淺談通信業(yè)智能網(wǎng)的發(fā)展和趨勢[J].商情，2011（21）：177～177.

[5]張奇支，廖建新，馬旭濤，雷正雄.移動智能網(wǎng)多業(yè)務(wù)環(huán)境下SCP過載控制研究[J].計算機應(yīng)用研究，2006（6）：254～257.

[6]王玉龍，廖建新.移動智能網(wǎng)SCP多業(yè)務(wù)環(huán)境下的過載控制研究[J].電子學(xué)報，2005（10）：1849～1852.

10.3969/j.issn.1001-8972.2012.17.037

張真 性別 男，1980年生，福建福州人，學(xué)歷（本科），工程師，現(xiàn)任職于中國移動福建公司網(wǎng)管中心，從事通信網(wǎng)絡(luò)研究以及維護(hù)工作。