zstack学习超强笔记Word下载.docx
《zstack学习超强笔记Word下载.docx》由会员分享,可在线阅读,更多相关《zstack学习超强笔记Word下载.docx(15页珍藏版)》请在冰豆网上搜索。
在Z-Stack1.4.1中一个设备的类型通常在编译的时候通过编译选项(ZDO_COORDINATOR和RTR_NWK)确定。
所有的应用例子都提供独立的项目文件来编译每一种设备类型。
2.2
栈配置(StackProfile)
栈参数的集合需要被配置为一定的值,连同这些值在一起被称之为栈配置。
ZigBee联盟定义了这些由栈配置组成的栈参数。
网络中的所有设备必须遵循同样的栈配置。
为了促进互用性这个目标,ZigBee联盟为ZigBee2006规范定义了栈配置。
所有遵循此栈配置的设备可以在其他开发商开发的遵循同样栈配置的网络中。
3.
寻址(Addressing)
3.1
地址类型(Addresstypes)
ZigBee设备有两种类型的地址。
一种是64位IEEE地址,即MAC地址,另一种是16位网络地址。
64位地址使全球唯一的地址,设备将在它的生命周期中一直拥有它。
它通常由制造商或者被安装时设置。
这些地址由IEEE来维护和分配。
16为网络地址是当设备加入网络后分配的。
它在网络中是唯一的,用来在网络中鉴别设备和发送数据。
3.2
网络地址分配(Networkaddressassignment)
ZigBee使用分布式寻址方案来分配网络地址。
这个方案保证在整个网络中所有分配的地址是唯一的。
这一点是必须的,因为这样才能保证一个特定的数据包能够发给它指定的设备,而不出现混乱。
同时,这个寻址算法本身的分布特性保证设备只能与他的父辈设备通讯来接受一个网络地址。
不需要整个网络范围内通讯的地址分配,这有助于网络的可测量性。
在每个路由加入网络之前,寻址方案需要知道和配置一些参数。
这些参数是MAX_DEPTH,MAX_ROUTERS和MAX_CHILDREN。
这些参数是栈配置的一部分,ZigBee2006协议栈已经规定了这些参数的值:
MAX_DEPTH=5,MAX_ROUTERS=6和MAX_CHILDREN=20。
MAX_DEPTH决定了网络的最大深度。
协调器(Coordinator)位于深度0,它的儿子位于深度1,他的儿子的的儿子位于深度2,以此类推。
MAX_DEPTH参数限制了网络在物理上的长度。
MAX_CHILDREN决定了一个路由(Router)或者一个协调器节点可以处理的儿子节点的最大个数。
MAX_ROUTER决定了一个路由(Router)或者一个协调器(Coordinator)节点可以处理的具有路由功能的儿子节点的最大个数。
这个参数是MAX_CHILDREN的一个子集,终端节点使用(MAX_CHILDREN–MAX_ROUTER)剩下的地址空间。
如果开发人员想改变这些值,则需要完成以下几个步骤:
首先,你要保证这些参数新的赋值要合法。
即,整个地址空间不能超过216,这就限制了参数能够设置的最大值。
可以使用projects\ZStack\tools文件夹下的CSkip.xls文件来确认这些值是否合法。
当在表格中输入了这些数据后,如果你的数据不合法的话就会出现错误信息。
当选择了合法的数据后,开发人员还要保证不再使用标准的栈配置,取而代之的是网络自定义栈配置(例如:
在nwk_globals.h文件中将STACK_PROFILE_ID改为NETWORK_SPECIFIC)。
然后nwk_globals.h文件中的MAX_DEPTH参数将被设置为合适的值。
此外,还必须设置nwk_globals.c文件中的Cskipchldrn数组和CskipRtrs数组。
这些数组的值由MAX_CHILDREN和MAX_ROUTER构成。
3.3
Z-Stack寻址(Addressinginz-stack)
为了向一个在ZigBee网络中的设备发送数据,应用程序通常使用AF_DataRequest()函数。
数据包将要发送给一个afAddrType_t(在ZComDef.h中定义)类型的目标设备。
typedefstruct
{
union
uint16shortAddr;
}addr;
afAddrMode_taddrMode;
byteendPoint;
}afAddrType_t;
注意,除了网路地址之外,还要指定地址模式参数。
目的地址模式可以设置为以下几个值:
typedefenum
afAddrNotPresent=AddrNotPresent,
afAddr16Bit=Addr16Bit,
afAddrGroup=AddrGroup,
afAddrBroadcast=AddrBroadcast
}afAddrMode_t;
因为在Zigbee中,数据包可以单点传送(unicast),多点传送(multicast)或者广播传送,所以必须有地址模式参数。
一个单点传送数据包只发送给一个设备,多点传送数据包则要传送给一组设备,而广播数据包则要发送给整个网络的所有节点。
这个将在下面详细解释。
3.3.1
单点传送(Unicast)
Uicast是标准寻址模式,它将数据包发送给一个已经知道网络地址的网络设备。
将afAddrMode设置为Addr16Bit并且在数据包中携带目标设备地址。
3.3.2
间接传送(Indirect)
当应用程序不知道数据包的目标设备在哪里的时候使用的模式。
将模式设置为AddrNotPresent并且目标地址没有指定。
取代它的是从发送设备的栈的绑定表中查找目标设备。
这种特点称之为源绑定。
当数据向下发送到达栈中,从绑定表中查找并且使用该目标地址。
这样,数据包将被处理成为一个标准的单点传送数据包。
如果在绑定表中找到多个设备,则向每个设备都发送一个数据包的拷贝。
上一个版本的ZigBee(ZigBee04),有一个选项可以讲绑定表保存在协调器(Coordinator)当中。
发送设备将数据包发送给协调器,协调器查找它栈中的绑定表,然后将数据发送给最终的目标设备。
这个附加的特性叫做协调器绑定(CoordinatorBinding)。
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
组寻址(GroupAddressing)
当应用程序需要将数据包发送给网络上的一组设备时,使用该模式。
地址模式设置为afAddrGroup并且addr.shortAddr设置为组ID。
在使用这个功能呢之前,必须在网络中定义组。
(参见Z-stackAPI文档中的aps_AddGroup()函数)。
注意组可以用来关联间接寻址。
再绑定表中找到的目标地址可能是是单点传送或者是一个组地址。
另外,广播发送可以看做是一个组寻址的特例。
下面的代码是一个设备怎样加入到一个ID为1的组当中:
aps_Group_tgroup;
//Assignyourselftogroup1
group.ID=0x0001;
group.name[0]=0;
//Thiscouldbeahumanreadablestring
aps_AddGroup(SAMPLEAPP_ENDPOINT,&
group);
3.4
重要设备地址(ImportantDeviceAdresses)
应用程序可能需要知道它的设备地址和父亲地址。
使用下面的函数获取设备地址(在ZStackAPI中定义):
l
NLME_GetShortAddr()——返回本设备的16位网络地址
NLME_GetExtAddr()——返回本设备的64位扩展地址
使用下面的函数获取该设备的父亲设备的地址:
NLME_GetCoordShortAddr()——返回本设备的父亲设备的16位网络地址
NLME_GetCoordExtAddr()——返回本设备的父亲设备的64位扩展地址
4.
绑定(Binding)
绑定是一种两个(或者多个)应用设备之间信息流的控制机制。
在ZigBee2006发布版本中,它被称为资源绑定,所有的设备都必须执行绑定机制。
绑定允许应用程序发送一个数据包而不需要知道目标地址。
APS层从它的绑定表中确定目标地址,然后将数据继续向目标应用或者目标组发送。
注意:
在ZigBee的1.0版本中,绑定表是保存在协调器(Coordinator当中)。
现在所有的绑定记录都保存在发送信息的设备当中。
4.1
建立绑定表(BuildingaBindingTable)
有三种方法可以建立一个绑定表:
ZigbeeDeviceObjectBindRequest——一个启动工具可以告诉设备创建一个绑定记录
ZigbeeDeviceObjectEndDeviceBindRequest——两个设备可以告诉协调器它们想要建立一个绑定表记录。
协调器来协调并在两个设备中创建绑定表记录。
DeviceApplication——一个设备上的应用程序建立或者管理一个绑定表
4.1.1
ZigBeeDeviceObjectBindingRequest
任何一个设备都可以发送一个ZDO信息给网络中的另一个设备,用来建立绑定表。
称之为援助绑定,它可以为一个发送设备创建一个绑定记录。
4.1.1.1
启动申请(TheCommissioningApplication)
一个应用程序可以通过ZDP_BindReq()函数(在ZDProfile.h),并在绑定表中包含两个请求(地址和终点)以及想要的群ID。
第一个参数(目标dstAddr)是绑定源的短地址即,16位网络地址。
确定你已经在ZDConfig.h允许了这个功能(ZDO_BIND_UNBIND_REQUEST)。
你也可以使用ZDP_UnbindReq()用同样的参数取消绑定记录。
目标设备发回ZigBeeDeviceObjectBind或者UnbindResponse信息,该信息是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
ZigBeeDeviceObjectEndDeviceBindRequest
这个机制是在指定的时间周期(timeoutperiod)内,通过按下选定设备上的按钮或者类似的动作来绑定。
协调器在指定的时间周期内,搜集终端设备的绑定请求信息,然后以配置ID(ProfileID)和群ID(ClusterID)协议为基础,创建一个绑定表记录作为结果。
默认的设备绑定时间周期(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终端设备中发现了匹配的请求,协调器将执行下面的步骤:
发送一个解除绑定请求给第一个设备。
这个终端设备锁定进程,这样解除绑定被首先发送来去掉一个已经存在的绑定记录。
等待ZDO解除绑定的响应,如果响应的状态是ZDP_NO_ENTRY,则发送一个ZDO绑定请求在源设备中创建一个绑定记录。
如果状态是ZDP_SUCCESS,则继续前进到第一个设备的群ID。
等待ZDO绑定响应,如果收到了,则继续前进到第一个设备的下一个群ID。
当地一个设备完成后,用同样的方法处理第二个设备。
当第二个设备也完成之后,发送ZDO终端设备绑定请求消息给两个设备。
4.1.1.3
DeviceApplicationBindingManager
另一种进入设备绑定记录的方式是应用自己管理绑定表。
这就意味着应用程序需要通过调用下面的绑定管理函数在本地进入并且删除绑定记录:
bindAddEntry()——在绑定表中增加一个记录
bindRemoveEntry()——从绑定表中删除一个记录
bindRomoveClusterIdFromList()——从一个存在的绑定表记录中删除一个群ID
bindAddClusterIdToList()——向一个已经存在的绑定记录中增加一个群ID
bindRemoveDev()——删除所有地址引用的记录
bindRemoveSrcDev()——删除所有源地址引用的记录
bindUpdateAddr()——将记录更新为另一个地址
bindFindExisting()——查找一个绑定表记录
bindIsClusterIdInList()——在表记录中检查一个已经存在的群ID
bindNumBoundTo()——拥有相同地址(源或者目的)的记录的个数
bindNumEntries()——表中记录的个数
bindCapacity()——最多允许的记录个数
bindWriteNV()——在NV中更新表
4.1.2
配置源绑定(ConfiguringSourceBinding)
为了在你的设备中使能源绑定在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)
Ameshnetworkisdescribedasanetworkinwhichtheroutingofmessagesisperformedasadecentralized,cooperativeprocessinvolvingmanypeerdevicesroutingoneachothers’behalf.
路由对与应用层来说是完全透明的。
应用程序只需简单的向下发送去往任何设备的数据到栈中,栈会负责寻找路径。
这种方法,应用程序不知道操作是在一个多跳的网络当中的。
路由还能够自愈ZigBee网络,如果某个无线连接断开了,路由功能又能自动寻找一条新的路径避开那个断开的网络连接。
这就极大的提高了网络的可靠性,同时也是ZigBee网络的一个关键特性。
5.2
路由协议(RoutingProtocol)
ZigBee执行基于用于AODV专用网络的路由协议。
简化后用于传感器网络。
ZigBee路由协议有助于网络环境有能力支持移动节点,连接失败和数据包丢失。
当路由器从他自身的应用程序或者别的设备那里收到一个单点发送的数据包,则网络层(NWKLayer)根据一下程序将它继续传递下去。
如果目标节点是它相邻路由器中的一个,则数据包直接被传送给目标设备。
否则,路由器将要检索它的路由表中与所要传送的数据包的目标地址相符合的记录。
如果存在与目标地址相符合的活动路由记录,则数据包将被发送到存储在记录中的下一级地址中去。
如果没有发现任何相关的路由记录,则路由器发起路径寻找,数据包存储在缓冲区中知道路径寻找结束。
ZigBee终端节点不执行任何路由功能。
终端节点要向任何一个设备传送数据包,它只需简单的将数据向上发送给它的父亲设备,由它的父亲设备以它自己的名义执行路由。
同样的,任何一个设备要给终端节点发送数据,发起路由寻找,终端节的的父亲节点都已它的名义来回应。
注意ZigBee地址分配方案使得对于任何一个目标设备,根据它的地址都可以得到一条路径。
在Z-Stack中,如果万一正常的路径寻找过程不能启动的话(通常由于缺少路由表空间),那么Z-Stack拥有自动回退机制。
此外,在Z-Stack中,执行的路由已经优化了路由表记录。
通常,每一个目标设备都需要一条路由表记录。
但是,通过把一定父亲节点记录与其子所有子结点的记录合并,这样既可以优化路径也可以不丧失任何功能。
ZigBee路由器,包括协调器执行下面的路由函数:
(i)路径发现和选择;
(ii)路径保持维护;
(iii)路径期满。
5.2.1
路径的发现和选择(RouteDiscoveryandSelection)
路径发现是网络设备凭借网络相互协作发现和建立路径的一个过程。
路由发现可以由任意一个路由设备发起,并且对于某个特定的目标设备一直执行。
路径发现机制寻找源地址和目标地址之间的所有路径,并且试图选择可能的最好的路径。
路径选择就是选择出可能的最小成本的路径。
每一个结点通常持有跟它所有邻接点的“连接成本(linkcosts)”。
通常,连接成本的典型函数是接收到的信号的强度。
沿着路径,求出所有连接的连接成本总和,便可以得到整个路径的“路径成本”。
路由算法试图寻找到拥有最小路径成本的路径。
路径通过一系列的请求和回复数据包被发现。
源设备通过向它的所有邻接节点广播一个路由请求数据包,来请求一个目标地址的路径。
当一个节点接收到RREQ数据包,它依次转发RREQ数据包。
但是在转发之前,它要加上最新的连接成本,然后更新RREQ数据包中的成本值。
这样,沿着所有它通过的连接,RREQ数据包携带着连接成本的总和。
这个过程一直持续到RREQ数据包到达目标设备。
通过不同的路由器,许多RREQ副本都将到达目标设备。
目标设备选择最好的RREQ数据包,然后发回一个路径答复数据包(aRouteReply)RREP给源设备。
RREP数据包是一个单点发送数据包,它沿着中间节点的相反路径传送直到它到达原来发送请求的节点为止。
一旦一条路径被创建,数据包就可以发送了。
当一个结点与它的下一级相邻节点失去了连接(当它发送数据时,没有收到MACACK),该节点向所有等待接收它的RREQ数据包的节点发送一个RERR数据包,将它的路径设为无效。
各个结点根据收到的数据包RREQ、RREP或者RERR来更新它的路由表。
5.2.2
路径保持维护(Routemaintenance)
网状网提供路径维护和网络自愈功能。
中间节点沿着连接跟踪传送失败,如果一个连接被认定是坏链,那么上游节点将针对所有使用这条连接的路径启动路径修复。
节点发起重新发现直到下一次数据包到达该节点,标志路径修复完成。
如果不能够启动路径发现或者由于某种原因失败了,节点则向数据包的源节点发送一个路径错误包(RERR),它将负责启动新路径的发现。
这两种方法,路径都自动重建。
5.2.3
路径期满(Routeexpiry)
路由表