如何在創建ZigBee應用時做出正確的選擇

低功耗、低成本的ZigBee無線網絡標準使得把無線通信功能嵌入到日用家電成為可能。它的支持者宣稱，該標準將在家庭和樓宇自動化、節能甚至國土安全領域開拓豐富的新市場。

盡管ZigBee v1.0版規范已經得到最終批準，但對于打算進入這個市場的公司來說，該協議不是能以一種規格適應所有應用的“萬能藥”。在其最基礎層，ZigBee確保了與其它符合標準的產品的互操作性。而與ZigBee的潛在應用非常之廣一樣，開發人員必須權衡的問題也非常之多，包括更深層的應用、架構和平臺等。

ZigBee標準提供了網絡、安全和應用支持服務，這些服務工作在IEEE 802.15.4媒體存取控制(MAC)和物理層(PHY)無線標準之上。它采用了一整套技術來實現可擴展、自組織、自恢復的網絡，這種網絡可以管理各種各樣的數據傳輸模式(見圖1)。

圖1：ZigBee標準提供了在 MAC和PHY層之上的網絡、安全和 應用支持服務。

盡管ZigBee常常被默認為無線網格網絡，但該標準實際上支持多種網絡拓撲，包括星型、簇樹型(cluster tree)或星/網格混合型網絡(見圖2)。因此，開發人員首先要考慮的是“哪種網絡結構最適合我的應用需要？”

如果數據可靠性是關鍵要求，那么網格網絡架構針對固有的不可知缺陷提供了最佳防護，這些缺陷有可能導致任何無線環境(例如存在RF衰減、電磁干擾和多徑信號的情況)中的信號質量下降。通過把ZigBee接收器和發射器放得更加靠近，所有這三種條件的負面效果將會減輕。網格網絡的冗余通道會確保提供替代的數據通道，從而避免單節點故障。

其它應用也許需要ZigBee路由器來擴展網絡的工作范圍，其中路由器將充當因為相距太遠而不能直接通信的節點之間的中繼器。此外，這種部署方案可能依賴于電池供電的路由器，所以需要相當數量的“睡眠”時間以增加它們的使用壽命。例如，在一個農作物監視網絡或者類似的農業應用中，簇樹型結構也許是最好的選擇。它可以把多個子網絡匯聚成一個長距離的ZigBee廣域網。在這個廣域網中，低數據率的通信流沿著樹進行傳輸，而只有當需要發送或接收適當子網之間的數據時才喚醒電池供電的路由器。反之，一些較短距離的應用更適合采用星型拓撲，因為它可以免除網格網絡的路由通信負擔。

互操作性

盡管ZigBee是一個開放標準，但它也賦予了OEM很大的自由度，允許他們決定自己的產品應該在多大程度上向第三方供應商開放。因為ZigBee標準只定義了網絡、安全和應用接口層，所以開發商可以購買整個ZigBee協議棧，包括針對特定產品的應用類(profile)，或者只許可實現基本的網絡級互操作性的聯網層。

在應用層，開發商必須決定是采用公共的應用類還是開發自己專有的類。ZigBee v1.0已經為照明應用定義了基本的公共類，并正在制定針對HVAC、工業傳感器和其它傳感器的應用類。任何公司都可以設計與支持公共類的產品相兼容的產品。例如，一個采用公共ZigBee照明類的熒光燈鎮流器供應商可以與采用相同類的第三方燈開關調光器實現互操作。開發人員可以對該公共類加入他們自己的看法和感覺。ZigBee設備采用應用對象進行建模，這些應用對象通過交換類對象和它們的屬性實現與其它設備的通信。

盡管這看起來同ZigBee的開放精神相矛盾，但一些OEM也會開發不在應用層提供互操作性的產品。開發商可以設計專有的應用類，以創造只有單一供應商的設備，或者選擇第三方設備。ZigBee定義了一個抽象接口，而平臺供應商提供了應用編程接口(API)，該API定義了應用如何被集成到ZigBee協議棧的規則。一個專有的ZigBee系統仍然可以在網絡層上受益于第三方產品制造商。ZigBee底層棧的互操作性提供了數據路由、媒體存取控制、網絡形成及維護、設備和服務發現等功能。

數據如何進行傳輸是開發人員考慮的另一個關鍵因素，因為ZigBee沒有定義傳輸層。開發人員必須決定到底是自己創建傳輸機制，還是使用一個帶有內置傳輸層的ZigBee芯片來創建他們的應用。例如，Ember公司連同ZigBee協議棧一道提供了一個傳輸層，這有助于簡化應用開發過程并確保可靠的端到端消息傳遞。該傳輸層提供了開發人員可以據此定義專有ZigBee類的框架。

安全性

大部分ZigBee解決方案將需要某種級別的安全性。ZigBee提供了一套基于128位AES算法的安全類和軟件，并集成了802.15.4的安全元素。ZigBee協議棧類為MAC、網絡和應用層定義了安全性。它的安全服務包括針對關鍵進程建立和傳輸、設備管理和框架保護的方法。

如果開發人員選擇使用一個公共的ZigBee類，那么就已經為其應用做出了安全決策，因為在該類中已經對安全性進行了預定義。即使開發人員打算創建一個專有類的應用，他仍可以在若干個ZigBee預定義的棧類中挑選一種安全模式。

在這個層上，開發人員需要決定這樣一些問題：是否需要對數據幀的載荷進行加密，以及附著在數據幀末尾的認證碼長度(8、16或64位，等等)。基本的應用也許不需要認證，因而可以受益于一個較小的數據包載荷。這些數據完整性方面的選項使得開發人員可以在消息保護和額外開銷之間進行權衡。

開發人員還必須決定在哪個層上施加安全機制：在MAC層、網絡層還是應用層。如果應用需要盡可能強大的安全保護，那么就在應用層保護它。此處實施的安全措施采用了一個會話密鑰，它只能被另一個擁有該鑰匙的設備所認證和解密。這種方法既能防止內部攻擊也能防止外部攻擊，但需要更多的存儲器來實現它。

在MAC層和網絡層的安全性實質上服務于相同的目的：確保單跳傳輸的安全。MAC層仲裁對共享媒介的訪問并控制相鄰設備之間的單跳傳輸。ZigBee聯盟添加了一個網絡層安全選項以便加入在MAC層無法實現的功能，包括拒絕不能被驗證的數據幀的能力。這兩個安全層采用的是該網絡上所有ZigBee設備都共享的全局密鑰。MAC層和網絡層的安全性適合需要防止對特定基礎設施攻擊的應用，例如防止一個非法設備惡意侵入網絡。如果開發人員需要在兩個設備之間建立路由，而該網絡層的框架又是不安全的，那么非法設備可能會截取數據包。

圖2：ZigBee支持多種網絡拓撲， 包括星型、集群樹型或星/網格混 合型網絡。

ZigBee安全性還引入了一個“信用中心(Trust Center)”的概念，它允許設備進入網絡，然后分配密鑰，從而確保設備之間端到端的安全性。此處，開發人員必須根據他們的應用從兩種信用中心模式之間選擇一種：住宅或商用。住宅模式消耗資源少，但不建立密鑰或隨著網絡規模而擴展。商用模式建立并維護密鑰，而且具有良好的擴展性，但其代價是要消耗相當多的存儲器。

平臺考慮因素

ZigBee提供了一個標準化的網絡和應用框架，開發人員可以在此基礎上建立應用而無須擔憂聯網和RF問題的煩擾。然而，單靠其自身，ZigBee標準化框架不能保證產品的順利開發。為了創建兼容ZigBee的應用，這個市場的不同供應商提供了各種各樣的產品，包括RF收發器、微控制器、閃存ROM、供應商專有的協議棧和應用開發工具。因此，開發人員必須選擇是用多家供應商的組件創建自己的ZigBee解決方案，還是在一個集成硬件/軟件平臺上建立自己的應用。由于前一種方法涉及艱難的集成工作，因此大部分開發人員將可能傾向于后一種方法。

他們必須做出的第一個決定是在芯片和聯網軟件層次上。最大的挑戰起源于硬件和聯網軟件之間的復雜性和不兼容性。在開發一個新應用時發現的問題很少只局限于一個協議棧層。例如，在一個原型設計的MAC層中發現的一個故障很少能夠被網絡層提供商檢測到并進行調試。因而，開發人員必須仔細考慮他們所選平臺的集成深度。

一個ZigBee解決方案需要一個RF收發器、一個針對應用處理的微控制器或DSP和一個ZigBee網絡棧。直到最近，大部分系統都是來自于多家供應商合作伙伴的多芯片、多軟件解決方案。目前，新一代的全集成、單供應商平臺正在進軍該市場。多供應商平臺有時可以提供較低的前期成本優勢。但是，一個單一來源的平臺雖然常常更昂貴，卻可讓開發人員避免由不同供應商的硬件和軟件產品組成的解決方案所固有的麻煩和產品開發延遲。

開發人員還必須考慮網絡棧的深度。一般來說，網絡棧越深，開發工作越容易。一個提供從物理網絡層、傳輸層直到ZigBee類的網絡棧將使開發人員不必理會網絡的內在工作機理，從而允許他們集中精力于應用開發上。例如，一個用混合供應商解決方案建立的ZigBee應用可能需要開發人員計算他們的應用將如何處理節點之間丟失的網絡包。這類復雜的網絡問題已經在單一來源、全棧平臺中得到考慮。

工具的選擇也可能成就或毀壞一項ZigBee開發工作。開發人員需要仔細考慮他們平臺的開發環境的廣度和功能。供應商提供全套的開發工具是很重要的，它應該具備多節點無線半導體、網絡軟件、軟件工具、培訓和技術支持。此外，該工具應該是一個集成環境的一部分，此集成環境具備通用接口或者是一系列獨立工具的集合。最后，開發環境應該包括用于調試的充分工具。

作者： Zachary Smith
首席軟件設計師
Ember公司