摘要：本文探討了在基于IP技術(shù)的下一代電信網(wǎng)絡(luò)中，是否有必要對VoIP實施基于資源的接納控制。根據(jù)VoIP呼叫的帶寬需求，對照具有接納控制和無阻塞情況的資源規(guī)劃方法，結(jié)合現(xiàn)階段的網(wǎng)絡(luò)資源部署情況，本文得出以下結(jié)論：1)在IP話音專網(wǎng)中，采用接納控制機制可以大大節(jié)約帶寬需求，但在資源充足的條件下可以不必實施接納控制；2)在多業(yè)務(wù)IP骨干網(wǎng)絡(luò)中，由于資源相對充足，而且VoIP業(yè)務(wù)的帶寬比例較小，在采用區(qū)分服務(wù)并對話音業(yè)務(wù)進行最高優(yōu)先級轉(zhuǎn)發(fā)的前提下，不必實施接納控制機制；3)在多業(yè)務(wù)城域網(wǎng)絡(luò)的接入和匯聚結(jié)點，話音業(yè)務(wù)所需帶寬資源所占比例不足5%，盡管接納控制機制可以適當節(jié)約帶寬，改善用戶體驗，但采用靜態(tài)帶寬配置的方法有利于降低設(shè)備和運營成本。

    1 引言

    VoIP，又稱IP電話，指的是在IP網(wǎng)絡(luò)上傳輸語音信號。VoIP已經(jīng)大量部署于企業(yè)網(wǎng)中或者電信運營商骨干網(wǎng)絡(luò)中作為中繼（trunking）技術(shù)以降低話音業(yè)務(wù)承載成本。下一代網(wǎng)絡(luò)（Next-GenerationNetwork,NGN）的目標是構(gòu)建多業(yè)務(wù)網(wǎng)絡(luò)，其基本思想是業(yè)務(wù)與承載分離，從而實現(xiàn)在統(tǒng)一的承載網(wǎng)絡(luò)平臺上支持多種業(yè)務(wù)。盡管現(xiàn)階段仍然存在VoIP的專網(wǎng)，今后的發(fā)展趨勢是VoIP業(yè)務(wù)與其它業(yè)務(wù)共享統(tǒng)一的承載網(wǎng)絡(luò)。VoIP系統(tǒng)也可以分成業(yè)務(wù)與承載兩個層次，其中業(yè)務(wù)層負責與業(yè)務(wù)相關(guān)的邏輯與控制，而承載層負責媒體流的傳送。多業(yè)務(wù)交換論壇（MultiserviceSwitching Forum, MSF ）定義了下一代VoIP網(wǎng)絡(luò)的體系架構(gòu)[1]。

    基于IP技術(shù)的NGN承載網(wǎng)絡(luò)面臨的最大挑戰(zhàn)是服務(wù)質(zhì)量（QualityofService,QoS）保證和安全問題。傳統(tǒng)電信網(wǎng)絡(luò)中的話音通信服務(wù)質(zhì)量為該業(yè)務(wù)確立了很高的標準。為了達到這一標準，VoIP對網(wǎng)絡(luò)的QoS提出了非常嚴格的要求[2]。在傳統(tǒng)的電話網(wǎng)中，接納控制是防止網(wǎng)絡(luò)過載的重要手段，對保證話音業(yè)務(wù)質(zhì)量具有重要作用。根據(jù)ITU-T 對IP多媒體子系統(tǒng)（IP Multimedia Sub-system，IMS）中資源與接納控制功能（RACF）的定義，在NGN中接納控制具有多個方面的功能 [3]：通過網(wǎng)絡(luò)附著控制功能（NASS）檢查基于用戶特征數(shù)據(jù)的的認證過程，基于用戶數(shù)據(jù)結(jié)合運營商特定的策略和資源可用性進行業(yè)務(wù)授權(quán)。檢查資源可用性意味著接納控制功能需要在當前剩余資源條件下驗證資源請求（如帶寬）是否可以被接受；即在業(yè)務(wù)授權(quán)時，不僅需用業(yè)務(wù)層面的接納控制，還需要考慮承載網(wǎng)絡(luò)資源的可用性。盡管業(yè)務(wù)層的控制機制對精細化網(wǎng)絡(luò)運營具有重要意義，但基于資源的接納控制是業(yè)務(wù)開展的基礎(chǔ)。

    接納控制的目的是為了避免網(wǎng)絡(luò)過載造成的QoS下降。隨著寬帶網(wǎng)絡(luò)技術(shù)的進步，網(wǎng)絡(luò)的帶寬資源相對比較充足，且VoIP會話對帶寬的需求相對較小，是否有必要對VoIP實施基于資源的接納控制是NGN承載網(wǎng)建設(shè)的基本問題。本文分析了大規(guī)模VoIP應(yīng)用的資源需求以及當前的IP承載網(wǎng)絡(luò)的資源配置與技術(shù)部署情況，在此基礎(chǔ)上探討了VoIP網(wǎng)絡(luò)中基于資源的接納控制的必要性。

    2 VoIP承載網(wǎng)絡(luò)體系架構(gòu)

    當前，IP網(wǎng)絡(luò)對話音業(yè)務(wù)的承載有兩種應(yīng)用場景。在電信網(wǎng)絡(luò)中，IP網(wǎng)絡(luò)主要用于話音業(yè)務(wù)的長途中繼，接入網(wǎng)絡(luò)和用戶終端保持不變。另外，一些企業(yè)部署了IP-PBX設(shè)備和IP終端，可以實現(xiàn)端到端IP話音通信。但這種情況下，IP接入設(shè)備專用于話音業(yè)務(wù)，且應(yīng)用規(guī)模較小，網(wǎng)絡(luò)的規(guī)劃建設(shè)較為容易。電信網(wǎng)絡(luò)的下一步發(fā)展方向是建設(shè)新的大容量IP/MPLS骨干網(wǎng)絡(luò)，并對接入網(wǎng)絡(luò)和城域網(wǎng)絡(luò)進行IP化改造，構(gòu)建具有三重播放能力的城域網(wǎng)絡(luò)，將話音、視頻和數(shù)據(jù)業(yè)務(wù)融合到統(tǒng)一的IP承載平臺上。

    圖1所示為VoIP系統(tǒng)的承載網(wǎng)絡(luò)架構(gòu)示意圖。圖中的核心網(wǎng)絡(luò)部分由IP/MPLS路由器組成，包括邊緣與核心路由器。核心網(wǎng)絡(luò)連接的可能是經(jīng)過VoIP網(wǎng)關(guān)的傳統(tǒng)電話網(wǎng)，也可以是通過接入集中設(shè)備連接IP接入網(wǎng)絡(luò)。IP接入網(wǎng)絡(luò)通過家庭網(wǎng)關(guān)或其它橋接/路由設(shè)備與終端相連，此時終端為支持SIP的IP電話或軟終端。

    圖1 VoIP承載網(wǎng)絡(luò)體系架構(gòu)示意圖

    2.1VoIP網(wǎng)絡(luò)容量規(guī)劃的影響因素

    網(wǎng)絡(luò)容量規(guī)劃是網(wǎng)絡(luò)建設(shè)的重要環(huán)節(jié)，其目的是通過對資源需求信息的分析得出應(yīng)部署的網(wǎng)絡(luò)設(shè)備與鏈路的容量。相比于傳統(tǒng)的電話網(wǎng)絡(luò)，VoIP的網(wǎng)絡(luò)架構(gòu)發(fā)生了根本的變化：由原來的TDM網(wǎng)絡(luò)變成了分組網(wǎng)絡(luò)，由原來相對專用的網(wǎng)絡(luò)向多業(yè)務(wù)網(wǎng)絡(luò)演進。在多業(yè)務(wù)IP網(wǎng)絡(luò)中，網(wǎng)絡(luò)架構(gòu)，流量混合情況，資源分配機制都對網(wǎng)絡(luò)容量規(guī)劃具有一定的影響。

    傳統(tǒng)電話網(wǎng)絡(luò)的容量規(guī)劃已經(jīng)具有科學(xué)的理論基礎(chǔ)和豐富的實踐經(jīng)驗。由于應(yīng)用時間較短，對VoIP網(wǎng)絡(luò)的容量規(guī)劃還沒有成熟的理論和技術(shù)。值得慶幸的是，VoIP應(yīng)用和傳統(tǒng)的電話業(yè)務(wù)有一定的相似之處，因而可以借鑒傳統(tǒng)電話網(wǎng)絡(luò)規(guī)劃的相關(guān)經(jīng)驗。

    電話業(yè)務(wù)的資源需求信息通常從長期應(yīng)用經(jīng)驗結(jié)合預(yù)測得出。話音業(yè)務(wù)的需求一般用流量矩陣表示，流量矩陣與用戶的數(shù)量及行為模式有關(guān)（訪問網(wǎng)絡(luò)的概率分布和通話時間的概率分布等）。VoIP應(yīng)用的目標是替代傳統(tǒng)話音業(yè)務(wù)，尤其是用戶的業(yè)務(wù)使用模式并沒有改變，因而原來的資源需求估算方法仍然有效。但是由于信號編碼方式和傳輸方式發(fā)生了變化，每個呼叫所需的帶寬隨之變化。

    3 VoIP業(yè)務(wù)的資源需求分析

    VoIP業(yè)務(wù)的資源需求由兩個方面的因素決定：每個呼叫的帶寬需求（平均碼率）和單位時間的呼叫數(shù)量。其中后者由用戶數(shù)量、用戶的活躍程度和用戶的網(wǎng)絡(luò)訪問模式?jīng)Q定。

    3.1每個呼叫的帶寬需求

    VoIP業(yè)務(wù)中，網(wǎng)絡(luò)中傳輸?shù)挠行盘柺菙?shù)字化語音信號，但是為了在IP網(wǎng)絡(luò)中傳輸，需要對原始信號進行包封裝，以便進行選路和實現(xiàn)一些控制功能。因此，每個呼叫所需的帶寬不僅與數(shù)字化方式（壓縮編碼）有關(guān)，還和語音信號的抽樣與打包頻率有關(guān)。

    3.1.1報頭負荷

    根據(jù)IETF的標準建議，通過IP網(wǎng)絡(luò)傳輸語音信號樣本需要增加三個額外的報頭，每個報頭對應(yīng)一個網(wǎng)絡(luò)層次，即IP，UDP和RTP[4]。IPv4的報頭長20個字節(jié)（8bit），UDP報頭為8字節(jié)，RTP報頭為12字節(jié)。圖2所示為語音信號的封裝格式。

    圖2 VoIP分組封裝格式

    從圖2可見，報頭信息的總長度為40字節(jié)，即320bit。每次語音樣本發(fā)送時，這些報頭也需要發(fā)送一次。因此，報頭信息所占用的額外帶寬與語音樣本的發(fā)送頻率有關(guān)。

    3.1.2 語音信號封裝頻率

    語音信號的封裝頻率指的是每秒鐘封裝發(fā)送的語音樣本數(shù)量。例如，一個語音樣本表示20毫秒的語音信號，則每秒鐘需要進行50次抽樣，即語音信號封裝頻率為50。語音信號抽樣頻率的選擇是語音質(zhì)量與帶寬需求的折衷。因為40字節(jié)的封裝報頭保持不變，樣本越小則所需帶寬越多。然而，當樣本長度增加時，系統(tǒng)的總時延隨之增加，分組丟失帶來的信號損失也隨之增大。

    IETFRFC1889中有一個例子說明語音樣本長度為20ms，但該文本并沒有將該值作為標準建議。對這個問題還沒有標準的答案，參考一般做法，通常取20ms，即每秒封裝發(fā)送50個樣本。這種情況下，每個樣本帶有320bit的IP/UDP/RTP報頭，因此，每秒鐘需發(fā)送報頭16Kbits。

    3.1.3 編碼算法的影響

    語音信號編碼實現(xiàn)語音信號的數(shù)字化，通常還具有一定的壓縮功能。語音信號通常采用恒定比特率編碼方式，相對于視頻信號而言其碼率較低。由于采用的編碼算法不同，其輸出碼流的速率和回放后得到語音質(zhì)量也不一樣。ITU-T的G系列推薦標準中包括了多種話音信號（壓縮）編碼方法。其編碼算法和速率見表1。

    表1 語音信號編碼速率與IP傳輸速率

    前面提到，如果樣本時間為20ms，則每秒需發(fā)送的報頭約為16Kbits。當樣本長度小于20ms時，可以將幾個抽樣打入一個分組中發(fā)送，這個經(jīng)驗值仍然有效。但當樣本長度大于20ms時，通常將一個樣本封裝到一個分組中，因而封裝所需的帶寬消耗將小于16Kbits。以表1中G.723.1編碼算法為例，由于樣本長度為30ms，因而分組封裝頻率為33.3，其消耗帶寬約為320x33.3=10.67Kbits。

    每種編碼算法對應(yīng)不同的復(fù)雜度，時延特征和語音回放質(zhì)量。G.729(A)和G.723.1被認為有望成為VoIP應(yīng)用主流的算法。

    表1只考慮了IP層的封裝，當IP分組在鏈路上傳輸時，通常還要經(jīng)過鏈路層協(xié)議的封裝。以太網(wǎng)正逐漸成為傳輸技術(shù)的主流，以太成幀也是開銷較大的鏈路層技術(shù)，包括差錯控制編碼一般需要16個字節(jié)。仍然假定每秒50次的封裝頻率，則需要增加開銷7.2kbps。如采用以太傳輸，則每個G.711語音會話所需帶寬為87.2kps，而每個G.729(A)語音會話所需事寬為31.2kps。

    3.1.4報頭壓縮

    對一個典型的8kbps的壓縮機制，報頭的負荷通常是16kbps(是凈荷的2倍)，因此有必要采取適當?shù)拇胧p少報頭的傳送開銷?，F(xiàn)在已經(jīng)存在一些方法，如報頭壓縮、RTP利用等[5]。通過采用這些方法，可以使用報頭的負擔降至2或4字節(jié)，大大提高了封裝的效率。

    4 VoIP網(wǎng)絡(luò)容量規(guī)劃方法

    在電路網(wǎng)絡(luò)中，對于給定的流量需求，需要估計出正常工作時所需的線路數(shù)量（鏈路容量）。為了防止偶爾出現(xiàn)的異常突發(fā)導(dǎo)致的線路數(shù)量不足，網(wǎng)絡(luò)支持呼叫接納控制功能。線路數(shù)量的估計通常根據(jù)一定的模型，對于話音業(yè)務(wù)，常見的兩種鏈路容量估計模型是ErlangB和Engset公式[6]。這兩個公式描述了呼叫強度、線路數(shù)量及呼叫阻塞率之間的關(guān)系。工程上，根據(jù)流量實際需求和可以接受的呼叫阻塞率，可以通過查找由公式推算出的表格得到所需的網(wǎng)絡(luò)容量。

    ErlangB或Engset公式的使用需要事先知道網(wǎng)絡(luò)的流量矩陣，即各條鏈路的資源需求。然而，在有些情況下，比如新建的網(wǎng)絡(luò)，流量矩陣通常難以準確得到，因而也無法根據(jù)相關(guān)模型進行資源規(guī)劃。為了保證通信的質(zhì)量，一種可行的方法是按照最壞的情況規(guī)劃和部署網(wǎng)絡(luò)資源。顯然，采用這種方法，大多數(shù)情況下會有一定的資源處于閑置狀態(tài)。

    假定VoIP流量與其它應(yīng)用流量隔離（VoIP專網(wǎng)或采用區(qū)分服務(wù)機制實現(xiàn)流量隔離），VoIP會話具有恒定比特率的特性（不考慮靜音壓縮），我們可以將電路網(wǎng)絡(luò)中的網(wǎng)絡(luò)規(guī)劃方法引入到VoIP網(wǎng)絡(luò)中?？紤]分組網(wǎng)絡(luò)的無連接特性，資源配置還與流量的路徑選擇有關(guān)，我們假定VoIP網(wǎng)絡(luò)采用最短路徑路由算法，沒有引入流量工程機制。

    4.1允許呼叫阻塞的網(wǎng)絡(luò)資源規(guī)劃方法

    在ErlangB和Engset模型中，都包括了呼叫阻塞率參數(shù)，即鏈路容量規(guī)劃對應(yīng)于一定的呼叫阻塞。

    根據(jù)VoIP呼叫到達時間間隔的指數(shù)分布特征，我們用Erlang公式描述網(wǎng)絡(luò)資源的需求。參考傳統(tǒng)電話網(wǎng)，假定在核心網(wǎng)絡(luò)中每對邊緣路由器之間建立流量中繼管道用于傳送來自相應(yīng)電話網(wǎng)關(guān)的呼叫，用話務(wù)量α表示每對網(wǎng)關(guān)之間的電話負荷的大小。α可通過忙時業(yè)務(wù)量（BHT，BusyHourTraffic）和平均呼叫保持時間（MCD，Mean Call Duration，單位秒）來計算： ，其單位為Erlang(Erl)。1Erlang表示1個小時的呼叫持續(xù)時間。

    用和 分別表示流量管道容量和每個呼叫所需帶寬，則流量管道可同時傳送的呼叫數(shù)目可表示為 。記為呼叫阻塞的概率，則Erlang B公式可以表示為[6]：

            (1)

    上式中GoS（GradeofService）表示服務(wù)等級，即最大可容忍的阻塞概率。公式（1）表示當鏈路話務(wù)量為α，流量管道已經(jīng)承載了個呼叫時，兩個網(wǎng)關(guān)之間的接納控制機制拒絕呼叫請求的概率。公式（1）也表示出網(wǎng)絡(luò)容量和服務(wù)等級之間存在的折衷關(guān)系。給定網(wǎng)關(guān)間的流量矩陣，VoIP服務(wù)提供商或網(wǎng)絡(luò)運營商可通過擴大為VoIP業(yè)務(wù)配置的網(wǎng)絡(luò)容量以獲得更好的服務(wù)等級。

    當呼叫源的數(shù)量（用戶）與線路數(shù)的比值大于10時，采用ErlangB模型會過高地估計所需線路數(shù)量，此時用Engset模型可以更加準確地對所需容量進行規(guī)劃。與ErlangB模型不同的是，Engset模型不僅需要考慮忙時業(yè)務(wù)量和阻塞概率，還需要參考呼叫源的數(shù)量。有了這三個參數(shù)后，同樣可以通過查找相應(yīng)的表格獲得所需的線路數(shù)量。

    4.2無阻塞資源規(guī)劃方法

    當網(wǎng)絡(luò)的流量矩陣未知時，為保證良好的通信質(zhì)量，容量配置必須考慮最壞情況下的資源需求，即每個網(wǎng)關(guān)支持最多呼叫的流量，且可能任意分布到其他網(wǎng)關(guān)。按照這種情況對每條鏈路進行容量配置則不會發(fā)生呼叫阻塞的情形，電話網(wǎng)關(guān)也無需進行接納控制。下面通過一個簡單的示例來說明這種方法[7]。

    圖3 VoIP資源規(guī)劃網(wǎng)絡(luò)拓撲示例

    網(wǎng)絡(luò)拓撲如圖3（a）所示，以鏈路A-C為例，將通過鏈路A-C的端到端的呼叫分別表示為a,b,c,d，如圖3(b)所示，Ni _{(i = 1, 2, …, 6)} 表示第i個網(wǎng)關(guān)可以支持的最大呼叫數(shù)量，記通過鏈路A-C的最大呼叫數(shù)量為m, 則a, b, c, d和m滿足以下關(guān)系：

    Maximize:m = a + b + c + d;

    _{Subject to     (2)}

    公式（2）是一個線性規(guī)劃問題，m的值可以通過線性規(guī)劃工具，如CPLEX[8]計算得到。

    4.3接納控制機制的資源收益分析

    下面我們將以相同的網(wǎng)絡(luò)拓撲結(jié)構(gòu)分別計算兩種資源配置方法所需的資源，從而可以得出采用接納控制可以獲得的資源收益。網(wǎng)絡(luò)拓撲仍如圖3所示。

    當流量矩陣已知時，我們可以在任意網(wǎng)關(guān)（邊緣路由器）之間建立邏輯連接，在最短路徑上建立流量管道傳送電話業(yè)務(wù)。根據(jù)公式（1）配置的流量管道容量，必須能夠支持流量矩陣中所說明的話務(wù)量。每條鏈路為VoIP業(yè)務(wù)配置的容量等于所有經(jīng)由此鏈路的管道帶寬的總和。以鏈路A-C為例，共有4條流量管道通過，分別為N1 N4，N1N5，N6N4以及N2N5。假設(shè)其管道帶寬分別用 ， ， 和 表示。則鏈路A-C需要配置的容量為： = + + +

    假定N_i=1000，且話務(wù)量均勻的分布至其他電話網(wǎng)關(guān)，且電話網(wǎng)關(guān)的每條出中繼線總是處于忙狀態(tài)，則每對網(wǎng)關(guān)之間的話務(wù)量為200Erlang。標準服務(wù)等級為0.002，即10％的過載不會致使呼叫損失的比例超過0.01。根據(jù)Erlang B公式，查閱Erlang呼損表，當話務(wù)量α = 200，GoS = 0.002時， = 233，則經(jīng)過鏈路A-C的呼叫數(shù)量為233*4 = 932，所需帶寬為 = 932＊ 。

    這種方法必須精確地估算網(wǎng)絡(luò)的流量矩陣，且必須定期地更新VoIP業(yè)務(wù)的網(wǎng)絡(luò)配置，以適應(yīng)流量的動態(tài)變化。同時，電話網(wǎng)關(guān)需實施接納控制機制，確保每條流量管道同一時間內(nèi)最多只能傳送個呼叫。

    在上例中，同樣假定為1000，對公式（2）進行計算可得m= 2000，即對于圖3(a)中鏈路A-C而言，根據(jù)最壞情況配置的鏈路帶寬是允許一定呼叫損失所需帶寬的2倍多。當然，上面的約束條件只考慮了網(wǎng)絡(luò)中的一條鏈路，而且在實際網(wǎng)絡(luò)中，約束條件更加復(fù)雜，而且任意兩點之間的業(yè)務(wù)量也有一定的具體的約束。

    5 VoIP承載網(wǎng)絡(luò)資源配備情況

    由于采用的技術(shù)不同，承載網(wǎng)絡(luò)的資源配備在核心網(wǎng)和接入/匯聚網(wǎng)絡(luò)差別較大。當前的IP/MPLS核心網(wǎng)絡(luò)中，普遍采用大容量高速路由器和高速光纖鏈路，因而帶寬資源相對充足。在新建的多業(yè)務(wù)網(wǎng)絡(luò)中，區(qū)分服務(wù)的采用可以有效地避免高突發(fā)的數(shù)據(jù)業(yè)務(wù)對其它業(yè)務(wù)的沖擊，因而發(fā)生擁塞的機率較小。以中國電信的下一代網(wǎng)絡(luò)CN2為例，其設(shè)計原則是在保證網(wǎng)絡(luò)結(jié)構(gòu)層次化的同時減少網(wǎng)絡(luò)端到端的路由跳數(shù)，以降低成本并提高網(wǎng)絡(luò)質(zhì)量。整個網(wǎng)絡(luò)采用三層結(jié)構(gòu)，分為核心層、匯接層和邊緣層。核心路由器的容量高達640G，支持高密度的10G端口；其它層次的路由器也具有很高的容量，并且支持高速率端口。

    CN2中路由器之間的互連采用IPoverDWDM技術(shù)，鏈路帶寬設(shè)計原則是采用輕載方式提供QoS保證，核心結(jié)點間的鏈路帶寬高達20G~ 60G bps，鏈路負載一般在25-50%之間。同時，在區(qū)分服務(wù)配置中，VoIP業(yè)務(wù)具有最高的優(yōu)先級，可以使用全部的鏈路帶寬，只有未使用的剩余帶寬供其他低優(yōu)先級的業(yè)務(wù)使用。

    圖4所示為支持三重播放（TriplePlay）業(yè)務(wù)的城域網(wǎng)架構(gòu)。在城域網(wǎng)架構(gòu)中，一般包括接入復(fù)用器（DSLAM）和IP邊緣路由器兩個層次；接入復(fù)用器連接多個家庭網(wǎng)絡(luò)，IP邊緣路由器是連接核心網(wǎng)的入口。在用戶密度較高的區(qū)域，城域網(wǎng)DSLAM和邊緣路由器之間通常還包括流量匯聚設(shè)備，現(xiàn)階段Ethernet是被廣泛認可的高速匯聚技術(shù)。DSLAM和匯聚結(jié)點的上連鏈路通常采用GE和10GE接口。

    圖4 支持三重播放的IP城域/接入網(wǎng)絡(luò)

    假定每個DSLAM連接2000個用戶，話音業(yè)務(wù)的并發(fā)率為50%，若每個呼叫所需帶寬為50kbps，則話音業(yè)務(wù)所需的平均帶寬約為50Mbps。若DSLAM上連鏈路的接口為GE，則話音業(yè)務(wù)所占帶寬約為5%。在更高一層的網(wǎng)絡(luò)結(jié)點，如匯聚和核心網(wǎng)絡(luò)，由于復(fù)用層次更高，總的用戶并發(fā)率進一步下降，話音業(yè)務(wù)所占帶寬比例將進一步下降。在中國電信的CN2中，話音業(yè)務(wù)的規(guī)劃帶寬也不足總帶寬的5%。

    5.1資源接納控制機制的必要性討論

    對于IP語音專網(wǎng)，和無阻塞情況資源配置方法相比，采用接納控制可以節(jié)約較多帶寬。如網(wǎng)絡(luò)資源有限，接納控制機制可以改善用戶的使用體驗；如網(wǎng)絡(luò)資源充足，則無需在業(yè)務(wù)授權(quán)時考慮資源可用狀況。

    對于多業(yè)務(wù)核心網(wǎng)絡(luò)，由于網(wǎng)絡(luò)容量配置非常充足，且話音業(yè)務(wù)具有最高資源使用優(yōu)先級，完全可以滿足最壞情況下的資源需求，因此沒有必要部署接納控制，也不必實時地跟蹤網(wǎng)絡(luò)流量矩陣的變化。

    從上面的分析可見，相對于接入復(fù)用與匯聚設(shè)備的容量，話音業(yè)務(wù)所消耗的資源非常有限。在接入復(fù)用和匯聚設(shè)備處靜態(tài)分配一定的超量帶寬，保證話音信號無阻塞是一種更加簡單可行的方法，可以避免實施接納控制機制帶來的設(shè)備更新。

    結(jié)論

    用VoIP替代傳統(tǒng)的電話通信技術(shù)已經(jīng)得到廣泛的認同并在逐步實施，在此過程中，如何達到傳統(tǒng)話音業(yè)務(wù)相當?shù)姆?wù)質(zhì)量是一個關(guān)鍵性問題。呼叫接納控制是傳統(tǒng)電話網(wǎng)絡(luò)的基本技術(shù)，它可以在網(wǎng)絡(luò)通信資源不足時拒絕新的呼叫請求。在下一代基于IP技術(shù)的電信網(wǎng)絡(luò)中，話音業(yè)務(wù)的帶寬需求和承載網(wǎng)絡(luò)都發(fā)生了很大的變化，是否或如何對VoIP實施基于資源的接納控制成為一個新的問題。本文分析了VoIP呼叫的帶寬需求，以及具有接納控制和最壞情況的資源規(guī)劃方法，結(jié)合現(xiàn)階段的網(wǎng)絡(luò)資源部署情況，我們得出以下結(jié)論：1)在IP話音專網(wǎng)中，采用接納控制機制可以大大節(jié)約帶寬需求，但在網(wǎng)絡(luò)資源充足的條件下可以不必實施接納控制；2)在多業(yè)務(wù)IP骨干網(wǎng)絡(luò)中，由于資源相對充足，而且VoIP業(yè)務(wù)所需的帶寬比例較小，在采用區(qū)分服務(wù)并對話音業(yè)務(wù)進行最高優(yōu)先級轉(zhuǎn)發(fā)的前提下，不必實施接納控制機制；3)在多業(yè)務(wù)城域網(wǎng)絡(luò)的接入和匯聚結(jié)點，話音業(yè)務(wù)所需帶寬資源所占比例不足5%，盡管接納控制機制可以適當節(jié)約帶寬，改善用戶體驗，但采用靜態(tài)配置帶寬的方法有利于降低設(shè)備和運營成本。

    參考文獻

    [1] Paul Drew and Chris Gallon, Next-Generation VoIP Network Architecture, MSF Technical Report, March, 2003. http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-001-FINAL.pdf

    [2] ITU-T recommendation Y.1541, Network performance objectives for IP-based services, May 2002

    [3] Keith Knightson, Naotaka Morita, Thomas Towle. NGN Architecture: Generic Principles,Functional Architecture, and Implementation, IEEE Comm. Magazine, 2005. 43(10): 49-56

    [4] Bur Goode, Voice over Internet Protocol (VoIP), Proc. of the IEEE, Sept. 2002. 90(9): 1495~1517

    [5] Tunneling multiplexed Compressed RTP ("TCRTP"), draft-ietf-avt-tcrtp-04.txt, IETF, July 2001

    [6] Telecom Traffic Online, http://www.erlang.com/

    [7] Van Hoey, G. Van den Bosch, S. de La Vallee-Poussin, P, et al, Capacity planning strategies for voice-over-IP traffic in the corenetwork, 2001

    [8] CPLEX, http://www.ilog.com/products/cplex/