測試OK！
因為有設定初值，所以不會出現warning message
-n：指定場景中有多少個節點。-p：指定當某節點到達目的地後要停留多少時間，如果設為0.0就表示不停流馬上往下一個目的地前進。
-M：指定節點隨機移動時速度的最大值，單位是m/sec，其速度將在[0, max speed中]隨機選擇。
-t：指定模擬場景的持續時間，單位是秒。
-x：指定移動區域的長度，x軸方向，單位是公尺。
-y：指定移動區域的長度，y軸方向，單位是公尺。
◎實驗：
●範例一：
此實驗有100個無線節點組成，模擬時間為100秒，pause time設為100秒，在模擬這段時間沒有mobility，另外設定使用CBR flow，最大連線數目為10條，每一條送出十個封包。
○使用cbrgen產生traffic pattern。
○使用setdest產生無線網路移動場景。
○執行模擬以及用效能評估程式觀看結果
DSDV：
AODV：
DSR：
從實驗結果可以看出，使用DSDV可以比較收到第一個封包，這是因為DSDV是table-driven protocol，資料傳送前，已經知道路徑，所以不需要再去尋找新的路徑，因此會收到較早收到第一個封包。
●範例二：
這個實驗是100個無線節點所組成，模擬時間為100秒，pause time設為0秒，也就是在模擬這段時間節點隨時都在移動中，另外設定使用CBR flow，最大連線數目為十條，每一條每秒送出十個封包。
○使用setdest.exe產生無線網路移動場景。
○執行模擬以及用效能評估程式觀看結果DSDV：
AODV：
DSR：
※這裡有點奇怪，因為由書本上告訴我這個實驗的結果應該會看到使用AODV或DSR的可以使的第一個封包接收的時間較早，但是我模擬之後的分析結果卻不是這樣書本上的DSDV的第一個接收時間是12.225 s，但我的卻是2.561 s。照理說應該會比較慢才對，因為實驗的場景是在節點隨時都在移動的場景，DSDV必須花時間更新路由表，所以應該會較慢。
下圖是使用說明
從這個結果得知若要設定有效傳輸距離為250公尺時，需要在模擬的TCL中設定傳輸功率為0.281838，傳輸頻率為9.14e+08，傳送天線增益為1，接收天線增益為1，傳送高度為1.5，接收天線告度為1.5，RxThresh_須設定為3.6526e-10。
用公式驗證RxThresh_的值：
(0.281838×(1.5^2)×(1.5^2))/(250^4)=3.652e-10
接下來用TC模擬程式驗證
首先確定lab9目錄下的test_2nodes.tcl裡面所設的參數是否設成上述我們得到的參數數值
然後進行模擬
模擬結束後發現產生傳送記錄檔(sd)和接收記錄檔(rd)，且rd記錄接收到的封包資訊接著我更改了TCL裡面的距離設定
原先的傳輸距離是設定為250公尺
我將它改成251公尺
結果發現模擬結束之後產生的rd檔案中是空的
表示只有傳送，但是卻沒收到任何的封包。
●隱藏節點問題：
情境描述：節點A到節點B的距離為100公尺，節點B到節點C的距離也是100公尺，而節點之間的carrier sense距離是150公尺，可以傳送資料的有效距離是120公尺
○先使用threshold.exe求出相對應的參數
設定的有效傳輸距離為120公尺時，需要的相關參數為傳送功率0.281838，傳送頻率9.14e+08，傳送天線增益為1，接收天線增益為1，傳送天線高度1.5，接收天線高度1.5，最後RxThresh_為6.88081e-09。 
然後來執行模擬以及看模擬的結果
○先看沒有RTS/CTS時(TCL裡面的要寫Mac/802_ 11 set RTSThreshold_ 3000)
然後跑模擬
跑完之後得到兩個發送端記錄檔(sd1,sd2)和兩個接收端記錄檔(rd1,rd2)sd1送出1689個封包，rd1收到154個封包，sd2送出1627個封包，rd2收到105個封包。
○接下來換看有RTS/CTS時(TCL裡面的要寫Mac/802_ 11 set RTSThreshold_ 0)
sd1送出1689個封包，rd1收到739個封包，sd2送出1627個封包，rd2收到783個封包。
從這個結果看來使用RTS/CTS可以降低隱藏節點問題。
●暴露節點問題：
情境描述：節點S1和節點S2同時想要分別傳送資料到R1和R2，節點之間的距離都為100公尺，而carrier sense距離為120公尺，可以傳送資料的有效距離為100公尺。
使用threshold.exe求出相對應的參數
因為有效距離120公尺剛剛已經做過，所以就不再做一次了。接著設定好參數進行模擬
○先模擬沒有RTS/CTS的情況(設定方式同隱藏節點時的做法)
執行完會產生sd1,sd2,rd1,rd2的記錄檔sd1送出1689個封包，rd1收到926個封包，sd2送出1627個封包，rd2收到796個封包。
○當有RTS/CTS的情況
sd1送出1689個封包，rd1收到829個封包，sd2送出1627個封包，rd2收到783個封包。
這個結果顯示RTS/CTS並不能有效的解決暴露節點問題。
Step3：接著再使用MP4Box將m4v檔案轉成mp4，注意這裡使用不同的封包大小去傳輸視訊串流，用mtu的選項設定，這個選項也要跟後面NS2模擬環境所使用的封包大小一致。(注意，這裡執行MP4Box前要記得把msvcr70.dll放進去lab8資料夾裡面，這地方跟實驗六的情況一樣)
Step4：接下來利用mp4trace程式將影片中的每一個frame相關資訊擷取出來並存放到附檔名為st的檔案中(這裡設成foreman_qcif.st)
Step5：接下來利用得到的st檔案，使用NS2模擬工具去模擬網路效能(這裡記得封包大小值要設成跟剛剛設的一樣(1024))
Step6：上一個步驟的模擬過程結束之後會產生傳送記錄(sd)、接收記錄(rd)，把這兩個檔案再加上影片記錄檔foreman_qcif.st檔案和mp4檔案，經由etmp4程式產生一個有畫面遺失的影片mp4檔(檔名是foreman_qcife)
Step7：再度使用ffmpeg程式，將上一步驟得到的重建後的mp4檔回復成yuv影片
Step8：最後，使用avgpsnr程式去針對重建後的yuv影片檔及原始tuv影片檔，獲得重建後的yuv影片的平均PSNR值大小。
PSNR=26.609726
下面是將原始圖和重建所得的圖show出來
結果
GOP length(g)較短的影像品質比較長的好
壓縮量化(qscale)的值越大影像品質越差
封包長度(mtu)越長影像品質越高
