LTE Access Transport fffDimensioning Guideline

MBB Customer Support Network Engineering

Dimensioning Guideline For internal use only

APPROVED, 09.05.2013

1/63

LTE Access Transport RL10 – approved

RL20 / RL15 – approved


RL40 – approved


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

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

https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D474249202

2/63




Revision History

Version Date Change Notes

1.0 09.05.2013 Approved version

Authors

Name Department

Dominik Dulas MBB CS NetEng Transport

Szymon Listwan MBB CS NetEng Transport

3/63




Table of contents

1.1 LTE Access Network reference model .......................................................... 5 1.1.1 S1_U interface (eNB ↔ SAE-GW) ................................................................ 8 1.1.2 S1_MME interface (eNB ↔ MME) ................................................................ 8 1.1.3 X2_U interface (source eNB ↔ target eNB) .................................................. 8 1.1.4 X2_C interface (source eNB ↔ target eNB) .................................................. 8 1.1.5 O&M interface (eNB ↔ O&M system) ........................................................... 8 1.1.6 S-Plane interface (eNB ↔ Signal Reference Clock) ..................................... 8 1.2 Flexi LTE BTS overview ............................................................................... 8 1.2.1 Flexi LTE BTS transport architecture. ........................................................... 9 1.2.2 Flexi LTE BTS transport capacity limits ...................................................... 10 1.3 Feature impact to LTE Access dimensioning .............................................. 10 1.3.1 RL10 features ............................................................................................. 11 1.3.2 RL20 / RL15 features ................................................................................. 14 1.3.3 RL30 / RL25 features ................................................................................. 16 1.3.4 RL40 features ............................................................................................. 17 1.3.5 RL50 / RL35 features ................................................................................. 18 2.1 LTE Access dimensioning workflow ............................................................ 20 2.1.1 Definition of input parameters ..................................................................... 21 2.1.2 Definition of output parameters ................................................................... 27 2.2 LTE Access dimensioning methodology ..................................................... 28 2.2.1 General concept ......................................................................................... 28 2.2.2 U-Plane traffic dimensioning: S1_U and X2_U interfaces ........................... 30 2.2.3 C-Plane dimensioning: S1_MME and X2_C interfaces ............................... 43 2.2.4 O&M I/F dimensioning ................................................................................ 53 2.2.5 S-plane dimensioning ................................................................................. 53 2.2.6 Resulting eNB transport capacity ................................................................ 54 2.2.7 Front mile dimensioning .............................................................................. 55

4/63




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

Buffer 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 (E-

UTRA); 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




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

U 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),

6/63




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

eNB

eNB

MME

SAE-GW

S1_MMEX

2_

U

X2_

C

O&M

O&M i/f

O&M i/f

S1_U

Evolved UTRAN Evolved Packet Core

La

st m

ile lin

k

SAE-GW – SAE Gateway

MME – Mobility Management Entity

eNB – evolved Node B

F

ron

t m

ile lin

k

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




MMEMME

SAE-GWSAE-GWeNB 1 eNB 2

eNB 2

eNB 2eNB 1

GTP-U

UDP

IP

IPSec (*)

L1/L2

GTP-U

UDP

IP

IPSec (*)

L1/L2

GTP-U

UDP

IP

IPSec (*)

L1/L2

GTP-U

UDP

IP

IPSec (*)

L1/L2

X2-U S1-U

eNB 1

MMEMME

LTE U-Plane

LTE C-Plane

S1-AP

SCTP

IP

IPSec (*)

L1/L2

S1-AP

SCTP

IP

IPSec (*)

L1/L2

S1-MME

X2-AP

SCTP

IP

IPSec (*)

L1/L2

X2-AP

SCTP

IP

IPSec (*)

L1/L2

X2-C

(*) IPSec is optional


eNB 1 eNB 2

Mgmt. Appl.

UDP/TCP

IP

IPSec (*)

L1/L2

Mgmt. Appl.

UDP/TCP

IP

IPSec (*)

L1/L2

Mgmt. Appl.

UDP/TCP

IP

IPSec (*)

L1/L2

O&M i/f O&M i/f

LTE M-Plane

NetActNetAct


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

8/63




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




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

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

S1, X2

10/63




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

Max. number of cells per BTS 3 (*) (**)

6 (***) -

Max. number of active users per BTS cell at

20Mhz

800 (*)

840 (**) (***)

RRC_connected

users with a DRB

established

Max. number of actively scheduled users per BTS

cell at 20Mhz

200 (*)

250 (**) (***)

Users scheduled in

the time domain by

the RRC scheduler;

subset of Active

users.

Max eNB transport capacity towards the Core 1000 Mbps

Number of GbE

interfaces at the eNB

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




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)

Operator specific QCI (LTE518)

Transport admission control (LTE144)

IP Transport network measurements

(LTE574)

Ethernet Jumbo frames (LTE931)

Support of QCI 2, 3 and 4 (LTE496)

Smart admission control (LTE497)

Multiple GBR EPS bearers per UE

(LTE587)

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)

RL09/RL10 RL20/RL15

RL40

Note: Only features impacting the LTE Access Dimensioning are shown.

LTE Transport Feature summary

RL30/RL25

Transport separation for RAN sharing

(LTE505)

RL50/RL35

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




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

P-GWS-GW Peer

Entity

UE eNB

EPS Bearer

Radio Bearer S1 Bearer

End-to-end Service

External Bearer

Radio S5/S8

Internet

S1

E-UTRAN EPC

Gi

E-RAB S5/S8 Bearer

13/63




number of services and users supported per cell. No CAC on S1 means no blocking-based 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.

6Voice, video, interactivegaming

GBR

4Real Time Gaming

9

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

non-GBR7Video (buffered streaming)

5IMS signaling

3Non-conversational Video

2Conversational Video

ResourceType

QCILTE Traffic Class

1Conversational Voice

LTE Radio domain


GBR

4Real Time Gaming

9



5IMS signaling



ResourceType



LTE Radio domain

3AF3228

2AF2118

4AF4134

0BE0

1AF1110

7EF46

3AF3126

5AF4236

Ethernet p-bits

DiffServPHB

DSCP

7EF46

LTE Transport domain

3AF3228

2AF2118

4AF4134

0BE0

1AF1110

7EF46

3AF3126

5AF4236

Ethernet p-bits

DiffServPHB

DSCP

7EF46


Not supported

in RL10


GBR

4Real Time Gaming

9



5IMS signaling



ResourceType



LTE Radio domain


GBR

4Real Time Gaming

9



5IMS signaling



ResourceType



LTE Radio domain

3AF3228

2AF2118

4AF4134

0BE0

1AF1110

7EF46

3AF3126

5AF4236

Ethernet p-bits

DiffServPHB

DSCP

7EF46


3AF3228

2AF2118

4AF4134

0BE0

1AF1110

7EF46

3AF3126

5AF4236

Ethernet p-bits

DiffServPHB

DSCP

7EF46


Not supported

in RL10

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




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 non-GBR 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.


GBR

4Real Time Gaming

9



5IMS signaling



ResourceType



LTE Radio domain


GBR

4Real Time Gaming

9



5IMS signaling



ResourceType



LTE Radio domain

3AF3228

2AF2118

4AF4134

0BE0

1AF1110

7EF46

3AF3126

5AF4236

Ethernet p-bits

DiffServPHB

DSCP

7EF46


3AF3228

2AF2118

4AF4134

0BE0

1AF1110

7EF46

3AF3126

5AF4236

Ethernet p-bits

DiffServPHB

DSCP

7EF46


Not supported

in RL20

Supported in RL20

with LTE010


GBR

4Real Time Gaming

9



5IMS signaling



ResourceType



LTE Radio domain


GBR

4Real Time Gaming

9



5IMS signaling



ResourceType



LTE Radio domain

3AF3228

2AF2118

4AF4134

0BE0

1AF1110

7EF46

3AF3126

5AF4236

Ethernet p-bits

DiffServPHB

DSCP

7EF46


3AF3228

2AF2118

4AF4134

0BE0

1AF1110

7EF46

3AF3126

5AF4236

Ethernet p-bits

DiffServPHB

DSCP

7EF46


Not supported

in RL20

Supported in RL20

with LTE010

Figure 7 Service differentiation options supported in RL20 / RL15 for LTE Access Transport.

Feature impact to the Dimensioning Tool:

‘Per-user’ service differentiation (premium vs. basic users) supported in the RL10 version has been changed to the ‘per-service’ differentiation: when defining the services in the tool, a user has possibility to assign to each service a QCI from the supported set (QCI 6-9; QCI 5, which is assumed to be used by the IMS signaling, is excluded from the set). Selected QCIs are then associated with respective DiffServ PHB classes, for which WFQ transport scheduler weights and dimensioning QoS targets

(packet/application transfer delays) can be explicitly specified by the user.

1.3.2.2 Support of EPS bearers for conversational voice (LTE010) LTE010 allows the support of data bearers with QCI = 1 for voice services. With this feature the number of QCIs for user data supported in RL20 / RL15 is increased to six:

QCI1 and QCI5 - QCI9 (see Figure 7)


If the feature activated, the Voice service is automatically assigned QCI = 1 and the voice traffic is handled with the highest priority by the transport scheduler (Expedited

Forwarding PHB).

15/63




1.3.2.3 QoS aware Ethernet switching (LTE649) This feature allows QoS-aware Ethernet switching between external ports of the BTS. It can be used for BTS co-location/chaining without the need for additional switching equipment.


By implementing this feature, eNB co-location / chaining is possible. Aggregated

bandwidth of N co-located eNBs is calculated.

1.3.2.4 Intra-LTE handover via S1 (LTE054) This feature supports inter-eNB handovers over S1 interface in case there is no X2 connectivity between a pair of neighboring eNBs.


With this feature both X2 and S1 inter-eNB handovers are supported. The overall user traffic due to inter-eNB handovers is split between X2 and S1 portions based on the user-defined input and the corresponding X2 and S1 capacities are appropriately tuned. Also the C-Plane traffic is modified to account for S1 handovers. Based on the user-defined input a part of the signaling traffic is subtracted from the X2_C and added to the S1_MME interface.

1.3.2.5 Rate capping UL/DL (LTE013) With these feature BTS can limit uplink and downlink bit rate of non-GBR bearers per

UE below the signaled UE-Aggregate Maximum Bit Rate (UE-AMBR).


Impact of the UE-AMBR parameter is included in the dimensioning: maximum bit rate available to a UE is limited to the specified UE-AMBR value.

1.3.2.6 RL20 / RL15 Capacity and Dimensioning (LTE458) The feature specifies performance and capacity parameters to be supported by RL20

release.


The parameters that have impact to the LTE Access dimensioning are limited (i.e. upper-bounded) to the values specified by LTE458. The following parameters used as

dimensioning inputs are impacted:

16/63




Table 2 LTE458 parameters impacting LTE Access dimensioning and their maximum values.

Parameter Radio channel bandwidth

3 MHz 5 MHz 10 MHz 15 MHz 20 MHz

Active users per cell (max

value) (*) 120 480 600 720 840

Actively scheduled users per

cell (max value) (**) 40 192 240 240 250

(*) Active users: RRC_connected users with a data bearer established; traffic demand per eNB is

calculated with respect to these users

(**) Actively scheduled users: Active users scheduled by the RRM scheduler to be served in the time

domain; Air I/F throughput limits are verified with respect to these users.


1.3.3.1 Operator specific QCI (LTE518) The operator specific QCI feature allows the operator to extend the standardized QCIs with additional 21 non-GBR QCIs for better user and service differentiation for non-GBR services. The QCI value for each additional QCI is operator configurable in the range

from 128 to 254.


With this feature, additional QCIs can be assigned. It is possible to differentiate services, users (e.g. gold, silver, bronze) or operators (when sharing eNBs). Up to 21

additional QCI can be specified except standard QCIs (1-9)

1.3.3.2 Transport admission control (LTE144) Transport Admission Control (TAC) is in charge of controlling admittance of user traffic based on available resources on the transport network in order to avoid overload conditions on both the air interface and the transport interface. Admittance control is applied to GBR connections only.


Impact of this feature is included when dimensioning the GBR traffic (Support of EPS bearers for conversational voice feature has to be enabled) by using Erlang B formula. Therefore, target Blocking Probability has been introduced.

1.3.3.3 IP transport network measurements (LTE574) This feature introduces means for actively measuring and supervising the IP network conditions between two IP terminations using either TWAMP protocol or UDP echo services implemented in eNodeB or other networking elements (i.e. router, security

gateway).


The IP transport network measurement can generate additional traffic, which at default packet size and standard packet rate is negligible to link dimensioning. However, with

17/63




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.


If this feature checkbox is activated in the dimensioning tool, the value of MTU can be defined from range: 576-1644. Setting values higher than standard MTU equal to 1500 bytes allows limiting fragmentation at the transport path for user data packets that would normally be fragmented.

That decreases the impact of overheads in dimensioning calculations, resulting in more efficient link utilization.

With Ethernet Jumbo frames enabled the default MTU value still remains 1500. It should be adjusted to reflect actual network value.

1.3.4 RL40 features

1.3.4.1 Support of QCI 2, 3, 4 (LTE496) This feature enables the usage of QCI 2, 3 and 4. As standardized by 3GPP, in network supporting this feature, bearers assigned to QCIs from range 1-4 are GBR bearers, and the rest are treated as non-GBR.


Activation of this feature is possible with simultaneous activation of Smart admission control (LTE497) and ARP based admission control (LTE534) only. Enabling this feature allows user to specify additional QCIs: 2, 3 and 4.

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


18/63




Activation of this feature is possible with simultaneous activation of Support of QCI 2, 3, 4 (LTE496) and ARP based admission control (LTE534) only. This feature enhances the RL30: Transport Admission Control by using various transmission rates instead of fixed one.

1.3.4.3 Multiple GBR EPS bearers per UE (LTE587) With LTE587 feature the Flexi Multi radio BTS supports up to three GBR EPS radio bearers per UE. Up to six data radio bearers can be established per UE. The different EPS bearers per UE can have the same or a different QCI. The QCIs needs to be enabled via separate features.


This feature allows establishing more than one GBR bearer per UE. User can assign QCIs 1 - 4 to GBR. For dimensioning purposes, Erlang B formula used up to RL30, has been replaced by Multidimensional Erlang B formula (MDErlang).


1.3.5.1 Transport separation for RAN sharing (LTE505) This feature enables separation of transport paths for U-Plane and also for C-Plane of two networks/operators. This separation can be done by splitting the traffic into separate VLANs.


There is no direct impact on the dimensioning tool. However, there can be two different traffic models coming from the operators, which can be configured in the tool by separate traffic profiles. For such configuration the total capacity for the whole transport interface will be shown.

19/63




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




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




for the eNB along with the capacity split per logical interfaces. Detailed description of

the output parameters is provided in Sec. 2.1.2.

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)

Area configuration

Area type

Software release

Site layout

C – plane dimensioning(S1_MME & X2_C)

U – plane dimensioning(S1_U & X2_U)

Features configuration

Feature selection

Feature parametrization

Services

Subscriber profile

definition

Service set definition

Traffic demand

Traffic Model definition

User data definition

Signaling parameters

Front Mile

Area selection

Number of eNBs

Load Distribution Factor

Transport configuration

Number of sites

QoS Class configuration

Scheduler weights

LT

E A

cc

es

s

dim

en

sio

nin

g in

pu

ts

LT

E A

cc

es

s

dim

en

sio

nin

g o

utp

uts

Front mile dimensioning

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




Table 3 LTE Access dimensioning inputs: Area configuration.

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

Area configuration

parameters Default value Comment

Software release RL40 Sets the software version which limits available

features.

Service parameters Default value Comment

Name Internet Static

Application Specifies the service name and type.

Bearer QCI 9 Specifies the QoS Class Identifier

(QCI) of service bearer.

Phase Enabled Enables/disables the service into/from

calculations within given phase.

Packet size Service dependant Sets average packet length for each

service.

23/63




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

QoS blocking probability 2% Sets the blocking probability for GBR

services used in ErlangB formula.

QoS mean delay 15 [ms]

Sets the average packet delay per

service for Last/Front mile calculation

(MGR-PS)

Traffic demand – general


Traffic model for Busy Hour

(BH)

Traffic demand per

subscriber

Indicates whether the traffic demand

is specified:

per subscriber

per area

TM parameters defined at End User/application

level

Indicates whether the traffic demand is

specified at:

Network level

End User/application level

Number of subscribers per area N/A

Defines number of subscribers per

area in case of traffic demand

specified per subscriber.

24/63




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

Traffic demand – U-Plane


Service Dependent on

selected service Service name

Link UL/DL 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


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) 50%

Defines the frequency of the paging

procedure executed in the scenario

when there is incoming call for the UE

in MME

MTC ratio for PS like services

(VoIP) 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




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

Traffic demand – smart

applications parameters Default value Comment

Service name Dependent on service Service name

Message size 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 150 [B] Keep alive message size

Time between keep alive

messages 90 [s] Time between keep alive messages

Number of applications per

subscriber 0,5

Amount of smart applications per

subscriber

26/63




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


Number of sites N/A Defines number of sites within area. To be putted by user or automatically copied from radio dimensioning results

Number of cells per site 3 Defines number of cells per site. To be putted by user or automatically copied from radio dimensioning results

Average cell throughput

[kbps] N/A

Defines the cell average throughput. To be

putted by user or automatically copied from

radio dimensioning results

Peak cell throughput [kbps] N/A

Defines the cell peak throughput. To be putted by user or automatically copied from radio dimensioning results

VLAN tag Enabled

Specifies whether the VLAN tag is included into

Ethernet frame

QoS Class configuration QCI

Dependent Defines the QCI to PHB queue mapping

PHB weight configuration PHB

dependent Defines the PHB weight in WFQ scheduler

PHB delay target PHB

dependent

Defines the PHB delay target which is the

minimum delay from all services assigned to

that PHB

2.1.1.6 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




Table 10 LTE Access dimensioning inputs: Aggregation point inputs.

Front mile inputs


Area N/A Defines which areas are included into aggregation point calculation

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

Handover traffic included False Defines if the handover traffic from the

connected sites is also aggregated at this point.

2.1.1.7 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


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

LDF parameter defines the Busy Hour

distribution among various eNBs.

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

2.1.2 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




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




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




LTE Access dimensioning steps for both options are presented in Figure 10.

Specification of traffic demand

(U-Plane, C-Plane)

LTE traffic model:

- User profile definition

- Service definition

- Service distribution

- Signaling inputs

Traffic aggregation according to

IPDiffServ PHB classes

LTE interface dimensioning

(logical S1, X2 and O&M i/f)

Resulting eNB

transport capacity

Radio-related

inputs

QoS settings

Area configuration

DIM

EN

SIO

NIN

G B

AS

ED

ON

TH

E U

SE

R T

RA

FF

IC D

EM

AN

D

DIM

EN

SIO

NIN

G B

AS

ED

ON

TH

E R

AD

IO I/F

TH

RO

UG

HP

UT

Resulting Front mile

transport capacity and statistical

multiplexing gain

Front mile inputs

Input

Intermediate results

Output

LEGEND:

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




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

NRT_Capacity__&_XRT + S_Capacity__&_X[kbps]= S_Capacity _&_XS 212121

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

Real-time GBR MDErlang blocking probability

Non-GBR M/D/1 single-link delay

Non-real-time Non-GBR Ext M/G/R-PS single-link delay

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




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

}RT_Capacity_X__&S{]kbps[RT_Capacity_X_&SService

Service 2121

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

}yprobabilit_blockingrate_peak

,load_traffic_X__&S{MDErlang]kbps[RT_Capacity_X__&S

Service,Service

ServiceGBRService 2121

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

}OH_U_Sweight_PHB,load_traffic_X__&S

size_packet,delay_packet{/D/M]kbps[RT_Capacity_X__&S

Service,ServiceService

,ServiceServiceenGBRServic

121

121

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




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

}NRT_Capacity_X__&S{Max =[kbps] ty_NRT_X2_Capaci&S1_ ServiceService

21

The application e2e delay per service is calculated using the M/G/R-PS formula [MGR-

PS]:

Equation 6

}OH_U_S

,weight_PHB,load_traffic_X__&S,delay_transfer

,size_file,peak_r{PSR/G/M]s[NRT_eDelaye_X__&S

Service

Service)Service(PHB)Service(PHB

ServiceServiceService

1

21

221

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




Equation 7

}weight_QCI,OH_Uu

,throughput_cell_avg,load_traffic_total{PS/G/M]kbps[peak_r

ServiceService

Service 1

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

Service

ServiceService

Service

sizefile

NRTeDelayeXSNRTeDelayeXS

n _estimatio= TN_delaykbps NRT_Capacity__&_XS

_

,min__2_2__&1,_2_2__&1

][21

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




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

}__1_{_][__ PDCPDloadtrafficSpstFreqHOkbpsloadtrafficHO

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

),util_Uu(),util_Uuutil_Uu,util_Uu,(

),util_Uu(,]kbits[DPDCP

3010240689613452110

3043233

where:

Uu_util [%] is the Radio I/F utilization, calculated as:

Equation 11

throughput_cell_avg

cell_per_load_traffic_gross][#util_Uu

where:

gross_traffic_load_per_cell [kbps] is the total user traffic in a radio cell with radio

overhead.

36/63




Note: If calculated X2_U capacity is zero, but the X2 load is greater than zero, it is assumed that X2 traffic is accommodated in S1_U capacity.

General dimensioning concept of the U-Plane bandwidth traffic (based on the user

traffic demand) is graphically illustrated in Figure 11.

Capacity

per PHB

TN delay <

Target Packet

delay

NO -> Increase capacity

YES -> S1_(&_X2)_Capacity_

NRTService[kbps]

S1_(&_X2)_traffic_load Service [kbps]

S1_(&_X2)_Capacity_RT Service [kbps]

packet_delay Service [ms]

S1_U_OH Service [%]

packet_size Service [bytes]

PHB_weight Service

file_size Service [kbytes]

PHB_weight Service

S1_(&_X2)_traffic_load PHB(Service) [kbps]

S1-U_OH Service [%]

S1_(&_X2)_e2eDelay_NRT_min Service [kbps]

S1_(&_X2)_e2eDelay_NRT Service [kbps]

Initial capacity = S1_(&_X2)_traffic_load [kbps]

ave_cell_throughput [kbps]

Uu_OH Service [%]

S1_(&_X2)_traffic_load per cell [kbps]

per PHB

Sum from all

RT nGBR

services

Max from all

NRT services

S1_(&_X2)_Capacity_

NRT [kbps]

per service S1_(&_X2)_Capacity_

RTnGBR [kbps]

Service = RT

Service =

GBR

NO

MD-Erlang

(for all RT

GBR services)

NO

YES

Sum

Max

S1_(&_X2)_Capacity_

RT_GBR [kbps]

S1_(&_X2)_Capacity_

NRT+RTnGBR+

RT_GBR_load [kbps]

Load RT GBR

M/D/1

YES

Weighted

M/G/1-PS

TN Delay

estimation

TN delay PHB [ms]

M/G/R-PS

r_peak Service

Target Packet DelayPHB[ms]

Blocking_probability

GBRservice

S1_(&_X2)_traffic_load Service [kbps]

S1_(&_X2)_Capacity [kbps]

QCI_weight

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

37/63




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

)OH_U_S()OH_Uu()throughput_cell_avg

eNB_per_cells_of_(#]kbps[Capacity_portPlaneTrans_U_eNB basedRadio

111

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

The “All Average” option is graphically presented in Figure 12.

Cell

pe

ak

eN

BU

-Pla

ne

tra

nsp

ort

Cell averageCell

pe

ak

Cell

pe

ak

eN

BU

-Pla

ne

tra

nsp

ort

Cell average

Figure 12 Dimensioning based on the Radio i/f throughput – the “All Average” option.

38/63




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

)OH_U_S()OH_Uu(}throughput_cell_avgeNB_per_cells_of_#

;throughput_cell_peak{MAX]kbps[Capacity_portPlaneTrans_U_eNB BasedRadio

111

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

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

eN

BU

-Pla

ne

transport

Cell averageCell

peak

Cell

peak

eN

BU

-Pla

ne

transport

Cell average

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.

39/63




The calculated U-Plane transport capacity should be:

Equation 14

)OH_U_S(

)OH_Uu(]throughput_cell_avg)eNB_per_cells_of_(#

throughput_cell_peak[]kbps[Capacity_portPlaneTrans_U_eNB basedRadio

11

11

The “Single Peak plus All-but-one-Average” option is illustrated in Figure 14.

Cell

peak

eN

BU

-Pla

ne

transport

Cell averageCell

peak

Cell

peak

eN

BU

-Pla

ne

transport

Cell average

Figure 14 Dimensioning based on the Radio i/f throughput – the “Single Peak plus All-but-one-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

)OH_U_S()OH_Uu()throughput_cell_peak

eNB_per_cells_of_(#]kbps[Capacity_portPlaneTrans_U_eNB basedRadio

111

The “All Peak” option is illustrated in Figure 15.

40/63




Cell

pe

ak

eN

BU

-Pla

ne

tra

nsp

ort

Cell

pe

ak

Cell

pe

ak

eN

BU

-Pla

ne

tra

nsp

ort

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)

eNB

S1_UL

S1_DL

X2_DL_in

eNB_Transp_Cap (UL)

Transport side

(ePC)

S1_DL - X2_DL_out

X2_DL_out

DL

S1_DL

X2_DL_in

S1_DL - X2_DL_out

X2_DL_out

UL

X2_DL_out

S1_ULeNB

eNB_Transp_Cap (DL)

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




Equation 16

in_DL_U_XDL_U_S]kbps[DL_Capacity_Transport_eNB 21

Equation 17

out_DL_U_XUL_U_S]kbps[UL_Capacity_Transport_eNB 21

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

][___2][___2 kbpsinDLUXkbpsoutDLUX

Assume as well that the total X2_U_DL traffic is some percentage of the average S1_U

DL traffic:

Equation 19

AVG_ALLDL_U_S[%]Share_HO]kbps[in_DL_U_Xout_DL_U_X 122

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

in_DL_U_XDL_Capacity_Transport_eNB]kbps[DL_U_S AVG_ALLAVG_ALL 21

From (Equation 18)-(Equation 20):

Equation 21

AVG_ALLDL_Capacity_Transport_eNB[%]Share_HO

[%]Share_HO

]kbps[in_DL_U_X]kbps[out_DL_U_X

2

22

From (Equation 16) - (Equation 17) and (Equation 21):

42/63




Equation 22

AVG_ALL

OptionOption

DL_Capacity_Transport_eNB[%]Share_HO

[%]Share_HO

DL_Capacity_Transport_eNB]kbps[DL_U_S

2

1

Equation 23

AVG_ALL

OptionOption

DL_Capacity_Transport_eNB[%]Share_HO

[%]Share_HO

UL_Capacity_Transport_eNB]kbps[UL_U_S

2

1

where:

Option {ALL_AVG, ALL_AVG_/_SINGLE_PEAK,

SINGLE_PEAK_+_ALL_BUT_ONE_AVG, ALL_PEAK}

2.2.2.3 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




Table 14 Dimensioning based on the user traffic demand vs. dimensioning based on the Radio interface throughput – comparative analysis.

PROS CONS

Dimensioning based on User traffic demand

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)

Dimensioning based on Radio I/F throughput

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




DIMENSIONING BASED ON THE USER TRAFFIC DEMAND

DIMENSIONING BASED

ON THE RADIO I/F

THROUGHPUT

Signaling messages parameters

Message size

Overhead size

Traffic model parameters

Attach frequency

BHCA

Number of handovers etc.

Traffic load of an event Frequency of an event

List of considered

events

Total signaling load

Input

Intermediate results

Output

LEGEND:

C-Plane traffic as a

percentage of the U-Plane

Total U-Plane traffic

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




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

eventeventevent FL]bps[T

4. Total load of signaling traffic resulting from the events is multiplied by the total number of subscribers (#UE [#]):

Equation 25

event

eventTUE#bpsT

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




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.

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

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.

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.

Tracking Area Update

Signaling load


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.

Inter eNB handover

Signaling load

[# of messages] [bytes] [# of messages] [bytes]

S1 (DL) S1 (UL) S1 (DL) S1 (UL) X2 (DL) X2 (UL) X2 (DL) X2 (UL)

1 1 72 88 2 2 320 136

47/63




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.

LTE_Idle to LTE_Active

Signaling load


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

planeUBHCAs

Load_Active_to_Idle

1

LTE_Active to LTE_Idle

Table 19 Event load: LTE_Active to LTE_Idle.

Signaling load

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 ‘keep-alive’ 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




Equation 27

timer_release_RRCmsg_timeif

msg_time

timer_release_RRCmsg_timeif

smsg_sm 3600

01

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

timer_release_RRCmsg_alivekeep_timeifmsg_alivekeep_time

timer_release_RRCmsg_alivekeep_timeif

smsg_ak_sm 3600

01

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

msg_ak_smmsg_sms

events_sm

1

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




call /

session

RRC

connected

RRC idle

time between

messages

time between

messages

RRC release

timer

time between messages < 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




call /

session

RRC

connected

RRC idle

time between

messages

RRC release

timer

time between messages ≥ RRC release timer

time between

messages

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.

Paging

Signaling load


S1 (DL) S1 (UL) S1 (DL) S1 (UL)

1 0 60 0

Event frequency:

Equation 30

PlaneUSFsizecp BHCAMTCTATAfactor_retrys

Paging

1

where: retry_factor [#] is an average number of repeated pagings due to subscriber

unavailability.

51/63




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

BHCAU-plane [#] is a sum of BHCA of all applications per subscriber. The same

parameter as used for state transitions calculations.

2.2.3.3 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 U-Plane traffic. Traffic of the S1_MME interface is specified as a percentage of the S1_U traffic:

Equation 31

AVG_ALLDL_U_S[%]Share_CP]kbps[DL_MME_S 11

Equation 32

AVG_ALLUL_U_S[%]Share_CP]kbps[UL_MME_S 11

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

in_DL_U_XDL_Capacity_Transport_eNB]kbps[DL_U_S AVG_ALLAVG_ALL 21

Equation 34

out_DL_U_XUL_Capacity_Transport_eNB]kbps[UL_U_S AVG_ALLAVG_ALL 21

From (Equation 31) – (Equation 32) and (Equation 33) - (Equation 34) one gets:

52/63




Equation 35


[%]Share_CP =[kbps] S1_MME_DL

2

2

Equation 36

AVG_ALLAVG_ALL DL_Cap_Transp_eNB

[%]Share_HO

[%]Share_HOUL_Cap_Transp_eNB

×[%] CP_Share =[kbps] S1_MME_UL

2

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_U_DL_in ×[%] CP_Share =[kbps] X2_C_DL_in

Equation 38

tX2_U_DL_ou ×[%] CP_Share =[kbps] tX2_C_DL_ou

From (Equation 21):

Equation 39


[%]Share_HO[%]Share_CP

=t[kbps] X2_C_DL_ou =[kbps] X2_C_DL_in

2

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

_DL_ratio:X2_C_UL_ × X2_C_DL =[kbps] X2_C_UL

From (Equation 39):

Equation 41


[%]Share_HO[%]Share_CP

2

× 0.716 = t[kbps]X2_C_UL_ou = [kbps]X2_C_UL_in

53/63




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

rate_msg_announce_PTPOH_Trssize_msg_announce_PTP

rate_msg_sync_PTPOH_Trssize_msg_sync_PTP]kbps[ToP_BW

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

]kbps[/))(,)((ToP_BW 1610001656035250560544

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




The calculation is defined by Equation 44:

Equation 44

rate_msg_SSM)size_Hdr_SSMsize_PDU_SSM(]kbps[SyncE_BW

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: 6104 [bits]

SSM_msg_rate: 5 [1/s]

SSM_Hdr_size: 224 [bits]

Equation 45

]kbps[/))((]kbps[SyncE_BW 8100052246104

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.

55/63




Radio side

( eUTRAN)

eNB

S1_ MME_UL

S1_U_DL

Transport side

(ePC)

X2_U_out

S1_U_ DL - X2_U_out

X2_C_out_DL

S1_ MME_DL

S1_U_UL

X2_U_inX2_C_in_DL

X2_C_out_UL

X2_C_in_UL

b) Allocation to the eNB’s transport interface

UL

eNB

S1_ MME_UL

X2_U_out

X2_C_out_DL

DL

X2_C_in_UL

S1_U_DL

S1_ MME_DL

X2_U_in

X2_C_out_UL

X2_C_in_DL

S1_U_UL

S1_U_ DL - X2_U_out

FTM

(FTIB or

FTLB)

FTM – Flexi BTS Transport Sub-Module

X2_U_out

a) Logical flow distribution across eNB

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

21 CCC

then the difference (C1 + C2) - C indicates the benefit resulting from traffic aggregation.

56/63




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

eNB Service

Service,eNB }RT_Capacity_X__&S{]kbps[RT_Capacity_X_&S_FM 2121

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

eNB Service,Service

Service

GBRService}yprobabilit_blockingrate_peak

,load_traffic_X__&S{MDErlang]kbps[RT_Capacity_X__&S_FM

2121

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 49

}OH_U_Sweight_PHB,load_traffic_X__&S

size_packet,delay_packet{/D/M]kbps[RT_Capacity_X__&S_FM

Service,Service

eNB

Service,eNB

,ServiceServiceService

121

121

where:

57/63




packet_delay Service [ms] is the max tolerable transport delay of IP packets on the

front mile link. It is the assumed QoS target for dimensioning the RT traffic, specified separately for each service class. Default value (for each service class) is 15 ms.

packet_size Service [bytes] is the average size of an IP packet per service.

eNB

Service,eNBload_traffic_X__&S 21 [kbps] is the user traffic demand per service

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.

FM_S1_&_X2_Capacity_RT Service [kbps]M/D/1

packet_delay Service [ms]

packet_size Service [bytes]

PHB_weight Service

S1_U_OH Service [%]

S1_&_X2_traffic_loadeNB,Service[kbps]ΣeNB

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




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.

S1_&_X2_e2eDelay_NRT_min Service [kbps]

Weighted

M/G/1-PS

M/G/R-PS

file_size Service [kbytes]

PHB_weight Service

S1-U_OH Service [%]

ave_cell_throughput [kbps]

r_peak Service

Uu_OH Service [%]

TN Delay

estimation

Target Packet DelayPHB Service[ms]

S1_&_X2_Capacity_NRTService[kbps]

S1_&_X2_e2eDelay_NRT Service [kbps]

S1_&_X2_traffic_load PHB(Service) [kbps]ΣeNB

Total_U-Plane_traffic_per_cell [kbps]

S1_&_X2_traffic_load_per_cell [kbps]

QCI_weight

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

k

i

)Service(PHB

eNB

)Service(PHB ieNB_load_traffic_X__&Sload_traffic_X__&S1

2121

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

1

1

_ ( )_ _ ( )*

_ ( )

k

NRT NRTk

i

j

Load eNB iFM BW FM BW i

Load eNB j

59/63




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

n_Bw.._Bw

BW_Aggregated[%]gain_ngMultiplexi

11

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




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

dimensioning.

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




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

Figure 25 Uneven load distribution.


The difference between the traffic demand calculated by “even load distribution” and

“uneven load distribution” is called the Load Distribution Factor (LDF):

Figure 26 Difference between even and uneven traffic load distribution at aggregation point.

Equation 53

62/63




B

ALDF

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

k

i

)Service(PHB

eNB

)Service(PHBLDF

ieNB_load_traffic_X__&Sload_traffic_X__&S

1

2121

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




Abbreviations

AMBR Aggregated Maximum Bit Rate BTS Base Transceiver Station DRB Data Radio Bearer eNB Evolved Node B EPC Evolved Packet Core ISD Inter Site Distance LDF Load Distribution Factor LTE Long Term Evolution MBR Maximum Bit Rate MDErlang Multidimensional Erlang B formula MME Mobility Management Entity MTU Maximum Transmission Unit O&M Operation and Maintenance PDCP Packet Data Convergence Protocol PDN GW Packet Data Network Gateway PHB Per Hop Behavior QCI QoS Class Indicator QoS Quality of Service RRC Radio Resource Control RTP Real-Time Transport Protocol SAE System Architecture Evolution SAE-GW SAE Gateway SCTP Stream Control Transmission Protocol SYNC-E Synchronous Ethernet TCP Transmission Control Protocol ToP Timing over Packet UDP User Datagram Protocol WFQ Weighted Fair Queuing

Documents

LTE Access Transport fffDimensioning Guideline