無線自組網節(jié)點極低基礎功耗方案的設計

黃小兵, 聶蘭順

(哈爾濱工業(yè)大學 計算機科學與技術學院, 哈爾濱 150001)

引言

水表、電表、熱表是常用的家庭計量儀器,出于成本的考慮,越來越多的家庭傾向于使用無線數據傳輸的方案。然而無線自組織多跳網絡面臨一個非常嚴峻的現實問題,即電池供電長周期運行的節(jié)點必須有極低的基礎功耗。無線自組織多跳網絡特點如下：

(1)無線自組織多跳的網絡。無線自組網需要有物聯(lián)網操作系統(tǒng)和微小的IPv6協(xié)議棧[1],操作系統(tǒng)為了更好地支持微小的IPv6協(xié)議棧必須提供滿足一定粒度的定時服務。目前主流的開源物聯(lián)網操作系統(tǒng)為Contiki[2]、TinyOS、FreeRTOS,雖然方便管理軟件和硬件資源,但也增加了功耗開銷。

(2)電池供電長周期運行。 根據實際的需求調查,面向抄表領域采用的工業(yè)電池容量為3 500 mAh,考慮自放電后能夠提供給節(jié)點的電量大約僅為50%。這樣要滿足10年的網絡壽命,節(jié)點每天的平均功耗必須不超過20uA。

(3)極低的基礎功耗。 基礎功耗是指不包括數據收發(fā)和偵聽行為,操作系統(tǒng)管理軟硬件資源帶來的功耗開銷。從業(yè)務角度分析,節(jié)點的平均功耗不能夠超過20uA,那么節(jié)點的基礎功耗應該很低,需要小于10uA。從節(jié)點的硬件功耗分析,比如CC1120節(jié)點待機的情況下為2.3uA,活躍時為2.85mA,那么使用操作系統(tǒng)進行管理時基礎功耗應該盡量的靠近2.3uA,這樣預留給網絡通信的能量就越多。Raghunathan等人在文獻[1]中提出沒有感興趣的事件發(fā)生時,節(jié)點應該盡可能處于超低功耗狀態(tài)。然而多跳網絡需要時刻保持活躍的狀態(tài)，這樣節(jié)點才能進行工作。

針對上述問題,本文對主流的開源IOT操作系統(tǒng)進行分析?；诓僮飨到y(tǒng)的時鐘,提出了一種極低基礎功耗方案的設計,即在內核中創(chuàng)建一個軟時鐘。該軟時鐘用來控制操作系統(tǒng)的其它時鐘(這些時鐘驅動事件，維持網絡正常的運行)，進而控制網絡活躍狀態(tài)和非活躍狀態(tài)的快速轉換。

1 無線自組網節(jié)點功耗分析

1.1 節(jié)點硬件概述

1.1.1 節(jié)點硬件功耗特性

無線自組網節(jié)點硬件包括4個主要組成部分：射頻通信模塊、微控制器、傳感器、電源。現有的主流硬件為CC1310、CC1120、CC2650、Avr、Sky、Zoul等,雖然每個硬件各項參數不同,但是大多數主流的自組網模塊都具有較低的待機電流。例如CC1310和CC1120節(jié)點的主要功耗參數見表1,表中CC1120的硬件指CC1120射頻模塊與MSP430F5418A MCU構成網絡節(jié)點。

表1 CC1310硬件平臺和CC1120硬件平臺的參數

1.1.2 節(jié)點硬件時鐘特性

一個典型的無線網絡節(jié)點有多個時鐘源：低頻時鐘源精度相對較高，但在低分辨率的定時(見表2)所有的RTC精度都≤40 ppm。高頻時鐘源雖然有很高分辨率的定時,但是通常不能夠滿足40 ppm的精度要求。

表2 無線網絡節(jié)點時鐘源的比較

節(jié)點活躍狀態(tài)既要用低頻時鐘源(驅動事件)來節(jié)約能量,同時也要使用高頻時鐘源(驅動CPU工作)來維持系統(tǒng)正常的組網通信。節(jié)點非活躍狀態(tài)時需嚴格控制事件觸發(fā)、進行IO處理、外設處理。

在抄表領域,節(jié)點與表的通信依賴于標準接口,以串口為例，節(jié)點功耗主要來自MCU、Timer&RTC、Radio、UART、Watchdog。表1,2中數據表明了這類設備具有極低基礎功耗的硬件基礎和支撐系統(tǒng)運行的時鐘基礎。

1.2 IOT操作系統(tǒng)的功耗來源

針對自組網,目前主流的軟件架構是物聯(lián)網操作系統(tǒng)和微小的IPv6網絡協(xié)議?！，F有開源的物聯(lián)網操作系統(tǒng)為Contiki、TinyOS、FreeRTOS,在無線傳感器網絡中有很廣泛的用途。然而除TinyOS能夠滿足極低的基礎功耗外,Contiki和FreeRTOS均不能滿足極低的基礎功耗條件。

Raghunathan等提出基于事件驅動的功耗管理方式能夠最大化網絡壽命,這種設計思想幾乎用在了所有主流的物聯(lián)網操作系統(tǒng)上。而Dunkels等指出基于事件驅動編程存在編寫、維護和調試代碼的困難,因此提出具有線程風格的事件驅動抽象層protothreads,并且用在了Contiki中。但是Contiki的進程管理功耗開銷大,經在CC1310平臺上測試結果為106 uA。Levis等指出TinyOS提供的功耗服務能夠達到15 uA的基礎功耗,并且TinyOS的Power-Management Interfaces提供開啟和關閉服務的功能,可見TinyOS具有很優(yōu)秀的功耗管理機制。FreeRTOS使用搶占式、多線程的編程模型,可以根據應用需求選擇TCP/IP或者UDP/IP服務[6]。TI-RTOS在FreeRTOS基礎上進行了裁剪,保存了內核的任務管理和時間管理。然而在CC1310上測試發(fā)現TI-RTOS基礎功耗達到66uA。

通過分析實驗結果,主流的操作系統(tǒng)采用了基于事件驅動的進程管理思想,通常的事件驅動指的是定時器中斷事件。系統(tǒng)為了達到一定的及時性要求,定時器中斷事件的粒度通常不會太大,如Contiki的etimer定時器中斷粒度默認為1/128秒。如此頻繁的定時器中斷,帶來較高的基礎功耗開銷。此外,物聯(lián)網的應用多種多樣,操作系統(tǒng)需要兼容各類服務,因此需要頻繁的定時器中斷。在極低基礎功耗(如幾個uA)情況下，需要嚴格控制操作系統(tǒng)的開銷。

1.3 民用計量領域物聯(lián)網應用的典型特點

不同于工業(yè)領域的物聯(lián)網,民用計量領域的物聯(lián)網技術實時性要求不高。每個節(jié)點每天只需要傳送少量的數據,典型值為20～100個字節(jié)。同時,這類應用是周期性的,每個節(jié)點上報的數據時間并沒有嚴格的限制,通常在指定的時間內上報成功即可。完成數據上報任務后,節(jié)點可處于休眠狀態(tài)。等待下一個上報時間段繼續(xù)上報數據。

大多數自然和人造系統(tǒng)都能描述為網絡，其中實體通過物理或者抽象邊連接，這迅速增加了人們對網絡理論及其應用領域的研究興趣 [1-3].基礎設施系統(tǒng)，如電力網、因特網、車輛運輸系統(tǒng)、航空網等都是網絡實例，這些網絡給人們的生活提供了極大的便利.然而，在這些網絡中，非常局部的攻擊或隨機故障就能引發(fā)整個網絡的級聯(lián)崩潰，造成嚴重經濟損失和社會混亂.典型的例子如，發(fā)生在美國、加拿大、意大利、印度、中國等國家的數次大規(guī)模停電[4]，因特網崩潰以及一些大城市頻繁的交通癱瘓[5].在此背景下，網絡應對攻擊和隨機故障引發(fā)的級聯(lián)故障的魯棒性和安全性一直是網絡科學領域的研究熱點.

2 Contiki定時器功耗分析

Contiki操作系統(tǒng)是一款輕量級的操作系統(tǒng),支持動態(tài)的加載和替代某個服務,是建立在事件驅動的內核上[8]。在Contiki內核中,有2類系統(tǒng)定時器,分別是etimer和rtimer。Contiki的進程輪詢使用etimer定時器驅動。出于更高定時精度的要求,6LoWPAN[9]協(xié)議棧中的數據鏈路層使用rtimer定時器驅動。

假定某個IOT操作系統(tǒng)有n類周期性的系統(tǒng)定時器,每個定時器的固定頻率為Fi,單位Hz；中斷持續(xù)時間為Di,單位ms；平均電流為Ci，單位uA；這樣定時器Timeri的平均功耗如下：

(1)

則系統(tǒng)定時器總平均功耗為：

(2)

(3)

系統(tǒng)平均功耗total_avg_current為：

(4)

etimer需要ms級別的計時粒度,rtimer需要us級別的計時粒度。根據CC1310的時鐘特性,3路通道RTC和4個通用定時器模塊均能夠滿足etimer和rtimer的定時精度。由于4個通用定時器模塊帶來的功耗高于3路通道RTC,因此選用3路通道RTC中的2路分別實現etimer和rtimer。

默認情況下etimer中斷觸發(fā)的頻率為128 Hz,rtimer中斷觸發(fā)頻率為8 Hz。無論選用哪一種,中斷都會帶來高功耗開銷。采用RTC實現的rtimer、etimer一次中斷的電流如圖1所示，功耗高達410 uA,持續(xù)時間達2 ms。

圖1 rtimer、etimer中斷電流

根據公式(1)得到Contiki操作系統(tǒng)的etimer(每1/128秒觸發(fā)一次)平均功耗為105 uA。實際測試的平均功耗為106.482 uA，如圖2所示；rtimer(每1/4秒觸發(fā)2次)的平均功耗為6.57 uA。由公式(2)得到etimer+rtimer的平均功耗為112.57 uA。

圖2 默認情況下etimer的平均電流

3 基于contiki的極低基礎功耗方案的設計

解決極低基礎功耗有2種常見方式：一是盡可能地降低etimer、rtimer中斷的頻率；二是使用更低頻率的時鐘，來維持網絡的活躍狀態(tài)和非活躍狀態(tài)的切換。這2種方式都需要滿足多跳網絡性能(如可靠性、網絡功耗)不能受損。

針對方式一分析如下：在6LoWPAN網絡里有很多的時間粒度限制,比如CSMA要求退避的時間間隔粒度需要達到125 ms；IPv6網絡層DS6更新必須滿足的最長周期為100 ms；一般對定時要求較苛刻的應用需要滿足62.5 ms。此外,同類型FreeRTOS的系統(tǒng)時間節(jié)拍在1 ms-100 ms之間。由此看來etimer的精度必須在毫秒級別,且不能夠高于62.5 ms,這樣在CC1310平臺上會帶來13+uA的基礎功耗。通過實驗驗證了當etimer周期低于16 Hz時，網絡的性能不佳。在6LoWPAN網絡中MAC層需要使用至少為2 Hz的rtimer,這是為了較小的網絡延遲。當網絡規(guī)模增大,MAC層頻率太低會導致接收方不能及時地接收數據包,從而影響整體網絡的收包率。因此不能簡單的降低操作系統(tǒng)默認的時鐘。

針對方式二,采用更低頻率的時鐘來嚴格控制系統(tǒng)的時鐘行為，并且保證活躍狀態(tài)網絡正常工作，非活躍期系統(tǒng)時鐘完全關閉，這樣能夠達到預期效果。此外，在方式二中，預先對引腳進行拉低電平處理，對外設進行完全關閉。

3.1 新增軟時鐘(soft-timer)

在contiki中,由于不能通過降低etimer、rtimer的頻率來實現極低基礎功耗。因此需要設計一個控制器,合理的控制網絡狀態(tài)。在contiki的時鐘內核中添加一個控制器(軟時鐘soft-timer),其結構體中含有second、minute、hour,于是contiki由原來的2個定時器變成了3個定時器。soft-timer需要一個RTC定時器驅動,RTC的定時間隔必須達到秒級別(如1秒或2秒最佳),幾乎所有的IOT設備均能夠滿足這樣的要求。RTC中斷每觸發(fā)一次就更新soft-timer的狀態(tài)。同時soft-timer維持一個活躍的標志位active_flag,其是一個共享變量，當active_flag=0節(jié)點進入非活躍期,否則節(jié)點進入活躍期?；钴S狀態(tài)的調度可以從根節(jié)點自動獲取,也可以手動靜態(tài)設置。手動配置只需要指定兩個參數：active_period和inactive_period,例如在contiki-conf配置文件中定義active_period=1和inactive_period=35表示每個周期網絡處于非活躍狀態(tài)350分鐘,網絡處于活躍狀態(tài)為10分鐘。

3.2 etimer調度設計

結合軟時鐘網絡狀態(tài)控制和contiki操作系統(tǒng)的進程管理,設計出如圖3所示soft-timer控制下的contiki進程調度狀態(tài)機。在圖3中,深灰色區(qū)域是contiki系統(tǒng)默認的處理方式,淺灰色區(qū)域為新增的部分。在inactive期間etimer中斷關閉,計時變量count不會更新,則不會有過期的事件,因此不會對事件進行poll操作,contiki進程處于靜止狀態(tài)。當inactive切換到active時,活躍標志位為1,開啟etimer中斷源,此時更新count變量。當有過期的事件時,進程輪詢就會執(zhí)行到期的etimer事件。

圖3 soft-timer控制下的contiki進程調度狀態(tài)機

Fig.3Contikiprocessschedulingstatecontrolledbysoft-timer

3.3 rtimer調度設計

Contiki中的rtimer是獨立的定時器,只被contikimac[10]使用。但是contikimac與歷史狀態(tài)有關,每次運行需要在上一次執(zhí)行的斷點位置開始,關閉rtimer會導致上一次的斷點位置清空。如圖4 rtimer變頻的狀態(tài)機,這里的回調函數采用rtimer實現,淺灰色區(qū)域為新增的部分。在這里的軟時鐘控制著rtimer的變頻(因為rtimer關閉導致斷點清空，進而導致contikimac時序錯誤)。當軟時鐘的標志位表示為非活躍期時,將rtimer的周期變長(如5 s)。當軟時鐘的標志位為活躍狀態(tài)，將rtimer的周期(如250 ms)變成原來的正常狀態(tài)。

4 實驗評估

4.1 CC1310和CC1120節(jié)點功耗實驗

為了達到實驗的效果,需要對CC1310和CC1120的引腳進行預處理配置。沒有進行預處理的引腳通常會帶來十幾個甚至幾十個微安的電流。

CC1310在非活躍期間測量得到etimer、rtimer、soft-timer中斷的平均電流如圖5所示。非活躍期間待機狀態(tài)，看門狗帶來的功耗常數C=1 uA。

CC1120在非活躍期間測量得到etimer、rtimer、soft-timer中斷電流分別為91uA*2ms、91uA*2ms、78uA*3ms，功耗常數C=3.3 uA。

CC1310和CC1120節(jié)點的軟時鐘頻率均是1 Hz,通過修改配置文件的參數。設置不同的etimer、rtimer頻率,在非活躍期間分別得到CC1310和CC1120節(jié)點的基礎功耗測量值和估計值,見表3。

圖4 Rtimer頻率變換

圖5 CC1310非活躍期etimer、rtimer、soft-timer中斷電流

Fig.5Theetimer,rtimer,soft-timerinterruptcurrentofCC1310duringinactiveperiod

表3不同配置下CC1310和CC1120的基礎功耗

Tab.3BasicpowerconsumptionofCC1310andCC1120indifferentconfigurations

etimer的頻率rtimer的頻率基礎功耗測量值基礎功耗估計值16 Hz4 Hz23.428uA/CC131024.352uA/CC1310關閉4 Hz5.985uA/CC13106.560uA/CC1310關閉0.2 Hz2.490uA/CC13102.334uA/CC1310關閉4 Hz4.243uA/CC11204.265uA/CC1120

4.2 CC1310網絡傳輸實驗

為了驗證對網絡的收包率是否有顯著的影響,節(jié)點的發(fā)射功率設置成15 dbm、發(fā)射速率為50 kbps、信道434 MHz。rtimer非活躍期0.2 Hz,活躍期8 Hz,節(jié)點個數為22,全部部署在同一層樓的各房間里，其中一個節(jié)點接上電流表進行電流的測試。通過根節(jié)點下發(fā)活躍調度,節(jié)點的非活躍期設置成350分鐘,,活躍期設置為10分鐘,并且每個節(jié)點在活躍期間上報1個數據。

實驗共運行3天,上報12輪數據，共收到數據包263個,收包率為99.62%,并沒有顯著導致網絡的收包率降低。

5 結束語

本文在事件驅動的IOT操作系統(tǒng)上,基于系統(tǒng)的時鐘完成了一種極低基礎功耗方案的設計。極低基礎功耗方案的核心在于采用RTC實現一個軟時鐘,用于控制系統(tǒng)的其它定時器。這種設計方式不僅對硬件資源要求低,系統(tǒng)內核改動少,還屏蔽了操作系統(tǒng)的任務執(zhí)行方式和協(xié)議棧的復雜性。應用程序員不需要關心低功耗處理的細節(jié),只需通過配置active_period和inactive_period參數,針對不同應用就能夠滿足功耗和網絡傳輸要求。最后通過實驗,在CC1310和CC1120上分別實現了2.5uA和4.3uA以內的極低基礎的功耗。