Impact of Transport Network Impairments On WCDMA Network Performance

Impact of Transport Network Impairments on
WCDMA Network Performance

Disclaimer
The information in this document is subject to change without notice and describes only the product defined in the
introduction of this documentation. This documentation is intended for the use of Nokia Solutions and Networks
customers only for the purposes of the agreement under which the document is submitted, and no part of it may be
used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia
Solutions and Networks. The documentation has been prepared to be used by professional and properly trained
personnel, and the customer assumes full responsibility when using it. Nokia Solutions and Networks welcomes
customer comments as part of the process of continuous development and improvement of the documentation.
The information or statements given in this documentation concerning the suitability, capacity, or performance of the
mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or
software products shall be defined conclusively and finally in a separate agreement between Nokia Solutions and
Networks and the customer. However, Nokia Solutions and Networks has made all reasonable efforts to ensure that
the instructions contained in the document are adequate and free of material errors and omissions. Nokia Solutions
and Networks will, if deemed necessary by Nokia Solutions and Networks, explain issues which may not be covered
by the document.
Nokia Solutions and Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL
NOKIA SOLUTIONS AND NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY
DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR
CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT
OR THE INFORMATION IN IT.
This documentation and the product it describes are considered protected by copyrights and other intellectual
property rights according to the applicable laws.
The wave logo is a trademark of Nokia Solutions and Networks Only. Nokia is a registered trademark of Nokia
Corporation.
Other product names mentioned in this document may be trademarks of their respective owners, and they are
mentioned for identification purposes only.
Copyright Â© Nokia Solutions and Networks 2012. All rights reserved.

Contents
1. Summary of changes
2. Introduction of Impact of Transport Network Impairments on WCDMA Network Performance
3. Measurement methods
3.1. Introduction
3.1.1. General assumptions
3.1.2. Test network architecture
3.1.3. Test setup
4. Iub performance values
4.1. Procedure KPIs
4.1.1. Mobile to Mobile AMR Call Setup Time
4.1.2. PDP Context Activation Accept
4.1.3. HSPA Call Setup Time with F-DPCH
4.1.4. Round Trip Time (RTT) on DCH
4.1.5. Round Trip Time (RTT) on HSPA
4.2. Throughput vs. impairment values
4.2.1. HSDPA results
4.2.2. HSUPA results
4.2.3. R99 results
4.3. Line break tests
4.3.1. RAN behavior
4.3.2. Services
5. Iu performance values
5.1. Procedure KPIs
5.2.3. R99 results
6. Summary
7. Appendix
7.1. IEEE1588v2 Timing over Packet (ToP)
7.2. 3GPP QoS requirements
7.3. Message flows
1. Summary of changes
Issue 01A (2011-04-21, WCDMA RAN RU20)
Chapter 4. Iu performance values has been added.
Issue 01 (2010-12-01, WCDMA RAN RU20)

This is the first issue of the document.
Id: DN0983316 © 2016 Nokia Solutions and Networks. All rights reserved.
2. Introduction of Impact of Transport Network Impairments on

WCDMA Network Performance
This document describes several inherent system dependencies from transmission network performance. Based on
those dependencies, conclusions can be drawn for the requirements for the IP transport network. The values
presented in this document represent Nokia's current best understanding. All measurements presented in this
document were taken in an unloaded network, so capacity issues were not checked.
When considering IP based Iub and Iu links, higher degradation may be expected because of the traffic characteristic,
system setup, and software release. Nokia recommends choosing link parameters according to the operator’s
strategy and service quality policy.
This document is divided into the following sections:
Section 2 specifies site conditions. Those conditions were used to measure KPIs presented in Sections 3
and 4.
Section 3 presents the impact of IP Iub transmission network impairments on certain RU20 KPIs.
Section 4 presents the impact of IP Iu transmission network impairments on certain RU20 KPIs.
Section 5 includes the test results summary.
Section 6 is an appendix with message flows and 3GPP QoS parameters. Also, brief ToP service
requirements are presented.
Note: NOTE: The measurements are done with RU20 release.
3. Measurement methods
Related resources
More on this topic
Introduction
3.1. Introduction
This section specifies the network conditions used in all tests.
Note: The measurement methods are done in RU20 release.
Related resources
More on this topic
General assumptions
Test network architecture
Test setup
Parent topic: Measurement methods
3.1.1. General assumptions

When introducing Packet Switched Network (PSN) for mobile backhaul solutions, at least the following parameters
need to be defined:
Static delay
Packet Delay Variation – Jitter
Packet Loss
Key Performance Indicators (KPIs) are affected when additional delay or increased packet loss is imposed by the
mobile backhaul network. However, the influence might be negligible or even acceptable.
The impact on KPIs depends on:
configuration of the network elements (used HW and interfaces)
features and services used
load conditions
Related resources
Parent topic: Introduction
3.1.2. Test network architecture

During Nokia transmission lab tests the following equipment was used:
RNC196 RU20 On Top release
Flexi WCDA BTS system module 2: RU20 On Top release
SGSN: J7
MSC: ME 9
HLR: ME 9
MGW: U4 7
Flexi ISN Rel 4
Client PC with Windows XP default settings
FTP Server on Ubuntu
List of active features that may impact the results:
RAN1262: HSPA QoS Aware Scheduling YES
RAN1110: HSDPA Congestion Control YES
RAN992: HSUPA Congestion Control NO
The lab test conditions assume generic network architecture. The architecture is depicted in Figure: IP Iu tests.
Figure: IP Iu tests
Related resources
3.1.3. Test setup

Laboratory conditions:
one single UE, or two UEs in case of Mobile to Mobile call setup time, connected to an unloaded Node B
wired RF connection with 30 dB attenuation between BTS antenna and UE
both HSDPA and HSUPA active in the network
stationary UEs, no Handover / no mobility takes place during the testing session
static radio conditions
Iub IP based Node B connected to the RNC with a 100 Mbps link
RNC committed bandwidth 90 Mbps
IP based Iu with 1 Gb/s
Internal Flow Control set OFF
timing over Packet as a synchronization source
Packet Storm IP network emulator was used to introduce additional delay, jitter, and packet loss as described below.
Both user and control plane were impacted by impairments, as described below.
Used impairments values (UL/DL):
Mean Delay: 10–100 ms, exponential distribution
Jitter: peak-to-peak value: 2.5 ms on Iub and 10 ms on Iu ms
PLR: 0.1% on Iub and 0.05% on Iu 0.1%
Measurements were taken for fixed jitter and packet loss values while applying different delay settings. Graphs in the
document are presented as a function of one way delay on tested interface. See Table: Measurement settings for
both interface for interface measurement delay.
Table: Measurement settings for both interface
Interface delay (ms) jitter (ms) PLR (%)
0 0 0
Iub 10 2,5 0,1
Iu 10 10 0, 05
Packet Storm settings with exponential distribution

Average delay equals defined delay
Min delay is Average delay – jitter
Max delay is average delay + 6.62 * jitter
Example: Delay = 30 ms, jitter = 2.5 ms
Average delay 30 ms, min 27.5 ms, max 30 + 6.62 * 2.5 = ~50 ms
Jitter settings of Packet Storm not used
Packet re-ordering off
Figure: Exponential delay distribution
The following chapters cover performance degradation, when above conditions are applied on Iub - chapter 3 and Iu -
chapter 4. Only one interface was impacted at the time, as tests were executed separately.
Related resources
4. Iub performance values

Related resources
More on this topic
Procedure KPIs
Throughput vs. impairment values
Line break tests
4.1. Procedure KPIs

This section presents measurement results for several E2E KPIs: Mobile to Mobile call Setup Time, RTT on DCH and
HSPA, PDP Context Accept Time, and HSPA Call Setup Time with F-DPCH. Actual results are presented with dark
blue diamonds while theoretical calculations with the pink squares.
Related resources
More on this topic
Mobile to Mobile AMR Call Setup Time
PDP Context Activation Accept
HSPA Call Setup Time with F-DPCH
Round Trip Time (RTT) on DCH
Round Trip Time (RTT) on HSPA
Parent topic: Iub performance values

Measurements were taken with Nokia 6260 Classic UEs.
The expected result in the worst-case scenario for the first triple should be 400 ms longer Call Setup Time. This
comes from the following calculations (message flows in appendix), see Table: Rationale for Call Setup Time.
Table: Rationale for Call Setup Time
Message Exchange Delay (ms)

Message Exchange Delay (ms)
RRC messages= 2 * 8 160
NBAP messages= 2 * 6 120
NAS messages= 2 + 3 50
Total 330
Packet Loss impact 2
Results
Figure: IP Iub delay vs. mobile to mobile call setup time
M2M Call Setup Time without impairment on the Iub interface is 3.4 s. When applying additional impairments on the
Iub link, the time increases +280 ms on average per additional 10 ms delay step. The results are similar to those
expected from the calculations. Almost linear dependency is presented in the figure with a trend line. In addition, Call
Setup Success Rate was checked. For all points presented in the figure, it was 100%.
Related resources
Parent topic: Procedure KPIs

The measurements were taken with a Nokia 6260 Classic.
The additional contribution for the PSN profile should be less than 150 ms for the first triple.
Table: Rationale for PDP Context Accept
Message
Delay (ms)
Exchange
RRC messages= 100

10
NBAP 20
messages= 2
Total 120
�Packet Loss 1
impact
Results
Figure: Impact of Iub delay on PDP Context Activation Time
Without impairments, PDP Context Activation Accept takes 1.75 s. When applying additional impairments on the Iub
link, the time increases +107 ms on average per additional 10 ms delay step. The results are similar to those
expected from the calculations. Almost linear dependency is presented in the figure with a trend line.
Related resources
With RU20 new feature, Fractional DPCH has been introduced. The expected improvement is an HSPA Call Setup
Time of around one second.
The measurements were taken with non-commercial UE.
Table: HSPA Call Setup Time with F-DPCH
Message exchange Delay (ms)
RRC messages = 7 70
NBAP messages= 5 40
Total 110
Figure: Impact of Iub delay on HSPA Call Setup Time with F-DPCH
Without impairment, HSPA Call Setup Time with F-DPCH takes 1.07 s. When applying additional impairments on the
Iub link, the time increases +110 ms on average per additional 10 ms delay step. The results overlap with those
expected from the calculations. Almost linear dependency is presented in the figure with a trend line.
Related resources
The measurements were taken with 32 byte and 1400 byte ping. Number of samples: 1000; used UE: Nokia 6260
Classic.
Additional configuration information are:
UE QoS Profile: Uplink Max Bit Rate: 64 kbps; Downlink Max Bit Rate 384 kbps
TOAWE and TOAWS set respectively to 5 ms and to 15 ms
Ping reply requires no more than +25 ms for 32 byte and no more than +40 ms for 1400 byte ping for the first triple.
The estimated degradation comes from the following:
additional 10 ms per transmission direction for all test cases due to PSN static delay for sending the ping
and ping reply
additional impact of packet losses for 32 byte ping is + 1.2 ms and + 17 ms for 1400 byte ping
Results
Figure: 32 byte ping vs. IP Iub delay on R99
Figure: 1400 byte ping vs. IP Iub delay on R99

Without additional impairments, 105 ms RTT was achieved for 32 byte ping and 323 ms for 1400 byte ping. When
applying additional impairments on the Iub link, the time increases +20 ms on average per additional 10 ms delay
step. The results are as expected from the calculations.
Related resources

The measurements were taken with 32 byte and 1400 byte ping. Number of samples: 1000; used UE: Nokia 6260
Classic.
Additional configuration information are:
UE QoS Profile- Uplink Max Bit Rate: 2000 kbps
Downlink Max Bit Rate 4000 kbps
HSUPA 10 ms TTI
Results
Without additional impairments, 45 ms was achieved for 32 byte ping and 82 ms for 1400 byte ping. When applying
additional impairments on the Iub link, the time increases 20 ms on average per additional 10 ms delay step. The
results are similar to those expected from the calculations; also no lost packets were observed. PLR impact from
rational was neglected.
Figure: 32 byte ping vs. IP Iub delay on HSPA

Figure: 1400 byte ping vs. IP Iub delay on HSPA
Related resources
The FTP data throughput was measured under laboratory conditions, to check the impact of the IP Iub delay, packet
loss ratio, and jitter. The delay impact increases when the FTP file size decreases. TCP Win size is an important
factor of FTP throughput performance. If there are many small files, which is typical for a web page, the overall results
could be worse than those presented in the following figures. See, Table: Configurations checked.
Table: Configurations checked
HSDPA 4 Mb/s HSUPA 2Mb/s HSUPA 5.8 Mb/s R99
DL (kb/s) 4096 4096 4096 384
UL (kb/s) 2048 2048 6400 64
file size 2.49 GB 500 MB 500 MB 2.49 GB
used UE Nokia 6260 Classic Non-commercial Nokia 6260

Classic without
HSPA
Related resources
More on this topic
HSDPA results
HSUPA results
R99 results

In the figures below, the dependency of HSDPA data throughput and Iub delay is shown for two jitter settings and
PLR 0.1%. The third curve represents 2.5 ms jitter and PLR 0.5%.
With default settings, throughput degradation below 25% was reached for a delay of 80 ms. For 200 ms, a 50%
downgrade was measured. When increasing jitter to 10 ms, a 50% downgrade was reached with 175 ms, while for a
higher PLR with 150ms. As the delay increases, the curves become similar.
Figure: HSDPA FTP Data throughput vs. IP Iub delay

HSDPA vs. jitter
Figure: HSDPA FTP Data throughput vs. IP Iub jitter – wide range
Figure: HSDPA FTP Data throughput vs. IP Iub jitter

HSDPA vs. PLR
Figure: HSDPA FTP Data throughput vs. IP Iub PLR – wide range
Figure: HSDPA FTP Data throughput vs. IP Iub PLR

Related resources
Parent topic: Throughput vs. impairment values

Two HSUPA services were tested:
2Mb/s with 10 ms TTI
5.8 Mb/s with 2 ms TTI
In the following figure, the dependency of HSUPA 2 Mbps data throughput and Iub delay is shown for default
impairment profile jitter 2.5 ms and PLR 0.1%.
Figure: HSUPA 2 Mb/s FTP Data throughput vs. IP Iub delay

HSUPA 2Mb/s offers lower a bit rate, so the impact of impairments should be relatively low. For up to 40 ms delay,
degradation is low, below 10%. With 70 ms, throughput is still higher than 1 Mb/s. With 100 ms, half of the starting
value was reached.
The same impairment profile was applied to HSUPA 5.8 Mb/s.
Without impairment, 4.4 Mb/s was reached. With 25 ms, delay performance dropped about 25%. When increasing the
delay to 75 ms, throughput dropped to 50% of the starting value. With a 100 ms delay, 1.8 Mb/s was reached.
Figure: HSUPA 5.8 Mb/s FTP Data throughput vs. IP Iub delay
HSUPA 5.8 Mb/s vs. jitter

When testing HSUPA against jitter with a Gaussian distribution, the following result was achieved.
Figure: HSUPA 5.8 Mb/s FTP Data throughput vs. Iub jitter
8 ms jitter is the last point where transmission is above 4 Mb/s. When reaching 10 ms, the measured throughput was
~150 kb/s, but transmission was still possible. Throughput reached 0 with 150 ms.
HSUPA 5.8 Mb/s vs. PLR
Figure: HSUPA 5.8 Mb/s FTP Data throughput vs. Iub PLR
With Packet Loss up to 3%, almost linear dependency was measured. For 5%, the throughput was ~70 kb/s, but
transmission was still possible. Throughput reached 0 with 50% PLR.
Related resources
4.2.3. R99 results

For release 99, only 10 ms jitter with 0.1% PLR was tested. The maximum delay applied was 200 ms. R99 is very
resilient against all impairments. For 200 ms, the data rate dropped about 21%.
Figure: R99 FTP data throughput vs. IP Iub delay
Related resources
4.3. Line break tests

The purpose of this test case was to check the system behavior in case of Iub link interruption.
Related resources
More on this topic
RAN behavior
Services
4.3.1. RAN behavior

With a 5 s link break, the cell was still on air. NBAP was not released and SCTP was not aborted. The only alarm
visible was BTS LOS, meaning no signal is received on the interface. NBAP was released with SCTP abort when
break last 7 s.
Related resources
Parent topic: Line break tests
4.3.2. Services
AMR Call
The call was still active with a 2 s break. From 3 to 5 s the call was re-established. Starting from 5 s the cell was
down.
R99 & HSPA NRT
Up to 5 s break, FTP transfer was continued after recovery. The RAB was not released.
O & M - NetAct
Maximum timeout is defined in the RNC, as interval timer * maximum timeout counter. With default settings this would
be 30 s * 2 = 60 s. After that time, alarm FAILURE IN WCDMA WBTS O&M CONNECTION should be raised and
O&M connection goes down.
Related resources
Parent topic: Line break tests
5. Iu performance values
Related resources
More on this topic
Procedure KPIs
Throughput vs. impairment values
5.1. Procedure KPIs

This section presents the measurement results for several E2E KPIs: Mobile to Mobile call Setup Time, RTT on DCH
and HSPA, PDP Context Accept Time, and HSPA Call Setup Time with F-DPCH. The actual results are presented
with dark blue diamonds while the theoretical calculations with the pink squares.
Related resources
More on this topic
PDP Context Activation Accept
HSPA Call Setup Time with F-DPCH
Round Trip Time (RTT) on DCH
Round Trip Time (RTT) on HSPA
Parent topic: Iu performance values

The measurements were taken with Nokia 6260 Classic UEs.
The expected result in the worst-case scenario for the first triple should be 200 ms longer Call Setup Time. This
comes from the following calculations (message flows in appendix), see Table 6 Rationale for Call Setup Time.
Table: Rationale for Call Setup Time
RANAP messages= 2*8 160
CC messages= 3 30
Total 190
Results
Figure: IP Iu delay vs. mobile to mobile call setup time
M2M Call Setup Time without impairment on Iu interface is 3.7 s. When applying additional impairments on the Iu link,
the time increases +173 ms on average per additional 10 ms delay step. The results are similar to those expected
from the calculations. Due to loaded CS core, results are scattered around a trend line. In addition Call Setup
Success Rate was checked. For all points presented in the figure, it was 100%.
Related resources

The measurements were taken with a Nokia 6260 Classic.
Table: Rationale for PDP Context Accept
NAS message= 2 20
RANAP messages= 6 60
Total 80
Results
Figure: Impact of Iu delay on PDP Context Activation Time
Without impairment, PDP Context Activation Accept takes 1.8 s. When applying additional impairments on the Iu link,
the time increases +77 ms on average per additional 10 ms delay step. The results are similar to those expected from
the calculations. Almost linear dependency is presented in the figure with a trend line.
Related resources

With RU20 new feature, Fractional DPCH has been introduced. The expected improvement is an HSPA Call Setup
Time of around one second.
The measurements were taken with non commercial UE.
RANAP messages= 6 60
Figure: Impact of Iu delay on HSPA Call Setup Time with F-DPCH

Without impairment, HSPA Call Setup Time with F-DPCH takes 1.19 s. When applying additional impairments on the
Iu link, the time increases +61 ms on average per additional 10 ms delay step. The results are close to the
calculations. Almost linear dependency is presented in the figure with a trend line.
Related resources

The measurements were taken with 32 byte and 1400 byte ping. The number of samples are 1000, and the used UE
is Nokia 6260 Classic.
Additional configuration information:
UE QoS Profile: Uplink Max Bit Rate: 64 kbps, Downlink Max Bit Rate 384 kbps
TOAWE and TOAWS set respectively to 5 ms and to 15 ms
Ping reply requires no more than +25 ms for 32 byte and no more than +40 ms for 1400 byte ping for the first triple.
The estimated degradation comes from the following:
additional 10 ms per transmission direction for all test cases due to PSN static delay for sending the ping
and ping reply
additional impact of packet losses for 32 byte ping is + 1.2 ms and + 17 ms for 1400 byte ping
Results
Figure: 32 byte ping vs. IP Iu delay on R99
Figure: 1400 byte ping vs. IP Iu delay on R99
Without additional impairments, RTT 128 ms was achieved for 32 byte ping and 334 ms for 1400 byte ping. When
applying additional impairments on the Iu link, the time increases +20 ms on average per additional 10 ms delay step.
The results are as expected from the calculations.
Related resources

The measurements were taken with 32 byte and 1400 byte ping. The number of samples are 1000 and the used UE
is Nokia 6260 Classic.
The additional configuration information used were UE QoS Profile: Uplink Max Bit Rate: 2000 kbps, Downlink Max
Bit Rate 4000 kbps, HSUPA 10 ms TTI.
Results
Without additional impairments, 46 ms was achieved for 32 byte ping and 50 ms for 1400 byte ping. When applying
additional impairments on the Iu link, the time increases 20 ms on average per additional 10 ms delay step. The
results are similar to those expected from the calculations, also no lost packets were observed. PLR impact from
rational was neglected.
Figure: 32 byte ping vs. IP Iu delay on HSPA
Figure: 1400 byte ping vs. IP Iu delay on HSPA

Related resources

The FTP data throughput was measured under laboratory conditions, to check the impact of the IP Iu delay, packet
loss ratio, and jitter. The delay impact increases when the FTP file size decreases. The TCP Win size is important
factor of FTP throughput performance. If there are many small files, which is typical for a web page, the overall results
could be worse than those presented in the following figures.
Configurations checked:
Note: During all FTP transfer tests, MTU set on the FTP server was reduced to 1450 bytes.
Table: Checked configurations
HSDPA 4 Mb/s HSUPA 2 Mb/s HSUPA 5.8 Mb/s R99
DL (kb/s) 4096 4096 13000 386
UL (kb/s) 2048 2048 6400 64
file size 2.49 GB 500 MB 500 MB 2.49 GB
used UE Nokia 6260 Classic Non-commercial Nokia 6260

Classic without
HSPA
Related resources
More on this topic
HSDPA results
HSUPA results
R99 results
Parent topic: Iu performance values

In the figure below, the dependency of HSDPA data throughput and Iu delay is shown for jitter 10 ms and PLR 0.05%,
which is default configuration for all Iu tests.
The throughput reached 75% of maximum value for a delay of 30 ms. and with 100 ms delay, more than 50% of
starting value was measured.
Figure: HSDPA FTP Data throughput vs. IP Iu delay
Related resources
Two HSUPA services were tested:
2Mb/s with 10 ms TTI
5.8 Mb/s with 2 ms TTI
In the following figure the dependency of HSUPA 2 Mb/s data throughput and Iu delay is shown for default impairment
profile jitter 10 ms and PLR 0.05%.
Figure: HSUPA 2 Mb/s FTP Data throughput vs. IP Iu delay
HSUPA 2Mb/s offers lower a bit rate, so the impact of impairments should be lower and for up to 40 ms delay,
degradation is minimal (below 10%). From that point, throughput drops less than 100 kb/s with every additional 10 ms
of Iu delay. With 100 ms Iu delay, throughput was still slightly higher than 1 Mb/s.
The same impairment profile was applied to HSUPA 5.8 Mb/s.
With 2 ms TTI HSUPA 5.8 Mb/s FTP transfer reached 4.8 Mb/s. When applying impairment default profile, throughput
dropped to 3.16 Mb/s with 10 ms delay on Iu. Increasing delay caused further degradation. With 40 ms, only half of
the nominal bit rate and with 100 ms 1.5 Mb/s upload was measured.
Figure: HSUPA 5.8 Mb/s FTP Data throughput vs. IP Iu delay

HSUPA 5.8 Mb/s vs. PLR
Figure: HSUPA 5.8 Mb/s FTP Data throughput vs. Iu PLR4
Packet loss should not be present on the Iu interface, as very small percentage of lost packets impacts all connection
oriented services, like FTP. Almost linear dependency in the measured range is presented with the trend line.
Throughput drops 200 kb/s on average with every 0.01% PLR on Iu. With 0.05% PLR used in default impairment
profile, the throughput dropped to 3.58 Mb/s.
Related resources
5.2.3. R99 results

R99 is very resilient against all impairments. Within the whole range, throughput was higher than 370 kb/s with default
profile, see Figure 31 R99 FTP data throughput vs. IP Iu delay .
Figure: R99 FTP data throughput vs. IP Iu delay
Related resources
6. Summary
When introducing impairments to the RAN interfaces, the impact on each KPI is dependent on the type of impairment
and the type of bearer. The measured values presented in the document are:
aligned with theoretical calculations
throughput tests results, which clearly depend on the bearer used
It is important to note that end user performance depends on a total delay budget. The graphs present only additional
one-way delay injected to the tested interface. Tests for Iub and Iu were executed separately and the results should
not be combined.
Iub and Iu vulnerability varies for different impairments. For example PLR is very destructive especially with high
bitrates on Iu. To deliver services with high QoE, mobile operator should avoid packet loss in the network.
Measured values strongly depend on the network configuration and system parameter settings. Therefore it cannot be
guaranteed that exactly the same measured KPI values can be replicated with a different network setup.
The presented material provides the information on the effect on the QoS for the customer services in the event of a
particular delay, jitter, and packet loss characteristics in the transport network. Based on the strategy for providing
services with a certain QoS to the end-users, the mobile operator should consider what QoS (delay, jitter, packet loss
and availability) should be demanded from the transport network. When considering these requirements, naturally
also commercial and technical feasibility should be taken into account.
7. Appendix
Related resources
More on this topic
IEEE1588v2 Timing over Packet (ToP)
3GPP QoS requirements
Message flows
7.1. IEEE1588v2 Timing over Packet (ToP)

The following network engineering rules should be obeyed:
maximum one way delay should be < 100ms
jitter < +/- 5 ms
packet loss < 2%
clock packet stream should have the highest priority or at least the same priority as the real-time traffic
sync packets receive expedited forwarding QoS
high-priority traffic share of bandwidth should be ~ 60% or less
a maximum of 20 hops with packet switch for links greater than or equal to 1 Gb/s
if MWR or connection greater than or equal to1Gb/s is used, the number of total hops must be smaller: 10
maximum 6 delay jumps per day
load balancing should not be used together with ToP
Following these recommendations does not guarantee operation within the specifications, because in some networks
there may be exceptionally high load levels or many links with low bandwidth. Therefore, the tolerance specifications
of ToP clocks to packet delay variation are based on MAFE (Maximum Average Frequency Error) masks. The MAFE
curve of a network connection is calculated from the packet delays across the connection. The curve should remain
below the mask. The Flexi WCDMA base station mask and a MAFE curve are shown below.
MAFE is a new metric proposed by Nokia, to assess link quality for the packet synchronization solution. More
information can be found in documents: “Nokia Synchronization Solution for MBH on Packet Networks: Timing over
Packet” and “ToP monitoring guideline”.
Figure: Flexi WCDMA ToP clock MAFE mask and a MAFE curve of a highly stressed connection. Tau is the averaging window size used in the MAFE
calculation.
Related resources
Parent topic: Appendix
7.2. 3GPP QoS requirements

The UMTS Bearer Service Attributes are defined in 23.107 document.
The following table lists the value ranges of the UMTS bearer service attributes. The value ranges reflect the
capability of the UMTS network.
Table: 3GPP QoS requirements
Traffic class Conversational class Streaming class Interactive class Background class
Maximum bitrate (kbps) <=256 000 (2) <=256 000 (2) <=256 000 (2) <=256 000 (2)
Delivery order Yes/No Yes/No Yes/No Yes/No
Maximum SDU size <= 1 500 or 502 (4) <= 1 500 or 502 (4) <= 1 500 or 502 (4) <= 1 500 or 502 (4)
(octets)
SDU format information (5) (5)

Traffic class Conversational class Streaming class Interactive class Background class
Delivery of erroneous Yes/No/- (6) Yes/No/- (6) Yes/No/- (6) Yes/No/- (6)
SDUs
Residual BER 5*10-2, 10-2, 5*10-3, 10-3, 5*10-2, 10-2, 5*10-3, 10-3, 4*10-3, 10-5, 6*10-8 (7) 4*10-3, 10-5, 6*10-8 (7)
10-4, 10-5, 10-6 10-4, 10-5, 10-6
SDU error ratio 10-2, 7*10-3, 10-3, 10-4, 10- 10-1, 10-2, 7*10-3, 10-3, 10- 10-3, 10-4, 10-6 10-3, 10-4, 10-6
5 4 -5
, 10
Transfer delay (ms) 100 – maximum value 300 (8) – maximum value
Guaranteed bit rate <= 256 000 (2) <= 256 000 (2)
(kbps)
Traffic handling priority 1,2,3 (9)
Allocation/Retention 1,2,3 1,2,3 1,2,3 1,2,3

priority
Source statistic Speech/unknown Speech/unknown

descriptor
Signaling Indication Yes/No (9)
Related resources
7.3. Message flows

Related resources
More on this topic

Uu Iub Iu
RRC:Connection-Request -->
<-- NBAP: Radiolink-Setup
NBAP: Radiolink-Setup-Response -->
<-- RRC:rrcConnectionSetupNBAP:Radiolink-
Synchronization -->
RRC:rrcConnectionSetupComplete -->
GPRS:Service Request -->
�GPRS:Service Request -->
<-- RRC:measurementControl
<-- RANAP:CommonID<-- RRC:imsi<--

RANAP:SecurityModeCommand
<-- RRC:securityModeCommand
RRC:securityModeComplete -->
RANAP:SecurityModeComplete -->
<-- RANAP:DirectTransfer<-- GPRS:P-

TMSI reallocation command
<-- GPRS:P-TMSI reallocation command
GPRS:Activate PDP context request -->
GPRS:Activate PDP context request -->
RANAP:DirectTransfer -->
GPRS:P-TMSI reallocation complete -->
GPRS:P-TMSI reallocation complete -->
<-- RANAP:RAB-AssignmentRequest
<-- RRC:radioBearerSetup
<-- RRC:measurementControl
RRC:radioBearerSetupComplete -->
RANAP:RAB-AssignmentResponse -->
<-- RANAP:DirectTransfer
<-- GPRS:Activate PDP context accept
<-- GPRS:Activate PDP context accept
RRC:RrcConnectionRequest -->
<-- NBAP:RadioLinkSetupRequestFDD
NBAP:RadioLinkSetupResponseFDD -->
Uu Iub Iu
<-- RRC:RrcConnectionSetup
RRC:RrcConnectionSetupComplete -->
RRC:InitialDirectTransfer -->
GPRS MM:SERVICE REQUEST --

>RANAP:InitialUE-Message -->
<-- RRC:MeasurementControl
<-- RANAP:CommonID
RLC:SRB2 RRC SDU ACK -->
NBAP:RadioLinkRestoreIndication -->
<-- RANAP:SecurityModeCommand
<-- RRC:SecurityModeCommand
RRC:SecurityModeComplete -->
RANAP:SecurityModeComplete -->
RRC:UplinkDirectTransfer -->
GPRS SM:ACTIVATE PDP CONTEXT

REQUEST -->
<-- RANAP:RAB-AssignmentRequest
<-- NBAP:RadioLinkReconfigurationPrepareFDD
NBAP:RadioLinkReconfigurationReady -->
<-- RRC:RadioBearerSetup
<-- NBAP:RadioLinkReconfigurationCommit
RRC:RadioBearerSetupComplete -->
Related resources
Parent topic: Message flows

Impact of Transport Network Impairments On WCDMA Network Performance

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Impact of Transport Network Impairments On WCDMA Network Performance

Загружено:

Авторское право:

Доступные форматы

Impact of Transport Network Impairments on

WCDMA Network Performance

Copyright Â© Nokia Solutions and Networks 2012. All rights reserved.

Issue 01 (2010-12-01, WCDMA RAN RU20)

2. Introduction of Impact of Transport Network Impairments on

Note: NOTE: The measurements are done with RU20 release.

Note: The measurement methods are done in RU20 release.

3.1.1. General assumptions

3.1.2. Test network architecture

3.1.3. Test setup

Table: Measurement settings for both interface

Interface delay (ms) jitter (ms) PLR (%)

Iub 10 2,5 0,1

Packet Storm settings with exponential distribution

Figure: Exponential delay distribution

4. Iub performance values

4.1. Procedure KPIs

4.1.1. Mobile to Mobile AMR Call Setup Time

Table: Rationale for Call Setup Time

Message Exchange Delay (ms)

RRC messages= 2 * 8 160

NBAP messages= 2 * 6 120

Packet Loss impact 2

4.1.2. PDP Context Activation Accept

Table: Rationale for PDP Context Accept

RRC messages= 100

Table: HSPA Call Setup Time with F-DPCH

Message exchange Delay (ms)

Packet Loss impact 1

Figure: 1400 byte ping vs. IP Iub delay on R99

4.1.5. Round Trip Time (RTT) on HSPA

Figure: 32 byte ping vs. IP Iub delay on HSPA

Table: Configurations checked

HSDPA 4 Mb/s HSUPA 2Mb/s HSUPA 5.8 Mb/s R99

DL (kb/s) 4096 4096 4096 384

UL (kb/s) 2048 2048 6400 64

file size 2.49 GB 500 MB 500 MB 2.49 GB

used UE Nokia 6260 Classic Non-commercial Nokia 6260

4.2.1. HSDPA results

Figure: HSDPA FTP Data throughput vs. IP Iub delay

Figure: HSDPA FTP Data throughput vs. IP Iub jitter

Figure: HSDPA FTP Data throughput vs. IP Iub PLR

4.2.2. HSUPA results

Figure: HSUPA 2 Mb/s FTP Data throughput vs. IP Iub delay

HSUPA 5.8 Mb/s vs. jitter

4.2.3. R99 results

Figure: R99 FTP data throughput vs. IP Iub delay

4.3. Line break tests

4.3.1. RAN behavior

5.1. Procedure KPIs

5.1.1. Mobile to Mobile AMR Call Setup Time

Table: Rationale for Call Setup Time

Message exchange Delay (ms)

RANAP messages= 2*8 160

Packet Loss impact 5

5.1.2. PDP Context Activation Accept

Table: Rationale for PDP Context Accept

Message exchange Delay (ms)

Packet Loss impact 1

5.1.3. HSPA Call Setup Time with F-DPCH

Table: HSPA Call Setup Time with F-DPCH

Message exchange Delay (ms)

Packet Loss impact 1