<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 手機(jī)與無線通信 > 設(shè)計(jì)應(yīng)用 > 鄰信道干擾(ACI)的來源以及射頻設(shè)計(jì)實(shí)踐

          鄰信道干擾(ACI)的來源以及射頻設(shè)計(jì)實(shí)踐

          作者: 時(shí)間:2012-09-19 來源:網(wǎng)絡(luò) 收藏

          圖4顯示了超外差接收機(jī)架構(gòu)的過濾可以將降低至可接受的級(jí)別。在至少具有20dB數(shù)字相鄰過濾的條件下,超外差接收機(jī)在不增加分組誤差率的情況下每秒能夠接收11兆位(Mbps)CCK或22MbpsPBCC802.11Wi-Fi信號(hào)。

          本文引用地址:http://www.ex-cimer.com/article/153908.htm

            如果采用DC架構(gòu),去除了中頻(IF)上的聲表面波(SAW)濾波器,從而導(dǎo)致接收機(jī)鏈路中A/D轉(zhuǎn)換器上的信號(hào)是40dB,高于可接受的程度。采用A/D上的過采樣與回遞抽取過濾(recursivedecimationfiltering),仍然可以恢復(fù)802.11信號(hào)。例如,GSM接收機(jī)使用DC架構(gòu),并且通過在大約26MHz上過采樣大約300KHz的帶寬GSM信號(hào)提供大約80dB的ACR。不幸的是,由于技術(shù)的局限性與電池供電產(chǎn)品的低功耗要求,過采樣所采用的信號(hào)幾乎百分之百都是像GSM信號(hào)這樣的窄帶信號(hào),不可能是像802.11信號(hào)那樣的寬帶信號(hào)。

            下面的圖5顯示了在A/D轉(zhuǎn)換器上強(qiáng)的效果。高級(jí)別的導(dǎo)致產(chǎn)生在802.11的SIR中占據(jù)主導(dǎo)地位的噪聲層,從而由于造成要處理大氣噪聲與量化而削弱了WLAN信號(hào)的強(qiáng)度。

            對(duì)于已經(jīng)實(shí)施OFDM調(diào)制方案的WLAN來說,從一個(gè)頻率接收器到另一個(gè)頻率接收器的往返傳輸過程中,接收機(jī)鏈路中的快速傅里葉變換(FFT)已經(jīng)有所損耗。從而導(dǎo)致帶外抑制層平均大約為25dB。圖6解釋了每個(gè)FFT接收器的SinX/X響應(yīng)。

            接收機(jī)

            雖然已經(jīng)超出了本白皮書探討的范圍,但是值得一提的是802.11接收機(jī)鏈路中的ACR過濾可以降低功耗,因?yàn)榛鶐幚砥髦蠥/D的采樣速率會(huì)有所下降。為了滿足防混淆的要求,將加重其他模擬過濾的負(fù)擔(dān),而不是以更高的速率進(jìn)行采樣。在5GHz頻帶所謂的全頻段中,這種防混淆的問題尤為關(guān)鍵,因?yàn)檫@些的前端是將近1GHz頻寬的信號(hào)。這就意味著為接收機(jī)鏈路中的A/D轉(zhuǎn)換器提供數(shù)百兆赫的頻譜。包含在此信號(hào)中的可以是高功率脈沖雷達(dá)信號(hào),該信號(hào)將在接收機(jī)鏈路中占據(jù)主導(dǎo)地位。

            到目前為止,匯聚已經(jīng)成為電子領(lǐng)域的主要趨勢(shì)。在手機(jī)與PDA市場中,這意味著匯聚的手持終端、智能電話、無線PDA多媒體設(shè)備,其中包括三種無線技術(shù):蜂窩技術(shù)、802.11Wi-FiWLAN與藍(lán)牙。很多專家預(yù)測,具有成本優(yōu)勢(shì)的匯聚設(shè)備在2004年就將問世。這種新型的移動(dòng)手持終端將側(cè)重MP3音樂、視頻流等多媒體應(yīng)用。為了提供引人注目的用戶體驗(yàn),這些新型設(shè)備必須能夠充分利用由新一代蜂窩協(xié)議與基礎(chǔ)設(shè)施提供的更高數(shù)據(jù)速率高速WLAN連接。無線藍(lán)牙耳機(jī)及其他類型的外設(shè)將為這些設(shè)備的便捷性與易用性增色不少。

            藍(lán)牙與WLAN共存的問題

            圖7解釋了在WLAN熱點(diǎn)中如何使用這類設(shè)備。在這種情形中,用戶可以通過WLAN在IP語音(VoIP)連接上進(jìn)行通信或可以通過設(shè)備的802.11調(diào)制解調(diào)器下載MP3或視頻流。此外,匯聚的設(shè)備還可以與藍(lán)牙耳機(jī)相連,以便進(jìn)行專用監(jiān)聽。

            圖7中描繪的這種使用情況不久就會(huì)出現(xiàn)于市場,但是用戶需要共存的解決方案才能充分利用此應(yīng)用中的所有無線技術(shù)。由于匯聚蜂窩電話/PDA設(shè)備中的藍(lán)牙與WLAN調(diào)制解調(diào)器是在同一無許可限制的頻帶中運(yùn)行的,因此它們會(huì)彼此相互。此外,該區(qū)域中的其他802.11客戶端設(shè)備也將競相訪問作為匯聚蜂窩電話/PDA的同一WLAN接入點(diǎn)。

            在當(dāng)前藍(lán)牙標(biāo)準(zhǔn)1。0版本中指定的唯一共存解決方案需要藍(lán)牙與WLAN共享系統(tǒng)的媒體接入控制器(MAC)功能,以便在WLAN或藍(lán)牙的傳輸過程中,其他技術(shù)將保持空閑。在預(yù)定義的一段時(shí)間內(nèi)獨(dú)占MAC之后,藍(lán)牙或WLAN將由其他技術(shù)對(duì)MAC進(jìn)行控制。

            在WLAN上的流量較小,并且存在最少Q(mào)oS激活的環(huán)境中,這種MAC時(shí)間共享的安排方式既可以避免WLAN與藍(lán)牙之間出現(xiàn)共存問題,同時(shí)也能夠提供可接受的性能。在這種環(huán)境中,WLAN接入點(diǎn)可以實(shí)施主動(dòng)的自動(dòng)請(qǐng)求協(xié)議,以重新傳輸丟失或延遲的包。不幸的是,隨著高級(jí)節(jié)能技術(shù)的部署及QoS服務(wù)的需求猛增,將迅速降低WLAN接入點(diǎn)(AP)單元中的性能。

            例如,WLAN與藍(lán)牙共存的形勢(shì)越來越嚴(yán)峻,導(dǎo)致802.11AP無法感測相關(guān)的客戶端是否正在遭受來自藍(lán)牙設(shè)備或無繩電話的非WLAN干擾。采用排隊(duì)算法或調(diào)度例程對(duì)需要QoS功能的應(yīng)用對(duì)AP進(jìn)行編程并不會(huì)緩解帶內(nèi)干擾的問題,因?yàn)锳P并不能意識(shí)到干擾是否存在,因此根本無法圍繞干擾進(jìn)行調(diào)度。

           即使AP具備802.11的自動(dòng)響應(yīng)隊(duì)列(ARQ)功能,鏈路的容錯(cuò)能力也只能夠達(dá)到5%。隨著接近并超過這一個(gè)百分點(diǎn),必須增加AP上的包隊(duì)列大小,以便它們能夠存儲(chǔ)與重新匯編零星達(dá)到的包。通常需要QoS功能的多媒體應(yīng)用(如高質(zhì)量音頻或MPEG2視頻)很快就背離了802.11標(biāo)準(zhǔn)對(duì)QoS的定義。作為一個(gè)備選方案,將從需要QoS的鏈路中刪除ARQ,在這種情況下,語音性能會(huì)稍有改進(jìn),具有低于2%的可接受包誤差率,但是任何種類的媒體流的性能都是不可接受的。

            切記在傳輸模式中,WLAN客戶端只使用802.11WLAN很小一部分帶寬。根據(jù)典型的經(jīng)驗(yàn)法則,80%客戶端的活動(dòng)WLAN時(shí)間用來進(jìn)行接收,而只有20%的時(shí)間用來進(jìn)行傳輸。在進(jìn)行傳輸時(shí),客戶端通常向AP發(fā)送簡短的確認(rèn)包。此法則的例外情況是從客戶端進(jìn)行文件傳輸,但是在這些文件在傳輸過程中始終要被劃分為不超過1,500字節(jié)的包,并且以可用比特速率(ABR)進(jìn)行傳輸。

            通過對(duì)圖7中列舉的匯聚WLAN/藍(lán)牙PDA示例應(yīng)用此信息與802.11操作的其他特點(diǎn),得出的結(jié)論是在適度加載WLANAP的環(huán)境中需要同時(shí)進(jìn)行WLAN與藍(lán)牙操作。對(duì)此狀態(tài)的具體分析如下。

            在圖7中列舉的與無線PDA相連的藍(lán)牙耳機(jī)最多具有700Kbps的鏈接帶寬,并不帶有協(xié)議開銷。如果PDA的用戶從Internet上的服務(wù)器播放MP3音頻流文件,那么此應(yīng)用將需要大約128Kbps的藍(lán)牙帶寬,而總藍(lán)牙帶寬為700Kbps。藍(lán)牙信號(hào)在空中傳輸?shù)臅r(shí)間占18%。與此相比,相同的應(yīng)用只使用128Kbps的PDAWLAN帶寬,而總帶寬為11Mbps。此外,802.11操作將涉及確認(rèn)的傳輸(ACK),同時(shí)接收MP3流。這些ACK的數(shù)量相當(dāng)于WLAN帶寬的1/16。也就是說,客戶端執(zhí)行802.11傳輸只需花費(fèi)不到0。1%的時(shí)間。

            如果WLAN與藍(lán)牙傳輸阻塞或彼此干擾,那么藍(lán)牙將對(duì)WLAN傳輸造成18%的時(shí)間干擾,因?yàn)樗{(lán)牙需要在空中傳輸也需相同長度的時(shí)間。反過來,WLAN傳輸將對(duì)藍(lán)牙傳輸造成不到1%的時(shí)間干擾。從而導(dǎo)致的結(jié)果是:加載適當(dāng)數(shù)量的AP時(shí),必須進(jìn)行藍(lán)牙傳輸,同時(shí)接收WLAN信號(hào),簡言之,必須同時(shí)運(yùn)行PDA的藍(lán)牙與WLAN功能。

            但是問題隨之而來:在采用WLAN與藍(lán)牙技術(shù)的匯聚設(shè)備中,WLAN是否能夠從AP不斷接收下載內(nèi)容,而不必考慮該設(shè)備藍(lán)牙子系統(tǒng)的操作模式?經(jīng)過對(duì)藍(lán)牙實(shí)施制定仔細(xì)的、規(guī)劃與部署決策,答案是肯定的。首先,人員必須利用藍(lán)牙1。2的功率控制(第3類設(shè)備)功能,藍(lán)牙的自適應(yīng)跳頻(AFH)。下面的圖8展示了AFH如何避免與WLAN操作發(fā)生直接的帶內(nèi)干擾。

            如果系統(tǒng)要部署功率控制技術(shù),那么將按比例降低接收機(jī)鏈路中LNA上的藍(lán)牙功率,以便使邊帶能量級(jí)別落在2.4GHz頻帶內(nèi),而不必考慮ACR過濾。預(yù)計(jì)藍(lán)牙信號(hào)將達(dá)到-40到-50dBm的傳播損失。從而使藍(lán)牙傳輸?shù)墓β试?25dBm至-15dBm范圍內(nèi),以便保持鏈路中的低誤差率。圖9解釋了功率控制技術(shù)如何降低藍(lán)牙中的頻譜發(fā)送。

            檢查具有藍(lán)牙與802.11,以及其他一些操作特點(diǎn)的手持終端設(shè)備進(jìn)一步說明了共存的問題。在此示例中,假設(shè)手持終端設(shè)備具有一個(gè)0dBm藍(lán)牙發(fā)送器與一個(gè)802.11接收機(jī),具有以下性能之一:

            1)功率控制技術(shù)可以提供在藍(lán)牙與WLAN之間20dB的隔離。

            2)在藍(lán)牙與802.11之間存在0dB的隔離,但是系統(tǒng)能夠在RF接收機(jī)鏈路中斷開LNA。系統(tǒng)并不具有功率控制功能。

            為了簡便起見,在此討論的內(nèi)容將局限在采用超外差架構(gòu)的接收機(jī)設(shè)計(jì)。圖10展示了接收機(jī)可以運(yùn)行的情形之一。在上述的第一種情況中,設(shè)備的藍(lán)牙與WLAN之間存在20dB的隔離,那么接收機(jī)必須具有至少15dB的數(shù)字過濾。在第二種情況中,藍(lán)牙與WLAN之間不存在隔離,因此必須具有30dB的過濾和數(shù)字增益。針對(duì)第二種情況,還可以選擇將接收機(jī)限制在大約大于-60dBm的802.11信號(hào)上,其中對(duì)專門的過濾沒有任何要求。



          評(píng)論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();