2. ZigBee
2.1 設備類型(Device Types)
在ZigBee網絡中存在三種邏輯設備類型：Coordinator(協調器)，Router(路由器)和End-Device(終端設備)。ZigBee網絡由一個Coordinator以及多個Router和多個End_Device組成。
上圖是一個簡單的ZigBee網絡示意圖。其中黑色節點為Coordinator，紅色節點為Router，白色節點為End-Device。
2.1.1 Coordinator(協調器)
協調器負責啟動整個網絡。它也是網絡的第一個設備。協調器選擇一個信道和一個網絡ID(也稱之為PAN ID，即Personal Area Network ID)，隨后啟動整個網絡。
協調器也可以用來協助建立網絡中安全層和應用層的綁定(bindings)。
注意，協調器的角色主要涉及網絡的啟動和配置。一旦這些都完成后，協調器的工作就像一個路由器(或者消失go away)。由於ZigBee網絡本身的分布特性，因此接下來整個網絡的操作就不在依賴協調器是否存在。
2.1.2 Router(路由器)
路由器的功能主要是：允許其他設備加入網絡，多跳路由和協助它自己的由電池供電的兒子終端設備的通訊。
通常，路由器希望是一直處於活動狀態，因此它必須使用主電源供電。但是當使用樹群這種網絡模式時，允許路由間隔一定的周期操作一次，這樣就可以使用電池給其供電。
2.1.3 End-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.3 Z-Stack尋址(Addressing in z-stack)
為了向一個在ZigBee網絡中的設備發送數據，應用程序通常使用AF_DataRequest()函數。數據包將要發送給一個afAddrType_t(在ZComDef.h中定義)類型的目標設備。
typedef struct
{
union
{
uint16 shortAddr;
} addr;
afAddrMode_t addrMode;
byte endPoint;
} afAddrType_t;
注意，除了網路地址之外，還要指定地址模式參數。目的地址模式可以設置為以下幾個值：
typedef enum
{
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_t group;
// 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中定義)：
l NLME_GetShortAddr()——返回本設備的16位網絡地址
l NLME_GetExtAddr()—— 返回本設備的64位擴展地址
使用下面的函數獲取該設備的父親設備的地址：
l NLME_GetCoordShortAddr()——返回本設備的父親設備的16位網絡地址
l NLME_GetCoordExtAddr()—— 返回本設備的父親設備的64位擴展地址
4. 綁定(Binding)
綁定是一種兩個(或者多個)應用設備之間信息流的控制機制。在ZigBee2006發布版本中，它被稱為資源綁定，所有的設備都必須執行綁定機制。
綁定允許應用程序發送一個數據包而不需要知道目標地址。APS層從它的綁定表中確定目標地址，然后將數據繼續向目標應用或者目標組發送。
注意：在ZigBee的1.0版本中，綁定表是保存在協調器(Coordinator當中)。現在所有的綁定記錄都保存在發送信息的設備當中。
4.1 建立綁定表(Building a Binding Table)
有三種方法可以建立一個綁定表：
l Zigbee Device Object Bind Request——一個啟動工具可以告訴設備創建一個綁定記錄
l Zigbee Device Object End Device Bind Request——兩個設備可以告訴協調器它們想要建立一個綁定表記錄。協調器來協調並在兩個設備中創建綁定表記錄。
l Device Application——一個設備上的應用程序建立或者管理一個綁定表
4.1.1 ZigBee Device Object Binding Request
任何一個設備都可以發送一個ZDO信息給網絡中的另一個設備，用來建立綁定表。稱之為援助綁定，它可以為一個發送設備創建一個綁定記錄。
4.1.1.1 啟動申請(The Commissioning Application)
一個應用程序可以通過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.2 ZigBee 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.3 Device Application Binding Manager
另一種進入設備綁定記錄的方式是應用自己管理綁定表。這就意味着應用程序需要通過調用下面的綁定管理函數在本地進入並且刪除綁定記錄：
l bindAddEntry()——在綁定表中增加一個記錄
l bindRemoveEntry()——從綁定表中刪除一個記錄
l bindRomoveClusterIdFromList()——從一個存在的綁定表記錄中刪除一個群ID
l bindAddClusterIdToList()——向一個已經存在的綁定記錄中增加一個群ID
l bindRemoveDev()——刪除所有地址引用的記錄
l bindRemoveSrcDev()——刪除所有源地址引用的記錄
l bindUpdateAddr()——將記錄更新為另一個地址
l bindFindExisting()——查找一個綁定表記錄
l bindIsClusterIdInList()——在表記錄中檢查一個已經存在的群ID
l bindNumBoundTo()——擁有相同地址(源或者目的)的記錄的個數
l bindNumEntries()——表中記錄的個數
l bindCapacity()——最多允許的記錄個數
l bindWriteNV()——在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 mesh network is described as a network in which the routing of messages is performed as a decentralized，cooperative process involving many peer devices routing on 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 and Selection)
路徑發現是網絡設備憑借網絡相互協作發現和建立路徑的一個過程。路由發現可以由任意一個路由設備發起，並且對於某個特定的目標設備一直執行。路徑發現機制尋找源地址和目標地址之間的所有路徑，並且試圖選擇可能的最好的路徑。
路徑選擇就是選擇出可能的最小成本的路徑。每一個結點通常持有跟它所有鄰接點的“連接成本(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 Quick reference)
| 設置路由表大小 |
MAX_RTG_ENTRIES，這個值不能小於4 (f8wConfig.cfg文件) |
| 設置路徑期滿時間 |
ROUTE_EXPIRY_TIME，單位秒。設置為零則關閉路徑期滿(f8wConfig.cfg文件) |
| 設置路徑發現表大小 |
MAX_RREQ_ENTRIES，網絡中可以同時執行的路徑發現操作的個數 |
6. ZDO消息請求(ZDO Message requests)
ZDO模塊提供功能用來發送ZDO服務發現請求消息，接收ZDO服務發現回復消息。下圖描述了應用程序發送IEEE 地址請求和接收IEEE地址回復的函數調用。
ZDO IEEE地址請求及應答
下面這個例子，一個應用程序想知道什么時候一個新的設備加入網絡。一個應用想要接收所有ZDO設備的通知信息。
ZDO Device 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)(MAC ACK)。MAC ACK默認情況下是一直打開的，通常能夠充分保證網絡的高可靠性。為了提供附加的可靠性，同時使發送設備能夠得到數據包已經被發送到目的地的確認，可以使用APS ACK。
APS acknowledgement在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 and network 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或者最大有效載荷大小。
typedef struct
{
uint8 kvp;
APSDE_DataReqMTU_t aps;
}afDataReqMTU_t;
uint8 afDataReqMTU( 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-Volatile Memory)
ZigBee設備有許多狀態信息需要被存儲到非易失性存儲空間中，這樣能夠讓設備在意外復位或者斷電的情況下復原。否則它將無法重新加入網絡或者起到有效作用。
為了啟用這個功能，需要包含NV_RESTORE編譯選項。注意，在一個真正的ZigBee網絡中，這個選項必須始終啟用。關閉這個選項的功能也僅僅是在開發階段使用。
ZDO層負責保存和恢復網絡層最重要的信息，包括最基本的網絡信息(Network Information Base NIB，管理網絡所需要的最基本屬性)；兒子節點和父親節點的列表；包含應用程序綁定表。此外，如果使用了安全功能，還要保存類似於幀個數這樣信息。
當一個設備復位后重新啟動，這類信息恢復到設備當中。如果設備重新啟動，這些信息可以使設備重新恢復到網絡當中。在ZDAPP_Init中， 函數NLME_RestoreFromNV()的調用指示網絡層通過保存在NV中的數據重新恢復網絡。如果網絡所需的NV空間沒有建立，這個函數的調用將同時初始化這部分NV空間。
9.6.2 應用的非易失性存儲器(Application Non-Volatile Memory)
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)
ZigBee security is built with the AES block cipher and the CCM mode of operation as the 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) |