無線區域網路跨階層式頻寬有效利用機制

(1)

無線區域網路跨階層式頻寬有效利用機制

林靖倫潘仁義

國立中正大學通訊工程研究所

[email protected] [email protected]

摘要

Receive Signal Strength Indication (RSSI) 是 802.11 標準規範裡用以選擇 Access Point (AP) 的指標，主要是根據訊號強度及連線品質作為判斷依據，這樣的選取方式會造成訊號強的 AP 擁有過多的使用者導致網路負載不平衡。先前的研究大都著重在如何平衡 AP 之間的網路負載，然而卻鮮少提及實際切換時傳輸的流程與方法。本文提出在 WLAN 環境下跨階層的頻寬有效利用機制 (Bandwidth Utilization In cross-Layer Design, BUILD)，以網路的角度透過多重介面傳輸來達到頻寬有效利用的目標，並結合傳統 DHCP 的機制辨認具有多重傳輸介面的使用者連線。在未來還可配合 Soft Handoff over IP (SHIP) 的設計達到無縫換手

(Seamless Handoff) ，以及 Local Connection

Translation (LCT) 實現應用層對移動通透性 (Mobility Transparent to Applications)的支援。關鍵詞：IEEE 802.11, AP Balance, Multi-interface, Cross Layer Design, Seamless Handoff.

Abstract

Receive Signal Strength Indication (RSSI) is a criteria used to choose association Access Point (AP) according to signal strength and link quality in IEEE 802.11 standard. This may cause too many users associated with one AP with strongest signal and unbalance the network traffic load. Previous researches commonly focus on how to equalize traffic load among APs but rarely refer to communication and switching mechanism in real world. We propose a Bandwidth Utilization In cross-Layer Design (BUILD) under WLAN to approach bandwidth utilization with multiple interface connections from a network’s point of view. We also combine traditional DHCP architecture to recognize multiple interface connections form the same user. In the future, BUILD may cooperate with Soft Handoff over IP (SHIP) to achieve seamless handoff and Local Connection Translation (LCT) for mobility transparent to applications.

1. 簡介

由 IEEE 制訂的 802.11 家族不斷推陳出新， 802.11a/g 都對外宣稱最高傳輸可支援到 54 Mbps 及 108 Mbps 的傳輸速率，然而這僅是對資料封裝傳輸的速度。現實環境下的負載，諸如 CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) 的延遲時間(backoff time)、802.11 的標頭檔、ACK、RTS、CTS…等皆未納入考量。根據 Xiao 與 Rosdahl 在 [15] 的研究結果顯示，目前 802.11 a/g 理論上最大的傳輸速率僅能達到 24.7 Mbps 與 32.8 Mbps，相較有線網路 100 Mbps 的傳輸速度仍有一段差距，由此不難看出無線網路的頻寬截至今日依然屬於稀有的資源。日前政府大力推行 M-Taiwan 計畫 [1] ，其中又以台北市進展最快，在捷運車站附近都已經可以使用 802.11 無線網路上網。而在未來使用者大量增加的情況下，極有可能出現無線網路頻寬不足的問題，如何對有限的頻寬作最有效的利用，一直是學者研究探討的主題。 RSSI 是 802.11 [4] 標準規範裡用以選擇 AP 的指標，主要是根據訊號強度及連線品質作為判斷依據。這樣的選取方式會導致所有的無線網路使用端 (STA) 都選擇訊號強、品質高的 AP，使得訊號強的 AP 擁有較高的網路負載，訊號次之的 AP 則乏人問津，無法充分利用所有的無線頻寬。到底要如何充分利用 AP 的傳輸效能來達到頻寬公平負載？現行的研究大約可以整理如表 1： 表 1 頻寬負載相關研究比較 Received Signal Strength Indicator (RSSI) [4] Cisco Aironet 350 Series Access Points [2] Hot-Spot Congestion Relief in Public-area Wireless Networks [6] Performance of an efficient Method for Association Admission Control [11] Fairness and Load Balancing in Wireless LANs Using Association Control [16] Signal Strength V V Number of STA V V Link Quality V V V Available Bandwidth V Transmission Rate V V AP Selection Algorithm Judging Parameter

Keywords: IEEE 802.11, AP Balance, Multi-interface,

(2)

大部分的研究均著重在如何根據現有資訊來平衡網路負載，但卻鮮少提及如何控制使用者端的連線來達到理想中的網路分佈。因此我們將探討以網路的角度控制使用者連線，讓使用者利用最合適的網路傳輸。本文第二節為相關研究；第三節提出我們建議的網路架構及理由分析；第四節用實驗說明網路負載平衡的效果；最後第五節作全文的總結。

2. 相關研究

在這節我們將引述關於如何偵測並判斷網路負載的相關研究，以及使用多重傳輸介面來達到無縫換手的 SHIP，最後提到能確保與應用層維持連線達成移動通透性的 LCT。

2.1 Load Balancing Among WLAN Access Points [10] 關於如何以最客觀的方式測量 AP 的網路負載，Fanglu Guo 等作者 [10] 提到目前主要有三個方法：第一是從後端有線網路的部分測量封包傳送速率，這個方法的缺點在於，計算到的封包是經由 AP 接收，扣除標頭檔、ACK、RTS、CTS…等現實負載後的結果，無法客觀呈現 AP 即時的傳輸情況。第二種方法是去測量 AP 的傳輸速度，此種方法的問題在於沒有考慮到相同頻道會共享頻寬，傳輸速率較低的 AP 可能已達傳輸速度上限。第三種方法則是作者提出的建議，測量頻道閒置時間來判斷 AP 的傳輸負載。之所以使用頻道閒置時間而非忙碌時間的理由，除避免以上兩種缺點之外，還可以避免 Martin Heusse 等作者在 [13] 提到較慢速 STA 佔據大部分傳輸時間的問題。

作者另外提出 WLAN Load Balancer (WLB) 的設計 (如圖 1) ，WLB 連接在 AP 的後端有線網路上，另外再加裝無線網路卡並且開啟射頻監視器模式 (RF monitor mode) ，如此除了可以整合不同 AP 上 STA 的分佈，還可藉由頻道閒置時間的監測，有效找出目前傳輸負載不高的 AP。再利用目前 AP 大都配備的 MAC Address Filtering 的功能，與各個 AP 溝通修改 MAC Address Filtering 的欄位，限制 STA 可連線的 AP，進而控管 AP 的網路負載。

圖 1 WLAN Load Balancer [10]

2.2 Soft Handoff over IP (SHIP) [7]

Soft Handoff over IP (SHIP) [7] 是 Bechir Hamdaoui 等作者提出在 IP 網路下實現無縫換手 (seamless handoff) 的網路架構 (如圖 2)，其中 SHIP Forwarding Agent (SHIP FA) 是建構在後端網路上的路由器，負責資料流的傳送；Access Node (AN) 是無線網路存取點，透過路由器的控管，可在不同網域下同時傳送資料；Mobile Node (MN) 則是有多重介面的移動節點。為確保資料的正確性及考慮同步傳送的問題，SHIP 捨棄複製兩份資料流的方式，採用 Reed–Solomon codes [3] 修正錯誤資料，經由不同介面同時傳遞資料與修正碼，在接收資料的同時進行錯誤修正以達到無縫換手。

圖 2 Soft Handoff over IP [7]

2.3 Local Connection Translation (LCT) [8] 在目前絕大多數關於移動性的相關研究裡，大 都僅考慮 IP 變動及網路端的傳輸方式，Chuanxiong Guo 等作者在 [8] 中提到以點對點使用者的角度，探討多重介面傳輸時隨著 IP 及介面的轉換，使用者端應用層的部分應如何設計以維持連線的穩定及順暢。在多重介面的環境下，首先要面對的問題是如何在 IP 更換之後依然能辨識出原本屬於哪個應用程式的連線，作者提出以點對點傳輸時雙方共享的資訊為參數，計算出一組屬於這個連線的 Connection ID (cid)： cid = HASH(orig_src_addr,orig_src_port,orig_dst_addr, orig_dst_port,protocol,seq,shared_key). 透過這個 cid，即使 IP 更換之後依然可以辨認原本的連線。以此作為搜尋值，加上 socket 傳輸時最主要的五個參數 (five-tuple) ：雙方 IP 位置、雙方連接埠、通訊協定，可架構出 Local Connection Translation (LCT) 的對照表 (如圖 3) 。當收到對方資料時，經由比對即時連線資訊 (current five-tuple) 和 cid，可以找到應用層原本的連線資訊 (original five-tuple)，維持連線穩定；相反的，傳遞資料時則由原本的連線資訊對照找出即時連線資訊。這個方法可以讓應用層使用同一組資訊連線，一旦傳輸介面更動，可由 LCT 自動對應至新的介面傳輸，不會因此中斷連線。

(3)

LCT 同時也支援多路徑傳輸 (multihoming) ，由於一開始即架構在多重介面的環境上，一個連線可以藉由 LCT 的對應，在不同介面上形成 current five-tuple 1、2、3…. n 的連線資訊，同時使用不同介面進行同一個連線的資料傳輸。 圖 3 Local Connection Translation [8]

3. Bandwidth Utilization In cross-Layer

Design (BUILD) Under WLAN

在這一節我們會從研究動機開始，分析架構設計的原因與目前面臨的問題，接著提出我們的主要架構與各部分元件，最後詳述整個架構的運作流程。 3.1 研究動機 在平日會議討論時，常常會使用無線網路瀏覽網頁或下載資料，然而卻經常發現雖然兩台電腦連線至不同 AP，傳輸速度卻依然受到影響；或者在同一間會議室突然有大量使用者連上網路，幾乎所有的人都會選擇到訊號最強的 AP，但是往往訊號次之的 AP 不一定有較慢的傳輸速率。因此我們想到如下圖描述的情境： S-Router Router Router S-Router Internet Internet Mobile Node Access Point Strong Signal Weak Signal Node A 圖 4 使用情境 圖 4 中 Node A 能同時收到兩台 AP 的訊號，如此在網路較為壅塞的時候，是不是可以選擇訊號較弱，但網路負載較輕的 AP 傳輸？而判斷負載的平衡，是否可以交由後端特殊的路由器 (Super Router) 負責，再告知使用者進行切換？為此我們有了以下所述的相關研究分析。 3.2 問題分析 關於如何測量 AP 的傳輸效能用以平衡網路負載的問題，在第二節裡簡單說明了客觀的測量方式及其原因，同時也提到作者使用 MAC Address Filtering 的功能來強迫使用者切換至指定的 AP。這個方法表面上看起來是不需更動 AP 以及 STA 原本的設計，但相對的也等同於要能與目前市面上所有的 AP 溝通來更改 MAC Address Filtering 的欄位，並且在阻擋 STA 連線的同時也可能造成 STA 有訊號卻無法連線的窘境。倘若希望使用者能根據頻寬負載進行有效的切換，單純使用目前 RSSI [4] 的機制是作不到的，不是要與 AP 溝通，就是 STA 仍須有相對應的軟體支援，兩者實乃魚與熊掌的問題，因此我們考慮從 STA 的角度著手。接著需要面臨的問題就是，要如何進行切換？根據 Héctor Velayos 等作者在 [12] 實驗出來的結果，他們將現行無線網路卡切換的過程分為三個步驟 (如表 2)：偵測並判斷連線是否已經不存在、搜尋所有的頻道、實際進行鏈路層的連結。 表 2 無線網路設備切換時間比較 在表中不難發現，目前無線網路設備仍須花大量時間作切換。在僅有一個網路介面的前提下，要改善這個問題有兩個辦法：其一是結合 802.11f [5] 等相關機制加速換手的時間，但是不論怎麼加快換手速度，仍然需要花時間確認訊號降低。其二無非是要去修改無線網路設備底層偵測連線強弱的方式，而我們的目標則是希望能不要更動這個部分，因此我們考慮使用多重網路介面傳輸。使用一張以上的 802.11 無線網路卡其實有相當大的爭議，畢竟成本仍是一大考量，雖然目前已開發 VirtualWiFi [9] 等虛擬網路卡的技術，但最後都會面臨同樣的問題：802.11 標準裡規定一張無線網路卡同一時間只能與一台 AP 連線。因此能做的研究也僅止於類似 TDMA 的方式在 AP 間切換 [9]，或者類似 FDMA 快速切換頻道進行有效利用 [14]，而這些方法的傳輸速率自然無法較單純的無線網路傳輸更為快速，並且時常會有網路停頓的感覺。當然，使用相對應的網路設備應能提高其傳輸速率，但我們希望以不更動現行的網路設備為主。有了以上考量，我們開始評估是否有必要使用多重網路介面傳輸。使用多重網路介面除了可以避免切換後反而失去連線的情況，同時可以使用 SHIP 的架構來確保資料正確性及減少介面切換的延遲時間，並且可以利用 LCT 支援多路徑傳輸加快網路速率，維持應用層的移動通透性，具有相當多的優點。同時在我們的測試下發現，目前在電腦上使用兩張

(4)

802.11 無線網路卡，效果等同於一張。其原因是作業系統會以一個路徑作為主要傳輸介面，無法自然的充分利用兩張網路卡的頻寬。更大的問題是，同一台電腦上不允許有兩個相同的 IP，即便有辦法可以利用這兩個路徑傳輸，要如何判定哪些連線是由同一台電腦發出？基於以上種種疑點，我們決定以多重網路介面的角度來探討。為此我們思索，是否可以透過網路連線的方式來主導傳輸路徑？因而設計出在 WLAN 環境下跨階層的頻寬有效利用機制 (Bandwidth Utilization In cross-Layer Design, BUILD)。

3.3 主要架構

Corresponding Node (CN)

Interface 1 Interface 2 Interface 3

IP 1 IP 2 IP 3

Local Connection Translation (LCT) Authentication Switching Request Data Transmission S-Router

STA

AP1 AP2 AP3

圖 5 Bandwidth Utilization In cross-Layer Design

(BUILD) under WLAN

BUILD 主要的精神是希望能透過 Super Router 的決策，將封包經由最合適的網路介面傳輸。如圖 5，STA 有多重網路介面，每個介面擁有各自的 IP 並且連線至不同的 AP，在認證程序完畢之後，透過 Super Router (S-Router) 的決策，可以對 STA 發出切換傳輸介面的請求，而 STA 則透過 LCT 的對應，在不影響應用程式連線的情況下，使用不同介面傳輸進而達到網路負載的平衡。

Traffic Control Union

Super Router (S-Router) Authentication Union Policy Union Binding Table Tunnel Union Public Network Priv ate N e tw or k Network Communication Internal Relation 圖 6 Super-Router 的元件設計 其中 S-Router (如圖 6) 為 BUILD 裡較為特殊的設計，因此分述如下：

1. Authentication Union (AU)

負責辨識使用者擁有的不同介面網路連線，AU 會將使用者端的 ID、MAC Address、IP…等資訊儲存至 Binding Table 裡，同時通知 PU 作決策，平衡網路負載。

2. Policy Union (PU)

負責決定使用者連線方式，透過 Binding Table 得知使用者擁有的所有網路連線，再經由 TCU 與使用者端的溝通得知最即時的決策資訊，最後透過 TCU 發出更換連線介面的請求，同時通知 TU 更動 IP Tunneling 的資料。 3. Binding Table 負責記錄使用者各裝置與 IP 的對應，以使用者端提供的 ID 為鍵值，對照出使用者擁有的所有介面與 IP，並將此一資訊提供給 PU 作決策。 4. Traffic Control Union (TCU)

負責接收 PU 的指令實際傳遞封包控制網路負載平衡，TCU 會發出詢問封包用以探知不同介面目前的連線狀況交由 PU 裁定，同時可以暫存由 TU 傳來的資料，確保資料不會遺失。 5. Tunnel Union (TU)

負責以 Tunnel 的形式轉送封包至外部網路，隨著介面的更換，需要一個元件負責維持舊有的連線，因此每當 PU 決策更換網路介面的同時，也會通知 TU 改變客戶端 IP 位置，確保連線的穩定。 3.4 封包流程 Tunneling STA Interface1 STA

Interface 2 AP1 AP2 S-Router CN

DHCP_DISCOVER DHCP_OFFER DHCP_REQUEST DHCP_DISCOVER DHCP_OFFER DHCP_REQUEST DHCP_ACK DHCP_ACK Data Transmission Binding Table ID MAC1 Binding Table ID MAC1 MAC2 Binding Table ID MAC1 IP1 MAC2 IP2 圖 7 認證封包流程 圖 7 為辨認同一使用者擁有多重傳輸介面的封包流程，其中 S-Router 本身具有類似 DHCP Server 的功能，STA 本身具有兩個網路介面，可連線至兩個不同 AP 並安裝修改過的 DHCP 客戶端程式。當使用者剛連線上網路時，會發出 DHCP_DISCOVER 的訊息，此時 S-Router 回傳的 DHCP_OFFER 裡會攜帶 option 的資訊，如果 STA 本身有多重傳輸介面，會在 DHCP_REQUEST 的訊息裡攜帶一個辨識

(5)

ID 及所有裝置的數量，其中 ID 是由所有裝置的 MAC Address 運算出來的結果。S-Router 這時會記錄 ID 與發出請求的 MAC Address，當收到使用者另一個裝置傳來的相同 ID 時，經由運算判斷兩個裝置皆屬於同一使用者，此時 S-Router 才會回傳兩個包含租用 IP 的 DHCP_ACK 。不同於以往收到 DHCP_REQUEST 後直接回傳其租用 IP，S-Router 會在一定時間內等到使用者的裝置都與 S-Router 發出詢問後才回應，確保此時兩個介面都可以正常運作。倘若時間內沒有回應，則會依照正常 DHCP 協定分別給予租用 IP 避免無法連線的情形發生。另外在 option 欄位裡亦可攜帶目前的 BSSID，用以解決兩個介面接連線至同一台 AP 的情形。 Tunneling STA Interface1 STA

Interface 2 AP1 AP2 S-Router CN

Data Transmission

Link Quality Detection

Data Transmission LCT Discover Traffic Bottleneck Decide Interface Switching Link Quality Reply

Buffer Packet

Change Binding Policy

Tunnel With New Binding Policy Buffered Packet Update LCT Table

Use New Five -Tuple to Transmit Seamlessly

Interface Switching Request

Interface Switching Response

Transmit Buffered Data

Initial Another Socket for Interface 2 圖 8 介面切換封包流程 圖 8 是使用者在未移動時切換介面的封包傳送流程，LCT 為使用者端負責與應用程式溝通的介面。當 S-Router 察覺網路負載不平衡的情形，會嘗試發出偵測連線品質的封包給使用者的其他介面，在確認網路狀況穩定的前提下，S-Router 才會發出切換介面的訊息，同時再另外開啟一個網路 socket 準備接收來自第二個介面的連線。STA 接收到切換訊息後，透過 LCT 的更新，會改由另外一個介面回傳得知連線建立的消息，並開始傳輸資料。在這段期間 S-Router 會協助暫存資料，這是為了避免當發覺舊的連線不穩定而切換之時便已無法傳輸的情況，若是先前網路介面仍有傳輸能力則直接由先前網路負責傳輸剩餘的封包。至於移動時的情形，因篇幅限制在此不加詳述，大意是使用者移動時，可以使用兩個介面連線類似 SHIP 的方式進行無縫換手。

4. 測試及分析

實驗裡我們僅初步針對網路頻寬有效利用的部分作測試，我們使用兩台 802.11b 的 AP 個別運作在頻道 1 與頻道 11，同時使用兩台筆記型電腦，各用一張無線網路卡監聽網路傳輸的負載，再用另一張無線網路卡來傳輸，即總共有 4 張無線網路卡在使用，軟體部分則選擇 AiroPeek NX 作為分析及繪圖之用。 700 kb 600 kb 500 kb 400 kb 300 kb 200 kb 100 kb 0 5 10 15 20 25 30 35 40 45 50 60 (sec) (byte/ sec) 圖 9 頻寬利用流量分析圖 圖 9 裡採用頻道掃瞄的方式進行監聽，每隔 5 秒監聽不同的頻道。一開始連線 A 在頻道 1 的 AP 下傳輸資料， 25 秒時另加入一組連線 B 至頻道 11。圖中 5 秒至 10 秒的部分顯示頻寬已達最高速接近 700 k byte/sec，在 10 秒到 15 秒的地方則因為連線 B 尚未建立，所以僅有少量資料。由於我們是在真實環境下測試，因此在頻道裡同時還會有其他 AP 發出的 Beacon 等雜訊。在 30 秒的地方可以發現，原本沒有資料傳輸的頻道 11 因加入連線 B 後傳輸量達到最高，並且在之後的連線裡發現兩者皆能以最高的速度傳輸，由此可證明妥善配置網路連線可以充分利用頻寬。根據我們實驗的結果，兩者使用的頻道不能太過接近，推測在現實環境下會有實體層電波互相干擾的情況，導致兩個傳輸都變的極不穩定。 700 kb 600 kb 500 kb 400 kb 300 kb 200 kb 100 kb 0 5 10 15 20 25 30 35 40 45 50 60 65 70 (byte/ sec) (sec) 圖 10 頻道重疊流量分析圖 圖 10 裡同時使用了兩種監聽，其一是類似圖 9 在頻道 1 與頻道 11 間切換，在圖中表示為顏色較深的重疊部分及顏色最淺的中央。其二是是單純只針對我們想要改善位於頻道 1 的連線 A 做監聽，在圖中為背景深淺居中的色塊。在 25 秒的時候我們在頻道 1 加入了另一組連線 B，此時 A、B 皆連線至

(6)

頻道為 1 的 AP。在 25 秒至 30 秒時可以看出連線 A 的傳輸受到了影響，落為原本速率的一半，起因為連線 B 正和它共同分享頻寬。在 30 秒至 35 秒的時候，此時第一種切換頻道的監聽剛好切換至頻道 1，因此觀測到的最大速率仍為 700 kb，差別在於此時已不完全是連線 A 的傳輸，有一半被連線 B 佔據。在 40 秒的時候我們把連線 B 切換至頻道 11，因此連線 A 又回復到如先前 10 秒至 15 秒的 700kb 傳輸速率，而在 45 秒到 50 秒監聽的是頻道 11，同時也是連線 B 的頻寬，我們可以發現連線 B 也能有效利用頻道 11 的頻寬。之所以沒辦法達到 700 kb 的最大傳輸速率，我們推測由於當下有四張網路卡同時在運行，因此無法很精確的量測傳輸，或者有電波的影響導致無法達到最高速傳輸，但我們仍能由圖中發現，分配過後的連線能確實有效的利用現有頻寬傳輸。

5. 結論

這篇論文提出以多重傳輸介面為主在 WLAN 環境下跨階層的頻寬有效利用機制--BUILD，嘗試以多個傳輸介面來解決目前無法有效利用無線網路頻寬的問題，針對諸多網路負載平衡的演算法提出實際運行的架構，同時利用 DHCP 的傳輸協定來辨認同一使用者所擁有的多個網路傳輸介面，進而銜接未來異質網路傳輸。 BUILD 可配合 SHIP、LCT 等研究來達到無縫換手與解決傳輸介面變更後與軟體應用層如何維持連線的問題，同時不需修改底層偵測與判斷連線強度的設定，僅需搭配修改過的 DHCP 客戶端連線至 S-Router 就能以網路的角度來控制傳輸介面的選取，充分利用現有網路頻寬。相較於單一介面的網路傳輸，BUILD 提供了另一種思維，多個網路介面傳輸時會有什麼樣的問題？是否能很直觀的透過兩個介面傳輸？在變動網路介面時應如何確保連線穩定及判定是否為同一使用者建立的連線？本文針對這些問題作了一些探討，相信在未來網路環境下仍有相當發展空間。

誌謝

本論文由國科會計畫所補助，計畫執行編號為 NSC 95-2219-E-194 -005。

參考文獻

[1] http://www.nici.nat.gov.tw/content/application/nici/ general/guest-cnt-browse.php?cnt_id=371 [2] http://www.tribecaexpress.com/Cisco_aironet_AP3 50.htm [3] http://www.4i2i.com/reed_solomon_codes.htm [4] IEEE Std 802.11, Wireless LAN Medium Access

Control (MAC) and Physical Layer (PHY) specifacations, 1999.

[5] IEEE Std 802.11F, Trial-Use Recommended

Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11™ Operation, 2003.

[6] A. Balachandran, P. Bahl and G. M. Voelker, “Hot-Spot Congestion Relief in Public-area Wireless Networks,“ In Proceedings of IEEE WMCSA'02, June 2002.

[7] B. Hamdaoui and P. Ramanathan, “A Network-Layer Soft Handoff Approach for Mobile Wireless IP-Based Systems,” IEEE Journal On Selected Areas In Communications, VOL. 22, NO. 4, May 2004.

[8] C. Guo, Z. Guo, Q. Zhang and W. Zhu, “Seamless and Proactive End-to-End Mobility Solution for Roaming Across Heterogeneous Wireless Networks,” IEEE Journal On Selected Areas In Communications, VOL. 22, NO. 5, June 2004. [9] C. Ranveer, B. Paramvir, B. Pradeep, "MultiNet:

Connecting to Multiple IEEE 802.11 Networks Using a Single Wireless Card" In Proceedings of IEEE INFOCOM, March 2004.

[10] F. Guo and T. Chiueh, ``Scalable and Robust WLAN Connectivity Using Access Point Array,'' in Proceedings of 2005 International Conference on Dependable Systems and Networks (DSN 2005), June 2005.

[11] H. Lee, S. Kim, W Ryu and C. Yoon, “Performance of an efficient method for association admission control in public wireless LAN systems,” IEEE Vehicular Technology Conference, Vol. 7, pp. 5049 - 5053,Sept. 2004.

[12] H. Velayos and G. Karlsson, “Techniques to Reduce IEEE 802.11b Handoff Time,” IEEE International Conference on Communication (ICC), June 2004.

[13] M. Heusse, F. Rousseau, G. Berger-Sabbatel, and A. Duda, “Performance anomaly of 802.11b,” In Proceedings of IEEE INFOCOM, April 2003. [14] P. Bahl, R. Chandra, and J. Dunagan, "SSCH:

Slotted seeded channel hopping for capacity improvement in IEEE 802.11 ad-hoc wireless networks," in Proceedings of ACM MOBICOM, Sept. 2004.

[15] Y. Xiao and J. Rosdahl, “Performance Analysis and Enhancement for the Current and Future IEEE 802.11 MAC Protocols,” ACM SIGMOBILE Mobile Comp. and Comm. Review, vol. 7, no. 2, pp. 6--19, April 2003.

[16] Y. Bejerano, S Han and Li (Erran) Li, “Fairness and Load Balancing in Wireless LANs Using Association Control,” ACM Annual International Conference on Mobile Computing and Networking (MOBICOM), page 315 ~ 329, September 2004.