• 沒有找到結果。

對行動節點與網路管理者的建議

第五章 分析與評估

5.3 跨網域交遞機制的建議

5.3.5 對行動節點與網路管理者的建議

由於快速的跨網域交遞必須要整個網路環境的建設配合行動節點自主的動作,所以 本篇論文經過分析與評估後對於行動節點與網路管理者有以下的建議。

5.3.5.1 建議一

最快速的交遞莫過於多買一張無線網路卡,利用Mobile SCTP 的機制,這樣不管 網路管理者是怎麼設置整個無線網路環境,都可以非常快速的完成整個跨網域交遞 的動作。但是這對絕大多數的使用者而言是不切實際的,比較可行的辦法是以後硬 體廠商都願意提高成本將無線網路卡設計為兩塊無線網路晶片配合兩支天線。

另外這個建議對於行動節點的電力負擔也勢必需要考量的,因為兩張無線網路卡同 時工作的話,勢必會造成行動節點的電力消耗速度加快。要不要花費電力來完成非 常快速的完成跨網域交遞,這就是行動節點自己必須取捨的地方。

5.3.5.2 建議二

所以我對行動使用者的建議為利用一隻daemon 隨時監控無線網路的訊號強度,一 但發現衰減的比率很快,就要在比first threshold 更強的訊號強度之前的開始做 handover 的準備。

首先就是Pre-probe 的動作,每 300ms 作一次 probe,並且先 probe 頻道 1、6、

11,如果都沒有找到訊號強度夠高的無線存取點在開始 probe 其他的頻道。這裡大 概有九成的比率是可以在1、6、11 頻道中找到合適的無線存取點。

在做probe 的時候網路管理者必須讓行動節點知道無線存取點的網域跟 MAC 的對 應關係,最簡單的作法就是寫個location server 並且當行動節點第一次進入你管理 的網路環境時就將所有網路管理者所管的無線存取點的資訊傳給行動節點。

當有這些資訊後,可以有兩種選擇:

A. 網路管理者必須架設DHCP server以及DHCP relay agent,而行動節點根 據這些資料開始做DHCP address pre-configuration,如前面 3.3.2 所提的 流程,可以順利的拿到新網域的各種資訊。並且隨時監控目前連線的無線 訊號強度等到second threshold來臨,當訊號強度低於second threshold馬 上開始做authentication、association、以及設定新網路位址、新存取路由。

這個選擇的延遲(行動節點無法收到封包)加起來必須花 70ms,也就是說甚 至比我們去probe所花的時間更少,但是行動節點已經可以使用新的無線網 路連線連上網際網路了 (Figure 5- 2)。

65 ms

Pre-probe DHCP client with SSO, DHCP relay agent Deauthentication,

authentication,

association Set IP,

Router

VoIP Kphone re-connection

400 ms~6 secs

70 ms 2 ms 8 ms

70 ms 2 ms 8 ms

0 ms 0 ms

DHCP address configuration probe

25ms 2 ms 8 ms

Handover the same essid AP

5ms Resource location

server option

Figure 5- 2 Latencies of over all handover

B. 網路管理者必須架設 Mobile IP,行動節點也必須配合使用 Mobile IP FA-CoA 隨時監控目前連線的無線訊號強度等到 second threshold 來臨,

當訊號強度低於second threshold 馬上開始做 authentication、

association,接著馬上發出 agent Solicitation。

等收到agent advertisement 後再馬上發 RegistrationRequest,並等待 Registration Reply 與封包一同到達。這個選擇的延遲(行動節點無法收到 封包)平均為 280ms (layer 2: 70ms, waiting advertisement: 100ms, waiting Reply: 60ms, Mobile IP HA tunnel 50ms)。

以上兩種選擇各有其優缺點,A 方法可以快速的達到跨網域交遞的動作,比較適合 在乎video (audio) streaming 品質的使用者使用,但是用了方法 A 會造成 TCP 的 session 中斷必須要重新連結 TCP socket。

B 方法在使用者正在用 video (audio) 的情況下,比較敏感的使用者會覺得有瞬間 的中斷感。但是一但完成後可以繼續使用剛剛所有的應用程式,而不需要重新連結 TCP 連線、重新登入 MSN、重新進入加密的網頁等等重新連結的動作。

5.3.5.2.1 縮短 solicitation 與 advertisement 之間的 delay

由於原本的FA 收到 agent Solicitation 後會多等待一個 random delay 後才 回行動節點agent advertisement,這段時間 100~140ms 不等。為了減輕這 個負擔,我們將FA 裡面的 delay 移除,讓 FA 接收到 agent Solicitation 後馬上可以回行動節點agent advertisement,這樣一來這段延遲時間就降 到只有15ms。

所以B 方法可以再降低到只剩下 195ms(layer 2: 70ms, waiting advertisement:

15ms, waiting Registration Reply: 60ms, Mobile IP HA tunnel 50ms)的跨網域交 遞延遲。

依據 5.2所提出的實驗數據,除了running之外,從-50dbm開始在喪失連線之前最 少還有8 秒鐘可以做handover的預先準備,而我們所提出的兩種(DHCP、Mobile IP address pre-configuration)都不需要花到這麼久的時間,所以可以順利的完成跨網 域交遞的動作。以上的兩個辦法都是可行的方法,但是這還有賴網路管理者與使用 者互相配合,才能達到這些結果。

另外當running 的情況產生的時候,唯一克服的辦法只有一進入新網域就取得所有 鄰近網域的網路位址資源,換句話說first threshold 不能從-50dbm 開始,而要從 每次進入新網域就當作first threshold 已經發生,但這需要預先佔用更多的網路資 源,所以這點也是網路管理者與行動節點必須取捨的部份。

第六章 結論與未來工作

相關文件