All-IP Cross-Layer 4G行動通訊研究---子計畫三：All-IP Cross-Layer 服務品質與計費系統之研究(II)

All-IP Cross-Layer4G 行動通信研究-

子計畫三: All-IP Cross-Layer 服務品質與計費系統之研究(2/2)

計畫編號：NSC 96－2219－E－011－009 執行期間： 96 年 8 月 1 日至 97 年 10 月 31 日

計畫主持人：陳俊良 國立台灣科技大學電機工程學系 計畫參與人員：卓俊宇、劉世偉、陳明僑

一、 中文摘要

隨著網際網路的蓬勃發展、無線通訊及行動計算 技術上的成長進步，為行動通訊者及服務提供者帶來 一個異質的服務環境。這種異質存在於無線存取技 術、網路、使用者終端機、裝置設備、應用程式及服 務 提 供 者 等 。 因 此 ， 為 一 個 異 質 環 境 提 供 無 縫

（Seamless）且可調適（Adaptive）的服務品質(QoS)

是下一代無線通訊系統的致勝關鍵。在未來的 4G 網

路將是各種異質網路的整合，在整合異質網路之中，

使用者將可能利用各種不同的終端設備來進行某一種 應用服務，此應用服務隨著使用者的移動行為，將跨 越 各 種異 質的 網 路環 境， 而 造成 各種 不 同層 次的 Handover。每種 Handover 都會導致不同程度的封包遺

失，因此在 4G 的網路環境中，服務品質的問題會是

ㄧ個重大的挑戰。

本計畫在異質整合且環境品質多變的 4G 網路

中，設計一套Cross-Layer Manager，來確保在異質網 路下的QoS，進而提昇服務品質。Cross-Layer Manager 的基本架構共分為三層，分別為：資料層（Data Plane Layer）、 控制 層 （ Control Plane Layer） 及 管 理層

（Management Plane Layer ）。 並 於 此 架 構 上 建 構 Accounting 的機制，使 All-IP 4G 的相關整體計畫成果 可與業界結合。為達成此研究目的，我們分三期計畫 來進行研究、設計與開發的步驟。

本階段計畫完成All-IP 4G 網路 Cross-Layer 動態 QoS 控管系統之 Accounting 服務整合，針對使用者所 提出的應用程式服務類型及使用者付費層級，進行對 相關文獻資料及標準規範的收集與探討，完成屬於

Cross-Layer 管理層所需的資料流等級分類與使用者

層級相關參數定義，進而提供相對應的QoS 服務品質

保證。4G Traffic 分類包含 VoIP、Audio & Video、HTTP

& FTP 和 Others 共四大類，而各分類亦擁有各自的網

路資源分配。根據量測結果顯示，有啟動QoS 機制的

平均封包遺失率與延遲分別為8.5%與 2%優於無啟動

QoS 機制。

此外，本研究之 QoS 控管系統係以 Open IMS 為基礎平台架構；P-CSCF (Proxy-Call Session Control Function)上建置使用者層級資料庫及 PCRF (Policy and Charging Rule Function)，分別進行使用者層級的 認 證 及 QoS 與 Policy Control 的 控 管 ； UE (User Equipment)端使用三種不同類型的應用程式進行效能 的量測，分別為：Kphone(VoIP 類型)、播放線上影片 (Vedio 類型)及透過 FTP 軟體下載檔案( FTP 類型 )；

PDG (Packet Data Gateway)則建置 QoS 監控機制，擷 取並分析各種不同類型的封包，進行量測與計算平均 封包遺失率與延遲時間。

關鍵詞： All-IP 4G 網路、跨層管理、服務品質、計 費管理、IMS、PCRF、WiMAX、Performance Anomaly、

Multicast Application

Abstract

Along with the rapid development in Internet, wireless communication technology and mobile calculation technology, it brings a totally new environment to all mobile communicators and service providers. This

heterogeneity is found in wireless access technique, network, user terminals, equipments, software operators and service providers. Therefore, the key successful factor for the next generation wireless communication system is to provide seamless and adaptive service quality to this heterogeneous environment. The future 4G network is going to unify different kinds of network technologies. In the unified heterogeneous network, the user can use different terminal equipments to process any application. It will cause different level of handover, because the application will move with the user, crossing different network environments. Every kind of handover will cause different degree of packet loss. Therefore, the management of QoS is going to become a challenge in a 4G network environment.

This project considered the All-IP 4G network is being heterogeneous integrated and at a changing environment.

The design of a Cross-Layer Manager is to ensure that under heterogeneous network’s QoS, and increase the quality of service. Cross-Layer Manager is divided into three planes: Data Plane Layer, Control Plane Layer and Manager Plane Layer. This structure is based on Accounting system, that why All-IP 4G related projects could be integrated with business sector. To achieve this goal, we divided the project into three different stages:

study, design, and development.

This stage has finished All-IP 4G network Cross-Layer dynamic QoS control system- integration of accounting service. According to application type and user level class, we do some related research and standard probing.

In order to support different applications and user’s QoS guarantee, the traffic flow classification and user level definition which Cross-Layer’s management layer needs were accomplished. We defined four traffic classes including VoIP, Audio & Video, HTTP & FTP and Others and each class has its own network resource distribution.

Mesurement results indicate that the average packet loss

and average latency with QoS scheme are reduced by about 8.5% and 2%, respectively than that achieved without QoS scheme.

Besides, our QoS control system is based on Open IMS.

Then we build user level database and PCRF (Policy and Charging Rule Function) on P-CSCF (Proxy-Call Session Control Function) to certificate the user level and to do policy control, respectively. The Kphone (VoIP type), play online vedio (Video type) and download files using FTP software (FTP type) as different type of applications to analyze the performance.

The PDG (Packet Data Gateway) captures and analyzes packet's types by use of QoS control mechanism to measure and calculate the average packet loss and average latency.

Keywords: All-IP Network, Cross-Layer Management,

二、 緣由與目的

傳 統 的 TCP/IP (Transmission Control Protocol/

Internet Protocol)網路採用階層式的模組設計(如圖 1 所示)，為了強化模組化的設計概念，使得主要的溝通 只發生在相鄰的階層間，因而引發了一些影響效能的 問題，諸如無線網路高錯誤率、安全性、Quality of Service、行動通訊的電力耗損。如繼續維持上述之運 作架構，勢必會影響未來 4G 環境整體執行效能 [1-3]。

圖 1 TCP/IP 各層的相關協定架構

現 行 的 網 路 服 務 可 以 分 為 Elastic Service 與 Real-Time Service。在 Elastic Service 中，如 FTP 協定

的檔案傳輸或HTTP 協定的網頁資料傳輸，這些服務

在一段時間內完成工作即可；而Real-Time Service 如 語音訊息或影音資料，這些服務應較具即時性的需 求，所以必須在限定的時間內完成工作。而在現行的 網路環境下，系統無法動態地針對不同的需求提供適

當的服務，造成無法滿足任一使用者所需的QoS。

為了解決QoS 於 TCP/IP 架構上可能會發生的問 題，本研究提出以Cross-Layer Coordination Plane 之架 構(如圖 2 所示)作為各階層間的溝通管道，以便解決 此一重大問題。

圖 2 Cross-Layer Coordination Plane

綜合上述在 TCP/IP 架構上所可能會發生的問

題，我們提出一套Cross-Layer Manager 來當作各個階

層間的溝通管道，以便解決這些問題，圖 3 為一套

Cross-Layer Manager 的基本架構，此 Manager 可以接 收各個階層間所發出的Events (如表 1)，例如 Handover Start、Link Lost，而這些 Events 會觸發 Manager 內的 各個模組與Algorithms 運作，然後依照其對整個網路 環 境 的 影 響 去 對 所 有 的 階 層 作 調 控 。 圖 4 為 Cross-Layer 各階層相互分享訊息的概念圖。

圖 3 Cross-Layer Manager

表 1 各階層之 Events 和可供調控的 Variables

圖 4 Cross-Layer 訊息分享

由於 QoS 本身就是一個應用服務。通過對不同的

用戶提供不同的 QoS，從而達到實施不同的收費策

略 。 利 用 與 使 用 者 簽 訂 SLA (Service Level Agreement)，根據不同的 QoS 保證收取不同的費用，

隨著以後個人用戶的增多，對QoS 的需求也會增加。

因此為了讓付費等級較高的使用者能夠享有更具保障 的QoS，因而產生 Accounting 機制。

三、 文獻探討

第一期計畫(NSC 94-2219-E-259-003)已針對增 進QoS 之相關 Cross-Layer 設計的研究，探討了許多 國內外跨Application Layer 及 Network Layer 的研究實 例，分別有AMC (Adaptive Modulation / Coding) with ARQ、ECN (Explicit Congestion Notification) Bit 之應 用、WQE (Wireless Quality Enhancer)系統等[4-9]。在 第二期計畫(NSC 95-2219-E-259-003)中，也針對 4G

互聯網路WiMAX 的架構，以及各類群播應用做研究

分析。在本期計畫中，進一步針對IMS 的架構，以及

IP QoS 目前主要技術、相關問題與 Accounting 計費系 統做深入探討。

3.1 IMS 網路架構

IMS (IP Multimedia Subsystem)是由國際合作組 織3GPP (3rd Generation Partnership Project)所提出的 技術標準。IMS 平台主要以 SIP (Session Initiation Protocol)為基礎，透過開放和標準的架構，使服務提

供者可以在IMS 平台上同時提供語音、數據、與視訊

等 多 樣 化 應 用 服 務 ， 亦 可 以 作 為 固 網 、WLAN、

WiMAX、GSM、GPRS 等有線或無線網路的共同平 台。IMS 的應用目的，係在 3G 網路架構中提供行動

網際網路的服務，並確保在不同網路間轉換時的QoS

[10,11]。

在Mobile Network 內提供 QoS 是相當具挑戰性

的問題。由於頻寬之變動、基地台之間Handoff 問題，

嚴重影響封包之傳遞，使得Mobile Network 中的 Real time Applications 相當容易受影響。在一般的有線網路 中，封包傳輸處於「最佳效率」的狀態，此狀態意味 著網路會儘量保持Application 所需的頻寬，但不會依 據頻寬的可用性和網路的堵塞情形，予以任何保證，

此 項 設 計 使 得 Mobile Network 中 的 Real-time Applications 服務 QoS 無法確保[12]。

IMS 的 QoS 機制是為了取代「最佳效率」狀態 而設計，以確保所提供的傳輸品質。IMS 的 QoS 機制 為確保封包傳輸的品質，經由針對相關網路狀態參數 如傳輸率、閘道延遲及錯誤率之量測，使得資源可以 先被保留。用戶可依據服務型式及用戶環境，指定要 求QoS。IMS 中「智慧型」的 QoS reguest，被稱為政 策決策功能(Policy Decision Function；PDF)模組(運作

架構如圖5 所示)，PDF 模組與基礎分封網路互動，並

透過 Go Interface 至 GGSN 控制分封網路資源分配 [13-15]。

圖 5 IMS Policy Decision Function 運作架構

在 IMS 標準中，明確地規範 QoS 參數可在兩個

UEs 的 Session 建立前，就進行協商動作[16]。其目的

在於檢查兩個UEs 之間的連線是否有足夠的資源可供

運用，當QoS 參數被確認後，IMS Network 則會要求 骨幹網路(Core Network)與存取網路(Access Network) 為該Session 保留資源。其中 SIP INVITE 及 UPDATE Message 的運作流程，如圖 6 所示[17]。

圖 6

IMS Pre-session QoS Negotiation 的運作流程

當 UE1 對 UE2 發出 INVITE Message 時，該 Message 會 夾 帶 QoS Proposal (request) ， 此 QoS Proposal 則 會 分 別 於 UE1 及 UE2 的 S-CSCF(Serving-Call Session Control Functions)檢查其 Subscription Level，並確定 QoS 參數。其後，UE2 會 回傳其所屬之QoS Proposal，此 QoS Proposal 也會於 UE1 及 UE2 之 S-CSCF 檢查 Subscription Level，並根 據此 Level 確定 QoS 參數。最後，UE1 會接收 UE2 的 QoS Proposal，並開始建立 Session 或是根據 SIP UPDATE Message 做出 Renegotiate 的動作。透過 SIP Message 傳遞 QoS 參數，使得 Session Data 得以藉由 Session Description Protocol (SDP)傳輸[18]。

3.2 IP QoS 目前主要技術

由於IP QoS 問題是解決 IP 網路承載多 traffic 的

關鍵因素，因此對IP QoS 的研究一直是當今熱門的研

究議題。從目前的研究成果來看，主要有以下幾種解 決方案。

1. IntServ [19]

針對IP QoS 的問題，IETF 在早期提出了 IntServ

（Integrated Services）模型，系統架構如圖 7 所示。

IntServ 模型又稱為集成服務模型，其基本思想是在傳

送資料之前，根據traffic 的 QoS 需求進行網路資源預 留，從而為該資料流程提供 E2E (End-to-End)的 QoS 保證。為此，IntServ 通常採用 TCP 的資源保留通訊協 定（RSVP），在 flow 傳輸路徑上的每個節點為 flow 預 留 並 維 護 資 源 。 主 機 利 用 RSVP 向 網 路 為 Application 提出 QoS 請求；路由器利用 RSVP 將 QoS

請求資訊傳送給flow 路徑中其他的路由器，並建立和

保存該服務的資訊；RSVP 請求將會使得沿著資料路 徑的資源在路由器預留。這種模型的優點是能提供 E2E 的絕對的 QoS 保證，表 2 描述了 InServ 的服務種 類，但由於這種模型在實現上是非常困難的，主要困 難點如下：

（1）由於預留是基於每個 flow 而進行的，因此使得

節點中要保留每個flow 的狀態資訊，導致核心路

由器負擔太重，因此可擴展性很差。

（2）網路中每個節點都要維護各類資料庫，並實現複 雜的功能模組（如資源預留、路由、Access Control 等），造成了極大的複雜性。

圖 7 IntServ 架構

表 2 IntServ Services

Guaranteed Controlled

Load Best Effort

Parameters TSpec None

QoS Delay bound, No loss

Best-effort over uncongested

network

None

Traffic control

Admission control, Policing, scheduling

Admission control, Policing, scheduling

FIFO scheduling

RFC RFC 2212 RFC 2211

2. DiffServ[20]

由於IntServ 的局限性，IETF 又提出了 DiffServ

（Differentiated Services）模型，又稱為區分服務模

型，系統架構如圖8 所示。區分服務模型的基本思想

是在網路的入口處為每個封包分類，並在封包中標記 相應的區分服務代碼點（DSCP，DiffServ CodePoint）， 用於指示封包在網路轉發路徑的中間節點上被處理的 方 式 。在 網路 內 部的 核心 路 由器 中只 保 存簡 單的 DSCP 與 PHB（Per Hop Behavior）的對應機制(如表 3 所示)，根據封包 header 中的 DSCP 值，對封包進行相 應的優先順序轉發，而traffic flow 狀態資訊的保存與 流量控制機制的實現等都在網路邊界節點進行，內部 節點是與狀態無關的。

圖 8 DiffServ 架構

表 3 DiffServ PHBs

AF PHB EF PHB Best-effort

Features

4 delay priority classes, each with 3 drop precedence

subclasses

Premium/V irtual leased line

service

none

Traffic Control

Static SLA Policing, Classification,

Marking, RIO/WRED

Scheduling

Dynamic SLA Policing, Classificati

on, Marking, Priority/WF

Q Scheduling

FIFO Scheduling

Non- conforming

Packets

Re-mark as best-effort

Drop Non- Conforming

Packets

RFC RFC 2597 RFC 2598

DiffServ 具有實現簡單及擴展性好的特點。目前 在IP 網路中 DiffServ 得到絕大部分廠家的支援，其具 體實現技術包括分類、重標記、速率限制、流量控管、

壅塞避免、佇列調度等。但區分服務也有自己的局限

性，主要的問題如下：

（1）DiffServ 只承諾相對的服務品質，因而不能對使 用者提供絕對的服務品質保證。

（2）在壅塞發生時，DiffServ 模型只能採取丟棄封包 的方式，而不能採用例如旁路的方式使部分流量 通過其他路徑到達終點。

（3）對相同優先順序的 traffic 而言，設備在壅塞時對 封包的丟棄是非常不智的，也就是說，設備只能

隨機地丟棄封包，其結果是所有traffic 的服務品

質都受到影響。而此時希望的結果是只丟棄少部 分 traffic flow 的封包，從而避免剩下大多數的 traffic flow 服務品質受到影響。

3. IntServ 與 DiffServ 結合

IntServ 與 DiffServ 結合的方式是另一策略，其

觀念為：在使用者網路仍使用 RSVP，在運營商的

DiffServ 網路邊界將 IntServ 的 traffic 類型映射為 DiffServ 的 traffic 類型，這樣利用 IntServ 的架構來解 決E2E 的 QoS，同時也利用 DiffServ 來提供好的擴展

性。但這種方法仍然存在IntServ 的信令複雜、不便於

管 理 等 問 題 ， 而 且 由 於 在 運 營 商 的 網 路 採 用 DiffServ，因此在這一段網路也只能提供相對的 QoS，

從而使E2E 的服務品質得不到絕對的頻寬保證。該方

法目前仍處於一種理論的研究階段。

4. MPLS & QoS [21]

利用多協議標籤交換MPLS（Multiprotocol Label Switching）技術，可以協助解決 QoS 問題。MPLS 是 一種結合第二層和第三層的交換技術，引入了基於標 籤的機制，把路由選擇和資料轉發分開，由標籤來規 定一個分組通過網路的路徑。MPLS 網路由核心部分

的標籤交換路由器（LSR）、邊緣部分的標籤邊緣路由

器（LER）組成。

由於 MPLS 採用標籤交換來進行 MPLS 轉發，

因此其轉發效率高於傳統IP 通過路由器的轉發，從而

通過減少轉發時間來提高QoS。此外，MPLS 的封包

header 中包含一個 3bit 的 EXP 欄位，通過該欄位可以

標記該MPLS 封包的優先順序，從而使設備在轉發該 MPLS 封包時能根據優先順序標誌進行區別對待。

這種方式的局限性在於：首先它必須基於MPLS

網路實現，而當前許多網路上並沒有實施 MPLS；另

外隨著近幾年晶片技術的不斷發展，路由轉發與交換

轉發之間的性能差異也越來越小；而且通過EXP 進行

優先順序區分實際上也是DiffServ 的實現方式，因而

這種方式也不可避免地具有DiffServ 所具有的一些局

限性。

5. MPLS-TE&QoS [22]

流量工程（TE；Traffic Engineer）是指為 traffic flow 選擇路徑的處理過程，以在網路中不同的連結路 徑、路由器和交換機之間平衡traffic flow 負載。其目 標 是 給 定 一 節 點 與 另 一 節 點 之 間 計 算 一 條 路 徑

（source 路由），該路徑不違反它的約束，例如頻寬或

管理要求，並且從一些數量指標看來是最好的。

MPLS 由於自身路由與轉發分離的特點，適合與 TE 的結合，形成 MPLS-TE 技術。應用 MPLS-TE，

可以提高網路的QoS，主要原因在：

（1）利用 MPLS-TE，可以在多條可能的轉發路徑中

進行負載平衡，從而避免壅塞，提高QoS。

（2）應用 MPLS-TE，通過 RSVP-TE 信令，創建一條 具有嚴格的QoS 頻寬保證的 tunnel，從而保證絕 對的QoS。

（3）可以通過備份 LSP、FRR（Fast Reroute）等方式 對tunnel 進行額外保護，從而提高網路的 QoS。

但MPLS-TE 也存在一些局限性，包括：首先它

必須應用在MPLS 網路中，因此目前部分非 MPLS 網

路無法支援該技術的應用；其次目前對 MPLS-TE 跨

domain 的 應 用 仍 然 在 研 究 階 段 ， 這 意 味 著 當 前 MPLS-TE 主要的應用只能在單個 domain 中；另外，

MPLS-TE 雖然可為用戶創建具有頻寬保證的 tunnel，

但如果在tunnel 中同時傳送多種 traffic 時，如何對這

些不同優先順序的traffic 進行區別處理也是需要研究

的問題。

6. Bandwidth Broker[23]

為了更有效地監視和控制全網的資源，在新一代 的模型中，人們又提出了頻寬代理（BB，Bandwidth

Broker），也就是網路資源管理器的概念，頻寬代理內

部模組運作如圖9 所示。頻寬代理收集網路的拓撲和

節點及link 狀態資訊，管理網路資源，並且結合策略

伺服器規定的策略進行access control。同時，頻寬管

理還負責管理 domain 之間的通信，通過與相鄰網路

domain 的頻寬代理通信來達到跨 domain 之間 QoS 目 的。

圖 9 頻寬代理內部模組運作

頻寬管理技術的優點是將 QoS 控制層與資料傳

輸層分開，核心路由器不需要進行 access control 和 QoS 狀態資訊保存，路由器之間也進行簡化，或者說

消除了QoS 信令，簡化路由器的複雜性。此外這種方

式支援絕對的QoS 保證，包括支持跨 domain 的 QoS 保證。還有這種方式中網路資源被統一地控制與管

理，有利於電信運營商把QoS 作為一種業務來發展。

但目前頻寬管理技術仍然處於研究階段， BB 之間的

信令交換都還在討論之中。另外，這種方式對 BB 的

要求很高，在某些情況下，如果同時申請資源的traffic

flow 個數很多，有可能會使 BB 成為網路中的瓶頸。

3.3 IP QoS 主要問題

IP QoS 發展至今，除了上述的技術外，還有很 多模型以及應用技術的提出，這些技術的產生與應 用，確實給目前的IP-based 網部分提高了 QoS 的支援

能力。但總體上，還沒有完全解決當前IP 網所面臨的

QoS 問題。具體說來，有以下幾個大方向還需要進一 步的研究。

1. 如何提供應用服務 E2E 的 QoS

E2E 的 QoS 是應用服務發展的必需條件。當前

電信運營商正大力推廣其增值應用服務，如 VoIP、

VOD、VPN 等，都需要考慮如何對這些應用服務提供 滿足要求的E2E QoS。此外，各種應用服務的 QoS 需 求不一致，包括頻寬、延遲、延遲抖動和封包遺失率

等，應分別根據其不同需求進行QoS 方面的考慮。 在

目前的QoS 技術中，對 E2E QoS 的支援都存在著不

足：或者是實現過於複雜，或者是不能提供絕對的QoS

保 證 ，或 者是 實 現的 範圍 有 限（ 例如 只 能在 某個 domain 裡）。這些都影響著 E2E 應用服務的發展。

從網路的角度而言，E2E 的應用服務涉及到網路

的各個層面。因此提供應用服務E2E 的 QoS，仍然要

分別從網路的各個層面考慮。應分別考慮在存取技術

以及核心網路對應用服務實施的QoS 策略，特別是存

取技術。由於目前access technology 的多樣性，包括 乙太網路、DSLAM、專線、無線等等，這都需要考慮 相應的QoS 策略。

從應用服務的角度看，對應用服務E2E QoS 的

研究應包括以下幾個方面。首先是QoS 測量，即在應

用服務發起前對應用服務所經過路徑的QoS 性能進行

測量，判斷當前網路性能是否支援應用服務的需求；

然後是資源預留，通過全程的資源預留為應用服務提 供絕對的頻寬支援，由於應用服務通常具有一定的持 續性，資源預留方式可以更好地支援在一段時間內應

用服務的QoS；還有就是應用服務監控，在應用服務

執行時間裡對應用服務進行監控，根據其服務品質以

及當前網路狀況進行統計與調整。對於上述 QoS 測

量，資源預留，應用服務監控這三個方面的研究都還

需要加強。

2. QoS 管理

QoS 由於自身具有 E2E 的特點，因此涉及到一

個全網的 QoS 管理問題，例如運營商需要管理全網

QoS 策略及一致性、網路資源資訊、QoS 授權使用者、

計費資訊等等，同時需要監控各連結網路即時的性

能，各使用者的QoS 實施情況，並且最好能動態地進

行調整。對全網QoS 的可管理也是重要的問題。

而傳統路由器設備的管理，往往集中在設備本

身，而不關心其他設備的狀況。例如通常實現關於QoS

的命令列以及 MIB，都只是關於設備本身的 QoS 管

理。而從整個網路來看，缺乏統一的QoS 管理結構和

應用方案。

目前對 QoS 管理的研究已經開始進行，例如前

面提到的 BB，就是對整個網路資源的管理。還有現

在提出基於策略的QoS 管理框架，通過在網路中部署

策略伺服器來達到整個網路中所有設備QoS 策略的一

致性。但這些研究還有待深入。

3. 應用服務發展

作為電信運營來說，QoS 本身就是一個應用服

務。通過對不同的用戶提供不同的QoS，從而達到實

施不同的收費策略。目前對QoS 應用服務的發展相對

簡單，通常是與使用者簽訂SLA，根據不同的 QoS 保

證收取不同的費用，這種方式QoS 保證與收費較固定

和簡單。隨著以後個人用戶的增多，對QoS 的需求也

會增加。同時，個人用戶對QoS 的要求也是不固定的，

也許有時需要，而有時不需要。因此，可以考慮與個

人用戶實現比較靈活的 QoS 支援，例如根據實際需

要，逐步提供QoS 使用者自助服務，使用者可自訂不

同的網路頻寬、服務等級、資費套餐等自助服務參數，

並可查詢網路頻寬、服務等級、服務資費等。而這種 業務的發展又需要以下幾方面的支援。

（1）目前對 QoS 的計費相對簡單，通常是包月計費。

如果要實現上述的使用者自助服務，那麼對QoS

的計費要求也相應地要提高，計費系統需要根據

使用者不同時段的QoS 服務提供綜合計費。

（2）這種服務要求運營商對 QoS 使用者的認證和後 方資料庫的管理都提出新的要求。

（3）對 QoS 的安全管理也有新的要求，要防止可能 出現的QoS 詐欺以及攻擊。

由於存在這些方面的新要求，從而導致 QoS 應

用服務發展成本的提高以及複雜性的上升。因此，如

何更好地對用戶發展QoS 應用服務，也是當前需要解

決的一個問題。

3.4 Accounting 計費系統

在以多媒體為主流的下一代網際網路(NGI)上，

傳輸的資料除了傳統的資料流程外，還包括各種音 訊、視頻。資訊在傳輸的過程中經過不同的網路技術 存取服務提供者、骨幹網設備提供商、內容和應用服 務提供者等的 access network、傳輸網、資料資訊系 統。相對應的下一代網路計費應當包括：資訊費、傳 輸費、access 費用和終端設備提供費。這些計費因素 分散在整個網路上，在各個網路服務提供商之間傳 遞，在不同的媒體中轉換，在不同的線路上傳輸。因 此，下一代網路計費的範圍遍及網路中的每一部分，

構成了一個複雜的計費網路系統，稱其為下一代網際 網路計費網路(NGIAN)。

在這個計費網路模式下，由各個ISP 各自為其提

供的服務計費方式已經不適應全域性下一代計費網 路。目前，很多國家的研究團隊和國際標準組織都對 NGI 計 費 問 題 進 行 了 相 關 研 究 。 M3I 、 SUSIE 、 EUROSCOM 及 IETF 分別從不同角度研究面向業務 計費網路的相關問題。M3I 工作組從商務模型入手，

提出將網路計費服務做為商務模型中的一個獨立角 色，稱為基礎層(infrastructure layer)的計費服務提供者 (billing service provider)，由這個獨立的 BSP 為網路各

內容和應用ISP 提供統一的計費服務。M3I 的研究結

果發現應用服務特性在網路計費系統中的重要性。但 是，對於如何將應用服務特性融合到具體的下一代互 聯網計費系統中則缺乏詳細的解決方案。SUISE 工作

組為ATM 上傳遞優質 IP 應用服務提供了一個整合計

費方案，但沒有對承載下一代網際網路應用服務的區 分服務(DiffServ) ，MPLS 技術的計費方面做詳細研 討。此外，IPDR 工作團隊、IETF，TMF 也在各自的 領域提出了針對局部問題的可借鑒的解決方案。但

是，以全網路為基礎架構面向應用服務的 NGIAN 問

題還有待解決。

計費參數指描述 Application 使用情況的參數，

表現了Application 與所使用資源之間的對應關係。這 裡參考ITU-T 和 IETF 相關工作組的研究成果，將計 費參數集劃分為3 類[24]。

(1) Application 標識參數，也稱基本屬性參數：作用在 於唯一標識一個traffic flow，指示 application 的種 類、發起者和服務類型、承載的業務特性等，與計 費功能沒有直接關係。

(2) Application 使用參數：描述一次 application 使用網 路資源的情況，與最終的費用直接相關。

(3) Application 品質參數：描述 application 的傳輸品 質，用於標識期望的application 服務等級以及衡量 實際獲得的服務狀況。與application 使用參數一起 構成了影響用戶應支付費用的因素。

計費模型採用三層體系結構如圖10 所示，計費

系統後台即時處理計費資訊，系統的使用者通過GUI

查看和處理計費生成結果，系統隨時保有一定容量不 同層次的計費處理資料。從軟體構架上看，系統分為:

應用服務層、資料處理層、網路通信層和資料儲存層。

應用服務層為計費系統的使用者提供計費資訊查詢介 面，為系統管理者提供友好的管理介面。資料處理層 集成計費模型各個層次的功能模組，完成提取計費相 關的網路資料，將其整合為標準化資料記錄，將網路 資料映射為application 使用費用，為計費系統使用者 提供各種類型的帳單。網路通信層為上層提供通信介 面，實現計費系統各個單元模組之間的資訊交流。資 料儲存層，保存計費流程各個階段的中間資料和最後 生成的業務帳單，是分佈在網路中的多個記憶體或網 路計費系統的中央資料庫計費系統中。

圖 10 網路計費系統層次結構

下一代互聯網計費系統功能實體及主要功能如 下所述：

●使用者管理模組：管理網路業務的使用者，如維護用

戶生命週期、管理用戶許可權等。

●業務管理模組：管理當前網路上提供的所有業務，實

現新業務的開通計費、業務資訊(SLS)的配置、修改 以及即時的業務資訊查詢功能。

●SLA 管理模組：保存和維護各業務 ISP 與用戶之間

協商和簽署的SLA，根據所簽署的 SLA 實現價格的

動態生成。

●資料測量模組：不間斷地測量流經網路元件的traffic flow 的計費資訊參數。

●資料收集模組：按照一定的時間週期從所屬的網域內

的各個測量器模組中收集計費相關的網路資料並對 其進行錯誤檢查，格式規格化。

●資料歸類模組：從不同的收集器獲取資料，進行錯誤

檢查，格式規格化，按照業務整合通過計費 ISP 管

理網路上有關聯的計費資料參數。歸類器模組可以 分別以推或拉的模式工作。

●測量器管理、收集器管理和歸類器管理模組：分解計

費策略，指導各層功能實體的功能集。

●定價器模組：根據使用者與ISP 簽訂 SLA 時的網路 狀況，為該服務確定網路資源的單價。

●計費器模組：完成網路資源到網路資源費用的映射。

綜合使用應用服務計費參數記錄、網路資源單價、

SLA 與實現 application 的 QoS 各種參數。需考慮各

類SLA 違約情況導致的補償計算。

●帳單生成器模組：生成基於使用者的明細帳單，根據

使用者指定的帳單格式和帳單發送方法生成與發送 帳單。

此計費系統完成了Application-oriented 的全網路 計費系統的功能，具有如下優點：

1. Application-oriented 的 IP 網路計費。

2. 實現計費流程的自動化。計費系統各個模組之間自 動觸發，從用戶使用業務開始到業務帳單生成完 畢，不需人工干預。

3. 支持 QoS 和 SLA。系統在計費參數採集、費用計

算等多個模組中保證了 QoS 參數對業務費用的影

響。

4. 實現計費系統元件化和網路結構的分散式運行本 系統各個模組獨立運行，可以獨立配置於網路的任

何位置，由計費ISP 管理介面統一管理。而且各個

模組功能相關性低、藕合度高，可以作為元件開發。

5. 遮罩網路底層細節和計費資料參數的異構性，對上 層模組使用統一的介面資訊模型，系統運行效率 高。

四、 研究方法

以下介紹本研究所提出建置在IMS 平台上的 QoS

機制、策略以及Accounting 計費系統之探討。

4.1 IMS 平台之 QoS 機制與策略

圖11 為 IMS 平台之測試環境架構圖，依據 IMS 訊 息 傳 輸 之 標 準 ， 本 研 究 將 QoS 策 略 機 制 置 於 P-CSCF，當 UE 端向 P-CSCF 發出請求服務之資訊時，

QoS 策略機制會根據使用者的身份、請求的服務及目

前頻寬情況等資訊，決定是否授權給 UE 端使用請求

的服務。當同意授權UE 端服務時，QoS 策略機制會

同時通知BAS/A-BGF、PDG 或 GGSN 等閘道上，保 留授權之使用者可用頻寬，以達到服務品質的保證。

圖 11 IMS 測試環境

在 IMS 網路中，媒體和訊息可以使用不同的

PDP 場景。UE 請求 PDG 建立媒體 PDP 場景的過

程稱為資源預留，各UE 執行此過程是完全相互獨

立的。本研究在各網路元件之間的媒體QoS 控制的

運作步驟如圖12 所示，步驟如下：

(1) UE 端向 AF 請求新服務的建立。

(2a) AF（P-CSCF）針對新服務的建立請求，向 PDF

傳達服務訊息，並週期性地向PDF 請求一個授權

的Token。

(2b) PDF 生成一個授權 Token 並返回给 AF。

(2c) AF 將此授權 Token 返回給 UE。

(3) UE 收到 Token 後，向 PEP(PDG)發出 PDP(Policy Decision point)啟用請求。

(4) PEP 收到資源保留請求後，向 PDF 請求授權，請 求中包含授權Token。

(5) PDF 收到授權請求後，根據與 AF 的事先约定，此 時通知AF。

(6) AF 收到 PDF 的授權指示後，返回業務訊息给 PDF。

(7) PDF 根據 AF 的業務訊息和本地策略，進行策略決

策，將授權的QoS 和封包分類数傳回給 PEP。

(8) PEP 將 PDF 返回的策略訊息與 UE 請求的訊息進

行比較，最後向UE 返回資源保留請求的執行结果。

(9) 此時 UE 完成一次服務所需的資源預留，可以繼續 應用層的業務處理。

圖 12 QoS 授權機制

此外，QoS 策略依據 3G、WLAN 及 WiMAX QoS 規格(如表 4、5 及 6 所示) ，將不同類型之應用程式 分為VoIP related，Video & Audio related，HTTP & FTP related 以及 Others 等四個類別(如表 7 所示)，每類應

用程式具有不同的頻寬及優先權，當有 traffic 經過

PDG gateway 時，QoS 機制便會偵測該 traffic 的封包

格式，藉由監測封包格式的不同，分辨該traffic 屬於

何種應用程式。最後QoS 機制分配該應用程式應得之

頻寬，以達到QoS 之目的。

表 4 3G QoS 規格

QoS Classes Fundamental Characteristics Application

Conversation Class

z Preserve time variation

z Conversational pattern voice

Streaming Class z Preserve time variation Streaming video

Interactive Class z Request response pattern z Preserve payload content

Web browsing

Background

z Destination is not expecting data within certain time

z Preserve payload content

Background download of e-mails

表 5 WLAN QoS 規格

# AC CWmin CWmax AIFSN

4 AC_VO

(Voice)

(aCWmin+1)/4 – 1

(aCWmin+1)/2 –

1 2

3 AC_VI (Video)

(aCWmin+1)/2 –

1 aCWmin 2

2

AC_BE (Best Effort)

aCWmin aCWmax 3

1

AC_BK (Back Ground)

aCWmin aCWmax 7

表 6 WiMAX QoS 規格

Scheduling type

Piggyback Request

Bandwidth

stealing Polling

UGS Not

allowed Not allowed

PM bit is used to request a unicast poll for

bandwidth needs of non-UGS

connections

rtPS Allowed Allowed

Scheduling only allows unicast

polling

nrtPS Allowed Allowed

Scheduling may restrict a service flow to unicast polling via

the transmission/reque

st policy; otherwise

all forms of polling are allowed BE Allowed Allowed All forms of

polling allowed

表 7 分類與通訊協定對照

# Class Support Protocols

1 VoIP related

SIP、Skype、Live 365、H323、Http-rstp、

Ventrilo、Quick time、Http audio、

Http-itunes.

2 Video& Audio

Related Http video、rtsp.

3 Http Ftp

Related FTP、Http.

4 Others POP3、Yahoo Messager、P2P.

4.2 Accounting 計費系統

本研究所建置的計費系統，主要參考兩個因素：

1、服務優先權/計價（Service Priority/ Accounting）；

2、流量等級（Traffic Class）。

服務優先權/計價的部份已經有使用者每月預付

更多的價錢及享有更好的QoS 服務支援的設計觀念，

或是每月固定使用大量的服務則在日後也可能會升級

進而得到更好的QoS 服務。

因 此 本 研 究 將 使 用 者 定 義 出 QoS 等 級

（QoSClass），將使用者分類成以下三種級別：

QoSClass = 3 （白金使用者）

QoSClass = 2 （VIP 使用者）

QoSClass = 1 （一般使用者）

這樣的使用者等級分類機制，當在資源衝突或使

用環境受到限制這類情形發生時，將更有助於 QoS

Agent 做出更正確的判斷。另外，在流量等級的定義 部份同樣也是很重要的，在分類定義的時候必須要考 慮到 Bit Error Rate（BER）、數據段順序（Segment Order）、數據段遺失（Segment Loss）和數據段延遲

（Segment Delay）等會影響流量等級的因素。我們在 此將最小分辨率流量稱為QoS 資料流（QoS Stream），

這些QoS 資料流和 QoS Agent 會有邏輯上的相關性，

並且能夠加入在數據段封包中一些已經規劃好的佇

列。因此我們將這些QoS 資料流概觀的分類成如表 8

所示：

在表8 中，QoS Stream ID #15 代表著最高等級 的QoS 資料流（如 E-911），相反地Stream ID #5 代表 著最低等級，而Stream ID #1～Stream ID #4 是預先保 留下來供未來擴充使用。而環境變數（BER、Segment Order、Segment Loss、Segment Delay）的評估範圍是 從#4～#1。這些的參數設定根據實體頻道狀況來做動 態的調校，我們定義這樣的機制，以供得出一個實際 QoS 的值（Value）給 QoS Agent。

在QoS 等級與 QoS 的資料流制定好後，將兩者

的觀念相結合，我們可以得到以下的QoS 值：

QoS = QoSclass * QoSstreamID

QoS Agent 得到重要的 QoS 值後便針對每個使用 者所要求的服務如語音、影像串流、資料，規劃出最

適當的QoS 狀態，再根據前面所提的方法達到動態調

整QoS 以滿足每位使用者。

表 8 QoS 不同資料流分配

Stream ID

Stream Description

Bit Error

Rate

Segment Order

Segment Loss

Segment Delay

#5 Management ^Network 2 3 2 3

#6 Internet Data 3 4 4 2

#7 ^Internet

Control 4 4 4 4

#8 Multicast,

RTP 3 3 3 3

#9 Interactive

Data 3 4 4 3

#10 Stream Video

(H263) 3 3 3 4

#11 ^VoIP 3 3 3 4

#12 Circuit Voice 3 3 3 4

#13 ^Layer3

Control 4 4 4 4

#14 ^Layer2

Control 4 4 4 4

#15 ^E-911

Session 4 4 4 4

由於每個不同的應用服務所需要的 QoS 網路環

境需求都不盡相同，所以針對網路環境狀態再提出一 個QoSnetwork 變數，這個變數可由表 4.5 的四項環境 參數（BER、Segment Order、Segment Loss、Segment Delay）所組成。如此再將這個 QoSnetwork 變數與 QoS

等級和QoS 的資料流三者結合，得到一個重要的 Cost

值如下：

Cost= QoSclass * QoSstreamID * QoSnetwork

五、 結果與討論

本研究於4G Testbed 環境(如圖 13 所示)測試 QoS scheme 對於 Core Network 上 QoS 之影響；首先，於 Core Network 環境外建立一 Media Server 提供 UE client 端各種多媒體服務，並於 PDG gateway 上觀測 有無QoS 機制下的 throughput 變化。

圖 13 本研究所建置之 4G Testbed

如圖14 及 15 所示，在 4G 系統下有 QoS 機制時，

VoIP related 應用及 FTP related 應用擁有各自的頻寬，

若取消QoS 機制時，則如圖 16 及 17 所示，FTP related 應用會逐漸搶走VoIP related 應用之頻寬，使得 VoIP 通訊品質下降，甚至斷線。

圖18 及 19 則代表 WLAN 系統下有 QoS 機制時 VoIP related 應用及 FTP related 應用運作之情形，圖中 所示可以清楚的了解VoIP related 應用及 FTP related

應用依舊擁有各自的頻寬，但將QoS 機制取消後，則

如圖20 及 21 所顯現，FTP related 應用逐漸搶走 VoIP related 應用之頻寬。

圖 14 4G 系統 VoIP related 應用 throughput (有 QoS 機制)

圖 15 4G 系統 FTP related 應用 throughput (有 QoS 機制)

圖 16 4G 系統 VoIP related 應用 throughput (無 QoS 機制)

圖 17 4G 系統 FTP related 應用 throughput (無 QoS 機制)

圖 18 WLAN VoIP related 應用 throughput (有 QoS 機制)

圖 19 WLAN FTP related 應用 throughput (有 QoS 機制)

圖 20 WLAN VoIP related 應用 throughput (無 QoS 機制)

圖 21 WLAN FTP related 應用 throughput (無 QoS 機制)

將上述觀察結果彙整 QoS scheme 對於 4G 及 WLAN 系統的 Throughput 之影響如圖 22 及 23 所示。

圖 22 QoS scheme 對於 4G 系統 Throughput 之影響

圖 23 QoS scheme 對於 WLAN Throughput 之影響

並於Gateway 上根據有啟動 QoS 機制與沒有啟動 QoS 機制量測 VoIP related 與 FTP related 兩種 traffic 整體的平均 latency，平均 jitter 和平均 packet loss ratio，分別如圖 24、25 及 26。由圖 24 可見，有 QoS 機 制 的 平 均 latency 會 低 於 無 QoS 機 制 的 平 均 latency；圖 5.12 顯示有 QoS 機制的平均 jitter 會比無 QoS 機制的平均 jitter 來的穩定；圖 5.13 有 QoS 機制 的平均packet loss ratio 會比無 QoS 機制的平均 packet loss ratio 來的小。經統計結果計算出，有啟動 QoS 機

制的平均封包遺失率與延遲比無啟動QoS 機制的平均

封包遺失率與延遲分別優於8.5%與 2%。

圖 24 平均 latency

圖 25 平均 jitter

3G SYSTEM

0 100 200 300 400 500 600 700

1 2 3 4 5

Time (Min)

Throughput (kbits/s) Audio Streaming(有QoS機

制)

FTP Traffic(有QoS機制) Audio Streaming(無QoS機 制)

FTP Traffic(無QoS機制)

WLAN SYSTEM

0 500 1000 1500 2000 2500 3000

1 2 3 4 5

Time (Min)

Throughput (kbits/s) Audio Streaming(有QoS機

制)

FTP Traffic(有QoS機制)

Audio Streaming(無QoS機 制)

FTP Traffic(無QoS機制)

圖 26 平均 packet loss ratio

六、 計畫成果自評

現 代 化 的 網 路 應 用 中 ， 特 別 注 重 即 時 性

（Real-Time）的應用服務，在有限的網路資源下，需 要一個品質保證的服務。而於有線及無線的異質性網 路中，關心的服務品質也不同，例如在無線網路環境 中比較關心位元錯誤率，資料重傳以及封包遺失的問 題，但這些服務品質控制參數在有線環境中的敏感度 卻不高。另外，不同的應用程式所需控制的服務品質 參數也有所差異。例如，網路電話較關心延遲變化率

及E2E 的延遲時間，線上電影則較關心封包遺失率對

影片解析度的影響。

本研究中，我們配合現有的QoS規範，以多媒體 應用軟體QoS分類為基礎，設計出可適性QoS管理機 制，來即時監控網路流量及網路壅塞時的頻寬管理，

針對有線網路及無線網路異質性的服務品質參數來做 進一步控制調整，進而達到Access Network的服務品 質保證。

本研究為三年期之研究計畫，研究主題分別為

「All-IP 4G網路Cross-Layer訊息交換排程系統」、

「All-IP 4G網路Cross-Layer控制層QoS整合與動態調 配」及「All-IP 4G網路Cross-Layer設計之QoS動態控 管的Accounting服務整合」三大課題。 在第三期研究 計畫中，我們完成了「All-IP 4G網路Cross-Layer設計 之QoS動態控管的Accounting服務整合」，並且已將計 畫成果協同其他子計畫整合於子計畫一所提供的平台 上。本計畫所提出的QoS網路基礎架構中的管理層，

其主要目的是針對使用者所提出的應用程式服務類型 以及使用者付費層級，進行Cross-Layer管理層所需的 資料流等級分類與使用者層級相關參數定義，根據資 料流的參數及分類依據，運行QoS處理機制，並將控 制 訊 號 透 過 資 料 層 來 進 行 處 理 及 傳 送 ， 以 達 到 Cross-Layer控制的目的進而提供相對應的服務品質保 證。本子計畫與其他子計畫整合(如圖27所示)，共同 運 作 在 子 計 畫 一 所 建 置 之4G-IMS Network 測 試平 台。本子計畫可提供QoS資料給予子計畫二，以便進 行跨層式的加解密機制，確保資料傳輸的安全性，並 且透過建立的匿名身份認證、資料認證機制及隱私性 保護機制，讓行動用戶可以安全地取得4G-IMS的應用 及服務。本子計畫亦提供子計畫四作為換手決策之相 關QoS參數。子計畫五則在整體計畫內提供多媒體 Application，本計畫可將QoS研究議題與設計機制運作 於Application，使得Application使用者得到QoS確保。

圖 27 本子計畫與其他子計畫之關連圖

在研究成果outcome 部份，本期研究成果已發表

兩篇國際期刊論文(Computer Networks 及 JISE Journal) 及四篇會議論文(IEEE ICCE、 CIT Conference & IEEE Radio and Wireless Symposium)。並已將現有研究成果

整合至總計畫之 Testbed 中，進度符合規劃。此外，

計畫執行迄今(三年)已培育出 1 位博士級及 7 位碩士 級人才，投入學術及產業研發行業。

七、 參考文獻

[1] Y. Wu, P.A. Chou, Q. Zhang, K. Jain, W. Zhu and S.Y. Kung, “Network Planning in Wireless Ad hoc Networks: a Cross-Layer Approach,” IEEE Journal

on Selected Areas in Communications, Vol.23, No.1,

[2] S.L. Kota, “Cross-Layer Design Challenges for Quality of Service Guarantees in Satellite Networks,”

Proceedings of Military Communications Conference, pp.1-7, Oct. 2006.

[3] E. Ekjic and Y. Tian, “Cross-Layer Collaborative In-Network Processing in Multihop Wireless Sensor Networks,”

IEEE Transactions on Mobile Computing, Vol.6, No.3, pp. 297-310, March 2007.

[4] Q. Liu, S. Zhou and G. B. Giannakis “Combining Adaptive Modulation and Coding with Truncated ARQ Enhances Throughput,” Proceedings of IEEE

Workshop on Signal Processing Advances in Wireless Communications (SPAWC 2003),

[5] S. Shakkottai, T. S. Rappaport and P. C. Karlsson

“Cross-Layer Design for Wireless Network,” IEEE

Communication Magazine, vol.41, no.10, pp.74-80,

[6] G. Pau, D. Maniezzo, S. Das, Y. Lim, J. Pyon, H Yu and M. Gerla “A Cross-Layer Framework for Wireless LAN QoS Support,” Proceedings of

International Conference on Information Technology:

Research and Education, pp.331-334, Aug. 2003.

[7] D. Chalmers and M. Sloman, “A Survey of Quality of Service in Mobile Computing Environments,” IEEE

Online Communication Surveys, vol.2, pp.2–10,

[8] B. Evans. M. Kalama, M.P. Kluth and S. Mourgues,

“Cross-Layer Improvement for TCP Westwood and VoIP over Satellite,” Proceedings of International

Workshop on Satellite and Space Communications,

[9] V. Mirchandani, M.R. Kibria and A. Jamalippour,

“Am Open-System 4G/B3G Network Architecture,”

Proceedings of IEEE International Conference on Communications, Vol.2, pp.1357-1361, May 2005.

[10] L. Lifeng and L. Gang, “Cross-Layer Mobility Management based on Mobile IP and SIP in IMS,”

Proceedings of the International Conference on Wireless Communications, Networking and Mobile Computing, pp.803-806, September, 2007.

[11] M.A. Melnyk, A. Jukan and C.D. Polychronopoulos,

“A Cross-Layer Analysis of Session Setup Delay in IP Multimedia Subsystem (IMS) with EV-DD Wireless Transmission,” IEEE Transactions on

Multimedia, vol.9, no.4, pp.869-881, June 2007.

[12] A. Anzaloni, M. Listanti and I. Petrilli,

“Performance Study of IMS Aythentication Procedures in Mobile 3G Networks,” Proceedings of

the International Conference on Wireless Communications and Mobile Computing,

[13] K.B. Johnsson and D.C. Cox, “QoS Scheduling of Mixed Priority Non-real-time Traffic,” Proceedings

of the IEEE 53

Vehicular Technology Conference,

[14] J. Chen, T. Lv and H. Zeng, “Joint Cross-Layer Design for Wireless QoS Content Delivery,”

Proceedings of the IEEE International Conference on Communications, vol.7, pp.4243-4247, June

[15] F. Xu, L. Zhang and Z. Zhou, “Interworking of Wimax and 3GPP Networks based on IMS,” IEEE

Communications Magazine, vol.45, no.3,

[16] IP Multimedia Subsystem (IMS), Stage 2, V7.6.0, TS 23.228, 3GPP, Dec. 2006.

[17] J. Rosenberg, G. Camarillo, A. Johnston, J. Peterson, Sparks, M. Handley and E. Schooler, SIP: Session

Initiation Protocol, RFC 3261, IETF, June 2002.

[18] M. Handley and V. Jacobson, SDP: Session

Description Protocol, RFC 2327, IETF, April 1998.

[19] Braden, Clark & Shenker, Integrated Services

Architecture, RFC 1633, IETF, June 1994.

[20] Blake, Architecture for Differentiated Services, RFC 2475, Dec 1998.

[21] N. Lin and M. Qi, “A QoS Model of Next Generation Network based on MPLS,” Proceedings

of the IFIP International Conference on Network and Parallel Computing, pp.18-21, Sept. 2007.

[22] D. Zhang and D. Ionescu, “QoS Performance Analysis in Deployment of DiffServ-aware MPLS Traffic Engineering,” Proceedings of the 8^th

ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, pp.963-967, Aug.

2007.

[23] L. Reis and P.R. Guardieiro, “An Enhanced Allocation Resource Mechanism for Diffserv Domains using Bandwidth Broker,” Proceedings of

the Telecommunications Symposium, pp.334-339,

[24] ITU-T Draft Rec Y, 1541-2002, Network Performance Objectives for IP-based Services.

附錄一

與子計畫二溝通之程式碼

#include "mysql.h"

#include <stdio.h>

#include <stdarg.h>

#include <stdio.h>

#include <string.h>

#include <errno.h>

//#include <resolv.h>

#include <signal.h>

#include <netdb.h>

#include <unistd.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <sys/types.h>

#include <stdlib.h>

int main(int argc, char *argv[]) {

MYSQL *conn;

MYSQL_RES *res;

MYSQL_ROW row;

char *server = "134.208.3.227";

char *user = "root";

char *password = "qweasd";

char *database = "qosmaster";

int sockfd, new_fd;

struct sockaddr_in server_addr;

struct sockaddr_in client_addr;

int sin_size, portnumber;

//char *total;

//char *remain;

char total[] =

" 321\n";

char remain[]="12 \n";

char buffer[1024];

char buffer1[1024];

int nbytes,nbytes1,check=0; conn = mysql_init(NULL);

/* Connect to database */

if (!mysql_real_connect(conn, server,

user, password, database, 0, NULL, 0)) { fprintf(stderr,

"%s\n", mysql_error(conn));

exit(0);

}

/* send SQL query */

if (mysql_query(conn, "SELECT * FROM qos where

no=2")) {

fprintf(stderr,

"%s\n", mysql_error(conn));

exit(0);

}

res = mysql_use_result(conn);

row = mysql_fetch_row(res);

// total[]='t';

// remain[]='e';

/* output fields 1 and 2 of each row */

//while ((row = mysql_fetch_row(res)) != NULL)

//printf("%s hello\n", row[1]);

//printf("%s %s\n", row[1], row[2]);

sprintf(total,"%s",row[2]);

sprintf(remain,"%s",row[1]);

mysql_free_result(res);

mysql_close(conn);

/* Release memory used to store results and close connection */

//port number

exit(1);

}

if((portnumber=atoi(argv[1])) < 0) { printf("Usage:%s portnumber\a\n", argv[0]);

exit(1);

}

// socket error

if((sockfd=socket(AF_INET,SOCK_STREAM,0)) ==

-1) {

//fprintf(stderr, "Socket error:%s\n\a",

strerror(errno));

printf("Socket error:%s\n\a", strerror(errno));

exit(1);

}

//family, address, port

bzero((char*)&server_addr,sizeof(struct

sockaddr_in));

server_addr.sin_family = AF_INET;

server_addr.sin_port = htons(portnumber);

//port number,Hhtons(16 bytes) netwro byte order

//htonl is for 32-bytes, binary presentation

//

if(bind(sockfd, (struct sockaddr *)(&server_addr), sizeof(struct sockaddr)) == -1) {

printf("Bind error:%s\n\a", strerror(errno));

exit(1);

}

printf("berfore listen\n");

// su

if(listen(sockfd,5) == -1) {

//fprintf(stderr, "Listen error:%s\n\a",

strerror(errno));

printf("Listen error:%s\n\a", strerror(errno));

exit(1);

} while(1) {

conn = mysql_init(NULL);

if (!mysql_real_connect(conn, server, user, password, database, 0, NULL, 0)) { fprintf(stderr,

"%s\n", mysql_error(conn));

exit(0);

}

if(inet_ntoa(client_addr.sin_addr)=='134.208.0.45')

{

/* send SQL query */

if (mysql_query(conn, "SELECT * FROM qos where

no=1")) {

fprintf(stderr,

"%s\n", mysql_error(conn));

exit(0);

} }

else if(inet_ntoa(client_addr.sin_addr)=='134.208.1.50')

{

/* send SQL query */

if (mysql_query(conn, "SELECT * FROM qos where

no=2")) {

fprintf(stderr,

"%s\n", mysql_error(conn));

exit(0);

} }

else

if(inet_ntoa(client_addr.sin_addr)=='134.208.1.111')

{

/* send SQL query */

if (mysql_query(conn, "SELECT * FROM qos where

no=3")) {

fprintf(stderr,

"%s\n", mysql_error(conn));

exit(0);

} }

else

{

/* send SQL query */

if (mysql_query(conn, "SELECT * FROM qos where

no=2")) {

fprintf(stderr,

"%s\n", mysql_error(conn));

exit(0);

} }

res = mysql_use_result(conn);

row = mysql_fetch_row(res);

sprintf(total,"%s",row[2]);

sprintf(remain,"%s",row[1]);

//total=row[2];

//remain=row[1];

sin_size = sizeof(struct sockaddr_in);

// socket

// clientaddress client_addr

*)(&client_addr), &sin_size)) == -1) { fprintf(stderr, "Accept error:%s\n\a",

strerror(errno));

exit(1);

} printf("Server get connection from %s\n",

inet_ntoa(client_addr.sin_addr));

// buffer

if((nbytes=read(new_fd, buffer, 1024)) == -1) { printf("Read Error:%s\n", strerror(errno));

exit(1);

}

buffer[nbytes] = '\0';

printf("I have received:%s\n", buffer);

//client

exit(1);

}

// buffer1

if((nbytes1=read(new_fd, buffer1, 1024)) == -1) {

printf("Read Error:%s\n", strerror(errno));

exit(1);

}

buffer1[nbytes1] = '\0';

printf("I have received:%s\n", buffer1);

if(check%2==0) {

// strcpy(remain,"123\n");

//client

if(write(new_fd, remain, strlen(remain)) == -1) {

printf("Write Error:%s\n", strerror(errno));

exit(1);

} }

if(check%2!=0) {

// strcpy(remain,"23\n");

//client

if(write(new_fd, remain, strlen(remain)) == -1) {

printf("Write Error:%s\n", strerror(errno));

exit(1);

} }

mysql_free_result(res);

mysql_close(conn);

close(new_fd);

check++;

} close(sockfd);

exit(0);

return 0;

}

與子計畫四溝通之程式碼

/**************************************************

*************************

* Copyright (C) 2008 by root

*

* root@134-208-3-227.ndhu.edu.tw

*

*

*

* This program is free software; you can redistribute it and/or modify *

* it under the terms of the GNU General Public License as published by *

* the Free Software Foundation; either version 2 of the License, or *

* (at your option) any later version.

*

*

*

* This program is distributed in the hope that it will be useful, *

* but WITHOUT ANY WARRANTY; without even the implied warranty of *

* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *

* GNU General Public License for more details.

*

*

*

* You should have received a copy of the GNU General Public License *

* along with this program; if not, write to the

*

* Free Software Foundation, Inc.,

*

* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *

***************************************************

************************/

/*#ifdef HAVE_CONFIG_H

#include <config.h>

#endif*/

#define _BSD_SOURCE 1

#include <mysql/mysql.h>

#include <pcap.h>

#include <ctype.h>

#include <errno.h>

#include <string.h>mysql_free_result(res);

#include <unistd.h>

#include <sys/socket.h>

#include <sys/types.h>

#include <arpa/inet.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <net/if.h>

#include <netinet/if_ether.h>

#include <netinet/tcp.h>

#include <sys/time.h>

#include <signal.h>

#include <stdio.h>

#include <stdlib.h>

/* default snap length */

#define SNAP_LEN 1518

int sockfd, count = 0;

char *SendSIPData[] = {NULL};

struct sockaddr_in servaddr, clntaddr;

const char *payload;

MYSQL *conn;

MYSQL_RES *res;

MYSQL_ROW row;

char *source_ip="127.0.0.1";

char *soucre_port="5060";

/* Ethernet header */

struct sniff_ethernet {

u_char ether_dhost[ETHER_ADDR_LEN]; /*

destination host address */

u_char ether_shost[ETHER_ADDR_LEN]; /*

source host address */

u_short ether_type;

/* IP?

ARP? RARP? etc */

};

/* IP header */

struct sniff_ip {

#if BYTE_ORDER == LITTLE_ENDIAN

u_int ip_hl:4, /* header

length */

ip_v:4;

/* version */

#endif

#if BYTE_ORDER == BIG_ENDIAN

u_int ip_v:4, /*

version */

ip_hl:4;

/*

header length */

#endif

u_char ip_tos;

/* type of service */

u_short ip_len;

/* total length */

u_short ip_id;

/* identification

*/

u_short ip_off; /* fragment

offset field */

#define IP_RF 0x8000

/* reserved fragment flag */

#define IP_DF 0x4000

/* dont fragment flag */

#define IP_MF 0x2000

/* more fragments flag */

#define IP_OFFMASK 0x1fff

/* mask for fragmenting bits */

u_char ip_ttl;

/* time to live */

u_char ip_p; /* protocol */

u_short ip_sum;

/* checksum */

struct in_addr ip_src,ip_dst; /* source and dest

address */

};

/* TCP header */

struct sniff_tcp {

u_short th_sport;

/* source port */

u_short th_dport; /* destination

port */

tcp_seq th_seq;

/* sequence number */

tcp_seq th_ack;

/*

acknowledgement number */

#if BYTE_ORDER == LITTLE_ENDIAN

u_int th_x2:4,

/* (unused)

*/

th_off:4;

/*

data offset */

#endif

#if BYTE_ORDER == BIG_ENDIAN

u_int th_off:4, /* data

offset */

th_x2:4; /*