Beruflich Dokumente
Kultur Dokumente
© 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.
RECOMMENDATIONS 2 (50)
Prepared (also subject responsible if other) No.
Revision history
Rev Date Description
A 2011-03-17 1st version
RECOMMENDATIONS 3 (50)
Prepared (also subject responsible if other) No.
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
RECOMMENDATIONS 4 (50)
Prepared (also subject responsible if other) No.
1 Introduction
1.1 Background
Bandwidth
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
RECOMMENDATIONS 6 (50)
Prepared (also subject responsible if other) No.
Which KPIs and counters that are of the most interest to observe for
the Abis over IP performance
This document can also be used as help for trouble shooters working with
BSS systems and Abis over IP for:
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].
RECOMMENDATIONS 7 (50)
Prepared (also subject responsible if other) No.
1.4 Prerequisites
1.5 Assumptions
The tuning guide is based on the Abis over IP feature and dependent features
in a BSS of revision G11B.
RECOMMENDATIONS 8 (50)
Prepared (also subject responsible if other) No.
1.6 Concepts
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.
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
1.7 Abbreviations
FR Full Rate
RECOMMENDATIONS 9 (50)
Prepared (also subject responsible if other) No.
HR Half Rate
MS Mobile Station
TG Transceiver Group
RECOMMENDATIONS 10 (50)
Prepared (also subject responsible if other) No.
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.
RECOMMENDATIONS 11 (50)
Prepared (also subject responsible if other) No.
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
3.1 Delay
3.1.1 Impact
[E r la n g in c r e a s e % ]
]
E r la n g
[
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
RECOMMENDATIONS 15 (50)
Prepared (also subject responsible if other) No.
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.1 Impact
As an example the SDCCH usage will increase due to a delay variation giving
temporarily high delays. See the measurements in Figure 3.
RECOMMENDATIONS 16 (50)
Prepared (also subject responsible if other) No.
200
180
160
140
120
100
80
60
40
20
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.
RECOMMENDATIONS 17 (50)
Prepared (also subject responsible if other) No.
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.
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.
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.
The best counter measure against drop in available bandwidth is to have Abis
over IP properly dimensioned or possibly over-provision the needed
bandwidth.
RECOMMENDATIONS 18 (50)
Prepared (also subject responsible if other) No.
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.1 Impact
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:
Increased radio resource usage
Decreased speech quality
Decreased GPRS/EGPRS throughput
Decreased accessibility and retainability
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.
RECOMMENDATIONS 20 (50)
Prepared (also subject responsible if other) No.
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.
The CS KPIs are grouped in the areas accessibility, retainability and integrity
as defined by ITU.
Accessibility covers:
Retainability includes:
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.
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
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.
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.
RECOMMENDATIONS 22 (50)
Prepared (also subject responsible if other) No.
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.
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.
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.
At Abis link outage the KPI will be affected, but this cannot be directly
measured using Abis over IP counters.
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.
16
14
12
10
Packet Loss %
0
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.
5.1 Delay
The formulas of the Total Delay for CS and PS are taken from reference [5].
5.1.1 CS Services
5.1.1.1 Downlink
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.
RECOMMENDATIONS 25 (50)
Prepared (also subject responsible if other) No.
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.
5.1.1.3 Uplink
5.1.1.4 Parameters
5.1.2 PS Services
5.1.2.1 Downlink
5.1.2.2 Parameters
5.1.2.3 Uplink
5.1.2.4 Parameters
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
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.
5.2.1.2 Parameters
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.
RECOMMENDATIONS 28 (50)
Prepared (also subject responsible if other) No.
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.
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.
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.
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
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.
RECOMMENDATIONS 30 (50)
Prepared (also subject responsible if other) No.
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:
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.
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.1 Counters
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].
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.
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]:
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
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 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.
RECOMMENDATIONS 33 (50)
Prepared (also subject responsible if other) No.
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
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.
RECOMMENDATIONS 34 (50)
Prepared (also subject responsible if other) No.
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
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:
7.1.1 Parameters
Recommendation:
Note: Before the BSS release G11B the algorithm was only available together
with the Abis Optimization feature.
7.2.1 Parameters
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.
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:
7.3.1 Parameters
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.
RECOMMENDATIONS 37 (50)
Prepared (also subject responsible if other) No.
Recommendation:
7.4.1 Parameters
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].
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:
7.5.1 Parameters
This feature makes sure that the system can handle long delays introduced
by e.g. a satellite connection.
Recommendation:
7.6.1 Parameters
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.
RECOMMENDATIONS 39 (50)
Prepared (also subject responsible if other) No.
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].
RECOMMENDATIONS 40 (50)
Prepared (also subject responsible if other) No.
8 References
12. Managing Abis over IP, User Guide; 1/1553-3/AOM 901 070
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
RECOMMENDATIONS 41 (50)
Prepared (also subject responsible if other) No.
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
RECOMMENDATIONS 42 (50)
Prepared (also subject responsible if other) No.
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.
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.
9.1.2.1 Characteristics
9.2.1.1 Characteristics
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.
RECOMMENDATIONS 44 (50)
Prepared (also subject responsible if other) No.
9.2.2.1 Characteristics
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.
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
RECOMMENDATIONS 45 (50)
Prepared (also subject responsible if other) No.
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.
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.
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.
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.
RECOMMENDATIONS 47 (50)
Prepared (also subject responsible if other) No.
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.
Measurements for Packet Previously it was only valid for Abis Optimization.
Abis
ABISTG UL0025JITBUFDEL New Lost Frame and This counter now also counts for Abis over IP. Previously it was
Buffer Delay only valid for Abis Optimization.
Measurements for Packet
Abis
ABISTG UL2650JITBUFDEL New Lost Frame and This counter now also counts for Abis over IP. Previously it was
Buffer Delay only valid for Abis Optimization.
Measurements for Packet
Abis
ABISTG UL5175JITBUFDEL New Lost Frame and This counter now also counts for Abis over IP. Previously it was
Buffer Delay only valid for Abis Optimization.
Measurements for Packet
Abis
ABISTG UL7600JITBUFDEL New Lost Frame and This counter now also counts for Abis over IP. Previously it was
Buffer Delay only valid for Abis Optimization.
Measurements for Packet
Abis
ABISTG UL100JITBUFDEL New Lost Frame and This counter now also counts for Abis over IP. Previously it was
Buffer Delay only valid for Abis Optimization.
Measurements for Packet
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%
PGW PBPGW4160LOAD 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 41% and 60%
PGW PBPGW6180LOAD 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 61% and 80%
PGW PBPGW8190LOAD 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 81% and 90%
PGW PBPGW9100LOAD 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 91% and 100%
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
RECOMMENDATIONS 49 (50)
Prepared (also subject responsible if other) No.
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.
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
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.
RECOMMENDATIONS 50 (50)
Prepared (also subject responsible if other) No.
It is now possible to use 31 time slots on Abis Lower (between SIU and BTS)
for E1.