張真

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

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

張真

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

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

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。本文重點(diǎn)是討論如何計(jì)算分析智能網(wǎng)處理能力，以及計(jì)算系統(tǒng)支持CAPS和用戶數(shù)的兩個(gè)公式。

1 基本知識(shí)

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

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

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

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

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

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

2.1 SAU側(cè)分析

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

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

例如：

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

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

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

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

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

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

2.2 SCP側(cè)分析

1）對(duì)話號(hào)與自動(dòng)機(jī)：這里面就不過多說明，與SAU側(cè)相關(guān)，見SAU側(cè)分析。

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

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

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

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

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

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

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

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

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

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

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

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

下面是計(jì)算過程：

每 萬 用 戶 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

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

那么最后公式就如下：

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

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

那么現(xiàn)在我們?cè)倏匆粋€(gè)有趣的現(xiàn)象，根據(jù)公式，為什么平均占用時(shí)長越長，反而可承載的用戶數(shù)越多？

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

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

那么肯定就會(huì)有人想到了，呼叫占用時(shí)長對(duì)于系統(tǒng)多少還是有一點(diǎn)影響，哪怕就是沒有影響，那么也不會(huì)因?yàn)橥ㄔ捳加脮r(shí)間長，反而能夠支持的用戶數(shù)越大呀？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

業(yè)務(wù)115829236459472230

業(yè)務(wù)2376387348937195

然后根據(jù)公式：

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

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

首先用戶數(shù)沒有大的變化，所以不會(huì)因?yàn)橛脩魯?shù)導(dǎo)致CAPS有大的變化。

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

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

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

對(duì)于這個(gè)案例和這個(gè)想法，看到這里大家是否有什么想法？

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

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

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

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

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

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

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

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

舉例子：

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

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

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

平均占用時(shí)長 200s

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

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

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

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

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

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

4 總結(jié)

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

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

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

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

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

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

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

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

10.3969/j.issn.1001-8972.2012.17.037

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