隨意式無線網路之可靠點對點地域性群播之研究

(1)

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

計畫類別：個別型計畫

計畫編號： NSC94-2213-E-011-050-

執行期間： 94 年 08 月 01 日至 95 年 07 月 31 日執行單位：國立臺灣科技大學電子工程系

計畫主持人：陳省隆

報告類型：精簡報告

報告附件：出席國際會議研究心得報告及發表論文處理方式：本計畫可公開查詢

中華民國 95 年 10 月 30 日

(2)

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

隨意式無線網路之可靠點對點地域性群播之研究

The Study of Reliable Point-to-Point Geocasts in Mobile Ad hoc Networks

計畫編號：NSC 94-2213-E-011-050 執行期限：94 年 8 月 1 日至 95 年 7 月 31 日

主持人：陳省隆教授國立台灣科技大學電子工程系計畫參與人員：王碩藝、李柏青、楊宗曄、彭禹傑

一、中文摘要

行動無基礎架構網路（Mobile Ad hoc

NETwork, MANET）是由一群行動主機

（mobile host）所組成的網路結構，這些行動主機不需要透過基地台的支援便可在網路中相互進行溝通。其具有隨建即用與低成本等優點。

近年來，隨著美國政府對全球衛星定位系統（Global Position System, GPS）功能的開放，相關應用愈來愈廣泛與普及，更有許多研究將此定位技術應用在 MANET 無線網絡上。地域性群播（Geocast）即為一利用定位技術來進行群播（Multicast）的繞送協定，意指來源點可對特定區域內中的行動主機進行群播繞送。然而，現今 Geocast 繞送協定均廣泛使用洪流

（Flooding）及廣播（Broadcast）的作法，

一旦網路拓樸變得壅塞時，碰撞（collision）

的機會便跟著增加，以至於封包損壞或遺失。因此，如何確保 Geocast 封包的傳送品質，將是重要的議題。

本研究計畫旨在提出一可靠的點對點地域性群播（Reliable Point-to-Point Geocast,

RP2PG）繞送協定，以單播（Unicast）取

代廣泛使用廣播的作法，不但提升封包傳送的可靠度，並能產生高的傳送比率

（ delivery ratio ）與低的網路負載

（overhead）。

關鍵詞：行動無基礎架構網路、行動主機、

全球衛星定位系統、地域性群播、群播、

洪流、單播、廣播、碰撞、傳送比率、負載。

Abstract

A MANET (Mobile Ad hoc NETwork) is a network consisting of a set of mobile hosts capable of communicating with each other without the assistance of base stations.

Its advantages include ease of deployment, low cost, etc.

In recent years, with the opening of GPS (Global Position System) from U.S.A government, the GPS-related applications become more and more extensive and popular. Even more, there are a lot of studies to employ this technology in a MANET.

Geocast, a variant of conventional multicasting, uses the location technology. A geocast is defined as delivering messages to the set of nodes within a specified geographical area. However, recent geocast protocols extensively use flooding and broadcasting approach. When network load is heavy, the chance of collision will be increased and then packets will be damaged or lost. So, it will be an important topic to reliably deliver packets in geocast.

The purpose of this project is to propose a Reliable Point-to-Point Geocast protocol (RP2PG). In this protocol, we employ unicast with the aid of GPS for data packets instead of flooding. It will improve reliability of packet transmissions and achieves high delivery ratio with low overhead.

Keywords: MANET, mobile host, GPS, geocast, multicast, flooding, unicast, broadcast, collision, delivery ratio, overhead.

(3)

二、緣由與目的

隨著無線技術的發展，透過基地台溝通的電子資訊產品不再是唯一的選擇。行動無基礎架構網路(MANET)為一不需要基地台支援的網路結構，其包含隨建即用與低成本等優點。然而，因應特殊應用（如戰場的軍事用途或災區的救難工作），

MANET將是最佳的選擇[3]。

近年來，隨著美國政府對全球衛星定位系統功能的開放，其應用愈來愈廣泛與普及，更有許多研究將此定位技術應用在

MANET 無線網絡上[2]。地域性群播即為

一利用定位技術來進行群播的繞送協定，

意指將特定區域內中的行動主機列為傳送目的點（destination）。然而，現今的 Geocast 繞送協定均廣泛使用洪流及廣播的作法 [11, 12, 14, 15, 16]，當網路分佈變得壅塞時，封包（packet）因碰撞而造成損壞或遺失的情形會變得很嚴重[13]，如何確保封包透過 Geocast 之傳送品質，將面臨相當大的挑戰。

MANET 的特點為可移動之隨建即用

的無線網路，即鄰近點均為非固定的行動主機，如何實作 Geocast 之應用以達到繞送的目的，高傳送比率是一個重要的依據。

一般研究均廣泛使用洪流及廣播的作法，

即因其具有高傳送比率與作法簡單等優點。然而，廣播的作法具有隠藏節點

（Hidden node problem）的問題，因此，在網路壅塞的環境下，封包碰撞的機率會變得很大[13]。

基於上述的考量，如何減少廣播的使用，將有助於減輕碰撞帶來的傷害，且能降低不必要浪費的負載，故可從此方面著手改進。因此，計劃中研究如何降低鄰近點的碰撞機會有其絕對的重要性，並將對

Geocast 實作與應用具有相當程度的貢

獻。其他重要的考量因素，包括高傳送比

率與低負載的要求，其分別為封包在傳送期間成功到達的比率及 Geocast 繞送中所收到封包的數量，也證明其是否為一個好的繞送協定[15]。因此傳送比率與負載必須有一定的水準。

因應特殊應用的環境，當高移動速度且數量大的行動主機分佈在行動無基礎架構網路時，現行的地域性群播繞送協定無法提供較具可靠性的封包傳送。以傳統洪流為基礎的作法，在壅塞的網路中會產生極大的網路負載，而以建立路徑為基礎的作法亦不易在高速移動時建立完整的路徑。針對這樣的問題，計畫中提出可靠的點對點地域性群播（Reliable Point-to-Point Geocast, RP2PG）繞送協定，以單播取代廣泛使用廣播的作法，不但改善封包傳送的可靠性問題，並提升傳送比率及降低網路負載。

三、主要研究方法

針對高速且壅塞的行動無基礎架構網路下實作地域性群播繞送，我們提出可靠的點對點地域性群播（RP2PG）繞送協定。

其系統協定堆疊（protocol stack）如圖一所示，我們針對網路層進行 Geocast 繞送協定設計，而 MAC 層與物理層皆遵循 IEEE 802.11通訊標準[1, 2]。

以下是本計畫的架構，1.點對點方法

（The point-to-point approach）介紹 RP2PG 於行動主機間的封包傳遞方法，2.選擇鄰近點進行傳送（ Select a neighbor for

forwarding）介紹四種選擇策略以抉擇下一

個處理傳送的行動主機，3.適應性的傳送區域（Adaptive forwarding zone）介紹如何轉換傳送區域以因應 Geocast 傳送失敗時機，4.適應性的座標軸（Adaptive coordinate axis）介紹一個以行動主機現行位置來應變傳送區域的作法，5. 兩條分離路徑方法

（Two-disjoint path approach）介紹 RP2PG 可能遭遇的最差狀況（worst case）及相對解決之作法。

(4)

圖一：系統協定堆疊

1. 點對點方法（ The point-to-point approach）

介紹封包傳遞方法之前，先說明 RP2PG 中定義的三類封包，要求

（Request）、回覆（Reply）及資料（Data）

封包。其中 Request 與 Reply 屬於控制封包，Request 代表傳送者（sender）進行 Geocast前所發佈的訊息，Reply 代表收到 Request之接收者符合 Geocast 條件的回應訊息。

針對行動主機間的封包傳遞方法，採用類似交握（handshake）的方式進行。如圖二所示，當來源點（s）有 Data 封包需要做 Geocast 到目的點（d）時，來源點先廣播 Request，表示有 Data 要做 Geocast。

當 x 點的行動主機收到 Request 時，其判斷現行位置（以 GPS 取得）是否位於

Request所定義的傳送區域，若符合條件則

廣播 Reply 以告知 x 點可進行 Data 的傳送。當 s 點收到 x 點的 Reply 時，即以單播的方式（ Unicast with RTS/CTS/DATA/ACK）送至 x 點，請 x 點繼續進行上述程序，直至 Data 傳送至指定的目的範圍。

圖二：點對點方法示意圖

由上述說明可得知控制封包（Request

and Reply）均以廣播的方式傳送，資料封

包（Data）以單播的方式傳送。考量原因如下，單播 Data 封包並採用 DCF

RTS/CTS/DATA/ACK 機制，能提供較具

可靠性的傳送，但其須作繁瑣的交握與預約媒介（medium），因此在控制封包部份採用較單純的廣播傳送。此外，廣播

Request 可讓傳送者的鄰近點都收得到要

求的訊息，廣播 Reply 亦讓鄰近點得知其要作特定 Request 的回應，包含那些收到同一 Request 的行動主機，當其收到別的

Reply 時，可自行判斷是否要作出回應

[14]。如圖二所示，當 x 點廣播 Reply 後，

x1收到後會判斷本身條件是否比 x 點好，

條件優劣意指該點與目的範圍中心點的距離近遠[11]，因此 x1 發現自身至目的範圍中心點的距離遠於 x 點與目的範圍中心點的距離，較差條件的 x1 點即不廣播不必要的 Reply。至於 x2 點，雖然條件比 x 點差，但因為其位於 x 點的傳輸範圍之外，

故收不到 x 點發出的回應，因此 x2 點仍會對來源點進行回應。而來源點如何對所收到的回應做出抉擇，由下一節繼續說明。

2. 選擇鄰近點進行傳送（Select a neighbor for forwarding）

此節將介紹四種不同的選擇策略，以抉擇下一個處理傳送的行動主機。

2.1. 選擇最先回應（First reply first select）

送出 Request 的發送者，以最先回應的行動主機為選擇對象，即表示發送者收到的第一個 Reply 封包，將檢查封包標頭

（packet header）部分，以其所記錄的發送端為下一個處理傳送的行動主機。

2.2. 發送者等待（Requester waiting）

當發送者廣播 Request 後，等待一段適當的時間以收集回應的封包，在該時間過後，發送者即檢查所有收集到的 Reply 封包標頭，找出條件最佳的回應者（最接近目的範圍中心點視為最佳條件）並選擇其為下一個處理傳送的行動主機。

圖三為一個發送者等待的實例，當來源點廣播 Request 後，即開始等待一段時間以收集 Reply。假設 A 與 B 點均收到此封包，並且兩點都要作出回應（暫不考慮前節所述的不回應機制）。在發送者等待

(5)

時間過後，來源點分別檢查由 A 與 B 點送來的 Reply，並判斷 B 點的條件最佳（B 比 A 點更接近目的範圍中心點），因此來源點會選擇 B 點為下一個處理傳送的行動主機，並以單播方式將 Data 封包傳送至 B 點。

圖三：發送者等待示意圖

2.3. 最佳方向作法（ The best direction approach）

基於“兩點之間以直線為最近”的原則，可以等分法劃分傳送區域，如圖四所示，來源點至目的範圍的傳送區域（來源座標軸的第一象限）可劃分成三等分，並以中間等分的區域為視為優先區域，因其較接近目的範圍[8]。當鄰近點接收到來源點廣播的 Request 封包後，將依接收者所在的位置決定是否需要等待，若處於優先的區域（如圖四 B 點），則不用等待，允許直接做回應；若處於非優先區域（如圖四 A 點），則要求其等待一段時間，才允許其回應。在來源點部分，套用選擇最先回應（2.1 節）原則，如此，位於優先區域的 B 點將先被來源點選擇。

圖四：最佳方向作法示意圖

2.4. 延遲時間演算法（ Defer time algorithm）

來源點仍以選擇最先回應（2.1 節）

為原則，Request 的接收者以其至目的範圍中心點的距離為依據，決定其回應的延遲時間（defer time），直至該延遲時間過後才可廣播 Reply 封包[17]。延遲時間的大小與其至目的範圍中心點的距離呈正比，

如下公式：

( )

( ) R Ds Dx

defertime x AverageDeferTime

R

− −

= ⋅

其中，defertime(x)代表行動主機 x 點的延遲時間，R 代表行動主機的傳輸範圍，Ds 與 Dx 分別代表來源點與 x 點各別至目的範圍中心點的距離， AverageDeferTime定義期望等待的平均時間，可依環境的狀況來調整。依此式運算的結果，行動主機最長的延遲時間為兩倍的 AverageDeferTime，最短的延遲時間則為零。

圖五為延遲時間演算法的示意圖，當 A與 B 點收到來源點廣播的 Request 後，

各別以其距目的範圍中心點的距離算出該延遲時間。由於 B 點的距離較 A 點近，故等待的時間也較短，因此來源點將優先選擇 B 點。

圖五：延遲時間演算法示意圖 3. 適應性的傳送區域（ Adaptive

forwarding zone）

傳送區域為某一點是否接受該封包的依據[11]，以發送點（包含來源點）而言，對其在位置標示座標軸，若 Geocast 目的範圍位於右上角，傳送區域則落於座

(6)

標軸的第一象限。

考慮無回應狀況，當發送者第一次廣播 Request 時，以第一象限為傳送區域，

在一段適當時間後，若發送者沒有收到任何位於傳送區域的鄰近點之 Reply，發送者將加大傳送區域並做第二次的廣播 [8]。如圖六所示，為適應性的傳送區域的兩種策略，不同之處在於第二次廣播的傳送區域範圍，半圓（傳輸範圍的一半）的傳送區域較符合漸近式原則。當發送者須進行第三次廣播時，代表前面兩次均失敗，故不再限制傳送區域，只要有鄰近點回應，皆視為符合條件。

圖六：適應性的傳送區域示意圖 4. 適應性的座標軸（Adaptive coordinate

axis）

對於傳送區域的設定，一般採用盒子

（box）的作法[11]，此為較簡易的作法。

以座標軸的觀念，即 X 與 Y 軸分別平行於模擬區域（simulation area）的邊長，如圖七中來源點處之座標軸。事實上，隨著行動主機轉傳封包的過程中，每一個行動主機依其所在位置不同，面對 Geocast 目的範圍的角度也有所不同，因此，可針對各個行動主機的位置動態調整座標軸的角度，使該點的傳送區域能面朝目的範圍。

如圖七所示，在來源點廣播 Request 封包之前，為決定傳送區域，須先畫出座標軸。由來源點對 Geocast 目的範圍中心點先畫出一條假想之虛線，以此虛線為依據，各展開 45 度並畫出兩條實線，即為 X 與 Y 軸。當 Data 封包轉交至 B 點後，接著由 B 點進行廣播 Request，同樣地，B 點用上述方法畫出座標軸，如此，B 點的座標軸便具適應性地朝向目的範圍。

圖七：適應性的座標軸示意圖 5. 兩條分離路徑方法（Two-disjoint path

approach）

RP2PG 繞送協定的特性為點對點的

交遞轉傳，直至目的範圍，即 x 點交遞 Data 封包至 y 點後，發送權便交給了 y 點，至於 y 點有無繼續進行轉傳，x 點卻無從得知。而前述的 RP2PG 作法，來源點僅挑選一個鄰近點來進行轉傳，因此看起來只有一條路徑在行進，如此可能遭遇一種最差的情況，即行進中的任何一點無法繼續轉傳時，此次的 Geocast 便會失敗。如圖八所示，由來源點進行 Geocast，而在 C 點獲得發送權後，因故無法繼續轉傳，Data 封包即不能送至目的範圍。

為降低最差情況的發生機會，可以產生兩條分離路徑來進行 Geocast，若其中一條路徑在行徑中失敗，還有另一條路徑可以抵達目的範圍[10, 16]。如圖九所示，由來源點進行兩條分離路徑的 RP2PG 繞送，來源點在得到回應封包後，須挑選兩個鄰近點（A 與 B 點），並由它們各自再進行轉傳，而自來源點後的行動主機僅須挑選一個鄰近點即可，以防止路徑過分的擴散而造成網路負載過重。當一個行動主機（C 點）已對某一點（A 點）的 Request 做出回應時，若又由別的行動主機（B 點）

收到同一 Request，則不允許做出回應，如此才可產生分離的路徑（disjoint path）。

(7)

圖八：RP2PG 可能遭遇的最差情況雖然此作法增加了傳送比率成功的機會，不過也必須付出多一倍的代價來進行 Geocast，因為多產生一條路徑必須多發送一些封包才能進行。

當 Data 封包到達 Geocast 目的範圍後，須在目的範圍內進行洪流繞送，為避免對同一 Data 封包做出重覆洪流繞送，當一個行動主機（Q 點）欲進行洪流繞送前，

若已收到其他鄰近點（P 點）洪流過來的同一 Data 封包，則不再對此封包進行洪流。

圖九：兩條分離路徑方法示意圖

四、結果與討論

圖十以總節點數目為變數，觀察傳送成功所需之平均封包數目的變化。基本上，隨著節點數的增加，再廣播次數會增加，封包數目亦跟著成長。在 40 至 60 個節點時，AHBG 與 GAMER 在節點較少時的封

包數卻比節點較多時還大。原因為兩者皆須建立路徑來進行地域性群播，額外得發送控制封包，而節點少時較難建立路徑，

且可能有死巷問題出現，造成控制封包的數目增加。因此，圖十在 40 個節點時，

GAMER 的封包負載大於其他三個協定。

就整體趨勢來看，AHBG 增加的幅度明顯比其他的協定來得小（於 120 個節點至少節省 32.98%以上），表示其在網路壅塞的環境下，完成一次傳送成功不須花費太多的封包。

Packets overhead (num. of pkts per oneSuccess)

0 5 10 15 20 25 30 35 40 45 50

40 60 80 100 120

num. of nodes num

. of p kts

AHBG LBM GeoGRID GAMER

圖十：改變節點數以觀察封包數目僅以封包數目可能無法確切掌握封包負載的變化，因為有些協定需要控制封包來實作，而控制封包的大小一般都比資料封包小。圖十一為以總節點數目為變數，觀察傳送成功所需之平均封包資料量（bytes）

的變化。在 40 個節點處試與圖十對照，

GAMER 封包資料量小於 LBM 與 GeoGRID，GAMER 封包數目大於 LBM 與 GeoGRID，表示 GAMER 在網路不壅塞時，控制封包使其封包數目大於其他協定，但就封包資料量而言，是比 LBM 及 GeoGRID 小（資料封包含標頭與 payload 約為 592 bytes，控制封包約為 80 bytes）。

而 AHBG 增加的幅度仍是所有協定中最小的（於 120 個節點至少節省 31.06%以上），表示其在網路壅塞的環境下，不論就封包數目或封包資料量都相當節省，不會造成嚴重的網路負載。

(8)

Packets overhead (num. of bytes per oneSuccess)

0 5 10 15 20 25 30

40 60 80 100 120

num. of nodes num

. of b ytet s (K B)

圖十一：改變節點數以觀察封包資料量

（bytes）

圖十二是在改變總節點數目的情況下，觀察傳送比率的變化。當在 40 個節點時，傳送比率均較低，原因為節點數目較小，沒能完全散佈在整個網路區域，故到達目的範圍的有效路徑也較少。且 LBM 與 GeoGRID 又較 AHBG 與 GAMER 低些，

原因為節點數目小，LBM 與 GeoGRID 矩形傳送區域的有效路徑亦少，甚至可能出現死巷問題，反觀 AHBG 與 GAMER 等 Routing-Based protocols，傳送區域不局限於矩形，傳送比率則會較佳。當節點數多時，包括 AHBG，傳送比率均接近 100%。

Delivery Ratio

60%

65%

70%

75%

80%

85%

90%

95%

100%

105%

40 60 80 100 120

num. of nodes deliv

ery ratio (%

)

圖十二：改變節點數以觀察傳送比率圖十三為改變節點數以觀察延遲時間。

GAMER 在延遲時間方面的表現較佳，其

次為 AHBG，即因為交握程序的處理時間，以至於整體延遲時間較 GAMER 長。

而 AHBG 中記憶式路徑（3.5 節）作法，

使得交握程序花費時間的比例減少，另外，推遲時間演算法（3.2 節）減少了花費的步數（hops），故整體的延遲時間仍比 LBM 與 GeoGRID 好。

End-to-end latency

0 10 20 30 40 50 60

40 60 80 100 120

num. of nodes late

ncy (ms)

圖十三：改變節點數以觀察延遲時間接下來觀察改變節點平均速度的表現，圖十四為封包數目的變化情形。GeoGRID 明顯地隨著速度的加快而增加封包數目，

是因為其須在各個 grid 維護一個

gateway，當節點移動速度快，造成現存的

gateway 常離開該 grid，而又得選舉出另一個 gateway，反反覆覆使得封包數目增加。

GAMER 些許隨著速度增加封包數目，甚

至大於 LBM，因為節點速度快，來源點至目的範圍間不易建立路徑，而造成控制封包數目增加。整體表現仍以 AHBG 最好

（於 20 m/s 至少節省 24.64%以上），表示其在節點速度快時，仍不須花費大量的封包來進行繞送。

Packets overhead (num. of pkts per oneSuccess)

0 5 10 15 20 25 30 35 40 45

1 5 10 15 20

avg. speed num

. of p kts

圖十四：改變節點速度以觀察封包數目圖十五為改變節點速度以觀察封包資料量（bytes），GeoGRID 的曲線並沒有明顯上昇，由於控制封包小，雖然隨著速度快而增加，但所佔整體封包資料量的比例不大。整體表現仍以 AHBG 最好（於 20m/s 至少節省 21.55%以上），表示其在節點速度快時，不會造成嚴重的網路負載。

(9)

Packets overhead (num. of bytes per oneSuccess)

0 2 4 6 8 10 12 14

1 5 10 15 20

avg. speed num

. of b ytet s (K B)

圖十五：改變節點速度以觀察封包資料量

（bytes）

圖十六是在改變節點速度的情況下，觀察傳送比率的變化。GAMER 的傳送比率明顯地隨著節點速度的增加而變差，原因為節點移動速度快，已建立的路徑容易斷裂，使其無法正常傳送，且其建立路徑的週期為 1 秒，無法立即反應路徑斷裂來維護。GeoGRID 的傳送比率亦有下滑的趨勢，因為 gateway 常離開現有的 grid，當有資料封包要傳時，可能面臨該 grid 沒有 gateway 的窘境。AHBG 的表現仍是較佳

（於 20 m/s 至少增加 3.6%以上，更比

GAMER 多出 6.86%的傳送比率），由於

其可即時反應速度快所造成的路徑斷裂，

一步步順應當時的網路拓樸來進行繞送。

Delivery Ratio

80%

85%

90%

95%

100%

105%

1 5 10 15 20

avg. speed deliv

ery ratio (%

)

圖十六：改變節點速度以觀察傳送比率雖然 AHBG 在節點速度快時，封包負載與傳送比率均優於其他協定，但在延遲時間方面也付出了代價。圖十七為改變節點速度以觀察延遲時間，由於節點移動速度快，AHBG 無法順利繞送至目的範圍，故須反覆地進行交握程序，也增加了整體的延遲時間。雖然其於 20 m/s 時比其他協定至少多出 18.37%的延遲時間，但事實上，

AHBG的 37.13 ms 仍算不錯的平均延遲時間。

End-to-end latency

0 5 10 15 20 25 30 35 40 45 50

1 5 10 15 20

avg. speed late

ncy (ms)

圖十七：改變節點速度以觀察延遲時間五、計畫成果與自評

本計畫提出在隨意無線網路中，當節點數目多或移動速度快時，如何進行地域性群播，以提供高傳送比率與低封包負載的傳送服務，計畫中提出適應性的交握式地域性群播（ Adaptive Handshaking-Based Geocasting, AHBG）繞送協定，以交握式機制之傳送來取代現今廣泛使用廣播的作法，而此交握式機制能反應當下網路拓樸的變化。根據模擬結果顯示，在網路壅塞或節點移動速度快時，封包負載比其他協定至少減少 21.55%以上，傳送比率亦比其他協定佳，甚至接近 100%。然而，延遲時間是 AHBG 付出的代價，主要由於交握程序所花費的時間。

多媒體應用是近年來熱門的項目，而以 AHBG 良好的繞送特性正好可以應用在多媒體資料傳輸，如此將有低頻寬負載、高傳送比率等優點。延遲時間與延遲變化率（jitter）將是未來主要面對的挑戰，

以達到服務品質（Quality of Service, QoS）

的要求。

六、參考文獻

[1] The VINT Project. The network simulator - ns-2.

A collaboratoin between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC.

[Online]. Available:

http://www.isi.edu/nsnam/ns/

[2] T. Imieliński and J.C. Navas, “GPS-based geographic addressing, routing, and resource discovery,” Communications of the ACM, vol. 42, no. 4, Apr. 1999, pp. 86-92.

(10)

[3] M. Guarnera, M. Villari, A. Zaia, and A.

Puliafito, “MANET: possible applications with PDA in wireless imaging environment,” Personal, Indoor and Mobile Radio Communications, the 13th IEEE International Symposium , vol. 5, Sept.

2002, pp. 2394-2398.

[4] IEEE Standards Board (1997, June 26).

ANSI/IEEE Std 802.11, 1999 Edition. LAN MAN Standards Committee of the IEEE Computer

Society. [Online]. Available:

http://standards.ieee.org/getieee802/download/80 2.11-1999.pdf

[5] G. Bianchi, “Performance analysis of the IEEE 802.11 distributed coordination function,” IEEE Journal on Selected Areas in Comm., vol. 18, Mar. 1998, pp. 535-547.

[6] E.M. Royer and C.E. Perkins, “Multicast operation of the ad-hoc on-demand distance vector routing protocol,” Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, Aug. 1999, pp. 207-218.

[7] J. Boleng, T. Camp, and V. Tolety, “Mesh-based geocast routing protocols in an ad hoc network,”

Proceedings of IPDPS, Apr. 2001, pp. 184-193.

[8] T. Camp and Y. Liu, “An adaptive mesh-based protocol for geocast routing,”Journal of Parallel and Distributed Computing: Special Issue on Routing in Mobile and Wireless Ad Hoc Networks, vol. 62, no. 2, 2003, pp. 196-213.

[9] C.-Y. Chang, C.-T. Chang, and S.-C. Tu,

“Obstacle-free geocasting protocols for single/multi-destination short message services in ad hoc networks,”Wireless Networks, vol. 9, no.

2, 2003, pp. 143-155.

[10] Y. Ko and N.H. Vaidya, “GeoTORA: A protocol for geocasting in mobile ad hoc networks,”

Proceedings of ICNP, Nov. 2000, pp. 240-250.

[11] Y. Ko and N.H. Vaidya, “Geocasting in mobile ad hoc networks: Location-based multicast algorithms,” Proceedings of WMCSA, 1999, pp.

101-110.

[12] Y. Ko and N.H. Vaidya, “Flooding-based geocasting protocols for mobile ad hoc networks,” Mobile Networks and Applications, Dec. 2002.

[13] S.-Y. Ni, Y.-C. Tseng, Y.-S. Chen, and J.-P.

Sheu, “The broadcast storm problem in a mobile ad hoc network,” Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, Aug. 1999.

[14] W.-H. Liao, Y.-C. Tseng, K.-L. Lo, and J.-P.

Sheu, “GeoGRID: A geocasting protocol for mobile ad hoc networks based on GRID,”

Journal of Internet Technology, vol. 1, no. 2, 2000, pp. 23-32.

[15] P. Yao, E. Krohne, and T. Camp, “Performance comparison of geocast routing protocols for a manet,” Technical report, Department of Math.

and Computer Sciences, Colorado School of Mines, May 2004.

[16] X. Jiang and T. Camp, “A review of geocasting

protocols for a mobile ad hoc network,” Grace Hopper Celebration (GHC), 2002.

[17] A. Bachir and A. Benslimane, “Multicast protocol in ad hoc networks inter-vehicle geocast,” VTC 2003-Spring, The 57th IEEE Semiannual, vol. 4, April 2003, pp. 22-25.

[18] A.M.K. Cheng and K. Rajan, “A digital map/GPS based routing and addressing scheme for wireless ad-hoc networks,” Intelligent Vehicles Symposium, Proceedings. IEEE, Jun.

2003, pp. 9-11.