Round Trip Time

End-to-End Analysis
 Introduction

• Network performance analysis has identified spurious unexpectedly high results

from Round Trip Time measurements
• Investigations have been completed to identify the reason for these high results

spurious high result

Round Trip Time (ms)

PING number

2
 Logging Strategy

• The Round Trip Time to the application server was recorded from:
• UE: UE -> server -> UE
• eNode B transport interface: eNode B -> server -> eNode B
• Packet Gateway transport interface PGW -> server -> PGW

• A combination of logging tools were used to record the Round Trip Times

Application
SGW / PGW Internet
UE Server
eNode B
LTE Server
109.123.85.36
XCAL / XCAP Wireshark IRIS
Logging Logging Logging

3
 Cell Load

• The following results were recorded during the morning rush hour at:
• CSR 039384 New Slough West MRBTS 500319
• The number of RRC connections within the cell peaked at 114

Results Results Results Results

Set 1 Set 2 Set 3 Set 4
RRC Users

4
 Results – Set 1

• Round trip time measured at the UE has greater variance than that measured
within the network
• Some of this variance originates from the 20 ms Scheduling Request period
Round Trip Time (ms)

Variance generated by 20 ms
Scheduling Request period

PING number LOG 6

5
 Results – Set 2

• Similar results from second set of measurements

Round Trip Time (ms)

Variance generated by 20 ms
Scheduling Request period

PING number
LOG 5

6
 Results – Set 3

• Similar results from third set of measurements

Round Trip Time (ms)

Variance generated by 20 ms
Scheduling Request period

PING number
LOG 4

7
 Results – Set 4

• Similar results from forth set of measurements

Round Trip Time (ms)

Variance generated by 20 ms
Scheduling Request period

PING number
LOG 3

8
 PING – Detailed Analysis (I)

• The ICMP layer completes a PING Request

2-way handshake for each
PING HARQ Ack
• Uplink and downlink RLC Ack
messages are acknowledged
at both the MAC and RLC HARQ Ack
layers
• Means that both the PING
Request and PING PING Response
Response messages have
associated uplink and HARQ Ack
downlink transmissions
RLC Ack

HARQ Ack

9
 PING – Detailed Analysis (II)

• RLC layer time stamps illustrate the pattern of some PING taking longer to complete
• Examples below show illustrate 2 fast PING and 2 slower PING

10
 PING – Detailed Analysis (III)

• Scheduling Request and Proactive Scheduling patterns for the same 4 PING are
shown below

PING Req
49 ms 51 ms 116 ms 73 ms

RLC Ack

PING Response

RLC Ack

1 Scheduling Request 2 Scheduling Requests

Proactive Proactive
Scheduling Scheduling

11
 Impact of 2nd Scheduling Request

• The second Scheduling Request increases the variance in PING performance from
+/- 10 ms to +/- 20 ms
Round Trip Time (ms)

Variance generated by two

20 ms Scheduling Request
periods

PING number
 Spike Analysis (I)

• Further analysis completed specifically for large Round Trip Time spikes
 Spike Analysis (II)

• Analysis indicates that PING Request required 14 transmissions before successful

reception: 14 transmissions consume 14 × 8 = 112 ms
• does not fully account for RTT of 278 ms
• RLC acknowledgement for PING Response also requires uplink re-transmissions

RTT of 278 ms

HARQ re-transmissions
HARQ re-transmissions
for RLC re-transmission
for RLC original
transmission

RLC original RLC re-transmission

transmission (same sequence number)
 Spike Analysis (III)

• Downlink behaviour is also different for PING with very long RTT
• potentially caused by uplink acknowledgement not received by eNode B

RLC Ack transmitted twice

Dual stream transmission for Single stream transmission for
RLC Ack for PING Request PING Response

RLC Ack for

PING Request
PING Request
 Conclusions

• When Proactive Scheduling is not active, the requirement for a second Scheduling
Request increases the PING performance variance to +/- 20 ms, i.e. there can be
40 ms difference between a fast PING and a slower PING
• This explains the relatively large variance observed from the UE perspective

• The spurious high spikes in RTT are caused by uplink air-interface reception
becoming very poor:
• high number of re-transmissions at both the HARQ and RLC layers for uplink
data transfer
• reception of uplink acknowledgements for downlink data failed
EPG Comparison
 Results per EPG

• PING testing was completed using a range of EPG

• multiple sets of 1000 PING towards each EPG
• Allocated EPG was observed to change between Attach procedures
• Average round trips times for each EPG are shown below

EPG RTT Set 1 RTT Set 2 RTT Set 3

FAR 56.7 ms 56.8 ms -
GLB 90.1 ms 76.5 ms 57.2 ms
RCN 67.2 ms 68.7 ms -
YAT 74.8 ms 70.1 ms -
HLW 56.1 ms 56.2 ms -
 Logging Strategy

• The Round Trip Time to the application server was recorded from:
• UE: UE -> server -> UE
• Packet Gateway transport interface PGW -> server -> PGW

• A combination of logging tools were used to record the Round Trip Times

Application
SGW / PGW Internet
UE Server
eNode B
LTE Server
109.123.85.36
XCAL / XCAP IRIS
Logging Logging

19
 FAR EPG

• Results from the FAR EPG

Round Trip Time (ms)

PING number
 GLB EPG

• Results from the GLB EPG

 RCN EPG

• Results from the RCN EPG

 YAT EPG

• Results from the YAT EPG

 HLW EPG

• Results from the HLW EPG

 Conclusions

• It has been observed that PING Round Trip Times (RTT):

• depend upon the EPG selected
• in the case of the GLB EPG
• the RTT varied between sets of PING to the same EPG
Telefonica / Vodafone
Comparison
 Introduction

• Measurements have indicated that Vodafone has a round trip time which is faster
than Telefonica
• common eNode B but different core networks
• Measurements were recorded from the UE and BTS to help isolate the cause of
the increased round trip time

TEF
SGW / PGW
TEF UE

VF Application
VF UE Internet
SGW / PGW Server
TEF and VF
eNode B LTE Server
109.123.85.36
XCAL / XCAP Wireshark
Logging Logging
 UE to Application Server

• Telefonica round trips times were measured to be ~ 20 ms higher than Vodafone

round trip times
 BTS to Application Server

• Round trip times were measured at the transport side of the BTS, i.e. excluding the
impact of the air-interface
• Telefonica round trips times were measured to be ~ 20 ms higher than Vodafone
round trip times
 Component of RTT between UE and BTS

• Both Telefonica and Vodafone have similar delays between the BTS and UE
• Calculated as the total Round Trip Time – Round Trip Time from BTS transport
interface to application server
 Conclusions

• Telefonica total Round Trip Time has been measured to be 20 ms greater than the
Vodafone Round Trip Time
• Results indicate that this is not caused by the air-interface nor BTS as both
operators have similar delays between UE and BTS transport interface
Operator Comparison
 Round Trip Times

• ‘3’ has the best

round trip time
performance in
terms of both mean
and standard
deviation
• See next slide for
parameters
associated with
each operator

Round Trip Time (ms)

VF Slough VF Slough VF London TEF Slough TEF Slough TEF London 3 EE

(RL70) (RL50) South (RL70) (RL50) South Slough Slough
Mean (ms) 55.4 87.8 81.9 66.4 64.2 112.0 36.7 75.6

Standard Deviation (ms) 10.9 20.7 13.0 15.3 14.0 14.9 5.7 19.3
 Configuration Comparison

• ‘3’ minimises round trip time by disabling DRX and by having a 10 ms Scheduling
Request period

Scheduling Proactive DRX Short DRX Long DRX

Request Scheduling Cycles Cycles Inactivity
Period
TEF Operated Site 20 ms Enabled 40 ms x 5 80 ms 10 ms
TEF Cell, Slough (RL70)
TEF Operated Site 20 ms Enabled 40 ms x 5 80 ms 10 ms
VF Cell, Slough (RL70)
TEF Operated Site 20 ms Disabled 40 ms x 5 80 ms 10 ms
TEF Cell, Slough (RL50)
TEF Operated Site 20 ms Disabled 40 ms x 5 80 ms 10 ms
VF Cell, Slough (RL50)
VF Operated Site 10 ms No Evidence 80 ms x 1 320 ms 100 ms
TEF Cell, London South
VF Operated Site 10 ms No Evidence 80 ms x 1 320 ms 100 ms
VF Cell, London South
3, Slough 10 ms No Evidence DRX Disabled

EE, Slough 20 ms No Evidence 80 ms x 2 320 ms 100 ms

 Analysis – Current
• 2 Scheduling Requests generate up to 40 ms of delay
• UE entering DRX generates up to 40 ms of delay
• Total potential variable delay = 80 ms
BTS PING
PDCP RESP Up to 40 ms

BTS RLC
RLC ACK

BTS Res. HARQ Res. HARQ

PHYS Alloc ACK Alloc ACK
up to up to
20 ms 20 ms
UE HARQ UE DRX HARQ
SR SR
PHYS ACK SLEEP ACK

UE RLC
RLC ACK

UE PING
PDCP REQ

Measured Round Trip Time

 Analysis – Minimised Latency
• 2 Scheduling Requests generate up to 20 ms of delay
• No DRX used (or increased DRX inactivity timer)
• Total potential variable delay = 20 ms
BTS PING
PDCP RESP

BTS RLC
RLC ACK

BTS Res. HARQ Res. HARQ

PHYS Alloc ACK Alloc ACK
up to up to
10 ms 10 ms
UE HARQ HARQ
SR SR
PHYS ACK ACK

UE RLC
RLC ACK

UE PING
PDCP REQ

Measured Round Trip Time

 Impact of Scheduling Request Reduction

• Reducing the Scheduling Request period from 20 ms to 10 ms will increase the

PUCCH resource allocation from 6 Resource Blocks to 8 Resource Blocks
• This will decrease the Resource Blocks available to the PUSCH from 44 to 42, i.e.
reduction of ~ 5 %
• PUCCH PUCCH Format 2, 2a, 2b cqiPerNp 40 ms
resource actDrx True
block
Cyclic Shifts 6
allocation can
Resource Blocks 2
be kept at 6 if
delta- PUCCH Format 1 cellSrPeriod 20 ms 10 ms 10 ms
PucchShift is deltaPucchShift 2 2 1
reduced to 1 Resource Blocks 1 2 1
but may
PUCCH Format 1a, 1b phichRes 1/6
impact
maxNrSymPdcch 3
PUCCH
performance Resource Blocks 3

TOTAL RESOURCE BLOCKS 6 8 6

Performance Improvement
 Parameter Changes

• The Bath Road site (CSR 040635 MRBTS 500749) was temporarily reconfigured to
minimum air-interface latency
• Objective to demonstrate what can be achieved if low latency is prioritised over UE
battery life and network capacity
• Changes are shown in table below

Scheduling period reduced

Default Low Latency
cellSrPeriod 20 ms 10 ms Proactive Scheduling
ilReacTimerUl 5 ms 200 ms
enabled for user plane data

drxProfileIndex 3 1
DRX disabled
 Results (I)

• EPG with relatively low latency show

an improvement of ~ 20 ms
• CDF becomes steeper due to
reduced variance
Averages
65.0 ms -> 47.5 ms
17.5 ms reduction

Averages
81.6 ms -> 59.5 ms
22.1 ms reduction
Averages
77.4 ms -> 56.4 ms
21.0 ms reduction
 Results (II)

• EPG with larger latency show an

improvement of ~ 40 ms
• Increased scope for improvement
when core network delay is large
Averages
because UE is more likely to be in 108.8 ms -> 66.8 ms
DRX and PING RESPONSE arrives 42 ms reduction
at the eNode B

Averages
99.9 ms -> 57.8 ms
42.1 ms reduction
 DRX Analysis

Croydon EPG
• UE log file illustrates that (default parameters)
UE enters DRX ‘sleep’
mode between the PING
REQUEST and PING
RESPONSE when core
network delay is relatively
large
• Once UE is in DRX ‘sleep’
mode then latency is
Glasgow EPG
increased by requirement (default parameters)
to wait for UE to become
DRX ‘active’

UE enters DRX ‘sleep’ mode

between PING REQUEST
and PING RESPONSE
 Scheduling Request Analysis

• UE log file illustrates that Glasgow EPG

(default parameters)
even though Proactive
Scheduling is enabled with
ilReacTimer = 200 ms, the
UE continues to transmit 2
Scheduling Request for
each PING
• Discovered that Proactive
Scheduling is not applied
when DRX is switched off Glasgow EPG
(low latency parameters)
• Thus further improvement
could be achieved by
enabling both DRX and
Proactive Scheduling
 Operator Comparison

• Croydon is the EPG providing the lowest latency results

• With the low latency parameter set, the latency remains ~10 ms greater than that
achieved on the 3 network
• Expected that a further 5 ms reduction can be achieved by enabling both DRX and
Proactive Scheduling
Performance Improvement II
 Parameter Changes

• All cells within TAC 4288 had the parameter changes shown below applied
• Expected benefit in terms of Round Trip Time:
• Scheduling Request for PING REQUEST
• average delay reduced from 10 ms to 5 ms
Total gain of
• Scheduling Request for RLC ACK to PING RESPONSE
21 ms
• average delay reduced from 10 ms to 0 ms
• plus scheduling delay of ~6 ms reduced to 0 ms
• Expected negative impact upon uplink throughput performance

Scheduling period reduced

Pre Post
cellSrPeriod 20 ms 10 ms Proactive Scheduling
ilReacTimerUl 5 ms 50 ms
enabled for user plane data
 Round Trip Time Benefit (I)

• Both RCN and CRX EPG demonstrate the expected gain of ~ 21 ms

Averages Averages
67.1 ms -> 65.9 ms 65.9 ms -> 44.4 ms
20.9 ms reduction 21.5 ms reduction

Average
PING
RTT

EPG
 Round Trip Time Benefit (II)

• Both YATE and ELL EPG demonstrate unexpected trends in their performance

Averages Averages
66.9 ms -> 72.0 ms 52.4 ms -> 44.4 ms
5.1 ms increase 8 ms reduction

Average
PING
RTT

EPG
 Uplink Throughput Reduction

• Uplink throughput reduced by 33 %

• Majority of reduction caused by proactive scheduling
Uplink Throughput (kbps)

1200 kbps

800 kbps