這個章節在探討實作時的細節，首先介紹實驗用的配備與無線通 訊環境，第二段說明SCTP 原始碼的取得來源與版本，第三段討論 WLAN 訊號強度與資料傳輸的關係，第四段對於 GPRS 頻寬的限制 做簡單的測試並討論結果，第五段討論 SCTP 在某種情況，並非真正 multi-homing 的問題與解法，最後探討 routing table 與網路介面的問 題。
3.1 實驗配備
本實驗用來測試實作的行動裝置是筆記型電腦，作業系統為 Windows XP SP2，無線網路方面，配有一張無線網路卡 D-Link DWL-G650+，Access Point 型號 D-Link DWL-2000AP+，無線網路環 境為WLAN 802.11g 54Mbps；GPRS 方面，配有一個 Solomon GPRS modem，網路環境為中華電信 GPRS 115Kbps，費率為每 128bytes 0.03 元；伺服器端是固定的主機，作業系統為FreeBSD 4.9-RELEASE 版 本，網路卡型號Intel 10/100 BaseTX，網路環境是乙太網路 100Mbps。
3.2 SCTP 原始碼的取得
我們用來修改並測試實作的SCTP 原始碼，是由 GNU Public
23
License (GPL)和 GNU Lesser Public License (LGPL)所發行，版本為 sctplib-1.0.2；目前最新的版本為 sctplib-1.0.3，在 2005 年 3 月 4 號 釋出；此兩種版本都可以在Linux、FreeBSD、Mac OS X、Solaris、
及Windows 上運作執行[23]。
3.3 High threshold 與 Low threshold 的取得
我們取得訊號強度的方法，是利用WiFiAPI，透過 NDIS User Mode I/O protocol 來取得，取得的值的大小，與提供廠商有關，我們的實 驗配備所取得的數據在0～255 之間，與 dBm 單位的換算方式，可以 參考[22]。
為了訂出High threshold 與 Low threshold 的值，我們針對不同的 WLAN 訊號強度，做定時定量資料傳輸的實驗，觀察其值與封包遺 失率的關係。
實驗流程與結果
我們用3.1 所介紹的配備，在 WLAN 的網域內移動，並定時 每秒送出100bytes 的資料，紀錄當時的訊號強度與封包是否 遺失，實驗時間為3 分鐘，結果如下表：
RSSI 217 216 215 214 211 210 204 202 201 199
傳送封包數 4 3 2 2 2 2 4 6 2 6
遺失封包數 0 0 0 0 0 0 0 0 0 0
198 197 196 195 194 193 192 191 190 189 8 8 2 2 14 20 24 10 13 16 1 1 1 2 1 5 8 3 6 3
24
188 186 185 184 183 181 180 179 178 2 2 2 4 2 6 6 4 2 1 2 2 2 0 6 6 4 2 表3-1 WLAN 訊號強度與資料傳輸的關係
實驗結果分析
根據此結果，我們保守估計當訊號強度大於200 時，封包遺 失率幾乎為0%；當訊號強度介於 200 與 180 之間，封包遺失 率平均為34%；當訊號強度小於 180 時，封包遺失率幾乎為 100%。如下圖所示：
圖 3-1 WLAN 訊號強度與封包遺失率的關係
因此，我們設定High threshold 為 200，Low threshold 為 180 做為我們實驗的參數。
3.4 GPRS 傳輸資料大小與 RTT 的關係
因為GPRS 頻寬的限制，所以如果單位時間內傳輸的資料過於龐 大，會使反應時間拉長，因此我們需要根據實驗，來觀察GPRS 在不 同資料量傳輸時的round trip time，並印證我們的應用適合於 GPRS 的環境。
25
實驗流程與結果
我們用3.1 所介紹的配備，在 GPRS 的環境下，定時每秒送 出100、150、200、500、1000bytes 的資料，然後紀錄每個封 包的反應時間，實驗時間為55 秒，結果如下圖： 秒以下的機會變的更低(30%)；當傳輸資料為 1000bytes 時，
RTT 會變的很糟糕；因為我們的研究要有快速的反應時間，
所以我們選擇100bytes 與 200bytes 作為實驗的參數，這適合 傳輸資料頻率低與短封包的應用，例如：網路棋類、麻將類
0 10000 20000 30000 40000 50000 60000
100bytes
26
如1.1.4.1 對 SCTP 所做的簡介，SCTP 對於 path 的定義，就等同 於有幾個destination，這在某種情況下，會使的 SCTP multi-homing 的特性失效[6]。以下圖為例：
圖 3-3 SCTP 單點錯誤示意圖
對Endpoint A 來說，由於他的 destination 只有一個，所以 path 就 只有一條，如果主要的那條連線中斷，則會造成path 變成 inactive，
由於唯一的一條path 變成 inactive，整個 SCTP 連線就會中斷，可是 Endpoint A 的另一個介面依然是可用的，所以 SCTP multi-homing 的 特性就失效了；我們採用full-mesh paths[7]來解決此問題，此方法對 path 的定義除了 destination，還有加入 source 來做配對，以圖 3-3 為 例，Endpoint A 有兩個 source 與一個 destination，所以他的 path 數目 為2，當主要的 path inactive，就會轉換到另外一條來繼續傳輸。
3.6 Routing table 和網路介面之間的問題
因為我們的演算法，需要指定用哪個網路介面來做傳輸，所以我 們必須要修改用戶端的routing table，讓封包在做繞送時，可以透過 正確的網路介面，修改方式如下：
27
圖 3-4 修改 Routing table
伺服器的IP 為 140.113.210.143、而用戶端的 WLAN 的 IP 為 140.113.210.116、GPRS 的 IP 為 221.120.1.1；當加上紅色圈圈這一個 rule 後，只要指定用 GPRS 傳送資料，封包在繞送時就會比對適合的 rule，正確的透過 GPRS 來做傳輸。