EV-DO实验网简介.ppt

起呼失败率小于2% 与 95/1X相似 非常相似的Access协议 终端设备正常的情况下，掉话率可小于1.2% 由于3种已知的手机问题，额外增加了约2.8% 的掉话率 1.2%中的0.55%是由于反向链路故障赵成的数据丢失产生的 在单用户，标准终端的情况下，前项FTP吞吐率为540Kbps CAIT 记录的吞吐率降低10-20% 注意：当两个用户以16kB窗口，另一个用户以64kB窗口进行测试时，总的 平均吞吐率为900Kbps左右 * 四种应用方式 UDP Test 模式 (throughput w/o window size delay constraints) FTP (throughput with 16kB window size) HTTP (pages from dedicated server and from remote hosts) CNET, 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 与笔记本电脑连接好 * 从物理层到链路层的吞吐量损失 DRC 的删除速率可以通过对容量和单扇区吞吐量的参数优化来降低其速率 当扇区内用户少时，DRC 的删除对总的扇区吞吐量的影响不大 (0.1% with 3 ATs) 参数的调整可以提高单用户的吞吐量，但会影响扇区的多用户容量 * 近点和远点的选择均应在合理的覆盖范围内 (min SRN=0dB) 中间点更好一些 在近点，RF的环境随天线和目标的微小移动而变化 问题的原因时，在测试过程中要关掉CAIT Gauge providing a real-time monitoring of the DRC requested rates would be very beneficial for stationary users 当天线移动在1~2英尺 范围内时，仅会有几百kbps的变化。 * 当把反向链路的帧降为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 压缩可以降低延时 * UDP 吞吐量比物理层低大约 22% – expected result with DRC erasures (one user) 由于其他原因，FTP吞吐量的测量值是不准确的 Other limiting mechanism HTTP 吞吐量大大低于 FTP 在本地服务器下载与通过internet 从远端服务器下载的差别很大 额外的延时, 丢包等等 * 如果RTT时延大于满窗所需的时间，在收到 acknowledgment 消息前，TCP将处于待机状态。 我们实测的 RTT 小于 160 msec Windows 95/98的默认 TCP Window 为 8kB, Windows 2000 为17520B 大多数的Unix系统的 TCP Window 是 64kB * TCP Protocol Data Exchange TCP Exchange with transmission time very small compared to Round Trip Time TCP window } 在假定无任何传输错误时的计算 当物理层的坏帧达到1%时，RLP 将重传 当RLP失败, TCP/IP 收到坏字节, TCP/IP将重传或减慢启动装置 (如果TCP超时) 传输的错误，会降低10%的吞吐率 FTP限制 * Not limited by RTT/Window Size, but by Physical Layer constraints * HTTP 是利用 TCP/IP 协议, 但更受限于网页的内容 典型网页: 100kBytes 的数据量 其中有很多嵌入的对象，约有几 kBytes * Obj2 Obj3 HTML Fi