960 likes | 1.13k Views
Challenges and Opportunities in Providing Wireless Data Services in 3G Wireless Networks. Dr. Sanjoy Paul ( sanjoy@bell-labs.com ) Research Director Bell Laboratories Research Lucent Technologies. Outline. Introduction Challenges in Consumer segment Data Performance
E N D
Challenges and Opportunities in Providing Wireless Data Services in 3G Wireless Networks Dr. Sanjoy Paul (sanjoy@bell-labs.com) Research Director Bell Laboratories Research Lucent Technologies
Outline • Introduction • Challenges in • Consumer segment • Data Performance • Enterprise segment • Security • Conclusion
cdma2000 1X (1.25 MHz) cdma2000 3X (5 MHz) Wireless Standards Evolution to 3G 1G 2G “2.5G” 3G/ IMT-2000 Capable Existing Spectrum New Spectrum Analog AMPS IS-95-A/ cdmaOne IS-95-B/ cdmaOne 1XEV DO: HDR (1.25 MHz) IS-136 TDMA 136 HS EDGE TACS GSM GPRS EDGE GSM UMTS (WCDMA) HSCSD
Current State of the Wireless Market • Primarily voice-centric; limited data usage • Penetration level for mobile subscribers continues to increase • “Minutes of use” per subscriber continues to rise • Average Revenue Per User (ARPU) is flat or declining • 3G voice alone is not enough to justify huge investments in 3G technology and licenses • Need for High Speed Data (HSD) in wireless networks is clear
Western Europe Wireless Subscribers In 2005 W. Europe will have over 410M mobile subscribers reaching 87% penetration The Strategies Group W. European Data Bank – March 2003
U.S. Wireless Subscribers U.S. wireless penetration is likely to reach 57.7% by year end 2003 with nearly 167 million subscribers Millions 52% 1995 1996 1997 1998 1999 2000 2001E 2002E 2003E Ending subs (millions) 33.8 44.0 55.3 69.2 86.0 109.5 129.9 149.8 167.3 Net Adds (millions) 9.7 10.3 11.3 13.9 16.8 23.4 20.4 20.0 17.4 % Change y/y 40% 30% 26% 25% 24% 27% 19% 15% 12% Ending Penetration 12.8% 16.4% 20.4% 25.2% 31.0% 38.9% 45.7% 52.2% 57.7% Incremental Penetration 3.5% 3.7% 4.0% 4.8% 5.8% 8.0% 6.8% 6.5% 5.5% Sources: CTIA, Goldman Sachs Research estimates 1/11/02
Rapidly Declining Voice ARPU Source: Pyramid Research Rapid decline of voice ARPU is driven by growth of low-usage prepaid segment.Only way to generate additional revenue is through data services
Consumer Applications like web browsing, gaming, music download, location-based services, micro-payment, mobile ticketing Performance is key Price sensitive Enterprise Applications like e-mail, calender, powerpoint presentation, netmeeting, voucher, vendor payment Security is key Performance is also important Willing to pay more Consumer vs Enterprise Customer
Outline • Introduction • Challenges in • Consumer segment • Data Performance • Enterprise segment • Security • Conclusion
End-to-End Architecture for CDMA2000 Network Servers PCF MSC/ RNC Wireless access Internet PDSN Packet Core BTS PDSN: Packet Data Serving Node PPP Connection End-to-End TCP/IP Connection • -2001 : Mostly Circuit Switched Wireless Networks based at 9.6 Kbps • 2001-2002: 2.5G Networks (using packet switching technology) 13-20 Kbps • 2002-2004? : 3G Networks (1X RTT): 40-100 Kbps; EV-DO: 600 Kbps • Q: How can the carriers improve throughput and response time?
Wireless Data Accelerators • Speed up user’s wireless data experience • “Wireline Experience over Wireless” • Decrease amount of data sent through Wireless interface • Boosts Network Capacity • Different levels of optimizations: Application Optimizations (e.g. compression) Session Optimizations (e.g. DNS Boosting) TCP Optimizations (e.g. Delay-jitter algorithm, ACK regulator) MAC optimizations (e.g. Qos, FEC)
Application Optimizations (e.g. compression) Session Optimizations (e.g. DNS response rewriting, url rewriting) TCP Optimizations (e.g. Delay-jitter algorithm, ACK regulator) MAC optimizations (e.g. Qos, FEC) Wireless Data Accelerators
Application Optimizations • Web Optimizations • Lossycompression of images • Recolor images (gifs and jpegs) • Eliminate animated gifs • Lossless compression of text/html • Removal and compression of HTTP headers • E-mail Optimizations (targeted for PDAs/Cellphones) • Remove attachments • Provide URLs pointing to attachments • Remove extraneous white-space • Remove vowels, provide e-mail summary, compress words
Data Compression Factors Most important Content Types Compression factor average / max HTML x 3.84 / x 8.8 x 4.9 / x 7.5 CSS Java Scripts x 2.73 / x 6.48 Gif x 2.44 / x 22.83 x 2 / x 6.5 JPEG x 3.38 / x 4.1 PAGE • 75 KB Web page at $10/Mbit • No data accelerator: $6 • Data accelerator: $1.7
Latency Reduction Speedup Average / Max x 2.74 / x 5.67 • 100 KB Web page through 1xRTT (application-level throughput=40 Kbps) • No data accelerator: 20 sec • Data accelerator: 5 sec
Image Quality 4 seconds at 150Kbps original JPEG 50k bytes 4 seconds at 30kbps optimized JPEG 10k bytes “Wireline over Wireless”
Application Optimizations (e.g. compression) Session Optimizations (e.g. DNS response rewriting, url rewriting) TCP Optimizations (e.g. Delay-jitter algorithm, ACK regulator) MAC optimizations (e.g. Qos, FEC) Wireless Data Accelerators
Session Optimizations (Problem overview) • Wireless links have very large Round Trip Times (RTTs) due to retransmission at the link layer: 400 msec- 1 sec • Internet applications were not built with such large and variable delays in mind: • shows up in session layer (DNS Lookup) • User experienced throughput is much lower than expected • Maximum Airlink Data Rate (physical layer): 153.6 kbps • Maximum TCP Throughput (with protocol overhead): 128 kbps • FTP throughput:100-120 Kbps • HTTP throughput:50-70 Kbps
Session Optimizations (HTTP Problem) • Popular Pages usually contain several embedded objects that are hosted in different domain names • e.g. weather.cnn.com, finance.cnn.com, a796.g.akamai.net • MS performs new DNS query for each domain name • 1-3 seconds delay • DNS response TTLs for popular Web sites tend to be small leading to frequent DNS requests • MS opens a new TCP connection for each domain name • TCP setup and DNS queries can account for significant overhead health.cnn.com http://cnn.com/index.html weather.cnn.com finance.cnn.com image Internet sports.cnn.com a796.g.akamai.net
Session Optimizations • Goals: • Avoid DNS lookups through the Wireless link • Avoid multiple TCP connections through the Wireless link • Ensure that Web traffic behaves like a long-lived FTP flow • Obvious Solutions: • Explicit Proxy Configuration • Configure a proxy on the browser • Bundling Content • Bundle all content into a single file before it is sent to the client.
Explicit Proxy • Goals: browser must fetch all objects from a single proxy • Avoids DNS look-ups • Avoids multiple TCP connections over the wireless link • Limitations: • Difficult to configure/maintain client’s browser • >90% of all proxy deployments are in transparent mode (browser doesn’t need to be explicitly configured to use the proxy)
Bundling Content • Goals:combine all objects into a single downloadable file • only one DNS request and one TCP connection over the wireless link. • Limitations: • Traditional proxies are not capable of bundling content • Needs new proxy . • Traditional browsers (Netscape/Internet Explorer) are not capable of breaking a bundled page into individual components • Needs new browser
Our Solution: Session-Layer Optimization • Goals: • browser must fetch all objects from a single proxy • Avoid DNS lookups and reuse TCP connections with proxy • No change in standard browser • Two possible complementary implementations • URL rewriting • DNS response rewriting
<img src = http://i.cnn.net/images/plane.jpg> <img src = http:// 10.0.0.12/i.cnn.net/images/plane.jpg> <img src = http:// www.foo.com/views/latest.gif> <img src = http:// 10.0.0.12/www.foo.com/views/latest.gif> <img src = http:// images.yahoo.com/news/world.jpg> <img src = http:// 10.0.0.12/images.yahoo.com/news/world.jpg> <img src = http:// 10.0.0.12/www.news.com/news/roundup.gif> <img src = http:// www.news.com/news/rpundup.gif> Rewritten Original (4) (3) (5) (6) (2) (1) Url Rewriting • Rewrite urls to point to a proxy • Avoids DNS look-up • Reuses a single TCP connection Caching Proxy 10.0.0.12 www.foo.com URL Rewriting Proxy i.cnn.net Images.yahoo.com www.news.com
(11) (12) (10) IP: 10.0.0.12 ------------------ GET /index.html HTTP/1.1 Host: www.foo.com (9) (7) Name: www.foo.com IP: ??? (6) (5) (8) (1) Name: www.foo.com IP: 193.123.25.10 TTL: 10 sec Name: www.foo.com IP: ??? (4) (2) Name: www.foo.com IP: 10.0.0.12 TTL: 1 day IP: 193.123.25.10 TTL: 10 sec Name: www.foo.com IP: ??? (3) Name: www.foo.com IP: 193.123.25.10 TTL: 10 sec DNS Response Rewriting Caching Proxy 10.0.0.12 www.foo.com 193.123.25.10 DNS Rewriting Proxy DNS Server
Experimental Set-up Apache Web Server (Virtual Hosting) www.cnn.com www.yahoo.com www.britannica.com Top 100 URLs DNS Server Internet Squid Caching Proxy (Transparent Mode) URL rewriting DNS rewriting proxy Transparent redirection WiDSE (1xRTT) Client Mobile Node (Mozilla Browser)
Performance Improvement Summary Without Session Layer optimizations HTTP Proxy OS1 Image 1 OS2 TCP 1 Image 2 TCP 2 DNS 1 DNS Server DNS 2 HTTP Proxy With Session Layer optimizations OS1 Image 1 30 – 50 % decrease in response time 50 – 100 % increase in throughput OS2 Image 2 TCP DNS Server
Experimental Details • Three Web pages fully replicated locally • www.cnn.com: 143 KB, 6 domains, 58 objects • www.yahoo.com: 74 KB, 3 domains, 16 objects • www.britannica.com: 167 KB, 14 domains, 32 objects • Instrumented Netscape to automatically download Web pages • Average results over 20 samples
Results: TCP Connections and DNS Requests Number of TCP connections and DNS queriesis much smaller with session-level optimizations: TCP connections reduced up to 500%; DNS requests reduced up to 50%
Results: User Perceived Response Time (average cell) 30% 33% 32% 34% 26% 26% Session-level optimizations provideanimprovement of 25%-35% DNS Response Re-writting and Url Re-writing providesimilar benefits The higher the number the objects/domains, the higher the improvement
Results: User Perceived Response Time (congested cell) 49% 50% 53% 55% 48% 55% Session-level optimizations provide animprovement of up to55% DNS Response Re-writing and Url Re-writing providesimilar benefits
Results: HTTP Throughout (average cell) 36% 36% 51% 50% 44% 48%
Results: HTTP Throughout (congested cell) 126% 124% 93% 117% 101% 98% Session-level optimizations provide more improvement when network conditions worsen (95%-125% improvement in throughput)
Application Optimizations (e.g. compression) Session Optimizations (e.g. DNS response rewriting, url rewriting) TCP Optimizations (e.g. Delay-jitter algorithm, ACK regulator) MAC optimizations (e.g. Qos, FEC) Wireless Data Accelerators
TCP and Wireless Networks • TCP was targeted for terrestrial links with • Few corruption losses (most losses are due to congestion) • Low Round Trip Time (RTT); Low Variability/Jitter • In Wireless • Most of losses are corruption losses • Round Trip Times are quite high (400-1000 msec); High Variability/Jitter • Link layer losses are hidden from the transport layers • Retransmission and Forward Error Correction • As a result TCP sees very few losses • Still, TCP has problems: • Link level reliability removes corruption losses but increases Round Trip Times from 200-400 msec to 2-3 sec leading to loss of throughput • Current TCP timeout algorithms do not work properly under links with high delay variability • Unnecessary retransmissions leading to loss of throughput • TCP is quite bursty • Increases probability of losing packets leading to loss of throughputs
3G1X RTT Link Delay Variability • Experiment Setup: • 3G1X RTT system and mobile device with 3G1X modem • 144 kbps downlink in infinite burst mode and 8 kbps uplink • Results: • No loss observed in ping packets • 75% of ping latency values are less than 200ms and • more than 20% of ping latency varies between 200ms and 500ms
Simulation: Variable Delay • Simulation set-up: • Constant rate of 200kb/s, delay variation is exponentially distributed • Simulate only congestion loss • Larger variation causes larger degradation in TCP throughput • Increasing buffer size increases throughput at the expense of larger RTT
TCP Modeling: Window Evolution TCP with no variation TCP with delay variation • Because of Delay Variations: • Buffer overflow occurs early leading to Lower average TCP window size • Multiple drops results in larger window back-off and time-outs leading to Low Average Throughput
Solution (Ramjee/Chan – Mobicom 2002) • Ack Regulator • Tries to keep buffer size large enough to avoid packet loss and small enough to reduce delay • When TCP congestion window is “small”, have large enough buffer to avoid buffer overflow (packet loss) • When TCP congestion window is “large”, have small enough buffer to allow one packet loss but avoid multiple packet loss
Simulation Result: Window Evolution Reno Reno w/ AR • Ack Regulation (AR) changes the window evolution behavior to be closer to the classic saw-tooth, and • reduces the number of multiple packet loss • maintains a higher average maximum window size • reduces the number of loss events
Multiple TCP Flows over 3G1X EV-DO (HDR) 4 TCP Flows 8 TCP Flows • With multiple TCP flows, improvement over Reno and Sack is significant • Performance improvement is more significant when buffer size is small • Throughput performance of AR is fairly robust w.r.t. to buffer size
Summary & Open issues in TCP Ack Regulation • Results • Improves performance of TCP Reno and Sack up to 40% • Delivers robust performance across different buffer size • Reduces round trip time for the same bandwidth achieved • Open Issues • Ack Regulator for Short flows • Problem with end-to-end IPSEC
Application Optimizations (e.g. compression) Session Optimizations (e.g. DNS response rewriting, url rewriting) TCP Optimizations (e.g. Delay-jitter algorithm, ACK regulator) MAC optimizations (e.g. Qos, FEC) Wireless Data Accelerators
TCP Timeout Problem • TCP Timeout Problemin 3G/1X Systems • Round-Trip Time (RTT) can increase abruptly (so-called Delay Spikes) due to RLP retransmissions, link condition changes, scheduling priorities, etc. • Delay Spikes can cause TCP Timeout: shuts down TCP Window and drastically reduces throughput
RTT / RTO in a 3G Network RTO = Retransmission Time Out RTT = Round Trip Time ms RTO = Estimated RTT + 4 * RTT Deviation Delay spikes lead to Timeouts; cutting TCP window to 1
10 10 10 How to deal with delay spikes? Naïve Solution 20 20 Inject delay every 10 RLP frames 20 20 … BSC PCF PDSN I N T E R N E T MT TE GRE Session GRE Session Rm interface RLP Session TCP BTS RTO = Estimated RTT + 4 * RTT Dev Injecting artificial delay increases RTT Dev This increases RTO and thus Avoids TCP timeouts Prevents loss of TCP throughput 20 IP 20 PPP RLP 2 20
Drawbacks of the Naïve Solution • Not robust as effectiveness depends on applications, data rate, traffic direction, and number of active TCP connections per user • Choice of control parameters (e.g., delay 180 msec once every 10 RLP frames) may be inappropriate