abis over ip tuning gl esontemplate-libre

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

QHEVIST 2/100 56-600/FCG 102 55 Uen Approved Checked Date Rev Reference

EAB/FJG/ST [Fredrik Wistmarker] 2011-03-17 A

Abis over IP Tuning Guideline

© Ericsson AB 2011. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document. Ericsson is the trademark or registered trademark of Telefonaktiebolaget LM Ericsson. All other trademarks mentioned herein are the property of their respective owners.




Revision history

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




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 ................................................................................................. 347.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




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




1 Introduction

1.1 Background

When Abis over IP is deployed and integrated according to dimensioning, deployment and integration guidelines, the system ideally works fine. However, since Abis over IP is highly dependent on the underlying IP service transport which by nature usually not is as static as classical TDM networks, changes in the IP network characteristics may result in changed KPIs. Therefore there might be a need to tune Abis over IP after the deployment.

Trying to tune Abis over IP in an optimal way is a complex task. This document tries to give hints and ideas on how to tune Abis over IP based on performance monitoring of KPIs and other counters. A basis for the tuning is the given underlying IP network with its specific characteristic. The IP transport network characteristics are defined by the four time variant parameters:

Bandwidth

Packet loss ratio

Delay

Delay variation.

The document will show what KPIs and Abis over IP counters that indicate that there are gains in tuning Abis over IP or dependent features that are using Abis over IP. Some guiding of in which direction and which parameters that could be tuned for improved system performance will be presented. To be noted is that exact values will mostly not be given since they are dependent on the specific situation, instead a discussion based on the default or recommended values according to the User Descriptions (references 1, 4, 8, 9, 10 and 11) will apply.

1.2 Purpose

The intended readers of the document are people within Ericsson involved in Abis over IP deployments or trials working in MUs or GSDCs that need to know more about the Abis over IP feature and the connection between its performance and configuration management.

After reading the guideline, the reader shall have a better understanding of:

Abis over IP




The dependence to the underlying IP service

Which KPIs and counters that are of the most interest to observe for the Abis over IP performance

Which parameters that can be tuned based on observations

It shall be easier to deduce if there might be problems with the underlying transport, or if Abis over IP is configured in a non-optimal way.

The tuning is mainly focused on the Abis upper interface.

This document can also be used as help for trouble shooters working with BSS systems and Abis over IP for:

Finding better configurations for the existing system

Concluding if a stated degraded characteristic is due to a badly configured BSS system or external impact.

1.3 Readers guide

The document starts with a background chapter describing the technical scope and the problems encountered when tuning the Abis over IP feature. It is followed by a general chapter about the main characteristics of an IP network and how they affect a BSS system using Abis over IP as a RAN transmission means. There are also some general counter measures on Abis over IP feature level described.

In chapter 4 a description of the impacts that the changes in the underlying IP transmission may have on important BSS KPIs is shown. The KPIs are part of the first line of observable performance statistics of Abis over IP. For each KPI there is a reference to a suitable second line of Abis over IP performance counter in chapter 5 where a more detailed description of counters and possible parameter settings is presented.

In chapter 6 a short summary of the Alarm supervision of the different parts of the Abis over IP system is provided.

Important features that may influence the end user performance or KPIs when using Abis over IP as a transmission means and their settings and references to applicable documentation is presented in chapter 7.

As an Appendix the feature growth of the Abis over IP feature from BSS 08A to BSS G11B is shown. Here information about e.g. when some parameter settings were introduced, how performance counters have been defined or re-defined during releases or when new features have been introduced is provided. The appendix is based on the information in the Network Impact Reports for the different releases; see reference [15] to [21].




1.4 Prerequisites

The IP network should have been properly dimensioned according to the rules and guidelines in reference 3

It is assumed that there is a deployed and integrated Abis over IP network up and running.

An operational support system such as OSS-RC should be used to access PM counters as well as to manage [12].

1.5 Assumptions

The tuning guide is based on the Abis over IP feature and dependent features in a BSS of revision G11B.




1.6 Concepts

Accessibility Accessibility is a part of the classification of the CS performance which

congestion as well as a high random access as well as TCH assignment success rate.

Delay In this document, the time to transmit information from point A to point B.

Delay Variation The variation of the delay, from the lowest to the highest, over some period of time. The highest delay may in some situations be capped, e.g. by the maximum time the receiving end can wait for the packet.

Integrity Integrity is a part of the classification of the CS performance which

Jitter In this document, the same as Delay Variation.

Jitter buffer At the edge between an asynchronous and synchronous packet transport, a jitter buffer may be needed to handle the delay variation and make sure a packet is available when needed by the synchronous transport. The jitter buffer is a queue where the packets may be queued for at least a time corresponding to the delay variation.

LAPD Bundling Group A LAPD Bundling Group is called LBG and is used as a profile by TGs. Enabling Quality of Service requires that the operator creates one LBG for each priority level and has DSCP enabled in the IP network

Packet loss Describing a loss of a packet on a specific protocol layer. It may be caused by either a packet drop or an error in the transmission path.

Retainability Retainability is a part of the classification of the CS performance which de a low TCH drop rate as well as

few minutes with TCH drop as well as handover scenarios with low drop rates and high success rates.

1.7 Abbreviations

AMR Adaptive Multi Rate

DHA Dynamic Half Rate Allocation

DYMA Dynamic Full Rate/Half Rate Adaptation

FR Full Rate




HR Half Rate

KPI Key Performance Indicator

LBG LAPD Bundling Group

MML Man Machine Language

MS Mobile Station

PTA Packet Timing Advance

SDCCH Stand-alone Dedicated Control Channel

SLA Service Level Agreement

TBF Temporary Block Flow

TCH Traffic channel

TFP Traffic Forwarding Protocol

TG Transceiver Group




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.




2.2 Static configuration vs. Dynamic behavior

Abis over IP system performance is monitored using applicable KPIs. When it comes to the measured system performance it is a result of the configuration of the Abis over IP system in combination with the input traffic patterns and the performance of the used IP transmission services.

The GSM traffic pattern is by its nature a time variant dynamic process, so is the random behavior that is disturbing the underlying transmission services. However, the Abis over IP configuration is a static configuration that may be changed, but at discrete moments in time.

Some parts in the system do have dynamic behavior. For example there are features within Abis over IP that adapt buffer sizes to the actual load and delay. There are also overload prevention algorithms that reduce the needed bandwidth on the cost of possibly worse speech quality. These features are part of the BSS solution that makes the system resilient to disturbances.

To tune the Abis over IP solution will thus imply checking the KPIs and by further monitoring of counters in the system find out what parameters that are to be changed and to what value. This is not something that the system does dynamically today, but it is a manual procedure. A changed configuration is given manually to the system through e.g. OSS-applications and MML commands.

2.3 Trade-offs

There are some inherent performance trade-offs in Abis over IP.

Generally speaking, there is a trade-off between the choices of configuring Abis over IP to cater for a bad underlying IP transmission or trying to

mostly a good transmission.

A bad underlying IP service cannot be neglected when it comes to Abis over IP performance but must be taken care of with correct configuration of the system. At the same time, this configuration will not be optimal with respect to e.g. throughput and delay when the transmission service gets better.

Other examples on trade-off decisions are e.g.:

There is a decision between the costs for over-dimensioning the Abis lower interface compared to the risk of not having the needed bandwidth from the STNs to the BTSes.

There might be a need to optimize for a decent usage of the bandwidth by minimizing the overhead. In Abis over IP this is accomplished by bundling many packets into one large packet and thus maximizing the payload/header ratio. This procedure will buffer and process many small packets, thus introducing a delay. There is a choice to make between having a low delay and a low probability of packet loss by using a small




bundling factor or trying to use a smaller bandwidth by using a large bundling factor.

In this document there will be some discussions when it comes to parameter settings that do imply trade-offs regarding the Abis over IP performance.




3 IP Transport Network characteristics impact on BSS performance

3.1 Delay

3.1.1 Impact

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




[Erl

an

g]

[Erl

an

gin

cre

as

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




3.1.2 Counter measures

Signaling is more sensitive to delays compared to CS traffic, since an increased delay together with the roughly equally sized signaling packets implies a reduced signaling bandwidth. There are techniques and functions within Abis over IP taking care of this controlled by the parameters SIGDEL and LDEL. The parameters should be configured to values matching the expected total BSC BTS delay. See reference [4] for suggested values.

The feature Adaptive Configuration of SDCCHs, see 7.5, is recommended to use for maximizing the probability that there are available SDCCHs also at delays.

To be noted is that the configured Jitter Buffer Delay is not influencing the signaling delay, since the signaling packets are routed directly to the receiving end without first being placed into a Jitter Buffer.

3.2 Delay variation

3.2.1 Impact

A degraded underlying IP service in terms of a reduced amount of available bandwidth will, considering the same traffic model as before, lead to an increased transmission delay variation when buffers are filled and emptied to a larger extent.

An increased transmission delay variation when using Abis over IP will on a high level impact the BSS system similar to delay through:


Increased speech path delay

Increased roundtrip delay for GPRS/EGPRS

Decreased GPRS/EGPRS throughput


As an example the SDCCH usage will increase due to a delay variation giving temporarily high delays. See the measurements in Figure 3.




KPIs as a function of super channel measured jitter

0

20

40

60

80

100

120

140

160

180

200

max Delay variation in ms

TCH ass success rate (%) SDCCH erlang difference (%)

TCH erlang difference (%)

Figure 3 Measurements on the SDCCH Erlang difference due to transmission Delay variation


The delay variation may be modeled as consisting of two parts:

A slow variation of the delay, called wander

A fast variation of the delay, called jitter A wander may be taken care of with e.g. different Timing Advance algorithms, while a jitter needs some kind of jitter buffer of correct size.

As of today, there are jitter buffers for CS and PS whose settings are a part of a proper dimensioning of the Abis over IP network. There are recommended values for all buffers settings as JBPTA for the PS service and JBSUL and JBSDL for the CS service in the UD [1].

The behavior of CS and PS traffic is a bit different when it comes to the jitter buffers.

For PS there is a Packet Timing Advance value that is used in a Packet timing advance mechanism. This value could either be manually set, in the parameter PTA, or adaptively changed if using the Adaptive Timers for Packet Abis feature, enabled by parameter PAL. It is highly recommended to use the Adaptive timers for Packet Abis feature. In the PAL case the wander is taken care of automatically.




The PTA adaptation algorithm used in Adaptive Timers for Packet Abis handles the wander but still needs a jitter buffer taking care of the fast variation. Therefore it is important to use a decent value of JBPTA to cope for the expected fast delay variation. If having a too small JBPTA value, some delayed PS packets could get lost.

In the CS case the wander is always taken care of automatically. If an increased jitter is leading to a frame arriving too late at the BTS or BSC this will result in a larger JBSDL or JBSUL in units of 20 ms, thus taking care of an increase of the delay variation.

The suggested values to use for the jitter buffers are the smallest usable one in terms of lost packets to decrease the introduced delay. A large value will introduce a delay that might be unwanted since it e.g. impacts end-user perceived speech quality.

The feature Adaptive Configuration of SDCCHs, see 7.5, is recommended to use for maximizing the probability that there are available SDCCHs also at delays.

3.3 Bandwidth

3.3.1 Impact

A properly dimensioned Abis over IP network will have the bandwidth needed for most traffic cases. The dimensioning guidelines given in [3] will give a formula giving the expected bandwidth that is needed for CS, PS and signaling. The bandwidth on the Abis lower interface should be dimensioned to take care of all expected traffic cases, or even be over-provisioned.

A degraded underlying IP service that reduces the available transmission bandwidth will lead to lost packets and larger delays and delay variations due to more extensive use of buffers in the system.

A transmission bandwidth decrease when using Abis over IP will on a high level impact the BSS system through:


Decreased speech quality



Increased roundtrip delay for GRPS/EGPRS


The best counter measure against drop in available bandwidth is to have Abis over IP properly dimensioned or possibly over-provision the needed bandwidth.




Within BSS there are numerous techniques for reducing needed bandwidth, e.g. DTX (see 7.1) and a Packet Abis packing algorithm, enabled by setting the parameter PACKALG=1, see [1].

Another possibility is to increase the bundling parts of Abis over IP, thus reducing the overhead needed for the transport over Abis. This will however increase the delay and the packet loss ratio in the system, since each bundled packet will include more CS and PS packets.

There are BSS overload prevention features that may reduce the probability of a congested system by, at configurable thresholds, reducing the needed bandwidth by changing speech codecs to HR or AMR-HR, on behalf of speech quality. It is recommended to use these features to increase the speech throughput.

There are built-in overload handling mechanisms that try to optimize the bandwidth use from a user perspective whenever the overload is a fact. A careful use of the overload handling mechanism is recommended, see 5.4.2.

3.4 Packet Loss

3.4.1 Impact

Dropped packets transported over Abis will lead to different behavior depending on the contents in the lost packet.

For streaming services like speech it is not very crucial with lost packets in other sense than it degrades the speech quality. For PS services it might be crucial and lead to longer end user delays, if reliable upper protocols are used and therefore need resending of packets. If a packet on Abis including signaling information is dropped, it will have even more impact. A lost control message may lead to failed attempts to set up TCHs or lost access requests that might time out before a renewed attempt.

Packet drop when using Abis over IP will on a high level impact the BSS system through:


Decreased speech quality



See for example Figure 4.





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.




4 Important BSS KPIs influenced by Abis over IP

4.1 General

The most important system characteristic is seen in the KPIs monitored by the operators as defined in [5] and recommended in [14]. The main idea in this document is to use these KPIs as a first line of observable performance counters.

If the KPIs show bad performance in any way, and there is a suspicion that the underlying IP transmission is the main source of performance decrease, a suggested second line of Abis over IP performance indicators in chapter 5 shall be monitored. Based on these observations, some conclusions may be drawn on how to identify the reason and adapt the feature to make it work in a more efficient way.

There is an assumption that the Abis lower transmission is dimensioned

will be from the Abis upper part of the transmission.

The CS KPIs are grouped in the areas accessibility, retainability and integrity as defined by ITU.

Accessibility covers:

Random access success rate

SDCCH Drop rate

SDCCH time congestion

TCH Assignment success rate.

Retainability includes:

TCH Drop rate

Handover success rate

Call minutes per drop

Handover lost rate.




Integrity KPIs are based on Speech Quality Supervision function, where the radio conditions are converted to a Speech Quality Index (SQI). Unfortunately

KPIs will not change although the Speech Quality might be influenced by the Abis performance, see 4.2.10.

To make it possible to evaluate GPRS/EGPRS end-user performance in a -user

performance tests, see [5].

4.2 Important BSS KPIs

In the following sections from chapter 8 in reference [5

transmission is shown. The descriptions are valid during normal running conditions, i.e. the Abis over IP transmission is not completely down.

4.2.1 IP Transfer interrupts

These KPIs will be influenced by longer interrupts on the Abis transmission. Long interrupts could potentially lead to lost TBFs. The lost TBFs will be

visible in the counters LDISRR and IAULREL in object CELLGPRS2; and

LDISRRSUB and IAULRELSUB are in object CELLGPRSO

To check if the interrupts are due to congestion in the Abis transmission, check the overload and packet loss counters in chapter 5.4.1.

4.2.2 GPRS Availability

This KPI is influenced by, possibly temporary, lack of Abis resources due to e.g. congestion. Check Abis overload counters in chapter 5.4.1

4.2.3 IP Latency GPRS

The GPRS IP latency KPIs includes packet Abis delays except packets arriving too early or too late outside the measuring window used. Unless having a high delay variance on Abis, the KPIs could be considered as showing the experienced latency.

4.2.4 IP Throughput and Radio Link Bitrate measurements

These KPIs will be influenced by bad transmission on Abis or over the air interface. The KPIs do not separate between the two causes so it is not directly observable if the effect is due to Abis or air interface problems.




If there is an Abis overload situation, this may result in fewer available PDCHs. This will be visible in multislot utilization and traffic load counters

found in object types TRAFDLGPRS, TRAFULGPRS, TRAFGPRS2 and

TRAFGPRS3, respectively, see reference [5].

The GPRS throughput KPIs will be affected by impacted number of TBFs due to e.g. the overload actions that are taken during overload.

In order to further check if the cause is due to the settings of Abis over IP it is suggested to check out the counters for delay, delay variation, Packet Loss ratio and overload counters in the chapters 5.1 to 5.3.

4.2.5 IP User Data Volume

These KPIs are influenced by the Abis over IP transmission. A changed user data volume may be a result of a changed performance of the Abis interface.

The packet loss ratio and overload counters, see 5.4.1, are indicators of the current Abis situation.

4.2.6 CS Accessibility - Random access success rate

This KPI will be influenced by Abis over IP only at very bad conditions, since the overload mechanisms try to keep CHANNEL REQUIRED message. If not finding this KPI behaving as expected, check out the overload and packet loss ratio counters in chapter 5.4.1.

4.2.7 CS Accessibility - SDCCH Time Congestion

At Abis link outage the KPI will be affected, but this cannot be directly measured using Abis over IP counters.

4.2.8 CS Accessibility - SDCCH Drop rate

The SDCCH drop rate is influenced by the Abis over IP interface. When packets are lost the SDCCH resources are occupied for a longer time than expected. When the packet loss ratio is increasing the SDCCH drop rate is also increasing, see Figure 4.

Indications if the underlying transmission is influencing the SDCCH drop rate are found in the overload and the packet loss counters in 5.4.1.




0

2

4

6

8

10

12

14

16

18

TCH assignment failure SDCCH drop rate

Packet Loss %

Figure 4 TCH assignment failure and SDCCH Drop Rate as a function of packet loss ratio.

4.2.9 CS Accessibility - TCH Assignment success rate

The KPI is influenced if there is congestion in the transmission leading to longer RTTs or increased packet losses, see also Figure 4. Check out the overload and packet loss ration counters in chapter 5.4.1

4.2.10 CS Integrity SQI

The KPIs are currently only influenced by the radio interface transmission, thus not influenced by Abis over IP.

There is for the moment no observability on the Abis delay or packet loss impact on CS integrity. However, if there are excessive delays or packet loss ratio on Abis of more than 0.1 % it is likely to have CS integrity issues.

4.2.11 CS Traffic Volume

The KPI is influenced if there is congestion and/or packet losses in the transmission leading to dropped SDCCHs, TCH assignment failures (see Figure 4) and possibly IP overload handling kicking in leading to a further increase of packet losses. Check out chapter 5.4.1




5 Abis over IP tuning based on Performance Indicators

This chapter describes the specific Abis over IP performance indicators for delay, delay variation, packet loss and bandwidth, how those are influenced by the configuration of Abis over IP and possible new configuration settings improving the Abis over IP performance.

5.1 Delay

The formulas of the Total Delay for CS and PS are taken from reference [5].

The function MeanOrMaxOverSC in the below formulas means that either a mean over all super channels shall be calculated. Or, as a worst case scenario, the max delay found in the available super channels shall be used.

5.1.1 CS Services

5.1.1.1 Downlink

TotDelayIP_CS_DL = [BUNDG1AVEDEL / 10] + [PingDelayAverage / 20] +

MeanOrMaxOverSC[FJBUFDELDL / FJBUFDLSCAN] milliseconds

The PM counter PingDelayAverage is a STN counter. The STS counters

FJBUFDELDL counts the accumulated delay in ms per SC for CS traffic

frames in the jitter buffer on the downlink, FJBUFDLSCAN counts the number

of accumulations and BUNDG1AVEDEL shows the average bundling delay in the LBG containing Speech.

The Transmission delay on the Abis Upper BSC STN interface is possible to measure by setting up a PingMeasurement in the SIU pointing out the BSC

PGW IP address. The resulting performance counter PingDelayAverage shows an average of the RTT of a ping packet sent from the BSC and returned from the PGW in the BSC. The one way delay can be estimated to RTT/2 if a symmetric delay is assumed.

The downlink CS jitter buffer delay is observed by the FJBUFDELDL and

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




5.1.1.2 Parameters

If the average bundling delay shows a long bundling time compared to the total CS DL delay, there is a possibility to decrease the bundling buffer size or the maximum bundling time (MPLSDL and MCLTDL) to reduce the latency. This will be on the cost of bandwidth but a possible lower packet loss rate.

If the downlink CS jitter buffer delay is high compared to the total CS DL delay, there may be a possibility to decrease the jitter buffer size, JBSDL, to a smaller value. For further info if a change is applicable and how to tune it, see the setting of JBSDL in 5.2.1.

5.1.1.3 Uplink

TotDelayIP_CS_UL = MeanOrMaxOverSC[FSCBUFDELUL/FSCBUFULSCAN]

+ MCLTUL + PingDelayAverage/20 +

MeanOrMaxOverSC[FJBUFDELUL/FJBUFULSCAN] milliseconds

PingDelayAverage is the STN counter. The STS counters FJBUFDELUL, counts the accumulated delay in ms per SC for CS traffic frames in the jitter

buffer on the uplink, FJBUFULSCAN counts the number of accumulations.

FSCBUFDELUL and FSCBUFULSCAN are the corresponding counters for the SC buffer. The parameter MCLTUL is the setting of the maximum bundle collecting time in uplink.

5.1.1.4 Parameters

If the uplink delay is perceived as long compared to the total CS UL delay, there is a possibility to reduce the bundling time by decreasing the Bundling Buffer Size and/or the Maximum Bundling Time (MPLSUL and MCLTUL). This will be on the cost of bandwidth and a possible lower packet loss rate.

If the downlink CS jitter buffer delay is high compared to the total CS UL delay, there may be a possibility to decrease the jitter buffer size, JBSUL, to a 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 PS Services

5.1.2.1 Downlink

TotDelayIP_PS_DL = [BUNDG3AVEDEL / 10] + [PingDelayAverage / 20] + JBPTA milliseconds

The PM counter PingDelayAverage is a STN counter. The STS counters

BUNDG3AVEDEL shows the average bundling delay in the LBG containing (E)GPRS. The parameter JBPTA shows the value of the P-GSL Jitter buffer.




5.1.2.2 Parameters

If the Bundling Delay counter, BUNDG3AVEDL shows a long bundling time compared to the total PS DL delay, there is a possibility to decrease the Bundling Buffer Size and/or the Maximum Bundling Time (MPLSDL and MCLTDL) to reduce the latency. This will be on the cost of bandwidth and a possible lower packet loss rate. If the downlink PS jitter buffer delay is high compared to the total PS DL delay, there may be a possibility to decrease the jitter buffer size, JBPTA, to a 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 setting of the maximum bundle collecting time in uplink.

The STS counters FSCBUFDELUL counts the accumulated delay in ms per SC

for CS traffic frames in the SC buffer on the uplink, FSCBUFULSCAN counts the number of accumulations.

5.1.2.4 Parameters

If the uplink delay is perceived as long compared to the total PS UL delay, there is a possibility to reduce the bundling time by decreasing the Bundling Buffer Size and/or the Maximum Bundling Time (MPLSUL and MCLTUL). This will be on the cost of bandwidth and a possible lower packet loss rate.

5.2 Delay Variation

5.2.1 CS Services

5.2.1.1 Counters

The total Delay variation, or jitter, is in some sense observable for CS in both up- and downlink, at least the jitter distribution for packets arriving too late.

The counters used are the jitter buffer counters in DL counted in the BTS and the jitter buffer counters in UL counted in the BSC/PGW. The delay variation is seen as the delay distribution in the histogram counters

[UL / DL][0025/ / / / 100]JITBUFDEL,




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.




Since it is hard to optimize the jitter buffer settings, it is suggested to start checking other buffer settings as for example the bundling buffers in the first place. A reduced time and size in the bundling buffer will reduce the delay variation so that it is possible to decrease the jitter buffer size in a corresponding degree.

5.2.2 PS Services

5.2.2.1 Counters

The PS service has a jitter buffer in the downlink, which shall make sure that there always is at least one packet ready to be sent out on the air interface. There are no counters that make the PS delay variation directly observable in Abis over IP and BSS. A jitter may be measured by external means by using intermediate IP probes and a corresponding measurement application.

Indirectly there is a possibility to check other Abis over IP counters, as the PS DL Delay measurements in 5.1.2.1 and packet loss DL counters in 5.4.1 to get a feeling for how well tuned the PS DL jitter buffer is.

5.2.2.2 Parameters

There are two out of three parameters that are to be set: JBPTA, PAL and PTA, see reference [1].

PAL to 1 there is a need to set the JBPTA value which shall cope for the round trip jitter correctly. It is highly recommended to use this feature.

The JBPTA value is used by a PTA adjustment algorithm for determining the average usage of a sending buffer in the TRXs. This buffer can take at a maximum 6 (RLC/MAC) blocks per time slot. The 6 blocks represent a 120 ms sending window. In the BSC and BTS there is an algorithm that tries to deliver frames to the BTS downlink buffer JBPTA ms before it shall be sent on the air interface. A reduced jitter leading to a decreased delay will fill the buffers faster, possibly leading to a buffer overflow and lost frames. On the other hand an increased jitter leading to an increased delay will fill the buffers more slowly, possibly leading to a buffer underrun and lost frames.

There are recommended values as well as guiding rules in reference [1] of how to tune the JBPTA value by checking the counters for lost packets. A decrease of JBPTA -and- -observation of the DLFramePktLoss counter. If the DLFramePktLoss counter shows a larger portion of lost packets after a change in JBPTA, this means there is a need to increase the value. Also care must be taken regarding the load when tuning the parameter, since high load will generate more jitter.




If using a good network with an expected small jitter, a value of 20 ms introducing a minor delay is appropriate. This setting will allow for a sudden delay increase of 20 ms before reaching a buffer underrun state or a delay decrease of 100 ms before reaching a buffer overflow state, and at the same time introducing a minimum delay in the jitter buffer.

If the Interfaces over satellite feature is used, see 7.6, expecting a large jitter, JBPTA should always be set to 60 ms, thus providing robustness for the largest possible variation in delay: ±60 ms.

To be noted is that non-recommended extreme JBPTA setting of 120 ms will imply:

Lost packets since there is no robustness against a sudden decrease

of delay. This unconditionally will lead to a buffer overflow and a lost packet

A jitter buffer delay of 120 ms

Robustness against a sudden increase of delay of 120 ms

And a non-recommended setting of JBPTA to 0 ms will have the opposite effect, leading to lost packets due to buffer underflow.

If the TotDelayIP_PS_DL counter shows that a large part of the total delay is due to the jitter buffer delay and at the same expecting a low jitter in the network, this is an indication of a possibility to decrease JBPTA. A reduction of the value must be done studying the DLFramePktLoss counter so that no increase in packet loss occurs. The jitter introduced by the bundling buffers as well as all other node internal and network generated jitter has to be taken into account. With recommended settings and a fair network the recommended 20 ms will be enough to cope for the jitter.

5.3 Bandwidth

5.3.1 Counters

ULABISipAVEthp = ( IPRECKBYTES * 8 ) / IPNUMSCAN

DLABISipAVEthp = ( IPSENTKBYTES * 8 ) / IPNUMSCAN

The Abis average throughput is calculated according to the above formula. This measure compared to the available bandwidth defined by a SLA will give a hint if there is enough bandwidth available for Abis over IP.

A temporary burst of packets might not fit into the available bandwidth. There are built-in overload prevention mechanisms like Abis Triggered HR Allocation and Full Rate AMR on 8 kbps Abis that shall prevent overload, see chapters 7.3 and 7.4.




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 / MBWULDLABISipAVEutil = DLABISipAVEthp / MBWDL

This fact makes the dimensioning of the two engineered bandwidth parameter an important task, since a too low setting of MBW[UL/DL] will make the overload prevention kick in earlier than necessary, degrading the speech quality in a too early stage.

If the counters OVERLOADREJCON in object type CLTCH and PREJABISCONG

in object type CELLGPRS3 are stepped, this indicates that there is ongoing Abis overload that prevents the system from setting up new TBFs (PREJABISCONG) or new CS connections.

There are also counters presenting the load distribution on the PGW STN link relative the engineered bandwidth in the

D[UL/DL][7075,7680,..,9600,00]STNLOAD

histogram counters. The load distribution gives some hint of how well dimensioned the Abis upper interface is compared to the engineered bandwidth.

5.3.2 Parameters

Available parameters for reducing the needed bandwidth are all parts of the DTX, packet Abis packing algorithm and overload prevention features. See chapters 7.1, 7.2, 7.3 and 7.4.

5.4 Packet Loss

5.4.1 Counters

ULFramePktLoss = 100 * LOSTULPACK / (TOTULPSSCFRBUF +

TOTFRULSCBUF) [%]

DLFramePktLoss = 100 * LOSTDLPACK / (TOTDLPSSCFRBUF +

TOTFRDLSCBUF ) [%]

The total super channel frame loss ratio per Super Channel for UL and DL are calculated as above. There are also loss ratios defined for CS and PS separately in reference [5].

There are also some counters on the IP level:




IPLOSTPACKUL in the BSC counting the number of Abis IP packets being lost on the IP link or received with checksum errors in the BSC, reported per TG. Note that an IP packet contains many bundled UL or DL super channel frames.

inAbisPacketsErrors and inAbisPacketsLost in the STN counting the number of DL IP packets received with checksum errors or being out of sequence or lost respectively.

If the UL or DL super channel frame loss is greater than 0.1 % and the number of discarded IP packets is increasing correspondently, this suggests that the transmission packet loss is larger than recommended for using Abis over IP.

It is not recommended to use an IP network having a larger packet loss than 0.1%.

There is an overload handling mechanism, which tries to reduce the impact of dropped packets on the Abis link on system and end-user performance. The main idea is to prioritize the different types of data and remove the packets that have the lowest priority. The trigger for the overload handling mechanism is amongst others the IP packet loss level, see reference [1].

The overload counters consists of some that are stepped during use of the overload handling mechanism, indicating how long overload reduction have been active, see reference [5]:

IPOVL[CS,PS]REG and IPOVLL[1/2]

Packets are discarded only during IPOVLL[1/2] overload handling.

The CS and PS discarded frames due to overload handling formulas:

CSdiscFrameOvlDL = 100 * CSDISCOVL / FRAMECOUNT [%]

PSdiscFrameOvlDL = 100 * PSDISCOVL / FRAMECOUNT [%]

where CS and PSDISCOVL is the sum of all SCs in the TG found in the SIU counter SC_FramesDownlink. It is only during the active phase of IPOVLL1 and L2 that packets are discarded due to overload handling.

5.4.2 Parameters

As in the case of overload prevention there can be situations where overload handling is triggered falsely due to the settings of MBW[UL/DL], see chapter 5.3. The overload handling mechanism in Abis over IP is designed for moderate to medium packet loss ratios. For very low packet loss transmission as well as for a high loss transmission the overload handling should be turned off, see recommendations in reference [13].




If Abis over IP is deployed on a transmission with a bandwidth that is high enough for any expected traffic expecting a very low packet loss ratio a magnitude under 0.1%, it is recommended to turn overload handling off to avoid any unnecessary falsely triggered performance degradation.

If the underlying IP network has a high packet loss ratio in the magnitude of 1% or above, it is recommended not to use the overload handling mechanisms.

above 5%, the IPOV parameter should be set to off to avoid falsely triggered overload handling.

Turning off overload handling is made by setting the IPOV to OFF and OVLTH to 1000, see e.g. [13].

If using overload protection, the tuning of OVLTH is important, since it is set as a factor of 0.1% of the expected peak packet loss ratio. A tuning procedure for OVLTH is given in reference [1], which basically consists of a statistical collection step of the packet loss ratio without overload protection, followed by a trial procedure where the OVLTH is set to a starting value and then iterated to a lower and lower value until either the recommended lowest value of 25 is reached, or the statistics show no falsely triggered overload protection procedures.

Overload prevention might be considered if the bandwidth is the limiting factor. See chapters 7.3 and 7.4.

If the loss is due to buffer overflows within BSS manageable buffers it may be possible to tune some configuration parameters to decrease the packet loss rate:

If there is a difference between CS and PS statistics, it could be suspected that some buffers are not properly tuned.

o The Bundling times for the LBG for CS may be decreased if there is a higher drop for CS than for PS and the other way around.

o The jitter buffer size JBPTA might be increased carefully up to maximum 60 ms, if the PS data has higher drop than CS and the other way around.

o Note that an increased buffer size will also will increase the delay.

If there is a different packet loss ratio for different Super Channels, it is likely that one SC is more overloaded than the other and that the dimensioning is wrong. It is suggested to re-distribute the TRXes used by each TG more evenly on the SC belonging to the Super Channel Group that is corresponding to the specific TG.




6 Hardware Supervision

6.1 BSC

There is Alarm supervision of the different parts of the BSC that influences Abis over IP. The PGW-RPs, of either PGWB or GARP-2 type, do issue alarms and events according to the descriptions in reference [6].

which makes the system more resilient to PGW-RP failures and tries to distribute an average part of the load on each available PGW-RP, see reference [6]. Within this feature there is some statistics available that could be monitored, e.g. a measure on the number of PGW CPUs where the load

PGWHLRPP. To be noted is that the feature automatically distributes the load based on algorithms and configurable thresholds.

6.2 BTS

Alarms and PM data are sent from the BTS and aggregated in the BSC.

If the Abis link is down the BTS cannot report anything about its state. A first measure would be to try to mend the link by checking the state and configuration of the intermediate nodes. If the Abis outage still appears, a connection on site is necessary to download the the state of the BTS and get it up and running again.

6.3 STN

When the STN supervision mechanism, based on heartbeats between the STN and OSS, is configured and triggered, see reference [7], there will be alarms triggered within the OSS if the STN goes out of service.

If the WAN interface of the STN is not working, the Abis upper link to the BSC and the IP link from STN to OSS will be down. In this case no Alarms or statistics will be available in OSS. However, if the STN is up and running with connectivity to the BSC and OSS, and a new configuration is downloaded resulting in a loss of connections to BSC and OSS, the STN will use a built-in rollback functionality that returns to the old working configuration after a certain time of connectivity trials.




7 Features

There are some features that are dependent to Packet Abis over IP and needs to be tuned in combination with Packet Abis over IP:

FAJ 122 287, Discontinuous Transmission (DTX) Downlink FAJ 122 256, Discontinuous Transmission (DTX) Uplink

FAJ 121 997, Abis Optimization

Only needed for releases earlier than G11B when using Packet Abis packing algorithm

FAJ 121 846, Abis Triggered HR Allocation

May use:

o FAJ 121 361, Dynamic FR/HR Adaptation

o FAJ 121 582, Dynamic Half Rate Allocation

FAJ 122 381, Adaptive Configuration of SDCCHs

FAJ 122 437, A-bis interface over satellite

FAJ 123 142, Abis Local Connectivity Satellite FAJ 123 159, Abis Local Connectivity - Terrestrial

7.1 DTX

FAJ 122 287, Discontinuous Transmission (DTX) Downlink FAJ 122 256, Discontinuous Transmission (DTX) Uplink

DTX together with the Packet Abis packing algorithm are the most important features in order to save bandwidth on Abis. The DTX features must be used in combination with the Packet Abis packing algorithm in order to save bandwidth.

The amount of bandwidth saved depends on the voice activity factor (which varies for different languages, cultures and nature of the call) but is usually around 50%.

Recommendation:

DTX UL and DL is always recommended to use since these features significantly reduces the Abis bandwidth. There is a need to enable the Packet Abis packing algorithm to make the bandwidth savings take place.

7.1.1 Parameters

DTXU = 1 and DTXD = ON is recommended. See reference [8].




7.2 Packet Abis packing algorithm

The Packet Abis packing algorithm is a feature to get substantial bandwidth savings on the Abis interface. Bandwidth savings are achieved by removal of redundant information and packing of frames in both uplink and downlink. The amount of savings is depending on the traffic mix and voice activity.

Recommendation:

The Packet Abis packing algorithm is a highly recommended bandwidth savings technique that should be used.

Note: Before the BSS release G11B the algorithm was only available together with the Abis Optimization feature.

7.2.1 Parameters

PACKALG = 1 is recommended, See reference [1].

7.3 Full Rate AMR on 8 kbps Abis

The Full Rate AMR on 8 kbps Abis feature allocates Full Rate AMR calls with codecs restricted to a maximum of 7.4 kbps in order to decrease the used bandwidth on Abis. The AMR codec is restricted to max AMR 7.4 kbps over Abis but uses AMR FR on the air interface.

This functionality is initiated at set up of an AMR FR call when the number of idle Abis resources has fallen below the threshold defined by the parameter SDAMRREDABISTHR specified per TG.

Note: Needs FAJ 121 055 Adaptive Multi Rate (AMR) and FAJ 121 358 AMR Half Rate. There is no need for the orderable feature FAJ 121 827, Full Rate AMR on 8 kbps Abis since it is coming with the Abis over IP baseline.

Recommendation:

It is recommended to use the Full Rate AMR on 8 kbps Abis feature to increase the system performance and improve the usage of the possibly scarce Abis bandwidth.

7.3.1 Parameters

The functionality is turned ON or OFF by the parameter DAMRCRABIS per cell see reference [1].




SDAMRREDABISTHR is the threshold where the initiation of FR AMR calls with max 7.4 kbps is started. A lower value will start the bandwidth savings technique earlier, maybe coping for a faster increase of needed saved bandwidth although possibly reducing the perceived speech quality. The settings recommended are found in [1].

7.4 Abis Triggered HR Allocation

FAJ 121 846, Abis Triggered HR Allocation

May also use:

FAJ 121 361, Dynamic FR/HR Adaptation FAJ 121 582, Dynamic Half Rate Allocation

There are features used for optimizing channel allocation algorithms. These features are also applicable and reused for a system which is Abis resource limited. Two principles are DHA and DYMA which work in different ways when the resources on Abis are scarce:

DYMA, Dynamic FR/HR Adaptation is used when trying to reduce the Abis resources needed for ongoing calls by downgrading the codecs from FR to HR, packing them and releasing the FR resources not needed anymore.

DHA, Dynamic Half Rate Allocation is used when resources on Abis are scarce and new calls are initiated. For all calls possible, instead of allocating FR, HR is used.

The feature Abis Triggered HR Allocation consists of the two parts: DHA triggered by Abis and DYMA triggered by Abis working as explained above. These functions may be triggered when there is high load on Abis when using Abis over IP. The triggers are set by the operator.

The DYMA part is triggered if the load on the packet Abis path for any of the super channels in the TG(s) serving a certain cell exceeds a percentage value, SDFRMAABISTHR, then connections using FR shall be moved to HR. There is also a mechanism to go back to FR allocations if the Abis load decreases under the threshold again.

The DHA part is triggered if the load on the packet Abis path for the TG(s) serving a certain cell exceeds a percentage value, SDHRAABISTHR, set per TG. If triggered, then AMR/HR and HR channels shall be preferred for new calls until the Abis load goes under the threshold again.

If using the two features Dynamic FR/HR Adaptation and FAJ 121 582 Dynamic Half Rate Allocation in conjunction with FAJ 121 846 Abis Triggered HR Allocation, there will be overload prevention triggered not only if Abis is a scarce resource, but also if the cell is experience load.




Recommendation:

It is recommended to use the channel optimization algorithms to increase the system performance and improve the usage of the possibly scarce Abis bandwidth. A lower value will start the bandwidth savings technique earlier, maybe coping for a faster increase of needed saved bandwidth although possibly reducing the perceived speech quality.

7.4.1 Parameters

The enabling of Abis Triggered HR Allocation is set in each cell by setting ATHABIS = On

The threshold for allocation of HR channels is set by the parameter SDHRAABISTHR per TG.

The threshold for FR to HR change triggered by lack of Abis bandwidth is set by the parameter SDFRMAABISTHR per TG.

The threshold for going back from HR to FR is triggered by the parameter SDHRMAABISTHR per TG.

The first triggered saving technique recommended is the Full Rate AMR on 8 kbps Abis, see chapter 7.3. The second counter measure is recommended to be DHA and the last triggered bandwidth saving technique should be DYMA. The settings recommended are found in [1].

For further reading abuot the Abis triggered DYMA and DHA features, see reference [9].

7.5 Adaptive Configuration of SDCCHs

This feature is used to optimize the traffic and signaling channel usage, especially by making the SDCCH dimensioning less critical by automatically adapting the number of SDCCHs in a cell to the demand for such channels.

Recommendation:

It is recommended to enable the adaptive configuration of logical channels to make sure there always are enough SDCCH channels to cater for delay and delay variations introduced in Abis over IP, which may temporarily increase the usage of SDCCHs.

In case Adaptive configuration of logical channels is not used the SDCCH utilization should be supervised.




7.5.1 Parameters

ACSTATE shows the activation state (ON/OFF) of the Adaptive Configuration of Logical Channels function in the cell. It is set in the BSC with the MML commands RLACI and RLACE on a cell level.

For further settings of parameter, see reference [4].

7.6 Abis interface over satellite

This feature makes sure that the system can handle long delays introduced by e.g. a satellite connection.

If using a high delay Abi

level, by adapting timers for CS and PS and modifying the Immediate Assignment procedure.

Recommendation:

When using an Abis satellite path or a long delay Abis transmission, it is highly recommended to use the Abis interface over satellite feature.

Note: For payload dimensioning of a packet Abis transmission running over a Satellite link, a dedicated integration project is required, as per standard Ericsson customer adaptation processes.

7.6.1 Parameters

The controlling parameter SIGDEL, which is set on a TG level, shall be changed from the default value NORMAL to LONG.

For further settings please refer to the User Description [10].

7.7 Abis Local Connectivity

Abis Local Connectivity provides the possibility to switch speech calls locally in the STN node. Local switching can be done if both legs of a call are handled by the same STN node and they use the same speech codec. When a call is locally switched there are no speech frames sent on Abis Upper although signaling, including measurement reports, are sent to and from the BSC as usual.

There are two features: Abis Local Connectivity - Satellite and Abis Local Connectivity - interface based on satellite or terrestrial transmission.

Since the application of this feature is very dependent on the actual business case, there is no general recommendation for using this feature or not.




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].




8 References

1. Packet Abis over IP, User Description; 326/1553-HSC 103 12

2. Packet Abis over TDM, User Description; 327/1553-HSC 103 12

3. Packet Abis Dimensioning Guideline, User Guide; 227/100 56-HSC 103 12

4. Adaptive Configuration of Logical Channels, User Description; 267/1553-HSC 103 12/15

5. Radio Network Statistics, User Description; 216/1553-HSC 103 12/18

6. PGW Load Distribution, User Description; 276/1553-HSC 103 12/16

7. SIU Network Integration, Operating Instruction; 1/1543-LZA 104 102/3

8. Discontinuous Transmission, User Description; 305/1553-HSC 103 12

9. Channel Allocation Optimization, User Description; 332/1553-HSC 103 12

10. Interfaces over Satellite, User Description; 266/1553-HSC 103 12/16

11. Abis Local Connectivity, User Description; 313/1553-HSC 103 12

12. Managing Abis over IP, User Guide; 1/1553-3/AOM 901 070

13. Important Guiding Rules when integrating Abis over IP, Recommendations; 1/100 56-230/FCG 102 55

14. BSS RADIO NETWORK KEY PERFORMANCE INDICATOR (KPI) GUIDELINE, Recommendations; 212/100 56-HSC 103 12

15. BSS G11B Network Impact Report; 1/109 48-HSC 103 12/18

16. BSS G10B Network Impact Report; 1/109 48-HSC 103 12/16




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




9 Appedix A Abis over IP feature growth within BSS releases from 08A to G11B

9.1 BSS G11B

9.1.1 Packet Abis Feature Replacements

The feature Abis Optimization (FAJ 121 997) and Abis over IP (FAJ 121 998) are replaced by the feature Packet Abis over TDM (FAJ 123 174) and Packet Abis over IP (FAJ 123 175) respectively.

The functional contents of Packet Abis over TDM correspond to Abis Optimization. Packet Abis over IP corresponds to Abis over IP with the addition that the packing algorithm used in Abis Optimization (controlled by parameter PACKALG) is available.

9.1.2 Improved Speech Path Delay for Packetized Speech

This feature improves the speech path delay for calls using A over IP (FAJ 123 147) in combination with Packet Abis over TDM (FAJ 123 174) or Packet Abis over IP (FAJ 123 175) which are transcoded outside the BSC or is not transcoded at all. This is achieved by changing from Group Switch to Ethernet as transport medium inside the BSC between the Packet Gateway (PGW) and the A-interface Gateway (AGW).

Furthermore, support for rate adaptation of Circuit Switched Data calls are introduced in the AGW and will be used when A over IP is activated together with Packet Abis over IP. Thus no TRA is required in this configuration to support Circuit Switched Data.

The capacity of the AGW is increased to 2000 simultaneous calls if A over IP is used in combination with Packet Abis over IP.

9.1.2.1 Characteristics

In a network where A-interface is used in combination with Packet Abis over IP the speech path delay is reduced with 20 ms in each direction.




9.2 BSS G10B

9.2.1 Abis Optimization and Abis over IP Load Handling Enhancements

The downlink PS scheduling mechanism on Abis Optimization and Abis over IP is enhanced to improve the Abis utilization at high load. At Abis overload detection on PS, instead of just preventing setups of new PS services and then (if this does not help) to escalate to shutting down the entire PS service, down scheduling of the PS traffic is applied.

By down-scheduling it is meant that PS data scheduling will be omitted to decrease the load downlink. The ratio of omitted PS data scheduling will gradually increase, if the overload scenario persist, until all PS data scheduling are omitted. Once the overload scenario is ceased the ratio of omitted PS data scheduling will gradually decrease until no PS data scheduling is omitted.


The GPRS/EDGE characteristics are improved according to the following:

GPRS/EDGE throughput can improve in certain cases, that is the amount down-scheduling is sufficient to avoid packet loss that would have resulted in even less throughput than the amount of down-scheduling results in.

GPRS/EDGE setups prevented due to Abis congestion will reduce due to the introduction of the new lowest level of Abis overload handling called down-scheduling.

The time to GPRS/EDGE service being available again after Abis congestion will decrease.

The Abis utilization at high load of GPRS/EDGE payload will increase.

9.2.2 Increased GPH Capacity for Abis Optimization and Abis over IP

Traffic between GPH and PGW is already today using Ethernet backplane communication instead of legacy Group Switch communication. Still, the implementation with its restrictions has been kept. This feature changes the internal implementation in the GPH which gives an increase in performance. The GPH HW need for Abis Optimization and Abis over IP will be reduced to equal or below the HW need when using Flexible Abis. It will be possible to define more E-GPRS channels per GPH if the load on the GPH allows it. In order to achieve this gain, allocation of PGW devices for CS calls will be performed dynamically at request instead of statically at configuration. This impacts O&M.





Allocation of the PGW devices for circuit switched calls will be performed dynamic at request instead of at configuration. This might impact times for call setup and handover slightly.

9.2.3 New Counters in Existing Object Types Object Type ABISIP

Function Counters for Abis IP

Counter Name Level Size Type Description

IPOVLCSREG TG 32 PC Indicates how long time the CS traffic reduction has been active for

Abis over IP. Measured in seconds. Stepping of this counter indicates

that as good as all PS data scheduling has been omitted. Stepping of this

counter also indicates a decreased level of new and existing CS calls.

IPOVLPSREG TG 32 PC Indicates how long time the PS traffic reduction has been active for

Abis over IP. Measured in seconds. Stepping of this counter indicates

that a number of PS data schedulings have been omitted.

Object Type SUPERCH2

Function Super Channel load and quality counters


SCOVLCSREG Super channel 32 PC Indicates how long time the CS traffic reduction has been active for

Abis Optimization. Measured in seconds. Stepping of this counter

indicates that as good as all PS data scheduling has been omitted.

Stepping of this counter also indicates a decreased level of new and

existing CS calls.

SCOVLPSREG Super channel 32 PC Indicates how long time the PS traffic reduction has been active for

Abis Optimization. Measured in seconds. Stepping of this counter

indicates that a number of PS data schedulings have been omitted.

9.2.4 Modified Counters Object Type ABISIP

Function Counters for Abis IP

Counter Name Level Size Type New Description

IPOVLL1 TG 16 PC Number of seconds when level 1 actions have been taken to solve

overload on Abis over IP. Level 1 actions reduces load on Abis

interface by removing PS frames from interface, uplink and downlink.

IPOVLL2 TG 16 PC Number of seconds when level 2 actions have been taken to solve

overload on Abis over IP. Level 2 actions reduces load on Abis

interface by removing both PS and CS frames from interface, uplink

and downlink.

9.3 BSS G10A

9.3.1 Abis Local Connectivity Enhancements

The Abis Local Connectivity (ALC) features, Abis Local Connectivity - Satellite (FAJ 123 142) and Abis Local Connectivity - Terrestrial (FAJ 123 159), have been enhanced with the following functionality in BSS G10A:

Improved coding matching

Support for locally switched calls using AMR

ALC supporting other vendors Core Network

License Handling




9.3.2 Dynamic Half Rate for AMR-WB

The feature Dynamic Half Rate for AMR-WB introduces a new load threshold indicating when to allocate HR or AMR HR for AMR WB capable terminals. This threshold will make it possible to differentiate between AMR-WB capable MSs and other MSs when a HR channel shall be allocated during high load. A new parameter indicates if the threshold is applicable only at call setup or both at call setup and handover.

9.3.2.1 Commands and Printouts

RLDHC: Radio Control Cell, Dynamic HR Allocation Data, ChangeRLDHP: Radio Control Cell, Dynamic HR Allocation Data, Print

The existing commands are changed to support the new parameter DTHAMRWB.

RXATC: Radio X-ceiver Administration, Abis Path Thresholds Data, Change

The existing command is changed to support new parameters DHRAABISTHRWB and SDHRAABISTHRWB.

9.4 BSS 09A

9.4.1 New Counters in Existing Object Types Object Type PGW

Function Counters for PGW RP CPU load


G2PGW0040LOAD BSC 32 PC

Number of scans where the PGW CPU load on GARP-2 was between 0% and

40%.



60%



80%



90%



100%

9.4.2 Modified Counters Object Type PGW

Function Counter for PGW RP CPU Load

Counter Name Level Size Type Changed behavior

PBPGW0040LOAD BSC 32 PC

Description modified compared to the design base. New description: Number of

scans where the PGW CPU load on PGWB was between 0% and 40%
















Object Type SUPERCH

Function Super Channel load and quality counters

Counter Name Level Size Type Changed behavior

THRULPACK SC 32 PC

Description modified compared to the design base. New description: Total

number of discarded CS and PS frames in the SC buffer, UL. This is the sum of

counters ULSCBUFTHR and ULPSSCBUFTHR.

9.5 BSS 08B

9.5.1 Adaptive Timers for Packet Abis

The feature Adaptive Timers for Packet Abis is an enhancement of the packet Abis features Abis Optimization (FAJ 121 997) and Abis over IP (FAJ 121 998). This feature makes the GPRS/EGPRS behavior more robust and removes the need for retuning the packet Abis transmission if the transmission latency varies.

A new regulation algorithm that adapts to varying Abis latency is introduced. The algorithm makes it possible to use Abis transmission with very high latency for example satellite transmission or transmission with varying latency.

With the new regulation algorithm the initial configuration of the network is much easier and the probability of obtaining a high and stable throughput increases. The network does not have to be retuned when the latency is changing when using the new algorithm. The input to the algorithm is the maximum expected jitter for the round trip latency BTS and BSC (JBPTA). The configuration is done on TG level.

9.5.2 New Lost Frame and Buffer Delay Measurements for Packet Abis

New Lost Frame and Buffer Delay Measurements for Packet Abis is afeature enhancement of the packet Abis features Abis Optimization (FAJ 121 997) and Abis over IP (FAJ 121 998). This feature enhancement improves the monitoring of existing resources on Packet Abis. The new statistics measures delay and discarded packets for the packet Abis system. This simplifies both the daily PM supervision and interpretation of packet Abis influence on main BSS Key Performance Indicators.

9.5.2.1 STS Counters

The new object type SCABISDEL with 10 new counters is added. The existing object type SUPERCH has received four new counters and the existing object type CLDTMPER has received one new counter. There are 9 changed counters in object type SUPERCH and ABISTG.




9.5.3 PGW on GARP-2

PGW on GARP-2 is a feature that enables the possibility to run the PGW application on the RP type GARP-2. One GARP-2 can handle double the amount of traffic compared to one PGWB.

9.5.4 BSC Parameters Parameter Feature Command Description User Description Comment

JBPTA Adaptive Timers for

Packet Abis

RXMOC

RXMOI

BTS jitter buffer depth for PAL=1 Abis over IP

9.5.5 New Counters in New Object Types Object Type SCABISDEL

Function Delay measurements per super channel for packet Abis


FJBUFDELDL SC 32 PC Accumulated jitter buffer delay on the DL

FJBUFDLSCAN SC 32 PC Number of accumulations for counter FJBUFDELDL

FJBUFDELUL SC 32 PC Accumulated jitter buffer delay on the UL

FJBUFULSCAN SC 32 PC Number of accumulations for counter FJBUFDELUL

FSCBUFDELDL SC 32 PC Accumulated super channel buffer delay, DL

FSCBUFDLSCAN SC 32 PC Number of accumulations for counter FSCBUFDELDL

FSCBUFDELUL SC 32 PC Accumulated super channel buffer delay, UL

FSCBUFULSCAN SC 32 PC Number of accumulations for counter FSCBUFDELUL

9.5.6 New Counters in Existing Object Types Object Type SUPERCH

Function Super Channel load and quality counters.


FCSLOSTUL SC 32 PC Number of lost and discarded CS frames on the UL during last recording period.

FPSLOSTUL SC 32 PC Number of lost and discarded PS frames on the UL during last recording period.

FCSLOSTDL SC 32 PC Number of lost and discarded CS frames on the DL during last recording period.

FPSLOSTDL SC 32 PC Number of lost and discarded PS frames on the DL during last recording period.

9.5.7 Modified Counters Object type Counter Correction Package

/Feature

Impact

SUPERCH TOTFRDLSCBUF New Lost Frame and Buffer Delay

Measurements for Packet

Abis

This counter now counts the total number of CS frames entering the super channel buffers downlink. Previously the counter did not

count discarded frames in the super channel buffer. This counter is

now also valid for Abis over IP. Previously it was only valid for

Abis Optimization.

SUPERCH TOTDLPSSCFRBUF New Lost Frame and

Buffer Delay


Abis

This counter now counts the total number of PS frames entering the

super channel buffers downlink. Previously the counter did not

count discarded frames in the super channel buffer. This counter is

now also valid for Abis over IP. Previously it was only valid for

Abis Optimization.

SUPERCH LOSTULPACK New Lost Frame and

Buffer Delay


Abis

This counter now also count the accumulated number of lost and

discarded CS+PS frames in the UL direction for Abis over IP.

Previously it was only valid for Abis Optimization.

SUPERCH LOSTDLPACK New Lost Frame and

Buffer Delay

This counter now also count the accumulated number of lost and

discarded CS+PS frames in the DL direction for Abis over IP.





Abis

Previously it was only valid for Abis Optimization.

ABISTG UL0025JITBUFDEL New Lost Frame and

Buffer Delay


Abis

This counter now also counts for Abis over IP. Previously it was

only valid for Abis Optimization.


Buffer Delay


Abis




Buffer Delay


Abis




Buffer Delay


Abis




Buffer Delay


Abis



PGW PBPGW0040LOAD PGW on GARP-2 Description modified compared to the design base. New

description: Number of scans where the PGW CPU load on PGWB

was between 0% and 40%













9.5.8 Changed Counters due to Correction Packages Object type Counter Correction Package Impact

SUPERCH TOTFRDLSCBUF,

TOTDLPSSCFRBUF

IP-A4 The counters TOTFRDLSCBUF and TOTDLPSSCFRBUF in

object type SUPERCH has been corrected to show a correct value

also in the case when more than 50 % of the frames are discarded.

SUPERCH LOSTULPACK IP-A7 The counter LOSTULPACK, which shows how many packets that

are lost on the Abis Interface, will not step as frequent as before

during high traffic load on Abis Opt super channel.

9.6 BSS 08A

9.6.1 STN

Below is a list of different STNs and their support of new features with STN impact. X indicated means support for stated feature.

STN Feature Support

BSS 08A Improvements SIU STN in RBS 2409

Abis Local Connectivity X X




GSM/WCDMA Transport sharing X

HDLC over IP X

IP over E1/T1 X

Load regulation improvements for

packet Abis

X X

Site LAN X

9.6.2 Abis Local Connectivity

Abis Local Connectivity is an optional feature that requires the STN node. Abis Local Connectivity makes it possible for operators to reduce Abis bandwidth requirements to sites where there is a fair amount of local traffic. The speech frames for calls where the A and B side are located within the same STN are switched in the STN and not sent to the BSC. All signaling will still go to the BSC and the MSC. Switching the speech in the STN node instead of in the core network saves Abis bandwidth and increases the speech quality as the speech path delay is reduced. This effect is very tangible when Abis is transported over satellite.

9.6.3 Load Regulation Improvements for Packet Abis

Load Regulation Improvements for Packet Abis is an enhancement to feature Abis over IP FAJ 121 998 and Abis Optimization FAJ 121 997.

The OVLTH (overload threshold) parameter has been moved from SCGR (Super Channel Group) to LBG (LAPD Bundling Group) and the behavior when OVLTH is exceeded has been slightly modified.

The BSC uses the parameter OVLTH to determine when to take steps at Abis congestion. It is configured from the BSC to the STN on all traffic flows for the TG. The STN starts reporting actual packet loss detected, to the BSC, when this threshold is exceeded. For a GSM/WCDMA Transport Sharing solution, where different Bundling Groups and DSCPs is recommended for different traffic types/flows/sessions, it is desirable to be able to configure and act on this threshold being exceeded at LBG level and not on one SCGR level value used for all sub-flows, as it would be without this change. This improvement applies to feature Abis over IP

The stopping of the PS traffic is improved by rejecting new UL TBFs in case of Abis overload. This improvement applies to feature Abis over IP and feature Abis Optimization.

9.6.3.1 Compatibility

The OVLTH threshold parameter has been moved from SCGR to LBG. During the upgrade to 08A, if more than one TG is using the same LBG the OVLTH of the LBG will be set to the lowest OVLTH of the TGs. It is assumed that the upgraded BSC does not have any overload.




9.6.4 STN system improvements

9.6.4.1 Increased number of time slots on Abis Lower on SIU/STN

It is now possible to use 31 time slots on Abis Lower (between SIU and BTS) for E1.

9.6.5 Parameter Changes

9.6.5.1 BSC Parameters Parameter Feature Command Description User Description Comment

CODECREST Abis Local

Connectivity

RLCLC Speech version (SPV) and

channel rate restriction

Abis Local

Connectivity

Function

OVLTH Load Regulation

Improvements for

Packet Abis

RRBGC/I Transmission overload

threshold

Abis over IP Parameter added

OVLTH Load Regulation

Improvements for

Packet Abis

RRSGC/I Transmission overload

threshold

Abis over IP Parameter

removed

9.6.6 Changed Counters due to Correction Packages Object Type Counter IP-A/CP-A package Description

ABISIP IPSENTKBYTES

IPRECKBYTES

IPDLSENTPACK

IPULRECPACK

IPLOSTPACKUL

IP-A2 Due to a truncating fault when merging most

significant bits to least insignificant bits, STS

counters in object type ABISIP have sometimes

shown wrong values.

SUPERCH TOTFRDLSCBUF,

TOTDLPSSCFRBUF

IP-A10 The counters has been corrected to show a correct

value also in the case when more than 50% of the

frames are discarded.

SUPERCH LOSTULPACK IP-A13 The counter is showing how many packets that are

lost on the Abis Interface, and will decrease during

high traffic load on Abis Opt super channel.

abis over ip tuning gl esontemplate-libre

Documents

important bss kpis

bss performance13

version recommendations

delay variation

technical background

continued progress

written permission

performance indicators