ZigBee快速入門

2.ZigBee

2.1 設備類型(Device Types)

在ZigBee網絡中存在三種邏輯設備類型：Coordinator(協調器)，Router(路由器)和End-Device(終端設備)。ZigBee網絡由一個Coordinator以及多個Router和多個End_Device組成。

上圖是一個簡單的ZigBee網絡示意圖。其中黑色節點爲Coordinator，紅色節點爲Router，白色節點爲End-Device。

2.1.1Coordinator(協調器)

協調器負責啓動整個網絡。它也是網絡的第一個設備。協調器選擇一個信道和一個網絡ID(也稱之爲PAN ID，即Personal Area Network ID)，隨後啓動整個網絡。

協調器也能夠用來協助創建網絡中安全層和應用層的綁定(bindings)。

注意，協調器的角色主要涉及網絡的啓動和配置。一旦這些都完成後，協調器的工做就像一個路由器(或者消失go away)。因爲ZigBee網絡自己的分佈特性，所以接下來整個網絡的操做就不在依賴協調器是否存在。

2.1.2Router(路由器)

路由器的功能主要是：容許其餘設備加入網絡，多跳路由和協助它本身的由電池供電的兒子終端設備的通信。

一般，路由器但願是一直處於活動狀態，所以它必須使用主電源供電。可是當使用樹羣這種網絡模式時，容許路由間隔必定的週期操做一次，這樣就可使用電池給其供電。

2.1.3End-Device(終端設備)

終端設備沒有特定的維持網絡結構的責任，它能夠睡眠或者喚醒，所以它能夠能夠是一個電池供電設備。

一般，終端設備對存儲空間(特別是RAM的須要)比較小。

注意：在Z-Stack 1.4.1中一個設備的類型一般在編譯的時候經過編譯選項(ZDO_COORDINATOR 和RTR_NWK)肯定。全部的應用例子都提供獨立的項目文件來編譯每一種設備類型。

2.2 棧配置(Stack Profile)

棧參數的集合須要被配置爲必定的值，連同這些值在一塊兒被稱之爲棧配置。ZigBee聯盟定義了這些由棧配置組成的棧參數。

網絡中的全部設備必須遵循一樣的棧配置。

爲了促進互用性這個目標，ZigBee聯盟爲ZigBee2006規範定義了棧配置。全部遵循此棧配置的設備能夠在其餘開發商開發的遵循一樣棧配置的網絡中。

3. 尋址(Addressing)

3.1 地址類型(Address types)

ZigBee設備有兩種類型的地址。一種是64位IEEE地址，即MAC地址，另外一種是16位網絡地址。

64位地址使全球惟一的地址，設備將在它的生命週期中一直擁有它。它一般由製造商或者被安裝時設置。這些地址由IEEE來維護和分配。

16爲網絡地址是當設備加入網絡後分配的。它在網絡中是惟一的，用來在網絡中鑑別設備和發送數據。

3.2 網絡地址分配(Network address assignment)

ZigBee使用分佈式尋址方案來分配網絡地址。這個方案保證在整個網絡中全部分配的地址是惟一的。這一點是必須的，由於這樣才能保證一個特定的數據包可以發給它指定的設備，而不出現混亂。同時，這個尋址算法自己的分佈特性保證設備只能與他的父輩設備通信來接受一個網絡地址。不須要整個網絡範圍內通信的地址分配，這有助於網絡的可測量性。

在每一個路由加入網絡以前，尋址方案須要知道和配置一些參數。這些參數是MAX_DEPTH，MAX_ROUTERS和MAX_CHILDREN。這些參數是棧配置的一部分，ZigBee2006協議棧已經規定了這些參數的值：MAX_DEPTH = 5，MAX_ROUTERS = 6和MAX_CHILDREN = 20。

MAX_DEPTH決定了網絡的最大深度。協調器(Coordinator)位於深度0，它的兒子位於深度1，他的兒子的的兒子位於深度2，以此類推。MAX_DEPTH參數限制了網絡在物理上的長度。

MAX_CHILDREN決定了一個路由(Router)或者一個協調器節點能夠處理的兒子節點的最大個數。

MAX_ROUTER決定了一個路由(Router)或者一個協調器(Coordinator)節點能夠處理的具備路由功能的兒子節點的最大個數。這個參數是MAX_CHILDREN的一個子集，終端節點使用(MAX_CHILDREN – MAX_ROUTER)剩下的地址空間。

若是開發人員想改變這些值，則須要完成如下幾個步驟：

首先，你要保證這些參數新的賦值要合法。即，整個地址空間不能超過216，這就限制了參數可以設置的最大值。可使用projects\ZStack\tools文件夾下的CSkip.xls文件來確認這些值是否合法。當在表格中輸入了這些數據後，若是你的數據不合法的話就會出現錯誤信息。

當選擇了合法的數據後，開發人員還要保證再也不使用標準的棧配置，取而代之的是網絡自定義棧配置(例如：在nwk_globals.h文件中將STACK_PROFILE_ID改成NETWORK_SPECIFIC)。而後nwk_globals.h文件中的MAX_DEPTH參數將被設置爲合適的值。

此外，還必須設置nwk_globals.c文件中的Cskipchldrn數組和CskipRtrs數組。這些數組的值由MAX_CHILDREN和MAX_ROUTER構成。

3.3Z-Stack尋址(Addressing in z-stack)

爲了向一個在ZigBee網絡中的設備發送數據，應用程序一般使用AF_DataRequest()函數。數據包將要發送給一個afAddrType_t(在ZComDef.h中定義)類型的目標設備。

typedefstruct

{

union

{

uint16shortAddr;

}addr;

afAddrMode_taddrMode;

byteendPoint;

}afAddrType_t;

注意，除了網路地址以外，還要指定地址模式參數。目的地址模式能夠設置爲如下幾個值：

typedefenum

{

afAddrNotPresent= AddrNotPresent,

afAddr16Bit= Addr16Bit,

afAddrGroup= AddrGroup,

afAddrBroadcast= AddrBroadcast

}afAddrMode_t;

由於在Zigbee中，數據包能夠單點傳送(unicast)，多點傳送(multicast)或者廣播傳送，因此必須有地址模式參數。一個單點傳送數據包只發送給一個設備，多點傳送數據包則要傳送給一組設備，而廣播數據包則要發送給整個網絡的全部節點。這個將在下面詳細解釋。

3.3.1 單點傳送(Unicast)

Uicast是標準尋址模式，它將數據包發送給一個已經知道網絡地址的網絡設備。將afAddrMode設置爲Addr16Bit而且在數據包中攜帶目標設備地址。

3.3.2 間接傳送(Indirect)

當應用程序不知道數據包的目標設備在哪裏的時候使用的模式。將模式設置爲AddrNotPresent而且目標地址沒有指定。取代它的是從發送設備的棧的綁定表中查找目標設備。這種特色稱之爲源綁定。

當數據向下發送到達棧中，從綁定表中查找而且使用該目標地址。這樣，數據包將被處理成爲一個標準的單點傳送數據包。若是在綁定表中找到多個設備，則向每一個設備都發送一個數據包的拷貝。

上一個版本的ZigBee(ZigBee04)，有一個選項能夠講綁定表保存在協調器(Coordinator)當中。發送設備將數據包發送給協調器，協調器查找它棧中的綁定表，而後將數據發送給最終的目標設備。這個附加的特性叫作協調器綁定(Coordinator Binding)。

3.3.3 廣播傳送(broadcast)

當應用程序須要將數據包發送給網絡的每個設備時，使用這種模式。地址模式設置爲AddrBroadcast。目標地址能夠設置爲下面廣播地址的一種：

NWK_BROADCAST_SHORTADDR_DEVALL(0xFFFF)——數據包將被傳送到網絡上的全部設備，包括睡眠中的設備。對於睡眠中的設備，數據包將被保留在其父親節點直到查詢到它，或者消息超時(NWK_INDIRECT_MSG_TIMEOUT在f8wConifg.cfg中)。

NWK_BROADCAST_SHORTADDR_DEVRXON(0xFFFD)——數據包將被傳送到網絡上的全部在空閒時打開接收的設備(RXONWHENIDLE)，也就是說，除了睡眠中的全部設備。

NWK_BROADCAST_SHORTADDR_DEVZCZR(0xFFFC)——數據包發送給全部的路由器，包括協調器。

3.3.4 組尋址(Group Addressing)

當應用程序須要將數據包發送給網絡上的一組設備時，使用該模式。地址模式設置爲afAddrGroup而且addr.shortAddr設置爲組ID。

在使用這個功能呢以前，必須在網絡中定義組。(參見Z-stack API文檔中的aps_AddGroup()函數)。

注意組能夠用來關聯間接尋址。再綁定表中找到的目標地址多是是單點傳送或者是一個組地址。另外，廣播發送能夠看作是一個組尋址的特例。

下面的代碼是一個設備怎樣加入到一個ID爲1的組當中：

aps_Group_tgroup;

//Assign yourself to group 1

group.ID= 0x0001;

group.name[0]= 0; // This could be a human readable string

aps_AddGroup(SAMPLEAPP_ENDPOINT, &group );

3.4 重要設備地址(Important Device Adresses)

應用程序可能須要知道它的設備地址和父親地址。使用下面的函數獲取設備地址(在ZStack API中定義)：

lNLME_GetShortAddr()——返回本設備的16位網絡地址

lNLME_GetExtAddr()—— 返回本設備的64位擴展地址

使用下面的函數獲取該設備的父親設備的地址：

lNLME_GetCoordShortAddr()——返回本設備的父親設備的16位網絡地址

lNLME_GetCoordExtAddr()—— 返回本設備的父親設備的64位擴展地址

4. 綁定(Binding)

綁定是一種兩個(或者多個)應用設備之間信息流的控制機制。在ZigBee2006發佈版本中，它被稱爲資源綁定，全部的設備都必須執行綁定機制。

綁定容許應用程序發送一個數據包而不須要知道目標地址。APS層從它的綁定表中肯定目標地址，而後將數據繼續向目標應用或者目標組發送。

注意：在ZigBee的1.0版本中，綁定表是保存在協調器(Coordinator當中)。如今全部的綁定記錄都保存在發送信息的設備當中。

4.1 創建綁定表(Building a Binding Table)

有三種方法能夠創建一個綁定表：

lZigbee Device Object Bind Request——一個啓動工具能夠告訴設備建立一個綁定記錄

lZigbee Device Object End Device Bind Request——兩個設備能夠告訴協調器它們想要創建一個綁定表記錄。協調器來協調並在兩個設備中建立綁定表記錄。

lDevice Application——一個設備上的應用程序創建或者管理一個綁定表

4.1.1ZigBee Device Object Binding Request

任何一個設備均可以發送一個ZDO信息給網絡中的另外一個設備，用來創建綁定表。稱之爲援助綁定，它能夠爲一個發送設備建立一個綁定記錄。

4.1.1.1啓動申請(The CommissioningApplication)

一個應用程序能夠經過ZDP_BindReq()函數(在ZDProfile.h)，並在綁定表中包含兩個請求(地址和終點)以及想要的羣ID。第一個參數(目標dstAddr)是綁定源的短地址即，16位網絡地址。

肯定你已經在ZDConfig.h容許了這個功能(ZDO_BIND_UNBIND_REQUEST)。

你也可使用ZDP_UnbindReq()用一樣的參數取消綁定記錄。

目標設備發回ZigBee Device Object Bind 或者Unbind Response信息，該信息是ZDO代碼根據動做的狀態，經過調用ZDApp_BindRsq()或者ZDApp_UnbindRsq()函數來分析和通知ZDApp.c的。

對於綁定響應，從協調器返回的狀態將是ZDP_SUCCESS,ZDP_TABLE_FULL或者ZDP_NOT_SUPPORTED。

對於解除綁定響應，從協調器返回的狀態將是ZDP_SUCCESS,ZDP_NO_ENTRY或者ZDP_NOT_SUPPORTED。

4.1.1.2ZigBee Device Object End Device Bind Request

這個機制是在指定的時間週期(timeout period)內，經過按下選定設備上的按鈕或者相似的動做來綁定。協調器在指定的時間週期內，蒐集終端設備的綁定請求信息，而後以配置ID(Profile ID)和羣ID(Cluster ID)協議爲基礎，建立一個綁定表記錄做爲結果。默認的設備綁定時間週期(APS_DEFAULT_MAXBINDING_TIME)是16秒鐘(在nwk_globals.h中定義)。可是將它添加到f8wConfig.cfg中，則能夠更改。

在「用戶指南」中的應用程序就是一個終端設備綁定的例子(在每一個設備上按下SW2按鍵)。

你應該注意到，全部的例程都有處理關鍵事件的函數(例如：在TransmitApp.c中的TransmitApp_HandleKeys()函數)。這個函數調用ZDApp_SendEndDeviceBindReq()(在ZDApp.c中)。這個函數蒐集全部終端節點的請求信息，而後調用ZDP_EndDeviceBindReq()函數將這些信息發送給協調器。

協調器調用函數ZDP_IncomingData()【ZDProfile.c中】函數接收這些信息，而後再調用ZDApp_ProcessEndDeviceBindReq()【ZDObject.c中】函數分析這些信息，最後調用ZDApp_EndDeviceBindReqCB【ZDApp.c中】函數，這個函數再調用ZDO_MatchEndDeviceBind()【ZDObject.c中】函數來處理這個請求。

當收到兩個匹配的終端設備綁定請求，協調器在請求設備中啓動建立源綁定記錄的進程。假設在ZDO終端設備中發現了匹配的請求，協調器將執行下面的步驟：

l 發送一個解除綁定請求給第一個設備。這個終端設備鎖定進程，這樣解除綁定被首先發送來去掉一個已經存在的綁定記錄。

l 等待ZDO解除綁定的響應，若是響應的狀態是ZDP_NO_ENTRY，則發送一個ZDO綁定請求在源設備中建立一個綁定記錄。若是狀態是ZDP_SUCCESS，則繼續前進到第一個設備的羣ID。

l 等待ZDO綁定響應，若是收到了，則繼續前進到第一個設備的下一個羣ID。

l 當地一個設備完成後，用一樣的方法處理第二個設備。

l 當第二個設備也完成以後，發送ZDO 終端設備綁定請求消息給兩個設備。

4.1.1.3Device Application Binding Manager

另外一種進入設備綁定記錄的方式是應用本身管理綁定表。這就意味着應用程序須要經過調用下面的綁定管理函數在本地進入而且刪除綁定記錄：

lbindAddEntry()——在綁定表中增長一個記錄

lbindRemoveEntry()——從綁定表中刪除一個記錄

lbindRomoveClusterIdFromList()——從一個存在的綁定表記錄中刪除一個羣ID

lbindAddClusterIdToList()——向一個已經存在的綁定記錄中增長一個羣ID

lbindRemoveDev()——刪除全部地址引用的記錄

lbindRemoveSrcDev()——刪除全部源地址引用的記錄

lbindUpdateAddr()——將記錄更新爲另外一個地址

lbindFindExisting()——查找一個綁定表記錄

lbindIsClusterIdInList()——在表記錄中檢查一個已經存在的羣ID

lbindNumBoundTo()——擁有相同地址(源或者目的)的記錄的個數

lbindNumEntries()——表中記錄的個數

lbindCapacity()——最多容許的記錄個數

lbindWriteNV()——在NV中更新表

4.1.2 配置源綁定(Configuring Source Binding)

爲了在你的設備中使能源綁定在f8wConfig.cfg文件中包含REFLECTOR編譯標誌。同時在f8wConfig.cfg文件中查看配置項目NWK_MAX_BINDING_ENTRIES和MAX_BINDING_CLUSTER_IDS。NWK_MAX_BINDING_ENTRIES是限制綁定表中的記錄的最大個數，MAX_BINDING_CLUSTER_IDS是每一個綁定記錄的羣ID的最大個數。

綁定表在靜態RAM中(未分配)，所以綁定表中記錄的個數，每條記錄中羣ID的個數都實際影響着使用RAM的數量。每一條綁定記錄是8字節多(MAX_BINDING_CLUSTER_IDS * 2字節)。除了綁定表使用的靜態RAM的數量，綁定配置項目也影響地址管理器中的記錄的個數。

5. 路由(Routing)

5.1 概述(Overview)

A meshnetwork is described as a network in which the routing of messages is performedas a decentralized，cooperative process involving many peer devices routingon each others’ behalf.

路由對與應用層來講是徹底透明的。應用程序只需簡單的向下發送去往任何設備的數據到棧中，棧會負責尋找路徑。這種方法，應用程序不知道操做是在一個多跳的網絡當中的。

路由還可以自愈ZigBee網絡，若是某個無線鏈接斷開了，路由功能又能自動尋找一條新的路徑避開那個斷開的網絡鏈接。這就極大的提升了網絡的可靠性，同時也是ZigBee網絡的一個關鍵特性。

5.2 路由協議(Routing Protocol)

ZigBee執行基於用於AODV專用網絡的路由協議。簡化後用於傳感器網絡。ZigBee路由協議有助於網絡環境有能力支持移動節點，鏈接失敗和數據包丟失。

當路由器從他自身的應用程序或者別的設備那裏收到一個單點發送的數據包，則網絡層(NWK Layer)根據一下程序將它繼續傳遞下去。若是目標節點是它相鄰路由器中的一個，則數據包直接被傳送給目標設備。不然，路由器將要檢索它的路由表中與所要傳送的數據包的目標地址相符合的記錄。若是存在與目標地址相符合的活動路由記錄，則數據包將被髮送到存儲在記錄中的下一級地址中去。若是沒有發現任何相關的路由記錄，則路由器發起路徑尋找，數據包存儲在緩衝區中知道路徑尋找結束。

ZigBee終端節點不執行任何路由功能。終端節點要向任何一個設備傳送數據包，它只需簡單的將數據向上發送給它的父親設備，由它的父親設備以它本身的名義執行路由。一樣的，任何一個設備要給終端節點發送數據，發起路由尋找，終端節的的父親節點都已它的名義來回應。

注意ZigBee地址分配方案使得對於任何一個目標設備，根據它的地址均可以獲得一條路徑。在Z-Stack中，若是萬一正常的路徑尋找過程不能啓動的話(一般因爲缺乏路由表空間)，那麼Z-Stack擁有自動回退機制。

此外，在Z-Stack中，執行的路由已經優化了路由表記錄。一般，每個目標設備都須要一條路由表記錄。可是，經過把必定父親節點記錄與其子全部子結點的記錄合併，這樣既能夠優化路徑也能夠不喪失任何功能。

ZigBee路由器，包括協調器執行下面的路由函數：(i)路徑發現和選擇；(ii)路徑保持維護；(iii)路徑期滿。

5.2.1 路徑的發現和選擇(Route Discovery andSelection)

路徑發現是網絡設備憑藉網絡相互協做發現和創建路徑的一個過程。路由發現能夠由任意一個路由設備發起，而且對於某個特定的目標設備一直執行。路徑發現機制尋找源地址和目標地址之間的全部路徑，而且試圖選擇可能的最好的路徑。

路徑選擇就是選擇出可能的最小成本的路徑。每個結點一般持有跟它全部鄰接點的「鏈接成本(link costs)」。一般，鏈接成本的典型函數是接收到的信號的強度。沿着路徑，求出全部鏈接的鏈接成本總和，即可以獲得整個路徑的「路徑成本」。路由算法試圖尋找到擁有最小路徑成本的路徑。

路徑經過一系列的請求和回覆數據包被發現。源設備經過向它的全部鄰接節點廣播一個路由請求數據包，來請求一個目標地址的路徑。當一個節點接收到RREQ數據包，它依次轉發RREQ數據包。可是在轉發以前，它要加上最新的鏈接成本，而後更新RREQ數據包中的成本值。這樣，沿着全部它經過的鏈接，RREQ數據包攜帶着鏈接成本的總和。這個過程一直持續到RREQ數據包到達目標設備。經過不一樣的路由器，許多RREQ副本都將到達目標設備。目標設備選擇最好的RREQ數據包，而後發回一個路徑答覆數據包(a Route Reply)RREP給源設備。

RREP數據包是一個單點發送數據包，它沿着中間節點的相反路徑傳送直到它到達原來發送請求的節點爲止。

一旦一條路徑被建立，數據包就能夠發送了。當一個結點與它的下一級相鄰節點失去了鏈接(當它發送數據時，沒有收到MAC ACK)，該節點向全部等待接收它的RREQ數據包的節點發送一個RERR數據包，將它的路徑設爲無效。各個結點根據收到的數據包RREQ、RREP或者RERR來更新它的路由表。

5.2.2 路徑保持維護(Route maintenance)

網狀網提供路徑維護和網絡自愈功能。中間節點沿着鏈接跟蹤傳送失敗，若是一個鏈接被認定是壞鏈，那麼上游節點將針對全部使用這條鏈接的路徑啓動路徑修復。節點發起從新發現直到下一次數據包到達該節點，標誌路徑修復完成。若是不可以啓動路徑發現或者因爲某種緣由失敗了，節點則向數據包的源節點發送一個路徑錯誤包(RERR)，它將負責啓動新路徑的發現。這兩種方法，路徑都自動重建。

5.2.3 路徑期滿(Route expiry)

路由表爲已經創建鏈接路徑的節點維護路徑記錄。若是在必定的時間週期內，沒有數據經過沿着這條路徑發送，這條路徑將被表示爲期滿。期滿的路徑一直保留到它所佔用的空間要被使用爲止。這樣，路徑在絕對不使用以前不會被刪除掉的。在配置文件f8wConfig.cfg文件中配置自動路徑期滿時間。設置ROUTE_EXPIRY_TIME爲期滿時間，單位爲秒。若是設置爲0，則表示關閉自動期滿功能。

5.3 表存儲(Table storage)

路由功能須要路由器保持維護一些表格。

5.3.1 路由表(Routing table)

每個路由器包括協調器都包含一個路由表。設備在路由表中保存數據包參與路由所需的信息。每一條路由表記錄都包含有目的地址，下一級節點和鏈接狀態。全部的數據包都經過相鄰的一級節點發送到目的地址。一樣，爲了回收路由表空間，能夠終止路由表中的那些已經無用的路徑記錄。

路由表的容量代表一個設備路由表擁有一個自由路由表記錄或者說它已經有一個與目標地址相關的路由表記錄。在文件「f8wConfig.cfg」文件中配置路由表的大小。將MAX_RTG_ENTRIES設置爲表的大小(不能小於4)。

5.3.2 路徑發現表(Route discovery table)

路由器設備致力於路徑發現，保持維護路徑發現表。這個表用來保存路徑發現過程當中的臨時信息。這些記錄只在路徑發現操做期間存在。一旦某個記錄到期，則它能夠被另外一個路徑發現使用。這個值決定了在一個網絡中，能夠同時併發執行的路徑發現的最大個數。這個能夠在f8wConfig.cfg文件中配置MAX_ RREQ_ENTRIES。

5.4 路徑設置快速參考(Routing Settings Quickreference)

設置路由表大小	MAX_RTG_ENTRIES，這個值不能小於4 (f8wConfig.cfg文件)
設置路徑期滿時間	ROUTE_EXPIRY_TIME，單位秒。設置爲零則關閉路徑期滿(f8wConfig.cfg文件)
設置路徑發現表大小	MAX_RREQ_ENTRIES，網絡中能夠同時執行的路徑發現操做的個數

6. ZDO消息請求(ZDO Message requests)

ZDO模塊提供功能用來發送ZDO服務發現請求消息，接收ZDO服務發現回覆消息。下圖描述了應用程序發送IEEE 地址請求和接收IEEE地址回覆的函數調用。

ZDOIEEE地址請求及應答

下面這個例子，一個應用程序想知道何時一個新的設備加入網絡。一個應用想要接收全部ZDO設備的通知信息。

ZDODevice Announce delivered to an application

7. 便攜式設備(Portable Devices)

在ZigBee2006中終端節點就是便攜式的設備。這就意味着當一個終端節點沒有偵聽到它的父節點回應(超出範圍或者沒法勝任)，它將試着從新加入網絡(加入到另外一個新的父親節點)。沒有設置或者編譯標誌位來設置這個選項。

終端節點經過巡檢(MAC 數據請求)失敗或者經過數據消息失敗偵聽它的父親節點都沒有迴應。MAX_POLL_FAILURE_RETRIES用來控制失敗的敏感度。這個值能夠在f8wConfig.cfg文件中修改。而且，這個值越大敏感度就越低，從新加入網絡須要的時間就更長。

當網絡層偵測到它的父親節點沒有迴應，它將調用ZDO_SynIndicationCB()函數，這個函數將啓動從新加入。從新加入過程首先對已有的父親節點進行孤兒掃描(orphan-scan)，而後掃描潛在的父親節點而且跟它的潛在父節點加入網絡。

在一個安全網絡中，假設設備都擁有一個鑰匙，新的鑰匙不用在分發給設備。

8. 端到端確認(End-to-end acknowledgements)

對於非廣播消息，有兩種基本的消息重試類型：端到端的確認(APS ACK)和單級確認(single hop acknowledgement)(MACACK)。MAC ACK默認狀況下是一直打開的，一般可以充分保證網絡的高可靠性。爲了提供附加的可靠性，同時使發送設備可以獲得數據包已經被髮送到目的地的確認，可使用APS ACK。

APSacknowledgement在APS層完成，是從目標設備到源設備的一個消息確認系統。源設備將保留這個消息知道目標設備發送一個APS ACK消息代表它已經收到了消息。對於每一個發出的消息能夠經過調用函數AF_DataRequest()的選項來使能/禁止來禁止這個功能。這個選項區域是一個位映射選項，對於將要發送的消息的選項區域或上(OR)AF_ACK_REQUEST就可使能APS ACK。消息重試(若是APS ACK消息沒有收到)的次數和重試之間的時間間隔的配置項在f8wConfig.cfg文件中。APSC_MAX_FRAME_RETRIES是APS層在放棄發送數據以前，沒有收到APS ACK確認從新發送消息的次數。APSC_ACK_WAIT_DURATION_POLLED是從新發送之間的時間間隔。

9. 其餘(Miscellaneous)

9.1 配置信道(Configuring channel)

每個設備都必須有一個DEFAULT_CHANLIST來控制信道集合。對於一個ZigBee協調起來講，這個表格用來掃描噪音最小的信道。對於終端節點和路由器幾點來講，這個列表用來掃描並加入一個存在的網絡。

9.2 配置PAN ID和要加入的網絡(Configuring PAN ID andnetwork to join)

這個可選配置項用來控制ZigBee路由器和終端節點要加入那個網絡。文件f8wConfg.cfg中的ZDO_CONFIG_PAN_ID參數能夠設置爲一個0~0x3FFF之間的一個值。協調器使用這個值，做爲它要啓動的網絡的PAN ID。而對於路由器節點和終端節點來講只要加入一個已經用這個參數配置了PAN ID的網絡。若是要關閉這個功能，只要將這個參數設置爲0xFFFF。

要更進一步控制加入過程，須要修改ZDApp.c文件中的ZDO_NetworkDiscoveryConfirmCB函數。

9.3 最大有效載荷大小(Maximum payload size)

對於一個應用程序最大有效載荷的大小基於幾個因素。MAC層提供了一個有效載荷長度常數102。NWK層須要一個固定頭大小，一個有安全的大小和一個沒有安全的大小。APS層必須有一個可變的基於變量設置的頭大小，包括ZigBee協議版本，KVP的使用和APS幀控制設置等等。最後，用戶沒必要根據前面的要素來計算最大有效載荷大小。AF模塊提供一個API，容許用戶查詢棧的最大有效載荷或者最大傳送單元(MTU)。用戶調用函數afDataReqMTU(見af.h文件)，該函數將返回MTU或者最大有效載荷大小。

typedefstruct

{

uint8kvp;

APSDE_DataReqMTU_taps;

}afDataReqMTU_t;

uint8afDataReqMTU( afDataReqMTU_t* fields )

一般afDataReqMTU_t結構只須要設置kvp的值，這個值代表KVP是否被使用。而aps保留。

9.4 離開網絡(Leave Network)

ZDO管理器執行函數「ZDO_ProcessMgmtLeaveReq」，這個函數提供對「NLME-LEAVE.request」原語的訪問。「NLME-LEAVE.request」原語設備移除它自身或者它的一個兒子設備。ZDO_ProcessMgmtLeaveReq根據提供給它的IEEE地址移除設備。若是設備要移除它本身，它需等待大約5秒鐘而後復位。一旦設備復位它將從新回來，並處於空閒模式。它將不在試圖鏈接或者加入網絡。若是設備要移除它的兒子設備，它將從本地的羣從表(accociation table)中刪除該設備。只有在它的兒子設備是個終端節點的狀況下，NWK地址纔會被從新使用。若是兒子節點是個路由器設備，NWK地址將再也不使用。

若是一個兒子節點的父親節點離開了網絡，兒子節點依然存在於網絡。

儘管「NLME-LEAVE.request」原語提供了一些可選參數，可是ZigBee2006(TI當前的應用也同樣)卻限制了這些參數的使用。如今，在ZDO_ProcessMgmtLeaveReq函數中使用的可選參數(「RemoveChildren」、「Rejion」and 「Silent」)都應該使用默認值。若是改變這些值，將會發生不可預料的結果。

9.5 描述符(Descriptors)

ZigBee網絡中的全部設備都有一個描述符，用來描述設備類型和它的應用。這個信息能夠被網絡中的其餘設備獲取。

配置項在文件ZDOConfig.h和ZDOConfig.c中定義和建立。這兩個文件還包含節點，電源描述符和默認用戶描述符。確認改變這些描述符來定義你的網絡。

9.6 非易失性存儲項(Non-volatile Memory Items)

9.6.1 網絡層非易失性存儲器(Network Layer Non-VolatileMemory)

ZigBee設備有許多狀態信息須要被存儲到非易失性存儲空間中，這樣可以讓設備在乎外復位或者斷電的狀況下復原。不然它將沒法從新加入網絡或者起到有效做用。

爲了啓用這個功能，須要包含NV_RESTORE編譯選項。注意，在一個真正的ZigBee網絡中，這個選項必須始終啓用。關閉這個選項的功能也僅僅是在開發階段使用。

ZDO層負責保存和恢復網絡層最重要的信息，包括最基本的網絡信息(Network Information Base NIB，管理網絡所須要的最基本屬性)；兒子節點和父親節點的列表；包含應用程序綁定表。此外，若是使用了安全功能，還要保存相似於幀個數這樣信息。

當一個設備復位後從新啓動，這類信息恢復到設備當中。若是設備從新啓動，這些信息可使設備從新恢復到網絡當中。在ZDAPP_Init中，函數NLME_RestoreFromNV()的調用指示網絡層經過保存在NV中的數據從新恢復網絡。若是網絡所需的NV空間沒有創建，這個函數的調用將同時初始化這部分NV空間。

9.6.2 應用的非易失性存儲器(Application Non-VolatileMemory)

NV一樣能夠用來保存應用程序的特定信息，用戶描述符就是一個很好的例子。NV中用戶描述符ID項是ZDO_NV_USERDESC(在ZComDef.h中定義)。

在ZDApp_Init()函數中，調用函數osal_nv_item_init()來初始化用戶描述符所須要的NV空間。若是這個針對這個NV項，這個函數是第一次調用，這個初始化函數將爲用戶描述符保留空間，而且將它設置爲默認值ZDO_DefaultUserDescriptor。

當須要使用保存在NV中的用戶描述符時，就像ZDO_ProcessUserDescReq()(在ZDObject.c中)函數同樣，調用osal_nv_read()函數從NV中獲取用戶描述符。

若是要更新NV中的用戶描述符，就像ZDO_ProcessUserDescSet()(在ZDObject.c中)函數同樣，調用osal_nv_write()函數更新NV中的用戶描述符。

記住：NV中的項都是獨一無二的。若是用戶應用程序要建立本身的NV項，那麼必須從應用值範圍0x0201~0x0FFF中選擇ID。

10. 安全(Security)

10.1 概述(Overview)

ZigBeesecurity is built with the AES block cipher and the CCM mode of operation asthe underlying security primitive。AES/CCM安全算法是ZigBee聯盟之外的研究人員發明的，而且普遍應用於其餘通信協議之中。

ZigBee提供以下的安全特性：

l 構造安全 (Infrastructure security)

l 網絡訪問控制(Network access control)

l 應用數據安全

10.2 配置(Configuration)

爲了擁有一個安全的網絡，首先全部的設備鏡像的建立，必須將預處理標誌位SECURE都置爲1。在文件「f8wConfig.cfg」文件中能夠找到。

接下來，必須選擇一個默認的密碼。這個能夠經過「f8wConfig.cfg」文件中的DEFAULT_KEY來設置。理論上，這個值設置爲一個隨機的128位數據。

這個默認的密碼能夠預先配置到網絡上的每一個設備或者只配置到協調器上，而後分發給假如網絡的全部設備。這個能夠經過文件「nwk_globals.c」文件的gPreConfigKeys選項來配置。若是這個值爲真，那麼默認的密碼將被預先配置到每個網絡設備上。若是這個值爲假，那麼默認的密碼只需配置到協調器設備當中。注意，在之後的場合，這個密碼將被分發到每個加入網絡當中的設備。所以，加入網絡期間成爲「瞬間的弱點」，競爭對手能夠經過偵聽獲取密碼，從而下降了網絡的安全性能。

10.3 網絡訪問控制(Network access control)

在一個安全的網絡中，當一個設備加入網絡時會被告知一個信任中心(協調器)。協調器擁有容許設備保留在網絡或者拒絕網絡訪問這個設備的選擇權。

信任中心能夠經過任何邏輯方法決定一個設備是否容許進入這個網絡中。其中一種就是信任中心只容許一個設備在很短的窗口時間加入網絡。這個時可能的，舉例說明，若是一個信任中心設備有一個「push」按鍵。當按鍵按下，在這個很短的時間窗口中，它容許任何設備加入網絡。不然全部的加入請求都將被拒絕。以他們的IEEE地址爲基礎，一個秒級的時間段將被配置在信任中心用來接收或者拒絕設備。

這種類型的策略能夠經過修改ZDSeeMgr.c模塊中的ZDSecMgrDeviceValidate()函數來實現。

10.4 更新密碼(Key Updates)

信任中心能夠根據本身的判斷更新通用網絡密碼。應用程序開發人員修改網絡密碼更新策略。默認信任中心執行可以用來符合開發人員的指定策略。一個樣例策略將按照必定的間隔週期更新網絡密碼。另一種將根據用戶輸入來更新網絡密碼。ZDO安全管理器(ZDSecMgr.c)API經過 「ZDSecMgrUpdateNwkKey」和「ZDSecMgrSwitchNwkKey」提供必要的功能。「ZDSecMgrUpdateNwkKey」容許信任中心向網絡中的全部設備廣播新的網絡密碼，此時，新的網絡密碼將被做爲替代密碼保存在全部網絡設備中。一旦信任中心調用「ZDSecMgrSwitchNwkKey」，一個全網範圍的廣播將觸發全部的網絡設備使用替代密碼。

10.5 快速參考(Quick Reference)

使能安全(Enabling Security)	SECURE = 1(f8wConfig.cfg)
使能預配置網絡密碼(Enabling Preconfig Network Key)	gPreConfigKeys = TRUE(nwk_globals.c)
設置預配置網絡密碼(Setting Preconfig Network Key)	設置defautlKey = {KEY}(ZDSecMgr.c)
使能/禁止信任中心的加入許可功能(Enabling/Disabling joining permission on the Trust Center)	調用函數ZDSecMgrPermitJoining()(ZDSecMgr.c)
加入期間特定設備批准(Specific device validation during joining)	修改ZDSecMgrDeviceValidate(ZDSecMgr.c)
網絡密碼更新(Network key updates)	調用ZDSecMgrUpdateNwkKey()和ZDSecMgrSwitchNwkKEy()函數(ZDSecMgr.c)