08 Ra47078en70naa0 Volte Analysis
Short Description
volte...
Description
Nokia Academy VoL oLTE TE Analysi Analysis s Summar Summary y
Copyright and confidentiality
The contents of this document are proprietary and confidential property of Nokia Solutions and Networks. This document is provided subject to confidentiality obligations of the applicable agreement(s). This document is intended for use of Nokia Solutions and Networks customers and collaborators only for the purpose for which this document is submitted by Nokia Solutions and Networks. No part of this document may be reproduced or made available to the public or to any third party in any form or means without the prior written permission of Nokia Solutions and Networks. This document is to be used by properly trained professional personnel. Any use of the contents in this document is limited strictly to the use(s) specifically created in the applicable agreement(s) under which the document is submitted. The user of this document may voluntarily provide suggestions, comments or other feedback to Nokia Solutions and Networks in respect of the contents of this document ("Feedback"). Such Feedback may be used in Nokia Solutions and Networks products and related specifications or other documentation. Accordingly, if the user of this document gives Nokia Solutions and Networks feedback on the contents of this document, Nokia
Solutions and Networks may freely use, disclose, reproduce, license, distribute and otherwise commercialize the feedback in any Nokia Solutions and Networks product, technology, service, specification or other documentation. Nokia Solutions and Networks operates a policy of ongoing development. Nokia Solutions and Networks reserves the right to make changes and improvements to any of the products and/or services described in this document or withdraw this document at any time without prior notice. The contents of this document are provided "as is". Except as required by applicable law, no warranties of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose, are made in relation to the accuracy, reliability or contents of this document. NOKIA SOLUTIONS AND NETWORKS SHALL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT DOCUMENT or for any loss of data or income or any special, incidental, consequential, indirect or direct damages howsoever caused, that might arise from the use of this document or any contents of this document.
This document and the product(s) it describes are protected by copyright according to the applicable laws. Nokia is a registered trademark of Nokia Corporation. Other product and company names mentioned herein may be trademarks or trade names of their respective owners. © Nokia Solutions and Networks 2015
Objectives
• After completing this module, you will be able to: • Discuss VoL oLTE TE implementation implementation example
Contents
• VoLTE Field Testing System Configuration • VoLTE Performance KPIs • VoL oLTE TE Field F ield Test Test Cases Ca ses & Results - TTI Bundling - SIP Sig ign nalin ing g
VoLTE XX Network (Cluster) Configuration • Network Vendors: -
NSN eNBs with RL50 release. EPC is supplied by LG-Ericsson (MME) & Samsung (SPGW) IMS is supplied by local company.
• Network design is based on distributed cells with large number of R RHs and repeaters. -
10 MHz bandwidth 850 MHz & 2100 MHz (2nd carrier)
• Network Settings: -
Robust Header Compression (RoHC) is disabled. QCI5 bearer ‘Scheduling type’ is set to NON-GBR instead of IMS SIGNALING. TTI Bundling is not activated. DRX in RRC connected mode is not activated. Proactive uplink scheduling is disabled.
Scope of VoLTE Field Test • The following data was collected from radio access network during field testing: -
UE traces Emil traces with RLF triggered snapshots SIP signaling MOS voice quality OSS statistics
• The scope of work was to conduct a deep analysis of VoLTE performance in terms of: -
Voice quality QCI 1 scheduling TTI bundling SIP signaling
VoLTE Field Test Cluster
• The VoLTE field testing was conducted at cluster XX -
Residential area with high rise apartment buildings.
• The cluster drive testing was mainly performed during night time -
Unloaded traffic scenario.
-
1 test also during busy hour (loaded scenario)
-
Test dates: 29th Nov - 13th Dec 2013
VoLTE Drive Test Tool Setup •
The short VoLTE (mobile-tomobile) calls were generated by DT call script to collect statistics from call setup performance during the drive testing.
•
The long VoLTE (mobile-tomobile) call was setup to collect MOS (POLQA) call quality values and statistics from handover and dropped call performance during the drive testing.
Contents
• VoLTE Field Testing System Configuration • VoLTE Performance KPIs • VoLTE Field Test Cases & Results - TTI Bundling - SIP Signaling
VoLTE Drive Test KPIs
# KPI Item RRC Setup Success Rate
Unit
Result
Remarks
%
100%
Short Call
2 Call Setup Time
s
MO – 4.84 * MT - 1.94s
Short Call
3 Drop Call Rate
%
0%
Long Call
Handover Success Rate
%
100%
Long Call
Handover InterruptionTime
s
0.0755 (MO – Tx) 0.1245 (MT – Rx)
Long Call
%
9.23
Long Call
#
3.33
Long Call
0.175
Long Call
1
4
5 BLER (DL) 6
MOS MOS Jitter Delay
s
* XCAP defines the call setup time from “Call Start” - “Call Connected” internal events
VoLTE Network KPIs – RRC Connection Performance RRC KPIs measure accessibility and retainability of signaling (SRB) connection between UE and eNB. VoLTE service cannot be differentiated from other traffic, i.e. no specific RRC establishment cause for voice in LTE as per 3GPP. Note that the all statistics are from the cluster only (not entire network). eNB issues in the cluster
VoLTE Network KPIs – Ratio of non-GBR and QCI1 ERAB Setup •
Non-GBR bearer attempts are almost double compared to RRC connnections due to fact that QCI5 bearer (non-GBR) for IMS signaling is always setup along with default radio bearer.
•
Note that when E-RAB setup procedure is executed for more than one E-RABs the setup counter is pegged each time.
VoLTE Network KPIs – E-RAB Performance for QCI1 Bearer •
E-RAB accessibility KPI measure the of E-RAB bearer connection between UE and MME, i.e. not the entire endto-end EPS bearer service (from UE to P-GW).
•
Note that Voice QCI1 bearer attempts are only 1-2% of the total traffic during busy hours.
•
Voice bearer has typically worse retainability due to longer call sessions compared with non-GBR data traffic.
VoLTE Network KPIs – E-RAB in-Session Activity Time •
This measurement provides the aggregated in-session activity time per E-RABs with QCI1 and non-GBR characteristics, i.e. when user data are transferred the insession activity time is aggregated during the E-RAB lifetime.
•
Note that voice bearer has more than 150 times longer session time compared to non-GBR data traffic.
VoLTE Network KPIs – Intra-eNB Handover Performance •
Intra-eNB handover KPI measure the success of preparation (resource reservation) and execution (handover to target cell) phases over the intra-LTE handover procedure.
•
Voice bearer is also more sensitive to HO failures than non-GBR bearer due to longer time in connected mode.
•
No separate counters available for voice handovers.
VoLTE Network KPIs – Inter-eNB Handover Performance •
Inter-eNB handover KPI measure the success of preparation (resource reservation) and execution (handover to target cell) phases over intra-LTE X2 based handover procedure.
•
No separate counters available for voice handovers.
Contents
• VoLTE Field Testing System Configuration • VoLTE Performance KPIs • VoLTE Field Test Cases & Results - TTI Bundling - SIP Signaling
VoLTE Quality Metrics
• The correlation between voice quality MOS (POLQA P863) and various network quality measures were investigated. • The biggest contributor was found to be the peak delay, e.g. potential contributors to delay can be the following factors: -
Uplink HARQ retransmissions for transmitting UE
-
Downlink HARQ retransmissions for receiving UE
-
Scheduling delays of QCI1 bearer
-
Processing the RTP packets in transmitting UE
-
Processing the RTP packets in receiving UE
-
Other delays in transport or EPC
Field Test Scenarios & Measurement Methodology • Field Test Scenarios: -
Baseline (unloaded)
-
Busy Hour (loaded)
-
Delay Target Optimization
• VoLTE capable UEs: Samsung S4 and LGU G2 • VoLTE calls were made by a single computer running XCAL software • MOS POLQA P863, 6 sec voice sample, AMR-WB 23 kbps
’talker’
’listener’
UL BLER vs. MOS Quality MOS vs. UL BLER
• QCI1 retransmissions in uplink direction of the transmitting UE cause additional delay and variations to RTP packet delivery. -
Maximum number of UL retransmissions = 7 (harqMaxTrUl)
-
Each retransmission adds 8ms and theoretically up to 7 x 8ms = 56ms in the worst case
• PUSCH HARQ BLER seems to have a very little impact to MOS. After BLER > 11% some degradation visible, but number of samples is low.
PUSCH BLER %
Average of MOS vs. UL BLER
• Delay variations due to UL HARQ in most cases is < 24ms.
PUSCH BLER %
DL BLER vs. MOS Quality
MOS vs. DL BLER
• Also QCI1 retransmissions in downlink direction of the receiving UE can cause additional delay to RTP packet delivery. -
Maximum number of DL retransmissions = 7 (harqMaxTrDl)
-
Each retransmission adds 8ms and theoretically up to 7 x 8ms = 56ms in the worst case
• PDSCH HARQ BLER also seems to have a little correlation with MOS. • Delay variations due to DL HARQ in most cases is < 24ms.
Average MOS per BLER (Red) Moving average, window size 5 (Green)
RTP Delay vs. MOS Quality • Measurement: -
Several hours drive testing in varying loading conditions
-
Delay target 80ms (delayTarget) with 98% (dlsOldtcTarget) probability
-
Maximum number of aggregated VoIP packets in uplink = 2 (ulsMaxPacketAgg)
• RTP Delay causes quick MOS degradation from 60ms peak delay point onwards.
• Possible causes for delay: -
HARQ retransmissions
-
Too low scheduling priority for QCI1 during high load
-
Scheduling frequency of RTP packets on radio interface
-
UE TX and or RX processing of RTP packets
Average MOS per peak delay (Red) Moving average, window size 10 (Green)
RTP Packet Delay Variations • In this example, the delay target is set to 80ms with probability of 98%. -
There are ~41400 samples during a 23 minutes measurement.
-
98% delay probability of packets exceeding a set delay target would allow the delay of 80ms to be exceeded up to 828 times during the 23 minutes, i.e. delay target is not exceeded very often.
-
Standard deviation of the delay RTP delay (BLUE) is switching between about 5ms and 20ms.
RTP Packet Delay Variations
• Switching between ~20ms and ~5ms standard deviation of RTP delay is a result of UE or eNB aggregating RTP packets in uplink transmission: -
In case of 40ms scheduling, there are two RTP packets aggregated and transmitted within 1 TTI instead of 2 TTIs.
40ms scheduling 20ms scheduling
Packet Aggregation and RTP Delay
Packet aggregation causes the first packet to be always 20ms late while the s econd one is delivered at the correct time. That causes constant jitter of 20ms.
1
1 20ms
1 20ms
2 1
1 20ms
20ms
1
1 20ms
2
Packet 2 on time
1
Packet 1 20ms late 20ms
20ms
1 20ms
2
Packet 2 on time
1
Packet 1 20ms late
MOS Delay Target Optimization G2 - Before
• The delay target (delayTarget) and target probability (dlsOldtcTarget) were changed from 80ms and 98% to 50ms and 99%, respectively.
Average = 3.40
MOSP863(POLQA) 4 3.8 3.6 3.4 3.2 3
• The delay profile did not seem very different, however the impact to MOS was noticeable.
2.8 2.6 2.4 2.2 2 5 7 0 0 1 3 6 7 7 8 9 1 4 4 5 7 8 0 1 1 3 3 6 6 5 6 0 9 2 5 6 9 7 0 8 1 2 4 5 9 8 8 0 4 4 6 7 0 2 7 9 9 4 5 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 9 5 1 7 3 9 5 2 8 4 0 6 2 8 4 1 7 3 9 5 1 7 4 0 6 2 9 4 0 6 2 9 4 1 7 3 9 5 1 8 5 0 6 2 8 5 1 7 3 0 6 2 9 0 1 1 2 3 3 4 4 5 0 0 1 2 2 3 3 4 5 5 0 0 1 2 2 3 4 4 5 5 0 1 1 2 2 3 4 4 5 5 0 1 1 2 3 3 4 4 5 0 0 1 2 2 3 3 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 0 1 3 4 5 6 7 8 9 0 1 3 4 5 6 7 8 9 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1
• Average MOS improved from 3.4 to 3.45 (distribution is shown on next page).
G2 -After
Average = 3.45
MOSP863(POLQA) 4 3.8 3.6 3.4 3.2 3 2.8 2.6 2.4 2.2 2 7 0 0 1 1 5 5 5 6 9 0 0 3 4 7 7 2 4 9 1 4 7 9 2 4 7 9 4 7 9 2 5 6 8 0 0 6 9 1 4 7 1 3 4 6 1 2 4 9 8 1 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0 7 3 9 5 1 7 3 9 5 2 8 4 0 6 3 9 5 1 8 4 0 6 3 9 5 1 8 4 0 7 3 9 5 2 9 4 0 7 3 9 6 2 8 4 1 7 3 9 6 2 8 5 5 0 0 1 2 2 3 3 4 5 5 0 1 1 2 2 3 4 4 5 0 0 1 1 2 3 3 4 5 5 0 0 1 2 2 3 4 4 5 5 0 1 1 2 3 3 4 4 5 0 0 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6 7 9 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 0 2 3 2 2 2 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 2 2 2
MOS Delay Target Optimization
• The delay target (delayTarget) and target probability (dlsOldtcTarget) were changed from 80ms and 98% to 50ms and 99%, respectively. • Distribution of MOS 3.5 or higher: - Before = 31% - After = 50% • Average MOS improved from 3.4 to 3.45
MOS - G2 P DF (Be fo re )
P DF (Aft er)
CDF (Be for e)
CD F (Afte r)
160
100.0%
140
90.0% 80.0%
120
70.0%
100
60.0%
80
50.0%
60
40.0% 30.0%
40
20.0%
20
10.0%
0
0.0% =3.8
RTP Packet Loss and Network Loading
• During the daytime when the loading is higher, the RTP packet loss is much higher. Further investigation is recommended. • Also there seems to be more MOS variations during the hours of higher loading, but average MOS is not much impacted.
RTP Packet Loss and Network Loading
• MOS distribution shows only minor difference between the tests even though the packet loss more frequent during daytime with higher loading. • Packet drops seem to have a minor impact on MOS. • Average MOS:
- Night time 3.404 - Day time 3.381
Contents
• VoLTE Field Testing System Configuration • VoLTE Performance KPIs • VoLTE Field Test Cases & Results - TTI Bundling - SIP Signaling
TTI Bundling • TTI bundling is specified in 3GPP (TS 36.213, 36.321) to allow the improved uplink performance for cell border UEs (which often hit the maximum transmission power) and for reduced PDCCH load.
• TTI bundling allows for transmitting the same transport block in 4 consecutive UL subframes (also known as bundle size), which leads to increased energy per transmi tted bit and therefore improved uplink link budget.
-
-
When BLER increases and Link Adaptation has no more options for MCS/PRB reduction while radio conditions for handover are not fulfilled, TTI Bundling can be triggered to sustain the voice call quality before UE will either change the cell or RF conditions becomes better.
TTIB activation
Note that TTI Bundling mode is also maintained during the handover (if target cell supports TTI Bundling).
HO conditions fulfilled
Transmission Characteristic in TTI Bundling • A single transport block is encoded and transmitted with different redundancy versions in four (4) consecutive UL subframes, i.e. within a bundle.
• A single UL grant on PDCCH is used for each bundle. • HARQ feedback is only received (and transmitted) for the last subframe of a bundle. HARQ process ID is same for each of the bundled subframes. • HARQ retransmission of a TTI bundle, which is also transmitted as a bundle, occurs 16 TTIs after previous (re)transmission in order to be synchronized with normal (nonbundled) LTE HARQ retransmissions (8 TTIs)
TTI # 1
2
4
4
5
6
7
8
9
1 0
1 1
1 2
1 3
1 4
1 5
1 6
1 7
1 8
1 9
2 0
2 1
2 2
2 3
2 4
UL Grant on PDCCH Retransmission of 1st bundle
1st bundle
Tx on PUSCH
ACK/NACK on PHICH
0
0
0
0
1
1
1
1
2
N HARQ RTT = 16 TTIs
2
2
2
A
3
3
3
3
A
0
0
0
0
A
TTI Bundling UL Coverage Gain • TTI Bundling feature improves UL Link Budget because it is possible to increase the number of retransmissions within a specific delay budget (i.e. time during which Transport Block retransmissions can occur before it will be dropped)
transmission 8ms RTT
TTI Bundling 16ms RTT
-
Maximum number of TB transmissions (within 50 ms delay budget) in normal mode is equal to 7 while in TTI Bundling mode is equal to 12 which leads to 2.34 dB (=10xlog(7/12)) gain in uplink pathloss.
-
Increasing delay budget up to 53ms, higher gains can be achieved, i.e. up to 3.59 dB (=10xlog(7/16)), as one more bundle that consist of 4 Transport Blocks can be transmitted.
Trigger Criterion to Enter TTI Bundling Mode
• The trigger condition to start TTI bundling of a UE shall be fulfilled if: -
UE is transmitting with currentMCS
View more...
Comments
