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地址是一个全球唯一的地址，并且一经分配就将跟随设备一生。它通常由制造商或者被安装时设置。这些地址由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)剩下的地址空间。
如果开发人员想改变这些值，则需要完成以下几个步骤：
首先，你要保证赋给这些参数的新值要合法。即整个地址空间不能超过，这就限制了参数能够设置的最大值。可以使用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)
应用程序通常使用AF_DataRequest()函数向一个ZigBee网络中的设备发送数据。数据包要发送给一个zAddrType_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) |