1 / 17

Reading “The Design and Implementation of the ZigBee Protocol Driver in Linux”

Reading “The Design and Implementation of the ZigBee Protocol Driver in Linux”. Speaker : Kai-Jia Chang Adviser :Quincy Wu Date : 9/28 NCKU, Institute of Computer Science and Information Engineering Sheng-Fu Su. Outline:. IEEE 802.15.4 標準 ZigBee 無線網路通訊協定 Linux Networking Subsystem

tanaya
Télécharger la présentation

Reading “The Design and Implementation of the ZigBee Protocol Driver in Linux”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Reading “The Design and Implementation of the ZigBee Protocol Driver in Linux” Speaker : Kai-Jia Chang Adviser :Quincy Wu Date : 9/28 NCKU,Institute of Computer Science and Information Engineering Sheng-Fu Su

  2. Outline: • IEEE 802.15.4 標準 • ZigBee 無線網路通訊協定 • Linux Networking Subsystem • 實作與難題 • Reference

  3. IEEE 802.15.4 標準 • IEEE 802.15.4 低速率無線個人區域網路標準(LR-WPANs, low-rate Wireless Personal Area Networks)的制訂目標主要是滿足低功率消耗、低資料傳輸並符合實作複雜度低、短距RF 傳輸等需求， 這些特性也說明了IEEE 802.15.4 的網路設備會比較適用於小型、供電能力有限且價格便宜的解決方案上。

  4. IEEE 802.15.4 的PHY 負責以下工作： • 啟動與關閉無線電收發器 • 無線頻道訊號能量偵測 • 連線品質指示 • CSMA-CA 空閒頻道評估 • 頻道頻率選擇 • 資料傳輸與接收

  5. IEEE 802.15.4 MAC 子層管理所有存取實體無線電頻道的動作， 並負責下列工作： • 當裝置被設定為 Coordinator 時，負責產生網路信標(beacon) • 利用信標作同步 • 支援 PAN association 與disassociation • 支援裝置加密措施 • 參與頻道存取的 CSMA-CA 機制 • 處理與維護 GTS 機制 • 在兩個對等的 MAC 實體間提供一個可靠的鏈路

  6. ZigBee無線網路通訊協定 • ZigBee 標準包含有NWK 層(Network layer)、APS 子層(Application Supportsublayer)、ZDO(ZigBee Device Object)、Application Framework、SSP(SecurityService Provider)與一些Profiles。主要會簡介NWK、APS、ZDO 與ZigBeeDevice Profile。

  7. NWK 負責網路層工作， 使用IEEE 802.15.4 MAC 所提供的服務來完成工作，並提供資料收送與管理兩種服務給上層呼叫使用。NWK 最重要的工作就是實行ZigBee 網路功能與了解週遭網路狀況，本論文主要實作的重點就在NWK。 • APS 是負責傳輸層工作， 使用NWK 所提供的資料傳輸服務， 並提供ZDO管理服務與Application Framework 資料傳輸服務。Multiplexing 是APS 重要的工作， 提供上層應用程式取用網路資料傳輸服務的Endpoint 號碼， 搭配網路位址， 這樣在兩個通訊端點間才能達到多工的需求， 讓多個應用程式可排程使用APS， 而不是整個APS 只能由一個應用程式所獨占使用。Binding 是APS 供的另一個重要功能， 一個Binding 好的應用程式可以用僅有來源Endpoint 號碼的封包， 來通知所屬Binding Table 擁有者去幫它傳遞完整封包給複數節點上的應用程式， 就某種程度上來說這是個可以讓某方省電的方法。

  8. ZDO 則是整個ZigBee 網路裝置的控制中心，會取用NWK 與APS 的管理服務， 並搭配ZigBee Device Profile(ZDP)的規範， 向Application Framework(AF)提供ZDO Public Interface(ZPUI)，AF 可以透過ZPUI 向ZDO 要求進行ZDP 規範的動作，如查找遠端節點的MAC 位址等。ZDO 包含五大物件，分別對應到五種重要的管理行為， 如下表：

  9. Linux Networking Subsystem • Linux Networking Subsystem (簡稱LNS)， Linux 網路子系統是目前Linux核心中主要的網路協定層模型， 大多數的Linux 網路功能都是依照LNS 來設計開發， 目前有支援TCP/IP、X.25、AppleTalk、IPX、IrDA 與Bluetooth 等數十種網路協定。這篇論文作者設計ZigBee 網路協定層是仿照TCP/IP 那一套流程來設計，如圖：

  10. 上 層 LNS 包含Socket Interface 與Protocol Driver 兩大部分。 • 這 部 分 主 要 是 以 BSD Socket 呈現給user space 的應用程式設計者使用，BSD Socket 提供了一層標準的抽象化網路溝通流程， 有socket()、bind()、connect()、accept()、recvfrom()、sendto()等API(ApplicationProgramming Interface) ；在BSD Socket 下一層則是各種網路協定層的實作(也就是Protocol Driver)，且自身需包含一個與BSD Socket 溝通的Socket這層Socket 的主要功能是在將各種不同網路協定層的資料傳遞機制整合對應到BSD Socket 的API。這兩層Socket 合稱為Socket Interface。

  11. LNS 最上層是應用程式層，Linux 核心是採用BSDSocket 與之互動， 應用程式層以上其實可以再另外設計很多層， 不過在此只將BSD Socket 以上全部視為應用程式層。接下來則是傳輸層與網路層， 也就是前文所介紹的Protocol Driver。最下層則是資料連結與實體層， 其中有包含net_device、MAC 子層與網路裝置驅動程式。

  12. 實作與難題 • 第一道難題：NWK 與MAC 的互動機制不順暢 • 實 作 時 所 遇 到 的 第 一 道 難 題 ， 就 是 NWK 與IEEE 802.15.4 有著非常緊密的關係， 很多NWK 服務都會直接去使用MAC 的service primitives。 • 除了重置裝置之外，其他管理功能並不會直接透過net_device 去使用下層服務。目前絕大部分的Linux 網路裝置都是依靠ioctl 來實現裝置管理或網路管理的功能。 • 將n e t _ d e v i c e 之外多加一層L RW P A N 抽象裝置層，NWK 使用的所有MAC 服務命令都封裝成資料封包，經由net_device傳遞給LRWPAN 的lrwpan_hard_xmit()後再傳遞給驅動程式解封裝， 再由驅動程式向ZigBee 網路裝置呼叫MAC 服務命令；當網路裝置執行完MAC 服務命令後，再將confirm 訊息重新封裝，丟給LRWPAN 虛擬裝置，讓它回傳給NWK。

  13. 第二道難題：額外動作造成超時 • 由 於 採 用 LRWPAN 虛擬裝置的關係，在驅動程式端和NWK 中都需另外花時間封裝額外的資料， 因此有部份ZigBee 標準中規範的時限， 就有可能因為這些額外的動作造成不該出現的超時狀況。不過 NWK 本身只有在NLME-LEAVE 時會比較注重時間，大部分都是下參數給MAC 層， 時間超過的話，MAC 會通知或自行處理。

  14. 第三道難題：Interrupt Context 認知不清 • 這 問 題 來 自 於 作者 在 設 計 NWK 時，並未對核心中的interrupt context 有清楚的認知。核心中有支援相當多同步機制， 常被用到有spinlock_t 與semaphore，大部分的MAC 呼叫都得等上一段時間才能完成， 且大部分的NWK 服務都是被ZDO 這個kernel thread 來呼叫， 所以剛開始設計時都讓NWK 使用rw_semaphore 讓ZDO 去休眠， 等候confirm 來喚醒ZDO。當然這是有問題的， 因為有部份工作是處理來自MAC 的indication， 然後response 它， 這時候是在interrupt context， 所以不能使用rw_semaphore。這部份會在以後改進。

  15. 第四道難題：NLME-LEAVE 與MLME 系列服 • NLME-LEAVE 會成為問題， 主要是由於文件中對其流程敘述的很煩雜， 且流程圖又模糊不清， 不同人閱讀同樣段落後， 可能會得到完全不同的認知。 NWK 在呼叫MLME 系列服務的時候能比較像函式呼叫。而不是像標準文件中講述的那樣在request 後某個時間點， 再呼叫confirm 來確認回覆狀況。 • 基本上將MLME 系列呼叫改成函式呼叫方式是沒什麼大問題的， 只要能正確運作就可以， 實作上採取不同方式設計是說的過去的。

  16. Reference • The Design and Implementation of the ZigBee Protocol Driver in Linux- NCKU, Institute of Computer Science and Information Engineering,Sheng-Fu Su

More Related