基于結構化方法的無線傳感器網絡設計

圖3：居民住宅樓內的無線抄表應用。

吞吐量

另外一個需要仔細考慮的設計因素是吞吐量。簡單地說，吞吐量指的是一個設備在單位時間內希望傳送的有用數據總量。許多系統(tǒng)工程師錯誤地認為系統(tǒng)具有比實際可用帶寬大得多的帶寬(有時甚至超出一個數量級)，從而導致性能差或無法運行的設備和失敗的設計。

導致這個常見問題的原因是802.15.4網絡鏈路宣稱有250kbps的介質容量。實際上，這個數字指的是理論上的物理極限，也就是PHY層的有效帶寬。它忽略了物理層上其它堆棧層引起的協(xié)議延時、處理和解析每個數據包的開銷、介質訪問時間、數據確認機制和誤碼率。根據我們的經驗，在相隔一跳的兩個ZigBee節(jié)點之間建立的點到點鏈路的傳輸速率不超過110到120kbps。在引入確認機制后，這個速率還要下降近一半。在任一給定時間點有3到5個節(jié)點試圖訪問共享介質的典型網絡環(huán)境中，這個傳輸速率還將進一步降低到數十kbps。

顯然，20~40kbps與標準宣稱的最大250kbps有很大差異，而一個缺乏經驗的系統(tǒng)工程師往往不知道這種差異，直到悔之晚矣。關鍵是無線傳感器網絡從來沒有打算要支持高帶寬的應用。相反，其目標市場是具有低帶寬要求的相對大型網絡。如果有個傳感器是產生100kbps數據流的視頻攝像機，那么無線傳感器網絡和ZigBee肯定不是最好的選擇，市場上有其它無線技術能更好地完成這個工作。

盡管吞吐量期望值和某種技術能夠支持的指標不匹配很常見，但仍可以合理使用這種技術，并通過帶寬優(yōu)化在目標環(huán)境中高效地運行。例如考慮每秒采樣100次的溫度傳感器。每次用一個數據包發(fā)送一個樣值將是一個較差的設計選擇。事實上，由于前面提到的網絡擁塞和級聯重傳故障問題，這樣做將給網絡健康帶來不良后果。一個更好的策略是，將多個樣值匯聚到一個數據包中，因為在大多數情況下，最大的數據包比較小的數據包更優(yōu)。

當匯聚無法實現時，可以用本地處理來降低帶寬要求。讓我們考慮具有低門限和高門限的典型自動調溫器應用。只要這些溫度讀數落在可接受的溫度范圍內，那么絕對不需要發(fā)送瞬時溫度讀數。節(jié)點可以使用本地處理功能來判斷何時讀數超出規(guī)定范圍，并在需要時才發(fā)送數據以警示另一個遠程設備。減少待發(fā)送數據量的另一個策略是采用某種形式的數據求和或平均算法。

然而需要注意的是，當多個物理事件同時發(fā)生時，即使是高度優(yōu)化的設備也會遭遇擁塞。如果整個樓層的溫度上升，可能會出現許多自動調溫器希望立即發(fā)送溫度讀數。對付這樣的帶寬峰值的一個實用方法是隨機化傳送延時。顯然，MAC層的重傳就是一種隨機化處理，但它無助于防止碰撞，它只在發(fā)生碰撞后起作用。應用層的延時如果做得好可以有效減少碰撞于發(fā)生之前。當每小時有數百個節(jié)點需要發(fā)送數據包，最佳設計會把傳送均勻分配在整個時段內，以盡量減少碰撞的機會。在有大量傳送的場合，強烈建議系統(tǒng)工程師采用這種策略。