Reading the design and implementation of the zigbee protocol driver in linux
Download
1 / 17

Reading “The Design and Implementation of the ZigBee Protocol Driver in Linux” - PowerPoint PPT Presentation


  • 106 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Reading “The Design and Implementation of the ZigBee Protocol Driver in Linux”' - elie


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
Outline:

  • IEEE 802.15.4 標準

  • ZigBee 無線網路通訊協定

  • Linux Networking Subsystem

  • 實作與難題

  • Reference


Ieee 802 15 4
IEEE 802.15.4 標準

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


  • IEEE 802.15.4 的PHY 負責以下工作:

    • 啟動與關閉無線電收發器

    • 無線頻道訊號能量偵測

    • 連線品質指示

    • CSMA-CA 空閒頻道評估

    • 頻道頻率選擇

    • 資料傳輸與接收


  • IEEE 802.15.4 MAC 子層管理所有存取實體無線電頻道的動作, 並負責下列工作:

    • 當裝置被設定為 Coordinator 時,負責產生網路信標(beacon)

    • 利用信標作同步

    • 支援 PAN association 與disassociation

    • 支援裝置加密措施

    • 參與頻道存取的 CSMA-CA 機制

    • 處理與維護 GTS 機制

    • 在兩個對等的 MAC 實體間提供一個可靠的鏈路


Zigbee
ZigBee無線網路通訊協定

  • ZigBee 標準包含有NWK 層(Network layer)、APS 子層(Application Supportsublayer)、ZDO(ZigBee Device Object)、Application Framework、SSP(SecurityService Provider)與一些Profiles。主要會簡介NWK、APS、ZDO 與ZigBeeDevice Profile。


  • 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 擁有者去幫它傳遞完整封包給複數節點上的應用程式, 就某種程度上來說這是個可以讓某方省電的方法。


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


Linux networking subsystem
Linux Networking Subsystem

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


  • 上 層 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。


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


實作與難題

  • 第一道難題: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。


  • 第二道難題:額外動作造成超時

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


  • 第三道難題: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。這部份會在以後改進。


  • 第四道難題:NLME-LEAVE 與MLME 系列服

    • NLME-LEAVE 會成為問題, 主要是由於文件中對其流程敘述的很煩雜, 且流程圖又模糊不清, 不同人閱讀同樣段落後, 可能會得到完全不同的認知。 NWK 在呼叫MLME 系列服務的時候能比較像函式呼叫。而不是像標準文件中講述的那樣在request 後某個時間點, 再呼叫confirm 來確認回覆狀況。

    • 基本上將MLME 系列呼叫改成函式呼叫方式是沒什麼大問題的, 只要能正確運作就可以, 實作上採取不同方式設計是說的過去的。


Reference
Reference

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


ad