原文轉自：http://blog.chinaunix.net/uid-20788636-id-1841397.html
一、 綁定
本文是作者根據TI Z-Stack開發文檔，ZigBee Specification-2007，《Zigbee WirelessNetworking》等英文資料整合和翻譯而成，採用中英雙語對照方便讀者理解，文中翻譯不當之處，望廣大同行不吝賜教。推廣ZigBee技術，提高國內電子行業的國際影響力，是我們無線通訊工程師的願景。本文歡迎轉載，請保留作者信息和出處，作爲支持我繼續努力前行的動力，謝謝！
E-mail:[email protected]
ZigBee2006版本中規定，在全部節點中實現綁定機制，並將其稱爲源綁定。綁定機制允許一個應用服務在不知道目標地址的情況下向對方（的應用服務）發送數據包。發送時使用的目標地址將由應用支持子層（APS）從綁定表中自動獲得，從而能使消息順利被目標節點的一個或多個應用服務，乃至分組接收。
Binding Table
1.Defined in RAM,but can be saved in Flash if theNV_RESTORE compiler option is used
2.Stored on source node(REFLECTOR compiler optionrequired)
3.Entries map messages to their intended destination
4.Each entry in the binding table contains thefollowing:
typedef struct
{
uint16srcIdx;//Source index
uint8srcEP;//Source endpoint
uint8dstGroupMode;//Specifies normal or group addressing
uint16dstIdx;//Destination index or group address
uint8dstEP;//Destination endpoint
uint8numClusterIds;//Number of cluster IDs in the clusterIdList below
uint16clusterIdList[MAX_BINDING_CLUSTER_IDS];
}BindingEntry_t;
綁定表
1. 綁定表存放的位置是內存中預先定義的RAM塊，如果編譯選項NV_RESTORE被激活，也能保存在Flash裏。
2. 綁定表放置在源節點（需要激活編譯選項REFLECTOR）。
3. 綁定表的條目把需要發送的消息映射到它們的目標地址上。
4. 綁定表中每個條目（entry）包括以下內容：
綁定表條目結構體的定義
typedef struct
{
uint16srcIdx; //源地址索引
uint8srcEP; //源端點
uint8dstGroupMode; //指定尋址模式
uint16dstIdx; //目標地址索引或者分組號
uint8dstEP; //目標端點
uint8numClusterIds; //在簇標識符表中簇標識符的個數
uint16clusterIdList[MAX_BINDING_CLUSTER_IDS]; //簇標識符表
}BindingEntry_t;1、 概述---怎樣綁定節點
（1） 定義：綁定指的是兩個節點在應用層上建立起來的一條邏輯鏈路。在同一個節點上可以建立多個綁定服務，分別對應不同種類的數據包。此外，綁定也允許有多個目標節點（一對多綁定）。
舉個例子，在一個燈光網絡中，有多個開關和燈光設備，每一個開關可以控制一個或以上的燈光設備。在這種情況下，需要在每個開關中建立綁定服務。這使得開關中的應用服務在不知道燈光設備確切的目標地址時，可以順利地向燈光設備發送數據包。
（2） 作用：一旦在源節點上建立了綁定，其應用服務即可向目標節點發送數據，而不需指定目標地址了（調用zb_SendDataRequest()，目標地址可用一個無效值0xFFFE代替）。這樣，協議棧將會根據數據包的命令標識符，通過自身的綁定表查找到所對應的目標設備地址。在綁定表的條目中，有時會有多個目標端點。這使得協議棧自動地重複發送數據包到綁定表指定的各個目標地址。同時，如果在編譯目標文件時，編譯選項NV_RESTORE被打開，協議棧將會把綁定條目保存在非易失性存儲器裏。因此當意外重啓（或者節點電池耗盡需要更換）等突發情況的發生時，節點能自動恢復到掉電前的工作狀態，而不需要用戶重新設置綁定服務。
（3） 配置設備綁定服務，有兩種機制可供選擇：
1、 如果目標設備的擴展地址（64位地址）已知，可通過調用zb_BindDeviceRequest()建立綁定條目。
2、 如果目標設·備的擴展地址未知，可實施一個“按鍵”策略實現綁定。這時，目標設備將首先進入一個允許綁定的狀態，並通過zb_AllowBindResponse()對配對請求作出響應。然後，在源節點中執行zb_BindDeviceRequest()（目標地址設爲無效）可實現綁定。
此外，使用節點外部的委託工具（通常是協調器）也可實現綁定服務。請注意，綁定服務只能在“互補”設備之間建立。那就是，只有分別在兩個節點的簡單描述結構體（simpledescriptor structure）中，同時註冊了相同的命令標識符（command_id）並且方向相反（一個屬於輸出指令“output”，另一個屬於輸入指令“input”），才能成功建立綁定。
2、 建立一個綁定表格有四種方法可供選擇：
1）自動綁定
1. 負責發送消息的設備在網絡上廣播帶有如下參數的“個人公告”（Personal Advertisement）：
（1）地址(Address)；配置文件標識符(Profile ID)；簇集合列表(Cluster Lists)；
（2）描述符匹配請求-ZDP_MatchDescReq()
2. 匹配的設備會作出響應。
3. 由ZDO處理和驗證響應。
4. 負責發送消息的設備建立綁定表並保存綁定記錄。
5. 這種方法有時也稱“服務發現”，“自動找尋”或者“自動匹配”。
ZigBee設備對象綁定請求-一種告訴目標設備建立綁定記錄的委託工具，也稱輔助綁定。
任何一個設備或應用服務，都能通過無線信道向網絡上的另一個設備發送一個ZDO消息，幫助其建立一個綁定記錄。這稱爲輔助綁定，在消息發向的設備上會建立一個綁定 條目。
2）委託綁定的申請：
任一個應用服務，通過向ZDP_BindReq()[definedin ZDProfile.h]提供綁定記錄所需要的應用服務入口參數（地址和端點）以及簇標識號（clusterID），即可啓動委託綁定的申請。第一個參數（消息發送目標地址）是綁定源節點的短地址（即保存綁定記錄的節點地址，這是因爲ZDP需委託應用框架AF輔助實現綁定，如果節點本身是REFLECTOR，並且希望保存綁定記錄，則此消息發送的目標地址就是本地的AF，這與目標節點的地址DestinationAddr of Receiving device不同）。
l 注意事項：
l 確保[ZDConfig.h]中ZDO_BIND_UNBIND_REQUEST特性已經打開！
l 你可以通過ZDP_UnbindReq()（使用相同參數）來移除綁定記錄。
l 被請求輔助綁定的目標設備會返回的ZDO申請綁定或者解除綁定的應答消息。此ZDO消息會被解析並通過調用ZDApp_BindRsp()或ZDApp_UnbindRsp()告知ZDApp.c此次請求的結果。
l 對於申請綁定的應答消息，從協調器返回的狀態可能有ZDP_SUCCESS,ZDP_TABLE_FULL or ZDP_NOT_SUPPORTED。
l 對於解除綁定的應答消息，從協調器返回的狀態可能有ZDP_SUCCESS,ZDP_NO_ENTRY or ZDP_NOT_SUPPORTED。
l 綁定是由外部的設備發起（“外部”的意思是發起綁定的不是綁定的對象之一）。
l 外部設備應用程序以兩個應用服務（地址和端點）和簇標識符作爲參數調用ZDP_BindReq ()發起綁定。第一個參數就是綁定記錄保存的設備地址。委託綁定。
l 確保編譯選項REFLECTOR已經打開！
3、 函數解析：
a) ZDP_BindReq()
實際上是調用ZDP_BindUnbindReq()的一個宏。這一調用會產生併發送一個綁定的請求，使得ZigBee協調器根據簇標識號clusterID對相應的應用服務實施綁定。
函數原型：
afStatus_t ZDP_BindReq(zAddrType_t*dstAddr,byte*SourceAddr,
byte SrcEPIntf,byte ClusterID,byte*DestinationAddr,byte DstEPIntf,
byte SecuritySuite);
參數細節：
DstAddr-消息發送地址 （負責綁定的設備地址，本地的AF）-參見上面委託綁定
SourceAddr–源節點的64位IEEE地址
SrcEPIntf–源節點應用服務的端點
ClusterID–需要綁定的簇標識符
DestinationAddr–目標節點的64位IEEE地址
DstEPIntf–目標節點應用服務的端點
SecuritySuite-安全機制模式
返回值：
afStatus_t–此函數需要藉助AF發送（AF_DataRequest()）生成的消息，因此返回值是AF狀態值。
ZigBee設備對象終端節點綁定請求-兩個設備可向協調器告知他們想建立一個綁定表記錄。協調器通過安排配對並分別在這兩個設備上建立綁定表條目，也稱集中式綁定。
這一機制規定在指定的時限內，通過按鍵或者其他類似動作對指定的設備實施綁定。在規定的時限內，協調器負責收集終端設備綁定請求消息，然後根據相同的配置文件標識號(profile id)和簇標識號(cluster id)建立相應的綁定表格條目。默認的終端節點綁定時限(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()[inZDObject.c]處理這一請求。
當協調器接收到第一個綁定請求時，他會在一定的時限內保留這一請求並等待第二個請求的出現。（默認的最長時間間隔是16秒）。
一旦協調器接收到兩個需要匹配的終端設備綁定請求時，它就會啓動綁定過程，爲發出請求的設備建立源綁定條目。假設在ZDO終端設備綁定請求中找到匹配，協調器將採取以下步驟：
（1） 協調器發送一個ZDO解除綁定請求給第一個設備。終端設備綁定 是一個切換過程，所以解除綁定請求需要發送給第一個 設備，以便移除一個已有的綁定條目。
（2） 等待ZDO解除綁定的應答，如果返回的狀態是ZDP_NO_ENTRY（沒有已存在的綁定），協調器可以發送一個ZDO綁定請求，在源設備（ZDP_EndDeviceBindReq()第一個參數指定的地址）中建立綁定條目。假如此時返回的狀態是ZDP_SUCCESS，可繼續處理第一個設備的簇標識符（解除綁定指令已經移除了綁定條目，即已經切換完成）。
（3） 等待ZDO綁定應答。收到以後，繼續處理第一個設備的下一個簇標識符。
（4） 等第一個設備完成了以後，在第二個設備上實行同樣的過程。
（5） 等第二個設備也完成了，協調器向兩個設備發送ZDO終端設備綁定應答消息。
注意打開編譯選項：REFLECTOR和ZDO_COORDINATOR
b) ZDApp_SendEndDeviceBindReq()
優點：
1. 綁定信息保存在網絡反射設備（例如協調器、路由器）中，可以節省目標設備的內存空間。
2. 網絡反射設備總是處於監聽網絡的狀態。所以，如果其中一個被綁定的節點廣播網絡地址改變的消息，網絡反射設備就可以馬上更新相應的綁定表條目。這樣，其他被綁定的節點即使處於休眠狀態（沒有收到該節點網絡地址改變的消息），隨後向該節點（網絡地址已改變）發送的消息，（在）網絡反射設備（協助下）仍能準確定位。
缺點：
1. 一個與多個設備綁定的節點不能只向一個或若干個配對的設備發送消息。網絡反射設備會向全部已綁定的設備本別發送單播消息。
2. 發送消息的設備無法收到目標設備接收情況的通告。（沒有像AF_ACK_REQUEST標誌位那樣返回接收情況的功能！）
3. 所有的消息必須經過網絡反射設備傳輸，降低了網絡的帶寬。
進一步分析：
與六個設備綁定的某個設備，向網絡反射器發送一個消息後，會導致反射器發送六個單播消息。假設一個網絡被分成兩個相等的地理區域A和B，網絡反射器在兩區之間的中央。如果發送消息的設備在A區的深處，接收消息的（六個）設備在B區的深處，那麼每次通過綁定（向反射器）發送一個消息，A區的網絡流量將會是對六個接收設備分別發送消息時的六分之一。（這是優點！）但如果發送和接收的設備都鄰近在一個區的深處（假設離反射器很遠），那麼（其中一個設備通過反射器的綁定功能向其他設備發送一個消息）該區的網絡流量將會是對六個接收設備分別發送單跳消息的許多倍。（這是缺點！）
設備的應用服務-設備上的一個應用服務可以建立或者維護一個綁定表。進入設備上綁定條目的另一種方法是由應用服務本身去管理綁定表。
這意味着應用服務通過調用以下的綁定表管理函數，可以在本地進入或者移除綁定表的條目。
管理綁定表使用的API：
1. bindAddEntry()–綁定表中加條目
2. bindRemoveEntry()–綁定表中移除條目
3. bindRemoveClusterIdFromList()–從一個已有的綁定表條目中移除一個簇標識符
4. bindAddClusterIdToList()–在一個已有的綁定表條目中加入一個簇標識符
5. bindRemoveDev()–移除某目標地址的所有條目
6. bindRemoveSrcDev()–移除某源地址的所有條目
7. bindUpdateAddr()–更新條目到新的地址
8. bindFindExisting()–查找一個綁定條目
9. bindIsClusterIDinList()–在綁定條目中查找一個已有的簇標識符
10. bindNumBoundTo()–某一地址（源地址或目標地址）綁定條目的個數
11. bindNumOfEntries()–綁定表條目的個數
12. bindCapacity()–允許的最大綁定條目數
13. BindWriteNV()–在NV中保存新的綁定表
我們應該選擇哪一種綁定方式？
二、 來自TI E2E社區的進一步討論：
1、“終端設備綁定請求”這一命名有誤導的嫌疑。這一請求不僅僅適用於終端設備，而且適用於對希望在協調器上綁定的兩個設備中匹配的簇實施綁定。一旦這個函數被調用，將假設REFLECTOR這一編譯選項在所有希望使用這一服務的節點中都已經打開。具體操作如下：
（1） (Bind Req) Device 1 --> Coordinator <--- Device 2 (Bind Req)
協調器首先找出包含在綁定請求中的簇，然後對比每一設備的IEEE地址，如果簇可以匹配，而且這幾個設備沒有已經存在的綁定表，那他將發送一個綁定應答給每一個設備。
（2） Device 1 <--- NWK Addr Req ------ Coordinator ------- NWK addrReq ----> Device 2
（3） Device 1 ----> NWK Addr Rsp ---> Coordinator <---- NWKaddr Rsp <--- Device 2
（4） Device 1 <----- Bind Rsp <----- Coordinator -----> BindRsp ----> Device 2
2、“描述符匹配”爲源設備的服務發現提供了一種靈巧的方法。下面是具體的操作，這一過程並沒有通過協調器。
（1） Device 1 ----> Match Descriptor request (broadcast or unicast)Device 2
（2） Device 1 <---- Match Descriptor response (if clusters, applicationprofile id match) that includes src endpoint, src address <---- Device 2
1號設備需要維護一個端點和地址的記錄。
許多應用服務最終都會使用第二種方法。