1/63

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

Dimensioning Guideline
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
 RL30 / RL25 – approved
 RL40 – approved
 RL50 / RL35 – approved

Please always check the latest version of this document under the following link: here

2/63

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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 clock’s
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),

MBB Customer Support
Network Engineering


Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

(*) IPSec is optional

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

(*) IPSec is optional

Figure 2 U-Plane (UP), C-Plane (CP) and M-Plane (MP) protocol stacks in LTE Access.

8/63

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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 clock’s
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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

1

Conversational Video

2

LTE Transport domain
Resource
Type

DSCP

DiffServ
PHB

Ethernet
p-bits

46

EF

7

36

AF42

5

Not supported
in RL10

GBR
Non-conversational Video

3

26

AF31

3

Real Time Gaming

4

46

EF

7

IMS signaling

5

34

AF41

4

Voice, video, interactive
gaming

6

18

AF21

2

Video (buffered streaming)

7

28

AF32

3

TCP-based (e.g. www, email, ftp, p2p file sharing,
etc.

8

10

AF11

1

9

0

BE

0

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

1

46

EF

7

Conversational Video

2

36

AF42

5

Non-conversational Video

3

26

AF31

3

Not supported

Real Time Gaming

4

46

EF

7

in RL20

IMS signaling

5

34

AF41

4

Voice, video, interactive
gaming

6

18

AF21

2

Video (buffered streaming)

7

28

AF32

3

TCP-based (e.g. www, email, ftp, p2p file sharing,
etc.

8

10

AF11

1

9

0

BE

0

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)
Feature impact to the Dimensioning Tool:
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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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.
Feature impact to the Dimensioning Tool:
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.
Feature impact to the Dimensioning Tool:
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).
Feature impact to the Dimensioning Tool:
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.
Feature impact to the Dimensioning Tool:
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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

RL30 / RL25 features

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.
Feature impact to the Dimensioning Tool:
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.
Feature impact to the Dimensioning Tool:
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).
Feature impact to the Dimensioning Tool:
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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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
results with ~64 [kbps] additional throughput
• Max TWAMP bandwidth configuration (single TWAMP session per BTS with highest
rate and biggest packet size)
results with ~120 [kbps] additional throughput
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.
Feature impact to the Dimensioning Tool:
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.
Feature impact to the Dimensioning Tool:
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.
Feature impact to the Dimensioning Tool:

18/63

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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.
Feature impact to the Dimensioning Tool:
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

RL50 / RL35 features

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.
Feature impact to the Dimensioning Tool:
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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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 clock’s
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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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
Features configuration
Services
Traffic demand
Transport configuration
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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

2.1.1.5

Transport configuration
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.
Transport configuration
parameters
Number of sites

Number of cells per site
Average cell throughput
[kbps]

Default value

N/A

3

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
putted by user or automatically copied from
radio dimensioning results

Defines the cell peak throughput. To be
N/A

VLAN tag

Comment

Enabled
QCI
Dependent
PHB
dependent
PHB
dependent

putted by user or automatically copied from
radio dimensioning results
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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

1

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.

Load Distribution Factor
(LDF)

2.1.2

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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:

-

o

the amount of Radio (Uu) and Transport (S1/X2) overheads,

o

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

 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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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 interface’s 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.

MBB Customer Support
Network Engineering

36/63

Note:

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering


Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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 Radiobased [ 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.

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

eNB U-Plane transport

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.

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

The calculated U-Plane transport capacity should be:
Equation 14

eNB _ U _ PlaneTransport _ Capacity Radiobased [ kbps ]  [ peak _ cell _ throughput 
(# _ of _ cells _ per _ eNB  1 )  avg _ cell _ throughput ]  ( 1  Uu _ OH ) 
( 1  S1 _ U _ OH )

Cell average

eNB U-Plane transport

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 Radiobased [ kbps ]  (# _ of _ cells _ per _ eNB 
peak _ cell _ throughput )  ( 1  Uu _ OH )  ( 1  S1 _ U _ OH )
The “All Peak” option is illustrated in Figure 15.

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

Cell peak

eNB U-Plane transport

MBB Customer Support
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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

Equation 22

S1 _ U _ DLOption [ kbps ]  eNB _ Transport _ Capacity _ DLOption 
HO _ Share[%]
 eNB _ Transport _ Capacity _ DLALL _ AVG
2  HO _ Share[%]
Equation 23

S1 _ U _ ULOption [ kbps ]  eNB _ Transport _ Capacity _ ULOption 
HO _ Share[%]
 eNB _ Transport _ Capacity _ DLALL _ AVG
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 operator’s choice and depends on the availability
of input data and the operator’s 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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

4

6

396

594

Detach

2

2

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)

1

1

72

88

2

2

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)

1

1

60

90

Event frequency:
The handover frequency per single subscriber is being specified by user.

X2 (

13

47/63

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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)

1

2

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)

1

2

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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)

1

0

60

0

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

Equation 35

S1_MME_DL [kbps] =

2  CP _ Share[%]
 eNB _ Transport _ Capacity _ DLALL _ AVG
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[%]
 eNB _ Transport _ Capacity _ DLALL _ AVG
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[%]
 eNB _ Transport _ Capacity _ DLALL _ AVG
2  HO _ Share[%]

53/63

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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.

MBB Customer Support
Network Engineering

55/63

Radio side
( eUTRAN)

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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 eNB’s 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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

 S1 _& _ X 2 _ traffic _ load

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.

Σ S1_&_X2_traffic_load

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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 [%]

Σ S1_&_X2_traffic_load
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

 S1 _& _ X 2 _ traffic _ load
eNB

k

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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.

Load Distribution Factor
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

MBB Customer Support
Network Engineering

LDF 

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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

 S1 _& _ X 2 _ traffic _ load

PHB ( Service )

eNB

k

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

MBB Customer Support
Network Engineering

Dimensioning Guideline
For internal use only
APPROVED, 09.05.2013

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
Load Distribution Factor
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