Professional Documents
Culture Documents
Abis Over IP Tuning
Abis Over IP Tuning
1 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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
Prepared (also subject responsible if other)
2 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Revision history
Rev
A
Date
2011-03-17
Description
1st version
Reference
RECOMMENDATIONS
Prepared (also subject responsible if other)
3 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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
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
References ............................................................................................. 40
RECOMMENDATIONS
Prepared (also subject responsible if other)
4 (50)
No.
QHEVIST
Approved
Checked
9.4
9.5
9.6
Date
Rev
2011-03-17
Reference
BSS 09A.................................................................................... 45
BSS 08B.................................................................................... 46
BSS 08A.................................................................................... 48
RECOMMENDATIONS
Prepared (also subject responsible if other)
5 (50)
No.
QHEVIST
Approved
Checked
Introduction
1.1
Background
Date
Rev
2011-03-17
Reference
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
Prepared (also subject responsible if other)
6 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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 redefined 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
Prepared (also subject responsible if other)
7 (50)
No.
QHEVIST
Approved
Checked
1.4
Date
Rev
2011-03-17
Reference
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
8 (50)
No.
QHEVIST
Approved
Checked
1.6
Date
Rev
2011-03-17
Reference
Concepts
Accessibility
Delay
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
Jitter
Jitter buffer
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
Retainability
1.7
Abbreviations
AMR
DHA
DYMA
FR
Full Rate
RECOMMENDATIONS
Prepared (also subject responsible if other)
9 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
HR
Half Rate
KPI
LBG
MML
MS
Mobile Station
PTA
SDCCH
SLA
TBF
TCH
Traffic channel
TFP
TG
Transceiver Group
RECOMMENDATIONS
Prepared (also subject responsible if other)
10 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Technical background
2.1
General
Figure 1
Reference
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
Prepared (also subject responsible if other)
11 (50)
No.
QHEVIST
Approved
Checked
2.2
Date
Rev
2011-03-17
Reference
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
RECOMMENDATIONS
Prepared (also subject responsible if other)
12 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
RECOMMENDATIONS
Prepared (also subject responsible if other)
13 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
14 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
E r la n g
[E r la n g in 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
RECOMMENDATIONS
Prepared (also subject responsible if other)
15 (50)
No.
QHEVIST
Approved
Checked
3.1.2
Date
Rev
2011-03-17
Reference
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 radio resource usage
Increased speech path delay
Increased roundtrip delay for GPRS/EGPRS
Decreased GPRS/EGPRS throughput
Decreased accessibility and retainability
As an example the SDCCH usage will increase due to a delay variation giving
temporarily high delays. See the measurements in Figure 3.
RECOMMENDATIONS
Prepared (also subject responsible if other)
16 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
180
160
140
120
100
80
60
40
20
3.2.2
Counter measures
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
17 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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:
Increased radio resource usage
Decreased speech quality
Decreased GPRS/EGPRS throughput
Decreased accessibility and retainability
Increased roundtrip delay for GRPS/EGPRS
3.3.2
Counter measures
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
Prepared (also subject responsible if other)
18 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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:
Increased radio resource usage
Decreased speech quality
Decreased GPRS/EGPRS throughput
Decreased accessibility and retainability
See for example Figure 4.
RECOMMENDATIONS
Prepared (also subject responsible if other)
19 (50)
No.
QHEVIST
Approved
Checked
3.4.2
Date
Rev
2011-03-17
Reference
Counter measures
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
20 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
21 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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
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
RECOMMENDATIONS
Prepared (also subject responsible if other)
22 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
4.2.6
4.2.7
4.2.8
RECOMMENDATIONS
Prepared (also subject responsible if other)
23 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
18
16
14
12
10
Packet Loss %
0
4.2.9
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
RECOMMENDATIONS
Prepared (also subject responsible if other)
24 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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
5.1.1.1
CS Services
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
25 (50)
No.
QHEVIST
Approved
Checked
5.1.1.2
Date
Rev
2011-03-17
Reference
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
smaller value. For further info if a change is applicable and how to tune it, see
the setting of JBSUL in 5.2.1.
5.1.2
5.1.2.1
PS Services
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
26 (50)
No.
QHEVIST
Approved
Checked
5.1.2.2
Date
Rev
2011-03-17
Reference
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
smaller value. For further info if a change is applicable and how to tune it, see
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
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 ,
RECOMMENDATIONS
Prepared (also subject responsible if other)
27 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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 5th 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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
28 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
PS Services
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
-anddecrease of JBPTA
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
29 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
30 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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
link relative the engineered bandwidth in the
STN
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) [%]
RECOMMENDATIONS
Prepared (also subject responsible if other)
31 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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
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].
RECOMMENDATIONS
Prepared (also subject responsible if other)
32 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
Note that an increased buffer size will also will increase the
delay.
RECOMMENDATIONS
Prepared (also subject responsible if other)
33 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Hardware Supervision
6.1
BSC
Reference
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
34 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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
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].
RECOMMENDATIONS
Prepared (also subject responsible if other)
35 (50)
No.
QHEVIST
Approved
Checked
7.2
Date
Rev
2011-03-17
Reference
7.2.1
Parameters
PACKALG = 1 is recommended, See reference [1].
7.3
7.3.1
Parameters
The functionality is turned ON or OFF by the parameter DAMRCRABIS per
cell see reference [1].
RECOMMENDATIONS
Prepared (also subject responsible if other)
36 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
7.4
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
Prepared (also subject responsible if other)
37 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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
RECOMMENDATIONS
Prepared (also subject responsible if other)
38 (50)
No.
QHEVIST
Approved
Checked
7.5.1
Date
Rev
2011-03-17
Reference
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
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
RECOMMENDATIONS
Prepared (also subject responsible if other)
39 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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
Prepared (also subject responsible if other)
40 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
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 56HSC 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
RECOMMENDATIONS
Prepared (also subject responsible if other)
QHEVIST
Approved
41 (50)
No.
Date
Rev
2011-03-17
Reference
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
Prepared (also subject responsible if other)
42 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
9.1
BSS G11B
9.1.1
9.1.2
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
43 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
9.2
BSS G10B
9.2.1
9.2.1.1
Characteristics
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 downscheduling 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
RECOMMENDATIONS
Prepared (also subject responsible if other)
44 (50)
No.
QHEVIST
Approved
Checked
9.2.2.1
Date
Rev
2011-03-17
Reference
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.
9.2.3
Object Type
Function
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
Counter Name
Level
Size
Type
Description
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
Counter Name
Level
Size
Type
New Description
IPOVLL1
TG
16
PC
IPOVLL2
TG
16
PC
9.3
BSS G10A
9.3.1
RECOMMENDATIONS
Prepared (also subject responsible if other)
45 (50)
No.
QHEVIST
Approved
Checked
9.3.2
Date
Rev
2011-03-17
Reference
9.3.2.1
9.4
BSS 09A
9.4.1
Object Type
Function
Counter Name
Level
Size
Type
G2PGW0040LOAD
BSC
32
PC
Description
Number of scans where the PGW CPU load on GARP-2 was between 0% and
40%.
G2PGW4160LOAD
BSC
32
PC
Number of scans where the PGW CPU load on GARP-2 was between 41% and
60%
G2PGW6180LOAD
BSC
32
PC
Number of scans where the PGW CPU load on GARP-2 was between 61% and
80%
G2PGW8190LOAD
BSC
32
PC
Number of scans where the PGW CPU load on GARP-2 was between 81% and
90%
G2PGW9100LOAD
BSC
32
PC
Number of scans where the PGW CPU load on GARP-2 was between 91% and
100%
9.4.2
Object Type
Modified Counters
PGW
Function
Counter Name
Level
Size
Type
PBPGW0040LOAD
BSC
32
PC
Changed behavior
Description modified compared to the design base. New description: Number of
scans where the PGW CPU load on PGWB was between 0% and 40%
PBPGW4160LOAD
BSC
32
PC
PBPGW6180LOAD
BSC
32
PC
PBPGW8190LOAD
BSC
32
PC
PBPGW9100LOAD
BSC
32
PC
RECOMMENDATIONS
Prepared (also subject responsible if other)
46 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
SUPERCH
Function
Counter Name
Level
THRULPACK
SC
Size
32
Type
Changed behavior
PC
9.5
BSS 08B
9.5.1
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.
RECOMMENDATIONS
Prepared (also subject responsible if other)
47 (50)
No.
QHEVIST
Approved
Checked
9.5.3
Date
Rev
2011-03-17
Reference
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
JBPTA
9.5.5
Object Type
Command
Description
User Description
Abis over IP
Comment
Function
Counter Name
FJBUFDELDL
Level
SC
Size
32
Type
PC
Description
Accumulated jitter buffer delay on the DL
FJBUFDLSCAN
SC
32
PC
FJBUFDELUL
SC
32
PC
FJBUFULSCAN
SC
32
PC
FSCBUFDELDL
SC
32
PC
FSCBUFDLSCAN
SC
32
PC
FSCBUFDELUL
SC
32
PC
FSCBUFULSCAN
SC
32
PC
9.5.6
Object Type
SUPERCH
Function
Counter Name
Level
Size
Type
Description
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.
9.5.7
Modified Counters
Object type
Counter
Correction Package
/Feature
Impact
SUPERCH
TOTFRDLSCBUF
SUPERCH
TOTDLPSSCFRBUF
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
SUPERCH
LOSTDLPACK
This counter now also count the accumulated number of lost and
discarded CS+PS frames in the DL direction for Abis over IP.
RECOMMENDATIONS
Prepared (also subject responsible if other)
48 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
Measurements for Packet Previously it was only valid for Abis Optimization.
Abis
ABISTG
UL0025JITBUFDEL
ABISTG
UL2650JITBUFDEL
ABISTG
UL5175JITBUFDEL
ABISTG
UL7600JITBUFDEL
ABISTG
UL100JITBUFDEL
PGW
PBPGW0040LOAD
PGW on GARP-2
PGW
PBPGW4160LOAD
PGW on GARP-2
PGW
PBPGW6180LOAD
PGW on GARP-2
PGW
PBPGW8190LOAD
PGW on GARP-2
PGW
PBPGW9100LOAD
PGW on GARP-2
9.5.8
Object type
SUPERCH
Counter
TOTFRDLSCBUF,
TOTDLPSSCFRBUF
Correction Package
IP-A4
Impact
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
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.
SIU
RECOMMENDATIONS
Prepared (also subject responsible if other)
49 (50)
No.
QHEVIST
Approved
Checked
Rev
Reference
HDLC over IP
IP over E1/T1
Site LAN
9.6.2
Date
2011-03-17
9.6.3
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
Prepared (also subject responsible if other)
50 (50)
No.
QHEVIST
Approved
Checked
Date
Rev
2011-03-17
Reference
9.6.4
9.6.4.1
9.6.5
9.6.5.1
Parameter Changes
BSC Parameters
Parameter
Feature
Command
Description
User Description
CODECREST
Abis Local
Connectivity
RLCLC
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
Comment
Object Type
ABISIP
Counter
IPSENTKBYTES
IPRECKBYTES
IPDLSENTPACK
IPULRECPACK
IPLOSTPACKUL
SUPERCH
TOTFRDLSCBUF,
TOTDLPSSCFRBUF
IP-A10
SUPERCH
LOSTULPACK
IP-A13