《EV-DO實(shí)驗(yàn)網(wǎng)簡(jiǎn)介.ppt》由會(huì)員分享，可在線閱讀，更多相關(guān)《EV-DO實(shí)驗(yàn)網(wǎng)簡(jiǎn)介.ppt（59頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

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