隨著微機電感測器製造技術及無線感測網路的蓬勃發展，由這些感測器裝置所構成的網際網路--物聯網(Internet of Things, IoT)或稱智慧聯網，已成為近年來十分熱門的議題。
然而，早期的無線感測網路缺乏一個共通的通訊協定標準，為了讓這些不同的感測網路裝置能夠互通，所以網際網路工程任務小組(IETF)以IPv6協定為基礎，制定專屬於這些低功率、低可靠度、網路規模極大網路裝置的互連通訊協定--6LoWPAN。本文將介紹6LoWPAN通訊協定的發展現況，及可能的實作議題。
因應網路發展 6LoWPAN WG/ROLL WG上陣
近10年來，隨著微機電感測器製造技術及無線感測網路通訊技術的快速發展，目前已經有許多無線感測網路相關的應用問世，例如個人健康醫療照護、先進電表系統架構(AMI)、家庭能源管理系統(ＨEMS)等。然而，隨著感測器節點的增加，讓原有的無線感測網路架構也面臨極大的挑戰。
有鑑於此，IETF從2005年開始為了因應此挑戰，也陸續成立兩個工作團隊(Working Group, WG)：6LoWPAN WG及ROLL WG。以IPv6通訊協定為基礎，開始訂定針對IEEE 802.15.4的低功率、低可靠度網路裝置的互通網際網路協定。
 |
| 圖1 6LoWPAN堆疊 |
其中，6LoWPAN WG負責制定有關網路連結建立、封包分割及封包壓縮的協定。而ＲＯＬＬ WG負責針對這樣的網路環境提出合適的路由演算法通訊協定，詳細的通訊協定堆疊如圖1所示。
6LoWPAN WG制定協定標準
因為IEEE 802.15.4網路連結技術，與先前IPv6常用的網路連結技術如IEEE 802.11和乙太網路(Ethernet)，有著極大不同的特性。舉例來說，最大傳輸單位(MTU)，IEEE 802.15.4只能支援127位元組(Bytes)，遠小於IEEE 802.11與Ethernet所能支援的1,500位元組。
除此之外，IEEE 802.15.4受限於其無線傳輸技術，所以無法具備讓所有網路節點都接收到訊息的廣播能力，資料的傳輸會受限於無線射頻天線的最大傳輸範圍。因此，IETF於2005年開始成立6LoWPAN WG，著手制定適用於IEEE 802.15.4的IPv6技術，同時，把此工作組的重點分類為兩大項工作項目：一是如何能讓IEEE 802.15.4的網路連結技術，攜帶IPv6的資料封包；二是如何在IEEE 802.15.4的無線環境下，運行必要的IPv6鄰居尋找功能，以建立起網路拓撲。
因為IPv6通訊協定的標準裡，網路連結層必須要具備傳輸1,280位元組資料封包的能力，而這是IEEE 802.15.4所辦不到的(其最大封包大小為127位元組)，因此，必須另外定義資料封包分割及重組的技術，以達到此要求，所以6LoWPAN WG在2008年發布RFC 4944，以支援與IPv6層的封包相容性，並定義封包分割的格式。
此外，在此RFC(Request For Comments)中並沒有包含已分割封包遺失的回復機制，而是定義封包傳輸時，收到資料封包的一方，必須要回覆ACK封包，以此確保可以達到足夠高的成功率，而詳細的封包格式如圖2所示。另外，為了配合IEEE 802.15.4的特性，6LoWPAN WG也另外定義不同於以往IPv6所使用的封包標頭壓縮技術，分別制定出RFC 6282及仍在討論中的draft-bormann-6lowpan-ghc-04(通用封包壓縮格式)，礙於文章篇幅，本文並不對此介紹，有興趣的讀者可自行參閱參考資料。
 |
| 圖2 6LoWPAN封包格式 |
除了定義資料傳輸的封包外，鄰居發現協定(Neighbor Discovery, ND)，也是建立IPv6網路不可或缺的項目。而典型IPv6所使用的ND協定，必須要網路連結層能夠支援群播(Multicast)能力，但IEEE 802.15.4並沒有此能力，所以6LoWPAN WG為此也制定了新的ND協定，並發布尚在討論中未正式定案的RFC草案：draft-ietf-6lowpan-nd-19。在此協定中，依然使用與IPv6 ND相同的Router Advertisement及Router Solicitation封包來讓新加入網路的節點找到已在網路上的鄰居，藉此成功加入網路中。
與先前ND機制的不同點在於，此協定假設Link-local的IPv6位址會來自於裝置原來的媒體存取控制(MAC)位址，因此6LoWPAN的網路節不再須要使用群播來解譯未知的連結層位址，並能利用此位址建立出IPv6位址。
在網路協定內，除了定義出封包格式及網路建立的方法外，如何建立適當的網路封包繞送路徑，也是必須要定義的規範。然而，在6LoWPAN WG只提出RFC6606定義在這些網路環境下，路由演算法所必須滿足的條件，而不去定義所使用的演算法。
由於在6LoWPAN網路環境所必須考慮的路由演算法，會因使用的案例而異，已經超出6LoWPAN WG的目標，所以IETF又另外建立ROLL WG工作組，來定義與6LoWPAN網路相關的路由演算法協定。
ROLL WG制定路由演算法標準
由於訂定在6LoWPAN網路下之路由演算法的標準，已經超出6LoWPAN WG原來的目標，原先網路上常用的路由演算法，也不能滿足6LoWPAN網路的需求，所以IETF在2008年另外成立ROLL WG來制定相關的路由演算法標準。
由於6LoWPAN所使用的網路環境最佳化定義，常會因應用情境而有所不同。所以，ROLL WG在考量路由的最佳化會因環境有所差異的情境下，訂定一個可以通用的路由演算法--IPv6 Routing Protocol for LLNs(簡稱RPL[RFC6550])。並且定義此演算法可支援的三種傳輸模式，包括Point-to-point Traffic、Point-to-multi-point Traffic及Multi-point-to-point Traffic。以下簡略說明，此路由演算法與典型常用路由演算法不同之處。
首先，典型的連結狀態路由演算法，在傳遞路由狀態資訊時，經常須要用到一定範圍的氾洪式資訊傳送，並且必須週期性的傳送這些封包，以保持最新的網路路由狀態。但在6LoWPAN這種低功率、大量節點的網路環境下，這樣須發出大量控制封包的演算法並不實際，因此在RPL中利用了有名的Trickle演算法[RFC6206]來滿足此需求。
使用Trickle演算法，可以藉由偷聽鄰居封包，減少路由資訊交換封包的特性，使得RPL可以用極小封包交換，讓網路的路由資訊保持在最新的狀態。此外，在6LoWPAN網路環境下，節點可能會常變化(突然消失)，所以RPL也納入空間多樣化的特性，讓一個節點同時有機會選擇多個不同節點做資料封包的轉傳。
如先前所述，6LoWPAN常會因不同的應用情境，而有不同的路徑繞送最佳化因素(例如有些考慮最少的轉傳節點，有些則考慮較穩定的傳送品質，其他也可能都要考慮)，而這卻是典型使用單純成本計算方式的路由演算法所無法達到的，所以，在RPL中會在路由資訊封包資訊交換時，帶進Objective Functions(OFs)的資訊，讓RPL路由演算法在計算最佳化路徑時，根據不同的OFs，計算出最符合實際網路應用需求的路徑。關於更完整的RPL演算法說明，可以參考RFC6550，找到更多的資訊。
實作專案陸續出爐
目前關於6LoWPAN網路協定較有名的實作，分別為在無線感測網路上常用的作業系統TinyOS，實作的Blip及TinyRPL。另一個則是在近年來，慢慢興起專為IoT所發展的Contiki作業系統。以下將分別介紹這兩個專案。
Blip專案的目的，是想在TinyOS系統上發展出一個適合使用者開發實際無線感測網路應用的通訊協定，後來為了因應IoT的發展，更加入了6LoWPAN相關的通訊協定，發布了Blip 2.0。目前其所支援的協定標準分別為Draft-6lowpan-hc-06、Draft-roll-rpl-17及RFC1661(Complient PPP Daemon for Communicating with External Networks)。雖然此專案尚未更新到最新的協定標準，但也已經可以滿足大多數的實際應用情景。根據文獻，Blip可以在只有極小48kbytes唯讀記憶體(ROM)及10kbytes隨機存取記憶體(RAM)的MSP430F1611上運作，並且也已有實際布建的網路在運作中。
Contiki專案是由瑞典資訊科學院專為IoT所發展出的作業系統，並且得到許多國際大廠，如愛特梅爾(Atmel)、思科(Cisco)的支持，目前已經發展出一套從應用層--CoAP(Constrained Application Protocol)到網路層符合6LoWPAN協定的軟體架構，並且也包含完整的軟體開發環境及網路模擬測試環境。此專案已經相當成熟，也在許多硬體平台，如德州儀器(TI)MSP430x、愛特梅爾AVR、愛特梅爾Atmega128RFA1、飛思卡爾(Freescale)MC1322x及意法半導體(STMicroelectronics)STM32w等，皆可成功移植。
6LoWPAN勢必帶來變革
近年來，無線感測網路的快速發展，讓無線感測網路從原本只屬於特定網路協定的區域網路，發展成能夠讓不同網路彼此相連的物聯網。為了達到這樣的網路環境，共同的網路通訊協定標準就成了不可或缺的角色，而IETF所提出的6LoWPAN網路協定也就應運而生。雖然很多的標準細項都還在討論，也有許多議題待定義，例如在此網路環境下的資安議題，但可以預見在不久的將來，這樣的網路架構將激發出許多不同的應用，而原本在無線感測網路上的應用程式架構也將被大幅翻新。
(本文作者任職於資策會智通所)