zibgee协议
1.1解析ZigBee堆栈架构
ZigBee堆栈是在IEEE 802.15.4标准基础上建立的，定义了协议的MAC和PHY层。ZigBee设备应该包括IEEE802.15.4(该标准定义了RF射频以及与相邻设备之间的通信)的PHY和MAC层，以及ZigBee堆栈层：网络层(NWK)、应用层和安全服务提供层。图1-1给出了这些组件的概况。
1.1.1ZigBee堆栈层
每个ZigBee设备都与一个特定模板有关，可能是公共模板或私有模板。这些模板定义了设备的应用环境、设备类型以及用于设备间通信的簇。公共模板可以确保不同供应商的设备在相同应用领域中的互操作性。
设备是由模板定义的，并以应用对象(Application Objects)的形式实现(见图1-1)。每个应用对象通过一个端点连接到ZigBee堆栈的余下部分，它们都是器件中可寻址的组件 图1-1 zigbe堆栈框架
从应用角度看，通信的本质就是端点到端点的连接(例如，一个带开关组件的设备与带一个或多个灯组件的远端设备进行通信，目的是将这些灯点亮)。
端点之间的通信是通过称之为簇的数据结构实现的。这些簇是应用对象之间共享信息所需的全部属性的容器，在特殊应用中使用的簇在模板中有定义。图1-1-2就是设备及其接口的一个例子：
图1-1-2
每个接口都能接收(用于输入)或发送(用于输出)簇格式的数据。一共有二个特殊的端点，即端点0和端点255。端点0用于整个ZigBee设备的配置和管理。应用程序可以通过端点0与ZigBee堆栈的其它层通信，从而实现对这些层的初始化和配置。附属在端点0的对象被称为ZigBee设备对象(ZD0)。端点255用于向所有端点的广播。端点241到254是保留端点。
所有端点都使用应用支持子层(APS)提供的服务。APS通过网络层和安全服务提供层与端点相接，并为数据传送、安全和绑定提供服务，因此能够适配不同但兼容的设备，比如带灯的开关。
APS使用网络层(NWK)提供的服务。NWK负责设备到设备的通信，并负责网络中设备初始化所包含的活动、消息路由和网络发现。应用层可以通过ZigBee设备对象(ZD0)对网络层参数进行配置和访问。
1.1.2 802.15.4 MAC层
IEEE 802.15.4标准为低速率无线个人域网(LR-WPAN)定义了OSI模型开始的两层。PHY层定义了无线射频应该具备的特征，它支持二种不同的射频信号，分别位于2450MHz波段和868/915MHz波段。2450MHz波段射频可以提供250kbps的数据速率和16个不同的信道。868/915MHz波段中，868MHz支持1个数据速率为20kbps的信道，915MHz支持10个数据速率为40kbps的信道。
MAC层负责相邻设备间的单跳数据通信。它负责建立与网络的同步，支持关联和去关联以及MAC层安全：它能提供二个设备之间的可靠链接。
1.1.3 关于服务接入点
ZigBee堆栈的不同层与802.15.4 MAC通过服务接入点(SAP)进行通信。SAP是某一特定层提供的服务与上层之间的接口。
ZigBee堆栈的大多数层有两个接口：数据实体接口和管理实体接口。数据实体接口的目标是向上层提供所需的常规数据服务。管理实体接口的目标是向上层提供访问内部层参数、配置和管理数据的机制。
1.1.4 ZigBee的安全性
安全机制由安全服务提供层提供。然而值得注意的是，系统的整体安全性是在模板级定义的，这意味着模板应该定义某一特定网络中应该实现何种类型的安全。
每一层(MAC、网络或应用层)都能被保护，为了降低存储要求，它们可以分享安全钥匙。SSP是通过ZD0进行初始化和配置的，要求实现高级加密标准(AES)。ZigBee规范定义了信任中心的用途。信任中心是在网络中分配安全钥匙的一种令人信任的设备。
1.1.5 ZigBee堆栈容量和ZigBee设备
根据ZigBee堆栈规定的所有功能和支持，我们很容易推测ZigBee堆栈实现需要用到设备中的大量存储器资源。 不过ZigBee规范定义了三种类型的设备，每种都有自己的功能要求：ZigBee协调器是启动和配置网络的一种设备。协调器可以保持间接寻址用的绑定表格，支持关联，同时还能设计信任中心和执行其它活动。一个ZigBee网络只允许有一个ZigBee协调器。
ZigBee路由器是一种支持关联的设备，能够将消息转发到其它设备。ZigBee网格或树型网络可以有多个ZigBee路由器。ZigBee星型网络不支持ZigBee路由器。
ZigBee端终设备可以执行它的相关功能，并使用ZigBee网络到达其它需要与其通信的设备。它的存储器容量要求最少。然而需要特别注意的是，网络的特定架构会戏剧性地影响设备所需的资源。NWK支持的网络拓扑有星型、树型和网格型。在这几种网络拓扑中，星型网络对资源的要求最低。
ZigBee堆栈应该可以提供ZigBee规范要求的所有功能，因此制造商的重点工作是开发实际的应用。为了更加容易实现，如果制造商使用某种公共模板，那么可用大多数现成的配置。如果没有合适的公共模板，则可以充分利用其它模板已经做过的工作创建自己的模板。
ZigBee协议栈体系包含一系列的层元件，其中有IEEE802.15.4 2003标准中的MAC层和PHY层，当然也包括ZigBee组织设计的NWK层。每个层的元件有其特定的服务功能。本说明描述内容涉及ZigBee协议栈的各层元件，但侧重于描述最具实际和理论探讨性的APL应用层和NWK网络层。图1-1为ZigBee栈结构框图。
2.APL应用层介绍
2.1.1应用层简介
如图2-1所示，ZigBee应用层由三个部分组成，APS子层、ZDO（包含ZDO管理平台）和制造商定义的应用对象。
图2-1 zigbee协议堆栈分层结构
2.1.2应用层框架
ZigBee中的应用框架是为驻扎在ZigBee设备中的应用对象提供活动的环境。
最多可以定义240个相对独立的应用程序对象，且任何一个对象的端点编号都是从1到240。此外还有两个附加的终端节点，为了APSDE-SAP的使用：端点号0固定用于ZDO数据接口；另外一个端点255固定用于所有应用对象广播数据的数据接口功能。端点241-254保留（留给未来扩展使用）。
2.1.2.1应用Profiles
应用profiles是一组统一的消息，消息格式和处理方法，允许开发者建立一个可以共同使用的分布式应用程序，这些应用是利用驻扎在独立设备中的应用实体来实现的。这些应用profiles允许应用程序发送命令、请求数据和处理命令的请求。
2.1.2.2簇
簇标识符可用来区分不同的簇，簇标识符联系着从设备流出和向设备流入的数据。在特殊的应用profiles范围内，簇标识符是唯一的。
2.1.3ZigBee设备对象
ZigBee设备对象（ZDO），描述了一个基本的功能函数，这个功能在应用对象、设备profile和APS之间提供了一个接口。ZDO位于应用框架和应用支持子层之间。它满足所有在ZigBee协议栈中应用操作的一般需要。此外ZDO还有以下作用：
（1）初始化应用支持子层（APS），网络层（NWK），安全服务规范（SSS）。
（2）从终端应用集合中配置的信息来确定和执行安全管理、发现、网络管理、以及绑定管理。
ZDO描述了应用框架层中应用对象的公用接口以及控制设备和应用对象的网络功能。在终端节点0, ZDO提供了与协议栈中与低一层连接的接口，如果是数据则通过APSDE-SAP，如果是控制信息则通过APSME-SAP。ＺＤＯ的具体描述在2.5节。
2.1.3.1设备发现
设备发现是ZigBee设备为什么能发现其他设备的过程。这有两种形式的设备发现请求：IEEE地址请求和网络地址请求。IEEE地址请求是单播到一个特殊的设备且假定网络地址已经知道。网络地址请求是广播且携带一个已知的IEEE地址作为负载。
2.1.3.2服务发现
服务发现是为什么一个已知设备被其他设备发现的能力的过程。服务发现通过在一个已知设备的每一个端点发送询问或通过使用一个匹配服务（广播或者单播）。服务发现方便定义和使用各种描述来概述一个设备的能力。
服务发现信息在网络中也许被隐藏，在这种情况下，设备提供的特殊服务便可能不在操作发生的时候到达。
2.2 ZigBee应用支持子层APS
APS提供了这样的接口：在NWK层和APL层之间，从ZDO到供应商的应用对象的通用服务集。这服务由两个实体实现：APS数据实体（APSDE）和APS管理实体（APSME）。
(1)APSDE提供在同一个网络中的两个或者更多的应用实体之间的数据通信。通过APSDE服务接入点(APSDE-SAP)；
（2）APSME提供多种服务给应用对象，这些服务包含安全服务和绑定设备，并维护管理对象的数据库，也就是我们常说的AIB。通过APSME服务接入点（APSME-SAP）。
2.2.1 范围
这一小节描述了应用层部分提供的服务规范和生产商定义的应用对象与ZigBee设备对象之间的接口。规范定义了允许应用对象传输数据的数据服务和提供绑定机制的管理服务。另外，它还定义了应用支持子层的帧格式和帧类型。如图2-2
图2-2 zigbee帧格式
2.2.2 目的
这小节的目的是定义ZigBee应用支持子层的功能。该功能建立在两个基础之上，一是正确运行ZigBee网络层的驱动功能，二是制造商定义的应用对象所需要的功能。
2.2.3 应用支持子层简介
应用支持子层给网络层和应用层通过ZigBee设备对象和制造商定义的应用对象使用的一组服务提供了接口，该接口提供了ZigBee设备对象和制造商定义的应用对象使用的一组服务。通过两个实体提供这些服务：数据服务和管理服务。APS数据实体(APSDE)通过与之连接的SAP，即APSDE-SAP提供数据传输服务。APS管理实体(APSME)通过与之连接的SAP，即APSME-SAP提供管理服务，并且维护一个管理实体数据库，即APS信息库（NIB）。
2.2.3.1 应用支持子层的数据实体（APSDE）
APSDE向网络层提供数据服务，并且为ZDO和应用对象提供服务，完成两个或多个设备之间传输应用层PDU。这些设备本身必须在同一个网络。
APSDU将提供如下服务：
生成应用层的协议数据单元（APDU）：APSDE将应用层协议数据单元（PDU）加上适当的协议帧头生成应用子层的协议数据单元（PDU）。
绑定：两个设备服务和需求相匹配的能力。一旦两个设备绑定了，APSDE将可以把从一个绑定设备接受到的信息传送给另一个设备。
组地址过滤：提供了基于终点组成员的过滤组地址信息的能力。
可靠传输：比从网络层仅仅通过端对端的传输增加了可靠性
拒绝重复：提供传送的信息不会被重复接收
支持大批量的传输：提供两个设备间顺序传输大批量的数据的能力。
碎片：当消息的长度大于单个网络层帧时，可以分割并重组消息。
流控制：APS提供避免传输消息淹没接收者的措施。
阻塞控制：APS层使用“尽力”原则，提供措施避免传输消息淹没中间网络。
2.2.3.2 应用支持子层的管理实体（APSME）
APSME应提供管理服务支持应用程序符合堆栈。
APSME应具有基于两个设备的服务和需求向匹配的能力。该服务称为绑定服务，APSME应具有能力来构建和维护绑定表来存储这些信息。
另外，APSME应提供如下服务：
1 应用层信息库管理：读取与设置设备应用层信息库属性的能力
2 安全：与其他设备通过使用安全密钥建立可信关系的能力
2.2.4 服务规范
应用支持子层为上层实体（NHLE）与网络层提供了一个接口。APS层理论上包含一个管理实体称为APS层，管理实体（APSME）。这个实体通过调用子层的管理函数来提供服务接口。APSME还负责维护一个关于APS子层管理实体的数据库。这是一个关于APS子层信息库（AIB）的数据库.图2-3描述了APS子层的构成和接口。
图2-3 应用支持之层参考模型
APS子层通过两个服务指针（SAPs）提供两种服务。APS数据服务通过APS子层数据实体服务指针SAP（APSDE-SAP），APS管理服务通过APS则层管理实体服务指针SAP(APSME-SAP).这两个服务通过NLDE-SAP和NLME-SAP 接口 (见3.2小节)提供了NHLE和网络层之间的接口。网络层和APS子层之间的NLME-SAP接口只支持NLME-GET 和 NLME-SET原语，其他的NLME-SAP原语只可以通过ZDO实现（见2.5小节）。除了这些外部接口以外，在APSME和APSDE之间还有一个内部的接口，支持APSME使用APS数据服务。
2.2.4.1 APS数据服务
APS子层数据实体SAP（APSDE-SAP）支持在两个同等的应用实体之间传输应用协议数据单元。表2-1列出了APSDE-SAP支持的原语。每一个原语将在下面的小节论述。
2.2.4.1.1 APSDE-DATA.request
该原语请求从本地NHLE向一个同等的NHLE实体传输NHLE PDU(ASDU)。
2.2.4.1.1.1 服务原语的语法
该原语的语法如下：
APSDE-DATA_request
{
DstAddrMode
DSTAddress
DstEndpoint
Profiled
Clusterld
SrcEndpoint
asduLength
asdu
TxOpionts
RadiusCounter
}
表2.2详细说明了APSDE-DATA.request原语的参数。
2.2.4.1.1.2 产生
当有一个数据PDU(ASDU)由本地NHLE向一个同等的NHLE传输时，由本地NHLE生成该原语。
2.2.4.1.1.3 2
当APS子层实体接收到该原语时，便开始传输提供的ASDU。
如果DstAddrMode参数为0x00，并且接收该原语的设备的APSDE支持绑定表，那么在绑定表中根据参数SrcEndpoint和ClusterId所指定的endpoint和cluster identifiers寻找相关联的绑定表入口。如果没有绑定表入口，APSDE将发送状态参数为NO_BOUND_DEVICE 的语APSDE-DATA.confirm原语。如果找到了一个或多个绑定表入口，APSDE将构建APDU，其endpoint信息从绑定表入口获得，当通过网络层传输信息帧时，其destination address信息从绑定表入口获得。如果存在多于一个绑定表入口，当接收到相应的NLDE-DATA.confirm原语，按上面描述的，APSDE将构建并向下一个绑定表入口传输APDU，直到没有绑定表入口剩余。如果接收到该原语设备的APSDE不支持绑定表，那么APSDE将发送状态参数为NOT_SUPPORTED的APSDE-DATA.confirm原语。
如果DstAddrMode参数为0x02，DstAddress参数包含扩展的64位IEEE地址，首次必须使用NIB（见表2.24）属性中的nwkAddressMap映射相应的16位网络地址。如果找不到相应的16位网络地址，那么APSDE将发送状态参数为NO_SHORT_ADDRESS的APSDE-DATA.confirm原语。如果找到了相应的16位网络地址，其值将被用在NLDE-DATA.request原语中，参数DstEndpoint将被置在作为结果的APDU中。如果DstAddrMode参数为0x01，表明为群地址，参数DstAddress将被解释为16位的全地址。这个地址将被放置在APS头中的群地址域，参数DstEndpoint将被忽略，APS头中的destination endpoint域将被省略。APS头中的帧控制域的delivery mode子域值在这种情况下为0x03.
如果DstAddrMode参数为0x02，DstAddress参数包含16位的网络地址，并且提供参数DstEndpoint，当目的网络地址用于应用响应，并且网络地址部位后面的数据传输请求保留时，上层只能使用DstAddrMode为0x02.
应用程序可以通过使用参数RadiusCounter来限制在网络中传输数据帧的跳数。如果参数RadiusCounter为0x00，网络层在网络中传输信息帧没有约束。如果参数RadiusCounter为非零，则网络层将允许信息帧在网络中传输存在最多RadiusCounter跳。
如果DstAddrMode参数为0x01，表明为群地址，或者DstAddrMode参数为0x00，并且相应的绑定表入口包含哪一个群地址，那么APSME将检查NIB（见表3.42）中的属性nwkUseMulticast值。如果属性值为FALSE，那么输出帧的帧控制域中的delivery mode子域设为0b11，16位的目的群地址将设置输出帧APS头中的group address域，该帧将以广播方式传输。传输该帧的原语NLDE-DATA.request的DstAddr参数设置为值0xfffd，广播给所有RxOnWhenIdle=TRUE的设备。如果属性nwkUseMulticast值为TRUE，那么该帧将使用网络层多点传送方式传输，群地址不用放置在输出帧的APS头中。
如果参数TxOptions指定使用安全传输，则APS子层将使用安全服务为ASDU提供安全（见4.2.4小节）。如果安全处理失败，则APSDE发送状态参数为SECURITY_FAIL的APSDE-DATA.confirm原语。
APSDE使用NLDE-DATA.request原语向网络层传输构造帧。当接收到NLDE-DATA.confirm原语，APSDE则发送APSDE-DATA.confirm原语，其状态参数值域从网络层接收到的一致。
APSDE通过每次发送使NLDE-DATA.request原语的DiscoverRoute参数值为0x01确保网络层中的路由发现始终激活。
如果传输的ASDU大于合适的单个帧，当没有请求确认传输或者在TxOptions域的fragmentation permitted标志位设为0时，则放弃传输ASDU，APSDE将发送状态参数为INVALID_REQUEST的APSDE-DATA.confirm原语。
如果传输的ASDU大于合适的单个帧，当请求确认传输并且在TxOptions域的fragmentation permitted标志位设为1时，ASDU将按照2.2.8.3.5小节所述分裂为多个APDU。如果请求传输和安全处理，那么每一个APDU都要进行处理。注意不要使用分裂处理，除非相应的上层文件或者相互明确表明帧的传输允许分裂处理，并且说明了块的数量和总共传输的大小。
2.2.4.1.2 APSDE-DATA.confirm
该原语报告从本地NHLE向一个同等的NHLE传输PDU数据的结果。
2.2.4.1.2.1 服务原语的语法
该原语的语法如下：
APSDE-DATA.confirm {
DstAddMode
DstAddress
DstEndpoint
SrcEndpoint
Status
}
表2.3详细介绍了APSDE-DATA.confirm原语的参数。
2.2.4.1.2.2 产生
该原语有本地APS子层产生作为对APSDE-DATA.request原语的响应。该原语返回的状态参数值为SUCCESS，表明请求传输成功，或者为错误代码NO_SHORT_ADDRESS , NO_BOUND_DEVICE 或SECURITY_FAIL或者为任何NLDE-DATA.confirm原语返回的状态值。这些状态值的路由在2.2.4.1.2小节中进行了详细的描述。
2.2.4.1.2.3 接收
接收到该原语，发起设备的上层被通报请求传输的结果。如果传输成功，状态参数值设置为SUCCESS。否则，状态参数表明错误。
2.2.4.1.3 APSDE-DATA.indication
该原语表明一个PDU数据向本地应用实体的APS子层传输。
2.2.4.1.3.1 服务原语的语法
该原语的语法如下：
APSDE-DATA.indication
{
DstAddrMode
DSTAddress
DstEndpoint
SrcAddrMode
SARCAddress
SrcEndpoint
Profield
Clusterld
asduLength
asdu
WasBroadcast
SecurityStatus
LinkQuality
}
表2.4详细描述了APSDE-DATA.indication原语的参数。
2.2.4.1.3.2 产生
该原语由APS子层产生，当从本地网络层实体接收到适当地址的数据帧时，APS子层向上层发送该原语。如果ASDU头的帧控制域表明该帧安全保护，则按照4.2.4小节的描述进行安全处理。
该原语由APS子层产生，当通过NLDE-DATA.indication原语从网络层接收到适当地址的数据帧时，发送给上层实体。如果APDU头的帧控制域表明该帧安全保护，则按照4.2.4小节的描述进行安全处理。
接收到的帧的源地址必须通过NIB（见表2.24）中的属性nwkAddressMap映射为相应的扩展的64位IEEE地址。如果能找到相应的64为IEEE地址，则APSDE发送该原语，其参数SrcAddrMode设为0x02，SrcAddress参数设为相应的64位IEEE地址。如果找不到相应的64位IEEE地址，APSDE将发送该原语，其参数SrcAddrMode设为0x01，参数SrcAddress设为接收帧包含的16位源地址。
2.2.4.1.3.3 接收
接收到该原语，上层被通报有数据到达该设备。
2.2.4.2 APS管理服务
APS管理实体SAP(APSME-SAP)支持上层和APSME层之间传输管理命令。表2.5总结了APSME通过APSME-SAP接口支持的原语。各原语的详细描述见下面小节。
2.2.4.3 绑定原语
这组原语定义了设备上层如何将一个绑定记录加入（提交）其本地绑定表或将绑定记录从本地绑定表中移除。
只有支持绑定表或者绑定表存储器的设备支持这些原语。如果其他设备从上层接收到这些原语，那么这些原语将被忽略。
2.2.4.3.1 APSME-BIND.request
该原语允许支持绑定的设备上层通过在本地绑定表中建立一个入口请求将两个设备绑定。
2.2.4.6.1.1 服务原语的语法
该原语的语法如下：
APSME-BIND.request {
SrcAddr
SrcEndpoint
Clusterld
DstAddrMode
DstAddr
DstEndpoint
}
表2.6详细描述了APSME-BIND.request原语的参数。
2.2.4.3.1.2 产生
该原语由上层产生发送给APS子层，在支持绑定表的设备上发起绑定操作。
2.2.4.3.1.3 接收
一旦被当前没有加入到网络或不支持绑定表的设备接收到该原语，那么APSME将发送状态参数为ILLEGAL_REQUEST的APSME-BIND.confirm原语。
如果支持绑定表的设备的APS子层从NHLE接收该原语，APSME将试图直接从其绑定表中建立指定的入口。如果可以建立入口，APSME将发送状态参数为SUCCESS的APSME-BIND.confirm原语。如果因为其绑定表缺乏能力而无法建立入口，APSME将发送状态参数为TABLE_FULL的APSME-BIND.confirm原语。
2.2.4.3.2 APSME-BIND.confirm
该原语使设备得到其上层请求绑定两个设备的结果。
2.2.4.3.2.1 服务原语的语法
该原语的语法如下：
APSME-BIND.confirm {
Status
SrcAddr
SrcEndpoint
Clusterld
DstAddrMode
DstAddr
DstEndpoint
}
表2.7详细描述了APSME-BIND.confirm原语的语法。
2.2.4.3.2.2 产生
该原语由APSME产生作为APSME-BIND.request原语的响应发送给NHLE。如果请求成功，那么状态参数将表明一个成功的绑定请求。否则，状态参数则为错误码ILLEGAL_DEVICE、 ILLEGAL_REQUEST 或TABLE_FULL。
2.2.4.3.2.3 接收
接收到该原语，上层就被通知其绑定请求的结果。如果绑定请求成功，状态参数设置为SUCCESS。否则，状态参数表明错误。
2.2.4.3.3 APSME-UNBIND.request
该原语允许支持绑定的设备上层通过在本地绑定表中移除一个入口请求将两个设备解除绑定。
2.2.4.3.3.1 服务原语的语法：
APSME-UNBIND.request {
SrcAddr
SrcEndpoint
Clusterld
DstAddrMode
DstAddr
DstEndpoint
}
表2.8详细描述了APSME-UNBIND.request原语的参数。
2.2.4.3.3.2 产生
该原语有上层产生发送给APS子层，在支持绑定表的设备上发起解除绑定操作。
2.2.4.3.3.3 接收
一旦被当前没有加入到网络或不支持绑定表的设备接收到该原语，那么APSME将发送状态参数为ILLEGAL_REQUEST的APSME-UNBIND.confirm原语。
如果支持绑定表的设备的APS子层从NHLE接收该原语，APSME将在绑定表中查找指定的入口。如果入口存在，APSME将移除这个入口并发送状态参数为SUCCESS的APSME-UNBIND.confirm原语（见2.2.4.3.4小节）。如果没有找到入口，APSME将发送状态参数为INVALID_BINDING的APSME-UNBIND.confirm原语。如果该设备不在网络中，APSME将发送状态参数为ILLEGAL_DEVICE的APSME-BIND.confirm原语。
2.2.4.3.4 APSME-UNBIND.confirm
该原语使设备得到其上层请求解除两个设备绑定的结果。
2.2.4.3.4.1 服务原语的语法
该原语的语法如下：
APSME-UNBIND.confirm {
Status
SrcAddr
SrcEndpoint
Clusterld
DstAddrMode
DstAddr
DstEndpoint
}
表2.9详细描述了APSME-UNBIND.confirm原语的语法。
2.2.4.3.4.2 产生
该原语由APSME产生作为APSME-UNBIND.request原语的响应发送给NHLE。如果请求成功，那么状态参数将表明一个成功的解除绑定请求。否则，状态参数则为错误码ILLEGAL_DEVICE、 ILLEGAL_REQUEST 或INVALID_BINDING。
2.2.4.3.4.3 接收
接收到该原语，上层就被通知其解除绑定请求的结果。如果解除绑定请求成功，状态参数设置为SUCCESS。否则，状态参数表明错误。
2.2.4.4 信息库的维护
这组原语定义了设备上层如何读取和写入AIB中的属性。
2.2.4.4.1 APSME-GET.request
该原语允许设备上层从AIB中读取属性值。
2.2.4.4.1.1 服务原语的语法
该原语的语法如下：
APSME-GET.request {
AIBAttribute
}
表2.10描述了该原语的参数。
2.2.4.4.1.2 产生
该原语由上层产生并发送给APSME来读取AIB中的属性。
2.2.4.4.1.3 接收
接收到该原语，APSME试图从数据库中得到AIB属性。如果在数据库中没有相应的AIB属性表标识符，APSME将发送状态参数为UNSUPPORTED_ATTRIBUTE的APSME-GET.confirm原语。
如果成功得到了AIB属性，APSME将发送状态参数为SUCCESS，包含AIB属性标识符和属性值的APSME-GET.confirm原语。
2.2.4.4.2 APSME-GET.confirm
该原语向上层报告从AIB中读取属性值的结果。
2.2.4.4.2.1 服务原语的语法
该原语的语法如下：
APSME-GET.confirm {
Status
AIBAttribute
AIBAttributeLength
AIBAttributeValue
}
表2.11描述了该原语的参数。
2.2.4.4.2.2 产生
该原语由APSME产生，发送给上层作为对APSME-GET.request原语的响应。该原语返回状态SUCCESS，表明请求读取AIB属性请求成功，或者返回错误码UNSUPPORTED_ATTRIBUTE.这些状态在2.2.4.4.1.3小节进行了描述。
2.2.4.4.2.3 接收
接收到该原语，上层得知读取AIB属性请求的结果。如果读取AIB属性请求成功，状态参数设置为SUCCESS。否则，状态参数表明错误。
2.2.4.4.3 ASPME-SET.request
该原语允许设备上层将属性值写入AIB。
2.2.4.4.3.1 服务原语的语法
该原语的语法如下：
APSME-SET.request {
AIBAttribute
AIBAttributeLength
AIBAttributeValue
}
表2.12描述了该原语的参数。
2.2.4.4.3.2 产生
该原语由上层产生并发送给APSME在AIB中写入一个属性值。
2.2.4.4.3.3 接收
接收到该原语，APSME试图将给定的数据库中的值写入AIB属性。如果在数据库中没有AIB属性参数指定的属性，APSME将发送状态参数为UNSUPPORTED_ATTRIBUTE的APSME-SET.confirm原语。如果AIB属性值参数给定的值超过了有效的属性范围，APSME将发送状态参数为INVALID_PARAMETER的APSME-SET.confirm原语。
如果成功写入了AIB属性，APSME将发送状态参数为SUCCESS的APSME-SET.confirm原语。
2.2.4.4.4 APSME-SET.confirm
该原语向上层报告向AIB属性中写入属性值的结果。
2.2.4.4.4.1 服务原语的语法
该原语的语法如下：
APSME-SET.confirm {
Status
AIBAttribute
}
表2.13描述了该原语的参数。
2.2.4.4.4.2 产生
该原语由APSME产生，发送给上层作为对APSME-SET.request原语的响应。该原语返回状态SUCCESS，表明将属性值写入AIB属性的请求成功，或者返回错误码INVALID_PARAMETER或UNSUPPORTED_ATTRIBUTE.这些状态在2.2.4.4.3.3小节进行了描述。
2.2.4.4.4.3 接收
接收到该原语，上层得知写入AIB属性请求的结果。如果写入AIB属性请求成功，状态参数设置为SUCCESS。否则，状态参数表明错误。
2.2.4.5 组管理
这组原语允许上层在当前设备中通过在组表中添加和移除入口来管理每个端点的组关系。
2.2.4.5.1 APSME-ADD-GROUP.request
该原语允许上层请求一个特定的组的组关系加入到特定的端点。
2.2.4.5.1.1 服务原语的语法
该原语的语法如下：
APSME-ADD-GROUP.request {
GroupAddress
Endpoint
}
表2.14描述了该原语的参数。
2.2.4.5.1.2 产生
当上层要将一个特定组的关系加入一个端点时产生该原语，设置了组地址的帧将被传送给该端点。
2.2.4.5.1.3 接收
如果接收到该原语，其GroupAddress参数的值超出了有效范围，APSME将向上层发送状态参数为INVALID_PARAMETER的APSME-ADD-GROUP.condirm原语。同样，如果Endpoint参数值为0x00或当前设备的其它没有执行的端点，APSME将发送状态参数为INVALID_PARAMETER的APSME-ADD-GRROUP.confirm原语。
完成上述参数检测后,APSME将检查组表中是否存在包含给定参数GroupAddress和Endpoint的入口。如果该入口已存在于组表中，APSME将向上层发送状态参数为SUCCESS的APSME-ADD-GROUP.confirm原语。如果没有该入口，表中还有入口空间，APSME将在组表中建立一个新的入口，其参数为给定的GroupAddress和Endpoint值。入口加入到APS组表后，APSME将发送NLME-SET.request原语来确保相应的网络层组表中的nwkGroupIDTable属性与APS子层中的组表包含的组地址列表相一致。一旦两个表一致了，APSME将向上层发送状态参数为SUCCESS的APSME-ADD-GROUP.confirm原语。如果没有给定参数GroupAddress和Endpoint的入口并且组表中没有建立另一个入口的空间，APSME将向上层发送状态参数为TABLE_FULL的APSME-ADD-GROUP.confirm原语。
2.2.4.5.2 APSME-ADD-GROUP.confirm
该原语使得设备得知其将一个组添加到端点的请求结果。
2.2.4.5.2.1 服务原语的语法
该原语的语法如下：
APSME-ADD-GROUP.confirm {
Status
GroupAddress
Endpoint
}
表2.15描述了该原语的参数。
2.2.4.5.2.2 产生
该原语由APSME产生并发送给上层作为对APSME-ADD-GROUP.request原语的响应。如果APSME-ADD-GROUP.request成功，那么状态参数值为SUCCESS。如果APSME-ADD-GROUP.request中的参数为无效值，那么状态产生设置为INVALID_PARAMETER。如果APSME试图加入一个组表入口，但表中已没有加入其它入口的空间，状态参数设置为TABLE_FULL。
2.2.4.5.2.3 接收
上层接收到该原语，则得知添加组请求的结果。状态参数值如上面所述。
2.2.4.5.3 APSME-REMOVE-GROUP.request
该原语允许上层请求将一个特定的组的组关系从特定的端点中移除。
2.2.4.5.3.1 服务原语的语法
该原语的语法如下：
APSME-REMOVE-GROUP.request {
GroupAddress
Endpoint
}
表2.16描述了该原语的参数。
2.2.4.5.3.2 产生
当上层要将一个特定组的关系从一个端点中移除时产生该原语，设置了组地址的帧将不被传送给该端点。
2.2.4.5.3.3 接收
如果接收到该原语，其GroupAddress参数的值超出了有效范围，APSME将向上层发送状态参数为INVALID_PARAMETER的APSME-REMOVE-GROUP.condirm原语。同样，如果Endpoint参数值为0x00或当前设备的其它没有执行的端点，APSME将发送状态参数为INVALID_PARAMETER的APSME-REMOVE-GRROUP.confirm原语。
完成上述参数检测后,APSME将检查组表中是否存在包含给定参数GroupAddress和Endpoint的入口。如果该入口已存在于组表中，该入口将被移除。APSME将发送NLME-SET.request原语来确保相应的网络层组表中的nwkGroupIDTable属性与APS子层中的组表包含的组地址列表相一致。一旦两个表一致了，APSME将向上层发送状态参数为SUCCESS的APSME-REMOVE-GROUP.confirm原语。如果没有该入口，APSME将向上层发送状态参数为SUCCESS的APSME-REMOVE-GROUP.confirm原语。
2.2.4.5.4 APSME-REMOVE-GROUP.confirm
该原语使得设备得知其将一个组从端点中移除的请求结果。
2.2.4.5.4.1 服务原语的语法
该原语的语法如下：
APSME-REMOVE-GROUP.confirm {
Status
GroupAddress
Endpoint
}
表2.17描述了该原语的参数。
2.2.4.5.4.2 产生
该原语由APSME产生并发送给上层作为对APSME-REMOVE-GROUP.request原语的响应。如果APSME-REMOVE-GROUP.request成功，那么状态参数值为SUCCESS。如果APSME-REMOVE-GROUP.request中有参数为无效值，那么状态产生设置为INVALID_PARAMETER。
2.2.4.5.4.3 接收
上层接收到该原语，则得知移除组请求的结果。状态参数值如上面所述。
2.2.4.5.5 APSME-REMOVE-ALL-GROUP.request
当上层想要将所有组中的关系从端点中移除时产生该原语，因此，没有组地址的帧传送给端点。
2.2.4.5.5.1 服务原语的语法
该原语的语法如下：
APSME-REMOVE-ALL-GROUPS.request {
Endpoint
}
表2.18描述了该原语的参数。
2.2.4.5.5.2 产生
当上层想要将所有组中的关系从端点中移除时产生该原语，因此，没有组地址的帧传送给端点。
2.2.4.5.5.3 接收
接收到该原语，如果Endpoint参数值为0x00或当前设备的其它没有执行的端点，APSME将发送状态参数为INVALID_PARAMETER的APSME-REMOVE-ALL-GRROUP.confirm原语。
完成上述参数Endpoint检测后,APSME将从组表中移除所有与该端点相关的入口。APSME将发送NLME-SET.request原语来确保相应的网络层组表中的nwkGroupIDTable属性与APS子层中的组表包含的组地址列表相一致。一旦两个表一致了，APSME将向上层发送状态参数为SUCCESS的APSME-REMOVE-ALL-GROUP.confirm原语。
2.2.4.5.6 APSME-REMOVE-ALL-GROUP.confirm
该原语使得设备得知其从一个端点中移除所有组的请求结果。
2.2.4.5.6.1 服务原语的语法
该原语的语法如下：
表2.19描述了该原语的参数。
2.2.4.5.6.2 产生
该原语由APSME产生并发送给上层作为对APSME-REMOVE-ALL-GROUP.request原语的响应。如果APSME-REMOVE-ALL-GROUP.request成功，那么状态参数值为SUCCESS。如果APSME-REMOVE-ALL-GROUP.request中有参数为无效值，那么状态产生设置为INVALID_PARAMETER。
2.2.4.5.6.3 接收
上层接收到该原语，则得知从端点中移除所有组请求的结果。状态参数值如上面所述。
2.2.5 帧格式
这小节描述了APS层的帧格式（APDU）。每一个APS帧包含如下的基本组成：
1、APS头，由帧控制和地址信息组成。
2、APS有效载荷，变长，包含帧类型指定的信息。
APS子层的帧作为有序域按照指定的顺序进行描述。这小节的所有帧格式都按照网络层的传输顺序进行描述，从左至右，最左的位最先传输。每个域中的长度为k位都从0（最左、最低）至k-1（最右、最高）排号。域中长度小于一个字节的值都按照从最低位至最高位的顺序向网络层传输。
2.2.5.1 常规的APDU帧格式
APS帧格式由一个APS帧头和APS有效载荷组成。APS帧头域有固定的顺序，在帧中可以不包含地址域。常规的APS帧格式如表2.2所示。
2.2.5.1.1 帧控制域
帧控制域8比特长，包含定义的帧类型、地址域和其它控制标志信息。帧控制域如表2.3所示的格式。
2.2.5.1.1.1 帧类型子域
帧类型子域为2比特长，可设置为表2.20所列出的值。
2.2.5.1.1.2 传输模式子域
传输模式子域2比特长，可设置为表2.21所列出的值。
如果值为0b00，帧将被发送给接收设备给定的端点。
如果值为0b10，消息为广播发送。在这种情况下，消息将被发送给所选择的使用的广播地址的所有设备和所有端点，见3.7.5小节。
如果值为0b11，将使用组地址，帧只被发送给APS头中组地址域所确定的在组中表示组成员的设备端点。注意，源设备的其它端点可能是输出帧组地址的成员。帧将被发送给指定组的成员，包括源设备的其它端点。
2.2.5.1.1.3 安全子域
安全服务提供者（见4章）管理安全子域。
2.2.5.1.1.4 确认请求子域
确认请求子域1比特长，指定了当前的传输是否要求接收者接收到帧后发送确认帧。如果该子域设置为1，确定接收的为有效帧后，接收者需要构建并向发起者发送确认帧。如果该子域为0，确定接收的为有效帧后，接收者不向发起者发送确认帧。
2.2.5.1.1.5 延长头存在
延长头存在子域为1比特长，指定在帧中是否包含延长头。如果该子域设置为1，那么延长头包含在帧中。否则，不包含在帧中。
2.2.5.1.2 目的端点域
目的端点8比特长，指定帧的最终接收端点。如果帧控制域中的传输模式子域为0b00（标准单播发送），那么帧中包含该域。
目的端点值为0x00，该帧的目的地址为每个设备的ZOD。目的端点值为0x01-0xf0，帧目的地址为操作的端点。目的端点值为0xff，帧目的地址为除了端点0x00的所有活跃的端点。端点（0xf1-0xfe）保留。
2.2.5.1.3 组地址域
组地址域16比特长，只有当帧控制中的传输模式子域为0b11时存在该域。在这种情况下，目的端点不存在。如果帧中的APS头包含组地址域，帧将被发送设备中组表中由组地址域确定的所有端点。
设备的nwkUseMukticast设置为TRUE，输出帧不设置组地址域。
2.2.5.1.4 簇标识符域
簇标识符16比特长，指定由请求中SrcAddr所指示的用于设备绑定操作的簇标识符。帧控制域的帧类型子域指定簇标识符域是否存在。该域只用于数据帧，不用于命令帧。
2.2.5.1.5 Profile标识符域
Profile标识符2字节长，指定在传输帧的过程中，用于设备过滤消息和帧的Profile标识符。该域之用于数据帧和确认镇。
2.2.5.1.6 源端点域
源端点域8比特长，指定发起者帧的端点。源端点值为0x00，表明从每个设备的ZDO发起。源端点值为0x01-0xf0，表明帧从应用操作的端点发起。其它的端点（0xf1-0xfe）保留。
2.2.5.1.7 APS计数器
该域8比特长，用于防止接收重复帧，如2.2.8.4.2小节。每新传输一次该值加一。
2.2.5.1.8 延长头子域
延长头子域包含深层子域，格式如表2.4所示。
2.2.5.1.8.1延长帧控制域
延长帧控制域长8比特，包含使用分裂的定义信息。延长帧控制域的格式如表2.5所示。
分裂子域2比特长，值为表2.22所列出的任意值。
2.2.5.1.8.2 块序号
块序号域为1字节长，用于如下所述的分裂控制：如果分裂子域的设置表示不是分裂传输，那么子域中不包含块序号域。如果分裂域设置为01，那么子域中包含块序号域，并且该域表示在分裂传输中块的序号。如果分裂域设置为10，那么子域中包含块序号域，并且表示当前帧传输的块序号，用值0x02表示第二个分裂块，0x03表示第三个，等等。
2.2.5.1.8.3 应答位域
应答位域为1字节长，用于2.2.8.4.3小节所描述的APS确认，表示成功传输哪个ASDU分裂块。该域只有在帧类型域表明为确认帧并且分裂子域表明是分裂传输使才出现。
2.2.5.1.9 帧有效载荷域
帧有效载荷域为变长，包含各个帧类型指定的信息。
2.2.5.2 个别帧类型的格式
定义了三种帧类型：数据、APS命令和确认帧。每一个帧类型都在下面的小节进行讨论。
2.2.5.2.1 数据帧格式
数据帧的格式如表2.6所示。
数据帧中域的顺序如表2.2所示的APS帧顺序。
2.2.5.2.1.1 数据帧APS帧头域
数据帧的APS帧头域包含帧控制、簇标识符、Profile标识符、源端点和APS计数器域。数据帧是否包含目的端点和延长头域则各自按照帧控制域中的传输模式和延长头存在域的规定。
在帧控制域中，帧类型应包含如表2.20所示的表示数据帧的值。源端点存在域设置为1.所有其它域根据使用数据帧的意图设置。
2.2.5.2.1.2 数据有效载荷域
对于输出的数据帧，数据有效载荷应包含部分或全部上层请求APS数据服务传输的字节序列。对于输入数据帧，数据有效载荷域应包含APS数据服务接收到的转发给目的设备或如果协调器是其中的目的地发送给上层字节序列。
2.2.5.2.2 APS命令帧格式
APS命令帧格式如表2.7所示。
APS命令帧中域的顺序如表2.7所示的APS帧顺序。
2.2.5.2.2.1 APS命令你帧APS头域
APS命令帧的APS头域应包含帧控制和APS计数器域。如果帧控制域中的传输模式子域表明为组地址，则帧中应包含组地址域。在该版本的规范中，APS命令帧不能分裂，并且没有延长头域。
在帧控制域中，帧类型子域应包含表明是APS命令帧的值，如表2.20所示。APS命令有效载荷应根据使用APS命令帧的意图进行适当的设置。
2.2.5.2.2.2 APS命令标识符域
APS命令标识符域表明正在使用APS命令。
2.2.5.2.2.3 APS命令有效载荷域
APS命令帧的APS命令有效载荷域应包含APS命令本身。
2.2.5.2.3 确认帧格式
确认帧格式如表2.8所示。
确认帧中域的顺序应与表2.8所示的APS帧中域顺序一致。
2.2.5.2.3.1 确认帧APS头域
确认帧的APS头域应包含帧控制、簇标识符、Profile标识符和APS计数器。源和目的端点都应包含在确认帧中。是否包含延长头域则按照帧控制域中延长头存在子域的要求设备。
在帧控制域中，帧类型子域应包含如表2020所示的表示为确认帧的值。延长头存在域应包含同样表明为确认帧的值。所有其它子域则根据使用确认帧的意图进行适当的设置。
确认帧源端点的值反映了要求进行确认的帧的目的端点的值。同样，确认帧目的端点的值反映了要求进行确认的帧的源端点的值。
APS计数器域包含与确认的帧相一致的值。
如果延长头域存在，延长的帧控制域的分裂域应包含域确认的帧一致的值。如果该帧使用分裂，那么应包含块序号和请求域。如果传输的使分裂的第一个帧，那么块序号应为0，否则应包含域确认的帧一致的值。
2.2.6 命令帧
这部分规范没有命令帧。APS命令帧和原语的相关安全问题见4.5.9小节。
2.2.7 常数和PIB属性
2.2.7.1 APS常数
APS子层常量的定义与描述见表2.23.
2.2.7.2 APS信息数据库
APS信息数据库包含管理设备APS层需要的属性。AIB属性如表2.24所示。AIB还包含一些管理安全服务的属性。这些属性在4.5.10小节列出。
2.2.8 功能描述
2.3ZigBee应用程序框架
2.3.1建立一个ZigBee Profile
在ZigBee网络中两个设备之间通信的关键是统一一个profile。
Profile的一个例子就是智能家居。这个ZigBee profile允许一系列设备类型交换控制消息来构造一个无线智能家居应用。这些设备被设计成很好的交换已知信息来实现这些控制，如控制灯的开和关，发送一个亮度传感器测量给一个照明设备控制器或者如果已有的传感器检测到移动就发送一个警告信息。
Profile另一个类型的例子是在连个ZigBee设备间定义了普通行为。为了举例说明，无线网络在网络中依靠自制设备的能力来同网络连接和发现其他设备和在设备上的服务。设备和服务发现是在设备的profile中支持的特性。
2.3.1.1从ZigBee联盟获得的Profile标识符
ZigBee在两个分开的等级定义Profile，这两个等级是：私人的和公开的。这些等级的精确定义和标准是在ZigBee联盟和在这个文件范围之外的一个管理问题。为了这个技术规范的目的，对Profile标识符标准是唯一的。到最后，对一个Profile标识符的应用程序，每一个Profile必须以向ZigBee联盟的一个请求开始。一旦获得Profile标识符，Profile标识符允许Profile设计者有如小定义：
（1） 设备描述
（2） 簇标识符
Profile标识符的应用的市场空间对从ZigBee联盟发行Profile标识符是一个关键的标准。Profile需要覆盖一个足够宽的设备范围来允许互动性来发生在没有过度范围设备之间，且导致用来描述它们接口的一个簇标识符的不足。相反的。Profile不能被定义的太狭窄导致很多被个人Profile标识符描述的设备导致Profile标识符寻址空间的浪费，且在描述设备如何接口时产生互操作性。在ZigBee联盟里的政策组将就如何定义Profile建立标准，且帮助请求者制作它们的Profile标识符请求。
2.3.1.2定义设备描述和簇
Profile标识符是在ZigBee协议中主要的主要枚举量。每一个唯一的Profile标识符定义了设备描述和簇标识符的一个联合的枚举量。例如，对Profile标识符“1”，存在一些被16位值描述的设备描述（就是说在每一个Profile中可能有65536个设备描述）和一些被16位值描述的簇标识符（就是说在每一个Profile中可能有65536个标识符）。每一个簇标识符也支持一些被16位值描述的属性。例如，每一个Profile标识符最多有65536格簇标识符且每一个这样的标识符最多又可以包含65536格属性。Profile开发者的责任就是定义和分配设备描述，簇标识符和在它们已分配的Profile标识符里的属性。注意设备描述、簇标识符和属性标识符的定义必须很小心的采用以保证简单描述的有效建立和当交换消息时单一化处理。
设备描述和簇标识符必须通过将被处理的已知的profile标识符来完成。在任何消息被定向到一个设备之前，ZigBee协议采用已经使用服务发现确定profile在设备和端点的支持。同样的，绑定处理采用相似的服务发现，且profile发生，由于作为结果的匹配提取到源地址、源端点、簇标识符、目的地址和目的端点。
2.3.1.3在端点配置profile
在一个单独的ZigBee设备也许包含许多的profile的维持，这些profile是由在这些profile定义的各种簇标识符的子集提供的，且维持多样的设备描述。在设备里使用一个分层寻址定义的能力如下：
（1） 设备：设备是由有唯一的IEEE和网络地址的单个无线电来维持的。
（2） 端点：这是一个8位的域，描述了不同的应用程序，这些应用都是由单个无线电来维持的。端点0x00用来寻址设备profile，设备profile是每个ZigBee设备必须使用的；端点0xff用来寻址所有活动的端点（广播端点），且端点0xf1-0xfe保留。结果，一个单独的物理ZigBee无线电能维持最多240个应用程序在端点0x01-0xf0.
应用程序决定关于如何造设备端点配置应用程序和哪个端点来广播（advertise）。唯一的要求是每个端点都建立简单的描述符，且这些描述符对于服务发现是有效的。
2.3.1.4激活安全发现
一旦设备被建立维护特殊的profile且同簇描述符使用一致，簇描述符使用是为在这些profile中的设备描述，那么应用程序能被配置。为了达到这一点，每一个应用程序被分配给个别的端点，且每一个都使用简单描述符来描述。通过简单描述和在ZigBee设被profile中描述的其他服务发现机制，激活服务发现，设备的绑定被维持和在补充的设备间应用程序的通知。
重要的一点是服务发现是以profile标识符、输入簇标识符列表和输出簇标识符列表（设备描述很明显的丢失了）为基础构成的。设备描述是在表示profile的类型的设备里规定必选的和可选的簇标识符维持的一个简单的协定。另外，期望设备描述枚举在PDA里使用或者其他辅助的绑定设备提供设备能力的额外描述。
2.3.1.5混合标准和所有权Profile
一个例子，ZigBee设备能被建立带有一个为了一个标准而写的单独的端点应用程序，公开的ZigBee profile标识符“XX”。如果生产商想配置一个ZigBee设备支持的标准profile“XX”，且提供给卖主特殊的扩展名，这些扩展名将被advertised在一个孤立的端点。维持标准的profile标识符“XX”，但生产时没有卖主扩展名的设备将仅仅advertised维持单独的profile标识符“XX”，且不能使用卖主扩展名响应或者建立消息。
2.3.1.6激活相反的兼容性
在先前的例子中，使用一个标准建立一个设备，这个标准公布ZigBee profile标识符“XX”，它包含了标准的profile的最初版本。如果ZigBee联盟将更新这个标准profile来建立新的特性和加法（additions），修订本将组合成一个新的标准profile，这个新的标准profile有一个新的profile标识符（即“XY”）。有profile标识符“XX”的设备应域新设备兼容，这新的设备对于profile标识符“XX”和profile标识符“XY”有新设备advertised维持。以这种方式，新设备使用profile标识符“XX”与旧设备通信，然而，也可以使用profile标识符“XY”与旧设备通信在相同的应用程序里。在ZigBee中的服务发现特性激活网络中的设备来确定维持级别。
2.3.2ZigBee描述
ZigBee设备使用描述符数据结构来描述它们自己。包含在这些描述符里的实际数据被定义在个人的设备描述符里。有五个描述符：节点、节点电源、简单的、复杂的和使用者，如表2.25所示。
表2.25ZigBee描述符
| 描述符名称 |
状态 |
描述 |
| Node |
M |
节点的类型和能力 |
| Node power |
M |
节点电源特性 |
| Simple |
M |
包含在节点里的设备描述 |
| Complex |
O |
设备描述的进一步信息 |
| User |
O |
定义的使用者的描述符 |
2.3.2.1描述符传送
节点、节点电源、简单的和使用者描述符按它们出现在各自的表中的顺序传送，也就是，在表头的域第一个传送，表底的域最后传送。每一个individual域按第一章规定的顺序传送。复杂的描述符的格式和传送如图2.15所示。
| 字节：1 |
可变长 |
… |
可变长 |
| 域计数器 |
域1 |
… |
域n |
图2.15复杂描述符的格式
包含在复杂标识符里的每一个域的格式如图2.16所示。
| 字节：1 |
可变长 |
| 压缩的XML标志 |
域数据 |
图2.16individual复杂描述符域的格式
2.3.2.1.1域计数器域
域计数器域长度为1字节，且规定包含在描述符里的域的数值，每一个格式描述如图。
2.3.2.1.1压缩的XML标志域
压缩的XML标志域长度为1字节，且规定当前域的XML标志。复杂标识符的压缩XML标志如表2.37所示。
2.3.2.1.1域数据域
域数据域是可变长且包含当前域的信息规定，如压缩XML标志域表明的。
2.3.2.2经由描述符发现
在ZDO管理实体设备中询问标识符信息，且使用ZigBee设备标识符请求原语的服务发现寻址到端点0。发现操作的详细描述见2.4.2.1节。信息通过ZigBee设备profile指示（indication）原语返回。
节点、节点电源、复杂和使用者标识符应用于完整节点。简单标识符必须为了每个被定义的端点在节点里而被规定。如果一个节点包含多个子组，这些将在孤立的端点上，且对于这些特殊的描述符通过在ZigBee设备profile里包含的相关的端点数来读取。
2.3.2.3复合设备（Composite Devices）
一个ZigBee节点包含分开的子组的数，每一个都有它自己的简单标识符。对于发现机制是在ZigBee设备profile发现部分描述。
2.3.4节点描述符
节点描述符包含ZigBee节点能力的信息，且对于每个节点都是必选的。在一个节点里仅仅有一个节点描述符。
节点描述符的域如表2.26所示，是按照传送的顺序。
表2.26节点描述符域
| 域名 |
长度（bit） |
| 逻辑类型 |
3 |
| 有效复杂描述符 |
1 |
| 有效使用者描述符 |
1 |
| 保留 |
3 |
| APS标志 |
3 |
| 频率组合（Frequency band） |
5 |
| MAC能力标志 |
8 |
| 生产商代码 |
16 |
| 最大缓冲值 |
8 |
| 最大转换值（Maximum transfer size） |
16 |
| 服务器MASK |
16 |
2.3.2.4.1逻辑类型域
节点的逻辑类型域是3个bit长，且规定ZigBee节点的设备类型，逻辑类型域设置为表2.27的一个非保留值。
表2.27逻辑类型域的值
| 逻辑类型域值b2b1b0 |
描述 |
| 000 |
ZigBee协调器 |
| 001 |
ZigBee路由器 |
| 010 |
ZigBee终端设备 |
| 011-111 |
保留 |
2.3.2.4.2有效复杂描述符域
节点描述符的有效复杂描述符域是1bit长，且规定一个复杂描述符在这个设备上是否有效。如果这个域设置为1，复杂描述符有效；如果这个域设置为0，复杂描述符无效。
2.3.2.4.3有效使用者描述符域
节点描述符的有效使用者描述符域是1bit长，且规定一个使用描述符在这个设备上是否有效。如果这个域设置为1，使用者描述符有效；如果这个域设置为0，使用者描述符无效。
2.3.2.4.4APS标志域
节点描述符的APS标志域是3bit长，且规定节点的应用支持子层的能力。
这个域是普遍的不维持且设置为0。（This field is currently not supported and shall be set to zero.）
2.3.2.4.5频率组合域
节点描述符的频率组合域是5bit长，且规定节点使用的IEEE802.15.4支持的频率组合。对每一个IEEE802.15.4支持的频率组合，频率组合域都有相应位，如表2.28所示，使用哪个频率组合相应位设置为1，其他位设置为0。
表2.28频率组合域的值
| 频率组合域位数 |
支持的频率组合 |
| 0 |
868- 868.6 MHz |
| 1 |
保留 |
| 2 |
902- 928 MHz |
| 3 |
2400 -2483.5 MHz |
| 4 |
保留 |
2.3.2.4.6MAC层能力标志域
MAC层能力标志域长度为8bit，且规定了节点的能力，是IEEE802.15.4MAC子层所要求的。MAC层能力标志域格式如图2.27所示。
| 比特：0 |
1 |
2 |
3 |
4-5 |
6 |
7 |
| 可选的PAN协调器 |
设备类型 |
电源源 |
空闲时接收机开 |
安全能力 |
分配地址 |
|
图2.17MAC层能力标志域格式
可选的PAN协调器子域长度是1位，且如果这个节点有成为PAN协调器的能力，该域设置为1。否则设置为0。
设备类型子域1位长，且如果这个节点是一个全功能设备（FFD），该域设置为1。否则设置为0，表明是一个简化功能设备（RFD）。
电源源子域长度是1位，且如果当前的电源源是主电源，该域设置为1。否则该域设置为0。这个信息是从节点电源（power）描述符的节点当前电源源域获得的。
空闲时接收机开子域长度是1位，且如果在空闲周期时设备使能它的接收机保存电源，该域设置为1。否则该域设置为0（参见2.3.2.5节）
安全能力子域长度是1位，且如果设备有使用【B1】规定的安全组使发送和接收帧安全的能力，该域设置为1。否则该域设置为0。
分配地址子域长度是1位，且总设置为1。
2.3.2.4.7生产商代码域
节点描述符生产商代码域长度是16位，且规定了一个由ZigBee联盟分配的生产商代码，与设备相关。
2.3.2.4.8最大缓冲值子域
节点描述符的最大缓冲域值长度8位，有效范围是0x00-0x7f，且规定了节点的应用支持子层（ASDU）的最大值，是以字节的方式。在分裂或者重新组合之前，这是要传输到应用层或者从应用层过来的数据或者命令的最大值。
这个域为了网络管理被作为高水平表示使用。
2.3.2.4.9最大转换值
节点描述符的最大转换值长度是16位，有效值范围是0x0000-0x7ffff，且以字节形式规定了转换到这个节点或从这个节点转换的最大值在一个单个消息转换里。这个值能超过节点最大缓冲值域的值（参见2.3.2.4.8）。
2.3.2.4.10服务Mask域
节点描述符的服务Mask域长度是16位，位设置表示这个节点的系统服务能力。系统里的其他节点使用这个使特殊系统服务发现便利。位设置如表2.29定义。
表2.29服务Mask位分配
| 位数 |
分配 |
| 0 |
主要信托中心 |
| 1 |
备份信托中心 |
| 2 |
主要绑定表高速缓冲存储器 |
| 3 |
备份绑定表高速缓冲存储器 |
| 4 |
主要发现高速缓冲存储器 |
| 5 |
备份发现高速缓冲存储器 |
| 6 |
网络管理 |
| 7-15 |
保留 |
2.3.2.5节点电源描述符
节点电源描述符给节点的电源状态一个动态表示，且对每一个节点都是必须有的。在一个节点里就只有一个节点电源描述符。
节点电源描述域如表2.30所示，按照传输的顺序。
表2.30节点电源描述域
| 域名 |
长度（bit） |
| 当前电源模式 |
4 |
| 有效的电源源 |
4 |
| 当前的电源源 |
4 |
| 当前电源源级别 |
4 |
2.3.2.5.1当前电源模式域
节点电源描述符的当前电源模式域长4位，且规定了节点的当前休眠/省电模式。当前节点模式域设置为表2.31所列的一个非保留值。
表2.31当前电源模式域的值
| 当前电源模式值b3b2b1b0 |
描述 |
| 0000 |
接收机与节点描述符的空闲时接收机开子域同步 |
| 0001 |
接收机如节点电源描述符定义的那样周期性的开始 |
| 0010 |
当有激励是接收机开，举例来说是使用者按下按钮 |
| 0011-1111 |
保留 |
2.3.2.5.2有效电源源域
节点描述符的有效电源源域长度4位，且规定了在这个节点的有效电源源。对于每个节点支持的电源源，有效的电源源域的相应的位如表2.32所列，设置为1，其他位设置为0。
表2.32有效电源源域的值
| 有效电源源域位数 |
支持的电源源 |
| 0 |
持续的电源（主要的）（Constant (mains) power） |
| 1 |
可充电电池 |
| 2 |
可任意使用的电池（Disposable battery） |
| 3 |
保留 |
2.3.2.5.3当前电源源域
节点描述符的当前电源源域长度4位，且规定节点使用的当前电源源。对于所选择当前电源源，当前电源源域相应的位如表2.23所列设置为1.其他位设置为0。
表2.23当前电源源域的值
| 当前电源源域位数 |
当前电源源 |
| 0 |
持续的电源（主要的）（Constant (mains) pow |
| 1 |
可充电电池 |
| 2 |
可任意使用的电池（Disposable battery） |
| 3 |
保留 |
2.3.2.5.4当前电源源级别域
节点描述符的当前电源源级别域长度4位，且规定了电源源负荷的级别。当前电源源域设置成表2.34所列的非保留值之一。
表2.34当前电源源级别域的值
| 当前电源源级别域b3b2b1b0 |
负荷水平 |
| 0000 |
危急的（Critical）没有电？？ |
| 0100 |
33% |
| 1000 |
66% |
| 1100 |
100% |
| 其他值 |
保留 |
2.3.2.6简单描述符
简单描述符包含节点里的每一个端点的特定信息。简单描述符在节点里存在的每一个端点是必选的。
简单描述符域如表2.35所示，是按照传输的顺序。这个描述符在整个空间进行传输，简单描述符的全部长度应小于等于maxCommandSize。
表2.35简单描述符域
| 域名 |
长度（bits） |
| 端点 |
8 |
| 应用profile标识符 |
16 |
| 应用设备标识符 |
16 |
| 应用设备版本 |
4 |
| 保留 |
4 |
| 应用输入簇计数器 |
8 |
| 应用输入簇列表器 |
16*i（i是应用输入簇计数器的值） |
| 应用输出簇计数器 |
8 |
| 应用输出簇列表器 |
16*o（o是应用输出簇计器的值） |
2.3.2.6.1端点域
简单描述符的端点域长度是8位，且规定在这个描述相关的节点里的端点。应用只用端点1-240。
2.3.2.6.2应用profile标识符域
简单描述符的应用profile标识符域长度是16位，且规定在这个端点上支持的profile。Profile标识符从ZigBee联盟处获得。
2.3.2.6.3应用设备标识符域
简单描述符的应用设备标识符域长度是16位，且规定在这个端点上支持的设备描述符。设备描述符从ZigBee联盟处获得。
2.3.2.6.4应用设备版本域
简单描述符的应用设备版本域长度是4位，且规定在这个端点上支持的设备描述符的版本。设备描述符的版本设置为表2.36所列的非保留值之一。
表2.36应用设备版本域的值
| 6应用设备版本域的值b3b2b1b0 |
描述 |
| 0000 |
版本1.0 |
| 0001-1111 |
保留 |
2.3.2.6.5应用输入簇计数器域
简单描述符的应用输入簇计数器域长度是8位，且规定在这个端点上支持的输入簇数，将出现在应用输入簇列表域。如果这个域的是0，应用输入列表域不被包含。
3.2.2.6.6应用输入簇列表
简单描述符的应用输入簇列表长度为16*i，i是应用输入簇计数器域的值，且规定了在这个端点上支持的输入列表，在绑定程序期间使用。
应用输入簇列表仅仅在输入簇计数器域的值大于0是才有。
2.3.2.6.7应用输出簇计数器域
简单描述符的应用输出簇计数器域长度是8位，且规定在这个端点上支持的输出簇数，将出现在应用输出簇列表域。如果这个域的是0，应用输出列表域不被包含。
3.2.2.6.6应用输出簇列表
简单描述符的应用输出簇列表长度为16*o，o是应用输出簇计数器域的值，且规定了在这个端点上支持的输出列表，在绑定程序期间使用。
应用输出簇列表仅仅在输出簇计数器域的值大于0是才有。
2.3.2.7复杂描述符
复杂描述包含在节点里的每一个复杂描述符的扩展信息。复杂描述的使用是可选的。
由于在这个描述符里的扩展的和复杂的特性，它使用压缩的XML标志以XML格式存在。描述符的每个域如表2.37所示，可以以任何顺序传输。作为这个标识符需要在整个空间传输，复杂描述符的全部长度应小于等于maxCommandSize。
表2.37复杂描述符域
| 域名 |
XML标志 |
复杂XML标志值b3b2b1b0 |
数据类型 |
| 保留 |
- |
0000 |
- |
| 语言和字符设置 |
<语言代码> |
0001 |
参见2.3.2.7.1 |
| 生产商名称 |
<生产商名称> |
0010 |
字符串 |
| 模型名称 |
<模型名称> |
0011 |
字符串 |
| 连续数 |
<连续数> |
0100 |
字符串 |
| 设备URL |
<设备URL > |
0101 |
字符串 |
| 图标（Icon） |
<图标> |
0110 |
字节串 |
| 图标URL |
<大纲 > |
0111 |
字符串 |
| 保留 |
- |
1000-1111 |
- |
2.3.2.7.1语言和特性设置域
语言和字符设置域是3字节长，且规定了在复杂描述符里的字符字节串使用的语言和字符设置。语言和字符设置域的格式如图2.18所示。
| 字节：2 |
1 |
| ISO639-1语言代码 |
字符设置标识符 |
图2.18语言和字符设置域格式
ISO639-1语言代码域是2字节长，且规定了为字符串使用的语言，如【B5】定义。
字符设置标识符子域长度是1字节，且规定了在字符设置里的字符使用的编码。这个子域设置为表2.38所列的非保留值之一。
表2.38字符设置标识符子域的值
| 字符设置标识符值 |
每个标识符的比特数 |
描述 |
| 0x00 |
8 |
ISO646，ASCII字符设置。每一个特性都适合一个字节的最没有意义的7 bit，带有最有意义bit设置为0（见【B6】）?? |
| 0x01-0xff |
- |
保留 |
如果语言和字符设置都没有规定，语言默认为英语（语言代码=“EN”）且字符设置为ISO 646。
2.3.2.7.2生产商名称域
生产商名称域是可变长，且包含字符串表明设备生产商的名称。
2.3.2.7.3模型名称域
模型名称域是可变长，且包含字符串表明设备生产商模型的名称。
2.3.2.7.4连续数域
连续数域是可变长，且包含字符串表明设备生产商连续数。
2.3.2.7.5设备URL域
设备URL是可变长，且包含字符串表明URL，通过它更多的关于设备的信息可以获得。
2.3.2.7.6图标域
图标域是可变长，且包含一个字节串，这个字节串携带一个图标数据，能表明在计算机、网关或者PDA上的设备。图标的格式是32*32像素的PNG图像。
2.3.2.7.7图标URL域
图标URL域是可变长，且包含字符串表明URL，通过它可以获得设备的图标。
2.3.2.8使用者标识符
使用者标识符包含允许使用者使用user-friendly字符标识符来识别设备的信息，这些字符串如“Bedroom TV”或者“Stairs light”。使用者标识符的使用是可选的。这个标识符包括一个单独的域，使用ASCII字符设置，且包含一个16个字符的最大值。
使用者标识符域如表2.39所示，按照它们传输的顺序。
表2.39使用者标识符域
| 域名 |
长度（字节） |
| 使用者标识符 |
16 |
2.3.3功能描述
2.3.3.1接受和拒绝
应用程序框架能通过APS子层的数据服务过滤到达的帧，且仅存在对在每个活动的（active）端点上执行的应用有影响的帧。
应用程序框架通过APSDEDATA.indication原语从APS子层接收数据，且被标定为一个特殊的端点（DstEndpoint参数）和一个特殊的profile（ProfileId参数）。
如果应用程序框架为一个不活动的端点接收一个帧，丢弃该帧。否则，应用程序框架应确定是否规定profile标识符与在规定的端点上执行的profile标识相匹配。如果profile标识符不匹配，那么应用程序框架拒绝该帧。反之，应用程序框架应传递接收到的帧的载荷到执行在规定端点的应用。
2.5ZigBee设备对象（ZDO）
2.5.1范围
本小节介绍在ZigBee应用支持子层和网络层顶端执行ZigBee设备对性应用需要的概念、结构和原语。
ZDO是使用网络和应用支持层原语执行ZigBee终端设备、路由器和协调器的一个应用。
ZDOProfile使用簇来描述它的原语。ZigBee设备Profile簇不使用属性，且同在消息传输协议里的消息类似。在ZigBee设备中使用簇标识符来列举在ZDO中使用的消息。
ZDO也使用配置属性。这些属性不是任何簇的元素。在ZDO中的配置属性是由应用或者是栈Profile设置的配置参数。虽然配置属性和ZigBee设备Profile都由ZDO来使用，但是配置属性和ZigBee设备Profile无关。
2.5.2设备对象描述
ZDO是应用解决方案，驻扎在ZigBee协议栈中的APL层和APS层之上，如图1.1所示。
ZDO有以下功能：
（1）初始化应用支持子层（APS），网络层（NWK），安全服务提供（SSP）和任何其他ZigBee设备层而不是驻扎在端点1-240的终端应用。
（2）从终端应用中集合配置信息来确定和执行下节描述的功能。
2.5.2.1最初的发现高速缓冲器设备操作（Primary Discovery Cache）
最初的发现高速缓冲器设备是通过设备的配置和在节点描述符里的advertisement来指定的。最初的发现高速缓冲器设备操作作为一个状态机，这个状态机是关于客户机希望使用最初的发现高速缓冲器。如下的状态和操作，如图2.99描述的，应被最初的发现高速缓冲器设备支持：
1.未发现的：
客户使用有限的半径广播到所有的RxOnWhenIdle设备消息Discovery Register请求来定位在请求提供的半径范围内的Primary Discovery Cache设备
2. 发现的：
客户使用单播发现高速缓存器请求，这个请求是定向到Discovery Cache设备，这个设备白含它愿意存储的发现高速缓存器信息的大小。Discovery Cache Device将响应，参数是SUCCESS或者TABLE_FULL。
3.已注册的：
当客户从Discovery Cache设备接收到SUCCESS状态，这个状态就从先前的Discovery Cache请求处到达。客户现在必须使用节点描述符（NodeDescriptor）存储请求、电源描述符存储请求、活动的端点存储请求和简单描述符存储请求上载它的发现信息来激活Primary Discovery Cache设备为了它自己的利益来充分的响应。
4.未注册的：
客户（或任何其他设备）也许请求不被注册。移动节点高速缓存器（Remove Node Cache）请求移动设备从Primary Discovery Cache设备。
Primary Discovery Cache设备响应设备和它支持的所有注册的客户的服务发现请求。Find Node Cache请求被想定位设备和为了已给设备的服务发现请求的客户使用。注意如果发现信息被设备本身保持，设备也必须响应来确认它自己作为发现信息的储藏。见图2.99为状态机处理Primary Discovery Cache设备的详细信息。
2.5.2.2设备和服务发现
在一个单独的PAN里，这个功能将支持设备和服务发现。另外，对于ZigBee协调器、ZigBee路由器和ZigBee终端设备类型，这个功能将做如下处理：
（1）在每一使用休眠的ZigBee终端设备、ZigBee路由器（或ZigBee协调器）的网络，必须被设计作为如它们的节点描述符描述的Primary Discovery Cache Devices。这些Primary Cache Devices 是它们自己可发现的，且提供服务器服务来上载和存储代表休眠的ZigBee终端设备的发现信息。另外Primary Cache Devices响应代表休眠Zigbee]终端设备的发现请求。每一个Primary Discovery Cache Device是ZigBee路由器或者ZigBee协调器。
（2）对于被:Config_Node_Power,设备和服务发现指示想要休眠的ZigBee终端设备将管理被ZigBee终端设备选择的Primary Discovery Cache设备上的网络地址、IEEE地址、活动节点、简单描述符、节点描述符和电源描述符的上载和存储来允许在这些休眠设备上的设备和服务发现操作。
（3）对于被设计作为Primary Discovery Cache Device的ZigBee协调器和ZigBee路由器，这个功能将代表休眠ZigBee终端设备响应发现请求，这些终端设备已经注册和上载了它们的发现信息。
（4）对于所有的ZigBee设备、设备和服务发现将支持设备和从其他设备过过来的服务发现请求，且允许从其他本地的应用对象过来的请求的产生。注意设备和服务发现服务是由Primary Discovery Cache设备代表其他ZigBee终端设备提供的。万一Primary Discovery Cache Device是请求的目标，那么NWKAddrOfInterest或者Interest域的设备将被请求和/或响应填满来区分从设备来的请求的目标，这个设备是发现的目标。将支持下边的发现特性：
（1）设备发现：
——以ZigBee协调器或者路由器IEEE地址的一个单播询问为基础，被请求设备的IEEE地址，随机的，所有联合设备的网络地址将被返回。
——以ZigBee终端设备的IEEE地址的一个单播询问为基础，被请求的设备的IEEE地址被返回。
——以ZigBee协调器或者带有一个已经提供的IEEE地址的路由器网络地址的一个多播询问（任何广播地址类型）为基础，被请求的设备的网络地址，随机的，所有联合设备的网络地址将被返回。
——以带有已经提供的IEEE地址的ZigBee终端设备的网络地址的广播查询（任何广播地址类型）为基础。被请求设备的网络地址被返回。响应的设备将使用APS层为单播响应已知的服务来广播查询。
（2）服务发现：以如下的输入为基础，相应的响应被提供：
——网络层地址加上（plus）活动的端点查询类型——指定设备将返回在那个设备里的所有应用的端点数。
——网络层地址或广播地址（任何广播地址类型）加上服务匹配，这些匹配包括Profile ID和随意的，输入和输出簇——指定的设备匹配带有所有活动的端点的Profile ID来确定一个匹配。如果没有输入或者输出簇被规定，匹配请求的端点被返回。如果那些匹配的输入和/或输出簇在请求里被提供，且任何匹配在带有提供匹配的设备上的端点列表的响应里被提供。响应的设备应该使用APS层已知的服务，这服务是为了单播响应到广播查询的。万一应用profiles想列举输入簇和它们的带有相同簇标识符的响应输出簇，应用profile将仅仅在为服务发现目的的简单标识符里列出输入簇。在这些情况下它将被采用，应用profile提供关于输入和响应输出的簇标识符的使用的细节。
——网络层地址加上节点标识符或标识符查询类型——指定的地址将为设备返回联合端点的简单标识符。
——随意的，网络层地址加上复杂或者使用者标识符查询类型——如果支持，指定的地址将为设备返回复杂或者使用者标识符。
2.5.2.3安全管理
这个功能确定是否使能安全，如果使能，将做如下处理：
建立钥匙
传输钥匙
请求钥匙
更新设备
移动设备
转换钥匙
安全管理功能按安全服务规范执行。安全管理由ZDO发出APSME原语来执行，步骤如下:
与信托中心通信（假定是ZigBee协调器）来获得Master Key，在设备和信托中心之间（如果设备是ZigBee协调器或者信托中心的Master Key被重新分配这一步忽略）。这一步使用传输钥匙原语。
与信托中心建立一个Link Key。这一步使用APSMEEstablish-Key原语。
从信托中心获得网络钥匙使用安全的通信与信托中心。这一步使用APSME-TRANSPORT-KEY原语。
作为必须的，建立Link Key和Master Key与在网络中被确定为消息的目的的指定的设备。这步使用APSMEESTABLISH-KEY和/或APSME-REQUEST-KEY原语。
使用APSMEDEVICE-UPDATE通知任何一个设备的信托中心连接网络。这个功能只有设备是ZigBee路由器时才执行。
允许设备使用APSMEREQUEST-KEY原语从信托中心获得钥匙。
允许信托中心从网络中移动设备，使用APSME-REMOVE-DEVICE原语。
允许信托中心转换active的网络钥匙，使用APSMESWITCH-KEY原语。
2.5.2.4网络管理
这个功能将执行ZigBee协调器、ZigBee路由器或者ZigBee终端设备逻辑设备类型根据已确定的配置设置，通过程序应用或者在安装期间。如果设备类型是一个ZigBee协调器或者Zigbee终端设备，这个功能将提供选择一个存在的PAN来加入和如果网络通信断开执行允许设备重新加入的程序的能力。如果设备类型是ZigBee协调器或者是Zigbee路由器，这个功能将提供为一个新的PAN建立选择一个未用的信道。注意在没有一个设备是预先指定为协调器的情况下，配置一个网络是可能的，这时，第一个全功能设备（FFD）被确定为ZigBee协调器的角色。网络管理做如下处理：
允许为网络信道列表的规定扫描程序。缺省值是规定在已选择的操作联合的所有信道的使用。
管理网络扫描程序来确定邻居网络和它们协调器和路由器的一致性。
允许一个信道的选择来启动一个PAN（ZigBee协调器）或者一个存在的PAN的选择来连接（ZigBee路由器或者Zigbee终端设备）。
支持孤点和扩展的程序来重新连接网络，包括支持可携带的内部PAN。
也许支持直接连接。对于ZigBee协调器和ZigBee路由器，直接连接的一个本地版本被支持来使能设备通过孤点或者重新连接流程来加入网络。
2.5.2.5绑定管理
绑定管理执行下列任务：
为绑定表建立一个资源值。这个资源值是通过程序应用或通过一个在安装期间定义的配置参数确定的。
从APS绑定表增加或者减少实体处理绑定请求。
从外部应用支持绑定和解绑定命令，如那些是主机在一个PDA上来支持协助绑定。绑定和解绑定命令将通过ZigBee设备Profile（见2.4节）被支持。
对于ZigBee协调器，支持终端设备绑定，这绑定允许以按钮按压或其他手动菜单为基础的绑定。
2.5.2.6节点管理
对于Zigbee协调器和路由器，节点管理功能执行以下步骤：
允许遥控操作命令来执行网络发现
提供遥控操作命令来重新获得路由表
提供遥控操作命令来重新获得绑定表
提供一个遥控操作命令来使一个设备离开网络或者是命令另一个设备离开网络
提供一个遥控操作命令来重新获得LQI，是为这个遥远的设备的邻居获得的。
允许源设备向一个初始化绑定表高速缓冲寄存器登记的能力来保持他们自己绑定表
允许配置工具把一个设备换成另一个设备，这个设备是在所有的绑定表入口中，这个入口涉及到他。
允许初始化绑定表高速缓冲寄存器备份和恢复个人绑定入口或者入口绑定表或者保持他们自己绑定表的源设备的表
提供一个遥控操作命令来允许或者禁止连接一个特殊的路由器；或者通常允许或者禁止通过信托中心连接
2.5.3层接口描述
不像对于应用居住的上述的端点1-240的其他设备描述，Zigbee设备对象（ZDO）接口除了APSDE-SAP之外，通过APSME-SAP到APS，通过NLME-SAP到NWK。ZDO在端点0上通信像所有其他应用一样通过Profiles使用APSDE-SAP。ZDO使用的Profile是ZigBee 设备Profile（见2.4节）
2.5.4系统使用方法
标题在协议版本发布的图表的同一页。
2.5.5对象定义和行为
2.5.5.1对象概述
ZigBee设备对象包括五个对象：
设备和服务发现
网络管理
绑定管理
安全管理
节点管理
表2.132描述这些ZigBee设备对象
表2.132 ZigBee设备对象
| 对象 |
描述 |
|
| 名称 |
状态 |
|
| :Device_and_Service_Discovery |
M |
处理设备和安全发现 |
| :Network_Manager |
M |
处理网络行为，如网络发现，断开/加入网络，重新设置一个网络连接和建立一个网络 |
| :Binding_Manager |
O |
处理终端设备绑定，绑定和解绑行为 |
| :Security_Manager |
O |
处理安全服务，如钥匙装载，钥匙建立，钥匙传输和认证 |
| :Node_Manager |
O |
处理操作功能 |
2.5.5.2可选的和强制的对象和属性
作为强制的列出的对象将在所有ZigBee设备中存在。然而，对于确定的ZigBee逻辑类型，对于所有ZigBee设备作为可选的列出的对象对于特殊的逻辑设备类型也许是强制的。例如，在网络管理对象中的NLMENETWORK-FORMATION.request原语是强制对象且是可选属性，尽管对于Zigbee协调器逻辑设备类型属性是必需的。每一个设备类型部分的介绍将详细说明逻辑设备类型的对象和属性支持的必要条件。
2.5.5.3安全钥匙使用方法
ZigBee设备对象也许为了由ZigBee设备Profile原语建立的数据包使用安全。这些在端点使用APSDE的应用数据包将使用网络钥匙，不使用个人连接钥匙。
2.5.5.4公共的和私人的方法
能够到达设备的任何端点应用的方法叫做公共方法。私人方法是仅仅可以到达端点0的设备应用，且不是到达终端设备（运行在端点1到240）
2.5.5.5状态机功能描述
2.5.5.5.1ZigBee协调器
2.5.5.5.1.1初始化
在执行中应该安排供应（Provision）来提供期望网络配置参数（:Config_NWK_Mode_and_Params）的一个单独复制到ZigBee设备对象的网络对象。另外，安排供应来提供配置元素来描述节点描述符，电源描述符，简单描述符为每一个活动的端点，和应用加上活动端点的列举。？？？这些配置将包括在:Config_Node_Descriptor,:Config_Power_Descriptor 和 :Config_Simple_Descriptors里，如果:Config_Node_Descriptor配置对象表明这个设备是Primary Discovery Cache设备，那么这个设备将被配置成处理服务器命令，是为了联合请求Primary Discovery Cache 的ZigBee设备Profile。且将会根据2.5.2.1节提供的状态机描述符来处理。
如果支持，将安排供应为复杂描述符，使用者描述符，绑定入口最大值和master key 提供配置元素。这些元素将包含在:Config_Complex_Descriptor，:Config_User_Descriptor，:Config_Max_Bind 和:Config_Master_Key里。
设备应用使用NLME-NETWORK-DISCOVERY.request原语，其中:Config NWK Mode and Params的ChannelList部分能扫描指定的信道。作为结果的NLME-NETWORK-DISCOVERY.confirm原语将提供一个网络清单，这个网络清单详细描述了在这个范围内的活动的PANs。设备应用将比较信道清单和网络清单，且选择一个未使用过的信道。
未使用信道选择的运算法则的规定将留给工具（implementer？）。一旦未使用的信道被确定，设备应用将设置nwkSecurityLevel和nwkSecureAllFrames的NIB属性，是根据设备使用的堆栈Profile里的规定建立的值来设置的。它将使用NLME-NETWORK-FORMATION.request原语，原语使用在:Config NWK Mode and Params规定的参数来建立一个PAN在那个信道。在nwkExtendedPANID里，扩展的PANID域将被设置。设备应用将通过NLME-NETWORK-FORMATION.confirm原语来核对返回的状态来检查PAN的成功建立。:Config_Permit_Join_Duration将根据使用NLME-PERMIT-JOINING.request原语提供的缺省参数值来设置。另外， nwkNetworkBroadcastDeliveryTime和nwkTransactionPersistenceTime网络信息块参数将分别的设置为with :Config NWK BroadcastDeliveryTime 和:Config NWK TransactionPersistenceTime（参见第三章）
应该安排供应来确保从端点0到240的终端设备的APS原语命令返回合适的错误状态值，是在ZigBee设备对象的初始化状态完成之前，且转换正常的操作状态。
2.5.5.1.2正常的操作状态
在这个状态中，Zigbee协调器将处理直接连接地址清单，是在:Config_NWK_Join_Direct_Addrs里，通过为每个仔清单里包含的地址产生NLME-DIRECTJOIN.request原语。直接连接地址处理过程将使用:Config_Max_Assoc参数来测试在:Config_NWK_Join_Direct_Addrs里是否成功处理直接连接地址。
ZigBee协调器将响应任何的设备发现或者服务发现操作，是由它自己设备请求的，且如果他被指定作为一个Primary Discovery Cache设备，也将代表注册的设备响应，这些设备已经存储了发现信息。设备应用将确保绑定入口数不超过:Config_Max_Bind属性。
ZigBee协调器将支持NLME-PERMIT-JOINING.request原语和NLME-PERMIT-JOINING.confirm原语允许网络连接处理的应用控制。
ZigBee协调器将支持NLME-LEAVE.request和NLMELEAVE.indication原语，原语使用:Config_NWK_Leave_removeChildren属性，在这个属性里适当允许在应用控制下的联合设备的移除。导致移除的条件也许包括缺少安全信任，设备的移除是通过一个有特权的应用或者是例外的发现。
ZigBee协调器应包含当前联合的设备的清单，且方便了孤点扫描的支持，并且重新连接处理使能先前的联合设备来重新连接到网络。ZigBee协调器也许为设备维持直接包含在网络中的能力，是通过NLME-DIRECTJOIN.request和NLME-DIRECT-JOIN.confirm原语。这个特性应允许ZigBee IEEE 地址清单被提供给Zigbee协调器，因为那些地址被包含作为先前的联合设备。对于由这些地址的ZigBee设备通过孤点或者重新连接程序而不是联合的直接的连接到网络是可能的。
ZigBee协调器应处理End_Device_Bind_req从ZigBee路由器和终端设备。一旦接收到一个End_Device_Bind_req，ZigBee协调器将使用属性中的:Config_EndDev_Bind_Timeout的值，且等待第二个End_Device_Bind_req的到来。第二个指示在timeout期间到达，ZigBee协调器将在两个指示之间匹配Profile ID。如果在两个指示中的Profile IDs不匹配，一个适当的错误状态将通过End_Device_Bind_req返回到每个设备，。如果Profile IDs匹配，ZigBee协调器将匹配两个指示里的AppInClusterLists和AppOutClusterLists。第一个指示的AppInClusterLists的Cluster IDs和第二个指示里的AppOutClusterLists的Cluster IDs匹配将被保存在一个清单里为指示End_Device_Bind_req。
ZigBee协调器将处理从其它ZigBee设备来的Device_annce信息。一旦接收到Device_annce，ZigBee协调器将检查所有的内部表，这些内部表是为PAN中设备维持64位IEEE地址为了与在Device_annce信息中提供的地址相匹配。如果匹配存在，ZigBee协调器将根据匹配的64位IEEE地址更新它的nwkAddressMapNIB属性来反映包含在Device_annce中的更新的16位网络地址。
2.5.5.5.1.3信托中心操作
当网络中安全使能时，ZigBee协调器将行使一个信托中心的功能。
信托中心被网络中的新设备通知，是通过APSMEDEVICE-UPDATE .indication原语。信托中心也能选择允许设备保持在网络中或者是强迫他离开网络，是通过APSMEREMOVE-
DEVICE.request原语。这个选择是使用网络控制原则制定的，是在这个协议范围外的。
如果信托中心决定允许设备保持在网络中，他将和设备建立一个master key，是通过APSME-TRANSPORTKEY.request原语，除非master key已经在两个设备中可用，且信托中心使用out-of-band机制来保证安全和认证。一旦交换了master key，信托中心将使用APSMEESTABLISH-KEY.request原语与设备建立一个link key，且将使用APSME-ESTABLISHKEY.response原语相应link key建立的请求。
信托中心将提供给设备网络钥匙，是通过使用APSMETRANSPORT-KEY.request.原语。一旦通过APSME-REQUEST-KEY.indication原语从设备接收到一个请求，他将提供网络钥匙。
信托中心再任何两个设备间将支持link keys的建立，是通过提供给他们一个共同的钥匙。一旦接收到APSMEREQUEST-KEY.indication原语请求一个应用钥匙，信托中心将建立一个master key或者link key，并且使用the APSMETRANSPORT-KEY.request.原语传输它到两个设备。
信托中心将周期性的更新网络钥匙，是根据一个原则，这个原则的详细内容在本协议范围外。网络中的所有设备将被更新新的网络钥匙，是通过APSME-TRANSPORT-KEY.request原语。
2.5.5.5.2ZigBee路由器
2.5.5.5.2.1初始化
在执行中应该安排供应（Provision）来提供期望网络配置参数（:Config_NWK_Mode_and_Params）的一个单独复制到ZigBee设备对象的网络对象。如果:Config_Node_Descriptor配置对象表明这个设备是Primary Discovery Cache设备，设备将被配置成处理服务器命令为联合了请求Primary Discovery Cache的ZigBee设备Profile，且将根据2.5.2.1节提供的状态机描述来操作。
如果支持，将安排作为复杂描述符，使用者使用描述符，为绑定入口最大值和master key提供配置元素。这些元素将被包含在:Config_Complex_Descriptor, :Config_User_Descriptor,以及:Config_Max_Bind 和:Config_Master_Key里。
设备应用将使用带有:Config_NWK_Mode_and_Params的ChannelList选项的NLME-NETWORK-DISCOVERY.request原语，然后使用NLME-NETWORK-DISCOVERY.
request原语属性来扫描特殊的信道。
作为结果的NLME-NETWORK-DISCOVERY.confirm原语将提供一个详细描述在那个范围内的活跃的PANs的网络清单（NetworkList）。NLME-NETWORKDISCOVERY.request程序将被:Config_NWK_Scan_Attempts执行，每一个被:Config_NWK_Time_btwn_Scans及时的分离。重复NLMENETWORK-DISCOVERY.request原语的目的是提供一个更正确的邻居列表和到网络层的联合的连接质量指示。设备应用将比较信道清单（ChannelList）和网络清单（NetworkList），且选择一个存在的PAN来连接。PAN选择的运算法则的规范将留给profile 描述，而且也许包含扩展的PAN ID。
3.1网络层状态值
网络层确认原语通常都包括一个参数，这个参数记录回答请求原语的状态。网络层状态参数值如表3.1所示。
表3.1
| 名称 |
值 |
描述 |
| SUCCESS |
0x00 |
请求执行成功 |
| INVALID_PARAMETER |
0xc1 |
从高层发出的原语无效或者超出范围 |
| INVALID_REQUEST |
0xc2 |
考虑到网络层目前的状态，高层发送的请求原语无效或者不能执行 |
| NOT_PERMITTED |
0xc3 |
NLME-JOIN.request原语不被接受 |
| STARTUP_FAILURE |
0xc4 |
NLME-NETWORK-FORMATION.request原语启动网络失败 |
| ALREADY_PRESENT |
0xc5 |
产生NLMEDIRECT-JOIN.request原语的设备的邻居表中已经存在有地址设备提供的NLMEDIRECT-JOIN.request原语 |
| SYNC_FAILURE |
0xc6 |
用来表明在MAC层NLME-SYNC.request原语失败 |
| NEIGHBOR_TABLE_FULL |
0xc7 |
NLME-JOIN-DIRECTLY.reques失败，因为邻居表没有更多的空间 |
| UNKNOWN_DEVICE |
0xc8 |
NLME-LEAVE.request原语失败，因为产生原语的设备地址不在邻居表中的参数列表中 |
| UNSUPPORTED_ATTRIBUTE |
0xc9 |
NLME-GET.request or NLME-SET.request原语产生带有未知的属性标识符 |
| NO_NETWORKS |
0xca |
没有检测到网络环境产生NLME-JOIN.request原语 |
| LEAVE_UNCONFIRMED |
0xcb |
设备确认从网络出发失败 |
| MAX_FRM_CNTR |
0xcc |
因为帧计数器达到最大值，所以输出帧安全处理失败 |
| NO_KEY |
0xcd |
输出帧尝试安全处理且失败，因为对于处理没有有效的钥匙 |
| BAD_CCM_OUTPUT |
0xce |
输出帧尝试安全处理且失败，因为安全设计产生一个错误的输出 |
| NO_ROUTING CAPACITY |
0xcf |
由于缺少路由表或者发现路由表能力，尝试发现路由失败 |
| ROUTE_DISCOVERY_FAILED |
0xd0 |
尝试发现路由失败，由于缺少路由能力 |
| ROUTE_ERROR |
0xd1 |
由于发送设备的路由失败，NLDE-DATA.request原语失败 |
| BT_TABLE_FULL |
0xd2 |
由于没有足够的空间在BTT，尝试发送一个广播帧或成员模式多点传送失败 |
| FRAME_NOT_BUFFERED |
0xd3 |
一个非成员多点传送帧丢弃未决路由发现 |
3.2概况描述
3.2.1网络层概述
ZigBee网络层的主要功能就是提供一些必要的函数，确保ZIgBee的MAC层（IEEE 802.15.4-2003）正常工作，并且为应用层提供合适的服务接口。为了向应用层提供其接口，网络层提供了两个必须的功能服务实体，它们分别为数据服务实体和管理服务实体。网络层数据实体（NLDE）通过网络层数据服务实体服务接入点（NLDE-SAP）提供数据传输服务，网络层管理实体（NLME）通过网络层管理实体服务接入点（NLME-SAP）提供网络管理服务。网络层管理实体利用网络层数据实体完成一些网络的管理工作，并且，网络层管理实体完成对网络信息库（NIB）的维护和管理，下面分别对它们的功能进行介绍。
3.2.1.1网络层数据实体（NLDE）
网络层数据实体为数据提供服务，在连个或者更多的设备之间传送数据时，将按照应用协议数据单元（APDU）的格式进行传送，并且这些设备必须在同一个网络中，即在同一个内部个域网中。
网络层数据实体提供如下服务：
（1） 生成网络层协议数据单元（NPDU）：网络层数据实体通过增加一个适当的协议头，从应用支持层协议数据单元中生成网络层的协议数据单元。
（2） 指定拓扑传输路由，网络层数据实体能够发送一个网络层的协议数据单元到一个合适的设备，该设备可能是最终目的通信设备，也可能是在通信链路中的一个中间通信设备。
（3） 安全：确保通信的真实性和机密性。
3.2.1.2网络层管理实体（NLME）
网络层管理实体提供网络管理服务，允许应用与堆栈相互作用。网络层管理实体应该提供如下服务：
（1） 配置一个新的设备：为保证设备正常工作的需要，设备应具有足够的堆栈，以满足配置的需要。配置选项包括对一个ZigBee协调器或者连接一个现有网络设备的初始化的操作。
（2） 初始化一个网络：使之具有建立一个新网络的能力。
（3） 连接和断开网络。具有连接或者断开一个网络的能力，以及为建立一个ZigBee协调器或者路由器，具有要求设备同网络断开的能力。
（4） 寻址：ZigBee协调器和路由器具有为新加入网络的设备分配地址的能力。
（5） 邻居设备发现：具有发现、记录和汇报有关一跳邻居设备信息的能力。
（6） 路由发现：具有发现和记录有效地传送信息的网络路由的能力。
（7） 接收控制：具有控制设备接收状态的能力，即控制接收机什么时间接收、接收时间的长短，以保证MAC层的同步或正正常接收等。
3.3 网络层服务协议
图3.1给出了网络层各组成部分和接口。
网络层通过两种服务接入点提供响应的两种服务。它们分别是网络层数据服务和网络层管理服务。网络层数据服务通过网络层数据实体服务接入点接入，网络层管理服务通过网络层管理实体服务接入点接入。这两种服务通过MCPS-SAP和MLME-SPA接口为MAC层提供接口。除此之外，在NLME和NLDE间还有一个接口使得NLME可以使用网络层数据服务。
3.3.1网络层数据服务
网络层数据实体服务接入点支持对等应用实体之间的应用协议数据单元的传输。表3.2列出了网络层数据实体服务接入点支持的原语，下面小节就是对这些原语的讨论。
3.3.1.1 NLDE-DATA.request 原语
该原语请求从本地应用支持层实体到单个或者多个对等的应用支持层实体的协议数据单元传输。
3.3.1.1.1 服务原语的语法
该服务原语的语法如下所示：
表3.3描述了NLDE-DATA.request函数原语的参数
3.3.1.1.2 产生
当一个NSDU要传送到一个对等的应用支持层实体时，本地应用支持层实体就会生成该原语。
3.3.1.1.3 接收
当一个不与网络连接的设备接收到该原语时，该设备网络层将发出一个状态参数为INVALID-REQUEST的NLDE-DATA.confirm原语。
网络层数据实体在接受到该原语时，为传送NSDU包，需要构造一个NPDU包。在处理过程中，如果网络层数据实体在发送NSDU包之前，先发送了NLDE-DATA.cindirm原语，则将发起所有的后续处理。在构造新的NPDU过程中，网络层头的目的地址域设置为参数DstAddr所提供的值，源地址域设置为MAC PIB中属性macShortAddress的值。网络层帧头帧控制域中的路由发现域设置为DiscoverRoute参数的值。如果提供的Radius参数不为0，那么它将设置在网络层帧头的radius域，如果值为0，那么网络层帧头中的radius域设置NWK IB中nwkMaxDepth属性值的二倍。网络层将会生成一个如3.7.2.1小节所描述的系列号。这个序列号可以插入到网络层帧头的sequence number域。帧头的多点发送标志位将根据DstAddrMode的值设置。如果DstAddrMode的参数值为0x01，网络层帧头将包含multicast control域，该域的设置如下：
（1） 如果该节点是DstAddr参数所包含的节点，那么multicast mode域置为0x01
（2） 否则，multicast mode域设为0x00
（3） non-member radius和max non-member radius域按照NonmemberRadius的值设置
一旦构造好NSDU包，如果是单播，将按照3.7.3.3小节所描述的过程为NSDU包确定传输路由；如果是广播，则参见3.7.4小节；如果是多点通信，则参见3.7.5.2小节。当确定了NSDU包传输路由后，通过MCPS-DATA.request原语来发送NSDU包，在该原语中参数SrcAddrMode 和 DstAddrMode都设置为0x02，表明适应16位的网络地址。参数SrcPANId 和 DstPANId应设置为MAC PIB中的macPANId值。SrcAddr参数值设置为MAC PIB中的macShortAddr值。DstAddr参数值为由路由程序所决定的下一跳地址。当TxOptions与0x01相与时，该参数值应为非零值，表示发送需要确认。在接收到MCPS-DATA.confirm原语时，网络层数据试题发送NLDE-DATA.confirm原语，该原语中的参数状态为MAC层所接收到的状态。
如果在网络层信息数据库（NIB）中所确定的网络安全级别标准为一个非零值，并且SecurityEnable值为TRUE，则在帧发送之前，按照4.4小节所描述对帧进行安全处理。否则，网络层不对该帧进行安全处理。如果安全处理已经进行了，但是由于某些原因而失败了，那么，将丢弃该帧，并且网络层数据实体将发送NLDE-DATA.confirm原语，该原语的状态参数为安全方案所返回的值。
3.3.1.2 NLDE-DATA.confirm 原语
该原语提供了从本地应用支持层实体到一个对等应用支持成实体传送NSDU包请求原语的结果。
3.3.1.2.1 服务原语的语法
该原语的语法如下所示：
表3.4详细描述了NLDE-DATA.confirm原语的参数。
3.3.1.2.2 产生
该原语为本地网络层数据实体对接收到NLDE-DATA.request原语而产生的响应。
Status域将反映相应的请求结果，详见3.3.1.2.3小节。
3.3.1.2.3 接收
接收到该原语，开始设备的APS子层将被通知传输请求的结果。如果传输成功了，那么status参数为SUCCESS。否则，status参数表明传输的错误。
3.3.1.3 NLDE-DATA.indication原语
该原语表示一个NSDU包从网络层到本地应用支持层实体的传送。
3.3.1.3.1 服务原语的语法
该原语的语法如下：
表3.5描述了NLDE-DATA.request原语的参数。
3.3.1.3.2 产生
当本地MAC层实体接收到一个适当地址的数据帧时，就生成该原语，并发送给应用支持层。
3.3.1.3.3 接收
当应用支持层接收到该原语时，则被通知一个数据帧到达设备，就可得到设备所接收的数据。
3.3.1.3.4 网络管理服务
网络层管理实体服务接入点为其上层和网络层管理实体之间传送管理命令提供接口。表3.6列出了NLME所支持的NLME-SPA原语，下面的小节详细介绍了这些原语。
3.3.2网络发现
网络层管理实体服务接入点支持运行网络的发现。采用NLME-NETWORK-DISCOVERY原语来发现网络。
3.3.2.1 NLME-NETWORK-DISCOVERY.request原语
该原语支持网络层上层应用该原语来发现在POS范围内正在运行的网络。
3.3.2.1.1 服务原语的语法
该原语的语法如下：
表3.7详细描述了NLME-NETWORK-DISCOVERY.request原语的参数。
3.3.2.1.2 产生
该原语由ZigBee设备网络层上层产生，发送给它的网络层管理实体，请求网络层发现当前在POS正在运行的网络。
3.3.2.1.3 接收
网络层在接收到该原语后，将通过检查ScanChannels参数确定的信道以及ScanDuration参数所确定的扫描时间，发现在POS中正在运行的网络。通过MLME-SCAN.request原语进行扫描。
在接收到MLME-SCAN.confirm原语后，网络层管理实体发送NLMENETWORK-
DISCOVERY.confirm原语，其原语参数为发现网络信息以及随MLME-SCAN.confirm原语返回的状态参数值。
3.3.2.2 NLME-NETWORK-DISCOVERY.confirm 原语
该原语返回网络发现操作的结果。
3.3.2.2.1 服务原语的语法
该原语的语法如下：
表3.8详细描述了NLME-NETWORK-DISCOVERY.confirm原语的参数。
表3.9给出了NetworkDescriptor参数中网络描述符所包含的具体内容。
3.3.2.2.2 产生
当NLME-NETWORK-DISCOVERY.request原语执行完成后，网络层管理实体生成该原语，并发送给网络上层。
3.3.2.2.3 接收
其上层接收到该原语后，就可得到网络的搜索结果。
3.3.3网络的形成
本小节原语定义了一个设备的应用层如何初始化，使其自身成为一个新的ZigBee网络协调器。
3.3.3.1 NLME-NETWORK-FORMATION.request 原语
该原语允许高层使用该原语请求设备发起一个新的ZigBee网络。并将其自身作为ZigBee协调器。
3.3.3.1.1 服务原语的语法
该原语的语法如下：
表3.10详细描述了NLME-NETWORK-FORMATION.request原语的参数。
3.3.3.1.2 产生
该原语由具有ZigBee协调器能力设备的应用层生成，发送给它的网络层管理实体，请求初始化设备，使之成为一个新网络的协调器。
3.3.3.1.3 接收
在网络中，当一个没有ZigBee协调器能力的设备接收到该原语时，网络层管理实体就会返回状态参数为INVALID-REQUEST的NLME-NETWORK-FORMATION.confirm原语。
如果设备被初始化为ZigBee协调器，网络层管理实体请求MAC层首先执行一个能量检测扫描，然后在所指定的信道上执行主动扫描。为了执行扫描任务，网络层管理实体将向MAC发送ScanType参数设置为能量检测扫描的MLME-SCAN.request原语；然后，再发送ScanType为主动扫描的MLME-SCAN.request原语。在主动扫描完成以后，网络层管理实体从MAC层接收到MLME-SCAN.confirm原语，并且选择一个合适的信道。网络层将选择一个个域网标识符，并且确保其不会与所选择信道的现有网络个域网标识符参数产生冲突。一旦合适的信道和个域网标识符PANId确定后，网络层管理实体将选择0x0000作为16位的短MAC地址，并且告知MAC层。为了实现该目的，网络层管理实体将向MAC层大宋MLME-SET.request原语来设置MAC PIB中的macShortAddress属性。如果NIB中的属性nwkExtendedPANId值为0x0000000000000000，那么该属性将被设置为MAC层的aExtendedAddress值。如果不能找到合适的信道和个域网标识符PANId，网络层管理实体将会发出状态参数为START_FAILURE的NLME-NETWORK-FORMATION.confirm原语。
如果在上层的请求中只提供了一个信道，那么网络层管理实体在开始形成网络前不需要进行能量检测扫描。主动扫描仍需要进行，确保所选择的个域网标识符不与现有网络中的标识符发生冲突。
开始一个新的网络，网络层管理实体向MAC层发送MLME-START.request原语。MLME-START.request原语的PANCoordinator参数设置为TRUE。MLME-START.request原语中的BeaconOrder和SuperframeOrder参数都设置为15，表明没有超帧信标。MLME-START.request中的参数CoordRealignment设置为False。在接收到相应的MLME-START.confirm原语时，网络层管路实体将会向其上层发送NLME-NETWORK-FORMATION.confirm原语，其中的状态参数为MLME-START.confirm原语所返回的状态参数值。
3.3.3.2 NLME-NETWORK-FORMATION.confirm 原语
该原语返回在网络中初始化一个ZigBee协调器请求的执行结果。
3.3.3.2.1 服务原语的语法
该原语的语法如下：
表3.11详细描述了NLME-NETWORK-FORMATION.confirm原语的参数。
3.3.3.2.2 产生
该原语由网络层管理实体生成，作为对NLME-NETWORK-FORMATION.request原语的响应，发送给其上层。该原语返回的状态为INVALID_REQUEST、STARTUP_FAILURE或者MLME-START.confirm原语所返回的状态。3.3.3.1.3描述了在那些条件下返回这些值。
3.3.3.2.3 接收
接收到该原语，上层就可得知初始化一个ZigBee协调器的执行结果。如果成功执行了请求原语，则状态参数设置为SUCCESS。否则，状态参数为错误状态。
3.3.4允许设备连接
该原语定义了ZigBee协调器或路由器的上层如何设置其设备允许其他设备同其网络连接。
3.3.4.1 NLME-PERMIT-JOINING.request 原语
该原语允许ZigBee协调其或路由器上层设定其MAC层连接许可标志，在一定期间内，允许其他设备同网络连接。
3.3.4.1.1 服务原语的语法
该原语的语法如下：
表3.12详细描述了NLME-PERMIT-JOINING.request原语的参数。
3.3.4.1.3 产生
当ZigBee协调器或路由器上层希望其他设备加入或阻止加入其网络时，将生成该原语，并传送给网络层管理实体。
3.3.4.1.3 接收
仅允许ZigBee协调器或路由器的上层发送该原语。如果ZigBee终端设备的网络层管理实体收到该原语，则将返回状态为INVALID_REQUEST的NLME-PERMIT-JOINING.confirm原语。
一旦网络层管理实体接收到参数PermitDuration的值为0x00的原语，则通过向MAC层发送MLME-SET.request原语将MAC层的PIB的macAssociationPermit属性设置为FALSE。一旦收到MLME-SET.confirm原语，则网络层管理实体发送NLME-PERMITJOINING.
Confirm原语，将其状态值设置为从MAC层所收到的状态。
一旦网络层管理实体接收到参数PermitDuration的值为0xff的原语，则通过向MAC层发送MLME-SET.request原语将MAC层的PIB的macAssociationPermit属性设置为TRUE。一旦收到MLME-SET.confirm原语，则网络层管理实体发送NLME-PERMITJOINING.
Confirm原语，将其状态值设置为从MAC层所收到的状态。
如果收到参数PermitDuration的值为除0x00或0xFF外的值，则网络层管理实体MAC层的PIB的macAssociationPermit属性设置为TRUE。当网络层管理实体收到MLME-SET.confirm原语后，将会启动一个计时器，在PermitDuration秒后，停止计时。一旦计时器启动，网络层管理实体将发送NLME-PERMIT-JOINING.confirm原语，其状态值设置为从MAC层所得到的状态值。如果计时器超时，网络层管理实体将发送参数macAssociationPermit为FALSE的MLME-SET.request原语。
任何一个由上层发出的NLME-PERMIT-JOINING.request原语，可以取代所有一切的请求。
3.3.4.2 NLME-PERMIT-JOINING.confirm原语
该原语向ZigBee协调器或路由器的上层返回允许设备连接网络请求原语的执行结果。
3.3.4.2.1 服务原语的语法
该原语的语法如下：
表3.13详细描述了NLME-PERMIT-JOINING.confirm原语的参数。
3.3.4.2.2 产生
该原语由ZigBee协调器或路由器初始化的网络管理实体生成，并且向上层发送作为对NLME-PERMIT-JOINING.request原语的确认。其状态参数既可以为MAC层所收到的状态，也可以INVALID-REQUEST的出错代码。这些状态值的原因详见3.3.4.1小节。
3.3.4.2.3 接收
当接收到该原语后，所初始化的设备上层即可得知允许其他设备连接网络请求原语的执行结果。
3.3.5路由器初始化
该原语允许一个新加入网络的ZigBee路由器开始参加ZigBee路由器的活动，包括数据帧的路由、路由发现、接收其他设备加入网络的请求。
3.3.5.1 NLME-START-ROUTER.request原语
该原语允许一个ZigBee路由器的上层发起路由。
3.3.5.1.1 服务原语的语法
该原语的语法如下：
3.3.5.1.2 产生
该原语由新设备的网络层管理实体上层生成，并发出给网络管理实体要求将设备初始化为ZigBee路由器。
3.3.5.1.3 接收
如果不是作为网络ZigBee路由器的设备接收到该原语后，网络层管理实体将返回状态参数为INVALID_REQUEST的NLME-START-ROUTER.confirm原语。
为初始化一个路由，网络层管理实体向MAC层发送MLME-START.request原语，MLME-START.request原语中的BeaconOrder 和 SuperframeOrder参数值设置为15，表明beaconless操作。MLME-START.request原语的CoordRealignment参数设置为FALSE。
当网络层管理实体收到相应的MLME-START.confirm原语，将向上层发送NLME-START-ROUTER.confirm原语，其中其状态值与MLME-START.confirm原语中的状态值一样。只有当MLME-START.confirm原语返回的状态值为SUCCESS时，设备开始作为ZigBee路由器开始工作，包括数据帧的路由、路由发现、接收设备加入网络的请求。否则，设备不允许做这些工作。
3.3.5.2 NLME-START-ROUTER.confirm原语
该原语返回执行ZigBee；路由器配置初始化的结果。
3.3.5.2.1 服务原语的语法
该原语的语法如下：
表3.14描述了NLME-START-ROUTER.confirm原语的参数。
3.3.5.2.2 产生
该原语由网络层管理实体生成，在接收到NLME-START-ROUTER.request原语时，向上层发送该原语作为响应。该原语返回的参数值为INVALID_REQUEST或者为MLME-START.confirm所返回的任何状态值。3.3.5.1.3小节描述了在哪些条件下返回这些值。
3.3.5.2.3 接收
接收到该原语，上层就得到ZigBee路由器初始化请求的结果。如果网络层管理实体已经成功设置，其返回的参数状态为SUCCESS，否则，参数状态为出错信息。
3.3.6能量扫描
该原语定义了设备的上层如何操作能量扫描
3.3.6.1 NLME-ED-SCAN.request原语
该原语允许上层请求本地信道进行能量扫描。
3.3.6.1.1 服务原语的语法
原语的语法如下：
表3.15详细描述了服务原语的参数。
3.3.6.1.2 产生
上层产生该原语要求：
·管理信道的能量扫描
3.3.6.1.3 接收
如果是连接到网络的设备接收到该原语，设备将停止接收任何新的NLDE-DATA.request原语，返回错误代码INVALID REQUEST。完成未解决的NLDE-DATA.request原语。一旦完成了未解决的NLDE-DATA.request原语，设备将临时停止网络操作，进行能量扫描。网络层管理实体向MAC层发送参数ScanType表示为能量扫描，参数ScanChannels和ScanDuration根据网络层管理实体请求设置的MLME-SCAN.request原语。
3.3.6.2 NLME-ED-SCAN.confirm原语
该原语返回上层请求能量扫描的结果。
3.3.6.2.1 服务原语的语法
该原语的语法如下：
表3.16详细描述了该原语的参数。
3.3.6.2.2 产生
该原语由ZigBee设备的网络层管理实体生生成，作为对NLME-ED-SCAN.request原语的响应。其状态表明从MAC层收到的MLME-SCAN.confirm原语所返回的状态。ScannedChannels表明那个信道被扫描了（1=信道已扫描）。EnergyDetectList包含信道扫描的结果（0x00-0xff）。其值与MAC层硬件表示为[dBm]无关。 (e.g. [-185 dBm ..
70dBm])参考IEEE802.15.4-2003。
3.3.6.2.3 接收
接收到该原语，上层得到能量扫描的结果。
3.3.7设备同网络连接
该原语给定了设备同网络连接的方式：
（1） 通过联合方式请求连接网络
（2） 直接请求连接网络
（3） 如果成为孤点设备，请求重新连接网络
3.3.7.1 NLME-JOIN.request 原语
该原语允许设备上层通过该原语以直接或间接方式请求连接网络，或者当设备为孤点设备时，请求重新连接网络。或者在一个网络中为设备改变操作的信道。
3.3.7.1.1 服务原语的语法
该原语的语法如下：
表3.17详细描述了NLME-JOIN.request原语的参数。
3.3.7.1.2 产生
设备的上层使用该原语请求：
（1） 通过使用MAC层连接过程请求同新网络连接
（2） 直接使用MAC层孤点过程请求连接网络
（3） 在成为孤点设备后，完成设备位置确定，并且重新连接网络
（4） 为连接到网络的设备改变操作信道
3.3.7.1.3 接收
如果收到该原语的设备已经同网络连接，并且RejoinNetwork参数为0x00，则网络管理实体将返回参数状态为INVALID_REQUEST的NLME-JOIN.confirm原语。
如果收到该原语的设备目前还没有同网络连接，并且RejoinNetwork参数为0x00，则设备尝试连接由参数ExtendedPANId所指定的网络。网络层管理实体发送MLME-ASSOCIATE.request原语，其中参数CoordAddress设置为在它的邻居表中的路由器地址，满足如下条件：
（1） 路由器属于参数CoordAddress所标识的网络
（2） 路由器对连接请求开发，is advertising capacity of the correctdevice type
（3） 当按照3.7.3.1小节诶所描述的计算方法，所计算连接成本最大为3时，设备收到帧的链路质量。
如果设备存在于邻居表中，且满足上述条件，原语MLME-ASSOCIATE.request中的LogicalChannel参数设置为邻居表中的地址，该地址与协调器地址的潜在父节点地址相对应。CapabilityInformation参数的位字段如表3.18所示。这里所收集的性能信息作为网络信息库的属性nwkCapabilityInformation存储起来（见表3.42）。如果多台设备满足上述要求，网络信息库中的nwkAddrAlloc属性为TRUE，则连接设备将选择最小深度的父节点。
如果在邻居表中不存在符合条件的设备，则网络层发送状态为NOT_PERMITTED的NLME-JOIN.confirm原语。否则，网络层管理实体发送状态与收到MLME-ASSOCIATE.confirm原语中的状态相一致的NLME-JOIN.confirm原语。
如果RejoinNetwork参数的值为0x00，且参数JoinAsRouter的值为TRUE，则设备将作为一个ZigBee路由器运行。如果参数JoinAsRouter的值为FALSE，则设备作为终端设备，不参与路由选择。
如果设备接收到该原语，且参数RejoinNetwork值为0x01，则发送MLME-SCAN.request原语，其参数ScanType设置为孤点扫描，ScanChannels 和 ScanDuration参数与NLME-JOIN.request原语的参数一致。网络层管理实体接收到MLME-SCAN.confirm原语，则发送NLME-JOIN.confirm原语，如果设备没有能力找到要连接的网络，其状态值为NO_NETWORKS，否则参数状态为MLME-SCAN.confirm原语所返回的状态值。
如果没有同网络连接的设备接收到该原语，并且RejoinNetwork参数值为0x02，则网络层管理实体发送状态参数为INVALID_REQUEST的NLME-JOIN.confirm原语。
如果当前与网络连接的设备接收到该原语，其RejoinNetwork参数值为0x02，则设备试图重新与当前的网络连接。在这种情况下，当下面情况为真时，网络层管理实体通过向它的邻居表中的路由地址发送重新建立网络连接请求命令初始化重新建立网络连接：
- 路由器有能力接收JoinAsRouter参数定义的设备类型
- 当按照3.3.7.1小节描述的计算方法，所计算连接成本最大为3时，设备收到帧的链路质量。
- 如果网络信息库中的属性nwkAddrAlloc值为0x00，并且由多于一个满足上述两个条件的潜在的父节点存在，则连接设备将选择最小深度的树根。
如果设备存在于邻居表中，且满足上述条件，重新连接请求命令的目的地址设置为潜在的父节点的网络地址。参数CapabilityInformation位如表3.18所示。这里的能力信息如网络信息库中属性nwkCapabilityInformation所示。（见表3.42）.
如果在邻居表中不存在符合条件的设备，则网络层发送状态为NOT_PERMITTED的NLME-JOIN.confirm原语。否则，网络层管理实体发送状态与收到重新连接响应命令状态参数值一致的NLME-JOIN.confirm原语。
一旦设备成功同网络连接，它将把网络信息库中属性nwkExtendedPANID的值设置为连接网络的PAN标识符。
如果设备接收到该原语，且参数RejoinNetwork值为0x03，设备试图把操作信道改变为参数ScanChannel所提供的信道。如果在参数ScanChannel中，提供多个信道，网络层管理实体将发送状态参数为INVALID_REQUEST的NLME-JOIN.confirm原语。否则，网络层管理实体发送NLME-JOIN.confirm原语，其状态参数为从转换的信道接收的状态参数值。
3.3.7.2 NLME-JION.indication原语
当一个新设备通过联合方式或者按照3.7.1.3.3小节所描述的重新连接的方式连接网络成功后，就发送该原语通知ZigBee协调器或路由器的上层。
3.3.7.2.1 服务原语的语法
该原语的语法如下：
表3.19详细描述了NLME-JION.indication原语的参数。
3.3.7.2.2 产生
在通过如表3.31所示的MAC层的联合方式成功的将一个新的设备连接到网络或如表3.36所示的网络层管理实体的重新连接方式将设备重新连接网络成功后，ZigBee协调器和路由器的网络层管理实体生成该原语，并向其上层传送。
3.3.7.2.3 接收
设备上层收到该原语就可得知一个新的设备已经成功地连接到本网络。
3.3.7.3 NLME-JOIN.confirm原语
设备上层通过该原语可得知其请求连接网络的结果。
3.3.7.3.1 服务原语的语法
该原语的语法如下：
表3.20详细描述了NLME-JOIN.confirm原语的参数
3.3.7.3.2 产生
网络层管理实体接收到NLME-JOIN.request时，对其NLME进行初始化，并生成该原语，发送给其上层作为对网络连接请求原语的响应。如果连接请求成功，则状态参数为SUCCESS，否则，状态参数为错误代码。如INVALID_REQUEST、NOT_PERMITTED、 NO_NETWORKS或者为MLME-ASSOCIATE.confirm 和MLME-SCAN.confirm原语所返回的状态值。这些状态值的情况如3.3.7.1.3小节所述。
3.3.7.3.3 接收
正在初始化设备的上层接收到该原语后，就可得到各种连接方式请求的执行结果，连接方式为联合方式，直接连接方式或古典连接方式。
3.3.8直接将设备同网络连接
该原语定义了ZigBee协调器或路由器上层利用直接请求的方式，将另一个设备同自身网络连接。
3.3.8.1 NLME-DIRECT-JOIN.request原语
该原语给出了ZigBee协调器或路由器的上层如何请求直接把另一个设备连接到自己的网络中。3.3.8.1.1 服务原语的语法
该原语的语法如下：
表3.21详细描述了NLME-DIRECT-JOIN.request原语的参数。
3.3.8.1.2 产生
ZigBee协调器或路由器生成该原语把新设备直接连接到自己的网络。这个过程不需要任何传输。
3.3.8.1.3 接收
网络层管理实体接收到此原语后，将会尝试把参数DeviceAddress所给定地址的设备连接到邻居表中，而参数CapabilityInformation设定了加入网络后设备的运行能力。在执行协议中，alternate PAN coordinator位为0。如果设备作为ZigBee路由器，那么其device type位为1，如果为终端设备则为0。如果设备的电源为交流电源，则power source位置为1，否则为0。如果设备在空闲期间，设备接收器打开，则receiver on when idle位置为1，否则置为0。如果设备具有安全操作能力，则security capability位置为1，否则为0.
如果网络层管理实体成功地把连接设备加入其邻居表，则发送状态参数为SUCCESS的NLME-DIRECT-JOIN.confirm原语。如果网络层管理实体发现所要加入的设备已在其邻接表中，则发送状态参数为ALREADY_PRESENT的NLME-DIRECT-JOIN.confirm原语。如果网络层管理实体不能将新的设备加入到邻接表中，则发送状态参数为NEIGHBOR_TABLE_FULL的NLME-DIRECT-JOIN.confirm原语。
3.3.8.2 NLME-DIRECT-JOIN.confirm 原语
该原语向ZigBee协调器或路由器上层通告直接把一设备加入网络请求原语的执行结果。
3.3.8.2.1 服务原语的语法
该原语的语法如下：
表3.22详细描述了NLME-DIRECT-JOIN.confirm原语的参数。
3.3.8.2.2 产生
在接收到NLME-DIRECT-JOIN.request原语后，网络层管理实体生成该原语，并向上层发送作为对请求原语的响应。如果请求成功，则参数表示连接成功，否则，状态参数为错误代码，即为ALREADY_PRESENT或 NEIGHBOR_TABLE_FULL。这些状态值的理由如3.3.8.1.3小节所述。
3.3.8.2.3 接收
正在初始化设备的上层接收到该原语后，即可得到其直接把一设备加入网络的请求原语执行结果。
3.3.9断开网络
本小节介绍了设备上层请求自身或其他设备同网络断开连接的原语，同时也介绍了当设备成功地同网络断开后，向ZigBee协调器上层报告时所采用的原语。
3.3.9.1 NLME-LEAVE.request原语
设备上层利用该原语请求自身或者其他设备同网络断开连接。
3.3.9.1.1 服务原语的语法
该原语的语法如下：
表3.23详细描述了NLME-LEAVE.request原语的参数。
3.3.9.1.2 产生
当设备上层需要同网络断开连接，或者ZigBee协调器或路由器上层准备将一个设备同网络断开连接时，生成该原语。
3.3.9.1.3 接收
如果设备没有同网络连接，而设备的网络层管理实体接收到该原语，则网络层管理实体发送状态参数为INVALID_REQUEST的NLME-LEAVE.confirm原语。当一个网络连接设备的网络层管理实体接收到该原语，并且其DeviceAddress参数为NULL，RemoveChildren参数为FALSE时，网络层管理实体将按照3.7.1.8.1小节所述将自身与网络断开连接。网络层管理实体将清除路由表入口参数，并向MAC层发送MLME-RESET.request原语。如果网络层管理实体收到MLME-RESET.confirm原语其状态参数不为SUCCESS,时，网络层管理实体可能会选择重发复位请求。网络层管理实体也将把相对于父节点的邻居表入口的relationship域设置为0x03，表明没有关系。如果接收到的NLME-LEAVE.request原语的DeviceAddress参数为NULL，RemoveChildren参数为TRUE，那么网络层管理实体将试图如3.7.1.8.3小节所述，移除其子节点。
当ZigBee协调器或路由器接收到该原语，且原语的设备地址参数不为NULL，则网络层管理实体将判断所指定设备是否存在于邻居表中，。如果所请求设备不存在于邻居表中，则网络层管理实体将发送状态值为UNKNOWN_DEVICE的NLME-LEAVE.confirm原语。如果所请求的设备存在于邻居表中，网络层管理实体将按照3.7.1.8.3小节所述将设备从网络移除。如果RemoveChildren参数为TRUE，将请求移除该设备的子节点。移除结束，网络层管理实体将发送NLME-LEAVE.confirm原语，其参数DeviceAddress为移除设备的64位IEEE地址，状态参数为MCPS-DATA.confirm原语所返回的状态值。然后对应于移除设备的邻居表的relationship域将被更新。Relationship域按照NLME-LEAVE.request原语的Rejoin参数进行更新。如果Rejoin域的值为FALSE，那么relationship域为0x03，表明没有关系。如果Rejoin域为TRUE，那么relationship域为0x04，表明节点属于上一层的子节点。
3.3.9.2 NLLME-LEAVE.indication原语
3.3.9.2.1 服务原语的语法
该原语的语法如下：
表3.24详细描述了NLLME-LEAVE.indication原语的参数。
3.3.9.2.2 产生
当与ZigBee协调器或路由器所连接的设备同网络断开时，协调器或路由器的网络层管理实体生层该原语，并且发送到ZigBee协调器或路由器的上层。该原语也可由ZigBee路由器或终端设备的网络层管理实体生层，并发送给设备上层以表明该设备已同该设备所连接的ZigBee协调器或路由器成功地断开连接。
3.3.9.2.3 接收
ZigBee协调器或路由器上层一旦收到该原语，就可得到与其连接的设备已离开网络的消息。ZigBee路由器或终端设备上层也由该原语可得到它与所连接的ZigBee协调器或路由器断开的通告消息。
如果参数Rejoin值为TRUE，那么上层期望按照3.7.1.3小节所述的NLME-JOIN.request原语重新与网络连接。如果参数Rejoin值为FALSE，离开的设备将不能自动的与网络重新连接，尽管可能在上层的指导下与网络重新连接。
3.3.9.3 NLME-LEAVE.confirm原语
该原语向一个设备上层通告请求设备自身或其他设备离开连接网络的结果。
3.3.9.3.1 服务原语的语法
该原语的语法如下：
表3.25详细描述了NLME-LEAVE.confirm原语的参数
3.3.9.3.2 产生
该原语向一个设备上层通告请求设备自身或者其他设备离开连接网络的结果。如果请求断开连接原语成功执行，则该状态参数值表明为成功地断开连接；否则，状态参数为INVALID_REQUEST或UNKNOWN_DEVICE或为MCPS-DATA.confirm原语所返回的任意状态值。这些状态值的原因如3.3.9.1.3小节所述。
3.3.9.3.3 接收
正在初始化中的设备上层收到此原语，就可得到请求自身或其他设备同网络断开的执行结果。
3.3.10重新复位设备
该原语介绍了一个设备应用层如何请求重新复位它的网络层。
3.3.10.1 NLME-RESET.request原语
设备应用层采用该原语请求网络层执行重新复位操作。
3.3.10.1.1 服务原语的语法
该原语的语法如下：
该原语无参数。
3.3.10.1.2 产生
该原语由设备应用层生成，并且发送到该设备的网络层管理实体，用来请求网络层重新复位网络层，以使它恢复到初始状态。
3.3.10.1.3 接收
网络层管理实体一旦收到该原语，就行MAC层发送SetDefaultPIB参数置为TRUE的MLME-RESET.request原语。网络层一旦收到所对应的MLME-RESET.confirm原语，将清除设备所有的内部变量和路由表入口参数，并将所有的NIB属性设为默认值，从而重新复位网络层。在网络层重新复位后，网络层管理实体将发出MLME-RESET.confirm原语；并且当MAC层成功地重新复位时，原语的状态参数设置为SUCCESS，否则状态参数设置为DISABLE_TRX_FAILURE。
如果此原语发送到一个已连接网络设备的网络层管理实体，任何使用NLME-LEAVE.request原语请求断开连接的企图都由上层进行优先判断。
3.3.10.2 NLME-RESET.confirm原语
该原语用来向设备应用层报告请求重新复位网络层的执行结果。
3.3.10.2.1 服务原语的语法
该原语的语法如下：
表3.26详细描述了NLME-RESET.confirm原语的参数
3.3.10.2.2 产生
该原语由设备的网络层管理实体生成，并发送到它的上层用开对NLME-RESET.request原语进行确认。如果请求成功，则状态参数表明进行了一次成功的重新复位操作。否则，状态参数为DISABLE_TRX_FAILURE的错误代码。这些状态值的原因如3.3.10.1.3小节所述。
3.3.10.2.3 接收
在收到该原语后，该设备应用层就会得到它请求网络层重新复位的执行结果。
3.3.10.3 网络层重新复位的顺序图
图3.2描述了重新复位网络层所必须的顺序图
3.3.11接收机同步
该原语介绍了一个设备应用层如何使它得得接收机与ZigBee协调器或路由器同步，并从网络层中得到它的数据。
3.3.11.1 NLME-SYNC.request原语
设备应用层使用该原语与ZigBee协调器或路由器进行同步，或从ZigBee协调器或路由器中得到它的数据。
3.3.11.1.1 服务原语的语法
该原语的语法如下：
3.3.11.1.2 产生
无论何时，设备应用层要与Zigbee协调器或路由器实现同步，或查询在协调器或路由器中是否存在它的数据时，都可生成该原语。
3.3.11.1.3 接收
接收到该原语，网络层管理实体将向MAC层发送MLME-POLL.request原语，并将它的参数TrackBeacon置为FALSE。在收到相应的MLME-POLL.confirm原语后，网络层管理实体将发送NLME-SYNC.confirm原语，其状态参数与MLME-POLL.confirm原语的状态参数一致。
3.3.11.2 NLME-SYNC.indication原语
该原语向设备的应用层通告MAC层丢失网络同步信号。
3.3.11.2.1 服务原语的语法
该原语的语法如下：
该原语无参数。
3.3.11.2.2 产生
网络层管理实体通过MLME-SYNC-LOSS.indication原语从MAC层得到丢失同步信号通知后，就会生成该原语。该原语跟随着NLME-SYNC.request原语之后，发送到网络层管理实体。
3.3.11.2.3 接收
接收到该原语，其应用层就可得到设备的MAC层丢失了网络的同步信标。
3.3.11.3 NLME-SYNC.confirm原语
该原语用来向设备应用层报告它所请求网络同步的执行结果，或报告请求从ZigBee协调器或路由器中所得到数据的结果。
3.3.11.3.1 服务原语的语法
该原语的语法如下：
表3.27详细描述了NLME-SYNC.confirm原语的参数。
3.3.11.3.2 产生
该原语由正在初始化中的网络层管理实体生成，并发送到它的应用层用以对NLME-SYNC.request原语的确认。如果请求原语成功执行，状态参数表明为一次成功的状态改变尝试。否则，状态参数为错误代码。这些状态的原因如3.3.11.1.3小节所述。
3.3.11.3.3 接收
设备应用层收到此原语后，就可得到请求同步或请求从ZigBee协调器或路由器取得数据原语的执行结果。如果请求执行成功，则状态参数置为SUCCESS；否则，状态参数为错误状态代码。
3.3.12信息库维护
该原语介绍了设备上层如何读写网络信息库的属性
3.3.12.1 NLME-GET.request原语
设备上层应用该原语请求读取网络信息库中某一属性值。
3.3.12.1.1 服务原语的语法
该原语的语法如下：
表3.28详细描述了NLME-GET.request原语的参数。
3.3.12.1.2 产生
该原语由设备网络层管理实体的上层生成，并发送给网络层管理实体以便从网络信息库中读取所指定的属性值。
3.3.12.1.3 接收
网络层管理实体一旦接收到该原语，就试图从它的数据库中获取所请求的属性值。如果在数据库中没有找到所指定的属性标识符，则发送状态为UNSUPPORTED_ATTRIBUTE的NLME-GET.confirm原语。
如果网络层管理实体成功地获取了所请求的属性值，则发送状态参数为SUCCESS以及NIB属性标识符和属性值的NLME-GET.confirm原语。
3.3.12.2 NLME-GET.confirm原语
该原语报告了从网络信息库中读取属性值的执行结果。
3.3.12.2.1 服务原语的语法
该原语的语法如下：
表3.29详细描述可该原语的参数。
3.3.12.2.2 产生
该原语由网络层管理实体生成，并发送给它的上层，作为对NLME-GET.request原语的确认。该原语返回的状态参数为SUCCESS，则表明成功地读取了所请求的NIB属性值，或者为UNSUPPORTED_ATTRIBUTE的错误代码。
3.3.12.2.3 接收
网络层管理实体上层一旦接收到该原语，就可得知读取NIB属性请求原语的执行结果。如果成功地执行了请求原语，则状态参数置为SUCCESS。否则，状态参数为错误代码。
3.3.13.3 NLME-SET.request原语
网络层管理实体上层使用该原语向网络信息库写入所指定的属性值。
3.3.13.3.1 服务原语的语法
该原语语法如下：
表3.30详细描述了该原语的参数。
3.3.12.3.2 产生
该原语由网络层管理实体上层生成，并发送给网络层管理实体，以此向网络信息库写入所给定的属性值。
3.3.12.3.3 接收
网络层管理实体一旦接收到该原语，就试图向它的数据库中写入所指定的属性值。如果所指定的属性参数在数据库中不存在，则网络层管理实体将发送状态参数为UNSUPPORTED_ATTRIBUTE的NLME-SET.confirm原语。如果所指定的属性值超出了所给定属性的正常范围，则网络层管理实体将发送状态为INVALID_PARAMETER的NLME-SET.confirm原语。
如果成功地写入了NIB属性，网络层管理实体将发送状态为SUCCESS的NLME-SET.confirm原语。
3.3.12.4 NLME-SET.confirm原语
该原语报告了尝试向网络信息管理库中写入属性值的执行结果。
3.3.12.4.1 服务原语的语法
该原语的语法如下：
表3.31详细描述了该原语的参数。
3.3.12.4.2 产生
该原语由网络层管理实体生成，并向其上层发送，作为对NLME-SET.request原语的确认。如果该原语返回的状态为SUCCESS，则表明所指定的属性值已经成功地写入所指定的NIB属性中，或者状态为INVALID_PARAMETER或UNSUPPORTED_ATTRIBUTE。这些状态值的情况如3.3.12.3.3小节所述。
3.3.12.4.3 接收
网络层管理实体上层一旦接收到该原语，就可得知请求写入NIB属性值原语的执行结果。如果成功执行，则状态参数为SUCCESS；否则，状态参数为出错代码。
3.3.13路由错误报告
该原语用来描述设备网络层通知其上层发生路由失败，结果是至少一个单播或多播帧发送失败或通过该设备转发信息帧失败。广播帧的路由错误是帧发送到如表3.23所示的广播地址没有报告。
3.3.13.1 NLME-ROUTE-ERROR.indication原语
该原语向设备上层通告网络通信失败。
3.3.13.1.1 服务原语的语法
该原语的语法如下：
表3.32详细描述了该原语的参数。
3.3.13.1.2 产生
当如下情况发生时，设备的网络层用该原语通知设备的上层：
（1） 设备发现或重修ShortAddr参数所给地址的路由发生错误
（2） 因为表3.40所给出的原因，设备向参数ShortAddr所给出的16位网络地址的终端子设备发送数据帧失败
（3） 设备收到该设备的路由错误命令帧。在这种情况下，参数ShortAddr域将反映目的地址的值和命令帧的错误码域。
接收
设备上层通过该原语被通告与确定地址的通信失败。
3.3.14路由发现
该原语用来定义设备上层如何初始化路由发现，如单播路由发现、多点传送路由发现和多对一路由发现，并被通知路由发现的结果信息。
3.3.14.1 NLME-ROUTE-DISCOBERY.request原语
该原语允许设备上层初始化路由发现。
3.3.14.1.1 服务原语的语法
该原语的语法如下：
表3.33详细描述了该原语的参数。
3.3.14.1.2 产生
该原语由ZigBee协调器或路由器的上层产生并发送给网络层管理实体请求初始化路由发现。
3.3.14.1.3 接收
如果是ZigBee终端设备的网络层管理实体接收到该原语，那么网络层管理实体将向上层发送状态参数为INVALID_REQUEST的NLME-ROUTE-DISCOVERY.confirm原语。
如果该原语的DstAddrMode参数不为0x00，并且DstAddr参数不为广播地址，那么网络层管理实体将向上层发送状态值为INVALID_REQUEST的NLME-ROUTE-DISCOVERY.confirm原语。
如果接收到该原语的ZigBee路由器或协调器没有路由能力，并且DstAddrMode参数为0x01或0x02，那么网络层管理实体将向上层发送状态值为NO_ROUTING_CAPACITY的NLME-ROUTE-DISCOVERY.confirm原语。
如果接收到该原语的ZigBee路由器或协调器有路由能力，并且参数DstAddrMode的值为0x02，网络层将开始发现从当前设备到参数DstAddr所示的16位网络地址设备的路由。初始化发现单播路由的详细描述见3.7.3.5.1小节。
如果接收到该原语的ZigBee路由器或协调器有路由能力，并且参数DstAddrMode的值为0x01，网络层管理实体将通过查看在nwkGroupIDTabl入口中是否有与目的地址相对应的入口来检查该设备是否是DstAddr参数所确定的多点传输组标识符的一员。如果设备时多点传输组中的一员，则网络层管理实体将立即发送状态值为SUCCESS的NLME-ROUTE-DISCOVERY.confirm原语，终止NLME-ROUTEDISCOVERY.request原语的后续处理。如果设备不是多点传输组的一员，网络层管理实体将初始化一个从当前设备到由DstAddr参数确定的多点传输组的单播路由发现。初始化发现单播路由的详细描述见3.7.3.5.1小节。
如果接收到该原语的ZigBee路由器或协调器的DstAddrMode参数为0x00，网络层管理实体将初始化多对一路由发现。初始化多对一路由发现的过程详见3.7.3.5.1小节。
在任何一个上述的三中路由发现情况下，网络层管理实体将使用MAC层的MCPS-DATA.request原语试图传输一个路由发现命令帧来初始化路由发现。如果提供了可选参数Radius，那么该值将出现在输出帧的网络层帧头的radius域；如果没有提供该值，那么如果要传输数据帧，网络层帧头的radius域将设置为网络层信息库中nwkMaxDepth参数的二倍。如果MAC层因为某些原因传输路由请求命令帧失败，那么网络层管理实体将向上层发送ROUTE-DISCOVERY.confirm原语，其状态参数与MCPS-DATA.confirm原语返回的状态值一致。如果路由发现命令帧发送成功，并且参数DstAddrMode值为0x00，表明为多对一路由发现，网络层管理实体将立即发送状态值为SUCCESS的ROUTE-DISCOVERY.confirm原语。否则，网络层管理实体将等待直到接收到路由响应命令帧或路由发现操作超时，如3.7.3.5小节所示。如果在路由发现操作时间结束前接收到路由响应命令帧，网络层管理实体将向上层发送状态值为SUCCESS的NLME-ROUTE-DISCOVERY.confirm原语。如果操作时间超时，将发送状态值为ROUTE_DISCOVERY_FAILED的NLME_ROUTE-DISCOVERY.confirm原语。
3.3.14.2 NLME-ROUTE-DISCOVERY.confirm原语
该原语用来向设备上层报告初始化路由发现操作的结果。
3.3.14.2.1 服务原语的语法
该原语的语法如下：
表3.34详细描述了NLME-ROUTE-DISCOVERY.confirm原语的参数。
3.3.14.2.2 产生
该原语由网络层管理实体产生，并作为初始化路由发现的结果发送给设备上层。
3.3.14.2.3 接收
设备上层通过该原语得知初始化路由发现的执行结果。可能的状态参数和它们在何种情况下产生如3.3.14.1.3小节所述。
3.3.15网络回退
该原语用来定义设备上层如何在改变信道前初始化网络回退。
3.3.15.1 NLME-START-BACKOFF.request原语
设备上层利用该原语用来请求初始化网络回退。
3.3.15.1.1 服务原语的语法
该原语的语法如下：
表3.35详细描述了NLME-START-BACKOFF.request原语的参数。
3.3.15.1.2 产生
设备上层在改变信道前利用该原语确保在执行改变信道时没有传输数据包。
3.3.15.1.3 接收
接收到该原语，网络层管理实体将不再处理NLDE-DATA.requests原语，并返回BACKOFF PERIOD错误代码。NLDE-DATA.confirm and .indication将继续正常处理。
3.4帧格式
本小节详细介绍了网络层帧的格式，即网络协议数据单元（NPDU）的格式。网络层帧由下列基本部分组成：
（1） 网络层帧头，包含帧控制、地址和序列信息。
（2） 网络层帧的可变长有效帧载荷，包含帧类型所指定的信息。
网络层帧是一种按指定的序列排列的序列。本节中所有的帧格式按MAC层的传播顺序来描述，即从左到右，最左边的比特位最先发送。长度为k个比特的帧，按从0（最左为最低位）到k-1（最右为最高位）进行编号。帧长度大于一个8比特的帧，将按照最小序列的比特组到最大序列号的比特组顺序传送到MAC层。
3.4.1通用网络层帧格式
网络层帧格式通常由一个网络层报头和一个网络层有效载荷组成。网络层报头按固定顺序出现。然而，仅仅只有多播标志值是1时才存在多播控制域。网络层帧格式如图3.3所示。
| 字节：2 |
2 |
2 |
1 |
1 |
0/8 |
0/8 |
0/1 |
变长 |
变长 |
| 帧控制 |
目的地址 |
源地址 |
广播半径域 |
广播序列号 |
目的IEEE地址 |
源IEEE地址 |
多点传送控制 |
源路由帧 |
帧的有效载荷 |
|
网络层帧报头 |
网络层的有效载荷 |
||||||||
图3.3通用网络层帧格式
3.4.1.1帧控制域
帧控制域为16位，包含所定义的帧类型、地址和序列域以及其他控制标记。帧控制域格式如图3.4所示。
| 比特0-1 |
2-5 |
6-7 |
8 |
9 |
10 |
11 |
12 |
13-15 |
| 帧类型 |
协议版本 |
发现路由 |
多播标记 |
安全 |
源路由 |
目的IEEE地址 |
源IEEE地址 |
保留 |
图3.4帧控制域格式
3.4.1.1.1帧类型子域
帧类型子域为2bit，其值为表3.36中所列的非保留值。
表3.36帧类型子域值
| 帧类型值b1 b0 |
帧类型名 |
| 00 |
数据 |
| 01 |
网络层命令 |
| 10，11 |
保留 |
3.4.1.1.2协议版本子域
协议版本子域为4bit，设置值反应了所使用的ZigBee网络层协议版本号特定设备上所使用的协议版本应像固定网络层协议版本号一样。
3.4.1.1.3发现路由子域
发现路由子域用根据帧的传送控制路由发现操作。（见3.7.3.5）
对于网络层命令帧，路由发现子域设置为0x00表明抑制路由发现。
表3.37发现路由子域值
| 发现路由子域值 |
域意义 |
| 0x00 |
抑制路由发现 |
| 0x01 |
使能路由发现 |
| 0x02 |
强制路由发现 |
| 0x03 |
保留 |
3.4.1.1.4多播标志域
多播标志域为1bit，如果是单播或者广播帧，值为0，如果为多播帧值为1。
3.4.1.1.5安全子域
安全子域值为1时，该帧才具有网络层安全操作能力。如果该帧的安全由另一层来完成或者完成被禁止，则该值是0。
3.4.1.1.6源路由子域
源路由子域值为1时，源路由子帧才在网络报头中存在。如果源路由子帧不存在则源路由子域值为0。
3.4.1.1.7目的IEEE地址子域
目的IEEE地址是1时，网络帧报头包含整个目的IEEE地址。
3.4.1.1.8源IEEE地址子域
源IEEE地址是1时，网络帧报头包含整个源IEEE地址。
3.4.1.2目的地址域
在网络层帧中必须有目的地址域，其长度是2字节。如果帧控制域的多播标志子域值是0，那么目的地址域值是16位的目的设备网络地址或者为广播地址（见表）。如果多播标志子域值是1，目的地址域是16位目的多播组的Group ID。值得注意的是设备的网络地址与IEEE802.15.4-2003协议中的MAC层16位短地址相同。
3.4.1.3源地址域
在网络层帧中必须有源地址域，其长度是2字节，其值是源设备的网络地址。值得注意的是设备的网络地址与在IEEE802.15.4-2003协议中的MAC层16位短地址相同。
3.4.1.4半径域
在网络层帧中必须有半径域，其长度是1字节，并且限定了传输半径范围。每个设备接收一次该帧，则该值减以。
3.4.1.5序列号域
在每个帧中都包含序列号域，其长度是1字节。每发送一个新的帧序列号值加1。帧的源地址和序列号子域是一对，在限定了序列号1字节的长度内是唯一的标识符。关于使用序列号的更多信息，见3.7.2节。
3.4.1.6目的IEEE地址域
如果存在目的IEEE地址域，则包含与包含在网络层地址头中的目的地址域的16位网络地址相对应的64位IEEE地址。如果该16位网络地址是广播或者多播地址那么目的IEEE地址不存在。
3.4.1.7源IEEE地址
如果存在源IEEE地址域，则包含与包含在网络层地址头中的源地址域的16位网络地址相对应的64位IEEE地址。
3.4.1.8多播控制域
多播控制域是1字节长度且只有多播标志子域值是1时存在。它分成3个子域如图3.5所示。
| 比特：0-1 |
2-4 |
5-7 |
| 多播模式 |
非成员半径 |
最低非成员半径 |
图3.5多播控制域帧格式
3.4.1.8.1多播模式子域
多播模式子域表明无论是使用成员或非成员模式传输该帧。成员模式在目的组成员设备中使用传送多播帧。非成员模式是从不是多播组成员设备到是多播组成员设备换算多播帧。
表3.38多播模式子域值
| 多播模式域值b0b1 |
域意义 |
| 00 |
非成员模式 |
| 01 |
成员模式 |
| 10 |
保留 |
| 11 |
保留 |
3.4.1.8.2非成员半径子域
当不是目的组成员设备转播时，非成员半径域表明成员模式多播范围。接收设备是目的组成员将设置该子域值是最大非成员半径（MaxNonmemberRadius）域的值。如果NonmemberRadius field的值是0，接收设备不是目的组成员时将丢弃该帧，且如果NonmemberRadius域的值是在0x01到0x06范围内，那么将耗尽此域。如果NonmemberRadius域值是0x07表明无限的范围且不能被耗尽。
3.4.1.8.3最大非成员半径（MaxNonmemberRadius）子域
该帧的非成员半径域的最大值。
3.4.1.9源路由子帧域
如果帧控制域的源路由子域的值是1，才存在源路由子帧域。它分成三个子域如图3.6所示。
| 字节：1 |
1 |
可变 |
| 应答 计数器 |
应答索引 |
应答列表 |
图3.6源路由子帧格式
3.4.1.9.1应答计数器子域
应答计数器子域表明包含在源路由子帧转发列表里的应答的数值。
3.4.1.9.2转发索引
应答索引子域表明传输的数据包的应答列表子域的下一转发的索引。这个域被数据包的发送设备初始化为0，且每转发一次就加1。
3.4.1.9. 应答列表子域
应答列表子域是节点的2字节短地址的列表，这个域用来为源路由数据包的目的转发。地址是最无意义字节格式（formatted least significant byte first,？？？）且在源路由中有顺序的出现。
3.4.1.10帧有效载荷域
帧有效载荷的长度是可变的，包含了各种帧类型的具体信息。
3.4.2各种帧类型的格式
定义了两种类型的网络层帧，它们分别是数据帧和网络层命令帧。在下面将对这两种帧类型进行讨论。
3.4.2.1数据帧格式
数据帧格式如图3.7所示。
| 字节：2 |
可变长 |
可变长 |
| 帧控制 |
路由域 |
数据载荷 |
| 网络层帧头 |
网络层载荷 |
|
图3.7数据帧格式
数据帧各部分的顺序与图3.3所示的通用网络层帧格式的顺序相同。
3.4.2.1.1数据帧网络层报头域
数据帧的网络层报头域有控制域和根据需要适当组合而得到的路由域组成。
如表3.36所示，在帧控制域中，帧类型子域应表示数据帧的值。根据数据帧的用途，对其他所有的子域进行设置。
根据帧控制域中的设置（参见图3.4），路由为地址域和广播域经过适当组合得到的。
3.4.2.1.2数据的有效载荷域
数据帧的数据有效载荷域包含字节的序列，该序列为网络层上层要求网络层传送的数据。
3.4.2.2网络层命令帧格式
网络层命令帧格式如图3.8所示。
| 字节：2 |
可变长 |
1 |
可变长 |
| 帧控制 |
路由域 |
网络层命令标识符 |
网络层命令载荷 |
| 网络层帧报头 |
网络层载荷 |
||
图3.8网络层命令帧格式
网络层命令帧各部分的顺序与图3.3所示的通用网络层帧格式的顺序相同。
3.4.2.2.1网络层命令帧中的网络层帧报头域
网络层命令帧中的网络层帧报头域由帧控制域和根据需要适当组合得到的路由域组成。
如表3.36所示，在帧控制域中，帧类型子域应表示网络层命令帧的值。根据网络层命令帧的用途，对其他所有的子域进行设置。
根据帧控制域中的设置，路由为地址域和广播域经过适当组合得到的。
3.4.2.2网络成命令标识符
网络层命令标识符域表明所使用的网络层命令，其值如表3.39所列的非保留值之一。
3.4.2.2.3网络层命令的有效载荷域
网络层命令帧的网络层命令载荷域包含网络层命令本身。
3.5命令帧
网络层定义的命令帧，如表3.39所示。本小节详细介绍网络层管理实体如何构造要传递的各种命令。
表3.39网络层命令帧
| 命令帧标识符 |
命令名称 |
|
| 0x01 |
路由请求 |
3.5.1节 |
| 0x02 |
路由应答 |
3.5.2节 |
| 0x03 |
路由错误 |
3.5.3节 |
| 0x04 |
断开 |
3.5.4节 |
| 0x05 |
路由记录 |
3.5.5节 |
| 0x06 |
重新连接请求 |
3.5.6节 |
| 0x07 |
重新加入响应 |
3.5.7节 |
| 0x08 |
连接状态 |
3.5.8节 |
| 0x09 |
网络报告 |
3.5.9节 |
| 0x0A |
网络更新 |
3.5.10节 |
| 0x0B- 0xFF |
保留 |
—— |
3.5.1路由请求命令
设备使用路由请求命令来请求在其无线通信范围内的其他设备发现到达目的设备的路由，以便在网络中建立一条稳定的使信息更快更经济地到达目的设备的路由。路由请求命令的载荷格式如图3.9所示。
| 字节：1 |
1 |
1 |
2 |
1 |
| 命令帧标识符（见表3.39） |
命令选择 |
路由请求标识 |
目的地址 |
路由开销 |
| 网络层载荷 |
||||
图3.9路由请求命令帧格式
3.5.1.1MAC数据服务请求
为了利用MAC层数据服务（在IEEE 802.15.4-2003【B1】）来传输这个命令，在MAC层帧报头包含如下信息：
（1）目的PAN标识符设置为发送路由请求命令设备的PAN标识符。
（2）目的地址必须为广播地址0xffff。
（3）源MAC地址和PAN标识符设置为发送路由请求命令设备的地址和PAN标识符，该设备不一定是命令源发送设备。
（4）因为任何来自于网络层的可靠帧都使用网络层的安全协议，帧控制域将禁止MAC层对MAC层数据帧使用安全功能。由于该帧为广播帧，因此不需要确认。地址模式以及内部PAN标记设置为支持在这里所描述的地址域。
3.5.1.2网络层帧报头域
为了传送路由请求命令帧到它的目的设备，且为了路由发现过程正确完成，应提供如下信息：
（1） 网络层帧头的源地址域设置成发送设备的地址。
（2） 网络层帧头的目的地址域设置成设备的广播地址，macRxOnWhenIdle的值等于TRUE（参见表3.51）
（3） 网络层帧头的发现路由子域设置成抑制路由发现（参见表3.36）
（4） 作为一个网络层命令帧，帧控制域的源IEEE地址子域设置成1，且网络层帧头的源IEEE地址域存在且包含帧发送此帧设备的64位IEEE地址。如果试图发现的设备的64位IEEE地址已经知道，那么帧控制域的目的IEEE地址子域的值是1，且网络层帧头的目的IEEE地址域存在且包含设备的64位IEEE地址。
3.5.1.3网络层帧有效载荷域
网络层帧的载荷包含命令标识符域、命令选择域、路由请求标识符域、目的地址和最新的路由总开销域。
命令帧标识符应包含表明路由请求命令帧的值。
3.5.1.3.1命令选择域
8位的命令选择域格式如图3.10所示。
| 比特：0-4？？？5哪去了 |
6 |
7 |
| 保留 |
多播 |
保留 |
图3.10路由请求命令选择域
3.5.1.3.1.1多播子域
多播子域是1位。只有命令帧请求多播组路由时，它的值是1，在这个情况下，目的地址域包含期望组的Group ID。
3.5.1.3.2路由请求标识符
路由请求标识符为一个8bit的路由请求序列号，在特定设备的网络层每发送一次路由请求，该标识符增加1。
3.5.1.3.3目的地址
目的地址长2字节，标识路由请求命令帧的目的地址。
3.5.1.3.4路由开销
路由开销域长度为8bit，常常用来积累路由请求命令帧在网络中传送的开销信息。（参见3.7.3.5.2节）
3.5.2路由应答命令
路由应答命令的目的设备使用路由应答命令来通知路由请求的源设备已接收到请求命令。ZigBee路由请求所经路由器建立一种能使帧更快捷地从源地址路由到目的地址的状态路由应答命令的载荷格式如图3.11所示。
| 字节：1 |
1 |
1 |
2 |
2 |
1 |
| 命令标识符（参见表3.39） |
命令选择 |
路由请求标识符 |
源地址 |
响应地址 |
路由开销 |
| 网络层载荷 |
|||||
图3.11路由应答命令帧格式
3.5.2.1MAC层数据服务请求
根据802.15.4协议标准，为了利用MAC层数据服务来传输该命令，在MAC层帧报头中应包含一下信息。
（1） 目的MAC层地址和PAN标识符分别设置为路由请求命令帧的发起端路由中第一跳的网络地址和PAN标识符。目的PAN标识符必须与命令起始端的PAN标识符相同。
（2） 源MAC地址和PAN标识符设置为发送路由应答命令的设备的地址和PAN标识符，该设备不一定为源命令发送的设备。
（3） 帧控制域设置为禁止MAC数据帧使用MAC层安全功能，因此任何来自于网络层的可靠的帧都使用网络层的安全协议。传输选择应设置为请求命令确认。地址模式以及内部PAN标记设置为支持这里所描述的地址域。
3.5.2.2网络层帧报头域
为了传送路由应答到目的地，并且使路由发现进程正确无误，必须提供下列信息：
（1） 网络层帧控制域中的帧类型子域应设置为表明此帧为网络层命令帧。
（2） 在网络层帧报头中的目的地址域应设置为回到相应路由请求的发起端路由的第一跳的网络地址。
（3） 网络层帧报头中的源地址应设置为传送此帧设备的网络层的16位网络地址。
（4） 网络层帧报头中的发现路由子域设置成抑制路由发现（参见表3.36）
（5） 作为一个网络层命令帧，帧控制域的源IEEE地址子域设置成1，且网络层帧头的源IEEE地址域存在且包含帧发送此帧设备的64位IEEE地址。如果试图发现的设备的64位IEEE地址已经知道，那么帧控制域的目的IEEE地址子域的值是1，且网络层帧头的目的IEEE地址域存在且包含所应答的路由请求命令帧的发送端的64位IEEE地址。
3.5.2.3网络层有效载荷域
网络层有效载荷域包含命令标识符、命令选择域、路由请求标识符域、源地址和应答地址和最新的路由开销总和。
命令标识符域包含表明路由应答命令帧的值。
3.5.2.3.1命令选择域
8bit的命令选择域的格式如图3.12所示。
| 比特：0-5 |
6 |
7 |
| 保留 |
多播域 |
保留 |
图3.12路由应答命令选择域格式
3.5.2.3.1.1多播子域
多播子域是1位。只有命令帧应答多播组路由时，它的值是1，在这个情况下，响应者地址域包含期望组的Group ID。
3.5.2.3.2路由请求标识符
路由请求标识符应长度是8位的所应答的路由请求帧序列号。
3.5.2.3.3源地址
源地址长度为2字节，包含所应答的路由请求命令帧发起端的16位的网络地址。
3.5.2.3.4响应地址
响应地址长度为2字节，且与相应的路由请求命令帧的目的地址域的值相同。
3.5.2.3.5路由成本
路由成本用来收集当路由应答命令帧穿梭于网络时链路成本。
3.5.3路由错误命令
当设备无法向前传送数据时，便使用路由错误命令。该命令通知发送数据帧源设备，在传送数据帧时出现错误。路由错误命令的载荷格式如图3.13所示。
| 字节：1 |
1 |
2 |
| 命令帧标识符（参见表3.39） |
错误代码 |
目的地址 |
图3.13路由错误命令帧格式
3.5.3.1MAC层数据服务要求
为了利用MAC层数据服务来传输该命令，根据802.15.4协议标准，应提供下列信息。
（1） 目的MAC层地址和PAN标识符应分别设置为出现传送故障的数据帧的发起端所经路由中第一跳的地址和PAN标识符。
（2） 源MAC层地址和PAN标识符应设置为发送路由错误命令的设备地址和PAN标识符。
（3） 帧控制域应设为使MAC数据帧禁止使用MAC安全功能，因此任何来自于网络层的可靠的帧都使用网络层的安全协议。是否执行发送该路由错误命令须取决于是否需要确认。
（4） 地址模式和内部PAN标记应设置为这里所描述的支持地址域。
3.5.3.2网络层帧报头域
为了传送路由错误命令帧，网络层帧报头中的地址域应为与出现传送错误数据帧的发起端地址相同。
网络层帧报头中的源地址应设置为发送路由错误命令的设备地址。
网络层帧报头中的发现路由子域应设置为抑制路由发现（参见表3.36）
3.5.3.3网络层载荷域
路由错误命令帧的网络层帧载荷域包含如下描述的命令标识符域、错误代码域和目的地址域。命令帧标识符域设置为为了描述如表3.39所定义的路由错误代码命令帧。
3.5.3.3.1错误代码
错误代码为表3.40所示的非保留值之一。
表3.40路由错误命令帧的错误代码
| 值 |
错误代码 |
| 0x00 |
无有效路由 |
| 0x01 |
树状态链路失败 |
| 0x02 |
非树状态链路失败 |
| 0x03 |
低电池电压 |
| 0x04 |
无路由能力 |
| 0x05 |
无间接能力 |
| 0x06 |
间接传送终止 |
| 0x07 |
目的设备没有获得 |
| 0x08 |
目的地址没有获得 |
| 0x09 |
父设备链路失败 |
| 0x0a |
有效路由 |
| 0x0b |
源路由失败 |
| 0x0c |
多对一路由失败 |
| 0x0d |
地址冲突 |
| 0x0e |
校验地址 |
| 0x0f |
PAN标识符更新 |
| 0x10-0xff |
保留 |
这些错误代码是表示错误代码命令帧的错误代码域的值和NLME-ROUTEERROR.indication原语的状态参数值。简单的解释如下：
（1） 无有效路由：路由发现和/或已经尝试修复和到目的地址没有发现路由。
（2） 树状态链路失败：帧沿树进行路由失败时，路由失败发生。
（3） 非树状态链路失败：尝试沿树路由的结果没有失败。
（4） 低电池电压：因为应答设备工作在低电压状态下，所以帧没有应答。
（5） 无路由能力：因为应答设备没有路由能力所以失败发生。
（6） 无间接能力：休眠终端子设备缓存该帧和应答设备没有足够的缓冲能力，所以失败发生。
（7） 间接传送终止：该帧代表休眠子设备time-out的结果缓存。
（8） 目的设备没有获得：响应设备的终端子设备由于一些原因没有获得。
（9） 目的地址没有获得：该帧是响应设备的终端子设备不存在的地址。
（10） 父设备链路失败：RF链路到设备的父设备失败。
（11） 有效路由：在目的地址域中多播路由标识符有效。
（12） 源路由失败：源路由失败可能表明源路由链路中的一个链路失败。
（13） 多对一路由失败：多对一的路由请求失败。
（14） 地址冲突：目的地址域的地址被两个或者更多设备使用。
（15） 校验地址：源地址在源IEEE地址域里有IEEE地址，且如果目的IEEE地址域存在，它包含的目的的期望的IEEE地址。
（16） PAN标识符更新：设备的操作网络PAN标识符已经更新。
3.5.3.3.2目的地址
目的地址长度为2字节，包含出现传送错误数据帧的目的地址。
3.5.4断开命令