lab9 無線網路效能分析探討(-) 隱藏節點和暴露節點問題

實驗目的:

1. 了解什麼是隱藏節點和暴露節點
2. 了解 RTS/CTS如何降低隱藏節點問題發生的機會,以提升系統效能 3. 了解 NS2 中無線傳輸模型和門檻的觀念

背景知識:

• 隱藏節點問題:
  
  節點B在節點A和節點C傳輸範圍內的交集區域內,但是A和C都不在互相的傳輸範圍內,這時有兩個節點A,C同時想傳送資料給節點B,節點A傳送資料給B時,節點C會認為目前網路閒置,同時也會傳送資料給節點B,同時傳送給節點B的資料就會發生碰撞(Collision).
  
  這種因傳送距離而發生的誤判的問題稱為隱藏節點問題(Hidden Terminal Problem).

• 降低隱藏節點問題
  
  當Tx在送出資料前先發送一個控制封包 (Request to Send),告知Tx傳送範圍內的所有節點不要有任何傳輸的動作,而Rx如果目前是空閒的,則回應一個Clear to Send 封包告訴Tx可以開始傳送料,如此一來就可以降低隱藏節點的問題,但是並不能完全解決!




• 暴露節點問題
  
  
  Tx:C 要傳送資料給D時,發現(聽到)傳輸範圍內的B正在傳送資料給A(C是B的暴露節點),Tx:C就會延遲傳送,但這種延遲是不必要的,因為B傳送資料給A與C傳送資料給D並不衝突,因此這種因為聽到傳輸範圍內有節點在傳輸,而延遲傳輸就是暴露節點的問題
  
• 使用RTS/CTS
  我們可能想到使用RTS/CTS,當C聽到B送出的RTS,但卻沒聽到相對應的CTS,那麼不就可以推論出C是自己是暴露節點了嗎?!所以C可以同時傳送資料出去,但在這種情況下,如果是別人傳送資料給C,那麼就可能預B傳送的資料發生碰撞,所以使用RTS/CTS並不能解決暴露節點的問題
  
• 傳輸模型及門檻
  NS2實做了一些傳輸模型:

Free Space 是最理想的傳輸模型(檔案在~/ns-2.29/mobile/propagation.h & propagation.cc)

Two Ray Ground 除了考慮直線 path loss也考慮地面反射(reflection of ground)
(檔案在~/ns-2.29/mobile/tworayground.h & tworayground.cc)

Shadowing 是用來模擬Tx到Rx中間有障礙物時對傳送訊號的影響,常用於indoor
(檔案在~/ns-2.29/mobile/shadowing.h & shadowing.cc)

關於"門檻",NS2主要利用訊號強度門檻(Threshold)方式,判斷封包是否成功收到
NS2設定一個訊號偵測(Carrier Sense)的門檻CSThresh_ ,決定封包是否能被Rx偵測出來 (於PHY Module)
NS2會設定另一個RxThresh_ ,用來判斷封包是否能被Rx所接收 (於MAC)

(檔案在~/ns-2.29/mobile/wireless-phy.h & wireless-phy.cc)

開始實驗步驟

STEP1.

ns2提供一個小工具程式threshold.cc(在ns-allinone-2.29/ns-2.29/indep-utils/propagation)，他可以藉由輸入想要使用的傳輸模型和有效傳輸距離，而輸出相對應的參數值

用g++編譯它

顯示警告

意思是版本不同了,引入的標頭檔不用x.h的形式而用x來取代
沒關係 不影響我們的作業
編譯完後在同目錄下會產生一個threshold.exe

STEP2
執行

它告訴我們使用方法囉
來測試看看 設定傳輸模式TwoRayGround 有效傳輸距離250m

顯示參數

STEP3
用TCL模擬程式驗證(home/clark/lab9/test_2nodes.tcl)
這程式設定有兩節點n0(30,30),n1(280,30) n0要傳輸給n1,參數如上設定
執行

模擬結束,會產生接收紀錄檔,打開來看看,確實有接收到

STEP4
那如果變更超過可接受距離呢?

在執行一次 $ns test_2nodes.tcl,開啟此次接收檔rd

可知n1完全沒接收到n0傳來的資料

接下來要討論隱藏節點問題了
如圖一nA-nB d=100m ,nB-nC d=100 m,節點之間的carrier sense d=150m 傳送有效距離為120m
利用小工具知道我們要設定的參數

對於CSThresh_的設定 ,因為用的公是相同,只要把RXThresh_結果拿來用即可
TCL模擬程式

執行
$ns test_hidden_terminal.tcl
我們看執行後產生的紀錄檔

sd1:

sd2:

rd1:
rd2:

更改TCL模擬檔

再一次執行

rd1:

rd2:

明顯的 使用RTS/CTS可以降低隱藏節點問題,但不能完整解決

接下來討論暴露節點問題
如圖2所示
S1,S2同時想分別傳送 資料給R1,R2,節點之間距離都是100m ,carrier sense 距離120m,有效傳輸距離100m用小工具算出相對應參數

tcl模擬程式

執行 $ns test_exposed_terminal.tcl

記錄檔封包

更改 ctsrts

rd1

rd2

結果顯示 使用RTS/CTS不能有效解決暴露節點的問題

又是防火牆擋PORT (IIS & 防火牆)

晚上中毒後,下載小紅傘 ~最近很夯的德國免費強大防毒軟體
繼續我的網頁製作~問題來了 ~ 居然無法連結我的IIS

又來孤狗一下 ~

參考

防火牆擋住 80 port ... 應該是說 被關掉了..

解決:
開啟 網路連線->點擊區域連線->點擊內容->點擊進階->點擊設定值->點擊進階->點擊設定值->選擇標籤 服務
->打勾網頁伺服器(HTTP)

~END~

Format My Source Code for Blogging

Format My Source Code for Blogging

編碼問題

網頁流程:
[login.php]登入頁面-->[check.php] 登入 -> [tpolygondemo2.php] 首頁
_>[name.php]新增會員 ->[addmember.php] 新增會員至資料庫


網頁編碼皆選擇 utf-8 ,
name.php的表單資料(變數)傳遞給在背後的addmember.php,進行insert to DB動作
要在DB management 上看到繁體中文,需要在addmember.php裡面的資料庫連結部分加上


mysql_query("SET NAMES 'utf8'");
這是寫繁體中文進資料庫的方法


試著用mysql_query("SET NAMES 'big5'");
結果在DBM看到的是亂碼(非一堆問號,是中文字..)


以上都是網頁編碼選擇UTF-8 ,那反過來呢?
如果網頁編碼選擇 big5
連結資料庫時 加上mysql_query("SET NAMES 'big5'");


沒問題 ~ 正常顯示


試著用mysql_query("SET NAMES 'utf8'");
這裡忘記了.. 只依稀記的應該也是中文亂碼

目前寫進資料庫 ~ 沒問題了~

那讀出來呢? 問題大了 ~~~

0~7 是 陣列資料 利用下列方式

$fields_data = mysql_fetch_row($result)

再用 foreach($fields_data as $name => $value ) // 把每一筆直印出來

{echo "$name : $value
" ; }

圖中"問號"就是繁體部分.. 現在要解決的就是中文讀取問題囉~

參考 MySQL 中文編碼徹底研究 作者jaceju 寫的非常詳細,值得花時間去看

文中提到

當 MySQL 要寫入資料或讀出資料時，它無法確定這些資料的格式是不是符合使用者的要求。這時候我們就得自行指定正確的編碼，讓 MySQL 自動轉換這些資料。因此，在對 MySQL 4.1 以後的版本下達 INSERT, UPDATE 及 SELECT 指令之前，都應該要先用以下指令來指定正確的連線校對

SET NAMES 'utf8'

也就是說在 MySQL 4.1 以後，就算我們把預設字集設為 big5 或 utf8 ，事實上還是得看資料庫或資料表實際所設定的校對編碼 (除非建立時採用繼承值) 。所以 SET NAMES 只會影響 MySQL 伺服端和 PHP 程式之間的通訊編碼格式，跟預設字集沒有太大關係。

看樣子使用utf-8頁面編碼比起big5 會方便許多,之前寫的網頁都是用big5,趁還沒太多網頁,全部改為utf-8了

跟寫入時一樣, 讀取時 設定 SET NAMES 'utf8' 編碼目前都沒問題了

無線網路封包模型

實驗目的:

1. 介紹無線網路的封包傳輸遺失模型

2.了解群體廣播(multicast) and 單點廣播(unicast) 的傳輸模式對於封包傳輸遺失機率的影響

背景知識 :

封包在傳輸時, 封包遺失的原因有兩個

• 擁塞遺失(congestion loss) : 網路擁塞,queue緩衝空間不足, 而將部分封包丟棄
• 無線遺失(wireless loss) : channel 受外界影響造成訊號衰減或干擾,造成封包遺失

對於無線傳輸遺失而言,根據資料遺失的分佈現象可分成兩種

• 分散式遺失(distributed loss) :遺失分佈情形 分散且平均 常用隨機統一模型(random uniform model)表示
• 連續性遺失(burst loss) : 遺失現象以連續性居多 常用Gilbert-Elliott模型(GE model)表示

接著討論multicast 與 unicast 兩種無線傳輸模式

• multicast : 封包遺失,Tx不會重新傳送,網路使用者所感受的傳送遺失機率(application-level packet loss rate)會與網路底層(physical-level packet loss rate)有相同的P
• unicast : 封包遺失,Tx利用重傳機制重新傳送封包,網路使用者所感受的傳送遺失機率當然就不會與網路底成的不同了,為了避免一直重傳而造成的傳輸延遲,我們會設定最大重傳次數N
  

接下來要用NS2模擬的環境,因為考慮到傳輸過程會因為碰撞或是訊號不在接收範圍內等錯誤,所以作者修改了mac目錄下的wireless-phy.cc,加上了random uniform model,以期達到真實狀態,需要注意的是,如果傳輸模型屬於雙向傳輸,那麼不僅接收端要加上無線遺失模型,傳送端也要

實驗步驟

執行lab5.tcl

(情境一)

使用 random uniform model (Pg = 0.1 , loss_model = 0) 和multicast 傳送(comm_type = 0)

執行結果:

我們得到兩個紀錄檔

傳送記錄檔(rd)

接收記錄檔(sd)

由此可知封包遺失率 = (12351-11124)/12351 = 0.099

趨近於預設的網路底層封包遺失率0.1

這說明了當 multicast傳送時 ,網路使用者所感受的傳送遺失機率(application-level packet loss rate)會與網路底層(physical-level packet loss rate)有相同的P

(情境二)

使用 random uniform model (Pg = 0.4 , loss_model = 0) 和unicast 傳送(comm_type = 1)

執行結果:
我們得到兩個紀錄檔

傳送記錄檔(sd)

接收記錄檔(rd)

由此可知封包遺失率 = (12351-12061)/12351 = 0.0234
趨近於預設的網路底層封包遺失率0.4的4次方

這說明了當 multicast傳送時 ,網路使用者所感受的傳送遺失機率(application-level packet loss rate)大約為網路底層(physical-level packet loss rate)設定的遺失率的4次方

(情境三)
使用 GE model (Pgg = 0.96 , Pbb = 0.94 , Pg = 0.001 , Pb = 0.05, loss_model = 1) 和multicast 傳送(comm_type = 0)

執行結果:

我們得到兩個紀錄檔

傳送記錄檔(sd)

接收記錄檔(rd)

由此可知封包遺失率 = (12351-12118)/12351 = 0.0188

趨近於理論值 0.01*(1-0.94) + 0.05*(1-0.96) / ( (1-0.96) + (1-0.94) ) = 0.0206

實驗四 PART II 無線網路

模擬範圍區域 1000m*1000m

共有3個Mobile Nodes : n0(350,500) , n1(500,500) , n2(650,500)

n0-n2 間有CBR/UDP連線

模擬時間200秒 : n1 從(500,500) ->(500,900)

模擬時間500秒 : n1 從(500,900) ->(500,100)

總模擬時間 : 1000秒

STEP1 執行 wireless-measure.tcl

模擬結束後一樣會產生sd_udp & rd_udp兩個紀錄檔

STEP2 計算CBR的封包遺失率

(453-205)/453 = 54.74%

STEP 3 求得封包延遲時間

再使用gnuplot 畫出cbr_delay

畫圖結果:

STEP4 計算抖動率

與上一步 一樣畫圖

畫圖結果:

STEP5 計算吞吐量

執行結果: