嵌入式網路通訊裝置評比技術與工具之研發---子計畫一：嵌入式網路通訊裝置應用效能評比技術與工具之研發(中心分項)(I)

行政院國家科學委員會專題研究計畫 期中進度報告

嵌入式網路通訊裝置評比技術與工具之研發--子計畫一:嵌

入式網路通訊裝置應用效能評比技術與工具之研發(中心分

項)(1/2)

期中進度報告(精簡版)

計 畫 類 別 ： 整合型 計 畫 編 號 ： NSC 98-2220-E-009-049- 執 行 期 間 ： 98 年 08 月 01 日至 99 年 07 月 31 日 執 行 單 位 ： 國立交通大學資訊工程學系（所） 計 畫 主 持 人 ： 林盈達 處 理 方 式 ： 本計畫可公開查詢

中 華 民 國 99 年 06 月 30 日

行政院國家科學委員會補助專題研究計畫

□ 成 果 報 告

■期中進度報告

嵌入式網路通訊裝置評比技術與工具之研發--子計畫一:

嵌

入式網路通訊裝置應用效能評比技術與工具之研發(中心分

項)(1/2)

計畫類別：□ 個別型計畫 ■ 整合型計畫

計畫編號：NSC 98-2220-E-009-049

執行期間： 2009 年 8 月 1 日至 2010 年 7 月 31 日

計畫主持人：林盈達

共同主持人：

計畫參與人員：甘東杰 吳金龍 陳一瑋 江易達 陳李睿

成果報告類型(依經費核定清單規定繳交)：■精簡報告 □完整報告

本成果報告包括以下應繳交之附件：

□赴國外出差或研習心得報告一份

□赴大陸地區出差或研習心得報告一份

□出席國際學術會議心得報告及發表之論文各一份

□國際合作研究計畫國外研究報告書一份

處理方式：除產學合作研究計畫、提升產業技術及人才培育研究計畫、

列管計畫及下列情形者外，得立即公開查詢

□涉及專利或其他智慧財產權，□一年□二年後可公開查詢

執行單位：國立交通大學

附件一

中 華 民 國 99 年 5 月 30 日

行政院國家科學委員會專題研究計畫成果報告

計畫名稱：嵌入式網路通訊裝置評比技術與工具之研發 - 子計畫一：

嵌入式網路通訊裝置應用效能評比技術與工具之研發

計畫編號：NSC 98-2220-E-009-049

執行期限：2009 年 8 月 1 日至 2010 年 7 月 31 日

主持人：林盈達

計畫參與人員：甘東杰 吳金龍 陳一瑋 江易達 陳李睿

國立交通大學資訊工程系

1. 摘要

嵌入式系統平台已被大量應用在商用 及家用產品上如 PDA 和 WiFi Phone，但是 對於嵌入式系統網路裝置在使用者端的應 用效能上卻缺乏可用的測試工具，廠商在開 發產品之後無法精確得到其效能，當產品有 關於效能方面的問題也無從得知可以改善 的方式，為此，開發「嵌入式系統網路通訊 裝置應用效能評比工具」，除了要提供黑箱 測試數據外，更應設計對於開發者可進行加 強以及偵錯的灰箱及白箱測試，協助開發者 清楚了解產品在使用者端所遇到的缺點以 及相關改進的方法。 本計畫開發的項目，是針對目前熱門的 嵌入式系統網路通訊產品，進行相關網路應 用服務效能評比( 如: Throughput, Session Capacity, Session Rate, Voice Quality )，利用 NBL 現有的工具以及 Open Source 軟體，以 Repeatable、Scalable、Automatic、Integrated 等四個條件為前提，進行 1. 測試計畫及方 法之研發, 2. 對測試設備無依賴性之測試 工具研發, 3. 整合型測試工具研發，配合總 計畫提供的共通測試平台，提供各種不同層 級的背景流量，更能貼近實際上使用者端使 用的環境，在測試工具的開發規劃裡，預計 進行兩項測試工具的開發，其中包括：連線 量測試工具、SSL VPN 連線量測試工具以及 語音品質整合測試工具，這些都是目前所所 缺乏的應用效能測試工。達成對嵌入式網路 通訊裝置進行完整效能的測試及評比，除了 能幫助產品開發者進行效能改進及選擇適 合使用的元件平台，亦可做為學術上進行相 關研究時有實際上產品的數據供做先進技 術的研發，並將此系統原始碼公開，提供開 放原始碼社群使用及研究。 關鍵詞： 嵌入式系統、網路通訊裝置、網 路應用服務效能、開放原始碼

2. 緣由與目的

晶片設計以及製程技術的進步，晶片組 以及其相關整合產品效能不斷的提升且價 格更趨便宜，使得許多平常可見的商用或家 用產品皆可利用嵌入式系統實現之，尤其現 在更強調這些產品的網路連通性，以及彼此 之間與個人電腦和網際網路的整合性，網路 功能不再是個人電腦的專利，而是各項資訊 產品、家電等各種產品用來整合個人和公司 資訊及各項功能的方案；然而針對這類型的 整合性產品(ex: PDA, WiFi Phone)卻缺乏可 以進行嵌入式網路通訊系統效能評比的方 式，針對單一元件可以直接進行該元件測試 即可達成，然而對 System Vendor 而言卻非 如此，Chip Vendor 可以經由單一晶片測試 達到其所需求的結果，但是 System Vendor 卻必須將目標放在產品的系統效能上，除此

之外現在 Chip Vendor 已漸漸走向 Total Solution 的模式，也就是說 Chip Vendor 要自 己來開發 System，因此更會期待一個測試中 心可以對整體系統的效能表現作一個完整 的測試，所以子計畫一的目標應考慮整合好 的產品所必須要了解的系統效能，並且要能 經由不同的應用程式測試，達成對整體系統 的分析，根據不同的嵌入式網路通訊系統 (註一)所欲得之結果(註二)，開發針對不同 型態(註三)的測試項目。 註一: handheld、server、network。 註二: Throughput、Latency、Bandwidth Consumption、Response time、TCP connection rate/capacity IPSec tunnel rate/capacity、Voice Quality、SIP call rate/capacity、WLAN association rate/capacity。

註三: Black, Grey, White Box。

Black box 測試：把待測物視為一個黑盒 子，餵入合成的存取樣式，從外部測量基本 的效能的讀數，如 Throughput。這種測試可 以測出在通用或是已知的特殊情況的行為 及效能。 Gray box 測試：不同的網路通訊裝置有其 特殊的使用機制，如 NAT/Firewall 上設定的 規則，必須進入 Gray Box 階段。並透過廠 商提供的控制介面，進一步的從待測物上取 得 black box 讀取不到的數據，如：Default Rules 和 Matching priority，進行 Throughput 和 Latency 效能評估。 White box 測試：主要用來取得更詳盡的測 試數據與事件截取，因為有了原始碼，則可 以直接針對該演算法取得所有與效能相關 的數據。 而評斷嵌入式系統效能的好壞可以由 兩個方向進行區分，一者為硬體上的效能， 指的是裝置上的 CPU、Memory 和 I/O 等裝 置的效能，例如 CPU 的處理速度為一秒鐘 可以執行多少指令集，記憶體容量有多少、 能以多快的速度接受存取，I/O 在複製、搬 移等動作時，每秒可以存取多少容量；另一 者 為 網 路 系 統 效 能 ， 如 Throughput 、

Latency 、 Loss 和 Session Capacity 等 ， Throughput 是對於網路系統最直接的評斷 方式，直接指出該網路系統在不造成封包丟 棄 的 狀 態 下 ， 能 處 理 的 最 大 數 量 封 包 ， Latency 則是封包從進入該網路系統至離開 該網路系統時，在系統中停留的時間，即為 系統所造成之延遲，Loss 則是當輸入 loading 超過系統所能負荷的最大負載時，所造成的 封包遺失為多少，Session Capacity 則是在測 試針對某單一通訊協定(如 TCP)，網路系統 能承受的連線數量為多少；本子計畫將針對 嵌入式系統網路裝置效能部份進行應用效 能評比工具開發。

3. 研究內容

本計畫研究所開發之工具為 SSL VPN Tunnel Tester (SSLTC) 與 Integrated Voice Quality Test(IVQT)，其詳細架構如下： „ SSLTC 用戶端可以利用 VPN 方式連線，進行私密 安全連線，以防止資料在網路上進行傳輸 時，遭到駭客竊取，但是加密連線必須使用 大量的運算，以及過濾，使得該類型的網路 安全產品可容納的 VPN 容量無法達到實際 需求，考量在大部份的情況下，利用 VPN 進行連線時，許多的連線都是在進行網頁瀏 覽，因此並非需要在 Client 和 Server 端之間 保持建立連線的狀況態，也可由此減輕 VPN 網通裝置的負擔，利用 SSL VPN 的方式進 行資料的流通，以 Linux 為 SSL VPN 的 client，產生同時多條的 SSL VPN tunnels (Full Tunnel Mode)與 users 來連上 SSL VPN server，可用來自動化測試 tunnel capacity、 user capacity、stability。

本系統的軟體架構主要是由幾項元件 所構成: Traffic Generator– SSL VPN Tunnel, Traffic Generator – Background Traffic, Controller，以下說明各個元件所扮演的角色 以及如何進行測試與蒐集數據：

Test Client SSLVPN 裝置 後端 Server SSL VPN Tunnel 用一台 PC 製造出同時上千條的 SSL VPN tunnels。

Traffic Generator – Background Traffic：除

了建立 SSL VPN tunnel 外，也可產生網路流 量導入 SSL VPN tunnel 中，如 HTTP、FTP.. 等等。

Controller：會使用一台 PC 作為 controller，

controller 的 功 能 一 是 用 來 trigger traffic generators ， 二 是 用 來 抓 取 DUT 上 的 information 來判斷該次測試的結果是 Pass or Fail。 SSLTC 之系統架構如下所示： 在 Client 上先執行 pptpd，然後執行測 試程式。測試程式會先登入 SSLVPN 裝置， 認證成功後由 pptpd 呼叫 pppd 建立 ppp 介 面，連到後端 server 所在的 subnet，之後再 由測試程式透過建立好的 SSLVPN Tunnel 向後端 server 抓取資料，驗證是否成功連線。 目前支援 capacity 及 throughput 兩種測 試模式，capacity 會不斷建立 tunnel，直到 指定的數量或是所有帳號都用完為止，每個 tunnel 建立的間隔時間為 RATE。每個 tunnel 建立後，會依據指定的 TRAFFICRATE 時間 間隔，向後端 server 抓取資料，驗證 tunnel 是否正常。 Throughput 測試會先建立指定數量的 tunnel。等全部建立好後同時向後端 server 抓取資料。每條 tunnel 會各自計算 throughput(總傳輸的資料量/(結束時間-開始 時間))，另外也會算總共的 throughput，以 全部 tunnel 的傳輸量除以(所有傳輸完成時 間-開始傳輸時間)。 目前支援 capacity 及 throughput 兩種測 試模式，capacity 會不斷建立 tunnel，直到 指定的數量或是所有帳號都用完為止，每個

tunnel 建立的間隔時間為 RATE。每個 tunnel 建立後，會依據指定的 TRAFFICRATE 時間 間隔，向後端 server 抓取資料，驗證 tunnel 是否正常。 Throughput 測試會先建立指定數量的 tunnel。等全部建立好後同時向後端 server 抓取資料。每條 tunnel 會各自計算 throughput(總傳輸資料量/(結束時間-開始時 間))，另外也會算總共的 throughput，以全 部 tunnel 的傳輸量除以(所有傳輸完成時間-開始傳輸時間)，時間計算如下圖的 部 分。 程式首先會讀取命令列參數，取得設定 檔名與要測試 tunnel 數，如果不是前面列的 參數(如 TRAFFIC、RATE)，就建立一個 test instance，傳入帳號密碼及其他資訊，若密 碼後有接 IP(以,分隔)，則使用這組帳號密碼 連線時，會連到此 SSLVPN 裝置，而不是 DEVICE 指定的 IP。全部建好後，就依設定 的間隔執行。每一個 instance 用一個 thread 跑，所以測試時會有很多個 thread 同時跑。 Tunnel 建立流程如下:

(1) getAuthCookie 連到 SSLVPN 裝置的 https 網頁，以給定 的帳號密碼登入後取得 cookie。 (2) getIPInfo 用第一步取得的 cookie，一樣連到 SSLVPN 的 HTTPS，送出: CONNECT 127.0.0.1: 10443 HTTP/1.1\r\n Host: 127.0.0.1\r\n Cookie: authtok= xxxxxxx\r\n\r\n 若回傳 HTTP/1.1 200，代表成功，之後 傳送如下，抓取 IP 設定資訊: GET /L2TunCFG xxxxxxx (3) resolvIPInfo 分割第二步抓到的資訊，取得 interface IP 等資訊。 (4) getDeviceConnection 同樣連到 SSLVPN HTTPS，送出： Get /L2TunREADY xxxxxxx 之後此連線要持續，整個 SSLVPN Session 中不可中斷。 (5) getServerConnection 與本機的 pptpd 溝通後會先額外送一個 含有第三步 IP 資訊的封包，以及本地 GRE port，交給 pptpd 的 getPreHeader 處理。Pptpd 呼叫 pppd 建立 interface 後， 會呼叫 extra/etc/ppp/ip-up 建立 routing entry，ppp interface 關閉時也會呼叫 extra/etc/ppp/ip-down 刪除 routing entry。 (6) doPPTP

分成兩步同時執行。首先是 RecvServer 建立一個 thread，由 test.java 中的 recvServer()函式處理。從 pptpd 抓取封 包送至 SSLVPN 裝置。另外是

RecvDevice，由 test.java 中的 recvDevice() 處理。從第四步的連線抓取封包，去除 header 後寫至第五步的 pptpd socket 建立 後取得的 gre socket。 流量測試的程式，依據設定檔中的 TRAFFIC 設定，呼叫 HttpClient、FtpClient、 SmbClient 執行。 而統計流量時，每個*Client 會各自計算 總共收到的 byte 數，再除以時間。另外 test client 會傳進一個 AtomicLong，讓每一個 client 將他收到的 byte 數也加進去，以計算 總共的 throughput。 而在 SmbClient 部分，因為是使用 jcifs library 處理，沒辦法抓到一開始溝通， 登入部份的封包，所以只計算下載資料的封 包。時間上會另外計算溝通所佔的時間，計 算 throughput 會扣掉所有這段時間的平均。 „ IVQT

PDA 或是 WiFi Phone 可以透過有線及無線 網路進行 VoIP 連線，利用 SIP 協定進行撥 打電話的動作，再藉由直接或間接使用 RTP 協定封包進行語音封包傳送，利用有線的方 式進行 VoIP 連線不必考慮移動性的問題， 但是在無線網路環境下則不同，除了無線網 路使用的 MAC Layer 協定(主要是

CSMA/CA)限制了 VoWiFi(Voice over WiFi) 使用上無法充份使用預定的頻寬，實際使用 上還有關於在無線網路下 Roaming 等問 題，所以在有線及無線網路的環境下，皆可 利用各自條件不同的變因，使用 PESQ 測試 語音品質的標準，測試對於待測物品的語音 通話品質影響。 本系統的軟硬體架構主要是由幾項元 件所構成: NIST-Net Controller，Background Traffic Generator，Azimuth Platform， Integrated Controller，以下說明各個元件所 扮演的角色以及如何進行測試與蒐集數據:

NIST-Net Controller：需能支援使用

NIST-Net 控制對於網路環境的影響，如在收 話端與受話端之間 Traffic 受環境影響的控 制，封包延遲或 Loss 等條件，用以測試在 該環境下對於語音通話品質的影響。

Background Traffic Generator：需能支援

在不同型態的Background Traffic之下，擷取 語音相關的封包進行語音品質測試，

Background Traffic可以為HTTP,FTP, or P2P etc.，藉以觀察在不同的traffic以及不同的 loading之下對Voice Quality的影響。

Azimuth Platform(For Wireless Only)：利

用 Azimuth 平台進行 RF Attenuator 控制，可 以擬似對於 WiFi Phone 的移動模式，藉以 測試在移動狀態中的 WiFi Phone 對於 Voice Quality 的影響，藉由本測試可以分析關於 WiFi Phone 與 AP 在移動態狀下的適應性， 由本測試可以進一步進行在移動中需進行 Roaming 時，WiFi Phone 對於 Roaming 機制 的調適，選擇以何機制和時機進行 Roaming 的動作，以及在 Roaming 的同時對於語音品 質的影響為何。 Integrated Controller：上面的測試都是只 有針對單一的情況進行測試，但是這樣的測 試無法進行多次的重複使用，每次進行測試 時都要重新再設定不同的環境和不同的條 件及劇本，做一次測試要花費許多的時間進 行其它工具的設定，再者在動態設定的情況 下，會造成各工具之間 Timing 的非同步， 造成測試不精確，因此本項目支援的目的是 要做到在測試時可以利用單一視窗介面，進 行對 WiFi Phone, NIST-Net 和 Azimuth 同步 的控制以及批次處理。

IVQT之整體系統架構如下所示：

IVQT之自動化控制架構：

IVQT之程式架構與Work Flow：

整個系統的軟體架構可以分成三部 份：Platform Controller、Traffic Controller 及 Traffic Parser，初始時可以利用 tcl 進行對 VoIP 產品與 AP 間的距離，控制 Azimuth 的 RF Module 造成 Voice Phone 與 AP 之間有訊 號上的衰減等因子，透過距離與 RF 訊號衰 減的公式，進行 RF 訊號強度調整，同時套 用入距離動態調變，並 動相關 module(ex: 利用 chariot 產生背景流量等)，而整個系統 動同時，VQT 亦開始進行 voice quality 的 量測，包含語音訊號產生、語音訊號傳送與 語音訊號品質量測等。最後會將測試的結果 及過程，將相關的記錄檔送至 Traffic Parser 進行後端的分析，以及語音量測分數產生， 達成對語音訊號品質量測的結果及報告。 IVQT 之 Stack Diagram(Platform)：

IVQT之Stack Diagram(Traffic Control and Analysis)：

4. 研究成果與討論

本計畫已經能利用相關的工具以及已 經開發的程式及模組，進行 SSL VPN Tunnel 及 Voice Quality 量測的工具。其中 SSL VPN Tunnel 部份，由於目前 SSL VPN Tunnel 技 術並沒有相關的標準製定，因此目前已經與 多家知名大廠合作，廠商也願意提供產品在 進行研發時將所使用的 protocol stack 與本 計畫合作，在本計畫本所使用的建立 SSL VPN Tunnel 技術有一定的透明度，使本計 畫中研發來給 SSL VPN 相關技術所使用的 測試計畫，不但有黑箱測試，同時也有灰箱 測試的部份，有助於本計畫團隊對於 SSL VPN 技術應用在學術用、商用平台上能精 確的了解其 Tunnel 建立技術；而 IVQT 部 份，由於涵蓋相當大範圍的不同技術(Voice Codec, Voice Generator, Voice Quality Tester, 802.11a/b/g, Background Traffic)及開發工具

(Azimuth, Abacus, Net-NIST, IxChariot)的整 合，雖然大部份的內容都是黑箱測試，但是 對於各項通訊協定及語音編碼、語音量測等 相關的標準的了解，有助於未來本團隊在進 行相關工具開發及學術研究的延展性，同時 整合多項測試工具實行利用有限的空間，實 施更大規模的測試，有助於未來在工具開發 及執行相關測試專案時，能接受各種不同腳 本進行有彈性的調整及高度客製化。

Reference

[1] Tilman Wolf and Mark Franklin, “A Telecommunications Benchmark for Network. Processors,” Proc. of IEEE International Symposium on.

Performance Analysis of Systems and Software, 2000.

[2] M. R. Guthaus, J. S. Ringenberg, D. Ernst, T. M. Austin, T. Mudge, and R. B. Brown, “MiBench: A free, commercially representative embedded benchmark suite," IEEE International Workshop on Workload Characterization, pp. 3-14, 2001.

[3] S. Bradner, Bechmarking Terminology for Network Interconnection

Devices.RFC1242, July 1991

[4] S Bradner, J McQuaid, Benchmarking Methodology for Network Interconnect Devices, RFC 2544, March 1999

[5] D. Newman, RFC 2647 - Benchmarking Terminology for Firewall Performance, August 1999

[6] Yunfei Wu, Stephan Wong, and Stamatis Vassiliadis, “Real-Time Network

Processing: An Investigation,” [7] Manohar Castelino and Frank Hady,

“Tutorial on NPF's IPsec Forwarding Benchmark,” Network Processing Forum [8] Lee Eng Kean, Sulaiman bin Mohd. Nor,

“A Benchmarking Methodology for NPU-Based Stateful Firewall,” IEEE

2003

[9] R. Ramjee, J. Kurose, D. Towsley, H. Schulzrinne, "Adaptive Playout Mechanisms for packetized Audio Applications in Wide Area Networks", Proceedings of the Conference on Computer Communications (IEEE Infocom), Toronto, Canada, 1994 [10] K. Fujimoto, “Adaptive Playout Buffer

Algorithm for Enchancing Perceived Quality of Streaming Apllications,” Osaka University, Japan, February 2002 [11] Henning Schulzrinne, Sankaran

Narayanan, Michael Doyle and Jonathan Lennox, "SIPstone - Benchmarking SIP Server Performance," April, 2002 [12] C. Lee, M. Potkonjak and

H.Mangione-Smith,”MediaBench: A Tool for Evaluating and Synthesizing Multimedia and Communications

Systems,” Micro-30, November 1997.SJ Shah, “Network benchmarking,”

netprl.calpoly.edu, 1997

[14] Sandra Johnson, Gerrit Huizenga, Badari Pulavarty, Performance Tuning for Linux Servers,IBM Press, May 2005

[15] Netfilter: firewalling, NAT and packet mangling for Linux,

http://www.netfilter.org [16] Tcl, http://tcl.sourceforge.net/ [17] Netperf, http://www.netperf.org/netperf/ [18] Netio, http://www.nwlab.net/art/netio/netio.html [19] ipbench, http://ipbench.sourceforge.net/ [20] EEMBC, http://www.embedded-computing.com [21] NIST NET, http://www-x.antd.nist.gov/nistnet/ [22] Azimuth Systems, http://www.azimuthsystems.com/ [23] Spirent, http://www.spirentcom.com/ [24] Radcom, http://www.radcom.com [25] NBL, http://www.nbl.org.tw