Transcript 投影片1
Speaker : Kai-Jia Chang Adviser :Quincy Wu Date : 9/28 NCKU,Institute of Computer Science and Information Engineering Sheng-Fu Su 1 IEEE 802.15.4 標準 ZigBee 無線網路通訊協定 Linux Networking Subsystem 實作與難題 Reference 2 3 IEEE 802.15.4 低速率無線個人區域網路標準(LRWPANs, 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 標準包含有NWK 層(Network layer)、APS 子層(Application Support sublayer)、 ZDO(ZigBee Device Object)、Application Framework、SSP(Security Service Provider)與 一些Profiles。主要會簡介NWK、APS、ZDO 與 ZigBee Device 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 (簡稱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(Application Programming Interface) ；在BSD Socket 下一層則是各種網路協定層的實作(也就是 Protocol Driver)，且自身需包含一個與BSD Socket 溝通的Socket這層Socket 的主要功能是在將各種不同 網路協定層的資料傳遞機制整合對應到BSD Socket 的 API。這兩層Socket 合稱為Socket Interface。 11 LNS 最上層是應用程式層，Linux 核心是採用BSD Socket 與之互動， 應用程式層 以上其實可以再另外設計很多層， 不過在此只將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 The Design and Implementation of the ZigBee Protocol Driver in Linux- NCKU, Institute of Computer Science and Information Engineering,Sheng-Fu Su 17