ath9k monitor mode

Monitor mode
In monitor mode of operations, the interface does not join
to any network. This mode is generally used for passive
sniffing. The interface receives all packets in its listening
channel, even though it may not be destined for it. The protocol
driver mac80211 sends upstream the unaltered IEEE 802.11
MAC packet with certain extra header information. The extra
header radiotap includes physical layer information such as
received channel, signal quality, signal to noise ratio, antenna
and modulation scheme [19]. Sniffing tools such as Wireshark
[20] use Pcap [21] function to get these packets to the
application layer.

The other purpose of mnitor mode is packet injection. It is
possible to inject random IEEE 802.11 MAC frames using the
radiotap header and monitor mode WLAN network interface.
Fig. 9 shows the functional flow of packet injection. This is
possible by assembling the packet with minimum required
radiotap header and sending it to the driver using kernel socket
functions. W-meter is one of the open source tool, which is
used for arbitrary frame injection [22].

Implications of Power Control in Wireless Networks: A Quantitative Study

Implications of Power Control in Wireless Networks:
A Quantitative Study

Abstract. 

在無線網路中利用功率控制會導致兩個互相矛盾的作用。在一段連結上增加發射功率會造成:
1.改善信號品質進而增加吞吐量

2.增加對其他連結的干擾

然而當我們減少發射功率時會造成相反的效果

在本篇paper中主要是了解當使用功率控制時造成的干擾與爭奪(contention)，並在室內網狀網路進行實驗。

根據實驗分析，可以確定有三種干擾情形:
1.重疊的情況:

其中總吞吐量無法透過功率控制來改善。

2.hidden terminal的情況:

使用適當的功率控制，可以提高Fairness。

3.不重疊的情況:
使用適當的功率控制可以實現同步傳輸，進而明顯的提高吞吐量。

結論發現，功率控制可以顯著的改善吞吐量以及Fairness，然而出乎意料的發現當採用虛擬載波感測(virtual carrier sensing)與功率控制結合，反而會大量的降低Performace。

1 Introduction

本篇paper的目標是去探討在802.11無線網狀網路中功率控制對干擾造成的影響。

增加傳輸功率會造成:

1.提高接收端信號品質進而增加吞吐量。

2.增加干擾

這兩個結果是互相衝突的，我們通過實驗來評估功率控制對增加無線網路的Performace，也結合了(RTS/CTS)與功率控制。

本篇Paper主要注重於連結間的干擾，並提供詳細的實驗數據，根據實驗結果確定了3種干擾情形:

1.重疊的情況:

其中總吞吐量無法透過功率控制來改善，只有一個連結是可以使用的，因此要達到最大的吞吐量是對一個連結去最大化。

2.hidden terminal的情況:

使用適當的功率控制，可以提高Fairness，並觀察到使用(RTS/CTS)與功率結合會導致吞吐量的下降。

3.不重疊的情況:
使用適當的功率控制可以實現同步傳輸，進而明顯的提高吞吐量，因使用(RTS/CTS)會阻止同時傳輸的機會，導致較低的吞吐量。本Paper主要為室內的量測，室外環境可能會受到不同程度的影響導致不同的結果，我們研究結果清楚表明，802.11 MAC Protocol的自適應功率控制機制的必須，因功率控制並無廣泛的實驗研究與干擾結合，我們將朝著自適應功率的設計機制前進。在第2節，我們提供的載波偵聽的背景和討論相關研究功率控制和干擾。第3節介紹我們的測試平台，並用於驗證目的一些初步的實驗。在第4節我們描述了我們的實驗方法

與目前的結果有關的干涉效應。第5節總結全文。

2 Background and Previous Work

我們重新來看物理和虛擬載波感測的IEEE 802.11 MAC協議。我們也討論了相關的研究，以及如何我們的工作從這些努力有所不同。在IEEE 802.11的MAC的分佈式協調功能（DCF）使用的CSMA / CA算法。該算法取決於物理和虛擬載波感測。物理載波感測為了避免碰撞，節點在傳輸前會先感測medium。如果感測到正在進行的傳輸，該節點會依照back-off機制的退避週期之後再次嘗試。

如果沒有感測到通信，則節點傳輸。然而，物理載波感測從隱藏和暴露終端的存在受到影響。第一，兩個發射器可能無法感測對方的載波，因此，它們的傳輸可以在預期接收機碰撞。在這種情況下，兩個發射器被說成被彼此隱藏。其次，發射器強大的抑制其傳播，因為它從另一個發射器感測到一個載體;然而，這可能是過於保守，因為同時傳輸有時是可行的。

在這種情況下，傳送端A被說成是暴露於B的傳輸。虛擬載波感測在IEEE 802.11使用RTS（請求到發送）和CTS（清除到發送）控制消息，旨在解決隱藏終端問題，可是卻加劇了暴露終端問題。DCF功能的更多細節可以在[2]中找到。

接下來，我們簡單地討論在基於802.11的干擾特性和功率控制相關的前期工作。在無線網狀網路中每個節點會承受到全方位的通訊，因此功率控制經常被用來做節省能源與空間再利用。

然而，大多數努力假定網絡可以用單位圓盤圖（UDGs）[16，6，17，11]進行建立模型。有更加逼真的通道模型[10，8]。然而，大多數這些努力都依賴於模擬和分析;雖然他們確實提供了無線信道的更好的表現，雖然所使用的模型可能無法在所有場合都適合。在[10]，Muqattash和Krunz，設計控制MAC協議的功率，允許節點以調整它們的傳輸功率，同時允許在接收機一些干擾餘量。在[7]，分佈式功率控制算法的設計;算法考慮到節點對干擾的敏感性。

無線網絡的實驗研究最近獲得了普及。在無線網狀網絡的研究[5]和[4]表明，單位圓圖模型是不存在的。然而，這些並不表示鏈路之間的干擾也沒有考慮功率控制。 Akella [1]使用來自各個城市的大規模測量數據，以顯示多麼常見幾十台部署在彼此接近的AP。

本文提出了減少鄰居之間干擾的目的，功率控制和速率自適應方案（PERF）。我們在第4節Padhye等人進一步討論PERF。 [13]還研究估計在多跳無線測試台鏈路之間成對干擾的問題。他們提出了一種鏈路干擾估計的方法和在多種環境研究它。 Sinha[18]，進行實驗來觀察的單播和廣播鏈路性能之間。研究干擾的影響，他們認為在網格室內測試平台的各種距離相關的干擾情況。 Son et al. [15]研究了功率控制對獨立的無線鏈路品質影響。他們專注於傳感器網絡和執行他們的低功耗RF鏈路實驗（高達10 dBm的）可是沒有研究干擾影響。

3 Experimental Setup

在本節中，我們描述了我們的實驗測試平台，並展示孤立鏈接的穩定性和功率控制的行為目前初步的實驗結果。

這些結果提供了關於所述干擾影響的研究提供了基礎。

我們的測試平台室內是由15的Soekris net4826節點[14]，部署在工程大樓第二單元的加州大學河濱分校的3樓;網絡在圖1所示的每個節點運行一個Debian V3.1 Linux發行版內核版本2.6.13.2並在啟動服務器掛載NFS上它的根分區。

我們已經配備有節點EMP-8602-6G的802.11a / b / g的無線網絡卡，嵌入的Atheros AR5006芯片組[3];該卡由Linux Madwifi的驅動控制（0.90版）[9]。每個卡連接到一個5 dBi的增益，外部全向天線。

我們為了避免從co-located的802.11b / g網絡干擾使用的802.11a模式;我們的測試平台是該地區唯一的802.11a網絡。對於我們的實驗中，我們使用的信道56，其對應於 5.28Hz。發送功率在我們實驗中由1到16 dBm的之間變化。我們使用採樣率[4，5]作為所述速率控制算法。

為了導出可靠的測量，我們運行多個實驗許多不同對的鏈節之間，並且為在一天的不同時間段。我們使用30秒back-to-back 1500-byte UDP數據包為我們traffic load。

為了結果的可靠性。為了確定我們的研究結果的穩定性，我們進行了大量的30秒的實驗中，考慮到在一個大量的連結，其中每個node單獨使用不同的功率。圖2示出了用於6個代表性的哦鏈接觀察吞吐量，功率為16 dBm。我們發現只有些微的影響performace，對於大多數研究中的鏈接。鏈接13→18具有較大的variance。這是因為該鏈接相對較差，作為一個可以從所獲得的吞吐量看到。這組實驗證明了我們一段時間的實驗結果的穩定性。

吞吐量與發射功率。我們觀察到獨立的連結（只有一個鏈路是在任何給定時刻活動的）的品質，用於改變發送功率設置。如圖3所示，可以達到良好throughput的鏈路取決於所使用的發送功率。我們還觀察到，對於一鏈路的最大吞吐量是在一定的power threshold來實現的。例如，對於鏈路20→12我們觀察到最大吞吐量約在4dBm。

吞吐量在這裡飽和，並在發送功率的進一步增加不會顯著提高性能。因此，獨立的鏈接不總是使用最大功率傳輸以達到最大的吞吐量。有人可能會認為這與IEEE 802.11a的有限的modulation和編碼的可能性。

4 Effect of Transmission Power on Interference and Contention

我們的實驗研究的首要目標是了解的發射功率trade-off：

在一個鏈接提高可靠性和性能 vs 對其他連結造成的干擾程度。

在我們的實驗中，我們依次使用兩個鏈路。我們過改變其對應的傳送功率觀察其吞吐量透。

這些鏈接的發射器發送大量的UDP給相對應的接收器。

在1到16 dBm的之間選擇傳輸功率，並且ACK被以相同的功率為DATA的數據包回送。

實驗有一個30秒的持續時間，在此期間，發送功率被保持在一個固定的水平。

時間到後，每一個鏈路配置有一個新的功率大小，並且重複該實驗。

我們使用所有實驗相同的載波檢測threshold（在我們的卡的默認設置）。

我們利用iperf的測量工具（版本2.0.2）[12]來測量鏈路的性能。

我們考慮的情況下，我們（i）禁用或（ii）啟用virtual carrier sensing與RTS / CTS。

4.1 Achievable Performance Gains

我們希望通過多少來決定，如果在所有性能可以改善

通過使用最佳功率控制機制。由於這樣的功率控制機構不可用，我們訴諸窮舉搜索。圖4描繪了使用最佳功率設置時，以及使用的最大發送功率時為一組鏈路對觀察到的最大的總吞吐量。

均具有RTS的情況下/ CTS啟用或禁用繪製。我們觀察到，使用最大功率並不必然導致最高網絡吞吐量。

因此，機會是存在的，通過功率控制顯著提高網絡性能。

此外，使用RTS / CTS未提高性能。

我們在下面更詳細討論這一點。接下來，我們就來仔細看看所收集的數據，看到的發射功率設置上吞吐量的影響，以及公平性。

4.2 Three Types of Interference Behavior

上述實驗是在16個鏈節對的運行。接下來更詳細地分析實驗數據，我們觀察到每個這16對的可被歸類為屬於三種情況。確定的三個干擾的情況是重疊的（5 links out of 16），隱藏終端（9 links out of 16）和潛在的脫節（(2 links out of 16）。

我們示出了使用鏈節對的吞吐量矩陣三種不同類型（圖5，6和7）。吞吐量矩陣說明對於發射功率所有組合的各個連結達到的吞吐量。在圖5中，水平軸和垂直軸分別表示由每個鏈路所使用的功率。

矩陣區域對應於所達到的總吞吐量。每個圓盤的黑色和白色部分對應於分別在垂直和水平軸在鏈路的吞吐​​量。例如，在圖6中，在坐標（11,8），良好的吞吐量達到，並且每個鏈路接收吞吐量的恰好一半（每17.5兆位/秒）。在坐標（11,16），總吞吐量為更好，但連結31→11接收大部分吞吐量（30.4兆位/秒），離開鏈路16→12用很少的（2.55兆比特/秒）。

現在我們將描述每一種情況下更詳細地，並研究其在相應的吞吐量基質效應。

重疊。在這種情況下，兩個鏈路總是抗衡，而不管所使用的功率設置。圖5示出了這種情況的一個例子。這種情況下，通常顯示其中兩個發件人之間的信道是比信道更好從至少一個發送器向它的相應的接收器。

在本例中，節點12和20是發送器和節點11和15的接收器，分別為（圖1）。鏈接12→11是鏈路和節點12的需求很差，至少有12至13 dBm的傳輸。同樣，節點20的功率必須至少有8至9 dBm的。發射機20和12是線的視線彼此的內（如圖1所示）和在它們之間的聯繫是很不錯的。

其結果是，他們能聽到對方的傳輸和退避相應。因此，只有兩個鏈路之一將攜帶通信量的時間，並且兩個鏈接的最大總吞吐量將永遠不會比最大的兩個鏈路的吞吐量。

隱藏終端。多數認為鏈節對都屬於這種類型。在這裡，發送者不能檢測到彼此的傳輸和物理載波偵聽失敗。多次傳輸在接收器同時到達。

這不一定是一個問題，如果期望的傳輸的信號強度比干擾傳輸的顯著高。

信號和干擾之間的這種競爭在圖6中觀察到。

作為節點16增加其功率時，它使31→11受到干擾增加;衝突發生在節點11。

然而，由於節點31增加其發送功率，其信號強度增大。因此節點11現在能夠收到節點31的DATA。請注意，雖然總吞吐量變化與發送功率較無關，如果該功率超過一定的水平，公平性是在可以通過矩陣沿對角線一致更好。

沿著這條電源設置對角線最佳平衡兩個鏈路之間的信號質量和干擾。

潛在的脫節。準確的功率設置可以同時進行成功發射，導致高達總吞吐量的增加一倍。

潛在分離鏈路是通過在通過基質峰超過單個鏈路的最大容量為特徵。

這在圖7所描繪的，用於鏈路15→16和22→31。

這兩個鏈路拓撲以及分離（圖1），並且是高品質的（有發射器和它們的相應的接收器之間的一條線的視距路徑）。

當桿15→16使用電源9 dBm的，當鏈路22→31使用6 dBm時，得到的最大總吞吐量（單鏈路的大約容量的兩倍）。

這表明，當發射功率被設置為上述的值，這兩個鏈路可以操作無干擾的。

當鏈接增加他們的功率，我們觀察到的總吞吐量下降。

從這些觀察，很明顯的是，為了實現高的總的網絡

換句話說，在線功率適應機制需要，可以為每個鏈路，確定這是最適合於使用在給定的實例中的時間的能力。

其中提出的方案，PERF [1]，部分解決了這個問題。只要可以通過不受影響PERF逐漸減小發送功率。 PERF可望成功地解決潛在的不相交的情況下，正確地降低功耗，直到空間复用成為可能。然而，在隱藏終端情況下，PERF將使用的最大功率，導致次優的公平性的條件。雖然PERF是朝著正確方向邁出的一步，

我們得出結論，進一步的改進是必要的。

4.3 Use of RTS/CTS in indoor environments

最後，我們研究如何加入RTS / CTS握手會影響干擾和競爭特點。我們重複以前的實驗，但將RTS / CTS啟用。鑑於RTS / CTS的目的是要解決隱藏終端問題，我們所期望的結果有所在隱藏終端情況改善。從測量，我們注意以下事項：

重疊。重疊鏈路的性能會略有由於惡化

RTS / CTS overhead（圖8）。

隱藏終端。我們注意到，RTS / CTS一直在所有我們測試的隱藏終端的情況下跑CSMA。

通過矩陣圖9，典型的隱藏終端情況下。總吞吐量是當啟用RTS /CTS始終較低。公平性受到影響，以更大的程度，我們的結果的穩定性顯著影響的程度。

注意，存在其中對於一些功率設置，使用RTS / CTS的導致改善公平性的情況下。然而，這種改善通常通過在總吞吐量的大量減少（見圖11，12）的偏移量。我們懷疑這是由於RTS / CTS加劇了暴露終端問題，降低了並行傳輸的機會。

潛在的脫節。最後，在一個潛在的不相交的情況下，鏈接還受到RTS​​ / CTS影響（見圖10）。而整體吞吐量仍然可以達到比單個鏈路的容量更高的水平，它是比用CSMA取得顯著降低。在其中空間复用實現的權力的制度也被減小的尺寸，要求更精確的功率控制，並且通常更高的傳輸功率（比較圖7）。

總之，RTS / CTS似乎是完全有害的室內無線網絡的性能，如果功率控制是可用的。然而，更多的實驗需要執行，在更廣泛的環境中，並與各種硬件，可以得出任何明確的結論。

5 Conclusion

而功率控制可以影響傳輸質量給定鏈路上，所使用的功率決定在其他鏈路的干擾，因此，也可以影響其他鏈路的性能。

我們進行測量與量化這種trade-off與功率控制的室內實驗網絡的IEEE 802.11a節點，無論是

和沒有虛擬載波感測。我們確定了三種類型的干擾行為。

在重疊的情況下，功率控制和/或RTS / CTS不增加可達到的最大吞吐量。

在隱藏終端情況下，功率控制減輕了隱藏終端問題，因此，提高了吞吐量。然而，在結合使用RTS / CTS與功率控制始終都降低整體吞吐量和公平性。

在可能的情況下不相交，功率控制可以幫助同時鏈接，從而可以產生在可實現的吞吐量幾乎增加了兩倍相比，在使用默認的最大功率情況下。

再次，虛擬載波感測加劇了暴露終端問題，顯著降低整體性能。

我們使用的IEEE 802.11a節點，以避免同一地點的802.11b / g網絡的干擾。儘管與802.11b / g的結果可能被調查的鏈接不同，我們對所觀察到的干擾類型的結論將仍懷疑。

整體來說，我們的研究表明，精確的功率控制適用於改善室內無線網絡的性能很大的希望。

AODV VS DSR

Ad hoc On-demand Distance Vector Routing Protocol (AODV) 

AODV 屬於 On-demand 路由協定，當來源節點有資料要傳送且路由表中 沒有目的節點的路徑資訊時，才會啟動路徑搜尋程序。

A. 路徑搜尋程序 

   
     當來源節點需要一條路徑到目的節點，會廣播一個Route REQuest (RREQ) 封包到網路中，然後等待 Route REPly (RREP)封包。RREQ 封包中包含來源節 點與目的節點的 IP 位址、廣播 ID、來源節點與目的節點最新的 Sequence number，如圖 2.5。每當節點收到 RREQ 封包後，都會紀錄下來源節點的 IP 位址與廣播 ID，當節點將 RREQ 封包廣播出去後，會設定一段預設的時間， 如果節點在這一段時間內接收到擁有相同來源節點的 IP 位址與廣播 ID 的 RREQ 封包時，就會丟棄此 RREQ 封包。如果沒有接收過此 RREQ 封包，節 點接著會判斷自己是否為目的節點或自己是否擁有到目的節點的路徑資訊， 如果滿足其中一項，則回覆 RREP 封包到來源節點，反之，則在 RREQ 封包 的 Hop 欄位加一後，廣播 RREQ 封包。另外，當節點接收到 RREQ 封包時， 會建立一條指向來源節點的反向路徑資訊到路由表中，如圖 2.6，實線箭頭代 表 RREQ 封包傳送的路徑，來源節點 A 廣播的 RREQ 封包，中間節點收到 RREQ 封包後再將此 RREQ 封包廣播出去，直到目的節點 G 收到為止。
 
     在 RREP 封包回覆到來源節點 A 的過程中，當中間節點接收到 RREP 封包時，會建立一條指向目的節點的正向路徑資訊到路由表中，然後傳給上 游節點，直到 RREP 封包傳到來源節點 A。如圖 2.7，虛線箭頭代表 RREP 封 包傳送的路徑，目的節點 G 收到 RREQ 封包後，沿著 RREQ 封包傳來的路徑 回傳 RREP 封包給來源節點 A。如果來源節點 A 在找路計時器倒數到 0 時還 沒有收到 RREP 封包，來源節點 A 會重覆廣播 RREQ 封包，重傳次數加一。 當來源節點 A 重傳次數超過預設的最大值，則此條連線宣告失敗。

    在 AODV 中，每個節點會維持一個路由表，路由表中記錄所有可用路徑 的資訊，最新的路徑資訊可以透過 Sequence number 來判斷。在 AODV 中， 每個節點都擁有屬於自己的 Sequence number，有兩種狀況節點會單調遞增自 己的 Sequence number：第一，當來源節點要發出 RREQ 封包時；第二，當目 的節點收到 RREQ 封包，準備要回傳 RREP 封包時。每個節點的路由表中， 針對通往目的節點的路徑都有一個 Sequence number，所以，每當節點收到 RREQ 封包時都會檢查控制封包中來源節點的 Sequence number 訊息；如果收 到 RREP 封包時會檢查控制封包中目的節點的 Sequence number 訊息。如果控 制封包中來源節點或目的節點的 Sequence number 大於路由表中的 Sequence number，則立即將控制封包中相關節點的 Sequence number 的值取代路由表中 的 Sequence number，然後更新關於此路徑的資訊。如此，節點可以擁有通往 目的節點的最新路徑資訊

B. 路徑維持程序
   
     當連結因為斷裂而失效時，其上游節點發覺後，會將經過此連結的路徑設為 無效，然後會根據路由表的資訊，發送 Route Error (RERR)封包給需要經過此 連結到達目的地的鄰近節點。鄰近節點收到 RERR 封包後，會將受到影響的路徑設為無效，再繼續發送 RERR 封包給受影響的鄰近節點。當來源節點收 到 RERR 封包後，如果還有需要，會啟動路徑搜尋程序。

AODV 和 DSR 都有類似的 route discovery 過程，都強調是在 source 工作站需要的時候才會去建立到目的地工作站的路徑，但是兩者仍然 有相當的差異：

（1） DSR 所需的路徑資訊較 AOVD 來得多。DSR 在一個 cycle 下完 成 request route 後，source 工作站可以獲得目的地工作站和所有中 間工作站的路徑資訊。每一個中間工作站也可以獲得到達其他中 間工作站的路徑資訊。而 AODV 得到的路徑資訊則是有限的，只 認得封包的下一個轉送點，所以可能會造成工作站常常執行 route discovery，而使得網路流量變大。

（2） 在 AODV 中，因為 AODV 只為每一個工作站維護一筆路徑資 訊，所以目的地工作站只回應最先到的 route request，慢到的一律 丟棄。在 DSR 中，因為是使用 route cache，目的地工作站會回應 所有的 route request 封包，即使是重複的。這使得 source 工作站可 以在 route cache 中保留許多條到同一目的地的路徑，所以當最短 路徑不通時，在 route cache 中還有另一個選擇。此機制節省了啟 動 route discovery 的機會和網路流量，但是回應每一個 route reply 卻可能造成網路流量的氾濫。

（3） 在 AODV 中，路徑的時效是由 sequence number 來決定，永遠會 選擇最新的路徑資訊，並且如果過一段時間後此路徑都沒用過， 就從 routing table 中刪除。在 DSR 中則無法分辨路徑資訊是新的 還是舊的，只有等到 route error 封包通知時，才會把 route cache 中無效的路徑資訊刪除。

（4） 在 AODV 中，一旦發出 route error 封包，會送達給所有用到此 連線的工作站，讓它們刪去無效的路徑。但是 DSR 的機制只會傳 給唯一的上游工作站，直到 source 為止。不在此一路徑上的其他 工作站都不會被通知。

Cickd 註解

今天要來記錄一下clickd的語法
因為太難了...要做個紀錄
以下是我們可以看到clickd中的code

#!/bin/sh 

# Copyright (c) 2006, Roberto Riggio
#
# All rights reserved.
# 
# Redistribution and use in source and binary forms, with or without 
# modification, are permitted provided that the following conditions    
# are met:
# 
#   - Redistributions of source code must retain the above copyright 
#     notice, this list of conditions and the following disclaimer.
#   - Redistributions in binary form must reproduce the above copyright 
#     notice, this list of conditions and the following disclaimer in 
#     the documentation and/or other materials provided with the 
#     distribution.
#   - Neither the name of the CREATE-NET nor the names of its 
#     contributors may be used to endorse or promote products derived 
#     from this software without specific prior written permission.
# 
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
# EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
# PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
# LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:./
DAEMON=click => 可執行檔
HELPER=click_config =>由click_config產生腳本
NAME=clickd

MODE="11g"
CHANNEL="2412"
DEV="moni0"

PROFILE="bulk"
LS="fcfs"
METRIC="wcett" => 有hop-count與wcett，這是route機制
RC="minstrel" => 有static與minstrel，這是Rate Control機制

CLICK_FILE=/var/run/$NAME.click
PID_FILE=/var/run/$NAME.pid
LOG_FILE=/var/log/$NAME.log 

test -x "$(which $DAEMON)" || exit 0
test -x "$(which $HELPER)" || exit 0

case "$1" in
  start)

 echo "Starting $NAME"

 if which wlanconfig > /dev/null 2>&1; then  => > /dev/null 2>&1表示說不Print在螢幕上
  PHY="wifi0"
  WLANCONFIG=$(which wlanconfig)
  [ ! -f "$WLANCONFIG" ] && {
   echo "Couldn't find wlanconfig";
   exit 1; 
  }
  $WLANCONFIG $DEV destroy 2> /dev/null
  $WLANCONFIG $DEV create wlandev $PHY wlanmode monitor > /dev/null 2>&1 || {
   echo "Couldn't create monitor device on $PHY";
   exit 1; 
  }
  echo '803' >  /proc/sys/net/$DEV/dev_type
  /sbin/iwpriv $DEV mode $MODE
 elif which iw > /dev/null 2>&1; then
  PHY="phy0"
  IW=$(which iw)
  [ ! -f "$IW" ] && {
   echo "Couldn't find iw";
   exit 1; 
  }
  $IW dev $DEV del > /dev/null 2>&1
  $IW phy $PHY interface add $DEV type monitor > /dev/null 2>&1 || {
   echo "Couldn't create monitor device on $PHY";
   exit 1; 
  }
 else
  echo "Couldn't find neither iw or wlanconfig";
  exit 1
 fi

 /sbin/iwconfig $DEV channel ${CHANNEL}M
 /sbin/ifconfig $DEV mtu 1900
 /sbin/ifconfig $DEV txqueuelen 5
 /sbin/ifconfig $DEV up
 /sbin/modprobe tun > /dev/null 2>&1 =>載入Module (包製多NIC)

 # extract the bottom three octects to use as IP =>查網卡卡號，可直接設SUFFIX成0.0.0.1
 MAC=$(/sbin/ifconfig $DEV 2>&1 | sed -n 's/^.*HWaddr \([0-9A-Za-z\-]*\).*/\1/p' | sed -e 's/\-/:/g' | cut -c1-17)
 HI=$(echo $MAC | sed -n 's/.*:.*:.*:\([0-9A-Za-z:]*\):.*:.*.*/\1/p')
 MID=$(echo $MAC | sed -n 's/.*:.*:.*:.*:\([0-9A-Za-z:]*\):.*.*/\1/p')
 LOW=$(echo $MAC | sed -n 's/.*:.*:.*:.*:.*:\([0-9A-Za-z:]*\).*/\1/p')
 SUFFIX=$((0x$HI)).$((0x$MID)).$((0x$LOW))

 XR_IFNAME="wing-mesh"
 XR_IP="6.$SUFFIX"
 XR_NM="255.0.0.0"
 XR_PERIOD="36000"
 XR_TAU="360000"

 $HELPER -p $PROFILE -r $RC -s $LS -l $METRIC -m $MODE -c $CHANNEL -n $DEV -a $MAC -d \
  | sed -e "s/__XR_IFNAME__/$XR_IFNAME/g" \
  | sed -e "s/__XR_IP__/$XR_IP/g" \
  | sed -e "s/__XR_NM__/$XR_NM/g" \
  | sed -e "s/__XR_PERIOD__/$XR_PERIOD/g" \
  | sed -e "s/__XR_TAU__/$XR_TAU/g" > $CLICK_FILE

 $DAEMON $CLICK_FILE > $LOG_FILE 2>&1 &

 sleep 2
 if ! pidof $DAEMON > /dev/null 2>&1; then
  echo "Unable to start click. Check log for more information."
  exit 1
 fi

 pidof $DAEMON > $PID_FILE

 ;;
  stop)
 echo "Stopping $NAME"

 if which wlanconfig > /dev/null 2>&1; then
  WLANCONFIG=$(which wlanconfig)
  [ ! -f "$WLANCONFIG" ] && {
   echo "Couldn't find wlanconfig";
   exit 1; 
  }
  $WLANCONFIG $DEV destroy > /dev/null 2>&1
 elif which iw > /dev/null 2>&1; then
  IW=$(which iw)
  [ ! -f "$IW" ] && {
   echo "Couldn't find iw";
   exit 1; 
  }
  $IW dev $DEV del > /dev/null 2>&1
 else
  exit 1
 fi
 [ -f $PID_FILE ] && {
  kill -9 $(cat $PID_FILE)
  [ -f $PID_FILE ] && rm $PID_FILE
 }
 [ -f $CLICK_FILE ] && rm $CLICK_FILE
 [ -f $LOG_FILE ] && rm $LOG_FILE
 ;;
  restart|force-reload)
 $0 stop
 sleep 1
 $0 start
 ;;
  *)
 echo "Usage: $NAME {start|stop|restart}" >&2
 exit 1
 ;;
esac

exit 0

無線隨意網路路由協定 (Routing Protocols for MANET)---DSR&AODV&TORA

無線隨意網路路由協定 (Routing Protocols for MANET)

8.1 無線隨意網路簡介 

8.2 主動式路由策略 

8.3 回應式路由策略 

8.4 主動式與回應式路由之比較

8.5 位置輔助路由 (location-based routing)策略 

8.6 結語

8.3 回應式路由策略

回應式(reactive)路由又稱On-demand routing (經需求路由)

主動式(路由表) vs. 回應式 ->8.4

回應式路由只尋找與維護有需要的路由

主動式路由則不論需要與否所有路由均須維護

回應式路由

優點： 省去一些不必要的路由維護

             適合偶發訊務(traffic)且一但發生則有大量的訊務；通訊只涉及少 數節點

缺點： 首次尋找耗時較多時間做路徑尋找造成封包延遲

回應式路由例子：

            動態來源路由 (Dynamic Source Routing , DSR)

            隨意依需求距離向量路由(Ad hoc On-demand Distance Vector, AODV) 

            臨時排序路由演算法 (Temporally Ordered Routing Algorithm, TORA)

回應式路由協定 –DSR(Dynamic Source Routing)

來源路由(Source routing)的基本精神：

1.封包的整個路由在來源地(source)已決定並置放在該節點的路由快取貯存區 (route cache) 

2.路由路徑資訊在封包標頭中；中繼節點按此資訊傳送封包。 

(要到的目地地無路由時) 啟動路由探索程序(Route discovery procedure)：

1.由節點送出路由請求(route request, RREQ)封包來啟動

2.中繼節點收到RREQ時，若收過此封包則丟棄，不然就更新封包內部資訊後繼續廣播此RREQ封包 

當此封包到達目的地或中繼節點的route cache中有目的地節點資訊時則回覆路由回應(Route Reply, RREP)封包

RREP封包利用來源路由(Source routing)的策略回傳至來源節點

當來源節點收到RREP封包後可開始傳輸資料封包 

路由錯誤(Route Error, RERR)封包 : 

1.在DSR協定中，當連結失敗 (即傳送封包給下一站時遇到 失敗)則會產生”路由錯誤(RERR)”封包送回並告知來源地

2.沿途的節點會把該路由資訊清除 

3.當來源地收到REER封包後會重新啟動路由探索程序找替代路徑 

DSR使用來源路由(Source routing)及路由快取貯存區 (route cache)策略有下列優點：

1.避免路由迴圈的產生(Routing Loop free) 

2.RREQ與RREP皆有整個路由路徑資訊

3.各節點可記錄路由 路徑資訊於route cache 

4.加速封包傳輸  RREQ與RREP皆有路由路徑資訊

5.可以有多條路由路徑

6.增加可靠性 (reliability)

回應式路由協定 –AODV(Ad-hoc On-Demand Distance Vector Routing)

AODV：使用如同DSR的路由探索使用RREQ與RREP 廣播機制找尋路徑。

但採用不同機制維護路由資訊： 使用傳統路由表 (目地、下一、跳躍數) 。

AODV捨棄 source routing而依靠著中繼節點機動地建立的路由表項 目(route table entries)。 

AODV 使用:

             1.DSDV的目的地序列編號演算法

                           距離向量 

                           序列編號 

             2.使用計時器(timer)保持路由新鮮。

回應式 (on-demand)產生路由：不在路由路徑(selected path)上的節點不需保有路由資訊與交換路由資訊。

目標：降低廣播經常費用(overhead)與傳輸延遲

對每一目的地路由表有一列資訊包含 :
<destination addr , next-hop addr , destination sequence number , life tine>

• 目的地 

• 下一節點 

• 量度 (metric) : 跳躍數 (hop count) 

• 目的地序號 (Sequence number) 

• 路由表項目過期時間[計時器]:被用過即重置，否則expire掉

• 來源節點廣播RREQ封包

• 中繼節點轉送至目的地節點

• 目的地節點以<broadcastID,src-address>來分辨RREQ 封包；且當收到第一個RREQ 封包時回應RREP封包

AODV-Route Discovery:

1.先檢查table->Yes 送
2.No->Source送RREQ
RREQ封包內容:<source IP addr , source current sequence number , destination IP addr , destination seq number>
封包也有Broadcast ID number(src 給)
所以當有Broadcast ID and Source IP addr就可以知道具唯一性。

Reverse Route Entry:

當node收到RREQ，會在route table建立一個reverse route entry
格式:<Source IP Address , Source seq. number , number of hops to source node , IP address of node from which RREQ was received>
使用這個reverse route entry去送RREP回Source，本身entry也具Life Time

RREP格式: <IP addr of source and destination>

If RREP sent by destination:
<current seq# of destination , hop-count= 0 , life-tine>

If sent by intermediate node
<destination seq number , hop-count=its distance to destination , its value of the life-tine>

When a node received a RREP means it can set up a forward path entry
<IP addr of destination , IP addr of node from which tje entry arrived , hop-count to destination , life-time>

When a node received multiple RREP 
- only forwards the first RREP
- May forward another RREP if that has greater destination seq number or a smaller hop-count
- Rest are discarded


NOTE:若Table中可以找到一個entry且Seq, number >= RREQ那可以直接送去destination
否則繼續轉送RREQ並增加hop-count

回應式路由協定 –TORA(：Temporally Ordered Routing Algorithm)

TORA : 為一回應式路由協定

路由探索程序：算出多條通往目的地之路徑->目的地導向的有向無迴圈圖(directed acyclic graph, DAG*) 

NOTE:*無線隨意網 路可被視為無方向的圖 (undirected graph) 但TORA將此圖的邊(edges)給與方向：朝向目的地節點。 

每個節點會記錄至任一目的地的距離又稱高度值。 封包送往目的地依其高度值遞減如水往下流。 

如何建立高度值：使用詢問(query) /更新(update) 機制 

當一節點嘗試送出封包時會發出詢問(Query)封包， 該封包廣播至整個網路直到目的地或有至目的地路 由的節點。接著此點會回覆更新(update)封包(包含自 己高度資訊)。

當其它結點收到更新(update)封包後…會更新其高度 值。

各節點的高度值建立成功，形成一以目的地導向的DAG 

當連結失敗時，節點發現它的高度值為局部最小時；則 會將其高度值提高並發出更新(update)封包

8.4 主動式與回應式路由之比較

定義：流量密度/差異(traffic diversity) ？[流量分布的情 形]

低流量密度：集中於網路的少數節點

高流量密度：平均分散於網路的每個節點

回應式路由能適應不同流量密度(較適合低流量密度)； 路徑非最佳，主動式路由則不受流量密度所影響。

高流量密度：路由負擔相當但：回應式路由->次佳路徑； 主動式路由->最佳路徑 

低流量密度：回應式路由->表現較佳 

->混合式路由(ZRP)

ZRP為一混合式路由協定。

一節點的區域(Zone)：半徑(= hop counts) 內的所有節點。

邊緣節點(Border node)：半徑上的所有節點。

Zone內使用連結狀態(link state)的主動式路由協定

 Zone間使用回應式路由協定的路由探索程序，其路由 請求封包只送往邊緣節點直到目的地的邊緣節點後回 覆。 

回應式路由 在路由探索(route discovery)造成較 長的延遲  不適用於對延遲 敏感(delay sensitive)和極短暫的應用(如問答) 

無線隨意網路路由協定 (Routing Protocols for MANET)----DSDV

無線隨意網路路由協定 (Routing Protocols for MANET)

8.1 無線隨意網路簡介 
8.2 主動式路由策略 
8.3 回應式路由策略 
8.4 主動式與回應式路由之比較
8.5 位置輔助路由 (location-based routing)策略 
8.6 結語

8.1 無線隨意網路

特性:

1.移動性(影響路由)
2.多點跳躍(multi-hop)

3.自我組態(self-configuration):node可以決定自己的參數[IP、路由表、位置]

4.可延伸性
5.安全性

無線隨意網路可隨時隨地可建立，無固定基礎架構，不需事先規劃與佈置；由自我(self)組態而 自動(auto)組織而成，成員可隨時加入或離開，通訊方法：單播(uni-cast)，群播 (multi-cast)。

大型的隨意(Ad-Hoc)網路封包傳輸須中繼站轉播 -->多點跳躍 (multi-hop) --> 路由(routing) ) 

[不同於(802.11)中定義的IBSS屬 單點跳躍(one-hop)可直接溝通無中繼站轉播,故無路由問題]

而單播(uni-cast)]路由策略又分以下四種:

1.主動式 (proactive)：事先建立 (又稱 table-driven) [8.2] 

2.回應式 (reactive)：只尋找與維護有需要的路由 [8.3] 

3.位置輔助 (Location-based)：利用節點的位置資訊 [8.4] 

4.混合式 (Hybrid)：主動式及回應式的混合[8.5]

8.2 主動式(proactive)路由策略

(無線隨意網路)主動式路由可分為：
距離向量 (Distance Vector, DV)法：記錄自己到網路中所 有節點的距離及要往該節點路由的下一個節點(向量)。 節點間交換距離向量(DV)資訊，從而計算出自己到各節 點的最佳路由。

連結狀態 (Link State)法：記錄自己的連結狀態。節點間 交換連結狀態，從而計算出自己到各節點的最佳路由。

距離向量(DV)不適用於隨意網路 (ad-hoc networks) ，因為網路連結失敗造成 路由迴圈 (Routing Loops)產生跳躍數無限 (Count to Infinity)，所以須要另找協定避免上述問題 ，

ex:目的地序列距離向量 (Destination-Sequenced Distance-Vector, DSDV) 協定

距離向量(Distance-Vector)路由協定

DSDV 協定:

DSDV是基於傳統Bellman-Ford路由選擇演算法所 改良而發展出來的，是一個以路由表(routing table)為基礎的通訊協定。 故每一個行動節點必須儲存一張路由表。須紀錄所有與該節點可能進行連結節點的距離。除給自己節點一個序列編號外，路由表內的每筆紀錄 同時還包含了一個目的地序列編號(destination sequence number)：用來判斷路徑的新舊，以避免迴路的產生。

當網路拓樸變動比較不頻繁時，並不需要將路由表的所有資料進行交換。DSDV在每個節點內再加了一個table，用來記錄其路由表從上次交換至今所更改的部分。如果更改很多[或定期地]，就進行全部資料的交 換，稱為全路由更新 (full routing update)；如果 改變很少，就只針對改變部分交換，稱為累加式路由更新 (incremental routing update)。

特性:

保有距離向量 (Distance Vector)的簡易性 

1.保證無迴路 ->路由表內新增一表項目 (Table Entry)：目的地序列編號 (Destination Sequence Number) 

3.對拓樸改變反應迅速??? 

       ->當路由表有顯著改變；立即做路由廣告(route advertisement)。 

       ->但對未穩定路由(unstable routes)採等待策略；而不立即做路由廣告 (damping             fluctuations) 

路由選取:

更新資訊與路由表比較： 

1. 選取目的地的序號 (destination sequence number) 較高的路由 (保證使用來自目 的地的最新資訊) 

2. 當目的地的序號一樣時，選取量度(Metric) [=至目的地的hop counts]較佳的路由

路由表範例

新節點加入:

無迴路，無跳躍數無限:

降低路由表的波動:

對每一個特殊目的地，保留關於最先到來的路由和最佳路由的到來的時間長度的資料。

依據這資料，决定延遲廣告 (可能將很快改變的) 路由 ，因而降低路由表的波動 (damping (抑制/降低) fluctuations )。通常為了減少相同序號編號之路由廣告的重播的數量 會延遲可能不穩定之路由廣告 。

何謂路由表的波動 :

路由表A中的項目D：[D, Q, 14, D-100] 

D 廣播序列編號 D-102  A 由P 收到D 的更新廣播：(D, 15, D-102) 

路由表A中的項目D：[D, P, 15, D-102] A 必須立即散播(propagate)此路由。

A 由Q收到D 的更新廣播：(D, 14, D-102)

路由表A中的項目D：[D, Q, 14, D-102] A 必須立即散播(propagate)此路由。

若不立即散播由P 收到的D 之更新廣播而延遲一 段時間，也許只要散播由Q 收到的D 之更新廣播 這可能發生在每一次在點D或其他節點做它的 更新廣播後導致在網路 上多餘的路由廣告，即 所謂波動 (fluctuations)。

如何緩和路由表波動:

於個別的表格上記錄上一次的決定時 間(Settling Time)與決定時間的平均。 [ 一個序列编号的第一個路由到來與最 佳的路由到來的時間間隔叫做決定時 間 (Settling Time)。]

當一個較新的特定序列编号的第一個 路由到來時，節點A仍然必須更新它的 路由表；但是它會等待一段時間才將 它散播。建議的等待時間約為平均決 定時間的兩倍。

在大型網路中像這的波動可以被降低 以避免多餘的廣告，因而節省了頻寬。

連結狀態(link-state)路由協定:

多重傳遞點(Multipoint Relay, MPR)概念：

1.單點跳躍 (1-hop)：節點A 與節點B能直接相互通訊時，我 們稱A與B為(直接) [單點跳躍 (1-hop)]鄰居；又稱A到B或 B到A為單點跳躍(1-hop) 。[單向通訊vs.雙向通訊???]

2.覆蓋：節點B與節點A為一單點跳躍的關係；我們可以說 節點B為節點A (或節點A為節點B)所覆蓋。 

3.兩點跳躍 (2-hop)：節點A與節點B及節點B與節點C皆為單 點跳躍(1-hop)的關係；但節點A與節點C無單點跳躍(1- hop)的關係時->節點A與節點C為一兩點跳躍(2-hop)的關係。又稱節點A為節點C[或節點C為節點A]的兩點跳躍(2- hop)鄰居

4.在節點A的單點跳躍 (1-hop)鄰居內選出一組特殊節 點；稱這些節點集合為”多重傳遞點” (Multipoint Relay, MPR)。

這些特殊節點要愈少愈好且滿足：節點A選出的MPR集合要能覆蓋節點A的所有兩點跳躍(2- hop)鄰居。PS:此最佳化問題為一NP-hard的問題

Self-management in chaotic wireless deployments

隨著無線通訊技術的進步，越來越多的AP被建立起來，而這些AP通常都是被隨意的設立，因此在沒有有善規劃下，會造成以下兩個問題:

Unplanned

由於，每一個人或公司組織在設立AP時，都是隨意設立，所以會造成有些區域密度過高，在使用相同頻段下，會造就出不好的網路環境。

Unmanaged

這個議題主要在探討parameter的，例如SSID，channel，以及較複雜的問題，包含AP個數的布置，還有power control。

(1)    首先此篇作者在美國城市中，大範圍的對APs做量測，發現到許多區域已經出現如chaotic deployment的網路形態。

A. Deployment Density

下表示從Place Lab database，所整理出來的資料，包含US的六個城市。(AP degree，表示有多少AP在它的干擾範圍。)

由上表和左圖可以發現高密度的802.11 hardware deployment已經開始出現 ，而且可以預期未來這樣的網路型態會增加的非常快速。

B. 802.11Usage: Channels

上表是Channel的份佈，可以用來觀察user of AP是否有善的管理他們的network，表中發現Channel 6的使用率最多，而non-overlapping的channel(1,11)，只有14%，所以這些AP當初的設置可能沒有考慮去minimize interference。

(2)    對Chaotic deployment做模擬量測:

在20-node的拓墣底下做模擬量測，底下左圖是用來做為優化的sub-topology。

(b) 8-node topology

(a) 20-node topology

上圖是在每個AP的Client為"1"的情況下，ap間的巨來會影響整體的吞吐量。tpf和http之間也會影響彼此的performance

當有channel配置管理時可以發現整體的吞吐量達到步錯的提升，不過可以發現stretch=1和stretch=2還是有一段差距。

當client增加，可以發現ftp和http的performance都會因ap增加而降低，可以看到stretch=1和stretch=10的performance差距很大。

當有channel管理配置，和power control可以發現performace達到很高的提升，stretch=1和strech=10幾乎一樣，所以power control是非常必要的。

(3)    TRANSMISSION POWER AND RATE SELECTION:

Power and Rate Selection Algorithm

ARF: 如果連續成功n次收到ACK，代表channel的狀況良好，可以繼續提高data rate，如果連續失敗m次，代表channel狀況不好，降低data rate，在這裡作者將m設為6，n設為4。

ERF(Estimated Rate Fallback):混合上述兩種方法的rate selection Algorithms，首先測量channel SNR，ERF 再選擇SNR可以維持的最高data rate，因為有可能會發生測量不準的關係 ，當所測出的SNR剛好低於rate decision boundary 一點，系統會在幾次傳輸成功後，rate再調回到下一個  level ，當SNR剛好高於rate decision boundary 一點，系統會在幾次傳輸失敗後，再調回去上一個Level。

PERF(Power-controlled Estimated Rate Fallback ):一開始跟前頁講的一樣，選擇SNR可以維持的highest data rate，如果EstimatedSNR還高於所需的SNR一些量(power margin)，就可以降低transit power rate，直到EstimatedSNR=decisionSNR+ power margin。在Unlimited的情況下，victim的throughput在ARF和ERF幾乎的零，原因在於，victim可以sense到aggressor，因為aggressor的transit power較高，但aggressor無法sense到victim，導致aggressor無止盡的增加他的rate，而victim則為了避免碰撞，所以就會降低他傳送的慾望，造成極低的throughput。而在PERF下， aggressor因為利他的心態下，我在某個rate，盡可能的降低transit power，讓兩組pairs可以獨立運作，而不相干擾。因此可以達到好的效果。