本文將以ZigBee無線感測網路骨幹裝置為核心，介紹兩種結合IP網路的ZigBee交換裝置。兩種裝置各自有不同的系統，以及不同的適用情境。然而兩種裝置對於架設多元化的無線感測網路環境此一目標，皆有著相當重要的地位。
前言
在無線感測網路的技術領域中，與傳統無線通訊解決方案最大的區別，就在於無線網路的標準化。在傳統的無線通訊解決方案中，各家的產品缺乏共通標準，只能與自家的產品互動。不同產品之間產生的干擾問題也時有所聞。無線感測網路的標準化，以及認證制度的推行，使得廠商有一個可以依循的方向。只要依循此一標準設計製造的產品，便可以保證與不同廠商裝置之間的相容性。這種特性對於廠商而言，最直接的效益就是產品將不再受到無線訊號本身的侷限。
傳統的無線通訊解決方案，通訊端與接收端必須維持在無線電訊號範圍內。而在無線感測網路技術領域，利用無線感測網路通訊協定的多點傳輸特性，便可僅依靠低傳輸功率的通訊裝置，達到廣域服務涵蓋面積的目的。無線感測網路通訊協定的標準化，更進一步擴展了無線感知網路的功能性：符合通訊協定標準的裝置，即可無障礙地利用一個已經建構完成的無線感測網路系統進行通訊。
由於這樣的特性，在無線感測網路的市場中自然衍生出兩種不同特性的裝置：不具備特定應用程式功能、但可用來架設無線感測網路骨幹(Backbone)的裝置，以及專門為了某些特定目的而開發的無線感測網路應用裝置。
無線感測網路應用裝置本身僅需具備通訊協定的存取界面，需要的技術能力比較少。然而無線感測網路骨幹裝置則是需要考慮到現實世界實際佈建的各種問題，同時需要考慮到各種多元化應用裝置的擴充性，無輪在設計上、或是實際佈建上，都會面臨相當多的挑戰。
本文將以ZigBee無線感測網路骨幹裝置為核心，介紹兩種結合IP網路的ZigBee交換裝置。兩種裝置各自有不同的系統，以及不同的適用情境。然而兩種裝置對於架設多元化的無線感測網路環境此一目標，皆有著相當重要的地位。
佈建的常見問題
任何一種無線感知網路，都存在各式各樣的限制。在一個環境受到控制的實驗室中，我們可以很簡單的建構出一個理想的網路，讓網路完全按這我們想要的方式擴張，讓封包按照我們想要的方式傳送。然而，當我們進入現實世界，我們會受到各式各樣的環境因素限制。在大多數的佈建案中，想要完全依靠無線技術來建構一個能夠傳遞資料的感知網路，是一件極端困難的挑戰。
在現實世界中基本佈建的規則是：節點的無線訊號範圍必須能夠互相涵蓋。這項要求在開放空間或許很容易達成，但是在複雜空間中，往往會產生各種意料之外的問題。佈建在室內空間的ZigBee網路，除非是在建築物建造或裝潢的時候就嵌入成為建材的一部份，否則必然是等裝潢完成後才進駐佈建。
ZigBee的無線訊號可以穿越木板、玻璃、石膏板、磚牆、水泥裝飾牆等裝潢隔間材質，但是無法穿越內含鋼骨的結構牆、金屬門、金屬隔間櫃等厚重物體，因此網路連線必定會受到建築結構的限制。舉例來說，房間與房間之間可能受到結構牆阻隔無法直接通訊，必須在房門口附近裝設一個中繼節點；樓層與樓層之間可能會因為加重承載結構無法直接通訊，需要由外牆、陽台、天井、樓梯井等地方架設數個中繼節點。這些問題通常會導致兩種常見的問題：網路傳輸路徑過長導致延遲過高，或是造成一個特別繁忙的瓶頸節點。
對於這些現實佈建物理限制所造成的問題，最有效率的解決方案就是將網路拆分成數個較小的區塊。每一個區塊可以被視為是一個小型的獨立網路，因此在這些區塊中，比較容易形成『平衡的』網路拓璞。每一個獨立區塊可以被視作為一個叢集(Cluster)。每個叢集會設置一個主要的控制節點，用來作為叢集資料的統一出入口。利用這種方式，可以比較有效率的達成流量分散、降低干擾等功用。然而叢集控制點的設計，變成很重要的關鍵。在某些應用情境中，會將依靠異質網路來作為叢集控制點與叢集控制點之間資料傳輸的通道，亦即叢集控制點本身即是扮演一個橋接器(Bridge)裝置的功用。
有相當多的實際應用案例採用這種方式佈建。低成本佈建的解決方案通常會使用一些現成的轉換裝置，例如RS232-to-Ethernet的轉接器，後端則是連接普通IP網路。這樣的解決方案相當有效率，然而這種解決方案通常伴隨著潛在問題。這種類型的佈建方式，橋接裝置幾乎毫無例外的採用應用程式層級的方式來實作封包轉發功能。由於通訊協定天生的封裝與解封裝(Capsulation & De-capsulation)性質，應用程式層級只能取得封裝的內容(Payload)，無法取得封裝的標頭(Header)。因此應用程式層級的封包轉發橋接器，只能依靠封裝內容來作為轉發判斷的依據。要做到這一點，封裝內容必須有一定的格式要求；換句話說，就是缺乏共通性與相容性。
在實際的佈建案例中，採用RS232-to-Ethernet轉接器的低成本佈建解決方案，幾乎都是為了單一用途而建構。在這種網路中如果想要增加新的功能，是非常困難的事。在不變更原有節點的前提下，幾乎不可能容納另外一個不同廠商的系統。
相容性的極限
通訊協定確保的是資料傳輸與轉發的相容性，而不是資料本身的相容性。以應用程式的層級來說，除非應用程式本身也依循某些標準規範，例如X.10自動控制，否則不同廠商生產的裝置，幾乎不可能相容。
這一點對於生產終端設備的廠商來說，可能反而是一種求之不得的壟斷優勢：任何購買Ａ公司的控制器的使用者，只能回過頭來購買Ａ公司生產的設備；因為Ａ公司的控制器，無法控制Ｂ公司的設備。從設備業者或是工程師的角度思考，這是很合情合理的結果；但是對於一個只是想要整合不同解決方案的使用者來說，這種缺乏相容的特性就顯得荒謬而可笑。
試想一個情境：在一個會議室中，先要尋找控制器Ａ來啟動空調設備，然後尋找控制器Ｂ來放下窗簾與投影屏幕，然後尋找控制器Ｃ來啟動投影機，最後再拿一開始用過的控制Ａ來關閉燈光。這樣的情境不只讓人不耐，更會讓人產生一種『無線感測網路並沒有帶來多少便利性』的負面印象。
將控制界面用個人電腦應用程式的方式製作，看似一個可行的解決方案：至少你可以在一台電腦前控制所有東西，而不需要去找一大堆控制器。但是以目前現行的眾多實作，這種做法也只是換湯不換藥。
採用這種解決方案的廠商，會提供你一個安裝軟體，以及一個硬體插件(Dangle)，同時會指示你用RS232或是USB連線把這個硬體插件連接到電腦上，然後執行控制程式。問題是：控制程式只認得特定的硬體插件，於是Ａ公司控制程式無法控制Ｂ公司硬體插件的老戲碼再次上演。各位可以試著想像另外一個情境：一個工程師捧著一台Notebook電腦站在會議室一角，Notebook後面接了一個USB Hub，然後Hub上插滿了各種形狀、顏色、大小都不同的硬體插件。
相信不用我說各位也曉得：這樣看起來真的很蠢。
標準化的解決方案
在上述各種問題重重的解決方案中，核心的問題其實只有一個：缺乏標準。其實針對這兩個主要的議題，異質網路整合以及圖形使用界面，早已有標準存在，只是比較鮮為人知。
ZigBee標準組織在 2005 年底，正式把整合異質網路來克服各種實際佈建問題的概念納入 ZigBee通訊協定的發展藍圖之中。Gateway Workgroup(GWG)是目前負責制定相關應用規格的組織，日前該組織公佈了一份新的標準：ZigBee Bridge。
ZigBee Bridge與傳統依靠應用程式層級來進行封包橋接的做法不同，ZigBee Bridge在第二層Data-link層進行封包交換。這樣的特向可以讓一個ZigBee Bridge完全不需要依靠使用者自動的應用程式，便可以交換所有類型的封包。因此ZigBee Bridge可以視作是一個單純的『路由器』。ZigBee Bridge的系統架構相當直觀；一個新的封包交換層介於網路層以及MAC層之間，原始資料在這一層進行交換，上層的通訊協定不需要任何修改便可正常工作。
ZigBee Bridge最早的構想，是使用IP網路來連接一個PAN裡面的兩個節點，藉此製造一個封包的『蟲洞』；可以用來縮短封包路由的路徑，或是用來連接兩個被空間隔離的網路。但是開發人員很快就發現了ZigBee Bridge另外一種用處：虛擬ZigBee裝置。ZigBee Bridge的橋接層，在設計上被視為一個擁有抽象界面的存取層。這樣的設計可以讓網路層以上的層級不需要關心資料到底是從無線界面還是從IP網路接收的。理論上，這樣的結構可以延伸發展並包含更多不同種類的界面，或是反過來將某些實體界面從架構中抽離。由於有這樣的特性，我們可以建構一個只包含IP界面的裝置，換句話說，我們可以建構一個『不包含無線界面的 ZigBee裝置』這樣的東西。
這種不包含無線界面的ZigBee裝置，可以完全由軟體構成，不再受到現有的2.4GHz無線傳輸平台限制。這個『裝置』可能是一個在UNIX伺服器上運作的daemon，或是在Windows 伺服器上運作的Service。我們甚至可能讓多個不同的虛擬裝置同時存在於一台主機之上。『虛擬ZigBee裝置』為現實應用情境的發展帶來很多的可能性。使用者程式現在可以使用正常的IPC(Inter-Process Communication)管道與ZigBee裝置進行資料交換。應用程式也可以在任何一個有IP網路連線的裝置上執行，不必侷限於佈建的現場。
利用這項技術，我們得以描繪出一個新的系統佈建方式。首先我們藉由 Ethernet、HomePNA、WiFi或是Power-Line等異質網路建構一個IP網路骨幹，接下來我們佈建的環境條件，將整個網路劃分成多個小區塊。每一個小區塊安裝一個ZigBee Bridge裝置，連接至IP骨幹網路。最後，我們架設一台伺服器，上面執行虛擬的ZigBee根節點，藉此形成整個ZigBee網路。在這樣的架構中，所有的ZigBee Bridge都被視為是虛擬根節點底下的第一層 Router，資料首先透過IP網路傳至 Bridge，在透過無線訊號傳至小區塊裡面的無線節點。
圖2：純無線網路 v.s. ZigBee Bridge 架構（資料來源：資策會）
上圖顯示一個典型的ZigBee Bridge使用情境。在原本的使用情境中，系統被佈建在一棟大樓中，由於樓板本身會阻隔無線訊號，因此必須沿著樓梯天井或是外牆佈建中繼節點，以確保資料路徑的暢通。如果大樓的層數很高，可以預期頂樓的通訊會有嚴重的延遲與封包遺失問題。若使用ZigBee Bridge，整個網路將會有完全不同的架構。每個樓層可被劃分成一個區塊，每個樓層安裝一個ZigBee Bridge裝置並透過骨幹網路直接與虛擬ZigBee根節點建立連線，每層樓的感測器直接與Bridge裝置進行連線(只要無線訊號能夠涵蓋)。亦即在這個網路中，整體的最大深度大幅度降低。與傳統的佈建方式相比，差異非常明顯。
整合多元化的應用程式環境
ZigBee Bridge成功的解決了與異質網路整合的問題，然而ZigBee Bridge使用的技術方法其實並非Gateway Workgroup最初成立的本意。Gateway Workgroup成立的用意，其實非常單純：『希望能有一個機制，讓使用者透過Internet控制ZigBee裝置』。在制定初期，GWG的主要目的，是建立一個跨網路存取的伺服器界面標準，此一界面將可提供ZigBee堆疊相關服務，以及網路遠端存取的能力。如同這個組織的全名，這種裝置就稱為一個『閘道器』(Gateway)。
如同Gateway這個英文單字的定義：一個預設的存取界面，ZigBee Gateway也是期望能作為網際網路與ZigBee網路的一個整合存取界面。與前述的ZigBee Bridge標準不同，ZigBee Bridge標準在信息傳遞上，還是使用ZigBee的封包，只是利用IP網路穿遂傳輸封包；ZigBee Gateway則是更進一步整合了ZigBee堆疊的服務。
目前ZigBee Gateway標準，是架構在原有的ZigBee之上，在不影響原有ZigBee堆疊的前提之下，能透過原本ZigBee堆疊定義的服務存取介面與ZigBee裝置作溝通，並增加了傳統通訊堆疊概念中的展示層(Presentation Layer)，作為與IP網路界接的界面。換句話說，ZigBee Gateway在IP端所提供的服務，即是以原本的ZigBee應用程式框架層的服務界面為藍本，提供遠端的應用程式以遠端程序呼叫(Remote Procedure Call)的方式，來存取ZigBee網路服務。
這種特性使得開發者可以用更具有彈性的方式來開發ZigBee應用程式，而不需要像以前一樣，將應用程式燒錄至通訊模組的嵌入式硬體晶片上。對於設備生產者來說，不會再受到通訊模組硬體資源的限制，而且也不再需要跟特定的晶片組綁在一起。對通訊模組製造者來說，應用程式移至外部系統，表示嵌入式系統晶片只需要滿足ZigBee通訊協定本身的需求即可，不再需要為了滿足所有可能的應用情境，而設計成一個包山包海的高成本晶片。
上圖顯示一個典型的ZigBee Gateway應用情境。使用者在個人終端界面(通常是一台PC)上安裝不同廠商提供的程式，程式各自透過IP網路與同一台Gateway裝置連線，然後存取各自的裝置。與上述『一台筆記電腦後面掛了一串硬體插件』的情境相比，兩者差距高下判若雲泥！
依照情境選擇適用的技術
本篇文章介紹了兩種不同的ZigBee整合IP網路的裝置。這兩種裝置各自擁有不同的架構，以及不同的適用情境。ZigBee Bridge裝置的角色是一個可用於擴充網路規模的中繼節點，適用於ZigBee無線感知網路的骨幹建構；ZigBee Gateway裝置則是一個具有高度擴充能力的應用程式存取框架。這兩種裝置的出現，賦予了ZigBee無線感測網路市場前所未有的可能性，以往ZigBee無線感測網路難以觸及的廣域網路，以及整合多元解決方案的應用情境，如今藉由這兩種技術，都可以輕易的達成需求。
這兩種新技術承諾了美好的未來遠景，不過有心嚐鮮的設備製造商與整合服務供應商還是得等一等。目前ZigBee聯盟公佈的Gateway標準只有草案，正式的標準文件截至截稿日期尚未完全定案。部份心急的上游供應商已經開始依照草案的架構來實作產品，但是依據ZigBee聯盟過去的行事風格，不太可能會上演類似『藍光DVD大戰』這樣的戲碼。
ZigBee Gateway的實際推出時間，在下半年應該會有比較明確的訊息。在目前的階段，各家廠商不妨開始評估ZigBee技術應用在自己產品服務的可行性，規劃自己該如何搭上這一列無線感測網路風潮的列車。
前言
在無線感測網路的技術領域中，與傳統無線通訊解決方案最大的區別，就在於無線網路的標準化。在傳統的無線通訊解決方案中，各家的產品缺乏共通標準，只能與自家的產品互動。不同產品之間產生的干擾問題也時有所聞。無線感測網路的標準化，以及認證制度的推行，使得廠商有一個可以依循的方向。只要依循此一標準設計製造的產品，便可以保證與不同廠商裝置之間的相容性。這種特性對於廠商而言，最直接的效益就是產品將不再受到無線訊號本身的侷限。
傳統的無線通訊解決方案，通訊端與接收端必須維持在無線電訊號範圍內。而在無線感測網路技術領域，利用無線感測網路通訊協定的多點傳輸特性，便可僅依靠低傳輸功率的通訊裝置，達到廣域服務涵蓋面積的目的。無線感測網路通訊協定的標準化，更進一步擴展了無線感知網路的功能性：符合通訊協定標準的裝置，即可無障礙地利用一個已經建構完成的無線感測網路系統進行通訊。
由於這樣的特性，在無線感測網路的市場中自然衍生出兩種不同特性的裝置：不具備特定應用程式功能、但可用來架設無線感測網路骨幹(Backbone)的裝置，以及專門為了某些特定目的而開發的無線感測網路應用裝置。
無線感測網路應用裝置本身僅需具備通訊協定的存取界面，需要的技術能力比較少。然而無線感測網路骨幹裝置則是需要考慮到現實世界實際佈建的各種問題，同時需要考慮到各種多元化應用裝置的擴充性，無輪在設計上、或是實際佈建上，都會面臨相當多的挑戰。
本文將以ZigBee無線感測網路骨幹裝置為核心，介紹兩種結合IP網路的ZigBee交換裝置。兩種裝置各自有不同的系統，以及不同的適用情境。然而兩種裝置對於架設多元化的無線感測網路環境此一目標，皆有著相當重要的地位。
佈建的常見問題
任何一種無線感知網路，都存在各式各樣的限制。在一個環境受到控制的實驗室中，我們可以很簡單的建構出一個理想的網路，讓網路完全按這我們想要的方式擴張，讓封包按照我們想要的方式傳送。然而，當我們進入現實世界，我們會受到各式各樣的環境因素限制。在大多數的佈建案中，想要完全依靠無線技術來建構一個能夠傳遞資料的感知網路，是一件極端困難的挑戰。
在現實世界中基本佈建的規則是：節點的無線訊號範圍必須能夠互相涵蓋。這項要求在開放空間或許很容易達成，但是在複雜空間中，往往會產生各種意料之外的問題。佈建在室內空間的ZigBee網路，除非是在建築物建造或裝潢的時候就嵌入成為建材的一部份，否則必然是等裝潢完成後才進駐佈建。
ZigBee的無線訊號可以穿越木板、玻璃、石膏板、磚牆、水泥裝飾牆等裝潢隔間材質，但是無法穿越內含鋼骨的結構牆、金屬門、金屬隔間櫃等厚重物體，因此網路連線必定會受到建築結構的限制。舉例來說，房間與房間之間可能受到結構牆阻隔無法直接通訊，必須在房門口附近裝設一個中繼節點；樓層與樓層之間可能會因為加重承載結構無法直接通訊，需要由外牆、陽台、天井、樓梯井等地方架設數個中繼節點。這些問題通常會導致兩種常見的問題：網路傳輸路徑過長導致延遲過高，或是造成一個特別繁忙的瓶頸節點。
對於這些現實佈建物理限制所造成的問題，最有效率的解決方案就是將網路拆分成數個較小的區塊。每一個區塊可以被視為是一個小型的獨立網路，因此在這些區塊中，比較容易形成『平衡的』網路拓璞。每一個獨立區塊可以被視作為一個叢集(Cluster)。每個叢集會設置一個主要的控制節點，用來作為叢集資料的統一出入口。利用這種方式，可以比較有效率的達成流量分散、降低干擾等功用。然而叢集控制點的設計，變成很重要的關鍵。在某些應用情境中，會將依靠異質網路來作為叢集控制點與叢集控制點之間資料傳輸的通道，亦即叢集控制點本身即是扮演一個橋接器(Bridge)裝置的功用。
有相當多的實際應用案例採用這種方式佈建。低成本佈建的解決方案通常會使用一些現成的轉換裝置，例如RS232-to-Ethernet的轉接器，後端則是連接普通IP網路。這樣的解決方案相當有效率，然而這種解決方案通常伴隨著潛在問題。這種類型的佈建方式，橋接裝置幾乎毫無例外的採用應用程式層級的方式來實作封包轉發功能。由於通訊協定天生的封裝與解封裝(Capsulation & De-capsulation)性質，應用程式層級只能取得封裝的內容(Payload)，無法取得封裝的標頭(Header)。因此應用程式層級的封包轉發橋接器，只能依靠封裝內容來作為轉發判斷的依據。要做到這一點，封裝內容必須有一定的格式要求；換句話說，就是缺乏共通性與相容性。
在實際的佈建案例中，採用RS232-to-Ethernet轉接器的低成本佈建解決方案，幾乎都是為了單一用途而建構。在這種網路中如果想要增加新的功能，是非常困難的事。在不變更原有節點的前提下，幾乎不可能容納另外一個不同廠商的系統。
相容性的極限
通訊協定確保的是資料傳輸與轉發的相容性，而不是資料本身的相容性。以應用程式的層級來說，除非應用程式本身也依循某些標準規範，例如X.10自動控制，否則不同廠商生產的裝置，幾乎不可能相容。
這一點對於生產終端設備的廠商來說，可能反而是一種求之不得的壟斷優勢：任何購買Ａ公司的控制器的使用者，只能回過頭來購買Ａ公司生產的設備；因為Ａ公司的控制器，無法控制Ｂ公司的設備。從設備業者或是工程師的角度思考，這是很合情合理的結果；但是對於一個只是想要整合不同解決方案的使用者來說，這種缺乏相容的特性就顯得荒謬而可笑。
試想一個情境：在一個會議室中，先要尋找控制器Ａ來啟動空調設備，然後尋找控制器Ｂ來放下窗簾與投影屏幕，然後尋找控制器Ｃ來啟動投影機，最後再拿一開始用過的控制Ａ來關閉燈光。這樣的情境不只讓人不耐，更會讓人產生一種『無線感測網路並沒有帶來多少便利性』的負面印象。
將控制界面用個人電腦應用程式的方式製作，看似一個可行的解決方案：至少你可以在一台電腦前控制所有東西，而不需要去找一大堆控制器。但是以目前現行的眾多實作，這種做法也只是換湯不換藥。
採用這種解決方案的廠商，會提供你一個安裝軟體，以及一個硬體插件(Dangle)，同時會指示你用RS232或是USB連線把這個硬體插件連接到電腦上，然後執行控制程式。問題是：控制程式只認得特定的硬體插件，於是Ａ公司控制程式無法控制Ｂ公司硬體插件的老戲碼再次上演。各位可以試著想像另外一個情境：一個工程師捧著一台Notebook電腦站在會議室一角，Notebook後面接了一個USB Hub，然後Hub上插滿了各種形狀、顏色、大小都不同的硬體插件。
相信不用我說各位也曉得：這樣看起來真的很蠢。
標準化的解決方案
在上述各種問題重重的解決方案中，核心的問題其實只有一個：缺乏標準。其實針對這兩個主要的議題，異質網路整合以及圖形使用界面，早已有標準存在，只是比較鮮為人知。
ZigBee標準組織在 2005 年底，正式把整合異質網路來克服各種實際佈建問題的概念納入 ZigBee通訊協定的發展藍圖之中。Gateway Workgroup(GWG)是目前負責制定相關應用規格的組織，日前該組織公佈了一份新的標準：ZigBee Bridge。
ZigBee Bridge與傳統依靠應用程式層級來進行封包橋接的做法不同，ZigBee Bridge在第二層Data-link層進行封包交換。這樣的特向可以讓一個ZigBee Bridge完全不需要依靠使用者自動的應用程式，便可以交換所有類型的封包。因此ZigBee Bridge可以視作是一個單純的『路由器』。ZigBee Bridge的系統架構相當直觀；一個新的封包交換層介於網路層以及MAC層之間，原始資料在這一層進行交換，上層的通訊協定不需要任何修改便可正常工作。
ZigBee Bridge最早的構想，是使用IP網路來連接一個PAN裡面的兩個節點，藉此製造一個封包的『蟲洞』；可以用來縮短封包路由的路徑，或是用來連接兩個被空間隔離的網路。但是開發人員很快就發現了ZigBee Bridge另外一種用處：虛擬ZigBee裝置。ZigBee Bridge的橋接層，在設計上被視為一個擁有抽象界面的存取層。這樣的設計可以讓網路層以上的層級不需要關心資料到底是從無線界面還是從IP網路接收的。理論上，這樣的結構可以延伸發展並包含更多不同種類的界面，或是反過來將某些實體界面從架構中抽離。由於有這樣的特性，我們可以建構一個只包含IP界面的裝置，換句話說，我們可以建構一個『不包含無線界面的 ZigBee裝置』這樣的東西。
這種不包含無線界面的ZigBee裝置，可以完全由軟體構成，不再受到現有的2.4GHz無線傳輸平台限制。這個『裝置』可能是一個在UNIX伺服器上運作的daemon，或是在Windows 伺服器上運作的Service。我們甚至可能讓多個不同的虛擬裝置同時存在於一台主機之上。『虛擬ZigBee裝置』為現實應用情境的發展帶來很多的可能性。使用者程式現在可以使用正常的IPC(Inter-Process Communication)管道與ZigBee裝置進行資料交換。應用程式也可以在任何一個有IP網路連線的裝置上執行，不必侷限於佈建的現場。
利用這項技術，我們得以描繪出一個新的系統佈建方式。首先我們藉由 Ethernet、HomePNA、WiFi或是Power-Line等異質網路建構一個IP網路骨幹，接下來我們佈建的環境條件，將整個網路劃分成多個小區塊。每一個小區塊安裝一個ZigBee Bridge裝置，連接至IP骨幹網路。最後，我們架設一台伺服器，上面執行虛擬的ZigBee根節點，藉此形成整個ZigBee網路。在這樣的架構中，所有的ZigBee Bridge都被視為是虛擬根節點底下的第一層 Router，資料首先透過IP網路傳至 Bridge，在透過無線訊號傳至小區塊裡面的無線節點。
圖2：純無線網路 v.s. ZigBee Bridge 架構（資料來源：資策會）
上圖顯示一個典型的ZigBee Bridge使用情境。在原本的使用情境中，系統被佈建在一棟大樓中，由於樓板本身會阻隔無線訊號，因此必須沿著樓梯天井或是外牆佈建中繼節點，以確保資料路徑的暢通。如果大樓的層數很高，可以預期頂樓的通訊會有嚴重的延遲與封包遺失問題。若使用ZigBee Bridge，整個網路將會有完全不同的架構。每個樓層可被劃分成一個區塊，每個樓層安裝一個ZigBee Bridge裝置並透過骨幹網路直接與虛擬ZigBee根節點建立連線，每層樓的感測器直接與Bridge裝置進行連線(只要無線訊號能夠涵蓋)。亦即在這個網路中，整體的最大深度大幅度降低。與傳統的佈建方式相比，差異非常明顯。
整合多元化的應用程式環境
ZigBee Bridge成功的解決了與異質網路整合的問題，然而ZigBee Bridge使用的技術方法其實並非Gateway Workgroup最初成立的本意。Gateway Workgroup成立的用意，其實非常單純：『希望能有一個機制，讓使用者透過Internet控制ZigBee裝置』。在制定初期，GWG的主要目的，是建立一個跨網路存取的伺服器界面標準，此一界面將可提供ZigBee堆疊相關服務，以及網路遠端存取的能力。如同這個組織的全名，這種裝置就稱為一個『閘道器』(Gateway)。
如同Gateway這個英文單字的定義：一個預設的存取界面，ZigBee Gateway也是期望能作為網際網路與ZigBee網路的一個整合存取界面。與前述的ZigBee Bridge標準不同，ZigBee Bridge標準在信息傳遞上，還是使用ZigBee的封包，只是利用IP網路穿遂傳輸封包；ZigBee Gateway則是更進一步整合了ZigBee堆疊的服務。
目前ZigBee Gateway標準，是架構在原有的ZigBee之上，在不影響原有ZigBee堆疊的前提之下，能透過原本ZigBee堆疊定義的服務存取介面與ZigBee裝置作溝通，並增加了傳統通訊堆疊概念中的展示層(Presentation Layer)，作為與IP網路界接的界面。換句話說，ZigBee Gateway在IP端所提供的服務，即是以原本的ZigBee應用程式框架層的服務界面為藍本，提供遠端的應用程式以遠端程序呼叫(Remote Procedure Call)的方式，來存取ZigBee網路服務。
這種特性使得開發者可以用更具有彈性的方式來開發ZigBee應用程式，而不需要像以前一樣，將應用程式燒錄至通訊模組的嵌入式硬體晶片上。對於設備生產者來說，不會再受到通訊模組硬體資源的限制，而且也不再需要跟特定的晶片組綁在一起。對通訊模組製造者來說，應用程式移至外部系統，表示嵌入式系統晶片只需要滿足ZigBee通訊協定本身的需求即可，不再需要為了滿足所有可能的應用情境，而設計成一個包山包海的高成本晶片。
上圖顯示一個典型的ZigBee Gateway應用情境。使用者在個人終端界面(通常是一台PC)上安裝不同廠商提供的程式，程式各自透過IP網路與同一台Gateway裝置連線，然後存取各自的裝置。與上述『一台筆記電腦後面掛了一串硬體插件』的情境相比，兩者差距高下判若雲泥！
依照情境選擇適用的技術
本篇文章介紹了兩種不同的ZigBee整合IP網路的裝置。這兩種裝置各自擁有不同的架構，以及不同的適用情境。ZigBee Bridge裝置的角色是一個可用於擴充網路規模的中繼節點，適用於ZigBee無線感知網路的骨幹建構；ZigBee Gateway裝置則是一個具有高度擴充能力的應用程式存取框架。這兩種裝置的出現，賦予了ZigBee無線感測網路市場前所未有的可能性，以往ZigBee無線感測網路難以觸及的廣域網路，以及整合多元解決方案的應用情境，如今藉由這兩種技術，都可以輕易的達成需求。
這兩種新技術承諾了美好的未來遠景，不過有心嚐鮮的設備製造商與整合服務供應商還是得等一等。目前ZigBee聯盟公佈的Gateway標準只有草案，正式的標準文件截至截稿日期尚未完全定案。部份心急的上游供應商已經開始依照草案的架構來實作產品，但是依據ZigBee聯盟過去的行事風格，不太可能會上演類似『藍光DVD大戰』這樣的戲碼。
ZigBee Gateway的實際推出時間，在下半年應該會有比較明確的訊息。在目前的階段，各家廠商不妨開始評估ZigBee技術應用在自己產品服務的可行性，規劃自己該如何搭上這一列無線感測網路風潮的列車。
