擁塞控制(Congestion Control)

在無線感應器網路中，由於節點的體積小，因此在傳輸上受限於資源的分配，也因

此如何去解決擁塞的問題，成了重要的項目之一。擁塞控制分為兩大類的控制方法，一

種為資源控制，另一種則為速率控制。

 資源控制：在現有的文獻中，如[27][28][29]，在[30]中，作者提出利用real-time 以

及 non-real-time 的方式來紓解擁塞的情況，在[3]中，當發生congestion時，群集裡

的Head node會把過多的資料往群集裡的Data Buffer node傳送，作為一個暫時的存

放地點，等到congestion狀況解除後，再把資料傳回去

head node，之後再傳回sink端，此種方式可以在發生congestion時能保有資料的完 整性但相對於需要即時性的資料而言(例如:即時影像傳輸)此種方式無法達到即時

性傳輸的要求。圖2.1為In-Network Storage的模型，在圖2.1(a)中我們可以看到當發

生congestion時，head node會去喚醒正在睡眠狀態的Data buffer node，圖2.1(b)為在

head node中控制Data buffer node是否啟動的列表圖。

圖 2.1 Clustered sensor field with data congestion at node N

 速率控制：在無線感應器網路中，速率控制是能夠在短時間內降低網路流量的一種

機制，藉以達到緩和擁塞的效果，如[15][21][22][23]，在HCCP中，作者將過去其他

論文中所提出的Buffer-control和rate-control加以混和利用，利用兩種不同的數據去

推算sensor裡的擁塞程度(Congestion Degree)，然後藉著CD值去演算出偏差擁塞指

標，在得出此一指標之後便可以依據這項指標，去做調整節點 i 之上游節點送到節

點 i 的資料速率，此一作法，確實可以改善節點間擁塞的情況，也解決當初PCCP所

存在的缺點，就是如果假設節點本身產生資料速率是不能變動的，那對於PCCP的

控制方法而言是一個致命傷，但是HCCP的做法剛好解決了在PCCP的問題，就是即

使在產生資料的速率不變的情況下，透過改變整體網路流量的調整，還是可以進行

擁塞的控制；但是HCCP和PCCP都有一個相同的缺點，就是即使去調整網路流量，

但萬一網路流量還是過大的話，則sensor內部的buffer還是無法減少儲存封包的數目

時，此一方式還是無法解決sensor的擁塞情況，尤其是有一些封包是具有時效性的，

如果發生擁塞時把它存在buffer過久的話，就會造成封包逾時，以至於封包無法傳

輸。

第三章

適應式擁塞控制(ACCP)

3.1 背景

在這一章中，我們將會介紹我們所提出的擁塞控制方法－Adaptive Congestion

Control Protocol (ACCP)。在[6]中，作者認為會發生擁塞的原因有兩種，如圖3-1所示，

第一種是因為節點層級裡的暫存器空間用盡，而造成過多的封包就會被丟棄，如圖

3-1(a)，第二種就是由於傳送層級裡的無線電互相干擾，而造成彼此需要傳送的封包無 法到達目標節點，而使得封包遺失，進而會讓能源的消耗變多，如圖3-1(b)。在本文中，

我們就圖3-1(a)造成的擁塞，來提出我們的解決方式，在我們所提出的方法中，我們把

ACCP分為兩大調節方式，第一種為In-network Buffer (InB)，第二種為Rate Adjustment (RA)。以下我們就說明這兩種調節方式。

首先說明在本論文中所使用的符號如下：

 網內儲存管理：

圖3-1 Congestion in wireless sensor network

h：群集裡的中心節點(Head node)

si

n ：在群集裡感應節點的總數(Number of sensing nodes)

bi

n ：在群集裡暫存器節點的總數(Number of buffer nodes)

RB ：在群集中所剩餘的暫存容量(Remaining buffer of cluster)c

RB ：在群集中，中心節點所剩餘的暫存容量(Remaining buffer of head node)h

C ：群集(Cluster)i

t：每單位時間(Time unit)

x：回報資料的單位時間(Time period for data reporting)

NS ：群集中的網路淨流量(Net flows of cluster)c

h

rs ：中心節點產生資料速率(Data rate generated by head node) CD ：群集擁塞指標(Congestion degree of cluster)c

CD ：中心節點擁塞指標(Congestion degree at head node)h

 速率調整：

i( )x

 ：傾向擁塞指標(Degree of congestion occurrence)

SUMi_：_i( )x _{的總和(Sum of} _i( )x ₎

PPCi：潛在可能容量(Potential capacity)

Ui

N ：上游群集總數(Number of upstream clusters for node i )

3.2 網內儲存管理(In-network Buffer Management)

在這一節中，我們將會介紹ACCP中的In-network Buffer (InB)的部分，當擁塞發生

時，如果我們就立即去啟動速率控制，雖然會立即將傳送速率降低下來，但是會造成在

上游的節點發生back pressure的現象，如圖3-2，進而演變成整體上游都會發生擁塞，因

此，我們再執行速率控制前，我們先使用In-network Buffer的方式來容納節點裡過多的

封包，藉以減少使用速率控制。我們把分散在四處的node依照指定的Head node傳送半徑

範圍，將node分為一個群體，群體裡面有三種性質的節點：head node、buffer node、sensing

node，如圖3-3，其群體的組成為:

i i

i i b s

C  h n n (3.1)

Head node是整個群集的中心，也是負責把資料分送至buffer nodes的控制中心，同

圖3-3 InB模型

圖3-4 Cluster buffer node list

圖3-2 限制流量後對於節點i及其上游造成擁塞示意圖

時也負責把資料傳送至下一個群集的 head node；而Sensing nodes是負責感應事件的發

生，然後再把資料傳送給Head node；Buffer nodes則是整個群集裡暫存資料的地方。在

平時，Head node就必須在每個周期時間t中，去計算整個群體的Buffer的空間，其計算公

因此，我們便需要在周期t中，得知每一個在群集裡的buffer node的暫存器容量還有多

少，在回報容量的機制上，首先，我們對每一個在群集裡的Buffer node編號，我們利用

Head node在單位時間內向群集內的每一個Buffer node發出query的廣播，根據buffer node list上的buffer node編號來確定每一個群集裡的buffer node是否有回報容量，如圖 3-4，我們設定Buffer node向Head node回報buffer容量的時間為x，假設有n個Buffer nodes，假設開始時間為 t ，則n 回報的時間為 t₁ x，n 的時間則為₂ t2x，如此類推，

NS ，我們可以計算出整體群集的擁塞指標Congestion Degree (CD)，在擁

塞指標中，我們將CD值分為兩大指標，一種是整體擁塞指標Congestion Degree of

cluster (CD )；另外一種則是Head node的擁塞指標Congestion Degree of Head node_c

(CD )；其中_h CD_c NS_cRB_c，如果CD_c 0則群集會發生擁塞，如果 CD_c0則不會 發生擁塞，另外，在計算Head node的擁塞指標上，其計算方式為CD_h NS_cRB_h，如

 

塞。在InB中，我們把InB定位是預防發生Congestion，因為啟動InB的速度比較快，而且

成本較低。我們依據CD 的值，作為啟動InB的依據，其計算方式為：，當_h CD_h 0時，

表示Head node所殘餘的Buffer空間是安全的，但若CD_h 0，表示在Head node的buffer 量已經不足，需要啟動InB。在InB中，Head node把過多的封包傳輸給buffer node的方式

是採用輪盤法，在平時buffer node回報容量時，就在Head node裡面建立一個buffer node

list，當啟動InB時，Head node會根據buffer node list裡所提供每個buffer node的容量，由 剩餘容量最多的來進行存放，當存放容量超過90%以上則抓取下一個buffer node來進行

存放資料，如圖3-4所示。

3.3 速率調整(Rate Adjustment Management)

在這一節中，我們將介紹我們所提出的方法中速率控制的部分，當我們已經啟動InB

之後，如果擁塞的情況來是沒有減緩下來，我們就要進行第二階段的擁塞控制－速率控

制(Ra)。首先，我們要先計算從群集 i 的上游－即群集x到群集 i 的傳輸容量，由於當發

生congestion時，封包會把節點裡的剩餘的Buffer填滿，所以在群集 i 的Head node就必須

要估算當發生擁塞時，上游的群集x的Buffer量是否可以去應付無法傳送出去的封包

另外，我們要去計算在群集 i 中潛在可能的容量，原因是因為我們要知道在群集 i

Remaining potential capacity (PPC )：_i'

i' i i

圖3-5 ACCP控制流程圖(1)

圖3-6 ACCP控制流程圖(2)

第四章 模擬研究

4.1 模擬環境

在這一節中，我們將會說明我們的模擬環境，我們的模擬程式是使用Matlab來撰

寫；在傳送速率和Buffer容量的不同下，我們想觀察封包的遺失率，並比較某一節點若

使用了InB 及Ra以及把上述兩種方式結合的ACCP的效果，最後我們再把我們所提出的

方法與InS和HCCP比較。在傳送速率不同的模擬中，我們設定最高和最低的資料速率分

別為每秒11個和每秒3個封包，傳出時間則為每秒間5個封包，Buffer容量為5個封包，模

擬時間為三百秒。而在Buffer容量不同的情況下，我們設定最高和最低的Buffer容量分別

為12和6個封包，傳入的資料速率為每秒11個封包，傳出的資料速率則為每秒5個封包，

模擬時間為三百秒，圖4-1為我們的模擬網路拓樸。

圖4-1 模擬環境網路拓樸

4.2 網內儲存模擬結果

在這一節中，我們將探討我所提出的擁塞控制－ACCP的方法中，InB的部分，在圖

4-2中，我們可以明顯的看到雖然InB可以幫助我們暫時延緩擁塞的情形，但是只要傳入 和傳出的速率差距很大時，便會開始丟棄大量的封包，以至於無法將封包遺失率壓低；

而在圖4-3中，我們可以看到雖然增加Buffer容量可以降低，但是在節點中是無法一直增 圖4-2 InB傳入速率不同封包遺失率比較圖

圖4-3 InB Buffer容量不同封包遺失率比較圖

加Buffer容量的，所以我們需要用速率控制來再降低封包遺失率。

4.3 速率控制模擬結果

在圖4-4和圖4-5中，我們可以看到採用速率控制在封包遺失率上可以降低許多，但

是這樣的做法會使得上游節點的傳出速率被迫降低，將會使得擁塞的情形會一直往上游

節點蔓延，而導致到最後可能整個無線感應器網路都會陷入擁塞的情況，所以我們需要

InB在發生擁塞之前就能夠先儲存傳送節點裡過多的封包，讓使用速率控制後的上游節 點的擁塞情形不會太過於嚴重。我們依照BufferSize的不同，把Ra依照Buffer Size量為5、

8、11三組不同的容量，在傳入速率不同的條件下去比較，其結果如圖4-6。

圖4-4 Ra傳入速率不同封包遺失率比較圖

在圖4-6中，我們可以看出在Buffer Size量為5、8、11時，封包的遺失率其實差異不

大，其原因是在速率控制中，只要節點裡的容量一旦發生不足時，即會通知上游節點把

網路流量降低，以減少封包的遺失。

我們把節點的buffer容量分別調整為5、8、11去分別執行模擬，其結果顯示於圖4-7、

4-8、4-9，我們可以看出，在節點的buffer容量為5的時候，其封包的遺失率大約在1.9到 2之間，而在節點的buffer容量為8、11時，我們可以看出封包遺失率只有稍微的差異，

是因為在節點的buffer容量調整為8之後，節點裡面的buffer就比較可以去容納過多的封

包，因此，在節點的buffer容量為8、11時，封包遺失的現象差距不大。

圖4-5 Ra Buffer Size容量不同下封包遺失率比較圖

在文檔中 I-Shou University Institutional Repository:Item 987654321/1178 (頁 18-0)