Packet - Abis Congestion Control

Congestion control in Packet Abis
Nokia Siemens Networks
RN20107EN14GLN0
Congestion control mechanism

Purpose and scope
Congestion control in Packet Abis: reason for introduction
in Packet Abis no traffic is transmitted using dedicated resources:
the available bandwidth is shared dynamically among various traffic types
the occupied transport bandwidth depends on load and traffic profile observed in
a BTS area and varies over time
a mechanism is needed to manage system behaviour when shortage of the transport
bandwidth reserved for the given BTS site is observed:
this may happen when the actual (offered) traffic starts to deviate remarkably from
the one being basis for bandwidth estimation done during network planning
such periods are expected to be short-lasting (if the traffic profile and load are defined
properly for network planning) but possible due to clear relation between incoming
traffic and required transport bandwidth
without any management of congestion situations the queues related to the overloaded
links grow lawless what intensifies congestion severity (delay and delay variation may
become unacceptable) and makes restoring of normal services more complex and time
consuming
therefore the congestion control mechanism is introduced in Packet Abis
the mechanism provides means to counteract congestion situations in both physical
realizations of Packet Abis (i.e. with TDM-based and PSN-based transport)
2
RN20107EN14GLN0

Implementation
Congestion control in Packet Abis: architecture
Packet Abis provides set of mechanisms which control the system in the event of congestion
Packet Abis congestion control
congestion
detection and reaction
BTS Tx queues
handling
when enabled
when enabled
BU
PL
monitoring detection
discarding
obsolete packets
when thresholds exceeded
start/stop related
congestion reaction procedures
Packet Abis congestion control mechanism can be enabled or disabled per BCF basis by
means of packetAbisCongestionControl parameter
when congestion control is enabled then monitoring of the following indicators is started to
detect congestion state:
backhaul utilization (BU) monitoring for link congestion
packet loss (PL) detection for transport network congestion
RN20107EN14GLN0

Implementation
Congestion control in Packet Abis: congestion detection algorithms (BU)
The backhaul utilization monitoring (BU) allows to observe Packet Abis bandwidth
consumption:
BU is defined as percentage of bandwidth reserved per BTS site
In PSN transport:
Abis bandwidth available for BTS site

in the PSN is defined explicitly by setting
committed information rate (CIR)
BSC
ETH (100M/1G)
Eth
CIR kbit/s
Packet Switched
Network
RN20107EN14GLN0
Eth

Implementation
Congestion control in Packet Abis: congestion detection algorithms (PL)
The packet loss detection (PL) allows to detect overload in the transport network:
transport network congestion is recognized when packet loss rates of different QoS
classes start to differ remarkably
in the event of congestion low QoS class flows suffer discarding by intermediate nodes
in Packet Abis congestion control PL is defined as a difference between PS and CS
packets loss rates
this means that mapping of CS traffic to a higher QoS class than PS traffic is a
prerequisite to have PL detection running in congestion control mechanism
otherwise PL values are ignored by congestion control as they might be meaningless
Realization of PL detection in Packet Abis:

CS packets loss rate and PS packets loss rate are measured separately and then
compared to each other
if the difference between PS and CS loss rates is greater than configurable
threshold then PL detection mechanism reports congestion in the transport network
and starts relevant reaction procedures
PL detection is mainly relevant for PSN-based transport, in case of TDM-based transport

useful
mainly
local switching
to control congestion between hub BTS and BSC
Nokia
Siemens for
Networks
RN20107EN14GLN0

Implementation
Congestion control in Packet Abis: configuration and handling
Congestion control mechanism is supervised by the following parameters:
configurable thresholds defining congestion severity for backhaul utilization (BU1 /
BU2) and packet loss (PL1 / PL2): depending on congestion severity appropriate
reaction procedure (R1 or R2) is invoked
filtering timers managing switch on/off of the reaction procedures (TON / TOFF)
Mechanism behaviour shown below for BU case (PL behaviour is analogous):
BU[%]
defaults:
BU2 = 90% => BU2_Hy = 85%
BU2
BU1 = 75% => BU1_Hy = 70%
BU2_Hy
BTON = 4 sec
BTOFF = 10 sec
PL2 = 28 (10%) => PL2_Hy = 24 (6%)
BU1
PL1 = 14 (0.5%) => PL1_Hy = 10 (0.1%) BU1_Hy
PLTON = 10 sec
PLTOFF = 100 sec
R2 stopped
R1 re-started
severe congestion
detected (R2)
congestion
detected (R1)
t [sec]
TON
TON
TOFF
TOFF
hysteresis thresholds are hardcoded

BU: 5% below, PL: 5 units below (cf. Slide99 for the range of the relevant parameters)
congestion state can be modified only after expiry of TON/TOFF

6
RN20107EN14GLN0
exceeding threshold
starts filtering timer and not reaction procedure
congestion
removed

Implementation
Congestion control in Packet Abis: reaction procedures
two sets of procedures (R1 and R2) are started up based on congestion severity
mechanism behaviour shown below for BU case (PL behaviour is analogous):
R2
R1
TOFF
TON
1_Hy BU1
TOFF
TON
2_Hy BU2
R1 reaction procedure involves:

decrease of AMR codec rate: AMR codec is downgraded directly to the lowest codec
supported by the affected BTS site
decrease PS scheduler rate by 25%: PCU omits frame insertion in every 4th scheduling
cycle towards the affected sites, this will effect in reduction of backhaul throughput rate
R2 reaction procedure involves:
rejection of newly incoming calls and PS territories upgrades: BSC does not start any
new calls towards the affected BTS sites and rejects PS upgrades requested therein
decrease PS scheduler rate by 75%: PCU omits frame insertion in 3 out of 4 scheduling
cycles
towards the
affected BTS sites
7
Nokia
Siemens Networks
RN20107EN14GLN0
Congestion
control
reactions
bu1AbisThroughputThreshold
OR pl1ThresholdPacketLoss
is exceeded
bu2AbisThroughputThreshold
OR pl2ThresholdPacketLoss
is exceeded
1-The BSC reduces the TBF

scheduling rate by 25%
2- AMR codec is downgraded to
the lowest codec
1-The BSC reduces the TBF

scheduling rate by 75%
2- any new calls towards the
affected BTS sites are allocated
RN20107EN14GLN0

Implementation
Congestion control in Packet Abis: Tx queues handling
Behavior of BTS transmission queues is configurable in addition to congestion control
mechanisms:
BTS removes from transmission queues of its scheduler all packets which are kept
there longer than configurable period of time called drop period
drop period is defined for each traffic type (plane) separately
it is also possible to prevent given traffic type from dropping regardless on load
these additional procedures are helpful:
when link is overloaded in spite of running congestion control mechanisms
when link is overloaded, congestion control is enabled but filtering timer has not yet
expired
when link is overloaded and congestion control is not enabled (but then it can help with
short-lasting peak periods)
BSC transmission queues behavior is managed by means of QoS definition
packets are served according to QoS mapping
dropping principles within QoS class: FIFO
RN20107EN14GLN0
Packet Abis Congestion Control (Recap)

BTS detects
interface congestion
by link utilization monitoring (UL/DL)

network congestion
by packet loss monitoring
BTS and BSC react to congestion:
10
Two threshold can be configured

Reduction of GPRS/EDGE throughput (BSC)
AMR HR & AMR FR codec rate reductions (BTS)
PS and CS call limitation (BSC)
(depend on congestion situation)
RN20107EN14GLN0
Packet Abis
Configuration management
11
RN20107EN14GLN0
Go to Table of content
Packet Abis connection type (1/9)
Connection type and topology

Parameter
Description
object: BCF
range: 03:
0 = Legacy Abis
1 = Packet Abis over TDM
2 = Packet Abis over Ethernet
default: 0 unit: MML command: EFC, EFM, EFO
MML abbreviated name: AICT
Abis interface connection type (abisInterfaceConnectionType), with this parameter it is

possible to define realization of Abis interface: it is possible to choose between legacy
(Dynamic Abis) and Packet Abis. For Packet Abis also physical realization can be indicated.
Please note that the setting of this parameter determines next mutually exclusive
configuration steps:
- for Packet Abis over TDM (AICT=1): HDLC link(s) must be created reflecting the existing
PCM configuration and available backhaul bandwidth (see HDLC parameters section),
- for Packet Abis over Ethernet (AICT=2): available backhaul bandwidth is expressed in
terms of Committed Information Rate (CIR) therefore traffic shaping and Ethernet links
capabilities must be configured (see Packet Abis over PSN section).
Besides, for Abis connection types different than legacy Abis, ETP object must exist in the
BSC.
object: BCF
range: 0, 1:
0 = satellite Abis is not used
1 = satellite Abis is used
default: 0 unit: MML command: EFO
MML abbreviated name: PASU
Packet Abis over satellite in use (paSatelliteUse), the parameter indicates whether
satellite connection is used by Packet Abis or not.
Usage of satellite connection is reflected in settings of retransmission timeouts which control
SCTP procedures related to TRXSIG and OMUSIG traffic. This is read-only parameter:
system sets the parameter depending on setting of SCTP association for RTO.init for Mplane (OMUSIG).
object: BCF
range: 04
default: 0 unit: MML command: EFM, EFO
MML abbreviated name: TRS5
Packet transport E1/T1 usage (packetTrsE1T1Usage), the parameter indicates whether

transport features aiming at protecting installed base (UltraSite and BTSplus) are enabled. In
particular, the parameter is related to one of the available options which foresees cross
connection of co-sited legacy BTS products through FlexiEDGE BTS using Dynamic Abis
(between legacy BTS and FlexiBTS, and CESoPSN between FlexiBTS and BSC) and
additionally allows to indicate how many PCM lines are used to connect UltraSite/BTSplus
with FlexiEDGE BTS site.
12
RN20107EN14GLN0
BSC HW (Exchange Terminal for Packet transport, ETP)

Parameter
Description
object: ETP
range: 05 step: 1
default: - unit: MML command: MML abbreviated name: -
ETP object ID (etpId), this parameter allows to define identity of particular ETP units
plugged in to the BSC (regardless on physical realization of Packet Abis) and represents
the relevant HW.
object: ETP
range: 015 step: 1
default: - unit: MML command: ESK, ESH, ESL, EFC,
EFM, EFO
MML abbreviated name: ETPGID
ETP group ID (etpGroupId), this parameter allows to identify ETP group.

ETP group is needed for redundancy purposes when N+N scheme is in use and therefore
the concept in only applicable for ETPT and ETPE (i.e. ETP modules responsible for AoIP
have different redundancy scheme). To define ETP group which indicates the pair of active
and spare modules (terminating the same Packet Abis type, i.e. either Packet Abis over
TDM or Packet Abis over Ethernet) ETP type is needed in addition to ETP group ID (see
below, ETPT parameter).
object: ETP
range: 1, 2:
1 = ETP-T (ETP for TDM transport)
2 = ETP-E (ETP for Ethernet transport)
step: - default: - unit: MML command: ESK, ESH
MML abbreviated name: ETPT
ETP type (etpType), this parameter allows to define ETP type of ETP unit to be used for
Packet Abis.
ETP type and ETP group ID (see above, ETPGID parameter) are needed to define ETP
group.
object: BCF
range: 0255 step: 1
default: - unit: MML command: EFO
MML abbreviated name: EBID
ETP BCF ID (etpBcfId), this parameter identifies BCF in ETP and PCU and is used
internally for PCU-ETP communication only.
It is created by the system automatically whenever Packet Abis is enabled in a new BCF.
This is read-only parameter.
13
RN20107EN14GLN0
Packet Abis over TDM: HDLC parameters (1/2)

Parameter
Description
object: BCF
range: 0255 step: 1
default: - unit: MML command: EFO
MML abbreviated name: MLPPP
ML-PPP bundle ID (mlPppBundleId), this parameter allows to identify ML-PPP bundle

related to the BCF. The parameter is read-only and its value is set by the system.
Multilink point-to-point protocol (MLPPP) aggregates several physical links (i.e. PCM TSL
available for the BCF) into a single logical pipe". To be more precise, MLPPP bundles
multiple link-layer channels into a single network-layer channel (pipe).
The parameter is mandatory for Packet Abis over TDM (AICT=1) where it allows to bundle
HDLC links representing all TDM lines connecting given BCF to the BSC. Thus the
bandwidth available in the BCF on Packet Abis depends on the number of TSLs assigned to
the HDLC links (listed by BHIDL, see below) which the MLPPP bundle is composed of.
The parameter is not relevant for Packet Abis over Ethernet (AICT=2) where traffic shaping
mechanisms are required to define bandwidth available for the BCF and to ensure traffic
management in Packet Switched network.
object: BCF
range: 13000 step: 1
default: - unit: MML command: EFC, EFM, EFO
MML abbreviated name: BHIDL
BCF HDLC ID list (bcfHdlcIdList), this parameter allows to define the list of HDLC links
related to the BCF.
Bandwidth contributions of each HDLC link listed by the parameter are summed up so they
constitute logical pipe (represented by ML-PPP bundle parameter) which determines
transmission capacity available on Packet Abis for given BTS site (BCF). Up to 8 entries
(HDLC links representing the entire PCM line or smaller bandwidth) may be defined for BCF
and listed by the parameter.
1st E1 (e.g. PCMID=101), TSL1-20
TDM
TDM
2nd E1 (e.g. PCMID=102), TSL1-31
BCF: MLPPP=1,
BHIDL=20, 21
14
RN20107EN14GLN0
MLPPP bundle =
= (20+31)*64 kbit/s
BSC
HNBR=20, HPCM=101
HTSL=1, HBAND=20
HNBR=21, HPCM=102
HTSL=1, HBAND=31
TSL1
TSL20
TSL1
TSL31
Packet Abis over TDM: HDLC parameters (2/2)

Parameter
Description
object: HDLC
default: - unit: MML command: ESX, ESF, ESS, ESY
MML abbreviated name: HNBR
HDLC link ID (hdlcLinkId), this parameter allows to identify HDLC link in the related MLPPP bundle. HDLC link represents the TDM line connecting the BCF with the BSC (or with
another BCF, in case of chained BTSs) and its ID is unique per BSC. A BCF can have up to
8 HDLC links included in BCF HDLC ID list (cf. BHIDL, previous slide) as each TDM line
configured in the BCF for Abis transport purposes must be reflected in HDLC configuration.
object: HDLC
range: string of 015 characters
default: - unit: MML command: ESX, ESF, ESS, ESY
MML abbreviated name: HNAME
HDLC link name (hdlcLinkName), this is optional parameter which allows to define a
name of the HDLC link in addition to, but not instead of, its ID to e.g. easily distinguish
between several HDLC links related to the same BCF (ML-PPP bundle).
object: HDLC
default: - unit: MML command: ESX, ESL
MML abbreviated name: HPCM
HDLC PCM ID (hdlcPcmId), this parameter allows to indicate the identity of the TDM line
represented by the HDLC link.
object: HDLC
range: 130 (ETSI) or 124 (ANSI)
step: 1 default: - unit: MML command: ESX, ESL
MML abbreviated name: HTSL
HDLC start TSL (hdlcStartTsl), this parameter allows to define the number of PCM TSL
where given HDLC link begins.
object: HDLC
range: 231 (ETSI) or 224 (ANSI)
step: 1 default: - unit: PCM TSL
MML command: ESX, ESF, ESL
MML abbreviated name: HBAND
15
HDLC bandwidth (hdlcBandwidth), this parameter allows to define the bandwidth which is
available for Packet Abis traffic in the given HDLC link. The bandwidth is expressed in terms
of PCM TSLs assigned to given HDLC link. A single HDLC link consists of continuous block
of 64kbit/s PCM TSLs, more than one HDLC link can be configured on the same TDM line
(fractional PCM configurations are supported). The minimum configurable HDLC bandwidth
is of 128 kbit/s (i.e. 2 subsequent PCM TSLs) and the maximum one is limited by TDM line
capacity in ETSI/ANSI environment. Please note that BCF bandwidth can be split to several
HDLC links (e.g. when BCF has more than one E1/T1 available for Abis interface).
RN20107EN14GLN0
Packet Abis over TDM: Header compression

Parameter
Description
object: BCF
range: 0 (OFF), 1 (ON)
MML abbreviated name: HECOP
Header compression for ML-PPP (headerCompression), this parameter is used to

enable (HECOP=1) or disable (HECOP=0) header compression for ML-PPP header.
Even though header compression is optional procedure it is recommended to enable it as it
contributes to bandwidth savings what is very important for Packet Abis over TDM.
For details about header compression please refer to Slide33.
Header compression is not possible with Packet Abis over Ethernet therefore the parameter
is only relevant for Packet Abis over TDM (AICT=1).
object: BCF
MML abbreviated name: HECOU
Header compression for UDP/IP (headerCompressionForUdpIp), this parameter is used

to enable (HECOU=1) or disable (HECOU=0) header compression for UDP and IP headers.
Even though header compression is optional procedure it is recommended to enable it as it
contributes to bandwidth savings what is very important for Packet Abis over TDM.
For details about header compression please refer to Slide33.
Header compression is not possible with Packet Abis over Ethernet therefore the parameter
is only relevant for Packet Abis over TDM (AICT=1).
16
RN20107EN14GLN0
Packet Abis over PSN

Parameter
object: BCF
range: 0, 1:
0 = NO SHAPING
1 = SHAPING COMMITTED
MML abbreviated name: ULTS
=> cf. Slide228 for Element Manager
17
Description
Uplink traffic shaping (uplinkTrafficShaping), this parameter is used to enable (ULTS=1)
or disable (ULTS=0) uplink traffic shaping for the BCF operating with Packet Abis over
Ethernet. The parameter is not relevant for Packet Abis over TDM.
Traffic shaping provides means necessary to control traffic transmitted by Packet Switched
networks (PSN) including traffic classification concepts, queue disciplines, congestion
management and quality of service. Enabling and cooperation of these mechanisms allow
to maximize performance within available bandwidth: packets related to particular traffic
types can be distinguished and are treated accordingly to the priorities they got. Without
traffic shaping each and every packet is treated in an identical manner regardless on the
traffic type and network load: they all are buffered in the same queue and there are no
means to indicate their importance, e.g. in the presence of congestion discarding of the
packets would be done randomly-like (i.e. based on queuing discipline used in the
transmission buffer).
For Packet Abis it means that enabling of traffic shaping is a prerequisite to configure set of
mechanisms which aim at managing traffic in a PSN (i.e. separate parameters to control
QoS mappings and scheduling as well as congestion management). The interactions
between QoS mechanisms and congestion management are fully configurable to gain the
best out of traffic shaping activities.
The parameter is mandatory for Packet Abis over Ethernet (AICT=2). When traffic shaping
is enabled in a BCF then Abis bandwidth available in the BCF is defined explicitly by
committed information rate (CIR) value which is reflected in ULCIR parameter.
Note: ULCIR (see next slide) is mandatory for the BCF where traffic shaping enabled
(ULTS=1) as traffic shaping is done at CIR level.
RN20107EN14GLN0

Parameter
object: BCF
range: 100250000 step: 100
default: - unit: kbps
MML command: EFM, EFO
MML abbreviated name: ULCIR
18
Description
Uplink committed information rate (ulCommittedInformationRate), this parameter is used
to define committed information rate (CIR) value for traffic shaping in the BCF.
Committed Information Rate (CIR) is the average bandwidth guaranteed by a PSN owner (e.g.
ISP) to work under normal conditions, i.e. the available bandwidth should be never below the
committed value. Normally, CIR is a part of SLA where apart from bandwidth availability also
acceptable level of transport impairments (delay, delay variations, packet loss rate) are
subjects to agreement.
Furthermore, bursty nature of the traffic leads to short-lasting periods when required
bandwidth is above CIR. This is also normally subject to agreement via SLA and such
bandwidth demands are reflected in definition of Excess Information Rate (EIR). Usually EIR
handling is done in one of the following ways (but in principle also other policies are possible):
- either EIR is only provided in low network load conditions (i.e. when required bandwidth is
available),
- or EIR is always provided but transport impairments are not guaranteed (i.e. delay, delay
variation and packet loss rate can exceed the levels agreed for CIR traffic).
CIR value depends on traffic profile and load in the BCF and must be evaluated for each BCF
separately by means of dimensioning. Please refer to section Impact on dimensioning for
explanations how to estimate the bandwidth required per BCF. EIR value is not needed in
database as it is optional parameter mainly related to SLA rather than to BSC database. Do
not mix up CIR and EIR while defining bandwidth required by the BCF.
Note that for Packet Abis over TDM the concept of CIR is not applicable. Cf. ML-PPP bundle
ID parameter which is relevant then.
Note that in RG20 traffic shaping is only supported in UL. In consequence, only UL CIR is to
be set for traffic shaping purposes. However, DL CIR value is also required in RG20 DB
because it is used by congestion control mechanism for DL bandwidth definition in case of
Packet Abis over PSN. Please refer to section congestion control for further details.
RN20107EN14GLN0

Parameter
object: BCF
range: 065535 step: default: 1522 unit: octet
MML abbreviated name: ULCBS
19
Description
Uplink committed burst size (ulCommittedBurstSize), this parameter is used to define
committed burst size value for traffic shaping in the BCF. Burst size is understood as the
amount of octets being scheduled for transmission in given scheduling cycle (all scheduled
packets, including payload and header bits, contribute to individual packet burst).
For shaping of bursty traffic which is present in Packet Abis, the average limit (allowing for
bursts of data to be sent) rather than a hard and unbreakable (i.e. constant) one on data
rate must be met. For that purpose a token bucket algorithms with configurable CBS are in
use since they allow a certain amount of burstiness while imposing a limit on the average
data transmission rate (defined by CIR). Committed burst size (CBS) denotes the maximum
size available for a burst of packets sent at the given link to keep its information rate in
conformity with the relevant CIR. For the token bucket overall principles refer to backup
slides.
For planning of CBS similar parameters should be involved like those for CIR (i.e. CS/PS
load, signalling profile as well as codec distribution and feature configuration e.g. CS
multiplexing). The easiest way to estimate CBS is to express the chosen CIR in terms of
octets per frame that is: CIR[kbit/s] x 1024 x 8 / 50. This simple approach may however lead
to understimation of CBS (as averaging of burst size is done over 50 cycles scheduled in 1
sec period) what should be avoided (e.g. by chosing 10-15% greater CBS than that related
directly to CIR).
RN20107EN14GLN0

Parameter
Description
class: ETHPRT
default: 1500 unit: octets
(BTS parameter)
cf. Slide227 for Element Manager
Ethernet maximum transfer unit size (ethernetMtuSize), this parameter is used to define
the maximum payload size that can be carried by Ethernet frame.
The higher MTU the better transport efficiency because each packet carries more user data
while protocol overheads remain fixed. However, large packets can occupy a slow or heavy
loaded link for some time, causing greater delays to the following packets.
class: ETHPRT
default: 1 unit: (BTS parameter)
cf. Slide226 for Element Manager
Ethernet auto-negotiation (ethernetAutoNegEnabled, this parameter is used to define

whether Ethernet auto-negotiation functionality is enabled or not.
Ethernet auto-negotiation is a procedure by which two connected devices choose common
transmission parameters such as speed (also other parameters like duplex mode, port type,
master-slave relation, etc can be agreed). In this process, the connected devices first share
their capabilities for these negotiated parameters and then choose the fastest transmission
mode they both support.
Note: In Packet Abis auto-negotiation is always enabled in BSC. At BTS side autonegotiation is optional and shall be enabled/disabled by configuration. Auto-negotiation is
managed only from BTS Element Manager.
20
RN20107EN14GLN0
Congestion control (1/8)
Congestion control activation

Parameter
Description
object: BCF
range: 0, 1:
0 = DISABLE
1 = ENABLE
MML abbreviated name: PACC
Packet Abis congestion control (packetAbisCongestionControl), this parameter allows

to enable (PACC=1) or disable (PACC=0) congestion control mechanism including both Abis
backhaul monitoring as well as Abis packet loss detection.
When Packet Abis congestion control is enabled (PACC=1) then severity thresholds and
filtering timers must be additionally configured (please refer to the related parameters on
Slide97 Slide101). Besides, in case of Packet Abis over Ethernet, definition of ULCIR and
DLCIR is mandatory (cf. Slide96 for further details).
When Packet Abis congestion control is disabled (PACC=0) then severity thresholds and
filtering timers are meaningless. In such case discarding of obsolete packets is the only
countermeasure in the presence of congestion. Therefore drop periods (cf. next slide) must
be cautiously defined to ensure BTS Tx queues handling according to expectations.
Note that drop periods are meaningful regardless on whether congestion control is enabled
or not. Even if congestion control is enabled prioritization of packets to be discarded can be
helpful to smoothly overcome congestion situation.
Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanisms
as it can help to better understand the meaning of and interdependencies between all
relevant parameters.
21
RN20107EN14GLN0
Drop periods
Parameter
Description
object: BSC
range: 0100 step: 1
default: 25 unit: msec
MML command: EEY, EEO
MML abbreviated name: CSPDP
CS packet drop period (csPacketDropPeriod), this parameter is used to define drop

period for CS U-plane packets.
Drop period denotes the period of time after which the queued packet is deemed obsolete
and becomes a candidate to drop from the queue to relax the link load in the event of
congestion. All packets related to a given plane which are kept in TX queues longer than
their drop period are subject to removal to counteract a congestion. Therefore drop periods
can be defined for each plane separately to better prioritize.
Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanisms.
object: BSC
range: 0100 step: 1
MML abbreviated name: PSPDP
PS packet drop period (psPacketDropPeriod), this parameter is used to define drop

period for PS U-plane packets.
object: BSC
MML abbreviated name: CPLPDP
C-plane packet drop period (cPlanePacketDropPeriod), this parameter is used to define

drop period for C-plane packets.
object: BSC
MML abbreviated name: MPLPDP
M-plane packet drop period (mPlanePacketDropPeriod), this parameter is used to

define drop period for M-plane packets.
22
RN20107EN14GLN0
Backhaul Utilization (1/3): DL bandwidth definition for PSN

Parameter
object: BCF
range: 100250000 step: 100
default: - unit: kbps
MML abbreviated name: DLCIR
=> Slide229 for Element Manager
23
Description
Downlink Committed Information Rate (dlCommittedInformationRate), this parameter
is used to define DL committed information rate (CIR) value for congestion control
purposes.
Congestion control mechanism requires bandwidth definition for both TDM-based and PSNbased transport in both directions:
- for Packet Abis over TDM, the number of capacity of HDLC links assigned to an ML-PPP
bundle determine the bandwidth available for given BTS site,
- for Packet Abis over PSN, the bandwidth per BTS site is defined explicitly by means of
CIR values: in UL congestion control mechanism re-uses the value related to traffic
shaping (cf. ULCIR parameter on Slide84), in DL where traffic shaping is not supported in
RG20
a dedicated value is needed and therefore DLCIR is additionally introduced.
Note that in RG20 DLCIR has nothing to do with traffic shaping (e.g. does not need to be a
part of SLA) and is only used by the system in the context of congestion control mechanism.
Also DLCIR value depends on traffic profile and load in the BCF and must be evaluated for
each BCF separately by means of dimensioning. Please refer to section Impact on
dimensioning for explanations how to estimate the bandwidth required per BCF.
RN20107EN14GLN0
Backhaul Utilization (2/3): severity thresholds

Parameter
object: BCF
range:
20100 (Packet Abis over TDM) 20
150 (Packet Abis over Ethernet)
step: 1 default: 75 unit: %
MML abbreviated name: BU1
object: BCF
range:
20100 (Packet Abis over TDM) 20
150 (Packet Abis over Ethernet)
step: 1 default: 90 unit: %
MML abbreviated name: BU2
24
Description
BU1 Abis throughput threshold (bu1AbisThroughputThreshold), this parameter is used to
define a first (lower) threshold triggering congestion reaction procedure based on backhaul
utilization (BU) monitoring.
When backhaul utilization related to either an ML-PPP pipe (for Packet Abis over TDM) or
ULCIR/DLCIR (for Packet Abis over PSN) exceeds the percentage defined by BU1 then timer
BTON starts (cf. see next slide). If backhaul utilization remains greater than the threshold for
the whole duration of BTON then R1 reaction procedures are invoked, otherwise the timer is
reset and no congestion reaction is invoked.
R1 reaction procedures are removed when backhaul utilization falls 5% below BU1 and is kept
within that range for a time longer than BTOFF (cf. see next slide). Refer to Slide64 Slide70
for overview about Packet Abis congestion control mechanisms.
NOTE: Range of the threshold going beyond 100% applicable for PSN transport allows to
cope with bursty nature of traffic which in combination with CIR/CBS concept may lead to
short-lasting periods when CIR is slightly exceeded. Besides, the system does not prevent
from enabling CIR with disabled shaping what may lead transmitted traffic to easily go out of
control.
BU2 Abis throughput threshold (bu2AbisThroughputThreshold), this parameter is used to
define a second (upper) threshold triggering congestion reaction procedure based on backhaul
utilization (BU) monitoring.
When backhaul utilization related to either an ML-PPP pipe (for Packet Abis over TDM) or
ULCIR/DLCIR (for Packet Abis over PSN) exceeds the percentage defined by BU2 then timer
BTON starts. If backhaul utilization remains greater than the threshold for the whole duration
of BTON then R2 reaction procedures are invoked, otherwise the timer is reset and no
adjustment of congestion reaction procedure occurs.
R2 reaction procedures are removed (changed to R1) when backhaul utilization falls 5% below
BU2 and is kept within that range for a time longer than BTOFF. Refer to Slide64 Slide70 for
overview about Packet Abis congestion control mechanisms.
RN20107EN14GLN0
Note that BU2 must be greater than BU1.
Backhaul Utilization (3/3): filtering timers

Parameter
Description
object: BSC
range: 1300 step: 1
default: 4 unit: sec
MML abbreviated name: BTON
Backhaul Timer Duration Start Reaction (bhTimerDurStartReact), this timer defines how
much time backhaul congestion must persist to declare detection of the related congestion
level (lower or upper) and to start the appropriate reaction procedures.
The timer starts when a congestion severity threshold (BU1 or BU2) is exceeded. If
backhaul utilization remains greater than the related threshold BUx for the whole duration
time of BTON then the related (R1 or R2) reaction procedures are invoked. Otherwise (i.e.
when backhaul utilization moves back even for a while below BUx before BTON expiry),
BTON is stopped and the related reaction procedure is not invoked.
The value of the timer is valid both for UL and for DL direction.
object: BSC
range: 1600 step: 1
MML abbreviated name: BTOFF
Backhaul Timer Duration Stop Reaction (bhTimerDurStopReact), this timer defines how
much time backhaul congestion must not be active to declare cancellation of the related
congestion level and to stop the appropriate reaction procedures.
The timer starts when backhaul utilization falls below hysteresis threshold associated with
congestion severity threshold (BU1 or BU2), i.e. 5% below given severity threshold. If
backhaul utilization remains lower than the related hysteresis threshold BUx_Hy for the
whole duration time of BTOFF then the related (R1 or R2) reaction procedures are stopped.
However, any rise of backhaul utilization above BUx_Hy before BTOFF expiry, causes reset
of BTOFF and lack of relaxation of ongoing reaction procedures.
Note that clearance of congestion level does not necessarily mean that reaction procedures
are completely stopped: clearance of congestion level 2 means that R2 procedure is just
replaced with R1 and only clearance of congestion level 1 actually means that reaction
procedures are cancelled. The value of the timer is valid both for UL and for DL direction.
Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanisms
25
RN20107EN14GLN0
Packet Loss (1/3): severity thresholds

Parameter
object: BCF
range: 132 step: 1
MML abbreviated name: PL1
26
Description
Packet loss on DL Abis PL1 threshold
(pl1ThresholdPacketLoss), this parameter is used to define a first
(lower) threshold triggering congestion reaction procedure based
on packet loss (PL) detection.
The threshold is compared with the difference between PS and CS
loss rates which are measured separately in advance. Loss rate is
defined as a ratio between the lost frames and the expected (i.e.
lost + received) ones and expressed as percentage. Therefore
parameter values are also eventually mapped to the percentage
(see table on the right).
When difference between PS and CS loss rates exceeds the
percentage defined by PL1 then timer PLTON starts (cf. see next
but one slide). If difference between PS and CS loss rates remains
greater than the threshold for the whole duration of PLTON then R1
reaction procedures are invoked, otherwise the timer is reset and
no congestion reaction is invoked.
R1 reaction procedures are removed when difference between PS
and CS loss rates become represented by the value mapped 5
levels below PL1 and is kept within that range for a time longer
than PLTOFF (cf. see next but one slide). Hardcoding of PL
hysteresis offset leads to the following rules:
- if PL1 > 5: PL1_Hy = PL1 5 (e.g. PL1_Hy = 9 for PL1 = 14)
- if PL1 5: PL1_Hy are predefined as follows
- PL1 = 1 => PL1_Hy = 5x10exp(-5) = 0.00005 = 0.005%
- PL1 = 2 => PL1_Hy = 6x10exp(-5) = 0.00006 = 0.006%
- PL1 = 3 => PL1_Hy = 7x10exp(-5) = 0.00007 = 0.007%
- PL1 = 4 => PL1_Hy = 8x10exp(-5) = 0.00008 = 0.008%
- PL1 = 5 => PL1_Hy = 9x10exp(-5) = 0.00009 = 0.009%
Note that monitoring of lost frames is only implemented for DL
direction in RG20. Refer to Slide64 Slide70 for overview about
Packet Abis congestion control mechanisms.
RN20107EN14GLN0
value
symbolic value
1x10exp(-4) = 0.0001 = 0.01%
2x10exp(-4) = 0.0002 = 0.02%
3x10exp(-4) = 0.0003 = 0.03%
4x10exp(-4) = 0.0004 = 0.04%
5x10exp(-4) = 0.0005 = 0.05%
6x10exp(-4) = 0.0006 = 0.06%
7x10exp(-4) = 0.0007 = 0.07%
8x10exp(-4) = 0.0008 = 0.08%
9x10exp(-4) = 0.0009 = 0.09%
10
1x10exp(-3) = 0.001 = 0.1%
11
2x10exp(-3) = 0.002 = 0.2%
12
3x10exp(-3) = 0.003 = 0.3%
13
4x10exp(-3) = 0.004 = 0.4%
14
5x10exp(-3) = 0.005 = 0.5%
15
6x10exp(-3) = 0.006 = 0.6%
16
7x10exp(-3) = 0.007 = 0.7%
17
8x10exp(-3) = 0.008 = 0.8%
18
9x10exp(-3) = 0.009 = 0.9%
19
1x10exp(-2) = 0.01 = 1%
20
2x10exp(-2) = 0.02 = 2%
21
3x10exp(-2) = 0.03 = 3%
22
4x10exp(-2) = 0.04 = 4%
23
5x10exp(-2) = 0.05 = 5%
24
6x10exp(-2) = 0.06 = 6%
25
7x10exp(-2) = 0.07 = 7%
26
8x10exp(-2) = 0.08 = 8%
27
9x10exp(-2) = 0.09 = 9%
28
1x10exp(-1) = 0.1 = 10%
29
2x10exp(-1) = 0.2 = 20%
30
3x10exp(-1) = 0.3 = 30%
Packet Loss (2/3): severity thresholds

Parameter
Description
object: BCF
range: 132 step: 1
MML abbreviated name: PL2
Packet loss on DL Abis PL2 threshold (pl2ThresholdPacketLoss), this parameter is

used to define a second (upper) threshold triggering congestion reaction procedure based
on packet loss (PL) detection.
Please refer to the previous slide for additional explanations about what is the threshold
compared with and what values is the parameters range mapped to.
When difference between PS and CS loss rates exceeds the percentage defined by PL2
then timer PLTON starts (cf. see next slide). If difference between PS and CS loss rates
remains greater than the threshold for the whole duration of PLTON then R2 reaction
procedures are invoked, otherwise the timer is reset and no adjustment of congestion
reaction procedure occurs.
R2 reaction procedures are removed (changed to R1) when difference between PS and CS
loss rates become represented by the value mapped 5 levels below PL2 and is kept within
that range for a time longer than PLTOFF (cf. see next slide). Hardcoding of PL hysteresis
offset leads to the following rules:
- if PL2 > 5: PL2_Hy = PL2 5 (e.g. PL2_Hy = 23 for PL2 = 28)
- if PL2 5: PL2_Hy are predefined as follows
- PL2 = 1 => PL2_Hy = 5x10exp(-5) = 0.00005 = 0.005%
- PL2 = 2 => PL2_Hy = 6x10exp(-5) = 0.00006 = 0.006%
- PL2 = 3 => PL2_Hy = 7x10exp(-5) = 0.00007 = 0.007%
- PL2 = 4 => PL2_Hy = 8x10exp(-5) = 0.00008 = 0.008%
- PL2 = 5 => PL2_Hy = 9x10exp(-5) = 0.00009 = 0.009%
Note that monitoring of lost frames is only implemented for DL direction in RG20.
27
RN20107EN14GLN0
Packet Loss (3/3): filtering timers

Parameter
Description
object: BSC
range: 1300 step: 1
MML abbreviated name: PLTON
Packet Loss Timer Duration Start Reaction (packetLossTimerDurStartReact), this timer

defines how much time backhaul congestion must persist to declare detection of the related
congestion level (lower or upper) and to start the appropriate reaction procedures.
The timer starts when a congestion severity threshold (PL1 or PL2) is exceeded. If difference
between PS and CS loss rates remains greater than the related threshold PLx for the whole
duration time of PLTON then the related (R1 or R2) reaction procedures are invoked.
Otherwise (i.e. when difference between PS and CS loss rates moves back even for a while
below PLx before PLTON expiry), PLTON is stopped and the related reaction procedure is not
invoked.
The value of the timer is valid only for DL direction (monitoring of lost frames in UL is not
implemented in RG20). Refer to Slide64 Slide70 for overview about Packet Abis congestion
control mechanisms.
object: BSC
MML abbreviated name: PLTOFF
Packet Loss Timer Duration Stop Reaction (packetLossTimerDurStopReact), this timer

defines how much time backhaul congestion must not be active to declare cancellation of the
related congestion level and to stop the appropriate reaction procedures.
The timer starts when difference between PS and CS loss rates falls below hysteresis
threshold associated with congestion severity threshold (PL1 or PL2), i.e. 5 levels below given
threshold. If difference between PS and CS loss rates remains lower than the related
hysteresis threshold PLx_Hy for the whole duration time of PLTOFF then the related (R1 or
R2) reaction procedures are stopped. However, any rise of difference between PS and CS
loss rates above PLx_Hy before PLTOFF expiry, causes reset of PLTOFF and lack of
relaxation of ongoing reaction procedures.
Note that clearance of congestion level does not necessarily mean that reaction procedures
are completely stopped: clearance of congestion level 2 means that R2 procedure is just
replaced with R1 and only clearance of congestion level 1 actually means that reaction
procedures are cancelled. The value of the timer is valid only for DL direction. Refer to
Slide64 Slide70 for overview about Packet Abis congestion control mechanism.
28
RN20107EN14GLN0

Packet - Abis Congestion Control

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Packet - Abis Congestion Control

Enviado por

Direitos autorais:

Formatos disponíveis

Congestion control in Packet Abis

Nokia Siemens Networks

Congestion control mechanism

Nokia Siemens Networks

Congestion control mechanism

when thresholds exceeded

Nokia Siemens Networks

Congestion control mechanism

Abis bandwidth available for BTS site

Nokia Siemens Networks

Congestion control mechanism

Realization of PL detection in Packet Abis:

PL detection is mainly relevant for PSN-based transport, in case of TDM-based transport

Congestion control mechanism

hysteresis thresholds are hardcoded

congestion state can be modified only after expiry of TON/TOFF

Nokia Siemens Networks

Congestion control mechanism

R1 reaction procedure involves:

1-The BSC reduces the TBF

1-The BSC reduces the TBF

Nokia Siemens Networks

Congestion control mechanism

Nokia Siemens Networks