ZigBee是一種嶄新的，專注于低功耗、低成本、低復雜度、低速率的近程無線網絡通信技術，也是目前嵌入式應用的一個大熱點。

近年來，ZigBee無線數據網絡在我國應用越來越多。在很多地方取代了局域網。實際應用于樓宇監控系統、無線方式集中抄表以及礦山救援系統和家電控制等等。文中談及在我國有較多客戶使用的TI公司的產品CC2430。

1? 問題的提出

在一片不大的區域內，有數個信道相同的協調器，但是PAN ID不同。當設置了終端的PAN ID后，終端只加入和其上存儲的PAN ID相同的協調器。目前本無線組網項目使用的是TI公司的CC2430，其上的ZigBee協議棧為TI的Z-STACK 1.4.3-1.2.1。由于TI公司的策略是終端比較隨機的加入其中的一個協調器，即使其上已經定義了特定的PAN ID。從少量的實驗來看，CC2430作為終端優先加入PAN ID號比較小的協調器。用戶一般無法讓終端選擇，并且終端掃描網絡和請求入網的過程都沒有給出源代碼。這樣便給這類實際應用帶來不便。

2? 問題分析

關于CC2430／2431網絡的形成，可以參考《ZigBee技,術實踐教程》一書。該書為北京航空航天大學出版社出版，高守瑋和吳燦陽主編。

路由器和終端試圖加入一個網絡時，首先調用NLME_NetworkDiscoveryRequest()函數。該函數將進行網絡掃描，其結果由函數ZDO_NetworkDiscoveryConfirmCB()返回。而發現網絡存在后，將調用NLME_OrphanJoinRequest()函數試圖加入網絡。其結果由函數ZDO_JoinIndicationCB()返回。

遺憾的是，網絡掃描和請求入網兩個函數都沒有源代碼，造成無法修改的困境。客觀地說，在TI公司的ZSTACK上修改某些參數常常是比較困難的。只好從提供了源代碼的ZDO_NetworkDiscoveryConfirmCB()函數和ZDO_JoinIndicationCB()函數來想辦法。檢測ZDO_NetworkDiscoveryConfirmCB()的代碼，發現其最終調用ZDO_FinishProcessingMgmtNwkDiscReq()函數。

而在該函數中，有對路由器的特殊處理。條件編譯變量RTR_NWK代表有路由器功能的設備，雖然協調器可以兼做路由器，但執行這段代碼的只可能是普通的路由器。

#if defined(RTR_NWK)
……
#endif

……中的代碼檢索返回的網絡信息描述結構，查看有沒有和存儲的PAN ID相同的協調器。觀察ZDObject．c文件中的ZDO_StartDevice()函數，當啟動設備模式為“再繼續”時，即startMode==MODE_RESUME，終端設備以孤點方式請求加入網絡。再繼續模式實際上是標識非協調器設備處于網絡掃描完成，準備請求入網的狀態。分析到此，可以想出辦法了。首先定義一個檢查是否有PAN ID相同的協調器的全局變量bool變量p_matching。初始化時設其為FALSE。

3? 解決方法和實際代碼

對剛才提及的代碼段，增加終端對返回的網絡信息描述結構的查詢。



在ZDApp．c中修改ZDApp_event_loop()函數，在調用ZDO_StartDevice(…)之前，亦即在終端設備掃描網絡和請求入網前增加一段代碼。當終端和協調器PAN ID不同，并且是再繼續模式時，重新搜索是否有與PAN ID相同的協調器，而不請求人網。



這樣就使得終端有協調器可挑選了。

關于如何修改PAN ID，給出代碼如下(該代碼為協調器和終端通用的。_NIB是和網絡相關的全局結構體)：



另外非協調器設備在初始化時，應該增加如下的代碼(gu16RecBuffLen為自定義的16位整型數)：



通過對掃描網絡結果處理函數的分析，研究掃描網絡和請求人網前的程序段。在程序段中增加一個對終端是否檢索到特定PAN ID的協調器的邏輯變量。最后在程序中增加未檢索到特定PAN ID的協調器時不請求入網的代碼，以達到終端選擇協調器入網的目的。經實驗，在現場有數個不同PAN ID的協調器的情況下，終端設備只加入特定的協調器。