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.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协调器的角 {MOD}。网络管理做如下处理：
允许为网络信道列表的规定扫描程序。缺省值是规定在已选择的操作联合的所有信道的使用。
管理网络扫描程序来确定邻居网络和它们协调器和路由器的一致性。
允许一个信道的选择来启动一个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
处理操作功能

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。否则，状态参数为错误状态。