cc2430学习7

yjbcnmdb

上节介绍了很大一部分Z-Stack的基础知识，这里接着忽悠。虽然说的不是很专业也不是很通俗，但是我尽力了，希望有人能看明白！本人英文水平有限，翻译的不好请谅解！
3、绑定
? 绑定是控制信息从一个应用层到另一个应用层流动的一种机制。在ZB06版本中，绑定机制在所有的设备中被执行。
? 绑定允许应用层发送信息不需要带目的地址，APS层确定目的地址从他的绑定表格中，然后在信息前端加上这个目的地址或组。
? 注意：在ZB1.0版本中，所有绑定条目存储在协调器中。现在所有绑定条目存储在发送数据的设备中。
3.1绑定一个绑定表格
? 有三种方式建立一个绑定表格：
? ZDO 绑定请求 – 一个试运转工具能告诉这个设备制作一个绑定报告。
? ZDO 终端设备绑定请求 – 2设备能告诉协调器他们想建立绑定表格报告。该协调器将使协调并在这两个设备上创建绑定表格条目
? 设备应用 – 在设备上的应用能建立或管理一个绑定表格 。
? 任何一个设备或应用能在网络中发送一个ZDO信息到另一个设备（）建立一个绑定报告。这是调用绑定帮助并且它将建立一个绑定条目为发送设备。
3.1.1 ZDO 绑定请求
? 通过调用函数ZDP_BindReq()发送一个绑定请求。第一个参数（dstAddr）
? 是绑定的源地址的短地址。
? 这之前应该确定允许绑定，在ZDConfig.h 文件中有参数[ZDO_BIND_UNBIND_REQUEST]允许绑定。
? 能用同样的参数调用函数ZDP_UnbindReq()移除绑定。
? 目标设备将调用函数ZDApp_BindRsp()或 ZDApp_UnbindRsp()，反馈绑定或移除绑定的响应，返回其操作状态为ZDP_SUCCESS, ZDP_TABLE_FULL或ZDP_NOT_SUPPORTED.
3.1.2 ZDO 终端设备绑定请求
该机制是用一个按钮按下或其他类似的动作来选择设备在指定时间内被绑定。在规定时间内，该终端设备绑定请求信息被收集到协调器，并创建一个基于模式（profile） ID 和串（cluster） ID的规定的绑定表格条目。默认的终端设备绑定超时时间（APS_DEFAULT_MAXBINDING_TIME）为16S（定义在nwk_globals.h中），但是能被改变
发送绑定请求
在所有的应用例子中有一个处理键盘事件的函数[例如在TransmitApp.c文件中的TransmitApp_HandleKeys()函数]。在该函数中，调用了函数ZDApp_SendEndDeviceBindReq()[在ZDApp.c中]，它将收集应用的终端设备的所有信息并调用函数ZDP_EndDeviceBindReq() [ZDProfile.c]，发送一个绑定信息到协调器。或者，在SampleLight 和 SampleSwitch例子中，直接调用ZDP_EndDeviceBindReq()函数就实现点亮/关闭灯的功能。
接收绑定请求
? 协调器将接收[ZDP_IncomingData() 在 ZDProfile.c]这些信息并分析处理[ZDO_ProcessEndDeviceBindReq() 在 ZDObject.c]这些信息并调用函数ZDApp_EndDeviceBindReqCB() [in ZDApp.c]，它将调用ZDO_MatchEndDeviceBind() [ZDObject.c]处理这个请求
? 当协调器接收到2个匹配终端色后备的绑定请求时，它将启动在绑定设备上创建源绑定条目的处理过程。该协调器有如下处理过程：
解除绑定
? 1. 发送一个ZDO解除绑定请求到第一个设备。终端设备绑定切换处理，所以解除绑定首先被发送到移除一个存在的绑定条目。
? 2. 等待ZDO解除绑定响应，如果响应状态为ZDP_NO_ENTRY, 发送一个ZDO绑定请求，在源设备上制作一个绑定条目 。如果该响应为ZDP_SUCCESS, 为第一个设备继续到move on to the cluster ID for the first device (the unbind removed the entry – toggle).
? 3. 等待ZDO绑定响应. When received, move on to the next cluster ID for the first device.
? 4. 当第一个设备完成时，对第二个设备做同样的处理。
? 5. 当第二个设备完成时，发送ZDO 终端设备绑定响应信息到第一个和第二个设备
3.1.3设备应用绑定管理
? 在设备上其他进入绑定条目的方式是应用层管理绑定表格。
? 意思是说，应用层将调用下列函数进入和移除绑定表格条目：
? bindAddEntry() –增加绑定表格条目
? bindRemoveEntry() – 从绑定表格中移除条目
? bindRemoveClusterIdFromList() – 从一个存在的绑定表格项目中移除一个串 ID 。
? bindAddClusterIdToList()——向一个已经存在的绑定记录中增加一个群ID
? bindRemoveDev()——删除所有地址引用的记录
? bindRemoveSrcDev()——删除所有源地址引用的记录
? bindUpdateAddr()——将记录更新为另一个地址
? bindFindExisting()——查找一个绑定表记录
? bindIsClusterIdInList()——在表记录中检查一个已经存在的群ID
? bindNumBoundTo()——拥有相同地址(源或者目的)的记录的个数
? bindNumEntries()——表中记录的个数
? bindCapacity()——最多允许的记录个数
? bindWriteNV()——在NV中更新表
3.2 配置源绑定
? 允许绑定源的编译选项REFLECTOR在f8wConfig.cfg文件中。在文件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的数量，绑定配置项目也影响地址管理器中的记录的个数。
4、路由
4.1 预览
? 在MESH网络中，为了使分布的节点间能够很好的通信，路由是非常重要的一个环节。
? 在应用层上路由是完全透明的。一个简单的应用数据发送到任意设备，下至协议栈，协议栈将负责发现一个路由路线。这个方式，应用层是不知道该操作在多跳网络中完成的事实。
? 路由使ZB网络具有“自动复原”的特性。如果一个无线连接断了，路由功能将自动的发现一个新的路由路线，该路线是避开（绕过）坏了的那个连接节点。这就提高了无线网络的可靠性，这也是ZB关键特点之一。
4.2 路由协议
? ZB执行的路由协议是基于AODV（Ad hoc On demand Distance Vector）的路由协议。作为一个简单的应用---传感器网络，ZB路由协议支持环境中的移动节点，连接失败和丢包功能。
? 当一个路由器接收到一个点对点信息包时，从他的应用或者从其他设备，NWK层将继续向前依照下面的进程。如果目的是路由器邻节点（包括它的子设备）之一，该信息包将直接传输到目的设备。另外的就是，路由器将检查它的路由表格，检查相应的信息包目的条目。如果在路由表格中有一个活跃的路由路线到该目的设备，那么该信息包将被转播到下一跳节点地址存储依照路由条目。如果没有活跃的条目发现，那么一个路由发现被启动并且该信息被缓存直到该过程完成。
ZB终端设备路由
? ZB终端设备不能执行任何路由功能。一个终端设备想发送一个信息包到任何设备都要向前到它的父设备，然后在由其父设备进行路由操作。类似的，任何设备想发送信息包到终端设备，都将发起一个路由发现操作，当然该操作都由终端设备的父设备响应。
? 注意：ZB地址分配方案使基于它的地址发起一个路由到任何目的成为可能。在Z-Sstack，这个机制被用于万一正规的路由程序不能被启动，作为一个自动退却（一般情况是由于路由表格空间不够）。
z-stack路由
? 在z-stack，执行的路由是已经被优化的路由存储表格。一般情况，对于每一个目的设备路由表格条目是需要的。但是通过综合携带父节点所有条目的特定父节点的终端设备的所有条目，没有任何功能丢失的存储已经被优化。
? ZB路由器，包括协调器，执行如下路由功能 (i)路由发现和选择 (ii) 路由维护(iii)
4.2.1路由发现和选择
? 路由发现是网络设备协作发现和建立路由的一个过程。一个路由操作总是针对某个目的，通过任何一个路由器启动。该路由发现机制在源设备和目的设备间搜寻所有可能的路由并试图选择最好的路由路线。
? 路由选择通过选择最小消耗的路由路线。每个设备在连接到邻节点几乎保持不变的“连接消耗”。该连接消耗是接收信号的强度的一个典型功能。沿着路由路线加起所有的连接消耗，就是整个路由的“连接消耗”。路由算法试图选择这个路由最小的“路由消耗”。
路由请求
路由通过请求/响应信息包被发现。一个源设备为了一个目的地址，通过发送一个广播路由请求（RREQ）信息到它的邻设备请求一个路由。当一个节点接收到一个RREQ信息时，它将依次转播这个RREQ信息。但是在做这个之前，它更新RREQ信息的消耗域，通过增加连接消耗为了最后的连接。这样，RREQ信息将携带向前传输的所有的连接消耗。这个重复过程直到RREQ到达这个目的设备。RREQ的一些复制可能经过不同的路径重复到达目的设备。该目的设备选择最好的RREQ信息并发送一个路由答复（RREP）返回到源设备。
路由响应
? RREP是沿着唯一的相反的路径返回到最初的请求节点。
? 作为RREP信息传播回源节点，中间的节点更新他们的路由表格，指出路由路线到目的设备。
? 一旦一个路由被创建，数据包能被发送。当一个节点丢失到它下一个节点的连通性时（发送数据包时，它不能接收一个MAC应答ACK），这个节点通过发送一个RERR到所有潜在的接收它RREP的节点，使该路由无效。在接收一个RREQ，RREP或RERR之上，这些节点都将更新他们的路由表格
4.2.2路由维护
MESH网络提供路由维护和自动修复。中间节点保持沿着连接传输失效的路径。如故一个连接被确定坏了，逆流的节点将启动路由修复那些连接的所有路由路线。这些工作通过启动路由重新发送被做，为了路由下一次数据包接收。如果路由重新发现不能启动，或者由于某些原因失败了，一个路由错误（RERR）信息被发送到这个数据包的源设备，然后重新启动新的路由发现。任意方式都使得该路由得到重新自动建立。
4.2.3路由终结
为了建立路由，路由表格条目要被维护。如果一段时间没有数据包沿着路由路线发送，该路由将被做终结记号。终止路由不是删除直到空间需要时。因此没有被删除直到它完全需要时。自动路由终结时间能被配置“在f8wconfig.cfg"文件中”。设置ROUTE_EXPIRY_TIME参数为终结时间（秒）。设置0为了关闭路由终结。
4.3 表格存储
? 路由功能需要路由器维护一些表格：
? 路由表格
? 路由发现表格
4.3.1路由表格
每一个路由器包括协调器都包含一个路由表。设备在路由表中保存数据包参与路由所需的信息。每一条路由表记录都包含有目的地址，下一级节点和连接状态。所有的数据包都通过相邻的一级节点发送到目的地址。同样，为了回收路由表空间，可以终止路由表中的那些已经无用的路径记录。
路由表的容量表明一个设备路由表拥有一个自由路由表记录或者说它已经有一个与目标地址相关的路由表记录。在文件“f8wConfig.cfg”文件中配置路由表的大小。将MAX_RTG_ENTRIES设置为表的大小(不能小于4)。
4.3.2路由发现表格
路由器设备致力于路径发现，保持维护路径发现表。这个表用来保存路径发现过程中的临时信息。这些记录只在路径发现操作期间存在。一旦某个记录到期，则它可以被另一个路径发现使用。这个值决定了在一个网络中，可以同时并发执行的路径发现的最大个数。这个可以在f8wConfig.cfg文件中配置MAX_ RREQ_ENTRIES。
4.4、路径设置快速参考
设置路由表大小 MAX_RTG_ENTRIES，这个值不能小于4 (f8wConfig.cfg文件)
设置路径期满时间 ROUTE_EXPIRY_TIME，单位秒。设置为零则关闭路径期满(f8wConfig.cfg文件)
设置路径发现表大小 MAX_RREQ_ENTRIES，网络中可以同时执行的路径发现操作的个数


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/73801/showart_1807655.html