Performance Optimisation of 3G Services

Anne Hathaway's cottage

Title:
Performance Optimisation of 3G Services
Author: David Bond – david@fizmez.com
Company: Fizmez
Report type: White paper
Copyright: Fizmez 2004
Subject: Performance Optimisation of 3G services
Date created: 04/27/04
Version: 20040426 0.1 – Initial draft
20040427 0.2 – Structure complete
20040427 0.3 – fizmez style applied, spell check
20040428 0.4 – More content

For more papers on new technologies, see the Fizmez website [1].

This document is open for review. Please send revisions to david@fizmez.com.

© fizmez.com 2004 Page 1 of 11

Performance Optimisation of 3G Services

Table of Contents
Executive Summary.........................................................................................................................3
Introduction......................................................................................................................................4
Scope........................................................................................................................................... 4
Optimization.................................................................................................................................... 5
Capacity implications..................................................................................................................5
Radio performance...................................................................................................................... 5
Content navigation...................................................................................................................... 5
HTTP transfers............................................................................................................................ 6
Caching....................................................................................................................................... 7
Streaming.................................................................................................................................... 7
Applications................................................................................................................................ 8
Charging......................................................................................................................................8
Conclusion....................................................................................................................................... 9
Biography.......................................................................................................................................10
References......................................................................................................................................11

© fizmez.com 2004 Page 2 of 11

Performance Optimisation of 3G Services

Executive Summary
When deploying 3G services, consideration must be given to various aspects of service
performance. It is not enough to expect the 3G network to provide fast service by itself. The
services must be designed with a 3G network's characteristics in mind. The key areas that should
be considered are:

• Capacity implications
• Radio performance
• Content navigation
• HTTP transfers
• Caching
• Streaming
• Applications
• Charging

The conclusion gives a full list of recommendations.

© fizmez.com 2004 Page 3 of 11

Performance Optimisation of 3G Services

Introduction
In 2004, the number of operational 3G telcos is increasing. In the UK, Hutchison 3G has been
operating under the brand “3” for over a year. It prides itself in providing “video mobile.” It offers
services aimed primarily at the entertainment market with video streaming and downloads, games,
ringtunes and location-based services. Vodafone has launched a data-oriented 3G service with a
data card offering high-speed Internet access. Vodafone will shortly be introducing 3G handsets
and the other UK operators are not far behind. Though these operators are offering different
services, they are differentiating their service on the “speed” advantage over 2G. While 3G
automatically brings certain benefits to the consumer, there is a large amount of scope for
optimizing the 3G user experience and this document discusses some of the optimizations available.

Scope
This document covers:

• performance optimization of 3G packet switched services

This document does not cover:

• performance optimization of 3G circuit switched services

• 2G, Wireless LAN, DAB, DVB wireless services

For more details of providing services over multiple radio bearers, see Multi-access, the 4G
network [2]

© fizmez.com 2004 Page 4 of 11

Performance Optimisation of 3G Services

Optimization

Capacity implications
When considering performance optimization, it is important to remember the capacity impacts.
Granting a 384kbps bearer to each request for a bearer would give a good experience to the first-
comers and no service at all to subsequent users. It is therefore essential that the policy for
allocation of radio bearers / code space is considered. One policy is to give each new user a 64kbps
DCH. Another policy is to grant 384kbps bearer to the first couple of users, then a series of
128kbps bearers, then 64kbps bearers and finally common channel bearers. This choice will be up
to the radio planners and may vary between regions or even cells. However, a policy must be set.
The radio bearer allocation policy must be carefully set.

Radio performance
In 3G networks, a UE may be in the following states:
• Idle
• Shared/common channel
• Dedicated channel
The policy for changing between these states has implications for both performance and capacity.
The longer spent in dedicated state when no traffic is flowing, the more capacity is being
inefficiently unused. However, in any set of application level data flows, there may be short pauses
due to known user or protocol behaviour. Due to the performance cost of state transitions, it may
be wise to delay the start of the state transition until a time after zero data flow.
The radio bearer state transition policy must be carefully set.
When transferring between radio states, delays of up to 5 seconds are possible due to the
complexities of control channels and RNC internal processes. These delays are periods when no
data can flow. If this occurs at the wrong stage of the process there is a negative impact on
customer experience.
The radio bearer state transition must be as quick as possible.
The radio bearer state transition should ideally occur when data is not flowing.
If TCP packets go missing, retransmission will occur and the flow may be interrupted, even with
advanced TCP options switched on. Missing packets can lead TCP to believe that congestion has
occurred and congestion avoidance mechanisms with kick in. This is to be avoided.
Few (ideally no) PDU's should be lost in radio state transition.

Content navigation
In badly-designed browser-based services the user can spend over 90% of their time trying to find
the content they already know they want. At some point in the users navigation, they will have
made up their mind which asset they wish to view. Once this decision has been made, there may be
3 or more pages between them and the content. This is VERY detrimental to the user experience.
Why not, for example, allow the user to bookmark “today's video news” in the browser's
bookmarks feature and make that a link straight to the video stream? In this manner, the user will

© fizmez.com 2004 Page 5 of 11

Performance Optimisation of 3G Services
have the desired content on their screen within 10 seconds. This also has the additional benefit of
releasing network capacity and thereby raising yield. The key to providing a good user experience
with browser-based services is to take the user through as few navigational steps as possible.
Minimize the navigation required of the user for browser-based services.

HTTP transfers
A large amount of time can be spent by the HTTP client simply setting up TCP sockets for HTTP
transfers. It is therefore recommended that the number of servers contacted by the client be kept to
a minimum. This can be achieved in a few ways:
• Have all content served from one (logical) server
• Serve all content via a proxy
• Provide a “gateway” HTTP service for access to other servers
The proxy architecture is not recommended. Though this may not be an obvious step to mobile
operators who are used to the “gateway” concept of WAP proxies, it is essential for HTTP
transport. Though the handset client may be under the control of the operator for handsets, it will
not be when the user connects their own TE (for example a PDA connected via Bluetooth).
For load balancing, it is tempting to use such mechanisms as multiple servers with the same path
e.g.
• www1.operator.com/games/
• www2.operator.com/games/
In the author's experience, this encourages sloppiness in implementation. Issues of complexity arise
soon afterwards. To give a good example, Google implements one virtual server with a load
balancing scheme that makes it appear as though all searches go via http://www.google.com/ . In
fact, a large server farm supports the Google implementation. It is recommended that operators
follow this strategy for their own HTTP-based portal.
A single logical server should be used for HTTP implementation.
When requesting a HTML page from the server, the page may come back with several assets
embedded (images, CSS, Shockwave etc.). It is efficient to pipeline the request for these images
using HTTP/1.1 pipelining.
HTTP/1.1 pipelining should be implemented on the HTTP client, the transparent proxy cache and
the server.
Due to the long, fat pipe nature of 3G networks (round-trip delays are typically 100-500ms), a large
TCP window size should be used. The maximum recommended without invoking TCP options
fields is 65535 bytes. The client and server should both support this value, though care should be
taken not to overrun buffers.
All HTTP elements should support an TCP window size of 64Kbytes.
The maximum achievable speed of a TCP pipe is related to the TCP round-trip time.
Every effort should be made to reduce the TCP round trip time. This is most heavily a requirement
on the radio network.
The TCP buffer can be effectively grown to improve the transfer characteristics of HTTP by using

© fizmez.com 2004 Page 6 of 11

Performance Optimisation of 3G Services
multiple sockets. Multiple sockets also allow the client to cope in cases where the content is being
delivered from more than one server (for example Internet-based web pages with images delivered
from many servers).
The operator-provided HTTP client should make efficient use of multiple concurrent sockets.
In TCP's slow-start mechanism, the amount of content transferred per packet is a function of the
MTU. MTU should be kept as high as possible to avoid overheads, but mainly to pack as much
content as possible into TCP's slow-start mechanism. On the other hand, packet fragmentation
should be avoided. In most cases, a well-designed web page fore mobile devices can be returned
within four packets (the recommended value of the initial congestion window size).
The MTU should be set as high as possible while avoiding fragmentation.
The initial congestion window should be set as high as possible to boost TCP's slow start
mechanism.

For lost packets, the entire TCP flow can cease until the packet has been re-transmitted. This can
be overcome using selective acknowledgement options.

SACK TCP options should be used.

Caching
In delivering content to the user, it is best if the content already exists on the end device itself. In
this way, no radio network capacity is used and the content is available to the user quickly. This is
easy to implement in HTTP using the cache-control directives. The best way to achieve this is
using the max-age directive. Not only is this easier to implement than explicitly stating an expiry
date for content, it also is insensitive to an incorrectly set real-time clock on the client.
A client-cache strategy should be adopted for all content.
The max-age directive should be used for HTTP.
A key point to be addresses is of network-side caching. It is more efficient to serve content from a
cache than from (for example) a J2EE environment if that content has not changed since the last
time it was accessed. For pages that are highly interactive with the user (form filling, payment
pages, location-based services) this may not be possible, but for ALL other content, the cache
should be used to deliver the content to the user. This will have performance benefits, but also cost-
saving implications. This should be done transparently, so no proxy is configured in the client (See
above).
Static, non-chargeable HTTP content should be served from a transparent cache, controlled using
the max-age directive.

Streaming
When streaming, the stream bandwidths should be carefully chosen so as to fit into the available
bearers. The packet loss characteristics are well understood by the radio planners and the stream
should be optimized for these characteristics. For dynamic rate adaption, the client's feedback
channel should send as much information as possible (though this may be detrimental to battery
life) as the radio uplink is typically empty otherwise and a tighter control loop can then let the
server know immediately about key radio link characteristics.

© fizmez.com 2004 Page 7 of 11

Performance Optimisation of 3G Services
Feedback levels should be high in streaming applications.
When setting up the stream, a protocol such as RTSP will be used. This can be a painfully serial
process and this may delay the stream setup. Wherever possible, RTSP control channel messages
should be pipelined or parallelized.
RTSP control channel messages should be pipelined or parallelized.

Applications
Java, Shockwave and other technologies can be used to provide games, business applications and
other functionality to the mobile user. Lessons may be learned here from the section on HTTP
(caching, pipelining etc.). However it is recommended that for all browser-like applications, the
browser itself is used.

Do not attempt to rewrite a browser in Java.

Instead, Java etc. can be used to provide content to the user where the response time of the
application needs to be fast and/or available when there is no network connection. Such
applications include PIM, games and office applications.

For most applications, the browser experience is familiar to the user. If possible, applications
should run within the browser framework, either as plugins or at the very least such that the normal
back/forward buttons work in coordination with the browser. The same is true of media players. If
the concept of multiple concurrent applications is one that has been chosen for the device, this may
be achieved in the same way as Mozilla's tabbed browsing approach.

Applications should work seamlessly with the browser experience.

If possible, it is a performance optimization for the user NOT to have to wait until they are in
coverage before being able to play a game. If an application MUST connect to the network, cache
these network requests on the handset until the handset is back in coverage. Ideally charge for the
game asset itself, do not change the user for the privilege of running a small application on their
device. It is still possible to change for content by changing the user to download new content
(characters, levels etc.)

Avoid making the application dependent on the radio network.

Do not charge for an application on a per-use basis. Instead charge only for original content.

Charging
All these performance optimizations bring issues for charging. Caching in particular is an issue.
Should you charge for the first attempt to stream content? The second? The third? Do you create
complex charging business logic around the percentage of successfully streamed packets? Unless
you are opting for a walled garden approach, with associated premium prices for content, it is
recommended that content is charged at an appropriate per-byte rate.

Content should be charged “per byte” for non walled-garden content.

© fizmez.com 2004 Page 8 of 11

Performance Optimisation of 3G Services

Conclusion
The following recommendations are made for performance optimization:

• The radio bearer allocation policy must be carefully set.

• The radio bearer state transition must be as quick as possible.
• The radio bearer state transition should ideally occur when data is not flowing.
• Few (ideally no) PDU's should be lost in radio state transition.
• Minimize the navigation required of the user for browser-based services.
• A single logical server should be used for HTTP implementation.
• HTTP/1.1 pipelining should be implemented on the HTTP client, the transparent proxy cache
and the server.
• All HTTP elements should support an TCP window size of 64Kbytes.
• Every effort should be made to reduce the TCP round trip time. This is most heavily a
requirement on the radio network.
• The operator-provided HTTP client should make efficient use of multiple concurrent sockets.
• The MTU should be set as high as possible while avoiding fragmentation.
• The initial congestion window should be set as high as possible to boost TCP's slow start
mechanism.
• SACK TCP options should be used.
• A client-cache strategy should be adopted for all content.
• The max-age directive should be used for HTTP.
• Static, non-chargeable HTTP content should be served from a transparent cache, controlled
using the max-age directive.
• Feedback levels should be high in streaming applications.
• Do not attempt to rewrite a browser in Java.
• Applications should work seamlessly with the browser experience.
• Avoid making the application dependent on the radio network.
• Do not charge for an application on a per-use basis. Instead charge only for original content.
• Content should be charged “per byte” for non walled-garden content.

OK, so I may have strayed from the scope. See the front page for review mechanisms :o)

© fizmez.com 2004 Page 9 of 11

Performance Optimisation of 3G Services

Biography

David Bond MSci

David graduated in 1997 from Nottingham University with a MSci in Physics.

He started work at BT laboratories, Ipswich, initially working in process design for BT's
international 'Alliance Partners.' With the growth in dial-up IP in the late 1990's, he moved into
Dial IP infrastructure design. There he worked on the design of the Q931+ signaling IP network
and the NOC's IP infrastructure. During this time he also studied for a MSc in British
Telecommunication Engineering.

In 2000, the UK government auctioned the 3G radio spectrum licenses and David made the move to
Hutchison 3G, a subsidiary of Hutchison Telecom, the company behind the launch of Orange. With
a completely blank sheet, Hutchison 3G designed, built and launched a 3G network in under three
years. David held responsibility for delivering the end-to-end performance optimization project, as
well as key design roles for handsets, network and services. He also managed end-to-end projects
to document the architecture and to monitor service performance.

In May 2004, he joins Agilent.

David and his wife, Becky, live in Maidenhead. In his spare time enjoys judo, pool, playing alto
saxophone and will never miss an opportunity to go snowboarding.

© fizmez.com 2004 Page 10 of 11

Performance Optimisation of 3G Services

References
[1] fizmez.com website: http://fizmez.com/
[2] “Multi-access, the 4G network” - fizmez.com 2004 http://fizmez.com/

© fizmez.com 2004 Page 11 of 11