無線通訊應用協定之實作

無線通訊應用協定之實作

An Implement of Wireless Session Protocol and Wireless Transcation Protocol

台大資訊系 分散式計算實驗室

2000 年 4 月 17 日

摘要

本文研究及討論無線通訊應用協定(WAP Wireless Application Protocol)的 會議層(Session Layer)，及交易層(Transaction Layer)的協定內容及程式實作。

並討論無線通訊應用協定會議層協定(WSP)，交易層協定(WTP)，中無線環境協 定設計的觀念，並與程式實作相驗證。

程式實作使用 Java 語言，利用其跨平台的特性及強大的網路功能，使程式 實作能更清晰。這個系統的主要功能可由上下兩層來說明:

(1) WSP 往上銜接應用層以 Java 撰寫的瀏覽器(Browser)，同為以 Java 撰寫，

可直接呼叫 WSP 所提供的功能。

(2) WTP 向下使用 Java 提供的網路 API，走 UDP 協定，只要在能夠使用 UDP 的網路中即可使用本系統。

為保證程式的正確性，本系統以已確定可正確運作的 Nokia Server 為測試對象，

確認本系統可以正確的扮演客戶端(Client)角色，與 Nokia Server 對話。

Java API WSP API

UDP WTP Machine WSP Machine WAP Browser

Figure 1 The Architecture of WAP Protocol Implementation

導言

近年來隨網際網路的發展與科技的進步，即使是一般人，對資訊也有者大量 而急迫的需求。而無線通訊科技在近年的蓬勃發展，已經漸漸與一般大眾的生活 結合，故終於有能將無線通訊與擁有無限且快速資訊的網際網路相結合的無線通 訊應用協定(WAP)的誕生。

無線環境具有許多特殊性質，使得必須特別為這些性質設計協定，而不能直 接架構在既有的網際網路之上。所以，無線通訊應用協定在設計上有者根本的改 變，不採用網際網路的四層架構，以因應無線通訊的幾項性質。

無線通訊的特性包括: (1)低頻寬，即使隨訊號處理技術的進步，能夠大幅提 昇無線網路的頻寬，但無線通訊的頻寬依然遠遠落後有線通訊，(2)漂移，行動 中通訊(Roaming)，也就是俗稱的漫遊，無線通訊中機台可能是隨時移動的，可 能在通訊中會從一個網域移動到另一個網域，這也是傳統網際網路中 TCP/IP 無 法解決的問題，這個問題主要由網路層解決，不在本文的討論範圍之內，(3)易 斷線，高延遲時間，這兩項因素在無線通訊中是最根本的問題，由於以傳輸介質 的限制，無線應用的協定必定需要考慮這兩項因素，在 WTP 的設計中，對於時 間限制及重傳的機制都有妥善的規劃。

而且，無線通訊應用協定的設計是完全模組化的，也就是各層的權責區分相 當明確，所以在端對端的層次，我們完全可以在傳統網際網路中測試 WSP 及 WTP 的程式實做，而無須在無線網路上進行。

WAE

WSP Use WAP Technology Outside WAP

WTP

WDP UDP

IP Non-IP Barear Network

Figure 2 The WAP Stacks

WTP 的設計觀念

WTP 為「無線交易協定」(Wireless Transaction Protocol)三個英文字的縮 寫，其中的 T 乃指「交易」(Transaction)，不同於 ISO 提出的 OSI 七層模型中 的傳輸層(Transport Layer)，強調該層協定的運作以一筆筆的交易為單位，但在 設計上和 OSI 模型中的傳輸層相同，為端對端(peer-to-peer)通訊的最底層，不 用考慮其下網路層(Network Layer)中整個龐大網路間資料的繞送(route)，只專注 於確認提出需求與回應的兩台機器間的通訊。資料間正確的交換即稱為交易，

WTP 這一層的主要目的之一即為提供 WTP 使用者，也就是上一層，一個可信 賴的資料傳輸，使上層不需考慮任何資料遺失的問題，故 WTP 中提供一套等待 時間與確認的機制，使得 WTP 能在無線網路的易斷線，高延遲等惡劣情況下提 供正確的資料傳輸。

且 WTP 處理資料的單位動作為交易，交易只簡單而明確的分為三個類型，

為的是讓確認資料正確交換的速度能更快，且更簡單。舉例來說，WSP 在一個 會議中，其中 WTP 可能已經進行了數十個交易，但 WSP 完全不需要了解這些 交易是如何進行的，只要把它想要送出的結果或提出的要求交給 WTP，WTP 就 能正確的送到目標。

Gateway

Bearer Adaption

WTP WSP WAE/Apps

Subnetwork Tunnel Bearer

Adaption Bearer

Adaption WTP WSP WAE

Mobile Others

Server Our Implementation

Figure 3 The WTP Architecture

WSP 的設計觀念

在 WTP 成功提供兩端間一個可信賴的通訊方法後，WSP 得以專心處理兩 台機器間的問題，如網路，機器狀況(Capabilities)，與伺服端要求資料等。

WTP 中的兩端分別為交易的驅動者(Invoker)，和回應該要求的回應者 (Responder)。WSP 中則分為客戶端(Client)與伺服端(Server)，但客戶端不一定 是 WTP 的驅動者，它也可能是回應者，伺服端也同樣可能在交易中扮演這兩種 角色，雖說客戶端與伺服端都需提供 WTP 驅動者與回應者的功能，但在 WSP 中則對無線環境中輕客戶端(thin Client)的要求做了設計，客戶端在 WSP 這一層 的功能要求較伺服端簡單，我們在低功率，體積小限制下的行動通訊工具不應負 荷過分龐大的協定要求。

應用層藉由 WSP，只要單純的取得或送出所需要的資料即可，在無線通訊 應用協定的應用層中使用最廣泛，也是最重要的應用就是瀏覽器，所以 WSP 對 於瀏覽器所需用到的功能必須特別加以設計，故 WSP 中有許多提供給瀏覽器的 服務，與 HTTP 定義中的功能相類似，如 GET，POST 等，WSP 的標頭(Header) 中也包含了許多 HTTP 所用到的資訊。

WTP Transactions

Client Server

Figure 4 WSP Method Example

WTP 程式說明

本系統中，WTP 部分的運作由下列幾個檔案負責:

(1) wtp_machine.java (2) wtp_pdu.java

(3) WTP_interface.java 以下分別說明

(一)wtp_machine

wtp_machine 包含有 WTP 運作的主要部分，有限狀態機(FA)的製作，提供 給上層的服務，對下則使用 Java 所提供的 UDP 函式傳送資料片(Datagram)，

這幾項功能。

WTP 的運作以交易(transaction)為單位，而交易可分為 Class 0，Class 1，

Class 2 三類，同時解釋這三種交易的運作方式及程式，有限狀態機的實做。

(a) Class 0

Class 0 的目的在於擴張交易服務的能力，由於 WTP 有時候會需要重複 傳送有相同內容的資料片(Datagram)，且不在意是否成功時，Class 0 就提 供了這項功能。也就是說，Class 0 提供給 WSP 的是一個不可信賴的 push 服務。

實際運作方面，由於 Class 0 的動作簡單，且只使用到 Invoke 的 PDU。

運作方式通常由 WTP 使用介面中的 TR-Invoke 呼叫另一端的 WTP 服務提

供者，且驅動端(Initiator)不需要等待回應，回應端(Responder)在收到這個 PDU 之後會立即接受它，也不需要重複檢查(verify)該程序的進行。

在本系統中，Class 0 的運作可由下圖簡單說明，其中傳入參數為該交 易的編號(N)，使用的交易類型(0)，簡單訊息(TG，即 TTR 和 GTR 兩個位 元均設為 1，表示這些 PDU 不需要分段(Segmentation)或重組

(Reassembly) )。

其中交易編號(tid)儲存在 wtp_machine 物件中，驅動 Class 0 交易的一 端必須在執行完後將此編號加一，回應方則不需要更動交易編號，不論回應 方有沒有收到這個 PDU。

Invoke(TID = N，TG，Class = 0)

Responder Initiator

Figure 5 Class 0 Transactions

(b) Class 1

當有時需要執行不需要從對方拿取結果資料的交易結果，此時即需要使用 Class 1 的交易。對 WSP 而言，Class 1 的交易提供給它一個可信賴的 push 服

務，由於 Class 1 是為了進行這類簡單的訊息交換而設計，所以在放棄連結 (TR-Abort.req，TR-Abort.ind)，確認驅動(TR-Invoke.cnf)等等功能都需要使用。

Class 1 的運作方式也不複雜，僅用到 Invoke 和 Ack 兩類的 PDU。開始執 行時，驅動端送出 Invoke 的 PDU，回應端送出一個確認收到的 Ack 的 PDU，

即是一次基本的 Class 1 交易，和 Class 0 不同的是驅動端必須收到來自回應端 的「確認收到」訊息才算一次成功的交易執行。如果沒收到，驅動端必須在一定 時間後重送。

如果回應端收到 Invoke，並發出 Ack，但這個 Ack 遺失，驅動端又重送一 個相同的 Invoke 來，回應端必須能再送出一個相同的 Ack，所以回應端必須能 檢查收到 PDU 的交易號碼(tid)，並維持原來的狀態資訊。

運作方式如下圖，Ack 的交易號碼必須能讓驅動端知道這是用來 Ack 哪一個 PDU，同時又必須不致混淆，所以 Ack 的交易號碼為原來的交易號碼與 0xF000 作互斥或(XOR)，也就是表示交易號碼的兩個 byte 中，改變最高的那一位，這 樣驅動端可以很輕易的反算回這個 Ack 是在 Ack 哪一個 PDU。

Ack(TID = N*)

Invoke(TID = N，TG，Class = 1)

Responder Initiator

Figure 6 Class 1 Transactions

Not received

Receive Ack Send Invoke

1 2 3

Figure 7 Class 1 transactions FA of Initiator

Not received 3

1 2

Receive Invoke Send Ack

Figure 8 Class 1 transactions FA of Responder

(c) Class 2

以上兩種交易都不算是真正在通訊 WTP 使用者的資料，而只是 WTP 所提 供的附屬功能。當我們有資料要使用 WTP 來傳送時，這時就必須使用 Class 2 的交易。

Class 2 為了確保資料能正確交換，機制較前兩種 Class 複雜許多，會用到 所有 WTP 提供的四種 PDU 格式，分別為 Invoke，Ack，Result，Abort 四種。

Class 2 同樣由需要拿取資料的驅動端發出 Invoke，如果回應端很快且正確 的收到該 PDU，則將結果放入 Result 的 PDU 中，送回給驅動端，驅動端也同

樣順利收到該 PDU 時，送回一個 Ack 給回應端，結束一次成功的 Class 2 交易，

這是最順利的狀況。但一般來說，無線網路的實際情形並不能保證每次都能這麼 順利，我們可能遭遇到的問題除前面提過的 PDU 遺失外，也可能回應端的上層 使用者忙於別的應用程式或其他工作，而不能即時送出 Result，但已正確收到該 Invoke 訊息，此時應先送回一個 Ack，說明已正確收到 Invoke，只是無法及時 處理，驅動端收到該 Ack 後，即等待回應端將結果送出，等到結果後如同一般 狀況再送 Ack 給回應端，同樣正確的結束一次成功的 Class 2 交易。

有時可能回應端需要驅動端檢查該交易的交易號碼，此時在 Ack 中把要確 認交易號碼的 bit 設為 1。之後驅動端確認交易號碼後，會再發出一個 Ack 給回 應端，回應端收到後即送出結果，驅動端等到結果後如同一般狀況再送 Ack 給 回應端，同樣正確的結束一次成功的 Class 2 交易。

為了解決 Ack 遺失的問題，Class 2 的交易同樣必須能夠維持原來的狀態資 訊。在確認交易號碼時，程式中必須過濾掉重複的交易號碼，或是舊的，較小的 交易號碼。

Result(TID = N*，TG，…) Ack(TID = N*)

Invoke(TID = N，TG，Class = 2)

Responder Initiator

Figure 9 Basic Class 2 Transactions

Ack(TID = N*)

Result(TID = N*，TG，…) Ack(TID = N*)

Invoke(TID = N，TG，Class = 2)

Responder Initiator

Figure 10 Class 2 Transaction with Hold on Acknowledgement

Initiator

Ack(TID = N，tidOk) Ack(TID = N*，V)

Result(TID = N*，TG，…)

Ack(TID = N*)

Invoke(TID = N，TG，Class = 2)

Responder

Figure 11 Class 2 Transaction with Transaction Id verification (Succeed)

Initiator

Ack(TID = N*，V)

Abort(TID = N，INVALIDTID) Invoke(TID = N，TG，Class = 2)

Responder

Figure 12 Class 2 Transaction with Transaction Id verification (Failure)

上面圖 9，10，11，12 為 Class 2 交易在各種不同情形中的運作狀況，再 設計程式時，使用如圖 13 的方式。

Receive Result Verify Failure Send Abort 6

Send Ack

Receive Result Verify succeed

Send Ack Receive Ack

With Verify

5

7 8

4 Not received

Receive Ack Send Invoke

1 2 3

Figure 13 Class 2 transactions FA of Initiator

程式碼中，wtp_machine 這個物件提供給使用者的功能如下:

(1) void TR_Invoke(int t_class,byte[] user_data,int length) (2) void TR_Abort(byte abort_code)

(3) byte[] TR_Result() (4) int TR_ResultLength()

其中，TR_Invoke 功能給定選用的交易類型，來自上層的資料，資料長度，

在順利完成交易後，可用 TR_Result，TR_ResultLength，兩函式取得結果 資料。

wtp_machine 物件中除維持狀態資訊包括目前使用的交易種類「int tcl」

交易號碼「int tid」，重傳位元「int rid」，是否送過 Ack，「ack_pdu_sent」，

是否需要檢查交易號碼「byte tid_ve_ok」外，還必須紀錄網路資訊

「DatagramSocket，DatagramPacket」，使用機器的通訊埠「int port」，

目標機器「String send_to」。以及是否已得到結果資料「boolean

have_result」，結果資料「byte[] result」，結果資料的長度「int n_result」。

(二)wtp_pdu.java

這個程式負責製作 WTP PDU，並由 wtp_machine 提供必要的資訊，物件

wtp_pdu 包含的資料為一位元組陣列(byte[])，先利用下面幾個函式自

wtp_machine 中取得資訊，並設定其中的資料。再藉由 byte[] getData()取得，

並由 int getLength()取得該陣列的長度。

(1) void pack_abort(byte abort_type,byte reason,wtp_machine m) (2) void pack_ack(wtp_machine m)

(3) void pack_invoke(wtp_machine m) (4) void pack_result(wtp_machine m)

(三)WTP_interface.java

這個檔案中包含一個 interface，其中定義了 WTP 所使用的各種常數。

WSP 程式說明

WSP 程式以類似的方式架構在 WTP 程式之上，由於 WSP 的功能與任務均 遠較 WTP 為多且繁雜，所以使用的模組也較多，目前的設計中總共包含下列檔 案:

(1) wsp_machine.java (2) wsp_pdu.java (3) WSP_interface.java (4) wsp_datatypes.java (5) wsp_capabilities.java (6) wsp_connectfield.java (7) wsp_getfield.java

先大致說明各檔案的功用，(1)wsp_machine，(2)wsp_pdu 的工作和前述 wtp_machine，wtp_pdu 相類似，分別是協定運作的主程式，及製作，設定 PDU 資料的類別。(3)WSP_interface 也同樣是提供一個介面，以定義 WSP 中所定義 的常數。(4)wsp_datatypes 則是因為 WSP 中對於資料的格式，有幾種自訂的型 態，在這個檔中定義好，使我們可以更方便而清楚的使用這些新的資料型態。

(5)wsp_capabilities 提供一種類別來設定各項雙方機器間的參數，每要設定一個

參數就需要在連結的 WSP PDU 中包含一個 capability，故不如將其也設為一種 資料型態，讓連結 PDU 在包含許多個 capabilities 時能夠更明確。

(6)wsp_connectfield，(7)wsp_getfield 分別是在建立 WSP 的「連結 PDU」與「拿 取 PDU」時，能夠更模組化，更易維護，且不用將龐大的標頭與 Capabilities，

上層資料等全部繁雜的寫在一個程式中。

先從 WSP 所使用的特殊資料型態開始說明，也就是 wsp_datatypes.java 中 所定義的 uint8，uint16，uint32，uintvar 這四個，前三個分別代表以一個 byte，

兩個 byte，三個 byte 表示一個整數，而第四個 uintvar 則是代表變動長度的整數，

不一定佔有幾個 byte，使用每個 byte 中後七個位元來表示數字資料，第一個位 元則是用來表示下一個 byte 是否仍然屬於該筆整數資料。舉例來說，一個使用 到九個位元的整數 102310=1111111112，若以 uintvar 格式表示，則必須用兩個 byte 來表示，分別為 10000011 01111111，其中第一個 byte 的第一個 1 表示下 一個 byte 也包含這個數字的內容，第二個 byte 的第一個 0 則是表示這筆整數資 料到這個 byte 為止，其他的 1 則是該筆數字的資料。

X XXXXXXX

Continue bit Payload

Figure 14 the Variable length integer uintvar

在程式中，若需要使用這幾種資料型態，我們可以直接以它們的名稱 uint8，

uint16，uint32，uintvar 宣告，不致與其他型態混淆。使用時可以以 byte[] getByte() 函是直接取用該數字的位元陣列，並以 int getLength()取得陣列長度，若需要直 接使用該數字，則可以使用 int getData()取得。

Capability 包含以(a)uintvar 格式儲存的該 Capability 的長度，(b)Identifier 與(c)Parameter 三部分，目前在該類別中，提供一些常用的 Capability 設定，使 用者無須分別一個個 byte 填入。分別是 void set_accept()，void

set_accept_encoding，void set_accept_language()，void

set_accept_ranges()。使用時僅需先宣告一個 Capability，然後使用上列函式，

即可將 Capability 填好，使用時同樣以 byte[] getByte，int getLength()取用該 Capability 的位元陣列內容。

Connect Field 包含了 Version，Capabilities 的總共長度，Headers 的總共 長度，Capabilities，Headers 四個部分，在一般情形下，可以使用 void

set_connect_fields()函式以製作一般的 Connect Field，同樣宣告一個

connect_fields，再使用 set_connect_fields()即可，使用時同樣以 byte[] getByte，

int getLength()取用該 Connect Field 的位元陣列內容。

TID – If Connectionless

Headers

Headers Length Capabilities Length Version

Capability…

Capability Capability

Connect Field Type – Connect PDU

Figure 15 An Example of WSP Connect PDU

主要程式 wsp_machine 中，可輕易的利用 wtp_machine 來進行工作，僅需 將如先前所述而建好的 WSP PDU 利用 wtp_machine 所提供的函式即可傳出，

舉例來說，我們要使用 WTP 中 Class 2 的交易方式將一個稱為 ex_pdu 的 WSP PDU 送出，則呼叫 wtp_machine . TR_Invoke(2，ex_pdu . getByte()，ex_pdu . getLength() )即可。

WSP 所提供的功能中瀏覽器用到的部分，最重要的 Get 功能，已能正常運作，

以進行從伺服器拿取網頁的內容，其他的功能製作則還在進行中。