You are on page 1of 104

VoLTE Radio Training

Part III
End to End VoLTE Analysis and Optimization workshop
20-24 November 2016 in Riyadh, KSA.

1 © Nokia Solutions and Networks 2014


<Change information classification in footer>
Contents

• VoLTE Parameter Assessment – RADAR


• RADAR introduction
• VoLTE Performance Analysis
• VoLTE KPIs
• High traffic event
• VoLTE Radio Optimization
• Periodical CQI reporting
• QCI1 specific T310 and T311 timers
• DRX – optimized algorithm
• PDCP discard timer and SN size
• High speed users
2 © Nokia Solutions and Networks 2014
VoLTE Parameter
Assessment
High Level training + Part of old agenda ( US
workshop)
• RADAR

RADAR Wiki: https://workspaces-emea.int.nokia.com/sites/nporadio/Radio%20Wiki/RADAR.aspx

3 © Nokia Solutions and Networks 2014


Radio Assessment Reporting Tool (RADAR)

Description: Automated Radio Assessment Report Creation (Parameter & Configuration)


Automation: One click analysis & report creation including charts, tables & standard text
Supported technologies: GSM, UMTS, LTE
Main use case(s): Interfaces (tool chain):
- NPO Radio Assessment Service report Input:
creation (Parameter & Configuration) by - Netact XML raml2 export file, Excel template with
GSD and CO parameter rules, PPT report template, site list with
- Standardized Assessment Reporting coordinates
- Comparison of parameter values Output:
(actuals) vs. target values & ranges - Complete Power Point report according to given
- Parameter consistency checks template, imported rules set & chapter definition
- Parameter Distribution creation - Comprehensive Excel Spreadsheet showing
- Parameter Chart creation Parameter inconsistencies distributions , graphs &
- Neighbour checks tables
- Activated Feature list creation - HW & SW Configuration Summary
- Parameter delta comparison of 2 xml files - Netact correction XML file
4 © Nokia Solutions and Networks 2014 - Google Earth visualization of sites and issues
Radio Assessment Reporting Tool (RADAR)

Excel Import File & PPT Easy to handle GUI Various Output Reports
template

5 © Nokia Solutions and Networks 2014


VoLTE Parameter Assessment
VoLTE Module in RADAR

• RADAR can be used for VoLTE Parameter Assessment


• Compare the VoLTE current network parameter list against:
• Default parameter set
• NPO Global parameter set
• Customer default parameter set
• Identify the parameter deviations
• Identify the missing parameter values, deviations etc,
• Experts view in parameter assessment

6 © Nokia Solutions and Networks 2014


Nokia Internal Use
VoLTE Module in RADAR
How the module has been done

• Created VoLTE sub-topics to cover all the VoLTE related parameters/ features
• Map all the VoLTE related parameters under the sub-topics
- One parameter may be under more than one subtopic
• Each subtopic populates one output slide (report), that contains
- Scope
- Observation
- Recommendation + Expert view
• If needed user can edit the input file

7 © Nokia Solutions and Networks 2014


Nokia Internal Use
VoLTE Module in RADAR
VoLTE Sub-Topics
• V_Act : VoLTE Activation • RoHC: Robust Header Compression
• AC : Admission Control • UpPaSeg: Uplink Packet Segmentation
• Sche : Scheduler Related • TTI_B: TTI Bundling
• QCI1_Tcheck: QCI 1 Table Check • Packet_Agg: Packet aggregation
• QCI5_Tcheck: QCI5 Table Check • Eme_CH: Emergency Call Handling
• PCDP_P1_C: PDCP Profile 1 Check • SRVCC_3G: SRVCC to 3G network
• PCDP_P101_C:PDCP Profile101 check • SRVCC_2G: SRVCC to 2G network
• RLC_P1_C: RLC Profile 1 Check
• RLC_P101_C: RLC Profile 101 Check
• DRX_P2_C: DRX Profile 2 Check
• DRX_P3_C: DRX Profile 3 Check

8 © Nokia Solutions and Networks 2014


Nokia Internal Use
Mapping between parameters and Sub-topics

9 © Nokia Solutions and Networks 2014


Nokia Internal Use
Scope , Observation and Recommendation
Experts view

10 © Nokia Solutions and Networks 2014


Output slide

11 © Nokia Solutions and Networks 2014


Analysis using excel
Identification of problematic parameters

12 © Nokia Solutions and Networks 2014


Find missing parameters

13 © Nokia Solutions and Networks 2014


VoLTE Performance Analysis

14 © Nokia Solutions and Networks 2014


VoLTE KPIs

15 © Nokia Solutions and Networks 2014


VoLTE KPI Definitions and Target Values

KPI definitions
• Report Set RSLTE052 (accessible from JUMP) in Report Manager collects OSS KPIs and counters
to monitor the traffic load and VoLTE Service Quality.
• Performance monitoring for VoLTE by NetEng. Based on references from JUMP and RAN LTE KPIs
document is a collection of LTE KPIs and counters used when monitoring the VoLTE service.
KPI values
• The MBB and NPO KPI commitment targets guideline . Its contents are aligned with the more
detailed document KPI Targets document below. Note: Always download the latest one from the link
above.
• MBB Performance Benchmarker
VoLTE KPI List for Acceptance
• A list covering all domains (not only radio) with OSS and drive test KPIs to be used as part of
customer discussions: VoLTE KPI List for Acceptance

16 © Nokia Solutions and Networks 2014


OSS KPI Reference from VoLTE Networks
MBB Benchmarker (August 2016)

KPI Max %ile 75 Median %ile 25 Min Mean Customers


LTE: eRAB Drop Ratio - QCI1 (LTE_5572) (%) 100.00 0.97 0.20 0.03 0.00 1.23 85
LTE: eRAB Setup Success Ratio - QCI1 (LTE_5204) (%) 100.00 99.88 99.82 99.75 0.00 98.27 77
LTE: eRAB Normal Release Ratio - QCI1 (LTE_5209) (%) 100.00 99.84 99.45 98.30 0.00 96.94 85
LTE: Inter-RAT HO UTRAN SRVCC Success Ratio (LTE_5564) (%) 100.00 98.15 95.49 93.25 0.00 93.05 43
LTE: Inter-RAT HO GERAN SRVCC Success Ratio (LTE_5567) (%) 100.00 95.68 94.08 91.33 50.00 92.94 40
LTE: eRAB Active Time - QCI1 (LTE_5576) (Min) 54767811 300927 809 0 0 2575883 116
LTE: Avg PDCP Active Cell Throughput DL per Cell, QCI1 (LTE_5293) (kbit/s) 87 6 0 0 0 7 116
LTE: Avg PDCP Active Cell Throughput UL per Cell, QCI1 (LTE_5294) (kbit/s) 80 4 0 0 0 6 116
LTE: eRAB Retainability Rate - QCI1 (LTE_5582) (/min) 45 0 0 0 0 0 85
LTE: eRAB Setup Attempts, QCI1 (LTE_5205) 9492277 200776 424 0 0 485345 108
LTE: Inter-RAT HO UTRAN SRVCC Attempts (LTE_5562) 468459 14 0 0 0 12715 116
LTE: Inter-RAT HO GERAN SRVCC Attempts (LTE_5565) 114244 2548 0 0 0 4351 116
LTE: VoLTE Traffic Load (LTE_1067) (erl /day) 316269 1962 4 0 0 14007 114
LTE: Average VoLTE Call Duration (LTE_1153) (s) 84397.9 121.8 102.1 66.9 0.0 189.9 83

17 © Nokia Solutions and Networks 2014


VoLTE Call Setup Success
GBR vs. non-GBR eRAB Setup Success
GBR and non-GBR E-RAB Setup Success (%) • QCI1 E-RAB setup success
E-RAB Setup Attempts, QCI1 E-RAB Setup Success Rate E-RAB Setup Success Rate, QCI1 Linear (E-RAB Setup Attempts, QCI1) rate is slightly worse than non-
GBR E-RAB setup success
100.00 400 000

720 users - 15 MHz


99.90
350 000 rate due to following factors:
Admission Control Threshold – 75%
99.80 600 users - 10 MHz - Much less QCI1 setups
99.70
300 000
compared to all QCIs and thus,
the weight of setups attempted

QCI1 Attempts (#)


250 000
under poor radio conditions is
Success Rate (%)

99.60

a se increased
99.50
ffic incre 200 000
E tra
ld VoLT - If a handover becomes
99.40 3x fo 150 000 necessary during E-RAB Setup,
99.30 the eNB may interrupt the
100 000
ongoing E-RAB Setup procedure
99.20
as specified in 36.413 (chapter
8.2)
50 000
99.10

99.00 0
08.25.2014
08.27.2014
08.29.2014
08.31.2014

09.04.2014

09.08.2014
09.10.2014
09.12.2014
09.14.2014
09.16.2014

09.22.2014

09.26.2014
09.28.2014
09.30.2014
10.02.2014
10.04.2014
10.06.2014

10.10.2014

10.14.2014
10.16.2014
10.18.2014
10.20.2014
10.22.2014
09.02.2014

09.06.2014

09.18.2014
09.20.2014

09.24.2014

10.08.2014

10.12.2014

18 © Nokia Solutions and Networks 2014


VoLTE Call Setup Failure due to Handover in Progress
MME Bearer Request Handling

• 3GPP 36.413 (chapter 8.2): If a handover becomes necessary during E-RAB Setup, the
eNB may interrupt the ongoing E-RAB Setup procedure and initiate the Handover
Preparation procedure as follows:
- The eNB shall send the E-RAB SETUP RESPONSE message in which the eNB shall indicate, if
necessary all the E-RABs fail with an appropriate cause value, e.g., ”S1 intra system Handover
triggered”, “S1 inter system Handover triggered” or “X2 Handover triggered”.
• Therefore, MME needs to resend the E-RAB Setup Request when it receives the Path
Switch Request after the failed E-RAB setup (same for E-RAB release or modify i.e.
any E-RAB procedure) – feature implemented in NS15.
- In case the SGW is changed due the HO then MME should send the Create Bearer Response
message to SGW indicating rejected E-RAB with cause 110 “Temporarily rejected due to
handover/TAU/RAU procedure in progress“.

19 © Nokia Solutions and Networks 2014


VoLTE Call Setup Failure due to Handover in Progress
PGW Bearer Request Handling

• 3GPP TS 23.401: Upon reception of a rejection for an EPS bearer(s) PDN GW initiated
procedure with an indication that the request has been temporarily rejected due to
mobility procedure in progress, the PDN GW start a locally configured guard timer. The
PDN GW shall re-attempt, up to a pre-configured number of times, when either it
detects that the Tracking Area Update procedure is completed or has failed using
message reception or at expiry of the guard timer.
- PDN GW which initiated the bearer related request (e.g. Create / Update / Delete Bearer
request) is supposed to handle the rejection by re-sending the request after handover is
completed.
- Since NG3.2, SGW has re-attempt mechanism, with the default value “handover-rejection-guard-
timer-reattempt-count” = 2, i.e. when SGW receives the rejection, it will re-initiate rejected EPS
bearer procedure to MME.

20 © Nokia Solutions and Networks 2014


VoLTE Call Setup Failure due to Handover in Progress
Failure Message Sequence
S-eNB T-eNB MME S-SGW T-SGW PGW

SIP:INVITE

SIP: TRYING

SIP: SESSION PROGRESS

Radio Handover in Progress


Create Bearer Request Create Bearer Request (QCI1)

E-RAB Setup Request

E-RAB Setup Response (failure) Cause: X2-Handover-Triggered

Patch Switch Request


Create Bearer Response Cause: Temporarily Rejected due to Handover Procedure in
(failure) Progress
SIP: 503 Service Unavailable

21 © Nokia Solutions and Networks 2014


VoLTE Call Setup Failure due to Handover in Progress
Correct Message Sequence
S-eNB T-eNB MME S-SGW T-SGW PGW

SIP:INVITE

SIP: TRYING

SIP: SESSION PROGRESS

Radio Handover in Progress


Create Bearer Request Create Bearer Request (QCI1)

E-RAB Setup Request

E-RAB Setup Response (failure) Cause: X2-Handover-Triggered

Patch Switch Request

Retransmission
Create Bearer Response Cause: Temporarily Rejected due to Handover Procedure in
(failure) Progress
Create Session Request (QCI5)
Modify Bearer Request

Modify Bearer Response


Create Session Response
Patch Switch Request Ack

Delete Access Bearer in S-eNB and Session in S-SGW


Create Bearer Request Create Bearer Request (QCI1)
SIP: PRACK

22 © Nokia Solutions and Networks 2014


VoLTE Drop Call Rate
GBR vs. non-GBR Drop Call Rate
GBR and non-GBR E-RAB Drop Rate (%) • QCI1 E-RAB drop rate is much
VoLTE Drops EPC initiated VoLTE Drops eNB initiated E-RAB Drop Rate, User Perspective (eNB pre-emptions excluded) VoLTE Drop Rate
worse compared to non-GBR
2.00 6 000
traffic.
1.80 720 users - 15 MHz
5 000
• VoLTE (QCI1) bearer drop rate
Admission Control Threshold – 75% 600 users - 10 MHz
1.60
has an increasing trend up to
1.40
4 000
1.6% with increased voice
traffic.

QCI1 Drops (#)


1.20
Drop Rate (%)

e - The QCI1 session time (activity


reas
c inc
1.00 3 000

TE traffi time) is much longer compared


oL
0.80 3xV to the non-GBRQCI and
0.60
2 000 therefore, QCI1 is much more
sensitive to mobility related
0.40
1 000
performance challenges (too late
0.20
HO, too early HO, RRC re-
establishments)
0.00 0
08.27.2014

09.06.2014

09.16.2014

09.26.2014

10.18.2014
08.25.2014

08.29.2014
08.31.2014
09.02.2014
09.04.2014

09.08.2014
09.10.2014
09.12.2014
09.14.2014

09.18.2014
09.20.2014
09.22.2014
09.24.2014

09.28.2014
09.30.2014
10.02.2014
10.04.2014
10.06.2014
10.08.2014
10.10.2014
10.12.2014
10.14.2014
10.16.2014

10.20.2014
10.22.2014
23 © Nokia Solutions and Networks 2014
VoLTE Drop Call Rate active drops per active minute QCI1
Active Drops per Session Time active drops per active minute non-GBR
non-GBR to QCI1 ratio
• The simple dropped call rate calculation 0 6
(drops/setup E-RABs per QCI) is not
0
necessarily a good metric due to the 5

extremely large difference in session 0


times between QCI1 (100s – 200s) and 4

Non-GBR : (0.5s – 1.5s) 0

drops per minite


3
• The QCI1 performance in terms of drops 0

Ratio
per minute is much better compared to 2
0
the non-GBR, i.e. QCI1 performance
should be also monitored by active drops 0 1
per active in session time.
0 0
4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
201 201 201 201 201 201 201 201 201 201 201 201 201 201 201
1. 2. 3. 4. 5. 6. 7. 8. 9. 0. 1. 2. 3. 4. 5.
0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.2 0.2 0.2 0.2 0.2 0.2
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

24 © Nokia Solutions and Networks 2014


VoLTE Drop Call Rate
DCR vs. Release Causes
• After iPhone6/6Plus launched with
iPhone6 VoLTE VoLTE enabled, the VoLTE calls
launch
increased by 6 times.
• VoLTE drop rate (ADR) KPI is stable
with ~1.6% level with more call
attempts.
• Howeve, abnormal VoLTE call release
distribution is as follows:
- ~80% calls are caused by EPC release due to
Radio cause
- ~10% calls are caused by ENB release due to
Radio cause
- ~10% calls are caused by ENB release due to
Other cause

25 © Nokia Solutions and Networks 2014


VoLTE Drop Call Rate
Duplicated S1 Connection
• Duplicated S1 connection occurs when the UE tries to
make HO from eNB-A cell to eNB-B cell but the HO fails
and following RRC connection re-establishment fails (no MME
LTE1617) and therefore, UE makes new RRC setup
attempt in eNB-B cell which causes new (duplicated) S1 eNB-B
connection establishment towards the MME
- The MME notices that there are two S1 connections for the
UE
UE and releases the old one (eNB-A). This release can be
done with cause: NORMAL release or RADIO, where the
latter causes dropped call counting (EPC initiated E-RAB
release due RNL)
eNB-A
UE
- After activation of LTE1617 there is no gain expected in
dropped call rate if the MME releases the duplicated S1
connection with NORMAL release cause (only gain on the
reduced mute time).
26 © Nokia Solutions and Networks 2014
VoLTE Drop Call Rate
Release Causes
• Note that different networks might have completely different call release cause distribution depending
on MME vendor.
FR, QCI1 EPC rel, RNL FR, QCI1 EPC rel, OTH FR, QCI1 EPC rel, RNL FR, QCI1 EPC rel, OTH FR, QCI1 EPC rel, RNL FR, QCI1 EPC rel, OTH
FR, QCI1 ENB rel, RNL FR, QCI1 ENB rel, OTH FR, QCI1 ENB rel, RNL FR, QCI1 ENB rel, OTH FR, QCI1 ENB rel, RNL FR, QCI1 ENB rel, OTH
FR, QCI1 ENB rel, TNL FR, QCI1 ENB rel, TNL FR, QCI1 ENB rel, TNL
8.00
1.20 8.00
6.00
7.00
1.00
4.00 6.00
0.80
2.00 5.00
0.00 0.60 4.00
00 59 00 00 59 00 00 59 00 3.00
00: 59: 00: 00: 59: 00: 00: 59: 00: 0.40
: : : : : : : : :
00 18 14 09 03 23 18 12 08 2.00
1 14 14 14 14 14 14 14 14
4 0.20
. 20 .20 .20 .20 .20 .20 .20 .20 .20 1.00
0 0 1 2 3 3 4 5 6
.2 .2 .2 .2 .2 .2 .2 .2 .2 0.00
10 10 10 10 10 10 10 10 10 0.00
04.20.2015 00:00:0004.23.2015 14:00:00 04.14.2015 00:00:0004.18.2015 14:00:00

E///-LG MME & Cisco/Telcoware IMS Nokia MME & Nokia IMS Samsung MME & Cisco/Telcoware IMS

27 © Nokia Solutions and Networks 2014


ERAB DR, RAN View, QCI1, LTE_5572A
VoLTE Drop Call Rate ERAB DR, QCI1 w/ data in buffer, LTE_5571B
Active Call Drops 1.00

0.90
• Typically E/// and Huawei are counting
only the drops when there is some data 0.80

in the eNB buffer to be transmitted to 0.70


the UE in both eNB triggered and EPC
0.60
triggered abnormal releases.

%
0.50
- Nokia eNB has similar counters only for
the radio related drops (eNB triggered 0.40
drops) and for radio drops the difference is
0.30
quite massive between all drops and
drops only in case there is data in buffer 0.20
as shown in the graph on the right 0.10
• 0.4%-0.8% for all drops
0.00
• 0.05%- 0.15% for drops with data in

.2 01 0: 00

.2 01 2: 00
.2 01 2: 00

.2 01 4: 59
.2 01 0: 00
.2 01 0: 00

14 :0 0

59
.2 01 0: 00
.2 01 6: 00
.2 01 5: 00
.2 01 2: 59

.2 01 8: 00
.2 01 8: 00
.2 01 3: 00

.2 01 0: 00

:5 0
20 06 :0
15 0:0
10 5.2 4 1 00:
10 0.2 4 1 00:
10 1.2 4 2 00:
10 1.2 4 0 00:
10 2.2 4 1 00:
10 2.2 4 0 59:
10 2.2 4 1 00:
10 3.2 4 2 00:
10 3.2 4 0 00:
10 4.2 4 1 00:
10 4.2 4 0 00:
10 5.2 4 1 59:
10 5.2 4 0 00:

10 6.2 4 2 00:

9:
buffer

6. 4 00
.2 01 0:
10 0.2 4 0
.2 01
10 0.2
.2
28 © Nokia Solutions and Networks 2014
10
SRVCC
SRVCC Success Rate
SRVCC Success (%)
• SRVCC performance for
Inter RAT HO Attempts to UTRAN SRVCC Inter RAT HO UTRAN with SRVCC Success Rate
VoLTE has declining trend with
95 20 000 increased attempts.
90 720 users - 15 MHz 18 000 - SRVCC is degraded due to an
85 Admission Control Threshold – 75% 600 users - 10 MHz
issue in MSS not sending proper
16 000
cause code for successful
SRVCC HO and thus, SRVCC
80
14 000

75 success counter is not correctly


12 000
incremented.

Attempts (#)
Success (%)

70
e
reas
c inc • The IMS network was not
10 000
65
TE traffi
oL
3xV 8 000
supporting aSRVCC and
60

55
6 000 therefore, the customized
4 000
firmware was created for the
phones to do CSFB instead of
50

45 2 000
VoLTE when the RSRP is less
40 0 than -115 dBm.
08.25.2014
08.27.2014
08.29.2014
08.31.2014
09.02.2014
09.04.2014
09.06.2014
09.08.2014
09.10.2014
09.12.2014
09.14.2014
09.16.2014
09.18.2014
09.20.2014
09.22.2014
09.24.2014
09.26.2014
09.28.2014
09.30.2014
10.02.2014
10.04.2014
10.06.2014
10.08.2014
10.10.2014
10.12.2014
10.14.2014
10.16.2014
10.18.2014
10.20.2014
10.22.2014
29 © Nokia Solutions and Networks 2014
SRVCC
SRVCC I-RAT Measurements

Modus avg time


Blind redirection w/o SRVCC and no 3G MEAS 110 ms
3G MEAS 1 neighbour 3G cell @ 1 UTRAN carrier 556 ms
3G MEAS 6 neighbour 3G cells @ 1 UTRAN carrier 707 ms
3G MEAS 12 neighbour 3G cells @ 1 UTRAN carrier 760 ms
3G MEAS 6+6 neighbour 3G cells @ 2 UTRAN carriers 853 ms

• If the measurements are started too late (low A2 threshold) and too large amount of 3G neighbors
the UE does not have enough time to send measurement reports (B2) hence the call drops.
• If A2 is set very close to B2 threshold this will reduce the time during which the measurement gaps
are scheduled to the mobile which may lead to non-optimal choice of target RAN cell if UE does not
have time to measure the best target cell (e.g. long neighboring list).
• However, if the SRVCC is triggered too early there might be too many SRVCC attempts and
aSRVCC attempts causing further challenges in case not supported by IMS.
30 © Nokia Solutions and Networks 2014
VoLTE Measurements and SRVCC Thresholds
Parameter alignment
Inter-frequency measurements will be started at threshold2InterFreqQci1
and A3 event is triggered once neighbouring cell becomes
Intra-frequency neighbouring a3OffsetRsrpInterFreqQci1 better than serving cell. The recommendation
cell measurements will be is to activate LTE inter-frequency measurements 2-3 dB earlier than
started at Threshold1 SRVCC measurements to favor handover to other LTE frequency before
moving to WCDMA. Thresholds are relative to -140 dBm

RRC connection release with


SRVCC measurements
redirect will be started at
will be started at
threshold4. Parameter
threshold2WcdmaQci1.
a2RedirectQci1 (= disabled)
can be configured not to
trigger redirection for VoLTE
users
Threshold2aQci1 b2Threshold1UtraQci1

RSRP decreases Threshold1 threshold2InterFreqQci1 threshold4 -140


threshold2WcdmaQci1

SRVCC handover will be triggered once a serving cell coverage falls


Inter-RAT and inter-frequency below b2Threshold1UtraQci1 and a neighboring cell RSCP and/or
measurements are stopped at EcNo is better than b2Threshold2UtraRscpQci1 and/or
Threshold2aQci1 b2Threshold2UtraEcn0Qci1

31 © Nokia Solutions and Networks 2014


SRVCC
Handover Interruption Time
• There is a short interruption period during SRVCC, i.e. user can notice ‘silent’ period.
• The interruption time of SRVCC should not be higher than 300ms as required in
TS 22.278 from EUTRAN to UTRAN.

32 © Nokia Solutions and Networks 2014


SRVCC
Frequency of SRVCC Handovers

• How often UEs move to WCDMA by SRVCC in three areas. (Dense / Rural / Highway)?
• UE was experiencing SRVCC every 4 minutes (average) in rural are and highway.

Dense area Rural area Highway


# of SRVCC 0 12 7

Total missing period during SRVCC 0.00 2.85s 1.81s

Total call duration 51min39s 49min16s 27min21s

On average UE experienced SRVCC


Every 4 minutes

33 © Nokia Solutions and Networks 2014


SRVCC
Setting Threshold
• To expand VoLTE service area and reduce chances of missing audio -> set SRVCC
threshold to as low value as possible.

Before VoLTE and PS available PS only

After VoLTE and PS available PS only VoLTE expanded area

LTE Redirect to WCDMA


threshold (-120dBm)

WCDMA

SRVCC threshold(current) SRVCC threshold(after)

34 © Nokia Solutions and Networks 2014


SRVCC
Setting Threshold VoLTE call drop case by redirect (from field measurement)

• If RRC release with redirect is


No SRVCC
triggered before SRVCC the
VoLTE call drops. Especially, RSRP suddenly
degraded
high speed users can
experience this problem.
• Sufficient margin between
SRVCC and RRC release with
redirect threshold need to be
assigned.
• In FL15A new parameter VoLTE call
dropped
a2RedirectQci1 = disabled
allows to disable redirection for
VoLTE users

35 © Nokia Solutions and Networks 2014


SRVCC
RSRQ based SRVCC HO
• If SRVCC triggering threshold is set to very low value the user might experience bad RF
quality before RSRP threshold is reached.
• However, SRVCC trigger (B2) is currently (this project) based on RSRP and thus, SRVCC
is not triggered once RSRQ degrades.
• LTE2572 RSRQ based B2 feature is available from FL17 onwards.

Do we need RSRQ based SRVCC


triggering?
LTE
VoLTE
(QCI1)
WCDMA

SRVCC threshold SRVCC threshold(after)


(current:-113dBm)

36 © Nokia Solutions and Networks 2014


SRVCC
RSRQ based SRVCC HO
• Relation between RSRQ and UL BLER shows that VoLTE voice quality deteriorates when
RSRQ becomes lower than -14dB @ UL BLER = 20%
RSRQ
-5 ○ Relation
Call
Call drop
drop -6 ○ between voice
Almost
Almost
Partially -7 ○
Clear voice quality
Partially
missing
missing
missing
missing quality and
-8 ○ RSRQ
-9 ○
-10 ○
-11 ○
-12 ○
-13 ○ Legend
-14 △
○ Clear voice
BLER -15 △
△ Partially missing
20% -16 △ voice
-17 ▲ ▲ Almost Missing
-18 ▲ voice
37 © Nokia Solutions and Networks 2014
-19 × × Call drop
VoLTE High Traffic Event
Performance

38 © Nokia Solutions and Networks 2014


High Traffic Events Handling in LTE
Introduction

Uplink Interference Mass events are uplink limited. Power control, link adaptation
Management and scheduling optimization

RRC Connected UE
High number of RRC connected UE per cell and per eNodeB
Capacity

Control Channel High RACH, PUCCH and PDCCH capacity and efficient
Capacity PDCCH link adaptation

Base Station Very high signalling capacity


Signalling Capacity Peak >250 actions / second / BTS

Inter-Frequency load balancing algorithms must minimize


Load Balancing signalling while balancing the load

39 © Nokia Solutions and Networks 2014


Busan Fireworks Festival (October 2015)
Highest performance and stability even under highest load

 Audience: ~ 1.5 million

 Event time: 20:00 to 21:30

 Signalling Traffic Peak: + 500% @ 20:00


(no admission control rejections)

 Call Completion SR – QCI1


 prior event: 99.7%
 during the event: 99.2%

 Max. UE per cell: 479

 388 cells and 40MHz


 10MHz @ 850
 10MHz @ 2100
 20MHz @ 2600
40 © Nokia Solutions and Networks 2014
Confidential
41 © Nokia Solutions and Networks 2014
Document ID / v. 0.1 / Life cycle status / Dept. / Author
VoLTE High Traffic Performance
Data Traffic Profile

• The BH is one hour earlier for VoLTE traffic compared to data in terms of E-RAB setups. The

S e t u p a t t s : Q C I 1 E -R A B , Q C I 2 E -R A B
uplink data volume starts to drastically increase during the event (fireworks).
S e t u p a tt a s : n o n -G B R E -R A B

#subs per cell DL Data Volume per Subs [MB]


UL Data Volume per Subs [MB]
450.00 6.0
400.00
5.0
350.00

Number of subscribers
300.00 4.0

Data volume [MB]


E-RAB Setup atts, non-GBR per cell
E-RAB Setup atts per cell, QCI2
250.00
3.0
9,000.0
E-RAB Setup atts, QCI1 per cell
80
200.00
8,000.0
7,000.0
70
60
150.00 2.0
6,000.0
5,000.0
50
100.00
4,000.0
40 1.0
3,000.0 30 50.00
2,000.0 20
1,000.0 10 0.00 0.0
00 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0.0 0

0: 2 : 4 : 6: 8: 10 : 12 : 14 : 1 6 : 18 : 20 : 22 :

42 © Nokia Solutions and Networks 2014


VoLTE High Traffic Performance
RRC Connected Users

• 2600MHz layer collects 40-50% of all RRC connected users during the highest traffic time
(6pm – 10pm) -> load balancing tries to put as many users to 2600 (largest BW) as possible.

RRC Connected Users Share [%] RRC connected users, max,LTE_806A


RRC connected users, avg, LTE_805A
100%
90% 600 40
80% 35
500
70% 30
60% 400
25

Average per cell


50%

Max per cell


300 20
40%
30% 15
200
20% 10
10% 100
5
0%
0 0
0:00

2:00

6:00
4:00

8:00

10:00

12:00

14:00

16:00

18:00

20:00

22:00
0 0 00 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0: 2: 4: 6 : 8 : 1 0 : 1 2 : 1 4 : 1 6 : 18 : 20 : 22 :

850 2100 2600

43 © Nokia Solutions and Networks 2014


VoLTE High Traffic Performance
E-RAB Attempts

• 2600MHz layer carries largest amount of eRAB setups up to 16000 during BH @7pm
followed by 850MHz layer and then 2100MHz layer.

ERAB Stp Att, QCI1, share - 2600 ERAB Stp Att, QCI1, share - 2100
QCI1 ERAB Setups - 850 QCI1 ERAB Setups - 2100 QCI1 ERAB Setups - 2600
ERAB Stp Att, QCI1, share - 850
100%
16000
90%
80% 14000
70% 12000
60%
10000
50%
40% 8000
30% 6000
20%
4000
10%
0% 2000
0:00

2:00

4:00

7:00

9:00

11:00

13:00
14:00
15:00
16:00

18:00

20:00

22:00
23:00
1:00

3:00

5:00
6:00

8:00

10:00

12:00

17:00

19:00

21:00

0:00
1:00

3:00
4:00
5:00

7:00
8:00

12:00
13:00

15:00
16:00
17:00
18:00
19:00
20:00

22:00
23:00
2:00

6:00

9:00
10:00
11:00

14:00

21:00
44 © Nokia Solutions and Networks 2014
VoLTE High Traffic Performance
E-RAB Setup Success

• E-RAB setup success rate performance during the event is stable around 99.6%
in average.
QCI1 E-RAB stp SR 850 QCI1 E-RAB stp SR 2100 E-RAB Setup
QCI1 E-RAB stp SR 2600 E-RAB success, QCI1,
Setup success, QCI1, LTE_5204B
LTE_5204B
100.0%
100.0

99.5% 99.5

99.0% 99.0

98.5
98.5%

98.0

8:00
9:00
10:00

12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
0:00
1:00
2:00
3:00
4:00
5:00
6:00
7:00

11:00

23:00
98.0%
1
1
1
1
1
1
1
1
1
1
2
2
2
2
0:00

2:00

4:00

6:00
1:00

3:00

5:00

7:00
8:00
9:00

45 © Nokia Solutions and Networks 2014


VoLTE High Traffic Performance
E-RAB Drop Rate

• Dropped call performance during the event is stable around 0.7%.

QCI1 drop rate - 850 QCI1 drop rate - 2100


ERAB DR, RAN View, QCI1, LTE_5572B
QCI1 drop rate - 2600
1.4% ERAB DR, RAN View, QCI1, LTE_5572B
1.0
1.2%
0.9
1.0% 0.8
0.7
0.8%
0.6
0.6% 0.5
0.4
0.4%
0.3
0.2% 0.2
0.1
0.0%
0.0
00 00 00 00 00 :0
0
:0
0
:0
0
:0
0
:0
0
:0
0
:0
0
0: 2: 4: 6: 8: 10 12 14 16 18 20 22 00 00 00 00 00 :0
0
:0
0
:0
0
:0
0
:0
0
:0
0
:0
0
0: 2: 4: 6: 8: 10 12 14 16 18 20 22

46 © Nokia Solutions and Networks 2014


VoLTE High Traffic Performance
Packet Discards - DL

• DL PDCP discard ratio is below PDCP SDU discard QCI1, DL, LTE_5256B - 850
PDCP SDU discard QCI1, DL, LTE_5256B - 2100
0.1% even at highest loaded PDCP SDU discard QCI1, DL, LTE_5256B - 2600
times -> retransmission delay 0.12
does not cause discard time to
0.1
expire and therefore loss of
packets. 0.08

0.06

%
0.04

0.02

1:00
2:00

5:00
6:00

10:00
11:00

13:00
14:00
15:00

17:00
18:00
19:00

21:00
22:00
23:00
0:00

3:00
4:00

7:00
8:00
9:00

12:00

16:00

20:00
47 © Nokia Solutions and Networks 2014
Confidential
VoLTE High Traffic Performance
Packet Discards - DL

850 2100 2600


0.01

PDCP SDU Discard DL, QCI1 [%]


0.01

• The packet discard ratio increases with 0.01

decreasing CQI. 0

• The average latency causes rapid increase 0

of the packet discards after ~12ms latency 0


2 4 6 8 10 12 14 16 18 20 22
0
Average Latency, DL QCI1 [ms]
850 2100 2600 850 2100 2600
0.02 0.02

PDCP SDU Discard DL, QCI1 [%]


PDCP SDU Discard DL, QCI1 [%]

0.02 0.02

0.01 0.01

0.01 0.01

0 0
9 9.5 10 10.5 11 11.5 12 12.5 4 4.5 5 5.5 6 6.5 7 7.5 8 8.5 9

0 0
48 © Nokia Solutions andAverage
NetworksCQI
2014 Residual BLER, DL [%]
Confidential
VoLTE High Traffic Performance
Packet Losses - DL

PDCP Loss ratio QCI1, DL, LTE_5305B - 850


• Packet loss ratio in DL for QCI1 is below PDCP Loss ratio QCI1, DL, LTE_5305B - 2100
PDCP Loss ratio QCI1, DL, LTE_5305B - 2600
0.25% during highest loaded time 0.45

0.4

0.35
QCI1 ERAB Setups - 850 QCI1 ERAB Setups - 2100
QCI1 ERAB Setups - 2600 0.3
16000
0.25
14000
12000

%
0.2
10000
8000 0.15
6000
0.1
4000
2000 0.05
0
1

1:00

3:00
4:00

6:00
7:00
8:00

10:00
11:00
12:00

14:00

16:00

18:00

20:00
21:00
22:00
0:00

2:00

5:00

9:00

13:00

15:00

17:00

19:00

23:00
49 © Nokia Solutions and Networks 2014
Confidential
VoLTE High Traffic Performance
Packet Losses - DL

850 2100 2600


0.45

PDCP SDU Loss Ratio DL, QCI1 [%]


0.4
0.35
• The DL packet losses for QCI1 seem to 0.3
increase with decreasing CQI and particularly 0.25
0.2
along with increasing DL latency. 0.15
0.1
0.05
0
9 9.5 10 10.5 11 11.5 12 12.5
Average CQI

ERAB Stp Att, QCI1, share - 850 ERAB Stp Att, QCI1, share - 2100 850 2100 2600
ERAB Stp Att, QCI1, share - 2600
0.45

PDCP SDU Loss Ratio DL, QCI1 [%]


100%
90% 0.4
80% 0.35
70% 0.3
60% 0.25
50%
0.2
40%
0.15
30%
20% 0.1
10% 0.05
0% 0
0 2 3 4 5 6 7 8 9 10 11 12 13 14
0 00 00 00 00 00 :0
0
:0
0
:0
0
:0
0
:0
0
:0
0
50 0: 2: © Nokia
4: Solutions
6: 8:and 1Networks
0: 12 2014
14 16 18 20 22 Average DL Latency, QCI1 [ms]
Confidential
VoLTE High Traffic Performance
Packet Losses - UL

• Packet loss ratio in UL is below PDCP loss ratio , QCI1, UL, LTE_5311B - 850
PDCP loss ratio , QCI1, UL, LTE_5311B - 2100
0.4% for QCI1 during highest PDCP loss ratio , QCI1, UL, LTE_5311B - 2600

loading time 0.4

0.35

QCI1 ERAB Setups - 850 QCI1 ERAB Setups - 2100


0.3
QCI1 ERAB Setups - 2600

16000 0.25
14000
12000 0.2

[%]
10000
8000 0.15

6000
0.1
4000
2000 0.05
0
1

10:00
11:00
12:00
13:00
14:00

18:00
19:00
20:00
21:00
2:00
3:00
4:00
5:00

9:00

15:00
16:00
17:00

22:00
23:00
0:00
1:00

6:00
7:00
8:00
51 © Nokia Solutions and Networks 2014
Confidential
VoLTE High Traffic Performance
Packet Losses - UL

850 2100 2600

PDCP SDU Loss Ratio UL, QCI1 [%]


0.4
• The UL packet losses for QCI1 seem to 0.35
0.3
increase a bit with increasing RSSI as well 0.25
as with increasing DL latency and especially 0.2
0.15
the packet loss increases with decreasing 0.1
PUSCH SINR 0.05
0
-108 -106 -104 -102 -100 -98 -96 -94
PUSCH RSSI [dBm]

850 2100 2600 850 2100 2600


0.4 0.4

PDCP SDU Loss Ratio UL, QCI1 [%]


PDCP SDU Loss Ratio UL, QCI1 [%]

0.35 0.35

0.3 0.3

0.25 0.25

0.2 0.2

0.15 0.15
0.1
0.1
0.05
0.05
0
0 2 3 4 5 6 7 8 9 10 11 12 13 14
52 2 4 © Nokia
6 Solutions
8 and
10Networks
12 2014
14 16 18 20 22
Confidential Average DL Latency, QCI1 [ms]
PUSCH SINR [dB]
VoLTE Optimization –
Use Cases

53 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
Physical layer optimization

• Antenna down tilt optimization reduced significantly VoLTE drop call rate due to improved
interference control, i.e. cell dominance was improved.
54 © Nokia Solutions and Networks 2014
Drop Call Optimization
Periodical CQI Reporting

55 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
CQI report failure detected on PUCCH

• From Traffica news, more


than 50% call failures are
cause by CQI report failure
detection on PUCCH

*Only 1 days data

56 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
eNB Detected Radio Link Failures (RLF) – CQI DTX Detection
• Nokia eNB can use periodic CQI reports for radio link failure detection on PUCCH and
PUSCH
- If MAC layer receives nCqiDtx consecutive reports from UL PHY, the MAC declares CqiRlf_ON
(this can be seen in BTS log and Emil)
- If the MAC has set CqiRLF_ON for a specific UE and nCqiRec consecutive CQI reports are
again detected successfully for that UE, the MAC sets CqiRlf_OFF.
- When a radio link problem is detected, an eNB-internal timer (T_RLF = T310 + T311 + 2200ms)
is started and stopped in case of radio link recovery or otherwise RRC+S1 release is triggered by
eNB
• In case the periodical CQI reporting periodicity is increased (or detection is disabled)
the dropped call rate decreases as some of the unnecessary call releases can be
avoided.
• NOTE: CQI_RLF detection does not apply to aperiodic CQI report in PUSCH

57 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
eNB Detected Radio Link Failures (RLF) – CQI DTX Detection
T_RLF = t310 + t311 RLF timer running

Periodic CQI detected

Periodic CQI detected


Periodic CQI detected
Periodic CQI
detected

DTX

DTX

DTX
DTX

DTX
CQI

CQI

CQI

CQI

CQI
DTX

DTX
DTX

DTX
DTX
CQI

CQI
CQI

CQI

CQI
time
LNCEL/cqiPerNp=10ms CQI_RLF ON
CQI_RLF
Example Vendor Parameter Values: OFF
nCqiDtx=4
nCqiRec=2

58 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization

• E-RAB drop call rate has increased


from mid-March and it goes up to
0.2%, i.e. 2x higher than before.
ERAB Drop increased
• However VoLTE drop looks no suddenly
From mid of March
difference.
• Samsung Galaxy Note 3 was
launched at mid of March

No Changes in VoLTE
Drop Ratio

59 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
Samsung Mobile Issue
• Due to Missing CQI report from Galaxy Note3 (NB3, NBD, NC3 version), eNB detect CqiRLF_ON and send
UEcontextReleaseRequest to MME with “radio connection with ue lost” Cause

Nomal case – CQI report

Abnormal case – no CQI report

60 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
nCqiDtx from 100 to 0
• eNB RLF detection
Both E-RAB DR(LTE_5025D) and E-RAB DR, based on periodic CQI
QCI1(LTE_5572A) is decreased
reporting was disabled
(nCqiDtx=0):
• E-RAB DR
(LTE_5025D) is
dropped from 0.068%
to 0.055% in average
(19% improvement)
• E-RAB DR,
QCI1(LTE_5572A) is
decreased from 0.116%
to 0.094% in average
(19% improvement)

61 © Nokia Solutions and Networks 2014


LTE2206: Extended RLF handling
Feature in the Nutshell

FL16 feature allows tuning RLF detection sensitivity at eNB in order to keep UEs longer in
RRC connection state.
It applies to cases the eNB indicates RLF due to CQI DTX
- The tuning is possible by setting LNBTS:nCqiDtx and LNBTS:nCqiRec parameters
LTE2206 does not change RLF detection functionality, sensitivity RLF indication is
issued

Before introduction LTE2206 feature: With LTE2206 feature:


Range and step
LNBTS:nCqiDtx==100 Hardcoded LNBTS:nCqiDtx 0…250 step 1
LNBTS:nCqiRec==2 values LNBTS:nCqiRec 1…8 step 1

62 © Nokia Solutions and Networks 2014


For internal use
Drop Call Optimization
QCI1 Specific T310 and T311 Timers

63 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
Physical Layer Failure & Recovery
• Timer T310 supervises the recovery from physical layer problems and Timer T311
supervises the RRC connection re-establishment.
3. T310 expires -> detection of radio link
failure : all RBs are suspended except
SRB0, the UE tx turned off in 40ms, the UE 6. UE acquires UL grant via random access
initiates RRC re-establishment process and procedure and physical layer sends RRC
1. UE detects 1st out of
searches for the best cell. T311 is started connection re-establishment request message
synchronization

4. UE finds suitable cell


Time

T310 running T311 running


7. UE receives RRC connection re-
2. UE detects n310 amount
5. UE acquired System Information establishment message and timer
of out of synchronization ->
of the target cell. The UE layer 3 T301 is stopped. SRB1 is resumed
The UE starts timer T310
sends RRC connection re- and layer 3 sends RRC connection
establishment message to the lower re-establishment complete message
layers. T311 is stopped and T301 to physical layer and procedure ends.
started.
64 © Nokia Solutions and Networks 2014
LTE1569: QCI1 Specific RLF and Re-establishment Control
QCI1 specific T310 and N310 Only UEs Rel. 9 and higher are benefiting from LTE1569

LTE1569 allows to configure QCI1 specific settings of N310 (LNCEL:n310qci1) and T310 (LNCEL:t310qci1) which are provided to the
UE during QCI1 bearer establishment by RRC Connection Reconfiguration message (overwriting SIB2 broadcasted values).
When UE is ending the VoLTE call, eNB sends RRC Connection Re-configuration message to release QCI1 DRB, this message
includes also RLF-TimersAndConstants-r9 IE with legacy values of T310 and N310 (LNCEL:t310 and LNCEL:n310).

System Information Block Type 2 RRC Connection Reconfiguration


Information Element Parameter Information Element Parameter
Ue-TimersAndConstans RLF-TimersAndConstants-r9
> t300 LNCEL:t300 > t300-r9 LNCEL:t300
> t301 LNCEL:t301 > t301-r9 LNCEL:t301
> t310 LNCEL:t310 > t310-r9 LNCEL:t310qci1
> n310-r9 LNCEL:n310qci1
> n310 LNCEL:n310
> t311-r9 LNCEL:t311
> t311 LNCEL:t311
> n311-r9 LNCEL:n311
> n311 LNCEL:n311
Ue-TimersAndConstans from broadcasted SIB2 are replaced The rest of the parameters needed for
in the UE by parameters from RLF-TimersAndConstants-r9 in rlf-TimersAndConstants IE are taken from legacy
RRC Connection Reconfiguration parameters used for SIB2.
Note: If configured QCI1 specific T310 and N310 are equal to legacy values, eNB will not include rlf-TimersAndConstants IE.

65 © Nokia Solutions and Networks 2014


For internal use
VoLTE Drop Call Optimization
Field Trial Settings

• Tests were performed with 3 different parameter settings:


Set 1: Set 2: Set 3:
Abbreviate MO
Full Name Modification Range and step Feature Feature Feature
d Name Class
OFF ON: n6 ON: n4
n310Qci1 N310 for QCI1 LNCEL On-line 1:n1;2:n2;3:n3;4:n4;6:n6;8:n8;10:n10;20:n20 -  - n4
0:0ms;50:50ms;100:100ms;200:200ms;500:500ms;1000:
t310Qci1 T310 for QCI1 LNCEL On-line 1000ms;2000:2000ms
-  500ms 500ms
Maximum number of
n310 out-of-sync LNCEL On-line 0:n1;1:n2;2:n3;3:n4;4:n6;5:n8;6:n10;7:n20 n6 n6 n6
indications
0:0ms;1:50ms;2:100ms;3:200ms;4:500ms;5:1000ms;6:20
t310 Timer T310 LNCEL On-line 00ms
1000ms 1000ms 1000ms

Maximum number of
N311 LNCEL On-line 0:n1;1:n2;2:n3;3:n4;4:n5;5:n6;6:n8;7:n10 n1 n1 n1
in-sync indications
0:1000ms;1:3000ms;2:5000ms;3:10000ms;4:15000ms;5:
T311 Timer T311 LNCEL On-line 20000ms;6:30000ms
3000ms 3000ms 3000ms
0:100ms;1:200ms;2:300ms;3:400ms;4:600ms;5:1000ms;6
t301 Timer T301 LNCEL On-line :1500ms;7:2000ms
400ms 400ms 400ms

66 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
Field Trial Results

• Set 1: initial ERAB drop rate for QCI1 with feature not activated: 0.14%
• Set 2: reduction of T310qci1 to 500ms improvement of ERAB DR QCI1 to 0.10%
• Set 3: reduction of N310qci1 from n6->n4 did not lead to further reduction, result: 0.13%

VoLTE capable Rel. 9 UEs during test: >95% => Higher penetration would even improve result
67 © Nokia Solutions and Networks 2014
Nokia Internal Use
VoLTE Drop Call Optimization
Field Trial Results

• Target is to start early re-establishment procedure by UE before call drop, but not to trigger too
early re-establishements and therefore, increase the risk to drop the call by a failed re-
estabishment procedure itself
• Set 1: Default parameters are T310=2000ms and N310=n10 -> Network was already adapted to
T310=1000ms, N310=n6 which leads to an improved ERAB DR.
• Set 2: QCI1 specific T310qci1 reduction leads to earlier triggering of re-establishment procedure
by UE and therewith to a further improvement of ERAB QCI1 DR from 0.14% -> 0.10%
• Set 3: Further parameter adaptions to trigger re-establishment procedure by UE even earlier lead
to an increase of DR compared to previous setting (Set 2) -> increased amount of re-
establishement procedures finally lead to an increased DR as re-establishement procedure might
fail as well
- It is recommended to activate feature LTE1617 RLF triggered handover to improve re-
establiment success in overall.

68 © Nokia Solutions and Networks 2014


Nokia Internal Use
Drop Call Optimization
DRX – Optimized Algorithm

69 © Nokia Solutions and Networks 2014


DRX Impact on VoLTE Performance

Drop Call Latency Packet Loss : Handover


0.1 → 0.25 Intra :
0.2 → 0.4 5ms → 30ms 99.98→ 98.75
MOS :
3.8 → 3.7 Inter HO
99.96→ 97.16

• DRX enabling makes KPI degradation inevitable at the expense of saving UE battery
consumption:
- DRX cycle has impact on HO measurements due to increased latency and thus, drop
call rate is increased and HO success rate (too late HO increase) is degraded.
- Packet loss and degraded MOS is detected.
- Longer Inactivity timer and Shorter DRX cycle can minimize the KPI impact.

70 © Nokia Solutions and Networks 2014


DRX Impact on VoLTE
Drop Call ratio
• Once DRX features enabled VoLTE DCR is degraded more than non-GBR call due to longer
VoLTE call duration and delayed signaling.

1 DRX ON (QCI1/2/5/6)
• E-RAB / VoLTE DCR is significantly degraded.
2 DRX OFF (QCI1/2)
• VoLTE DCR was not changed because QCI 5/6
still on DRX. 1 2

3 DRX OFF (QCI1/2) & DRX Profile3 (QCI 5/6)


• Below changes make UE awake longer with
decreasing delay
DRX inactivity timer 10ms80ms 4
3
DRX long cycle 80ms40ms

4 DRX ON (QCI1/2) only & DRX OFF (QCI5/6)


• VoLTE call drop is still increased but lower than
case 1or 2
71 © Nokia Solutions and Networks 2014
DRX Impact on VoLTE 1 DRX ON (QCI 1/2/5/6)
Latency 2 DRX ON (5/6) and OFF (QCI1/2)
• DL packets can be sent only when UE goes DRX Active time and thus, DL latency is more 3 DRX ON (5/6) and OFF (QCI1/2)
Inactivity timer(1080ms)
impacted. Uplink is not affected because UL grant will be provided after SR is sent. long drx cycle(8040ms))
• When DRX features are enabled the longer DRX cycle means also higher latency.
4 Smart DRX ON (QCI 1/2/5/6)

1 4
2
3

DL delay can be longer when


DRX cycle is longer
72 © Nokia Solutions and Networks 2014
DRX Impact on VoLTE
Packet Loss

• When enabling QCI1=drxprofile2 only, VoLTE Drop increases 2 times and Packet loss is visible in
KPI (LTE_5311b)
• In Packet loss KPI, QCI1 UL packet loss was increased but no changes in DL Packet loss

DRX enable
for QCI1

73 © Nokia Solutions and Networks 2014


DRX Impact on VoLTE
DRX Profile Priority and ANR
• In case of ANR profile101 priority is lower than other DRX profiles then eNB rejects ANR process

Recovered after changing


DRX profile1 priority 4525
Or DRX profile101 priority 3047

Before supercell work,


cDRX on no neighbor changes After Supercell work and HO
(only QCI1 so no problem even decision Ratio KPI degraded
enabled) ANR didn’t work  ANR doesn’t work

74 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
DRX Impact on Poor RF
• The current analysis of DRX problems indicate that in case of poor RF the
DRX causes additional dropped calls
- These dropped calls could be caused by additional delays caused by DRX
• Measurement delays for handovers
• Measurement inaccuracies of CQI (reported CQI in DRX active state might not correctly
reflect the RF quality due to the DRX sleep state)
• Due to this the LA might not work accurately and fast enough to be able to react on
changing CQI in poor RF and UE might never hear the HO command
• The DRX feature can be improved so that it could be turned off in poor RF (based on
CQI) and turned on in case of improved RF (improving absolute CQI value)
- Available in FL15A

75 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
DRX Optimized Algorithm for VoLTE
• If UE has QCI-1 DRB and DRX is currently enabled, and C-plane receives RL Status
Indication for this UE indicating “BadChannelQuality” then C-plane sends RRC
Reconfiguration message to UE to disable DRX:
rrcConnectionReconfiguration-r8 :
            {
              radioResourceConfigDedicated
              {
                mac-MainConfig explicitValue :
                  {
                    drx-Config release : NULL,
                    …
                 }

• If UE has QCI-1 DRB and DRX was previously disabled due to Poor RF, and C-plane
receives new RL Status Indication for this UE indicating “GoodChannelQuality”, then C-
plane sends RRC Reconfiguration message to UE to re-install the DRX profile (i.e. re-
enable DRX) provided that other DRX feature add conditions (feature flag, configuration,
etc.) are satisfied

76 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
DRX Optimized Algorithm for VoLTE – Laboratory Test

In poor RF, DRX initially turned on (very


briefly) on hand-in to target cell, then
77 © Nokia Solutions and Networks 2014 quickly turned back off state.
VoLTE Drop Call Optimization
DRX Optimized Algorithm for VoLTE

• The parameters should be set according to the network statistics i.e.


• qci1DrxOnThreshold (default=9) should be set according to the average reported CQI
across the whole network i.e. if average reported CQI = 9 then CDrxOnThreshold
should be set to 9.
• qci1DrxOffThreshold (default=7) should be set 2 steps below the above parameter
value
• Above parameters will be tunable parameters in release 16 (defaults used as above)
• Algorithm can be switched on and off by parameter in release 15A

78 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
DRX Optimized Algorithm for VoLTE

• cDRX setup and


release in one cell
is depending on
CQI level.
• However it’s not
exactly matched
with CQI threshold
since CQI
act/deact works
based on adjusted
CQI, not UE
reported CQI.

79 © Nokia Solutions and Networks 2014


VoLTE Drop Call Optimization
DRX Optimized Algorithm for VoLTE – Field Test
• VoLTE DR increased greatly right after cDRX ON in knife version which has CQI threshold as 7and 9 for
deactivation and activation accordingly. Turned CDRX off and VoLTE DR became back to before level. Turned
CDRX on again with changing CQI threshold as 9 and 11 and VoLTE DR maintained as CDRX off level.

Avg
Avg CQI
CQI is
is 11
11 or
or higher
higher in
in the
the
cluster
cluster so
so changed
changed CQI
CQI
threshold
threshold higher
higher

80 © Nokia Solutions and Networks 2014


Voice Quality Optimization
PDCP Discard Timer and SN Size

81 © Nokia Solutions and Networks 2014


Voice Quality Optimization
PDCP Discard Timer
Lab Test(Cell edge)
・ MinTbs56
• The lab tests for the cell edge user showed
・ PRB3 & MCS0
significant MOS improvement when tDiscard (for ・ UL BLER10%
QCI1) was increased. There are 2 root causes
for this performance:
tDiscard Median POLQA
• Case #1 (significant only for the high loaded, in
DL, cells)
300ms 2.9
- During high load the HARQ retransmissions can be
delayed in DL (in UL HARQ retransmissions must
be synchronous to 8ms intervals) hence in case 500ms 2.86
tDiscard is very short and HARQ retransmissions
are allowed to run e.g. up to 7 HARQ transmissions
the total delay can easily exceed the tDiscard 1500ms 3.30
default value: 100ms.

82 © Nokia Solutions and Networks 2014


Voice Quality Optimization
PDCP Discard Timer
• Case #2 (significant for the cell edge user) UE eNB

- the tDiscard starts running @ PDCP layer when UE


UE has
has VoLTE
VoLTE packet
packet for
for
the PDCP SDU is sent to lower layer transmission
transmission and
layer
and PDCP
PDCP
layer sends
sends the
the PDCP
PDCP
PDU
PDU toto lower
lower layers
layers for
- However the tDiscard runs despite the lower transmission
transmission ->-> SR
SR
for

layer problems for e.g. SR transmissions -> triggered


triggered

some VoLTE packets never transmitted causing SR Scheduling Request


problems for MOS and causing OWA (One Way (re)transmitted
according to
Audio) SR periodicity
parameter
- PUCCH OLPC parameter evaluation (SR)
eNB
eNB does
does not
not hear
hear the
the SR
SR
causing
causing delay
delay and
and
potential
potential tDiscard
tDiscard expiry
expiry
without
without any
any successful
successful
transmission
transmission
Same scenario
happens for
non-GBR

83 © Nokia Solutions and Networks 2014


Voice Quality Optimization
PDCP Discard Timer

PDCP tDiscard Avearge PDCP delay


500ms 100ms–14.860ms vs. 500ms–14.755ms
300ms 100ms–15.302ms vs. 300ms –
15.389ms

84 © Nokia Solutions and Networks 2014


Voice Quality Optimization
PDCP Sequence Number Size
UE eNB
• The UE might experience long lasting UL (or DL)
coverage problems (RTP time out) and eNB might UE
UE has
has VoLTE
VoLTE packet
packet for
for
not hear the SRs at all (sent by PUCCH or RACH) transmission
transmission and
layer
layer sends
and PDCP
sends the
PDCP
the PDCP
PDCP
PDU
PDU toto lower
lower layers
layers for
for
- This can cause several PDCP packets to be discarded and transmission
transmission ->-> SR
SR
eventually the PDCP HFN in the Tx and Rx (cipher and decipher triggered
triggered
respectively) can have a mismatch causing ciphering
Scheduling Request
(deciphering) problems and RTP time out.
SR
- The current default pdcp profile101/snSize = 7bit which can (re)transmitted
according to SR
handle 2^7*20ms=2.56s long duration of UL or DL coverage periodicity
parameter
problems -> recommendation is to change from 7bit to 12bit to eNB
eNB does
does not
not hear
hear the
the SR
SR
enable 2^12*20=81.92s duration for better recovery and reduced causing
causing delay
delay and
and
potential
potential tDiscard
tDiscard expiry
expiry
probability of sequence number ambiguity. without
without any
any successful
successful
transmission
transmission
- Similarly the RLC header size should be increased RLC
profile101/snFieldLengthxL from size5 to size10 (5bit to 10bit) to Scheduling Request
enable better recovery

85 © Nokia Solutions and Networks 2014


Voice Quality Optimization
PDCP Sequence Number Size

• Negative impact of the PDCP SN and RLC SN • Data PDU with Long PDCP SN (12 bit) (RLC AM and
UM Mapped DRBs)
increase is that the total TB size due to larger
PDCP and RLC overhead.

• Data PDU with Short SN (7 bit) (RLC UM Mapped


DRBs)

86 © Nokia Solutions and Networks 2014


Voice Quality Optimization
Field Trial Results
• RTP jitter in Huawei area is only about 7 ~ 8ms, while the RTP jitter is about 14ms in Nokia area.
• The parameter setting of different vendors (ZTE/NOKIA/HUAWEI)
Fenghua Haishu Shaoxing
3GPP Parameter
1. From the test resut, disable DRX can
(ZTE) (Nokia) (Huawei) Nokia parameter

len12bit len7bit len12bit


pdcp-SN-Size
maxCID
s
15
s
4
s
5
pdcp profile101/snSize
pdcp profile101/rohcMaxCid
improve the RTP Jitter
ul-UM-RLC/sn-FieldLength
dl-UM-RLC/sn-FieldLength
size10
size10
size5
size5
size10
size10
RLC profile101/snFieldLengthTL
RLC profile101/snFieldLengthDL
2. Changing pdcp-SN-Size can further
t-Reordering
prioritisedBitRate
45ms
8kbps
50ms
8kbps
50ms
16kbps
RLC profile101/tReord
pbrNonGbr  ?
improve RTP jitter and MOS and RTP
discardTimer
bucketSizeDuration
infinity
500ms
100ms
100ms
100ms
100ms
pdcp profile101/tDiscard
QCI tab1/schedulBSD
packet loss.

Packet Loss RTP Jitter


Date Test Case RSRP SINR MOS Duration Comments
Ratio (ms)

20151215 Default -83.172 14.767 0.83% 3.83 14.37 286.31  

20151215 Test case1 -83.166 15.129 0.58% 3.8 9.57 309.46 Disable QCI1 DRX

Disable QCI1 DRX, AND pdcp


20151215 Test case2 -82.765 14.942 0.03% 3.98 7.99 281.86 profile101/ snSize=
len12bits

87 © Nokia Solutions and Networks 2014


High Speed Users
Optimization

88 © Nokia Solutions and Networks 2014


LTE48 Support of High Speed Users
Feature Description

• The Flexi Multiradio BTS supports the uplink reception for the users with the speed up to:
- 350 km/h in the open space
- 300 km/h in tunnels
• In this case the eNB uplink signal receiver suffers from a huge Doppler shift which
causes severe performance degradations
• LTE48 feature deals only with enhancing link level performance for high speed users by
intoduction of eNB UL receiver improvements (e.g. Doppler shift estimation)
• After feature activation improvements in KPIs related to HO SR, CSSR, DCR can be
observed in environment with dominant number of high speed users

89 © Nokia Solutions and Networks 2014


LTE48 Support of High Speed Users
Use of Different Operating Bands

• The relationship between Doppler frequency shift and UE speed depends on the
operating band:
• Higher carrier frequencies experience greater Doppler shifts at lower speeds - It means that
lower UE speeds are supported in the higher operating bands
Scenario 1 (Open space) Scenario 3 (Tunnel)
Carrier frequency (F_c)
[Ghz] Maximum velocity Maximum Doppler Maximum velocity Maximum Doppler
[km/h] shift (F_o) [Hz] [km/h] shift (F_o) [Hz]
1,9 1232.3 1056.3
2,3 350 1491.8 300 1278.7
2,6 1686.4 1445.4

The eNB supports high speed users up to maximum Doppler shift/offset of 1700 Hz
for open space and 1450 Hz for tunnel scenario
90 © Nokia Solutions and Networks 2014
LTE48 Support of High Speed Users
Doppler shift estimation

• Doppler shift estimation for UEs – To mitigate problems in high speed deployments
eNB shall support a Doppler shift (frequency shift) estimation for each UE based on the
received signal in different uplink physical channels (PRACH, PUSCH and PUCCH) and
signals (SRS)

PRACH PUSCH PUCCH SRS


• For improving the measurement accuracy the frequency offset measurement is filtered in
UL PHY
• The estimated frequency offset is used for correcting the received signal before
the bit level decoding

91 © Nokia Solutions and Networks 2014


LTE48 Support of High Speed Users
Feature activation

• LTE48 Support of High Speed Users feature can be activated by setting the
prachHsFlag parameter to ‘true’ (requires object locking)
• High speed flag for PRACH preamble generation determines whether an unrestricted or
a restricted set has to be used by the UE where ‘false’ = Unrestricted and ‘true’ =
Restricted.
• Configuring the prachHsFlag parameter with a value of ‘true’ has an impact on other
parameters:
- hsScenario must be configured to ‘scenario1’ or ‘scenario 3’ dependently on the deployment
scenario - Scenario 1 (open space scenario) and scenario 3 (tunnel scenario) defined by 3GPP
- The range of values available to rootSeqIndex becomes dependent on the value of prachCS –
the number of preamble sequences per root sequence is dependent upon the root sequence
(varies from one root sequence to another)
- ulCombinationMode must be set to ‘MRC’, i.e. LTE1402 Intra eNB UL CoMP cannot be used
92 © Nokia Solutions and Networks 2014
LTE2445: Combined Supercell
High Speed User support

The UE can move seamlessly between subcells, without interruption by a RACH procedure
due to cell change as with normal cells
6 RRH support allows for extended supercell coverage
High speed UE support.

93 © Nokia Solutions and Networks 2014


Nokia Internal Use
94
90.00
92.00
94.00
96.00
98.00
100.00

100.00

90.00
95.00
04.28.00
04.28.00 04.28.05
04.28.05 04.28.10
04.28.10 04.28.15
04.28.15 04.28.20
04.28.20 04.29.01
04.29.01 04.29.06
04.29.06 04.29.11
04.29.11
SR LTE_5220A

04.29.16
before
04.29.16 04.29.21
04.29.21
Total Att LTE_753A

04.30.02
04.30.02 04.30.07

© Nokia Solutions and Networks 2014


04.30.07 04.30.12
Stp SR LTE_5017A
04.30.12 Stp Att LTE_5118A
04.30.17
04.30.17
04.30.22 04.30.22
05.01.03 05.01.03
after

Normal, NW view LTE_5024C

05.01.08 05.01.08
High Speed Train Optimization

05.01.13 05.01.13
05.01.18 05.01.18
CSSR LTE_5218C

05.01.23 05.01.23
0

0
5,000
10,000
15,000
20,000

10,000
20,000
30,000
KPI Improvement after prachHsFlag=true

90.00
92.00
94.00
96.00
98.00
100.00

0.00
2.00
4.00
6.00
8.00

04.28.00
04.28.00 04.28.06
04.28.06 04.28.12
04.28.12 04.28.18
04.28.18 04.29.00
04.29.00 04.29.06
04.29.06 04.29.12
04.29.12 04.29.18
Stp ATT LTE_5116A
Data SR LTE_5117A

04.29.18 04.30.00
04.30.00 04.30.06
04.30.06 04.30.12
04.30.18
DR LTE_5025C

04.30.12
04.30.18 05.01.00
05.01.00 05.01.06
05.01.12
05.01.06
05.01.18
05.01.12
0

05.01.18
Data stp SR LTE_5003A

20,000
40,000
60,000
80,000
100,000
High Speed Train Optimization
KPI Improvement after prachHsFlag=true

Intra ENB HO Att LTE_5124A Inter ENB HO Att LTE_5125A


Intra ENB HO Prep att LTE_5123A Inter ENB HO Prep att LTE_5126A
Intra ENB HO SR total LTE_5043A Inter ENB HO SR total LTE_5058B
Intra ENB HO SR LTE_5035A Inter ENB HO SR LTE_5048B
Intra ENB HO Prep SR LTE_5036A Inter ENB HO Prep SR LTE_5049B

100.00 45,000 100.00 45,000


99.50 40,000 99.50 40,000
99.00 35,000 99.00 35,000
98.50 30,000 98.50 30,000
98.00 98.00
25,000 25,000
97.50 97.50
20,000 20,000
97.00 97.00
96.50 15,000 96.50 15,000
96.00 before after 10,000 96.00 10,000
95.50 5,000 95.50 5,000
95.00 0 95.00 0
04.28.05

04.28.15
04.28.20
04.29.01
04.29.06

04.29.16

04.30.07
04.30.12

04.30.22

05.01.08
05.01.13

05.01.23
04.28.00

04.28.10

04.29.11

04.29.21
04.30.02

04.30.17

05.01.03

05.01.18

04.28.00
04.28.05

04.28.15

04.29.06

04.29.16
04.29.21

04.30.07
04.30.12

04.30.22
05.01.03

05.01.13
04.28.10

04.28.20
04.29.01

04.29.11

04.30.02

04.30.17

05.01.08

05.01.18
05.01.23
95 © Nokia Solutions and Networks 2014
High Speed Train Optimization
DL Signaling Robustness
• PDCCH aggregation level increased for Msg2 and Msg4 to 8 CCEs.
• Maximum coderate for SIB, Paging, Msg2 and Msg4 to 0.05.

RACH SR contention based [%] ADR [%] MRBTS-382625/LNBTS-382625


MRBTS-382625/LNBTS-382625 MRBTS-389528/LNBTS-389528 45 Parameter change
MRBTS-389560/LNBTS-389560 40
15 35
Parameter change
14 30
13 25
12
5% improved
20
11 15
10 10
9 1.5% improved 5
8 0
2014.06.12

2014.06.13

2014.06.14

2014.06.15

2014.06.17

2014.06.18

2014.06.20

2014.06.21

2014.06.22
2014.06.16

2014.06.19

2014.06.14

2014.06.15

2014.06.19

2014.06.20

2014.06.22
2014.06.12

2014.06.13

2014.06.16

2014.06.17

2014.06.18

2014.06.21
96
Tunnel site
© Nokia Solutions and Networks 2014
Tunnel site
High Speed Train Optimization
Contention based RACH for Handover
• PRACH from contention free to contention based at HO. Because contention free uses PRB8
but contention based (Group A) uses PRB1, so contention based is more robust than
contention free.

HO SR [%] (Intra+Inter eNB) ADR [%]


99.4 4.5
Parameter change
99.2 Parameter change 4 1% improved
99 3.5
0.44% improved 3
98.8 3.09% MRBTS-
2.5
98.6 383912/LNBTS-
After : 98.80% 2 2.11%
98.4 383912/LNCEL-1
1.5
98.2 Before : 98.36% MRBTS-
1
1.35% 385859/LNBTS-
98 0.5 1.07% 385859/LNCEL-1
97.8 0
2014.06.27

2014.06.28

2014.06.30

2014.07.01

2014.07.03

2014.07.06
2014.06.26

2014.06.29

2014.07.02

2014.07.04

2014.07.05

2014.07.07

2014.06.25
2014.06.26
2014.06.27
2014.06.28
2014.06.29
2014.06.30
2014.07.01
2014.07.02
2014.07.03
2014.07.04
2014.07.05
2014.07.06
2014.07.07
2014.07.08
0.3% improved

Tunnel site Tunnel site


97 © Nokia Solutions and Networks 2014
High Speed Train Optimization
VoLTE Performance
• When high speed train enters a tunnel, VoLTE call easily fails Handover to the tunnel site
and the call sometimes drops, because RF condition dramatically changes.

HO Failure ⇒ Tunnel
Re-establishment
Drive test result or drop

98 © Nokia Solutions and Networks 2014


High Speed Train Optimization
Tunnel Site (Drive test result)

• There are many RRC Re-establishment of VoLTE call when Train goes through a tunnel
• This Re-establishment causes missing Voice, VoLTE call can not keep good quality in tunnels.

RSRP

RSRQ

RRC
Re-establishment

VoLTE Packet

99
Re-esta
© Nokia Solutions and Networks 2014
Re-esta Re-esta Re-esta
0
10
Tunnel Site (KPI)

WCDMA AMR
should be used

through a tunnel
when Train goes

© Nokia Solutions and Networks 2014


• LTE drop rate is around 38%

0
10
20
30
40
50
60

2014.11.18:06.00
2014.11.18:13.00
High Speed Train Optimization

2014.11.18:20.00
2014.11.19:09.00
2014.11.19:16.00
2014.11.19:23.00
2014.11.20:12.00
2014.11.20:19.00
2014.11.26:08.00
2014.11.26:15.00
2014.11.26:22.00
• WCDMA’s drop rate is lower than LTE in tunnel sites.

2014.11.27:11.00
2014.11.27:18.00
2014.11.28:07.00
2014.11.28:14.00
2014.11.28:21.00
2014.11.29:10.00
2014.11.29:17.00
Drop Rate (ADR) [%]

2014.11.30:06.00
2014.11.30:13.00
2014.11.30:20.00
2014.12.01:09.00
2014.12.01:16.00
LTE

2014.12.01:23.00
WCDMA

2014.12.02:12.00
Lower
drop rate
High Speed Train Optimization
Possible Design Concept
• To make UEs enter tunnels continuously without drop, our new design forces VoLTE UEs
to move to WCDMA by SRVCC in tunnel adjacent sites and tunnel sites.

Forced SRVCC to WCDMA AMR


VoLTE Tunnel
LTE

WCDMA AMR AMR

10 © Nokia Solutions and Networks 2014


1
High Speed Train Optimization
TAC Design
• In case VoLTE is launched for certain areas only the design of TAC and eNB QCI1
support needs to be as below
SRVCC to WCDMA AMR
VoLTE area VoLTE Non VoLTE area

LTE

WCDMA
AMR AMR

VoLTE ON site VoLTE OFF site VoLTE OFF site


TAC VoLTE ON TAC VoLTE OFF TAC VoLTE OFF TAC
Configuration

eNB VoLTE ON VoLTE ON VoLTE ON


Configuration

10 © Nokia Solutions and Networks 2014


2
High Speed Train Optimization

• If VoLTE is supported by the target eNB but the TAC of the target eNB does not support
VoLTE then the HO for QCI1 should go through and path switch should be possible.
Hhowever there might be differences in different vendor’s MMEs.
• Also whether the UE SIP client drops the call or not (UE sending SIP : BYE message)
when TAC without VoLTE support is detected depends on the UE implementation.
• Therefore rather SRVCC to WCDMA needs to be triggered.

10 © Nokia Solutions and Networks 2014


3
THANK YOU!

10 © Nokia Solutions and Networks 2014


4

You might also like