ZigBee四種綁定 在TI Z-Stack協議棧中應用
BindingTable
綁定表
1.綁定表存放的位置是內存中預先定義的塊，如果編譯選項NV_RESTORE被激活，也能保存在Flash里。
2.綁定表放置在源節點（需要激活編譯選項REFLECTOR）。
3.綁定表的條目把需要發送的消息映射到它們的目標地址上。
4.綁定表中每個條目包括以下內容：
5.綁定表條目結構體的定義
typedefstruct
{
uint16srcIdx;//源地址索引
uint8srcEP;//源端點
uint8dstGroupMode;//指定尋址模式
uint16dstIdx;//目標地址索引或者分組號
uint8dstEP;//目標端點
uint8numClusterIds;//在簇標識符表中簇標識符的個數
uint16clusterIdList[MAX_BINDING_CLUSTER_IDS];//簇標識符表
}BindingEntry_t;
SimpleDescription---Howtobinddevices
概述---怎樣綁定節點
綁定指的是兩個節點在應用層上建立起來的一條邏輯鏈路。在同一個節點上可以建立多個綁定服務，分別對應不同種類的數據包。此外，綁定也允許有多個目標節點（一對多綁定）。
舉個例子，在一個燈光網絡中，有多個開關和燈光設備，每一個開關可以控制一個或以上的燈光設備。在這種情況下，需要在每個開關中建立綁定服務。這使得開關中的應用服務在不知道燈光設備確切的目標地址時，可以順利地向燈光設備發送數據包。
一旦在源節點上建立了綁定，其應用服務即可向目標節點發送數據，而不需指定目標地址了（調用zb_SendDataRequest()，目標地址可用一個無效值0xFFFE代替）。這樣，協議棧將會根據數據包的命令標識符，通過自身的綁定表查找到所對應的目標設備地址。
在綁定表的條目中，有時會有多個目標端點。這使得協議棧自動地重復發送數據包到綁定表指定的各個目標地址。同時，如果在編譯目標文件時，編譯選項NV_RESTORE被打開，協議棧將會把綁定條目保存在非易失性存儲器里。因此當意外重啟（或者節點電池耗盡需要更換）等突發情況的發生時，節點能自動恢復到掉電前的工作狀態，而不需要用戶重新設置綁定服務。
配置設備綁定服務，有兩種機制可供選擇。如果目標設備的擴展地址（64位地址）已知，可通過調用zb_BindDeviceRequest()建立綁定條目。如果目標設備的擴展地址未知，可實施一個“按鍵”策略實現綁定。這時，目標設備將首先進入一個允許綁定的狀態，并通過zb_AllowBindResponse()對配對請求作出響應。然后，在源節點中執行zb_BindDeviceRequest()（目標地址設為無效）可實現綁定。
此外，使用節點外部的委托工具（通常是協調器）也可實現綁定服務。請注意，綁定服務只能在“互補”設備之間建立。那就是，只有分別在兩個節點的簡單描述結構體（simpledescriptorstructure）中，同時注冊了相同的命令標識符（command_id）并且方向相反（一個屬于輸出指令“output”，另一個屬于輸入指令“input”），才能成功建立綁定。
Thereare4waystobuildabindingtable:
建立一個綁定表格有四種方法可供選擇：
自動綁定
一、負責發送消息的設備在網絡上廣播帶有如下參數的“個人公告”（PersonalAdvertisement）：
（1）地址，配置文件標識符，簇集合列表；
（2）描述符匹配請求-ZDP_MatchDescReq()。
二、匹配的設備會作出響應。
三、由ZDO處理和驗證響應
四、負責發送消息的設備建立綁定表并保存綁定記錄。
五、這種方法有時也稱“服務發現”，“自動找尋”或者“自動匹配”。
ZigBee設備對象綁定請求-一種告訴目標設備建立綁定記錄的委托工具，也稱輔助綁定。
任何一個設備或應用服務，都能通過無線信道向網絡上的另一個設備發送一個ZDO消息，幫助其建立一個綁定記錄。這稱為輔助綁定，在消息發向的設備上會建立一個綁定條目。
委托綁定的申請：
任一個應用服務，通過向ZDP_BindReq()[definedinZDProfile.h]提供綁定記錄所需要的應用服務入口參數（地址和端點）以及簇標識號（clusterID），即可啟動委托綁定的申請。第一個參數（消息發送目標地址）是綁定源節點的短地址（即保存綁定記錄的節點地址，這是因為ZDP需委托應用框架AF輔助實現綁定，如果節點本身是REFLECTOR，并且希望保存綁定記錄，則此消息發送的目標地址就是本地的AF，這與目標節點的地址DestinationAddrofReceivingdevice不同）。
注意事項：
確保[ZDConfig.h]中ZDO_BIND_UNBIND_REQUEST特性已經打開！
你可以通過ZDP_UnbindReq()（使用相同參數）來移除綁定記錄。
被請求輔助綁定的目標設備會返回的ZDO申請綁定或者解除綁定的應答消息。此ZDO消息會被解析并通過調用ZDApp_BindRsp()或ZDApp_UnbindRsp()告知ZDApp.c此次請求的結果。
對于申請綁定的應答消息，從協調器返回的狀態可能有ZDP_SUCCESS,ZDP_TABLE_FULLorZDP_NOT_SUPPORTED。
對于解除綁定的應答消息，從協調器返回的狀態可能有ZDP_SUCCESS,ZDP_NO_ENTRYorZDP_NOT_SUPPORTED。
綁定是由外部的設備發起（“外部”的意思是發起綁定的不是綁定的對象之一）。
外部設備應用程序以兩個應用服務（地址和端點）和簇標識符作為參數調用ZDP_BindReq()發起綁定。第一個參數就是綁定記錄保存的設備地址。
確保編譯選項REFLECTOR已經打開！
函數解析：
ZDP_BindReq()實際上是調用ZDP_BindUnbindReq()的一個宏。這一調用會產生并發送一個綁定的請求，使得ZigBee協調器根據簇標識號clusterID對相應的應用服務實施綁定。
函數原型：
afStatus_tZDP_BindReq(zAddrType_t*dstAddr,byte*SourceAddr,byteSrcEPIntf,byteClusterID,byte*DestinationAddr
,byteDstEPIntf,byteSecuritySuite)
參數細節：
DstAddr-消息發送地址（負責綁定的設備地址）
SourceAddr–源節點的64位IEEE地址
SrcEPIntf–源節點應用服務的端點
ClusterID–需要綁定的簇標識符
DestinationAddr–目標節點的64位IEEE地址
DstEPIntf–目標節點應用服務的端點
SecuritySuite-安全機制模式
返回值：afStatus_t–此函數需要借助AF發送（AF_DataRequest()）生成的消息，因此返回值是AF狀態值。
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()inZDProfile.c]和解析[ZDO_ProcessEndDeviceBindReq()inZDObject.c]，然后讓回調函數ZDApp_EndDeviceBindReqCB()[inZDApp.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()
優點：
1.綁定信息保存在網絡反射設備（例如協調器、路由器）中，可以節省目標設備的內存空間。
2.網絡反射設備總是處于監聽網絡的狀態。所以，如果其中一個被綁定的節點廣播網絡地址改變的消息，網絡反射設備就可以馬上更新相應的綁定表條目。這樣，其他被綁定的節點即使處于休眠狀態（沒有收到該節點網絡地址改變的消息），隨后向該節點（網絡地址已改變）發送的消息，（在）網絡反射設備（協助下）仍能準確定位。
缺點：
1.一個與多個設備綁定的節點不能只向一個或若干個配對的設備發送消息。網絡反射設備會向全部已綁定的設備本別發送單播消息。
2.發送消息的設備無法收到目標設備接收情況的通告。（沒有像AF_ACK_REQUEST標志位那樣返回接收情況的功能！）
3.所有的消息必須經過網絡反射設備傳輸，降低了網絡的帶寬。
進一步分析：
與六個設備綁定的某個設備，向網絡反射器發送一個消息后，會導致反射器發送六個單播消息。假設一個網絡被分成兩個相等的地理區域A和B，網絡反射器在兩區之間的中央。如果發送消息的設備在A區的深處，接收消息的（六個）設備在B區的深處，那么每次通過綁定（向反射器）發送一個消息，A區的網絡流量將會是對六個接收設備分別發送消息時的六分之一。（這是優點?。┑绻l送和接收的設備都鄰近在一個區的深處（假設離反射器很遠），那么（其中一個設備通過反射器的綁定功能想其他設備發送一個消息）該區的網絡流量將會是對六個接收設備分別發送單跳消息的許多倍。（這是缺點?。?/p>
設備的應用服務-設備上的一個應用服務可以建立或者維護一個綁定表。進入設備上綁定條目的另一種方法是由應用服務本身去管理綁定表。
這意味著應用服務通過調用以下的綁定表管理函數，可以在本地進入或者移除綁定表的條目。
管理綁定表使用的API：
bindAddEntry()–綁定表中加條目
bindRemoveEntry()–綁定表中移除條目
bindRemoveClusterIdFromList()–從一個已有的綁定表條目中移除一個簇標識符
bindAddClusterIdToList()–在一個已有的綁定表條目中加入一個簇標識符
bindRemoveDev()–移除某目標地址的所有條目
bindRemoveSrcDev()–移除某源地址的所有條目
bindUpdateAddr()–更新條目到新的地址
bindFindExisting()–查找一個綁定條目
bindIsClusterIDinList()–在綁定條目中查找一個已有的簇標識符
bindNumBoundTo()–某一地址（源地址或目標地址）綁定條目的個數
bindNumOfEntries()–綁定表條目的個數
bindCapacity()–允許的最大綁定條目數
BindWriteNV()–在NV中保存新的綁定表
WhichBindingMethodToUse?
我們應該選擇哪一種綁定方式？
Automatic
+nouserinteractionrequired
+notoolcost
-developmenttimeknowledge
-non-configurable
Assisted
+install-timedecisions(site-specificknowledge)
+analysis,maintenance,modification,visualization
canbeunderinstallerscontrol
-costoftool
Centralized
+allowsusertodecide
+costoftoolminimal
-few,ifany,configurableparameters
-requiresauserinterfaceoneachdevice
Application
+maximumflexibility
-youmustwriteallthecode
【編輯推薦】
