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’sDocument Type
Unit or Department
Revision History Version Date Change Notes
0.1..0.3 2009..2010 Early documentation by Jacek Ryzner
1.0 Oct 2011 Approved for LTE air interface and access dimensioning
Authors
Name Department
Table of contents
1.
Introduction...6
1.1 Scope...6
1.2 Point of reference...6
2.
LTE bearers and state handling...7
2.1 Bearer architecture...7 2.2 UE state handling...9 2.3 Definitions...10
3.
Application Mix...12
3.1 Application characteristics...134.
Traffic demand...15
4.1 Mean Active UE throughput...15
4.2 Number of Active UEs...16
5.
Other parameters...17
5.1 Busy Hour concentration...17
5.2 Traffic evolution...17
6.
Default Traffic Model...19
6.1 Default Application Mix...19
6.2 Default Traffic Model...24
7.
Open points and future enhancements...27
7.1 Validation with PM data...27
7.2 UE split...27
7.3 Base station load...28
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
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.
1.
Introduction
1.1
Scope
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.
2.
LTE bearers and state handling
2.1
Bearer architecture
A list of E-UTRA bearers and their specification is standardized in [4]. QCI Resource type Priority Packet delay budget Packet loss error rate Example services 1 GBR 2 100 10-2 Conversational voice
2 4 150 10-3 Conversational video (live
streaming)
3 5 300 10-6 Non-conversational video
(buffered streaming)
4 3 50 10-3 Real time gaming
5
Non-GBR
1 100 10-6 IMS signaling
6 7 100 10-3 Video (buffered streaming),
TCP-based (e.g. WWW, e-mail, chat, FTP, p2p file sharing, progressive video, etc.)
7 6 300 10-6 Voice,
Video (live streaming), Interactive gaming
8 8 300 10-6 Video (buffered streaming),
TCP-based (e.g. WWW, e-mail, chat, FTP, p2p file sharing, progressive video, etc.)
9 9 300 10-6
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.
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 Conversational N/A 10-3 1 4 or 5 4 Streaming N/A 10-6 1 2 5 Interactive 1 10-6 1 2 6 Interactive 1 10-6 1 2 7 Interactive 2 10-3 2 4 or 5 8 Interactive 3 10-6 3 2 9 Background N/A 10-6 4 2
Table 2-2: QoS profiles mapping between LTE, UMTS and GPRS ([4])1
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).
2.3
Definitions
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 <Mean []
per Subscriber> 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.
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.
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] Internet Multimedia Applications 1, 7, 9, 8 Conversation Voice Bearer rate [kbps], Service duration [s], Activity [%]. 2, 7, 9, 8 Conversation Video 3, 7, 9, 8 Streaming 4, 7, 9, 8 Gaming
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.
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 non-GBR 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.
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 [kbps]
• Call duration [s]
The following formula can be used:
UEThr MeanActive on CallDurati BHCA s subscriber kb ume TrafficVol [ ]# s kb ume TrafficVol kbps Throughput 3600 ] [ ] [ s on CallDurati BHCA s subscriber mErl and TrafficDem 3600 1000 # ] [
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 [kbps] • Activity [] Activity BearerRate kbps UEThr MeanActive [ ]
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:
1000 3600 ] [ _ ] [ on CallDurati BHCA bps inBH iberThr MeanSubscr kbps UEThr MeanActive
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
traffic profiles. Based on that, MeanSubscriberThr_inBH is derived from the application data volume.
ns applicatio s MB ume AppDataVol bps inBH iberThr MeanSubscr 3600 8 10 ] [ ] [ _ 64.2
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:
s kbps UEThr MeanActive s subscriber kb ume TrafficVol ActiveUEs 3600 ] [ # ] [ #
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] Traffic intensity Busy Hour daily concentration Number of Busy Days per month Busy Hour monthly concentration Speech (equivalent to Conversational Voice) Low 6% 30 0.20% Medium 9.5% 0.32% High 12.5% 0.42% PS (equivalent to ISA) Low 6.5% 0.22% Medium 7% 0.23% High 8% 0.27% Video (equivalent to Conversational Video) Low 8% 0.27% Medium 10% 0.33% High 12% 0.40%
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.
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%
6.
Default Traffic Model
6.1
Default Application Mix
Application Application characteristics Value
Web Browsing 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 3 s 2 5% File Downloads 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%
Table 6-5: Default Application Mix
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).
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
Audio codec 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:
rval SampleInte Header L IPHeader SampleSize kbps dth PDCPBandwi [ ] 2
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: 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.
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.
• 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.
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.
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,
Abbreviations
3GPP Third Generation Partnership Project
AAC Advanced Audio Coding
AMR Adaptive Multi Rate
BH Busy Hour
BHCA Busy Hour Call Attempt
CAGR Compound Annual Growth Rate
CRC Cyclic Redundancy Check
DRX Discontinuous Receiving
E-UTRA Evolved UMTS Terrestrial Radio Access Network
FTP File Transfer Protocol
GBR Guaranteed Bit Rate
GPRS General Packet Radio Service
HSPA High Speed Packet Access
I&V Integration and Verification
IMS IP Multimedia Subsystem
IP Internet Protocol
MAC Medium Access Control
MBB Mobile Broadband
MPEG Moving Picture Experts Group
MPS Multimedia Priority Services
NetEng Network Engineering
O&M Operation and Maintenance
PCEF Policy and Charging Enforcement Function
PDCP Packet Data Convergence Protocol
PS Packet System
QCI QoS Class Identifier
QoS Quality of Service
RTP Real Time Protocol
RLC Radio Link Control
RoHC Robust Header Compression
RRC Radio Resource Control
SAE-GW Serving Gateway
SFS System Feature Specification
TCP Transmission Control Protocol
UDP User Datagram Protocol
UMTS Universal Mobile Telecommunications System
VoLTE Voice over LTE
WCDMA Wideband Code Division Multiple Access
