ZigBee聯盟為制定閘道器(Gateway)的協定，在2004年2月成立閘道器工作小組(Gateway Working Group)，專門負責Gateway堆疊協定的制定與標準化。在制定初期，Gateway的主要目的是作為一個跨網路存取的伺服器，並提供ZigBee堆疊相關的服務。因為牽扯的範圍非常廣大，所以逐步制定一些目標規畫作為未來發展的藍圖。
目前Gateway的首要目標，是建立IP網路的應用端與ZigBee網路之間的一個溝通管道，達到跨網路與服務的存取，下一步，才是ZigBee網路對ZigBee網路之間直接的互通與服務存取(圖1)。與已經公開的ZigBee橋接器(Bridge)標準不同的是，ZigBee Bridge標準在訊息傳遞上，還是使用ZigBee封包，只是透過IP網路傳輸，並沒有跨異質網路的概念。而ZigBee Gateway則是具有跨異質網路的功能，並整合ZigBee堆疊的服務。目前ZigBee Gateway的標準是先建立與IP網路之間的溝通，未來ZigBee Gateway將整合IP伺服器(Service)，如ICMP或是Web Service，並且加入與其他異質網路溝通的功能。
 |
| 資料來源：ZigBee聯盟 圖1 Gateway發展的目標 |
ZigBee Gateway首要目標為與網際網路結合
在技術發展上，一開始Gateway Working Group也無法知道要制定哪些功能，所以只能從市場的需求下手。廠商在發展ZigBee產品的過程中，漸漸有了整合應用伺服端的需求。也就是說，廠商希望能有一個伺服器，一方面能夠控制ZigBee網路，提供ZigBee服務；一方面又能夠與應用伺服端互通。且這些伺服器必須具備一些介面，提供多元的服務。在這些需求之下，ZigBee聯盟制定Gateway的雛型，如現今很熱門的家庭控制應用，一個典型的家庭網路都是透過IP骨幹(Backbone)，與家庭裡各種裝置達到互通(圖2)。在這個例子裡，使用者可以從外部的網路，如公司的網路透過網際網路連回家裡的網路，由於網際網路是普及的網路，促使ZigBee Gateway首要目標為建立與IP網路通道的原因。
 |
| 資料來源：ZigBee聯盟 圖2 典型的家庭網路拓撲 |
若廠商發展一套應用ZigBee的產品，如何連接IP網路與ZigBee網路？此即Gateway最主要的功能–即跨異質網路的整合服務。如圖3所示為典型整合ZigBee的家庭網路，使用者一樣可以透過網際網路先連回家裡的網路，再透過ZigBee Gateway將控制或存取訊息轉送給ZigBee網路內任何一個節點。ZigBee網路內的任一節點如果對指令有回應或是一些觸發性的警告，也可以透過ZigBee Gateway將訊息經由網際網路傳回給外部網路的使用者。這就是ZigBee Gateway的原型–一個伺服器，可讓不同於ZigBee網路的外部網路使用者，能透過此伺服器連結ZigBee網路與ZigBee網路內的節點通訊。
 |
| 資料來源：ZigBee聯盟 圖3 家庭網路整合ZigBee網 |
根據ZigBee聯盟公布的標準規格文件，作為一個能夠溝通IP網路與ZigBee網路之間的橋樑，ZigBee Gateway必須要滿足以下最低限度的要求：
ZCL是ZigBee聯盟根據各種應用制定的功能標準化之集大成，可視ZCL為根據不同的應用功能而制定的傳輸溝通標準，如燈光亮度的控制、空調溫度調整或是電視機的開啟與關閉，都是屬於ZigBee堆疊應用層之上的協定。所以ZCL相關的操作，簡單來說，就是支援應用層級制定的溝通命令的操作，若廠商須自訂一個應用層級的溝通介面，就會使用到ZCL相關的操作。
ZDO(ZigBee Device Objects)則是屬於ZigBee堆疊(ZigBee Stack)的一部分，提供ZigBee相關的服務，如裝置與服務搜尋(Device and Service Discovery)、安全管理(Security Manager)、網路管理(Network Manager)、繫結管理(Binding Manager)與節點管理(Node Manager)。Gateway透過ZigBee本身提供的ZDO命令，可組合出不同應用的巨集，如ZDO指令集(Command Sets)裡的IEEE_addr_req可查詢某一個節點的IEEE位址與其附屬之子節點(Child Node)，所以在這個指令的特性之下，Gateway便可以實作Start Node Discovery一組巨集。此巨集的運作方式是使用IEEE_addr_req指令，透過查詢網路位址為0x0000的協調員(Coordinator)IEEE位址，可得知協調員擁有哪些子節點，再重複利用這個指令查詢這些子節點的IEEE位址，又可取得子節點的子節點。依此類推，可建立目前網路的拓撲(圖4)。
 |
| 資料來源：ZigBee聯盟 圖4 ZDO命令組合而成的巨集服務範例 |
Gateway制定上述巨集服務後，將可更有效發揮ZDO命令本身提供的效用，以達到更多元的應用。服務端點(Endpoint)則類似TCP/IP網路堆疊裡通訊埠的概念，Gateway會管理IP網路與ZigBee網路之間通訊管道的轉換，而服務端點的使用也與應用導向的規格(Profile)有關。
IPHA(IP Host Application)是Gateway標準裡制定的一個角色，用來定義要與Gateway通訊的伺服器所須具備的功能與特性，可想像為可直接對Gateway通訊、控制的裝置與須具備的堆疊。
圖5為目前ZigBee Gateway標準制定的堆疊，由此圖可以看出其架構在原有的ZigBee堆疊之上。在不影響原有ZigBee堆疊的前提之下，ZigBee Gateway的堆疊主要是透過原本ZigBee堆疊定義的服務存取介面，如圖5中的APSME-SAP或NLME-SAP與ZigBee裝置溝通。在轉換ZigBee封包與IP封包的過程中，是透過所謂的表現層(Presentation Layer)的介面，如圖5中的Web Services Presentation Layer SAP與Binary Presentation Layer SAP。在標準裡，Gateway定義三種陳述約束力(Presentation Binding)的方式，前兩種是透過Web Service，底層採用XML文件格式，稱為Web Service Binding，包含SOAP與REST；第三種則是透過ZigBee Gateway標準所定義的資料流交換方式，稱之為Binary Presentaion Binding。這三種資料交換方式，再搭配RPC(Remote Process Call)機制，就是Gateway端與IPHA端的通訊協定。
 |
| 資料來源：ZigBee聯盟 圖5 ZigBee Gateway裝置堆疊 |
ZGD(ZigBee Gateway Device)意同ZigBee Gateway，其與IPHA之間的互動採用主/從(Client/Server)的架構，再搭配一組制定的RPC通訊協定。ZigBee聯盟在ZGD端定義一些功能，為避免混淆，稱之為Procedure；而IPHA端定義的功能，則稱之為Event Handler。程序是IPHA透過前述三種Presentation Binding通訊方式的其中一種，以遠端呼叫(Remote Call)的方式執行在ZGD之上的功能，如圖6(a)所示。而Event Handler則相反，由ZGD透過遠端呼叫的方式執行在IPHA之上的功能，如圖6(b)所示。透過ZGD與IPHA兩者互為Client/Server的角色，搭配遠端呼叫的方式，來達到控制與資料交換的目的。
 |
| 資料來源：ZigBee聯盟 圖6 Procedures與Event Handler的呼叫 |
整個ZGD目前制定的功能設置共包含七大類，剛好對應前述的Gateway最低限度需求，分別是閘道的管理(Gateway Management)、安全層級(Security Layer)、裝置方案(Device Profile)、應用函式庫(Cluster Library)、應用層(Application Layer)、網路層(Network Layer)、媒體存取控制層(MAC Layer)，整個Function Set定義的功能超過上百種。
| 主要包括Gateway本身的設定存取、網路節點與服務的搜尋巨集(Device and Service Searching Macro)、與IPHA之間的RPC通訊設定。透過這個類別的功能，IPHA可取得網路上所有節點的資訊與提供的服務，也可註冊訊息回呼(Callback)，ZGD具備回呼管理機制，將ZigBee網路傳回的訊息依先前設定，轉送給IPHA。 |
| ZigBee提供的安全設定與控制，將整合進Gateway提供的服務裡。這個類別包含了原本定義於ZigBee堆疊裡，對於安全的功能設定，實作這些功能，代表著Gateway支援可充當安全管理中心(ZigBee Trust Center)的角色。 |
| 這個類別定義全部類別裡最多的功能，幾乎涵蓋原本ZigBee堆疊裡ZDO所提供的所有介面。透過這些功能，IPHA可以直接從IP網路下達所有ZigBee的ZDO指揮與ZDP格式的訊息封包到ZigBee網路裡的某一個ZigBee裝置，達到跨網路通訊的目的。 |
| ZigBee ZCL定義針對叢集(Cluster)屬性(Attribute)的操作，並支援ZCL屬性讀寫與搜尋的操作。 |
| 這個類別定義的功能允許IPHA可直接設定Gateway本身所有關於應用層相關(如ZDO)的設定，或者直接透過Gateway發送應用層的封包，或是資料庫存取。 |
| 這個類別定義的功能，對應ZigBee堆疊網路層提供的管理介面(Management)，包含網路組成(Formation)、加入網路(Join)、離開網路(Leave)、搜尋(Discovery)、訊號掃瞄(Energy Scan)等。同時，也支援可以直接對網路資料庫存取。 |
| 這個類別目前定義的功能只有對管理資料庫的存取。 |
透過開啟的伺服器窗口 Gateway底層與IP網路資料交換
圖7所示為ZGD與IPHA之間的通訊堆疊。最底層是由TCP/IP網路堆疊所組成的插座(Socket)管理模組，負責Socket的實際開啟、傳送與接收。如前所述，ZGD與IPHA是一個互為Client/Server的架構。若IPHA要透過這些通訊堆疊，對ZGD的程序遠程呼叫，則IPHA屬於Client端，而ZGD就是Server端。相對地，如果ZGD同樣要透過這些通訊堆疊，對IPHA的Event Handler作遠程呼叫，則ZGD屬於Client端，而IPHA屬於Server端。這意謂ZGD與IPHA在運行時，必須持續開啟著一個Server埠(Port)，提供對方連入。而須與對方通訊的同時，須要開啟一個Client埠連入對方，才有之後的通訊。在Socket管理堆疊之上是Gateway標準制定的所謂ZIPT(ZigBee IP Transport Protocol)的堆疊，主要分為三部分。
| 這個介面提供資料傳輸(Data Transmission)的服務，所有來自上層要送給對方的訊息與來自下層接收自對方的訊息，稱之為資料。 |
| 這個介面提供連線管理的服務，透過這個介面，可跟對方開啟通道、關閉通道與接受連結。這個介面對於實體網路連線的建立，就是透過前述的Socket管理模組。 |
| 這個服務提供資料傳輸時的安全機制，支援資料的加密、資料的驗證與確保資料的完整。除了連線建立與資料傳遞，ZIPT也支援網路位址轉換(NAT)，而在未來的版本，也會加入可透通防火牆的機制。 |
 |
| 資料來源：ZigBee聯盟 圖7 ZGD與IPHA的通訊堆疊 |
在ZIPT協定之上，是名為GRIP(Gateway Remote Interface Protocol)的協定，此協定是一個輕量級(Lightweight)的RPC協定，主要的目的就是讓ZGD與IPHA可透過此協定交互呼叫一個遠端的函式。GRIP即是屬於其中的二元陳述(Binary Presentation)，也就是GRIP的傳輸主要是傳遞位元組資料流。GRIP提供的介面很簡單，只有一個，就是GRIDE，純粹是用來包裝要往對方發送的訊息。
當有一筆新的資料(呼叫)要往對方送，GRIDE先去檢查是否已經跟對方建立連線，若尚未建立任何連線，則GRIDE先透過底層ZIPT開啟一個與對方的連線。若建立連線了，再來就是決定呼叫對方的哪一個功能，呼叫哪一個功能，由這個封包的頭端(Function Header)決定，透過頭端包含參數，即可決定要呼叫的函式。頭端是由三個部分組成，包括FunctionCategory、ManufacturerCode及FunctionIdentifier。FunctionCategory可視為要遠端呼叫的目標功能的類別；ManufacturerCode則代表這個功能屬於廠商自訂，而FunctionIdentifier指出實際要呼叫的功能。透過這些參數，就能呼叫的對應的實體功能。在作遠程呼叫的同時，也可以設定逾時(Timeout)參數，代表執行這個功能時，應該要在某一個設定的時間內完成要求，否則就應該要回應逾時。每一次發送要求與收到對應回覆的過程，可以視為完成一次指令的處理(Transaction)。以IPHA的來看，操作Transcation分成六種型態，再依照操作型態來區分如下：
即觸發型的指令(Trigger Transaction)，由IPHA發出一個請求，設定回覆結果的觸發條件(圖8)。當ZGD處理完要求的指令後，根據設定的條件，將結果透過非同步型的指令回覆給IPHA。
|
即同步型的指令(Synchronous Transaction)，由IPHA發出一個請求，夾帶此次遠程呼叫的逾時設定。ZGD處理完呼叫的函式後，須立即回覆IPHA，若超過設定的逾時值，也須即刻回覆IPHA。這類型的指令屬於一對一的指令，IPHA得到回覆的同時，也得到了結果(圖9)。
|
包含起始型的指令(Start Transaction)、結果型的指令(Result Transaction)與終止型的指令(Stop Transaction)，開始-結束型的操作這類型的命令，通常包括三種型態的指令。起始型的指令是由IPHA發起一個請求，ZGD收到請求之後，會開始並持續地執行這個指令(圖10)。而結果型的指令，伴隨起始型指令，但是方向卻是由ZGD送往IPHA。起始型指令，會要求ZGD執行一個程序，不斷地執行某一個命令，之後，ZGD將每一次執行的結果，再透過結果型的指令，回覆給IPHA。終止型的指令也是由IPHA發起，用來停止之前透過起始型的指令調用ZGD的某一個程序，當ZGD收到這個指令後，會終止之前被起始型的指令調用的程序，並清除相關的資源。
|
即非同步型的指令(Asynchronous Transaction)，由ZGD發起，通常來自ZigBee網路的事件或是回應之前IPHA要求的處理結果。之所以稱之為非同步，是因為IPHA並不一定在這個時間點發出請求，在不特定的時間點，就可能得到這些訊息(圖11)。
以上操作包含RPC機制在實作上各種指令操作可能出現的情形。而Gateway制定的功能除前述區分的類別，也可透過這些操作型態區分。 Gateway的定位依Gateway標準提供的功能，可區分為基礎型應用與衍生型應用。基礎型應用包含網路管理、安全中心。 |
| Gateway的堆疊包含ZigBee ZDO的服務，所以Gateway本身制定的一些巨集命令，就使用到這些ZDO Command。透過Gateway這個平台，等於是將ZigBee堆疊本身所有提供的服務，開放出一個介面給使用者可直接存取，加上Gateway可經由外部程式彈性的設定，選擇成為協調員或是路由器(Router)，在網路的管理上保留很大的彈性。這個型態的應用，在IPHA端的設計上，須要有對等的介面可產生遠程呼叫的命令，使用者可以透過Gateway查詢整個ZigBee網路總共有哪些節點，或查詢每個節點搭載的服務，或針對某一個節點傳送自訂格式的訊息。 |
| ZigBee堆疊本身即包括安全機制(Security Mechanism)，但由於硬體(運算與儲存)的限制，所以常常因為資源的考量，會有必須捨棄網路安全的情形發生，由於Gateway可整合所有原本ZigBee堆疊所包含的服務，自然也包括ZigBee的安全功能，因此有了Gateway後，這些問題可迎刃而解。可能的做法是將ZigBee堆疊定義的安全中心，在Gateway本身實作，或可透過Gateway的介面，將安全中心獨立實作於ZigBee網路後，並可透過遠端資源管理的整合，達到以UI管理ZigBee網路安全的目的。安全中心的標準裡，也有管控節點進出網路的功能，不但能讓使用者監督網路情形，也可隨時隨地將某一個節點踢出ZigBee網路。 |
| ZigBee聯盟根據廠商的需求，制定許多標準化的傳輸定義，這些定義根據應用不同，以應用的標的區分，稱之為方案。而最新推出的方案，即是為了滿足目前家庭自動化需求，ZigBee聯盟稱之為家庭自動化方案(Home Automation Profile)。較可惜的是，雖然有這樣的標準誕生，但是一直缺乏一個強大的整合平台，能讓聯盟制定的方案很容易套用進來。這方面的問題，有一部分在於硬體的考量，亦即目前各家廠商推出的ZigBee晶片組很少能將所有標準制定的功能容納進來，現在有Gateway的標準，就可以把應用導向的方案，釋放給使用者端設計。也就是說，之後所推出的任何方案定義，不論是ZigBee聯盟制定的標準，或是廠商自行開發出來的客製化定義，都不須再跟晶片組綁在一起，而是同樣透過Gateway的介面，將實作的權責交由SI設計，使很多原本因硬體限制的應用，都能因為Gateway的誕生得以解決。 |
本文點出的應用範圍，在基礎型的部分是偏向使用ZigBee本身就有的服務，而衍生型則是使用方案的方式，將應用再套用上去，但在此之前，須了解某些限制。在目前的應用實例裡，一般的節點裝置因為功能確定所以不須搭載全部的功能，但是一些特殊目的的裝置，往往都礙於ZigBee晶片組硬體限制而無法支援全部的功能，如安全機制因為記憶體的受限，或是ZDO服務因為儲存空間不夠，都被迫要從ZigBee堆疊裡刪減。這樣的限制在較簡單的小型應用還可接受，但若要作更大型、更多元的應用，設計上就會變得複雜或綁手綁腳。例如，現在要實作Gateway的案例，Gateway因為規格定義上，須要與所有ZigBee提供的服務銜接，等同於須要把所有ZigBee堆疊有支援的服務打開，也就是說，原本標準有制定的所有功能都須要含括進來，這時候ZigBee晶片組再也無法迴避硬體限制的問題。
若實作所有ZigBee堆疊支援的功能無法避免，在不考慮修改ZigBee晶片組的硬體條件下，一個比較簡單的做法就是將ZigBee晶片組的定位定義在網路傳輸，而其他服務的部分全部抽離出晶片組所包含的堆疊。原本的ZigBee堆疊會被切開，網路工作層以下的堆疊繼續留在晶片組的程式碼裡，而原本也在ZigBee晶片組的應用層之上的程式碼，包含ZDO服務，全部拉到Gateway端以軟體形式運行(圖12)。
 |
| 資料來源：ZigBee聯盟 圖12 ZigBee堆疊的切割 |
ZigBee Gateway的誕生，不但能提供廠商作後端整合，也讓整個ZigBee產品方案更加完整，能跨越異質網路的界線，勢必能夠產生更多元的應用，強大的網路控制平台，更可以發揮原本就已經存在於ZigBee堆疊裡服務的效用。目前ZigBee聯盟公佈的Gateway標準，已更新到第19版(075329r19ZB_GWG-ZigBee_IP_Gateway_Specification.doc)，仍然不是一個完整的版本，雖然架構底定，但是一些實作細節尚陸續發展中。
(本文作者任職於資策會網路多媒體研究所先進環境感測技術中心)
