3G, Wireless Data Services in #G Wireless Networks

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

Dr. Sanjoy Paul Dr. Sanjoy Paul (([email protected])Research DirectorResearch DirectorBell Laboratories ResearchBell Laboratories ResearchLucent TechnologiesLucent Technologies

mailto:[email protected]

2

OutlineOutline

Introduction

Challenges in o Consumer segment

Data Performanceo Enterprise segment

Security

Conclusion

3

IntroductionIntroduction

4

3G/ IMT-2000 Capable

Existing Spectrum New Spectrum

IS-95-A/cdmaOne

IS-95-A/cdmaOne

IS-95-B/cdmaOne

IS-95-B/cdmaOne

IS-136TDMA

IS-136TDMA

136 HSEDGE

136 HSEDGE

GSMGSM

GSM GPRSGSM GPRS EDGEEDGE

UMTS(WCDMA)

UMTS(WCDMA)

cdma2000 1X (1.25 MHz)

cdma2000 3X (5 MHz)

HSCSDHSCSD

1XEV DO: HDR (1.25 MHz)1XEV DO: HDR (1.25 MHz)

2G “2.5G”

Wireless Standards Evolution to 3GWireless Standards Evolution to 3G

1G

AnalogAMPS

AnalogAMPS

TACSTACS

5

Current State of the Wireless MarketCurrent 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

In 2005 W. Europe will have over 410M mobile subscribers reaching 87% penetration

80%87%

-

100.00

200.00

300.00

400.00

500.00

95 96 97 98 99 00 01 02 03 04 05

Millio

ns o

f S

ub

s

0%

15%

30%

45%

60%

75%

90%

105%

Pen

etr

ati

on

W. Europe Subs

End Year Penetration

Western Europe Wireless SubscribersWestern Europe Wireless Subscribers

W. Europe 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005Subs (Millions) 22.0 34.1 53.1 166.5 261.3 309.6 349.3 372.6 388.8 400.5 411.5 Net Adds (Millions) 7.9 12.0 19.0 113.4 94.8 48.3 39.7 23.2 16.2 11.7 11.0 % Change y/o/y 56% 54% 56% 214% 57% 19% 13% 7% 4% 3% 3%End Year Penetration 5% 8% 12% 37% 57% 67% 76% 80% 83% 85% 87%Incremental Penetration 3% 4% 25% 21% 10% 8% 5% 3% 2% 2%

The Strategies Group W. European Data Bank – March 2003

7

U.S. Wireless SubscribersU.S. Wireless Subscribers

0

20

40

60

80

100

120

140

160

180

1995 1996 1997 1998 1999 2000 2001E 2002E 2003E

0%

10%

20%

30%

40%

50%

60%

Subscribers

Ending Penetration

1995 1996 1997 1998 1999 2000 2001E 2002E 2003EEnding subs (millions) 33.8 44.0 55.3 69.2 86.0 109.5 129.9 149.8 167.3Net 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

8

Source: Pyramid Research

0

25

50

75

100

1997 1998 1999 2000 2001 2002 2003 2004 2005 2006

AR

PS

(U

S$

/mo

nth

)

North America Latin America Western Europe

CEE Asia Pacific Africa/Middle East

Rapidly Declining Voice ARPURapidly 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

9

Consumer vs Enterprise CustomerConsumer 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

OutlineOutline

Introduction



Security

Conclusion

11

Challenges in Challenges in Consumer SegmentConsumer Segment

12

End-to-End Architecture for CDMA2000 NetworkEnd-to-End Architecture for CDMA2000 Network

Internet PDSN

Packet Core

BTS

Wireless accessServersServers

MSC/ RNCMSC/ RNCPCFPCF

Q: How can the carriers improve throughput and response time?

End-to-End TCP/IP ConnectionPPP 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

13

Wireless Data AcceleratorsWireless 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)

14

Wireless Data AcceleratorsWireless Data Accelerators


(e.g. compression)

TCP Optimizations


MAC optimizations

(e.g. Qos, FEC)


(e.g. DNS response rewriting, url rewriting)

15

Application OptimizationsApplication 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 FactorsData 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

17

Latency ReductionLatency Reduction

x 2.74 / x 5.67

Speedup

Average / Max

Speedup Distribution

.00%

20.00%

40.00%

60.00%

80.00%

100.00%

0 1 2 3 4 5 6 7 8

Speedup

CD

F

•100 KB Web page through 1xRTT (application-level throughput=40 Kbps)

•No data accelerator: 20 sec•Data accelerator: 5 sec

18

Image QualityImage Quality

4 seconds at 150Kbpsoriginal JPEG 50k bytes

4 seconds at 30kbps optimized JPEG 10k bytes

“Wireline over Wireless”

19



(e.g. compression)

TCP Optimizations


MAC optimizations

(e.g. Qos, FEC)



20

Session Optimizations (Problem overview)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

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)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

22

Session OptimizationsSession 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

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 ProxyExplicit Proxy

24

Bundling ContentBundling 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 OptimizationOur 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 RewritingUrl 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 proxyAvoids DNS look-upReuses 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)

27

DNS Response RewritingDNS Response Rewriting

www.foo.com193.123.25.10

Caching Proxy

10.0.0.12

DNS Server

Name: www.foo.comIP: ???

(1)

Name: www.foo.com IP: ???

(2)

Name: www.foo.comIP: 193.123.25.10TTL: 10 sec

(3)

Name: www.foo.comIP: 10.0.0.12TTL: 1 dayIP: 193.123.25.10TTL: 10 sec

(4)

DNS Rewriting

Proxy

(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.1Host: www.foo.com

(11)(12)

28

Comparison with other TechniquesComparison with other Techniques

Explicit Proxy

URL Rewriting

DNS Response Rewriting

Content-Bundling

Free from Browser Configuration

No Yes Yes No

No Client-Side Component required

Yes Yes Yes No

Works with traditional caching proxies

Yes Yes (with very

minimal change)

Yes No

29

Experimental Set-upExperimental Set-upApache Web Server

(Virtual Hosting)www.cnn.com

www.yahoo.comwww.britannica.com

Top 100 URLsDNS Server

Squid Caching Proxy

(Transparent Mode)

Client Mobile Node(Mozilla Browser)

Internet

WiDSE (1xRTT)

Transparent

redirection

URL rewritingDNS rewriting

proxy

30

Performance Improvement SummaryPerformance 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 time50 – 100 % increase in throughput

31

Experimental DetailsExperimental 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 RequestsResults: 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%

Top 100 URLs

0

200

400

600

800

1000

1200

DNSRW URLRW NULL

Session Level Optimization Technique

Nu

mb

er o

f T

CP

Co

nn

(o

r)

DN

S R

equ

ests

TCP Connections

DNS Requests

33

Results: User Perceived Response Time (Results: User Perceived Response Time (averageaverage cell) cell)

Response Time. Average Cell(RTT = 400 msec)

0

5

10

15

20

25

30

35

40

45

DNSRW URLRW NULL


Re

sp

on

se

Tim

e (

se

c)

CNN

Yahoo

Britannica

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

34

Results: User Perceived Response Time (Results: User Perceived Response Time (congestedcongested cell) cell)

Session-level optimizations provide an improvement of up to 55%

DNS Response Re-writing and Url Re-writing provide similar benefits

Response Time. Congested Cell(RTT = 600 msec)

0

10

20

30

40

50

60

70

DNSRW URLRW NULL


Re

sp

on

se

Tim

e (

se

c)

CNN

Yahoo

Britannica55%

48%

49% 50%

55%

53%

35

Results: HTTP Throughout (Results: HTTP Throughout (averageaverage cell) cell)

Throughput. Average Cell(FTP Throughput = 78 Kbps)

0

10

20

30

40

50

60

70

80

DNSRW URLRW NULL


Th

rou

gh

pu

t (K

bp

s)

CNN

Yahoo

Britannica

51%36%

44%

50%36%

48%

36

Results: HTTP Throughout (Results: HTTP Throughout (congestedcongested cell) cell)

Throughput. Congested Cell(FTP Throughput = 56 Kbps)

0

10

20

30

40

50

60

DNSRW URLRW NULL


Th

rou

gh

pu

t (K

bp

s)

CNN

Yahoo

Britannica

124%93%

98%101%

126%

117%

Session-level optimizations provide more improvement when network conditions

worsen (95%-125% improvement in throughput)

37



(e.g. compression)

TCP Optimizations

(e.g. Delay-jitter algorithm, ACK regulator )

MAC optimizations

(e.g. Qos, FEC)



38

TCP and Wireless NetworksTCP 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

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

42

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)

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

• 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

45

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

46



(e.g. compression)

TCP Optimizations

(e.g. Delay-jitter algorithm, ACK regulator )

MAC optimizations

(e.g. Qos, FEC)



47

TCP Timeout ProblemTCP 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 NetworkRTT / RTO in a 3G Network

0 10 20 30 40 50 60 70 80 90 1000

500

1000

1500

2000

2500

3000

Packet Index

RT

T /

RT

O (

ms

ec

)

RTTRTO

Timeouts

ms

RTO = Estimated RTT + 4 * RTT DeviationDelay spikes lead to Timeouts; cutting TCP window to 1

RTO = RetransmissionTime OutRTT = Round Trip Time

49

BSC PDSNPCFMTTE Rm interface

BTS

INTERNET

RLPSession

GRESession

GRESession

20

20

202

TCP

IP

PPP

RLP

How to deal with delay spikes? How to deal with delay spikes? Naïve SolutionNaïve Solution

10

1010

20 20

20 20

…

Inject delay every10 RLP frames

RTO = Estimated RTT + 4 * RTT DevInjecting artificial delay increases RTT DevThis increases RTO and thus Avoids TCP timeouts Prevents loss of TCP throughput

50

Drawbacks of the Naïve SolutionDrawbacks 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

• 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 An Enhanced Delay-Jitter Algorithm (Leung/Klein)(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

52


BTS

INTERNET

RLPSession

GRESession

GRESession

20

20

202

TCP

IP

PPP

RLP

Enhanced Delay Jitter AlgorithmEnhanced Delay Jitter Algorithm

10

1010

20 20

20 20

Inject delay every“n” PPP frames

RTO = Estimated RTT + 4 * RTT DevInjecting artificial delay increases RTT DevThis increases RTO and thus Avoids TCP timeouts Prevents loss of TCP throughput

10

53

Enhanced Delay Jitter Algorithm (more)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 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 D0 (in simulations, chose exponential distribution).

54

100

101

102

0

50

100

150

200

250

300D

0 = 100 msec

Fixed or Average Jitter Period

To

ta

l N

um

be

r o

f T

ime

ou

ts

FTFD RTFD RTRD

100

101

102

0

50

100

150

200

250

300

350

400

450

500D

0=200 msec


To

ta

l N

um

be

r o

f T

ime

ou

ts

FTFDRTFDRTRD

Effect of Enhanced Delay Jitter (EDJ) Algo on TCP TimeoutsEffect of Enhanced Delay Jitter (EDJ) Algo on TCP Timeouts

Injecting 100ms delay does not reduce # timeouts

Injecting 200ms delay reduces # timeouts

TimeoutsWithoutEDJ algo


55

100

101

102

0

100

200

300

400

500

600D

0=300 msec


To

ta

l N

um

be

r o

f T

ime

ou

ts

FTFD RTFD RTRD

100

101

102

0

100

200

300

400

500

600

700

800

900

1000D

0=400 msec


To

ta

l N

um

be

r o

f T

ime

ou

ts

FTFD RTFD RTRD

Effect of Enhanced Delay Jitter Algorithm on TCP TimeoutsEffect of Enhanced Delay Jitter Algorithm on TCP Timeouts

Injecting 300ms delay every N=2/3/4 samples reduces # timeouts

Bad choice ofParameters canIncrease the # oftimeouts

Injecting 400ms delay every N=2/3/4 samples reduces # timeouts

Bad choice ofParameters canIncrease the # oftimeouts



560 10 20 30 40 50 60 70 80 90 1000

500

1000

1500

2000

2500

3000

3500

Packet Index

RT

T /

RT

O (

ms

ec

)

RTTRTO

Timeout

0 10 20 30 40 50 60 70 80 90 1000

500

1000

1500

2000

2500

3000

Packet Index

RT

T /

RT

O (

ms

ec

)

RTTRTO

Timeouts

RTT/RTO with and without Enhanced Delay Jitter AlgorithmRTT/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 AlgorithmSummary 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 OpportunitiesSummary of Performance Enhancement Opportunities

Layer Enhancement Opportunity Sample applications Speedup

Application

+

Session

Context sensitive image compression and/or transcoding

Web, PowerPoint, Word processor

Up to 300-400%Text compression Web, Word processor

Application header removal and/or compression

Web, Email

Proxy for cookies Web

DNS lookup optimization Web

Transport

TCP Performance Enhancements such as Ack Regulator, Snoop, I-TCP, M-TCP

Web, Email, File Transfer 20-50%

TCP/IP Header compression Web, Email, File Transfer

Internet Offload, Service differentiation Multiple classes of service

* Source: Inktomi Corporation

59

OutlineOutline

Introduction



Security

Conclusion

60

Challenges in Challenges in Enterprise SegmentEnterprise Segment

61

Business Services are projected to grow strongly

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

Business oriented high-speed data services for enterprise Business oriented high-speed data services for enterprise intranet/extranet access will drive demand for 3G and surpass voiceintranet/extranet access will drive demand for 3G and surpass voice

Carriers will need to provide Virtual Private Network (VPN) servicesCarriers will need to provide Virtual Private Network (VPN) services

UMTS Forum: 2001

62

Two choices for Virtual Private Network (VPN)Two choices for Virtual Private Network (VPN)

IP Service Switch/PDSN VPN

Gateway

Firewall

End-to-end TunnelSplit Tunnel

End-to-end IPSec tunnel

Split Ipsec tunnels

End-to-End IPSec Tunnel-based VPN Network-based Split IPSec VPN

Carrier provides simple transport Carrier provides value-added services like aggregation

Carrier charges flat rate Carrier charges premium for value-added services

Split Ipsec tunnels

INTERNET

63

End-to-End IPSec-based VPNEnd-to-End IPSec-based VPN

PDSN

AT

SubscriberAccess Terminal

EnterpriseVPN Gateway

Decryption at VPN Gateway

IP

TCP

ApplicationHeader

ApplicationData

IP

TCP

ApplicationHeader

ApplicationDataencrypt decrypt

Encryption at ClientIntermediate Nodes

See only encrypted headers/data

IP

TCP

ApplicationHeader

ApplicationData

IPSec

IP

IP

TCP

ApplicationHeader

ApplicationData

IPSec

IP

IP

TCP

ApplicationHeader

ApplicationData

IPSec

IP

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

64

Network-based Split IPSec VPNNetwork-based Split IPSec VPN

PDSN

AT




encrypt decrypt

Encryption at Client Intermediate NodesHeader/Data exposed

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

IPSec

IP

IP

TCP

Applic.Header

Applic.Data

IP

TCP

Applic.Header

Applic.Data

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

65

Dilemma for a Wireless CarrierDilemma for a Wireless Carrier

Encrypted IPSec tunnel forming a Virtual Private Network

CorporateWAN

VPNGateway

Internet PDSN

Packet Core

BTS

Wireless access

MSC/ RNCMSC/ RNCPCFPCF

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 VPNAdaptive 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

Networ

k-bas

ed Ser

vicesEnd-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

67

User-based and Application-based User-based and Application-based Adaptive VPNAdaptive VPN

IP Service Switch

VPN Gateway

Firewall


Executive@Company

Officer@Company

Staff@Company

AAA

Application Officer Executive Staff

E-mail

Web

other

Example:

End-to-End VPN

Network-based VPN

68

Policy Download with Adaptive VPNPolicy Download with Adaptive VPN

IP Service Switch

VPN Gateway

Firewall


AAA/LSMS

135.180.144.254135.180.244.15

0

NAI

Officer@company

Executive@company

Staff@company

Selection criteria

Dest IP: AllTCP port: All

Dest IP: 192.168.5.0/24TCP port: 25, 80

Dest IP: AllTCP Port: All

Dest IP: AllTCP 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)

69

Adaptive VPN DemoAdaptive 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 IP192.168.5.10Hosts behind tunnel

192.168.5.0/24

Tunnel A

Local Presence IP192.168.1.10Hosts behind tunnel

192.168.1.0/24192.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

70

Multi-Layer IPSec (ML-IPS)Multi-Layer IPSec (ML-IPS)

PDSN

AT




encrypt decrypt

Encryption at Client Intermediate NodesHeaders exposed

Enterprise Data protected

IP

TCP

Applic.Header

Applic.Data

IPSec

IP

IP

TCP

Applic.Header

Applic.Data

IP

TCP

Applic.Header

Applic.Data

decrypt encrypt

IP

TCP

Applic.Header

Applic.Data

IPSec

IP

IP

TCP

Applic.Header

Applic.Data

IPSec

IP

IP

TCP

Applic.Header

Applic.Data

IPSec

IP

IP

TCP

Applic.Header

Applic.Data

IPSec

IP

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 IPSecMulti-Layer IPSec (ML-IPS): Evolution of IPSec

ExpandedRules Engine

End2End KeyEncryption

Carrier KeyEncryption

Data

Applic. Hdr.

TCP

IP

Data

Applic. Hdr.

TCP

IP

RulesEngine

ftp

header.

TCP

IP

web

HTTP hdr.

TCP

IP

PacketSplitting

Two KeyEncryption Per packet options

Example outgoing packets

ML-IPSClient or VPN GW

video

RTP hdr.

UDP

IP

Capabilityadded w/ML-IPS

ML-IPSsupports

Split & E2EIPSec 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

email

header

TCP

IP

video

RTP hdr.

UDP

IP

72

Summary of Security Options for VPNSummary 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

Possible for all traffic, with end-to-end security preserved

Possible for some traffic, end-to-end security not preserved

Not possible

Network-based Services TodayEnd-to-End IPSec

73

An example of a futuristic application

74

Landline

Party 1 Dad

Converged voice/data/streaming video service across Converged voice/data/streaming video service across CDMA/UMTS and Landline connectionCDMA/UMTS and Landline connection

CDMA

Let’s see ifthe kids are

okay.

Party 3Day Care

Voice ConnectionVideo Connection

We need to buy some flowers for the party. Let me show you a

few bouquets.

Data Connection

I like the roses.Can I have themIn a different vase?

How about this? Do you like the

vase?

This is perfect!

Party 2 Mom

UMTS

1-800-Flowers. How can I help you?

DoneNext Call

Voice

Connection

DoneNext CallCall

75

Something doesn’t seem right. Am I testing the right circuit? This is the one I’mworking on.

Less experienced technician at field site #1.

No, that’s not the correctone. Scan to the left, I’ll tell you to stop whenyou get to the right spot.

Expert technician at field site #2.

Another Converged Service Example: Expert on CallAnother Converged Service Example: Expert on CallStreaming Media, Real-time voice, Best Effort Data Convergence

76

OutlineOutline

Introduction



Security

Conclusion

77

ConclusionConclusion

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

78

BACK UP

79

Browser IssuesBrowser 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

80

More on Session OptimizationMore 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 DisconnectionTemporal 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 ReleaseFrequent 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 VPNCompromise 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 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

• 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

• Terminates any secure tunnel • Oblivious to different tunnels

3G Carrier/Public Network EnterpriseMobile Users

84

Adaptive VPN:Adaptive VPN:Added flexibility to Network-based VPNAdded flexibility to Network-based VPN

ExpandedRules Engine

End2EndTunnel

CarrierTunnel

Data

Applic. Hdr.

TCP

IP

RulesEngine

web

HTTP hdr.

TCP

IP

email

header

TCP

IP

TunnelSelection

SeparateTunnels Per packet options

Example outgoing packetsA-VPN clientClient 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

85

A-VPN implementation with ML-IPSec A-VPN implementation with ML-IPSec support is transparent to clientsupport is transparent to client

PDSN/SG

Network-based VPN

CPEFirewall

End-to-end VPN

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

decrypt encrypt

IP

TCP

Applic.Header

Applic.Data

IPSec

IP

IP

TCP

Applic.Header

Applic.Data

IPSec

IP

IP

TCP

Applic.Header

Applic.Data

IPSec

IP

Terminate packetsto port 80

Forward packetsto port 25

86

A-VPN client implementationA-VPN client implementation

PDSN/SG

Network-based VPN

CPEFirewall

IP

TCP

Applic.Header

Applic.Data

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 toPDSN

Tunnel toCPE

87

Adaptive VPN ImplementationAdaptive 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


Executive@company

LSMS

IPSecclient

88

Routing Table at the client with Adaptive VPNRouting 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

89

3GPP2 IMS QoS Architecture for Simple IP3GPP2 IMS QoS Architecture for Simple IP

External IP NetworkDiffserv Aware

RAN

MS

R R

R

PL

R-P

Airlink

MAC

LAC

SIP/RTPSIP/RTP

UDPUDP

IPIP

PL

Link Layer

PL

R-P

PPP

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

SS7 NetworkSS7 Network

IP Network

Home Access Provider network

Broker network

AAA

SIP/RTP Header Compression

SDP Service Option (SO)

Mapping + BLO

Policy DB

QoS ResourceSubscription

CSCF

SIP Header Compression

Remote Host

Airlink

MAC

LAC

PPP

IP

UDP

SIP/RTP

MSC

PDSN

SDP QoS Subscription Authorization

AAA

PDF/CQMQoS

InterworkingDiffserv CP

PDF=Policy Decision FunctionCQM = Core QoS Manager

90

Low-Level

Interface

PPP

IP

TCPUDP

IS2000

RLP

PPP

IP

IS2000 PP PP

RLP

T1

IP

T1

IPWAN

IP

TCPUDP

WANLow-Level

Interface


IP

WANGRE GRE

T1

IPGRE

TE MT BSCBTS PCF PDSN TErouter

Rm Abis A8/A9 A10/A11Air

Interface

BTS

INTERNET

RLPSession

GRESession

GRESession

20

20

202

TCP

IP

PPP

RLP

CDMA 2000 Network ArchitectureCDMA 2000 Network Architecture

10

91

RTT Histogram with Delay Jitter AlgorithmRTT Histogram with Delay Jitter Algorithm

400 500 600 700 800 900 10000

100

200

300

400

500

600Histogram of RTT

msec

Nu

mb

er o

f O

ccu

rren

ces

no delay jitterFTFDRTFDRTRD

Fixed or Average Delay: D0=300 msec

Fixed or Average Jitter Period: N=2

92

Url RewritingUrl 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

93

DNS Response RewritingDNS 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 RTTHistogram of RTT

RTT distribution (32 bytes)

0

100

200

300

400

500

600

400 600 800 1000 1200

RTT is concentrated between 500-700ms for short pings

95

Histogram of RTTHistogram of RTT

RTT distribution (300 bytes)

0

200

400

600

800

1000

1200

800 900 1000 1100 1200 1300 1400

RTT is concentrated between 900-1000ms for large pings

96

Documents

3G, Wireless Data Services in #G Wireless Networks