Packet Abis - Internal Workshop

For internal use only!!!
Packet Abis
For internal use only

1
Nokia Siemens Networks
Packet Abis / Network Engineering / March 2010
Content
Key content
Introduction
Feature details
Dimensioning aspects
PM counters
Configuration management
2
Introduction:
Packet Abis overview
SW/HW requirements

3
Go to Table of content
Introduction
GERAN transport overview
TTDD
MM
cy ce
a
g rfa
e
L te
In
Dynamic
Abis
Abis over IP
(CESoPSN)
Packet Abis
over TDM
Packet Abis
over
Ethernet

4
IP
Introduction
-
TDM
Abis
TDM
TDM
BSC
TDM
Legacy Abis adequate for handling of voice

and basic data in TDM environment:
fixed allocation of bandwidth
dedicated channels
for voice (TCH)
for signalling (TRXSIG)
for management (OMUSIG)
and a pool for PS data (EDAP)
less flexibility to react on data peaks

5
leased E1/T1 lines (e.g. p2p)

meshed network (e.g.
MWR)
Introduction
One
Traffic channel
TDM line / Ethernet
Packet Abis
Packet Abis is a completely new transport concept:

TDM framing removed, no empty packets are sent (idle, silence)
the whole interface capacity is combined to
a single bit-pipe where all traffic types share common bandwidth => no dedicated
bandwidth reserved
efficient overhead reduction mechanisms
...the same concept for TDM (through MLPPP) and Ethernet transport

6
Introduction
Packet Abis means introduction of a new transport concept:
Abis frames conveying traffic and signaling information between BTS and BSC are
subject to packetization process prior to sending them to the transmission path
as a result of packetization the incoming TRAU/PCU/LAPD frames are converted to
new (Packet Abis specific) formats which are encapsulated and form IP packets
eventually transmitted over Abis
these principles are valid regardless of physical media used in transport network; in
RG20 there are 2 possible realizations of transport network for Packet Abis:
Packet Abis over TDM
Packet Abis over PSN (Ethernet)
Packetization brings in a number of effects which contribute to bandwidth savings

achievable with Packet Abis compared to legacy Abis:
removal of unneeded bits (e.g. header information of TRAU/PCU frames) or even the
entire frames (e.g. idle frames)
silence suppression
statistical multiplexing due to unbalanced sectors load and reuse of common bandwidth
by different types of traffic (trunking gain)
efficient usage of bandwidth which is allocated according to the actual needs (i.e. no
bandwidth
is wasted
due to granularity,
nothan
empty
packets are
The savings
from packetization
more
compensate
fortransmitted)
the bandwidth
7
Nokia
Siemens Networks
Packet Abis / Network
Engineering / March
2010
consumption
due to transport
of protocol
headers
introduced by Packet Abis
Introduction
Packet Abis basic scenarios
Packet Abis over TDM (Abis over IP over TDM)
TDM
Abis*
p-RTP/UDP/IP
ML-PPP/HDLC
TDM
TDM
BSC
SDH
ETP
Packet Abis over PSN (Abis over IP over Ethernet)
Eth

8
Abis*
p-RTP/UDP/IP
Ethernet
PSN
BSC
Eth
ETP
Introduction
Packet Abis and PWE (CESoPSN)
key differentiator: Packet Abis consumes much less bandwidth than PWE does
CESoPSN is intermediate step between TDM-based transport and PSN-based one
CESoPSN allows to replace (already before RG20) TDM backhaul with PSN one while Packet
Abis simplifies such configuration and optimizes bandwidth usage to the far extent
besides, CESoPSN can be used for legacy BTS (where Packet Abis cannot be implemented)
to protect the installed HW base and, at the same time, to ensure seamless availability of IP
transport
Both features aim at encapsulation of TDM payload into Ethernet/IP

the difference lies in the level on which packetization is done
PWE: packetization on TDM frame level (125 s)
lack of awareness about content of the frame which is impossible to recognize

all bits (1 octet per emulated TSL every 125 s) are transmitted as their meaning is unidentified
no optimization can be done for emulated TSL (each and every bit must be and is transmitted)
in consequence, constant bandwidth is used regardless on traffic load
Packet Abis: packetization on TRAU/PCU frame level (20 ms = 160 TDM frames)
content-aware packetization
amount of informative bits in TRAU/PCU frame depends on voice/data codec used on radio
idle and silent frames can be recognized: trunking gain and DTX contribute to bandwidth
savings (as constant bit rate does not need to be maintained)
optimization can be done (only effective data is transmitted, i.e. payload bits and data needed

9
Introduction
Synchronization
Method
Basic application
new (RG20) HW needed

at BTS site (*)
Bandwidth consumption for

default settings (**)
E1/T1
none
none (TSL0 is used)
ToP (IEEE1588v2)
Packet Abis over PSN
FIYB/FIQB
~ 14.8 kbps
ACR (CESoPSN)
none (FIYA/FIQA-supported)
~ 212 kbps
SyncEth
FIYB/FIQB
none (dedicated Eth link is used)

10
Dependency tables
BSS
BSC
DX200
BTS
Talk
Family
BTS
Metro
Site
BTS
Ultra
Site
BTS
Flexi
EDGE
BTS
Flexi
Multiradio
BTS
BTS
plus
NetAct
SGSN
RG20
S15
Y
(EX4.0)
Y
(EX4.1)
OSS5.2
MP1
MSC
MS
BSC/BTS/TC/SGSN
HW/FW
License
ASW/BSW
Key control
ASW
Y feature support
N lack of support
- no dependency

11
Introduction
SW requirements
SW requirements
Packet Abis is delivered within RG20 system program, the state of related functionality can be
checked with:
Packet Abis over Ethernet
ZW7I:FEA,FULL:FEA=1533;
Packet Abis over satellite (BSS21438)
Packet Abis security (BSS21444)
Packet Abis Delay Measurement (BSS30395) ZW7I:FEA,FULL:FEA=1555;
Packet Abis sync (SyncEth, BSS30450)
Packet Abis sync (ToP, BSS21439)
Packet Abis congestion reaction (BSS21445)
Besides, the BSC which is supposed to terminate Packet Abis (apart from certain HW
requirements: Exchange Terminals, CPU memory, LAN connectivity) requires:
L3 connectivity for FlexiBSC product family* (BSS21323; license key FEA=1234)
Moreover, utilization of Packet Abis requires a balancing of the signalling load in the BSC and
therefore it is necessary to employ feature Precise Paging (BSS21335). Furthermore, the
Precise Paging also provides a positive effect for the end user experience during network busy
periods
12
(*) L3 level IP connectivity requires OSI over TCP/IP feature (BSS30340, FEA=1242) to be used for NetAct interface
Introduction
HW requirements
HW requirements
BTS requirements:
Packet Abis is supported by FlexiEDGE BTS (ESMA) and FlexiMultiradio BTS(ESMB/C)
ESMA supports Packet Abis with RG20 and ESMB/C with RG20EP1
FlexiBTS transport sub-modules in RG20:

FIEA
FIYA
8x E1 asymmetric
75 ohm
FIPA
FIYB/FIQB successors of FIYA/FIQA
4x E1 asymmetric, PWE
75 ohm, 2x FE 1xGE
ESMA
System Module
8xE1/T1symmetrical
120/100 ohm
Abis implementation
Dynamic Abis
PWE Abis
Packet
Abis
over TDM
For
internal
use only
13
FIFA
2x FlexBus coaxial
FIQA
4x E1/T1 symmetrical, PWE
120/100 ohm, 2x FE 1xGE
FIYB *
4x E1 asymmetric, PWE
75, 2x FE, 1x FE/GE
FIQB *
4x E1/T1 symmetrical, PWE

120/100, 2x FE 1xFE/GE
(*) FIYB / FIQB:
new transport sub-modules,
introduced in RG10 EP3.1

MP5...
...with the same features as

FIYA/FIQA (Dynamic Abis and
PWE)
RG20 provides support of

Packet Abis and extended sync
methods
(i.e. ToP and SyncEth)
go to backupSlide for FIYB/FIQB

connectivity
enhancements
in
Ref. S. Krafft,
GSM/EDGE Transport
Version 0.01, March 2009
RG20EP2
FIPA/FIEA
8x E1/T1
FIFA
2x FB (16 E1)
FIYA/FIQA
2 FE, SFP, 4x E1/T1
FIYB/FIQB
2x FE, 1xSFP, 4x E1/T1
OK
OK
OK
OK RG10 EP3.1 MP5
OK BSS13
OK RG10 EP3.1 MP5
OK RG20
OK RG20
OK RG20
OK RG20
OK RG20
OK RG20
-
Introduction
HW requirements
HW requirements
BSC requirements:
Packet Abis is supported by BSC3i 1000/2000 and FlexiBSC
a new Exchange Terminal called Exchange Terminal for Packet transport (ETP) is
required to be plugged in BSC to support Packet Abis
ETP is fully integrated with BSC and can freely co-exists with the existing Exchange
Terminals ET16/ETS2/ETIP
Packet Abis and Legacy Abis (Dynamic Abis, CESoPSN) can run on the same BSC
at the same time (therefore co-existence of ETP and the remaining Exchange
Terminals is possible)
PCU requirements:
Packet Abis is supported by PCU2-D and PCU2-E
a single PCU (*) only supports either Packet Abis or Legacy Abis; Packet Abis PCUs
(*) ...regardless of how many logical PCUs there are in the physical board
(**) If, in the
given track, there
are PCUs
in the same mode (Legacy Abis or Packet Abis)
and Legacy Abis PCUs must not be mixed in the same
BCSU
track
(**)
in every BCSU then Asymmetrical PCU configuration (BSS21226) is not needed.
Otherwise, i.e. in case of mixture of slots with PCUs and empty ones within a given track,
TCSM requirements:
Asymmetrical PCU configuration is required.
Packet Abis has no direct impact on TCSM
TR3E/A/T (TCSM3i) can be used in RG20 regardless of Abis implementation
even TCSM2 does not need to be upgraded when native IP transport terminates in
BSC (i.e. with TDM/PWE-based Ater and A interfaces)
14
Ater interface is either TDM-based or PWE-based (CESoPSN) in RG20
Introduction
ETP is a new
plug-in unit for BSC
Exchange Terminal for Packet transport (ETP)

New BSC HW: ETP
Physical implementation at BSC side:
Packet Abis requires a new Exchange Terminal called ETP
an ETP acts as either ETPT or ETPE functional unit
ETPT: Exchange Terminal for Packet Abis over TDM
ETPE: Exchange Terminal for Packet Abis over PSN (Ethernet)
during start-up the ETP reads-off its environment
(TDM or Ethernet) and based on that loads the correct protocol stack
ETP does not terminate E1/T1 lines (only Ethernet can be connected directly to ETP)
ETS2 is mandatory (in addition to ETP) for Packet Abis over TDM
in such case a new version (4A or newer) of ETS2 is needed
E1/T1 flows that carry Packet Abis are multiplexed into STM1/OC3 interface which
is supervised by the ETS2 module associated with ETP
Note: a new Exchange Terminal is also required to terminate AoIP
Exchange Terminal for AoIP is referred to as ETP-A
an ETP-A can be located either in BSC (ETPA) or in TCSM (ETPC) depending on
AoIP scenario
ETP (Packet Abis terminal) and ETP-A (AoIP terminal) are not exchangeable
15
Engineering / March 2010
AoIP is out of scopePacket
of Abis
the/ Network
presentation
Introduction
New BSC HW: ETP
Overall characteristics of ETP and its role in BSC:
terminates and adapts U-/C-/M- plane Abis packets; adaptation activities include e.g.:
forming packets with proper format (handling of related protocol stacks) and
sequence including multiplexing messages and header compression
de-jittering, silence deletion
relays all traffic types to the proper BSC FUs (see figure below)
supports synchronization techniques, i.e. HW support for SynchE master
ToP
master
EEP
ETPT
ETPSIGm
ETPA
EU
PEPd
ETPE
PEPe
ETPSIGm: M-plane interface between ETP and BCSU
BCSU
ETPC
(if AoIP with TCSM)
ETPSIGc
ETP
AoIP
TC in MGW
BCSU
ETPSIGc: C-plane interface between ETP and BCSU

PEP: PS U-plane interface between ETP and PCU
PCU2D GSWB
EEP: CS U-plane interface between ETP-T/E and ETP-A (i.e. TC in MGW)
PCU2E
EU: CS U-plane path
BSC
Ref. RS TEAM, Exchange Terminal

for Packet Transport, Requirement spec v 1.0.1
16
Introduction
New BSC HW: ETP
Summary on required BSC HW (Packet Abis/AoIP, PWE):
ETIP
Abis (CESoPSN)
1+1 x GE, PWE

(optical short haul or
copper SFP module)
Ater/A (CESoPSN)
ETS2 **
ETP *
2 x STM1/OC3
(optical long haul)
1+1 x GE
copper SFP module)
ETP-A *
1+1 x GE
copper SFP module)
AoIP *
* TC in MGW
* available in RG20
** version 4A (or newer)
Ref. S. Krafft, GSM/EDGE Transport
Version 0.01, March 2009

17

(***) More info about BSC LAN topology: [BSC Site Solution Scenarios and Requirements], cf. References
Introduction
GERAN scenarios with Packet Abis in RG20
Network scenario : all IP GERAN transport (RG20EP1)
N
SIGTRA
TDM
BTS
MSC
Server
TDM ETPT
ETH
PSN
ETH
codec X (TC in MGW)

A over IP
ETH
PSN
ETH ETPE ETPA ETH

TDM
BTS
BSC
PSN
ETH
MGW
(*)
Legacy Abis
TDM
BTS
Abis and A interfaces are migrated to native IP

Ater interface can be realized using either TDM or CESoPSN (i.e. all IP transport possible)
For A over IP (AoIP) two distinct scenarios are possible:
TC in BSS: related ETP-A (ETPC) is installed in TCSM, original radio CS codecs are converted in
TCSM to G.711 (64 kbps/TCH regardless on codec), no specific requirements concerning Abis
realization, Ater can be realized using TDM or CESoPSN (all IP), if the latter Packet Abis is
recommended to minimize the amount of TDM<->IP conversions and reduce transport delay
TC in MGW: related ETP-A (ETPA) is installed in BSC, original radio CS codecs are transmitted over
A interface, optimum solution from bandwidth consumption and delay perspective, Packet Abis is prefor this realization of AoIP (to be removed in RG20EP2 => tentative information, feature
For internal userequisite
only
18
Abis / Network Engineering / March 2010
candidate, cf. BSS101407),Packet
Ater/TCSM
is not present in GERAN
Feature details:
Operability
Header Compression
CS Multiplexing
Silent Suppression
QOS
IP Addressing

19
Realization
Introduction to Abis transport
Introduction: PCM basics, TDM frame, TRAU frame (2/2)
TRAU frames
speech is transmitted in TRAU frames
TRAU frame is a standardized structure consisting of 160 consecutive TDM frames
TRAU frame lasts 20 ms and its length depends on used codec
FR: 320 bits is transmitted by TRAU frame (320 bit / 20 ms = 16 kbit/s)
HR: 160 bits is transmitted by TRAU frame (160 bit / 20 ms = 8 kbit/s)
header (variable size, few bytes e.g. less than 5):
- sync pattern (SPF) indicates the frame boundary in the channel
- control bits (C-bits) identify the frame content (CS, PS,)
- time alignment bits (TA) trim phase differences between channels
header
payload (informative bits)
dummy bits
payload (size is variable and depends on codec):

- the max size is 244 bits for FR and 148 bits for HR
- the max payload size corresponds to codec with the highest source
bit rates (i.e. 12.2 kbit/s and 7.4 kbit/s for FR and HR, respectively)
total length: 320 bits for FR / 160 bits for HR
dummy bits (variable size):

- fill up frame to preserve constant bit rate (2 Mbit/s for E1)
- their amount depends on header length and payload size
TRAU frame structure determines the way how CS calls are mapped on Abis:

20
each Abis sub-channel

Packet
Abis / 16
Network
Engineering
/ March
2010
(i.e.
kbit/s)
has
enough
capacity to carry either 1 FR call or 2 HR
TRAU frame, channel coding, TDMA frame

TRAU frame
transmitted: on Abis (in a sub-channel, i.e. 16 kbit/s)
total length: 320 bits (FR) including:
- block of 260 bits of speech signal (max payload size: 244 bits)
- the remaining bits form header (SPF, C-bit, TA) and eventually
- dummy bits are inserted to keep constant length of frame (regardless of codec)
duration: 20 ms, composed of 160 consecutive samples of PCM signal:
- sampling frequency of 8 kHz
- encoding resolution is 8 bit/channel
TRAU frame i.e. 320 bits per 20 ms (16 kbit/s)

header
payload (informative bits)
dummy bits
block of 260 bits of speech
Channel coding
260 bits block divided into:
- class I: 182 bits incl. class Ia (50 bits) and class Ib (132 bits)
- class II: 78 bits
first step: block coding for error detection in class Ia
second step: convolutional coding for error correction
50 bits
132 bits
78 bits
tail bits
(0000)
block
coding
parity bits
TB
3
payload
57 bits
SF TS SF
1 26 1
payload
57 bits
53 bits
TB GP
3 8.25
132 bits
normal burst, i.e. 148 bits in 577s

convolutional
coding
378 bits
78 bits
block of 456 bits to be transmitted by 4 TDMA frames

(i.e. 114 bits / TDMA frame)
0 1 234 5 6 7 0 1 234 5 6 7 0 1 234 5 6 7 0 1 234 5 6 7
TDMA frame n TDMA frame n+1

TDMA frame n+3
TDMA frame n+2
4.615 ms

21
TDMA frame
transmitted: on radio interface, composed of 8 RTSL on the same frequency,
sequence of periodically transmitted RTSLs sets up physical channel (e.g. TCH/F)
payload: each burst transmits 114 gross (i.e. channel coded and error-protected) bits
TDMA vs. TRAU frames: 4 consecutive TDM frames contribute to a single TRAU frame
so 4 x 114 = 456 information bits are outcome of channel coding of a TRAU frame
gross bit rate in radio interface:
50 (TRAU) frames/sec * 456 bit/frame = 22.8 kbit/sec (FR)
Implementation of Packet Abis

Structure of packet
Packetization process: IP packet structure
Basic principles
the content of an incoming TRAU frame is recognized (idle or busy, if busy then with
noise or silence)
the informative bits are retrieved from an incoming frame and account for payload
payload gets headers and form manageable IP packet
payload
header
headers size is basically the same for each packet while payload size depends on
codec (e.g. 244 bits for AMR12.2 and 148 bits for AMR7.4, cf. previous slide)
therefore optimization of packetization process is needed otherwise transport overhead
would be unacceptable especially for lower codecs
RG20 implementation:
the following configurable features contribute to overhead reduction
header compression
CS multiplexing
22

Header compression (1/4)
Header compression: overview on protocol stack in Packet Abis
various protocol stacks are used for different planes and for different realization of
physical layer
CS/PS
U-plane
C/Mplane
p-RTP
p-RTP
UDP
UDP
IUA
IUA
SCTP
SCTP
IPIP
MC
MCML
MLPPP
PPP/ /HDLC
HDLC
TDM
TDM

CS/PS
U-plane
C/Mplane
p-RTP
p-RTP
UDP
UDP
IUA
IUA
SCTP
SCTP
IPIP
Ethernet
Ethernet(L2)
(L2)/ /VLAN
VLAN
Ethernet
Ethernet(L1)
(L1)
Notes:
usethese
are simplified pictures just for overview needed for network
planning
For internal
only
SCTP: Stream Control Transmission Protocol
23
IUA: ISDN User Adaptation
introduction of IPSec brings in additional headers

Header compression: basic principles
allows compression of some protocol headers before sending packets over a link and
decompression to their original state upon reception at the far end of the link
is possible due to the redundancy in header fields of given packet stream (many fields
being constant or changing hardly ever in consecutive packets: these can be recognized
and replaced with the smallest representation)
is hop-to-hop process, so it is necessary to decompress the header upon reception at
each node to manage the incoming packet (e.g. to perform routing or apply QoS
mechanisms), i.e. all interconnecting elements must support header compression
the functionality is supported (optionally) for Packet Abis over TDM (where bandwidth
efficiency is crucial) and is not for Packet Abis over PSN (lack of relevant standard)
Header compression is controlled by means of parameters

Next two slides give overview on header lengths used for network planning;
note that:
header length depends on plane (e.g. C-plane has different headers than U-plane)
header length depends on physical realization of Packet Abis (i.e. TDM vs. Ethernet)
header length depends on whether header compression is enabled or not
24

Header compression: compression gain for Packet Abis over TDM
CS/PS U-plane
IP
UDP
p-RTP
20
HDLC MC/ML-PPP
7
PPP header
compression
IP header
compression
45 octets without compression
UDP header
compression: 0 octets
18 octets with header compression
C/M-plane
HDLC MC/ML-PPP
7
PPP header
compression
IP
SCTP
IUA
20
16
24
IP header
compression

25

16
24
51 octets with header compression

Header compression: overview on headers lengths for Packet Abis over PSN
header compression is not supported in case of Packet Abis over PSN
CS/PS U-plane
VLAN
Ethernet (802.3) incl. IFG
IP
UDP
p-RTP
38
20
C/M-plane
VLAN
Ethernet (802.3) incl. IFG
IP
SCTP
IUA
38
20
16
24

26

CS multiplexing (CS U-plane)
CS multiplexing: basic principles
allows to put the content of several speech frames transmitted by different RTSLs
(from different TRXs within the same site) to the same packet
header
Ethernet or
MLPPP/HDLC
IP
payload
UDP
p-RTP
CODEC x
p-RTP
CODEC x
p-RTP
CODEC x
Packet Length without CS multiplexing

Packet Length with CS multiplexing
as a result several blocks of payload share the same header to minimize transport
overhead
Note that p-RTP header is needed for each call in the packet
CS multiplexing is applicable regardless on physical layer used by Packet Abis
(i.e. is supported for Packet Abis over TDM as well as for Packet Abis over PSN)
CS multiplexing is often (e.g. throughout this presentation) interchangeably referred to
as CS bundling
For internal
only amount of CS calls that can be bundled into a single packet is managed by means
usethe
27
of two configurable parameters

CS multiplexing: impact of parameterization (1/4)
This is simplified picture just to illustrate the concept and understand its gain!
e.g. just one TDMA frame out of the sequence that contribute to TRAU frame is visible
RTSL with signalling,
EGPRS or idle
Overhead evaluation with CS multiplexing:

- required information: used protocol stack (TDM or PSN)
and number of calls with particular codecs per packet
Case1:
RTSL with voice

call (AMR12.2)
MaxMuxWaitTime (RTSL) = 2
MaxPacketLength (octets) = 1500
TDMA frame
TRX1 / cell1
TRX2 / cell2
For example: Packet Abis over TDM (with header compression),

3 AMR12.2 calls multiplexed
with header compression
is taken into account
in calculations below
IP
p-RTP call 1
p-RTP call 2
p-RTP call 3
Header contributors:
TRX3 / cell3
2 RTSL
packets are built here:

1st packet: 3 calls => header = 32 octets, payload = ~92 octets
2nd packet: 4 calls => header = 39 octets, payload = ~122 octets
3rd packet: 3 calls => header = 32 octets, payload = ~92 octets
4th packet: 2 calls => header = 25 octets, payload = ~61 octets
Overall: header = 128 octets, payload = ~367 octets, overhead = ~26%
Overhead definition:
MLPPP
HDLC
- 11 octets of compressed HDLC/MLPPP/IP/UDP headers

- p-RTP header of 7 octets needed for each call in the packet
(in this example there are 3 calls in packet and thus 21 octets)
- in such case header of 11+21 = 32 octets is transmitted
- for Packet Abis over PSN proper stack must be used (i.e. 70 octets
for lower layers and p-RTP headers for each call in the packet)
Payload contributors:
- informative bits related to transmitted codec
- in this example, for 3 AMR12.2 calls, it is 3 x 244 bits = ~ 92 octets
Packet length:
- sum of header and payload octets transmitted by packet

header [octets]
- in this example 124 octets (32+92) i.e. less than set value of 1500
header [octets] payload [octets]

[%]Networks
28
overhead
Nokia Siemens

CS multiplexing: impact of parameterization (2/4)
This is simplified picture just to illustrate the concept and understand its gain!
e.g. just one TDMA frame out of the sequence that contribute to TRAU frame is visible
Case1:
Case2:
Case3:
MaxPacketLength (octet) = 1500
TDMA frame
TDMA frame
TDMA frame
TRX1 / cell1
TRX2 / cell2
TRX3 / cell3
2 RTSL
8 RTSL
packet is built here:
packets are built here:
Packet Abis over TDM: overhead of ~26%

Packet Abis over PSN: overhead of ~50%

29

packet is to be built here

but packet length limits
the amount of calls thus
calls are split into 2 packets

Silence suppression (CS U-plane)
Silence suppression in Packet Abis: background
in a typical speech call the involved parties are active alternately leaving pauses of silence
silent periods during speech connection can be represented by background noise and thus
transmitted at a much lower bit rate than speech in discontinuous transmission (DTX) mode
enabling of DTX results in the interference reduction in radio interface and
in transmission of TRAU frames containing no informative bits (silent frames) in
Legacy Abis interface
in Packet Abis silent frames are not transmitted
Packet Abis bandwidth savings due to silence suppression varies in different networks
as it depends on Voice Activity Factor (VAF)
Voice Activity Factor (VAF)
Definition: percentage of data blocks classified as active speech
~50% noise and ~50% silence

i.e. VAF = 50%

30
~50% noise and ~50% silence

i.e. VAF = 50%
VAF typically is within the range of 50% 60%
QoS mapping (1/3)
Overview on QoS concept in Packet Abis (IP layer)

Layer 3
combination of IP DiffServ and traffic scheduling is used
IP DiffServ
each packet is placed into one of predefined traffic classes

each router is configured to differentiate traffic based on its class
each traffic class can be managed differently and gets appropriate treatment based on its PHB
the PHB is indicated by encoding a value called the Differentiated Services Code Point (DSCP)
put into the Type Of Service (TOS) field of the IP packet header (6 LSB out of 8 bits are in use)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
6 various DSCP are available in Packet Abis:
Version
IHL
DiffServ (TOS)
Total Length
Identification
Flags
Fragment Offset
Expedited Forwarding (EF)
Time to Live
Protocol
Header Checksum
Source Address
4 Assured Forwarding (AF41 AF11)
Destination Address
Best Effort (BE)
traffic scheduling
Packet Abis scheduler has six FIFO queues,
each one corresponds to a different PHB
a traffic sent to the EF queue is handled with
the highest priority in the strict priority (SP) queue
a traffic sent to the remaining PHB is handled in
Weighted Fair Queuing (WFQ) with configurable
31
Nokia Siemens
Networks per queue
weights
QoS mapping (2/3)
Overview on QoS concept in Packet Abis (ETH layer)
Layer 2
combination of VLAN tagging and Ethernet traffic prioritization is used
VLAN tagging (IEEE802.1q)
VLAN tagging is used to create independent logical networks within a physical network, e.g. to
support different QoS (different packet treatment can be ensured in interconnecting switches for
different VLAN IDs, e.g. forwarding through alternative paths/ports where e.g. different bw is
assured)
2 different VLAN IDs are supported by BCF in RG20 (to separate M-plane from the rest of the
traffic): in RG20 achievement of full traffic separation by means of VLAN tagging is not possible
as it is left for future releases (VLAN differentiation for Packet Abis traffic is candidate for
RG30EP1)
traffic prioritization (IEEE802.1p)

traffic classes associated with different PHB can be additionally prioritized using Ethernet p-bits
8 priority levels are configurable however as many as 6 are needed to fully distinguish between
available PHB
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
C
TPID
PCP
F
VLAN ID
I
VLAN ID and PCP (Priority Code Point)

are configurable and mapped to VLAN header
Layer 2/3
PCP allows mapping PHB between L2/L3 for Packet Abis over PSN
mapping between PHB to L2 is also possible in case of Packet Abis over TDM:

32
QoS mapping (3/3)
QOS ISAT

33
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)
34

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
usepacket
For internal
only
loss (PL) detection for transport network congestion
35

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

36
Packet Abis
/ Network Engineering
/ March
2010reaction procedure
exceeding threshold starts
filtering
timer and
not
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
37
Nokia
Siemens Networks
Packet Abis
/ Network
Addressing
Overview on IP addressing concept in Packet Abis

BTS side
2 IP addresses needed: one for M-plane and another one for C/U-planes
the configuration of the same (single) IP address for all planes (M/U/C) is possible too
BSC side
4 groups of IP addresses needed (each plane may have its own address)
2 different addresses per each BCSU (one for M-plane and another for C-plane)
1 address per each ETP (for U-plane; in RG20 the same address is shared by CS and PS)
apart from IP addresses UDP ports (at U-plane) and SCTP ports (at M-/C-plane)
definitions are required to differentiate CS/PS (RTSL) and TRXSIG/OMUSIG flows
call and LAPD message differentiation is done on the higher layer i.e. RTP and IUA, respectively
Network Gateways
IP packet transmitted between BSC and BTS needs IP gateway if the packet destination is
not in theBTS
same subnet with source
Network Gateway
M-plane
C/U-plane
BSC
Network Gateway
M-plane
C/U-plane
Note:
refer
to notes
(cf. CR131)
38
Nokia
Siemens page
Networksfor addressing restrictions
CS U-plane
PS U-plane
C-plane
M-plane
CS U-plane (ETP)
PS U-plane (ETP)
C-plane (BCSU)
M-plane (BCSU)
Packet Abis
Dimensioning aspects

39
ETP/ETP-A Dimensioning

40
Dimensioning aspects: BSC/TCSM HW

ETP/ETP-A planning
ETP planning aspects (1/4): overall characteristics (1/2)
BSC/TCSM configuration possibilities:
BSC:
2000/FlexiBSC: 6+6 ETP for Packet Abis (ETPT+ETPE) + 4 ETP-A for AoIP (ETPA)
1000: 2+2 ETP for Packet Abis (ETPT+ETPE) + 2 ETP-A for AoIP (ETPA)
TCSM3i (per cabinet):
RG20 HW: 5+5 ETP-A for AoIP (ETPC)
legacy HW: 3+3 ETP-A for AoIP (ETPC)
Note1: CPU memory requirements for BSC with ETP installed
1GB in OMU/MCMU/BCSU is required
FlexiBSC: has 1 GB in all units as standard
BSC3i 1000/2000: to be checked (as typically it is 512 MB) and upgraded if necessary
Note2: redundancy concept for ETP-A (ETPA)
ETP-A units installed in BSC (AoIP with TC in MGW) work in load sharing mode...
...so in case of outage of one module the remaining ones are supposed to take over its
traffic => this concept must be reflected in planning strategy, e.g.
BSC serving ~24k Erl needs just 3 active ETPA modules
41

ETP/ETP-A planning
ETP planning aspects (2/4): overall characteristics (2/2)
ETP/ETP-A capacity:
256 BTS sites (BCF): #cells/TRX are irrelevant as ETP has no functionality on their level
i.e. up to 6x 256 = 1536 BCF per BSC can use Packet Abis
8192 TCH per ETPT/ETPE/ETPA and 3840 TCH per ETPC
32 logical PCU2-D or 8 logical PCU2-E or mixture of both (relevant only for ETP)
in mixed configuration each PCU2-E takes capacity of 4 logical PCU2-D
e.g. with 2 PCU2-E up to 32 2 x 4 = 24 logical PCU2-D can be handled too
ETPT requires ETS2
ETPT handles traffic from 1 STM1/OC3 interface => i.e. up to 63 E1 / 84 T1 per ETPT
ETS2 offers 2 STM1/OC3 interfaces; the second one can be used for another ETPT
ETP/ETP-A CPU capacity: under investigation
CPU load depends on the amount and length of processed packets:
PS traffic with high MCS and long C-plane messages are the most challenging
current view/expectation: should not limit capacity of ETP for the majority of traffic profiles
depending on the results of L&S tests planning methodology might be subject to
refinement (e.g. CPU capacity may need to be included in planning process)
42

ETP/ETP-A planning
ETP planning aspects (3/4): planning process
Basic engineering rules:
the number of ETPE and ETPT (as well as ETPA/ETPC) must be calculated separately
BCF sites with Packet Abis must be distributed homogenously between available ETPE
and ETPT by means of proper IP addressing
Example of calculation (see next slide for info about tool support):
Given:
100 sites with Packet Abis over TDM (e.g. 100 Erl/site, 1 E1/site)
50 sites with Packet Abis over Ethernet (e.g. 50 Erl/site)
4 PCU2-E per BSC
AoIP enabled
Calculations:
100 sites/BSC x 100 Erl/site = 10 kErl => 10,170 TCH (0.1% blocking) => 2 ETPT
50 sites/BSC x 50 Erl/site = 2.5 kErl => 2,603 TCH (0.1% blocking) => 1 ETPE
Note: BCF and PCU as well as ETS2 (for ETPT) limits are not exceeded
100 x 100 Erl + 50 x 50 Erl = 12.5 kErl/BSC => 12,682 TCH (0.1% blocking) =>
=> 2 ETPA (in case of AoIP with TC in MGW) or
=> 4 ETPC (in case of AoIP with TC in BSS) => TCSM configuration to be checked!
43
Nokia contribution
Siemens Networks
Packet
Abis / Network
Engineering
/ March
2010
Note:
of PS traffic
might
need
to be
re-evaluated
once ETP CPU

ETP/ETP-A planning
ETP planning aspects (4/4): tool support
ETP planning is fully supported by Packet Abis Calculator
To conduct ETP planning in the tool go to A & ETP worksheet
Define network configuration:
number of sites with given configuration
for each site configuration all relevant inputs must be given (cf. Slide132 for details), e.g.
#TRX per sector #RTSL for signalling, CS and PS traffic, CS and PS codec distribution
for each site configuration also two parameters which are ETP planning specific must be
given, i.e. Abis realization and AoIP realization (see callouts below)
Section Abis realization:
- for each site type user can indicate whether Legacy Abis (site is excluded from
ETP dimensioning) or Packet Abis over TDM or Packet Abis over Ethernet is used
- field global can speed up the setting for large networks: mixed means that Abis
realization varies among sites while any specific realization (again Legacy Abis,
PAoTDM, PAoEth) if chosen is loaded automatically in each and every site
Section AoIP realization:

- for each site type user can indicate whether AoIP with transcoding in BSS or in MGW
is used (note: tool assumes that AoIP is always in use; if this is not the case then
the results related to ETP-A can be just ignored)
- field global can speed up the setting for large networks: mixed means that AoIP
realization varies among sites while any specific realization (again tsc in BSS,
tsc in MGW) if chosen is loaded automatically in each and every site; value compare
gives at once the results as if all sites would use AoIP with transcoding in BSS and
in MGW for comparison purposes
Then press calculate and read-off the results:

Note!
Packet
For
internal
use onlyAbis Calculator knows nothing about topology of planning area and thus can not check whether STM1 capacity (63 E1 per ETPT) is not
factor
in case
of Packet Abis over TDM.Packet
Hence
user
mustEngineering
check manually
whether obtained number of ETPT is sufficient in a given scenario
44a limiting
Nokia
Siemens
Networks
Abis
/ Network
/ March 2010
(this might be critical when majority of Base Stations has p2p connection to BSC by their own E1, i.e. when grooming is hardly ever in use)
A-bis Interface Dimensioning

45
Dimensioning aspects: overview (1/2)

General overview, required inputs
Overall aspects
Main difference between bandwidth estimation for Dynamic Abis and Packet Abis:
Dynamic Abis bandwidth is mainly determined by a TRX configuration of a base station
and is constant over time due to permanent mapping, i.e. nearly the same (EGPRS might
be a main differentiator) bandwidth is reserved for base stations with a given configuration
regardless of traffic load (again: EDGE makes the only difference)
Packet Abis bandwidth mainly depends on a load distribution as well as on traffic profile
observed in a base station and varies over time
Therefore the bandwidth required by Packet Abis depends on many factors:
HW configuration per sector:
BTS site
configuration
and traffic
characteristics
#TRX
RTSLs reserved for signaling (BCCH /
CCCH / SDCCH) and PS traffic (CDED)
as well as shared between CS and PS
DTX on/off
Packet Abis
configuration
Physical layer: TDM or Ethernet

CS multiplexing configuration
Header compression
Synchronization method
Security features
Traffic load per sector:
CS: FR, HR, OSC Erlangs

PS: MB/hour
CS/PS codec distribution per site:
CS: usage of various AMR codecs

PS: usage of various (M)CS blocks
User profile
Amount of signaling
transactions per sub in BH:
#MOC, #MTC, #LUP, #SMS,
#HO
Call holding time
These all factors must be taken into account while doing bandwidth estimation
otherwise the planning outcome
is of reduced accuracy

46
Dimensioning aspects: bw estimation tool (4/8)

Packet Abis bandwidth estimation tool
Packet Abis bandwidth estimation tool (1/5): overview
To accurately estimate the gain coming from Packet Abis and optimally choose either capacity
of ML-PPP pipe or CIR (depending on L1) a statistics-based modeling is needed for:
CS and PS call arrival rates,
CS and PS territory size and PDCH utilization
The aspects related to Packet Abis dimensioning are implemented into Packet Abis Calculator
the tool is stored at https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/418327787
Apart from Packet Abis the tool can also support dimensioning for:
ETP/ETP-A units (cf. Slide149)
AoIP
refer to dedicated presentations
for details how to used the tool
for these features
Tool workflow:
choose preferred View
(i.e. calculation mode)
enter Inputs
press Calculate
Nokia
read-off
required Abis bandwidth
47
Siemens Networks

Packet Abis bandwidth estimation tool (2/5): calculation mode
The tool offers calculations on the basis of either full (i.e. Complete View) or reduced (i.e.
Basic View) set of inputs
reduced set of inputs (Basic View) can be used when full accuracy is not needed (e.g.
for quick overview, never for contractual commitments!) or when some parameters are
unknown (and reduced accuracy is acceptable)
in Basic View some parameters are not explicitly defined and in calculation procedure
are replaced with default values; the replaceable parameters are:
BTS (sector)
configuration
and load
Packet Abis
configuration
codec distribution
(CS and PS)
configuration of header
compression and CS mux
default values used in Basic View are shown below:
FR/HR share is
reflected in share
of 12.2 (FR) and
7.4 (HR) codecs
default MCS
distribution leads
to moderate
mean PDCH thr
For
use only
of ~internal
38 kbps
48
User profile
traffic profile
Header compression by default is:

- enabled for TDM transport
- disabled for PSN transport

Packet Abis bandwidth estimation tool (3/5): Input definition (1/2)
BTS (sector)
configuration
and load
BTS configuration and load

Section BTS HW Configuration:
- #TRX per sector
- for each sector: total #RTSLs reserved for signaling (BCCH/CCCH/SDCCH),
for PS traffic (CDED) and those shared between CS and PS
Section Traffic Load:

- CS: FR, HR, OSC Erlangs per sector (!!!!)
- PS: MB/hour per sector (!!!!)
Note:
user can choose a mode of CS traffic definition, i.e. load and utilization:
- load: user can enter the amount of FR/HR/OSC Erlangs retrieved from the
field by means of PM counters (this mode allows for the most accurate bw
estimation and is the recommended approach as e.g. allows to quantitatively
approximate trunking gain coming from unbalanced sectors load)
- utilization: user can enter required percentage of FR/HR/OSC and tool will
calculate the amount of FR/HR/OSC Erlangs that can be served by available
RTSL assuming blocking rate of 2% (only hard blocking is to be met)

49
Section Codec distribution and utilization:

- CS: usage of various AMR codecs per BTS site (BCF)
- PS: usage of various (M)CS blocks pet BTS site (BCF)
Note:
- CS: when AMR is enabled choose AMR = ON and
enter distribution, when AMR is disabled choose AMR =
OFF and then FR/HR share is reflected in share of 12.2
(FR) and 7.4 (HR) codecs
- PS: when EDGE is enabled choose EDGE = ON and
enter distribution, when EDGE is disabled choose EDGE
= OFF

Packet Abis bandwidth estimation tool (4/5): Input definition (2/2)
Packet Abis
configuration
Packet Abis configuration

Section Packet Abis configuration:
- Physical transport: TDM or Ethernet
- synchronization method: E1/T1 (for TDM) and ToP/ACR/SyncEth (for PSN)
- Header compression: on/off for TDM and off only for PSN
- CS multiplexing time: 2, 4 or 6 msec (corresponding to 2, 4 and 8 RTSL)
- CS packet length: 300 1500 octets
User profile
User profile
Section Signalling:
- amount of signaling transactions per sub in BH (#MOC, #MTC, #LUP, #SMS,
#HO) and call holding time
- #LAC per BSC:
1 corresponds to ~3000 cells per LAC
2 corresponds to ~1500 cells per LAC
Section Throughput given by:
- PDCH throughput can be defined either by definition of MCS distribution or
directly by entering manually
Section DTX mode:
- when enabled then gain from silence suppression is calculated and included in
CS U-plane traffic otherwise no distinction between speech frames with
silence and noise
50

Packet Abis bandwidth estimation tool (5/5): outcome of the tool
The bandwidth estimation is displayed in section OUTPUTS:
The calculated and displayed value denotes Packet Abis bandwidth which is needed to
transmit offered CS and PS traffic with given codec distribution
therefore both traffic amount and codec distribution affect backhaul bandwidth
and thus any modification of either traffic amount or codec distribution modifies
the required Abis bandwidth too
Any modification of traffic amount and/or codec distribution
must trigger recalculation of the required Packet Abis bandwidth
The outcome of the tool (Abis bandwidth required) has different meaning depending on
physical realization of Packet Abis:
TDM: required bandwidth must be expressed in terms of PCM TSL that are mapped to
HDLC link(s) which constitute ML-PPP bundle associated with TDM lines connecting BTS
with BSC
For internal
only
usePSN:
required bandwidth
is mapped to CIR value
51
PCU Dimensioning

52
Dimensioning aspects: PS traffic in Packet Abis

PCU planning with Packet Abis
PCU planning aspects (1/8): impact of Packet Abis on PCU planning
Summary on PCU planning aspects :
the method used for Dynamic Abis must be adapted:
Dynamic Abis => #EDAP/PCU (i.e. ~ #EGPRS sites/PCU) = f(CDEF_sum, EDAP)

for Packet Abis a new parameter is introduced to indicate whether given cell must
satisfy just connectivity or throughput requirements: GPRS capacity throughput factor
(GCTF)
Packet Abis => #SEG/PCU (i.e. ~ #EGPRS sites/PCU/3) = f(CDEF, GCTF)

PCU utilization rate must be taken into account to reserve some resources for territory
upgrades
Pros and cons of the replacement of EDAP with GCTF:

more sites can be controlled by PCU (in majority of cases, depending on GCTF settings)
more room for optimization/service: it is possible to indicate cell importance (connectivity
vs. throughput) rather than BCF => optimization can be done per cell basis
more complex planning, more degrees of freedom per PCU
more complex Gb planning

53

PCU planning aspects (2/8): dimensioning targets
PCU planning in Packet Abis environment is composed of 2 steps:
connectivity and throughput targets
initial allocation aspects (GCTF planning)
Basic dimensioning formula used for Dynamic Abis can be
(*) per logical PCU
parameter (*)
PCU2-E
PCU2-D
max RTSL
1024
256
max BTS
384
128
max SEG
256
64
max TRX
1024
256
8 Mbps
2 Mbps
max Gb throughput
reused for Packet Abis after small adaptations:

#DSP
6
8
6880 B
1280 B
#EDAPs and #Abis channels removed (as they are irrelevant) #bw/DSP
1
2
target PCU utilization factor U should be of 50% (to leave #logical PCU/PIU
enough space for territory upgrades and at the same time allow for high overbooking)
# RTSL
# BTS
# SEG
# TRX
GbThr
# PCU max
;
;
;
;
max RTSL U max BTS max SEG max TRX max GbThr
PCU connectivity target is understood as sum of RTSLs in default territory (CDEF)

Gb throughput calculation is based on all average and single peak approach
As a result of EDAP removal the radio resources are distributed among PCU on per cell
(segment) basis (i.e. no longer per site/EDAP like for Legacy Abis); to simplify planning a
distinction between two basic types of cells is introduced:
throughput cell (TC) where high throughput rates are expected
connectivity cell (CC) where mainly PS connectivity is required and throughput rates
54
Nokia
Siemens
can
beNetworks
moderate

PCU planning aspects (3/8): connectivity and throughput cells
An optimum PCU planning requires an aware cell assignment to CC or TC classes; this in
combination with statistical multiplexing results after migration to Packet Abis in:
serving typically more cells per PCU (compared to the case with Dynamic Abis),
achieving greater throughput rates (Note: Gb throughput might be bottleneck as it is not
extended in Packet Abis) for both throughput and connectivity cells:
TC: by proper planning of overbooking factor (less TC than CC are allocated to PCU
to maximize throughput)
CC: throughput is no longer limited by EDAP size (like in Dynamic Abis where a cell
assigned to a small EDAP could never get high throughput rates even though the
other EDAPs assigned to the PCU were not used in a given scheduling cycle)
Therefore, initial rough estimation of #cells per PCU is just based on the size of CDEF; and
e.g. PCU2-E can support (keeping in mind that utilization factor U should not exceed 50%):
256 connectivity cells with CDEF=2 (extra small PS configuration that can be used to
provide connectivity to a very high number of cells),
128 connectivity cells with CDEF=4 (which is a typical size of default territory for a
majority of configurations),
42 throughput cell with CDEF=12 (this will allow to maximize throughput for these cells)
of course different mixtures of both cell types is absolutely possible depending on the
throughput
in Abis
a given
network
55
Nokia
Siemens Networks requirements
Packet
/ March 2010

PCU planning aspects (4/8): connectivity and throughput cells
Assignment to CC or TC group must be done for each cell that is supposed to support PS
traffic by means of three basic parameters: CDEF (incl. CDED), CMAX and GCTF
The following settings of CDEF and GCTF are recommended to define CC and TC:
CC: CDEF = 4 (or even 2 to maximize connectivity cf. example on previous slide),
CMAX = 16, GCTF = 20%
TC: CDEF = 12, CMAX = 24 to 48 (typical), GCTF= 80 %
The recommended settings defined above give the following benefits:
CDEF/CMAX settings: allow to calculate how many TC and/or CC should be assigned
to the PCU to get a reasonable overbooking (to meet throughput and/or connectivity
targets)
GCTF settings: allow to distribute cells in optimum way among DSP (e.g. too many
TC will not be served by the same DSP to maximize throughput)
Note:
an improper or suboptimal planning of GCTF reduces the number of cells that can
be controlled by a PCU as during system init default PCU resource need is calculated
(cf. DEF_BW_NEED formula on Slide50) per cell based on CDEF and GCTF
then system calculates how many cells can be controlled by DSP and, in
consequence, by the PCU (and what is optimum distribution of cells among DSPs)
56
Nokia
cf.Siemens
nextNetworks
slide for details Packet Abis / Network Engineering / March 2010

PCU planning aspects (5/8): initial PCU allocation aspects (GCTF planning)
When PCU knows DEF_BW_NEED per each allocated cell
(*) per logical PCU
parameter (*)
PCU2-E
PCU2-D
then it checks:
max RTSL
1024
256
max BTS
384
128
whether all cells can be connected to the PCU and
max SEG
256
64
what is optimum distribution of cells among DSPs
max TRX
1024
256
E.g. for PCU2-E:
max Gb throughput
8 Mbps
2 Mbps
#DSP
6
8
PCU manageable bw: 6 DSP x 6880 octets = 41280 octets
#bw/DSP
6880 B
1280 B
E.g. 128 EDGE capable connectivity cells with CDEF = 4
#logical PCU/PIU
1
2
(cf. Slide140) and GCTF = 20% can be easily allocated
128 x (200 x 4 x 0.2) = 20480 octets
Note that setting GCTF to e.g. 80% (default value) for all these connectivity cells effects
in reduction of the number of cells that can be connected to this PCU (just because of not
feasible initial allocation) by factor of 2 => 41280 / (200 x 4 x 0.8) = 64
cell throughput will be maximized but for CC this is not a planning target
GCTF planning rules:
one type of cells (either CC or TC) is to be connected: set GCTF to identical and low
value (e.g. 10%, 20%...) for each cell to minimize its impact
mixture of CC and TC is to be connected (typical case): set GCTF to very different
for CC and TC (e.g. 20% and 80%, respectively) to clearly indicate to PCU which
For internal usevalues
only
57
cells are supposed to provide
high rates (and thus to reduce likelihood of TC

PCU planning aspects (6/8): Gb capacity
Gb link capacity is calculated based on the following assumptions:
Gb average throughput is calculated based on all average and single peak approach
it is assumed that 25% cells are transmitting at the same time
Note: for big overbooking this assumption might be unrealistic, so overbooking
should be limited to the case with pure CC for which achievable throughput is not
critical
Dimensioning has two steps: link capacity estimation and transport overhead calculation
average
link capacityGbcan
be throughput
estimated by means of Erlang Crequired
formula
link capacity
peak cell throughput
delay factor
Erlang C
(raw data, without overhead)
Note: there is no closed formula describing Erlang C distribution but efficient and
numerically stable tools are online available, e.g. cf. [ErlangC_calc]
overhead factor depends on realization of physical layer and length of transmitted blocks
Gb over Frame Relay: total headers length of ~109 octets
Gb over IP: total headers length of ~163 octets
typical
Gb interface
is of ~500 octets what corresponds to
58
Nokia Siemens
Networks size of payload
Packet blocks
Abis / Networkon
Engineering
/ March 2010

PCU planning aspects (7/8): Gb capacity
final step is to calculate Gb throughput rate as: link_capacity x overhead_factor
resulting Gb throughput rate must not exceed PCU capabilities (e.g. 8 Mbit/s for PCU2-E)
if it exceeds then it means that:
either that many cells cannot be served (this is only when certain throughput rates
must be guaranteed for majority of cells which is nearly never the case),
or expected average throughputs cannot be achieved for that many cells (i.e.
25% of connected cells) simultaneously but only when PS peak hours for connected
cells are distributed
Therefore Gb throughput requirements may lead to reconsideration of the amount of cells
connected to the PCU due to following reasons:
required Gb link capacity is a well known trade-off between network cost (especially for
Frame Relay transport where 4 Gb E1 lines needed to provide 8 Mbit/s) and throughput
as a result, when many E1 lines would be needed on Gb, either reduction on #cells per
PCU (makes sense only when strict throughput requirements are defined) or reduction of
average throughput rates help to reduce E1 lines on Gb
careful planning aiming at allocation to the PCU cells having PS peak hours distributed
also helps to maximize throughput within reasonable HW configuration
in majority cases this is not that challenging as normally handling of offered traffic is
the
only
dimensioningPacket
target
for PS
U-plane
59
Nokia
Siemens
Networks
Abis / Network
Engineering
/ March 2010

PCU aspects (PS U-plane)
PCU aspects: impact of Packet Abis on DSP allocation algorithm (2/5)
in Packet Abis, apart from removal of EDAP (and Abis channels), the same PCU capacity
figures are in place hence EDAP must be replaced both:
in DSP allocation algorithm as well as
in its role of indicator showing whether connectivity or throughput requirements shall be met
Therefore, in Packet Abis:

DSP resources are distributed among segments rather than EDAPs (#segments and their CDEFs)
GPRS capacity throughput factor defines BTS priority from pure coverage to high performance
at segment level
DSP allocation algorithm estimates for each segment default bandwidth need:
DEFAULT_BW_NEED / SEGMENT =
= (NUM_CS1_CS2_RTSL x CS1_CS2_BW_NEED + NUM_CS3_CS4_RTSL x CS3_CS4_BW_NEED +
+ NUM_EGPRS_RTSL x EGPRS_BW_NEED) x GPRS_CAPACITY_THROUGHPUT_FACTOR
where:
NUM_CS1_CS2_RTSL: default territory in BTS with GPRS CS1/CS2 channels

NUM_CS3_CS4_RTSL: default territory in BTS with GPRS CS3/CS4 channels
NUM_EGPRS_RTSL: default territory in BTS with EGPRS channels
CS1_CS2_BW_NEED: 46 octets (= octets needed by CS2 incl. PCU frame header, PEP header and data link
header)
useCS3_CS4_BW_NEED:
80 octets
For internal
only
60
EGPRS_BW_NEED: 200 octetsPacket Abis / Network Engineering / March 2010

for PCU planning (in addition to GPRS capacity throughput factor) the bandwidth managed
by DSP of given PCU2 HW variant is also needed:
PCU2-D: 32 channels x 40 bytes = 1280 bytes
PCU2-E: 172 channels x 40 bytes = 6880 bytes
initial PCU reservation per segment can be then evaluated based on:
default bandwidth need per segment and
DSP controllable bandwidth
initial DSP allocation is done at system start-up (init, BCSU switchover, PCU re-start, PCU
pooling) and aims at throughput maximizing for each RTSLs in default territory
while during regular scheduling DSP consumption in Packet Abis is managed Dynamic
Abis likewise as it depends on the actual coding scheme used (and not on xxx_BW_NEED
shown on the previous slide) and aims at connectivity maximizing:
each allocated RTSL has 1 channel (40 octets) reserved in UL, no reservation in DL
EGPRS MCS
Dynamic Abis
Packet Abis
available DSP bw is used for territory
MCS1
1+0
40 octets
upgrades and handling of high (M)CS
MCS2 MCS5
1+1
80 octets
GCTF is not checked while handling
MCS6
1+2
120 octets
territory upgrade or high MCS assignment
MCS7
1+3
160 octets
PCU
handles
the
requests
in
the
order
MCS8 MCS9
1+4
200 octets
61
of coming (FIFO)

Therefore, in Packet Abis:
the number of segments per PCU replaces the number of EDAPs in the planning
methodology and
the number of PCUs is determined by combination of CDEF and GCTF (i.e. GPRS
capacity throughput factor):
Packet Abis => #SEG/PCU (i.e. ~ #EGPRS sites/PCU/3) = f(CDEF, GCTF)

just like for Dynamic Abis, certain assumption concerning PCU utilization must be taken
to reserve some resources for territory upgrades
see next slides for further details!
Note that definition of default bandwidth need determines the actual PCU connectivity with
Packet Abis:
E.g. how many PCU2E is needed to handle 1024 RTSL with MCS9? Lets assume 4
RTSL / segment:
4 EGPRS RTSLs x 200 bytes = 800 bytes / segment and we need 1024 / 4 = 256
segments of that kind
Nokia
62
Siemens
Networks
Packetper
Abis / Network
Engineering
March 2010
256
segments
x 800 bytes
segment
/ /6880
bytes per DSP = 30 DSP => 5 PCU2-E

Impact of GCTF settings on regular PCU scheduling (e.g PCU2-D, all cells are EDGE capable)
case 1: CDEF = 3, GCTF = 40%
case 2: CDEF = 3, GCTF = 80% (default)
Case 1:
DEF_BW_NEED/SEG = 3 x 200 x 40% = 240 octets => 5 SEG/DSP (94% of DSP utilization)
15 (= 5 SEG x 3 CDEF/SEG) channels reserved => 17 channels available for upgrades
4 RTSLs get MCS9 if all of those 15 RTSLs request for MCS9 => 4xMCS9 + 11xMCS1 (31
channels in use)
Case 2:
DEF_BW_NEED/SEG = 3 x 200 x 80% = 480 octets => 2 SEG/DSP (75% of DSP utilization)
6 (= 2 SEG x 3 CDEF/SEG) channels reserved => 26 channels available for upgrades
all 6 RTSLs may get MCS9 if all of them request for it => 6xMCS9 (30 channels in use)
Notes:
GCTF should be set so that trade-off between number and utilization of PCU is
reasonable and installed PCUs meet throughput and connectivity requirements
this can be ensured by combination of PCU connectivity and Gb throughput rates
refer to PCU planning aspects for relevant planning rules and examples
63

PCU planning aspects (8/8): summary
The following aspects must be taken into account during PCU planning
PCU
connectivity
Planning is done based on CDEF and CMAX

CDEF must reflect the importance of the cell: small and moderate CDEF for CC, large CDEF
only (!!!!) for TC
CMAX is the only mean to limit PCU consumption by a single cell (in Dynamic Abis it is also
managed by EDAP): careful planning should be considered to avoid PCU occupation by a single
cell (crucial for PCU2-D, but also important for PCU2-E)
PCU utilization rate: 50% should be used as a planning rule (enough space for territory upgrades)
GCTF
planning
careless planning of GCTF reduces the number of cells that can be controlled by a PCU
if one type of cells connected to PCU (CC or TC): set GCTF to identical and low value (e.g. 10%,
20%...) for each cell
if mixture of CC and TC connected to PCU: set GCTF to very different values for CC and TC (e.g.
20% and 80%, respectively)
Gb
throughput
calculated based on all average and single peak approach

link capacity required to transmit offered traffic via queuing system can be estimated by Erlang C
header lengths depend on physical layer realization (Frame Relay or IPoEth)
E1 capacity on Gb is a trade-off between cost and throughput, migration to Gb over IP reduces
costs (PSN cheaper than TDM) but does not extend PCU throughput rates (beyond 8 Mbit/s)
Different cases can be studied by means of the worksheet below

refer to backup slides for a calculation example
64
Micros oft Excel

Works heet
Packet Abis
PM counters

65
Performance Measurements for Packet Abis

Overview
With Packet Abis all Dynamic Abis related measurements (e.g. 76 Dynamic Abis
measurement) are not triggered any longer (new Packet Abis related counters
are pegged instead)
6 new transmission measurements have been implemented:
- 123 Packet Abis BTS measurement
- 124 Packet Abis Traffic measurement
- 125 Packet Abis SCTP measurement
- 126 Packet Abis Delay measurement
- 127 Packet Abis Congestion Control measurement
- 128 ETP Ethernet BSC measurement
3 measurements have been modified and new counters introduced:
- 1 Traffic measurement
- 72 Packet Control Measurement
- 110 PCU utilization

66

Overview
6 new transmission measurements have been implemented
while 4 of them are used for packet flow monitoring:
- 123 - Packet Abis BTS measurement
- 124 - Packet Abis Traffic measurement
- 125 - Packet Abis SCTP measurement
- 128 - ETP Ethernet BSC measurement
CS/PS
U-plane
123 Packet Abis
BTS meas
p-RTP
p-RTP
UDP
UDP

67
C/Mplane
IUA
IUA
SCTP
SCTP
CS/PS
U-plane
124 Traffic meas
p-RTP
p-RTP
UDP
UDP
C/Mplane
IUA
IUA
SCTP
SCTP
IPIP
Ethernet
Ethernet(L2)/
(L2)/ML
MLPPP
PPP
IPIP
Ethernet
Ethernet(L2)/
(L2)/ML
MLPPP
PPP
Ethernet
Ethernet(L1)/
(L1)/TDM
TDM
Ethernet (L1)/ TDM

Ethernet (L1)/ TDM
BSC
125 SCTP meas

128 ETP Ethernet
BSC meas
Dimensioning aspects: transport aspects

PSN requirements
Impact of SLA on performance: delay, delay variation and packet loss
Packet Loss
Transport impairments (delay, delay variation
Malfunction of the system
Not acceptable degradation
TDM-like
KPIs !!!
Acceptable
degradation
and packet loss) are unavoidable in PSN,

but when they are kept below certain thresholds
degradation is small and hardly noticeable
which degradation is acceptable depends on:
traffic mix (basically CS is more robust
against delay compared with PS),
PSN configuration
operator
Delay
Ref. TRS PM, Packet Network for Mobile Backhaul
For Packet Abis investigation is ongoing to find acceptable values of SLA parameters:
Note that the figures given in the table below must be currently interpreted as
the design target
rather thanmaximum
the binding indication!
recommended
max delay
15 msec
50 msec
max delay variation
10 msec
50 msec
max packet loss rate
0.001 %
0.01 %

68
recommended: near or the same performance like TDM

maximum: system operational but gives KPIs that are normally
not acceptable
Ref. SFS Packet Abis overview, S. Krafft / L. Marnoni,

BSS21231,
version
1.0.1, December
2008
Packet
Abis / Network
Engineering
/ March 2010

Feature verification
Feature impact
How to observe/measure
SLA must be negotiated to guarantee

backhaul requirements concerning
packet loss rate
delay
max delay variation (jitter)
KPI:
UL_ FRAME_ERROR_RATE
DL_PACKET_LOSS_RATE_U_PLANE_RTP
UL_PACKET_LOSS_RATE_U_PLANE_RTP
DL_PACKET_LOSS_RATE_U_PLANE_UDP_CS
SCTP_RETRANS_RATE_DL
SCTP_RETRANS_RATE_UL
New KPIs must be observed to verify

whether backhaul performs properly

69

Feature verification
Feature impact
Delay
How to observe/measure
KPI:
AVG_RTT shall be monitored and based on this value Jitter
Buffer Size fine tuned.
Furthermore counters:
ROUND_TRIP_TIME_VARIATION_MIN (126007) and
ROUND_TRIP_TIME_VARIATION_MAX (126008)
shall be observed. The closer their values are each other the
more accurate AVG_VAR_RTT, the further these values are
each other the less reliable average variation is and (if Jitter
Buffer Size is set according to average variation) more packets
is received outside buffering window due to too early or too
late arrival. This phenomena can be observed by following
KPIs:
DL_CS_PACKET_LOSS_RATE_RTP_DUE_TO_DEJITTER
and
UL_CS_PACKET_LOSS_RATE_RTP_DUE_TO_DEJITTER

70

List of new KPIs
Ethernet
KPI
Jump (*)
Formula
UL_ FRAME_ERROR_RATE
pabi_1000
ERRORED_ETH_FRAMES_ETP_BSC *100 /
RECEIVED_ETH_FRAMES_ETP_BSC [%]
AVG_DL_FRAME_SIZE
pabi_1001
TRANSM_ETH_OCTETS_ETP_BSC /
(TRANSM_ETH_FRAMES_ETP_BSC *1000)
AVG_UL_FRAME_SIZE
pabi_1002
OCTETS_SENT_BTS / FRAMES_SENT_BTS
AVG_DL_GROSS_BIT_RATE
pabi_1003
TRANSM_ETH_OCTETS_ETP_BSC * 8 / granularity_period
AVG_UL_GROSS_BIT_RATE
pabi_1004
OCTETS_SENT_BTS * 8 / granularity_period
(*): cf. References

71

List of new KPIs
RTP
KPI
Jump
Formula
DL_PACKET_LOSS_RATE_U
_PLANE_RTP
pabi_1005
(CS_U_PLANE_RTP_PACKT_LOST_BTS+
PS_U_PLANE_RTP_PACKT_LOST_BTS)*100 /
(CS_U_PLANE_RTP_PACKT_LOST_BTS +
PS_U_PLANE_RTP_PACKT_LOST_BTS +
CS_U_PLANE_RTP_PACKT_REC_BTS +
PS_U_PLANE_RTP_PACKT_REC_BTS) [%]
UL_PACKET_LOSS_RATE_U
_PLANE_RTP
pabi_1006
(CS_U_PLANE_RTP_PACKT_LOST_BSC +
PS_U_PLANE_RTP_PACKT_LOST_BSC)*100/
(CS_U_PLANE_RTP_PACKT_REC_BSC +
CS_U_PLANE_RTP_PACKT_LOST_BSC+
PS_U_PLANE_RTP_PACKT_REC_BSC +
PS_U_PLANE_RTP_PACKT_LOST_BSC) [%]
_PLANE_RTP_CS
pabi_1007
CS_U_PLANE_RTP_PACKT_LOST_BTS * 100 /
(CS_U_PLANE_RTP_PACKT_LOST_BTS +
CS_U_PLANE_RTP_PACKT_REC_BTS) [%]
_PLANE_RTP_CS
pabi_1008
CS_U_PLANE_RTP_PACKT_LOST_BSC *100 /
(CS_U_PLANE_RTP_PACKT_REC_BSC +
CS_U_PLANE_RTP_PACKT_LOST_BSC ) [%]
_PLANE_RTP_PS
pabi_1009
PS_U_PLANE_RTP_PACKT_LOST_BTS *100 /
(PS_U_PLANE_RTP_PACKT_LOST_BTS +
PS_U_PLANE_RTP_PACKT_REC_BTS) [%]

72

List of new KPIs
RTP
KPI
Jump
Formula
_PLANE_RTP_PS
pabi_1010
PS_U_PLANE_RTP_PACKT_LOST_BSC * 100 /
(PS_U_PLANE_RTP_PACKT_REC_BSC +
PS_U_PLANE_RTP_PACKT_LOST_BSC) [%]
DL_CS_PACKET_LOSS_RAT
E_RTP_DUE_TO_DEJITTER
pabi_1011
(CS_U_PLANE_RTP_TOO_LATE_BTS +
CS_U_PLANE_RTP_TOO_EARLY_BTS) *100 /
(CS_U_PLANE_RTP_PACKT_REC_BTS) [%]
UL_CS_PACKET_LOSS_RAT
pabi_1012
(CS_U_PLANE_RTP_TOO_LATE_BSC +
CS_U_PLANE_RTP_TOO_EARLY_BSC) *100/
CS_U_PLANE_RTP_PACKT_REC_BSC [%]
DL_PS_PACKET_LOSS_RAT
pabi_1013
(PS_U_PLANE_RTP_TOO_LATE_BTS +
PS_U_PLANE_RTP_TOO_EARLY_BTS) *100 /
(PS_U_PLANE_RTP_PACKT_REC_BTS) [%]
CS_MUX_FACTOR_DL
pabi_1014
CS_U_PLANE_RTP_PACKT_SENT_BSC /
CS_U_PLANE_UDP_PACKT_SENT_BSC
CS_MUX_FACTOR_UL
pabi_1015
CS_U_PLANE_RTP_PACKT_SENT_BTS /
CS_U_PLANE_UDP_PACKT_SENT_BTS

73

List of new KPIs
RTP
KPI
Jump
Formula
CS_TRAFFIC_SHARE_DL
pabi_1016
CS_U_PLANE_RTP_PACKT_SENT_BSC *100 /
(CS_U_PLANE_RTP_PACKT_SENT_BSC +
PS_U_PLANE_RTP_PACKT_SENT_BSC) [%]
CS_TRAFFIC_SHARE_UL
pabi_1017
CS_U_PLANE_RTP_PACKT_SENT_BTS *100 /
(CS_U_PLANE_RTP_PACKT_SENT_BTS +
PS_U_PLANE_RTP_PACKT_SENT_BTS ) [%]
PS_TRAFFIC_SHARE_DL
pabi_1018
PS_U_PLANE_RTP_PACKT_SENT_BSC *100 /
(CS_U_PLANE_RTP_PACKT_SENT_BSC +
PS_U_PLANE_RTP_PACKT_SENT_BSC) [%]
PS_TRAFFIC_SHARE_UL
pabi_1019
PS_U_PLANE_RTP_PACKT_SENT_BTS *100 /
(CS_U_PLANE_RTP_PACKT_SENT_BTS +
PS_U_PLANE_RTP_PACKT_SENT_BTS ) [%]

74

List of new KPIs
UDP
KPI
Jump
Formula
_PLANE_UDP_CS
pabi_1020
(CS_MUX_FACTOR_DL *
CS_U_PLANE_RTP_PACKT_LOST_BTS ) * 100 /
(CS_U_PLANE_UDP_PACKT_REC_BTS +
CS_MUX_FACTOR_DL *
CS_U_PLANE_RTP_PACKT_LOST_BTS ) [%]
_PLANE_UDP_CS
pabi_1021
(CS_MUX_FACTOR_UL *
CS_U_PLANE_RTP_PACKT_LOST_BSC) * 100 /
(CS_U_PLANE_UDP_PACKT_REC_BSC +
CS_MUX_FACTOR_UL*
CS_U_PLANE_RTP_PACKT_LOST_BSC) [%]
AVG_DL_CS_U_PLANE_UDP
_PACKET_SIZE
pabi_1022
CS_U_PLANE_UDP_OCTET_SENT_BSC /
CS_U_PLANE_UDP_PACKT_SENT_BSC
AVG_UL_CS_U_PLANE_UDP
_PACKET_SIZE
pabi_1023
CS_U_PLANE_UDP_OCTET_SENT /
CS_U_PLANE_UDP_PACKT_SENT_BTS / 100
SHARE_OF_DL_OCTS_FOR_
CS
pabi_1024
CS_U_PLANE_UDP_OCTET_SENT_BSC * 100 /
(CS_U_PLANE_UDP_OCTET_SENT_BSC +
PS_U_PLANE_UDP_OCTET_SENT_BSC) [%]
SHARE_OF_UL_OCTS_FOR_
CS
pabi_1025
CS_U_PLANE_UDP_OCTET_SENT * 100 /
(CS_U_PLANE_UDP_OCTET_SENT +
PS_U_PLANE_UDP_OCTET_SENT_BTS) [%]

75

List of new KPIs
SCTP
KPI
Jump
Formula
AVG_SCTP_PACKET_SIZE_D
L
pabi_1026
SCTP_OCTETS_SENT_BSC /
SCTP_PACKETS_SENT_BSC / 1000
AVG_SCTP_PACKET_SIZE_U
L
pabi_1027
SCTP_OCTETS_SENT_BTS /
SCTP_PACKETS_SENT_BTS
SCTP_RETRANS_RATE_DL
pabi_1028
SCTP_PACKET_RETRANSMIT_BSC * 100 /
SCTP_PACKETS_SENT_BSC [%]
SCTP_RETRANS_RATE_UL
pabi_1029
SCTP_PACKETS_RETRANSMIT_BTS * 100 /
SCTP_PACKETS_SENT_BTS [%]
C_M_PLANE_SHARE_DL
pabi_1030
SCTP_OCTETS_SENT_BSC * 100 /
(SCTP_OCTETS_SENT_BSC + 1000 *
CS_U_PLANE_UDP_OCTET_SENT_BSC + 1000 *
PS_U_PLANE_UDP_OCTET_SENT_BSC) [%]
C_M_PLANE_SHARE_UL
pabi_1031
SCTP_OCTETS_SENT_BTS * 100 /
(SCTP_OCTETS_SENT_BTS + 10 *
CS_U_PLANE_UDP_OCTET_SENT + 10 *
PS_U_PLANE_UDP_OCTET_SENT_BTS) [%]

76

List of new KPIs
Miscellaneous
KPI
Jump
Formula
AVG_RTT
pabi_1032
SUM_OF_ABIS_ROUND_TRIP_TIMES /
ABIS_ROUND_TRIP_TIME_SAMPLES
AVG_VAR_RTT
pabi_1033
SUM_ROUND_TRIP_TIME_VARIATION /
ROUND_TRIP_TIME_VAR_SAMPLES
CONGESTION_RATE
pabi_1034
(DECREASE_TBF_SCH_RATE_25 / 100) / 3600
CONGESTION_RATE_DUE_T
O_PL1_BU1
pabi_1035
((DECREASE_TBF_SCH_RATE_25
DECREASE_TBF_SCH_RATE_75) / 100) / 3600
O_PL2_BU2
pabi_1036
(DECREASE_TBF_SCH_RATE_75 / 100) / 3600
O_ETP_OVL
pabi_1037
(LIMIT_NEW_CS_CALLS_OVERLOAD / 100) / 3600
PACKET_ABIS_SHARE_IN
TCH BLOCKING
pabi_1038
(TCH_REQ_REJ_DUE_ABIS_CON +
TCH_REQ_REJ_DUE_ETP_OVERLOAD)*100 /
TCH_REQ_REJ_LACK [%]
TERRITORY_UPGRADE_REJ
ECTION_DUE_TO_ABIS
blck_1000
GPRS_TERR_UG_REJ_DUE_ABIS /
GPRS_TER_UPGRD_REQ
PCU2D_UTIL
PCU2E_UTIL
77
PEAK_RESERVED_PCUPCM_CH / 10240
PEAK_RESERVED_PCUPCM_CH
/ 41280
Packet Abis / Network Engineering
/ March 2010
Packet Abis

78
Overview
Packet Abis parameters which are somehow relevant each other are clustered together:
Packet Abis connection type
U-/C-/M-plane mechanisms (CS bundling, SCTP/IUA procedures)
Congestion control
QoS
Addressing
Miscellaneous (PCU allocation algorithm, PDV compensation buffer, IPSec enabling)
Security
Synchronization

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

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

81
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
82
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
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
whenEngineering
BCF has
more
than one E1/T1 available for Abis interface).
Packet (e.g.
Abis / Network
/ March
2010

83
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).

84

Parameter
object: BCF
range: 0, 1:
0 = NO SHAPING
1 = SHAPING COMMITTED
MML abbreviated name: ULTS
=> cf. Slide228 for Element Manager

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

Parameter
object: BCF
range: 100250000 step: 100
default: - unit: kbps
MML command: EFM, EFO
MML abbreviated name: ULCIR

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

Parameter
object: BCF
range: 065535 step: default: 1522 unit: octet
MML abbreviated name: ULCBS

87
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 / 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-20% greater CBS than that related
directly to CIR).
Besides, a common sense rules must be applied, i.e.
- burst size must be greater than (or equal to) biggest possible ETH frame,
- burst size must be smaller than RX buffer in the next hop (and if several sources, e.g.
BTSs or system modules, are connected to the same buffer, this must be taken into account
as well; for instance assuming burst size of Ethernet service as of 100 kB and 3
independent GSM system modules connected with similar TRX configurations lead to CBS
of 100 / 3 = ~33 kB); certainly, it makes sense to scale CBS to the actual needs, especially
if various technologies with different burst size potential are mixed up within a single
UNI/service

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

88
U-/C-/M-plane mechanisms (1/7)
U-plane: CS mux
Parameter
Description
object: BCF
range: 2, 4, 6 step: default: 2 unit: msec
MML abbreviated name: MEMWT
Maximum ETP multiplexing wait time (maxEtpMultiplexingWaitTime), this parameter

allows to control CS multiplexing at BSC side. The parameter defines:
- how much the ETP must delay beginning of reconstruction of the TDMA structure to put all
bundled CS calls in (in UL),
- how much the ETP may delay forming of CS U-plane packets (due to putting several calls
into the same packet) to guarantee that BCF correctly interpret the transmitted payload and
properly build TDMA structure to meet radio interface needs (in DL).
The available values correspond to duration timeslots in TDMA frame in the following way:
MEMWT = 2, 4, 6 corresponds to 2, 4, 8 RTSL, respectively.
Please see below for counterpart at BCF side (MBMWT) and refer to Slide36 (and
successive ones up to Slide41) for further details.
object: BCF
range: 2, 4, 8 step: default: 2 unit: RTSL
MML command: EFC, EFM, EFO
MML abbreviated name: MBMWT
Maximum BTS multiplexing wait time (maxBtsMultiplexingWaitTime), this parameter

allows to control CS multiplexing at BCF side. It is a BCF counterpart of MEMWT explained
above.
The parameter defines how many RTSLs should be observed to collect CS calls which are
subject to bundling.
Refer to Slide36 (and successive ones up to Slide41) for further details.
object: BCF
range: 1601500 step: 10
default: 300 unit: octet
MML abbreviated name: MMPS
Maximum multiplexing packet size (maximumMultiplexingPacketSize), this parameter

allows to define the maximum size of the packet carrying bundled CS calls.
For consideration on the parameters impact on bandwidth savings please refer to Slide36
(and successive ones up to Slide41).
Besides, keep in mind that (in case of Packet Abis over Ethernet) MMPS should not be
greater than Ethernet MTU size (cf. previous slide) otherwise IP fragmentation occurs (and
IP fragmentation is not desired effect as it can cause increase in overall packet loss rate
when particular fragments encounter packet loss and the packet reassembly procedure fails
due to lack
recovery
from the/ March
loss2010
of a single fragment).
Packetof
Abis

89
U-plane: supervision mechanism

Parameter
Description
class: PABTRS
range: 50010000 step: 100
default: 2000 unit: msec
(BTS parameter)
CS U-plane supervision packets timer (ucsSupervisionPktTimerValue), this parameter

is used to define the time interval between transmission of subsequent control packets for
CS U-plane.
For details about U-plane supervision mechanism please refer to here. Note that setting of
this parameter to a special value of 0 disables CS U-plane supervision.
class: PABTRS
range: 50010000 step: 100
(BTS parameter)
PS U-plane supervision packets timer (upsSupervisionPktTimerValue), this parameter

is used to define the time interval between transmission of subsequent control packets for
PS U-plane.
For details about U-plane supervision mechanism please refer to here. Note that setting of
this parameter to a special value of 0 disables PS U-plane supervision.

90
C-/M-plane: SCTP procedures (1/4)

Parameter
Description
object: LAPD
range: 03:
0 = NOT DEFINED (i.e. user defined)
1 = PACKET ABIS FAST
2 = PACKET ABIS MEDIUM
3 = PACKET ABIS OVER SATELLITE
step: 1 default: 1 unit: (BTS parameter)
SCTP parameter set, this parameter can be used to simplify and speed up configuration of
SCTP procedures. It allows to select one of three predefined SCTP parameters sets. The
selected set will be then loaded automatically and used by the system. Besides, it is also
possible to define customer specific SCTP parameter set (when none of predefined sets fits
to the particular network) and in such case the parameter should be set to 0 and all SCTP
related parameters (described below) must be defined. The following values of SCTP
related parameters are invoked when predefined parameter set is chosen:

91
SCTP parameter set:
1 (fast)
2 (medium)
3 (satellite)
SCTP.bundling:
enabled
enabled
enabled
RTO.min
150 msec
300 msec
750 msec
RTO.max
400 msec
750 msec
2000 msec
RTO.init
200 msec
500 msec
1000 msec
SACK.period
120 msec
200 msec
200 msec
path.max.retrans
HB.interval
1000 msec
1000 msec
1000 msec
association.max.retrans

Parameter
Description
class: SCTP
range: 0 (DISABLED), 1 (ENABLED)
step: - default: 1 unit: (BTS parameter)
SCTP bundling (bundlingEnabled), this parameter allows to indicate whether bundling of

SCTP chunks is enabled or not.
Note: the parameter is only meaningful when SCTP parameter set (cf. previous slide) is
equal 0.
In small BTS configuration it is recommend to disable SCTP bundling to reduce the impact of
the delay to the signaling plane. Only the TRXSIG SCTP associations need to be modified.
The following guideline can be applied to select the small BTS configuration: sites with
maximum utilization of 90% of a configured CIR (Committed Information Rate) less than
2 Mbits/s can run with disabled SCTP bundling on signaling plane.
class: SCTP
range: 1020000 step: 10
(BTS parameter)
Minimum retransmission timeout (minRto), this parameter is used to define the minimum
retransmission timeout (RTO.min) needed for SCTP acknowledgment procedure and
liveliness detection (SCTP heartbeat procedure). Refer to Slide60 and Slide61, respectively
for further information about parameter meaning.
Note: the parameter is only meaningful when SCTP parameter set is equal 0.
class: SCTP
range: 1020000 step: 10
(BTS parameter)
Maximum retransmission timeout (maxRto), this parameter is used to define the maximum
retransmission timeout (RTO.max) needed for SCTP acknowledgment procedure and
class: SCTP
range: 1020000 step: 10
(BTS parameter)
Initial retransmission timeout (initRto), this parameter is used to define the initial
retransmission timeout (RTO.init) needed for SCTP acknowledgment procedure and

92

Parameter
Description
class: SCTP
(BTS parameter)
Selective acknowledgment period (periodSack), this parameter is used to define the

selective acknowledgment period (SACK.period) which is a timer defining time interval within
which the SCTP acknowledgment messages are generated. It is only relevant for SCTP
acknowledgment procedure. Refer to Slide60 for further information about parameter
meaning.
class: SCTP
range: 15 step: 1
Maximum retransmission path (maxRetransPath), this parameter is used to define the

maximum number of tried retransmissions per message per destination (path.max.retrans).
Lack of acknowledgement after expiry of retransmission timeout after the last path
retransmission leads to termination of ongoing connection. It is only relevant for SCTP
acknowledgment procedure. Refer to Slide60 for further information about parameter
meaning.

93

Parameter
Description
class: SCTP
range: 10300000 step: 10
(BTS parameter)
Heartbeat interval (hbInterval), this parameter is used to define the heartbeat interval
(HB.interval) which is a timer defining for how long no signalling message is sent to given
address to trigger transmission of SCTP heartbeat message verifying each idle remote
endpoint (i.e. to check if the port is reachable but indeed simply idle or the port does not
respond due to failure).
The parameter is only relevant for C- and M-plane liveliness detection (SCTP heartbeat
procedure). Refer to Slide61 for further information about parameter meaning.
class: SCTP
range: 110 step: 1
Maximum retransmission association (maxRetransAssoc), this parameter is used to

define the maximum number of consecutive retransmissions of heartbeat messages to
a port that sends no response. Lack of heartbeat acknowledgement after expiry of
retransmission timeout after the last retransmission leads to declaration of port unavailability
and closes the association.
The parameter is only relevant for C- and M-plane liveliness detection (SCTP heartbeat
procedure). Refer to Slide61 for further information about parameter meaning.

94
C-/M-plane: IUA procedure

Parameter
Description
class: SCTP
range: 25 step: 1
default: 2 unit: sec
(BTS parameter)
IUA acknowledge timer (ackTimerIua), this parameter is used to define the value for IUA
acknowledgment timer (T(ack)).
IUA acknowledgement timer is started when a message is sent. If IUA server does not
receive a response to the transmitted message within T(ack) notification actions will start to
indicate the problem.

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

96
Drop periods
Parameter
Description
object: BSC
range: 0100 step: 1
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.

97
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

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

99
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.
Note that
BU2 must be greater than BU1.
Backhaul Utilization (3/3): filtering timers

Parameter
Description
object: BSC
range: 1300 step: 1
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

100
Packet Loss (1/3): severity thresholds

Parameter
object: BCF
range: 132 step: 1
MML abbreviated name: PL1

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

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

103
QoS mapping (1/10)

Layer 3
combination of IP DiffServ and traffic scheduling is used
IP DiffServ
each packet is placed into one of predefined traffic classes

each router is configured to differentiate traffic based on its class
each traffic class can be managed differently and gets appropriate treatment based on its PHB
the PHB is indicated by encoding a value called the Differentiated Services Code Point (DSCP)
put into the Type Of Service (TOS) field of the IP packet header (6 LSB out of 8 bits are in use)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
6 various DSCP are available in Packet Abis:
Version
IHL
DiffServ (TOS)
Total Length
Identification
Flags
Fragment Offset
Expedited Forwarding (EF)
Time to Live
Protocol
Header Checksum
Source Address
4 Assured Forwarding (AF41 AF11)
Destination Address
Best Effort (BE)
traffic scheduling
Packet Abis scheduler has six FIFO queues,
each one corresponds to a different PHB
a traffic sent to the EF queue is handled with
the highest priority in the strict priority (SP) queue
a traffic sent to the remaining PHB is handled in
Weighted Fair Queuing (WFQ) with configurable
104
Nokia Siemens
Networks per queue
weights
QoS mapping (2/10)
Overview on QoS concept in Packet Abis (ETH layer)
Layer 2
combination of VLAN tagging and Ethernet traffic prioritization is used
VLAN tagging (IEEE802.1q)
VLAN tagging is used to create independent logical networks within a physical network, e.g. to
support different QoS (different packet treatment can be ensured in interconnecting switches for
different VLAN IDs, e.g. forwarding through alternative paths/ports where e.g. different bw is
assured)
2 different VLAN IDs are supported by BCF in RG20 (to separate M-plane from the rest of the
traffic): in RG20 achievement of full traffic separation by means of VLAN tagging is not possible
as it is left for future releases (VLAN differentiation for Packet Abis traffic is candidate for
RG30EP1)
traffic prioritization (IEEE802.1p)

traffic classes associated with different PHB can be additionally prioritized using Ethernet p-bits
8 priority levels are configurable however as many as 6 are needed to fully distinguish between
available PHB
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
C
TPID
PCP
F
VLAN ID
I
VLAN ID and PCP (Priority Code Point)

are configurable and mapped to VLAN header
Layer 2/3
PCP allows mapping PHB between L2/L3 for Packet Abis over PSN
mapping between PHB to L2 is also possible in case of Packet Abis over TDM:

105
QoS mapping (3/10)
L3: mapping of traffic types to IP DiffServ (1/2)

Parameter
Description
object: BSC
range: BE (0), AF11 (10), AF21 (18),
AF31 (26), AF41 (34), EF (46)
default: 34 unit: MML command: EEY, EEO
MML abbreviated name: AUCS
Abis U-plane CS to DSCP mapping (tmAbisUplaneCs), this parameter allows to map CS

U-plane packets (including control packets used to CS U-plane supervision) to PHB.
The setting of the parameter is mapped to a 8-bit ToS field in IP packet header. 6 least
significant bits are used for encoding of DiffServ Code Points (DSCP). Even though these 6
bits would allow for 26 = 64 different encodings only 6 of them are allowed for Packet Abis.
These are:
- 101110 = 46 => Expedited Forwarding (EF)
- 100010 = 34 => Assured Forwarding class 41 (AF41)
- 000000 = 0 => Best Effort (BE)
object: BSC
range: BE (0), AF11 (10), AF21 (18),
AF31 (26), AF41 (34), EF (46)
MML abbreviated name: AUPS
Abis U-plane PS to DSCP mapping (tmAbisUplanePs), this parameter allows to map PS

U-plane packets (including control packets used to PS U-plane supervision) to PHB.
object: BSC
range: BE (0), AF11 (10), AF21 (18),
AF31 (26), AF41 (34), EF (46)
MML abbreviated name: ACP
Abis C-plane to DSCP mapping (tmAbisCplane), this parameter allows to map C-plane
packets to PHB.

106
QoS mapping (4/10)
L3: mapping of traffic types to IP DiffServ (2/2)

Parameter
Description
object: BSC
range: BE (0), AF11 (10), AF21 (18),
AF31 (26), AF41 (34), EF (46)
MML abbreviated name: AMP
Abis M-plane to DSCP mapping (tmAbisMplane), this parameter allows to map M-plane
packets to PHB.
object: BSC
range: BE (0), AF11 (10), AF21 (18),
AF31 (26), AF41 (34), EF (46)
MML abbreviated name: CLKS
Clock sync to DSCP mapping (tmClockSync), this parameter allows to map timing
packets to PHB.
The parameter is shown here only for the sake of completeness. Please refer to the slideset
dedicated for Synchronization Methods in Packet Abis for further information.
object: BSC
range: BE (0), AF11 (10), AF21 (18),
AF31 (26), AF41 (34), EF (46)
MML abbreviated name: SS
Site support traffic to DSCP mapping (tmSiteSupport), this parameter allows to map to
PHB the packets carrying traffic exchanged with site support equipment (like e.g. site power
control equipment) having its own IP management server which is not integrated with
NetAct.
In such case, a traffic from a server is forwarded to BSC site where it is mapped to chosen
IP DiffServ class and forwarded to BTS site using Packet Abis. BTS switches the traffic to
the site support equipment connected to one of its Ethernet ports.

107
QoS mapping (5/10)
L3: Traffic scheduling

Parameter
Description
object: BSC
MML abbreviated name: AF4WFQ
TS AF4 WFQ weight (tsAf4Wfq), this parameter allows to define a weight for a traffic scheduler queue
where packets assigned to the Assured Forwarding class 4 (AF41) are stored. (=> cf. Slide228 for Element
Manager)
object: BSC
Manager)
object: BSC
Manager)
object: BSC
Manager)
object: BSC
MML abbreviated name: BEWFQ
TS BE WFQ weight (tsBeWfq), this parameter allows to define a weight for a traffic scheduler queue where
packets assigned to the Best Effort class (BE) are stored. (=> cf. Slide228 for Element Manager)
GSM scheduler offers 1SP+5WFQ queues:

- packets from SP queue are served until the queue is empty (regardless on amount of packets stored in the remaining queues)
when SP is empty then WFQ queues are served based on their weights (defined by parameters above):
--- in WFQ, the weights assigned per queue, determine directly the bandwidth share between queues (unlike in WRR where weights define the share in terms of
subsequently sent packets, i.e. length of packets may lead to unfair/unexpected bandwidth share)
108
BW
= (BW
BW ) x Wi / (W)

WFQi
CIR
EF
QoS mapping (6/10)
L2: mapping of traffic types to VLAN ID

Parameter
class: PABTRS
default: 4095 unit: MML abbreviated name: CUPVID
class: PABTRS
default: 4095 unit: MML abbreviated name: MPVID

109
Description
C-plane VLAN identifier (cPlaneVlanId), this parameter allows to map C-plane and Uplane and timing (S-plane) packets (including control packets used to U-plane supervision)
to VLAN ID.
BCF supports in RG20 only two different VLANs. In current implementation M-plane can
have its own VLAN ID and the remaining planes must be in one common VLAN ID.
The setting of the parameter is mapped to a 12-bit VID field in Ethernet header specifying
the VLAN which the frame belongs to. There are two specific values of VID reserved for
management of VLAN tagging:
- a value of 0 means that the frame doesn't belong to any VLAN: in Packet Abis it is not
used at BSC side;
- a value of FFF(hex)=4095 is reserved for implementation use: in Packet Abis it means that
VLAN tagging is disabled.
All other values may be used as VLAN identifiers, allowing up to 2 12 2 = 4094 VLAN
codes. However, only 2 of them can be used in RG20 within a particular BCF (of course,
different VIDs can be set for different BTS sites and so several VLAN IDs are possible
within the BSC).
BTS M-plane VLAN ID (mPlaneVlanId), this parameter allows to map M-plane packets to
VLAN ID.
Please note the remarks above, these are also relevant for MPVID.
QoS mapping (7/10)
L3/L2: mapping between IP DiffServ and MC-PPP (TDM)

Parameter
Description
object: BSC
range: 03:
0 (00) = BEST EFFORT
1 (01) = ASSURED FORWARDING 1-3
2 (10) = ASSURED FORWARDING 4
3 (11) = EXPEDITED FORWARDING
MML abbreviated name: MCBE
MC-PPP Best Effort (mcpppBestEffort), this parameter is used to define MC-PPP class
(i.e. in L2) for best effort packets (i.e. those marked with BE PHB in L3).
When Packet Abis over TDM is in use and QoS is to be controlled by layer 2 then it is
required to reflect PHB definitions done for packets conveying traffic related to particular
planes into MC-PPP protocol classes. There are 2 bits available for MC-PPP class encoding
(where 00 denotes the lowest priority) and thus L3 DSCP encodings can be mapped to 1
out of 4 MC-PPP classes even though we have 6 various DSCP defined (corresponding to
every PHB defined for IP layer i.e. BE, AF11, AF21, AF31, AF41, EF).
object: BSC
range: 0..3
MML abbreviated name: MCAFC1
MC-PPP Assured Forwarding class 1 (mcpppAssuredForwardingClass1), this

parameter is used to define MC-PPP class (i.e. in L2) for AF class 1 packets (i.e. those
marked with AF11 PHB in L3).
Please see above (bestEffort parameter) for additional remarks and for the exact coding of
range of the parameter.
object: BSC
range: 0..3

object: BSC
range: 0..3


110
QoS mapping (8/10)
L3/L2: mapping between IP DiffServ and MC-PPP (TDM)

Parameter
Description
object: BSC
range: 0..3

Please see previous slide (bestEffort parameter) for additional remarks and for the exact
coding of range of the parameter.
object: BSC
range: 0..3
MML abbreviated name: MCEF
MC-PPP Expedited Forwarding (mcpppExpeditedForwarding), this parameter is used to

define MC-PPP class (i.e. in L2) for expedited forwarding packets (i.e. those marked with EF
PHB in L3).
Please see previous slide (bestEffort parameter) for additional remarks and for the exact
coding of range of the parameter.

111
QoS mapping (9/10)
L3/L2: mapping between IP DiffServ and VLAN p-bits (PSN)

Parameter
Description
object: BSC
range: 06 step: 1
MML abbreviated name: VPBE
VLAN priority BE (vpBe), this parameter is used to define VLAN priorities (i.e. p-bits in L2)
for best effort packets (i.e. those marked with BE PHB in L3).
When Packet Abis over PSN is in use and QoS is to be controlled by layer 2 then it is
required to reflect PHB definitions done for packets conveying traffic related to particular
planes into VLAN priorities (often referred to as p-bits).
The setting of the parameter is mapped to a 3-bit PCP (Priority Code Point) field in VLAN
header which refers to the IEEE 802.1p priority and indicates explicitly the frame priority.
These 3 bits allow for 23 = 8 different encodings from 0 (lowest) to 7 (highest); value 7 is
forbidden in RG20.
Anyway this is more than enough to completely reflect L3 QoS handling also in L2 switched
network since it is still possible to distinguish between all 6 DSCP defined (corresponding to
every PHB defined for IP layer i.e. BE, AF11, AF21, AF31, AF41, EF).
At BTS side, similar mapping can be done in BTS element manager (=> Slide227).
object: BSC
range: 06 step: 1
MML abbreviated name: VPAF1
VLAN priority AF1 (vpAf1), this parameter is used to define VLAN priorities (i.e. p-bits in
L2) for AF class 1 packets (i.e. those marked with AF11 PHB in L3).
Please see above (vpBe parameter) for additional remarks which are also relevant for this
parameter.
object: BSC
range: 06 step: 1
Please see above (vpBe parameter) for additional remarks which are also relevant for this
parameter.

112
QoS mapping (10/10)
L3/L2: mapping between IP DiffServ and VLAN p-bits (PSN)

Parameter
Description
object: BSC
range: 06 step: 1
Please see previous slide (vpBe parameter) for additional remarks which are also relevant
for this parameter.
object: BSC
range: 06 step: 1
for this parameter.
object: BSC
range: 06 step: 1
MML abbreviated name: VPEF
VLAN priority EF (vpEf), this parameter is used to define VLAN priorities (i.e. p-bits in L2)
for expedited forwarding packets (i.e. those marked with EF PHB in L3).
for this parameter.

113
Addressing (1/8)
Overview on IP addressing concept in Packet Abis

BTS side
2 IP addresses needed: one for M-plane and another one for C/U-planes
the configuration of the same (single) IP address for all planes (M/U/C) is possible too
BSC side
4 groups of IP addresses needed (each plane may have its own address)
2 different addresses per each BCSU (one for M-plane and another for C-plane)
1 address per each ETP (for U-plane; in RG20 the same address is shared by CS and PS)
apart from IP addresses UDP ports (at U-plane) and SCTP ports (at M-/C-plane)
definitions are required to differentiate CS/PS (RTSL) and TRXSIG/OMUSIG flows
call and LAPD message differentiation is done on the higher layer i.e. RTP and IUA, respectively
Network Gateways
IP packet transmitted between BSC and BTS needs IP gateway if the packet destination is
not in theBTS
same subnet with source
Network Gateway
M-plane
C/U-plane
BSC
Network Gateway
M-plane
C/U-plane
Note:
to notes
(cf. CR131)
114 refer
Nokia
Siemens page
Networksfor addressing restrictions
CS U-plane
PS U-plane
C-plane
M-plane
CS U-plane (ETP)
PS U-plane (ETP)
C-plane (BCSU)
M-plane (BCSU)
Addressing (2/8)
BSC side: BTS IP addresses and lengths of subnet masks

Parameter
Description
object: BCF
range: #.#.#.# with # within 0255
default: - unit: MML command: EFO, EFC, EFM
MML abbreviated name: BMIP
BTS M-plane IP address (btsMPlaneIpAddress), this parameter is used to define IP

address for M-plane packets at BTS site.
This address uniquely identifes an endpoint for M-plane termination at BTS side so is used by
BSC (and intermediate nodes) as destination address for M-plane packets towards the BTS.
Note: it is equal to mPlaneLocalIpAddress defined (via SCF) in corresponding BTS.
object: BCF
MML abbreviated name: BCUIP
BTS C/U-plane IP address (btsCuPlaneIpAddress), this parameter is used to define IP

address for C-plane and U-plane packets at BTS site.
This address uniquely identifes an endpoint for C-plane and U-planes termination at BTS side
so is used by BSC (and intermediate nodes) as destination address for C-plane and U-planes
packets towards the BTS.
Note: In RG20 a BTS can be configured with the same (single) IP address and subnet mask
for all planes (M/U/C) or with separate addressing for M-plane and C/U-planes.
object: BCF
range: 032 step: 1
MML abbreviated name: SMMP
BTS IPv4 IP subnet mask length for M-plane (btsIpv4SubnetMaskLengthMplane), this

parameter is used to define IP subnet mask length for M-plane at BTS site.
Note that CIDR (Classless Inter-Domain Routing) methodology of subnet definition is used
rather than traditional one which is based on 32 bits in four-part dotted-decimal format. Please
refer to backup part for more information about CIDR. For instance:
- subnet mask = 32 corresponds to 255.255.255.255
- subnet mask = 29 corresponds to 255.255.255.248 etc.
object: BCF
range: 032 step: 1 default: - unit: MML command: EFO, EFC, EFM
abbreviated
ForMML
internal
use only name: SMCUP
cf. Slide232
forSiemens
ElementNetworks
Manager
115
Nokia
BTS IPv4 subnet mask length for C/U-plane (btsIpv4SubnetMaskLengthCUplane), this

parameter is used to define IP subnet mask length for C-plane and U-plane at BTS site.
Addressing (3/8)
BSC side: GW IP addresses

Parameter
Description
object: BCF
default: - unit: MML command:
MML abbreviated name:
BTS M-plane IP gateway address (btsMplaneGatewayIPAddress), this parameter is

used to define IP gateway address for M-plane packets at BTS site.
Note: this gateway is only needed when BTS where the packets are sent to (i.e. destination
endpoint) is not in the same subnet with the BSC, i.e. transport network is a routed
backhaul (L3 network).
object: BCF
default: - unit: MML command:
BTS C/U-plane IP gateway address (btsCuPlaneGatewayIPAddress), this parameter is

used to define IP gateway address for C-plane and U-plane packets at BTS site.
Note: this gateway is only needed when BTS where the packets are sent to (i.e. destination
endpoint) is not in the same subnet with the BSC, i.e. transport network is a routed
backhaul (L3 network).

116
Addressing (4/8)
BTS side: BSC IP addresses

Parameter
Description
object: PABTRS
default: - unit: cf. Slide232 for Element Manager
BSC M-plane IP address (mPlaneRemoteIpAddress), this parameter is used to define IP address for Mplane packets at BSC. This address uniquely identifes an M-plane termination point at BSC so is used by
associated BTSs (and intermediate nodes) as a destination address for M-plane traffic forwarded to the
BSC. Regardless of physical realization of Packet Abis the parameter indicates IP address to BCSU unit
associated with the BTS site (BCF).
Note that, in case of Packet Abis over TDM, due to termination of physical interface in ETS2/ETPT, the
ETP unit associated with the BTS site (BCF) is involved in forwarding of M-plane towards its actual
destination which is anyway the addressed BCSU.
object: PABTRS
BSC C-plane IP address (cPlaneIpAddress), this parameter is used to define IP address for C-plane
packets at BSC.This address uniquely identifes a C-plane termination point at BSC so is used by
associated BTSs (and intermediate nodes) as a destination address for C-plane traffic forwarded to the
BSC. Since TRXSIGs associated with a single BCF can be distributed over several BCSUs, each TRXSIG
can have its endpoint in a different BSC C-plane IP address. Regardless of physical realization of Packet
Abis the parameter indicates IP address to BCSU unit associated with the BTS site (BCF).
Note that, in case of Packet Abis over TDM, due to termination of physical interface in ETS2/ETPT, the
ETP unit associated with the BTS site (BCF) is involved in forwarding of C-plane towards its actual
destination which is anyway the addressed BCSU.
object: PABTRS
BSC CS U-plane IP address (uCsPlaneIpAddress), this parameter is used to define IP address for CS
U-plane packets at BSC. This address uniquely identifes a CS U-plane termination point at BSC so is used
by associated BTSs (and intermediate nodes) as a destination address for CS U-plane traffic forwarded to
the BSC. Regardless of physical realization of Packet Abis the parameter always indicates IP address to
ETP unit.
Note that in RG20 the same IP address must be used by CS and PS U-plane.
object: PABTRS
BSC PS U-plane IP address (uPsPlaneIpAddress), this parameter is used to define IP address for PS
U-plane packets at BSC. This address uniquely identifes a PS U-plane termination point at BSC so is used
by associated BTSs (and intermediate nodes) as a destination address for PS U-plane traffic forwarded to
the BSC. Regardless of physical realization of Packet Abis the parameter always indicates IP address to
ETP unit.
Note that in RG20 the same IP address must be used by CS and PS U-plane.

117
Addressing (5/8)
BTS side: lengths of subnet masks

Parameter
Description
object: PABTRS
range: 032 step: 1
BSC M-plane IP subnet mask length (mPlaneSubnetMask), this parameter is used to

define IP subnet mask length for M-plane packets at BSC.
Note that CIDR (Classless Inter-Domain Routing) methodology of subnet definition is used
rather than traditional one which is based on 32 bits in four-part dotted-decimal format.
Please refer to backup part for more information about CIDR.
object: PABTRS
range: 032 step: 1
BSC C-plane IP subnet mask length, this parameter is used to define IP subnet mask
length for C-plane packets at BSC.
object: PABTRS
range: 032 step: 1
BSC CS U-plane IP subnet mask length, this parameter is used to define IP subnet mask
length for CS U-plane packets at BSC.
Note that in RG20 the same IP address must be used by CS and PS U-plane so IP subnet
mask must be also identical.
object: PABTRS
range: 032 step: 1
BSC PS U-plane IP subnet mask length, this parameter is used to define IP subnet mask
length for PS U-plane packets at BSC.
Note that in RG20 the same IP address must be used by CS and PS U-plane so IP subnet
mask must be also identical.

118
Addressing (6/8)
BTS side: GW IP addresses

Parameter
Description
object: PABTRS
BSC M-plane IP gateway address (mPlaneGatewayIpAddress), if the M-plane

destination (BCSU) IP address belongs to another subnet, this parameter specifies the
address of IP gateway that is used to route the M-plane traffic to the actual destination.
object: PABTRS
BSC C-plane IP gateway address (cuPlaneGatewayIpAddress), if the C-plane

destination (BCSU) IP address belongs to another subnet, this parameter specifies the
address of IP gateway that is used to route the C-plane traffic to the actual destination.
object: PABTRS
object: PABTRS

119
BSC CS U-plane IP gateway address, if the CS U-plane destination (ETP) IP address

belongs to another subnet, this parameter specifies the address of IP gateway that is used
to route the CS U-plane traffic to the actual destination.
Notes:
- in RG20 the same IP address must be used by CS and PS U-plane and this also holds for
relevant gateway addresses,
- in RG20 Element Manager has just one entry for C- and CS/PS U-plane gateway that is
cuPlaneGatewayIpAddress
BSC PS U-plane IP gateway address, if the PS U-plane destination (ETP) IP address
belongs to another subnet, this parameter specifies the address of IP gateway that is used
to route the PS U-plane traffic to the actual destination.
See notes above concerning CS U-plane traffic, they both hold also for PS U-plane.
Addressing (7/8)
BSC side: UDP MUX ports

Parameter
Description
object: BCF
range: 4915265534 step: 2
default: 49152 unit: MML command: EEY, EEO, EFO
MML abbreviated name: CSUMP
CS UDP MUX port (usedCsUdpMuxPort), this parameter allows to define UDP port
number which is used to terminate CS U-plane flows.
Flows related to both TCH traffic (U-plane) as well as TRXSIG/OMUSIG (C/M-plane) must
be differentiated above IP layer (i.e. at UDP layer for U-plane and at SCTP layer for C/Mplanes). Basically each RTSL should have 4 (to handle OSC-DHR calls) dedicated UDP
ports defined to terminate all potential U-plane flows associated with the RTSL. Such setup
would however lead to extremely complex addressing scheme (e.g. just 1 TRX would
required as many as 32 UDP ports defined). Therefore (so-called) UDP MUX ports are
introduced where all CS/PS U-plane related flows incoming from BTS site connected to the
BSC are directed to. Then further processing/routing is based on included indication of BTS,
TRX, RTSL and subchannel the connection (call) is related to.
object: BCF
range: 4915265534 step: 2
default: 49152 unit: MML command: EEY, EEO, EFO
MML abbreviated name: PSUMP
PS UDP MUX port (usedPsUdpMuxPort), this parameter allows to define UDP port
number which is used to terminate PS U-plane flows.
See above (parameter csUdpMuxPort) for further info about UDP MUX concept.
Recommendation (CR204): the configured value for PS UDP MUX ports shall be different to
CS UDP MUX port (as well as different to all other UDP ports reserved for other purposes,
e.g. traceroute).

120
Addressing (8/8)
BSC/BTS side: SCTP ports

Parameter
Description
class: SCTP
range: 4915265534 step: 2
default: 49152 unit: MML command: EEY, EEO, OYP
Minimum SCTP port (minSctpPort), this parameter allows to indicate the number of the first
(called minimum) SCTP port which is used to terminate C/M-plane flows related to given SCTP
association (SCTP association corresponds to Abis LAPD link in Legacy Abis).
For signalling traffic, unlike U-plane where all flows (calls) associated with the BTS site are
directed to the same port (see previous slide), each TRX association (i.e. TRXSIG flows) and
BCF one (i.e. OMUSIG flows) needs to have its own SCTP port defined. However, to avoid too
complex SCTP addressing scheme (i.e. manual definition of several ports for each site would be
needed, i.e. the more TRXs per site, the more complex addressing scheme) some automization
of this process is introduced: SCTP port numbers are sequentially allocated to each flow
associated with the BTS site (i.e. all TRXSIG and OMUSIG related flows) starting from a
minSctpPort as follows:
- OMUSIG association: minSctpPort
- TRXSIG association: minSctpPort + i, where i=TRX ID
Note that each TRXSIG SCTP association carries two streams per direction: the stream identifier
2 is used for transferring Measurement Report messages whereas the remaining messages (i.e.
telecom) are transferred with stream identifier 1.
OMUSIG SCTP association is in stream 0. SCTP assigns stream ID automatically.
Refer to backup for detailed TRXSIG configuration example incl. MML and related parameters.
The commands below must be rewritten for each OMUSIG and TRXSIG
every SCTP association (identifed by SCTPID) is mapped to SCTP port as well as to C- or M-plane addresses for TRXSIG and OMUSIG, respectively:
Packet Abis:
ZOYP:IUA:<SCTPID>:<source IP address>,<source port>:<destination IP address>,<destination port>;
<source port> = <destination port> but SCTP ports must be unique in BTS =>
OMUSIG port = minSctpPort

TRXSIG(i) port = minSctpPort + i =>
in DB / BTS Element Manager: only minSctpPort

in ZOYP / BSC MML: proper source/destination ports
Next, every SCTP association (corresponding to D-channel in Legacy Abis) is mapped to OMUSIG or to particular TRXSIGs (and BCSU):
Packet Abis:
ZDWP:<D-channel name>:BCSU,<unit index>:<SAPI>,<TEI>:<SCTPID>,<STREAMID>;
Legacy Abis:
ZDSE:<D-channel name>:BCSU,<unit index>:<SAPI>,<TEI>:<bitrate>,<PCMID-TSL>,<SUB-TSL>;

121
Miscellaneous (1/4)
New PCU resources (DSP) allocation algorithm

Parameter
Description
object: BTS
default: 80 unit: %
MML command: EQV, EQO
MML abbreviated name: GCTF
GPRS capacity throughput factor (gprsCapacityThroughputFactor), this parameter

allows to define throughput factor in a EGPRS cell.
This is a new parameter which is required by DSP allocation algorithm in PCU when Packet
Abis is in use. For that purpose the GPRS capacity throughput factor (GCTF) is introduced
to distinguish between cells where only connectivity shall be guaranteed (GCTF set to low
value) and those where high throughput is expected (GCTF set to high values). Such
differentiation is necessary to optimize DSP allocation at system start-up (and after reconfiguration) as well as for optimum hunting of idle DSP resources during territory
upgrades. For legacy systems (i.e. with Dynamic Abis) a trade-off between connectivity cells
and throughput cells is managed by allocation of EDAPs with different size (but in Packet
Abis, due to removal of EDAP concept, a new indicator of cells priorities is needed).
Please refer also to Slide48 Slide53 for further details on PCU resources allocation with
Packet Abis as well as to Slide142 where GCTF planning rules are discussed.
Note that although the parameter is defined in BTS object it must be the same for each
BTSs within a segment (as this is a BTS parameter on segment level).
Enable GPRS:
ZEQV:BTS=1:CDED=1,CDEF=30,CMAX=100,RAC=3,GENA=Y:NSEI=490;,GCTF=80%;
BTS-PCU relation is done stepwise:

-> PCU ID defined in BTS object (no changes due to Packet Abis)
-> BTS-ETP relation is done by means of IP addressing
-> new step: connect PCU to ETP
Connect PCU to ETP:

122
ZESK:ETPGID=2,ETPT=ETP-E,BCSU=0,PCU=4;
Miscellaneous (2/4)
PDV compensation buffer

Parameter
Description
object:
range: 0100000 step: 500
default: 5000 unit: s
MML abbreviated name: PDV
Packet delay variation (packetDelayVariation), this parameter allows to define the

expected packet delay variation (PDV) in the PSN which is then used to evaluate size of the
jitter compensation buffer (often called de-jitter buffer or even more correctly PDV
compensation buffer).
PDV compensation buffer is a shared memory area where incoming packets can be
collected, temporarily stored, and sent to further processing after a time equal to the
expected PDV so that a continuous play-out of the stream transmitted over the network
can be ensured. The maximum PDV that can be counteracted by a compensation buffer is
equal to the delay introduced therein.
Note that PDV compensation buffer introduces static delay (equal to the parameter setting)
which contributes unavoidably to end-to-end delay (so may affect KPIs as a consequence).
For that purpose, packet delay variation (in addition to delay and packet loss rate) is subject
to agreement with owner of PSN (by means of SLA) to guarantee that transport impairments
present in the network can be overcome.

123
Miscellaneous (3/4)
IPSec enabling
Parameter
Description
object: BCF
range: 0, 1:
0 = DISABLED
1 = ENABLED
MML abbreviated name: IPSEC
IPSec enabled (ipSecEnabled), this parameter allows to enable (IPSEC = 1) or disable

(IPSEC = 0) IPSec feature in the BTS.
Enabling of the feature is only possible with Packet Abis over PSN.
Please note that enabling of IPSec leads to greater bandwidth consumption (cf.
dimensioning aspects section).
Please refer to dedicated presentation (
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/D419822673) for more details
about security features for Packet Abis.

124
Miscellaneous (4/4)
ETP overload protection

Parameter
Description
range: 0...100 step: 1

default: 60 unit: %
(PRFIL parameter)
Low overload limit (LOW_OVERLOAD_LIMIT), this parameter is used to define a first

(lower) threshold triggering ETP overload reaction procedures.
If the processing load of ETPx exceeds the LOW_OVERLOAD_LIMIT value then ETPx
rejects new CS calls (except emergency calls) and PS connections. These overload
reaction procedures are stopped when ETP processing load falls below
LOW_OVERLOAD_LIMIT by percentage value defined by setting of LOAD_HYSTERESIS
and is kept within that range for a time longer than TIME_HYSTERESIS.
Note: ETPT/ETPE suports up to 8192 calls, however the simultaneous presence of high PS
traffic may lead to ETP overload. The L&S tests are run to verify ETP CPU capacity: as a
result of these tests further recommendations concerning thresholds related to ETP
overload limits may be given if necessary.

default: 70 unit: %
(PRFIL parameter)
High overload limit (HIGH_OVERLOAD_LIMIT), this parameter is used to define a second

(higher) threshold triggering ETP overload reaction procedures.
If the processing load of ETPx exceeds the HIGH_OVERLOAD_LIMIT value then ETPx
rejects also emergency calls (in addition to CS calls and PS connections) as well as drops
every 10th CS U-plane packet (10%) and every 5th PS U-plane packet (20%). These
overload reaction procedures are stopped when ETP processing load falls below
HIGH_OVERLOAD_LIMIT by percentage value defined by setting of LOAD_HYSTERESIS.
Any TIME_HYSTERESIS is not applied while handling of HIGH_OVERLOAD_LIMIT.

default: 5 unit: %
(PRFIL parameter)
Load hysteresis (LOAD_HYSTERESIS), this parameter defines by what percentage the

ETP processing load must fall below the related overload limit to declare cancellation of the
related overload level and to stop the appropriate reaction procedures.

For(PRFIL
internalparameter)
use only
125
Time hysteresis (TIME_HYSTERESIS), this timer defines how much time ETP overload
must not be active (processing load of ETPx fell below LOW_OVERLOAD_LIMIT
LOAD_HYSTERESIS) to declare cancellation of first overload level and to stop the
appropriate
reaction procedures.

Packet Abis - Internal Workshop

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Packet Abis - Internal Workshop

Uploaded by

Copyright:

Available Formats

For internal use only!!!

For internal use only

Packet Abis / Network Engineering / March 2010

Packet Abis / Network Engineering / March 2010

For internal use only

Packet Abis / Network Engineering / March 2010

For internal use only

Packet Abis / Network Engineering / March 2010

Legacy Abis adequate for handling of voice

For internal use only

Packet Abis / Network Engineering / March 2010

leased E1/T1 lines (e.g. p2p)

TDM line / Ethernet

GERAN transport overview

Packet Abis is a completely new transport concept:

For internal use only

Packet Abis / Network Engineering / March 2010

Packetization brings in a number of effects which contribute to bandwidth savings

Packet Abis over PSN (Abis over IP over Ethernet)

For internal use only

Packet Abis / Network Engineering / March 2010

Both features aim at encapsulation of TDM payload into Ethernet/IP

lack of awareness about content of the frame which is impossible to recognize

For internal use only

new (RG20) HW needed

Bandwidth consumption for

Packet Abis over TDM

none (TSL0 is used)

Packet Abis over PSN

Packet Abis over PSN

Packet Abis over PSN

none (dedicated Eth link is used)

For internal use only

Packet Abis / Network Engineering / March 2010

For internal use only

Packet Abis / Network Engineering / March 2010

FlexiBTS transport sub-modules in RG20:

FIYB/FIQB successors of FIYA/FIQA

4x E1/T1 symmetrical, PWE

(*) FIYB / FIQB:

new transport sub-modules,

introduced in RG10 EP3.1

...with the same features as

RG20 provides support of

go to backupSlide for FIYB/FIQB

OK RG10 EP3.1 MP5

OK RG10 EP3.1 MP5

Packet Abis / Network Engineering / March 2010

Exchange Terminal for Packet transport (ETP)

ETPSIGm: M-plane interface between ETP and BCSU

ETPSIGc: C-plane interface between ETP and BCSU

EEP: CS U-plane interface between ETP-T/E and ETP-A (i.e. TC in MGW)

EU: CS U-plane path

Ref. RS TEAM, Exchange Terminal

Packet Abis / Network Engineering / March 2010

1+1 x GE, PWE

Packet Abis over TDM

Packet Abis over PSN

For internal use only

Packet Abis / Network Engineering / March 2010

Packet Abis over Ethernet

codec X (TC in MGW)

ETH ETPE ETPA ETH

Abis and A interfaces are migrated to native IP