分散式使用者代理人的行動管理系統

全文

(1)分散式使用者代理人的行動管理系統 Distributed User Agent Proxy Mobility Management System 曾建超. 謝明燈蔡清松國立交通大學資訊工程學系新竹市大學路 1001 號. cctseng@csie.nctu.edu.tw. mdhsieh@csie.nctu.edu.tw. tstsai@csie.nctu.edu.tw. 動設備的使用或是使用者的移動，也產生了許多的問題。過去有許多研究，分別針對不同的問題與應用提出各種不同的解決方法。架構於 IP 網路上的 Mobile IP [6]利用註冊與 tunnel 的機制，使得其它主機(Correspondent Node – CN) 可以隨時將資訊送給在不同網域間移動的行動設備。在 Mobile IP 中，資料傳送的目的是以每一個行動設備所獨有的 Home Address 來識別。有別於此，MPA [21][24]提出了 Person Level Routing 的觀念，一個使用者可以使用多種設備，例如：PC、PDA、行動電話、固定的電話等。使用者在移動的同時，就可能會使用不同的設備，CN 要傳送資訊給行動使用者時，必須透過一些查詢的機制找到行動使用者現在所能聯絡到的方式(包含使用的設備與該設備所支援的應用程式)，然後再利用適當的應用程式透過適當的通訊協定來傳送資訊給行動使用者。在 MPA 中，還可以透過 Personal Proxy 來進行資訊格式與應用層協定的轉換，如此一來，即使 CN 無法使用行動使用者現在所能聯絡到的應用程式或通訊協定，仍然可以和過 Personal Proxy 的中介來傳送資訊給行動使用者。此一觀念在[13][14] [18] [25]也分別被採用。. 摘要本論文提出了一套行分散式使用者代理人 (User Agent Proxy － UAP) 的行動管理系統。UAP 轉送轉換過的資訊讓行動使用者可以利用各種不同的設備來收送各種資訊；另外，Directory Service 可以讓其他使用者或機器查詢行動使用者位置。本系統的行動管理機制採用類似 Mobile IP 分散式註冊的觀念，但不同於 Mobile IP，我們利用使用者作為註冊識別的基礎，並記錄使用者的設備及環境；並結合 Directory Service 以提供查詢使用者位置與網路服務功能，能讓行動使用者可以更方便而快速的取用各種網路服務或收送各種資訊。除此之外，使用者還能夠利用 UAP 做為擷取網路上資訊的 Proxy，不僅發揮 Proxy 的優點，也有助於在無線網路環境中更可靠的資訊傳輸。關鍵詞：User Agent Proxy、Directory Service、註冊. 一、簡介. 前述的資訊格式轉換點出另一個問題，中介的 Proxy 並須要有行動使用者所使用設備軟硬體能力資訊(Device Capability) 與使用者偏好設定(User Preference)，才能進行適當的轉換。在 MPA [21] [24]、iMobile [4]、與[13][25] 中，使用者都可以透過某些機制將設備能力資訊與使用者偏好設定送到中介的 Proxy 網路上傳送到到中介 Proxy，以供其使用。在 WAP [27]的 User Agent Profile [28]與 W3C的 CC/PP [16][19][22]提出了此類資訊格式制定與交換的方式，雖然在 iMobile、WAP、與 Web 的應用中，使用者都是屬於資訊的主動拮取者，而. 近幾年來，使用網際網路(Internet)與行動通訊設備的人口快速成長，於此同時，資料網路與電話網路也開始互相連接，甚至合而為一。人們可以使用行動設備透過電話網路來存取網際網路上豐富的資訊[27][28]；另一方面，利用網際網路來接打網路電話也越來越受到重視，市面上已經有許多產品，相關研究也不斷的在進行。所以，利用各種不同的設備來存取資料或電話網路，已經是未來的趨勢。這其中，行 1.

(2) 手機，並以 IP 作為網路層繞送機制；網路部分則包含 Wired LAN 、 Wireless LAN 、與 IP-based Celluar Networks。在我們的網路架構中，會設置許多 User Agent Proxy (UAP)與 Directory Server，進行分散式的運作。UAP 的主要功能是在不同的網路中服務使用者；就像是 GSM 的 HLR/VLR 與 Mobile IP 的 HA/FA 的觀念，對每一個使用者而言，UAP 也分為 Home UAP 與 Visited UAP (可由 ISP 在其建制的網路中，為付費或註冊的使用者提供 Home UAP)。. 前一段所述的行動環境應用中，使用者是被動資訊的接收者，但無論如何，使用者最後都是 adapted 資訊的接受者。比較遺憾的是目前的 Web Server、WAP Server 與應用程式大部分都尚未支援應用層協定轉換、設備能力/偏好設定交換、與資訊轉換這些功能。在行動環境中，網路服務的搜尋與使用也是一個很重要的課題。對於行動使用者而言，使用所在地網路所提供的某些網路服務 (例如：DNS、Web Proxy、SMTP)可以加快存取這些網路服務的速度，這種狀況在目前 Internet 流量的最主要的部分 Web Browsing 尤為重要，因為在使用 Web Proxy 的狀況時，一個處於 Visiting Network 的使用者，若使用 Home Network 的 Web Proxy 來瀏覽網站，資料可能因此被繞經不必要的路徑，因而浪費網路頻寬與增加使用者等待的時間。而現今大部分的網路服務的使用方式是必須知道該服務的所在位置，並在應用程式或是使用的設備中進行手動的設定。這對於不斷在各個網路間移動的使用者是很不方便的，使用者也很不可能記住所有網路所網路服務及服務主機的所在。[1][2][12]提出了動態選擇 Web Proxy 的方法。另外，還有許多 Directory Service 的機制: SLP－Service Location Protocol [7][15]定義了一種尋找 Service Location 與 Service Property 的協定；在 Bluetooth 中，則是利用 SDP－ Service Discovery Protocol [29]來尋找網路服務；另在，在 Internet 廣為使用的 DNS Service [23]中，也新增了 SRV Record [3]以作為此類用途。. 圖 1 系統網路架構我們將整個系統的存取分成幾個階段：取得網路的存取權、網路服務的搜尋與使用、向 UAP 註冊、透過 UAP 來接送或擷取資訊。下面幾小節將對這四個階段進行說明(因為我們將重心先放在整個網路架構的設計，所以在某些部分，我們尚未進行實作，這些部分會列出多個現行通訊協定或機制作為參考)。. 針對上述需求，本論文提出了一套分散式使用者代理人行動管理系統，其中包含:. (一) 取得網路的存取權這裡的所指的網路存取權並不是單指網路的載體(Carrier)本身的存取，也包含了網路提供者對使用者進行身份驗證並設定使用者設備來存取網路服務，由於使者可能是來自其他網路 (即所謂的漫遊 — roaming)，所以可能必須利用一些 Remote Authentication 的機制 [9][10]。舉例來說，利用電話(可能是有線或無線)撥接上網的使用者，會利用 PPP 或 SLIP 之類通訊協定的與撥接主機連線，在通過身份驗證之後，再利用 IPCP [17]或類似的協定取得 IP 位址。在 Wireless LAN 的部分，使用者設備可以透過 Wireless Access Point 來和 DHCP [11]或類似的伺服器溝通，以取得 IP 位址。總之使用者設備必須取得 IP 位址做為存取 IP 網路的識別之用。在這一階段使用的都是現有的通訊協定與機制，而且是屬於網路提供者的建制考量，所以我們便不多加舉例說明。. • 使用者註冊與資訊繞送機制 • Directory Service 以作為網路服務與使用者位置搜尋之用 • 多功能的中介 User Agent Proxy(包含資訊與協定轉換) 在接下來的幾節中，我們將介紹此一系統的架構與運作。第二節是系統架構與基本運作方式的介紹，在第三節會說明 Directory Service 與註冊機制，在第四節則說明了使用者在本系統如何透過 User Agent Proxy 接送或擷取資訊，最後在第五節做個結論與說明未來的工作。. 二、系統架構圖 1 是我們所設計系統的網路架構，在目前，我們所考慮的使用者設備包含: PC、筆記型電腦、具無線通訊能力的 PDA、與 WAP 2.

(3) 在我們的設計中，我們採用MPA [21][24] 的觀念，不以使用者設備的 IP 位址作為註冊的基礎，而是以使用者作為註冊的基礎。我們採用 Network Access Identifier - NAI [5]來進行註冊。當使用者欲使用一部機器或帶著行動設備移動時，便可以進行註冊；但是在此之前，使用者必須知道所在網路的 UAP，所以便向在第二階段所找到的 Directory Server 詢問 UAP 所在，然後再進行註冊的動作。關於註冊的詳細動作，我們將在第三節說明。. (二) 網路服務的搜尋與使用在取得 IP 位址之後，使用者設備必須知道所在網路有那些服務與服務主機所在。傳統的解決方式是使用者設備進行廣播(Broadcast) 或群播(Multicast)，提供該服務的主機收到訊息後便會將使用者設備所需要資訊回應過去。例如前一段所述的 DHCP 便是採用此一方式。另外一種方式將這些資訊收集到一部 Directory Server 上，使用者設備對 Directory Server 進行查詢即可，例如 SLP [7][15]與 DNS [3][23]；但是這種方式也衍生出另外一個問題，使用者主機如何知道這些提供查詢資訊主機的位置?在 SLP 中，建議依序使用下列四種方式來搜尋網路服務：. (四) 透過 UAP 來接送或擷取資訊當行動使用者完成註冊的動作之後，便可利用 UAP 做為 Application 的 Proxy，例如 Web browsing。CN 也可以透過查詢使用者位置的機制來找到使用者所在位置，將資訊送到使用者所註冊所在的 UAP。隨後 UAP 可以將這些資訊進行必要的轉換，再送給使用者的設備。這部分的動作會在第四章做詳細的說明。. 1. 利用 DHCP 的 SLP option [8]來尋找 Directory Agent (DA －相當於 Directory Server) 2. 預先設定好的 DA 位址 3. 使用群播來搜尋 DA 4. 使用群播來搜尋 Service Agent (SA – 即提供網路服務的主機) 綜合以前的方法，我們採取了一種綜合的方式：. 三、Directory Service 與註冊動作. 1. 如果在第一階段(取得網路存取權階段)，網路可以提供類似 DHCP 的 SLP option [8]或類似的機制，便藉此將 Directory Server 的資訊告訴使用者設備 2. 否則，便在取得 IP 位址後，利用廣播或群播找到 Directory Serve r. (一) Directory Service 架構在前一章的第二節我們已說明搜尋 Directory Server 的方法，現在說明我們的 Directory Service 的架構。由於網路上的資源與服務數目十分龐大，也可能不斷的變動，所以在大型的網路系統中，集中式 (Centralized) 的管理並不適合 Directory Servi ce 使用。現行的網際網路 Directory 或查詢機制多是採取分散式的架構，例如 DNS、LDAP 等。為求簡單，我們暫時不考慮如 LDAP 或 SLP 的 Service Property 等複雜的查詢方式，而採用 DNS [23] 這種較簡單的查詢方式。在 DNS 的架構中，每一個或幾個 DNS Server 負責管理某一網路上的 Name Service；如果該網路上層還有較大的網路，上層網路也會有自己的 DNS Server；餘此類推，至最上層為 Root DNS Server。為記錄網路服務，我們採用 DNS 的 SRV Record[3]。網路上的服務主機可以向所在網路的 DNS Server 註冊，如此一來，不論在同一網路或其他網路上的機器便可以透過傳統的 DNS 查詢機制來查詢網路服務。. (三) 向 UAP 註冊傳統的 Mobile IP 註冊所憑藉的是使用者設備的 Home IP Address，CN 將資訊送往該使用者設備的 Home IP address，再由 Home Network 上的 HA (Home Agent)將資訊轉送 (forward, tunnel) 到使用者所連接的 FA (Foreign Agent)。事實上，如果 CN 可以不透過 HA 便將資訊送給行動使用者設備，效率會比較好，也可能避免掉三角傳輸所造成效率低落，所以就有了 Mobile IP Route Optimization 的產生。在[20]中，更採取了類似 DNS 與 GSM HLR/VLR 先查詢再傳送的方式，CN 在送出資訊前，先進行查詢行動使用者設備位置的動作，然後直接將資訊送往行動使用者設備。在 [20]中，還採用的類似 DNS 的觀念，將使用者設備位置的資訊複製到其它的機器上(可以是其它網路的機器)，這樣在 Home Network 與外界的連接斷掉時，仍然可以進行使用者位置的查詢。. 相較於傳統 DNS，我們除了使用 SRV Record 來記錄網路服務主機之外，我們也將行動使用者的位置查詢機制合併進來。這樣子做的好處是可以利用現有 DNS 的查詢機制， 3.

(4) 給 Home UAP 4. Home UAP 回應一個認可給使用者設備，完成註冊. 查詢者一開始並不需要知道所欲查詢的使用者屬於那一個 Home UAP，仍然可以藉由 DNS 的 Referral 或 Recursive 查詢機制，來找到使用者所屬的 Home UAP，進而找到使用者現在所處的 UAP 所在。因為 UAP 必須與 DNS Server 合作以供其他使用者查詢使用者位置，所以在我們的 Directory Service 中，UAP 也是一種 DNS Server，但僅負責記錄以其為 Home UAP 的使用者之位置資訊。. 要注意的是，若使用者設備與 Home UAP、 Visited UAP 之間沒有交互驗證或其他考量，步驟 2 與步驟 4 應可同時進行。 B. 從 Home UAP 移動到 Visited UAP，在 Visited UAP 註冊. (二) 註冊在這個系統中，使用者會向 UAP 註冊自己目前所使用設備的 IP 位址，同時將該設備的設備能力與偏好設定傳送給 UAP，以作為 UAP 進行資訊轉換的依據。以下我們分三種狀況來說明註冊的動作。圖 3 從 Home UAP 移動到 Visited UAP，在 Visited UAP 註冊. A.在 Home UAP 註冊(也可能是從 Visited UAP 移動回到 Home UAP). 步驟說明如下： 1. 在使用者設備從 Directory Server 知道現在處於那一個 Visited UAP 的服務範圍之後，便向此一 Visited UAP 發出註冊的請求，並將 NAI、目前的 IP 位址、設備能力與偏好設定、以及所屬的 Home UAP 告知 Visited UAP 2. Visited UAP 收到註冊的請求之後，將請求訊息內的 NAI、目前的 IP 位址、以及設備能力與偏好設定記錄起來；再對此一 NAI 所屬的 Home UAP 發出註冊的請求，此一註冊請求會包含使用者的 NAI、使用者所註冊的 Visited UAP、使用者設備能力與偏好設定 3. Home UAP 收到來自 Visited UAP 的註冊的請求之後，將請求訊息內的 NAI、Visited UAP、以及設備能力與偏好設定記錄起來，再回應一個認可給 Visited UAP 4. Visited UAP 收到 Home UAP 的認可之後，也回應一個認可給使用者設備，完成註冊. 圖 2 在 Home UAP 註冊為求簡化，我們暫時不考慮 UAP 與使用者之間相互驗證的訊息交換。圖 2 是使用者設備在 Home UAP 註冊的訊息交換示意圖，步驟說明如下： 1. 在使用者設備從 Directory Server 知道現在處於 Home UAP 的服務範圍之後，便向 Home UAP 發出註冊的請求，並將 NAI、目前的 IP 位址、以及設備能力與偏好設定告知 Home UAP 2. Home UAP 收到註冊的請求後，若發現此一使用者先前曾在某一 Visited UAP (參考下一小節)註冊過，便向舊的 Visited UAP 發出 Binding Update 訊息，同時將服務此 NAI 的新 UAP(即 Home UAP 本身 ) 告訴舊的 Visited UAP 3. Visited UAP 收到 Binding Update 訊息後，會將服務此 NAI 的新 UAP 暫存一段時間，以供將來使用 (詳見第四節之第(二)小節)，然後再回應一個認可. C.從 Visited UAP 移動到另一個 Visited UAP，在新的 Visited UAP 註冊圖 4 是從 Visited UAP 移動到另一個 Visited UAP，在新的 Visited UAP 註冊此一狀況在某種意義上就如同前面的 A 與 B 的合併，所以訊息與動作就類似同 A 與 B 的合併，所以我們就不多加說明。. 4.

(5) Service 機制來查詢使用者所在的位置。. 圖 5 查詢使用者位置圖 4 從 Visited UAP 移動到另一個 Visited UAP，在新的 Visited UAP 註冊. 圖 5 是 CN 透過 DNS 的機制來查詢使用者位置的示意圖。首先 CN 就近對附近的 DNS Server 發出查詢，然後透過一連串的 DNS 機制[23]找到被查詢者所屬之 Home UAP，此一查詢會送到被查詢者的 Home UAP。Home UAP 便將使用者的目前註冊所在的 UAP(如果使用者是在 Home Network，便是 Home UAP ；否則便是 Visited UAP)透過一連串的 DNS 回應轉送給 CN。. 上面的註冊動作中有一點是要注意的： Home UAP 僅會記錄使用者設備註冊所在的 UAP(可能是 Home UAP 或 Visited UAP)，而更詳細的 IP 位址是記錄在使用者設備註冊所在的 UAP。因為其他使用者要送資訊給行動使用者設備時，都必須透過 UAP，所以 Home UAP 便不需要記錄使用者設備的 IP。而這樣設計也比較符合現實，以現今網路上 Proxy 的設置的狀況，一個 Proxy 所負責的區域往往較一個 LAN 或無線基地臺來得大。所以使用者設備移動而改變位置與 IP 位址時，可能還是處於同一個 UAP 的服務範圍。此時註冊的動作便可以簡化，收到註冊請求的 UAP 不用再通知 Home UAP，僅須要更新用者者設備的 IP 位址、設備能力與偏好設定。. 接下來 CN 便可以送資訊給使用者給使用者註冊所在的 UAP，該 UAP 收到資訊後，便根據使用者註冊時所提供的設備能力與偏好設定進行資訊的調整；再將調整過的資訊送往使用者所註冊的 IP 位址。 (二) 被動的接收資訊過程中，更換 UAP 在此狀況下，會有部分資料因為已經被送往舊的 UAP，所以必須有辦法讓舊的 UAP 將這些資料轉送到新的 UAP，並將服務此使用者的新 UAP 通知 CN。. 四、接送與擷取資訊在完成前面的動作之後，使用者設備就可以透過 UAP 來接送資訊（例如：接聽網路電話或寄 e-Mail）或擷取資訊(例如：Web Browsing)。我們將這些應用分成兩種狀況：一是使用者設備被動的接收 CN 所送來的資訊，另一則是使用者設備主動向其他網路上的機器擷取資訊。另外還有一種比較特殊複雜的狀況，就是當 CN 正在傳送資訊給行動使用者的時候，使用者帶著設備移動到另一個 UAP 的服務範圍且正在註冊，此時會有部分資料因為已經被送往舊的 UAP，所以必須有辦法讓舊的 UAP 將這些資料轉送到新的 UAP，並將服務此使用者的新 UAP 通知 CN。. 圖 6 被動的接收資訊過程中，更換 UAP 圖 6 被動的接收資訊過程中，更換 UAP 的訊息交換示意圖，最上面六個訊息與圖三是相同的，就不再贅述。其他訊息的說明如下：. (一) 被動的接收資訊. 1. 舊的 Visited UAP 收到 CN所送來的資訊 1.a 舊的 Visited UAP 將此資訊轉往送到服務使用者的新 Visited UAP；服務使. 在這種狀況下，CN 希望將某些資訊送給某一個使用者(以 NAI 識別)。由於使用者的位置不詳，所以 CN 必須先透過我們的 Directory. 5.

(6) 用者的新 Visited UAP 在收到舊的 Visited UAP 轉送來的資訊後，將資訊進行調整後送給使用者設備 1.b 舊的 Visited UAP 同時送出 Binding Warning 訊息給 Home UAP，此一訊息會包含 CN 的位址 2. Home UAP 收到來自舊的 Visited UAP 的 Binding Warning，便將服務使用者的新 Visited UAP 通知此 Binding Warning 訊息內的 CN 3. CN 收到 Binding Update 訊息後，就會知道服務使用者的新 Visited UAP，以後便直接透過新的 UAP 來送資料給使用者設備. 本論文提出了一套行分散式使用者代理人 (User Agent Proxy － UAP) 的行動管理系統。UAP 轉送轉換過的資訊讓行動使用者可以利用各種不同的設備來收送各種資訊；另外，Directory Service 可以讓其他使用者或機器查詢行動使用者位置。本系統的行動管理機制採用類似 Mobile IP 分散式註冊的觀念，但不同於 Mobile IP，我們利用使用者作為註冊識別的基礎，並記錄使用者的設備及環境，而我們的註冊機制相較於 Mobile IP 的註冊機制，所需要交換的訊息數目，幾乎是一樣的，也就不會有註冊效率上的問題。我們的系統並結合 Directory Service 以提供查詢使用者位置與網路服務功能，不僅能讓行動使用者可以更方便而快速的取用各種網路服務，其他使用者或機器也因此能夠成隨時隨地找傳送資訊給使用者的目的，不論該行動使用者使用的是那一種設備。除此之外，使用者還能夠利用 UAP 做為擷取網路上資訊的 Proxy，不僅發揮 Proxy 的優點－節省擷取重複資料的頻寬與加速資料的擷取，也利用了 Proxy 處於品質較佳的有線網路(相較於行動設備可能使用的無線網路) 的優點，可以將資訊以較快的速度擷取至 Proxy，再由 Proxy 與使用者設備進行較短距離的傳輸，這樣若無線傳輸發生錯誤時，可以較快的進行重送。. 在此我們要說明的是: 為何要由 Home UAP 來發出通知 CN 的 Binding Update，這是參考 Mobile IP 的 Route Optimization 的作法。雖然我們在這些訊息交換的示意圖中，把一些認證的訊息都省略掉，但是在網路環境中，安全性的認證是十分重要的，而通常一些認證的重要資訊都會儲存在使用者的 Home Network 主機 (在我們的系統是 Home UAP，在 Mobile IP 則為 HA)，所以應該由 Home UAP 來送 Binding Update。另外一種作法則是由使用者設備來送 Binding Update 給 CN，但如此一來使用者設備就必須記錄一份 CN 列表，這就會遷涉維持此一 CN 列表的許多考量；另外，讓使用者設備記錄此一 CN 列表就表示必須在使用者設備做更多的更動，這與我們設計此系統的本意違背，故暫時不考慮此一方法。. 未來，我們將繼續改進我們的系統，希望這可以作到將使用者所正在接收的資訊交遞(handoff) 到另一個設備的功能(Inter-device handoff)；這個功能可以讓行動使用者在移動時，切換到更方便的設備來繼續接收資訊。在 Proxy 的功能方面，我們將會設計在 Web Browsing Proxy 之外的用途，讓更多的常用的應用(例如 e-Mail)可以利用到我們 UAP 的優點。. (三) 主動擷取資訊目前網際網路上，由使用者主動發出請求來擷取資訊的應用程式是以 Web Browsing 為主，另外比較常用就是 FTP 與送 e-Mail。在目前的應用程式中，只有 Web Browsing 會利用到 Proxy 的中介，以提昇效率。所以我們目前在主動擷取資訊方面是以 Web Browsing 為主要考量，Browsing 的資料格式則可能是 HTML [31[32]、XML [30]、與 WML [27]。因為使用者可以利用不同設備來瀏覽這些不同格式的網頁，所以便需要進行這些網頁的調整 [26]，以符合使用者的設備能力與偏好設定。所以的我們的系統中，使用者以 UAP 作為 Web Browsing 的 Proxy 時，因為註冊時已經將使用者的設備能力與偏好設定記錄在 UAP 中，UAP 便可據以轉換使用使用者所欲瀏覽的 Web Page。. 六、參考文獻 [1] 王陸方, A Dynamic Web-Proxy-Selection Scheme for the Wireless Internet, Jun 1999. [2] A. Fox, I. Goldberg, and etc, “Experience With Top Gun Wingman, A Proxy-Based Graphical Web Browser for the USR PalmPilot,” Proceedings of the IFIP International Confernce on Distributed Systems Platforms and Open Distributed Processing (Middleware ’98), Sep 1998. [3] A. Gulbrandsen, P. Vixie, and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” IETF Internet draft, Nov 2000.. 五、結論與未來工作. [4] AT&T Labs, “iMoblie: A Proxy-Based 6.

(7) 1999.. Platform for Mobile Services,” 2001. [5]. B. Aboba, M. Beadles, The Network Access Identifier, RFC2486, Mar 2000.. [6]. C.E. Perkins, “IP Mobility Support for IPv4, revised,” IETF Internet draft, Sep 2000.. [20] Jan, R. and etc, “Enhancing Survivability of Mobile Internet Access Using Mobile IP with Location Registers,” IEEE INFOCOM, 1999. [21] Mema Roussopoulos, Petros Maniatis, and etc, “Person-level Routing in the Mobile People Architecture,”. [7] C.E. Perkins, “Service Location Protocol for Mobile Users,” Proceedings of the Portable and Indoor Mobile Radio Conference (PIMRC’98), 1998.. [22] Mikael Nilsson, Johan Hjelm, and Hidetaka Ohto, Composite Capabilities/Preference Profiles: Requirements and Architecture, W3C Working Draft 21 July 2000.. [8] C. E. Perkins , E. Guttman, DHCP Options for Service Location Protocol, RFC2610, June 1999.. [23] P. Mockapetris, DOMAIN NAMES CONCEPTS AND FACILITIES, RFC1034, Nov 1987.. [9] Cecilia Corbi and etc, “A Direcotory Enabled Solution for Internet Roaming,” 1999.. [24] Petros Maniatis, Mema Roussopoulos, and etc , “The Mobile People Architecture,” Mobile Computing and Communications Review, Volume 1, Number 2.. [10] C. Rigney, S. Willens, A. Rubens, and W. Simpson, Remote Authentication Dial In User Service (RADIUS), RFC2865, June 2000.. [25] Ramiro Liscano, Roger Impey, and etc, “Integrating Multi-Modal Messages across Heterogeneous Networks,” ENM-97 In conjunction with the ICC-97, pp. 45 –53.. [11] Droms, R., Dynamic Host Configuration Protocol, RFC2131, March 1997. [12] D. Wessels, and K. Claffy, “ICP and the Squid Web Cache,” IEEE Journal on Selected Areas in Communications, Vol. 16, No. 3, pp. 345-357, Apr 1998.. [26] Y.Y.Hsu, Automatic Transformation from HTML Documents to WML Documents, Jun 2000. [27] Wireless Application Protocol Forum Ltd, “WAP Forum Home page,” http://www.wapforum.org/.. [13] Di Stefano A., and Santoro C., “NetChaser: agent support for personal mobility,” IEEE Internet Computing, Vol. 4 Issue. 2, pp. 74-79, Mar-Apr 2000.. [28] Wireless Application Protocol Forum Ltd, “User Agent Profile Specification,” http://www.wapforum.org/.. [14] E.A. Brewer, R.H. Katz, and etc, “A Network Architecture for Heterogeneous Mobile Computing,” IEEE Personal Communications, Vol. 5, No. 5, pp. 8-24, Oct 1998.. [29] “Service Discovery Protocol (SDP),” bluetooth Specification Version 1.0B, 1999. [30] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 Oct 2000.. [15] E. Guttman, C. Perkins, J. Veizades, M. Day , Service Location Protocol, Version 2, RFC2608, Jun 1999.. [31] Hypertext Transfer Protocol -- HTTP/1.1, RFC2616, 1999.. [16] Franklin Reynolds, Chris Woodrow, Hidetaka Ohto, Composite Capability/Preference Profiles (CC/PP): Structure, W3C Working Draft 21 July 2000.. [32]. [17] G. McGregor, The PPP Internet Protocol Control Protocol (IPCP), RFC1332, May 1992. [18] Helen J. Wang, Bhaskaran Raman, and etc, “ICEBERG: An Internet Core Network Architecture for Integrated Communications,” IEEE Personal Communications, Aug. 2000. [19] Hidetaka Ohto, and Johan Hjelm, CC/PP exchange protocol based on HTTP Extension Framework, W3C Note 24 June 7. HTML 4.01 Specification, Recommendation 24 Dec 1999.. W3C.

(8)