EV-DO实验网简介.ppt

目录 1 试验网的规模与地点试验网的目的测试工具与计算机的设置测试项目计算机模拟结果测试结果结论 2 试验网的规模与地点 试验网1 地点 Whippany站数 2个基站试验网2 地点 美国中部和东部站数 8 10个基站 3 证明EV DO系统的功能和算法证明其系统符合IS 856标准 试验网的目的 4 测试工具与计算机的设置 测试工具 测试工具 Chester Chester byQualcomm试验时Chester出现的早期版本 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个测试区域城区 郊区地貌包含山地和平原具有多样的传输环境测试基于1 9GHzIS 95 1Xoverlay的网络上展开优化工作类似于IS 95 1X优化主导频 12 测试结果 试验网的基本情况 系统完全符合IS 856标准所用Chester终端的情况 ver 3 0 46 在良好的RF环境下部分前向数据丢失RLPbug 无NAKrequests MDSPHaltbug 暂停应用现象 Chestersver 3 2 以上版本有很多改进试验表明只有高性能的数据骨干网才能使1xEV的先进性得到最大体现减少丢失数据包降低延迟 13 测试中的几点说明 测试结果 实例 WhippanyRd NJ 14 手机接收功率 手机接收功率和发射功率 SNR 15 前向和反向数据速率和PER 16 前向链路和反向链路请求速率随着RF环境的变差而降低 直到最低速率请求前反向链路维持在1 的PER单扇区空载测试 前反链路速率平衡前反链路出现几秒断开 路径损耗 160dB 空载测试单扇区前向覆盖不变单扇区反向覆盖扩展 约5dB在多个扇区下 前向覆盖更好覆盖受限于反向链路反向链路实际结果类似3G 1X结果支持1 1overlay1xEVon3G 1X前向链路吞吐量时常大于物理层请求的速率ARQGain IncrementalRedundancy 300kbps速率4slots的传输请求可由1 3slots完成 17 由前页曲线可见 覆盖边界受距离和路径损耗影响单根和双根天线接入终端移动速率 静止 步行 车载 测试路线用不同行驶速度 静止和步行 5mph 低速 20 30mph 高速 30 70mph 合并的情况分别测试单根和双根天线测试从基站近点向外呈辐射状路线至到掉话用不同的行驶路线比较评估路径损耗 18 测试结果 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速率与天线数量的关系 天线数量 终端移动速度与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 覆盖测试小结 在路径损耗 160dB时还能保持会话基于不同的cellclutter 小区覆盖半径为4 17 4 8KM在平坦空旷地带能覆盖12 8KM在单用户单扇区情况下 前反向链路是平衡的在多用户情况下是反向链路受限 5dB底噪抬升 在大多数多扇区情况下是反向链路受限根据不同的假定有所不同1xEV的反向链路与3G 1X非常相似1 1overlay就中等速率而言 双天线可获得者最高50 的增益高速移动用户获得的增益大 静止用户获得的增益小由于其它的一些限制 如时延 TCP搜索窗大小等 实际应用中增益往往比较小实地测试发现分集增益为2 2 5dB 23 24 测试结果 2 虚拟软切换 虚拟软功换原理 25 a g b a g b 虚拟软切换过程 26 虚拟软切换过程 前向速率与活动集中导频的关系 27 上图中Cell1的Alpha扇区和Gamma扇区之间是前向链路虚拟软功换 快速扇区选择 的示例Cells1和2之间是软切换的示例反向链路支持三方软切换和更软切换当新导频的信噪比低于主导频信噪比10dB 新导频将被加入 用于确保快速可靠的切换在切换区域当各信号近似相等时 前向速率可达300 600kbps在小区边缘 有用信号和干扰相等时 信噪比 0dB 数据速率为600kbps在切换地区信号衰落会降低数据速率 单速率任可保持 300kbps这些数据是实际网络中小区边缘的预期值 受限于邻小区的干扰 28 虚拟软切换总结 测试结果 3 连接测试 连接测试统计 起呼成功率掉话率FTP吞吐量以基站群优化路线测试测试路线包括所有主路和辅路 2 8小时 正常移动速度两个终端同时测试 起呼 用单个PING 中断15秒掉话 重复用FTP下载 长呼叫 失败 起呼 用PING脚本输出掉话 从CAIT挂断很多掉话从FTP脚本输出是无法检测到的掉话率按90秒一个通话计算 29 连接测试结果 连接测试 呼叫次数 1289试呼次数 2293掉话次数 51接入失败次数 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 可通过优化解决FT有效丢失是反向链路丢失 0 55 原因待查其中许多掉话终端用户是察觉不到的 31 连接测试总结 起呼失败率小于2 与95 1X相似非常相似的Access协议终端设备正常的情况下 掉话率可小于1 2 由于3种已知的手机问题 额外增加了约2 8 的掉话率1 2 中的0 55 是由于反向链路故障赵成的数据丢失产生的在单用户 标准终端的情况下 前项FTP吞吐率为540KbpsCAIT记录的吞吐率降低10 20 注意 当两个用户以16kB窗口 另一个用户以64kB窗口进行测试时 总的平均吞吐率为900Kbps左右 32 测试结果 4 单用户定点吞吐量测试 四种应用方式UDP Test模式 throughputw owindowsize delayconstraints FTP throughputwith16kBwindowsize HTTP pagesfromdedicatedserverandfromremotehosts CNET Yahoo Amazon NYTandYahooMapsPING roundtriptime 四种环境NC Near the Cell 在基站近距离范围内 MC Middle of Cell 在基站中等距离范围内 EC Edge of Cell 在基站覆盖边缘 两种天线设置方式单根双根到达已选择好的测试位置 NC MC EC 将Chester与笔记本电脑连接好 33 单用户吞吐量 从物理层到链路层的吞吐量损失DRC的删除速率可以通过对容量和单扇区吞吐量的参数优化来降低其速率当扇区内用户少时 DRC的删除对总的扇区吞吐量的影响不大 0 1 with3ATs 参数的调整可以提高单用户的吞吐量 但会影响扇区的多用户容量 34 单用户吞吐量 射频部分 近点和远点的选择均应在合理的覆盖范围内 minSRN 0dB 中间点更好一些在近点 RF的环境随天线和目标的微小移动而变化问题的原因时 在测试过程中要关掉CAITGaugeprovidingareal timemonitoringoftheDRCrequestedrateswouldbeverybeneficialforstationaryusers当天线移动在1 2英尺范围内时 仅会有几百kbps的变化 35 延时 Round TripTime 当把反向链路的帧降为26 7毫秒时 默认的ping的RTT小于110msec backhauldelay32BPing 20BIPheader 8BICMPheader 5BPPPheader 65B65Brequire3reverselinkframes 80msec about70 ofthetime由于Chester的原因会造成大约一个帧的额外延时使用VJorPPP压缩可以降低延时 36 单用户测试结果 UDP吞吐量比物理层低大约22 expectedresultwithDRCerasures oneuser 由于其他原因 FTP吞吐量的测量值是不准确的OtherlimitingmechanismHTTP吞吐量大大低于FTP在本地服务器下载与通过internet从远端服务器下载的差别很大额外的延时 丢包等等 37 RTT TCP窗口尺寸的考虑 如果RTT时延大于满窗所需的时间 在收到acknowledgment消息前 TCP将处于待机状态 我们实测的RTT小于160msecWindows95 98的默认TCPWindow为8kB Windows2000为17520B大多数的Unix系统的TCPWindow是64kB 38 TCPProtocolDataExchange TCPExchangewithtransmissiontimeverysmallcomparedtoRoundTripTime TCPwindow TCP IP吞吐量 在假定无任何传输错误时的计算当物理层的坏帧达到1 时 RLP将重传当RLP失败 TCP IP收到坏字节 TCP IP将重传或减慢启动装置 如果TCP超时 传输的错误 会降低10 的吞吐率FTP限制 NotlimitedbyRTT WindowSize butbyPhysicalLayerconstraints 39 HTTP应用 HTTP是利用TCP IP协议 但更受限于网页的内容典型网页 100kBytes的数据量其中有很多嵌入的对象 约有几kBytes 40 Obj2 Obj3 HTMLFile OBJECTS FinalWebPage Obj1 Obj N HTTP吞吐量 浏览器在点击之后向服务器发出申请服务器确定相关的HTM文件 并且回复给浏览器浏览器分析HTM文件 确定不同的目标 HTML text GIF 然后下载目标下载应该是连续的 因浏览器而异 在正常情况下 HTTP无法提供TCP窗口采用PPP软件压缩 利用二者其中之一 通常可以提高HTTP的吞吐量 41 单用户吞吐量总结 应用层的吞吐量满足预期吞吐量要求 给定RTT 对于一些重要的应用 比如HTTP 增大TCPWindow不能改善性能升级网络浏览器软件 pipelining和multipleTCPs 和 或者软件加速器将会有进一步的改善 42 43 单用户吞吐量总结 应用层用户感知吞吐量取决于以下因素应用 网页浏览 文件下载 音频 视频流 电子邮件 协议 TCP IP或者UDP以及它们在服务器端和客户端的实现 网络参数设置 TCP IP以及一些RF相关的参数 在经过骨干网和互联网时的延时和丢包 远端服务器的特性以及响应时间 负载情况 实际内容 网页上的对象以及文件可压缩性 用户在小区中所处的位置 小区中其它用户数量 终端设备 单vs 双天线 延时等 膝上型电脑 接口速度以及它们自己的TCP设置 应用层的吞吐量很难得到保证取决于多种因素 不是人为所能控制的 测试结果 5 多用户定点和慢速吞吐量测试 4个激活用户 8个激活用户和4个激活用户 4个休眠用户FTP和UDP协议用户所处位置两个NC NC1andNC2 四个MC MC1 MC2 MC3andMC4 两个EC EC1andEC2 定点和慢速沿着相应路线停在指定地点在小范围内移动两个天线的终端安装在膝上型电脑上收集路测数据 进行吞吐量分析 44 定点测试 一些移动台终端的信噪比比通常预期的要好MC的接收电平在 85 5dBm之间 EC的接收电平在 95 5dBm之间 IndividualFTPThroughput 之间差距不大主要受限于TCPwindow和RTT 而不是 requestedrate 45 stationary pedestrian FTP吞吐量 休眠状态的移动台对吞吐量没有影响8个用户与4个用户相比 吞吐量大约下降7 在定点状态下是由于低的 requestedrates NC1 MC1 MC3和EC14个用户时平均为1 85Mbps 而8个用户时平均为1 75Mbps对于慢速移动的终端 由于调度算法的原因则不能采用类似的计算吞吐量与用户数量曲线中 吞吐量在速率高的时候较早地达到了饱和状态 46 UDP吞吐量 IndustryAssociations ProprietaryInformation LucentTechnologies 47 在四个用户和8个用户 终端具有两个天线以及扇区内随机分布的情况下 扇区平均吞吐量能够达到1 2到1 5Mbps之间静止或者慢速UDP或者FTP协议有或者没有处于休眠状态的手机一些终端处于非常好的无线环境下任何的容量向上调整建议 都需要更多的测试 48 多用户定点和慢速吞吐量测试总结 49 多用户定点和慢速吞吐量测试总结 定点测试的结果取决于用户位置及其附近的环境 不只取决于接收电平在一些情况下 8个用户与4个用户相比 平均吞吐量大约有7 的下降一些结果可用 requestedrates 的不同来解释在任何实际测量中 7 的精确程度是很平常的实验室测试结果中未发现这种现象 测试结果 6 多用户移动吞吐量测试 真正的多用户测试是很难进行的 对于满负载情况下需要上百个移动终端切实可行的测试例子 8个移动用户 4辆车 随机分布在cluster内FTP应用Cluster内路线选择 1 1 5小时 所有的一级路线和一些二级路线扩展到一些信号较弱的地区两个终端同时处在一个小区覆盖范围内不是所有的小区都处于有负载状态将会影响 IncrementalRedundancygain 而不会影响 requestedrates 50 8个用户移动吞吐量测试 8个具有两个天线的终端安装在膝上型电脑上4辆车 每辆车里两个终端每扇区里两个终端少量数据是在4个终端处于一个扇区下搜集的 PN388 测试时间大约1小时 cluster内的主要路线 典型的为移动物体所走路线 向南部扩展路线 采集一些信号较弱地区的路测数据驾驶速度为典型的移动速度 最大70mph 一些停止 51 52 以FTP方式循环下载3MB的文件前向FTP平均吞吐量为462kbps每用户 或者925kbps每扇区测试中的SNR中值约为5 4dB 仿真建议值为3 4dB 两个FTP进程不足以提供足够的数据量来填充数据队列 8个用户移动吞吐量测试 Scheduler测试 希望提供出一些模拟UDP话务模型的实际数据测试沿一个圆圈以10mph的速度缓慢行驶 测试环境分别为 1个终端3个终端分布在2辆车上5个终端分布在3辆车上8个终端分布在4辆车上路测表明SNR MRx和DRC的变化相当大Scheduler增益能够通过计算获得 为N个终端下的单扇区平均速率和一个终端下的数据速率之比测量表明在8个用户时scheduler增益约为25 大约5个用户 Schedule增益就可以进入饱和区假如测试中能够保持前后一致的速度 增益可能会更大 多用户测试时路测速度稍微快了一些 53 Scheduler测试 54 1 3 5 8用户测试 55 Scheduler增益 56 测试总结 测试结果验证了甚至超过了在静止 步行和车辆行驶等不同环境下要求的吞吐量900kbps 在车辆行驶环境1 2 1 6Mbps 在静止和步行环境对DRCrequestedrate或者SNR使用实时VU meter 会非常有益于静止用户 Real timeVU meterforDRCrequestedrateorSNRwouldbeverybeneficialforstationaryusers 修正现有的指导文档还需要进一步的测试 受不同市场基站数量情况影响受实际干扰情况 手机功率等影响接入和掉话性能同95 1X网络相若许多掉话实际用户难以察觉覆盖情况和3G 1X网络相当 支持1 1的overlay切换迅速可靠现场测试结果表明Scheduler增益可高达30 57 58 计算机模拟结果 期望的扇区吞吐量 模拟条件 单天线的测试设备 满载系统 59 扇区吞吐量取决于 该扇区内的用户数量用户的移动速度测试的射频环境测试设备的天线个数 计算机模拟结果 期望的扇区吞吐量