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
Version: 20040426 0.1 – Initial draft
20040427 0.2 – Structure complete
20040427 0.3 – fizmez style applied, spell check
20040428 0.4 – More content
20040614 0.5 – Spelling, grammar, style, nonsense removal

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 12

Performance Optimisation of 3G Services

Table of Contents

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

© fizmez.com 2004 Page 2 of 12

Performance Optimisation of 3G Services

Executive Summary
When deploying 3G services, service performance is expected by the customer. However, the 3G
network will not provide fast service by itself. Services must be designed with a 3G network's
characteristics in mind. The key areas that should be considered are:

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

The conclusion gives a full list of recommendations.

© fizmez.com 2004 Page 3 of 12

Performance Optimisation of 3G Services

Introduction
In 2004, the number of 3G operators is increasing. In the UK, Hutchison 3G has been operating
under the brand “3” since 2003/03/03. It prides itself in providing “video mobile.” It offers
services aimed primarily at the consumer market with video streaming and downloads, games,
ringtunes and location-based services. Vodafone has launched a data-oriented PCMCIA 3G service
offering high-speed Internet access for laptop owners. 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 all selling 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 12

Performance Optimisation of 3G Services

Optimization

Capacity
When considering performance optimization, it is important to remember the capacity impacts.
Granting a 384kbps bearer to each bearer request would give a good experience to the first few
users, but no service at all to subsequent users. Radio bearers / code space policies should be
considered. One policy would be 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.
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 such as SACK (see below). Missing packets can lead TCP to believe that
congestion has occurred and congestion avoidance mechanisms will 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 much of their time looking for 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 several clicks
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

© fizmez.com 2004 Page 5 of 12

Performance Optimisation of 3G Services

make that a link straight to the video stream? In this way, the user can have the desired content
quicker. This has the additional benefit of releasing network capacity and thereby raising yield.
With browser-based services, taking the user through as few navigational steps as possible is key.
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 important for HTTP
transport. Though the handset client may be under the control of the operator, it may 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. For 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.

© fizmez.com 2004 Page 6 of 12

Performance Optimisation of 3G Services

The TCP buffer can be effectively grown to improve the transfer characteristics of HTTP by using
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). This value
should be set on the servers, proxies and network caches.
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 acknowledgment 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. The UE
HTTP cache should be as large as feasible. A figure of 1MB is about right for a QVGA handset.
An HTTP cache of at least 1MB should be allocated in the UE.
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 and will save
cost on expensive J2EE boxes. 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

© fizmez.com 2004 Page 7 of 12

Performance Optimisation of 3G Services

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. The radio uplink is typically otherwise empty
and a tighter control loop can then let the server know immediately about key radio link
characteristics.
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 charge the user for the privilege of running a small application on their
device. It is still possible to charge 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

© fizmez.com 2004 Page 8 of 12

Performance Optimisation of 3G Services

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. This will avoid complexity
and avoid an arms race between the operator and customer. For justification of this point, contact
the author or watch “The Great Escape” [3].

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

© fizmez.com 2004 Page 9 of 12

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.
• An HTTP cache of at least 1MB should be allocated in the UE.
• 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 10 of 12

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 11 of 12

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/
[3] Great Escape, The: http://www.imdb.com/title/tt0057115/

© fizmez.com 2004 Page 12 of 12