Escolar Documentos
Profissional Documentos
Cultura Documentos
Document:
Stefan Engels
Version 1.21
www.commsquare.com
info@commsquare.com
The screenshot in figure 7 and 8 are taken with the Actix Analyzer.
Actix Ltd. is a registered company of the UK, www.actix.com.
All rights reserved. No part of this document shall be reproduced, stored in a retrieval system, or
transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without
written permission from the author. While every precaution has been taken in the preparation of this
document, the publisher and author assume no responsibility for errors or omissions. Neither is any
liability assumed for damages resulting from the use of the information contained herein.
The diagram below shows the different stages in GPRS performance analysis and
optimisation.
The initial optimisation step in the GPRS lifecycle is radio & system optimisation.
Once completed, the radio & system performance should be monitored.
For each (major) SW release or HW change, retesting or auditing the performance is needed.
Additional optimisation work might be required, e.g. in case of changes to the radio resource
management algorithm or its parameter settings.
As GPRS system & radio performance can affect application performance we recommend
you perform a sanity check on application performance for major changes to the GPRS
system, e.g. after (major) PCU or SGSN software upgrades.
The diagram below shows the most important processes, network elements and parameters
affecting GPRS performance. Their impact is typically investigated and optimised during the
different stages of GPRS performance analysis and optimisation.
Coverage
Interference
Capacity Radio Resource Management
Cell update Dynamic Link Adaptation
Gi
Server 1 PEP
IP, UDP, TCP performance (slow
start, retransmissions, etc.)
Application behaviour (HTTP
persistent, dynamic web pages,
etc.), packet losses, etc. Internet
Server 2
Server 3
(We recommend this course for engineers involved in GPRS radio & system optimisation.
For the course outline, see our Training Catalogue,
our website www.commsquare.com or the Annex of this document.)
This is the first phase in the GPRS optimisation process. It has the following major goals:
• Validation of the signalling procedures.
• Verification of network element performance.
• Optimisation of GPRS as a bearer service.
System & radio optimisation is usually performed with an application server connected to the
Gi-interface (“server 1” in fig. 1). This ensures that the entire test setup, from client to server,
is under the control of the network operator.
Typical test applications are ping-sequences and FTP file upload & downloads. These
applications are very well suited to test the technical performance of a GPRS network.
These tests will allow you to identify the network elements and processes with poor
performance: is the radio Um interface working fine, is the PCU performance degraded,
is the SGSN dropping packets, what network elements have unstable behaviour, etc.
The test scenarios also allow you to identify the root-cause for most of the problems, and to
define corrective actions.
We highly recommend you perform the system & radio optimisation during the early stages
of the GPRS lifecycle. Early tuning of the GPRS system will ensure early adopters get a
reliable service with good performance and hence will accelerate take-up of GPRS usage. It
will also facilitate the introduction of new GPRS services afterwards and reduce the time to
optimise them.
The tables below contain an example for the GRPS Attach procedure from a Gb trace file.
In addition, the analysis of and comparison with best-practice values for a number of
performance indicators regarding these procedures can be performed (from test mobile log
files). Typical indicators are GPRS attach time, PDP activation time, routing area update time
(during an active GPRS session), etc.
We recommend an in-depth and systematic analysis of the different Gb protocols at this stage.
This is a efficient and useful way to detect all kind of problems, such as stability issues, buffer
overflow problems, poor cell update performance, quality problems on the radio interface, etc.
All protocols (see diagram below), from Network Service (NS) up to SNDCP and GMM&SM
should be analysed in great detail.
Figure 6 contains an example of such a stability problem observed at the Gb-interface. The
cell with identity BVCI=244 is taken out of service (through a BVC Block message) and is
then immediately taken back into service (through a BVC reset message). Roughly 30 sec
later, another cell (with identity BVCI=255) shows the same unacceptable behaviour. The
whole Block & Reset procedure takes less than 20 msec (see column “Time”).
The observed problem will dramatically reduce user-perceived GPRS quality for users on
these cells because all user data for these cells will be deleted from the PCU buffers. It is then
up to the application or TCP to resend the deleted data. This process is often very slow, taking
a few up to 30 sec.
Network elements also often exhibit unreliable and poor performance, e.g. due to SW or HW
bugs. For instance, PCU buffers can overflow and hence drop packets, SGSNs can drop an
excessive number of packets, etc. Again, this will lead to a poor user experience.
The screenshot below shows a TCP packet drop for an FTP download. Packet drops are quite
normal during cell updates/changes or in case of (PCU or SGSN) buffer overflows. However,
for this particular example, the download was performed on a single cell and there weren’t
any buffer size issues (the relevant radio & Gb trace data isn’t shown here).
Instead, it turned out that the SGSN dropped 2% of the incoming packets in a fairly random
way due to a SW bug.
The example below contains the TCP sequence and acknowledgement numbers on the server
and client side:
• (In green): packet is originally sent.
• (In red): packet is not received at client.
• (In purple): client reports the missing packet.
• (In blue): server retransmits the missing packet, which is then received by client.
The goal of GPRS bearer optimising is to ensure that the GPRS network operates close to its
theoretical or best-practice system limits (e.g. in terms of delay and throughput). It involves
tuning of GPRS system parameters and vendor-specific GPRS parameters, such as timeslot
allocation and coding scheme usage.
3.3.1 Throughput
Figure 8 below contains a typical analysis for a file upload using data from a test phone. This
is an example of a perfect file upload:
• RLC Throughput is stable and close to the theoretical maximum (of 13.4 kbps for
coding scheme 2).
• The mobile stays on a single cell, i.e. the CI of the serving cell is the same for the
entire duration of the upload.
• The uplink TFI has stable behaviour.
• The number of timeslots equals the maximum number of timeslots the mobile can
support (only one for this mobile).
• Coding scheme 2 is used all the time, i.e. the highest coding scheme supported in this
network.
• There aren’t any retransmissions. This is an indication of perfect uplink quality.
CI serving cell
UL TFI
UL retransmissions
Delay or latency is usually analysed based on a series of “ping” commands (i.e. ICMP Echo
Request & Reply messages). In order to get a good understanding of delay, it is recommended
to send different ping sequences.
Ping delay
A first type of analysis investigates the “ping delay”, e.g. defined as the time between the
Echo Request and Echo Reply message measured at the client/mobile side. Figure 9 shows
the evolution of the ping delay in one network for different SW releases.
Ping Delay
950 70
897
900 869 60
786
800 40
735 Mean
750 30
Stdev
700 671 679 20
657
650 10
600 0
SW-2 SW-2b SW-3 SW-3b SW-3c SW-4 SW-5
SW Version
Ping signature
Further investigation will reveal the underlying reasons for the different values in ping delay.
The table below shows the “ping signature” for 2 different SW releases in the same network.
The ping signature analysis contains the sequence of RLC/MAC signalling messages needed
to convey a ping command (i.e. a pair of ICMP Echo Request & Reply messages), and the
time between consecutive messages.
The allocation of radio resources (i.e. PDCHs1 or GPRS timeslots) is another important area
of analysis. The quality of the algorithms and their parameter tuning highly affects how close
the operator’s GPRS network can operate to the theoretical GPRS system limits.
Often, timeslot allocation and radio resource usage aren’t optimal because:
• The infrastructure supplier’s radio resource management algorithms aren’t as efficient
or fast as the competition.
• The operator has not tuned these algorithms.
This allows for faster allocation or upgrade of the GPRS resources which is useful for delay-
sensitive services such as WAP.
The table below shows a typical example of a lifetime extension mechanism. The actual
implementation is vendor-specific, but it only uses standard signalling messages. Hence all
types of GPRS mobiles will benefit from this mechanism.
1
PDCH or Packet Data Channel. A PDCH is a timeslot that is allocated for packet-switched traffic, i.e.
GPRS.
2
TBF or Temporary Block Flow. Allocating GPRS resources to a mobile means setting up a “TBF” for
that mobile. In other words, if a mobile has a TBF, it has GPRS resources (or GPRS timeslots or
PDCHs allocated to it).
Service & application optimisation focuses on the actual application, e.g. web browsing,
corporate intra-net access and email, MMS, streaming, etc. The application servers can be
connected directly to the operator’s network (“server 2” in diagram), or can be connected
through the internet (“server 3”).
Even if the GPRS system is optimised, i.e. operates close to its theoretical system limits (see
optimisation phase 1 above), the application performance can be poor. Indeed, it is well
known that GPRS, TCP-based applications and mobility don’t go together very well.
Service & application optimisation is about optimising the user experience. In order to do so,
a detailed technical analysis is required. Service optimisation involves end-to-end analyses of
server & client performance, internet protocols, proxies, performance enhancement proxies
(PEP) or boosters, the radio link performance and internet, core network and radio equipment
performance, etc.
Both system & radio and service & application optimisation require in-depth analysis of radio
log files, TCP/IP sniffer data at client & server and Gb/Gi interface trace files.
Once the GPRS network is tuned and the services are rolled out and optimised, its
performance needs to be monitored.
The operator will define a set of key performance indicators to monitor GPRS radio and
system performance, as well as performance of the different services.
Typical sources for performance monitoring are OMC counters (from BTS, PCU and GSN)
and/or a Gb- and Gi-interface monitoring systems.
Commsquare provides services for all stages of GPRS performance analysis and optimisation.
• Our trainers are experienced engineers with experience in GPRS testing, performance
analysis and optimisation.
• We use your data in guided exercises, e.g. from test mobiles, TCP/IP sniffers and
protocol analysers.
• We perform a training needs analysis and tailor the course accordingly.
• We teach you proven methodologies and strategies on how to test, analyse and
optimise the performance of your GPRS network.
An experienced engineer will spend the necessary time at your premises to help solve a
particular GPRS-related problem, or test a new SW release, or to introduce a new feature, etc.
Often, we perform an entire GPRS optimisation project in close collaboration with your
engineers to ensure knowledge transfer (as described in section 2 of this document).
This type of training or consultancy is run as a project, i.e. with an agreed upon scope,
deliverables, responsibilities and timeline. Knowledge transfer is a key aspect of this type of
service: the project is typically concluded with a workshop for your engineers and a
presentation to your management.
Gb Signalling Analysis
(3 days)
E
D EDGE – GPRS Planning
G and Optimisation (3 days)
E
The following pages contain the outline of the “GPRS Performance Analysis & Optimisation”
course and the “EDGE Planning & Optimisation” course.
The outline is the standard course outline. Please note the course content can be customised
following a training needs analysis.
For the outline of the workshops, please send an email to info@commsquare.com or visit our
website at www.commsquare.com.
Prerequisites This is an advanced training course. The students should have followed a
GPRS system course and have hands-on experience working with GPRS.
Target The course is aimed at radio, system, O&M and quality engineers involved
audience in GPRS planning & optimisation and monitoring of GPRS performance.
Input from All guided exercises will be made using data from the operator’s own
operator network. Therefore, Commsquare needs trace data (from Um, Gb and
sniffer) from the operator according to Commsquare specifications (e.g. file
up- & download with cell update, web browsing session, ping session, etc.).
Goal of course On completion of the training course, the student will be able to explain the
underlying GPRS technology principles and apply them to enhance
performance in a live GPRS network. In particular, the student will
(a) Understand how the different network elements and protocol layers
affect GPRS performance.
(b) Be able to measure, monitor and identify good and poor
performance.
(c) Be able to identify causes for poor performance.
(d) Understand and be able to apply the mechanisms that exist to
improve GPRS performance.
Course content
Day 1 GPRS system overview refresher
• Network model: different network elements & their logical role.
• Protocol stack: different protocol layers & principles of data encapsulation.
• Performance: main procedures, protocols & network elements affecting
performance.
GPRS Mobility & Session Management procedures
• Mobility Management: details of GPRS attach/detach procedures, routing area
update procedure, overview of other procedures.
• Session Management: details of Activate/deactivate PDP context procedure,
overview of other procedures.
• Guided exercises: Um and Gb trace analysis of GMM procedures. Definition of
performance counters (KPI’s).
Radio Link & Medium Access Control
• Air (Um) interface principles: logical channel types, temporary block flow &
TFI, uplink transmission (MAC-mode) and uplink state flag USF, coding
schemes & dynamic link adaptation, MM states and RR modes.
• RLC/MAC: data block format, RLC acknowledged mode of operation, window
stall, countdown procedure, system information, timers T3168 & T3192.
• Signalling: TFI establishment & release, packet transfer procedure, cell update,
one-phase vs. two-phase access, contention resolution, abnormal releases.
Input from All guided exercises will be made using data from the operator’s own
operator network. Therefore, Commsquare needs trace data (from Um, Gb and sniffer)
from the operator according to Commsquare specifications (e.g. file up- &
download with cell update, web browsing session, ping session, etc.).
Introduction
• Comparison between GPRS and EDGE-GPRS (EGRPS): changes in physical layer,
modulation schemes, protocol stack, hardware upgrades.
Physical layer
• Modulation and Coding Schemes (MCS) in EGRPS
• Modulation schemes: GMSK-modulation, 8-PSK modulation, consequences of using 8-PSK.
Channel coding
• Channel coding.
• Incremental redundancy, puncturing.
• Link adaptation mechanism.
• Data block families.
Planning E-GPRS
• EGPRS sensitivity and interference performance. Comparison with GPRS.
• Upgrading the Abis-interface.
The GPRS audit can either focus on performance analysis of the GPRS radio & system or
address performance optimisation of GPRS services.
An important aspect of the GPRS audit is knowledge transfer. We involve your engineers in
the test program and the actual data analysis, and provide a workshop to your engineers as
part of the audit.
Find below the information regarding a “GPRS system & radio” audit.
(We recommend this course for engineers involved in the GPRS audit)
8.1 Goal
In case poor performance is observed, its underlying causes will be identified and
mechanisms to improve performance will be suggested and described. This requires an in-
depth analysis of technical data from test mobiles, sniffers and protocol analysers.
8.2 Methodology
Tests are performed both under static and driving conditions. Data is collected with test
phones, TCP/IP sniffer on client and server side and a Gb protocol analyser simultaneously.
In addition to dedicated testing (see above), a statistical analysis of Gb-interface log files is
performed for:
• Analysis of network stability.
• Statistical analysis of the performance of important procedures, such as GPRS attach,
PDP activation, Routing area update, as well as LLC-discard, Flush, Radio Status,
etc.
We recommend two of your GPRS engineers attend the data analysis made by our engineers.
This has proven to be a successful way to increase the GPRS expertise of your engineers and
to transfer our GPRS knowledge to your engineers.
We prefer to use your test equipment for the data collection, i.e. test phones and protocol
analyzers, as well as to use your test server.
The main advantage of this approach is that your engineers can run GPRS audits in your
network after we’ve completed one. Again, this is part of our knowledge transfer during an
audit.
8.3 Analysis
The analysis follows a top-down approach, starting from the application level.
Then, we will drill down further in the underlying level, i.e. is poor performance caused by
radio issues, PCU implementation, PCU stability, the SGSN/GGSN core network, etc.
Finally, we will identify the root-causes for poor performance and recommend solutions.
We will break down the areas of poor performance in your network by:
• Operator processes and engineering strategy. In other words, we will clearly indicate
what you can do about poor performance in your network.
• Weaknesses in your infrastructure, i.e. what should your infrastructure supplier(s) do
to improve GPRS performance in your network.
• Limitations of the technology, i.e. what is typical poor performance due to the
technology itself (e.g. TCP over GPRS for mobile users doesn’t work very well.)
The engineering report contains a description of the test setup, the test scenarios, the
methodologies employed to analyse the data, the results of the analyses, the areas of good and
poor performance, root-cause analysis for poor performance, a prioritised list of
recommended actions and optionally draft test plans to improve performance.
This information is then presented in a highly-interactive workshop to a group of your GPRS
engineers.
Note: Commsquare can also provide engineering support or technology coaching to your
engineers when executing the test plans to improve GPRS performance.
A typical audit will take 4 weeks to deliver, starting with the actual test scenarios. Therefore,
setting up the test server and gathering the necessary measurement equipment, identifying the
test areas, etc. is part of the project preparation.
The project is then concluded with the workshop and management presentation.