Challenges and Opportunities in Providing Wireless Data Services in 3G Wireless Networks


1
Challenges and Opportunities in Providing
Wireless Data Services in 3G Wireless Networks
Dr. Sanjoy Paul (sanjoy_at_bell-labs.com) Research
Director Bell Laboratories Research Lucent
Technologies
2
Outline

• Introduction
• Challenges in
• Consumer segment
• Data Performance
• Enterprise segment
• Security
• Conclusion

3
Introduction
4
Wireless Standards Evolution to 3G
2G
2.5G
1G
3G/ IMT-2000 Capable
Existing Spectrum New Spectrum
IS-95-A/ cdmaOne
IS-95-B/ cdmaOne
Analog AMPS
1XEV DO HDR (1.25 MHz)
IS-136 TDMA
136 HS EDGE
TACS
GSM GPRS
EDGE
GSM
UMTS (WCDMA)
HSCSD
5
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

6
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
7
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
8
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
9
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

10
Outline

• Introduction
• Challenges in
• Consumer segment
• Data Performance
• Enterprise segment
• Security
• Conclusion

11
Challenges in Consumer Segment
12
End-to-End Architecture for CDMA2000 Network
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

13
Wireless Data Accelerators

• Speed up users 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)
14
Wireless Data Accelerators
15
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

16
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

17
Latency Reduction
Speedup Average / Max
x 2.74 / x 5.67

• 100 KB Web page through 1xRTT (application-level
  throughput40 Kbps)
• No data accelerator 20 sec
• Data accelerator 5 sec

18
Image Quality
4 seconds at 150Kbps original JPEG 50k bytes
4 seconds at 30kbps optimized JPEG 10k bytes
Wireline over Wireless
19
Wireless Data Accelerators
20
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

21
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
Internet
image
sports.cnn.com
a796.g.akamai.net
22
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.

23
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 clients browser
• 90 of all proxy deployments are in transparent
  mode
• (browser doesnt need to be explicitly configured
  to use the proxy)

24
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

25
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

26
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
27
DNS Response Rewriting
Caching Proxy 10.0.0.12
www.foo.com 193.123.25.10
DNS Rewriting Proxy
DNS Server
28
Comparison with other Techniques
29
Experimental Set-up
Apache Web Server (Virtual Hosting) www.cnn.com ww
w.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)
30
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
31
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

32
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
33
Results User Perceived Response Time (average
cell)
30
33
32
34
26
26
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
34
Results User Perceived Response Time (congested
cell)
49
50
53
55
48
55
Session-level optimizations provide an
improvement of up to 55 DNS Response Re-writing
and Url Re-writing provide similar benefits
35
Results HTTP Throughout (average cell)
36
36
51
50
44
48
36
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)
37
Wireless Data Accelerators
38
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

39
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

40
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

41
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

42
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

43
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

44
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

45
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

46
Wireless Data Accelerators
47
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

48
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
49
How to deal with delay spikes Naïve Solution
20
20
Inject delay every 10 RLP frames
20
20

BSC
PDSN
PCF
I N T E R N E T
MT
TE
GRE Session
GRE Session
Rm interface
RLP Session
BTS
TCP
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
20
2
50
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

51
An Enhanced Delay-Jitter Algorithm (Leung/Klein)

• Key Observation
• For typical applications not much
  fragmentation from TCP/IP to PPP
• Most of fragmentation occurs between PPP and RLP

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

52
Enhanced Delay Jitter Algorithm
Inject delay every n PPP frames
20
20
20
20
BSC
PDSN
PCF
I N T E R N E T
MT
TE
GRE Session
GRE Session
Rm interface
RLP Session
BTS
TCP
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
20
2
53
Enhanced Delay Jitter Algorithm (more)

• Different versions
• Fixed time fixed delay (FTFD) inject delay
  according to schedule i.e. inject delay D0 every
  N packets.
• Random time fixed delay (RTFD) inject fixed
  delay D0 to every packet with probability p1/N.
• Random time random delay (RTRD) inject delay
  to every packet with certain probability p1/N
  injected delay is chosen according to some pdf
  with mean D0 (in simulations chose exponential
  distribution).

54
Effect of Enhanced Delay Jitter (EDJ) Algo on TCP
Timeouts
Injecting 100ms delay does not reduce timeouts
Timeouts Without EDJ algo
Injecting 200ms delay reduces timeouts
Timeouts Without EDJ algo
55
Effect of Enhanced Delay Jitter Algorithm on TCP
Timeouts
Injecting 300ms delay every N2/3/4 samples
reduces timeouts Bad choice of Parameters
can Increase the of timeouts
Timeouts Without EDJ algo
Injecting 400ms delay every N2/3/4 samples
reduces timeouts Bad choice of Parameters
can Increase the of timeouts
Timeouts Without EDJ algo
56
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
57
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 D0 p) needs to
  be worked out

58
Summary of Performance Enhancement Opportunities
Source Inktomi Corporation
59
Outline

• Introduction
• Challenges in
• Consumer segment
• Data Performance
• Enterprise segment
• Security
• Conclusion

60
Challenges in Enterprise Segment
61
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
62
Two choices for Virtual Private Network (VPN)
End-to-end IPSec tunnel
INTERNET
IP Service Switch/ PDSN
Firewall
VPN Gateway
Split Ipsec tunnels
Split Ipsec tunnels
63
End-to-End IPSec-based VPN
Enterprise VPN Gateway
Subscriber Access Terminal
PDSN
Application Data
Application Data
encrypt
decrypt
Application Header
Application Header
TCP
TCP
IP
IP
Intermediate Nodes See only encrypted headers/data
Encryption at Client
Decryption at VPN Gateway

• Todays 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

64
Network-based Split IPSec VPN
Enterprise VPN Gateway
Subscriber Access Terminal
PDSN
decrypt
encrypt
encrypt
decrypt
IPSec
IPSec
IP
IP
Encryption at Client
Intermediate Nodes Header/Data exposed
Decryption at VPN Gateway

• 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

65
Dilemma for a Wireless Carrier
Wireless access
Internet
PDSN
Corporate WAN
VPN Gateway
Packet Core
BTS
Encrypted IPSec tunnel forming a Virtual Private
Network

• 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

66
Adaptive VPN
User
Carrier Network
Enterprise
Carrier Network
Enterprise
User

• End-to-end security for all applications and
  users
• Network cannot enable any new service

• User data come in clear inside Carriers IPSS
• Network enables new services for all users

End-to-end VPN
Network-based VPN
End-to-end security
Network-based Services
Adaptive VPN
Value-added services based on IP TCP and
application level headers and application data
Flexibility in providing different VPN services
to different application/user
User
Carrier Network
Enterprise

• End-to-end security for some applications/users
• Network enabled new services for some
  applications/users

67
User-based and Application-based Adaptive VPN
End-to-End VPN
Network-based VPN
Example
Officer_at_Company
Firewall
VPN Gateway
Executive_at_Company
IP Service Switch
End-to-end Tunnel
Split Tunnel
Staff_at_Company
68
Policy Download with Adaptive VPN
Selection criteria
VPN End-point
Dest IP All TCP port All
135.180.144.254
Dest IP 192.168.5.0/24 TCP port 25 80 Dest
IP All TCP Port All
135.180.144.254
135.180.244.150
AAA/LSMS
Dest IP All TCP Port All
135.180.244.150
Firewall
135.180.244.150
135.180.144.254
VPN Gateway
IP Service Switch
Executive _at_company
192.168.5.0/24
End-to-end Tunnel
Split Tunnel
Mail Server (Port 25)
Web server (Port 80)
69
Adaptive VPN Demo
Enterprise Network
192.168.5.0/24
Enterprise VPN Gateway LVF Brick
Tunnel A
Local Presence IP 192.168.5.10 Hosts behind
tunnel 192.168.5.0/24
135.180.144.254
Tunnel A
Physical IP 130.160.140.17
Network VPN Gateway
Tunnel C
Client
129.180.244.15
Hosts behind tunnel 192.168.3.0/24
Tunnel B
192.168.3.0/24
Local Presence IP 192.168.1.10 Hosts behind
tunnel 192.168.1.0/24 192.168.3.0/24
192.168.1.0/24
70
Multi-Layer IPSec (ML-IPS)
Enterprise VPN Gateway
Subscriber Access Terminal
PDSN
decrypt
encrypt
encrypt
decrypt
IPSec
IPSec
IPSec
IPSec
IP
IP
IP
IP
Encryption at Client
Intermediate Nodes Headers exposed Enterprise
Data protected
Decryption at VPN Gateway

• Enterprise data is encrypted end-to-end (Protocol
  headers exposed to carrier)
• Many network-based enhancements/services are
  possible

71
Multi-Layer IPSec (ML-IPS) Evolution of IPSec
Example outgoing packets
End2End Key Encryption
ftp header. TCP IP
video RTP hdr. UDP IP
Capability added w/ ML-IPS
Data Applic. Hdr. TCP IP
ML-IPS Client or VPN GW
Rules Engine
web HTTP hdr. TCP IP
ML-IPS supports Split E2E IPSec options
Carrier Key Encryption
video RTP hdr. UDP IP
Expanded Rules Engine
Packet Splitting
Two Key Encryption
Per packet options
trusted to carrier
Secure end-to-end
Benefits

• 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

72
Summary of Security Options for VPN
Adaptive-VPN
ML-IPS
Today End-to-End IPSec
Network-based Services
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
73
An example of a futuristic application
74
Converged voice/data/streaming video service
across CDMA/UMTS and Landline connection
Lets see if the kids are okay.
We need to buy some flowers for the party. Let me
show you a few bouquets.
How about this Do you like the vase
CDMA
Call
Data Connection
Party 1 Dad
Voice Connection
Video Connection
Voice Connection
75
Another Converged Service Example Expert on Call
Streaming Media Real-time voice Best Effort
Data Convergence
76
Outline

• Introduction
• Challenges in
• Consumer segment
• Data Performance
• Enterprise segment
• Security
• Conclusion

77
Conclusion

• Challenges for 3G Wireless Data Services (being
  explored)
• Improving Data Performance
• Preserving Security while providing value-added
  services
• Enable QoS-sensitive applications like
  GamingVOIPPush-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

78
BACK UP
79
Browser Issues

• Browser does not reuse persistent connections to
  servers with different domain names and identical
  IP address
• Browsers 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

80
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

81
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.

82
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.

83
Compromise Solution Adaptive VPN
End-to-end tunnel only
Firewall
VPN Gateway
Both end-to-end and split tunnels
IP Service Switch
Split tunnel only
3G Carrier/Public Network
Enterprise
Mobile Users

• 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

84
Adaptive VPNAdded flexibility to Network-based
VPN
Example outgoing packets
A-VPN client Client or VPN GW
End2End Secure No enhancements possible
End2End Tunnel
Rules Engine
web HTTP hdr. TCP IP
Trusted to Carrier enhancements possible
Carrier Tunnel
Expanded Rules Engine
Tunnel Selection
Separate Tunnels
Per packet options
trusted to carrier
Secure end-to-end
Benefit

• 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

Limitation
85
A-VPN implementation with ML-IPSec support is
transparent to client
Terminate packets to port 80
Forward packets to port 25
End-to-end VPN
CPE
Firewall
PDSN/SG
decrypt
encrypt
Network-based VPN

• TCP headers are exposed with IP SuperSec
• Because of this the PDSN can identify
• the application

IPSec
IPSec
IPSec
IP
IP
IP
86
A-VPN client implementation
End-to-end VPN
CPE
Firewall
PDSN/SG
Network-based VPN
Packets to TCP port 80 (Web)
Packets to TCP port 25 (E-mail)
IPSec

• Applications identified using TCP port number
• Client needs to be modified

IP
Tunnel to PDSN
Tunnel to CPE
87
Adaptive VPN Implementation

• Lucent VPN security products modified for
  Adaptive VPN
• Modified IPSec client
• Modified LSMS (Lucent Security Management System)

LSMS
IPSec client
Firewall
VPN Gateway
IP Service Switch
Executive _at_company
End-to-end Tunnel
Split Tunnel
88
Routing Table at the client with Adaptive VPN
One tunnel
Two tunnels

• 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

89
3GPP2 IMS QoS Architecture for Simple IP
Home Access Provider network
HLR
MSC
Broker network
AAA
SO QoS Subscription Authorization
Home IP network
QoS Resource Subscription
AAA
AAA
SIP Header Compression

• Let diffserv CP marking go through
• Remark packet diffserv CP if needed

Policy DB
SDP Service Option (SO) Mapping BLO
CSCF
R
SDP QoS Subscription Authorization
Diffserv aware
Diffserv marking
RAN
PDSN
R
R
QoS Interworking Diffserv CP
MS
PDF/CQM
SIP/RTP Header Compression
PDFPolicy Decision Function CQM Core QoS
Manager
90
CDMA 2000 Network Architecture
BSC
PDSN
PCF
I N T E R N E T
MT
TE
GRE Session
GRE Session
RLP Session
Rm interface
TCP
20
BTS
IP
20
PPP
RLP
20
2
Air Interface
Rm
Abis
A8/A9
A10/A11
TCP
TCP
UDP
UDP
IP
IP
IP
IP
PPP
PPP
GRE
GRE
WAN
WAN
WAN
RLP
RLP
IP
IP
Low-Level
Low-Level
Interface
Interface
IS2000
PP
PP
T1
T1
IS2000
TE
BSC
BTS
PCF
PDSN
router
MT
TE
91
RTT Histogram with Delay Jitter Algorithm
92
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/image
  s/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

93
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

94
Histogram of RTT
RTT is concentrated between 500-700ms for short
pings
95
Histogram of RTT
RTT is concentrated between 900-1000ms for large
pings
96
(No Transcript)