圖 11.1 UMTS 各類服務之特性
傳統的公眾通訊網路，尤其是語音電話網路，不但非常可靠， 而且品質非常穩定，但是某些IP網路（例如Internet）不但可靠度遠遠不及 傳統網路，在其上執行的即時性訊務（如VoIP）之品質也非常不穩定， 本章將討論All-IP網路上的應用之品質問題及改善之道。 因為VoIP將為All-IP網路上比重最大的即時性應用，本章多處將以 VoIP 做為範例說明。
| 頻寬需求 (未壓縮) | 64kbps
| 對 Delay 之容忍度
| < (300-400)ms
| 對 Jitter 之容忍度
|
對jitter 敏感，僅可容許低程度之 jitter，<= 50ms
|
對音訊遺失之容忍度
| 可容許某種程度之音訊遺失，<= 3%
| |
|---|
使用者在交談中，如果有小部分的音訊丟失，並不一定會影響通話內容
的瞭解，如果音訊丟失影響通話的清晰度，通話者通常可以重複小部分
通話，因此某種程度的音訊遺失是可以容忍的。
反之，使用者卻對抖動卻極為敏感，微小之抖動都可被使用者察覺。
在IP 網路中，封包到達目的地的時間長短不一，稱為jitter(抖動)，
接收端接到語音封包之後，如果直接解碼成音訊送給使用者的話，
語音就也隨著封包傳遞時間的抖動而跟者抖動。如果將封包先儲存在
一個dejitter buffer 中，排序，再依既定步調逐一解碼送出音訊，
如此可以很容易的降低語音的 jitter，所增加的是一些延遲時間。
使用者可容許的延遲時間約在 300ms 至 400ms之間。VoIP
系統最大的挑戰即在降低封包的遺失以及將延遲時間控制在這個範圍之下。
維持即時性訊務品質的首要工作，當然是提供足夠的end-to-end頻寬。
但很多從事VoIP的初學者常有一個錯誤的認知:
只要能保證足夠的頻寬就能解決封包延遲問題。
其實這個論點並不完全正確。語音訊號在一個VoIP系統裡所遭受到的延遲時間
包含幾個重要的延遲因素，而VoIP 運用在國際長途電話時，因距離太長
所導致的延遲時間(propagation delay time)將300ms這個可容忍的
延遲時間佔有一大半，使得剩下的可容忍延遲時間大為縮小，
導致其他因素的變動都對聲音的品質產生重大損害。
就如同感冒導致身體抵抗力降低而引發其他併發症一般。
我們首先說明一通電話從發話端到達收話端在各階段所消耗的延遲時間。
在傳送或接收封包時，封包的大小也會佔用不等的傳送時間，serialization
dealy 的定義是接收端接到封包的第一個bit到最後一個bit進來所耗時間。
封包的長度與packetization time 息息相關，
如果採取具壓縮功能的編碼時，在壓縮的過程中，因為必須先行進行sampling
取得整個frame 的語音資訊才能進行壓縮，會多出一個frame 的延遲時間，所以
sampling frame 不能太長，以免增加太多延遲時間。但是
IP封包的 header 為40bytes，所承載的資料如果太少會浪費寶貴的頻寬，
（若以壓縮比為8:1的編碼而言，20ms 的音訊會產生 20 bytes 資料，只有
IP header 的一半），因此 sampling frame 不能太短，成為兩難。
在衡量頻寬使用效率與延遲時間之後，最常見的 CODEC time 都設法控制在
20ms 與 30ms之間。
因為 CODEC 所耗用時間佔了 packetization time 及 unpacketization
time 的絕大部分，所以通常以 CODEC time 來估計
packetization time 及 unpacketization time。
總而言之，長距離通訊由於 propagation delay time 耗費
太長的延遲時間，使得 VoIP 通訊的品質變得極為脆弱。
除了網路頻寬之外，仍有許多可能導致延遲的因素必須控制，方能提高
VoIP品質的穩定度。
以上分析之法也適用於其他種類的即時性訊務，例如IPTV。
此種簡單的服務品質保證方式非常有效，長期以來保證了
公眾電信網路超高的服務品質。可是面對未來花樣繁多的網路服務需求，
此種方式缺乏彈性，也缺乏效率。舉例而言，一個一般的電話用戶接
在用戶迴路上只能使用頻寬為64kbps的一般電話，不能使用高品質影像電話。
如果要使用高品質影像電話則必須提高用戶迴路的規格，但昂貴的
用戶迴路的使用率雖然極低，但因該迴路綁住資源之故，使用者必須
持續付費(固定的月租費)，極為浪費。All-IP 網路對於品質管理必須能做到
彈性使用，彈性付費，方能顯出優勢。
All-IP 網路如果要對於個別訊務提供品質之保證，只要賦予足夠
之頻寬，並加上一些輔助措施，並不困難。但如果能從
整個網路的觀點做全面性的資源調度，將可以提高資源的使用效率，且可避免
不必要的資源競爭與衝突。
例如，若封包傳輸路徑沒有適度的分散而集中於某些瓶頸鏈路時，
會造成不必要的網路壅塞，增加延遲時間，
導致有充裕的頻寬卻發生網路壅塞的現像，
如能從整體的觀點做適當的安排，可以避免此種情況，
因此，即使網路頻寬過剩，我們仍需積極研究QoS各種機制方能應付未來
的挑戰。
在假設網路頻寬餘裕不高或頻寬不足的條件下，
All-IP 網路品質管理之目標在於以最高的資源運用效率達到
使用者或網路營運者的品質目標。
封包在 IP network 上傳遞難免遺失，某些應用，例如 FTP, Email 等，都會
採用 TCP 這類可保證封包傳輸的通訊協定。而VoIP這種應用
可容許遺失部分語音封包，而且對延遲時間的要求較為嚴格，
因此都採用不保證封包遞送而比較快速的 UDP 傳輸層協定。
CODEC 採用的sampling frame 之大小，決定了CODEC 的延遲時間，
如果頻寬充裕時，可以採用較短的 sampling frame，以減少延遲時間。
Dejitter buffer 是儲存一段陸續到達接收端的音訊封包再依固定
步調送出音訊，如此可以降低 jitter，但增加了延遲時間。
Jitter 與延遲時間兩者是蹺蹺板的兩端，使用者可衡量自身需求，決定
偏向哪一邊。
經過多年來的研究，已有許多降低封包遺失的方法被提出，例如:
如果一個封包的遺失會影響到另一個封包的解碼時，稱為
Packet Dependency， 例如一個英文語詞被放在兩個封包內時，
遺失一個封包，會使得另一個封包的內涵難以解讀，變成無用封包。
有些編碼方式中，例如DPCM (Differential Pulse Code Modulation)，
如果遺失部分資訊，會導致一段語音碼無法解碼。
引起 packet dependency 的因素不止一種，
盡量減低 packet dependency 可以降低封包遺失之影響，iLBC 編碼標準
比G.729優越之處即在於 iLBC 處理 packet dependency 的能力較強。
我們用一個故事比擬品質管理的作用。
如同一群學生一起享用標準便當，便當裡有豐富的菜色，
但是每個人喜好的口味皆不同，儘管便當菜色豐富，但仍無法
讓所有人都非常滿意。如果大家互相交換便當內容，將不喜歡
的菜拿出來與他人交換自己喜歡的菜，如此可以在不增加費用的情況下，
提高整體滿意度。
整體服務品質管理的首要工作是根據使用者需求訂出品質管理目標。
由於各種使用者之需求各自不同，訂定目標函數也是挑戰性極高的
工作，當目標函數定出來之後，有很多最佳化演算法，或最佳化工具
可供使用。（見過太多初學者在沒有訂出適當的目標函數之前就急著
提出解答，就如同沒有舵的船一般，費力划船盡是虛功。）
使用者、網路營運者、研究者對於品質的定義與著眼點俱皆不同，表11.2是
使用者與網路營運者對服務品質之各種不同觀點:
11.2 IP網路傳遞特性與即時性訊務品質之關係
與電路交換網路(Circuit-Switched Network)相較，封包在封包交換網路
(Packet-Switched Network) 上
傳遞，有較長的傳遞時間，較高的抖動率，以及較高的封包遺失率。
這幾項特性對即時性訊務的品質產生極大的威脅。前已提及，抖動率其實很容易
使用dejitter buffer降低，而所付出的代價是延遲時間的增加。
剩下的問題是在維持一定的封包遺失率下盡量降低延遲時間。
網路頻寬不足時，所增加的是 link queueing time，適當的配置頻寬可以降低
link queueing time。
選擇適當的路徑可以減少所經的節點數以及路徑長度，因此可以降低
processing time 及 propagation delay time。VoIP的封包通常不大，因此
serialization delay time 可以忽略不計。
而初學者最容易忽略的兩項延遲因素是 CODEC 所需時間 及
propagation delay time。
CODEC 編碼/解碼時間
在傳統電話網路上，都是以 G.711 標準將語音訊號數位化成流量為64kbps的
數位訊號，未經過壓縮直接送進網路，所耗費的時間極短。但在 VoIP
網路上，語音訊號必須封裝成封包而且可能會經過壓縮以節省頻寬，因而會產生
額外的延遲時間。
Propagation Delay Time
電磁信號在導線中或光信號在光纖裡的傳遞速度，接近真空中的光速。
封包在 VoIP 網路中傳遞，其所經過的鏈結總長度必長於發話端與受話端的
直線距離，因此語音封包的 propagation delay time 不可能低於光線從
發話端傳遞到受話端所需時間。舉例而言，無論頻寬多高，
一個封包從台灣送至美國東岸其所需 propagation delay time 一定超過
70ms，再加上 CODEC time
(假設使用有壓縮功能的 CODEC 標準)及其他必要時間，
最終的封包傳輸時間的一定在 100ms 以上。只要封包傳輸路徑
稍微曲折，或網路效能稍微降低，VoIP 的品質就會受損。
11.3 保證即時訊務服務品質之方法
11.3.1 傳統電路交換式網路之服務品質保證方法
傳統電路交換網路保證服務品質的方法
是以保留資源(頻寬)的方式為之。以電話為例，當一通電話接通之前，
電話網路會先將資源明確保留下來，加上不需進行
packetization 及 unpacketization等動作，因而 propagation delay time
幾乎就等於總延遲時間，因此通話品質得以
獲得保證。除了電話之外，其他的服務也是以相同方式為之。
11.3.2 All-IP網路整體服務品質管理問題
All-IP 網路受限於封包交換網路的特性，難以提供比擬電路交換網路的品質，
其在品質管理方面的優勢在於資源調配上可以提供較高的彈性。
11.3.3 單一VoIP訊務的品質保證
我們首先探討保證單一VoIP訊務品質的技術。
以下是幾項可以採取的措失：
(A)提供足夠的頻寬
(B)選擇符合品質要求的傳送路徑(QoS-aware Routing)
(C)使用 UDP 等傳輸層協定以減少傳輸時間
(D)降低 CODEC 時間延遲
(E)控制 Dejitter Buffer 的時間延遲
(F)彌補封包遺失之影響 (Lost Packet Concealment)
(G)降低封包遺失之影響 (Packet Dependency Reduction)
11.3.4 整體服務品質管理
瞭解單一VoIP訊務品質保證的技術，有助於瞭解
整體服務品質的管理技術。一個網路營運者必須盡力調度有限的資源
盡力提高顧客總體滿意度，而不能僅滿足於個別訊務的滿意度。
在資源有限的情況下，不可能對所有訊務都提供最高程度的
滿意度，而必須有所取捨，在用戶需求各不相同的情況下，
提供一致的品質保證並非最佳的資源管理策略。通常
差別化的服務併同分級收費是比較好的選擇。
11.3.4.1 服務品質需求與品質管理目標
| 使用者 |
以最低價格獲得最高品質之服務
(Request the best quality at the lowest price )
以最低價格獲得期望的品質之服務
| (Request the demanded quality at the lowerest price )
以合理價格獲得最高品質之服務
| (Request the best quality at the acceptable price )
以最低價格獲得可接受的品質之服務
| (Request the torlerable quality at the lowest price) 網路營運者
|
以合理價格提供最高品質之服務
| (Offer the best quality at the acceptable price )
以最高價格提供實用者期望之品質之服務
| (Offer the acceptable quality at the highest price)
以最低價格提供最低可接受品質之服務
| (Offer the tolerable quality at the lowest price) |
|---|
面對差異極大的品質要求，作為研究者應當以何種品質需求作為追求的目標?
考慮到品質管理系統的直接使用者是網路營運者，
而網路營運者各有其特有的營運目標，
研究者不應對品質目標預設立場，而應提供彈性的品質管理系統，讓直接
使用者（即網路營運者)根據自身的營運目標調整其品質管理系統，進而服務
最終使用者。
11.3.4.2 應用服務之分類與品質要求之分析
UMTS 組織將網路上風行的應用依時效與品質需求概略分為四大類，而
這四類服務的特性以及對品質的要求各不相同，表11.3及圖11.1是簡要分析：
| 類別 | 應用例 | Delay Sensitivity | Jitter Sensitivity | Packet Loss Sensitivity
| Conversational | 語音服務，影像電話
| High | High | Low
| Streaming | VoD | Medium | High | Low
| Interactive | WWW, Telnet | Medium | Low | High
| Background | E-Mail | Low | no | High
| |
|---|
圖 11.1 UMTS 各類服務之特性
Conversational class services 主要用來支援人類的雙向溝通， 根據人類感官之經驗歸納，此種服務對 delay time 與 jitter 相當敏感，使用者在 delay time 超過 300 ms 時，就難以忍受 其通話品質(ITU-t G.114 標準對VoIP 的delay time 要求是150ms)。 相反的，對於 packet loss 則較可忍受。
Streaming class service 則要求持續穩定的 packet flow， 因此對 jitter 相當敏感，反之，對 delay time 則有較高的容忍度。 在傳送影音資料時，對 packet loss 也可忍受。
Interactive class 與 Background class 都屬於 data communication 的服務，可容忍較長的資料傳送時間，但是要求精準的資料傳送，因此 幾乎無法忍受資料的 loss.
面對品質要求即時化，多樣化且負載極高的 All-IP 網路，其品質管理複雜度 遠比單純的語音或數據網路複雜。猶如管理大小汽車與機車爭道的 一般街道遠比車種單純的高速公路複雜一樣，All-IP 網路上的品質管理是一大技術挑戰。 網路管理系統必須提供適當的資源管理機制管理不同服務的資源運用， 並讓管理者可輕易的調校網路，使得各類服務都可以獲得適當的品質服務。
圖 11.2 異質性網路組成新世代網路
網路異質性使得一個呼叫(call)/服務要求(request)可能橫跨數個特性不同 的網路，例如由一個3G 手機連到3G無線接取網路，接到核心網路，再連到一個無線區域網路(Wi-Fi)。 這些不同網路有不同的頻寬，不同的通訊協定，不同的品質機制或參數， 在網路介面上產生銜接的困難，我們稱之為 impedance mismatch。 例如，一個高頻寬的 Wi-Fi 接到一個低頻寬的 GPRS 網路時，一個呼叫 (call) 無法維持高頻寬的服務，必須降低頻寬以配合 GPRS 的速率。 又如某一段網域用DiffServ 作為品質管理機制，每一個呼叫都應該 根據其品質要求被適當歸類以資提供適當的資源，但另一個鄰接 的網路卻未提供DiffServ服務，如此DiffServ網路無足夠資訊將承接的呼叫 歸類，導致DiffServ 無法順利運作。此種 mismatch 稱為水平impedance mismatch。
除了水平的impedance mismatch 之外，另有垂直 impedance mismatch， 例如，DiffServ 網域的分類與下層網路（例如 ATM) 就大不相同，兩者之間沒有一定的對應關係，難以用自動方式定義兩者之間 的對應關係，以致網路管理者必須 根據實際情況將高層的 DiffServ 參數以個案方式 對應到下層的 ATM (或其他種類）網路，造成網路管理的極大障礙。 因此，有必要積極投入研究，建立系統化自動化的管理方式克服各網域 之間或各種通訊協定之間的 impedance mismatch。
在All-IP 網路上管理資源，可以依需求的急迫性訂定不同價格， 並依價格訂定使用資源的優先度。如此，急迫性的需求可以獲得 優先的服務，而非急迫性的需求則可用較低的價格獲得次優先的服務， 如此，可以提高整體滿意度。
為了在IP網路上提供具品質保證的服務，IETF (Internet Engineering Task Force) 制定了IntServ (Integrated Service)[31]與DiffServ (Differentiated Service)兩種機制[32]， 這兩種機制各有優缺點， 引發了一些後續的研究試圖提供更有效的品質管理機制，略述於本章。
此外，如果訊務必須跨越不同網路時，不同網路間 為了保證品質所需的協調聯絡也過於複雜，大幅增加建置成本。
一個DiffServ Domain是由許多個提供DiffServ服務執行相同PHB且相連的 節點所組成，這些節點可分為edge router和core router。 如圖11.3，X domain為一沒有DiffServ功能的網域，Y 和 Z domain為各別的兩個 DiffServ網域， 兩者可能執行不同的PHB，對同類別的資料可有不同的標誌(DSCP)。 與其他網域連結的點統稱為edge router，此又分為Ingress和 Egress， 分別表示訊務進入網域和離開網域的節點，而沒有與其他domain相連接的節點稱為 core router。
DiffServ中依訊務型態不同定義了幾種基本的服務種類：
DiffServ架構的設計主要有兩個功能來管理和控制網路上的資料傳遞：
綜觀以上兩種服務品質保證之方法，若以IntServ方法來提供服務品質保證， 則服務網域會因為控制訊息數量成長快速而受到限制，並且RSVP路徑尋找方法 所產生的訊務量(RSVP message)也會導致整個網路要負擔額外增加流量。反之， 若採用DiffServ方法來提供服務品質保證，所有的訊務被歸納為三個不同的 QoS服務等級，只在每個core router提供相對的品質保證，所以在純粹DiffServ Domain環境下，我們無法針對每個訊務提供真正的end-to-end QoS。 IETF正嘗試另定標準融合IntServ與DiffServ兩種機制。
AQUILA (Adaptive Resource Control for QoS Using an IP-based Layered Architecture)是歐洲另一個研究網路服務品質的計畫，主要目標是想在Internet 上設計一個能支持服務品質的架構[3,6]。類似TEQUILA計畫， AQUILA仍在進行當中，許多細部的功能元件尚在討論研究階段。
| 層次 | QoS責任 |
|---|---|
| IP 以上 | 提供end-to-end QoS, 例如：IntServ, BBQ |
| IP | 提供鏈路階層之 QoS: 例如：DiffServ |
| MPLS | 在核心網路中快速傳輸IP封包 |
| ATM/ Ether Switch | 提供快速交換式封包轉送能力及基本的QoS機制，例如： traffic engineering, CBR, rt-VBR, nrt-VBR, UBR |
| 實體層 | 提供充足的鏈路頻寬 |
在最下層的實體層，對QoS的貢獻主要在頻寬的擴增，最常見者乃運用光纖以及DWDM技術 大幅擴增頻寬。在ATM層則提供快速的轉送能力及基本的QoS能力，例如CBR、 rt-VBR、nrt-VBR、UBR等。但是這只是針對某一個ATM網路的品質管制，並未能提供 End-to-End QoS，而且當初ATM設計時並未針對IP網路設計，故不盡符合IP網路的要求。仍然需要透過一層 IP over ATM的轉換才能支援IP網路，不免影響效率增加傳輸時間。由於ATM之不足而有MPLS之出現， 試圖彌補ATM與IP之間的縫隙，可大幅提高傳輸效率降低延遲時間，使得ATM網路更適合提供即時 (real time) 的IP服務。但仍然無法提供end-to-end的QoS。在IP層之上，網路管理者必須提供 End-to-End QoS，對於所有QoS參數均需提供相當程度的保證。
在網路尚未有統一標準之前，採用分層結構可以保有必要彈性，可以隨著技術演進以局部方式汰換 網路元件，大幅降低開發成本與縮短開發時程。但是分層結構不免導致效率降低，傳輸時間延遲， 層間介面整合不易。對於時效性服務而言，各層之間的介面所造成的時間延遲與QoS轉換更成為絆腳石， 因此，既然IP通訊協定已經成為世界共通標準，似乎可以揚棄分層結構，直接將IP通訊協定建置在 光纖網路上。第一步，先將ATM層去掉，將IP協定建在SDH網路上，第二步再將IP通訊協定建置在 光纖網路上。基於這個趨勢，本研究將注重於在IP層提供end-to-end品質管理所需的技術，採用 DiffServ QoS環境，而下層的實體網路則由IP層覆蓋，提供透通性。
相較於即時管理法，預先分配法可容忍耗費較高的計算時間，進行較複雜之計算程序以達到 資源分配最佳化，但受限於預測不準確而不易針對網路之即時狀況做最佳資源分配，只適用於 訊務具高度可預測性之情況。在BBQ架構下我們提供一系列的預先規劃工具供營路營運者使用。 每個Ingress記錄過去各時間點各種訊務需求的統計資料，利用這些歷史資料來預測各不同時段 所需資源，據以進行預先資源分配。此外，現階段我們假設網域的資源僅涵蓋附有品質保證 之鏈路頻寬。
網路上的訊務流量需求並不一定非常規律，預測的頻寬需求可能與實際情況出現誤差。除了盡 可能提高預測之準確度之外，網路營運者可以採取BBQ所提供的誤差彌補方案以減少因預測誤差 所導致的資源浪費。
對網路營運者而言，為了滿足所有可能之訊務需求以追求最大利潤，對於非TSCO之訊務 仍應於網路建置階段盡可能預估潛在之需求並建置足夠之網路資源，方能於營運階段避免 拒絕太多訊務需求，且能提供合理的品質予非TSCO之訊務。如果網路建置足夠資源以容納 預期之TSCO與非TSCO之訊務需求，在營運時更可挪用原為非TSCO訊務所建置之資源以 應付遽增之TSCO需求，而延後處理非TSCO訊務。如此，建置給非TSCO訊務之網路容量 可發揮類似水庫之資源調節功能。（建置時期之網路規劃不在本文之討論範圍）。
Interactive類訊務雖然有相當程度之時效需求而且也有連續性質， 但是由於其封包並非密集的持續傳送，因此並不適合為個別封包保留資源， 實際運作時，可直接當作DiffServ之AF類處理，BBQ不需特別處理。 我們的研究專注於提供解決方案予TSCO類的服務品質保證。
圖11.4 End-to-End承載服務
為了降低在訊務允入時執行call setup procedure所需的負擔，我們將資源保留的任務 分成兩階段執行。第一階段，預先規劃階段，核心網路管理元件根據需求之歷史 資料將所擁有之資源（所屬核心網路內之鏈路頻寬）分配到每個edge router， 每個edge router將所獲配之資源組成從edge router到其他edge router特定服務品質之 short-path。換言之，網路資源已經由鏈路資源改成更高階的short-path資源， 每個edge router在第一階段獲配short-path資源，以備於允入階段時使用。 此外每個網路營運者，必須收集所有核心網路所提供的short-path資訊， 為來自所屬接取網路進入的訊務規劃合乎品質需求的end-to-end path。 第二階段，允入階段，最前端的允入控制元件為提出允入需求的服務選擇 一條事先規劃好的end-to-end path，再根據組成該end-to-end path的short-path 逐一向各個核心網路要求保留，以便允入欲進入的訊務。由於實際上一個 訊務所經過的核心網路數屈指可數，在允入階段所耗費的管理負擔遠比RSVP協定少， 而且在事先規劃階段也可運用較佳的規劃工具獲得更有效率的資源運用。
Short-path資源是由各個edge router所掌控，在為某一TSCO訊務保留short-path時，
並不須逐一保留所經過之鏈路，因為鏈路頻寬已經事先以批購方式保留給edge router。
11.4.3 管理系統架構
為了降低管理的複雜度，BBQ採用分散式階層式管理系統，負責規劃資源分配及
具服務品質之路徑，其主要目標是要讓網路管理者在所擁有的網路資源下，
提供最多符合品質的服務。服務品質管理之階層架構如下：
end-to-end服務品質保證協調層（End-to-End Network QoS Coordination
Layer）負責提供end-to-end服務品質保證，利用下層元件所提供之資源，規劃
long-path和end-to-end path；核心網路資源管理層（Core Network Resource
Management Layer）負責核心網路之資源管理分配；核心網路資源控制層（Core
Network QoS Control Layer）負責執行服務品質保證之策略以提供服務品質保證，
例如允入控制等。
DiffServ或其他IP層網路則負責執行上層元件所規劃出來服務品質管理策略，
屬於下層網路技術。BBQ管理架構具有彈性，可更換底層之網路技術，
目前BBQ假設底層網路架構為DiffServ。
| 層級 | 作用 |
|---|---|
| end-to-end服務品質保證協調層 | end-to-end服務品質控制，包括資源和路徑規劃 |
| 核心網路資源管理層 | 核心網路資源管理分配 |
| 核心網路資源控制層 | 執行核心網路服務品質策略 |
| DiffServ | 執行上層資源管理架構所設定策略 |
遵循簡單原則，BBQ將管理任務根據表四的架構分解成許多小任務，交付給特定軟體 (agent)， 這些agent自主的執行所指定之任務，非必要時不須與中央管理者協商。 如此，依據BBQ管理架構所建置的網路之反應時間將非常快速。 以下簡介我們所提出的資源規劃，分配與保留等各種機制。
我們將時間分成時段，每一時段可採用不同之資源管理機制，而每一個時段在執行允入之前，
都在先前的某一個「短期事先規劃」階段規劃所需之short-path
（例如：每天12-5am規劃當天所有時段所需資源），
而在允入時段之起始點實際保留所需的鏈路頻寬，
在執行允入任務時可以立刻決定是否允入一個訊務。
「長期事先規劃」之執行頻率則可低於「短期事先規劃」，
而且所規劃出的long-path並不必要實際保留網路資源，此因太過繁瑣的跨
核心網路資源保留方式可能浪費太多寶貴資源而不切實際，
其規劃之主要目的在於提供需求資訊給網路營運者，以便其預先建置足夠網路資源。
此外，以上的機制都需要強大的資源規劃最佳化工具以提高資源使用效率。
我們已經發展了一些工具可供運用 [15,16,17,18]。
BBQ架構中，品質管理之一個重要任務是為預期中的訊務規劃一組符合end-to-end
品質需求之end-to-end path，並提供給網路營運者以預先建置足夠資源以應付預期
之訊務。由於All-IP網路是由許多獨立的網路互連而成，我們假設並不存在一個
可以為整個網路規劃end-to-end path的管理者，因此long-path及end-to-end path之規劃
必須由各個核心網路獨立負責，彼此合作，各自規劃自身網路訊務所需之end-to-end
path。
11.4.4 End-to-End品質管理
11.4.4.1 Long-path Planning Agent
如圖11.5 所示，每個核心網路均有一個軟體元件，CNC (Core Network
Coordinator)，是核心網路的中央管理者，負責處理所有須要集中處理之任務，
其中一個元件，LPPA (Long-path Planning Agent)，負責規劃long-path。
所有核心網路之LPPA互相合作規劃出各自所需之long-path。
圖11.5 Long-Path Planning Agent.
圖11.6 前端允入控制程序
在長期事先規劃階段，由眾多short-path中以最有效率的方式規劃long-path 是一個典型的最佳化問題，我們利用Integer Programing方式進行最佳化。相關參數包括每一條short-path上相關的服務品質參數 （quality parameters）、剩餘容量（residual bandwidth）、和相關使用成本等等。 為了因應不同的規劃需求，我們發展了一系列最佳化模型及解決方案。 在最簡單的模型中，彈性變動的參數包括short-path的品質及其容量， 各個鏈路及short-path的品質參數是單一值，沒有選擇餘地，而其容量亦無限制。 當long-path規劃完成之後，網路營運者再根據需求建置足夠之網路容量。 在比較複雜的模型中，各個鏈路的容量是確定的且不再增加， 而其品質參數則隨著承諾允入訊務之多寡而變動，在此種情況下， 網路營運者須先規劃各鏈路的承諾允入訊務及其可保證之品質， 在計算時必須考慮各鏈路與short-path之剩餘容量，而最佳化模型將因而比前者複雜許多。 以下是一個一般化的最佳化模型，細節可參考[15]。
Maximize 滿意度指標 Subject to 符合有限的資源之限制 符合路徑品質需求 滿足不同種類之需求
當訊務的型態可預測時，事先資源規劃法有相當的好處， 我們所提出的方案適用於訊務具備可預測性的網路。 我們可根據訊務變化情況，將時間切成許多小時段， 並從歷史訊務資料中找出相似時段，再根據歷史資料規劃未來時段的資源配置。 我們根據這種情況，設計了一系列的規劃工具讓網路營運者盡力提高資源使用效率。
圖11.7 DiffServ-Like核心網路架構
在每一個核心網路之中皆有一個核心網路協調元件(以下簡稱CNC)， 是核心網路之主要控制元件，也是與其他核心網路協調之對外窗口，其內包含三個元件：
Ingress負責向BB批購各鏈路的頻寬資源，組成short-path，並執行訊務允入任務。 內含三個元件：
當資料流結束傳送時，Egress負責釋放原先配置的資源，以利後續進入的訊務使用。
圖11.8 核心網路品質管理軟體架構
以上的規劃程序需要數個規劃工具， 我們設計了幾個追求最高平均獲益之一般最佳化模型供網路營運者參考使用[15,16,17,18]。
圖11.9 Short-Path規劃程序
我們提出了一個品質管理架構，BBQ，供網路營運者提供end-to-end QoS保證予其使用者， 本架構具備高度彈性，網路營運者可根據自身需要調校其網路，追求其所定義之最高滿意度。 在BBQ架構下，訊務的品質參數以預算方式分配到各網路元件，而各網路元件負責達成承諾的品質， 上層的品質管理系統則負責以高效率的方式保證訊務之end-to-end品質。除了管理架構之外， 我們也設計了一些資源分配與繞徑等問題之最佳化模型及其解決方案。 我們的研究範圍包括核心網路， 第三代行動電話網路及無線區域網路。