智能網處理能力研究

張真

中國移動福建公司網管中心，福州 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年生，福建福州人，學歷（本科），工程師，現任職于中國移動福建公司網管中心，從事通信網絡研究以及維護工作。