ContikiMAC翻譯

1、ContikiMAC 周期性休眠RDC協(xié)議Adam Dunkels（瑞典）2011.12摘要低功耗設備必須盡可能的保持射頻的關閉，以達到盡量的能耗，但也需經常的醒來以接收周圍節(jié)點的通信數(shù)據(jù)。這份報告描述了ContikiMAC周期性休眠機制，在Contiki 2.5中的默認機制中使用了一個高效的喚醒機制，并使用一系列的時序管理盡可能使射頻處于關閉狀態(tài)。使用ContikiMAC，節(jié)點可以在網絡中通信時，保持基本上99%的時間中射頻都處于關閉狀態(tài)。這份報告描述了ContikiMAC機制，測量單個ContikiMAC操作的能量消耗，以及評估快速休眠和時序鎖定的優(yōu)化效果。1. 前沿低功耗無線設備必須維持

2、嚴格的能耗以獲得數(shù)年的生存時間。在低功耗無線設備的所有部件中，無線收發(fā)器通常能耗消耗更高。無線收發(fā)器在被動監(jiān)聽其他設備的信號中的功率與主動傳輸?shù)墓β室恢?，因而收發(fā)機必須完全的關閉以節(jié)省能量。因為節(jié)點在收發(fā)機關閉狀態(tài)不能接受任何數(shù)據(jù)，周期性的休眠管理機制必須被用于不時地打開收發(fā)機。在多年發(fā)展中，提出了許多的周期休眠機制（例如，Dutta 和Dunkels 的更加徹底的周期休眠機制的審視）；這篇文檔描述了ContikiMAC的周期休眠機制，使用的是Contiki 2.5 中的默認機制。ContikiMAC被設計來易于理解和實現(xiàn)。ContikiMAC僅使用異步機制，沒有同步信息，也沒有額外的包頭數(shù)據(jù)

3、。ContikiMAC數(shù)據(jù)包是普通的鏈路層信息。ContikiMAC具有更為高效節(jié)能的喚醒機制。通過一系列的精準的時間約束來實現(xiàn)。另外，ContikiMAC使用了快速休眠的優(yōu)化方法，以允許快速的檢測到失敗的喚醒，并且采用傳輸時序鎖優(yōu)化方法，允許傳輸數(shù)據(jù)時能耗的實時優(yōu)化。ContikiMAC中的機制是由現(xiàn)有的周期循環(huán)機制中啟發(fā)而來的。周期喚醒的想法在許多的協(xié)議中都使用過，如B-MAC,X-MAC和BoX-MAC。時序鎖優(yōu)化已經先前由WiseMAC中所推薦使用，也已經被用于其他的一些協(xié)議。重發(fā)數(shù)據(jù)包作為喚醒方式也已經被TinyOS的BoX-MAC協(xié)議所使用。本報告的結構如下所示。第二部分介紹Con

4、tikiMAC機制和它的原理。第三部分介紹在Contiki 2.5系統(tǒng)中的ContikiMAC實現(xiàn)。第四部分評估ContikiMAC協(xié)議的節(jié)能效果，包含微基準測試和在網絡中的數(shù)據(jù)收集。相關工作在第五部分介紹，并且第六部分做總結。圖1. ContikiMAC：節(jié)點在大部分時間內休眠，周期性的醒來檢測射頻信號。如果檢測到了信道中有數(shù)據(jù)包傳輸，接收端保持喚醒狀態(tài)以接收數(shù)據(jù)包，并發(fā)送鏈路層確認信息。當發(fā)送數(shù)據(jù)包時，發(fā)送端不斷重發(fā)數(shù)據(jù)包直至收到鏈路層確認信息。圖2. 廣播數(shù)據(jù)包在整個喚醒周期內不斷重發(fā)2. ContikiMACContikiMAC是一個射頻周期休眠（Radio Duty Cycling

5、Protocol）協(xié)議，使用周期性的喚醒來監(jiān)聽鄰居節(jié)點的數(shù)據(jù)包傳輸。如果檢測到數(shù)據(jù)包傳輸，接收端保持喚醒以能夠接收完整的數(shù)據(jù)包。當數(shù)據(jù)包被成功接收時，接收端發(fā)送一個鏈路層確認信息。為了傳輸數(shù)據(jù)，發(fā)送端不斷重發(fā)數(shù)據(jù)包直到接收到來自接收端的鏈路層確認信息。發(fā)送廣播包時不要求確認。另外，發(fā)送端會在整個周期內重發(fā)數(shù)據(jù)包以確保所有的鄰居可以接收到。ContikiMAC的基本原理如圖1和圖2所示。圖3. ContikiMAC傳輸和CCA時間2.1 ContikiMAC 時序關系ContikiMAC有一個高效節(jié)能的喚醒機制，依賴精確的時間控制。ContikiMAC喚醒使用了低代價的信道確認(CCA)機制，使

6、用射頻收發(fā)機中RSSI信息用來給出信道中射頻能量的指示。如果RSSI低于某個給定的閾值，CCA會返回正值，標示信道內飾沒有信號的。如果RSSI值高于某個給定的閾值，CCA會返回負值，標示信道現(xiàn)在正被使用。ContikiMAC時序關系如圖3所示。從圖中所示的各個時間為:ti : 數(shù)據(jù)包間隔；tr : 一個穩(wěn)定的RSSI測量所需的時間，用以給出一個穩(wěn)定的CCA值；tc : 每個CCA間的間隔；ta : 接收數(shù)據(jù)包和發(fā)送確認包之間的間隔；td : 接收端成功接收到確認信息所需的時間；圖4. 數(shù)據(jù)包的傳輸時間必須足夠長，才不會落在兩個CCA間隔的時間內。所有的時間必須滿足一系列的約束。首先，對于ti，

7、每個傳輸數(shù)據(jù)包之間的間隔，必須要小于tc，每個CCA之間的間隔。這是為了確保第一個或者第二個CCA能夠檢測到傳輸?shù)臄?shù)據(jù)包。如果tc小于ti，兩個CCA將有不會可靠的檢測到數(shù)據(jù)傳輸。ti和 tc的關系也限定了ContikiMAC中所能支持的數(shù)據(jù)包的最短大小，如圖4所示。對于ContikiMAC，使用兩個CCAs來檢測數(shù)據(jù)，傳輸包長不能太短而使其落在兩個CCAs之間。特別的，ts，最短數(shù)據(jù)包的傳輸時間，必須要長于tr + tc + tr。當一個CCA檢測到數(shù)據(jù)包的傳輸時，ContikiMAC保持射頻的打開來接收到完整的數(shù)據(jù)包。當一個完整的數(shù)據(jù)包被接收后，發(fā)送一個鏈路層確認信息。發(fā)送確認信息的時間t

8、a，和確認信息被檢測到的時間td，確保要小于CCA間隔tc。我們能夠構建出完整的ContikiMAC時間約束關系為：ta + td ti tc tc + 2tr ts. (1)使用IEEE 802.15.4 鏈路層和一個特定的收發(fā)器，在式（1）中的部分變量可以確定。首先，ta，接收到數(shù)據(jù)包和確認發(fā)出間的時間，在IEEE 802.15.4規(guī)范中已被指定為12個符號時間。在802.15.4，一個符號長為4/250 ms，則ta=48/250=0.192ms。第二，IEEE 802.15.4接收端可以在4字節(jié)的前導碼和1字節(jié)的幀起始符傳輸后可以檢測到確認信息接收，時間為40/250ms。因此，td=

9、40/250。最后，tr在CC2420的數(shù)據(jù)手冊中已給出，時間為0.192ms。使用這些數(shù)據(jù)代替式（1），式(1)變?yōu)椋?.352 ti tc tc + 0.384 0.736ms，為所能處理的最短數(shù)據(jù)包的大小做了限制。在250kbps的傳輸速率時，意味著數(shù)據(jù)包的大小至少為23字節(jié)，包含前導，幀起始符和長度域，剩余16字節(jié)的包數(shù)據(jù)域。為了確保所有的數(shù)據(jù)包都大于最短包長，數(shù)據(jù)包中可能添加額外的數(shù)據(jù)?；蛘?，如果網絡層可以確保數(shù)據(jù)包不會低于一個給定值，則不會添加額外的數(shù)據(jù)。例如，在IPv6的網絡中，數(shù)據(jù)包攜帶完整的IPv6頭部時，必然會大于在IEEE 802.15.4的鏈路層中所要求的Contiki

10、MAC的最短包長。使用6lowpan IPv6的頭部壓縮后，數(shù)據(jù)包可能會變小，但是確保一個最短包長的方法很簡單：不要壓縮低于某個給定長度的IPv6的數(shù)據(jù)包。Contiki 2.5 中使用的ContikiMAC實現(xiàn)如下：ti=0.4ms，tc=0.5ms，ts=0.884ms。2.2 包檢測和快速休眠ContikiMAC 中的CCAs并不能可靠的檢測數(shù)據(jù)包的傳輸:他們只能檢測到射頻信號強度高于某個設定的閾值。檢測到射頻信號可能意味著，一個鄰居節(jié)點正在傳輸數(shù)據(jù)包至接收節(jié)點，或者鄰居節(jié)點正在傳輸至另外的一個接收節(jié)點，有或者其他的設備正在發(fā)送無線信號，恰巧被CCA檢測到。ContikiMAC必須能夠識

11、別這些事件并作出合適的反應。如果一個鄰居正在發(fā)送數(shù)據(jù)包給接收節(jié)點，接收節(jié)點應該保持喚醒以接收到完成的數(shù)據(jù)包并發(fā)送鏈路層確認。其他檢測到數(shù)據(jù)傳輸?shù)墓?jié)點，能夠快速的再次進入休眠。但是可能的接收節(jié)點不能快速的休眠，因為其必須要接收到完整的數(shù)據(jù)包。當一個CCA檢測到射頻活動后，決定多久喚醒時間的一種樸素方法便是tl + ti + tl，tl為可能傳輸?shù)淖铋L數(shù)據(jù)包的傳輸時長。這就確保了即使CCA在數(shù)據(jù)包傳輸?shù)钠鹗继幮褋?，也可以被接收端接收到完整的?shù)據(jù)包。圖5. ContikiMAC的快速休眠優(yōu)化：如果在tl之前沒有檢測到信道為空，接收端進入休眠。如果信道空閑時間超過ti，接收端進入休眠。如果在信道空閑期

12、后沒有接收到數(shù)據(jù)包，即使檢測到信道活動，接收端也會進入休眠。快速休眠優(yōu)化使得可能的接收節(jié)點可以盡快的進入休眠，在CCA由于噪聲而喚醒的情況下?？焖傩菝邇?yōu)化影響ContikiMAC傳輸?shù)奶囟Ｊ饺缦滤尽Ｊ紫?，如果CCA檢測到射頻活動，但是射頻活動時間長于最大數(shù)據(jù)包傳輸時長tl，CCA檢測到噪聲并進入休眠，也就是如果射頻活動之后未緊跟這一個空閑期。第二，如果射頻活動后有一個空閑期，但是長于兩個數(shù)據(jù)包間的間隔，ti,接收端也會進入休眠。第三，如果在射頻活動后有一個正確長度的空閑期，之后又可以檢測到射頻活動，但是無法檢測到包起始位置，接收端也會進入休眠。這個過程在圖5中被描述。2.3 傳輸時序鎖定如

13、果我們假定每個接收端有一個周期性且穩(wěn)定的喚醒間隔，發(fā)送端便可以利用接收端喚醒時間的知識來優(yōu)化傳輸。發(fā)送端能夠通過記下從接收端收到鏈路層ACK的時間來學習到接收端喚醒時間。因為接收端必須醒來以接收數(shù)據(jù)包，發(fā)送端可以假定接收到鏈路層ACK意味著發(fā)送端已經成功在接收端的喚醒窗口內傳輸了數(shù)據(jù)，因此發(fā)送端可以發(fā)現(xiàn)接收端的喚醒時間。在發(fā)送端學習了接收端的時序后，發(fā)送端著手開始在接收端正要進入喚醒時間前發(fā)送數(shù)據(jù)給接收端。這個過程如圖6所示。圖6. 傳輸時序鎖定：一次成功的數(shù)據(jù)傳輸后，發(fā)送端可以學習到接收端的喚醒時間，隨后便可以發(fā)送更短的傳輸了。3. 實現(xiàn)在Contiki 2.5中的ContikiMAC實現(xiàn)使

14、用Contiki實時定時器（rtimer）來調度周期性喚醒時間，以確保在許多其他的進程在運行時依然有一個穩(wěn)定的時間行為。實時定時器的優(yōu)先級高于任何Contiki中的進程無論在任何時間里。ContikiMAC的喚醒機制作為一個線程在運行，由一個周期性實時定時器。這個線程執(zhí)行周期性的喚醒和快速休眠優(yōu)化。傳輸過程有一個普通的Contiki進程所驅動。如果在傳輸過程中喚醒事件被調度，喚醒定時器會開啟一個新的喚醒周期，而不是執(zhí)行喚醒后的操作。時序鎖定機制作為ContikiMAC中的一個分離的模塊，允許被其他的周期休眠機制所使用，例如Contiki X-MAC實現(xiàn)。時序鎖定機制維持了一個鄰居列表和他們的喚

15、醒時間。ContikiMAC傳輸邏輯記錄每個包傳輸?shù)臅r間。當一個鏈路層確認被接收時，它標示了時序鎖模塊上一個包的傳輸時間。這個時間被用于作為接收端的喚醒時間的估計。在開始一次傳輸前，ContikiMAC傳輸邏輯調用時序所模塊，檢查是否有接收端的喚醒時間記錄。如果有的話，時序鎖模塊將數(shù)據(jù)包放入發(fā)送隊列，并設置一個回調定時器在預估的接收端喚醒時間。ContikiMAC將假定當回調發(fā)生的時候傳輸開始。傳輸時間將顯著的小于正常的傳輸時間，因為它僅僅在接受端正要醒來時發(fā)送數(shù)據(jù)。減小了傳輸?shù)臅r間因而也減少了射頻的擁塞。如果一個時序已知的鄰居重啟或其時鐘發(fā)生偏移較多時，與這個鄰居的通信將會失敗。為防止這種情

16、況的發(fā)生，ContikiMAC為每個已知節(jié)點維護一個失敗傳輸?shù)拇螖?shù)。當達到一定數(shù)量的傳輸失敗后(在Contiki 2.5中為16)，鄰居節(jié)點從已知的鄰居列表中刪除。同樣的，如果在一個固定的時間內（在Contiki 2.5中為30s）沒有收到鏈路層ACK，無論多少次的傳輸，鄰居節(jié)點都會被刪除。4. 評估這份報告評價了ContikiMAC的兩個方面：單個ContikiMAC操作的能量消耗以及在一個數(shù)據(jù)收集傳感器網絡中ContikiMAC的能量消耗。除了在此處呈現(xiàn)的結果外，我們還在最近的許多工作中使用了ContikiMAC。為獲取更多的ContikiMAC性能結果，躲著可以參照Dunkel等；。圖7

17、. 一個ContikiMAC喚醒時間，沒有檢測到 圖8. 一個CCA喚醒，檢測到了信號任何信號。在下圖中所示是兩個CCAs。 活動，同時快速休眠機制將射頻迅速關閉。4.1 微基準我們測試了單個ContikiMAC操作的能量消耗，通過測量運行ContikiMAC 的Tmote Sky mote的電流曲線。我們在Tmote Sky的電源部分串聯(lián)一個100的電阻，通過示波器測量電阻的電壓來得到電流曲線。我們還通過注冊射頻的狀態(tài)在Tmote Sky的一個I/O引腳上，使用一個高電流值表示視頻開，一個低電流值表示射頻關，同樣使用示波器來測量引腳的狀態(tài)。所有的測量使用帶有8HZ喚醒頻率的ContikiMA

18、C，意味著每次的喚醒間隔為125ms。圖9. 廣播接收：喚醒，包檢測，接收廣播數(shù)據(jù)包圖10. 單播接收：喚醒，包檢測，接收單播數(shù)據(jù)包圖7描述了ContikiMAC的喚醒過程中沒有檢測到數(shù)據(jù)包的電流曲線。在下面的圖中，可以看到射頻打開了兩次，執(zhí)行了ContikiMAC喚醒中的兩個CCAs。圖8描述了一個ContikiMAC喚醒過程，其中在第二個CCA處檢測到了噪聲的射頻活動。射頻隨后保持打開了一段時間，知道快速休眠優(yōu)化機制將射頻關閉。圖9和圖10分別描述了一個廣播包的接收和一個單播包的接收。在兩種場景中，作為ContikiMAC喚醒機制的一部分，射頻都被打開。射頻隨后保持打開狀態(tài)知道數(shù)據(jù)包被接收

19、?？梢钥吹皆趶V播場景中射頻打開的時間比單播場景更長。這是因為在單播場景中包含有ACK傳輸確認的功能。在圖11至圖13中描述了傳輸過程中的電流曲線。圖11描述了廣播傳輸?shù)碾娏髑€。一個廣播包傳輸必然會醒來并將數(shù)據(jù)包傳遞給所有的鄰居。因此運行在所有的醒來階段。因為一個廣播包傳輸并不會期待任何鏈路層的確認，發(fā)送者可以在每次數(shù)據(jù)包傳輸?shù)拈g隔中關閉射頻以節(jié)省能量。圖12描述了單播傳輸至一個先前未知的鄰居的電流圖。在這種情況下，鄰居的喚醒時間發(fā)生在大約60ms后，這導致了發(fā)送端重發(fā)了數(shù)據(jù)包持續(xù)了70ms。在發(fā)送端的開始部分，初始的CCA也可以看到。隨后的傳輸至相同接收端的過程可以被優(yōu)化為在鄰居期待的醒來時

20、間的起始處傳輸，如圖13所示，顯示了由于時序鎖的優(yōu)化減少了許多次的重復傳輸。圖11. 廣播傳輸圖12. 未同步的單播傳輸（隨后的喚醒在110ms處）圖13. 同步的單播傳輸（隨后的喚醒在110ms處）圖14. 單個ContikiMAC操作的能量消耗通過計算從圖7至圖13中的圖示中的區(qū)域，我們可以計算得到每個操作的能量消耗。結果顯示在圖14上。我們看到廣播傳輸?shù)南氖沁h大于喚醒的操作的。這是有好處的：喚醒操作是在ContikiMAC中的最為頻繁的操作每秒執(zhí)行很多次因而應該是顯著的低于其他操作的。有了圖14中的信息，我們可以比較ContikiMAC喚醒操作與其他的周期休眠機制的喚醒操作的能耗。表1

21、中顯示了在ContikiMAC中的喚醒操作的成本與Contiki X-MAC實現(xiàn)和Hui and Culler的機制的比較。表1. 喚醒操作的能耗比較圖15. 有丟包率的數(shù)據(jù)采集網絡中周期休眠，使用X-MAC與ContikiMAC，作為喚醒頻率的函數(shù)（圖中表示為信道采集速率）4.2 網絡電量消耗為了評估ContikiMAC和優(yōu)化效果的網絡電量消耗，我們在Contiki仿真環(huán)境中運行了一系列的仿真。Contiki仿真環(huán)境包含Cooja網絡模擬器和MSPsim設備模擬器。MSPsim提供了周期精確度的Tmote Sky仿真，使用一個符號精確度的CC2420射頻模擬器。它能夠模擬ContikiMAC

22、的行為在一個時間精確和可控的環(huán)境中。圖16. 使用ContikiMAC的網絡周期休眠，沒有丟包率的網絡中的所有節(jié)點的平均值。我們運行了一系列的仿真使用20個節(jié)點的仿真拓撲。所有的節(jié)點運行Contiki和Contiki Collect協(xié)議。Contiki Collect協(xié)議是Contiki Rime協(xié)議棧的一部分，是一個不需要地址的數(shù)據(jù)收集協(xié)議，構建了一個樹，根節(jié)點為一個或多個sink節(jié)點，通過這些節(jié)點數(shù)據(jù)包進行轉發(fā)。Contiki Collect的性能已經通過實驗驗證與其他的數(shù)據(jù)收集協(xié)議類似，例如Tiny OS Collection Tree Protocol。節(jié)點向sink節(jié)點每隔120s發(fā)

23、送一個數(shù)據(jù)包。每次傳輸都通過31次的hop-by-hop的轉發(fā)。每個節(jié)點發(fā)送100個數(shù)據(jù)包向sink節(jié)點。仿真運行直到所有的數(shù)據(jù)包都被sink節(jié)點接收。在所有的仿真中，Contiki Collect能夠成功的將所有的數(shù)據(jù)包發(fā)送給sink節(jié)點。仿真的目的既是測量ContikiMAC中典型的RDC，又可以測量快速休眠和時序鎖優(yōu)化的效果。我們控制休眠頻率和仿真中的丟包率水平的值。通過運行一系列沒有丟包率情況下的仿真：數(shù)據(jù)包不會因為鏈路狀況丟包，僅僅會由于與其他數(shù)據(jù)包的沖突而丟包。第二個仿真設定使用鏈路丟包的模型，丟包的概率是與發(fā)送端與接收端的距離的平方成正比的。我們通過使用Contikis Powe

24、rtrace工具測量射頻周期。使用射頻休眠周期作為網絡中的能耗的代理，作為射頻收發(fā)器有一個線性的能耗，依據(jù)其時間。我們首先比較了ContikiMAC和X-MAC的性能在一個有丟包率的網絡環(huán)境中。我們期待X-MAC的能耗會顯著的高于ContikiMAC的能耗，由于在X-MAC中的更高成本的喚醒機制。圖15顯示了這個結果：ContikiMAC的能耗是顯著的低于X-MAC在所有的實驗的頻率上。然后，我們測量了獨自的ContikiMAC優(yōu)化的效果。我們使用ContikiMAC優(yōu)化開和關操作運行仿真。結果顯示在圖16和圖17中。圖16中顯示了沒有丟包率環(huán)境下的RDC周期休眠。我們可以看到RDC隨著喚醒頻

25、率而增加:有更多的喚醒，整個網絡的能耗也會增加。我們還可以看到快速休眠和時序所優(yōu)化顯著的降低了能耗。圖17顯示了有丟包率網絡中的結果?？梢钥吹皆谟衼G包的環(huán)境中時序鎖和快速休眠優(yōu)化更有效。這是因為一個時序鎖定的傳輸比未添加時序優(yōu)化的傳輸更短，導致了更少的傳輸能耗以及更少的射頻沖突。5. 相關工作射頻收發(fā)器的高能耗是一個廣為人知的問題，激發(fā)了在RDC上的許多的工作。RDC機制可以被分成兩個主要的部分：同步機制和異步機制。同步機制依賴同步過的鄰居節(jié)點，然而異步機制并不依賴任何先驗的同步信息。異步機制可以進一步的分拆為發(fā)送端發(fā)起的和接收端發(fā)起的機制。在發(fā)送端發(fā)起的機制中，發(fā)送端在發(fā)送端和接收端發(fā)起通信，然而在接收端發(fā)起的機制中，接收端發(fā)起通信。ContikiMAC是一個發(fā)送端發(fā)起的異步機制。這篇文章提供了許多的機制的例子從這些類別中，以及混合類別，融合了不止一種類別特征的機制。同步協(xié)議的例子如早期工作S-MAC和T-MAC，以及最近的