afStatus_t ZDP_BindReq(zAddrType_t*dstAddr,byte*SourceAddr, byte SrcEPIntf,byte ClusterID,byte*DestinationAddr,byte DstEPIntf, byte SecuritySuite); 参数细节：
DstAddr-消息发送地址 （负责绑定的设备地址） SourceAddr–源节点的64位IEEE地址 SrcEPIntf–源节点应用服务的端点 ClusterID–需要绑定的簇标识符
DestinationAddr–目标节点的64位IEEE地址 DstEPIntf–目标节点应用服务的端点 SecuritySuite-安全机制模式 返回值：
afStatus_t–此函数需要借助AF发送（AF_DataRequest()）生成的消息，因此返回值是AF状态值。
? Zigbee Device Object End Device Bind Request–2 devices can tell the coordinator
that they would like to setup a binding table record.The coordinator will make the match up and create the binding table entries in the 2 devices.Or named Centralized Binding.
This mechanism uses a button press or other similar action at the selected devices to bind within a specific timeout period. The End Device Bind Request messages are collected at the coordinator within the timeout period and a resulting Binding Table entry is created based on the agreement of profile ID and cluster ID. The default end device binding timeout(APS_DEFAULT_MAXBINDING_TIME)is 16 seconds(defined in nwk_globals.h),but can be changed if added to f8wConfig.cfg.
You’ll notice that all sample applications have a function that handles key events[for example, TransmitApp_HandleKeys()in TransmitApp.c].This function calls ZDApp_SendEndDeviceBindReq()[in ZDApp.c],which gathers all the information for the application’s endpoint and calls ZDP_EndDeviceBindReq()[ZDProfile.c]to send the message to the coordinator.Or,as in SampleLight and SampleSwitch,ZDP_EndDeviceBindReq()is called directly with only the cluster IDs relevant to the lamp On/Off functions.
The coordinator will receive[ZDP_IncomingData()in ZDProfile.c]and parse [ZDO_ProcessEndDeviceBindReq()in ZDObject.c]the message and call ZDApp_EndDeviceBindReqCB()[in ZDApp.c],which calls ZDO_MatchEndDeviceBind()[ZDObject.c] to process the request. Coordinator receives and holds the request until a request from another node is received(16 seconds is the default).
When the coordinator receives 2 matching End Device Bind Requests,it will start the process of creating source binding entries in the requesting devices.The coordinator follows the following process,assuming matches were found in the ZDO End Device Bind Requests:
1.Send a ZDO Unbind Request to the first device.The End Device Bind is toggle process,so the unbind is sent first to remove an existing bind entry.
2.Wait for the ZDO Unbind Response,if the response status is ZDP_NO_ENTRY,send a Z
第 26 页 共 107 页
DO Bind Request to make the binding entry in the source device.If the response status is ZDP_SUCCESS,move on to the cluster ID for the first device(the unbind removed the entry–toggle).
3.Wait for the ZDO Bind Response.When received,move on to the next cluster ID for the first device.
4.When the first device is done,do the same process with the second device.
5.When the second device is done,send the ZDO End Device Bind Response messages to both the first and second device.
ZigBee设备对象终端节点绑定请求-两个设备可向协调器告知他们想建立一个绑定表记录。协调器通过安排配对并分别在这两个设备上建立绑定表条目，也称集中式绑定。
这一机制规定在指定的时限内，通过按键或者其他类似动作对指定的设备实施绑定。在规定的时限内，协调器负责收集终端设备绑定请求消息，然后根据相同的配置文件标识号和簇标识号建立相应的绑定表格条目。默认的终端节点绑定时限(APS_DEFAULT_MAXBINDING_TIME)是16秒(在nwk_globals.h中定义)，若要修改可在f8wConfig.cfg中新增数值。
所有例子的应用服务中都有一个响应按键事件的函数（例如，TransmitApp.c中的TransmitApp_HandleKeys()）。这一响应函数调用ZDApp_SendEndDeviceBindReq()[在 ZDApp.c中]收集该应用服务端点的所有信息，然后再调用ZDP_EndDeviceBindReq()[在ZDProfile.c中]把信息发送给协调器。或者，像SampleLight和SampleSwitch例程中，按键后直接调用ZDP_EndDeviceBindReq()，仅把与开关灯函数相关的簇标识号发送出去。
这一消息将会被协调器接收[ZDP_IncomingData()in ZDProfile.c]和解析[ZDO_ProcessEndDeviceBindReq()in ZDObject.c]，然后让回调函数ZDApp_EndDeviceBindReqCB()[in ZDApp.c]调用ZDO_MatchEndDeviceBind()[ZDObject.c]处理这一请求。 当协调器接收到第一个绑定请求时，他会在一定的时限内保留这一请求并等待第二个请求的出现。（默认的最长时间间隔是16秒）。
一旦协调器接收到两个需要匹配的终端设备绑定请求时，它就会启动绑定过程，为发出请求的设备建立源绑定条目。假设在ZDO终端设备绑定请求中找到匹配，协调器将采取以下步骤：
1. 协调器发送一个ZDO解除绑定请求给第一个设备。终端设备绑定是一个切换过程，所
以解除绑定请求需要发送给第一个设备，以便移除一个已有的绑定条目。 2. 等待ZDO解除绑定的应答，如果返回的状态是ZDP_NO_ENTRY，协调器可以发送一
个ZDO绑定请求，在源设备（ZDP_EndDeviceBindReq()第一个参数指定的地址）中建立绑定条目。假如此时返回的状态是ZDP_SUCCESS，可继续处理第一个设备的簇标识符（解除绑定指令已经移除了绑定条目，即已经切换完成）。
3. 等待ZDO绑定应答。收到以后，继续处理第一个设备的下一个簇标识符。 4. 等第一个设备完成了以后，在第二个设备上实行同样的过程。
5. 等第二个设备也完成了，协调器向两个设备发送ZDO终端设备绑定应答消息。
注意打开编译选项：REFLECTOR和ZDO_COORDINATOR
ZDApp_SendEndDeviceBindReq()
-Pro:The binding information resides on the network reflector device, saving RAM space o
第 27 页 共 107 页
n the target devices.
-Pro:The network reflector must be RxOnWhenIdle(always listening to the network).So if one of the bound devices broadcasts that its network address has changed,then the network reflector will update the corresponding binding table entry.Thus,even if the other bound device was sleeping,its subsequent messages to the changed device will still be correctly addressed by the network reflector.
-Con:A device that is bound to more than one other device cannot send a message to one or a subset of its matching devices–the reflector will generate a unicast message to all of the bound devices.
-Con:A sending device cannot receive notification of delivery to the destination device(i.e.the expected result when using the AF_ACK_REQUEST flag.)
-Con:All messages must go thru the network reflector, reducing network bandwidth.
-Pro/Con:A sending device bound to six devices will send one message to the network reflector which will result in the network reflector sending six unicast messages.Consider a network divided into two equal geographic regions,A and B,with the network reflector on the centerline.If the sending device is deep into region A and the receiving devices are deep into region B,then for every message sent, network traffic in region A will be six times less than it would be if the sending device has generated six instead of one trans-network messages.If all devices are nearby each other,deep in one region,then network traffic in that region is very much more than if the sending device could just send single hop messages to the intended recipients.
ZDApp_SendEndDeviceBindReq() 优点：
1. 绑定信息保存在网络反射设备（例如协调器、路由器）中，可以节省目标设备的内存空
间。
2. 网络反射设备总是处于监听网络的状态。所以，如果其中一个被绑定的节点广播网络地
址改变的消息，网络反射设备就可以马上更新相应的绑定表条目。这样，其他被绑定的节点即使处于休眠状态（没有收到该节点网络地址改变的消息），随后向该节点（网络地址已改变）发送的消息，（在）网络反射设备（协助下）仍能准确定位。 缺点：
1. 一个与多个设备绑定的节点不能只向一个或若干个配对的设备发送消息。网络反射设备
会向全部已绑定的设备本别发送单播消息。
2. 发送消息的设备无法收到目标设备接收情况的通告。（没有像AF_ACK_REQUEST标
志位那样返回接收情况的功能！）
3. 所有的消息必须经过网络反射设备传输，降低了网络的带宽。
进一步分析：
与六个设备绑定的某个设备，向网络反射器发送一个消息后，会导致反射器发送六个单播消息。假设一个网络被分成两个相等的地理区域A和B，网络反射器在两区之间的中央。如果发送消息的设备在A区的深处，接收消息的（六个）设备在B区的深处，那么每次通过绑定（向反射器）发送一个消息，A区的网络流量将会是对六个接收设备分别发送消息时的六分之一。（这是优点！）但如果发送和接收的设备都邻近在一个区的深处（假设离反射器很远），那么（其中一个设备通过反射器的绑定功能想其他设备发送一个消息）该区的网络
第 28 页 共 107 页
流量将会是对六个接收设备分别发送单跳消息的许多倍。（这是缺点！）
? Device Application–An application on the device can build or ma
nage a binding table. Another way to enter binding entries on the device is for the application to manage the binding table for itself.
Meaning that the application will enter and remove binding table entries locally by calling the following binding table management functions(ref.ZStack API Document–Binding Table Management section)
bindAddEntry()–Add entry to binding table
bindRemoveEntry()–Remove entry from binding table bindRemoveClusterIdFromList()
–Remove a cluster ID from an existing binding table entry bindAddClusterIdToList()
–Add a cluster ID to an existing binding table entry
bindRemoveDev()–Remove all entries with an address reference bindRemoveSrcDev()
–Remove all entries with a referenced source address bindUpdateAddr()–Update entries to another address bindFindExisting()–Find a binding table entry bindIsClusterIDinList()
–Check for an existing cluster ID in a table entry bindNumBoundTo()
–Number of entries with the same address(source or destination) bindNumOfEntries()–Number of table entries bindCapacity()–Maximum entries allowed BindWriteNV()–Update table in NV.
设备的应用服务-设备上的一个应用服务可以建立或者维护一个绑定表。进入设备上绑定条目的另一种方法是由应用服务本身去管理绑定表。 这意味着应用服务通过调用以下的绑定表管理函数，可以在本地进入或者移除绑定表的条目。
管理绑定表使用的API：
bindAddEntry()–绑定表中加条目
bindRemoveEntry()–绑定表中移除条目
bindRemoveClusterIdFromList()–从一个已有的绑定表条目中移除一个簇标识符 bindAddClusterIdToList()–在一个已有的绑定表条目中加入一个簇标识符 bindRemoveDev()–移除某目标地址的所有条目 bindRemoveSrcDev()–移除某源地址的所有条目 bindUpdateAddr()–更新条目到新的地址 bindFindExisting()–查找一个绑定条目
第 29 页 共 107 页
bindIsClusterIDinList()–在绑定条目中查找一个已有的簇标识符
bindNumBoundTo()–某一地址（源地址或目标地址）绑定条目的个数 bindNumOfEntries()–绑定表条目的个数 bindCapacity()–允许的最大绑定条目数 BindWriteNV()–在NV中保存新的绑定表
Which Binding Method To Use? 我们应该选择哪一种绑定方式？
Automatic
+no user interaction required +no tool cost
-development time knowledge -non-configurable Assisted
+install-time decisions(site-specific knowledge) +analysis,maintenance,modification,visualization can be under installers control -cost of tool Centralized
+allows user to decide +cost of tool minimal
-few,if any,configurable parameters
-requires a user interface on each device Application
+maximum flexibility
-you must write all the code
Some further discussion from TI E2E COMMUNITY
1. The nomenclature \Device Bind Req\is misleading. This doesn't just apply to end devices... but rather puts the binding logic of matching clusters between two devices that wish to bind on the coordinator. When this function is invoked, assuming all devices that wish to use this service have REFLECTOR turned on, here is what happens:
a. (Bind Req) Device 1 --> Coordinator <--- Device 2 (Bind Req)
Coordinator looks at the cluster contained in the bind req, compares the IEEE of each device, and if the clusters match, and no binding table already exists for these IEEEs then it will send a bind response back to each device.
After step a, you will see in the packet sniffer, step b:
b. Device 1 <--- NWK Addr Req ------ Coordinator ------- NWK addr Req ----> Device 2
c. Device 1 ----> NWK Addr Rsp ---> Coordinator <---- NWK addr Rsp <--- Device 2
第 30 页 共 107 页