Abis Over IP Tuning GL EsonTemplate-libre

RECOMMENDATIONS 1 (50)
Prepared (also subject responsible if other) No.

QHEVIST 2/100 56-600/FCG 102 55 Uen
Approved Checked Date Rev Reference
EAB/FJG/ST [Fredrik Wistmarker] 2011-03-17 A

Abis over IP Tuning Guideline

Ericsson AB 2011. All rights reserved. No part of this document may be reproduced in any form without the written
permission of the copyright owner.
The contents of this document are subject to revision without notice due to continued progress in methodology, design
and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this
document.

Ericsson is the trademark or registered trademark of Telefonaktiebolaget LM Ericsson. All other trademarks mentioned
herein are the property of their respective owners.

QHEVIST 2/100 56-600/FCG 102 55 Uen

Revision history
Rev Date Description
A 2011-03-17 1
st
version

QHEVIST 2/100 56-600/FCG 102 55 Uen

Contents
1 Introduction ............................................................................................. 5
1.1 Background ................................................................................. 5
1.2 Purpose ....................................................................................... 5
1.3 Readers guide ............................................................................. 6
1.4 Prerequisites ............................................................................... 7
1.5 Assumptions................................................................................ 7
1.6 Concepts ..................................................................................... 8
1.7 Abbreviations .............................................................................. 8
2 Technical background .......................................................................... 10
2.1 General ..................................................................................... 10
2.2 Static configuration vs. Dynamic behavior ............................... 11
2.3 Trade-offs .................................................................................. 11
3 IP Transport Network characteristics impact on BSS performance13
3.1 Delay ......................................................................................... 13
3.2 Delay variation .......................................................................... 15
3.3 Bandwidth ................................................................................. 17
3.4 Packet Loss ............................................................................... 18
4 Important BSS KPIs influenced by Abis over IP ............................... 20
4.1 General ..................................................................................... 20
4.2 Important BSS KPIs .................................................................. 21
5 Abis over IP tuning based on Performance Indicators .................... 24
5.1 Delay ......................................................................................... 24
5.2 Delay Variation .......................................................................... 26
5.3 Bandwidth ................................................................................. 29
5.4 Packet Loss ............................................................................... 30
6 Hardware Supervision .......................................................................... 33
6.1 BSC ........................................................................................... 33
6.2 BTS ........................................................................................... 33
6.3 STN ........................................................................................... 33
7 Features ................................................................................................. 34
7.1 DTX ........................................................................................... 34
7.2 Packet Abis packing algorithm................................................. 35
7.3 Full Rate AMR on 8 kbps Abis .................................................. 35
7.4 Abis Triggered HR Allocation ................................................... 36
7.5 Adaptive Configuration of SDCCHs ......................................... 37
7.6 Abis interface over satellite ....................................................... 38
7.7 Abis Local Connectivity ............................................................. 38
8 References ............................................................................................. 40
9 Appedix A Abis over IP feature growth within BSS releases from
08A to G11B ........................................................................................... 42
9.1 BSS G11B ................................................................................. 42
9.2 BSS G10B ................................................................................. 43
9.3 BSS G10A ................................................................................. 44

QHEVIST 2/100 56-600/FCG 102 55 Uen

9.4 BSS 09A .................................................................................... 45
9.5 BSS 08B .................................................................................... 46
9.6 BSS 08A .................................................................................... 48

QHEVIST 2/100 56-600/FCG 102 55 Uen

1 Introduction
1.1 Background
When Abis over IP is deployed and integrated according to dimensioning,
deployment and integration guidelines, the system ideally works fine.
However, since Abis over IP is highly dependent on the underlying IP service
transport which by nature usually not is as static as classical TDM networks,
changes in the IP network characteristics may result in changed KPIs.
Therefore there might be a need to tune Abis over IP after the deployment.
Trying to tune Abis over IP in an optimal way is a complex task. This
document tries to give hints and ideas on how to tune Abis over IP based on
performance monitoring of KPIs and other counters. A basis for the tuning is
the given underlying IP network with its specific characteristic. The IP
transport network characteristics are defined by the four time variant
parameters:
Bandwidth
Packet loss ratio
Delay
Delay variation.
The document will show what KPIs and Abis over IP counters that indicate
that there are gains in tuning Abis over IP or dependent features that are
using Abis over IP. Some guiding of in which direction and which parameters
that could be tuned for improved system performance will be presented. To
be noted is that exact values will mostly not be given since they are
dependent on the specific situation, instead a discussion based on the default
or recommended values according to the User Descriptions (references 1, 4,
8, 9, 10 and 11) will apply.
1.2 Purpose
The intended readers of the document are people within Ericsson involved in
Abis over IP deployments or trials working in MUs or GSDCs that need to
know more about the Abis over IP feature and the connection between its
performance and configuration management.
After reading the guideline, the reader shall have a better understanding of:
Abis over IP

QHEVIST 2/100 56-600/FCG 102 55 Uen

The dependence to the underlying IP service
Which KPIs and counters that are of the most interest to observe for
the Abis over IP performance
Which parameters that can be tuned based on observations
It shall be easier to deduce if there might be problems with the underlying
transport, or if Abis over IP is configured in a non-optimal way.
The tuning is mainly focused on the Abis upper interface.
This document can also be used as help for trouble shooters working with
BSS systems and Abis over IP for:
Finding better configurations for the existing system
Concluding if a stated degraded characteristic is due to a badly
configured BSS system or external impact.
1.3 Readers guide
The document starts with a background chapter describing the technical
scope and the problems encountered when tuning the Abis over IP feature. It
is followed by a general chapter about the main characteristics of an IP
network and how they affect a BSS system using Abis over IP as a RAN
transmission means. There are also some general counter measures on Abis
over IP feature level described.
In chapter 4 a description of the impacts that the changes in the underlying IP
transmission may have on important BSS KPIs is shown. The KPIs are part of
the first line of observable performance statistics of Abis over IP. For each
KPI there is a reference to a suitable second line of Abis over IP performance
counter in chapter 5 where a more detailed description of counters and
possible parameter settings is presented.
In chapter 6 a short summary of the Alarm supervision of the different parts of
the Abis over IP system is provided.
Important features that may influence the end user performance or KPIs when
using Abis over IP as a transmission means and their settings and references
to applicable documentation is presented in chapter 7.
As an Appendix the feature growth of the Abis over IP feature from BSS 08A
to BSS G11B is shown. Here information about e.g. when some parameter
settings were introduced, how performance counters have been defined or re-
defined during releases or when new features have been introduced is
provided. The appendix is based on the information in the Network Impact
Reports for the different releases; see reference [15] to [21].

QHEVIST 2/100 56-600/FCG 102 55 Uen

1.4 Prerequisites
The IP network should have been properly dimensioned according to the
rules and guidelines in reference 3
It is assumed that there is a deployed and integrated Abis over IP network up
and running.
An operational support system such as OSS-RC should be used to access
PM counters as well as to manage
[12].
1.5 Assumptions
The tuning guide is based on the Abis over IP feature and dependent features
in a BSS of revision G11B.

QHEVIST 2/100 56-600/FCG 102 55 Uen

1.6 Concepts
Accessibility Accessibility is a part of the classification of the CS performance which
congestion as well as a high random access as well as TCH
assignment success rate.
Delay In this document, the time to transmit information from point A to point
B.
Delay Variation The variation of the delay, from the lowest to the highest, over some
period of time. The highest delay may in some situations be capped,
e.g. by the maximum time the receiving end can wait for the packet.
Integrity Integrity is a part of the classification of the CS performance which

Jitter In this document, the same as Delay Variation.
Jitter buffer At the edge between an asynchronous and synchronous packet
transport, a jitter buffer may be needed to handle the delay variation
and make sure a packet is available when needed by the synchronous
transport. The jitter buffer is a queue where the packets may be queued
for at least a time corresponding to the delay variation.
LAPD Bundling Group A LAPD Bundling Group is called LBG and is used as a profile
by TGs. Enabling Quality of Service requires that the operator creates
one LBG for each priority level and has DSCP enabled in the IP network
Packet loss Describing a loss of a packet on a specific protocol layer. It may be
caused by either a packet drop or an error in the transmission path.
Retainability Retainability is a part of the classification of the CS performance which
de a low TCH drop rate as well as
few minutes with TCH drop as well as handover scenarios with low drop
rates and high success rates.
1.7 Abbreviations
AMR Adaptive Multi Rate
DHA Dynamic Half Rate Allocation
DYMA Dynamic Full Rate/Half Rate Adaptation
FR Full Rate

QHEVIST 2/100 56-600/FCG 102 55 Uen

HR Half Rate
KPI Key Performance Indicator
LBG LAPD Bundling Group
MML Man Machine Language
MS Mobile Station
PTA Packet Timing Advance
SDCCH Stand-alone Dedicated Control Channel
SLA Service Level Agreement
TBF Temporary Block Flow
TCH Traffic channel
TFP Traffic Forwarding Protocol
TG Transceiver Group

QHEVIST 2/100 56-600/FCG 102 55 Uen

2 Technical background
2.1 General
Figure 1 Transport Network of Abis over IP. The Security Gateway is optional.
The underlying IP transport used for the Abis upper interface in Abis over IP,
see Figure 1, is characterized by available bandwidth (throughput), packet
loss, packet delay and a packet delay variation, also called jitter. These
parameters of the transport network, in effect decide how well the Abis over
IP feature optimally might work. The throughput, delay, delay variation and
dropped packets are influenced by other services utilizing the same transport
IP network as Abis over IP. The delay and delay variation may for example
increase if adding other services as well as throughput can decrease and
dropped packets can increase if adding a service with higher priority.
The Abis lower interface between the STNs and the BTSes, applicable for
STNs of type SIU, also influences Abis over IP. This document mainly
focuses on tuning of the Abis upper interface parts.
There are some different traffic types using Abis over IP as a transmission
means. Packet switched (E)GPRS data and circuit switched data are less
sensitive to transmission disturbances compared to signaling data as RSL
and OML. An unfinished signaling procedure may lock resources during a
period of time until a time out is triggered and thus increases a congestion
scenario. The different traffic types are subject to different functions within
Abis over IP and are in some sense possible to tune independently of each
other.

QHEVIST 2/100 56-600/FCG 102 55 Uen

2.2 Static configuration vs. Dynamic behavior
Abis over IP system performance is monitored using applicable KPIs. When it
comes to the measured system performance it is a result of the configuration
of the Abis over IP system in combination with the input traffic patterns and
the performance of the used IP transmission services.
The GSM traffic pattern is by its nature a time variant dynamic process, so is
the random behavior that is disturbing the underlying transmission services.
However, the Abis over IP configuration is a static configuration that may be
changed, but at discrete moments in time.
Some parts in the system do have dynamic behavior. For example there are
features within Abis over IP that adapt buffer sizes to the actual load and
delay. There are also overload prevention algorithms that reduce the needed
bandwidth on the cost of possibly worse speech quality. These features are
part of the BSS solution that makes the system resilient to disturbances.
To tune the Abis over IP solution will thus imply checking the KPIs and by
further monitoring of counters in the system find out what parameters that are
to be changed and to what value. This is not something that the system does
dynamically today, but it is a manual procedure. A changed configuration is
given manually to the system through e.g. OSS-applications and MML
commands.
2.3 Trade-offs
There are some inherent performance trade-offs in Abis over IP.
Generally speaking, there is a trade-off between the choices of configuring
Abis over IP to cater for a bad underlying IP transmission or trying to
mostly a good transmission.
A bad underlying IP service cannot be neglected when it comes to Abis over
IP performance but must be taken care of with correct configuration of the
system. At the same time, this configuration will not be optimal with respect to
e.g. throughput and delay when the transmission service gets better.
Other examples on trade-off decisions are e.g.:
There is a decision between the costs for over-dimensioning the Abis
lower interface compared to the risk of not having the needed bandwidth
from the STNs to the BTSes.
There might be a need to optimize for a decent usage of the bandwidth
by minimizing the overhead. In Abis over IP this is accomplished by
bundling many packets into one large packet and thus maximizing the
payload/header ratio. This procedure will buffer and process many small
packets, thus introducing a delay. There is a choice to make between
having a low delay and a low probability of packet loss by using a small

QHEVIST 2/100 56-600/FCG 102 55 Uen

bundling factor or trying to use a smaller bandwidth by using a large
bundling factor.
In this document there will be some discussions when it comes to parameter
settings that do imply trade-offs regarding the Abis over IP performance.

QHEVIST 2/100 56-600/FCG 102 55 Uen

3 IP Transport Network characteristics impact on BSS
performance
3.1 Delay
3.1.1 Impact
A degraded underlying IP service in terms of reduced amount of available
bandwidth will, considering the same traffic model as before, lead to
increased transmission delays of IP packets in various buffers and queues.
The latency will increase and in turn affect the Abis over IP performance both
regarding internal resources as well as radio resources such as SDCCHs.
See Figure 2 below.

QHEVIST 2/100 56-600/FCG 102 55 Uen

[
E
r
l
a
n
g
]
[
E
r
l
a
n
g
i
n
c
r
e
a
s
e

%
]

Figure 2 Measured TCH and SDCCH traffic and SDCCH usage as a function of
transmission delay
When some signaling messages are delayed or get lost this makes the MS
spend longer time on the signaling channels, which increases the usage of
the signaling resources. As the disturbance increases new calls might fail due
to lack of SDCCH resources while (E)GPRS connections might fail due to cell
congestion. When the delay is further increasing ongoing (E)GPRS
connections and CS calls will eventually be dropped, either at hand over
scenarios or spontaneously.
Abis over IP, as implemented in BSS, use buffers that take care of the
underlying transmission delay in the system. These buffers are configured by
the operator.
An increased transmission delay when using Abis over IP will on a high level
impact the BSS system through:
Increased radio resource usage
Increased speech path delay
Increased roundtrip delay for GPRS/EGPRS
Decreased accessibility and retainability

QHEVIST 2/100 56-600/FCG 102 55 Uen

3.1.2 Counter measures
Signaling is more sensitive to delays compared to CS traffic, since an
increased delay together with the roughly equally sized signaling packets
implies a reduced signaling bandwidth. There are techniques and functions
within Abis over IP taking care of this controlled by the parameters SIGDEL
and LDEL. The parameters should be configured to values matching the
expected total BSC BTS delay. See reference [4] for suggested values.
The feature Adaptive Configuration of SDCCHs, see 7.5, is recommended to
use for maximizing the probability that there are available SDCCHs also at
delays.
To be noted is that the configured Jitter Buffer Delay is not influencing the
signaling delay, since the signaling packets are routed directly to the receiving
end without first being placed into a Jitter Buffer.
3.2 Delay variation
3.2.1 Impact
A degraded underlying IP service in terms of a reduced amount of available
bandwidth will, considering the same traffic model as before, lead to an
increased transmission delay variation when buffers are filled and emptied to
a larger extent.
An increased transmission delay variation when using Abis over IP will on a
high level impact the BSS system similar to delay through:
Increased speech path delay
Increased roundtrip delay for GPRS/EGPRS
Decreased GPRS/EGPRS throughput
As an example the SDCCH usage will increase due to a delay variation giving
temporarily high delays. See the measurements in Figure 3.

QHEVIST 2/100 56-600/FCG 102 55 Uen

KPIs as a function of super channel measured jitter
0
20
40
60
80
100
120
140
160
180
200
max Delay variation in ms
TCH ass success rate (%) SDCCH erlang difference (%)
TCH erlang difference (%)
Figure 3 Measurements on the SDCCH Erlang difference due to transmission
Delay variation

The delay variation may be modeled as consisting of two parts:
A slow variation of the delay, called wander
A fast variation of the delay, called jitter

A wander may be taken care of with e.g. different Timing Advance algorithms,
while a jitter needs some kind of jitter buffer of correct size.
As of today, there are jitter buffers for CS and PS whose settings are a part of
a proper dimensioning of the Abis over IP network. There are recommended
values for all buffers settings as JBPTA for the PS service and JBSUL and
JBSDL for the CS service in the UD [1].
The behavior of CS and PS traffic is a bit different when it comes to the jitter
buffers.
For PS there is a Packet Timing Advance value that is used in a Packet timing
advance mechanism. This value could either be manually set, in the
parameter PTA, or adaptively changed if using the Adaptive Timers for
Packet Abis feature, enabled by parameter PAL. It is highly recommended to
use the Adaptive timers for Packet Abis feature. In the PAL case the wander
is taken care of automatically.

QHEVIST 2/100 56-600/FCG 102 55 Uen

The PTA adaptation algorithm used in Adaptive Timers for Packet Abis
handles the wander but still needs a jitter buffer taking care of the fast
variation. Therefore it is important to use a decent value of JBPTA to cope for
the expected fast delay variation. If having a too small JBPTA value, some
delayed PS packets could get lost.
In the CS case the wander is always taken care of automatically. If an
increased jitter is leading to a frame arriving too late at the BTS or BSC this
will result in a larger JBSDL or JBSUL in units of 20 ms, thus taking care of
an increase of the delay variation.
The suggested values to use for the jitter buffers are the smallest usable one
in terms of lost packets to decrease the introduced delay. A large value will
introduce a delay that might be unwanted since it e.g. impacts end-user
perceived speech quality.
The feature Adaptive Configuration of SDCCHs, see 7.5, is recommended to
use for maximizing the probability that there are available SDCCHs also at
delays.
3.3 Bandwidth
3.3.1 Impact
A properly dimensioned Abis over IP network will have the bandwidth needed
for most traffic cases. The dimensioning guidelines given in [3] will give a
formula giving the expected bandwidth that is needed for CS, PS and
signaling. The bandwidth on the Abis lower interface should be dimensioned
to take care of all expected traffic cases, or even be over-provisioned.
A degraded underlying IP service that reduces the available transmission
bandwidth will lead to lost packets and larger delays and delay variations due
to more extensive use of buffers in the system.
A transmission bandwidth decrease when using Abis over IP will on a high
level impact the BSS system through:
Decreased speech quality
Increased roundtrip delay for GRPS/EGPRS
The best counter measure against drop in available bandwidth is to have Abis
over IP properly dimensioned or possibly over-provision the needed
bandwidth.

QHEVIST 2/100 56-600/FCG 102 55 Uen

Within BSS there are numerous techniques for reducing needed bandwidth,
e.g. DTX (see 7.1) and a Packet Abis packing algorithm, enabled by setting
the parameter PACKALG=1, see [1].
Another possibility is to increase the bundling parts of Abis over IP, thus
reducing the overhead needed for the transport over Abis. This will however
increase the delay and the packet loss ratio in the system, since each
bundled packet will include more CS and PS packets.
There are BSS overload prevention features that may reduce the probability
of a congested system by, at configurable thresholds, reducing the needed
bandwidth by changing speech codecs to HR or AMR-HR, on behalf of
speech quality. It is recommended to use these features to increase the
speech throughput.
There are built-in overload handling mechanisms that try to optimize the
bandwidth use from a user perspective whenever the overload is a fact. A
careful use of the overload handling mechanism is recommended, see 5.4.2.
3.4 Packet Loss
3.4.1 Impact
Dropped packets transported over Abis will lead to different behavior
depending on the contents in the lost packet.
For streaming services like speech it is not very crucial with lost packets in
other sense than it degrades the speech quality. For PS services it might be
crucial and lead to longer end user delays, if reliable upper protocols are used
and therefore need resending of packets. If a packet on Abis including
signaling information is dropped, it will have even more impact. A lost control
message may lead to failed attempts to set up TCHs or lost access requests
that might time out before a renewed attempt.
Packet drop when using Abis over IP will on a high level impact the BSS
system through:
Decreased speech quality

See for example Figure 4.

QHEVIST 2/100 56-600/FCG 102 55 Uen

It is important to analyze why a packet drop has happened. As of today it is in
Packet Abis over IP possible to observe if the packet drop is due to a bad
setting of the jitter buffers, or if it was due to IP overload handling algorithms
in Abis over IP.
If the drop is not considered to have its roots in Packet Abis over IP, but in the
IP transmission, there may be a way of reducing the impact of Packet drop on
the system. The bundling size of packets might be decreased and in this way
reduce the probability to have many included packets dropped within one
bundled packet, however with the drawback that it will reduce the aggregation
gain.

QHEVIST 2/100 56-600/FCG 102 55 Uen

4 Important BSS KPIs influenced by Abis over IP
4.1 General
The most important system characteristic is seen in the KPIs monitored by the
operators as defined in [5] and recommended in [14]. The main idea in this
document is to use these KPIs as a first line of observable performance
counters.
If the KPIs show bad performance in any way, and there is a suspicion that
the underlying IP transmission is the main source of performance decrease, a
suggested second line of Abis over IP performance indicators in chapter 5
shall be monitored. Based on these observations, some conclusions may be
drawn on how to identify the reason and adapt the feature to make it work in a
more efficient way.
There is an assumption that the Abis lower transmission is dimensioned
will be from the Abis upper part of the transmission.
The CS KPIs are grouped in the areas accessibility, retainability and integrity
as defined by ITU.
Accessibility covers:
Random access success rate
SDCCH Drop rate
SDCCH time congestion
TCH Assignment success rate.
Retainability includes:
TCH Drop rate
Handover success rate
Call minutes per drop
Handover lost rate.

QHEVIST 2/100 56-600/FCG 102 55 Uen

Integrity KPIs are based on Speech Quality Supervision function, where the
radio conditions are converted to a Speech Quality Index (SQI). Unfortunately
KPIs will not change although the Speech Quality might be influenced by the
Abis performance, see 4.2.10.
To make it possible to evaluate GPRS/EGPRS end-user performance in a
-user
performance tests, see [5].
4.2 Important BSS KPIs
In the following sections from chapter 8 in reference [5
transmission is shown. The descriptions are valid during normal running
conditions, i.e. the Abis over IP transmission is not completely down.
4.2.1 IP Transfer interrupts
These KPIs will be influenced by longer interrupts on the Abis transmission.
Long interrupts could potentially lead to lost TBFs. The lost TBFs will be
visible in the counters LDISRR and IAULREL in object CELLGPRS2; and
LDISRRSUB and IAULRELSUB are in object CELLGPRSO
To check if the interrupts are due to congestion in the Abis transmission,
check the overload and packet loss counters in chapter 5.4.1.
4.2.2 GPRS Availability
This KPI is influenced by, possibly temporary, lack of Abis resources due to
e.g. congestion. Check Abis overload counters in chapter 5.4.1
4.2.3 IP Latency GPRS
The GPRS IP latency KPIs includes packet Abis delays except packets
arriving too early or too late outside the measuring window used. Unless
having a high delay variance on Abis, the KPIs could be considered as
showing the experienced latency.
4.2.4 IP Throughput and Radio Link Bitrate measurements
These KPIs will be influenced by bad transmission on Abis or over the air
interface. The KPIs do not separate between the two causes so it is not
directly observable if the effect is due to Abis or air interface problems.

QHEVIST 2/100 56-600/FCG 102 55 Uen

If there is an Abis overload situation, this may result in fewer available
PDCHs. This will be visible in multislot utilization and traffic load counters
found in object types TRAFDLGPRS, TRAFULGPRS, TRAFGPRS2 and
TRAFGPRS3, respectively, see reference [5].
The GPRS throughput KPIs will be affected by impacted number of TBFs due
to e.g. the overload actions that are taken during overload.
In order to further check if the cause is due to the settings of Abis over IP it is
suggested to check out the counters for delay, delay variation, Packet Loss
ratio and overload counters in the chapters 5.1 to 5.3.
4.2.5 IP User Data Volume
These KPIs are influenced by the Abis over IP transmission. A changed user
data volume may be a result of a changed performance of the Abis interface.
The packet loss ratio and overload counters, see 5.4.1, are indicators of the
current Abis situation.
4.2.6 CS Accessibility - Random access success rate
This KPI will be influenced by Abis over IP only at very bad conditions, since
the overload mechanisms try to keep CHANNEL REQUIRED message. If not
finding this KPI behaving as expected, check out the overload and packet loss
ratio counters in chapter 5.4.1.
4.2.7 CS Accessibility - SDCCH Time Congestion
At Abis link outage the KPI will be affected, but this cannot be directly
measured using Abis over IP counters.
4.2.8 CS Accessibility - SDCCH Drop rate
The SDCCH drop rate is influenced by the Abis over IP interface. When
packets are lost the SDCCH resources are occupied for a longer time than
expected. When the packet loss ratio is increasing the SDCCH drop rate is
also increasing, see Figure 4.
Indications if the underlying transmission is influencing the SDCCH drop rate
are found in the overload and the packet loss counters in 5.4.1.

QHEVIST 2/100 56-600/FCG 102 55 Uen

0
2
4
6
8
10
12
14
16
18
TCH assignment failure SDCCH drop rate
Packet Loss %

Figure 4 TCH assignment failure and SDCCH Drop Rate as a function of
packet loss ratio.
4.2.9 CS Accessibility - TCH Assignment success rate
The KPI is influenced if there is congestion in the transmission leading to
longer RTTs or increased packet losses, see also Figure 4. Check out the
overload and packet loss ration counters in chapter 5.4.1
4.2.10 CS Integrity SQI
The KPIs are currently only influenced by the radio interface transmission,
thus not influenced by Abis over IP.
There is for the moment no observability on the Abis delay or packet loss
impact on CS integrity. However, if there are excessive delays or packet loss
ratio on Abis of more than 0.1 % it is likely to have CS integrity issues.
4.2.11 CS Traffic Volume
The KPI is influenced if there is congestion and/or packet losses in the
transmission leading to dropped SDCCHs, TCH assignment failures (see
Figure 4) and possibly IP overload handling kicking in leading to a further
increase of packet losses. Check out chapter 5.4.1

QHEVIST 2/100 56-600/FCG 102 55 Uen

5 Abis over IP tuning based on Performance Indicators
This chapter describes the specific Abis over IP performance indicators for
delay, delay variation, packet loss and bandwidth, how those are influenced
by the configuration of Abis over IP and possible new configuration settings
improving the Abis over IP performance.
5.1 Delay
The formulas of the Total Delay for CS and PS are taken from reference [5].
The function MeanOrMaxOverSC in the below formulas means that either a
mean over all super channels shall be calculated. Or, as a worst case
scenario, the max delay found in the available super channels shall be used.
5.1.1 CS Services
5.1.1.1 Downlink
TotDelayIP_CS_DL = [BUNDG1AVEDEL / 10] + [PingDelayAverage / 20] +
MeanOrMaxOverSC[FJBUFDELDL / FJBUFDLSCAN] milliseconds
The PM counter PingDelayAverage is a STN counter. The STS counters
FJBUFDELDL counts the accumulated delay in ms per SC for CS traffic
frames in the jitter buffer on the downlink, FJBUFDLSCAN counts the number
of accumulations and BUNDG1AVEDEL shows the average bundling delay in
the LBG containing Speech.
The Transmission delay on the Abis Upper BSC STN interface is possible to
measure by setting up a PingMeasurement in the SIU pointing out the BSC
PGW IP address. The resulting performance counter PingDelayAverage
shows an average of the RTT of a ping packet sent from the BSC and
returned from the PGW in the BSC. The one way delay can be estimated to
RTT/2 if a symmetric delay is assumed.
The downlink CS jitter buffer delay is observed by the FJBUFDELDL and
FJBUFDLSCAN per SC.

The downlink delay in the BSC IP buffer, as well as in the STN SC buffer and
the transmission delay on Abis lower are not observable. There is no
congestion assumed at the PGW IP Interface neither on the super channel on
Abis lower.

QHEVIST 2/100 56-600/FCG 102 55 Uen

5.1.1.2 Parameters
If the average bundling delay shows a long bundling time compared to the
total CS DL delay, there is a possibility to decrease the bundling buffer size or
the maximum bundling time (MPLSDL and MCLTDL) to reduce the latency.
This will be on the cost of bandwidth but a possible lower packet loss rate.
If the downlink CS jitter buffer delay is high compared to the total CS DL
delay, there may be a possibility to decrease the jitter buffer size, JBSDL, to a
smaller value. For further info if a change is applicable and how to tune it, see
the setting of JBSDL in 5.2.1.
5.1.1.3 Uplink

TotDelayIP_CS_UL = MeanOrMaxOverSC[FSCBUFDELUL/FSCBUFULSCAN]
+ MCLTUL + PingDelayAverage/20 +
MeanOrMaxOverSC[FJBUFDELUL/FJBUFULSCAN] milliseconds
PingDelayAverage is the STN counter. The STS counters FJBUFDELUL,
counts the accumulated delay in ms per SC for CS traffic frames in the jitter
buffer on the uplink, FJBUFULSCAN counts the number of accumulations.
FSCBUFDELUL and FSCBUFULSCAN are the corresponding counters for the
SC buffer. The parameter MCLTUL is the setting of the maximum bundle
collecting time in uplink.
5.1.1.4 Parameters
If the uplink delay is perceived as long compared to the total CS UL delay,
there is a possibility to reduce the bundling time by decreasing the Bundling
Buffer Size and/or the Maximum Bundling Time (MPLSUL and MCLTUL).
This will be on the cost of bandwidth and a possible lower packet loss rate.
If the downlink CS jitter buffer delay is high compared to the total CS UL
delay, there may be a possibility to decrease the jitter buffer size, JBSUL, to a
the setting of JBSUL in 5.2.1.
5.1.2 PS Services
5.1.2.1 Downlink
TotDelayIP_PS_DL = [BUNDG3AVEDEL / 10] + [PingDelayAverage / 20] +
JBPTA milliseconds
The PM counter PingDelayAverage is a STN counter. The STS counters
BUNDG3AVEDEL shows the average bundling delay in the LBG containing
(E)GPRS. The parameter JBPTA shows the value of the P-GSL Jitter buffer.

QHEVIST 2/100 56-600/FCG 102 55 Uen

5.1.2.2 Parameters
If the Bundling Delay counter, BUNDG3AVEDL shows a long bundling time
compared to the total PS DL delay, there is a possibility to decrease the
Bundling Buffer Size and/or the Maximum Bundling Time (MPLSDL and
MCLTDL) to reduce the latency. This will be on the cost of bandwidth and a
possible lower packet loss rate.

If the downlink PS jitter buffer delay is high compared to the total PS DL
delay, there may be a possibility to decrease the jitter buffer size, JBPTA, to a
the setting of JBPTA in 5.2.2.
5.1.2.3 Uplink
TotDelayIP_PS_UL = MCLTUL + PingDelayAverage/20 +
MeanOrMaxOverSC[FSCBUFDELUL/FSCBUFULSCAN] milliseconds
PingDelayAverage is the STN counter and the parameter MCLTUL is the
setting of the maximum bundle collecting time in uplink.
The STS counters FSCBUFDELUL counts the accumulated delay in ms per SC
for CS traffic frames in the SC buffer on the uplink, FSCBUFULSCAN counts
the number of accumulations.
5.1.2.4 Parameters
If the uplink delay is perceived as long compared to the total PS UL delay,
there is a possibility to reduce the bundling time by decreasing the Bundling
Buffer Size and/or the Maximum Bundling Time (MPLSUL and MCLTUL).
This will be on the cost of bandwidth and a possible lower packet loss rate.
5.2 Delay Variation
5.2.1 CS Services
5.2.1.1 Counters
The total Delay variation, or jitter, is in some sense observable for CS in both
up- and downlink, at least the jitter distribution for packets arriving too late.
The counters used are the jitter buffer counters in DL counted in the BTS and
the jitter buffer counters in UL counted in the BSC/PGW. The delay variation
is seen as the delay distribution in the histogram counters
[UL / DL][0025/ / / / 100]JITBUFDEL,

QHEVIST 2/100 56-600/FCG 102 55 Uen

Where each counter includes the number of CS traffic frames where the jitter
buffer delay in UL or DL was between x% and y% of the jitter buffer size
setting. The behavior of the counters will then be:
A packet arriving at the average time will be placed in the 100 bucket,
since it will stay in the buffer the whole configured buffer time.
A packet arriving very much later than average may thus be counted in
the 0-25% bucket, since it resides in the buffer for a short period of time.
A packet arriving earlier than average will be counted in the 100 bucket,
since it will stay in the buffer for a longer time than the configured jitter
buffer time.
A packet arriving too late will be lost and not even counted in the 0-25%
bucket but as a dropped packet in [UL/DL]DROPJBUF.
With this kind of counting, all packets arriving earlier than or on average time,
will be placed in the 100 bucket, which makes it impossible to observe the
jitter distribution when packets are arriving early in any finer resolution.
To be noted is that for a jitter with normal distribution, the counter
[UL/DL]100JITBUFDEL should have approximately the same value as the
sum of the other counters. However other jitter distributions are more

[UL/DL]100JITBUFDEL will be even larger than the sum of the other
counters. Also it is more probable that the counters are more tended to the
[UL/DL]100JITBUFDEL part if the buffers were adaptively increased due to
late arriving packets.
5.2.1.2 Parameters
If the [UL/DL]0025JITBUFDEL have been stepped many times relative to
the other counter buckets (for example if every 5
th
packet, 20%, is arriving in
this bucket) and there are also many dropped packets in [UL/DL]DROPJBUF,
this signals that the jitter buffer size JBS[UL/DL]
cater for the large jitter in the system. There is a built in adaptation of the jitter
buffer size, which makes the buffer larger when packets are lost, so the
system effect of a manual setting to a high value in the jitter buffer is small.
The jitter buffer size is reset to the original configured value when a new call
is set up.
If there are no or only a small number of dropped packets and not many
packets counted in[UL/DL]0025JITBUFDEL there could be a possibility to
make the jitter buffer size JBS[UL/DL] smaller. A comparison of the delay in
the jitter buffers compared to the total delay may indicate that there is a
possibility to reduce the CS jitter buffer size, see 5.1.1.2 and 5.1.1.4.
However, it must not be smaller than the corresponding bundling protocol
buffer size, since this buffer is creating system internal jitter which will be
added to the IP network jitter and all other sources of jitter.

QHEVIST 2/100 56-600/FCG 102 55 Uen

Since it is hard to optimize the jitter buffer settings, it is suggested to start
checking other buffer settings as for example the bundling buffers in the first
place. A reduced time and size in the bundling buffer will reduce the delay
variation so that it is possible to decrease the jitter buffer size in a
corresponding degree.
5.2.2 PS Services
5.2.2.1 Counters
The PS service has a jitter buffer in the downlink, which shall make sure that
there always is at least one packet ready to be sent out on the air interface.
There are no counters that make the PS delay variation directly observable in
Abis over IP and BSS. A jitter may be measured by external means by using
intermediate IP probes and a corresponding measurement application.
Indirectly there is a possibility to check other Abis over IP counters, as the PS
DL Delay measurements in 5.1.2.1 and packet loss DL counters in 5.4.1 to
get a feeling for how well tuned the PS DL jitter buffer is.
5.2.2.2 Parameters
There are two out of three parameters that are to be set: JBPTA, PAL and
PTA, see reference [1].
PAL to 1
there is a need to set the JBPTA value which shall cope for the round trip
jitter correctly. It is highly recommended to use this feature.
The JBPTA value is used by a PTA adjustment algorithm for determining the
average usage of a sending buffer in the TRXs. This buffer can take at a
maximum 6 (RLC/MAC) blocks per time slot. The 6 blocks represent a 120
ms sending window. In the BSC and BTS there is an algorithm that tries to
deliver frames to the BTS downlink buffer JBPTA ms before it shall be sent on
the air interface. A reduced jitter leading to a decreased delay will fill the
buffers faster, possibly leading to a buffer overflow and lost frames. On the
other hand an increased jitter leading to an increased delay will fill the buffers
more slowly, possibly leading to a buffer underrun and lost frames.
There are recommended values as well as guiding rules in reference [1] of
how to tune the JBPTA value by checking the counters for lost packets. A
decrease of JBPTA -and- -
observation of the DLFramePktLoss counter. If the DLFramePktLoss counter
shows a larger portion of lost packets after a change in JBPTA, this means
there is a need to increase the value. Also care must be taken regarding the
load when tuning the parameter, since high load will generate more jitter.

QHEVIST 2/100 56-600/FCG 102 55 Uen

If using a good network with an expected small jitter, a value of 20 ms
introducing a minor delay is appropriate. This setting will allow for a sudden
delay increase of 20 ms before reaching a buffer underrun state or a delay
decrease of 100 ms before reaching a buffer overflow state, and at the same
time introducing a minimum delay in the jitter buffer.
If the Interfaces over satellite feature is used, see 7.6, expecting a large jitter,
JBPTA should always be set to 60 ms, thus providing robustness for the
largest possible variation in delay: !60 ms.
To be noted is that non-recommended extreme JBPTA setting of 120 ms will
imply:
Lost packets since there is no robustness against a sudden decrease
of delay. This unconditionally will lead to a buffer overflow and a lost
packet
A jitter buffer delay of 120 ms
Robustness against a sudden increase of delay of 120 ms
And a non-recommended setting of JBPTA to 0 ms will have the opposite
effect, leading to lost packets due to buffer underflow.
If the TotDelayIP_PS_DL counter shows that a large part of the total delay is
due to the jitter buffer delay and at the same expecting a low jitter in the
network, this is an indication of a possibility to decrease JBPTA. A reduction
of the value must be done studying the DLFramePktLoss counter so that no
increase in packet loss occurs. The jitter introduced by the bundling buffers as
well as all other node internal and network generated jitter has to be taken
into account. With recommended settings and a fair network the
recommended 20 ms will be enough to cope for the jitter.
5.3 Bandwidth
5.3.1 Counters
ULABISipAVEthp = ( IPRECKBYTES * 8 ) / IPNUMSCAN
DLABISipAVEthp = ( IPSENTKBYTES * 8 ) / IPNUMSCAN
The Abis average throughput is calculated according to the above formula.
This measure compared to the available bandwidth defined by a SLA will give
a hint if there is enough bandwidth available for Abis over IP.
A temporary burst of packets might not fit into the available bandwidth. There
are built-in overload prevention mechanisms like Abis Triggered HR Allocation
and Full Rate AMR on 8 kbps Abis that shall prevent overload, see chapters
7.3 and 7.4.

QHEVIST 2/100 56-600/FCG 102 55 Uen

These features are triggered when the load is crossing configured thresholds
for utilized bandwidth. The utilized bandwidth is calculated as a percentage of
engineered bandwidth, MBWDL and MBWUL:
ULABISipAVEutil = ULABISipAVEthp / MBWUL
DLABISipAVEutil = DLABISipAVEthp / MBWDL
This fact makes the dimensioning of the two engineered bandwidth parameter
an important task, since a too low setting of MBW[UL/DL] will make the
overload prevention kick in earlier than necessary, degrading the speech
quality in a too early stage.
If the counters OVERLOADREJCON in object type CLTCH and PREJABISCONG
in object type CELLGPRS3 are stepped, this indicates that there is ongoing
Abis overload that prevents the system from setting up new TBFs
(PREJABISCONG) or new CS connections.
There are also counters presenting the load distribution on the PGW STN
link relative the engineered bandwidth in the
D[UL/DL][7075,7680,..,9600,00]STNLOAD
histogram counters. The load distribution gives some hint of how well
dimensioned the Abis upper interface is compared to the engineered
bandwidth.
5.3.2 Parameters
Available parameters for reducing the needed bandwidth are all parts of the
DTX, packet Abis packing algorithm and overload prevention features. See
chapters 7.1, 7.2, 7.3 and 7.4.
5.4 Packet Loss
5.4.1 Counters
ULFramePktLoss = 100 * LOSTULPACK / (TOTULPSSCFRBUF +
TOTFRULSCBUF) [%]
DLFramePktLoss = 100 * LOSTDLPACK / (TOTDLPSSCFRBUF +
TOTFRDLSCBUF ) [%]
The total super channel frame loss ratio per Super Channel for UL and DL are
calculated as above. There are also loss ratios defined for CS and PS
separately in reference [5].
There are also some counters on the IP level:

QHEVIST 2/100 56-600/FCG 102 55 Uen

IPLOSTPACKUL in the BSC counting the number of Abis IP packets
being lost on the IP link or received with checksum errors in the BSC,
reported per TG. Note that an IP packet contains many bundled UL or
DL super channel frames.
inAbisPacketsErrors and inAbisPacketsLost in the STN
counting the number of DL IP packets received with checksum errors
or being out of sequence or lost respectively.
If the UL or DL super channel frame loss is greater than 0.1 % and the
number of discarded IP packets is increasing correspondently, this suggests
that the transmission packet loss is larger than recommended for using Abis
over IP.
It is not recommended to use an IP network having a larger packet loss than
0.1%.
There is an overload handling mechanism, which tries to reduce the impact of
dropped packets on the Abis link on system and end-user performance. The
main idea is to prioritize the different types of data and remove the packets
that have the lowest priority. The trigger for the overload handling mechanism
is amongst others the IP packet loss level, see reference [1].
The overload counters consists of some that are stepped during use of the
overload handling mechanism, indicating how long overload reduction have
been active, see reference [5]:
IPOVL[CS,PS]REG and IPOVLL[1/2]
Packets are discarded only during IPOVLL[1/2] overload handling.
The CS and PS discarded frames due to overload handling formulas:
CSdiscFrameOvlDL = 100 * CSDISCOVL / FRAMECOUNT [%]
PSdiscFrameOvlDL = 100 * PSDISCOVL / FRAMECOUNT [%]

where CS and PSDISCOVL is the sum of all SCs in the TG found in the SIU
counter SC_FramesDownlink. It is only during the active phase of IPOVLL1
and L2 that packets are discarded due to overload handling.
5.4.2 Parameters
As in the case of overload prevention there can be situations where overload
handling is triggered falsely due to the settings of MBW[UL/DL], see chapter
5.3. The overload handling mechanism in Abis over IP is designed for
moderate to medium packet loss ratios. For very low packet loss transmission
as well as for a high loss transmission the overload handling should be turned
off, see recommendations in reference [13].

QHEVIST 2/100 56-600/FCG 102 55 Uen

If Abis over IP is deployed on a transmission with a bandwidth that is
high enough for any expected traffic expecting a very low packet loss
ratio a magnitude under 0.1%, it is recommended to turn overload
handling off to avoid any unnecessary falsely triggered performance
degradation.
If the underlying IP network has a high packet loss ratio in the
magnitude of 1% or above, it is recommended not to use the overload
handling mechanisms.

above 5%, the IPOV parameter should be set to off to avoid falsely
triggered overload handling.
Turning off overload handling is made by setting the IPOV to OFF and
OVLTH to 1000, see e.g. [13].
If using overload protection, the tuning of OVLTH is important, since it is set
as a factor of 0.1% of the expected peak packet loss ratio. A tuning procedure
for OVLTH is given in reference [1], which basically consists of a statistical
collection step of the packet loss ratio without overload protection, followed by
a trial procedure where the OVLTH is set to a starting value and then iterated
to a lower and lower value until either the recommended lowest value of 25 is
reached, or the statistics show no falsely triggered overload protection
procedures.
Overload prevention might be considered if the bandwidth is the limiting
factor. See chapters 7.3 and 7.4.
If the loss is due to buffer overflows within BSS manageable buffers it may be
possible to tune some configuration parameters to decrease the packet loss
rate:
If there is a difference between CS and PS statistics, it could be
suspected that some buffers are not properly tuned.
o The Bundling times for the LBG for CS may be decreased if
there is a higher drop for CS than for PS and the other way
around.
o The jitter buffer size JBPTA might be increased carefully up to
maximum 60 ms, if the PS data has higher drop than CS and the
other way around.
o Note that an increased buffer size will also will increase the
delay.
If there is a different packet loss ratio for different Super Channels, it is
likely that one SC is more overloaded than the other and that the
dimensioning is wrong. It is suggested to re-distribute the TRXes used
by each TG more evenly on the SC belonging to the Super Channel
Group that is corresponding to the specific TG.

QHEVIST 2/100 56-600/FCG 102 55 Uen

6 Hardware Supervision
6.1 BSC
There is Alarm supervision of the different parts of the BSC that influences
Abis over IP. The PGW-RPs, of either PGWB or GARP-2 type, do issue
alarms and events according to the descriptions in reference [6].
which makes the system more resilient to PGW-RP failures and tries to
distribute an average part of the load on each available PGW-RP, see
reference [6]. Within this feature there is some statistics available that could
be monitored, e.g. a measure on the number of PGW CPUs where the load
PGWHLRPP. To be noted is that the
feature automatically distributes the load based on algorithms and
configurable thresholds.
6.2 BTS
Alarms and PM data are sent from the BTS and aggregated in the BSC.
If the Abis link is down the BTS cannot report anything about its state. A first
measure would be to try to mend the link by checking the state and
configuration of the intermediate nodes. If the Abis outage still appears, a
connection on site is necessary to download the the state of the BTS and get
it up and running again.
6.3 STN
When the STN supervision mechanism, based on heartbeats between the
STN and OSS, is configured and triggered, see reference [7], there will be
alarms triggered within the OSS if the STN goes out of service.
If the WAN interface of the STN is not working, the Abis upper link to the BSC
and the IP link from STN to OSS will be down. In this case no Alarms or
statistics will be available in OSS. However, if the STN is up and running with
connectivity to the BSC and OSS, and a new configuration is downloaded
resulting in a loss of connections to BSC and OSS, the STN will use a built-in
rollback functionality that returns to the old working configuration after a
certain time of connectivity trials.

QHEVIST 2/100 56-600/FCG 102 55 Uen

7 Features
There are some features that are dependent to Packet Abis over IP and
needs to be tuned in combination with Packet Abis over IP:
FAJ 122 287, Discontinuous Transmission (DTX) Downlink
FAJ 122 256, Discontinuous Transmission (DTX) Uplink
FAJ 121 997, Abis Optimization
Only needed for releases earlier than G11B when using Packet Abis
packing algorithm
FAJ 121 846, Abis Triggered HR Allocation
May use:
o FAJ 121 361, Dynamic FR/HR Adaptation
o FAJ 121 582, Dynamic Half Rate Allocation
FAJ 122 381, Adaptive Configuration of SDCCHs
FAJ 122 437, A-bis interface over satellite
FAJ 123 142, Abis Local Connectivity Satellite
FAJ 123 159, Abis Local Connectivity - Terrestrial
7.1 DTX
FAJ 122 287, Discontinuous Transmission (DTX) Downlink
FAJ 122 256, Discontinuous Transmission (DTX) Uplink
DTX together with the Packet Abis packing algorithm are the most important
features in order to save bandwidth on Abis. The DTX features must be used
in combination with the Packet Abis packing algorithm in order to save
bandwidth.
The amount of bandwidth saved depends on the voice activity factor (which
varies for different languages, cultures and nature of the call) but is usually
around 50%.
Recommendation:
DTX UL and DL is always recommended to use since these features
significantly reduces the Abis bandwidth. There is a need to enable the
Packet Abis packing algorithm to make the bandwidth savings take place.
7.1.1 Parameters
DTXU = 1 and DTXD = ON is recommended. See reference [8].

QHEVIST 2/100 56-600/FCG 102 55 Uen

7.2 Packet Abis packing algorithm
The Packet Abis packing algorithm is a feature to get substantial bandwidth
savings on the Abis interface. Bandwidth savings are achieved by removal of
redundant information and packing of frames in both uplink and downlink. The
amount of savings is depending on the traffic mix and voice activity.
Recommendation:
The Packet Abis packing algorithm is a highly recommended bandwidth
savings technique that should be used.
Note: Before the BSS release G11B the algorithm was only available together
with the Abis Optimization feature.
7.2.1 Parameters
PACKALG = 1 is recommended, See reference [1].
7.3 Full Rate AMR on 8 kbps Abis
The Full Rate AMR on 8 kbps Abis feature allocates Full Rate AMR calls with
codecs restricted to a maximum of 7.4 kbps in order to decrease the used
bandwidth on Abis. The AMR codec is restricted to max AMR 7.4 kbps over
Abis but uses AMR FR on the air interface.
This functionality is initiated at set up of an AMR FR call when the number of
idle Abis resources has fallen below the threshold defined by the parameter
SDAMRREDABISTHR specified per TG.
Note: Needs FAJ 121 055 Adaptive Multi Rate (AMR) and FAJ 121 358 AMR
Half Rate. There is no need for the orderable feature FAJ 121 827, Full Rate
AMR on 8 kbps Abis since it is coming with the Abis over IP baseline.
Recommendation:
It is recommended to use the Full Rate AMR on 8 kbps Abis feature to
increase the system performance and improve the usage of the possibly
scarce Abis bandwidth.
7.3.1 Parameters
The functionality is turned ON or OFF by the parameter DAMRCRABIS per
cell see reference [1].

QHEVIST 2/100 56-600/FCG 102 55 Uen

SDAMRREDABISTHR is the threshold where the initiation of FR AMR calls
with max 7.4 kbps is started. A lower value will start the bandwidth savings
technique earlier, maybe coping for a faster increase of needed saved
bandwidth although possibly reducing the perceived speech quality. The
settings recommended are found in [1].
7.4 Abis Triggered HR Allocation
FAJ 121 846, Abis Triggered HR Allocation
May also use:
FAJ 121 361, Dynamic FR/HR Adaptation
FAJ 121 582, Dynamic Half Rate Allocation

There are features used for optimizing channel allocation algorithms. These
features are also applicable and reused for a system which is Abis resource
limited. Two principles are DHA and DYMA which work in different ways when
the resources on Abis are scarce:
DYMA, Dynamic FR/HR Adaptation is used when trying to reduce the Abis
resources needed for ongoing calls by downgrading the codecs from FR to
HR, packing them and releasing the FR resources not needed anymore.
DHA, Dynamic Half Rate Allocation is used when resources on Abis are
scarce and new calls are initiated. For all calls possible, instead of allocating
FR, HR is used.
The feature Abis Triggered HR Allocation consists of the two parts: DHA
triggered by Abis and DYMA triggered by Abis working as explained above.
These functions may be triggered when there is high load on Abis when using
Abis over IP. The triggers are set by the operator.
The DYMA part is triggered if the load on the packet Abis path for any of the
super channels in the TG(s) serving a certain cell exceeds a percentage
value, SDFRMAABISTHR, then connections using FR shall be moved to HR.
There is also a mechanism to go back to FR allocations if the Abis load
decreases under the threshold again.
The DHA part is triggered if the load on the packet Abis path for the TG(s)
serving a certain cell exceeds a percentage value, SDHRAABISTHR, set per
TG. If triggered, then AMR/HR and HR channels shall be preferred for new
calls until the Abis load goes under the threshold again.
If using the two features Dynamic FR/HR Adaptation and FAJ 121 582
Dynamic Half Rate Allocation in conjunction with FAJ 121 846 Abis Triggered
HR Allocation, there will be overload prevention triggered not only if Abis is a
scarce resource, but also if the cell is experience load.

QHEVIST 2/100 56-600/FCG 102 55 Uen

Recommendation:
It is recommended to use the channel optimization algorithms to increase the
system performance and improve the usage of the possibly scarce Abis
bandwidth. A lower value will start the bandwidth savings technique earlier,
maybe coping for a faster increase of needed saved bandwidth although
possibly reducing the perceived speech quality.
7.4.1 Parameters
The enabling of Abis Triggered HR Allocation is set in each cell by setting
ATHABIS = On
The threshold for allocation of HR channels is set by the parameter
SDHRAABISTHR per TG.
The threshold for FR to HR change triggered by lack of Abis bandwidth is set
by the parameter SDFRMAABISTHR per TG.
The threshold for going back from HR to FR is triggered by the parameter
SDHRMAABISTHR per TG.
The first triggered saving technique recommended is the Full Rate AMR on 8
kbps Abis, see chapter 7.3. The second counter measure is recommended to
be DHA and the last triggered bandwidth saving technique should be DYMA.
The settings recommended are found in [1].
For further reading abuot the Abis triggered DYMA and DHA features, see
reference [9].
7.5 Adaptive Configuration of SDCCHs
This feature is used to optimize the traffic and signaling channel usage,
especially by making the SDCCH dimensioning less critical by automatically
adapting the number of SDCCHs in a cell to the demand for such channels.
Recommendation:
It is recommended to enable the adaptive configuration of logical channels to
make sure there always are enough SDCCH channels to cater for delay and
delay variations introduced in Abis over IP, which may temporarily increase
the usage of SDCCHs.
In case Adaptive configuration of logical channels is not used the SDCCH
utilization should be supervised.

QHEVIST 2/100 56-600/FCG 102 55 Uen

7.5.1 Parameters
ACSTATE shows the activation state (ON/OFF) of the Adaptive Configuration
of Logical Channels function in the cell. It is set in the BSC with the MML
commands RLACI and RLACE on a cell level.
For further settings of parameter, see reference [4].
7.6 Abis interface over satellite
This feature makes sure that the system can handle long delays introduced
by e.g. a satellite connection.
If using a high delay Abi
level, by adapting timers for CS and PS and modifying the Immediate
Assignment procedure.
Recommendation:
When using an Abis satellite path or a long delay Abis transmission, it is
highly recommended to use the Abis interface over satellite feature.
Note: For payload dimensioning of a packet Abis transmission running over a
Satellite link, a dedicated integration project is required, as per standard
Ericsson customer adaptation processes.
7.6.1 Parameters
The controlling parameter SIGDEL, which is set on a TG level, shall be
changed from the default value NORMAL to LONG.
For further settings please refer to the User Description [10].
7.7 Abis Local Connectivity
Abis Local Connectivity provides the possibility to switch speech calls locally
in the STN node. Local switching can be done if both legs of a call are
handled by the same STN node and they use the same speech codec. When
a call is locally switched there are no speech frames sent on Abis Upper
although signaling, including measurement reports, are sent to and from the
BSC as usual.
There are two features: Abis Local Connectivity - Satellite and Abis Local
Connectivity -
interface based on satellite or terrestrial transmission.
Since the application of this feature is very dependent on the actual business
case, there is no general recommendation for using this feature or not.

QHEVIST 2/100 56-600/FCG 102 55 Uen

Note that the Abis dimensioning is influenced and that the frame loss counters
are not correctly counted when using the Abis Local Connectivity feature, see
reference [1].
7.7.1 Parameters
The MO LocalConnect in the STN shall be created and configured. For more
information regarding the possible settings see reference [11].

QHEVIST 2/100 56-600/FCG 102 55 Uen

8 References
1. Packet Abis over IP, User Description; 326/1553-HSC 103 12
2. Packet Abis over TDM, User Description; 327/1553-HSC 103 12
3. Packet Abis Dimensioning Guideline, User Guide; 227/100 56-
HSC 103 12
4. Adaptive Configuration of Logical Channels, User Description;
267/1553-HSC 103 12/15
5. Radio Network Statistics, User Description; 216/1553-HSC 103
12/18
6. PGW Load Distribution, User Description; 276/1553-HSC 103
12/16
7. SIU Network Integration, Operating Instruction; 1/1543-LZA 104
102/3
8. Discontinuous Transmission, User Description; 305/1553-HSC
103 12
9. Channel Allocation Optimization, User Description; 332/1553-HSC
103 12
10. Interfaces over Satellite, User Description; 266/1553-HSC 103
12/16
11. Abis Local Connectivity, User Description; 313/1553-HSC 103 12
12. Managing Abis over IP, User Guide; 1/1553-3/AOM 901 070
13. Important Guiding Rules when integrating Abis over IP,
Recommendations; 1/100 56-230/FCG 102 55
14. BSS RADIO NETWORK KEY PERFORMANCE INDICATOR (KPI)
GUIDELINE, Recommendations; 212/100 56-HSC 103 12
15. BSS G11B Network Impact Report; 1/109 48-HSC 103 12/18
16. BSS G10B Network Impact Report; 1/109 48-HSC 103 12/16

QHEVIST 2/100 56-600/FCG 102 55 Uen

17. BSS G10A Network Impact Report; 1/109 48-HSC 103 12/15
18. BSS 09A Network Impact Report; 1/109 48-HSC 103 12/14
19. BSS 08B Network Impact Report; 1/109 48-HSC 103 12/13
20. BSS 08A Network Impact Report; 1/109 48-HSC 103 12/12
21. BSS 07B Network Impact Report; 1/109 48-HSC 103 12/11

QHEVIST 2/100 56-600/FCG 102 55 Uen

9 Appedix A Abis over IP feature growth within BSS
releases from 08A to G11B
9.1 BSS G11B
9.1.1 Packet Abis Feature Replacements
The feature Abis Optimization (FAJ 121 997) and Abis over IP (FAJ 121 998)
are replaced by the feature Packet Abis over TDM (FAJ 123 174) and Packet
Abis over IP (FAJ 123 175) respectively.
The functional contents of Packet Abis over TDM correspond to Abis
Optimization. Packet Abis over IP corresponds to Abis over IP with the
addition that the packing algorithm used in Abis Optimization (controlled by
parameter PACKALG) is available.
9.1.2 Improved Speech Path Delay for Packetized Speech
This feature improves the speech path delay for calls using A over IP (FAJ
123 147) in combination with Packet Abis over TDM (FAJ 123 174) or Packet
Abis over IP (FAJ 123 175) which are transcoded outside the BSC or is not
transcoded at all. This is achieved by changing from Group Switch to Ethernet
as transport medium inside the BSC between the Packet Gateway (PGW)
and the A-interface Gateway (AGW).
Furthermore, support for rate adaptation of Circuit Switched Data calls are
introduced in the AGW and will be used when A over IP is activated together
with Packet Abis over IP. Thus no TRA is required in this configuration to
support Circuit Switched Data.
The capacity of the AGW is increased to 2000 simultaneous calls if A over IP
is used in combination with Packet Abis over IP.
9.1.2.1 Characteristics
In a network where A-interface is used in combination with Packet Abis over
IP the speech path delay is reduced with 20 ms in each direction.

QHEVIST 2/100 56-600/FCG 102 55 Uen

9.2 BSS G10B
9.2.1 Abis Optimization and Abis over IP Load Handling Enhancements
The downlink PS scheduling mechanism on Abis Optimization and Abis over
IP is enhanced to improve the Abis utilization at high load. At Abis overload
detection on PS, instead of just preventing setups of new PS services and
then (if this does not help) to escalate to shutting down the entire PS service,
down scheduling of the PS traffic is applied.
By down-scheduling it is meant that PS data scheduling will be omitted to
decrease the load downlink. The ratio of omitted PS data scheduling will
gradually increase, if the overload scenario persist, until all PS data
scheduling are omitted. Once the overload scenario is ceased the ratio of
omitted PS data scheduling will gradually decrease until no PS data
scheduling is omitted.
The GPRS/EDGE characteristics are improved according to the following:
GPRS/EDGE throughput can improve in certain cases, that is the
amount down-scheduling is sufficient to avoid packet loss that would
have resulted in even less throughput than the amount of down-
scheduling results in.
GPRS/EDGE setups prevented due to Abis congestion will reduce due
to the introduction of the new lowest level of Abis overload handling
called down-scheduling.
The time to GPRS/EDGE service being available again after Abis
congestion will decrease.
The Abis utilization at high load of GPRS/EDGE payload will increase.
9.2.2 Increased GPH Capacity for Abis Optimization and Abis over IP
Traffic between GPH and PGW is already today using Ethernet backplane
communication instead of legacy Group Switch communication. Still, the
implementation with its restrictions has been kept. This feature changes the
internal implementation in the GPH which gives an increase in performance.
The GPH HW need for Abis Optimization and Abis over IP will be reduced to
equal or below the HW need when using Flexible Abis. It will be possible to
define more E-GPRS channels per GPH if the load on the GPH allows it. In
order to achieve this gain, allocation of PGW devices for CS calls will be
performed dynamically at request instead of statically at configuration. This
impacts O&M.

QHEVIST 2/100 56-600/FCG 102 55 Uen

Allocation of the PGW devices for circuit switched calls will be performed
dynamic at request instead of at configuration. This might impact times for call
setup and handover slightly.
9.2.3 New Counters in Existing Object Types
Object Type ABISIP
Function Counters for Abis IP
Counter Name Level Size Type Description
IPOVLCSREG TG 32 PC Indicates how long time the CS traffic reduction has been active for
Abis over IP. Measured in seconds. Stepping of this counter indicates
that as good as all PS data scheduling has been omitted. Stepping of this
counter also indicates a decreased level of new and existing CS calls.
IPOVLPSREG TG 32 PC Indicates how long time the PS traffic reduction has been active for
Abis over IP. Measured in seconds. Stepping of this counter indicates
that a number of PS data schedulings have been omitted.
Object Type SUPERCH2
Function Super Channel load and quality counters
SCOVLCSREG Super channel 32 PC Indicates how long time the CS traffic reduction has been active for
Abis Optimization. Measured in seconds. Stepping of this counter
indicates that as good as all PS data scheduling has been omitted.
Stepping of this counter also indicates a decreased level of new and
existing CS calls.
SCOVLPSREG Super channel 32 PC Indicates how long time the PS traffic reduction has been active for
Abis Optimization. Measured in seconds. Stepping of this counter
indicates that a number of PS data schedulings have been omitted.
9.2.4 Modified Counters
Object Type ABISIP
Function Counters for Abis IP
Counter Name Level Size Type New Description
IPOVLL1 TG 16 PC Number of seconds when level 1 actions have been taken to solve
overload on Abis over IP. Level 1 actions reduces load on Abis
interface by removing PS frames from interface, uplink and downlink.
IPOVLL2 TG 16 PC Number of seconds when level 2 actions have been taken to solve
overload on Abis over IP. Level 2 actions reduces load on Abis
interface by removing both PS and CS frames from interface, uplink
and downlink.
9.3 BSS G10A
9.3.1 Abis Local Connectivity Enhancements
The Abis Local Connectivity (ALC) features, Abis Local Connectivity - Satellite
(FAJ 123 142) and Abis Local Connectivity - Terrestrial (FAJ 123 159), have
been enhanced with the following functionality in BSS G10A:
Improved coding matching
Support for locally switched calls using AMR
ALC supporting other vendors Core Network
License Handling

QHEVIST 2/100 56-600/FCG 102 55 Uen

9.3.2 Dynamic Half Rate for AMR-WB
The feature Dynamic Half Rate for AMR-WB introduces a new load threshold
indicating when to allocate HR or AMR HR for AMR WB capable terminals.
This threshold will make it possible to differentiate between AMR-WB capable
MSs and other MSs when a HR channel shall be allocated during high load.
A new parameter indicates if the threshold is applicable only at call setup or
both at call setup and handover.
9.3.2.1 Commands and Printouts
RLDHC: Radio Control Cell, Dynamic HR Allocation Data, Change
RLDHP: Radio Control Cell, Dynamic HR Allocation Data, Print
The existing commands are changed to support the new parameter
DTHAMRWB.
RXATC: Radio X-ceiver Administration, Abis Path Thresholds Data, Change
The existing command is changed to support new parameters
DHRAABISTHRWB and SDHRAABISTHRWB.
9.4 BSS 09A
Object Type PGW
Function Counters for PGW RP CPU load
G2PGW0040LOAD BSC 32 PC
Number of scans where the PGW CPU load on GARP-2 was between 0% and
40%.
60%
80%
90%
100%
Object Type PGW
Function Counter for PGW RP CPU Load
Counter Name Level Size Type Changed behavior
PBPGW0040LOAD BSC 32 PC
Description modified compared to the design base. New description: Number of
scans where the PGW CPU load on PGWB was between 0% and 40%

QHEVIST 2/100 56-600/FCG 102 55 Uen

Object Type SUPERCH
Function Super Channel load and quality counters
Counter Name Level Size Type Changed behavior
THRULPACK SC 32 PC
Description modified compared to the design base. New description: Total
number of discarded CS and PS frames in the SC buffer, UL. This is the sum of
counters ULSCBUFTHR and ULPSSCBUFTHR.
9.5 BSS 08B
9.5.1 Adaptive Timers for Packet Abis
The feature Adaptive Timers for Packet Abis is an enhancement of the packet
Abis features Abis Optimization (FAJ 121 997) and Abis over IP (FAJ 121
998). This feature makes the GPRS/EGPRS behavior more robust and
removes the need for retuning the packet Abis transmission if the
transmission latency varies.
A new regulation algorithm that adapts to varying Abis latency is introduced.
The algorithm makes it possible to use Abis transmission with very high
latency for example satellite transmission or transmission with varying
latency.
With the new regulation algorithm the initial configuration of the network is
much easier and the probability of obtaining a high and stable throughput
increases. The network does not have to be retuned when the latency is
changing when using the new algorithm. The input to the algorithm is the
maximum expected jitter for the round trip latency BTS and BSC (JBPTA).
The configuration is done on TG level.

9.5.2 New Lost Frame and Buffer Delay Measurements for Packet Abis
New Lost Frame and Buffer Delay Measurements for Packet Abis is afeature
enhancement of the packet Abis features Abis Optimization (FAJ 121 997)
and Abis over IP (FAJ 121 998). This feature enhancement improves the
monitoring of existing resources on Packet Abis. The new statistics measures
delay and discarded packets for the packet Abis system. This simplifies both
the daily PM supervision and interpretation of packet Abis influence on main
BSS Key Performance Indicators.
9.5.2.1 STS Counters
The new object type SCABISDEL with 10 new counters is added. The existing
object type SUPERCH has received four new counters and the existing object
type CLDTMPER has received one new counter. There are 9 changed
counters in object type SUPERCH and ABISTG.

QHEVIST 2/100 56-600/FCG 102 55 Uen

9.5.3 PGW on GARP-2
PGW on GARP-2 is a feature that enables the possibility to run the PGW
application on the RP type GARP-2. One GARP-2 can handle double the
amount of traffic compared to one PGWB.
9.5.4 BSC Parameters
Parameter Feature Command Description User Description Comment
JBPTA Adaptive Timers for
Packet Abis
RXMOC
RXMOI
BTS jitter buffer depth for PAL=1 Abis over IP

9.5.5 New Counters in New Object Types
Object Type SCABISDEL
Function Delay measurements per super channel for packet Abis
FJBUFDELDL SC 32 PC Accumulated jitter buffer delay on the DL
FJBUFDLSCAN SC 32 PC Number of accumulations for counter FJBUFDELDL
FJBUFDELUL SC 32 PC Accumulated jitter buffer delay on the UL
FJBUFULSCAN SC 32 PC Number of accumulations for counter FJBUFDELUL
FSCBUFDELDL SC 32 PC Accumulated super channel buffer delay, DL
FSCBUFDLSCAN SC 32 PC Number of accumulations for counter FSCBUFDELDL
FSCBUFDELUL SC 32 PC Accumulated super channel buffer delay, UL
FSCBUFULSCAN SC 32 PC Number of accumulations for counter FSCBUFDELUL
Object Type SUPERCH
Function Super Channel load and quality counters.
FCSLOSTUL SC 32 PC Number of lost and discarded CS frames on the UL during last recording period.
FPSLOSTUL SC 32 PC Number of lost and discarded PS frames on the UL during last recording period.
FCSLOSTDL SC 32 PC Number of lost and discarded CS frames on the DL during last recording period.
FPSLOSTDL SC 32 PC Number of lost and discarded PS frames on the DL during last recording period.
Object type Counter Correction Package
/Feature
Impact
SUPERCH TOTFRDLSCBUF New Lost Frame and
Buffer Delay
Measurements for Packet
Abis
This counter now counts the total number of CS frames entering
the super channel buffers downlink. Previously the counter did not
count discarded frames in the super channel buffer. This counter is
now also valid for Abis over IP. Previously it was only valid for
Abis Optimization.
SUPERCH TOTDLPSSCFRBUF New Lost Frame and
Buffer Delay
Abis
This counter now counts the total number of PS frames entering the
super channel buffers downlink. Previously the counter did not
count discarded frames in the super channel buffer. This counter is
now also valid for Abis over IP. Previously it was only valid for
Abis Optimization.
SUPERCH LOSTULPACK New Lost Frame and
Buffer Delay
Abis
This counter now also count the accumulated number of lost and
discarded CS+PS frames in the UL direction for Abis over IP.
Previously it was only valid for Abis Optimization.
SUPERCH LOSTDLPACK New Lost Frame and
Buffer Delay
This counter now also count the accumulated number of lost and
discarded CS+PS frames in the DL direction for Abis over IP.

QHEVIST 2/100 56-600/FCG 102 55 Uen

Abis
Previously it was only valid for Abis Optimization.
ABISTG UL0025JITBUFDEL New Lost Frame and
Buffer Delay
Abis
This counter now also counts for Abis over IP. Previously it was
only valid for Abis Optimization.
Buffer Delay
Abis
Buffer Delay
Abis
Buffer Delay
Abis
Buffer Delay
Abis
PGW PBPGW0040LOAD PGW on GARP-2 Description modified compared to the design base. New
description: Number of scans where the PGW CPU load on PGWB
was between 0% and 40%
9.5.8 Changed Counters due to Correction Packages
Object type Counter Correction Package Impact
SUPERCH TOTFRDLSCBUF,
TOTDLPSSCFRBUF
IP-A4 The counters TOTFRDLSCBUF and TOTDLPSSCFRBUF in
object type SUPERCH has been corrected to show a correct value
also in the case when more than 50 % of the frames are discarded.
SUPERCH LOSTULPACK IP-A7 The counter LOSTULPACK, which shows how many packets that
are lost on the Abis Interface, will not step as frequent as before
during high traffic load on Abis Opt super channel.

9.6 BSS 08A
9.6.1 STN
Below is a list of different STNs and their support of new features with STN
impact. X indicated means support for stated feature.
STN Feature Support
BSS 08A Improvements SIU STN in RBS 2409
Abis Local Connectivity X X

QHEVIST 2/100 56-600/FCG 102 55 Uen

GSM/WCDMA Transport sharing X
HDLC over IP X
IP over E1/T1 X
Load regulation improvements for
packet Abis
X X
Site LAN X

9.6.2 Abis Local Connectivity
Abis Local Connectivity is an optional feature that requires the STN node.
Abis Local Connectivity makes it possible for operators to reduce Abis
bandwidth requirements to sites where there is a fair amount of local traffic.
The speech frames for calls where the A and B side are located within the
same STN are switched in the STN and not sent to the BSC. All signaling will
still go to the BSC and the MSC. Switching the speech in the STN node
instead of in the core network saves Abis bandwidth and increases the
speech quality as the speech path delay is reduced. This effect is very
tangible when Abis is transported over satellite.
9.6.3 Load Regulation Improvements for Packet Abis
Load Regulation Improvements for Packet Abis is an enhancement to feature
Abis over IP FAJ 121 998 and Abis Optimization FAJ 121 997.
The OVLTH (overload threshold) parameter has been moved from SCGR
(Super Channel Group) to LBG (LAPD Bundling Group) and the behavior
when OVLTH is exceeded has been slightly modified.
The BSC uses the parameter OVLTH to determine when to take steps at Abis
congestion. It is configured from the BSC to the STN on all traffic flows for the
TG. The STN starts reporting actual packet loss detected, to the BSC, when
this threshold is exceeded. For a GSM/WCDMA Transport Sharing solution,
where different Bundling Groups and DSCPs is recommended for different
traffic types/flows/sessions, it is desirable to be able to configure and act on
this threshold being exceeded at LBG level and not on one SCGR level value
used for all sub-flows, as it would be without this change. This improvement
applies to feature Abis over IP
The stopping of the PS traffic is improved by rejecting new UL TBFs in case
of Abis overload. This improvement applies to feature Abis over IP and
feature Abis Optimization.
9.6.3.1 Compatibility
The OVLTH threshold parameter has been moved from SCGR to LBG.
During the upgrade to 08A, if more than one TG is using the same LBG the
OVLTH of the LBG will be set to the lowest OVLTH of the TGs. It is assumed
that the upgraded BSC does not have any overload.

QHEVIST 2/100 56-600/FCG 102 55 Uen

9.6.4 STN system improvements
9.6.4.1 Increased number of time slots on Abis Lower on SIU/STN
It is now possible to use 31 time slots on Abis Lower (between SIU and BTS)
for E1.
9.6.5 Parameter Changes
9.6.5.1 BSC Parameters
Parameter Feature Command Description User Description Comment
CODECREST Abis Local
Connectivity
RLCLC Speech version (SPV) and
channel rate restriction
Abis Local
Connectivity
Function

OVLTH Load Regulation
Improvements for
Packet Abis
RRBGC/I Transmission overload
threshold
Abis over IP Parameter added
OVLTH Load Regulation
Improvements for
Packet Abis
RRSGC/I Transmission overload
threshold
Abis over IP Parameter
removed

9.6.6 Changed Counters due to Correction Packages
Object Type Counter IP-A/CP-A package Description
ABISIP IPSENTKBYTES
IPRECKBYTES
IPDLSENTPACK
IPULRECPACK
IPLOSTPACKUL
IP-A2 Due to a truncating fault when merging most
significant bits to least insignificant bits, STS
counters in object type ABISIP have sometimes
shown wrong values.
SUPERCH TOTFRDLSCBUF,
TOTDLPSSCFRBUF
IP-A10 The counters has been corrected to show a correct
value also in the case when more than 50% of the
frames are discarded.
SUPERCH LOSTULPACK IP-A13 The counter is showing how many packets that are
lost on the Abis Interface, and will decrease during
high traffic load on Abis Opt super channel.

Abis Over IP Tuning GL EsonTemplate-libre

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Abis Over IP Tuning GL EsonTemplate-libre

Diunggah oleh

Hak Cipta:

Format Tersedia

RECOMMENDATIONS 1 (50)

Prepared (also subject responsible if other) No.

Anda mungkin juga menyukai