LTE Default Traffic Model

1/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

Document Type Unit or Department For internal use only, Date

Annex to Dimensioning Guideline LTE Traffic Model for Network Dimensioning

“It is difficult to make predictions, especially about the future” popularized by economic forecasters in 70’s

2/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

Revision History Version 0.1..0.3 1.0

Date

Change Notes

2009..2010 Early documentation by Jacek Ryzner Oct 2011

Approved for LTE air interface and access dimensioning

Authors Name

Department

Piotr Godziewski

NWS LTE RA E2E SA Network Engineering LTE

3/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

Table of contents

1.

Introduction.............................................................6

1.1 1.2

Scope..........................................................................................6 Point of reference........................................................................6

2.

LTE bearers and state handling.............................7

2.1 2.2 2.3

Bearer architecture......................................................................7 UE state handling........................................................................9 Definitions..................................................................................10

3.

Application Mix.....................................................12

3.1

Application characteristics.........................................................13

4.

Traffic demand......................................................15

4.1 4.2

Mean Active UE throughput.......................................................15 Number of Active UEs................................................................16

5.

Other parameters.................................................17

5.1 5.2

Busy Hour concentration............................................................17 Traffic evolution..........................................................................17

6.

Default Traffic Model............................................19

6.1 6.2

Default Application Mix...............................................................19 Default Traffic Model..................................................................24

7.

Open points and future enhancements................27

7.1 7.2 7.3

Validation with PM data..............................................................27 UE split......................................................................................27 Base station load.......................................................................28

Abbreviations......................................................................29

4/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

List of Figures and Tables Figure 2-1: LTE RRC UE State Handling.......................................................................................................10 Figure 6-2: Robust Header Compression gain for AMR VoIP compared to IPv4 w/o compression..............23

Table 2-1: LTE QoS Class Identifiers ([4])......................................................................................................7 Table 2-2: QoS profiles mapping between LTE, UMTS and GPRS ([4]).......................................................9 Table 3-3: Application Mix..............................................................................................................................13 Table 5-4: Busy Hour concentration according to [3].....................................................................................17 Table 6-5: Default Application Mix..................................................................................................................19 Table 6-6: VoIP bandwidth requirements.......................................................................................................22 Table 6-7: Exemplary streaming bandwidth requirements according to [7]...................................................24 Table 6-8: Monthly data consumption according to [1]..................................................................................25

List of planning rules No table of figures entries found.

5/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

References [1]

NSN Traffic Model Roadmap. Markus Djupsund. https://sharenet-ims.inside.nokiasiemensnetworks.com/Guest/Open/379133629

[2]

LTE SFS Capacity plus Traffic Model. Wolf-Jens Teubert. (please download latest version from DOORS)

[3]

Traffic Modeling for Network Dimensioning. Dimensioning Guideline for RU30 and i-HSPA Rel.4 v1.0.1. Grzegorz Ścibior. https://sharenet-ims.inside.nokiasiemensnetworks.com/Guest/Open/421155604

[4]

3GPP TS 23.203. Policy and charging control architecture (Release 7/8). http://www.3gpp.org/ftp/Specs/html-info/23203.htm

[5]

WCDMA for UMTS – HSPA Evolution and LTE. Fourth Edition. H. Holma, A. Toskala.

[6]

Mobile Data Traffic Analysis. ABI Research. April 29, 2011.

[7]

Internet blog http://adterrasperaspera.com/blog/2010/05/24/approximate-youtube-bitrates

[8]

What are the Pricing and Deployments Plans of the Early bird LTE Operators? Julian Watson. April 2011 http://www.ihs.com

[9]

E-UTRAN Dimensioning Guideline. February, 2011. https://sharenet-ims.inside.nokiasiemensnetworks.com/Guest/Overview/D433598235

6/27

Unit or Department Piotr Godziewski

1.

Introduction

1.1

Scope

Document Type For internal use only Date

The following document focuses on a traffic model definition for LTE dimensioning. When referring to dimensioning it is about both the air interface and the access network and the process itself is a part of offer (budgetary) planning which requires an estimation of the number of sites for the given customer requirements (e.g. HW configuration, feature set, throughput requirement, traffic demand, etc.). The main target is to let a planner understand the traffic modeling rules and eventually tune it according to specific operator requirements. It is neither to be used for marketing purposes nor as NSN official statement about the current or expected traffic volumes and user behavior. It is the LTE Traffic Model for Network Dimensioning.

1.2

Point of reference The following preconditions are stated. • The LTE Traffic Model for Network Dimensioning shall be aligned with [1]. It is about aligning the key output (data volume per subscriber) and the way the services are defined and differentiated, • The LTE Traffic Model for Network Dimensioning shall be aligned with [2] as it is the main document specifying capacity requirements across LTE NSN releases as well as the traffic model network view based on [1], • The LTE Traffic Model for Network Dimensioning shall be aligned with [3] because of a general requirement to implement LTE and WCDMA/HSPA dimensioning on the same tool platform. Above mentioned three documents have slightly different scopes therefore one shall realize the following: • [1] is the NSN Traffic Model Roadmap. It tries to combine all technologies together (2G, 3G, LTE and beyond) and to justify a necessity for network capacity boosters. The underlying data was gathered from real operators and traffic forecast is based on third parties research and analysis, • [2] is an SFS defining NSN LTE eNB capacity performance including the air interface and base band. The capacity estimates however refer to maximum eNB capabilities and for this reason cannot be used as average LTE traffic model. A specific chapter (“Traffic Model Network View”) has been added in order to extend the SFS with an average traffic model (based on [1]), • [3] is a part of 3G dimensioning deliverables from NetEng. From the conceptual point of view it is the one matching the subject matter of this document.

7/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

2.

LTE bearers and state handling

2.1

Bearer architecture A list of E-UTRA bearers and their specification is standardized in [4]. QCI

Priority

Packet delay budget

Packet loss error rate

Example services

1

2

100

10-2

Conversational voice

2

4

150

10-3

Conversational video (live streaming)

5

300

10-6

Non-conversational video (buffered streaming)

3

50

10-3

Real time gaming

3

Resource type

GBR

4

-6

5

1

100

10

6

7

100

10-3

Video (buffered streaming), TCP-based (e.g. WWW, email, chat, FTP, p2p file sharing, progressive video, etc.)

6

300

10-6

Voice, Video (live streaming), Interactive gaming

8

8

300

10-6

9

9

300

10-6

Video (buffered streaming), TCP-based (e.g. WWW, email, chat, FTP, p2p file sharing, progressive video, etc.)

7

Non-GBR

IMS signaling

Table 2-1: LTE QoS Class Identifiers ([4])

A clear 1:1 mapping between QoS Class Identifiers (QCI) and the bearer characteristics exists in order to achieve same treatment for services crossing multivendor environment. A network node, which transmits data, maps its Service Data Flows to appropriate QCI and therefore determines how the aggregated services are treated on the way to a recipient. Taking an example of RAN segment, the radio schedulers can prioritize VoIP traffic (QCI 1) while serving QCI 9 internet traffic in a best-effort manner. Later on QCIs impact priority handling on S1 interface towards SAE-GW. Short characteristic of QCIs and the relations with NSN SW features are introduced below: • QCI 1 – requires LTE10 EPS bearers for conversational voice. The maximum guaranteed bit rate for QCI 1 is configurable with O&M qci1GbrLimit which means that the system will reject a connection which requests more than qci1GbrLimit defines.

8/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

For this bearer, it is also possible to enable Robust Header Compression (RoHC) to reduce an IP overhead. This can be done when LTE11 Robust header compression is active (O&M actPdcpRohc). RLC layer can operate in Unacknowledgement Mode (UM) only, • QCI 2, 3, 4 – requires LTE496 Support of QCI 2, 3 and 4. The maximum guaranteed bit rate per QCI is O&M configurable. RLC UM is applied for QCI 2 and 3 and AM is only possible for QCI 4. None of them can operate with RoHC, • QCI 5 – is valid if conversational voice (or video) is supported in a network. 3GPP has decided that Session Initial Protocol (SIP) shall be used for IP multimedia applications [5]. SIP messages will be carried on QCI 5, • QCI 6 – is valid only if a network supports Multimedia Priority Services (MPS) which is an enhancement to IMS allowing authorized persons (public safety) for prioritized access to (overloaded) network in case of emergency situations (e.g. disaster recovery), • QCI 7 – is suitable for voice and streaming services, • QCI 8 – could be used as a dedicated bearer for “premium subscribers”, • QCI 9 – is typically used as a default bearer for non-privileged subscribers. QCI 5, 6, 7, 8 and 9 are supported already in RL10 with LTE905 Non-GBR QCI 5, 6, 7, 8 and 9. In multi-RAN environment it is the Policy and Charging Enforcement Function (PCEF) which is responsible for 1:1 mapping from QCI to UMTS QoS profile and vice versa [4]. Some recommendation is given by 3GPP in [4]. Note that although Table 2 -2 provides full LTE-UMTS-GPRS mapping, it is not to be taken for granted. The (E)GPRS networks have never been really capable of supporting a QoS architecture of this kind. Nevertheless planners who have 2G or 3G experience can look up possible relations between newly introduced QoS Class Identifiers and well known UMTS QoS profiles. Exemplary mapping of services to specific UMTS Traffic Classes has been introduced in [3]. LTE Release 8

UMTS Release99

GPRS Release 97/98

QCI

Traffic Class

Traffic Handling Priority

SDU Error Ratio

Delay Class

Reliability Class

1

Conversational

N/A

10-2

1

4 or 5

2

Conversational

N/A

10-3

1

4 or 5

-3

3

Conversational

N/A

10

1

4 or 5

4

Streaming

N/A

10-6

1

2

-6

5

Interactive

1

10

1

2

6

Interactive

1

10-6

1

2

-3

7

Interactive

2

10

2

4 or 5

8

Interactive

3

10-6

3

2

4

2

9

Background

N/A

-6

10

Table 2-2: QoS profiles mapping between LTE, UMTS and GPRS ([4]) 1

1

The QoS parameters which are not considered in the original mapping table are subjected to operator’s configuration.

9/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

2.2

UE state handling There are only two LTE Radio Resource Control (RRC) states as shown on Figure 2 -1: • RRC_Connected –UE is located on a cell level. Mobility is managed with handovers. UE is ready for transmitting data and receiving data (for this reason UE listens to PDCCH). It also sends periodic measurements to eNB in order to stay synchronized with a base station (eNB calculates the Timing Advance and sends it back to UE). UE which is RRC_Connected has Signaling (S-) and Data (D-) Radio Bearers (SRB and DRB) established but not necessarily data to be transferred. From the traffic model and capacity assessment point of view RRC_Connected UE is considered as Active even if it does not have any actively scheduled data transfers. Every Active UE consumes certain amount of System Module’s DSP processing power and that is why it is subjected to licensing. • RRC_Idle – UE monitors paging while mobility is managed with cell-reselections. For paging purposes, UE is located on a tracking area level. After data transfer is completed both radio schedulers (downlink and uplink) starts counting inactivityTimer (O&M configurable). When a threshold is reached the eNB switches UE from RRC_Connected to RRC_Idle at the same time releasing all the radio bearers established on the air interface (eUu). Therefore longer inactivityTimer (by default set to 300s) may result in too many Active UEs which the eNB will not be able to handle (even if they “sleep” most of the time and does not consume physical resources). On the other hand a very short break to RRC_Idle will increase the amount of RRC signaling (switching events). 2 An introduction of LTE42 DRX in RRC_Connected mode will not change the above principles. Keeping UEs longer in RRC_Connected state will save their batteries at the cost of increased amount of Active UEs and handovers.

Figure 2-1: LTE RRC UE State Handling

2

Default inactivityTimer=300s might be much too long for initial LTE deployments (data driven). At the time this document is being released, TeliaSonera LTE network is configured with inactivityTimer of 60s (source: mail correspondence with Wolf-Jens Teubert).

10/27

Unit or Department Piotr Godziewski

2.3

Definitions

Document Type For internal use only Date

Busy Hour (BH) – the 60 minutes period when the number of transferred bits or the call duration (in case of voice traffic) at network level is highest during a day. Note that on RAN level different busy hours can be found for each eNB or cell but that is not considered in homogenous dimensioning. It is usually reflected in detailed network planning through appropriate subscriber distribution (and traffic profiles) in a planning tool or simulator. Subscriber – any HLR subscription (SIM) irrespectively of the end user activity (Active, RRC_Idle, turned off, out of service area/coverage – all are counted). Usually an operator cannot differentiate between 3G and LTE subscriptions (SIM cards can register to both networks). For this reason, a term of Subscriber shall be replaced with a term of Attached Subscriber in case of traffic measurements from a real network. Busy Hour Call Attempt (BHCA) – the number of calls cumulated over a network during the Busy Hour and referred to the number of Subscribers. The number of calls can vary depending on the reference point. At the end user level unsuccessful calls are not considered. The unsuccessful call attempts at the end user level may lead to additional attempts at the network level while from the end user point of view only one call has been requested. Therefore the network level BHCA (all counted events) is higher than BHCA at end user level. Call – successfully completed Evolved Radio Access Bearer (E-RAB) access phase3. Mean per Subscriber parameter – any traffic model parameter marked as is accumulated over a whole network and referred to the number of Subscribers. Subscriber Traffic Demand in BH – the end user level traffic defined as either the call duration or the amount of transferred bits. Service – a set of high level characteristics defining the possible user behavior when Service is running and used.

3

Note that in LTE dimensioning there is no reason to differentiate between calls (CS domain) and sessions (PS domain) as it is defined in [3]. All the traffic is handled with IP connectivity. The Call in this document refers to both voice and data services.

11/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

3.

Application Mix The LTE Traffic Model for Network Dimensioning defines the following reference services (applications): 1) Internet Static Applications (ISA) a. Web Browsing, b. File Downloads, c. E-mail, d. Instant Messaging. 2) Internet Multimedia Applications (IMA) a. Conversational Voice, b. Conversational Video, c. Streaming, d. Gaming. Above suggested groups have been decided based on the application mix in [1] however they have been slightly modified for dimensioning purposes. This also concerns the final parameterization of the default values.

12/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

3.1

Application characteristics Classification

Recommended QCI 4

Application

Application characteristics

Internet Static Applications

9, 8

Web Browsing

Web page size [MB], Web page reading time [s], Web page waiting time [s], Number of web pages, UL-to-DL ratio [%].

File Downloads

Subscription rate [Mbps], Overbooking factor, Service duration [s], UL-to-DL ratio [%].

E-mail

Number of messages, Message size [kB], UL-to-DL ratio [%].

Messaging

Data volume [kB]

1, 7, 9, 8

Conversation Voice

2, 7, 9, 8

Conversation Video

Bearer rate [kbps], Service duration [s], Activity [%].

3, 7, 9, 8

Streaming

4, 7, 9, 8

Gaming

Internet Multimedia Applications

Table 3-3: Application Mix

The Internet Static Applications are carried using QCI 9 or 8. QCI 6 is excluded because of its original purpose of supporting MPS and QCI 7 is not considered since it is relevant for streaming (see Chapter 2.1). QCI 5 is not present either because it is dedicated for IMS signaling. The Internet Multimedia Applications are defined by the following numbers: • Required bandwidth – throughput required at PDCP layer. This means it considers PHY overhead (CRC), L2 overhead (RLC and MAC) and L3 overhead (IPv4 or IPv6 with or without RoHC). Only then the figure is comparable with L3 cell throughput obtained from system level simulations, • Service duration – the time when a service “occupies the line”. Obviously with PS domain in LTE there is no line booking for CS-like services however this parameter may reflect either the actual call duration time from the end-user perspective or at the network level. In this concept, the call duration which is used for further calculations is defined at the network level, • Activity – speech and interactive services are characterized by specific silence periods when other call parties are active. In this case, the effective data volume is not a 4

Bold font indicates a typical assumption. The sequence of QCIs is not random but reflects the most probable configuration options. Note however that this recommendation assumes all QCIs being available in a system. This is not true especially for early LTE releases.

13/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

product of bandwidth requirement and service duration only but includes an activity factor too. A default QCI is chosen based on Table 2 -1. Additionally QCI 7 is on the list as the only non-GBR option to properly handle “delay in-tolerant” services through a higher priority. Obviously VoIP, video and streaming services can be carried with a default nonGBR QCI 9 (or 8). There is no reason to separate occasional internet video/audio streaming (e.g. YouTube, last.fm, Pandora, etc.) from the rest of best-effort traffic. Same applies to popular VoIP services bundled with many community networks. On the other hand the special operator services such as Network TV may be served with a dedicated bearer ensuring the proper QoS-awareness.

14/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

4.

Traffic demand The total (over all subscribers) traffic demand can be obtained based on the following input data: • Busy Hour Call Attempts (BHCA) • Mean Active UE throughput • Call duration

[] [kbps] [s]

The following formula can be used: TrafficVol ume[ kb] # subscribers  BHCA  CallDuration  MeanActiveUEThr

Throughput [kbps ] 

TrafficVol ume[ kb] 3600 s

TrafficDemand [mErl ] 

# subscribers  BHCA  CallDuration  1000 3600s

The term MeanActiveUEThr refers to the user throughput averaged over the time when it was seen as Active UE in a system. This means the UE was RRC_Connected not necessarily actively using its bearer(s) all the time (see Figure 2 -1).

4.1

Mean Active UE throughput If only the service activity and the required (nominal) bearer rate are known, it is easy to derive MeanActiveUEThr: • Bearer rate • Activity

[kbps] []

MeanActiveUEThr[kbps]  BearerRate  Activity

The above calculation is valid if the considered application gets the resources with a guaranteed bit rate. In case of best effort internet-like traffic it is not possible to derive MeanActiveUEThr from the bearer guaranteed bit rate since this kind of traffic is typically carried on non-GBR bearers which do not give any guarantee that the required bandwidth will be provided. The following relation can be given:

MeanActiveUEThr[kbps] 

MeanSubscriberThr _ inBH [bps]  3600 BHCA  CallDuration  1000

In the 3G Traffic Model for Network Dimensioning [3] MeanSubscriberThr_inBH is given based on measurements from the real networks (i.e. evaluation of available Radio Access Network and Core Network counters). This is currently not possible for LTE dimensioning due to relatively smaller number of deployments and inability to gather sufficient amount of data. For this reason, the LTE Traffic Model for Network Dimensioning introduces the Application Mix which allows for defining customer specific

15/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

traffic profiles. Based on that, MeanSubscriberThr_inBH is derived from the application data volume. MeanSubscriberThr _ inBH [bps] 



applications

4.2

AppDataVol ume[ MB]  10 6  8 3600s

Number of Active UEs The key metric for LTE base station hardware capacity is the number of Active UEs (RRC_Connected UEs). A very simple method of estimating the amount of Active terminals is to apply the Share of Active UEs (see Chapter 9.5 in [9]). However with the newly introduced concept of the LTE Traffic Model for Network Dimensioning, it is recommended to follow the rule presented below:  TrafficVol ume[ kb]# subscriber s  # ActiveUEs     MeanActiveUEThr[ kbps ]  3600 s 

16/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

5.

Other parameters

5.1

Busy Hour concentration Based on PM counters analysis from WCDMA/HSPA performed by NetEng in 2010 [3] it is recommended to apply the numbers listed in Table 5 -4. Service classification according to [3] Speech (equivalent to Conversational Voice)

PS (equivalent to ISA)

Video (equivalent to Conversational Video)

Traffic intensity

Busy Hour daily concentration

Number of Busy Days per month

Low

6%

0.20%

Medium

9.5%

0.32%

High

12.5%

0.42%

Low

6.5%

0.22%

Medium

7%

High

8%

0.27%

Low

8%

0.27%

Medium

10%

0.33%

High

12%

0.40%

30

Busy Hour monthly concentration

0.23%

Table 5-4: Busy Hour concentration according to [3]

Concentration of 0.42% and 0.27% respectively for Speech and PS is aligned with the assumptions of the global NSN TM Roadmap [1].

5.2

Traffic evolution Traffic model is already hardly predictable when there is no input from an operator so any forecast on future trends is by definition characterized by an estimation error. Obviously there are many sources indicating various figures depending on the assumptions therefore all of the available market studies shall be very carefully considered in traffic modeling for dimensioning: • Is the traffic increase from one period to another caused by higher number of subscribers (new subscriptions in a network)? • If the traffic increase is caused by adding new subscribers to a network, is the traffic demand per average subscriber really changing or does it stay the same? • How exactly is the traffic forecasted? If this is a function of Year-over-Year (YoY) increase from previous measurement periods, what is the argument for assuming same trends in the future (e.g. can we expect roughly exponential data volume boom still for next few years?) • Eventually what is the background purpose of a given market study? One shall remember that the LTE Traffic Model for Network Dimensioning is to help estimating the required number of sites and not to overstate data consumption for specific marketing purposes. The concept which underlies dimensioning procedures must be carefully balanced in order to provide a competitive budgetary planning, not to overdimension and not to underestimate the number of network entities.

17/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

An older version of LTE Traffic Model for Network Dimensioning suggested 15% annual traffic increase which is aligned with the current 3G Traffic Model for Network Dimensioning [3]. The NSN Traffic Model Roadmap [1] estimates approximately 21% year by year volume increase (see Table 6 -8) however one shall remember that it treats about all existing and future mobile technologies (2G, 3G and LTE). There is a very important argument for assuming high traffic increase factors at the early deployments. This refers to the fact how the market behaves when a new transmission media becomes available. The volume boom is especially visible when a newly introduced system offers a great quality and throughput improvement for subscribers who do not care too much about the amount of consumed data. For the LTE Traffic Model for Network Dimensioning it is recommended to use 21% annual volume increase as per [1]. This is relevant for the sum of subscriber traffic.

18/27

Unit or Department Piotr Godziewski

6.

Default Traffic Model

6.1

Default Application Mix Application Web Browsing

Document Type For internal use only Date

Application characteristics

Value

Web page size [MB] Web page reading time [s] Web page waiting time [s] Number of web pages UL-to-DL ratio [%]

0.6 MB 12 s 3s 2 5%

Subscription rate [Mbps] Overbooking factor Service duration [s] UL-to-DL ratio [%]

0 Mbps 25 250 s 10%

E-mail

Number of messages Message size [kB] UL-to-DL ratio [%]

1 100 kB 100%

Messaging

Number of messages Message size [kB] UL-to-DL ratio [%]

1 0.01 kB 100%

Conversation Voice

Bearer rate [kbps] Service duration [s] Activity [%]

16 kbps 90 s 50%

Conversation Video

Bearer rate [kbps] Service duration [s] Activity [%]

64 kbps 144 s 50%

Streaming

Bearer rate [kbps] Service duration [s] Activity [%]

100 kbps 60 s 0%

Gaming

Bearer rate [kbps] Service duration [s] Activity [%]

64 kbps 300 s 90%

File Downloads

Table 6-5: Default Application Mix

Web Browsing

19/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

The volume is generated from the number of visited web pages. One shall note that the most of key internet services (social networks, news servers, web-based e-mail clients, etc.) are capable of recognizing a browser engine. This allows for appropriate content tuning in order to make reading on a mobile more comfortable. Usually it is all about compressing or reducing the embedded objects. It can effectively reduce the web page weight. File Downloads This application shall be used very carefully in dimensioning process. In spite of the fact that mobile networks offer more and more capacity to the end-users, most of the operators cannot afford to offer flat rate tariffs without volume limitations. It is very unlikely that it will change with LTE. Therefore any sort of heavy traffic peer-to-peer (p2p) applications shall be applied only after a very careful consideration. From the end-user point of view one can experience the full bandwidth (a subscription rate) only for the periods of time when the network is not heavily loaded. When an operator starts offering DSL-like services usually an overbooking factor is introduced to dimensioning process. The factor determines maximum possible level of throughput degradation when all allowed subscribers request their bandwidth. In this case, an operator is fully aware that the average network capacity can match only a fraction of total bandwidth aggregated over all SIM cards. An insight into DSL fixed network dimensioning would be helpful to guess an overbooking factor when it is not given by a customer. Overbooking of 25 is assumed in the LTE Traffic Model for Network Dimensioning. This means that when the air interface is loaded by all LTE subscribers one can experience just 1/25 of the subscription rate being available. UL-to-DL ratio depends highly on the application characteristics: • Occasional file download (music samples, e-books, software packages, system updates, etc.) does not involve too much of upstream traffic  UL-to-DL ratio is close to 0% for occasional file downloads, • Heavy peer-to-peer (p2p) applications usually allows for configuring how much of the bandwidth (consumed by an application) can be reserved for seeding (upstream portions shared with other peers). One shall remember that assuming 0% UL-to-DL ratio might be a mistake since the p2p networks will most likely not tolerate downstream-only users  UL-to-DL ratio is typically ~10% for standard p2p applications. E-mail and Messaging This kind of traffic has nearly no impact on the overall data volume. For the sake of completeness a size and number of messages can be defined. On the other hand long service duration with a small portion of data transfer can be used in order to reflect the smartphone penetration in a system (i.e. keep-alive messages, which are sent periodically, keep the UE in RRC_Connected for a long time). Conversational Voice

20/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

Voice service in LTE is carried using a dedicated QCI 1. 3GPP recommends IMS architecture for supporting Voice over LTE (VoLTE). Such an All-IP concept makes every VoIP call generate some amount of Session Initiation Protocol (SIP) messages. The SIP volume is however so small compared to overall user data that it is neglected in the LTE Traffic Model for Network Dimensioning.5 Most popular audio coding schemes for voice are AMR yet its wideband variant becomes more and more popular. From the dimensioning perspective the key parameters characterizing VoIP codec are the sample rate and the interval. The sample rate determines how heavy a single VoIP packet is while the interval says how often the consecutive samples are generated by the application layer. Table 6 -6 lists the bandwidth requirements for typical VoIP encoders assuming an IP/RTP/UDP overhead of 40 Bytes or 60 Bytes respectively for IPv4 and IPv6. RLC/MAC/CRC overhead of 32 bits is considered. When the Robust Header Compression (RoHC) is activated, the average compressed header size of 40 bits is assumed for below calculation.

5

SIP is carried on QCI 5 as Non Access Stratum (NAS) traffic being transparent to a base station. Physically it is piggybacked along with the dedicated RRC signaling.

21/27

Unit or Department Piotr Godziewski

Audio codec

Document Type For internal use only Date

Sample rate

Sample interval

Sample size including padding

eUu bandwidth requirement at PDCP layer IPv4

IPv6

IPv4 w/ RoHC

[kbps]

[ms]

[bits]

[kbps]

[kbps]

[kbps]

AMR 1.8

1.8

20

40.0

19.6

27.6

5.6

AMR 4.75

4.75

20

96.0

22.4

30.4

8.4

AMR 5.15

5.15

20

104.0

22.8

30.8

8.8

AMR 5.9

5.9

20

120.0

23.6

31.6

9.6

AMR 6.7

6.7

20

136.0

24.4

32.4

10.4

AMR 7.4

7.4

20

152.0

25.2

33.2

11.2

AMR 7.95

7.95

20

160.0

25.6

33.6

11.6

AMR 10.2

10.2

20

208.0

28

36

14

AMR 12.2

12.2

20

248.0

30

38

16

WB-AMR 1.75

1.75

20

40.0

19.6

27.6

5.6

WB-AMR 6.6

6.6

20

136.0

24.4

32.4

10.4

WB-AMR 8.85

8.85

20

184.0

26.8

34.8

12.8

WB-AMR 12.65

12.65

20

256.0

30.4

38.4

16.4

WB-AMR 14.25

14.25

20

288.0

32

40

18

WB-AMR 15.85

15.85

20

320.0

33.6

41.6

19.6

WB-AMR 18.25

18.25

20

368.0

36

44

22

WB-AMR 19.85

19.85

20

400.0

37.6

45.6

23.6

WB-AMR 23.85

23.85

20

480.0

41.6

49.6

27.6

G.711 (PCM)

64

10

640.0

99.2

115.2

71.2

G.729(a)

8

10

80.0

43.2

59.2

15.2

Table 6-6: VoIP bandwidth requirements

The following is used to derive the PDCP bandwidth requirement: PDCPBandwidth[kbps] 

SampleSize  IPHeader  L 2 Header SampleInterval

IPHeader shall be chosen according to IP protocol version taking into account a possible activation of RoHC. Layer 2 introduces RLC (UM) and MAC overhead. CRC is in fact added after creation of the Transport Block therefore it shall be named as PHY overhead. Figure 6 -2 presents the RoHC gain achievable with various AMR rates.

22/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

Figure 6-2: Robust Header Compression gain for AMR VoIP compared to IPv4 w/o compression

Conversational Video Video calls are dominated with MPEG-2 and MPEG-4 coding combined with an audio stream (e.g. AMR, AAC). The bandwidth requirement is higher than for a typical voice call because a video stream must be carried. However it can be lower than the requirement for streaming since the vision part of a signal is usually more static than in case of streaming movies, TV shows, etc. Streaming Taking into account the variety of video and audio coding techniques it is extremely challenging to choose something default. For the sake of simplicity one example is given in the document showing how much the bandwidth requirement depends on the selected coding scheme. Table 6 -7 presents the aggregated bit rate (including video and audio streams) from empirical measurements using different streaming sources. Obviously the streaming servers usually recognize an application engine trying to adjust the bit rate to device characteristics (i.e. no point in high quality streaming to devices equipped with small, low resolution screens). Moreover, most of the video and audio coding standards provide a capability of scalable bit rate.

23/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

Video codec

Audio codec

Approximate bit rate target on YouTube application (video and audio)

H.264 1920x1080 30 fps

AAC 44.1 kHz stereo

3.75 Mbps

H.264 1280x720 30 fps

AAC 44.1 kHz stereo

2.25 Mbps

H.264 854x480 30 fps

AAC 44.1 kHz stereo

1.25 Mbps

H.264 640x480 30 fps

AAC 44.1 kHz stereo

768 kbps

H.264 480x360 30 fps

AAC 44.1 kHz stereo

768 kbps

Sorenson Spark 320x240 30 fps

MP3 22 kHz stereo

384 kbps

MPEG-4 ASP 176x144 12 fps

AAC 22 kHz mono

100 kbps

H.263+ 176x144 15 fps

AMR 8 kHz mono

75 kbps

Table 6-7: Exemplary streaming bandwidth requirements according to [7]

Gaming Playing online games in an old fashion manner (playing and not downloading when playing; the main game content is locally stored on a device) can usually be played comfortable with a link of 64 kbps. The bandwidth is used for exchanging information about players’ movements (actions) and to support voice chats. Playing an hour of typical online game (stored locally) may consume several MBytes (often less in uplink than in downlink).

6.2

Default Traffic Model While the Default Application Mix presented in Chapter 6.1 provides the reference application characteristic per subscriber a complete traffic model still needs a definition of traffic intensity during the Busy Hour (BH). This is reflected by the Busy Hour Call Attempt (BHCA). One of the preconditions for the document is to leave the traffic model concept open for further enhancements such as future validation against PM data. Certainly it reduces the freedom of defining the model which will be technically suitable for dimensioning and clear enough for easy handling and adjusting to customer requests. At the point of time when this document is released it is not possible to reliably answer the question about typical LTE subscriber behavior based on real networks measurements. A study on PM data is valid only if sufficient amount of information from enough networks is analyzed which is not achievable yet. For this reason an educated engineering approach has been taken and both the NSN TM Roadmap [1] and 3G TM for Network Dimensioning [3] have been used as the main reference materials. The following assumptions have been made out of the mentioned study: • Conversational Voice with 1 BHCA and the call duration of 90 s (according to [1] and roughly aligned with [3] which states 0.92 BHCA with 86 s average call duration). BHCA may vary in range of 0.5..1.5 whereas the call duration in range of 40..130 s according to [1]. • Conversational Video is a marginal fraction of total R99 and HSPA traffic according to [3] which states 0.005 BHCA and the call duration of 144 s for video telephony carried on the CS Conversational UDI 64. Same assumption is recommended for the LTE Traffic Model for Network Dimensioning.

24/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

• There is no clear indication about the fraction of mobile traffic being related to Gaming and (dedicated) Streaming (not related with a typical web-based services) therefore a marginal 0.001 BHCA for Gaming and 0.1 BHCA for Streaming is recommended combined with the average call duration of 300 s and 60 s respectively for Gaming and Streaming (call durations according to [1]). • Since the overall Internet Static Application traffic is aggregated in a single bearer (QCI 9 or 8) it does not make sense to differentiate among these kinds of (best-effort) applications because it will not be possible with live PM data either. NetEng study performed for the 3G Traffic Model for Network Dimensioning concluded 0.7 BHCA for data services mapped to PS Interactive/Background RAB with the average subscriber demand of 1631 bps including Release99 and HSPA carriers. A great portion is carried in HSPA (1305 bps out of the total PS traffic). The NSN TM Roadmap [1] also provides an insight into the average data service demand (see Table 6 -8). It is recommended to check the traffic model output with the figures below. It may deviate to a certain extent. Such validation could be a basis for further clarification with a customer which may have misunderstood a traffic model concept in dimensioning process. 570 MB monthly data corresponding to 3247.9 bps BH traffic demand is used as reference in the LTE Traffic Model for Network Dimensioning. Operator profile

Monthly usage [MB/month]

CAGR 2012..2015

4Q2009-3Q2011

Y2012

Y2015

Voice Centric

130

285

500

21%

Middlefield

370

570

1000

21%

Data Centric

1030

1000

1500

14%

Average

390

570

1000

21%

Busy Hour concentration (PS)

1/13/30 = 0.26% BH traffic demand [bps]

Voice Centric

740.7

1623.9

2849.0

Middlefield

2108.3

3247.9

5698.0

Data Centric

5868.9

5698.0

8547.0

Average

2222.2

3247.9

5698.0

Table 6-8: Monthly data consumption according to [1]

• A great number of LTE operators limits the maximum transferred volume by introducing data caps into their offers (same with HSPA). Data caps vary from 5 GB (NTT DoCoMo) up to 20..30 GB (in Europe) 6. When considering heavy traffic scenarios such as Mobile Broadband (MBB) it is worth to check a margin between monthly data consumption from the user defined traffic model and a data cap foreseen by a customer.

6

Based on the market report from April 2011 [8]

25/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

7.

Open points and future enhancements Further enhancements of the LTE Traffic Model for Network Dimensioning are foreseen in the future following the open points listed below: • The LTE Traffic Model for Network Dimensioning shall be ready for future validation and possible calibration with PM data from commercial LTE networks, • The LTE Traffic Model for Network Dimensioning shall consider the eNB load by evaluating the number of events impacting the System Module DSP processing power, • The LTE Traffic Model for Network Dimensioning shall consider the UE split mainly for determining the number of mobility related events impacting the eNB load.

7.1

Validation with PM data The following RAN counters could be used to validate the current traffic model assumptions: • EPS_SETUP_ATT & EPS_SETUP_SUCC, • DRB_SETUP_ATT & DRB_SETUP_SUCC, • CELL_THROUGHPUT_PDCP as a function of CELL_VOLUME_PDCP. The number of attached subscribers shall be known from the Evolved Packet Core (EPS) counters to properly calculate metrics per (attached) UE.

7.2

UE split A UE split has been introduced in [1] and is also reflected in the NW View Traffic Model in [2]. It is unlikely to find a simple method for future validation of the assumed UE split with the real network PM data. One shall realize that using a certain UE mix for dimensioning may be a source of additional estimation error unless it is clearly specified by an operator. The LTE Traffic Model for Network Dimensioning presented in this document does not explicitly support any sort of terminal differentiation and yet it is possible to properly recalculate the BH traffic demand using the Application Mix concept. One shall execute separate calculations of the Busy Hour traffic demand depending on a UE type and sum them all considering a given terminal type penetration. It is just a common and very general practice to treat a UE type and a user behavior evenly. In other words it is not a device type itself which defines how an average subscriber will use it. Still this is usually true when a majority of subscribers use devices according to their original targets. The rule which cannot be forgotten is that nobody shall ever try to reflect the average subscriber behavior with his or her own tendencies as it is the worst mistake which can be made. Mobility characteristic of considered terminals may significantly impact eNB load estimation.

26/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

7.3

Base station load Engineers who have a technical background on base station load dimensioning (base band dimensioning) are most probably familiar with a term of Channel Element which is widely used for evaluating processing capabilities of a WCDMA base station. In case of LTE base station I&V department is responsible for doing similar evaluations which are later on reflected in [2]. Future versions of the LTE Traffic Model for Network Dimensioning shall enhance the whole concept by a method which would allow for calculating how much of the Flexi System Module processing power is consumed by events such as BHCA setup, release, UE state transitions, handovers, Timing Advance Updates, paging, etc.: • Every UE type shall be defined by a set of events, • Every event shall be explicitly mapped to the fraction of DSP processing consumption, • A method shall be proposed to aggregate over all the subscribers (all UE types) and all the events to reflect a single eNB load, • eNB load shall be an indicator for further base band dimensioning process.

27/27

Unit or Department Piotr Godziewski

Document Type For internal use only Date

Abbreviations 3GPP AAC AMR BH BHCA CAGR CRC DRX E-UTRA FTP GBR GPRS HSPA I&V IMS IP MAC MBB MPEG MPS NetEng O&M PCEF PDCP PS QCI QoS RTP RLC RoHC RRC SAE-GW SFS TCP UDP UMTS VoLTE WCDMA WDSL

Third Generation Partnership Project Advanced Audio Coding Adaptive Multi Rate Busy Hour Busy Hour Call Attempt Compound Annual Growth Rate Cyclic Redundancy Check Discontinuous Receiving Evolved UMTS Terrestrial Radio Access Network File Transfer Protocol Guaranteed Bit Rate General Packet Radio Service High Speed Packet Access Integration and Verification IP Multimedia Subsystem Internet Protocol Medium Access Control Mobile Broadband Moving Picture Experts Group Multimedia Priority Services Network Engineering Operation and Maintenance Policy and Charging Enforcement Function Packet Data Convergence Protocol Packet System QoS Class Identifier Quality of Service Real Time Protocol Radio Link Control Robust Header Compression Radio Resource Control Serving Gateway System Feature Specification Transmission Control Protocol User Datagram Protocol Universal Mobile Telecommunications System Voice over LTE Wideband Code Division Multiple Access Wireless DSL