• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
3G, Wireless Data Services in #G Wireless Networks
 

3G, Wireless Data Services in #G Wireless Networks

on

  • 551 views

 

Statistics

Views

Total Views
551
Views on SlideShare
551
Embed Views
0

Actions

Likes
0
Downloads
36
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    3G, Wireless Data Services in #G Wireless Networks 3G, Wireless Data Services in #G Wireless Networks Presentation Transcript

    • Challenges and Opportunities in Providing Wireless Data Services in 3G Wireless Networks Dr. Sanjoy Paul ( [email_address] ) Research Director Bell Laboratories Research Lucent Technologies
    • Outline
      • Introduction
      • Challenges in
        • Consumer segment
          • Data Performance
        • Enterprise segment
          • Security
      • Conclusion
    • Introduction
    • 3G/ IMT-2000 Capable Existing Spectrum New Spectrum IS-95-A/ cdmaOne IS-95-B/ cdmaOne IS-136 TDMA 136 HS EDGE GSM GSM GPRS EDGE UMTS (WCDMA) HSCSD 1XEV DO: HDR (1.25 MHz) 2G “ 2.5G” Wireless Standards Evolution to 3G 1G Analog AMPS TACS cdma2000 1X (1.25 MHz) cdma2000 3X (5 MHz)
    • 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
    • In 2005 W. Europe will have over 410M mobile subscribers reaching 87% penetration Western Europe Wireless Subscribers The Strategies Group W. European Data Bank – March 2003
    • U.S. Wireless Subscribers 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 Millions 52% U.S. wireless penetration is likely to reach 57.7% by year end 2003 with nearly 167 million subscribers
    • Source: Pyramid Research Rapidly Declining Voice ARPU 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 vs Enterprise Customer
      • 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
    • Outline
      • Introduction
      • Challenges in
        • Consumer segment
          • Data Performance
        • Enterprise segment
          • Security
      • Conclusion
    • Challenges in Consumer Segment
    • End-to-End Architecture for CDMA2000 Network
      • Q: How can the carriers improve throughput and response time?
      End-to-End TCP/IP Connection PPP Connection PDSN: Packet Data Serving Node
      • -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
      Internet PDSN Packet Core BTS Wireless access Servers MSC/ RNC PCF
    • 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) TCP Optimizations (e.g. Delay-jitter algorithm, ACK regulator) MAC optimizations (e.g. Qos, FEC) Session Optimizations (e.g. DNS Boosting)
    • Wireless Data Accelerators Application Optimizations (e.g. compression) TCP Optimizations (e.g. Delay-jitter algorithm, ACK regulator) MAC optimizations (e.g. Qos, FEC) Session Optimizations (e.g. DNS response rewriting, url rewriting)
    • Application Optimizations
      • Web Optimizations
        • Lossy compression 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 JPEG Most important Content Types HTML CSS Java Scripts Gif x 3.84 / x 8.8 x 4.9 / x 7.5 x 2.73 / x 6.48 x 2.44 / x 22.83 x 2 / x 6.5 Compression factor average / max PAGE x 3.38 / x 4.1
      • 75 KB Web page at $10/Mbit
        • No data accelerator: $6
        • Data accelerator: $1.7
    • Latency Reduction x 2.74 / x 5.67 Speedup Average / Max
      • 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”
    • Wireless Data Accelerators Application Optimizations (e.g. compression) TCP Optimizations (e.g. Delay-jitter algorithm, ACK regulator) MAC optimizations (e.g. Qos, FEC) Session Optimizations (e.g. DNS response rewriting, url rewriting)
    • 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
      • 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
      Session Optimizations (HTTP Problem) Internet http://cnn.com/index.html image weather.cnn.com finance.cnn.com sports.cnn.com a796.g.akamai.net health.cnn.com
    • 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 .
      • 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)
      Explicit 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
    • Url Rewriting www.foo.com Caching Proxy 10.0.0.12 URL Rewriting Proxy i.cnn.net Images.yahoo.com www.news.com
      • Rewrite urls to point to a proxy
      • Avoids DNS look-up
      • Reuses a single TCP connection
      (1) (2) (3) <img src = http:// 10.0.0.12 / i.cnn.net /images/plane.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:// 10.0.0.12/www.foo.com/views/latest.gif> Rewritten (6) (5) <img src = http:// i.cnn.net /images/plane.jpg> <img src = http:// images.yahoo.com/news/world.jpg> <img src = http:// www.news.com/news/rpundup.gif> <img src = http:// www.foo.com/views/latest.gif> Original (4)
    • DNS Response Rewriting www.foo.com 193.123.25.10 Caching Proxy 10.0.0.12 DNS Server DNS Rewriting Proxy Name: www.foo.com IP: ??? (1) Name: www.foo.com IP: ??? (2) Name: www.foo.com IP: 193.123.25.10 TTL: 10 sec (3) Name: www.foo.com IP: 10.0.0.12 TTL: 1 day IP: 193.123.25.10 TTL: 10 sec (4) (5) (6) Name: www.foo.com IP: ??? (7) Name: www.foo.com IP: 193.123.25.10 TTL: 10 sec (8) (9) (10) IP: 10.0.0.12 ------------------ GET /index.html HTTP/1.1 Host: www.foo.com (11) (12)
    • Comparison with other Techniques No Yes Yes (with very minimal change) Yes Works with traditional caching proxies No Yes Yes Yes No Client-Side Component required Yes DNS Response Rewriting No Content-Bundling No Explicit Proxy Yes Free from Browser Configuration URL Rewriting
    • Experimental Set-up Apache Web Server (Virtual Hosting) www.cnn.com www.yahoo.com www.britannica.com Top 100 URLs DNS Server Squid Caching Proxy (Transparent Mode) Client Mobile Node (Mozilla Browser) Internet WiDSE (1xRTT) Transparent redirection URL rewriting DNS rewriting proxy
    • Performance Improvement Summary TCP 1 DNS 2 DNS 1 OS1 OS2 HTTP Proxy DNS Server TCP 2 TCP OS1 OS2 HTTP Proxy DNS Server With Session Layer optimizations Without Session Layer optimizations Image 1 Image 2 Image 1 Image 2 30 – 50 % decrease in response time 50 – 100 % increase in throughput
    • 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 queries is 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) 34% 26% 30% 33% 26% 32% Session-level optimizations provide an improvement of 25%-35% DNS Response Re-writting and Url Re-writing provide similar benefits The higher the number the objects/domains, the higher the improvement
    • Results: User Perceived Response Time ( congested cell) Session-level optimizations provide an improvement of up to 55% DNS Response Re-writing and Url Re-writing provide similar benefits 55% 48% 49% 50% 55% 53%
    • Results: HTTP Throughout ( average cell) 51% 36% 44% 50% 36% 48%
    • Results: HTTP Throughout ( congested cell) 124% 93% 98% 101% 126% 117% Session-level optimizations provide more improvement when network conditions worsen (95%-125% improvement in throughput)
    • Wireless Data Accelerators Application Optimizations (e.g. compression) TCP Optimizations (e.g. Delay-jitter algorithm, ACK regulator ) MAC optimizations (e.g. Qos, FEC) Session Optimizations (e.g. DNS response rewriting, url rewriting)
    • 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
      • 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
      TCP with no variation TCP with delay variation
      • 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
      Solution (Ramjee/Chan – Mobicom 2002)
    • 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
      • 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
      8 TCP Flows
      • 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
      Summary & Open issues in TCP Ack Regulation
    • Wireless Data Accelerators Application Optimizations (e.g. compression) TCP Optimizations (e.g. Delay-jitter algorithm , ACK regulator ) MAC optimizations (e.g. Qos, FEC) Session Optimizations (e.g. DNS response rewriting, url rewriting)
    • TCP Timeout Problem
      • TCP Timeout Problem in 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 ms RTO = Estimated RTT + 4 * RTT Deviation Delay spikes lead to Timeouts; cutting TCP window to 1 RTO = Retransmission Time Out RTT = Round Trip Time
    • BSC PDSN PCF MT TE Rm interface BTS I N T E R N E T RLP Session GRE Session GRE Session 20 20 20 2 TCP IP PPP RLP How to deal with delay spikes? Naïve Solution 20 20 20 20 … Inject delay every 10 RLP frames 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 10 10 10
    • 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
      • Key Observation:
        • For typical applications, not much fragmentation from TCP/IP to PPP
        • Most of fragmentation occurs between PPP and RLP
      An Enhanced Delay-Jitter Algorithm (Leung/Klein) TCP Segment ~ PPP Frame
      • Enhanced Solution :
      • Insert extra delay at PPP Layer on PCF
      • instead of inserting delay at RLP Layer on BSC
      • (More effectively deals with TCP at PPP level)
        • PCF identifies PPP Packet Delimiter
        • Count each PPP packet as a TCP packet
      • Benefits:
        • More effectively avoids TCP Timeout to maintain throughput
        • Increases robustness and wider applicability
    • BSC PDSN PCF MT TE Rm interface BTS I N T E R N E T RLP Session GRE Session GRE Session 20 20 20 2 TCP IP PPP RLP Enhanced Delay Jitter Algorithm 20 20 20 20 Inject delay every “ n” PPP frames 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 10 10 10 10
    • Enhanced Delay Jitter Algorithm (more)
      • Different versions:
        • Fixed time – fixed delay (FTFD) : inject delay according to schedule, i.e. inject delay D 0 every N packets.
        • Random time – fixed delay (RTFD) : inject fixed delay D 0 to every packet with probability p=1/N.
        • Random time – random delay (RTRD) : inject delay to every packet with certain probability p=1/N; injected delay is chosen according to some pdf with mean D 0 (in simulations, chose exponential distribution).
    • Effect of Enhanced Delay Jitter (EDJ) Algo on TCP Timeouts Injecting 100ms delay does not reduce # timeouts Injecting 200ms delay reduces # timeouts Timeouts Without EDJ algo Timeouts Without EDJ algo
    • Effect of Enhanced Delay Jitter Algorithm on TCP Timeouts Injecting 300ms delay every N=2/3/4 samples reduces # timeouts Bad choice of Parameters can Increase the # of timeouts Injecting 400ms delay every N=2/3/4 samples reduces # timeouts Bad choice of Parameters can Increase the # of timeouts Timeouts Without EDJ algo Timeouts Without EDJ algo
    • RTT/RTO with and without Enhanced Delay Jitter Algorithm Without Enhanced Delay Jitter Algorithm: RTO is ~700ms 2 timeouts in the example With Enhanced Delay Jitter Algorithm: RTO is ~1200ms 1 timeout in the example
    • Summary of Enhanced Delay Jitter Algorithm
      • With appropriate parameters, proposed methodology does reduce number of timeout occurrences.
      • Random Time – Random Delay method performs quite poorly: too much randomness introduced in the RTT. Degree of randomness in delay injection has to be properly controlled.
      • Fixed Time – Fixed Delay gives optimal performance in terms of reducing the number of timeout occurrences.
      • Need to assess impact on TCP throughput performance
      • (conflicting requirements):
        • Increase in mean RTT  decreases throughput.
        • Decrease in timeout occurrences  increases throughput
        • Optimal choice of parameters ( n, D 0 , p ) needs to be worked out
    • Summary of Performance Enhancement Opportunities * Source: Inktomi Corporation Web, Email, File Transfer TCP/IP Header compression 20-50% Web, Email, File Transfer TCP Performance Enhancements such as Ack Regulator , Snoop, I-TCP, M-TCP Transport Web Proxy for cookies Multiple classes of service Internet Offload, Service differentiation Web DNS lookup optimization Web, Email Application header removal and/or compression Web, Word processor Text compression Up to 300-400% Web, PowerPoint, Word processor Context sensitive image compression and/or transcoding Application + Session Speedup Sample applications Enhancement Opportunity Layer
    • Outline
      • Introduction
      • Challenges in
        • Consumer segment
          • Data Performance
        • Enterprise segment
          • Security
      • Conclusion
    • Challenges in Enterprise Segment
    • Business Services are projected to grow strongly
      • Business oriented high-speed data services for enterprise intranet/extranet access will drive demand for 3G and surpass voice
      • Carriers will need to provide Virtual Private Network (VPN) services
      UMTS Forum: 2001 North America 3G Operator Services Revenue 0 5000 10000 15000 20000 25000 2003 2004 2005 2006 2007 2008 2009 2010 Simple voice --- --- Rich voice --- --- Location Based Services --- --- Busines MMS --- --- Mobile Internet Access --- --- Consumer MMS --- --- Mobile Intranet/Extranet Access --- --- Customized Infotainment --- ---
    • Two choices for Virtual Private Network (VPN) IP Service Switch/ PDSN VPN Gateway Firewall End-to-end IPSec tunnel Split Ipsec tunnels Split Ipsec tunnels INTERNET End-to-end Tunnel Split Tunnel Carrier charges premium for value-added services Carrier charges flat rate Carrier provides value-added services like aggregation Carrier provides simple transport Network-based Split IPSec VPN End-to-End IPSec Tunnel-based VPN
    • End-to-End IPSec-based VPN PDSN Subscriber Access Terminal Enterprise VPN Gateway Decryption at VPN Gateway IP TCP Application Header Application Data IP TCP Application Header Application Data encrypt decrypt Encryption at Client Intermediate Nodes See only encrypted headers/data
      • Today’s common solution offers end-to-end security, but does not allow network-based enhancements/services that require access to header information
      • Carriers become simple transport providers and can only charge at flat rate
      AT IP TCP Application Header Application Data IPSec IP IP TCP Application Header Application Data IPSec IP IP TCP Application Header Application Data IPSec IP
    • Network-based Split IPSec VPN PDSN Subscriber Access Terminal Enterprise VPN Gateway Decryption at VPN Gateway encrypt decrypt Encryption at Client Intermediate Nodes Header/Data exposed IPSec IP IPSec IP decrypt encrypt
      • Enterprise data is exposed within carrier network
      • All network-based enhancements are possible (Application/Session/TCP optimizations)
      • Carriers can charge premium for value-added services
      AT IP TCP Applic. Header Applic. Data IPSec IP IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data IPSec IP IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data
    • Dilemma for a Wireless Carrier Encrypted IPSec tunnel forming a Virtual Private Network Corporate WAN VPN Gateway Internet PDSN Packet Core BTS Wireless access
      • For enterprise customers, Security is key
      • Faster response time and higher throughput are also important
      • With end-to-end IPSec, carrier cannot add value!
      • Challenge: Can we preserve security and at the same time
      • provide value-added services and performance improvement?
      MSC/ RNC PCF
    • Adaptive VPN User Carrier Network Enterprise Carrier Network Enterprise User Carrier Network Enterprise
      • End-to-end security for all applications and users
      • Network cannot enable any new service
      • User data come in clear inside Carrier’s IPSS
      • Network enables new services for all users
      • End-to-end security for some applications/users
      • Network enabled new services for some applications/users
      End-to-end security User Network-based Services End-to-end VPN Network-based VPN Adaptive VPN Flexibility in providing different VPN services to different application/user Value-added services based on IP, TCP and application level headers and application data
    • User-based and Application-based Adaptive VPN IP Service Switch VPN Gateway Firewall End-to-end Tunnel Split Tunnel [email_address] [email_address] [email_address] Example: End-to-End VPN Network-based VPN AAA other Web E-mail Staff Executive Officer Application
    • Policy Download with Adaptive VPN IP Service Switch VPN Gateway Firewall End-to-end Tunnel Split Tunnel AAA/LSMS 135.180.144.254 135.180.244.150 Selection criteria Dest IP: All TCP port: All Dest IP: 192.168.5.0/24 TCP port: 25, 80 Dest IP: All TCP Port: All Dest IP: All TCP Port: All VPN End-point 135.180.244.150 135.180.244.150 135.180.144.254 135.180.144.254 Executive @company 192.168.5.0/24 Web server (Port 80) Mail Server (Port 25) Staff @company Executive @company Officer @company NAI
    • Adaptive VPN Demo Client Network VPN Gateway Enterprise VPN Gateway LVF Brick Tunnel B Tunnel A Tunnel C 135.180.144.254 129.180.244.15 Physical IP 130.160.140.17 Local Presence IP 192.168.5.10 Hosts behind tunnel 192.168.5.0/24 Tunnel A Local Presence IP 192.168.1.10 Hosts behind tunnel 192.168.1.0/24 192.168.3.0/24 Hosts behind tunnel 192.168.3.0/24 192.168.5.0/24 192.168.3.0/24 192.168.1.0/24 Enterprise Network
    • Multi-Layer IPSec (ML-IPS) PDSN Subscriber Access Terminal Enterprise VPN Gateway Decryption at VPN Gateway encrypt decrypt Encryption at Client Intermediate Nodes Headers exposed Enterprise Data protected IPSec IP decrypt encrypt IPSec IP IPSec IP IPSec IP
      • Enterprise data is encrypted end-to-end (Protocol headers exposed to carrier)
      • Many network-based enhancements/services are possible
      AT IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data IPSec IP IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data
    • Multi-Layer IPSec (ML-IPS): Evolution of IPSec Expanded Rules Engine End2End Key Encryption Carrier Key Encryption Data Applic. Hdr. TCP IP Rules Engine ftp header. TCP IP web HTTP hdr. TCP IP Packet Splitting Two Key Encryption Per packet options Example outgoing packets ML-IPS Client or VPN GW video RTP hdr. UDP IP Capability added w/ ML-IPS ML-IPS supports Split & E2E IPSec options “ trusted” to carrier Secure end-to-end
      • Enterprise decides security policy for what content is trusted to carrier
        • Not only application and user control, but also “section of packet” control
      • Many network-based enhancements/services are possible while still preserving end-to-end security of enterprise content
      Benefits video RTP hdr. UDP IP Data Applic. Hdr. TCP IP email header TCP IP
    • Summary of Security Options for VPN Application Compression Internet Offload/Caching URL Blocking/Filtering Stateful Firewall Denial of Service prevention TCP-based enhancements/scheduling Scheduling based on Application/QoS Header compression Adaptive-VPN ML-IPS Network-based Services Today End-to-End IPSec Possible for all traffic, with end-to-end security preserved Possible for some traffic, end-to-end security not preserved Not possible
    • An example of a futuristic application
    • Party 1 Dad Converged voice/data/streaming video service across CDMA/UMTS and Landline connection CDMA Let’s see if the kids are okay. Voice Connection Video Connection We need to buy some flowers for the party. Let me show you a few bouquets. Data Connection How about this? Do you like the vase? Voice Connection Call Landline Party 3 Day Care I like the roses. Can I have them In a different vase? This is perfect! Party 2 Mom UMTS 1-800-Flowers. How can I help you? Done Next Call Done Next Call
    • Another Converged Service Example: Expert on Call Streaming Media, Real-time voice, Best Effort Data Convergence Something doesn’t seem right. Am I testing the right circuit? This is the one I’m working on. Less experienced technician at field site #1. No, that’s not the correct one. Scan to the left, I’ll tell you to stop when you get to the right spot. Expert technician at field site #2.
    • Outline
      • Introduction
      • Challenges in
        • Consumer segment
          • Data Performance
        • Enterprise segment
          • Security
      • Conclusion
    • Conclusion
      • Challenges for 3G Wireless Data Services (being explored)
        • Improving Data Performance
        • Preserving Security while providing value-added services
        • Enable QoS-sensitive applications like Gaming,VOIP,Push-to-Talk
      • Challenges for 3G Wireless Data Services (not yet explored)
        • Multicast
        • Secure group communication (chat)
        • Quality of Service issues
      • Opportunities abound in solving practical problems and enabling carriers to provide high-speed data services and novel multi-media applications while reducing capex and opex for a carrier
    • BACK UP
    • Browser Issues
      • Browser does not reuse persistent connections to servers with different domain names and identical IP address
        • Browser’s bug (breaks persistent connections for Virtual Hosts)
        • Impacts DNS rewriting, but not URL rewriting
      • Browser keeps opening new connections, even if max_connect is reached
        • Browser does this while it finds no idle connections
        • Opens almost as many connections as objects
      • Simple browser modifications/configuration fixes these issues
        • Should be incorporated in Wireless browsers
    • More on Session Optimization
      • Sessions should be kept alive even under mobility scenarios
        • TCP for temporal disconnections
          • User goes through tunnel, server connection is still kept alive
      • Sessions should be kept alive even after a certain idle time (e.g. think time)
        • TCP for frequent channel releases
          • Gold users do not need to go through a Wireless channel adquisition each time they request a new page
    • Temporal Disconnection
      • Problem:
      • With Temporal Disconnections, TCP ACKs do not flow to the server from the mobile client – TCP at the server starts backing off and eventually the server resets the connection.
      • Solution: TCP Proxy
      • TCP proxy keeps state of the TCP connections from the mobile client to the server.
      • When disconnection is noticed (no packets from the mobile), TCP packets with a window size of zero are generated by the TCP proxy and sent to the server - this effectively freezes the TCP end-point at the server.
      • Once connection is established with the mobile, the TCP window size is left as is on the packets from client to server thereby allowing the server to start sending packets.
    • Frequent Channel Release
      • Problem:
      • Mobile nodes release Wireless channels after a certain quiet period if no data packets are received. This timeout period is small (3 – 4 sec.) and it takes 2 to 3 sec. to re-acquire a channel.
      • During a normal browsing operation there are frequent periods of inactivity when data packets do not flow to the mobile (e.g. idle RTTs in between image requests) - if Wireless channel is frequently released in the middle of a TCP session, end-user experience is significantly degraded.
      • Solution: TCP Proxy
      • During quiet periods, TCP ping packets are generated by the TCP proxy and sent to the mobile.
      • Mobile sees continuous data flow on the channel it is holding and so it does not release the channel - once data session is resumed, no more keep-alive packets are generated.
    • Compromise Solution: Adaptive VPN IP Service Switch VPN Gateway Firewall Both end-to-end and split tunnels End-to-end tunnel only Split tunnel only
      • Decision on tunnel is based on user and/or application requirement
      • Application to tunnel mapping is done dynamically
      • Decision on tunnel is based on user id and/or enterprise requirement
      • VPN tunnel mapping is done at setup with help from AAA
      • Terminates any secure tunnel
      • Oblivious to different tunnels
      3G Carrier/Public Network Enterprise Mobile Users End-to-end Tunnel Split Tunnel
    • Adaptive VPN: Added flexibility to Network-based VPN Expanded Rules Engine End2End Tunnel Carrier Tunnel Rules Engine web HTTP hdr. TCP IP Tunnel Selection Separate Tunnels Per packet options Example outgoing packets A-VPN client Client or VPN GW End2End Secure, No enhancements possible Trusted to Carrier, enhancements possible “ trusted” to carrier Secure end-to-end
      • Enterprise decides security policy for what content is trusted to carrier
        • application and user control
      • No standards change, simple additional development
      • Network-based enhancements/services only possible by giving up end-to-end security
      Benefit Limitation Data Applic. Hdr. TCP IP email header TCP IP
    • A-VPN implementation with ML-IPSec support is transparent to client PDSN/SG Network-based VPN CPE Firewall End-to-end VPN
      • TCP headers are exposed with IP SuperSec
      • Because of this, the PDSN can identify
      • the application
      decrypt encrypt IPSec IP IPSec IP IPSec IP Terminate packets to port 80 Forward packets to port 25 IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data IP TCP Applic. Header Applic. Data
    • A-VPN client implementation PDSN/SG Network-based VPN CPE Firewall IPSec IP End-to-end VPN Packets to TCP port 25 (E-mail) Packets to TCP port 80 (Web)
      • Applications identified using TCP port number
      • Client needs to be modified
      Tunnel to PDSN Tunnel to CPE IP TCP Applic. Header Applic. Data
    • Adaptive VPN Implementation
      • Lucent VPN security products modified for Adaptive VPN
      • Modified IPSec client
      • Modified LSMS (Lucent Security Management System)
      IP Service Switch VPN Gateway Firewall End-to-end Tunnel Split Tunnel Executive @company LSMS IPSec client
    • Routing Table at the client with Adaptive VPN
      • Without Adaptive VPN, routes to reach the subnets behind the tunnel added that specify the Local Presence IP address as the gateway
      • With Adaptive VPN, subnets behind the tunnel can be reached either through the End-to-end tunnel or the Network tunnel. Routes are added to the routing table with the appropriate Local Presence IP address as the gateway
      One tunnel Two tunnels
    • 3GPP2 IMS QoS Architecture for Simple IP RAN MS R R R Diffserv marking AAA Diffserv aware Home IP network
      • Let diffserv CP marking go through
      • Remark packet diffserv CP if needed
      HLR SO QoS Subscription Authorization Home Access Provider network Broker network AAA SIP/RTP Header Compression SDP  Service Option (SO) Mapping + BLO Policy DB QoS Resource Subscription CSCF SIP Header Compression MSC PDSN SDP QoS Subscription Authorization AAA PDF/CQM QoS Interworking Diffserv CP PDF=Policy Decision Function CQM = Core QoS Manager External IP Network Diffserv Aware PL R-P Airlink MAC LAC SIP/RTP SIP/RTP UDP UDP IP IP PL Link Layer PL R-P PPP SS7 Network SS7 Network IP Network Airlink MAC LAC PPP IP UDP SIP/RTP
    • Low-Level Interface PPP IP TCP UDP IS2000 RLP PPP IP IS2000 PP PP RLP T1 IP T1 IP WAN IP TCP UDP WAN Low-Level Interface BSC PDSN PCF MT TE Rm interface IP WAN GRE GRE TE MT BSC BTS PCF PDSN TE router Rm Abis A8/A9 A10/A11 Air Interface BTS I N T E R N E T RLP Session GRE Session GRE Session 20 20 20 2 TCP IP PPP RLP CDMA 2000 Network Architecture T1 IP GRE 10
    • RTT Histogram with Delay Jitter Algorithm
    • Url Rewriting
      • Steps
        • Browser first fetches the top-level page from origin server
        • The page is parsed by an intercepting URL rewriting proxy
        • All embedded objects hosted in a different Web server than the top-level page are prefixed with the IP address of a caching proxy (say, 10.0.0.12)
          • For example http://i.cnn.net/images/plane.jpg is changed to: http://10.0.0.12/i.cnn.net/images/plane. jpg
        • The browser connects to the caching proxy to retrieve all embedded objects over a single persistent HTTP (TCP) connection. No DNS requests at the browser needed as IP address of caching proxy is prefixed
    • DNS Response Rewriting
      • Steps
        • All DNS responses intercepted by a DNS rewriting proxy
        • DNS responses are rewritten to add the IP address of a caching proxy to the front of the list of IP addresses returned by the DNS server
        • DNS TTL response is increased
        • Original IP addresses that are returned by the DNS server are left as they are to enable mobile roaming
      • The browser connects to the caching proxy to retrieve the top-level page and the embedded objects.
        • All objects retrieved over a single persistent HTTP (TCP) connection.
        • DNS requests made once and cached for an extended period because of the increased TTL. This prevents DNS queries for a long time and hence improves latency
    • Histogram of RTT RTT is concentrated between 500-700ms for short pings
    • Histogram of RTT RTT is concentrated between 900-1000ms for large pings
    •