無線感知網路的基本概念是三低：耗電低、傳輸距離低、而且傳輸速度也低。裝置在設計的時候亦是以低成本為主要考量。整個無線感知網路系統必須依靠大量的佈建節點，各節點的無線傳輸範圍互相涵蓋，如此才能建構出一個大型的服務範圍。在網路中，資料以點對點自由傳輸(ad-hocs)的方式，一點一點傳輸至目的地。
無線感知網路的狂熱與現實
早在數年以前，『無線感知網路』這個概念剛剛開始形成的時候，這個新技術被認為可以應用在各式各樣的場合；可以適用於工業控制、醫療保健、家庭自動化，還有其他許許多多充滿期望的願景。然而，過了數年的時間，我們到現在為止都還沒有在市場上看到一個可以被視為『典範』，或是『殺手級』的無線感知網路應用。回頭看看過去數年的發展，我們不難發現在整個晶片產業、以及服務整合產業之中，對這個新技術都有過度樂觀估算的現象；熟知這一項技術的工程師以及市場分析師們，會告訴你各式各樣複雜而令人頭昏的理論來解釋這個現象。在本文中我們不打算去深究這些原因；我們將專注於討論其中一項主要的因素：在現實世界佈建一個無線感知網路所需要花費的成本。
任何一種無線感知網路，都存在各式各樣的限制。在一個環境受到嚴密控制的實驗室中，我們可以很簡單的建構出一個理想的網路，讓網路完全按這我們想要的方式擴張，讓封包按照我們想要的方式傳送。然而，當我們進入現實世界，我們會受到各式各樣的環境因素限制：牆壁、樓層、階梯、門廊、電力線、甚至水管。這些看似極端瑣碎無聊的東西，對於整個無線訊號環境會帶來完全超出預期的影響。在大多數的佈建案中，想要完全依靠無線技術來建構一個能夠傳遞資料的感知網路，根本是一件不可能的任務。因為這個限制，無線感知網路的規模一直無法突破瓶頸。
在本文中，我們將深入探討無線感知網路在現實世界佈建中會碰到的問題，同時我們將介紹一種新的跨網路整合技術；這種技術目前已經融合入ZigBee無線通訊協定的標準中。藉由這種新技術，我們將會使用一種全新的視點來評估無線感知網路的佈建這件事。
無線感知網路的本質
在現實世界中，要佈建一個使用ZigBee通訊協定的無線感知網路會有多困難？要了解這個問題，首先我們必須先了解無線感知網路的本質。
無線感知網路的基本概念是三低：耗電低、傳輸距離低、而且傳輸速度也低。裝置在設計的時候亦是以低成本為主要考量。整個無線感知網路系統必須依靠大量的佈建節點，各節點的無線傳輸範圍互相涵蓋，如此才能建構出一個大型的服務範圍。在網路中，資料以點對點自由傳輸(ad-hocs)的方式，一點一點傳輸至目的地。
這樣的需求在實作上，通常是由一些具有動態調整特性的路由選徑演算法來達成。舉例來說，最常見的自組網路隨傳距離向量演算法(Ad-hoc On-Demand Vector，AODV)；這種演算法被實作在許多不同的通訊技術中，包括ZigBee。AODV是一種具備動態調整路徑的技術，他執行的方式就是將選徑封包用廣播方式淹沒(Flood)整個網路，藉此搜尋一條往目標節點的最短路徑。
顯而易見的，這種路由選徑方式在某些特定的應用情境中，是很沒有效率的做法；尤其是當網路的涵蓋範圍越變越大的時候。同時，AODV本身只是路由選徑技術，並不包含對於網路『管理』方面的功能。對於一個需要更嚴謹的管理功能的無線網路，必須另外尋找一套更加完整的網路通訊行為模式，包括網路的形成、裝置的認證、以及裝置的定址管理。
ZigBee通訊協議所採用的網路通訊行為模式即是一種以樹狀結構為基礎的技術。在這種網路模式中，每一個節點必須按照一定的順序依次『加入』網路。每一個節點的網路位址是在加入網路的同時，依據它在網路中的『位置』計算而得知。這樣的規則相當單純：整個網路首先必須由一個『根節點』(Coordinator)形成；在根節點建立起整個網路之後，其他的節點便會試著與根節點要求建立網路連線。
在ZigBee網路中，封包可以根據目的位址計算出下一個節點該往哪邊傳輸。這個網路行為模式相當單純且易於實作，然而這種方式帶來最直接的影響，就是網路位址空間的浪費。ZigBee通訊協定預設整個網路是一個『平衡的』樹狀結構，亦即每個節點都應該要能接受預設的最大連線數量，以此一假設為基數進行位址的計算與分配。然而IEEE 802.15.4本身使用的動態網路位址只有兩個位元組，亦即整個網路最大不能超過65536個節點，包括實際存在的節點以及『可能會』存在的節點。在這種條件限制下，無論是每個節點可接受的最大連線數量，以及整個網路的最大階層數量，都會受到很大的限制。
現實世界佈建的各種問題
在現實世界佈建時，基本的規則是：節點的無線範圍必須互相涵蓋。這項要求在開放空間或許很容易達成，但是在複雜空間中，這是很困難的事。建築為了有效率的使用空間，會用各式各樣的隔間來劃分走道與房間。建築的材料本身有時候會遮蔽無線訊號，因此實際上能夠佈建的地點受到限制。在大多數的佈建案中，裝置都被侷限在人的活動空間中；無線訊號的軌跡實際上也是依照走道、門廊、樓梯的路徑。這些問題通常會導致兩種常見的問題：長鏈狀網路，以及傳輸瓶頸。
長鏈狀網路是最常發生的佈建問題，特別是在複雜的環境中，例如辦公室、學校、醫院等地。在這些環境中，佈建的區域通常較大，同時根節點位置的選擇通常不是依照無線特性或拓墣結構等技術因素；實際上在大部分的佈建案中，決定根節點位置的，是使用者的喜好、將就現有裝置、以及環境的美觀等等非技術因素。
為了能夠彌補這些限制，額外的中繼節點必須佈建在系統中，以維持整體網路能夠互相涵蓋。這樣會產生兩個額外的效應：首先，額外的網路深度會限制每個節點能夠容許的連線數量。因此整體網路的規模會受到限制。其次，越大的網路深度，表示更久的延遲，以及更高的封包遺失率。如果系統的應用情境無法容忍封包的遺失，逾時重傳以及流量管制等機制是必要加入系統中。如此一來，網路整體的效能將會大幅下降。
傳輸瓶頸是另外一個常見的問題。這個問題通常發生在多個感測節點必須依賴單一一個中繼節點來轉發資料的狀況。
圖2顯示一個典型的傳輸瓶頸問題。在這個情境中，感測節點被佈建在數個彼此分隔的獨立空間中，例如教室或是多樓層的佈建。多個感測器被佈建在一個廣大的空間中，例如大會議室，然後這些感測節點必須依賴單一一個節點來轉發資料，例如安裝在會議室門框上緣的路由器。如果感測節點的資料發送很頻繁，例如位置追蹤等應用，中繼節點的資料壅塞狀況就會很明顯。使用流量控制與緩衝等機制有助於改善封包壅塞的狀況，但是這些節點使用的MCU通常不會具備太高的運算能力以及儲存空間，通常上限只有10到20個封包的空間。超出這個容量，後續的封包還是會被捨棄。
對於這些現實佈建會發生的問題，最有效的解決方案就是將網路拆分成數個較小的區快。每一個區塊可以被視為是一個小型的獨立網路，因此在這些區塊中，比較容易形成『平衡的』網路拓璞。在某些應用情境中，會將異質網路終端點與各區塊的根節點連接，也就是在物理與邏輯上都把一個大型網路切分成數個小網路。網路與網路之間的資料傳輸，全部依靠異質網路上的應用程式來轉發。這樣的解決方案通常會使用一些現成的轉換裝置，例如RS232到Ethernet的轉接器。
在圖3中，我們可以明顯看出兩種不同架構的差異。資料路徑長度明顯降低，同時整體網路效能也大幅提升。這樣的解決方案在固定的應用情境中可以達到很理想的效能，然而這個解決方案同時存在一個問題：網路系統的功能會難以擴充。上述的解決方案需要依靠應用程式將接收到的封包轉換成特定的序列傳輸資料。當有新的應用加入這個網路中時，區塊根節點如果沒有相對應的處理程式(Profile)存在，將無法轉發這種封包。這個問題會發生的主要原因是由於依賴應用程式層級來進行封包轉發，如果我們需要一個更加通用的解決方案，我們要從更底層著手。
ZigBee Bridge
ZigBee在2005年底，正式把整合異質網路來克服各種實際佈建問題的概念納入ZigBee通訊協定的發展藍圖之中。Gateway Workgroup(GWG)是目前負責制定相關應用規格的組織，日前該組織公佈了一份新的標準：ZigBee Bridge。
ZigBee Bridge與傳統依靠應用程式層級來進行封包橋接的做法不同，ZigBee Bridge在第二層data-link層進行封包交換。這樣的特向可以讓一個ZigBee Bridge完全不需要依靠使用者自動的應用程式，便可以交換所有類型的封包。因此ZigBee Bridge可以視作是一個單純的『路由器』。
一個新的封包交換層介於Network層以及MAC層之間，原始資料在這一層進行交換，對於上層的通訊協定不會造成任何干擾，上層的通訊協定也不需要任何修改便可正常工作。橋接層可以分成三個不同的功能區塊：橋接路由層(Bridge Routing Layer)，橋接裝置層(Bridge Device Layer)，以及網際網路層(ZigBee IP Transport Layer)。
橋接路由層負責解析外送的封包，依照封包的目的地位址，配合預先制定的對應表，將封包分派至 無線電界面或是IP網路界面。橋接路由層的功能存取界面設計成和802.15.4完全相同，亦即上層Network層完全不需要進行任何修改就可以與橋接路由層界接。
橋接裝置層負責封包資料的封裝與解封，同時負責維持IP網路的連線。橋接裝置層同時負責提供類似802.15.4 MLDE與MLME的資料與管理服務，讓橋接路由層呼叫取用。包括建立連線、傳輸與接收封包、以及模擬Scan、Associate等動作。
網際網路層負責實際的封包傳輸。根據ZigBee Bridge標準規範，預設使用的傳輸協定是UDP/IP，IANA分配的通訊埠17755。ZigBee Bridge也支援透過TCP/IP的封包傳輸形式，不過由於TCP/IP需要維護連線，對於一般低成本裝置來說，會耗費過大的系統運算資源。因此TCP/IP的支援在目前被列為是選擇性支援。
ZigBee Bridge應用於現實世界佈建
ZigBee Bridge最早的構想是使用IP網路來連接一個PAN裡面的兩個節點，藉此製造一個封包的『蟲洞』，或者用來連接兩個實體隔離的PAN。但是很快的，研究人員發現了ZigBee Bridge另外一種用處。ZigBee Bridge的橋接層，在設計上被視為一個實體抽象層；上層不需要知道資料到底是從RF傳輸還是從IP傳輸。理論上，這樣的結構可以延伸發展，以包含更多不同的界面；或是反過來，將某些實體界面從架構中抽離。由於有這樣的特性，我們可以建構一個只包含IP界面的裝置，或者換句話說，一個不包含無線界面的ZigBee裝置。
這種不包含RF界面的ZigBee裝置，可以完全由軟體構成，不再受到現有的2.4GHz無線傳輸平台限制。這個『裝置』可能是一個在UNIX伺服器上運作的daemon，或是在Windows伺服器上運作的服務。我們甚至可能讓多個不同的虛擬裝置同時存在於一台主機之上。
『虛擬ZigBee裝置』為現實應用情境的發展帶來很多的可能性。使用者程式現在可以使用正常的IPC(Inter-Process Communication)管道與ZigBee裝置進行資料交換。應用程式也可以在任何一個有IP網路連線的裝置上執行，不必侷限於佈建的現場。
利用這項技術，我們得以描繪出一個新的系統佈建方式。首先我們藉由Ethernet、HomePNA、WiFi甚或GPRS建構一個IP網路骨幹。接下來我們根據功能或是實際無線的環境條件，將整個無線感知網路劃分成多個小區塊。每一個小區塊安裝一個ZigBee Bridge裝置，連接至IP骨幹網路。最後，我們架設一台伺服器，上面執行虛擬的ZigBee根節點，藉此形成整個ZigBee網路。在這樣的架構中，所有的ZigBee Bridge都被視為是虛擬根節點底下的第一層Router，資料首先透過IP網路傳至Bridge，在透過無線訊號傳至小區塊裡面的無線節點。
Case Study:AMR讀表系統
我們最後用一個範例當作結論。這個範例是一個AMR系統，亦即自動讀表系統(Automatic Meter Reader)，例如瓦斯、電表、水表等。近年來這是無線感知網路領域的一個熱門主題。AMR系統的最大挑戰就是：必須實際佈建在住宅建築中，網路的規模取決於建築物本身。一個五層樓的公寓規模相對較小且容易執行，但是一棟10層樓以上的大廈就完全是另外一回事了。
圖5顯示一個典型的AMR系統佈建方式。在這個例子中，系統被佈建在一棟12層樓的大樓中，每層樓有4戶需要安裝。樓板本身會阻隔無線訊號，因此必須沿著樓梯天井或是外牆佈建中繼節點，以確保資料路徑的暢通。然後資料蒐集/顯示裝置被安裝在大樓1樓的入口處，以便於瓦斯或者電力公司人員擷取資料。從1樓到12樓，總共有11個階層，亦即每個節點可接受的連線數量限制在兩個以下。如圖所示，最長的路徑深度是15層，已經到達ZigBee規格的最大上限。如果樓層數量比12層更多，或是每層樓的戶數比4戶更多，整個系統就無法形成網路。
若使用ZigBee Bridge，整個網路將會有完全不同的架構。每個樓層被劃分成一個區塊，12個ZigBee Bridge裝置透過骨幹網路直接與虛擬ZigBee根節點建立連線，每層樓的4個感測器直接與Bridge裝置進行連線(只要無線訊號能夠涵蓋)。亦即在這個網路中，整體的最大深度只有2(或3)。與傳統的佈建方式相比，差異非常明顯。
結論
ZigBee Bridge技術提供了一個符合標準的異質網路整合解決方案。同時也提供了一個全心的無線感知網路佈建方式。在這種新的架構中，無線感枝節點被劃分成多區塊，每個區塊藉由ZigBee Bridge裝置與IP網路與資料骨幹連結，同時一個完全由軟體元件構成的虛擬 ZigBee根節點負責整個網路的建立。這種方式將會有效的克服現實世界佈建發生的各種問題，簡化網路架構，同時提升網路整體效能。
無線感知網路的狂熱與現實
早在數年以前，『無線感知網路』這個概念剛剛開始形成的時候，這個新技術被認為可以應用在各式各樣的場合；可以適用於工業控制、醫療保健、家庭自動化，還有其他許許多多充滿期望的願景。然而，過了數年的時間，我們到現在為止都還沒有在市場上看到一個可以被視為『典範』，或是『殺手級』的無線感知網路應用。回頭看看過去數年的發展，我們不難發現在整個晶片產業、以及服務整合產業之中，對這個新技術都有過度樂觀估算的現象；熟知這一項技術的工程師以及市場分析師們，會告訴你各式各樣複雜而令人頭昏的理論來解釋這個現象。在本文中我們不打算去深究這些原因；我們將專注於討論其中一項主要的因素：在現實世界佈建一個無線感知網路所需要花費的成本。
任何一種無線感知網路，都存在各式各樣的限制。在一個環境受到嚴密控制的實驗室中，我們可以很簡單的建構出一個理想的網路，讓網路完全按這我們想要的方式擴張，讓封包按照我們想要的方式傳送。然而，當我們進入現實世界，我們會受到各式各樣的環境因素限制：牆壁、樓層、階梯、門廊、電力線、甚至水管。這些看似極端瑣碎無聊的東西，對於整個無線訊號環境會帶來完全超出預期的影響。在大多數的佈建案中，想要完全依靠無線技術來建構一個能夠傳遞資料的感知網路，根本是一件不可能的任務。因為這個限制，無線感知網路的規模一直無法突破瓶頸。
在本文中，我們將深入探討無線感知網路在現實世界佈建中會碰到的問題，同時我們將介紹一種新的跨網路整合技術；這種技術目前已經融合入ZigBee無線通訊協定的標準中。藉由這種新技術，我們將會使用一種全新的視點來評估無線感知網路的佈建這件事。
無線感知網路的本質
在現實世界中，要佈建一個使用ZigBee通訊協定的無線感知網路會有多困難？要了解這個問題，首先我們必須先了解無線感知網路的本質。
無線感知網路的基本概念是三低：耗電低、傳輸距離低、而且傳輸速度也低。裝置在設計的時候亦是以低成本為主要考量。整個無線感知網路系統必須依靠大量的佈建節點，各節點的無線傳輸範圍互相涵蓋，如此才能建構出一個大型的服務範圍。在網路中，資料以點對點自由傳輸(ad-hocs)的方式，一點一點傳輸至目的地。
這樣的需求在實作上，通常是由一些具有動態調整特性的路由選徑演算法來達成。舉例來說，最常見的自組網路隨傳距離向量演算法(Ad-hoc On-Demand Vector，AODV)；這種演算法被實作在許多不同的通訊技術中，包括ZigBee。AODV是一種具備動態調整路徑的技術，他執行的方式就是將選徑封包用廣播方式淹沒(Flood)整個網路，藉此搜尋一條往目標節點的最短路徑。
顯而易見的，這種路由選徑方式在某些特定的應用情境中，是很沒有效率的做法；尤其是當網路的涵蓋範圍越變越大的時候。同時，AODV本身只是路由選徑技術，並不包含對於網路『管理』方面的功能。對於一個需要更嚴謹的管理功能的無線網路，必須另外尋找一套更加完整的網路通訊行為模式，包括網路的形成、裝置的認證、以及裝置的定址管理。
ZigBee通訊協議所採用的網路通訊行為模式即是一種以樹狀結構為基礎的技術。在這種網路模式中，每一個節點必須按照一定的順序依次『加入』網路。每一個節點的網路位址是在加入網路的同時，依據它在網路中的『位置』計算而得知。這樣的規則相當單純：整個網路首先必須由一個『根節點』(Coordinator)形成；在根節點建立起整個網路之後，其他的節點便會試著與根節點要求建立網路連線。
在ZigBee網路中，封包可以根據目的位址計算出下一個節點該往哪邊傳輸。這個網路行為模式相當單純且易於實作，然而這種方式帶來最直接的影響，就是網路位址空間的浪費。ZigBee通訊協定預設整個網路是一個『平衡的』樹狀結構，亦即每個節點都應該要能接受預設的最大連線數量，以此一假設為基數進行位址的計算與分配。然而IEEE 802.15.4本身使用的動態網路位址只有兩個位元組，亦即整個網路最大不能超過65536個節點，包括實際存在的節點以及『可能會』存在的節點。在這種條件限制下，無論是每個節點可接受的最大連線數量，以及整個網路的最大階層數量，都會受到很大的限制。
現實世界佈建的各種問題
在現實世界佈建時，基本的規則是：節點的無線範圍必須互相涵蓋。這項要求在開放空間或許很容易達成，但是在複雜空間中，這是很困難的事。建築為了有效率的使用空間，會用各式各樣的隔間來劃分走道與房間。建築的材料本身有時候會遮蔽無線訊號，因此實際上能夠佈建的地點受到限制。在大多數的佈建案中，裝置都被侷限在人的活動空間中；無線訊號的軌跡實際上也是依照走道、門廊、樓梯的路徑。這些問題通常會導致兩種常見的問題：長鏈狀網路，以及傳輸瓶頸。
長鏈狀網路是最常發生的佈建問題，特別是在複雜的環境中，例如辦公室、學校、醫院等地。在這些環境中，佈建的區域通常較大，同時根節點位置的選擇通常不是依照無線特性或拓墣結構等技術因素；實際上在大部分的佈建案中，決定根節點位置的，是使用者的喜好、將就現有裝置、以及環境的美觀等等非技術因素。
為了能夠彌補這些限制，額外的中繼節點必須佈建在系統中，以維持整體網路能夠互相涵蓋。這樣會產生兩個額外的效應：首先，額外的網路深度會限制每個節點能夠容許的連線數量。因此整體網路的規模會受到限制。其次，越大的網路深度，表示更久的延遲，以及更高的封包遺失率。如果系統的應用情境無法容忍封包的遺失，逾時重傳以及流量管制等機制是必要加入系統中。如此一來，網路整體的效能將會大幅下降。
傳輸瓶頸是另外一個常見的問題。這個問題通常發生在多個感測節點必須依賴單一一個中繼節點來轉發資料的狀況。
圖2顯示一個典型的傳輸瓶頸問題。在這個情境中，感測節點被佈建在數個彼此分隔的獨立空間中，例如教室或是多樓層的佈建。多個感測器被佈建在一個廣大的空間中，例如大會議室，然後這些感測節點必須依賴單一一個節點來轉發資料，例如安裝在會議室門框上緣的路由器。如果感測節點的資料發送很頻繁，例如位置追蹤等應用，中繼節點的資料壅塞狀況就會很明顯。使用流量控制與緩衝等機制有助於改善封包壅塞的狀況，但是這些節點使用的MCU通常不會具備太高的運算能力以及儲存空間，通常上限只有10到20個封包的空間。超出這個容量，後續的封包還是會被捨棄。
對於這些現實佈建會發生的問題，最有效的解決方案就是將網路拆分成數個較小的區快。每一個區塊可以被視為是一個小型的獨立網路，因此在這些區塊中，比較容易形成『平衡的』網路拓璞。在某些應用情境中，會將異質網路終端點與各區塊的根節點連接，也就是在物理與邏輯上都把一個大型網路切分成數個小網路。網路與網路之間的資料傳輸，全部依靠異質網路上的應用程式來轉發。這樣的解決方案通常會使用一些現成的轉換裝置，例如RS232到Ethernet的轉接器。
在圖3中，我們可以明顯看出兩種不同架構的差異。資料路徑長度明顯降低，同時整體網路效能也大幅提升。這樣的解決方案在固定的應用情境中可以達到很理想的效能，然而這個解決方案同時存在一個問題：網路系統的功能會難以擴充。上述的解決方案需要依靠應用程式將接收到的封包轉換成特定的序列傳輸資料。當有新的應用加入這個網路中時，區塊根節點如果沒有相對應的處理程式(Profile)存在，將無法轉發這種封包。這個問題會發生的主要原因是由於依賴應用程式層級來進行封包轉發，如果我們需要一個更加通用的解決方案，我們要從更底層著手。
ZigBee Bridge
ZigBee在2005年底，正式把整合異質網路來克服各種實際佈建問題的概念納入ZigBee通訊協定的發展藍圖之中。Gateway Workgroup(GWG)是目前負責制定相關應用規格的組織，日前該組織公佈了一份新的標準：ZigBee Bridge。
ZigBee Bridge與傳統依靠應用程式層級來進行封包橋接的做法不同，ZigBee Bridge在第二層data-link層進行封包交換。這樣的特向可以讓一個ZigBee Bridge完全不需要依靠使用者自動的應用程式，便可以交換所有類型的封包。因此ZigBee Bridge可以視作是一個單純的『路由器』。
一個新的封包交換層介於Network層以及MAC層之間，原始資料在這一層進行交換，對於上層的通訊協定不會造成任何干擾，上層的通訊協定也不需要任何修改便可正常工作。橋接層可以分成三個不同的功能區塊：橋接路由層(Bridge Routing Layer)，橋接裝置層(Bridge Device Layer)，以及網際網路層(ZigBee IP Transport Layer)。
橋接路由層負責解析外送的封包，依照封包的目的地位址，配合預先制定的對應表，將封包分派至 無線電界面或是IP網路界面。橋接路由層的功能存取界面設計成和802.15.4完全相同，亦即上層Network層完全不需要進行任何修改就可以與橋接路由層界接。
橋接裝置層負責封包資料的封裝與解封，同時負責維持IP網路的連線。橋接裝置層同時負責提供類似802.15.4 MLDE與MLME的資料與管理服務，讓橋接路由層呼叫取用。包括建立連線、傳輸與接收封包、以及模擬Scan、Associate等動作。
網際網路層負責實際的封包傳輸。根據ZigBee Bridge標準規範，預設使用的傳輸協定是UDP/IP，IANA分配的通訊埠17755。ZigBee Bridge也支援透過TCP/IP的封包傳輸形式，不過由於TCP/IP需要維護連線，對於一般低成本裝置來說，會耗費過大的系統運算資源。因此TCP/IP的支援在目前被列為是選擇性支援。
ZigBee Bridge應用於現實世界佈建
ZigBee Bridge最早的構想是使用IP網路來連接一個PAN裡面的兩個節點，藉此製造一個封包的『蟲洞』，或者用來連接兩個實體隔離的PAN。但是很快的，研究人員發現了ZigBee Bridge另外一種用處。ZigBee Bridge的橋接層，在設計上被視為一個實體抽象層；上層不需要知道資料到底是從RF傳輸還是從IP傳輸。理論上，這樣的結構可以延伸發展，以包含更多不同的界面；或是反過來，將某些實體界面從架構中抽離。由於有這樣的特性，我們可以建構一個只包含IP界面的裝置，或者換句話說，一個不包含無線界面的ZigBee裝置。
這種不包含RF界面的ZigBee裝置，可以完全由軟體構成，不再受到現有的2.4GHz無線傳輸平台限制。這個『裝置』可能是一個在UNIX伺服器上運作的daemon，或是在Windows伺服器上運作的服務。我們甚至可能讓多個不同的虛擬裝置同時存在於一台主機之上。
『虛擬ZigBee裝置』為現實應用情境的發展帶來很多的可能性。使用者程式現在可以使用正常的IPC(Inter-Process Communication)管道與ZigBee裝置進行資料交換。應用程式也可以在任何一個有IP網路連線的裝置上執行，不必侷限於佈建的現場。
利用這項技術，我們得以描繪出一個新的系統佈建方式。首先我們藉由Ethernet、HomePNA、WiFi甚或GPRS建構一個IP網路骨幹。接下來我們根據功能或是實際無線的環境條件，將整個無線感知網路劃分成多個小區塊。每一個小區塊安裝一個ZigBee Bridge裝置，連接至IP骨幹網路。最後，我們架設一台伺服器，上面執行虛擬的ZigBee根節點，藉此形成整個ZigBee網路。在這樣的架構中，所有的ZigBee Bridge都被視為是虛擬根節點底下的第一層Router，資料首先透過IP網路傳至Bridge，在透過無線訊號傳至小區塊裡面的無線節點。
Case Study:AMR讀表系統
我們最後用一個範例當作結論。這個範例是一個AMR系統，亦即自動讀表系統(Automatic Meter Reader)，例如瓦斯、電表、水表等。近年來這是無線感知網路領域的一個熱門主題。AMR系統的最大挑戰就是：必須實際佈建在住宅建築中，網路的規模取決於建築物本身。一個五層樓的公寓規模相對較小且容易執行，但是一棟10層樓以上的大廈就完全是另外一回事了。
圖5顯示一個典型的AMR系統佈建方式。在這個例子中，系統被佈建在一棟12層樓的大樓中，每層樓有4戶需要安裝。樓板本身會阻隔無線訊號，因此必須沿著樓梯天井或是外牆佈建中繼節點，以確保資料路徑的暢通。然後資料蒐集/顯示裝置被安裝在大樓1樓的入口處，以便於瓦斯或者電力公司人員擷取資料。從1樓到12樓，總共有11個階層，亦即每個節點可接受的連線數量限制在兩個以下。如圖所示，最長的路徑深度是15層，已經到達ZigBee規格的最大上限。如果樓層數量比12層更多，或是每層樓的戶數比4戶更多，整個系統就無法形成網路。
若使用ZigBee Bridge，整個網路將會有完全不同的架構。每個樓層被劃分成一個區塊，12個ZigBee Bridge裝置透過骨幹網路直接與虛擬ZigBee根節點建立連線，每層樓的4個感測器直接與Bridge裝置進行連線(只要無線訊號能夠涵蓋)。亦即在這個網路中，整體的最大深度只有2(或3)。與傳統的佈建方式相比，差異非常明顯。
結論
ZigBee Bridge技術提供了一個符合標準的異質網路整合解決方案。同時也提供了一個全心的無線感知網路佈建方式。在這種新的架構中，無線感枝節點被劃分成多區塊，每個區塊藉由ZigBee Bridge裝置與IP網路與資料骨幹連結，同時一個完全由軟體元件構成的虛擬 ZigBee根節點負責整個網路的建立。這種方式將會有效的克服現實世界佈建發生的各種問題，簡化網路架構，同時提升網路整體效能。
