ZigBee四種綁定方式在TI Z-Stack協定棧中應用

ZigBee四種綁定方式在TI Z-Stack協定棧中應用

本文是作者根據TI Z-Stack開發文檔，ZigBee Specification-2007，《Zigbee Wireless Networking》等英文資料整合和翻譯而成，采用中英雙語對照友善讀者了解，文中翻譯不當之處，望廣大同行不吝賜教。推廣ZigBee技術，提高國内電子行業的國際影響力，是我們無線通訊工程師的願景。本文歡迎轉載，請保留作者資訊和出處，作為支援我繼續努力前行的動力，謝謝！ ZigBee2006版本中規定，在全部節點中實作綁定機制，并将其稱為源綁定。綁定機制允許一個應用服務在不知道目标位址的情況下向對方（的應用服務）發送資料包。發送時使用的目标位址将由應用支援子層從綁定表中自動獲得，進而能使消息順利被目标節點的一個或多個應用服務，乃至分組接收。 Binding Table 綁定表 1.   綁定表存放的位置是記憶體中預先定義的塊，如果編譯選項NV_RESTORE被激活，也能儲存在Flash裡。 2.   綁定表放置在源節點（需要激活編譯選項REFLECTOR）。 3.   綁定表的條目把需要發送的消息映射到它們的目标位址上。 4.   綁定表中每個條目包括以下内容： 5.   綁定表條目結構體的定義 typedef struct { uint16 srcIdx; //源位址索引 uint8 srcEP; //源端點 uint8 dstGroupMode; //指定尋址模式 uint16 dstIdx; //目标位址索引或者分組号 uint8 dstEP; //目标端點 uint8 numClusterIds; //在簇辨別符表中簇辨別符的個數 uint16 clusterIdList[MAX_BINDING_CLUSTER_IDS]; //簇辨別符表 }BindingEntry_t; Simple Description --- How to bind devices 概述---怎樣綁定節點 綁定指的是兩個節點在應用層上建立起來的一條邏輯鍊路。在同一個節點上可以建立多個綁定服務，分别對應不同種類的資料包。此外，綁定也允許有多個目标節點（一對多綁定）。 舉個例子，在一個燈光網絡中，有多個開關和燈光裝置，每一個開關可以控制一個或以上的燈光裝置。在這種情況下，需要在每個開關中建立綁定服務。這使得開關中的應用服務在不知道燈光裝置确切的目标位址時，可以順利地向燈光裝置發送資料包。 一旦在源節點上建立了綁定，其應用服務即可向目标節點發送資料，而不需指定目标位址了（調用zb_SendDataRequest()，目标位址可用一個無效值0xFFFE代替）。這樣，協定棧将會根據資料包的指令辨別符，通過自身的綁定表查找到所對應的目标裝置位址。     在綁定表的條目中，有時會有多個目标端點。這使得協定棧自動地重複發送資料包到綁定表指定的各個目标位址。同時，如果在編譯目标檔案時，編譯選項NV_RESTORE被打開，協定棧将會把綁定條目儲存在非易失性存儲器裡。是以當意外重新開機（或者節點電池耗盡需要更換）等突發情況的發生時，節點能自動恢複到掉電前的工作狀态，而不需要使用者重新設定綁定服務。     配置裝置綁定服務，有兩種機制可供選擇。如果目标裝置的擴充位址（64位位址）已知，可通過調用zb_BindDeviceRequest()建立綁定條目。如果目标裝置的擴充位址未知，可實施一個“按鍵”政策實作綁定。這時，目标裝置将首先進入一個允許綁定的狀态，并通過zb_AllowBindResponse()對配對請求作出響應。然後，在源節點中執行zb_BindDeviceRequest()（目标位址設為無效）可實作綁定。     此外，使用節點外部的委托工具（通常是協調器）也可實作綁定服務。請注意，綁定服務隻能在“互補”裝置之間建立。那就是，隻有分别在兩個節點的簡單描述結構體（simple descriptor structure）中，同時注冊了相同的指令辨別符（command_id）并且方向相反（一個屬于輸出指令“output”，另一個屬于輸入指令“input”），才能成功建立綁定。 There are 4 ways to build a binding table: 建立一個綁定表格有四種方法可供選擇： 自動綁定 一、    負責發送消息的裝置在網絡上廣播帶有如下參數的“個人公告”（Personal Advertisement）： （1） 位址，配置檔案辨別符，簇集合清單； （2）描述符比對請求- ZDP_MatchDescReq()。 二、    比對的裝置會作出響應。 三、    由ZDO處理和驗證響應 四、    負責發送消息的裝置建立綁定表并儲存綁定記錄。 五、    這種方法有時也稱“服務發現”，“自動找尋”或者“自動比對”。     ZigBee裝置對象綁定請求-一種告訴目标裝置建立綁定記錄的委托工具，也稱輔助綁定。 任何一個裝置或應用服務，都能通過無線信道向網絡上的另一個裝置發送一個ZDO消息，幫助其建立一個綁定記錄。這稱為輔助綁定，在消息發向的裝置上會建立一個綁定條目。 委托綁定的申請： 任一個應用服務，通過向ZDP_BindReq()[defined in ZDProfile.h]提供綁定記錄所需要的應用服務入口參數（位址和端點）以及簇辨別号（cluster ID），即可啟動委托綁定的申請。第一個參數（消息發送目标位址）是綁定源節點的短位址（即儲存綁定記錄的節點位址，這是因為ZDP需委托應用架構AF輔助實作綁定，如果節點本身是REFLECTOR，并且希望儲存綁定記錄，則此消息發送的目标位址就是本地的AF，這與目标節點的位址DestinationAddr of Receiving device不同）。 注意事項： 確定[ZDConfig.h]中ZDO_BIND_UNBIND_REQUEST特性已經打開！ 你可以通過ZDP_UnbindReq()（使用相同參數）來移除綁定記錄。 被請求輔助綁定的目标裝置會傳回的ZDO申請綁定或者解除綁定的應答消息。此ZDO消息會被解析并通過調用ZDApp_BindRsp()或ZDApp_UnbindRsp()告知ZDApp.c此次請求的結果。 對于申請綁定的應答消息，從協調器傳回的狀态可能有ZDP_SUCCESS,ZDP_TABLE_FULL or ZDP_NOT_SUPPORTED。 對于解除綁定的應答消息，從協調器傳回的狀态可能有ZDP_SUCCESS,ZDP_NO_ENTRY or ZDP_NOT_SUPPORTED。 綁定是由外部的裝置發起（“外部”的意思是發起綁定的不是綁定的對象之一）。 外部裝置應用程式以兩個應用服務（位址和端點）和簇辨別符作為參數調用ZDP_BindReq ()發起綁定。第一個參數就是綁定記錄儲存的裝置位址。 確定編譯選項REFLECTOR已經打開！ 函數解析： 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-消息發送位址 （負責綁定的裝置位址） 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()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() 優點： 1.     綁定資訊儲存在網絡反射裝置（例如協調器、路由器）中，可以節省目标裝置的記憶體空間。 2.     網絡反射裝置總是處于監聽網絡的狀态。是以，如果其中一個被綁定的節點廣播網絡位址改變的消息，網絡反射裝置就可以馬上更新相應的綁定表條目。這樣，其他被綁定的節點即使處于休眠狀态（沒有收到該節點網絡位址改變的消息），随後向該節點（網絡位址已改變）發送的消息，（在）網絡反射裝置（協助下）仍能準确定位。 缺點： 1.     一個與多個裝置綁定的節點不能隻向一個或若幹個配對的裝置發送消息。網絡反射裝置會向全部已綁定的裝置本别發送單點傳播消息。 2.     發送消息的裝置無法收到目标裝置接收情況的通告。（沒有像AF_ACK_REQUEST标志位那樣傳回接收情況的功能！） 3.     所有的消息必須經過網絡反射裝置傳輸，降低了網絡的帶寬。 進一步分析：     與六個裝置綁定的某個裝置，向網絡反射器發送一個消息後，會導緻反射器發送六個單點傳播消息。假設一個網絡被分成兩個相等的地理區域A和B，網絡反射器在兩區之間的中央。如果發送消息的裝置在A區的深處，接收消息的（六個）裝置在B區的深處，那麼每次通過綁定（向反射器）發送一個消息，A區的網絡流量将會是對六個接收裝置分别發送消息時的六分之一。（這是優點！）但如果發送和接收的裝置都鄰近在一個區的深處（假設離反射器很遠），那麼（其中一個裝置通過反射器的綁定功能想其他裝置發送一個消息）該區的網絡流量将會是對六個接收裝置分别發送單跳消息的許多倍。（這是缺點！） 裝置的應用服務-裝置上的一個應用服務可以建立或者維護一個綁定表。進入裝置上綁定條目的另一種方法是由應用服務本身去管理綁定表。     這意味着應用服務通過調用以下的綁定表管理函數，可以在本地進入或者移除綁定表的條目。 管理綁定表使用的API： bindAddEntry()–綁定表中加條目 bindRemoveEntry()–綁定表中移除條目 bindRemoveClusterIdFromList()–從一個已有的綁定表條目中移除一個簇辨別符 bindAddClusterIdToList()–在一個已有的綁定表條目中加入一個簇辨別符 bindRemoveDev()–移除某目标位址的所有條目 bindRemoveSrcDev()–移除某源位址的所有條目 bindUpdateAddr()–更新條目到新的位址 bindFindExisting()–查找一個綁定條目 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 來自TI E2E社群的進一步讨論： 一、“終端裝置綁定請求”這一命名有誤導的嫌疑。這一請求不僅僅适用于終端裝置，而且适用于對希望在協調器上綁定的兩個裝置中比對的簇實施綁定。一旦這個函數被調用，将假設REFLECTOR這一編譯選項在所有希望使用這一服務的節點中都已經打開。具體操作如下： （1）       (Bind Req) Device 1 --> Coordinator <--- Device 2 (Bind Req) 協調器首先找出包含在綁定請求中的簇，然後對比每一裝置的IEEE位址，如果簇可以比對，而且這幾個裝置沒有已經存在的綁定表，那他将發送一個綁定應答給每一個裝置。 （2）      Device 1 <--- NWK Addr Req ------ Coordinator ------- NWK addr Req ----> Device 2 （3）       Device 1 ----> NWK Addr Rsp ---> Coordinator <---- NWK addr Rsp <--- Device 2 （4）       Device 1 <----- Bind Rsp <----- Coordinator -----> Bind Rsp ----> Device 2 二、“描述符比對”為源裝置的服務發現提供了一種靈巧的方法。下面是具體的操作，這一過程并沒有通過協調器。 （1）       Device 1 ----> Match Descriptor request (broadcast or unicast) Device 2 （2）       Device 1 <---- Match Descriptor response (if clusters, application profile id match) that includes src endpoint, src address <---- Device 2 1号裝置需要維護一個端點和位址的記錄。 許多應用服務最終都會使用第二種方法。

本文轉載自：http://omaday.net/forum.php?mod=viewthread&tid=367。若作者看見後不允許轉載，請告知。