ZigBee Pro Feature Set塵埃定　ZigBee商機現蹤

新聞稿內容除描述規格中新增的功能與特點，以及未來聯盟的發展方向外，也提及在2006年底所公布的規格Revision 13(一般稱為ZigBee-2006)中，大部分的功能都可支援ZigBee Feature Set，其中有些功能在Revision 16中有更新的實作方法；另外2006年底後，在Revision 16版本中所新增的功能，則屬於ZigBee Pro Feature Set。  

何謂ZigBee Feature Set？何謂ZigBee Pro Feature Set？什麼又是ZigBee-2006與ZigBee-2007，與先前常聽到的ZigBee Pro又有何關聯？本文一開始即由ZigBee聯盟的正名運動，來解釋這些疑慮。  

ZigBee規格與版本演進  

圖1是目前ZigBee聯盟所公布的最新系統架構。由聯盟所主導的標準，定義了網路層(Network Layer)、安全層(Security Layer)、應用層(Application Layer)以及各種應用產品方案(Application Profile)。

資料來源：www.zigbee.org 圖1　ZigBee規格架構圖

網路層負責網路機制的建立與管理，包含網路位置(Network Address)的分配與封包的轉發與路由(Route)，並具有自我組態(Self Configure)裝置節點間網路拓撲(Topology)與連結，以及自我修復(Self Healing)封包路由路徑(Routing Path)的能力；應用層則是將抽象的封包資料分門別類，定義出一系列有意義的格式或程序，如網路裝置的管理、裝置的應用描述、裝置間功能的配對、或是對網路上其他裝置的資料存取；安全層則是負責上述網路層與應用層加解密的方法，以及在網路系統內，金鑰配送與更換的程序；而最上層的應用產品方案，則是定義各種類型的應用產品方案中，應該存在哪些裝置、這些裝置應該存在哪些功能、這些功能應該使用到底層ZigBee哪些功能與哪些設定。  

ZigBee規格制定就是在調整上述功能的演算法與實現方式，而這些網路層、安全層與應用層中，提供了許多功能與參數的設定，讓使用者可以根據產品的特性來設計使用。不過不同廠商在開發產品時，所使用到的功能或是參數設定會有所不同，這些差異性會使得ZigBee產品彼此間可能無法互通。因此為求統一管理與互通性著想，ZigBee聯盟官方則定義了一系列的規格使用規範，稱之為堆疊方案(Stack Profile)。  

過去，ZigBee聯盟根據應用產品方案制定相對應所需的使用規範，包含家庭控制堆疊方案(Home Control Stack Profile)、大樓自動化堆疊方案(Building Automation Stack Profile)與工廠控制堆疊方案(Plant Control Stack Profile)等，這些堆疊方案中，規定了網路層、安全層與應用層等各層中所須使用的功能與設定參數，例如網路層中的路由(Routing Table)、鄰近節點(Neighbor Table)等表格的大小、網路拓撲的深度(NwkMaxDepth)與寬度(NwkMaxChildren & NwkMaxRouter)等，或是安全層中加解密的等級，使用多少支金鑰等。這些都是在實際開發相關應用時須共同遵守的規範，這些規範也會在認證時一併測試，而透過這些規範也將使得使用相同堆疊方案的ZigBee產品彼此間可以互通。圖2是家庭控制堆疊方案的網路層規範的參數。

資料來源：www.zigbee.org 圖2　家庭控制堆疊方案中網路層相關參數的規範範例

在2004年所推出的第一個規格版本Revision 7之後，ZigBee聯盟也不斷針對潛在的市場需求與產品方向，調整規格改善的計畫與步驟。在這些過程中，ZigBee聯盟制定的規格版本之間的命名方式也隨之調整，因而造成許多人的混淆。例如規格的版本應該是使用版號如ZigBee1.0、ZigBee1.1，或是規格公布的年分如ZigBee 2004、ZigBee 2006、ZigBee 2007，還是規格的特點如ZigBee Pro。這些名詞混用，也逐漸造成大家在討論或運用時的困擾，因此聯盟也開始正名的運動。  

目前ZigBee聯盟的處理方式，是一致使用ZigBee-2006與ZigBee-2007等以年分標示的方式，來表示規格的版本。而根據新聞稿的內容，過去常聽到的ZigBee Pro已從過去代表規格版本的定義，調整成為表示堆疊方案的名詞。目前聯盟把堆疊方案調整成兩種，一是ZigBee Stack Profile，又稱為ZigBee Feature Set，主要是針對網路規模較小的應用場合如幾十到幾百個網路節點裝置以內的系統所定義的功能集與參數集的規範，另一個就是ZigBee Pro Stack Profile，又稱為ZigBee Pro Feature Set，主要針對網路規模較大的應用情境如網路節點裝置超過一千個以上的系統所定義。  

以目前的情況來說，ZigBee Feature Set所使用的功能大部分在ZigBee-2006中已經支援，但是ZigBee-2006並不支援ZigBee Pro Feature Set，而規格演進到ZigBee-2007時，同時滿足了ZigBee Feature Set以及ZigBee Pro Feature Set中所需要的功能。舉例而言，在ZigBee-2007中同時制定樹狀路由(Tree Route)與隨意路由(Mesh Route)的功能，但其中樹狀路由是提供給ZigBee Feature Set使用，而隨意路由則提供給ZigBee Pro Feature Set。  

因此總結來說，目前對ZigBee聯盟官方而言，ZigBee-2004、ZigBee-2006、ZigBee-2007是ZigBee的規格版本，而Stack Profile、ZigBee Feature Set以及ZigBee Pro Feature Set則是使用ZigBee規格時相關的規範(圖3)，基於這些規範，再配合公開的產品應用方案(Public Application Profile)或是私人產品方案(Private Application Profile)，開發成最終的產品。

資料來源：www.zigbee.org 圖3　ZigBee-2006、ZigBee-2007與Stack Profile的關聯性

ZigBee Pro Feature Set技術特點  

而ZigBee Pro Feature Set新增的功能，可說是ZigBee規格調整的重要目標與里程碑，雖然在這次新聞稿與相關文件中，ZigBee聯盟把ZigBee Pro改為ZigBee Pro Feature Set，並將其定義調整為規格使用規範，但大多數人還是會直接把ZigBee Pro視為是ZigBee規格的改良版本，包括在ZigBee聯盟裡許多會員在討論規格時也會這麼稱呼ZigBee Pro。而原本ZigBee聯盟預計在2007年第三季時可以正式公布這個版本(大家都認為ZigBee-2007=ZigBee Pro)，不過目前看起來Revision 16版本仍有部分的規格無法支援ZigBee Pro Feature Set的要求，可能須要等到Revision 17後，所有的功能才能完全底定。而根據ZigBee聯盟預計時程是希望在2007年年底前將Revision 17完成，而未來兩年，ZigBee的規格將不會有太大的變動。  

為了讓ZigBee應用在建構大型網路系統，ZigBee Pro Feature Set主要改善在網路位置管理、裝置群組管理、安全機制管理、傳輸頻道轉換，以及須要傳送較大筆資料時的資料分割機制。  

網路位置管理  

在網路形成的過程中，首先遇到的是網路位置配置(Address Assignment)的問題。原本的位置配置方式是透過Cskip的公式計算出來，Cskip會根據系統原先設定的網路參數，包含每個節點最多可接受的子節點(NwkMaxChildren)，這些子節點中，最多可擔任路由器節點(NwkMaxRouter)的數量，以及整個網路系統中最長的深度(NwkMaxDepth)，利用這些參數所計算出來的Cskip數值，可以讓每個加入到網路的節點，配置到一個唯一的網路位置，而且不會與其他節點有重複的狀況。  

如圖4與圖5所示，此種位置配置的方式，會使得所配置到的網路位置與節點在整個系統網路拓撲中實際的相對位置有絕對關係，所以這種配置方式最大的好處是簡易，而且可用來做樹狀路由的依據。

資料來源：www.zigbee.org 圖4　Cskip的網路位置管理範例

資料來源：www.zigbee.org 圖5　樹狀路由範例

上述的NwkMaxChildren、NwkMaxRouter、NwkMaxDepth等參數，與整個系統網路拓撲有密切關係，但問題是，建置一個大型網路系統時，不容易事先知道網路會形成的拓撲狀態，因此也就不知道參數要如何設定。既然如此，要事先在系統建置前設定這些參數是有困難的，特別是在大型的網路系統。因此，在ZigBee Pro Feature Set中使用的網路位置配置的方法則是改為隨機選取的方式(Stochastic Address Assignment)，既然網路位置是隨機選取配置，這麼一來，所有子節點的網路位置就與在整個系統網路拓撲中實際的相對位置是完全沒有關係，也因此，ZigBee Pro Feature Set無法支援樹狀路由，完全使用隨意路由，如圖6所示。而隨機選取的方式也可能會造成在同一個網路系統中，產生出重複的網路位置，因此在規格中也定義當發生重複的網路位置時應該有的調整流程。

資料來源：www.zigbee.org 圖6　隨意網路路由範例

裝置群組管理  

新增加一對多路由(Multicast Route)。一對多路由則利用近端設定群組身分表(Group ID Table, GIDT)來表示哪些裝置節點是屬於同一個群組，這個功能可以用來同時控制多項裝置，例如同時控制某一個樓層的燈光。假設裝置發送一對多(Multicast)的封包，首先會先檢查GIDT，如果不是屬於同一個群組，就會檢查路由表(Routing Table, RT)，把封包往下一個節點(Next Hop)傳送，如果檢查到是屬於自己群組封包時，會將自己的狀態改成會員模式(Member Mode)，然後再將封包以廣播(Broadcast)的方式向其他的裝置傳送，確保同一個群組的節點都能夠接收到這筆資料。當然，為了避免這個廣播封包在網路上一直重複傳送，當節點的狀態為Member Mode時，會再檢查另外一個廣播傳送表(Broadcast Transmission Table)，以確保自己不再重複傳送同樣的封包。  

就應用而言，很多的情境會把資料集中收集，多數的節點都會把資料往同一個節點送，因此整個網路拓撲就像樹狀一樣。由於ZigBee Pro Feature Set並不使用樹狀路由的功能，此時為了建立樹狀的路由路徑，如果每個節點都做一對一路由要求(Unicast Route Request)，才能建立往源節點(Originator/Source)的路徑，就會花很多時間，相較起來沒有效率，尤其是在規模較大的系統。  

為因應上述情形，ZigBee Pro Feature Set提出一個新的路由方式，稱為多對一路由(Many to One Route)。當發送多對一路由要求時，接收到這個封包的節點，就會直接建立一條往源節點路由的路徑，不須再透過路由回應(Route Reply)的機制建立資料傳送的路徑，所以很快的所有節點就會建好傳送路徑。反之若源節點要傳送資料給其他裝置，基本上還是得透過一對一路由要求的方式，建立起源節點對於其他節點的路由路徑。不過在ZigBee Pro Feature Set增加了一個源節點路由(Source Route)的功能，就是當路由路徑有變化時，節點會先發出一個路由紀錄命令(Route Record Command)給源節點，這個命令中會記錄這條路徑上經過的所有節點，當源節點接收到這個命令後，會把這條路徑記錄在一個叫做源路由表(Source Route Table)的表格中，只要源節點須要把資料傳送到其他節點時，就會先到Source Route Table找尋傳送的路徑，以加快時間，並且減少建立路由路徑或是做路徑修復的次數。而這些功能的目的都是為了增加網路上路由的效率。  

安全機制管理  

要在低頻寬與低運算能力的平台上做很複雜的安全機制並不是一件容易的事。近來，雖然ZigBee的安全機制沒有太大變化，但在ZigBee-2004所定的規格對大多數應用來說已算完整。在此描述的安全機制大致可分為資料加解密與金鑰的交換方式。在加解密方面，規格要求在網路層與應用層都使用所謂的CCM安全機制。CCMCTR(Counter Mode)與CBC-MAC(Cipher Block Chaining Mode)的縮寫，CTR是加解密的演算法，CBC-MAC是檢查資料有無被竄改的演算法，透過CTR與CBC-MAC的組合，ZigBee總共可以提供八種資料加密的等級。  

而在金鑰交換的部分，在ZigBee-2004中定義了所謂的住宅模式(Residential Mode)又稱標準模式(Standard Mode)，以及與商業模式(Commercial Mode)又稱高安全模式(High Security Mode)。在過去版本的認證中，並未有商業模式相關的測試案例，因此大部分堆疊並未支援商業模式，但在ZigBee Pro Feature Set則要求同時要支援住宅模式與商業模式。  

所謂的住宅模式，就是當節點加入網路時，信託中心(Trust Center, TC)會配置一把NWK Key放在AP Payload中傳送給對方，傳送過程不做任何的加密保護的動作，所有加入網路中的節點，就透過NWK Key來加密資料。如圖7所示，在商業模式中，TC會先配一把Master Key給新加入的節點，然後，新加入的節點再用這把Master Key，透過SKKE的流程，與網路中的任何節點建立Link Key，最後再利用Link Key加密後產生一把網路共用的NWK Key，所以相較起來商業模式有較強的安全性。

資料來源：www.zigbee.org 圖7　金鑰示意圖

傳輸頻道轉換  

為了讓系統在偵測到頻道遭受干擾時，能夠盡快找尋出一個相對穩定的頻道，並且通知所有的相關節點轉換到另外一個頻道上。雖然形容起來看似簡單，不過目前實際上卻會面臨很多問題，特別是在大範圍的系統，例如如何定義與偵測頻道遭受到干擾？如果有節點暫時失去聯繫是不是就代表受到干擾？如何找尋一個相對穩定的頻道？也許在近端第十一個頻道是相對穩定的，可是在大範圍系統的另外一端第十一個頻道可能也受到干擾(圖8)？如何通知系統上所有節點同步的轉換頻道？也因為有諸多的問題與解決方式尚未獲得共識，因此在目前最新的Revision 16版本中，只有提出概念性的內容，但未提及實作的方式。

圖8　干擾示意圖

資料分割機制  

最後一部分是資料分割機制。在過去的規格中，應用程式要傳送資料時，會受到應用層資料單元(Application Sublayer Data Unit, ASDU)的長度限制，超過84位元組的長度無法傳送，而在ZigBee Pro Feature Set則改善此限制，在應用時須要傳送的資料超過Payload長度的限制時，可以使用分割(Fragmentation)與重組的功能來傳送長度較長的資料。  

這裡分割的方式先設定Window的大小及每個Window中區塊(Block)數，接著系統便會按照區塊數分段傳送封包，直到完整的封包送完為止。如圖9，當長度大於ASDU的長度限制時，會自動進行切割，切割的單位為Block，一個Block即為一個ASDU，數個Block成為一個Window，最多可以設定八個Block為一個Window。

圖9　Windows size=3，Number of blocks=5，No frame is lost資料傳送流程示意

每次傳送均以Window的總長度為一個段落，送出多個Block封包，之後必須等待接收端送出APS ACK，才會再進行下一個Window的傳送。接收端送出的APS ACK中，會記載著接收的狀況，哪些Block封包已經成功接收，哪些Block封包沒有接收到，因此傳送端收到接收端的APS ACK後，依其內容，重送遺失Block的資料。  

當傳送端確認接收端接收所有在此次Window中的Block後，傳送端繼續下一個Window的傳送。當傳送端或接收端，經過一特定時間後，沒有往下一個Window移動時，此次Fragmentation傳送視為失敗。當接收端成功接收所有Fragmentation傳送的Block後，則此次Fragmentation傳送視為成功。  

產品相容性仍待觀察  

不論是工程師在開發或是廠商推出產品，最害怕的事情之一，就是相關的技術規格一直無法穩定，或者是前後版本無法相容得問題，這些情況都會讓廠商裹足不前，不敢貿然使用相關技術開發產品，這些狀況正好都在ZigBee身上發生。儘管這段時間ZigBee在市場上一直處於比較低迷的狀態，但也造就許多非ZigBee標準的應用產品出現在一些利基市場裡，也由於這些廠商的堅持，非ZigBee標準的應用產品相對的也協助ZigBee不致於被市場所淘汰，再加上這個階段規格的改善也告一個段落，相信多數廠商也會逐漸將注意力再次移回到ZigBee標準。  

從技術的角度而言，將來廠商在開發產品時，會使用不同的堆疊方案以及不同產品應用方案，因此將來的ZigBee產品在相容性則會存在一些問題。對於使用相同的堆疊方案或是應用方案的產品而言，應該是使用在相似的場合，以堆疊方案為例，假設若干時間後有新的版本出現，則版本之間應該要能夠向上與向下相容(Backward、Forward)才合理，ZigBee這個部分則是有待觀察；而若使用不同堆疊方案或應用方案的產品，則表示將使用在不同的應用場合，所以彼此間就不一定要相容，ZigBee在這個部分則是符合預期。  

以堆疊方案為例，使用ZigBee Pro Feature Set與ZigBee Feature Set的產品，在一些條件限制之下，彼此可以互相加入對方的網路，但因為網路位置管理與群組管理機制等的方式不同，因此只能擔任末端節點(End Device)。而當無法滿足限制條件的情況之下，例如相同的安全機制，則兩者是完全無法相容的。因此未來在開發產品時，依舊還是須要注意彼此相容的問題。  

資料來源：www.zigbee.org 圖10　西門子大樓自動化產品APOGEE

再從市場的角度來看，雖然過去先有家庭控制的ZigBee產品出現，可是相關的無線感測網路技術中，ZigBee因為具有網路與安全的能力，使用在大範圍的應用系統較具優勢，藉由網路的能力，ZigBee可以使應用系統的範圍廣泛延伸；藉由安全能力，ZigBee可使應用的安全強度增加，這也是為什麼ZigBee Pro Feature Set會加強ZigBee網路與安全的能力，即是要拉開與競爭技術的區隔。  

不難發現，為了要有較為成功的案例，ZigBee聯盟現階段則將資源與希望投入在大型系統的應用市場，像是大樓控制與自動讀表系統，也算搭上近來全球在提升能源使用效率的趨勢，而這是其他可能的技術競爭者無法和ZigBee比較的市場。  

最後，藉由ZigBee規格的改善，配合其他如ZigBee Bridge、ZigBee Gateway、Commission Tool等附屬規格的輔助，再加上其他新的應用方案如商業大樓自動化應用方案與自動讀表基礎建設應用方案將陸續公布，未來像是西門子的大樓控制系統(圖10)，或是Itron的自動讀表系統(圖11)的產品將越來越多，屆時將有助ZigBee走出自己的一片天。

資料來源：www.zigbee.org 圖11　Itron自動讀表系統產品OpenWay

(本文作者為資策會網路多媒體研究所組長)