基于逐跳最晚離開時(shí)刻的點(diǎn)協(xié)調(diào)無線媒介接入控制方法
發(fā)布時(shí)間:2020-12-25 03:37
IEEE 802.11無線局域網(wǎng)標(biāo)準(zhǔn)在構(gòu)建無線寬帶計(jì)算環(huán)境中起著非常重要的作用。同時(shí),多媒體應(yīng)用在迅猛發(fā)展。然而,多媒體應(yīng)用需要QoS的支持,比如帶寬、時(shí)延、抖動和誤碼率的保障。無線網(wǎng)絡(luò)的傳輸介質(zhì)是共享信道的,MAC層對QoS的保障起著非常關(guān)鍵的作用。但由于無線傳輸時(shí)延動態(tài)性和路由跳數(shù)不同等原因,802.11無線局域網(wǎng)要保障QoS的需求是一個很大的挑戰(zhàn)。因此,研究和改進(jìn)IEEE 802.11 MAC層協(xié)議,使其滿足QoS需求,是很有意義的。IEEE 802.11的基本模式是DCF,此外還有基于輪詢的PCF模式,IEEE 802.11沒有對QoS的支持。為了增強(qiáng)QoS的支持,IEEE委員會提出了IEEE 802.11e,根據(jù)業(yè)務(wù)類別的不同而有不同的傳輸優(yōu)先級,有EDCA和HCCA兩種模式。但I(xiàn)EEE 802.11e有服務(wù)類型受限、擴(kuò)展性不好、不能適應(yīng)路由路徑多樣和跳數(shù)各異的情況以及會導(dǎo)致低優(yōu)先級業(yè)務(wù)的饑餓等缺點(diǎn)。本文提出了一種PCF模式的解決方案,基于逐跳最晚離開時(shí)刻的PCF MAC協(xié)議。區(qū)別于傳統(tǒng)的端到端最晚離開時(shí)刻,采用單跳的最晚離開時(shí)刻來衡量數(shù)據(jù)幀的緊急程度。接著,為了讓一次輪詢,...
【文章來源】:華南理工大學(xué)廣東省 211工程院校 985工程院校 教育部直屬院校
【文章頁數(shù)】:60 頁
【學(xué)位級別】:碩士
【部分圖文】:
鏈路多樣S123D4
基本DCF
隱藏站點(diǎn)問題是指一個站點(diǎn)在發(fā)送數(shù)據(jù)時(shí),接收方可以監(jiān)聽到,但其他要發(fā)送數(shù)據(jù)的站點(diǎn)不能監(jiān)聽到。當(dāng)其他站點(diǎn)也發(fā)送數(shù)據(jù)給相同接收方時(shí),就會發(fā)生沖突碰撞。為了解決隱藏站點(diǎn)問題,提出了一個可選的 RTS/CTS 方案。源站點(diǎn)在傳輸數(shù)據(jù)之前,先發(fā)送一個短的 RTS 幀(20 bytes),如圖 2-2 所示[29],然后如果目的站點(diǎn)如果確實(shí)收到了RTS 幀,就回復(fù)一個 CTS 幀(14 bytes)。源站點(diǎn)收到 CTS 幀后,才開始發(fā)送數(shù)據(jù)幀。所以,所有在同一 BSS 的其他站點(diǎn)聽到 RTS、CTS 或者數(shù)據(jù)幀后,就更新各自的 NAV以及不會在 NAV 計(jì)時(shí)器清零之前發(fā)送數(shù)據(jù)。因?yàn),短?RTS 或者 CTS 幀碰撞的代價(jià)遠(yuǎn)小于數(shù)據(jù)幀(多達(dá) 2346 bytes)發(fā)生碰撞,所以 RTS/CTS 方案在很多場景下極大地提高了基本 DCF 模式的性能。當(dāng)數(shù)據(jù)幀很短時(shí),發(fā)送 RTS/CTS 幀的開銷就不可忽視了,這樣信道就沒有得到充分地利用。此外,跟短幀相比,長幀出現(xiàn)無法糾正的錯誤時(shí)所造成帶寬和傳輸時(shí)間的浪費(fèi)也更多。所以,采用了一個最優(yōu)化參數(shù) 分片門限值(fragmentation_threshold)。當(dāng)數(shù)據(jù)幀的大小超過分片門限值時(shí),這個數(shù)據(jù)幀就會分為幾個短的 MAC 層幀。
本文編號:2936882
【文章來源】:華南理工大學(xué)廣東省 211工程院校 985工程院校 教育部直屬院校
【文章頁數(shù)】:60 頁
【學(xué)位級別】:碩士
【部分圖文】:
鏈路多樣S123D4
基本DCF
隱藏站點(diǎn)問題是指一個站點(diǎn)在發(fā)送數(shù)據(jù)時(shí),接收方可以監(jiān)聽到,但其他要發(fā)送數(shù)據(jù)的站點(diǎn)不能監(jiān)聽到。當(dāng)其他站點(diǎn)也發(fā)送數(shù)據(jù)給相同接收方時(shí),就會發(fā)生沖突碰撞。為了解決隱藏站點(diǎn)問題,提出了一個可選的 RTS/CTS 方案。源站點(diǎn)在傳輸數(shù)據(jù)之前,先發(fā)送一個短的 RTS 幀(20 bytes),如圖 2-2 所示[29],然后如果目的站點(diǎn)如果確實(shí)收到了RTS 幀,就回復(fù)一個 CTS 幀(14 bytes)。源站點(diǎn)收到 CTS 幀后,才開始發(fā)送數(shù)據(jù)幀。所以,所有在同一 BSS 的其他站點(diǎn)聽到 RTS、CTS 或者數(shù)據(jù)幀后,就更新各自的 NAV以及不會在 NAV 計(jì)時(shí)器清零之前發(fā)送數(shù)據(jù)。因?yàn),短?RTS 或者 CTS 幀碰撞的代價(jià)遠(yuǎn)小于數(shù)據(jù)幀(多達(dá) 2346 bytes)發(fā)生碰撞,所以 RTS/CTS 方案在很多場景下極大地提高了基本 DCF 模式的性能。當(dāng)數(shù)據(jù)幀很短時(shí),發(fā)送 RTS/CTS 幀的開銷就不可忽視了,這樣信道就沒有得到充分地利用。此外,跟短幀相比,長幀出現(xiàn)無法糾正的錯誤時(shí)所造成帶寬和傳輸時(shí)間的浪費(fèi)也更多。所以,采用了一個最優(yōu)化參數(shù) 分片門限值(fragmentation_threshold)。當(dāng)數(shù)據(jù)幀的大小超過分片門限值時(shí),這個數(shù)據(jù)幀就會分為幾個短的 MAC 層幀。
本文編號:2936882
本文鏈接:http://sikaile.net/kejilunwen/wltx/2936882.html
最近更新
教材專著