章節簡介

本篇論文在稍後的章節編排與簡述如下：第一章描述本篇論文的研究動機，

以及本篇論文希望達到的目標。第二章為背景知識概述，包含中介軟體簡介、跨 層信號簡介、具網路感知應用程式介紹、程式化換手策略、多網路整合及 Linux 下使用者空間和核心空間的訊息交換機制相關討論及研究。第三章則為介紹與本 論文相關的文獻，包括目前正在制定的兩個標準 IEEE 802.21 及 Toward Open and Unified Link-Layer API，和本實驗室之前對於在 Linux 事件通知機制的相關 研究。第四章接著說明我們所開發的整合平台之系統架構與其內各個軟體元件。

第五章便介紹我們實作本系統的各個細節，包含了軟硬體架構、各元件互動機 制，及核心修改部份。第六章將介紹我們所開發出來的中介軟體成果及貢獻。其 中包括如何開發具網路感知的應用程式的範例，我們會舉出一個簡單的換手策略 程式和兩個使用者常用的應用程式 VoIP 及 FTP。最後，第七章對本論文做出總 結，以及未來的研究方向。

第 2 章 背景知識介紹

2.1 中介軟體簡介 (Middleware)

根據 ［1］的定義，中介軟體屬於軟體層，它是藉於作業系統上層、應用程 式下層間的軟體。

Figure 2-1 中介軟體概觀

對於程式設計者而言，中介軟體提供比作業系統更高階的系統函式和系統支 援，因此使用中介軟體來開發程式有以下幾點好處：

z 所開發出來的程式更具移植性 z 讓程式設計員更有生產力

z 可以降低系統相關程式碼錯誤的機會

藉著中介軟體提供較高階的系統函式，中介軟體可以遮蔽許多系統上不同的 異質性。

以下列舉出一些可以藉由中介軟體所遮蔽掉異質性的情況:

z 中介軟體可以遮蔽掉各種的網路存取技術

„ 如：數位電視的開發 (訊號可以透過各種不同的方式接收)

二

z 中介軟體可以遮蔽掉不同作業系統的異質性

„ 如：Java Virtual Machine

z 中介軟體可以遮蔽掉不同的程式語言

„ 如：Java RMI

本論文以中介軟體的方式來發展平台，其中一個目的就是為了遮蔽掉不同作 業系統的異質性。

程式開發人員可以使用以下各種不同的方法來使用中介軟體來開發軟體。

z 中介軟體提供函式庫和程式設計界面

„ 如：Linda、本論文提供的方法 z 從一開始就提供程式設計語言

„ 如：Java 和 Java Virtual Machine

z 提供介面定義語言 (Interface Definition Language) 用來映射到程式語言

„ 如: CORBA

接下來再來介紹各種不同的中介軟體類型：

z Distribute Tuples：(a, b, c, d, e)

„ Relational Database, SQL

„ Linda and Tuple spaces z Remote Procedure Call (RPC)

„ 使得遠端的函式可以在本地端被查詢 z Message-Oriented Middleware (MOM)

„ 程式開發員藉著訊息和中介軟體溝通

„ 本論文所實作出的中介軟體屬於此類 z Distributed Object Middleware

„ DCOM/SOAP/.NET 802.11 無線區域網路，和個人行動數據服務的GPRS以及 3G、PHS等，及最近標 準剛剛定好，產品正要開始上市的 802.16WiMAX無線網路。Table 2-1 顯示了目 前常見的不同無線網路存取技術的標準、最大傳輸速率和使用頻帶。

Table 2-1 各種常見異質無線網路的相關資訊 ［8］

Network Standard Data rate Frequency band Cellular Networks GSM data (2G)

GPRS (2.5G)

IEEE 802.11a IEEE 802.11g IEEE 802.11n

1, 2, 5.5, 11 Mbps Bluetooth IEEE 802.15.1 721 kbps (BT 1.1)

2 – 20 Mbps (BT 2.0)

2.4 GHz

WiMAX IEEE 802.16c 134 Mbps 10 – 66 GHz

現今無論是筆記型電腦，平板電腦，個人數位助理或是智慧型手機在硬體上

Figure 2-2 顯示了一個搭載WLAN及GPRS網路模組的手機在異質網路間的漫 遊。

當使用者在不同的異質網路間換手時，會受到影響的就是各個網路應用程 式，因為在不同的網路間換手時，正在通訊的兩個應用程式間的會談 (Session) 會斷掉。所以在過去有各種方法被提出用來保持應用程式會談的持續性 (Session Continuity) 如SIP［16］及Mobile IP［17］。可是不論是 SIP 或著是 Mobile IP 都會遇到一個問題，就是負責掌控SIP或Mobile IP的程式如何得知使用者切換網 路了呢？過去這一部份都是由使用者自行下達指令來告訴SIP作Re-Invite的動作 或通知Mobile IP作Binding Update的動作，不過這顯然不符合使用者的方便性。

因此本論文所提供事件通知機制可以幫助架構在SIP的程式得知使用者切換網路 的事件後馬上作Re-Invite的動作，或是控制Mobile IP的Daemon得知使用者切換 網路的事件後直接作Binding Update的動作，對於多個異質網路的整合有極大的 幫助。

2.3 跨層設計簡介 (Cross Layer Design)

Figure 2-3 顯示出一個傳統的無線行動網路的架構。在此架構之下，標準的網路 堆疊協定 (e.g. TCP/IP［18］) 會被實作在各個點上 (e.g. Base station、Access Point、Mobile Device) ，以此保證該系統可以在目前已發展成熟的網路上使用。

Figure 2-3 傳統的無線行動網路架構

參考 Figure 2-4 傳統的協定堆疊是以階層 (layer) 的方式設計和實作的，藉著 分層可以清楚地將各層需要實作的功能抽象分離出來。因此各層間不需互相知道 其它層的狀態，只要把自己該層的事情作好就行了。

Figure 2-4 TCP/IP protocol stack

但在 ［19］中有提到依據分層所設計的協定堆疊在無線行動網路的環境下運 作起來是沒有效率的，這起因於無線網路連結的不穩定性及行動裝置天生就沒辦 法搭載太多的資源。

在過去已經有許多想要藉由跨層回饋 (Cross Layer Feedback) 來增進目前協

跨層回饋的機制是指在協定堆疊中每個不同的協定層間可以互相的互動，以 下舉出幾個例子。

z TCP 層可將封包遺失的資訊告知 Application 層，這樣 Application 就可以 根據這些資訊來調整自己發送封包的速率。

z Link/MAC 層可以調整 Physical 控制的 power 大小來控制 bit-error rate。

z Link 層重傳封包的次數可以當作是目前 Channel 的狀況的測量，TCP 層可 以藉著該資訊調整 retransmission timer。

z Application 層也可以藉著 Link 層得知目前 Link 的好壞來調整封包發送 速度率。

在 ［22］篇文章中提到在目前現有在使用的協定堆疊以及網路架構都沒有納 入多重介面的特性作為考量，在該篇文章之中也提及，在進行垂直換手的時候 (Vertical Handoff) ，由於不同網路接取技術的特性相差很多，因此會對系統效能 造成很大的傷害。由於如此，該篇文章認為應該存在著跨層 (Cross-Layer) 的通 知機制，使得驅動程式的事件可以傳達至協定堆疊內的各層，如 Figure 2-5。

Figure 2-5 顯示了許多資訊可以在協定堆疊內的不同層中傳遞，如Security、QoS、

Mobility及Wireless link adaptation。

Figure 2-5 跨層設計概念示意圖 ［22］

行動漫遊機制時通常會遇到一個嚴重的問題，就是行動管理程式缺乏底層網 路的資訊，而不能做有效的行動管理。而在異質網路間換手時會產生嚴重延遲，

以至於不能提供良好的服務品質。然而這類行動管理程式通常是使用者空間的應 用程式，傳統上，介面管理程式會週期性的發出系統呼叫，以取得底層介面的資 訊 (例如網路介面的種類、頻寬或連線狀況)。但是，由於網路介面的狀態改變 可能不會如此的頻繁，因此頻繁的發出系統呼叫可能會造成系統多餘的負荷。此 外，在需要快速換手的情況下，行動管理程式必須對網路介面的狀態改變做出迅 速的反應，而在傳統的狀況下，網路介面狀態更新的頻率取決於程式發出系統呼 叫的頻率，發出系統呼叫的頻率愈高，就愈容易得到即時的資訊，當然對系統的 負荷也就愈大。

因此本論文導入了跨層網路設計的概念，能提供底層網路資訊給使用者空間 的行動管理程式或其它應用程式，並透過我們設計的事件觸發機制，讓相關程式 能夠快速地被告知底層網路的改變，並做出適當的反應，進而提供良好的服務品 質。

2.4 具網路感知應用程式簡介

可以根據目前所處網路狀態來調整本身行為的應用程式稱為具網路感知的應 用程式。

具網路感知的應用程式也算是一種跨層設計的應用，只是把協定堆疊各層的 資訊都傳達給應用層。而用來處理異質網路間換手的行動管理員程式也是屬於具 網路感知的應用程式，因為行動管理員程式若是無法得知網路情況，則行動管理 員程式如何作有效的換手？最低限度也必需要知道每張網路界面卡的連線狀 態、連線品質、訊號強度等資訊，這樣行動管理員才可用取得的資訊來做決定要

傳統的網路程式設計是不知道底層的網路狀態的，所以我們會常常看到 FTP 或 Email 的程式，在連線失敗後會設一個計時器，等到時間倒數完了再試一次，

是嘗試及錯誤 (try & error) 的作法。但如今在多模行動裝置下，使用者也會比以 往更具有移動性，因此再用過去的方式來設計網路應用程式，會顯得沒有效率。

如果在一開始設計網路應用程式的時候就納入網路底層狀態的考量，相信所開發 出來的程式會更適合以後擁有高度移動性的使用者。如影像串流客戶端 (Video Streaming Client) 的應用程式如果有辦法得知目前連線網路的頻寬狀態，該客戶 端應用程式就可以通知影像串流伺服器 (Video Streaming Server) 根據客戶端目 前的頻寬來調整撥放的品質。

現今也有許多關於具網路感知應用程式方面的研究文獻，可參考 ［3］［23］

［24］［25］［26］［27］［28］。

2.5 Linux 下使用者空間和核心空間的訊息交換機制

核心可以通過各種不同的方式將核心內部的訊息提供給使用者程式。本節將 介紹 Linux 系統下使用者程式與核心溝通的機制。

2.5.1 procfs (/proc filesystem)

這是一個虛擬檔案系統，通常掛載在 /proc 目錄下。核心透過檔案的方式將 核心內部訊息傳遞給使用者空間的程式。因為是以檔案的形式存在，因此我們可 以用 cat 或著是 more 指令來讀取核心訊息。甚至可以用導向符號 “>＂將訊息 傳遞給核心。

2.5.2 ioctl 系統呼叫

iotcl (輸入/輸出控制)系統呼叫可以用來操作一個檔案描述子。ioctl 通常用來 作一些設備的特殊操作。ioctl 也可以用來操作 socket 描述子來控制網路，在一 些網路管理程式上就是使用 ioctl 來操作 socket 描述子來控制網路，如 ifconfig 和 route 等。

讓我們以 ifconfig 為例子。ifconfig 就是使用 ioctl 與核心溝通的。如果系統

讓我們以 ifconfig 為例子。ifconfig 就是使用 ioctl 與核心溝通的。如果系統