LTE Access Transport Fffdimensioning Guideline

1/63
MBB Customer Support

Network Engineering
Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013
Dimensioning Mobile Access, MBB CS Network Engineering
For internal use only, approved, version 1.0, 09.05.2013
LTE Access Transport

RL10 approved
RL20 / RL15 approved
RL40 approved
Please always check the latest version of this document under the following link: here
2/63

Network Engineering
Revision History
Version
1.0
Date
Change Notes
09.05.2013 Approved version
Authors
Name
Department
Dominik Dulas
MBB CS NetEng Transport
Szymon Listwan
MBB CS NetEng Transport
3/63

Network Engineering
Table of contents
1.1
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.1.6
1.2
1.2.1
1.2.2
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
2.1
2.1.1
2.1.2
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.2.7
LTE Access Network reference model .......................................................... 5

S1_U interface (eNB SAE-GW)................................................................ 8
S1_MME interface (eNB MME) ................................................................ 8
X2_U interface (source eNB target eNB).................................................. 8
X2_C interface (source eNB target eNB).................................................. 8
O&M interface (eNB O&M system) ........................................................... 8
S-Plane interface (eNB Signal Reference Clock) ..................................... 8
Flexi LTE BTS overview ............................................................................... 8
Flexi LTE BTS transport architecture. ........................................................... 9
Flexi LTE BTS transport capacity limits ...................................................... 10
Feature impact to LTE Access dimensioning .............................................. 10
RL10 features ............................................................................................. 11
RL20 / RL15 features ................................................................................. 14
RL30 / RL25 features ................................................................................. 16
RL40 features ............................................................................................. 17
RL50 / RL35 features ................................................................................. 18
LTE Access dimensioning workflow ............................................................ 20
Definition of input parameters ..................................................................... 21
Definition of output parameters ................................................................... 27
LTE Access dimensioning methodology ..................................................... 28
General concept ......................................................................................... 28
U-Plane traffic dimensioning: S1_U and X2_U interfaces ........................... 30
C-Plane dimensioning: S1_MME and X2_C interfaces ............................... 43
O&M I/F dimensioning ................................................................................ 53
S-plane dimensioning ................................................................................. 53
Resulting eNB transport capacity ................................................................ 54
Front mile dimensioning.............................................................................. 55
4/63

Network Engineering
References
[LTE_Transp_SFS]
Josef Singer, LTE Transport SFS, MBB Global LTE
[LTE_Capacity+TM_SFS]
Wolf-Jens Teubert, LTE Capacity plus Traffic Model SFS, MBB

Global LTE
[LTE_Perf_SFS]
Stefan Klein, LTE System Performance SFS, MBB Global LTE
[LTE_TM]
Piotr Godziewski, LTE Traffic Model for Network Dimensioning,

MBB CS Network Engineering
[LTE_Radio_Dim]
Piotr Godziewski, LTE Air Interface Dimensioning Guideline,

MBB CS Network Engineering
[LTE_EPC_Dim]
Ooi Khai Siong, LTE EPC Dimensioning Guideline GS MS NPO

CoC
[MD1]
M. H. A. Davis, J. M. Howl, A Markovian Analysis of the FiniteBuffer M/D/1 Queue, Proceedings: Mathematical, Physical and
Engineering Sciences, Volume 453, Issue 1964, pp. 1947-1962
[MGR-PS]
A. Riedl et al, Investigations of the M/G/R Processor Sharing

Model for Dimensioning of IP Access Networks with IP Traffic,
1st Polish-German Telegraphic Symposium PGTS 2000,
Dresden.
[TS29.281]
3GPP TS 29.281, General Packet Radio System (GPRS)

Tunneling Protocol User Plane (GTPv1-U)
[TS36.413]
3GPP TS 36.413, Evolved Universal Terrestrial Radio Access (EUTRA); S1 Application Protocol (S1AP)
[TS36.423]
3GPP TS 36.423, Evolved Universal Terrestrial Radio Access

Network (E-UTRAN); X2 Application Protocol (X2AP)
[LTE_Transp_+_QoS]
Torsten Musiol, LTE Transport Tutorial, NWS Product

Management
5/63

Network Engineering
1.
Scope of LTE Access Transport dimensioning

LTE Access Transport dimensioning covers the following logical LTE interfaces:
S1_U: User data transport between eNB and S-GW (GTP-U tunneling)
S1_MME: Signaling transport between eNB and MME (S1AP protocol)
X2_U: User data transport between eNB nodes during inter-eNB handovers (GTPU tunneling)
X2_C: Signaling transport between eNB nodes (X2AP protocol)
O&M i/f: Transport of O&M data between eNBs and O&M System
S-Plane i/f: synchronization transport between eNB and the reference clocks
signal according to Timing over Packet (ToP) standard.
The dimensioning framework consists of two deliverables: LTE Access Transport
dimensioning guideline (i.e. this document) and LTE Access Transport dimensioning
tool. The guideline describes the overall dimensioning process and covers all relevant
points important for dimensioning: definition of input and output parameters,
dimensioning workflow and possible limitations coming from the LTE access network
and LTE network elements. The tool facilitates the LTE dimensioning with an
automated dimensioning process, as described in this guideline.
LTE Access Transport dimensioning guideline consists of two parts. First part provides
an overview of the LTE reference architecture and the LTE features having a major
impact to the dimensioning. Second part presents the actual LTE Access Transport
dimensioning concept and methodology. It describes the dimensioning workflow, input
and output parameters and dimensioning formulae.
Two Annexes are available for this document:
Annex A: Dimensioning example. This document consists of two, end-to-end examples
showing the full path of LTE radio access dimensioning. First part focuses on radio
coverage calculations, which is a pre-step for access dimensioning. Second part
describes in details steps needed for access transport network capacity requirement
calculations.
Annex B: Dimensioning models description. This document focuses on details of
analytical models used for access network dimensioning. It describes the assumptions
made and mathematical background for adopted approach.
1.1
LTE Access Network reference model

By convention used in this document, the LTE Access Network provides the
interconnection between Evolved UTRAN (E-UTRAN) and Evolved Packet Core (EPC)
domains, as shown in Figure 1. LTE Access Network reference model provides a logical
representation of the LTE Access Network. It defines functional entities and reference
points over which interoperability between functional entities can be achieved.
Figure 1 shows the LTE Access Network reference architecture. It comprises the
following logical interfaces:
S1_U (eNB SAE-GW),
S1_MME (eNB MME),

Network Engineering
X2_U and X2_C (source eNB target eNB),

O&M i/f (eNB O&M system),
LTE Access Transport dimensioning covers interfaces at the eNB side (last mile) as
well as at the network side (front mile).
Note:
Only S1 interface at the core side is covered. Dimensioning of the

remaining interfaces at the EPC side is out of scope, it is described in
[LTE_EPC_Dim].
Evolved Packet Core
Evolved UTRAN
S1_MME
eNB
X2_C
X2_U
MME
eNB
SAE-GW SAE Gateway

MME Mobility Management Entity
eNB evolved Node B
O&M i/f
Front mile link
S1_U
Last mile link
6/63
SAE-GW
O&M i/f
O&M
Figure 1 LTE Access Network reference architecture
Overview of the LTE Access interfaces for U-Plane, C-Plane and M-Plane, together with
the involved protocol stacks can be seen in Figure 2.
7/63

Network Engineering
LTE U-Plane
eNB 2
eNB 1
SAE-GW
X2-U
S1-U
GTP-U
GTP-U
GTP-U
UDP
UDP
UDP
GTP-U
IP
IP
IP
IP
IPSec (*)
IPSec (*)
IPSec (*)
IPSec (*)
L1/L2
L1/L2
L1/L2
L1/L2
UDP
(*) IPSec is optional
LTE C-Plane
eNB 2
eNB 1
MME
S1-AP
S1-MME
SCTP
X2-AP
SCTP
IP
IP
IPSec (*)
IPSec (*)
L1/L2
L1/L2
eNB 2
eNB 1
X2-C
SCTP
S1-AP
MME
X2-AP
SCTP
IP
IP
IPSec (*)
IPSec (*)
L1/L2
L1/L2
LTE M-Plane
eNB 2
eNB 1
NetAct
O&M i/f
O&M i/f
Mgmt. Appl.
Mgmt. Appl.
UDP/TCP
UDP/TCP
Mgmt. Appl.
IP
IP
IP
IPSec (*)
IPSec (*)
IPSec (*)
L1/L2
L1/L2
L1/L2
UDP/TCP
Figure 2 U-Plane (UP), C-Plane (CP) and M-Plane (MP) protocol stacks in LTE Access.
8/63

Network Engineering
1.1.1
S1_U interface (eNB SAE-GW)

The S1_U interface is used for transport of user data between the eNB and SAE-GW
using GTP-U protocol. Each S1 bearer consists of a pair of GTP-U tunnels (one for
uplink and one for downlink). The eNB performs mapping between Radio Bearer IDs
(RBID) and GTP-U Tunnel Endpoints. The GTP-U protocol is defined in [TS29.281]
and its position in the protocol stack is shown in Figure 2.
1.1.2
S1_MME interface (eNB MME)

The S1_MME interface is used for transferring signaling information between the eNB
and MME using S1-AP protocol [TS36.413]. It is used for S1 bearer management,
mobility and security handling and transport of NAS signaling messages between the
UE and MME. S1_MME protocol stack is shown in Figure 2.
1.1.3
X2_U interface (source eNB target eNB)

The X2_U interface is used for forwarding user data between the source eNB and
target eNB during inter-eNB handovers. A GTP-U tunnel is established across the X2
between the source eNB and the target eNB. Thus the protocol stack is the same as
for S1_U (Figure 2).
1.1.4
X2_C interface (source eNB target eNB)

The X2_C interface is used for transferring signaling information between neighboring
eNBs using the X2-AP protocol [TS36.423]. This signaling is used for handovers and
inter-cell RRM signaling. X2_C protocol stack is shown in Figure 2.
1.1.5
O&M interface (eNB O&M system)

O&M interface is used for transferring M-Plane traffic from the O&M system to the eNB.
M-Plane traffic (messaging and data) can be based on UDP or TCP protocol stacks, as
indicated in Figure 2.
1.1.6
S-Plane interface (eNB Signal Reference Clock)

This is an optional interface used for synchronizing an eNB with the reference clocks
signal according to Timing over Packet (ToP) standard.
1.2
Flexi LTE BTS overview

Flexi LTE BTS is a key network element of the NSN LTE system. It is based on a Flexi
Multiradio BTS platform and provides an interface between the LTE EPC domain and
the LTE radio link. Functionally, it consists of one System Module and up to three RF
Modules as shown in Figure 3. System Module includes the baseband processing,
O&M and synchronization, power distribution and transport functions (TRS). The RF
Module contains the RF functions. As this guideline covers the LTE transport
dimensioning aspects, this section focuses on the transport configuration and capacity
aspects of the LTE BTS.
9/63

Network Engineering
S1, X2
Figure 3 Flexi Multiradio BTS front view and logical diagram.
1.2.1
Flexi LTE BTS transport architecture.

Transport-related functions of Flexi LTE BTS are realized with the transport sub-module
for system modules FSMD, FSME, and FSMF (available from RL40). For FSMF system
module, the transport sub-module is optional and is not needed if Ethernet transport is
used. Transport sub-modules supporting LTE are FTIB, FTLB and FTIF. Transport submodule implements the following transport functions:
Termination of logical S1 and X2 interfaces

Embedded L2 switch supporting the integrated switching between the Ethernet
interfaces of the Flexi LTE BTS (with RL20 / RL15 feature LTE649).
Encryption and Authentication for UP/CP/MP/SP traffic with IPSec.
Transport-Layer QoS: priority marking (L3 DSCP and L2 802.1 p-bits), traffic
shaping and rate limiting.
Ethernet synchronization (SyncE, ToP).
BTS transport configuration and the supported capacity determine the LTE Access
dimensioning process, as described in Sec. 2.2.
10/63

Network Engineering
1.2.2
Flexi LTE BTS transport capacity limits

Flexi LTE BTS capacity-related parameters imposing static limits on S1 and X2
dimensioning are summarized in Table 1.
Table 1 Selected Flexi LTE BTS capacity parameters. Source: [LTE_Perf_SFS],
[LTE_Capacity+TM_SFS] and [LTE_Transp_SFS].
Parameter
Value
Comments
3 (*) (**)
Max. number of cells per BTS
6 (***)
Max. number of active users per BTS cell at

20Mhz
800 (*) RRC_connected

users with a DRB
840 (**) (***) established
Max. number of actively scheduled users per BTS

cell at 20Mhz
Users scheduled in
200 (*) the time domain by
the RRC scheduler;
250 (**) (***) subset of Active
users.
Max eNB transport capacity towards the Core
Number of GbE
interfaces at the eNB
1000 Mbps that can be used
towards the Core is
limited to 1.
(*) for RL10, (**) for RL20 / RL15, (***) for RL30 / RL25 / RL40
1.3
Feature impact to LTE Access dimensioning

This section summarizes the features that have a major impact to the LTE Access
dimensioning (features with negligible impact are omitted). The features are grouped
according to their system releases. The set of relevant features is presented in Figure 4.
11/63

Network Engineering
LTE Transport Feature summary

RL09/RL10
LTE transport protocol stack (LTE664)

Non-GBR QCI 5, 6, 7, 8 and 9 (LTE905)
Trafic prioritization on IP layer (DiffServ)
(LTE131)
Trafic prioritization on Ethernet layer
(LTE129)
LTE IPSec support (LTE689)
Traffic shaping (LTE138)
RL20/RL15
RL30/RL25
Operator specific QCI (LTE518)

Transport admission control (LTE144)
IP Transport network measurements
(LTE574)
Ethernet Jumbo frames (LTE931)
Service differentiation for non-GBR EPS

bearer (LTE009)
Support of EPS bearers for conversional
voice (LTE010)
QoS aware Ethernet switching (LTE649)
Rate capping UL/DL (LTE013)
RL20 Capacity and Dimensioning
(LTE458)
RL40
Support of QCI 2, 3 and 4 (LTE496)

Smart admission control (LTE497)
Multiple GBR EPS bearers per UE
(LTE587)
RL50/RL35
Transport separation for RAN sharing

(LTE505)
Note: Only features impacting the LTE Access Dimensioning are shown.
Figure 4 RL10, RL20 / RL15, RL30 / RL25, RL40, and RL50 / RL35 transport features
affecting LTE Access dimensioning.
1.3.1
RL10 features
1.3.1.1
LTE bearer implementation in RL10

LTE (EPS) bearer uniquely identifies traffic flows that receive a common QoS treatment
between a UE and a PDN GW, as shown in Figure 5. An EPS bearer is the level of
granularity for QoS control in the EPC/E-UTRAN. That is, all traffic mapped to the same
EPS bearer receives the same bearer level packet forwarding treatment (e.g.
scheduling policy, queue management policy, rate shaping policy, RLC configuration,
etc.).
12/63

Network Engineering
E-UTRAN
UE
EPC
eNB
S-GW
Internet
P-GW
Peer
Entity
End-to-end Service
EPS Bearer
E-RAB
Radio Bearer
Radio
External Bearer
S5/S8 Bearer
S1 Bearer
S1
S5/S8
Gi
Figure 5 LTE bearer concept representation. Source: [3GPP 23.401].
LTE bearers are split into 2 types: Guaranteed Bit Rate (GBR) bearers and non-GBR
bearers. Each bearer type is allocated different parameters in terms of supported bit
rates, QoS Class identifier (QCI) and Allocation and Retention Priority (ARP). Another
split of LTE bearers is between default and dedicated bearers:
Default LTE bearer: first bearer being established for UE at connection setup.
Dedicated LTE bearers: bearers established for UE in addition to the default
bearer.
Current system limitations in RL10 are the following:
Only nGBR bearers are supported (supported QCIs: QCI5 QCI9)
One nGBR bearer per UE (a default one, no dedicated bearer support)
Up to four realtime or two non-realtime services per bearer (either/or)
These limitations affect the traffic model definition in terms of number and type of
supported services per LTE user.
1.3.1.2
Connection Admission Control support in RL10

Connection Admission Control (CAC) function decides whether an incoming call can be
admitted to the network depending on the agreed QoS level of the call and currently
available network resources.
Currently, the CAC is implemented only on the Air interface, as one of RRM functions;
no transport CAC on S1 is available (i.e. the incoming connections are always admitted
on S1). On the Air i/f each incoming connection is verified only against a systemconfigurable upper-bound of active RRM-connections per cell. In particular, no
admission decisions against bitrates (GBR, MBR, AMBR) or any other QoS parameters
(QCI, ARP) are done.
As currently each user is allowed using only one LTE bearer (see Sec. 1.3.1.1), the
CAC threshold is by default equal to the max number of active users per cell, which is
set to 200 (see Table 1). This will affect the user traffic model definition in terms of the
13/63

Network Engineering
number of services and users supported per cell. No CAC on S1 means no blockingbased performance measures are considered in the LTE Access dimensioning (like
Erlang-B and/or Erlang-C).
1.3.1.3
Transport QoS support in RL10

Transport QoS is based on a standard IP DiffServ solution. DiffServ framework consists
of:
Traffic differentiation and prioritization
Traffic scheduling and shaping
Traffic differentiation and prioritization in the transport domain is done with Layer 3
DSCP marking, based on the QCI values of LTE bearers. Alternatively, it can be done
using Layer 2 Ethernet priority bits (IEEE 802.1p) and/or VLAN ID's (IEEE 802.1q). As
the system supports only non-GBR bearers in the RL10, only four differentiation levels
are possible in the transport domain for the U-Plane traffic, as shown in Figure 6 (one
QCI goes to IMS signaling). QoS differentiation is done on a per-user basis, i.e. a user
gets a single QoS level, irrespective of the service he/she uses. Thus, with this scheme
the system can support up to four different QoS levels in the U-Plane domain, for
example golden, silver, bronze and best-effort users.
LTE Radio domain
LTE Traffic Class
QCI
Conversational Voice
Conversational Video
LTE Transport domain

Resource
Type
DSCP
DiffServ
PHB
Ethernet
p-bits
46
EF
36
AF42
Not supported
in RL10
GBR
Non-conversational Video
26
AF31
Real Time Gaming
46
EF
IMS signaling
34
AF41
Voice, video, interactive

gaming
18
AF21
Video (buffered streaming)
28
AF32
TCP-based (e.g. www, email, ftp, p2p file sharing,

etc.
10
AF11
BE
non-GBR
Figure 6 QoS differentiation and mapping options in the LTE Transport supported in
RL10.
Traffic scheduling is performed both S1/X2downlink and uplink by the DiffServ

scheduler, according to the combined Strict Priority and Weighted Fair Queuing
(SP+WFQ) scheme.
Traffic shaping can be done on a per-VLAN and per-physical port basis in the S1/X2
uplink and on a per-bearer, per-VLAN and per- ph. port basis in the S1 downlink.
14/63

Network Engineering
1.3.2
RL20 / RL15 features
1.3.2.1
Service differentiation for Non-GBR EPS bearer (LTE009)

LTE009 enables the QoS differentiation among 5 distinct QCI classes (QCI 5-9) for nonGBR bearers, as indicated in Figure 7. Together with the LTE007 feature which allows
multiple data bearers per single UE this changes the possible way of differentiating user
traffic from the per-user to the per-service scope: with the per-user differentiation
(supported in RL10) a user is allocated a single QoS class (QCI) regardless the type of
service he/she currently uses; with the per-service differentiation a user can be
allocated multiple QoS classes (QCIs) depending on the service(s) he/she uses.
LTE Radio domain

LTE Traffic Class
QCI
LTE Transport domain

Resource
Type
DSCP
DiffServ
PHB
Ethernet
p-bits
Supported in RL20
Conversational Voice
46
EF
Conversational Video
36
AF42
Non-conversational Video
26
AF31
Not supported
Real Time Gaming
46
EF
in RL20
IMS signaling
34
AF41
Voice, video, interactive

gaming
18
AF21
Video (buffered streaming)
28
AF32
TCP-based (e.g. www, email, ftp, p2p file sharing,

etc.
10
AF11
BE
with LTE010
GBR
non-GBR
Figure 7 Service differentiation options supported in RL20 / RL15 for LTE Access
Transport.
Feature impact to the Dimensioning Tool:

Per-user service differentiation (premium vs. basic users) supported in the RL10
version has been changed to the per-service differentiation: when defining the services
in the tool, a user has possibility to assign to each service a QCI from the supported set
(QCI 6-9; QCI 5, which is assumed to be used by the IMS signaling, is excluded from
the set). Selected QCIs are then associated with respective DiffServ PHB classes, for
which WFQ transport scheduler weights and dimensioning QoS targets
(packet/application transfer delays) can be explicitly specified by the user.
1.3.2.2
Support of EPS bearers for conversational voice (LTE010)

LTE010 allows the support of data bearers with QCI = 1 for voice services. With this
feature the number of QCIs for user data supported in RL20 / RL15 is increased to six:
QCI1 and QCI5 - QCI9 (see Figure 7)
If the feature activated, the Voice service is automatically assigned QCI = 1 and the
voice traffic is handled with the highest priority by the transport scheduler (Expedited
Forwarding PHB).
15/63

Network Engineering
1.3.2.3
QoS aware Ethernet switching (LTE649)

This feature allows QoS-aware Ethernet switching between external ports of the BTS. It
can be used for BTS co-location/chaining without the need for additional switching
equipment.
By implementing this feature, eNB co-location / chaining is possible. Aggregated
bandwidth of N co-located eNBs is calculated.
1.3.2.4
Intra-LTE handover via S1 (LTE054)

This feature supports inter-eNB handovers over S1 interface in case there is no X2
connectivity between a pair of neighboring eNBs.
With this feature both X2 and S1 inter-eNB handovers are supported. The overall user
traffic due to inter-eNB handovers is split between X2 and S1 portions based on the
user-defined input and the corresponding X2 and S1 capacities are appropriately tuned.
Also the C-Plane traffic is modified to account for S1 handovers. Based on the userdefined input a part of the signaling traffic is subtracted from the X2_C and added to the
S1_MME interface.
1.3.2.5
Rate capping UL/DL (LTE013)

With these feature BTS can limit uplink and downlink bit rate of non-GBR bearers per
UE below the signaled UE-Aggregate Maximum Bit Rate (UE-AMBR).
Impact of the UE-AMBR parameter is included in the dimensioning: maximum bit rate
available to a UE is limited to the specified UE-AMBR value.
1.3.2.6
RL20 / RL15 Capacity and Dimensioning (LTE458)

The feature specifies performance and capacity parameters to be supported by RL20
release.
The parameters that have impact to the LTE Access dimensioning are limited (i.e.
upper-bounded) to the values specified by LTE458. The following parameters used as
dimensioning inputs are impacted:
16/63

Network Engineering
Table 2 LTE458 parameters impacting LTE Access dimensioning and their maximum
values.
Radio channel bandwidth
Parameter
3 MHz
5 MHz
10 MHz
15 MHz
20 MHz
Active users per cell (max

value) (*)
120
480
600
720
840
Actively scheduled users per

cell (max value) (**)
40
192
240
240
250
(*) Active users: RRC_connected users with a data bearer established; traffic demand per eNB is
calculated with respect to these users
(**) Actively scheduled users: Active users scheduled by the RRM scheduler to be served in the time
domain; Air I/F throughput limits are verified with respect to these users.
1.3.3
1.3.3.1
Operator specific QCI (LTE518)

The operator specific QCI feature allows the operator to extend the standardized QCIs
with additional 21 non-GBR QCIs for better user and service differentiation for non-GBR
services. The QCI value for each additional QCI is operator configurable in the range
from 128 to 254.
With this feature, additional QCIs can be assigned. It is possible to differentiate
services, users (e.g. gold, silver, bronze) or operators (when sharing eNBs). Up to 21
additional QCI can be specified except standard QCIs (1-9)
1.3.3.2
Transport admission control (LTE144)

Transport Admission Control (TAC) is in charge of controlling admittance of user traffic
based on available resources on the transport network in order to avoid overload
conditions on both the air interface and the transport interface. Admittance control is
applied to GBR connections only.
Impact of this feature is included when dimensioning the GBR traffic (Support of EPS
bearers for conversational voice feature has to be enabled) by using Erlang B formula.
Therefore, target Blocking Probability has been introduced.
1.3.3.3
IP transport network measurements (LTE574)

This feature introduces means for actively measuring and supervising the IP network
conditions between two IP terminations using either TWAMP protocol or UDP echo
services implemented in eNodeB or other networking elements (i.e. router, security
gateway).
The IP transport network measurement can generate additional traffic, which at default
packet size and standard packet rate is negligible to link dimensioning. However, with
17/63

Network Engineering
some settings it may achieve throughputs which should be accounted into overall link
capacity calculation. After some analysis only three scenarios, which have significant
impact on dimensioning, were specified. They can be selected by a user and taken into
account during link dimensioning. These are:
2 TWAMP sessions per BTS, low TWAMP sending rate
results with ~7 [kbps] additional throughput
2 TWAMP sessions per BTS, high TWAMP sending rate
Max TWAMP bandwidth configuration (single TWAMP session per BTS with highest
rate and biggest packet size)
1.3.3.4
Ethernet jumbo frames (LTE931)

With this feature IP fragmentation and reassembly can be avoided. The MTU can be
increased up to maximum value of 1644 bytes.
If this feature checkbox is activated in the dimensioning tool, the value of MTU can be
defined from range: 576-1644. Setting values higher than standard MTU equal to 1500
bytes allows limiting fragmentation at the transport path for user data packets that
would normally be fragmented.
That decreases the impact of overheads in dimensioning calculations, resulting in more
efficient link utilization.
With Ethernet Jumbo frames enabled the default MTU value still remains 1500. It
should be adjusted to reflect actual network value.
1.3.4
RL40 features
1.3.4.1
Support of QCI 2, 3, 4 (LTE496)

This feature enables the usage of QCI 2, 3 and 4. As standardized by 3GPP, in network
supporting this feature, bearers assigned to QCIs from range 1-4 are GBR bearers, and
the rest are treated as non-GBR.
Activation of this feature is possible with simultaneous activation of Smart admission
control (LTE497) and ARP based admission control (LTE534) only. Enabling this
feature allows user to specify additional QCIs: 2, 3 and 4.
1.3.4.2
Smart admission control (LTE497)

The smart admission control enhances the resource utilization of the eNB and keeps
the radio interface in a healthy state when congestion happens. It extends the fixed
threshold based admission control for GBR EPS bearers and realizes a congestion
supervision mechanism on radio interface. Up to RL30 Radio AC works with a counter
based solution on O&M configured. With LTE497 for GBR-DRBs a forecast calculation
on needed radio resources is done using a transmission efficiency value determined by
L2 (RLC and scheduling) for uplink and downlink. If the forecast calculation shows that
the newly requested GBR-DRB has sufficient radio resources (still PRBs left over and
not beyond configured thresholds) then the request is admitted - otherwise it is rejected.
18/63

Network Engineering
Activation of this feature is possible with simultaneous activation of Support of QCI 2, 3,

4 (LTE496) and ARP based admission control (LTE534) only. This feature enhances
the RL30: Transport Admission Control by using various transmission rates instead of
fixed one.
1.3.4.3
Multiple GBR EPS bearers per UE (LTE587)

With LTE587 feature the Flexi Multi radio BTS supports up to three GBR EPS radio
bearers per UE. Up to six data radio bearers can be established per UE. The different
EPS bearers per UE can have the same or a different QCI. The QCIs needs to be
enabled via separate features.
This feature allows establishing more than one GBR bearer per UE. User can assign
QCIs 1 - 4 to GBR. For dimensioning purposes, Erlang B formula used up to RL30, has
been replaced by Multidimensional Erlang B formula (MDErlang).
1.3.5
1.3.5.1
Transport separation for RAN sharing (LTE505)

This feature enables separation of transport paths for U-Plane and also for C-Plane of
two networks/operators. This separation can be done by splitting the traffic into
separate VLANs.
There is no direct impact on the dimensioning tool. However, there can be two different
traffic models coming from the operators, which can be configured in the tool by
separate traffic profiles. For such configuration the total capacity for the whole transport
interface will be shown.
19/63

Network Engineering
2.
LTE Access dimensioning concept and methodology

LTE Access dimensioning allows determining the required transport capacity of the BTS
on the following logical LTE interfaces:
S1_U: User data transport between eNB and SAE-GW

S1_MME: Signaling transport between eNB and MME
X2_U: User data transport between eNB nodes during handover
X2_C: Signaling transport between eNB nodes
O&M i/f: Transport of O&M data between eNBs and O&M System
S-Plane i/f: synchronization transport between eNB and the reference clocks
signal according to Timing over Packet (ToP) standard
Note that these are logical interfaces which share the physical transport interface at the
eNB. Specification of the transport capacity requirements for these interfaces is of the
utmost importance if the operator does not have its own transport infrastructure and
has to use leased lines. eNB transport capacity components subject to dimensioning
are shown in Figure 8.
In the following sections the LTE Access dimensioning workflow is described. Section
2.1 provides a definition of input and output parameters used in the dimensioning. In
Section 2.2 a detailed dimensioning methodology for LTE Access is described.
20/63

Network Engineering
Figure 8 LTE Access interface dimensioning components.
2.1
LTE Access dimensioning workflow

Figure 9 depicts the consecutive steps in the LTE Access dimensioning
process.
The dimensioning starts with specifying dimensioning inputs. These include the LTE
traffic model, radio-related inputs, signaling inputs and various configuration settings.
For a detailed description of the input parameters please refer to Sec. 2.1.1.
Next, the actual dimensioning follows covering all the above-mentioned interfaces. As
the result a set of dimensioning outputs is provided, i.e. the required transport capacity
21/63

Network Engineering
LTE Access
dimensioning inputs
for the eNB along with the capacity split per logical interfaces. Detailed description of
the output parameters is provided in Sec. 2.1.2.
Features configuration
Feature selection
Feature parametrization
Services
Subscriber profile
definition
Service set definition
Traffic demand
Transport configuration
Traffic Model definition

User data definition
Signaling parameters
Number of sites
QoS Class configuration
Scheduler weights
Area configuration
Front Mile
Area type
Software release
Site layout
Area selection
Number of eNBs
Load Distribution Factor
U plane dimensioning
LTE Access
dimensioning outputs
(S1_U & X2_U)
C plane dimensioning
(S1_MME & X2_C)
Front mile dimensioning
Dimensioning Output
Transport capacity per logical interface
S1 (UP & CP)
X2 (UP & CP)
S-Plane (optional)
Total transport capacity
per eNB (last mile)
per aggregation point (front mile)
Figure 9 LTE Access dimensioning workflow.
2.1.1
Definition of input parameters

The following groups of inputs are defined:
Area configuration
Services
Traffic demand
Aggregation point inputs
They will be described in the following sub-sections.

2.1.1.1
Area configuration
This group of inputs specifies the area configuration. It consist of such parameters as
the duplex mode, area type, operating band, bandwidth, channel bandwidth, and
software release. Note, that not all of them impact directly the access network
dimensioning. In this section, only parameters directly impacting the access
dimensioning will be covered. They should be specified in the first place as they
determine the overall dimensioning process.
22/63

Network Engineering
Table 3 LTE Access dimensioning inputs: Area configuration.

Area configuration
parameters
Software release
2.1.1.2
Default value
Comment
RL40
Sets the software version which limits available

features.
Features configuration step allows the feature set configuration. It is divided into three
sections:
Common features configuration

consist of features impacting radio and access network dimensioning
Radio features configuration
consist of features impacting radio network dimensioning
Access features configuration
consist of features impacting access network dimensioning
The feature description and impact on dimensioning is described in Feature impact to

LTE Access dimensioning chapter.
2.1.1.3
Services
Services are used for dimensioning based on the user traffic demand only. In this step
user defines the subscriber profile with the service sets. For each service it is possible
to set the basic parameters describing it.
Table 4 LTE Access dimensioning inputs: Traffic model inputs LTE User Profile.
Service parameters
Default value
Name
Internet Static
Application
Bearer
QCI 9
Phase
Enabled
Packet size
Service dependant
Comment
Specifies the service name and type.
Specifies the QoS Class Identifier

(QCI) of service bearer.
Enables/disables the service into/from
calculations within given phase.
Sets average packet length for each
service.
23/63

Network Engineering
QoS blocking probability
QoS mean delay
2.1.1.4
2%
Sets the blocking probability for GBR

services used in ErlangB formula.
15 [ms]
Sets the average packet delay per

service for Last/Front mile calculation
(MGR-PS)
Traffic demand
Traffic demand is used for dimensioning based on the user traffic demand only. Traffic
demand specifies the user traffic requirement. For each subscriber profile and service
set, it is possible to define parameters separately, which enables high flexibility of traffic
model definition. Parameters used in this step are divided into four subsections:
General
U-plane
C-plane
Smart applications
Table 5 LTE Access dimensioning inputs: Traffic demand general.

Traffic demand general
parameters
Traffic model for Busy Hour
(BH)
TM parameters defined at
Number of subscribers per area
Default value
Traffic demand per

subscriber
End User/application
level
N/A
Comment
Indicates whether the traffic demand
is specified:
per subscriber
per area
Indicates whether the traffic demand is
specified at:
Network level
End User/application level
Defines number of subscribers per
area in case of traffic demand
specified per subscriber.
24/63

Network Engineering
Table 6 LTE Access dimensioning inputs: Traffic demand U-plane.

Traffic demand U-Plane
parameters
Service
Link
Default value
Dependent on
selected service
UL/DL
Comment
Service name
Direction indication
BHCA
Dependent on
selected service
Defines amount of Busy Hour Call

Attempts for each service
Call/session duration
Dependent on
selected service
Defines the call/session duration
Average bearer rate
Dependent on
selected service
Defines the average service

throughput demand within the
call/session duration
Traffic demand
Dependent on
selected service
Defines the service traffic demand

within the BH
Table 7 LTE Access dimensioning inputs: Traffic demand C-plane.

Traffic demand C-Plane
parameters
Default value
Comment
Attach per subscriber
0,1
Average amount of subscriber

attaches within BH
Paging retry (or repetition)

factor
1,1
Defines the average number of

repeated paging by MME
MTC ratio for CS like services

(VoIP)
MTC ratio for PS like services

(VoIP)
50%
Defines the frequency of the paging

procedure executed in the scenario
when there is incoming call for the UE
in MME
15%
Defines the frequency of the paging

procedure executed in the scenario
when there is incoming call for the UE
in MME
Handovers per call
4,5
Defines the average number of

handovers per call
Tracking Area Update per

subscriber
1,8
Defines the amount of Tracking Area

Updates per subscriber within the BH
25/63

Network Engineering
Table 8 LTE Access dimensioning inputs: Traffic demand Smart applications.

Traffic demand smart
applications parameters
Service name
Message size
Default value
Comment
Dependent on service Service name

2000 [B]
Smart application message size
Time between messages
90 [s]
Time between smart application

messages
Percentage of incoming
messages
50%
Percentage of incoming messages

from all smart application messages
Keep alive message

Time between keep alive
messages
Number of applications per
subscriber
150 [B]
90 [s]
0,5
Keep alive message size

Time between keep alive messages
Amount of smart applications per
subscriber
26/63

Network Engineering
2.1.1.5
Transport configuration is used for dimensioning based on the user traffic demand only.
This section consist of transport network configuration such as VLAN tag, QCI mapping
to Per Hop Behavior (PHB) queue and PHB weights. Parameters are described in Table
9.
Table 9 LTE Access dimensioning inputs: Transport configuration.
parameters
Number of sites
Number of cells per site

Average cell throughput
[kbps]
Default value
N/A
N/A
Peak cell throughput [kbps]
QoS Class configuration

PHB weight configuration
PHB delay target
2.1.1.6
Defines number of sites within area. To be

putted by user or automatically copied from
radio dimensioning results
Defines number of cells per site. To be putted
by user or automatically copied from radio
dimensioning results
Defines the cell average throughput. To be
Defines the cell peak throughput. To be

N/A
VLAN tag
Comment
Enabled
QCI
Dependent
PHB
dependent
PHB
dependent

Specifies whether the VLAN tag is included into
Ethernet frame
Defines the QCI to PHB queue mapping
Defines the PHB weight in WFQ scheduler
Defines the PHB delay target which is the
minimum delay from all services assigned to
that PHB
Aggregation point inputs

Aggregation point inputs are used for dimensioning based on the user traffic demand
only. This group of input parameters refers to capacity dimensioning of traffic from
several eNBs aggregated at some point of network. It can be any aggregation point
within the network (i.e. router).
27/63

Network Engineering
Table 10 LTE Access dimensioning inputs: Aggregation point inputs.

Front mile inputs
parameters
Area
Number of sites
Handover traffic included
2.1.1.7
Default value
N/A
Comment
Defines which areas are included into
aggregation point calculation
Defines the amount of sites within each area

that are connected in the aggregation point.
The maxium value is the total amount of sites in
the area.
False
Defines if the handover traffic from the

connected sites is also aggregated at this point.
Front mile inputs

Front mile inputs are used for dimensioning based on the user traffic demand only. This
group of input parameters refers to capacity dimensioning of traffic from all eNBs
aggregated in the network.
Table 11 LTE Access dimensioning inputs: Front mile inputs.
Front mile inputs
parameters
Default value
Comment
Area
N/A
Defines which areas are included into front mile

calculation
Number of sites
N/A
Shows the amount of sites within each area.

LDF parameter defines the Busy Hour
distribution among various eNBs.

(LDF)
2.1.2
Note: The Load Distribution Factor should be

used for situation when the eNB environment is
stochastic (unusual traffic situation of one site
does not change the general traffic behavior in
aggregation point).
Definition of output parameters

LTE Access dimensioning outputs include the transport-related capacity parameters
obtained through the dimensioning. They are summarized in Table 12.
28/63

Network Engineering
Table 12 Interface dimensioning outputs.
Interface dimensioning outputs
Comment
Transport capacity per logical interface

of the eNB [kbps]
These are bandwidth portions of the individual

logical interfaces at the eNB side.
Total transport capacity per eNB [kbps]
This is a dimensioned total transport capacity to be

installed at the eNB side; it is specified separately as
a sum of the capacities of individual logical
interfaces.
Transport capacity per selected

aggregation node without multiplexing
gain [Mbps] (*)
This is total transport capacity of interface of

selected aggregation node without multiplexing gain.
All last mile link capacities are summarized here.
Transport capacity per selected

aggregation node with multiplexing gain
[Mbps] (*)
This is total transport capacity of interface of

selected aggregation node with multiplexing gain. All
last mile link capacities are summarized here taking
into account the gain achieved by aggregation.
Multiplexing gain [%] (*)
This is achieved statistical multiplexing gain resulting

from aggregation of several eNBs.
(*) This output is valid for front mile dimensioning only.
2.2
LTE Access dimensioning methodology
2.2.1
General concept
There are two general approaches proposed for the transport capacity dimensioning:
-
Dimensioning based on the user traffic demand: transport capacity is

calculated based on the estimated user traffic demand so that some transport
QoS performance targets are assured (packet delay and loss).
Dimensioning based on the Radio interface throughputs: transport capacity

is calculated from the supported Radio interface throughputs.
Network planner is free to use any of the above options knowing the availability of input
data and potential advantages and drawbacks of each option, as summarized in Sec.
2.2.2.3. Here, a general dimensioning workflow is described for both options and
illustrated in
Figure 9.
Note:
Dimensioning based on the Radio interface throughputs is on the

roadmap and not yet implemented in official version of dimensioning tool.
Latest implementation is available in ANT_LTE tool (no longer
developed), for calculation support please contact author.
29/63

Network Engineering
2.2.1.1
Dimensioning based on the user traffic demand

When using this option, the LTE Access dimensioning workflow consists of the following
steps:
-
Specification of the traffic demand: First, the traffic offered to the LTE Access
network has to be specified. Parameters required to appropriately model the
offered U-Plane and C-Plane traffic are described in the LTE Traffic Model and
Signaling sections. The TM parameters values need to be set by the operator
or, alternatively, taken from the LTE reference traffic model specified in
[LTE_TM].
Transport aggregation: LTE services are grouped into IP DiffServ classes

supported for the U-Plane traffic in the LTE Transport domain, as described in
Sec. 1.3.2.1 1.3.2.2. For each service a specific DiffServ PHB class (Per Hop
Behavior) is assigned and the dimensioning is done respecting service priorities
(see Sec. 2.2.2.1).
Specification of Quality of Service targets: Certain level of QoS must be

guaranteed for the traffic in the LTE transport network. The assumed QoS
metric is the max tolerable IP packet delay in the transport network to achieve a
requested end user quality of service.
Network planner must be able to quantify the QoS requirements and to apply
them in the dimensioning.
Optional: Front mile: Selection of aggregation node (with its interface transport
capacity) and specification of number of eNBs to be aggregated.
Dimensioning: In order to guarantee the QoS requirements for the traffic to be

transmitted in the LTE transport network, different approaches are used to
calculate the bandwidth on interfaces either M/D/1 or MDErlang for RT traffic
and M/G/R-PS for NRT traffic. U-Plane dimensioning methods for RT/NRT
traffic are described in Sec. 2.2.2.1 - 2.2.2.2. In addition, C-Plane and M-Plane
traffic is dimensioned accordingly, as described in Sec. 2.2.3 and 2.2.4.
At the end, U-Plane RT/NRT, C-Plane and M-Plane traffic share the
dimensioned interface capacity according to the priorities resulting from their
DiffServ PHB settings.
Front mile dimensioning is covered in section 2.2.7.
2.2.1.2
Dimensioning based on the Radio interface throughputs

When using this approach, the dimensioning workflow is much simplified. It consists of
three steps as shown in Figure 10:
-
First, radio-related inputs need to be collected from the Radio planning.
Next, the following parameters are specified, as a part of configuration settings:
the amount of Radio (Uu) and Transport (S1/X2) overheads,
the estimated amount of handover and signaling traffic as a percentage

of the overall user traffic demand.
Finally, the eNB transport capacity dimensioning is performed according to the

rules described in Sec. 2.2.2.2.
30/63

Network Engineering
LTE Access dimensioning steps for both options are presented in Figure 10.
LEGEND:
LTE traffic model:

- User profile definition
- Service definition
- Service distribution
- Signaling inputs
Intermediate results
Traffic aggregation according to

IPDiffServ PHB classes
QoS settings
Front mile inputs
LTE interface dimensioning

(logical S1, X2 and O&M i/f)
Resulting eNB
transport capacity
Area configuration
Radio-related
inputs
DIMENSIONING BASED ON THE USER TRAFFIC DEMAND
Output
DIMENSIONING BASED
ON THE RADIO I/F THROUGHPUT
Specification of traffic demand

(U-Plane, C-Plane)
Input
Resulting Front mile

transport capacity and statistical
multiplexing gain
Figure 10 LTE Access interface dimensioning flowchart.
2.2.2
U-Plane traffic dimensioning: S1_U and X2_U interfaces

S1_U and X2_U interfaces are dimensioned jointly reflecting the fact that both
interfaces share a common buffer of the transport scheduler and are multiplexed
together on the transport link. The joint S1_U and X2_U transport capacity is calculated
separately for each area, using two alternative methods:
Dimensioning based on the user traffic demand
Dimensioning based on the radio interface throughput
Both methods will be presented in the following sections.
31/63

Network Engineering
2.2.2.1
S1_U and X2_U dimensioning based on the user traffic demand

With this approach the U-Plane transport capacity for S1_U and X2_U interfaces is
calculated as a sum of bandwidth portions of the RT and NRT traffic:
Equation 1
S1_&_X 2_Capacity [kbps]= S1_&_X 2_Capacity_ RT + S1_&_X 2_Capacity_ NRT

The RT and NRT capacities are calculated separately using different inputs and
dimensioning formulas. Bandwidth of the RT traffic is calculated using either MDErlang
formula or M/D/1 formula [MD1], which uses IP packet delay as a QoS measure in the
dimensioning. The NRT bandwidth is calculated with M/G/R-PS [MGR-PS], extended
with Transport Network delay estimation, which also uses IP packet delay as a QoS
measure in the dimensioning. Table 13 indicates which dimensioning formula is used
for particular service based on its characteristics; the same information can be retrieved
from Figure 11:
Table 13 Dimensioning formula selection based on service characteristic.
Service type
[RT or NRT]
QCI
[GBR or non-GBR]
Dimensioning
formula
QoS target
GBR
MDErlang
blocking probability
Non-GBR
M/D/1
single-link delay
Non-GBR
Ext M/G/R-PS
single-link delay
Real-time
Non-real-time
For real-time services there are two possibilities for dimensioning formula selection. If
the service is real-time, the further check is necessary. For services assigned to GBR
bearers, the MDErlang formula is used. Note that calculation is performed once for all
GBR services and no QoS target in seconds is applied except blocking probability.
Real-time services assigned to non-GBR bearers are calculated with M/D/1 formula with
single-link delay as QoS target (each separately). For all non-real-time services
extended M/G/R-PS with single-link delay QoS target is applied.
Note:
Dimensioning based on the traffic model and the Transport Network

Delay QoS targets may result in a capacity lower than the radio cell peak
throughputs. If the ability to deliver such peak rates is a must (e.g. driven
by marketing requirements), then the greater value should be taken from
the dimensioned capacity and the cell peak rate multiplied by transport
overheads.
32/63

Network Engineering
Dimensioning RT U-Plane traffic with M/D/1 and MDErlang

RT U-Plane capacity is calculated as a sum of the capacity portions occupied by
individual RT services:
Equation 2
S1 _& X 2 _ Capacity _ RT [ kbps ]
{ S1 _& _ X 2 _ Capacity _ RT
Service
Service
The RT capacity per service is calculated using either the MDErlang formula (for all RT
GBR services, Equation 3) or the M/D/1 formula [MD1] (for RT non-GBR services,
Equation 4):
Equation 3
S1 _& _ X 2 _ Capacity _ RTGBRService [ kbps ] MDErlang{ S1 _& _ X 2 _ traffic _ load Service ,

peak _ rate Service,blocking _ probabilit y Service }
where:
S1_&_X2_traffic_load Service [kbps] is the user traffic demand per service on S1

and X2 interfaces.
peak_rate Service [kbps] is a service peak rate.
blocking_probability [#] is a probability of block of incoming call.
Equation 4
S1 _& _ X 2 _ Capacity _ RTnGBRService [ kbps ] M / D / 1{ packet _ delay Service , packet _ sizeService,

S1 _& _ X 2 _ traffic _ load Service , PHB _ weight Service, S1 _ U _ OH Service }
where:
packet_delay Service [ms] is the max tolerable transport delay of IP packets on the
last mile link. It is the assumed QoS target for dimensioning the RT traffic,
specified separately for each service class. Default value (for each service class)
is 15 ms.
packet_size
Service
[bytes] is the average size of an IP packet per service.
S1_&_X2_traffic_load Service [kbps] is the user traffic demand per service on S1

and X2.interfaces.
33/63

Network Engineering
PHB_weight Service [#] is the weight of the DiffServ scheduler queue that serves
the QoS class of the service; it determines the bandwidth available to that QoS
class during the congestion (i.e. all queues fully occupied with traffic).
S1_U_OH Service [%] is the S1_U transport overhead per service.
Note: the offered user traffic load should be compared against the average cell
capacity. This is to check if the offered traffic can be accommodated within the
supported radio capacity.
Note:
M/D/1 approach underestimates the required capacity at S1. The reason

is M/D/1 approach assumes a complete random packet arrival, but in
reality, the video and streaming are flow based instead of packet based.
This underestimation is compensated by NRT services which are
dimensioned separately for the same plane. Therefore, it is
recommended to use both RT and NRT services in the dimensioning.
Dimensioning NRT U-Plane traffic with M/G/R-PS

NRT U-Plane capacity is assigned so that it fulfills the requirements of the QoS class
with the most stringent delay targets. Dimensioning procedure runs separately for each
service (with respective delay targets) and the final capacity is picked up as a max of
the capacities needed by individual services:
Equation 5
S1_ & _X2_Capaci ty_NRT [kbps] = Max{ S1 _& _ X 2 _ Capacity _ NRTService }

Service
The application e2e delay per service is calculated using the M/G/R-PS formula [MGRPS]:
Equation 6
S1 _& _ X 2 _ e2eDelay _ NRTService [ s ] M / G / R PS { r _ peak Service , file _ sizeService ,

transfer _ delay PHB ( Service ) , S1 _& _ X 2 _ traffic _ load PHB ( Service ) , PHB _ weight Service ,
S1 _ U _ OH Service }
where:
r_peak Service [kbps] is a service peak rate. This maximum results either from
available radio link resources not occupied by other services or from the radio
scheduler weight assigned to particular bearer. It is calculated with the weighted
M/G/1-PS formula [MGR-PS], using the following inputs:
34/63

Network Engineering
Equation 7
r _ peak Service [ kbps ] M / G / 1 PS { total _ traffic _ load , avg _ cell _ throughput ,

Uu _ OH Service , QCI _ weight Service }
where:
-
total_traffic_load [kbps] is the total user traffic in a radio cell,
avg_cell_throughput [kbps] is the average radio cell throughput; it is the

outcome of the radio planning (refer to [LTE_Radio_Dim]). The user
traffic per cell, as specified via the traffic model should not exceed the
average radio cell throughput,
Uu_OH Service [%] denotes the protocol overhead on the Radio interface
(including RLC and PDCP layers),
QCI_weightService[#] is a radio scheduler weight of QCI which service is

assigned to.
file_size Service [kBytes] is an average size of a TCP file per service,
S1_&_X2_traffic_loadPHB(Service) [kbps] is the user traffic demand on S1 and X2

interfaces for the whole PHB class the service belongs to (i.e. sum over all
services within the class). The X2 load:
o
HO_traffic_load [kbps] is a traffic load on X2 interface (Equation 9)
Note: the offered user traffic load should be compared against the average cell
capacity. This is to check if the offered traffic can be accommodated within the
supported radio capacity.
The application e2e delay per service is calculated for the dimensioned link capacity
and for ideal, non congested link. Using these two delays, the Transport Network delay
can be estimated, which is the QoS requirement for the dimensioning. Finally, NRT
capacity which fulfills QoS requirement for each service can be calculated.
Equation 8
S1_&_X 2 _Capacity_ NRTService [kbps]= TN_delay_estimatio n

S1 _& _ X 2 _ e2eDelay _ NRTService , S1 _& _ X 2 _ e2eDelay _ NRT _ min Service ,
file _ sizeService
where:
S1_&_X2_e2eDelay_NRTService [s] is the application e2e delay per service

calculated using the M/G/R-PS formula (Equation 6),
S1_&_X2_e2eDelay_NRT_min Service [s] is the minimum application e2e delay

per service for ideal and non congested link calculated using the M/G/R-PS
formula (Equation 6),
35/63

Network Engineering
file_size Service [kBytes] is an average size of a TCP file per service.
Dimensioning the U-Plane bandwidth for NRT traffic using M/G/R-PS is illustrated in
Figure 11.
Calculating user traffic due to inter-eNB handovers
U-Plane traffic of an eNB due to inter-eNB handovers is calculated with the following
formula:
Equation 9
HO _ traffic _ load [kbps] HO _ Freq {t _ ps S1 _ traffic _ load DPDCP }

where:
S1_traffic_load [kbps] is the U-Plane traffic load per eNB on S1 interface.
HO_Freq [1/s] is the inter-eNB handover frequency
t_ps [s] is a switchover duration,
D PDCP [kbits] is the PDCP buffer occupancy of an eNB, which in turn depends
on the Radio interfaces utilization. It is calculated with a polynomial function of
the Radio I/F utilization, which reflects the PDCP buffer occupancy results
obtained via simulations:
Equation 10
3,4 ( Uu _ util 0,3 )
DPDCP [ kbits ] 3
3
2
10 ( 1,3452 Uu _ util 1,6896 Uu _ util Uu _ util 0,1024 ) ( Uu _ util 0,3 )
where:
Uu_util [%] is the Radio I/F utilization, calculated as:
Equation 11
Uu _ util [# ]
gross _ traffic _ load _ per _ cell

avg _ cell _ throughput
where:
gross_traffic_load_per_cell [kbps] is the total user traffic in a radio cell with radio
overhead.

Network Engineering
36/63
Note:
If calculated X2_U capacity is zero, but the X2 load is greater than zero, it
is assumed that X2 traffic is accommodated in S1_U capacity.
General dimensioning concept of the U-Plane bandwidth traffic (based on the user
traffic demand) is graphically illustrated in Figure 11.
Service = RT
YES
Blocking_probability
Service =
GBR
GBRservice
YES
MD-Erlang
(for all RT
GBR services)
S1_(&_X2)_traffic_load Service [kbps]
NO
Load RT GBR
S1_(&_X2)_traffic_load Service [kbps]
packet_delay Service [ms]
packet_size Service [bytes]
S1_U_OH Service [%]
S1_(&_X2)_Capacity_RT Service [kbps]
M/D/1
S1_(&_X2)_Capacity_
RT_GBR [kbps]
Sum from all

RT nGBR
services
Max
PHB_weight Service
NO
per service
ave_cell_throughput [kbps]
Uu_OH Service [%]
Weighted
M/G/1-PS
QCI_weight
S1_(&_X2)_traffic_load per cell [kbps]
Target Packet DelayPHB[ms]
S1_(&_X2)_Capacity_
RTnGBR [kbps]
Initial capacity = S1_(&_X2)_traffic_load [kbps]

Capacity
per PHB
S1_(&_X2)_Capacity_
NRT+RTnGBR+
RT_GBR_load [kbps]
Sum
NO -> Increase capacity
r_peak Service
Max from all
NRT services
S1_(&_X2)_Capacity_
NRT [kbps]
S1_(&_X2)_e2eDelay_NRT Service [kbps]

S1-U_OH Service [%]
S1_(&_X2)_traffic_load PHB(Service) [kbps]
M/G/R-PS
per PHB
TN Delay
estimation
PHB_weight Service
file_size Service [kbytes]
S1_(&_X2)_e2eDelay_NRT_min Service [kbps]
TN delay <
Target Packet
delay
TN delay PHB [ms]
YES -> S1_(&_X2)_Capacity_

NRTService[kbps]
S1_(&_X2)_Capacity [kbps]
Figure 11 S1_U dimensioning general concept.
2.2.2.2
S1_U and X2_U dimensioning based on the Radio interface throughput

Alternatively to the dimensioning based on the user traffic demand, the U-Plane
transport capacity (S1_U, X2_U) can be determined based on the supported radio
interface throughput. The idea behind this approach is the observation that the eNB
transport capacity should be not higher than the available capacity of the radio cells
served by this eNB.
eNB U-Plane transport capacity derived from available Radio IF throughputs (denoted
as eNB_U-Plane Transport_Capacity Radio-based) can be calculated using one of the
options defined in [LTE_Transp_+_QoS]:
All Average
All Average / Single Peak

Network Engineering
Single Peak plus All-but-one-Average

All Peak
They will be summarized in the following sub-sections.
All Average
With this option the total U_Plane transport capacity at eNB shall support the
aggregated average capacity of all cells. The calculated U_Plane transport capacity
should be:
Equation 12
eNB _ U _ PlaneTransport _ Capacity Radiobased [ kbps ] (# _ of _ cells _ per _ eNB

avg _ cell _ throughput ) ( 1 Uu _ OH ) ( 1 S1 _ U _ OH )
where:
avg_cell_throughput [kbps] is the average radio cell throughput. It is determined

under realistic air interface conditions and multiple users per cell, and should be
the outcome of the radio planning (refer to [LTE_Radio_Dim]).
Uu_OH [%] is the transport overhead on the Radio interface (including RLC and
PDCP layers),
S1_X2_U_OH [%] is the U-Plane transport overhead on S1 and X2 interface
(see dimensioning inputs).
Cell average
eNB U-Plane transport
The All Average option is graphically presented in Figure 12.
Cell peak
37/63
Figure 12 Dimensioning based on the Radio i/f throughput the All Average option.

Network Engineering
All Average / Single Peak

With this option the U-Plane transport capacity at eNB shall support the aggregated
average capacity of all cells, while at least supporting the peak capacity of one cell:
Equation 13
eNB _ U _ PlaneTransport _ Capacity Radio Based [ kbps ] MAX { peak _ cell _ throughput ;
# _ of _ cells _ per _ eNB avg _ cell _ throughput } ( 1 Uu _ OH ) ( 1 S1 _ U _ OH )
where:
peak_cell_throughput [kbps] is the peak radio cell throughput; it is determined

under ideal Radio interface conditions and with a single user per cell under
realistic air interface conditions. It should be the outcome of the radio planning
(refer to [LTE_Radio_Dim]).
Cell average
The All Average / Single Peak option is graphically presented in Figure 13. This is the
recommended option for Radio-based dimensioning (often 3G operators use it to
dimension the HSPA traffic).
Cell peak
38/63
Figure 13 Dimensioning based on the Radio i/f throughput the All Average / Single
Peak option.
Single Peak plus All-but-one-Average

With this approach the U-Plane transport capacity at eNB shall support the peak
capacity of one cell and the aggregated average capacity of the remaining cells.

Network Engineering
The calculated U-Plane transport capacity should be:

Equation 14
eNB _ U _ PlaneTransport _ Capacity Radiobased [ kbps ] [ peak _ cell _ throughput

(# _ of _ cells _ per _ eNB 1 ) avg _ cell _ throughput ] ( 1 Uu _ OH )
( 1 S1 _ U _ OH )
Cell average
The Single Peak plus All-but-one-Average option is illustrated in Figure 14.
Cell peak
39/63
Figure 14 Dimensioning based on the Radio i/f throughput the Single Peak plus All-butone-Average option.
All Peak
With this approach the U-Plane transport capacity at eNB shall support the aggregated
peak capacity of all cells. As the load per eNB will hardly achieve peak values in all cells
at the same time, this approach will lead to over-dimensioning, thus usually extra costs.
The calculated U-Plane transport capacity should be:
Equation 15
eNB _ U _ PlaneTransport _ Capacity Radiobased [ kbps ] (# _ of _ cells _ per _ eNB

peak _ cell _ throughput ) ( 1 Uu _ OH ) ( 1 S1 _ U _ OH )
The All Peak option is illustrated in Figure 15.
Cell peak

Network Engineering
40/63
Figure 15 Dimensioning based on the Radio i/f throughput the All Peak option.
Figure 16 shows how the U-Plane traffic of logical S1_U and X2_U interfaces is
distributed within the eNB and how it is mapped onto the available transport capacity.
Radio side
(eUTRAN)
Transport side
(ePC)
eNB
S1_UL
eNB
X2_DL_out
UL
eNB_Transp_Cap (UL)
S1_UL
X2_DL_out
X2_DL_out
S1_DL
S1_DL
S1_DL - X2_DL_out
S1_DL - X2_DL_out
DL
eNB_Transp_Cap (DL)
X2_DL_in
X2_DL_in
a)
b)
Figure 16 U-Plane traffic distribution within the eNB: a) logical distribution, b) mapping to
the transport capacity.
From the figure it can be seen that:
41/63

Network Engineering
Equation 16
eNB _ Transport _ Capacity _ DL[ kbps ] S1 _ U _ DL X 2 _ U _ DL _ in

Equation 17
eNB _ Transport _ Capacity _ UL[ kbps ] S1 _ U _ UL X 2 _ U _ DL _ out
where:
X2_U_DL_out [kbps] is the outgoing X2 traffic, for which the eNB is the source
eNB,
X2_U_DL_in [kbps] is the incoming X2 traffic, for which the eNB is the target
eNB
Now, assume the uniform user/traffic distribution within all eNBs:

Equation 18
X 2 _ U _ DL _ out[kbps] X 2 _ U _ DL _ in[kbps]
Assume as well that the total X2_U_DL traffic is some percentage of the average S1_U
DL traffic:
Equation 19
X 2 _ U _ DL _ out X 2 _ U _ DL _ in [ kbps ] HO _ Share[%] S1 _ U _ DLALL _ AVG

To make the X2_U traffic independent from the selected dimensioning option, the
average S1_U traffic in (Equation 19) is always calculated using ALL_AVG option. From
(Equation 16):
Equation 20
S1 _ U _ DLALL _ AVG [ kbps ] eNB _ Transport _ Capacity _ DLALL _ AVG X 2 _ U _ DL _ in
From (Equation 18)-(Equation 20):

Equation 21
X 2 _ U _ DL _ out [ kbps ] X 2 _ U _ DL _ in [ kbps ]

HO _ Share[%]
eNB _ Transport _ Capacity _ DLALL _ AVG
2 HO _ Share[%]
From (Equation 16) - (Equation 17) and (Equation 21):
42/63

Network Engineering
Equation 22
S1 _ U _ DLOption [ kbps ] eNB _ Transport _ Capacity _ DLOption

HO _ Share[%]
2 HO _ Share[%]
Equation 23
S1 _ U _ ULOption [ kbps ] eNB _ Transport _ Capacity _ ULOption

HO _ Share[%]
2 HO _ Share[%]
where:
2.2.2.3
Option {ALL_AVG, ALL_AVG_/_SINGLE_PEAK,

SINGLE_PEAK_+_ALL_BUT_ONE_AVG, ALL_PEAK}
U-Plane traffic dimensioning Summary

In the above, two alternative methods are proposed for the transport dimensioning with
the U-Plane traffic:
Dimensioning based on the user traffic demand,

Dimensioning based on the Radio interface throughput
Their comparative analysis is presented in Table 14.

The use of a particular method is the operators choice and depends on the availability
of input data and the operators strategy to assure the QoS to the customers. In
general, the dimensioning based on the user traffic demand is recommended, as it
allows the transport capacity to be exactly tailored to the user traffic demand; it also
allows the transport QoS parameters (such as packet delay) to be taken into account in
the dimensioning. On the other hand, the dimensioning based on the Radio interface
throughput should be used when the exact traffic model is not available and/or the
transport QoS performance does not need to be considered.
43/63

Network Engineering
Table 14 Dimensioning based on the user traffic demand vs. dimensioning based on the
Radio interface throughput comparative analysis.
PROS
Dimensioning based
on User traffic demand
Dimensioning based
on Radio I/F
throughput
CONS
Possibility to directly account for

transport QoS impairments (i.e.
data transfer delay and /or
packet loss).
Capacity is tailored to the actual
traffic needs and not to the
assumed Radio I/F throughput
(e.g. dimensioning over Peak
cell throughput will lead to over
dimensioning)
Front mile dimensioning is
possible
Difficult to collect all input data;

usually operators can provide
only some of them (i.e.
simplified traffic model)
Easily available input data:

Peak/Avg cell capacity can be
easily collected from Radio
planning of system specification
Straightforward approach
Impossibility to take into

account any transport QoS
impairments (i.e. packet loss,
delay etc.)
May lead to over dimensioning,
i.e. when eNB transport is
dimensioned over Peak cell
throughput
2.2.3
C-Plane dimensioning: S1_MME and X2_C interfaces
2.2.3.1
General concept
Similarly to the U-Plane traffic dimensioning, also the C-Plane traffic is dimensioned
according to the two proposed options:
-
Dimensioning based on the user traffic demand: C-Plane traffic is carefully

estimated based on the frequency of signaling events and the structure of
signaling flows.
Dimensioning based on the Radio i/f throughput: C-Plane traffic is only roughly
estimated as a percentage of the U-Plane traffic.
Both dimensioning options are described in detail below. General concept of the
dimensioning is shown in the Figure 17.
44/63

Network Engineering
LEGEND:
Input
List of considered
events
Intermediate results
Output
Signaling messages parameters
Message size
Overhead size
Traffic load of an event
Traffic model parameters
Attach frequency
BHCA
Number of handovers etc.
Frequency of an event
C-Plane traffic as a
percentage of the U-Plane
Total U-Plane traffic
Total signaling load

DIMENSIONING BASED
ON THE RADIO I/F
THROUGHPUT
DIMENSIONING BASED ON THE USER TRAFFIC DEMAND
Figure 17 General concept of control plane traffic load calculations in LTE access
network.
2.2.3.2
C-Plane dimensioning based on the user traffic demand

The S1_MME interface is used to exchange signaling messages between the eNB and
MME needed for bearer management, mobility and security handling and transport of
NAS signaling messages between the UE and MME.
The X2_C interface is a logical connection used to exchange control information
between two eNBs participating in an inter-eNB handover.
Dimensioning approach is the same for both interfaces.
Steps for calculating the signaling load in LTE access network
Control plane traffic load on S1_MME and X2_C interfaces is calculated as a sum of
bandwidth portions of traffic load generated by selected events in the Busy Hour
multiplied by the number of subscribers. Overall procedure is impacted by:
45/63

Network Engineering
1. List of events causing the control plane traffic. Each event is described by a detailed
message flow and size of control messages, including the overhead (SCTP + IP +
(IPSec) + Eth). These parameters are used for calculating the traffic load per event
as a sum of lengths of all messages sent on each interface and direction.
Considered signaling events are:
Attach
Detach
Handover
Tracking Area Update
State transition
Paging
2. Frequency of each event per subscriber (Fevent [1/s]) is calculated based on the
traffic model. For every event the formula is different and is presented in this
chapter.
3. Traffic load per event resulting from multiplying the traffic load generated by the
event (Levent [bits]) with its frequency (Fevent [1/s]):
Equation 24
Tevent [ bps ] Levent Fevent

4. Total load of signaling traffic resulting from the events is multiplied by the total
number of subscribers (#UE [#]):
Equation 25
T bps # UE Tevent
event
where:
T [bps] is the total traffic load generated by the selected events on S1_MME/X2_C
interface,
Tevent [bps] is a traffic load generated by the event per subscriber,
#UE [#] is the total amount of subscribers.
Signaling events
Following subchapters explain a set of signaling events used for calculation of the
control plane load. Each subchapter contains following information:
Event load - is a total amount of data sent in each interface and direction without
transport overhead.
Event frequency this section will describe the formula and parameters used for
event frequency calculation.
46/63

Network Engineering
Attach/Detach (Non Access Stratum signaling)

These events are triggered when subscriber either attaches to or detaches from the
network.
Table 15 Event load: Attach/Detach.
Signaling load
[# of messages]
[bytes]
S1 (DL)
S1 (UL)
S1 (DL)
S1 (UL)
Attach
396
594
Detach
82
108
Attach/Detach
Event frequency:
It is assumed that frequency of Attach event is equal to Detach event and the Attach to
LTE_Active state is equal to Attach to LTE_Idle state. Default value can be found in
NSN Traffic Model.
Handover (Access Stratum signaling)
For C-plane calculations intra-eNB handover is not taken into calculations due to the
fact that no traffic is generated either in S1_MME or in X2_C interfaces. Only inter-eNB
handover is considered.
Table 16 Event load: Handover.
Signaling load
Inter eNB
handover
[# of messages]
[bytes]
[# of messages]
[bytes]
S1 (DL)
S1 (UL)
S1 (DL)
S1 (UL)
X2 (DL)
X2 (UL)
X2 (DL)
72
88
320
Event frequency:
The handover frequency per single call is being specified by user.
Tracking Area Update (Non Access Stratum signaling)

Tracking Area Update (TAU) procedure is used for tracking the location of moving UEs
while they are in the LTE_Idle state. A TAU can be either periodic (network access point
remains the same) or related to mobility (network access point changes).
Table 17 Event load: Tracking Area Update.
Signaling load
Tracking Area
Update
[bytes]
[# of messages]
S1 (DL)
S1 (UL)
S1 (DL)
S1 (UL)
60
90
Event frequency:
The handover frequency per single subscriber is being specified by user.
X2 (
13
47/63

Network Engineering
State Transitions (Access Stratum signaling)

LTE_Idle to LTE_Active
This procedure is used when there is user data to be sent to/from the UE while the UE
is in the LTE_Idle state. This procedure is initiated by either the UE (if it has uplink data
to send), or by the network (if there is downlink data waiting to be sent to the UE). Since
the user in LTE_Active can request next service without the change of state, the call
attempts from such users are skipped in calculation using the share of active
subscribers parameter.
Table 18 Event load: State Transitions.
Signaling load
LTE_Idle to
LTE_Active
[# of messages]
[bytes]
S1 (DL)
S1 (UL)
S1 (DL)
S1 (UL)
120
132
Event load is different according to the initiator. It is assumed that the event is triggered
by UE and Network equally.
Event frequency:
Equation 26
1
Idle _ to _ Active _ Load BHCAU plane
s
LTE_Active to LTE_Idle
Table 19 Event load: LTE_Active to LTE_Idle.
Signaling load
[bytes]
[# of messages]
LTE_Active to
LTE_Idle
S1 (DL)
S1 (UL)
S1 (DL)
S1 (UL)
40
78
Event frequency:
Assuming constant share of active subscribers, the amount of LTE_Idle to LTE_Active
state changes is equal to the reverse event.
Impact of smartphones on number of state transitions.
Smartphones load the network in new way. Their always-on applications rely on keepalive messages to keep the connectivity open. On the other hand, to preserve the
battery, the fast dormancy features have been introduced by UE vendors. With that
feature, shortly after data transmission is over, the smartphone UE goes to the idle
mode. messages sent by application cause reverse state change to active mode. These
additional events are accounted in c-plane dimensioning based on the equation below:
48/63

Network Engineering
Equation 27
0
1
sm _ msg 3600
s time _ msg
if time _ msg RRC _ release _ timer

if time _ msg RRC _ release _ timer
where:
sm_msg [#] additional state transitions caused by smart application messages
time_msg [s] time between smart application messages
RRC_release_timer [s] - inactivity timer after which the UE is moved to

RRC_Idle state
Equation 28
0
1
3600
sm _ k a _ msg
s time _ keep alive _ msg
if time _ keep alive _ msg RRC _ release _ timer

if time _ keep alive _ msg RRC _ release _ timer
where:
sm_k-a_msg [#] additional state transitions caused by smart application keep

alive messages
time_msg [s] time between smart application keep alive messages
RRC_release_timer [s] - inactivity timer after which the UE is moved to

RRC_Idle state
Equation 29
1
sm _ events sm _ msg sm _ k a _ msg
s
where:
sm_events [#] additional state transitions caused by smartphone users
Note 1:
If the keep-alive_interval parameter is smaller than the RRC_release_timer, no
additional events are considered as the RRC_release_timer will never expire (Figure
18):
49/63

Network Engineering
time between messages < RRC release timer

time between
messages
time between
messages
RRC
connected
call /
session
RRC idle
RRC release
timer
Figure 18 Relation of time between messages and RRC_release_timer parameters.
Note 2:
If the keep-alive_interval parameter is greater than the RRC_release_timer, the
additional events are added to the total number of state transitions. Only the Idle users
are considered, as users who actively exchange data with network cannot go to idle
mode (RRC_release_timer will not expire) (Figure 19):
50/63

Network Engineering
time between messages RRC release timer

time between
messages
time between
messages
RRC
connected
call /
session
RRC idle
RRC release
timer
RRC release
timer
State transitions
active->idle / idle->active
Figure 19 Relation of time between messages and RRC_release_timer parameters.
Paging (Non Access Stratum signaling)

A UE in the LTE_Idle state is traceable only to its registered TAs. Every time the EPC
needs to initiate contact with a UE which is in LTE_Idle state, a paging procedure is
initiated.
Table 20 Event load: Paging.
Signaling load
Paging
[# of messages]
[bytes]
S1 (DL)
S1 (UL)
S1 (DL)
S1 (UL)
60
Event frequency:
Equation 30
1
Paging retry _ factor TAcp TAsize MTCSF BHCAU Plane
s
where:
retry_factor [#] is an average number of repeated pagings due to subscriber

unavailability.
51/63

Network Engineering
Default value given by NSN default traffic model: retry_factor = 1,1 [#]
TACP [#] is number of Tracking Areas under a network paging control point
(MME, eNB).
Default value given by NSN default traffic model: TACP = 1 [#]
TAsize [#] is number of eNBs in one Tracking Area.

Default value given by NSN default traffic model: TAsize = 20 [#]
MTCSF [%] is a Mobile Terminated Call Share of requested Service Flows.

Default value given by NSN default traffic model: MTCSF = 15 [%]
2.2.3.3
BHCAU-plane [#] is a sum of BHCA of all applications per subscriber. The same
parameter as used for state transitions calculations.
C-Plane dimensioning based on the Radio interface throughput

When using this option, the C-Plane traffic is defined as a percentage of the average UPlane traffic. Traffic of the S1_MME interface is specified as a percentage of the S1_U
traffic:
Equation 31
S1 _ MME _ DL[ kbps ] CP _ Share[%] S1 _ U _ DLALL _ AVG

Equation 32
S1 _ MME _ UL[ kbps ] CP _ Share[%] S1 _ U _ ULALL _ AVG

To make the C-Plane traffic independent from the selected dimensioning option
(ALL_AVG, ALL_AVG_/_SINGLE_PEAK, SINGLE_PEAK_+_ALL_BUT_ONE_AVG,
ALL_PEAK), the average S1_U traffic in (Equation 31) (Equation 32) is always
calculated using ALL_AVG option. Referring to an Equation 16 and Equation 17 one
gets:
Equation 33
S1 _ U _ DLALL _ AVG [ kbps ] eNB _ Transport _ Capacity _ DLALL _ AVG X 2 _ U _ DL _ in
Equation 34
S1 _ U _ ULALL _ AVG [ kbps ] eNB _ Transport _ Capacity _ ULALL _ AVG X 2 _ U _ DL _ out

From (Equation 31) (Equation 32) and (Equation 33) - (Equation 34) one gets:
52/63

Network Engineering
Equation 35
S1_MME_DL [kbps] =
2 CP _ Share[%]
2 HO _ Share[%]
Equation 36
S1_MME_UL [kbps] = CP_Share [%]
HO _ Share[%]
eNB _ Transp _ Cap _ ULALL _ AVG 2 HO _ Share[%] eNB _ Transp _ Cap _ DLALL _ AVG
Signaling traffic on the X2 interface due inter-eNB handovers for downlink is calculated
as a percentage of the downlink X2 U-Plane traffic:
Equation 37
X2_C_DL_in [kbps] = CP_Share [%] X2_U_DL_in

Equation 38
X2_C_DL_out [kbps] = CP_Share [%] X2_U_DL_out

From (Equation 21):
Equation 39
X2_C_DL_in [kbps] = X2_C_DL_out[kbps] =

CP _ Share[%] HO _ Share[%]
2 HO _ Share[%]
For uplink, it is calculated from the X2_C downlink traffic using the ratio of X2 signaling
flows for uplink and downlink derived from the analysis of the message flows (refer to
Sec. 2.2.3.2):
Equation 40
X2_C_UL [kbps] = X2_C_DL X2_C_UL_ : _DL_ratio

From (Equation 39):
Equation 41
X2_C_UL_in[kbps]= X2_C_UL_out[kbps]= 0.716

CP _ Share[%] HO _ Share[%]
2 HO _ Share[%]
53/63

Network Engineering
2.2.4
O&M I/F dimensioning

For the M-Plane bandwidth it is recommended to allocate extra 1Mbps at the eNB side,
as defined in [LTE_Transp_SFS]. This is specified on the O&M application level, so the
additional transport overhead needs to be added. Note, that O&M traffic is not included
in tool calculation results.
2.2.5
S-plane dimensioning
S-plane interface is in use with Timing over Packet (ToP) standard. For dimensioning,
very straightforward approach is adopted. Having the rate of messages and their
lengths with transport overhead, the required interface capacity can be derived. Below
one can find calculation details.
2.2.5.1
Timing over Packet

The calculation is defined by Equation 42:
Equation 42
BW _ ToP[ kbps ] PTP _ sync _ msg _ size Trs _ OH PTP _ sync _ msg _ rate
PTP _ announce _ msg _ size Trs _ OH PTP _ announce _ msg _ rate

where:
BW_ToP [bps] is the transport capacity required for s-plane interface,

PTP_sync_msg_size [bits] is a PTP synchronization message size,
PTP_announce_msg_size [bits] is a PTP announce message size,
PTP_sync_msg_rate [1/s] is a frequency of synchronization messages,
PTP_announce_msg_rate [1/s] is a frequency of announce messages,
Trs_OH [bits] is a transport overhead.
Exemplary calculation:
The values used below are defaults. For some configurations they can
vary.PTP_announce msg_size:
544 [bits]
PTP_sync_msg_size:
352 [bits]
PTP_announce_msg_rate:
0,5 [1/s]
PTP_sync_msg_rate:
16 [1/s]
Trs_OH (Eth+IP+UDP):
336+160+64 = 560 [bits]
Equation 43
BW _ ToP (( 544 560 ) 0,5 ( 352 560 ) 16 ) / 1000 16 [ kbps ]

2.2.5.2
Synchronous Ethernet
Although Synchronous Ethernet is not in use with S-plane interface, it may be used
instead of the ToP standard for synchronization purposes. Therefore appropriate
calculation is shown below.
54/63

Network Engineering
The calculation is defined by Equation 44:

Equation 44
BW _ SyncE [ kbps ] ( SSM _ PDU _ size SSM _ Hdr _ size ) SSM _ msg _ rate
where:
BW_SyncE [bps] is the transport capacity required for synchronization,

SSM_PDU_size [bits] is a SSM synchronization message size,
SSM_msg_rate [bits] is a frequency of synchronization messages,
SSM_Hdr_size [bits] is an SSM message header length.
Exemplary calculation:
The values used below are default ones. For some configurations they can vary.
SSM_PDU_size:
SSM_msg_rate:
SSM_Hdr_size:
6104 [bits]
5 [1/s]
224 [bits]
Equation 45
BW _ SyncE [ kbps ] (( 6104 224 ) 5 ) / 1000 8 [ kbps ]
2.2.6
Resulting eNB transport capacity

Dimensioned bandwidth of the logical interfaces is distributed to the uplink and downlink
part of the eNBs transport card, as depicted in Figure 20.

Network Engineering
55/63
Radio side
( eUTRAN)
Transport side
( ePC)
FTM Flexi BTS Transport Sub-Module
eNB
eNB
S1_U_UL
X2_C_out_DL
X2_U_out
S1_ MME_UL
X2_C_out_UL
X2_U_out
S1_U_UL
S1_ MME_UL
X2_U_out
S1_U_ DL - X2_U_out
X2_C_out_DL
FTM
(FTIB or
FTLB)
X2_C_in_UL
UL
S1_U_DL
S1_U_DL
S1_ MME_DL
S1_U_ DL - X2_U_out
S1_ MME_DL
X2_U_in
X2_C_out_UL
X2_C_in_DL
X2_C_in_UL
X2_C_in_DL
a)
DL
X2_U_in
Logical flow distribution across eNB
b)
Allocation to the eNBs transport interface
Figure 20 Distribution of the eNB traffic between UL and DL parts of the eNB transport
card: a) logical flow distribution, b) allocation to the eNB transport interface.
Based on Figure 20, the transport capacities to be set for UL and DL parts of the eNB
transport card can be figured out.
2.2.7
Front mile dimensioning

Front mile dimensioning is possible for the methodology based on user traffic demand
only. It is not available for calculation based on radio interface throughputs as this
simplified approach provides the rough estimation only without accounting any QoS
requirements.
Dimensioning of front mile link in fact means dimensioning of S1 interface at
aggregation node (e.g. router, switch). The point of this calculation is to observe, what
multiplexing gain can be achieved by the aggregation of several eNBs.
Suppose that in order to provide the required level of service (defined by the QoS
requirements) to a given traffic mix (t1) the transport link capacity should be at least C1,
whereas in case of another traffic mix (t2) the required transport link capacity is different,
C2. If the traffic mix t1 and t2 is multiplexed on a common transport link and the resulting
traffic mix can be served with a transport link capacity C and:
Equation 46
C C1 C2
then the difference (C1 + C2) - C indicates the benefit resulting from traffic aggregation.
56/63

Network Engineering
The dimensioning algorithm finds the lowest front mile link capacity that is still able to
provide the required level of service to all aggregated eNBs. Calculation methodology
proposed here applies exactly the same models as for last mile dimensioning, extended
with one step to calculate the multiplexing gain. M/D/1/MDErlang models are used for
Real-Time services and M/G/R-PS for non-Real-Time; necessary modification and
adjustment of input parameters is shown below. The description focuses on the
differences comparing to the last mile dimensioning.
Note:
In order to obtain the statistical multiplexing gain both, last and front mile,
links capacities are required. Due to the fact, that the QoS target may be
different for last and front mile, the referenced last mile result, used for
multiplexing gain calculation, is re-calculated with front mile delay target.
Front Mile dimensioning RT U-Plane traffic with M/D/1 and MDErlang

Front Mile RT U-Plane capacity is calculated as a sum of the capacity portions occupied
by individual RT services summarized from all eNBs:
Equation 47
FM _ S1 _& X 2 _ Capacity _ RT [ kbps ] { S1 _& _ X 2 _ Capacity _ RTeNB ,Service }

eNB Service
Aggregated from all eNBs RT capacity per service is calculated using either the
MDErlang formula (for all RT GBR services, Equation 48) or the M/D/1 formula [MD1]
(for RT non-GRB services, Equation 49)
Equation 48
FM _ S1 _& _ X 2 _ Capacity _ RTGBRService [ kbps ]

eNB
MDErlang{ S1 _& _ X 2 _ traffic _ load S
peak _ rate Service,blocking _ probabilit y S
where:
S1_&_X2_traffic_load
and X2.interfaces.
Service
[kbps] is the user traffic demand per service on S1
peak_rate Service [kbps] is a service peak rate.

blocking_probability [#] is a probability of block of incoming call.
Equation 49
FM _ S1 _& _ X 2 _ Capacity _ RTService [ kbps ] M / D / 1{ packet _ delay Service , packet _ sizeServi
S1 _& _ X 2 _ traffic _ load

eNB
where:
eNB ,Service
, PHB _ weight Service, S1 _ U _ OH Service }
57/63

Network Engineering
packet_delay Service [ms] is the max tolerable transport delay of IP packets on the
front mile link. It is the assumed QoS target for dimensioning the RT traffic,
specified separately for each service class. Default value (for each service class)
is 15 ms.
packet_size
Service
[bytes] is the average size of an IP packet per service.
eNB ,Service
[kbps] is the user traffic demand per service
eNB
on S1 and X2 interfaces summarized from all aggregated eNBs.

PHB_weight Service [#] is the weight of the DiffServ scheduler queue that serves
the QoS class of the service; it determines the bandwidth available to that QoS
class during the congestion (i.e. all queues fully occupied with traffic).
S1_U_OH Service [%] is the S1_U transport overhead per service.
Note:
The same PHB scheduling weights are applied for all eNBs as well as for
aggregation point.
Figure 21 below illustrates the workflow for dimensioning of RT services at aggregation

point. Red marking indicates the modification comparing to the Figure 11.
eNB,Service[kbps]
eNB
packet_delay Service [ms]

packet_size Service [bytes]
PHB_weight Service
M/D/1
FM_S1_&_X2_Capacity_RT Service [kbps]
S1_U_OH Service [%]
Figure 21 Front Mile S1_U dimensioning with RT traffic using M/D/1.
When looking at last and front mile links dimensioning, two major differences can be
found:
no comparison of offered user traffic load against the average radio cell
capacity. This step is already performed during LM link calculation, therefore no
need to repeat this.
input parameter: traffic load per service is a sum of traffic from all users served
by aggregated eNBs.
Front Mile dimensioning NRT U-Plane traffic with M/G/R-PS
58/63

Network Engineering
As the same model is applied for front mile dimensioning, the dimensioning process is
very similar to the one used in 2.2.2.1. Red marking indicates the modification
comparing to the Figure 11.
Total_U-Plane_traffic_per_cell [kbps]
ave_cell_throughput [kbps]
Uu_OH Service [%]
QCI_weight
Weighted
M/G/1-PS
S1_&_X2_traffic_load_per_cell [kbps]
r_peak Service
S1-U_OH Service [%]
eNB
Target Packet DelayPHB Service[ms]

PHB(Service)
[kbps]
M/G/R-PS
PHB_weight Service
S1_&_X2_e2eDelay_NRT Service [kbps]

S1_&_X2_e2eDelay_NRT_min Service [kbps]
file_size Service [kbytes]
TN Delay
estimation
S1_&_X2_Capacity_NRTService[kbps]
Figure 22 Front Mile S1_U dimensioning with NRT traffic using M/G/R-PS.
The differences are:
no comparison of offered user traffic load against the average radio cell
capacity. This step is already performed during LM link calculation, therefore no
need to repeat this.
input parameter: traffic load per PHB is a sum of traffics from all users served by
aggregation point:
Equation 50

eNB
PHB ( Service )
S1 _& _ X 2 _ traffic _ load PHB ( Service ) _ eNB i

i 1
where:
o k number of aggregated eNBs
aggregated eNBs (traffic sources) can have different traffic behavior (e.g.
ave_cell_throughput). For each eNB i, the appropriate set of parameters is being
used for M/G/R-PS and the resulting front mile bandwidth is weighted by the
load of individual eNB:
Equation 51
k
FM _ BWNRT FM _ BWNRT (i )*
i 1
Load _ eNB(i)
k
Load _ eNB( j)
j 1
59/63

Network Engineering
where:
FM_BWNRT [kbps] is a resulting front mile capacity of NRT services,
k [#] is a number of aggregated eNBs,
2.2.7.1
Multiplexing gain calculation

The rate with which the eNB (traffic source) generates data packets is not constant in
time, but forms bursts on a lower time scale. The resulting aggregated bandwidth is
lower than the sum of individual links. Due to this fact, the required bandwidth of a link
does not increase linearly with the number of simultaneous sessions. This is graphically
illustrated in Figure 23.
Figure 23 Source of statistical multiplexing gain.
The multiplexing gain calculation is a very last step of front mile dimensioning. Having
the last and front mile link capacities, one can calculate the statistical multiplexing gain
resulting from merging the traffic from several sources:
Equation 52
Aggregated _ BW
Multiplexi ng _ gain [%] 1
Bw _ 1 .. Bw _ n
where:
Aggregated_BW [kbps] is the resulting front mile link capacity,
Bw_... [kbps] are the transport capacities of eNB last mile links.
The resulting multiplexing gain value indicates how much the traffic from several
sources can be squeezed and what saving can be achieved on front mile link.
60/63

Network Engineering
2.2.7.2
Load distribution factor (LDF)

In real-life networks, the daily traffic of eNBs is distributed unevenly within the network,
i.e. for each eNB the busy hour occurs at different time of a day. So far, for front mile
link capacity calculation the only gain taken into account was the advantage of
multiplexing several sources at one point. Therefore, also the gain from uneven traffic
distribution should be accounted, as current solution can easily lead to overdimensioning.
Calculation with even load distribution
This approach assumes the worst case scenario, when busy hours of all aggregated
eNBs are at the same time of a day:
Figure 24 Even load distribution.
One can see in the Figure 24, the even traffic distribution results in high traffic demand
during busy hour at aggregation point. This solution would satisfy link requirements for
extreme cases; however, when considering the larger amount of eNBs, such situation is
highly improbable.
Calculation with uneven load distribution
61/63

Network Engineering
When considering more realistic approach of uneven traffic load distribution in time
across the network, one can observe (Figure 25) that the load at aggregation point is
quite evenly spread out. The reason behind this is that the busy hours of multiple eNBs
occur at different time of a day:
Figure 25 Uneven load distribution.

The difference between the traffic demand calculated by even load distribution and
uneven load distribution is called the Load Distribution Factor (LDF):
Figure 26 Difference between even and uneven traffic load distribution at aggregation
point.
Equation 53
62/63

Network Engineering
LDF
A
B
where:
A [kbps] traffic load at aggregation point for even load distribution case,
B [kbps] traffic load at aggregation point for uneven load distribution case,
LDF is applied for link capacity estimation at the aggregation point and is used in
dimensioning process for accounting the impact of traffic distribution over the time. As
the LDF factor indicates, how the traffic load from particular eNBs can be decreased, it
should be applied before front mile calculations and multiplexing gain calculations.
Therefore, for dimensioning cases with Load Distribution Factor applied, the input
parameter: traffic load per PHB queue presented in Equation 50 is re-calculated:
Equation 54
PHB ( Service )
eNB
S1 _& _ X 2 _ traffic _ load PHB ( Service ) _ eNB i
i 1
LDF
The rest of dimensioning process described above remains unchanged.

2.2.7.3
Aggregation Point dimensioning

Front Mile dimensioning is a special case of Aggregation Point dimensioning.
Aggregation point can be any point in the network aggregating traffic from at least two
base stations, even at one site. The same dimensioning methodology as for Front Mile
is applied also for any aggregation point. However, special care should be taken when
configuring the QoS targets for dimensioning, e.g. e2e packet delay has to be split
between all the transport links on the traffic path. Additional step called Aggregation
Point has been added to the tool before the Front Mile dimensioning step with the
possibility to configure any number of base stations within the selected areas. In
addition separate QoS delay target can be configured in the Services step.
Depending on the topology and configuration, handover traffic may be included in the
aggregation point dimensioning. It can be optionally enabled in the Dimensioning Tool.
LDF shall be applied only for the aggregation points which accumulate traffic from
several areas including many base stations (e.g. over hundred). It is not included in the
aggregation point dimensioning in the Dimensioning Tool.
63/63

Network Engineering
Abbreviations
AMBR
BTS
DRB
eNB
EPC
ISD
LDF
LTE
MBR
MDErlang
MME
MTU
O&M
PDCP
PDN GW
PHB
QCI
QoS
RRC
RTP
SAE
SAE-GW
SCTP
SYNC-E
TCP
ToP
UDP
WFQ
Aggregated Maximum Bit Rate

Base Transceiver Station
Data Radio Bearer
Evolved Node B
Evolved Packet Core
Inter Site Distance
Long Term Evolution
Maximum Bit Rate
Multidimensional Erlang B formula
Mobility Management Entity
Maximum Transmission Unit
Operation and Maintenance
Packet Data Convergence Protocol
Packet Data Network Gateway
Per Hop Behavior
QoS Class Indicator
Quality of Service
Radio Resource Control
Real-Time Transport Protocol
System Architecture Evolution
SAE Gateway
Stream Control Transmission Protocol
Synchronous Ethernet
Transmission Control Protocol
Timing over Packet
User Datagram Protocol
Weighted Fair Queuing

LTE Access Transport Fffdimensioning Guideline

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

LTE Access Transport Fffdimensioning Guideline

Hochgeladen von

Copyright:

Verfügbare Formate

1/63

MBB Customer Support