无线论坛 门户 技术和理论 无线研究者 查看内容

保护机制:避免无线混合网络冲突

2008-9-4 13:24| 查看: 812| 评论: 0|原作者: |来自: Anywlan

2003年6月12日,IEEE正式通过了802.11g draft 8.2,使之成为正式标准。在正式标准中,原本位于11g 草案6.1版附录E中的在混合环境下(11b+g)采用保护机制的指导性的建议,被加入到了正式标准第9.10节,成为了标准的一个组成部分。

那么,什么是保护机制呢?其实,所谓的保护机制并不是新的技术,它只是采用CTS/RTS来避免冲突的一种方法。早在802.11的规范内,就已经定义了CTS/RTS,只不过在802.11/11b中,这只是作为一个可选项,并不一定需要。各个厂商也往往在其产品中,默认不启用这种机制。

CTS/RTS全称Clear to send/Request to send,是两种特殊的管理数据帧,并不承载数据。当启用CTS/RTS时,每个WLAN节点,在获得了媒介使用权后要发送数据之前,都要发送CTS,宣告自己将要占用媒介一段时间x,所有听到这个宣告的WLAN节点,无论媒介中是否真正有数据在发送,都会静候x时间,以避免冲突。当AP收到CTS的时候,会发送RTS,再次通知其管辖范围内的所有节点,媒体将要被占用x时间。

采用了CTS/RTS机制的好处是,避免了WLAN中的冲突。因为冲突会导致数据包的丢失,丢失数据的节点需要重发数据包,这还可能引致下一轮冲突,从而严重影响到网络的运行效率。CTS/RTS的另外一个好处是解决了隐藏节点的问题,从而进一步减小了发生冲突的可能性。

不过,CTS/RTS机制也给网络的运行带来了额外的开销,因为每发送一个数据包之前都要发送额外的两个管理数据包,虽然这两个数据包都比较小,但也给原本就不快的无线网络增加了很多负担。当网络中传输的是数量众多但尺寸都很小的数据包的时候,这种额外的负担就变得尤其沉重,甚至会使得网络运行效率下降到原先的1/3!

有鉴于此,CTS/RTS在传统的802.11b网络中,只是作为一个可选项,并且可以设定一个阈值,当数据包的大小超过这个阈值时,才使用CTS/RTS。

在802.11b+g的混合网络中,为什么要使用保护机制呢?我们知道,802.11g采用的是CCK/OFDM的调制方式,传输数据时采用OFDM以实现其高达54Mbps的速率,而802.11b则是使用CCK编码来调制的。因此,在802.11g的网络中,11g的节点可以听懂11b节点,知道11b节点正在发送数据;但是11g节点发送数据时是采用OFDM方式,11b节点并不知道。因此,11g节点在发送数据时,11b节点会以为网络空闲,也发送数据,造成冲突和数据丢失,影响到网络性能。在发送正式数据之前,用11b和11g节点都懂的CCK来发送CTS/RTS来宣告网络占用,可以避免冲突的发生。

打个比方来说明这个问题,假设在一个圆桌会议(WLAN)上,有两个国家的代表,英国代表(11b)和阿拉伯代表(11g),一个时间只能有一个代表发言,如果有两个代表发言,则没人能听清任何代表的发言(这说明不能冲突的机制)。为了保证不冲突,会议规定每位代表发言前,必须首先告诉大家,自己将发言多少时间(NAV),那么在接下去的时间内,其他代表都会静候这段时间(VCS机制)。会场上的英国代表只会说英语(CCK),而阿拉伯代表则懂双语——阿拉伯语(OFDM)和英语(CCK)。阿拉伯语(OFDM)是一种说起来非常快的语言,可以比英语快4倍,因此为了提高效率,特别要求阿拉伯代表在正式发表长篇大论的时候必须说阿拉伯语(OFDM)。可是阿拉伯代表告诉大家自己要发言多少时间也用的是阿拉伯语(OFDM),英国代表(11b)不懂,怎么办?因此会场制订了一个规则(保护机制),规定所有的代表发言之前,都要首先用英语(CCK)发布一个宣告(CTS),告诉与会代表他将要发言的时间。这个宣告往往还会由会议主持人重复一遍(RTS),因为他有麦克风,可以传到会场的每个角落,不会有任何代表听不到。

采用了保护机制之后,11b和g混合网络中的冲突问题就得到了解决。这就是为什么11g标准定稿会把这个保护机制添加在其中的原因。早在802.11g正式标准发表之前,Intersil 在其11g芯片中就已经采用了Nitro技术,已经包含了这种保护机制。因此,使用Intersil Prism GT芯片组的SMC Networks 的g系列产品也早在今年5月就已经支持了这种保护机制。


高人

专业

握手

霸气

雷人

吐血

山寨

奋斗

最新评论

文章栏目
论坛新贴
今日热议
本周排行
最新文章

站点统计 | Archiver | 手机版 | 无线门户 ( 粤ICP备11076993号|粤公网安备44010602008359号 ) |网站地图

GMT+8, 2024-5-5 00:06

返回顶部