EV-DO实验网简介.ppt

《EV-DO实验网简介.ppt》由会员分享，可在线阅读，更多相关《EV-DO实验网简介.ppt（59页珍藏版）》请在三一文库上搜索。

1、目 录,1,试验网的规模与地点 试验网的目的 测试工具与计算机的设置 测试项目 计算机模拟结果 测试结果 结论,2,试验网的规模与地点,试验网1: 地点: Whippany 站数: 2 个基站 试验网2: 地点: 美国中部和东部 站数: 8 10 个基站,3,证明EV-DO系统的功能和算法 证明其系统符合IS-856标准,试验网的目的,4,测试工具与计算机的设置,测试工具,测试工具：Chester,“Chester” by Qualcomm 试验时Chester 出现的早期版本 (ver. 3.0.xx) 试验至今已有一些新的升级 双根天线 (或单根天线),5,6,Chester 技术指标-1

2、,7,Chester 技术指标-2,8,Chester 技术指标-3,9,测试工具： EV-Do Cait,10,测试工具与计算机的设置,计算机的设置,TCP Window Size: 16kB TCP/IP Header (a.k.a. Van Jacobson) Compression: OFF PPP Software Compression: OFF TCP Selective ACK: ON TCP Time Stamping: OFF,11,测试项目,覆盖测试 切换测试 连接测试 (掉话率、接入失败率） 单用户定点吞吐量测试 多用户定点和慢速吞吐量测试 多用户移动吞吐量测试 Sch

3、edule 测试,在Whippany， 以及全球其它8个地方 试验站从 2-3个增加至30 个 测试区域城区/郊区 地貌包含山地和平原 具有多样的传输环境 测试基于1.9GHz IS-95/1X overlay的网络上展开 优化工作类似于IS-95/1X 优化主导频,12,测试结果,试验网的基本情况：,系统完全符合IS-856 标准 所用Chester 终端的情况 (ver.3.0.46) 在良好的RF环境下部分前向数据丢失 RLP bug (无NAK requests) MDSP Halt bug (暂停应用现象) Chesters ver.3.2.* 以上版本有很多改进 试验表明只有高性能

4、的数据骨干网才能使1xEV的先进性得到最大体现 减少丢失数据包 降低延迟,13,测试中的几点说明,测试结果,实例 (Whippany Rd, NJ),14,手机接收功率,手机接收功率和发射功率, SNR,15,前向和反向数据速率和PER,16,前向链路和反向链路请求速率随着RF环境的变差而降低，直到最低速率请求 前反向链路维持在1% 的PER 单扇区空载测试，前反链路速率平衡 前反链路出现几秒断开 (路径损耗 160dB) 空载测试 单扇区前向覆盖不变 单扇区反向覆盖扩展，约5dB 在多个扇区下，前向覆盖更好 覆盖受限于反向链路 反向链路实际结果类似3G-1X结果 支持1:1 overlay

5、1xEV on 3G-1X 前向链路吞吐量时常大于物理层请求的速率 ARQ Gain (Incremental Redundancy) 300kbps 速率4 slots的传输请求可由1-3 slots完成,17,由前页曲线可见：,覆盖边界受距离和路径损耗影响 单根和双根天线接入终端 移动速率 (静止，步行，车载) 测试路线用不同行驶速度: 静止和步行 (5mph) 低速 (20-30mph) 高速 (30-70mph) 合并的情况 分别测试单根和双根天线 测试从基站近点向外呈辐射状路线 至到掉话 用不同的行驶路线比较评估路径损耗,18,测试结果: (1)覆盖测试,路径损耗,19,Yellow

6、 Hata Urban prediction Red Hata Suburban prediction,1,000,2,000,3,000,5,000,10,000,Distance m,40,60,100,80,120,140,160,180,Path Loss dB,DRC 速率与路径损耗的关系,20,Path Loss dB,0,500,1000,1500,2000,2500,3000,120,125,130,135,140,145,150,155,160,165,DRC Requested rate kbps,0,500,1000,1500,2000,2500,3000,120,125

7、,130,135,140,145,150,155,160,165,DRC Requested rate kbps,Low Speed 0-30mph,High Speed 30-70mph,21,0,500,1000,1500,2000,2500,3000,120,125,130,135,140,145,150,155,160,165,DRC Requested rate kbps,Dual, 0-30mph,0,500,1000,1500,2000,2500,3000,120,125,130,135,140,145,150,155,160,165,Path Loss dB,DRC Reque

8、sted rate 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,Data Rate kbps,Probability %,Fast/Single Div,Slow/Single Div.,Fast/Double DIv,Slow/Double

9、 Div,Cumulative Fast/Single,Cumulative Slow/Single,Cumulative Fast/Double,Cumulative Slow/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-Noise Ratio dB,Fast/Single,Slow/Single,Fast/Double,Slow/Double,覆盖测试小结,在路径损耗160dB时还能保持会话 基于不同的cel

10、l clutter,小区覆盖半径为4.17- 4.8KM 在平坦空旷地带能覆盖12.8 KM 在单用户单扇区情况下,前反向链路是平衡的 在多用户情况下是反向链路受限( 5dB 底噪抬升) 在大多数多扇区情况下是反向链路受限 根据不同的假定有所不同 1xEV的反向链路与3G-1X非常相似 1:1 overlay 就中等速率而言,双天线可获得者最高50% 的增益 高速移动用户获得的增益大,静止用户获得的增益小 由于其它的一些限制(如时延,TCP搜索窗大小等) 实际应用中增益往 往比较小 实地测试发现分集增益为2-2.5 dB,23,24,测试结果: (2)虚拟软切换,虚拟软功换原理：,25,a,g

11、,b,a,g,b,虚拟软切换过程,26,虚拟软切换过程,前向速率与活动集中导频的关系,27,上图中Cell 1的Alpha扇区和Gamma扇区之间是前向链路虚拟软功换(快速扇区选择)的示例 Cells 1 和 2之间是软切换的示例 反向链路支持三方软切换和更软切换 当新导频的信噪比低于主导频信噪比10dB,新导频将被加入用于确保快速可靠的切换 在切换区域当各信号近似相等时,前向速率可达300-600kbps 在小区边缘,有用信号和干扰相等时(信噪比=0dB),数据速率为600kbps 在切换地区信号衰落会降低数据速率,单速率任可保持 300kbps 这些数据是实际网络中小区边缘的预期值(受限于

12、邻小区的干扰),28,虚拟软切换总结,测试结果: (3)连接测试,连接测试统计: 起呼成功率 掉话率 FTP吞吐量 以基站群优化路线测试 测试路线包括所有主路和辅路(2-8小时) 正常移动速度 两个终端同时测试: 起呼: 用单个PING,中断15秒 掉话: 重复用FTP下载(长呼叫) 失败: 起呼: 用PING脚本输出 掉话: 从CAIT 挂断 很多掉话从FTP脚本输出是无法检测到的 掉话率按90秒一个通话计算,29,连接测试结果,连接测试: 呼叫次数:1289 试呼次数:2293 掉话次数:51 接入失败次数:45 掉话率: 3.98% 接入失败率: 1.96% 掉话率约为1.2% 约3%

13、是由于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%是由于反向链路故障赵成的数据

14、丢失产生的 在单用户，标准终端的情况下，前项FTP吞吐率为540Kbps CAIT 记录的吞吐率降低10-20% 注意：当两个用户以16kB窗口，另一个用户以64kB窗口进行测试时，总的 平均吞吐率为900Kbps左右,32,测试结果: (4)单用户定点吞吐量测试,四种应用方式 UDP & Test 模式 (throughput w/o window size & delay constraints) FTP (throughput with 16kB window size) HTTP (pages from dedicated server and from remote hosts) C

15、NET, Yahoo, Amazon, NYT and Yahoo Maps PING (round trip time) 四种环境 NC Near-the-Cell（在基站近距离范围内） MC Middle-of-Cell（在基站中等距离范围内） EC Edge-of-Cell（在基站覆盖边缘） 两种天线设置方式 单根 双根 到达已选择好的测试位置 (NC, MC, EC) 将Chester 与笔记本电脑连接好,33,单用户吞吐量,从物理层到链路层的吞吐量损失 DRC 的删除速率可以通过对容量和单扇区吞吐量的参数优化来降低其速率 当扇区内用户少时，DRC 的删除对总的扇区吞吐量的影响不大 (

16、0.1% with 3 ATs) 参数的调整可以提高单用户的吞吐量，但会影响扇区的多用户容量,34,单用户吞吐量 射频部分,近点和远点的选择均应在合理的覆盖范围内 (min SRN=0dB) 中间点更好一些 在近点，RF的环境随天线和目标的微小移动而变化 问题的原因时，在测试过程中要关掉CAIT Gauge providing a real-time monitoring of the DRC requested rates would be very beneficial for stationary users 当天线移动在12英尺 范围内时，仅会有几百kbps的变化。,35,延时(Rou

17、nd-Trip Time),当把反向链路的帧降为26.7毫秒时，默认的 ping 的RTT小于 110 msec + backhaul delay 32B Ping + 20B IP header + 8B ICMP header + 5B PPP header = 65B 65B require 3 reverse link frames (80msec) about 70% of the time 由于Chester的原因会造成大约一个帧的额外延时 使用VJ or PPP 压缩可以降低延时,36,单用户测试结果,UDP 吞吐量比物理层低大约 22% expected result with

18、 DRC erasures (one user) 由于其他原因，FTP吞吐量的测量值是不准确的 Other limiting mechanism HTTP 吞吐量大大低于 FTP 在本地服务器下载与通过internet 从远端服务器下载的差别很大 额外的延时, 丢包等等,37,RTT/TCP 窗口尺寸的考虑,如果RTT时延大于满窗所需的时间，在收到 acknowledgment 消息前，TCP将处于待机状态。 我们实测的 RTT 小于 160 msec Windows 95/98的默认 TCP Window 为 8kB, Windows 2000 为17520B 大多数的Unix系统的 TCP

19、 Window 是 64kB,38,TCP Protocol Data Exchange,TCP Exchange with transmission time very small compared to Round Trip Time,TCP window,TCP/IP 吞吐量,在假定无任何传输错误时的计算 当物理层的坏帧达到1%时，RLP 将重传 当RLP失败, TCP/IP 收到坏字节, TCP/IP将重传或减慢启动装置 (如果TCP超时) 传输的错误，会降低10%的吞吐率 FTP限制 * Not limited by RTT/Window Size, but by Physical

20、Layer constraints,39,HTTP 应用,HTTP 是利用 TCP/IP 协议, 但更受限于网页的内容 典型网页: 100kBytes 的数据量 其中有很多嵌入的对象，约有几 kBytes,40,Obj2,Obj3,HTML File,OBJECTS,Final Web Page,Obj1,Obj,N,HTTP 吞吐量,浏览器在点击之后向服务器发出申请 服务器确定相关的 HTM 文件，并且 回复给浏览器 浏览器分析 HTM文件, 确定不同的目标 (HTML, text, GIF), 然后下载目标 下载应该是连续的 (因浏览器而异) 在正常情况下，HTTP 无法提供 TCP 窗口

21、 采用PPP软件压缩，利用二者其中之一，通常可以提高 HTTP的吞吐量,41,单用户吞吐量总结,应用层的吞吐量满足预期吞吐量要求(给定RTT) 对于一些重要的应用(比如HTTP)，增大TCP Window不能改善性能 升级网络浏览器软件(pipelining和multiple TCPs)和/或者软件加速 器将会有进一步的改善。,42,43,单用户吞吐量总结,应用层用户感知吞吐量取决于以下因素 应用 (网页浏览,文件下载 , 音频/视频流, 电子邮件); 协议 (TCP/IP或者UDP以及它们在服务器端和客户端的实现); 网络参数设置 (TCP/IP以及一些RF相关的参数); 在经过骨干网和互联

22、网时的延时和丢包; 远端服务器的特性以及响应时间(负载情况); 实际内容 (网页上的对象以及文件可压缩性); 用户在小区中所处的位置; 小区中其它用户数量; 终端设备 (单vs.双天线, 延时等); 膝上型电脑 (接口速度以及它们自己的TCP设置)。 应用层的吞吐量很难得到保证 取决于多种因素，不是人为所能控制的。,测试结果: (5)多用户定点和慢速吞吐量测试,4个激活用户, 8个激活用户和4个激活用户+4个休眠用户 FTP和UDP协议 用户所处位置 两个NC (NC1 and NC2) 四个MC (MC1, MC2, MC3 and MC4) 两个EC (EC1 and EC2) 定点和慢速

23、 沿着相应路线停在指定地点 在小范围内移动 两个天线的终端安装在膝上型电脑上 收集路测数据,进行吞吐量分析,44,定点测试,一些移动台终端的信噪比比通常预期的要好 MC的接收电平在-855dBm之间，EC的接收电平在-955dBm之间 “Individual FTP Throughput”之间差距不大 主要受限于TCP window和RTT，而不是“requested rate”,45,stationary,pedestrian,FTP 吞吐量,休眠状态的移动台对吞吐量没有影响 8个用户与4个用户相比，吞吐量大约下降7% 在定点状态下是由于低的“requested rates” NC1,MC1

24、,MC3和EC1 4个用户时平均为1.85Mbps，而8个用户时平均为1.75Mbps 对于慢速移动的终端,由于调度算法的原因则不能采用类似的计算 吞吐量与用户数量曲线中，吞吐量在速率高的时候较早地达到了饱和状态,46,UDP 吞吐量,Industry Associations -Proprietary Information Lucent Technologies,47,在四个用户和8个用户, 终端具有两个天线以及扇区内随机分布的情况下,扇区平均吞吐量能够达到1.2到1.5Mbps之间 静止或者慢速 UDP或者FTP协议 有或者没有处于休眠状态的手机 一些终端处于非常好的无线环境下 任何的容

25、量向上调整建议,都需要更多的测试,48,多用户定点和慢速吞吐量测试总结,49,多用户定点和慢速吞吐量测试总结,定点测试的结果取决于用户位置及其附近的环境,不只取 决于接收电平 在一些情况下,8个用户与4个用户相比,平均吞吐量大约有 7%的下降 一些结果可用“requested rates”的不同来解释 在任何实际测量中,7%的精确程度是很平常的 实验室测试结果中未发现这种现象,测试结果: (6)多用户移动吞吐量测试,真正的多用户测试是很难进行的, 对于满负载情况下需要上百个移动终端 切实可行的测试例子: 8个移动用户(4辆车) 随机分布在cluster内 FTP应用 Cluster内路线选择(

26、1-1.5小时) 所有的一级路线和一些二级路线 扩展到一些信号较弱的地区 两个终端同时处在一个小区覆盖范围内 不是所有的小区都处于有负载状态 将会影响“Incremental Redundancy gain”, 而不会影响“requested rates”,50,8个用户移动吞吐量测试,8个具有两个天线的终端安装在膝上型电脑上 4辆车,每辆车里两个终端 每扇区里两个终端 少量数据是在4个终端处于一个扇区下搜集的(PN388) 测试时间大约1小时,cluster内的主要路线 (典型的为移动物体所走路线) 向南部扩展路线,采集一些信号较弱地区的路测数据 驾驶速度为典型的移动速度(最大70mph,

27、一些停止),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个终端下的单扇

28、区平均速率和一个终端下的数据速率之比 测量表明在8个用户时scheduler增益约为25% 大约5个用户,Schedule增益就可以进入饱和区 假如测试中能够保持前后一致的速度,增益可能会更大 (多用户测试时路测速度稍微快了一些),53,Scheduler 测试,54,1, 3, 5, 8 用户测试,55,Scheduler 增益,56,测试总结,测试结果验证了甚至超过了在静止,步行和车辆行驶等不同环境下要求的吞吐量 900kbps ,在车辆行驶环境 1.2-1.6Mbps ,在静止和步行环境 对DRC requested rate或者SNR使用实时VU-meter,会非常有益于静止用户 (R

29、eal-time VU-meter for DRC requested rate or SNR would be very beneficial for stationary users) 修正现有的指导文档还需要进一步的测试: 受不同市场基站数量情况影响 受实际干扰情况,手机功率等影响 接入和掉话性能同95/1X网络相若 许多掉话实际用户难以察觉 覆盖情况和3G-1X网络相当, 支持1:1 的overlay 切换迅速可靠 现场测试结果表明Scheduler 增益可高达30%,57,58,计算机模拟结果（期望的扇区吞吐量）,模拟条件：单天线的测试设备、满载系统,59,扇区吞吐量取决于： 该扇区内的用户数量 用户的移动速度 测试的射频环境 测试设备的天线个数,计算机模拟结果（期望的扇区吞吐量）,