Chasing

milliseconds in the world of LTE

Goran Petrovic, Zoltan Va3 P3 communica3ons
Aachen, March 2014

Public

Chasing milliseconds in the world of LTE

The test setup
The test setup
During various network capability measurements, P3 communica3ons uses an ini3al PING sequence
prior to the measured service to ensure that the measurements start in dedicated mode. The same
applies for the network latency measurements, where the rst PING has a higher size followed by 5
smaller PINGs that are used for latency evalua3on.
In the current exercise, one 800 byte PING was followed by ve 40 byte PINGs issued by an
automated tool. The tool needs a few-hundred milliseconds to switch from the big PING to the small
PING. While these few-hundred milliseconds do not have impact in UMTS, in LTE it is enough to
trigger the UE to go to micro sleep state in dedicated mode.
Due to the addi3onal 28 byte long header informa3on the nal PING sizes result in 828 and 68
bytes.
Lenght Protocol
Info
828
ICMP
Echo ( ping) request i d=0x1a16, seq=1/256, ttl=128
828
ICMP
Echo ( ping) reply i d=0x1a16, seq=1/256, ttl=50
68
ICMP
Echo ( ping) request i d=0x9716, seq=1/256, ttl=128
68
ICMP
Echo ( ping) reply i d=0x9716, seq=1/256, ttl=50
68
ICMP
Echo ( ping) request i d=0xb216, seq=1/256, ttl=128
68
ICMP
Echo ( ping) reply i d=0xb216, seq=1/256, ttl=50
68
ICMP
Echo ( ping) request i d=0xc016, seq=1/256, ttl=128
68
ICMP
Echo ( ping) reply i d=0xc016, seq=1/256, ttl=50
68
ICMP
Echo ( ping) request i d=0xc616, seq=1/256, ttl=128
68
ICMP
Echo ( ping) reply i d=0xc616, seq=1/256, ttl=50
68
ICMP
Echo ( ping) request i d=0xcc16, seq=1/256, ttl=128
68
ICMP
Echo ( ping) reply i d=0xcc16, seq=1/256, ttl=50

Public

Chasing milliseconds in the world of LTE

The observa:on and goal of the exercise
Observa:on during the test result analysis
A special paXern could be observed during measurements performed in LTE: specic PINGs have
longer round trip 3mes than others. The aected packets were always the rst 40 byte PINGs a[er
the 800 byte PINGs.
The graphs show only the round trip 3mes of the 40 bytes PINGs and their cumulated distribu3on.

Goal of the exercise
The nal goal of this exercise is to iden3fy the root cause of the addi3onal delay of 55-60
milliseconds in average experienced as per the graphs above.

Public

Chasing milliseconds in the world of LTE

Analysis approach
What could be dierent for the separate PINGs of the same size?
To understand what can cause the dierence in the RTT for the separate PINGs one needs to
understand both the network parameters and the behaviour of the test device.
At this point P3 communica3ons used the synergies between the internal competence centers and
analysed the network parameters and device logs with the help of QXDM.
The available Qualcomm documents provided excellent addi3onal guidance to the engineers from
Interna3onal Benchmarking and Device Tes3ng departments.
The rst theorem vs. the real results
As LTE uses cDRX to improve the baXery consump3on of the devices, cDRX was an obvious star3ng
point for nding the solu3on.
However, the rst theorem was not in-line with the distribu3on of the test results. Even in the case
of cDRX, the expecta3on was to see a distribu3on of the round trip 3mes randomly between the
typical RTT 3me and the (Long DRX cycle + typical RTT 3me OnDura3on Timer).
The parameteriza3on of the Scheduling Request was considered as an addi3onal factor that could
cause further delays measured in a few milliseconds based on the 3ming of the IP packet arrival.

Public

Chasing milliseconds in the world of LTE

Analysis Step 1 Network Parameters
What are the parameters set for the DRX congura:on?
The RRC signalling provides the necessary MAC congura3on
parameters. The local network makes use of both short and
long DRX cycles.
The congura3on sets a rela3vely short OnDura3on 3me
which can lead to baXery live saving on one hand, but to
longer reac3on 3me on downlink packets on the other hand.
What is the Scheduling Request congura:on?
The RRC signalling also denes the SR related parameters.
For the current exercise the sr-CongIndex needs to be
observed which mandates a 10ms SR periodicity, which can
result in up to 10ms addi3onal delay based on the 3ming of
the IP packet arrival.

Public

Chasing milliseconds in the world of LTE

Analysis Step 2 Physical Layer considera:ons
What to expect on the PHY layer? Channels, :ming, etc.
As a best prac3ce, the engineers dene what needs to be taken into considera3on before the
analysis, which physical channels to focus on and what 3ming expecta3ons to set.
The following ow and numbering will guide us through the whole analysis:
1.
2.
3.
4.
5.
6.

PUCCH / Scheduling Request

PDCCH / UL Grant (DCI O)
PUSCH / UL Data transmission
PHICH / ACK/NACK decision
PDCCH / DL Data recep3on
PUCCH / ACK/NACK

Downlink
Uplink

...
1

n
2

n+8
4

...

3
n+4

Public

...
...

m
5
6
m+4

Chasing milliseconds in the world of LTE

Analysis Step 3 The layered approach I.
The route of the PING through the various layers
Following the LTE User plane protocol stack, the IP packet will bypass the following layers in the
handset: PDCP -> RLC -> MAC -> PHY
The powerful QXDM tool gives exact indica3on on all levels what happens with our PING
Below QXDM Log packets were considered during the analysis for the layers:

Layer

Log Packet ID

Log Packet Name

PDCP

0xB0B3

PDCP UL Data PDU with Ciphering

RLC

0xB092

LTE RLC UL AM All PDU

MAC

0xB064

LTE MAC UL Transport Block

0xB066

LTE MAC Buer Status

0xB173

LTE ML1 PDSCH Stat Indica3on

0xB130

LTE LL1 PDCCH Decoding Results

0xB16B

LTE LL1 PDCCH-PHICH Indica3on Report

0xB16D

LTE ML1 GM Tx Report

PHY

Public

Chasing milliseconds in the world of LTE

Analysis Step 4 The layered approach II.
Understanding the common informa:on
The excellent documenta3on for the log packets provided by Qualcomm allows one to nd a
common 3me in all layers -> the System Frame Number / Sub-Frame Number when the IP packet is
sent to the network
Taking one example for a PING experiencing longer RTT the common SFN/Sub-FN is 618/2

Public

Chasing milliseconds in the world of LTE

Analysis Step 5 Going back in :me
How to nd the right sequence on the PHY layer
With the help of QXDM, one can iden3fy the 3rd message from the PHY layer considera3ons. The
next ac3on is to iden3fy the other SFN / Sub-FN TTIs for the rest of the messaging.
Using the men3oned log packets for the physical layer separately for Uplink and Downlink one can
easily nd the TTIs for the 1st / 2nd / 4th / 5th / 6th message in the ow for the PING
Downlink

...

Uplink

1 ...
617/3

617/8
2

618/6
621/9
4 ...
5
3
618/2

...

6
622/3

50ms
Determining the same for a subsequent PING with a typical RTT shows similar PHY performance
Downlink
Uplink

626/7
...
2
1 ...
626/3

627/5
631/4
4 ...
5
3
627/1

...

6
631/8

55ms

Public

Chasing milliseconds in the world of LTE

Analysis Step 6 Intermediate conclusion
What do we see on the Physical Layer?
The results un3l now already indicate a few important facts:
1. The device respects the 10 milliseconds Scheduling Request periodicity and the Sub-FN oset
Considering 3GPP TS 36.213 Table 10.1-5 -> sr-CongIndex = ISR = 8
SR occasions: 617/3 then 626/3 -> 9x 10milliseconds; Sub-FN Oset = ISR 5 = 3 (617/3 and 626/3)

2. The rela3ons for the DL / UL interac3ons with the 4 sub-frame shi[s are used properly
3. The observed RTT dierence is not a result of Physical Layer dierences

What will be the next ac:ons?
The addi3onal delay must be visible on higher layers, hence one needs to con3nue on the MAC

Public

10

Chasing milliseconds in the world of LTE

Analysis Step 7 MAC layer analysis I.
What shall be considered on the MAC layer?
As indicated previously, the analysis on the MAC layer was limited to the UL Transport Blocks and
the Buer Status.
The Log Packet 0xB066 provides the rst valuable informa3on about the experienced delay:

The MAC layer keeps the data in the UL buer. For a PING experiencing the long RTT the data is
buered for ~70 milliseconds, whereas for a PING with typical RTT the data is buered ~15
milliseconds.

Public

11

Chasing milliseconds in the world of LTE

Analysis Step 8 MAC layer analysis II.
How long is the data buered on the MAC layer?
Going back in 3me again in the same Log Packet, one can see how long the data is buered on the
MAC layer.
For a PING experiencing the long RTT, the data is buered for approximately 70 milliseconds.
However for a PING experiencing the typical RTT, the data is kept in the buer for shorter 3me,
approximately for 15-20 milliseconds.
Considering an addi3onal 3me 0 for the data arrival in the MAC buer, the 3ming graph changes
accordingly to the below values:

Long RTT

Downlink

Uplink

...

...

0 ...
1 ...
3
611/0
617/3
618/2

Short RTT

Downlink
Uplink

...

...

0 ...
1 ...
3
625/5
626/3
627/1

As it is visible in the 3ming sequences, the Data Arrival in the MAC buer to Scheduling Request
3mes need to be checked.

Public

12

Chasing milliseconds in the world of LTE

Analysis Step 9 Correla:on to cDRX states I.
What are the cDRX states at the Data Arrival :mes?
To extract informa3on about the cDRX states, one needs to look at the Log Packet 0xB198 LTE ML1
CDRX Events Info. The log packet provides printouts of the various 3mer start and end 3mes, state
changes, and the corresponding SFN / Sub-FN numbers.
Long RTT case: Based on the informa3on provided by QXDM, the device was in its O Dura3on at
the data arrival in the MAC buer.
Next scheduled On Dura3on would have been at SFN / Sub-FN 624/2, remember the Long DRX cycle
length of 320 milliseconds. However, due to the data arrival in the MAC buer at 611/0, there was a
need to break out from the O Dura3on, which happened at 617/3.
The 3me needed to break out was 63 milliseconds.

Public

13

Chasing milliseconds in the world of LTE

Analysis Step 10 Correla:on to cDRX states II.
What are the cDRX states at the Data Arrival :mes?
Typical RTT case: Considering the same Log Packet once more, one will nd that the cDRX state is
dierent at this point.
In this case the data arrival in the MAC buer happened at 625/5. According to the informa3on
extracted from QXDM, the device was s3ll ac3ve, as the drx-Inac3vityTimer and the UL DRX-
Retransmission Timer were running.
Therefore the device could send the SR at 626/3 and the UL data at 627/1.
Here the device needed only 8 milliseconds to send the SR.
The dierence between the 2 cases exactly matches the
average Round Trip Time dierence of 55 milliseconds.

The addi2onal delay has been iden2ed successfully!!!

Public

14

Chasing milliseconds in the world of LTE

Analysis Step 11 Final conclusion
The lessons of the exercise
In the 1 millisecond TTI world of LTE where everything changes rapidly, a normal user would not
care about a few milliseconds delay. However, for device OEMs and Mobile Network Operators,
even these milliseconds are crucial to ensure proper interac3on and to meet the goals of the LTE
standard.
With the help of simple tests, QXDM, and the provided documenta3on by Qualcomm, every
engineer can follow up single data packets in the log les.
At the end of the analysis, the engineers of P3 communica3ons concluded that the experienced
dierences between the Round Trip Times of the PING of the same size is a result of:
1. Usage of cDRX almost independent of the parameteriza3on
2. The property of the automa3on tool to switch between PING sequences
3. The design of the test device and its break out performance from O Dura3on

Public

15

Authors
GORAN PETROVIC
Joined P3 communica3ons in 2007
Started as Measurement Setup and Support
Engineer
Drive Test Verica3on and Classica3on
Engineer between 2009 - 2011
Mobile Network and Service Quality Analyst
for Interna3onal Benchmarking since 2011
Member of P3 communica3ons Expert Group

ZOLTAN VATI
Joined P3 communica3ons in 2008
Started as Field Test Engineer in the Device
Tes3ng department
Joined the internal log le analysis team in
2009
Technical coordinator in Device Tes3ng since
2012
Member of P3 communica3ons Expert Group

Key exper3se:
Protocol expert of GSM/UMTS/LTE radio
layers
End to End Quality of Service analysis and
troubleshoo3ng
Strong TCP/IP protocol knowledge
MNO Strategy Evalua3on

Key exper3se:
3GPP System Selec3on
UICC-Terminal interface communica3on
Mul3-Mode (3GPP and 3GPP2) mobile
device tes3ng
GCF and various Carrier Acceptance tes3ng
Advanced user of Qualcomm Tools

Public

16

Your Contact
WEB

GERMANY - AACHEN

e-Mail: info.communica3ons@p3-group.com
Internet: www.p3-group.com

P3 communica3ons GmbH
Am Kra[versorgungsturm 3
52070 Aachen
Germany

YOUR CONTACT
Sascha Cigoj
+49 151 571 333 99
sascha.cigoj@p3-group.com

Ron Housenick
+1 973 867 8395
ron.Housenick@p3-group.com

Markus Michelt
+49 151 571 333 22
markus.michelt@p3-group.com

Vladimir Obradovic
+49 151 571 333 00
vladimir.obradovic@p3-group.com

ISCLAIMER

USA NEW JERSEY

P3 Communica3ons Inc.
412 Mt. Kemble Ave., Suite G2
Morristown, NJ 07960
USA

INDIA - MUMBAI
P3 Marquis communica3ons Pvt. Ltd
Unit No. 301, Bldg - 4, Sector - 3,
Millenium Business Park, Mahape,
Navi Mumbai - 400710
India

AUSTRALIA SYDNEY

This document contains P3 communica3ons GmbH proprietary informa3on and shall at all
3mes remain the property of P3 communica3ons GmbH. It shall be distributed and used
only by the subcontractor sta registered on the distribu3on list of this document. The
subcontractor is not allowed to copy this document without P3 communica3ons GmbH
prior wriXen consent. It shall not be used, distributed or copied by any other third part
without P3 communica3ons GmbH prior wriXen consent.

P3 communica3ons Pty Ltd

Level 20, Tower A, The Zenith Centre
821 Pacic Highway
Chatswood NSW 2067


Public

17