《EV-DO實驗網(wǎng)簡介.ppt》由會員分享，可在線閱讀，更多相關《EV-DO實驗網(wǎng)簡介.ppt（59頁珍藏版）》請在裝配圖網(wǎng)上搜索。

目錄 1 試驗網(wǎng)的規(guī)模與地點試驗網(wǎng)的目的測試工具與計算機的設置測試項目計算機模擬結(jié)果測試結(jié)果結(jié)論 2 試驗網(wǎng)的規(guī)模與地點 試驗網(wǎng)1 地點 Whippany站數(shù) 2個基站試驗網(wǎng)2 地點 美國中部和東部站數(shù) 8 10個基站 3 證明EV DO系統(tǒng)的功能和算法證明其系統(tǒng)符合IS 856標準 試驗網(wǎng)的目的 4 測試工具與計算機的設置 測試工具 測試工具 Chester Chester byQualcomm試驗時Chester出現(xiàn)的早期版本 ver 3 0 xx 試驗至今已有一些新的升級雙根天線 或單根天線 5 6 Chester技術指標 1 7 Chester技術指標 2 8 Chester技術指標 3 9 測試工具 EV DoCait 10 測試工具與計算機的設置 計算機的設置 TCPWindowSize 16kBTCP IPHeader a k a VanJacobson Compression OFFPPPSoftwareCompression OFFTCPSelectiveACK ONTCPTimeStamping OFF 11 測試項目 覆蓋測試切換測試連接測試 掉話率 接入失敗率 單用戶定點吞吐量測試多用戶定點和慢速吞吐量測試多用戶移動吞吐量測試Schedule測試 在Whippany 以及全球其它8個地方試驗站從2 3個增加至30個測試區(qū)域城區(qū) 郊區(qū)地貌包含山地和平原具有多樣的傳輸環(huán)境測試基于1 9GHzIS 95 1Xoverlay的網(wǎng)絡上展開優(yōu)化工作類似于IS 95 1X優(yōu)化主導頻 12 測試結(jié)果 試驗網(wǎng)的基本情況 系統(tǒng)完全符合IS 856標準所用Chester終端的情況 ver 3 0 46 在良好的RF環(huán)境下部分前向數(shù)據(jù)丟失RLPbug 無NAKrequests MDSPHaltbug 暫停應用現(xiàn)象 Chestersver 3 2 以上版本有很多改進試驗表明只有高性能的數(shù)據(jù)骨干網(wǎng)才能使1xEV的先進性得到最大體現(xiàn)減少丟失數(shù)據(jù)包降低延遲 13 測試中的幾點說明 測試結(jié)果 實例 WhippanyRd NJ 14 手機接收功率 手機接收功率和發(fā)射功率 SNR 15 前向和反向數(shù)據(jù)速率和PER 16 前向鏈路和反向鏈路請求速率隨著RF環(huán)境的變差而降低 直到最低速率請求前反向鏈路維持在1 的PER單扇區(qū)空載測試 前反鏈路速率平衡前反鏈路出現(xiàn)幾秒斷開 路徑損耗 160dB 空載測試單扇區(qū)前向覆蓋不變單扇區(qū)反向覆蓋擴展 約5dB在多個扇區(qū)下 前向覆蓋更好覆蓋受限于反向鏈路反向鏈路實際結(jié)果類似3G 1X結(jié)果支持1 1overlay1xEVon3G 1X前向鏈路吞吐量時常大于物理層請求的速率ARQGain IncrementalRedundancy 300kbps速率4slots的傳輸請求可由1 3slots完成 17 由前頁曲線可見 覆蓋邊界受距離和路徑損耗影響單根和雙根天線接入終端移動速率 靜止 步行 車載 測試路線用不同行駛速度 靜止和步行 5mph 低速 20 30mph 高速 30 70mph 合并的情況分別測試單根和雙根天線測試從基站近點向外呈輻射狀路線至到掉話用不同的行駛路線比較評估路徑損耗 18 測試結(jié)果 1 覆蓋測試 路徑損耗 19 Yellow HataUrbanpredictionRed HataSuburbanprediction 1 000 2 000 3 000 5 000 10 000 Distance m 40 60 100 80 120 140 160 180 PathLoss dB DRC速率與路徑損耗的關系 20 PathLoss dB 0 500 1000 1500 2000 2500 3000 120 125 130 135 140 145 150 155 160 165 DRCRequestedrate kbps 0 500 1000 1500 2000 2500 3000 120 125 130 135 140 145 150 155 160 165 DRCRequestedrate kbps LowSpeed0 30mph HighSpeed30 70mph 21 0 500 1000 1500 2000 2500 3000 120 125 130 135 140 145 150 155 160 165 DRCRequestedrate kbps Dual 0 30mph 0 500 1000 1500 2000 2500 3000 120 125 130 135 140 145 150 155 160 165 PathLoss dB DRCRequestedrate kbps Single 0 30mph DRC速率與天線數(shù)量的關系 天線數(shù)量 終端移動速度與DRC速率 SNR間的關系 22 00 10 00 20 00 30 00 40 00 50 00 60 00 70 00 80 00 90 00 100 00 100 300 500 700 900 1100 1300 1500 1700 1900 2100 2300 2500 DataRate kbps Probability Fast SingleDiv Slow SingleDiv Fast DoubleDIv Slow DoubleDiv CumulativeFast Single CumulativeSlow Single CumulativeFast Double CumulativeSlow Double 00 10 00 20 00 30 00 40 00 50 00 60 00 70 00 80 00 90 00 100 00 15 10 5 0 5 10 15 Singal to NoiseRatio dB Fast Single Slow Single Fast Double Slow Double 覆蓋測試小結(jié) 在路徑損耗 160dB時還能保持會話基于不同的cellclutter 小區(qū)覆蓋半徑為4 17 4 8KM在平坦空曠地帶能覆蓋12 8KM在單用戶單扇區(qū)情況下 前反向鏈路是平衡的在多用戶情況下是反向鏈路受限 5dB底噪抬升 在大多數(shù)多扇區(qū)情況下是反向鏈路受限根據(jù)不同的假定有所不同1xEV的反向鏈路與3G 1X非常相似1 1overlay就中等速率而言 雙天線可獲得者最高50 的增益高速移動用戶獲得的增益大 靜止用戶獲得的增益小由于其它的一些限制 如時延 TCP搜索窗大小等 實際應用中增益往往比較小實地測試發(fā)現(xiàn)分集增益為2 2 5dB 23 24 測試結(jié)果 2 虛擬軟切換 虛擬軟功換原理 25 a g b a g b 虛擬軟切換過程 26 虛擬軟切換過程 前向速率與活動集中導頻的關系 27 上圖中Cell1的Alpha扇區(qū)和Gamma扇區(qū)之間是前向鏈路虛擬軟功換 快速扇區(qū)選擇 的示例Cells1和2之間是軟切換的示例反向鏈路支持三方軟切換和更軟切換當新導頻的信噪比低于主導頻信噪比10dB 新導頻將被加入 用于確保快速可靠的切換在切換區(qū)域當各信號近似相等時 前向速率可達300 600kbps在小區(qū)邊緣 有用信號和干擾相等時 信噪比 0dB 數(shù)據(jù)速率為600kbps在切換地區(qū)信號衰落會降低數(shù)據(jù)速率 單速率任可保持 300kbps這些數(shù)據(jù)是實際網(wǎng)絡中小區(qū)邊緣的預期值 受限于鄰小區(qū)的干擾 28 虛擬軟切換總結(jié) 測試結(jié)果 3 連接測試 連接測試統(tǒng)計 起呼成功率掉話率FTP吞吐量以基站群優(yōu)化路線測試測試路線包括所有主路和輔路 2 8小時 正常移動速度兩個終端同時測試 起呼 用單個PING 中斷15秒掉話 重復用FTP下載 長呼叫 失敗 起呼 用PING腳本輸出掉話 從CAIT掛斷很多掉話從FTP腳本輸出是無法檢測到的掉話率按90秒一個通話計算 29 連接測試結(jié)果 連接測試 呼叫次數(shù) 1289試呼次數(shù) 2293掉話次數(shù) 51接入失敗次數(shù) 45掉話率 3 98 接入失敗率 1 96 掉話率約為1 2 約3 是由于Chester問題FTP吞吐量 不用CAIT為540kbps用CAIT下降10 20 30 掉話率分析 2 3和 5是Chester問題 2 81 排除Chester問題 掉話率為1 1 1 2 RF相關的掉話占0 55 可通過優(yōu)化解決FT有效丟失是反向鏈路丟失 0 55 原因待查其中許多掉話終端用戶是察覺不到的 31 連接測試總結(jié) 起呼失敗率小于2 與95 1X相似非常相似的Access協(xié)議終端設備正常的情況下 掉話率可小于1 2 由于3種已知的手機問題 額外增加了約2 8 的掉話率1 2 中的0 55 是由于反向鏈路故障趙成的數(shù)據(jù)丟失產(chǎn)生的在單用戶 標準終端的情況下 前項FTP吞吐率為540KbpsCAIT記錄的吞吐率降低10 20 注意 當兩個用戶以16kB窗口 另一個用戶以64kB窗口進行測試時 總的平均吞吐率為900Kbps左右 32 測試結(jié)果 4 單用戶定點吞吐量測試 四種應用方式UDP Test模式 throughputw owindowsize delayconstraints FTP throughputwith16kBwindowsize HTTP pagesfromdedicatedserverandfromremotehosts CNET Yahoo Amazon NYTandYahooMapsPING roundtriptime 四種環(huán)境NC Near the Cell 在基站近距離范圍內(nèi) MC Middle of Cell 在基站中等距離范圍內(nèi) EC Edge of Cell 在基站覆蓋邊緣 兩種天線設置方式單根雙根到達已選擇好的測試位置 NC MC EC 將Chester與筆記本電腦連接好 33 單用戶吞吐量 從物理層到鏈路層的吞吐量損失DRC的刪除速率可以通過對容量和單扇區(qū)吞吐量的參數(shù)優(yōu)化來降低其速率當扇區(qū)內(nèi)用戶少時 DRC的刪除對總的扇區(qū)吞吐量的影響不大 0 1 with3ATs 參數(shù)的調(diào)整可以提高單用戶的吞吐量 但會影響扇區(qū)的多用戶容量 34 單用戶吞吐量 射頻部分 近點和遠點的選擇均應在合理的覆蓋范圍內(nèi) minSRN 0dB 中間點更好一些在近點 RF的環(huán)境隨天線和目標的微小移動而變化問題的原因時 在測試過程中要關掉CAITGaugeprovidingareal timemonitoringoftheDRCrequestedrateswouldbeverybeneficialforstationaryusers當天線移動在1 2英尺范圍內(nèi)時 僅會有幾百kbps的變化 35 延時 Round TripTime 當把反向鏈路的幀降為26 7毫秒時 默認的ping的RTT小于110msec backhauldelay32BPing 20BIPheader 8BICMPheader 5BPPPheader 65B65Brequire3reverselinkframes 80msec about70 ofthetime由于Chester的原因會造成大約一個幀的額外延時使用VJorPPP壓縮可以降低延時 36 單用戶測試結(jié)果 UDP吞吐量比物理層低大約22 expectedresultwithDRCerasures oneuser 由于其他原因 FTP吞吐量的測量值是不準確的OtherlimitingmechanismHTTP吞吐量大大低于FTP在本地服務器下載與通過internet從遠端服務器下載的差別很大額外的延時 丟包等等 37 RTT TCP窗口尺寸的考慮 如果RTT時延大于滿窗所需的時間 在收到acknowledgment消息前 TCP將處于待機狀態(tài) 我們實測的RTT小于160msecWindows95 98的默認TCPWindow為8kB Windows2000為17520B大多數(shù)的Unix系統(tǒng)的TCPWindow是64kB 38 TCPProtocolDataExchange TCPExchangewithtransmissiontimeverysmallcomparedtoRoundTripTime TCPwindow TCP IP吞吐量 在假定無任何傳輸錯誤時的計算當物理層的壞幀達到1 時 RLP將重傳當RLP失敗 TCP IP收到壞字節(jié) TCP IP將重傳或減慢啟動裝置 如果TCP超時 傳輸?shù)腻e誤 會降低10 的吞吐率FTP限制 NotlimitedbyRTT WindowSize butbyPhysicalLayerconstraints 39 HTTP應用 HTTP是利用TCP IP協(xié)議 但更受限于網(wǎng)頁的內(nèi)容典型網(wǎng)頁 100kBytes的數(shù)據(jù)量其中有很多嵌入的對象 約有幾kBytes 40 Obj2 Obj3 HTMLFile OBJECTS FinalWebPage Obj1 Obj N HTTP吞吐量 瀏覽器在點擊之后向服務器發(fā)出申請服務器確定相關的HTM文件 并且回復給瀏覽器瀏覽器分析HTM文件 確定不同的目標 HTML text GIF 然后下載目標下載應該是連續(xù)的 因瀏覽器而異 在正常情況下 HTTP無法提供TCP窗口采用PPP軟件壓縮 利用二者其中之一 通?？梢蕴岣逪TTP的吞吐量 41 單用戶吞吐量總結(jié) 應用層的吞吐量滿足預期吞吐量要求 給定RTT 對于一些重要的應用 比如HTTP 增大TCPWindow不能改善性能升級網(wǎng)絡瀏覽器軟件 pipelining和multipleTCPs 和 或者軟件加速器將會有進一步的改善 42 43 單用戶吞吐量總結(jié) 應用層用戶感知吞吐量取決于以下因素應用 網(wǎng)頁瀏覽 文件下載 音頻 視頻流 電子郵件 協(xié)議 TCP IP或者UDP以及它們在服務器端和客戶端的實現(xiàn) 網(wǎng)絡參數(shù)設置 TCP IP以及一些RF相關的參數(shù) 在經(jīng)過骨干網(wǎng)和互聯(lián)網(wǎng)時的延時和丟包 遠端服務器的特性以及響應時間 負載情況 實際內(nèi)容 網(wǎng)頁上的對象以及文件可壓縮性 用戶在小區(qū)中所處的位置 小區(qū)中其它用戶數(shù)量 終端設備 單vs 雙天線 延時等 膝上型電腦 接口速度以及它們自己的TCP設置 應用層的吞吐量很難得到保證取決于多種因素 不是人為所能控制的 測試結(jié)果 5 多用戶定點和慢速吞吐量測試 4個激活用戶 8個激活用戶和4個激活用戶 4個休眠用戶FTP和UDP協(xié)議用戶所處位置兩個NC NC1andNC2 四個MC MC1 MC2 MC3andMC4 兩個EC EC1andEC2 定點和慢速沿著相應路線停在指定地點在小范圍內(nèi)移動兩個天線的終端安裝在膝上型電腦上收集路測數(shù)據(jù) 進行吞吐量分析 44 定點測試 一些移動臺終端的信噪比比通常預期的要好MC的接收電平在 85 5dBm之間 EC的接收電平在 95 5dBm之間 IndividualFTPThroughput 之間差距不大主要受限于TCPwindow和RTT 而不是 requestedrate 45 stationary pedestrian FTP吞吐量 休眠狀態(tài)的移動臺對吞吐量沒有影響8個用戶與4個用戶相比 吞吐量大約下降7 在定點狀態(tài)下是由于低的 requestedrates NC1 MC1 MC3和EC14個用戶時平均為1 85Mbps 而8個用戶時平均為1 75Mbps對于慢速移動的終端 由于調(diào)度算法的原因則不能采用類似的計算吞吐量與用戶數(shù)量曲線中 吞吐量在速率高的時候較早地達到了飽和狀態(tài) 46 UDP吞吐量 IndustryAssociations ProprietaryInformation LucentTechnologies 47 在四個用戶和8個用戶 終端具有兩個天線以及扇區(qū)內(nèi)隨機分布的情況下 扇區(qū)平均吞吐量能夠達到1 2到1 5Mbps之間靜止或者慢速UDP或者FTP協(xié)議有或者沒有處于休眠狀態(tài)的手機一些終端處于非常好的無線環(huán)境下任何的容量向上調(diào)整建議 都需要更多的測試 48 多用戶定點和慢速吞吐量測試總結(jié) 49 多用戶定點和慢速吞吐量測試總結(jié) 定點測試的結(jié)果取決于用戶位置及其附近的環(huán)境 不只取決于接收電平在一些情況下 8個用戶與4個用戶相比 平均吞吐量大約有7 的下降一些結(jié)果可用 requestedrates 的不同來解釋在任何實際測量中 7 的精確程度是很平常的實驗室測試結(jié)果中未發(fā)現(xiàn)這種現(xiàn)象 測試結(jié)果 6 多用戶移動吞吐量測試 真正的多用戶測試是很難進行的 對于滿負載情況下需要上百個移動終端切實可行的測試例子 8個移動用戶 4輛車 隨機分布在cluster內(nèi)FTP應用Cluster內(nèi)路線選擇 1 1 5小時 所有的一級路線和一些二級路線擴展到一些信號較弱的地區(qū)兩個終端同時處在一個小區(qū)覆蓋范圍內(nèi)不是所有的小區(qū)都處于有負載狀態(tài)將會影響 IncrementalRedundancygain 而不會影響 requestedrates 50 8個用戶移動吞吐量測試 8個具有兩個天線的終端安裝在膝上型電腦上4輛車 每輛車里兩個終端每扇區(qū)里兩個終端少量數(shù)據(jù)是在4個終端處于一個扇區(qū)下搜集的 PN388 測試時間大約1小時 cluster內(nèi)的主要路線 典型的為移動物體所走路線 向南部擴展路線 采集一些信號較弱地區(qū)的路測數(shù)據(jù)駕駛速度為典型的移動速度 最大70mph 一些停止 51 52 以FTP方式循環(huán)下載3MB的文件前向FTP平均吞吐量為462kbps每用戶 或者925kbps每扇區(qū)測試中的SNR中值約為5 4dB 仿真建議值為3 4dB 兩個FTP進程不足以提供足夠的數(shù)據(jù)量來填充數(shù)據(jù)隊列 8個用戶移動吞吐量測試 Scheduler測試 希望提供出一些模擬UDP話務模型的實際數(shù)據(jù)測試沿一個圓圈以10mph的速度緩慢行駛 測試環(huán)境分別為 1個終端3個終端分布在2輛車上5個終端分布在3輛車上8個終端分布在4輛車上路測表明SNR MRx和DRC的變化相當大Scheduler增益能夠通過計算獲得 為N個終端下的單扇區(qū)平均速率和一個終端下的數(shù)據(jù)速率之比測量表明在8個用戶時scheduler增益約為25 大約5個用戶 Schedule增益就可以進入飽和區(qū)假如測試中能夠保持前后一致的速度 增益可能會更大 多用戶測試時路測速度稍微快了一些 53 Scheduler測試 54 1 3 5 8用戶測試 55 Scheduler增益 56 測試總結(jié) 測試結(jié)果驗證了甚至超過了在靜止 步行和車輛行駛等不同環(huán)境下要求的吞吐量900kbps 在車輛行駛環(huán)境1 2 1 6Mbps 在靜止和步行環(huán)境對DRCrequestedrate或者SNR使用實時VU meter 會非常有益于靜止用戶 Real timeVU meterforDRCrequestedrateorSNRwouldbeverybeneficialforstationaryusers 修正現(xiàn)有的指導文檔還需要進一步的測試 受不同市場基站數(shù)量情況影響受實際干擾情況 手機功率等影響接入和掉話性能同95 1X網(wǎng)絡相若許多掉話實際用戶難以察覺覆蓋情況和3G 1X網(wǎng)絡相當 支持1 1的overlay切換迅速可靠現(xiàn)場測試結(jié)果表明Scheduler增益可高達30 57 58 計算機模擬結(jié)果 期望的扇區(qū)吞吐量 模擬條件 單天線的測試設備 滿載系統(tǒng) 59 扇區(qū)吞吐量取決于 該扇區(qū)內(nèi)的用戶數(shù)量用戶的移動速度測試的射頻環(huán)境測試設備的天線個數(shù) 計算機模擬結(jié)果 期望的扇區(qū)吞吐量