chasing milliseconds lte qualcomm p3 comm

Chasing milliseconds in the world of LTE

Public

Goran Petrovic, Zoltan Va3 – P3 communica3ons

Aachen, March 2014

Public

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 first 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 five 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 final PING sizes result in 828 and 68 bytes.


Lenght Protocol Info828 ICMP Echo (ping) request id=0x1a16, seq=1/256, ttl=128828 ICMP Echo (ping) reply id=0x1a16, seq=1/256, ttl=5068 ICMP Echo (ping) request id=0x9716, seq=1/256, ttl=12868 ICMP Echo (ping) reply id=0x9716, seq=1/256, ttl=5068 ICMP Echo (ping) request id=0xb216, seq=1/256, ttl=12868 ICMP Echo (ping) reply id=0xb216, seq=1/256, ttl=5068 ICMP Echo (ping) request id=0xc016, seq=1/256, ttl=12868 ICMP Echo (ping) reply id=0xc016, seq=1/256, ttl=5068 ICMP Echo (ping) request id=0xc616, seq=1/256, ttl=12868 ICMP Echo (ping) reply id=0xc616, seq=1/256, ttl=5068 ICMP Echo (ping) request id=0xcc16, seq=1/256, ttl=12868 ICMP Echo (ping) reply id=0xcc16, seq=1/256, ttl=50

2

Public

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: specific PINGs have longer round trip 3mes than others. The affected packets were always the first 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 final 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.


3

Public

Analysis approach

What could be different for the separate PINGs of the same size? §  To understand what can cause the difference 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 first theorem vs. the real results §  As LTE uses cDRX to improve the baXery consump3on of the devices, cDRX was an obvious star3ng point for finding the solu3on.

§  However, the first 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.


4

Public

Analysis Step 1 – Network Parameters

What are the parameters set for the DRX configura:on? §  The RRC signalling provides the necessary MAC configura3on parameters. The local network makes use of both short and long DRX cycles.

§  The configura3on 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 configura:on? §  The RRC signalling also defines the SR related parameters. §  For the current exercise the sr-‐ConfigIndex 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.


5

Public

Analysis Step 2 – Physical Layer considera:ons

What to expect on the PHY layer? Channels, :ming, etc. §  As a best prac3ce, the engineers define what needs to be taken into considera3on before the analysis, which physical channels to focus on and what 3ming expecta3ons to set.

§  The following flow and numbering will guide us through the whole analysis:

1.  PUCCH / Scheduling Request 2.  PDCCH / UL Grant (DCI O) 3.  PUSCH / UL Data transmission 4.  PHICH / ACK/NACK decision 5.  PDCCH / DL Data recep3on 6.  PUCCH / ACK/NACK


n n+8 mDownlink ... 2 4 ... 5

Uplink 1 ... 3 ... 6n+4 m+4

6

Public

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 Buffer Status

PHY 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

7

Public

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 find 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


8

Public

Analysis Step 5 – Going back in :me

How to find 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 find the TTIs for the 1st / 2nd / 4th / 5th / 6th message in the flow for the PING

§  Determining the same for a subsequent PING with a typical RTT shows similar PHY performance


617/8 618/6 621/9Downlink ... 2 4 ... 5

Uplink 1 ... 3 ... 6617/3 618/2 622/3

626/7 627/5 631/4Downlink ... 2 4 ... 5

Uplink 1 ... 3 ... 6626/3 627/1 631/8

50ms

55ms

9

Public

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 offset Considering 3GPP TS 36.213 Table 10.1-‐5 -‐> sr-‐ConfigIndex = ISR = 8 SR occasions: 617/3 then 626/3 -‐> 9x 10milliseconds; Sub-‐FN Offset = 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 difference is not a result of Physical Layer differences

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


10

Public

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 Buffer Status.

§  The Log Packet 0xB066 provides the first valuable informa3on about the experienced delay:

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


11

Public

Analysis Step 8 – MAC layer analysis II.

How long is the data buffered on the MAC layer? §  Going back in 3me again in the same Log Packet, one can see how long the data is buffered on the MAC layer.

§  For a PING experiencing the long RTT, the data is buffered for approximately 70 milliseconds. §  However for a PING experiencing the typical RTT, the data is kept in the buffer for shorter 3me, approximately for 15-‐20 milliseconds.

§  Considering an addi3onal 3me “0” for the data arrival in the MAC buffer, the 3ming graph changes accordingly to the below values:

§  Long RTT Short RTT

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


Downlink ... ...

Uplink 0 ... 1 ... 3625/5 626/3 627/1

Downlink ... ...

Uplink 0 ... 1 ... 3611/0 617/3 618/2

12

Public

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 Off Dura3on at the data arrival in the MAC buffer.

§  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 buffer at 611/0, there was a need to “break out” from the Off Dura3on, which happened at 617/3.

§  The 3me needed to “break out” was 63 milliseconds.


13

Public

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 find that the cDRX state is different at this point.

§  In this case the data arrival in the MAC buffer 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 difference between the 2 cases exactly matches the average Round Trip Time difference of 55 milliseconds. §  The addi2onal delay has been iden2fied successfully!!!


14

Public

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 files.

§  At the end of the analysis, the engineers of P3 communica3ons concluded that the experienced differences 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 Off Dura3on


15

Public 16

Authors

§  Joined P3 communica3ons in 2007 §  Started as Measurement Setup and Support Engineer

§  Drive Test Verifica3on and Classifica3on Engineer between 2009 -‐ 2011

§  Mobile Network and Service Quality Analyst for Interna3onal Benchmarking since 2011

§  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

GORAN PETROVIC §  Joined P3 communica3ons in 2008 §  Started as Field Test Engineer in the Device Tes3ng department

§  Joined the internal log file analysis team in 2009

§  Technical coordinator in Device Tes3ng since 2012

§  Member of P3 communica3ons Expert Group

§  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

ZOLTAN VATI

Your Contact

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

WEB

DISCLAIMER 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 staff 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.

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

GERMANY -‐ AACHEN P3 communica3ons GmbH Am Kra[versorgungsturm 3 52070 Aachen Germany

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 P3 communica3ons Pty Ltd Level 20, Tower A, The Zenith Centre 821 Pacific Highway Chatswood NSW 2067

Public 17

chasing milliseconds lte qualcomm p3 comm

Documents