分析 6LoWPAN 中連續的 IPv6 UDP 封包傳輸速率

第四章在非理想通道環境下透過 Contiki OS 評估 6LoWPAN 之效能

4.2 多跳環境下之效能分析

4.2.5 分析 6LoWPAN 中連續的 IPv6 UDP 封包傳輸速率

本章節將探討連續性的 IPv6 UDP 封包於 6LoWPAN 網路中的封包傳送效率，

使用大量封包於感測網路中傳送將對於 6LoWPAN 是個重大的挑戰，IPv6 封包在

IEEE 802.15.4 標準下，必須能即時地進行分割及重組，且封包與封包之間所需的傳輸時間間隔，傳輸時間間隔的大小與傳輸效能有密不可分的關係，傳輸時間間

Optimal two-hop transmission

Number of Fragments

之差異性。

圖 4-16 為封包傳輸時間間隔 PTTI(Packet Transmission Time Interval)與 Packet

Interframe Space(PIFS)之關係圖，在傳輸的資料量上是以每個片段封包所能乘載的最大 IPv6 資料量做傳送，封包傳輸時間間隔將會依傳送之 IPv6 MTU 而成長，

當 IPv6 封包長度越長時，其所需要的傳輸時間將要更長，每個封包之間將會有個 PIFS，由於將傳輸大量的 IPv6 作測試，所以 PIFS 之調變將會影響整體封包傳輸之效率。

圖 4-16、封包傳輸時的 PTTI 與 PIFS 間之關係 4.2.6 多跳下的封包傳輸排程

圖 4-17 為多跳下的封包傳輸排程，此時的 PIFS 將與一跳或是兩跳的傳輸有所差別，每個 Node 只能傳輸至鄰近節點，且只能聽到鄰近節點的傳輸封包，Node1 需要透過多跳的方式將 IPv6 封包傳輸至 Node5，首先 Node1 將會把封包傳輸給 Node2，Node2 接收封包後將會傳給 Node 3，由於 Node2 正在傳輸封包，所以 Node1 將不會傳輸封包，當 Node3 傳輸封包給 Node4 時，將產生 hidden node problem，雖然 Node1 不知道 Node3 在傳送，雖然 Node3 的封包不是傳給 Node2，

但是 Node2 將會監聽到 Node3 的封包傳送，此時若 Node1 傳送封包，將有可能導致封包碰撞遺失的情況發生，所以必須等 Node3 將封包傳給 Node4，而當 Node4 傳送封包給 Node5 時，Node1 則可傳送下一個封包，Node2 不會聽到 Node4 的封包傳送，透過此封包傳送排程將可避免封包在傳輸過程中因為碰撞遺失，但是此時間排程還是得透過實際測試調變，由於最後成果呈現將透過 COOJA 模擬的方式，在大量封包傳送前，將會事先分析於 COOJA 模擬器中的封包傳輸排程。

圖 4-17、Queuing in multi hop transmission

4.3 結論

本章節的主要目的於利用 Contiki OS 實際建構 6LoWPAN 網路環境，在多跳環境中傳輸 IPv6 UDP 封包，計算在無線感測網路下 IPv6 封包的傳輸效率，且經

由無線封包截取器(sniffer)，觀察 IPv6 MTU 大小與 Fragment 之分割數目來探討對於網路效能之影響，並分析 6LoWPAN 在多跳環境中所能傳輸之最大 IPv6 MTU 與 Fragment 之分割數目。本研究是在 ATmega128RFA1 微處理器為核心的無線感測器所建構的 6LoWPAN 環境下進行，透過實際的封包傳輸，sniffer 之擷取，在多跳傳輸過程中將會增加來源節點的 MAC 位址，因此將會導致封包在多跳的傳輸中多出一個片段封包，所以將在一開始的 IPv6 封包中空出 MAC 位址的大小，

此最佳化將會使封包在傳輸過程中不會再增加一個片段封包，此方法除了提升

Goodput，也可降低封包遺失率。

本研究為了提升 IPv6 封包於低功耗有損網路中的傳輸效能，因此將對 IPv6 封包作傳輸排程，事先的排程將可避免不必要的封包碰撞，導致封包在傳輸過程中遺失，由於最後之結果將透過模擬的方式呈現，所以將於下個章節對 IPv6 封包作傳輸排程，從圖 4-17 中可事先了解，PIFS 將會在多跳傳輸過程中遠大於 IPv6 封包傳輸時間，所以在最後程先出來的傳輸效能有所降低將是無法避免的，但此排程確實可避免封包因為碰撞而產生封包遺失。

第五章

RPL RSSI Routing Metric

本研究將提出在低功耗有損網路下以接收訊號強度為基礎且具有動態調整

MTU 之 IPv6 路由機制，同時基於路由整體的接收訊號強度，動態調整 IPv6 MTU 大小以提升 IPv6 封包傳輸成功機率，並且提升整體 Goodput 效能為本研究最終呈現之結果。

5.1 RPL

Routing Protocol for Low-power and loosy network(RPL)是以 IPv6 為基準，被廣泛的使用於低功耗、低運算能力與記憶體受限的嵌入式設備上，提供一個在有損的網路下，具有低功耗且高效率的路由協定。

5.1.1 RPL routing

RPL 是在 Low power and Lossy Networks(LLNs)使用距離向量(Distance Vector) 的 IPv6 路由協議，使用此方法可建立出一個目的指向無循環之樹狀圖

DODAG(Destination Oriented Directed Acyclic Graph)，如圖 5-1 為 DODAG 以樹狀模式進行節點分類，藉由分層之方式來降低整體拓樸之複雜度，RPL 也支援三種通信模式： Multi-Point-To-Point(MP2P) 、 Point-To-Multi-Point(P2MP) 以及 Point-To-Point(P2P)，其中 MP2P 與 P2MP 為其主要之通訊方式，比起以往 WSN

的點對點之通訊能力，透過 RPL 之通訊方式，可及時在訊號品質不穩的狀態時進行路由之轉換，且其擁有備源路線以備不時之需。

圖 5-1、Destination oriented direct acyclic graph (DODAG)

在 6LoWPAN 環境底下，由於節點的能源有限，所以並不適用於大量週期性的路由維護方式，且使用舊有的廣播方式容易造成廣播風暴，所以 RPL 採用

Trickle algorithm 方法來維護路由，Trickle algorithm 是一種傳輸排程的演算法，

用在 WSN 的廣播及維護，其可使用在不同的地方，像是 multicast 廣播、路由的發現以及控制傳輸的時間，Trickle algorithm 的運作方式是每隔一段時間會傳輸特定的 metedata 給鄰近節點，並監聽鄰近節點是否有發出相同之 metadata，若無相

同之 metadata 則將本身之節點訊息封包傳送給與該節點，透過這種方式來達到整體網路拓樸之更新，使用 Trickle algorithm 的好處是網路拓樸若無發生任何變化，

其更新封包將非常少量，反之若網路拓樸發生變動，其也可迅速的將整體網路節點訊息更新完成。

5.1.2 RPL Control Message

RPL 之控制訊息封包分為三種[24]，分別是 DIO(DODAG Information)、

DAO(Destination Advertisement Object)與 DIS(DODAG Information Solocitation)，

各層之間之節點只需與鄰近之節點互相維護，透過這種方式在拓樸的維護上將較為的容易，DIO 之訊息將記錄各別節點的參數訊息，可減少節點須與 Sink 節點溝通之重複通訊。在路由選擇的考量方面，有可以分類為 Routing Metric 與 Constraint

objects，其中 Routing Metric 取決於各路由之定義，像是 Delay、Link Quality、權重．．．等之類的方式，Constraint objects 則是依節點狀態而決定，其相關資訊將透過 DIO 進行傳遞。使用 DIO 控制封包之傳遞，可進行節點之間的狀態資料更新，獲取節點間之資訊，藉此當作下一跳節點之路由選擇依據，當有新的節點欲加入此 DODAG 當中，需等待鄰近節點發送 DIO 之訊息，若新的節點一直沒收到 DIO 訊息，其則會發送 DIS 向鄰近節點請求發送 DIO 訊息，以便加入該 DODAG 中，DAO 之訊息則為各節點資訊送至 Sink 端之封包，RPL 中分為儲存模式(Storing mode)與非儲存模式(Non-Storing mode)，如圖 5-2 所示，儲存模式為

各節點要進行資料之傳送，可搜尋自己的路由表(Routing Table)即可直接傳送至目的地，Source node 欲傳送資料給 Destination node，其只需透過最近的 Common

parent 即可將訊息轉傳，圖 5-3 為非儲存模式的 DODAG，除了 Root 節點具有路由表之外，其餘節點將不具有路由表，所以節點要傳送資訊時，必須依賴 Root 節點來辨識目的節點之路徑，Source node 將訊息傳至 Root 節點，Root 節點搜尋自己的 routing table，將訊息轉傳至 Destination node，在非儲存模式下須依賴週期性的 DAO 封包，更新 Root 節點之路由表，以利節點間封包之傳送。

圖 5-2、DODAG with storing mode 圖 5-3、DODAG with non-storing mode

5.1.3 Routing Metric ETX-Expected Transmission Count

在 RFC6550 [25]中定義了 RPL 的相關標準架構，其網路拓樸為 DODAG，以 Root 端為目標導向之無循環之樹狀圖，根據定義中路由決策以到 Root 端之階層

數(Rank)以及 Object Function(OF)為主，其中透過 Rank 值來避免路徑造成循環狀態，而 OF 則定義了路由決策之條件。其中路由決策包含了兩種定量指標，第一種為節點選擇指標，包括節點狀態、節點能量與節點跳數(Hop Count)，第二種為鏈路指標，其代表路由路徑之狀態，包括 ETX－Expected Transmission Count、鏈路之 Throughput、鏈路可靠性、鏈路延遲等，根據不同的網路環境，可選擇不同的路徑狀態作為定量指標，藉由相關 OF 之設定即可明確定義目前所需之路由決策條件，由於 RFC6551[26]中有提到，目前無法將多個 OF 應用於同一個 DODAG 拓樸環境，代表著在 OF 中只能選擇其中一項作為 RPL 整體路由的決策條件，故本研究設計出一個新的 OF 參數，透過本研究分析出對應 RSSI 之 Packet successful

rate 與 Hop Count 數之結合，調變出一具有較高傳輸效能之 RSSI-based RPL 路由選擇機制。

5.2 RSSI-based RPL 路由選擇機制

本研究使用 Contiki OS 來建構 6LoWPAN 環境，在 Contiki 中的預設 RPL 路由機制，在路由建構時是使用 hop count 作為主要的路由判斷方式，每經過一個

hop 將增加其 metric 的權重，對於每個節點其有相對應之 ETX 數值，RPL 在建構路由時將會從 Root 節點發出 DIO 訊息，DIO 之訊息封包裡將會對每經過節點之 ETX 數值做相加，所以每個節點皆會有到 Root 節點之總 ETX 權重，因此 Contiki RPL 將會以最短路徑(最低跳數)作為優先選擇之路由路徑，但在預設 RPL 路由機

制中忽略因 IPv6 封包因使用 Route-over 路由，傳輸路徑上的每個節點都將會進行 IPv6 fragment 之重組、分割及再傳送的過程，因此僅單純計算各別 IEEE

802.15.4 封包之傳輸機率將不足以表示實際的 IPv6 封包傳輸成功機率。另外，

在預設 RPL 路由機制中，RPL 在建構路由時將會從 Root 節點發出 DIO 訊息，每個節點需要經過足夠之統計時間，方能實際反應較正確的到 Root 節點之總 ETX 權重，而在 RSSI-based RPL 路由選擇機制，僅需要透過從 Root 節點發出 DIO 訊息來判斷各鏈路間的 RSSI 值，即可即時透過表 5-1 得知該 RSSI 對應到各不同長度之 IPv6 MTU 之 IPv6 封包傳輸成功機率，如此將大幅節省 Root 節點發出 DIO 訊息之數量與 RPL 路由建構所花費之時間。而且本研究所提出的 RSSI-based RPL 路由選擇機制是根據目前節點至 Root 節點對於對應節點的整條路徑的 IPv6 封包成功傳送率做為 ETX 值。由於 DODAG 內部節點若需與網際網路連結，皆須要透過 Root 節點轉發，反之網際網路之訊息欲傳至 DODAG 內部節點，也須經過

Root 節點才有辦法將訊息傳至 DODAG 內部節點，因此，選擇對其最有利的路由

在文檔中在低功耗有損網路下改善IPv6 路由機制之研究 (頁 57-0)