LTE Messaging Analysis and Performance Optimization PDF

Course 508
LTE Messaging Analysis

and Performance Optimization
DOWNLOAD THIS COURSE:

http://scottbaxter.com/508.pdf
September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 1

Course Outline
 Introduction to LTE Performance Optimization

 LTE Quick Refresher – Core Network and Air Interface
 LTE System Statistics and Operational Measurements
 LTE Field Data Examples
 LTE Key Performance Indicators
 Practical Considerations for LTE Performance
Measurements
 LTE RAN Optimization Field Tools
 LTE Core Network Monitoring and Optimization Tools
 Examining LTE Message and Event Records

Introduction to
LTE Performance Optimization

Performance Optimization Perspective
 LTE is a complex marriage of advanced radio technology with

high-speed TCP/IP
• The LTE Radio Access Network (RAN), although more resilient
than earlier technologies, is still vulnerable to impairments from
RF causes
• The LTE Core Network, although more effectively structured
than in earlier wireless systems, still requires solid planning
and configuration and is vulnerable to the normal range of
issues faced by all TCP/IP systems
 Performance impairments are normally perceived by the end user
of data services in a TCP/IP data context, whether resulting from
RAN, Core Network, or external TCP/IP factors.
• Many problem symptoms are hard to identify as RAN, Core, or
external in origin
 The monitoring and investigative tools for identifying and resolving
problems are quite different for the RAN and the Core network

Types of LTE Performance Testing
 To most closely understand a user’s experience on the network,

and to benchmark overall performance, end-to-end (“E2E”) testing
is often the initial method used
• Measure date performance from user terminal to test server, or
from user-terminal to user-terminal
• Basic testing of latency and throughput can be performed with
user-level tools readily available on app stores and general
TCP/IP utilities
• More detailed results and organized benchmarking are
available from commercial tools which connect to user
terminals to other-end servers for more advanced test
capabilities
 When problems or performance issues appear in end-to-end
testing, more specific RAN and Core Network tools are then used
to drill down for problem location and root cause analysis

Optimization Questions We Aim to Answer:
 How are eNodeB counters used to monitor the performance of the

LTE network?
 How are these counters collected and stored?
 What are the Key Performance Indicators (KPI) for the LTE
network?
 What are the parameters that influence these KPIs?
 What is contained in LTE Cell and UE Trace and how are they
handled by the available tools?

LTE Quick Review

The Evolved Packet System and the
Evolved Packet Core
E-UTRAN
eNB
Inter-cell RMM
RB Control EPC
Connection Mobility Ctrl
MME
Radio Admission Ctrl.
NAS Security
eNB Measurement
Config. & Provision
Idle State Mobility
Dynamic Resource Handling
Allocation (scheduler)
EPS Bearer
Control
RRC
PDCP
S-GW P-GW
RLC
Mobility UE IP Address
Anchoring Allocation
MAC Internet
S1
PHY Packet Filtering

Network Functional Elements
(eNB; MME; Anchors/Gateways, PCRF; HSS)
Legacy GSM radio Networks
GERAN Gb
Policy and Charging Rules Function
SGSN GPRS CORE PCRF

UTRAN Iu S7 Rx+
S3 S4
S5b
Home Subscriber Server
S5a
WCDMA /HSPA radio Networks “Super HLR”
Ref Pt.
Mobility Management Entity S6a HSS
User Plane Entity
S1 SGi Operator’s
Evolved MME 3GPP SAE IP Services
RAN: eNB Ref Pt. UPE Anchor Anchor
LTE radio Inter Access System Anchor IASA
Networks
Uu Evolved Packet Core

S2a S2b,c
1xRTT, CDMA2000, Non-3GPP WLAN 3GPP
EV-DO networks
IP access IP access

Long-Term Evolution Protocol Family
 How much do you remember about each of these protocols?

• What does it do?
• Where in the network is it used?
• What types of symptoms and failures could it cause?
 S1AP
 PDCP-LTE
 GTPv2
 X2AP
 NAS-EPS
 LTE RRC
 RLC-LTE
 MAC-LTE

Physical channels and signals - recap

Downlink Physical Signals and Channels
 Downlink Physical Signals

• Reference Signals
• Synchronisation Signals
 Downlink Physical Channels
• Physical Broadcast Channel (PBCH)
• Physical Downlink Shared Channel (PDSCH)
• Physical Downlink Control Channel (PDCCH)
• Physical Control Format Indicator Channel (PCFICH)
• Physical Hybrid-ARQ Indicator Channel (PHICH)
• Physical Multicast Channel (PMCH)

Overview – Control Information

Resource Block

Physical Layer Downlink Summary

Reference Signals: OFDMA Channel Estimation

UL Channels
 The mapping of transport channels and UL control information

(UCI) to physical channels is a task of the physical layer (PHY).
Furthermore reference signals are provided by the physical layer
which do not transfer any higher layer information.
 Logical channel mapping is provided by the MAC layer.
 Physical channel for data and signaling from higher layers:
• Physical Uplink Shared Channel, PUSCH.
• Physical Random Access Channel, PRACH.
 Physical channels with UL control - related signaling:
• Physical Uplink Control Channel, PUCCH. and signals with no
information of higher layers:
• Demodulation Reference Signals (DRS).
• Sounding Reference Signal (SRS).

UE Channel state information (CSI)
feedback types in LTE

PDCCH Uplink Grant
 The eNodeB allocates the Uplink resources to the UEs by sending
an UL Grant
UL Grant contents
•Resource Block assignment
–Indicates the PRB the UE may use for transmission
–Signaling format: index of starting PRB & number of contiguous
PRBs
•Modulation and Coding Scheme and the Redundancy version (5
bits)
•Power control command (2 bits)
•Cyclic Shift for the demodulation reference symbols
•CQI request flag
•PUSCH Hopping flag
•New data indicator
TDD specific
•UL index (indicates which UL subframe the grant refers to)
•Downlink assignment index

LTE Key Performance Indicators:
Radio Quality Measurements

Radio Quality Measurements
 A set of radio quality

measurements are
specified by 3GPP
36.214, “E-UTRA
Physical Layer
Measurements”
 Some are measured
by the eNB, and
some by the UE
 eNB vendors have some leeway in how they handle these
measurements using their own proprietary implementations, since
measurement reports for the S1 interface are not standardized.
 Usually the E-UTRAN measurement results will be sent to the
OMC via proprietary O&M interfaces.
 Radio quality is measurable on both UL and DL.
 On UL, the only parameter sent by the UE using a RRC
measurement report is the UE Tx power
Radio Quality Measurements (continued)
 The eNodeB can provide these measurements:

• Received Interference Power (RIP): the UL noise floor for a
set of UL resource blocks.
• Thermal noise power: This is the UL receive power for the
entire UL frequency bandwidth without any signals present
• Timing advance: This is the time it takes for the radio signal to
travel from the UE to the eNB’s receiver across the radio
interface. Thus, it is proportional to the distance between the
UE and the eNodeB.
 An scanning receiver or air interface analyzer can also provide:
• Channel baseband power: This is the power of a particular
physical channel in the time domain
• I/Q constellation diagrams: Indicate the quality/accuracy of
the modulated symbols received.
• Error vector magnitude: A measurement of how far “off” the
actual symbols are from their correct positions in the
constellation.
LTE Measurement: RSSI
LTE Carrier Received Signal Strength Indicator (RSSI)

 Definition: The total received wideband power observed by the UE
from all sources, including co-channel serving and non-serving
cells, adjacent channel interference and thermal noise within the
bandwidth of the whole LTE signal.
 Uses: LTE carrier RSSI is not used as a measurement by itself,
but as an input to the LTE RSRQ measurement.
LTE Downlink

LTE Measurement: RSRP
LTE Reference Signal Received

Power (RSRP)
 Definition: RSRP is the linear
average power of the
Resource Elements (REs)
carrying a specific cell’s RS
within the considered
measurement frequency
bandwidth.
 Uses: Ranking cells for
reselection and handoff.
 Notes: Normally based on the
RS of the first antenna port, but
the RS on the second antenna
port can also be used if known
to be transmitted.

RSRP UE Measurements: RSRP
dB
-50 RSRP is a measure of cell
downlink coverage
-60 • When triggered, the
UE sends RRC
-70 measurement reports
including RSRP,
-80 which is defined from
−140 to −44 dBm with
-90 1 dB resolution.
 UEs use RSRP to choose the best cell for access or handover.
-100  RSRP correlates with user plane QoS. Outdoor expectations:
• RSRP > −75 dBm gives excellent QoS.
-110
• RSRP between −75 and −95 dBm gives a slight degradation of the
QoS. Throughput declines by 30–50% between -75 and −95 dBm.
-120
• RSRP < −95 dBm gives unacceptable QoS. Throughput reaches
zero at approximately −108 to −100 dBm. Call drops will occur.
-130
• In-House cells often give usable QoS with RSRP down to
−115dBm, due to lower in-house interference levels
-140
RSSI and RSRP
 RSSI = wideband power= noise + serving cell power + interference

power
 Without noise and interference, 100% DL PRB activity:
RSSI=12*N*RSRP
• RSRP is the received power of 1 RE (3GPP definition) average
of power levels received across all Reference Signal symbols
within the considered measurement frequency bandwidth
• RSSI is measured over the entire bandwidth
• N: number of RBs across the RSSI is measured and depends
on the BW
 Based on the above, under full load and high SNR:
RSRP (dBm)= RSSI (dBm) -10*log (12*N)

LTE Measurement: RSRQ
RB RB RB RB RB RB RB RB RB RB RB RB
 LTE Reference Signal Received Quality (RSRQ)

 Definition: RSRQ = N · RSRP / RSSI
• N is the number of Resource Blocks (RBs) of the LTE carrier
RSSI measurement bandwidth. Since RSRQ exists in only one
or a few resource blocks, and RSSI is measured over the
whole width of the LTE signal, RSRQ must be “scaled up” for a
fair apples-to-apples comparison with RSSI.
 Uses: Mainly to rank different LTE cells for handover and cell
reselection decisions
 Notes: The reporting range of RSRQ is defined from −19.5 to −3
dB with 0.5 dB resolution. -9 and above are good values.
UE Measurements: RSRQ
 Like RSRP, RSRQ is used to determine the best cell for LTE radio
connection at a certain geographic location. However, while RSRP
is the absolute strength of the reference radio signals, RSRQ is the
signal-to-noise ratio. Like RSRP, RSRQ can be used as the
criterion for initial cell selection or handover. RSRQ is calculated by
the formula above.
 The following page shows how RSRP and RSRQ vary in the
outdoor environment due to varying propagation loss and
interference of various types.
RSRQ More RSRQ Details
dB -3
-4  The reporting range of RSRQ is defined from −19.5 to −3 dB
-5
with 0.5 dB resolution
-6  Comparing measured values of RSRQ and RSRP at one
-7
location will show whether coverage or interference problems
are present.
-8
-9 • If RSRP remains stable or gets better, but RSRQ is
declining, this indicates rising interference.
-10
-11 • If both RSRP and RSRQ decline, coverage is weak.
-12  This kind of logic helps in finding the root cause of drops due
-13 to radio problems.
-14  Three quality ranges can be defined for RSRQ:
-15 • RSRQ values above −9 dB give the best subscriber
-16 experience.
-17 • RSRQ of −9 to −12 dB degrades QoS, but with fair results.
-18 • RSRQ values of −13 dB and lower give reduced
-19 throughput and a risk of call drops.
RSRQ-RSRP Interactions in the Field

SNR: RSRP vs. Noise
in an Interference-free “Fairyland”
 SNR (Signal to Noise Ratio) is a comparison of RSRP to only the internal
noise of a UE receiver, with no external interference
 It’s a measure of the best-possible performance of a UE at a given RSRP
 RSRP is measured for the bandwidth of a single subcarrier
 Noise power is measured likewise for the bandwidth of a single subcarrier
• noisepower_for_15KHz= -125.2dBm
• Noise figure = 7 dB
• Temperature = 290 K

SINR: LTE Signal vs. Noise And Interference
 SINR is a more practical measure of signal quality than SNR

 It is not defined in the 3GPP specs but rather by UE vendor. It is
not reported to the network.
 SINR is popular with operators since it better quantifies the
relationship between RF conditions and throughput
• Most UEs use SINR to calculate the CQI (Channel Quality
Indicator) they report to the network
 The components of the SINR calculation are:
• S: the power of measured usable signals, such as Reference
signals (RS) and physical downlink shared channels (PDSCHs)
• I: the power of measured interference from other cells in the
current system
• N: background noise power
 SINR can be defined as Wideband or Narrowband (for specific
subcarriers or a specific resource element)
•
How RSRQ and SINR Relate
 Cell traffic load influences RSRQ, but not SINR
 To “map” RSRQ vs. SINR, RE/RB is an important factor
• Used Resource Elements per Resource Block (in serving cell)

Power Headroom
 Power Headroom (PH), in dB, is the
difference between current UE PUSCH
transmit power and the UE’s maximum
capable power output
• it’s how much extra transmit power the
UE has left in reserve to be used in case
uplink conditions worsen
 PH reports can be sent either event-
triggered or periodically. The most common
trigger is a path loss change higher than a
predefined value when a timer expires.
Otherwise, periodic PH reporting starts when
the PH measurement task is configured or
reconfigured.
 UE PH reports are sent in MAC, not RRC.
 The eNB can set UE’s maximum transmit
power by the P-max parameter in RRC.
• PH runs from −23 to +40 dB. The 64
values correspond to 6 bits of the PH
control element in the MAC.
“Signatures” of Common LTE Conditions
 In a good LTE call, SIGNATURE:

GOOD CALL
• RSSI and RSRP will be well
above their respective noise RSSI RSRP RSRQ SINR Headroom
-50
floors -30 -3 +40 +40
-40 -60
• RSRQ will be -9 or stronger -50 -70 -6 +30 +30
• SINR will be +20 or stronger -60 -80

-9 +20 +20
-70 --90
• Headroom will be around or -80 -110 -12 +10 +10
better than +10 --90 -120

0 0
-15
-10 -10
-110 -130
-120 -140 -19.5 -23 -23
RSSI RSRP RSRQ SINR Headroom
UE
eNB Messaging
September, 2013 508 v2.0 (c) 2013 Scott Baxter 508 - 39

Signature of LTE Dropped Call in Poor Coverage
SIGNATURE:
 In bad coverage, poor RF DROPPED CALL, BAD COVERAGE
conditions will lead to call drops
 RSSI will be around the noise -30 -50 +40 +40
-3
floor, -115 or weaker -40 -60
 RSRP will be around or below -50 -70 -6 +30 +30
its noise floor, -135 or weaker -60 -80 +20 +20

-9
 RSRQ will be -12 or weaker -70 --90
+10 +10
-110 -12
 SINR will be below 0 -80
0 0
--90 -120
 Headroom will be well below 0 -130
-15
-10 -10
-110
-120 -140 -19.5 -23 -23
BTS Messaging

Signature of LTE Downlink Interference
SIGNATURE:
 In forward link interference, all the
FORWARD LINK INTERFERENCE
forward link indicators will be poor:
• RSSI will be normal, but its RSSI RSRP RSRQ SINR Headroom
-50
strength comes from the strong -30 -3 +40 +40
included interference -40 -60

+30 +30
-70 -6
-50
• RSRP will be lower than
-60 -80 +20
expected compared to RSRP -9 +20
-70 --90
• RSRQ will be lower than -80 -110 -12 +10 +10
normal, well below -9 --90 -120

0 0
-15
• SINR will be lower than normal, -110 -130
-10 -10
around 0 -120 -140 -19.5 -23 -23
 The uplink-related “Headroom” RSSI RSRP RSRQ SINR Headroom

measurement is independent of
downlink conditions; its current BTS Messaging
value isn’t affected by downlink
interference
Signature of LTE Uplink Interference
SIGNATURE:
 In LTE Uplink interference makes
REVERSE LINK INTERFERENCE
the UE transmit at higher power
trying to compensate RSSI RSRP RSRQ SINR Headroom
-50
• UE power Headroom will be -30 -3 +40 +40
driven down, even to 0 or -40 -60

+30 +30
-6
below in serious cases -50 -70
-60 -80 +20

 The Downlink indicators RSSI, -9 +20
-70 --90
RSRP, RSRQ, and SINR aren’t -12 +10 +10
-80 -110
directly affected by Uplink 0 0
-120
interference --90
-15
-10 -10
-110 -130
• Their values will be consistent -140 -19.5 -23 -23
-120
with whatever is happening on
the downlink at that moment
BTS Messaging

Modulation Quality:
I/Q Constellations and EVM
 I/Q constellation diagrams and EVM measurements are available

for UL and DL physical channels and a separate measurement for
each type of physical channel in the cell.
 To measure the DL quality the air interface tester must be used as
a kind of drive test device and cannot remain connected to the
CPRI of the eNB.
 Also for the DL quality, a set of measurement tasks is performed
by the UE (see Figure 4.17).
 Drive test equipment will perform the same measurement jobs but
store the measurement results in its log files with higher granularity
(typical time granularity for reference signal measurements: 1
second) and correlated with the true GPS location of the
geographic measurement point.
 Regular subscriber handsets will send RRC measurement reports
with reference signal measurements only in event-triggered mode,
which means only if a predefined threshold is exceeded.

EVM and Modulation Error Ratio
 The EVM is sometimes also called the Receive Constellation Error

(RCE).
• It reports the difference between measured constellation points
and their ideal positions
– in other words, how big is the
• Like I/Q constellation diagrams, the EVM can be measured
with radio interface testers but cannot be provided by any drive
test or eNB statistics.
• At right is an error vector diagram
– Notice the vectors:
P reference
P measured
P error

LTE Received Channel Quality Indication, CQI
CQI Modula Code rate Efficiency
Index -tion x 1024 b/s/Hz  LTE modulation is adapted in
0 Out of Range real-time to match existing RF
1 QPSK 78 0.1523 conditions reported by the UE.
2 QPSK 120 0.2344  Three types of modulation are
3 QPSK 193 0.3770 available, QPSK, 16QAM, and
4 QPSK 308 0.6016 64QAM. The coding rate can
5 QPSK 449 0.8770 also be adjusted through 16
6 QPSK 602 1.1758 steps.
7 16QAM 378 1.4766  The table at left shows the 16
8 16QAM 490 1.9141 CQI indexes, their modulation
9 16QAM 616 2.4063 and coding details, and the
10 64QAM 466 2.7305 resulting spectral efficiency of
11 64QAM 567 3.3223 the LTE signal in bits per
12 64QAM 666 3.9023 second per hertz of bandwidth.
13 64QAM 772 4.5234
14 64QAM 873 5.1152
15 64QAM 948 5.5547

General Wireless Key Performance Indicators

Common LTE Key Performance Indicators (1)
Accessibility
 Initial E-RAB Establishment Success Rate
 Add E-RAB Establishment Success Rate
 Retainability
 E-RAB Retainability
Integrity
 Downlink Latency (first packet)
 Downlink Throughput
 Downlink Packet Loss
 Uplink Latency
 Uplink Throughput
 Downlink Packet Error Loss Rate
 Uplink Packet Loss Rate

Common LTE Key Performance Indicators (2)
Mobility
 Mobility Success Rate
 Availability
 Cell Availability

Specific LTE Key Performance Indicators
The Key Performance Indicators for an LTE system fall into several
major groups:
 The most critical function in the E-UTRAN is the scheduling
algorithm implemented in the eNodeB
• This is the most critical and decisive function affecting the user’s
Quality of Service (QoS) and Quality of Experience (QOE)
• The most critical KPIs are those measuring scheduler
effectiveness
 Radio Quality Measurements
 Control Plane Performance Counters and Delay measurements
 User Plane QoS and QoE Measurements

Latency Testing
 On the Android platform, the free

application “TracePing” will perform
multiple pings of any url or IP
address you give it, also locating
every node with an IP address
along the path. It shows packet loss
percentage to/from each node, as
well as the ost recent latency for
each node in the path.

Latency
Testing
 The free windows application WinMTR biy Appnor MSP will perform multiple pings
of any IP address you give it, also locating every node with an IP address along the
path. It shows packet loss percentage to/from each node, as well as the best,
average, worst and most recent latency for each node in the path.
LTE Optimization Measurements
and Techniques

Monitoring Scheduler Efficiency
 On the LTE radio interface the most interesting aspect for radio quality
and throughput of particular connections between the UE and network is
inter-cell interference.
 In LTE, thanks to Frequency Division Multiple Access (FDMA),
mechanisms exist to avoid inter-cell interference.
 The base station (eNB) rapidly and frequently collects information about
the current interference situation in each cell.
 Knowing which particular subcarriers of the available range are currently
impacted by interference, the scheduler can assign only interference-free
subcarriers to active connections.
 Assigned resources are rescheduled with a periodicity of 1ms. In other
words, within 1 second the subcarriers used for a particular connection
can change up to 1000 times
 For DL data transmission the interference status of subcarriers is derived
from quality feedback sent by the UEs:
• Channel Quality Indicator (CQI) and
• number of Hybrid Automatic Repeat Request (HARQ) retransmissions

Monitoring Scheduler Efficiency (2)
 To predict interference on the UL subcarriers, the neighbor eNBs exchange load

information messages across the X2 interface with a maximum time granularity of
20 ms.
 For a system that reschedules radio resources every millisecond, this reporting
granularity is certainly not sufficient. Hence, additional techniques are introduced to
minimize interference impact in the UL scheduler, such as random frequency
hopping.
 In general, the scheduling of UL resources and hence the management of UL
coverage and capacity are more difficult due to the fact that on the UL a set of
neighbor subcarriers must be bundled together while on the DL any subcarrier is
available for any connection.
 This “bundling” of a set of neighbor subcarriers for UL signal transmission of a
particular connection is required to overcome the Peak-to-Average Power Ratio
(PAR or PAPR) problem of Orthogonal Frequency Division Multiplex (OFDM)
without introducing stronger and more power-consuming amplifiers in the handsets.
 An example for UL scheduling of three different subscribers is shown in Figure
4.10. Note that this PAR problem of OFDM should be familiar to anybody who used
to work in the WLAN (Wireless Local Area Network) environment. Here, even if
your signal is weak you can experience the DL throughput as quite acceptable
while the upload of e-mails and other documents is wholly inadequate.

Radio Resource Control (RRC) for LTE
 This protocol controls MAC, RLC and PDCP layers in the LTE air
interface (connecting an LTE UE with an eNodeB). It is compliant
with Release 8 (V8.4.0 2008-12)(trunk V9.1.0 (2009-12))
 Protocol dependencies
 If NAS messages are encapsulated in RRC messages, LTE-RRC
calls NAS-EPS dissector. Although LTE RRC has control over
RLC-LTE and MAC-LTE, the LTE-RRC dissector does not
currently configure these dissectors. When that will be the case, a
log at the MAC interface will enable MAC dissector to call RLC and
RLC will be able to call PDCP.
 Example traffic
 Here is an example of a connection setup.

DL Scheduling for Four Mobiles
a

X2 Load Indications
 Load indication messages sent periodically on the X2 interface are

a major input for the scheduler.
 Neighbor cells exchange loading indications to inform each other
about the UL resources are currently used.
• A cell would like ideally to schedule its UL traffic on resource
blocks that are not occupied by neighbor cells.
• However, scheduler works much faster than the information
can be exchanged between the neighbor eNBs. So the
scheduler will change the allocation of radio resources every
millisecond while the best possible time granularity for X2 load
indication reports is limited to 20ms.
• The load indication message – as on the next page – does not
contain scheduling information, but rather an abstract of the
overall situation on the UL radio path.

Example: X2 Load Indication Message
+--------------------------------------------------------------+------------------------------------+
|ID Name |Comment or Value |
+--------------------------------------------------------------+------------------------------------+
|X2AP 3GPP TS 36.423 V8.4.0 (2008-12) (X2AP) initiatingMessage (= initiatingMessage) |
|x2apPDU |
|1 initiatingMessage |
|1.1 procedureCode |id-loadIndication |
|1.2 criticality |ignore |
|1.3 value |
|1.3.1 protocolIEs |
|1.3.1.1 sequence |
|1.3.1.1.1 id |id-CellInformation |
|1.3.1.1.2 criticality |ignore |
|1.3.1.1.3 value |
|1.3.1.1.3.1 sequenceOf |
|1.3.1.1.3.1.1 id |id-CellInformation-Item |
|1.3.1.1.3.1.2 criticality |ignore |
|1.3.1.1.3.1.3 value |
|1.3.1.1.3.1.3.1 cell-ID |
|1.3.1.1.3.1.3.1.1 pLMN-Identity |'299000'H |
|1.3.1.1.3.1.3.1.2 eUTRANcellIdentifier |'00fce00'H |
|1.3.1.1.3.1.3.2 ul-InterferenceOverloadIndication |
|1.3.1.1.3.1.3.2.1 uL-InterferenceOverloadIndication-Item |low-interference |
|1.3.1.1.3.1.3.2.3 uL-InterferenceOverloadIndication-Item |high-interference |
|1.3.1.1.3.1.3.2.48 uL-InterferenceOverloadIndication-Item |high-interference |

Load Indication Messages and RNTP
 Besides the identity of the sending cell, the load indication message
contains three different parameters:
• UL Interference Overload Information.
• UL High Interference Indication.
• Relative Narrowband Transmission Power (RNTP).
 For each UL resource block the interference level at the sending cell is
reported as one of three values: high, medium, or low.
 This interference level depends on how many UEs are scheduled on the
reported Physical Resource Block (PRB) and their transmit power.
 Interference power level is measured for each UL transmission block.
 The UL High Interference Indication is encoded as a bit map. Each
position in the bit map represents a PRB (first bit = PRB 0, and so on).
Value “1” indicates “high interference” and value “0” indicates “low
interference.”
 If the LTE signal is 50 resource blocks wide, the bit map would consist of
50 bits. The maximum number of PRBs in an LTE cell is 110.
 In addition to the uplink measurements above, RNTP provides an
indication of downlink DL power restriction per PRB in a cell.
RNTP
Relative Narrowband Transmission Power
 RNTP is reported as a bit map.

• Each bit a PRB value (i.e., first bit = PRB 0, and so on).
• Instead of the full bit map the value 0 might be transmitted to
indicate “Tx not exceeding RNTP threshold” or value 1
indicates “no data on the Tx power is given” by the reporting
cell.
• The individual RNTP thresholds for the PRBs are encoded as
integers ranging from −11 to +3 dB.
• Regarding aggregation and visualization of the X2 load
indication measurements – and the same statement is true for
the PRB usage reports discussed in the next section – it is
obvious that simple counter or histogram data is an
inapplicable approach.

PRB Physical Resource Block Usage
 The eNB can report the usage of PRBs to the OMC, in these 5 types:
 1. UL/DL total PRB usage: used as the traffic level indicator driving load
balancing information shared across the X2 interface, and general O&M
observability.
 2. UL/DL PRB usage per traffic class: An aggregate for all UEs in a cell,
measuring just Dedicated Traffic Channels (DTCHs). The reference point
is the SAP between MAC and L1. The measurement is done separately
for DL DTCH for each QCI, and UL DTCH for each CQI.
 3. UL/DL PRB usage per Signaling Radio Bearer (SRB): This
measurement is applicable to Dedicated Control Channels (DCCHs). The
reference point is the SAP between MAC and L1. The measurement is
done separately for DL DCCH and UL DCCH.
 4. DL PRB usage for Common Control Channels (CCCHs), including the
Broadcast Control Channel (BCCH) and Paging Control Channel (PCCH).
The reference point is the SAP between MAC and L1.
 5. UL PRB usage for CCCHs: This is the percentage of PRBs used for
CCCHs’ Random Access Channel (RACH) and Physical Uplink Control
Channel (PUCCH). Value range: 0–100%.

Received Random Access Preambles
 The number of received random access preambles is an important

accessibility KPI for a cell.
 The more UE preambles it takes to get RACH resources assigned
by the cell, the longer it takes to set up a call or to complete a
handover.
 The worst cell is the one with the highest number of received
random access preambles.
• Worst case, the UE never gets access to the RACH – an effect
that is known from drive test campaigns as the “sleeping cell.”

Number of Active Users Over Time
 The number of active UEs is a simple gauge measurement that

shows how many subscribers on average use the resources of the
cell over a defined period of time.
 This is important for traffic and radio resource planning.
 OMC statistics are typically reported every 15, 30, and 60 minutes.
• However, the figure above shows a much finer time granularity.
This makes it easier to see peaks which could lead to a
shortage of radio resources in the cell.

Uplink Scheduling Requests
 The UL scheduling request is used for requesting Uplink Shared

Channel (UL-SCH) resources for new transmission.
 This is also not a measurement for statistical purposes, but
mandatory for troubleshooting and optimizing the UL scheduling
function of the eNB.
 UL scheduling requests are sent on the MAC layer and can be
tracked for measurement purposes by an air interface tester and
visualized as shown in the figure on the following page.
 There are no scheduling request statistics provided by the eNB.

UL Scheduling for Four Mobiles
x

Buffer Status Reporting
 Another important input for uplink scheduling sent via the MAC layer
is the UL buffer status report of the UE.
• It tells the serving eNB the amount of data waiting for
transmission at the UE.
 Buffer Status Reports (BSRs) are sent either periodically or event
triggered. Typical event triggers are:
• UL data becomes available for a logical channel in a logical
channel group to be transmitted in the (RLC) or PDCP entity.
• UL resources are allocated and the UE detects that more
padding bits are scheduled than the size of the BSR MAC control
element. This BSR is called a Padding Buffer Status Report.
• A serving cell change occurs or the retransmission timer for
BSRs expires while the UE has data waiting for transmission.
• The 3GPP specs call this a “Regular Buffer Status Report.” This
should trigger an UL scheduling request to be sent in parallel.

Buffer Status Reports and Bins
 Two BSR formats exist, short and long.

• Long format is used if more than one
logical channel group has data available
for UL transmission in the TTI where the
BSR is transmitted.
• Otherwise, the short format is used.
 For the reporting a binned format (index) is
used as shown in the table at right.
 There are no statistics for BSRs from the
eNB defined by 3GPP.
 The availability of measurement results for
troubleshooting and network optimization
depends on proprietary implementations and
the radio interface test equipment.

eNodeB Physical Layer Measurements
Received Interference Power (RIP)
 RIP is the noise floor in the UL
resource blocks.
• includes UL signals of all UEs in
UL resource blocks on one Rx
antenna.
• measured in the eNB, can also be
measured by air interface testers
connected to the eNB’s CPRI.
 runs −126 to −75 dBm, in 0.1 db bins.
 High indications can come from strong
adjacent-frequency external RF
interference sources.
 LTE’s time/frequency resource grid
reduces vulnerability to interference
• Steady interferors affect only a few
subcarriers
• Pulsed interferers like radar impact
only a few time sub-slots
Thermal Noise Power
 This is the UL noise for the entire UL frequency bandwidth of the

receiving cell without the signals received from LTE handsets, i.e.,
no traffic.
• It is measured by the eNB, and/or an air interface tester
 In the absence of any signal, the thermal noise power at room
temperature is approximately -174 dbm/hz. Therefore in typical
LTE bandwidths the noise power is:
• 1.4 MHz. -112.5 dbm
• 1.6 MHz. -111.9 dbm
• 3 MHz. -109.2 dbm
• 5 MHz. -107.0 dbm
• 10 MHz. -104.0 dbm
• 15 MHz. -102.2 dbm
• 20 MHz. -101.0 dbm

Timing Advance
 Timing advance is required to
synchronize the UE uplink
transmissions so they arrive at the eNB
at the correct instant.
• However, it is also a useful statistic
since it is proportional to the
distance from the UE to the eNB
 This figure shows three different UEs scheduled for the same UL sub-slot
on the time domain. Since the distance between each UE and the eNB is
different, signals from the farther UEs must must be sent in order to arrive
at the same time sub-slot at the eNB.
• By sending timing advance commands the eNB adjusts the proper
arrival time of all three UL radio signals individually.
 The initial timing advance command is sent together with the random
access response encoded in an 11-bit timing advance value TA.
• The 11 bits represent a range of timing advance values numbered as
integer index values of TA = 0, 1, 2, . . . , 1282.
• The TA step size is expressed in multiples of 16Ts, where Ts is the
basic time unit of the LTE radio interface, 32.552083 ns.
Timing Advance Calculations
 Ts is the basic time unit of the LTE radio interface:

• Ts = 1/ (15000 × 2048) s = 1/30720000 s = 32.552083 ns
 One step of timing advance (TA) is
• TA = 16Ts = 16 × 32.552083 ns = 0.52 μs
 The geographic distance for a single timing advance step is
• r = c × 16Ts = 300m × 0.52 = 156m
 A maximal timing advance index value of 1282 means
• the UE is 1282 × 156m = 199,992 m (~200 km) from the eNB
• After the RRC connection is established, the 6-bit timing
advance updates are sent on the MAC layer over the PDSCH
as needed
• These timing advance command values sent during the active
call are relative to the current UL timing, not absolute.
– They correspond only to the change in distance since the
last timing advance command was sent.

Dynamic Rate of Timing Advance Adjustment
 When a UE receives a timing advance command from the eNB, it

needs to calculate the new timing advance using the formula
• NTAnew = NTAold + (TA − 31) × 16
 The fastest rate of timing advance commands is 2 per second.
Using the 64 index values, a distance of 64 × 156m = 9984m
(roughly 10 km) is covered.
• This means the timing advance can be properly adjusted when
the UE changes its position relative to the eNB by ±5 km in as
short a period as within 500 ms.
• Theoretically this would be sufficient to handle mobile speeds
up to 3600 km/h. Remember, however sudden changes in path
length can occur in obstructed areas even during slow
movement of the mobile as different reflections come into view.

Delays in Adjusting Timing Advance
 There is a delay between the reception and implementation of a timing
advance command inside the UE.
 A timing advance command is executed for the UL subframe that begins
six subframes later.
• Errors in timing advance can cause the loss of UL radio frames, which
seriously affects the user’s quality of experience, particularly for real-
time services like Voice over IP (VoIP).
 To catch problems in the timing advance procedure measurements should
be collected in an aggregated format per handset type and cell. This will
help benchmark the equipment of different UE manufacturers and cells
that cover different geographic areas against each other.
 Timing advance information can also be helpful in estimating the UE’s
geographic position in cases when GPS methods are not available.
 Timing advance is not part of eNB statistical measurements.
• It is a task for a protocol tester to decode and store the timing
advance command values in a trace file.
• It is possible to capture the timing advance commands directly on the
radio signal stream that is monitored at the CPRI, or some eNBs may
have a monitoring port to allow the capture of radio protocol traces.
Radio Interface Tester Measurements
Channel Baseband Power
 The channel baseband power measurement is used to track the changes

in the power amplitude of physical channels over time. This measurement
is available for both the receiver and transmitter sides of a particular
physical channel. Thus, in an ideal measurement scenario a radio
interface tester should be located at each side of the connection, at the
UE and eNB. Under these conditions the baseband power measurements
for all physical channels are available in a graphical format as shown in
Figure 4.24. In particular, these measurements are used to evaluate the
amplitude of sent and received signals for the:
• Physical Downlink Shared Channel (PDSCH).
• Physical Downlink Control Channel (PDCCH).
• Primary Synchronization Channel (P-SCH).
• Secondary Synchronization Channel (S-SCH).
• Physical Broadcast Channel (PBCH).
• Physical Uplink Shared Channel (PUSCH).
• Physical Uplink Control Channel (PUCCH).

Channel Baseband Power Measurement
Graph
x

Transmitted Signal Impairments
 For the purpose of analyzing received signal quality, some types of

corruption are very evident in the constellation diagram. Typical
radio transmission problems can be easily recognized as follows:
• Gaussian noise becomes evident as fuzzy constellation points.
• Non-coherent single frequency interference appears in the
form of circular constellation points.
• Phase noise leads to rotationally spreading constellation
points, like a time exposure photo showing the stars as traces
not dots.
• Amplitude compression causes the corner points to be
“smushed closer in” than their proper positions at the edge of
the constellation
 All of these diseases can result in the same problem – difficulty
properly recognizing the correct values of the symbols being
transmitted

I/Q Constellation Diagrams
 A constellation diagram is a scatter diagram used to visualize the

distribution of symbols of a modulated signal in the so-called
complex plane. For each common modulation scheme such as
Phase Shift Keying (PSK) and Quadrature Amplitude Modulation
(QAM) the ideal distribution pattern of symbols in the complex
plane is known from signal theory. Now the measured pattern can
be visually compared to the expected ideal pattern. In the ideal
pattern each symbol dot is laser focused on a particular fixed
position of the constellation diagram. The real-time measurement
as shown in Figure 4.25 shows the symbol measurement samples
“dancing” around their ideal positions and the further they are from
the ideal position as plotted, the more the signal was corrupted.

I/Q Constellations for Different Channels
 The I/Q constellation diagram can be measured on the transmitter

side – then it shows the quality of signal modulation before
transmission over the air interface. However, this use case is seen
more in the lab than in live networks. The typical use case for live
networks is to measure the modulation quality of a received signal.
A high-quality air interface tester should provide the particular I/Q
constellation diagrams for the following physical channels:
• Physical Downlink Shard Channel (PDSCH).
• Physical Downlink Control Channel (PDCCH).
• Primary Synchronization Channel (P-SCH).
• Secondary Synchronization Channel (S-SCH).
• Physical Broadcast Channel (PBCH).
• Physical Uplink Shared Channel (PUSCH).
• Physical Uplink Control Channel (PUCCH).
• Sounded Reference Symbols (SRSs) for UL.

Three-Dimensional I/Q Constellation Diagram
 The 2D constellation diagram can be enriched with the individual

signal strength amplitude for each received and demodulated
symbol. The result is a 3D constellation diagram as shown in
Figure 4.26.

Modulation Error Ratio for LTE Spectrum
x

Control Plane Performance Counters
Within the Network
 The eNB and MME collect a set of common performance counters and
KPIs for accessibility, retainability, and mobility
 These performance counters are also named network element counters or
OMC counters.
 One disadvantage of such network element counters is that their trigger
point definitions are usually proprietary
• a set of Nokia Siemens Network MME counters will never be 100%
identical to a set from an Ericsson MME.
• the differences are not addressed directly by the standards
 Each manufacturer’s set KPIs is quite sophisticated and almost impossible
to be implemented by external measurement equipment
• Access to user plane buffer status is mandatory, it can only be seen
from within the network, not by external monitoring equipment
• Even implementation inside the network element is not easy and
significant processing resources are required to compute such
sophisticated KPIs in the network elements.

Interpreting Counters from
Different Network Elements
 Network element performance counters are referenced to a single

measurement point and do not provide end-to-end visibility
• if a failure is found in eNB statistics it might be possible to
determine that the origin of this failure was not in the eNB itself,
but somewhere in the core network
• However, from the eNB we can’t see that the root cause of a
core network problem that triggered a chain reaction including
failure in the eNB was located in the Public Data Network
Gateway (PDN-GW).
• To follow a call across multiple interfaces, collect the records
from all the network elements and synchronize the timestamps
of measurements and protocol events
• Although it is not easy to give a clear definition of a “call” in the
all-IP world of LTE and EPC, the general measurement tasks
and aggregation levels are very close to the methods used in
earlier 2G/3G networks.

Network Accessibility
 Network accessibility in LTE requires different performance counters than

those known in 2G and 3G radio access networks
 Strictly speaking, for most types of traffic on an LTE network, the term
“call” isn’t really appropriate to describe the packet-type connections
• Actually the term “call” is no longer used by 3GPP E-UTRAN and EPC
standard documents in describing network functions. However, it is
still commonly used in the field of drive test, network operation and
maintenance, and performance measurement.
 Typically a “call” means all signaling messages and payload belonging to
a single subscriber.
 The function of a call trace application is to filter all messages and payload
packets belonging to such a particular user connection and display these
messages and packets in the correct time sequence.
• From this, a call can be defined as a single RRC connection between
the UE and the network.
• This also fits the definition of a “call drop” in the radio access network
environment, which means that the connection between the UE and
network was lost.
Network Accessibility 2
 During an LTE “call” multiple different service flows and bearers are
usually active.
• Each bearer has its own set of QoS parameters
 Overall, it is useful to aggregate all accessibility performance counters on
two different levels:
• subscriber level
– allows computing “call setup” KPIs that reflect the user
experience
• service level
– reflects the network-centric view of a network
• In addition, it makes sense to aggregate accessibility counters on a
“per handset” dimension. This will be useful for checking the
robustness of new handset models and for benchmarking handsets of
different brands against each others.
• Significant differences in handset performance have been observed in
2G and 3G technologies

Random Access Failures
 Due to radio interface testers and eNB trace ports, it is fairly easy
to monitor the random access procedure.
• Now a random access success ratio KPI can be defined as
follows:
 Low percentage values of this KPI help identify cells with serious
problems on the radio interface
• the message defined for raw counters in this formula are the
first messages sent on the UL-SCH and Downlink Shared
Channel (DL-SCH) of a cell. If there are radio transmission
problems in a cell, the random access procedures will be the
ones most impacted. Failed random access also has the
highest user impact, because missing network access is
immediately recognized by a user.
RRC Connection Setup Procedure

RRC Setup Timeout on UE Side

RRC Accessibility Failures
 In case of successful RRC connection establishment, the UE will

return a RRC connection setup complete message to the eNB.
Using a simple equation, the RRC connection setup success ratio
can be computed per cell as follows:
 However, instead of the RRC connection setup message, the eNB

may block the UE’s connection request by sending RRC
Connection Reject and a RRC blocking ratio can be computed per
cell using Equation 4.6:
 Different from the same message in 3G UTRAN, there will be no

cause value signaled to the UE with RRC Connection Reject, but a
wait time value of 1–16 seconds that can help to protect the eNB
from overload due to rising numbers of RRC Connection
Requests.

RRC Accessibility Failures (2)
 When an RRC Connection Request is sent, the timer T300 is

started in the UE
• if the RRC connection setup message is not received before
timer T300 expires on the UE side there will be no
retransmission of the RRC connection request message
• Instead the UE will reset the MAC, release the MAC
configuration, and inform upper layers about the failed RRC
connection establishment attempt.
• It is then the job of these upper layers (e.g., NAS signaling) to
decide if and when a new RRC Connection Request should be
sent.
 This means that every single RRC connection request message
must be counted as a single RRC connection establishment
attempt.

 Using the timer T300, the RRC connection establishment procedure is pretty well
surrounded from a protocol standard’s point of view.
 However, it is important to distinguish between two cases of T300 expiry
• the eNB receives the RRC Connection Request, but sends neither a RRC
Connection Setup nor a RRC Connection Reject before T300 expires.
– the root cause of this kind of problem would be located in the eNB, for
example, processor overload. The proper strategy for dealing with this is
to block access of UEs if a critical limit is reached and increase the wait
time parameter in RRC Connection Reject to balance the signaling load.
• The second failure case is when the eNB sent the RRC connection setup
message, but does not receive the expected RRC connection setup complete
message from the UE.
– The problem is usually transmission errors on the radio interface DL,
because the level of the received DL signal is too weak or there is
interference
– For a UE located at the cell edge, the partial frequency reuse settings for
the Physical Control Format Indicator Channel (PCFICH) and DL-SCH (in
particular, the resource blocks that carry the message itself) should be
verified and if necessary modified.
– In case of interference, the scheduler efficiency must be investigated

 Knowing all failure cases, an overall RRC accessibility failure ratio

can be expressed:

Call Setup Failures
 If the definition can be agreed that a “call” is a single radio

connection between the UE and the network that is used to
transmit payload using multiple bearers and service flows, then all
failures that prevent a UE from attaching to the network and
enabling Public Data Network (PDN) connectivity can be
summarized by the umbrella term “call setup failures.”
 The strong link between attach to network and PDN connectivity is
also reflected by the standards, especially 3GPP 24.301 “NAS
Protocol for Evolved Packet System (EPS).” Here it is defined that
in case of an unsuccessful attach an explicit PDP connection
reject message should be sent to the UE to ensure proper
transitions of EPS Mobility Management (EMM) and ESM (EPS
Session Management) states in the UE’s NAS signaling entity.

Call Setup Failures (2)
 Here is an attach rejected by

the network due to EPC
problems.
• The most common problems
are that one of GTP tunnels
for the default EPS bearer
cannot be established or,
• the location update
procedure between the
MME and Home Subscriber
Server (HSS) fails.
 Also, failures in Stream Control Transmission Protocol (SCTP)
transport as described in Section 1.10.3 belong to this category.
• Usually, we’d expect that errors on the SCTP level will have a
more serious impact on the network performance than just the
failed attach of a single subscriber.
Call Setup
Failures (3)
 Here is a typical
update location failure
 This isn’t necessarily
a network issue. In
fact, there are a
couple of cases
where it is meaningful
that access to the
network is restricted
to particular
subscribers or groups
of subscribers.
 For instance, if the home network operator of the subscriber does not have
a roaming agreement with the operator of the visited network then the
subscriber cannot be charged for the roaming services and, hence, it is
good not to reject the attach request.
Call Setup
Failures (4)
 In these cases the
cause value from
DIAMETER or MAP
from the HSS will be
the same as in Attach
Reject.
 However, it’s quite
likely failures in the
communication
between visited MME
and the home HSS
will occur.
 If latency on the link between MME and HSS is too high, the Update
Location Response (DIAMETER or MAP) would not arrive in time.
• If this happens, typically the cause value “network failure” is
shown in the attach reject message – but remember not every
“network failure” actually has its origin in the core network.
Call Setup
Failures (5)
 If security
functions in the E-
UTRAN can’t be
activated as
requested,
“Network Failure”
is also reported.
 This requires an
intelligent network
management and
troubleshooting
tool to distinguish
and report the
true location and
root cause of
“network failures.”
 Since the initial attach procedure is linked with many other signaling
procedures in the E-UTRAN and EPC, failures that occur in a particular
network element or on a particular signaling link often trigger a chain
reaction. This is also true in case the initial context setup procedure on S1
between the MME and eNB fails, as shown in the figure.
Call Setup Failures (5)
 If the eNB is not able to set up the initial context, this triggers an
Attach Reject (with cause “network failure”? – which depends on
the implementation in MME software) and PDP Connection Reject.
 In addition, due to the failed attach, the GTP tunnels on S1-U and
S5 that have already been established need to be deleted.
 To do this, the GTP-C delete session procedure will be used on
the S11 signaling link between the MME and Serving Gateway (S-
GW) and on S5 between S-GW and PDN-GW.
 Since the UE’s new location was already successfully updated in
the HSS, it is now necessary to delete this entry and mark the UE
in the HSS database as “not reachable,” because a UE that is not
attached to the network should not be paged.
 The signaling procedure that is used to notify the HSS about this
new state of the connection is the purge UE procedure.
 One failure can generate a lot of activity!

Activate Default EPS Bearer Failure
 Even if the UE can successfully attach to the network, another potential

error could impact on the PDN connectivity: After the successful attach the
activation of the default bearer fails.
• In most cases the origin of this failure is in the UE itself. Although all
handsets undergo various load and stress test scenarios before they
become available on the market, but problems can still exist.
• This is addressed in the new LTE NAS protocol (3GPP 24.301).
 The next page shows the signaling in such failures. Activate Default EPS
Bearer Request is sent by the MME to the UE with Attach Accept.
• While Attach Accept is a mobility management (EMM) message,
Activate Default EPS Bearer Request belongs is a session
management (ESM) message.
• If the UE can’t confirm the successful default EPS bearer activation, it
will respond with an activate default EPS bearer failure message.
• This means the UE will remain attached to the network (NAS state:
EMM Registered) while it does not have an active bearer (NAS state
in UE: ESM Bearer Context Inactive).
• The lights are on, but nobody’s home!
Activate Default
EPS Bearer
Failure (2)
 When the MME receives Activate Default EPS Bearer Failure it will
repeat the Activate Default EPS Bearer Request up to four times.
 If this does not activate the bearer context on the UE side, the MME
may detach the UE to require new initial registration to the network.
Dedicated
Bearer Setup
Failures
 Whenever a
dedicated bearer
cannot be
established, access
to an individual
service and its
contents is blocked
for the subscriber.
 To properly measure user experience, this kind of failure should be aggregated
on a subscriber ID that can later be used to generate customer-centric reports.
 Aggregation of performance counters for dedicated bearer setup on the service
level (defined by the embedded QoS parameters in the bearer setup request
message) and on the location level (defined by tracking area and E-UTRAN cell
ID) is also highly recommended.
 Watch out! The message name for this bearer setup failure is “Successful
Outcome.” This is a carryover from RANAP outcome message in the UTRAN
which confirmed setup and/or failed setup for a list of multiple Radio Access
Bearers. This is why the message name in S1AP is now “Successful Outcome”
even if it reports that the required E-RAB could be established.
Dedicated Bearer Setup Failures (2)
 The most typical reasons for failed E-RAB setup are drops of the
radio connection before RAB establishment is completed.
 The eNB may also reject the setup of a particular bearer, because
it is not able to provide the necessary resources for the requested
service
• for example it can’t support the desired bit rates.
• Often the leak of resources isn’t related to availability of
subcarriers and time slots on the radio interface, but simply to
limited processing power and system memory in the eNB.
• Processors and memory to serve a certain number of
connections are found on so-called “channel cards,” boards
that allow scalability of hardware (and in turn scalability of the
hardware price) according to the amount of expected traffic.
• If the eNB’s hardware is inadequate this will result in error
messages with cause values like “not enough user plane
processing resources,” especially during peak hours of traffic.
Paging Failures
 The analysis of paging failures requires a distinct workflow for the

multi-step paging process, rather than just reacting to one KPI.
 Due to the tracking area concept of the E-UTRAN, the last known
location of a handset that misses a page sent by the MME is pretty
accurately known.
 In a network where one cell has been assigned as a single
tracking area, the UE will be paged in a few cells only.
• In contrast 2G and 3G RAN paging messages are typically
sent to all cells of a particular Location Area Code (LAC)
– a few hundred cells compared to a few dozen in the E-
UTRAN.
 However, a paging failure ratio KPI on cell aggregation level will
always have a questionable value since a UE can only camp in a
single cell and there will be no paging response from most cells
which transmitted the page.
Paging Failures (2)
 It makes sense to store the subscriber ID of UEs that do not

respond to pages investigate the conditions leading up to their
paging failures including where they may have gone’
 The most likely reasons for paging failures are:
• The UE is defective, failed without detaching from the network.
• The UE while in IDLE mode performed a new cell (re)selection
and is camping now on a 3G or 2G cell without informing the
network properly about the new location that is geographically
the same as before, but covered by a different RAT.
 Possible root causes of paging failures to be investigated
according to these symptoms are:
• defective handsets;
• insufficient coverage;
• wrong settings for broadcast cell (re)selection parameters like
S0 criteria.
Paging Failures (3)
 Considering interworking between 3G and 4G networks, it is very

important to monitor both radio access networks to get rapid
updates of UEs toggling between the different RATs.
 This is important because the handsets in 2G/3G networks can
perform cell reselection to the LTE E-UTRA without further notice.
• While this will lead to paging failures experienced in the 3G
part of the network, continuous toggling of radio access will
also lead to performance degradation and accessibility failures
that impact both radio access technologies.
Accessibility Delay Measurements
 An accessibility problem isn’t always because of a dedicated failure
message sent by an involved protocol entity. Some problems don’t block
the progress of the accessibility procedures, but cause unacceptable
delay. Minimizing subscriber access delay is a key target in the 3GPP
spec. Accessibility delay measurements are crucial for optimizing
performance. These delay measurements are:
• Random Access Time: t MAC Random Access Preamble → RRC Connection
Request.
• RRC Connection Setup Time: t RRC Connection Request→RRC Connection
Setup Complete.
• NAS Attach Delay: t NAS Attach Request → NAS Attach Accept.
• Activate Default EPS Bearer Delay: t NAS Activate Default EPS Bearer
Request → NAS Activate Default EPS Bearer Accept.
• Initial Context Setup Delay: t S1AP Initial Context Setup Request → S1AP
Initial Context Setup Response.
• E-RAB Setup Delay: t S1AP E-RAB Setup Request → S1AP E-RAB Setup
Response.
• Service Request Delay: t S1AP Initial UE Message (NAS Service Request) →
S1AP Initial Context Setup Response.
• Paging Response Time: t S1AP Paging → S1AP Initial UE Message (NAS
Service Request).
Accessibility Delay Measurements (2)
 All delay measurements that involve the handset, especially RRC

Connection Setup Time and Paging Response Time, should be
correlated not just with the handset type, but also with the initial
timing advance measurement from the random access response.
 This allows taking into account the specific radio conditions at the
time of the event (distance between the cell antenna and UE).
Network Retainability: Call Drops
 A “call” in the all-IP always-on E-UTRAN is really defined as a single radio

connection between a UE and the network.
 When this connection is suddenly interrupted (e.g., signal lost on the radio
interface), we call it a “dropped call”.
 Drop events can be found in the S1AP UE context release request message sent
by the eNB to the MME
 When this message is sent, the radio connection with the UE is already terminated
on the RRC layer, so UE and eNB go back to the E-UTRA RRC IDLE state.
 However, the PDN connection between the UE and the server hosting application
contents on the IP network is typically left active.
Call Drops (2)
 Here’s a KPI formula for dropped call ratio at the cell aggregation level:
 The total number of active calls is defined as the number of initial contexts
successfully established plus the number of incoming handovers (S1AP
handover notify message) minus the number of outgoing handovers (UE
Context Release “successful handover”).
 Dropped calls in the all-IP world of E-UTRAN and EPC won’t usually be
perceived by the subscriber as a dropped connection
• For non-real-time services like web-browsing or e-mail, user
perception will be just short interruption of data transport, delay in
accessing a next web site, or slowdown of an ongoing download.
• If the network can re-establish the lost radio connection fast enough
the subscriber won’t even notice the drop.
– Re-establishment delay is an important KPI for RRC retainability)
 In real-time services like voice calls, the user will immediately recognize
the loss of connection. It would require extremely fast RRC re-
establishment procedures (1-2 seconds) to save the situation.
Call Drops (3)
 Knowing the difference in user perception of drops in the IP

environment, we need
• not just to compute a call drop ratio per cell,
• but also to have a call drop ratio per service (per QCI is
sufficient) within the cell to measure the user-perceived QoE.
 The root causes for call drops are varied and cannot be accurately
identified just by looking at the cause value in the S1AP UE
context release request message.
• In fact the identification of the root cause requires an in-depth
analysis of all transport and signaling protocols involved in the
call, with a focus on call state transitions and changing radio
quality parameters.
RRC Re-Establishment
 It is mandatory for the UE to try a RRC re-establishment before

giving up the call as dropped and going back to IDLE.
• RRC re-establishment can help to recover connection
problems in areas of quickly changing radio conditions.
• Counting the number of RRC re-establishment messages and
benchmarking this procedure per cell will help to identify
problem areas in the network.
 An RRC re-establishment success ratio can be defined:
Mobility (Handover)
 Basically three major groups of problems due to mobility can be

identified when monitoring the E-UTRAN:
• handover preparation failures;
• handover execution failures;
• data forwarding failures.
 Handover preparation is the phase in which the target cell assigns
the necessary radio resources for taking over the connection and
sending back a handover command message containing the new
radio parameters to the source cell.
 Common root causes for handover preparation failures are
• insufficient resources in the desired target cell,
• signaling transport between the source and target cell,
• protocol errors in one of the involved peer entities,
• parameterization errors in the network configuration, for
example, errors in IP/ATM routing tables.
Handover Execution Phase
 The handover execution phase starts when the previously

received handover command message is sent to the UE and
successfully finished after the UE has arrived at the target cell.
 Handover execution can fail because
• the UE refuses to execute the handover by sending a RRC
reconfiguration failure message or
• radio contact with the UE is lost during handover execution on
the radio interface.
Mobility (Handover) 2
Handover Types
 The various handover procedures in the E-UTRAN can also be

classified by their type:
• X2 handover/S1 path switch = Inter-eNB handover with X2.
• S1 handover = Inter-eNB handover without X2. Special cases
of this scenario are the inter-MME handover with/without S-GW
and/or PDN-GW relocation.
• Inter-RAT handover to 3G UTRAN.
• Inter-RAT handover to GERAN.
• Other inter-RAT handover types, for example, to TD-SCDMA
or CDMA2000 radio access technology (not discussed in more
detail in this chapter).
• Inter-RAT handover from 3G UTRAN to E-UTRAN.
• Inter-RAT handover from GERAN to E-UTRAN.
 The handover type can be distinguished according to the interface

(X2 or S1) and for S1 according to the different containers
embedded in the S1AP handover required message.
 In the case of S1 inter-eNB handover, the Source eNB to Target
eNB Transparent Container is included.
• Inter-RAT handover to 3G UTRAN requires the Source RNC to
Target RNC Transparent Container
• inter-RAT handover to GERAN the Source BSS to Target BSS
Transparent Container.
 It’s necessary to distinguish between incoming and outgoing
handover legs in the case of intra-system S1 handover.
• This differentiation is possible due to the S1AP mobility
elementary procedures.
• While the S1AP handover preparation procedure is found on
the outgoing leg, the incoming leg deals with the S1AP
handover resource allocation procedure.
Handover Preparation
 The following KPIs can be defined for handover preparation

• the failure report should display the cause values found in
handover failure messages:
X2AP/S1AP Message Type
and Associated Procedure Code
handoverPreparation X2AP-ELEMENTARY-PROCEDURE ::= {
INITIATING MESSAGE HandoverRequest The message names
SUCCESSFUL OUTCOME HandoverRequestAcknowledge used in 3GPP standard
UNSUCCESSFUL OUTCOME HandoverPreparationFailure documents and in the
PROCEDURE CODE id-handoverPreparation previous KPI formulas
CRITICALITY reject need to be mapped to
} the ASN.1 encoded
handoverPreparation S1AP-ELEMENTARY-PROCEDURE ::= { message format used to
INITIATING MESSAGE HandoverRequired construct X2AP/S1AP
SUCCESSFUL OUTCOME HandoverCommand messages, based on
UNSUCCESSFUL OUTCOME HandoverPreparationFailure
X2AP/S1AP message
PROCEDURE CODE id-handoverPreparation
type and associated
CRITICALITY reject
procedure code:
}
handoverResourceAllocation S1AP-ELEMENTARY-PROCEDURE ::= {
INITIATING MESSAGE HandoverRequest
SUCCESSFUL OUTCOME HandoverRequestAcknowledge
UNSUCCESSFUL OUTCOME HandoverFailure
PROCEDURE CODE id-HandoverResourceAllocation
CRITICALITY reject
Handover Execution Phase
 KPIs for the handover execution phase are:
Handover Execution (2)
 The handover type (intra-system or inter-RAT) must be detected

according to the preceding Handover Required message:
 The handover type (intra-system or inter-RAT) must be detected

on the source ID found in Source eNB to Target eNB Transparent
Container in the preceding handover request message.
 The UE History Information that is included as a mandatory
parameter in the Source eNB to Target eNB Transparent
Container contains a list of up to 6 cells maximum visited by the
UE before the handover attempt to the target cell.
• The history can include E-UTRAN cells as well as 3G UTRAN
cells but is not defined for cells of any other radio access
technology.
Handover Delay Measurements
 These measurement are:

• X2 Handover Delay = t X2AP Handover Request → X2AP Sequence
Number (SN) Status Transfer.
• S1 Path Switch Delay = t S1AP Path Switch Request → S1AP Path
Switch Request Acknowledge.
• S1 Outgoing Handover Preparation Delay = t S1AP Handover
Required → S1AP Handover Command.
• S1 Outgoing Handover Total Delay = t S1AP Handover Command
→ S1AP UE Context Release (“successful handover”). Although this
delay measurement is not meaningful for the user experience, it is
important to measure how long radio resources in the source eNB are
blocked after a handover command was sent to the UE.
• eNB Handover Command Latency = t S1AP Handover Command →
RRC Handover Command.
• S1 Incoming Handover Total Delay = t S1AP Handover Request
Acknowledge → S1AP Handover Notify.
• eNB Handover Success Latency = t RRC Handover Confirm →
S1AP Handover Notify.
Data Forwarding
 Data forwarding occurs in X2 handover procedures and can start

after the X2AP handover request acknowledge message is
received by the source eNB.
• In order to assist the reordering function in the target eNB, the
S-GW should send one or more “end marker” packets to the
source eNB using the old S1-U path immediately after
switching the path for each E-RAB of the UE.
• The “end marker” packets do not contain any user data and are
marked with a special flag in the GTP header. After sending
the “end marker” packets, the S-GW should not send any
further user data packets via the old path.
 Upon receiving the “end marker” packets from the S-GW via the
old S1-U path, the source eNB should, if forwarding is activated for
that bearer, forward the packet toward the target eNB.
 The PDCP SN of forwarded Service Data Units (SDUs) is carried
in the “PDCP PDU number” field of the GTP-U extension header.
The target eNB should use the PDCP SN if it is available in the
forwarded GTP-U packet.
KPIs for Data Forwarding
 Important KPIs for data forwarding are:

• number of forwarded SDUs;
• number of lost SDUs;
• time difference t X2AP Handover Request Acknowledge → first
UP packet forwarded on X2;
• time difference t first “end marker” packet on old S1-U path →
first UP packet forwarded on X2
User Plane KPIs (1)
 User plane KPIs are typically measured on a per call basis, but we
don’t have to do it that way. There are various ways to store and
display user plane performance measurements. The chosen
approach should depend on the purpose of the measurement.
 Consider the example of throughput measurements.
• To get a rough idea of the user plane load it is sufficient to
collect the data volume for a longer timer period like 15, 30, or
60 minutes.
• Using this time interval average throughput can be computed,
but typically this is not done since there’s not enough data
volume for a user plane metric except in the busiest cells.
• However, to describe the user experience in these cells, this
kind of measurement isn’t really meaningful.
User Plane KPIs (2)
 A better way to measure the user experience or throughput is to collect
throughput measurement samples during each active call in a particular cell
and store and count the results in a bin histogram table.
 The bin distribution of throughput measurement samples allows a good
evaluation of the subscriber’s throughput quality experience.
• However, most common applications in today’s mobile networks aren’t
very throughput-sensitive. Connections for e-mail and web-browsing
services show high volatility due to the traffic itself.
• This means distribution of samples in a bin histogram reflect the nature
of the traffic more than the user experience.
• Even if throughput is lower during downloading a web site, this isn’t
usually recognized as a problem by the subscriber, because they
experience the same kinds of issues all the other IP environments they
use.
• The bin histogram approach is meaningful to evaluate the user
experience in throughput-sensitive services like streaming video or File
Transfer Protocol (FTP), but not for a generic measurement of user
experience and cell quality.
• Another disadvantage is that this kind of measurement requires a lot of
hardware and cost.
IP Throughput
 The IP throughput is defined as the data volume of IP frames

transmitted within a defined time period in the UL or DL direction.
There are different versions and derivatives of the IP, so a suite of
protocols should be supported by this measurement, especially as
we find in mobile IP networks:
• IPv4 – Internet Protocol version 4 (32-bit addresses).
• IPv6 – Internet Protocol version 6 (128-bit addresses).
• PIP – The “P”-Internet Protocol.
• IP/ST – IP in ST datagram mode.
• TP/IX – The “Next” Internet Protocol.
• TUBA – Transmission Control Protocol/User Datagram
Protocol (TCP/UDP) over Connectionless mode Network
Protocol (CLNP).
Throughput Measurement Graph of a Single Connection
Correlated with Occurrence of Handover Events.
 xx
IP Frame Header
Application Throughput
TCP and FTP data frame
Application Throughput
UP Datagram With Length Indicator
 For real-time services the data volume of Real-Time Transport Protocol

(RTP) packets is a good metric to determine the throughput, but since
there is no length filed in the RTP header, the size of RTP blocks must be
determined using a little algorithm as is typically implemented in decoder
engines. One possible approach is to take the length field from the UDP
header if the UDP ports indicate that RTP packets are transported and to
plot the length of the payload field (UDP length minus UDP header size) in
a trailer that comes along with the plain decoder output. By reading this
trailer information and summing the size of RTP blocks over time, it is
easy to calculate the RTP throughput.
UDP throughput of a connection between two terminal
endpoints as measured on S1-U interface
 xx
TCP Startup KPIs
 For non-real-time services such as file transfer, web-browsing, and

e-mail a set of service startup failure ratio, service startup time, IP
service startup failure ratio, and IP service startup time KPIs is
defined in ETSI TS 102.250 together with other QoE KPIs such as
UL/DL throughput for individual services.
 Originally ETSI TS 102.250 was defined to measure QoS and QoE
KPIs with drive test equipment.
• That’s why we have different definitions for service setup time
and IP service setup time.
– service setup time refers to start trigger point of the first
real application frame sent, while
– IP service setup sees the trigger points for the start and
stop of delay measurements in the TCP layer.
FTP (IP) service setup time
 Here’s an example of IP service setup time measurement for FTP.

• The delay between the TCP syn (frame 1983) and the first TCP
ack (frame 1992) message is 68 ms. in the table.
TCP Port Numbers for Application Tracking
 Tracking setup times and other measurements for application

processes requires identifying the appropriate events.
 The TCP port numbers used for each application will be useful in
recognizing events involving each application.
TCP Round-trip Time Measurement
 The TCP Round-Trip Time (RTT) is the delay between sending a

TCP packet identified on behalf of an individual TCP SN in a
particular TCP flow and acknowledgment of this packet in the
same TCP flow.
 When implementing this measurement remember TCP has some
options to work with selective acknowledgments per RFC 2018.
• Here the acknowledgment number refers not just to a single
sent SN, but to a set of previously sent packets. The TCP RTT
is heavily influenced by radio quality and radio interface
procedures.
HARQ Retransmissions Trigger TCP RTT Peaks
 This shows how HARQ retransmissions on the E-DCH in 3G trigger peaks

of TCP RTT and how power control increased the UL SIR (Signal-to-
Interference Ratio) target to preserve QoS.
 After each increase, the UL SIR target decreases in quick small steps.
 LTE HARQ and power control behave the same way.
Packet Jitter
 Packet jitter is defined as the average of the deviations from the

network mean latency.
• It is an important QoS parameter for real-time services using
UDP transport due to their delay sensitivity.
• For non-real-time services like web-browsing or e-mail the jitter
has no impact on the user plane QoS.
 Jitter’s impact is easiest to understood thinking about a constant
stream of VoIP packets. Thousands of small voice packets must
be received with high reliability and continuity for reassembly and
smooth playback.
• If the re-assembling entity must wait longer for some individual
packets – even if they are received error-free – this will cause a
delay in the reassembly and conversion back to speech. In the
worst case this can be heard as a gap in the audio signal.
Packet jitter is a simple measurement that allows one to
estimate the risk of experiencing such gaps.
Packet Jitter (2)
 There are various UDP jitter measurement definitions.

 The most needed UDP jitter analysis is a “loose” UDP jitter based
on the arrival timestamp of subsequently received UDP packets at
the measurement point.
 For the UDP jitter calculation the formula below is used. The
individual latency measurement samples for two subsequently
received packets of the same stream are defined as Di and DJ and
the difference of these two latency measurement results is defined
as J (j – i ):
 The factor 16 in the denominator is a smoothing factor proposed in

RFC 1889, the standard specification document for RTP.
Packet Delay and Packet Loss on a Hop-to-
Hop Basis
 When packet loss or abnormal packet delay is measured at a

particular measurement point, we wonder which element or part of
the network caused such problems.
 For this kind of root cause analysis it is necessary to measure
packet loss and packet delay on a hop-to-hop basis, for example,
between Uu and S1-U, between S1-U and S5, and so on.
Packet Delay and Lost Packets
Caused by eNodeB
 The figure above shows the results for the following measurements:
• Packet delay UL: The time the eNB needs to forward a packet received from
the Uu to the S1-U interface.
• Packet delay DL: The time the eNB needs to forward a packet received from
the S1-U interface to the Uu interface.
• Lost packets: The total number of lost packets and the time distribution of
packet losses according to the tracking results after call trace.
Packet Delay and Packet Loss on a Hop-to-
Hop Basis
 When packet loss or abnormal packet delay is measured at a

particular measurement point, we wonder which element or part of
the network caused such problems.
 For this kind of root cause analysis it is necessary to measure
packet loss and packet delay on a hop-to-hop basis, for example,
between Uu and S1-U, between S1-U and S5, and so on.
 The packet delay and packet loss for DL transmissions from S1-U
to Uu are shown in the previous graph.
 UL delay measurement results are usually displayed in tabular
format as a max/min/mean value triple.
• Notice the previous graph corresponds to the UDP throughput
shown in the corresponding previous figure. A comparison of
both figures reveals the loss of packets in eNB as the root
cause of the throughput degradation shown in the earlier figure
on UDP throughput.
LTE System Statistics
and Operational Measurements
System Statistics
 Optional Exercise:
• Let’s look at available counter and statistical data from your
own network statistics tools
• We can explore the available manufacturer documents to
become more familiar with the statistics and counters available
from your network
LTE Field Data Examples
Example from 3HK trial – reusing 3G sites
Improving performance by blocking excess cells
Example from 3HK trial – reusing 3G sites
Improving performance by blocking excess cells
Detecting interference - SINR
 SINR measurements can indicate interference areas, but don’t

necessarily see all interference sources:
• Impacted by network load. Traffic in the neighboring cells will
reduce Serving cell SINR.
• Depends on the measurement method (RS or SCH) and tool
• Depends on PCI planning (RS SINR)
Detecting interference RSRP
 RSRP measurement with scanner is the most reliable way to

detect areas with possible interference problems.
 Not impacted by network load
Summary
 Absolute SINR measurement values can’t be used as a reliable

performance indicator.
• Operators should be educated, not to believe blindly measured
SINR values.
• Relative SINR changes can be used as performance indicator,
if the same measurement tool is used all the time.
• SINR measured from S-SCH and RS behaves differently
depending on the interference situation (intra/inter eNodeB).
• Detailed SINR measurement methods of the terminals and
scanners are not known.
 The most robust and reliable measurement quantity seems to be
RSRP
RF optimization
 Basic RF planning is important

• Clear cell dominance areas
• Avoid sites shooting over large areas with other cells
 Antenna tilting has big impact on other cell interference, at least in
planning tool estimates
• No LTE reference measurements available
LTE RAN Optimization Tools
LTE RAN Testing
 Successful RAN problem resolution focuses especially on the

lower levels of the protocol stack
• RF performance – the Uu interface
– Terminal and eNodeB signal quality tests
– Dynamic field capture of RF indicators
– Field RF environment testing, interference detection
• “Call Processing” Event Capture and Performance Analysis
– MAC layer performance
Process monitoring, parameter capture, and problem
detection for unsuccessful events
Handover monitoring and configuration analysis
– Messaging Capture and Interpretation
Identification of specific failed events and root analysis
LTE RAN Test Tools
Multiple tools are available for RAN testing:

 UE-intrinsic diagnostic and status displays
 Specific UE logging applications for more detailed capture of RF
conditions and “signatures”
 Commercial Off-Air receivers for field signal analysis of both uplink
and downlink conditions
 Commercial “call processing” capture tools logging UE RF
indications, MAC-level and Message-level activity, and state
changes of the UE
 RAN Manufacturer-specific logging/capture and reporting utilities
for eNodeB RF indications and event records
 Post-Processing software tools for merging and analysis of
captured field and RAN-side RF data to support detailed analysis
of performance problems
 The following pages list many available tools, in alphabetical order
by manufacturer
Agilent RF Tools
 Agilent (formerly Hewlett-

Packard, HP) has a long
history of in RF tools
 A few years ago Agilent
sold its wireless
optimization product line to
another company, JDSU
 However, Agilent continues
to offer its own drive-test
collection solution, the
E6474A and W1314
receiver family (above)
 Agilent also offers spectrum
analyzers for both lab and
field environments such as
the Fieldfox N9912A, below
Anite Field Test Products
Anite in Finland absorbed the former Grayson wireless and Handy
offers its own comprehensive system of optimization tools
 Handy – android-based portable
FSR-1
 NEMO Autonomous
• Unattended/mobile data collection Autonomous
 NEMO CEM customer experience tool Outdoor
• Reporting software on subscriber handsets and
back-end processor
CEM
 NEMO FSR1
• Modular Receiver data collection
 NEMO Outdoor
• Full-featured data collection in portable package
 NEMO Invex Analyze
• Multi-device data collection for benchmarking and in-
depth problem capture
 NEMO Analyze post processor
• Problem analysis, benchmarking Invex
Anritsu RF Tools
 Anritsu’s traditional strength has been in spectrum

analyzers, line testers, and big-ticket testers for
Handset and BTS manufacturing
 Anritsu has boldly entered drive-test and network
performance optimization with two new products:
 Link Master LML – Air Interface Logging Tools
• logs air interface data taken during a drive test
from multiple UEs or receivers on a PC.
 Link Master LMA – Air Interface Analysis Tools
• provides in-depth analysis of the post processed
log data on a PC.
Ascom-TEMS RF Tools
TEMS INVESTIGATION TEMS DISCOVERY
 Ascom acquired the earlier Ericsson TEMS tool

 Ascom-TEMS offers a field data acquisition system called
TEMS Investigation. It collects RF field data from UEs,
scanning receivers, and GPS.
 TEMS Discovery is a post-processing tool which allows root TEMS Pocket
cause analysis of RF environment and event failure problems
captured by TEMS Investigation
 TEMS Pocket is performance date and event capture
software which runs on a UE for collection and display in
almost any conceivable location Scanners
 TEMS Automatic automonously collects field RF and event

data and uploads it to servers without manual intervention. If
mounted in public transport or commercial service vehicles, it
can collect wide-area data without operation intervention. TEMS Automatic
DRT – Digital Receiver Technologies
E-UTRA Carrier RSSI

UTRA FDD Carrier RSSI
GSM Carrier RSSI Carrier Frequency Offset
RS CINR SCH CINR
Reference Signal Received Power PSCH Detection
(RSRP) - Physical Layer Cell Identity
Reference Signal Received Quality - PSCH Power
(RSRQ) - PSCH Quality
Spectral Display SSCH Detection
Channel Response - Physical Layer Cell Identity Group
Delay Spread - SSCH Power
Multipath Count - SSCH Quality
 DRT, owned by Boeing, offers a compact digital receiver/scanner

covering 2-3000 MHz. supporting LTE and most other wireless
technologies in addition to spectrum analysis
 It offers its own windows and android management/analysis
software, or the receiver can be managed by other companies’
software such as Ascom TEMS
JDSU RF Tools
 JDSU purchased the wireless test product line of Agilent and has
expanded it to provide end-to-end testing of LTE systems,
integrating RF field-collected data with messaging captured from
the interfaces between RAN and Core Network for powerful event
and root cause analysis
PCTEL RF Tools
 PCTEL has developed a line of

particularly fast scanning receivers for
all wireless technologies including LTE
 The receivers are substantially faster
than most competitors, allowing much Scanning Receivers
more dense and revealing RF data to
be collected with less time in the field
 Because of their small size, the
receivers are suitable for both indoor
and outdoor surveys
 Advanced signal processing capability
allows evaluation of MIMO Indoor-Outdoor Measured Propagation
effectiveness and benchmarking

MIMO results against prior results over
time
LTE Speed, Diversity vs 4-branch Mimo

Rohde & Schwarz RF Tools
 The Rohde-Schwarz TSMW scanner provides

very rapid scanning and measurement of LTE
parameters
• RSRP, RSRQ narrow and wideband,
RSSI, Ptot, SINR, RS-SINR, ISI, CIR,
Doppler shift, CP type, MIMO CN
• Available technologies LTE-FDD, LTE-
TDD, GSM, WCDMA, CDMA2000,
1xEVDO 0/A/B, WiMAX
• Also integrates/collects UE data
 Rohde-Schwarz ROMES4 post processing
software analyzes data from all technologies
collected by the TSMW scanner and provides
detailed event-processing and messaging
analysis
 The Rohde-Schwarz PR100 real-time
spectrum analyzer is the most advanced and
sensitive interference detection device
available to civilians in the western countries
Tektronix RF Tools
 Tektronix is a long-established test

equipment manufacturer in both the RF
and network arenas.
 In the RF area, Tektronix does offer
leading-edge spectrum analyzers with
advanced interference detection
capabilities. However, it does not offer a
general field wireless RF optimization
tool to collect messaging and layer-2
data for call processing analysis.
 In the data arena, Tektronix has
developed advanced IP and core network
monitoring tools well-suited to analysis of
LTE systems. These will be described
along with other core-network-centric
tools in the next section.
Transcom Instruments
 Transcom Instruments of Shanghai, China offers a cost-effective

LTE scanning receiver and analysis software
 Eagle: LTE Scanner supports TDD-LTE and FDD-LTE in all band
classes using a DSP-based engine with rapid scanning and high
dynamic range
 EMAS: Eagle Measurement & Analysis System automatic signal
measurement and analysis software can operate multiple Eagle
Scanner Receivers. It includes GPS, displays and is compatible
with a wide variety of available maps for display and analysis
LTE Core Network
Monitoring/Optimization Tools
Core Network Tools
 Core Network Tools monitor the various interfaces within and around the
LTE core network to collect packet and messaging information about
interface and node conditions, failed processing events, traffic levels, and
other network statistics.
 Manufacturers of the core network nodes provide their own generic and
proprietary counters and indicators for the performance of their network
elements and the interfaces they use. These provide the main operational
statistics upon which LTE operators rely on to manage their networks
ordinary operation.
 Test equipment manufacturers provide data monitoring and collection
tools which capture TCP/IP packets and network events. The
manufacturers also provide various software tools for post-analysis of the
collected data, making it possible to zoom in on specific types of packets
and events and drill down to first causes.
 Some tools provide simulation of traffic and simulation of various network
nodes to support core network design and element selection, beyond the
narrower function of optimization.
 Following pages describe available core network analysis tools.
Agilent Core Network Tools
 In addition to its
LTE RF
optimization tools
and broad line of
spectrum
analyzers and
other RAN-related
equipment, Agilent
also offers a
series of
Distributed
Network
Analyzers and
analysis software
for deep study and
event capture in
the LTE Core
Network
JDSU Core Network Tools
 In addition to its RAN test products, JDSU also offers extensive

core network data collection and analysis tools including special
emphasis on services such as video/TV and IMS for VoLTE.
Tektronix Core Network Tools
 Tektronix provides data probes to monitor all TCP/IP interfaces of an LTE network,
both in the RAN and the Core, along with its IRIS Performance, Traffic and Protocol
analyzers and new Spectra2 XL3 IMS and EP3 test application.
Examining LTE
Message and Event Records
Wireshark
http://www.wireshark.org/download.html
 Wireshark is a free, open-source packet capture and analysis tool

 Wireshark is a “poor man’s friend” tool for high quality (if somewhat
tedious) analysis of packets from any of the LTE RAN and Core
Network interfaces
 The desired packet streams must be captured by other software or
hardware probes
 Many templates for analysis of LTE call processing events are
already available through resource blogs and online collaborations
using Wireshark
cc
Example RRC Traffic: Connection Setup
RRC Wireshark Notes
 The LTE-RRC dissector is fully functional. However, at the

moment you need to call it through DLC_USER interface to
decode a single packet or create a wiretap plugin to read your data
from a file with a specific format. There are some wrappers
available to help you use the protocol directly. 3GPP message
decoder is one of them and is very simple to use.
 Alternatively, if you are using Wireshark to decode MAC-LTE,
RLC-LTE, PDCP-LTE then the RRC dissector will be called
appropriately, if enabled by preference settings. The dissector is
also called appropriately when "rrc_r8_lte" or "rrc_r9_lte" primitives
are found in IxCatapult DCT2000 logs.
LTE-RRC Wireshark Preferences and Filters
 Preference Settings
• There are currently no preference settings for this protocol.
 Display Filter
• A complete list of RLC-LTE display filter fields can be found in
the display filter reference
• Show only the LTE-RRC based traffic: lte-rrc
 Capture Filter
• You cannot directly filter LTE-RRC protocols while capturing.
 External links
• 3GPP TS 36.331 Evolved Universal Terrestrial Radio Access
(E-UTRA) Radio Resource Control (RRC) protocol
specification
Wireshark Dissector Notes for LTE-RRC
 This dissector is generated through asn2wrs script. Any

modifications must be in the template or in the configuration file.
 How to generate a dissector based on a newer release:
• - Download 36331-xxx specification as Word document, open,
in "View" panel select "normal" or "web layout" (removes page
header/footer) - Save in asn1\lte-rrc directory as a text file.
• - Call the asn1 extractor: perl
..\..\tools\extract_asn1_from_spec.pl 36331-xxx.txt It should
generate EUTRA-RRC-Definitions.asn, EUTRA-UE-
Variables.asn and EUTRA-InterNodeDefinitions.asn
• - Run asn2wrs:
• ../../tools/asn2wrs.py -L -p lte-rrc -c lte-rrc.cnf -s packet-lte-rrc-
template EUTRA-RRC-Definitions.asn EUTRA-UE-
Variables.asn EUTRA-InterNodeDefinitions.asn
 The packet-lte-rrc.c file is generated. Put it into the epan\dissectors
folder and recompile wireshark.
Medium Access Control (MAC) for LTE
 This protocol is layer 2 of the LTE air interface (connecting an LTE

UE with an eNodeB).
 •MAC-LTE runs over the PHY layer
 A UDP framing format for MAC-LTE has been defined (described
in packet-mac-lte.h, purely for use with Wireshark)
• Can call RLC dissector for its SDUs (see Preference Settings
below)
• BCH, PCH and CCCH payloads can be decoded by the LTE
RRC dissector
• RAR UL Grant field can be broken down according to 3GPP
TS 36.213
 Example traffic
Example: (MAC) for LTE
LTE-MAC Wireshark Notes
 The MAC-LTE dissector can read MAC-LTE frames from:

• DCT2000 log files, OR
• using the UDP format defined in packet-mac-lte.h. This (BSD-
licensed) program gives an example of how you might send
MAC-LTE frames in this format, OR
• the compact format decoded by the mac-lte-framed dissector.
This shares the same framing format as the UDP format
described above. This (BSD-licensed) program gives an
example of how you might write MAC-LTE frames directly in a
file of this format. Currently, this does not have its own
registered DLT, so if (as the same program does) you use DLT
147 you will need to edit the preferences of the DLT_USER
dissector (add an entry with DLT=147, Payload Protocol=mac-
lte-framed) OR your own framing protocol. The functions
get_mac_lte_proto_data() and set_mac_lte_proto_data() are
available for querying and setting the necessary context
information associated with a frame.
MAC-LTE Statistics
 MAC-LTE statistics can be viewed in a window
• see Telephony | LTE | MAC ...
 Also can be viewed in tshark using the -zmac-lte,stats option.
LTE-MAC Wireshark Preferences and Filters
• Number of Re-Transmits before expert warning triggered.
Default is 3.
• Attempt to decode BCH, PCH and CCCH data using LTE RRC
dissector. Default is TRUE.
• Dissect frames that have failed CRC check. Default is FALSE.
• Try Heuristic LTE-MAC framing over UDP. Default is FALSE.
• Attempt to dissect LCID 1&2 as srb 1&2. Default is FALSE.
 LCID -> DRB Mappings Table. Can configure data channel ID and
RLC mode so RLC-LTE dissector can be called for these SDUs.
• Attempt to track UL HARQ resends. When frame marked as
reTx, looks for link back to original tx. Default is TRUE.
• BSR size when warning should be issued. Default is 50 (19325
< BS <= 22624)
LTE-MAC Wireshark Preferences and Filters
(continued)
• track status of SRs within UEs. Looks for and shows links
between SR request and resulting grant or failure indication.
Default is TRUE.
• Which layer info to show in Info column.
– Choices are PHY, MAC or RLC info. Default is MAC-info.
 Display Filter
• A complete list of MAC-LTE display filter fields can be found in
 Show only the MAC-LTE based traffic: mac-lte
 You cannot directly filter MAC-LTE protocol frames while
capturing. But, if you are using the supported UDP framing format,
you may be able to filter on the UDP port you know that you are
using, e.g. udp port 9999
Packet Data Convergence Protocol
(PDCP) for LTE
 This protocol sits between the RLC and RRC layers in the LTE air
interface (connecting an LTE UE with an eNodeB).
• A preference setting may be enabled to allow dissection of
(some) RRC payloads. This dissector may be called by the
RLC-LTE dissector for signalling PDUs (if preference settings
are enabled).
• A UDP framing format for PDCP-LTE has been defined
(described in packet-pdcp-lte.h, purely for use with Wireshark)
PDCP-LTE Traffic Example
PDCP-LTE Wireshark Notes
 The PDCP-LTE dissector can decode the PDCP-LTE headers but

has limited support for ROHC payloads. There is no support for
ciphering. There is support for reading RLC-LTE frames from:
• DCT2000 log files, or
• using the UDP format defined in packet-pdcp-lte.h. This (BSD-
PDCP-LTE frames in this format.
• Show User-Plane uncompessed data as IP. Default is Off.
• Show unciphered Signalling-Plane data as RRC. Default if Off.
• Attempt to decode ROHC data. Default is Off.
• Try Heuristic LTE-PDCP over UDP framing. Default is Off.
• Which layer info to show in Info column. Default is RLC.
PDCP-LTE Filters and References
 Display Filter
• A complete list of PDCP-LTE display filter fields can be found
in the display filter reference
• Show only the PDCP-LTE based traffic: pdcp-lte
 Capture Filter
• You cannot directly filter PDCP-LTE protocols while capturing.
 External links
(E-UTRA); Packet Data Convergence Protocol (PDCP)
specification
• RFC 3095 RObust Header Compression (ROHC): Framework
and four profiles: RTP, UDP, ESP, and uncompressed
• Example program that generates and sends frames using the
supported UDP framing format
Radio Link Control (RLC) for LTE
 RLC protocol sits between the MAC and PDCP layers in the LTE
air interface (connecting an LTE UE with an eNodeB).
• The MAC-LTE dissector can call the RLC-LTE dissector for
srb1 and srb2 (since it is known that these should be AM). For
signalling PDUs, the RLC-LTE dissector can call PDCP-LTE
for SRB channels, or LTE_RRC for CCCH channels. This is
controlled by preferences (see below).
• A UDP framing format for RLC-LTE has been defined
(described in packet-rlc-lte.h, purely for use with Wireshark)
Traffic Example: RLC for LTE
Wireshark RLC-LTE Notes
 The RLC-LTE dissector can read RLC-LTE frames from:

• DCT2000 log files, or
• using the UDP format defined in packet-rlc-lte.h. This (BSD-
RLC-LTE frames in this format.
 There is also an LTE RLC stats window shown on the next page,
available from the Wireshark Telephony menu. This can be useful
for finding channels where problems are happening, and setting
appropriate display filters.
• The same statistics are available from tshark, using the option -
zrlc-lte,stats
LTE RLC Traffic Statistics Example
LTE-RLC Wireshark Preference Settings
• Do sequence analysis for AM channels. Can be done for either
standalone RLC frames, or those found inside MAC frames.
Default is OFF.
• Do sequence analysis for UM channels. Can be done for either
standalone RLC frames, or those found inside MAC frames.
Default is OFF.
• Call PDCP dissector for SRB PDUs. Default is OFF.
• Call RRC dissector for CCCH PDUs. Default is OFF.
• Try heuristic LTE-RLC framing over UDP. Default is OFF.
• May see RLC headers only. Default is OFF.
• Attempt SDU reassembly. Default if OFF. Will not currently
work with out-of-order PDUs or resegmentation.
LTE-RLC Wireshark Filters
 Display Filter
• A complete list of RLC-LTE display filter fields can be found in
• Show only the RLC-LTE based traffic: rlc-lte
 Capture Filter
• You cannot directly filter RLC-LTE protocols while capturing.
 External links
(E-UTRA) Radio Link Control (RLC) protocol specification
• Example program that generates and sends frames using the
supported UDP framing format
Practical Considerations about
LTE Performance Measurements
Some Realities about Measured
RF Performance Indicators
 Not all UEs and LTE scanners measure the basic performance
indicators in the same way
 The following pages show some of the differences you will likely
encounter with your own measurement equipment
 Practical Advice:
• It is not necessary that your equipment measure the indicators
perfectly, in exact conformity with the definitions
• If you’re looking for perfect equipment, you’ll be waiting a long
time before beginning to optimize your network
• But as long as you use the same equipment for monitoring and
benchmarking, you will have useful and comparable data
• When changing or adding new equipment, compare the results
obtained with the results of the old equipment during
simultaneous measurements; note the differences, and
reconcile
Measurement results with different tools
 Scanners and terminals have their own specific algorithms for
RF measurements.
 RSRP
• Can be measured from the whole bw or from part of the bw.
 RSRQ
• RSSI, used in the RSRQ definition, can be measured from the
whole bw or from part of the bw.
 SINR
• Measured from Reference Signal or from Synchronization
channel.
 Other differences
• Averaging methods
• Sampling rate
• Receiver sensitivity
• Cell info decoding capabilities
RSSI versus RSRP, measurement with
Samsung in fully loaded 10MHz cell
RSRP vs. RSSI vs. Number of RBs
 RSSI rises about 5dB when RB activity increases to 100%, in 10MHz cell
SNR vs. RSRP, measurement,
Samsung BT-3710
 Fading channel measurement, drive test.

RSRQ to SINR mapping
RSRQ to SINR mapping, scanner measurement
RSRP vs. DL throughput
 Example measurement: Drive test, 20MHz BW, ~2.6GHz

 FTP download, no other interfering traffic in the network
SINR vs. DL throughput
 Example measurement Drive test, 20MHz BW, ~2.6GHz
MIMO variants, measurement, Samsung (1)
 Example: RSSI measured by UE
 Note rx power imbalance between receive antenna branches
 Example: RSRQ measured by UE
 Note that no notable RSRQ imbalance between receive antenna branches
 Example: RSRP measured by UE with one external antenna (one
external antenna rx1 + one internal antenna used rx2)
Channel correlation
 Channel correlation impacts on MIMO performance

• If the correlation is high, SM mode doesn’t increse throughput
even with high SINR (compared to Tx diversite mode).
 Channel correlation is not usually reported by DT tools or
scanners.
• Can be estimated by following Rank Indicator (RI) reported by
UE and SINR measurements.
• Some terminals (LG) report correlation matrix to DT tool.
EPA03, change of correlation, MIMO subchannel throughputs,
from fading simulator, LG terminal, 20MHz, 2.6GHz, SINR=25dB
 High spatial correlation causes rank-1 transmission even at high SNR (second stream tput almost zero)
Measurement accuracy requirement, 3GPP TS
36.133 (simplified)
 RSRP absolute accuracy under normal conditions

• ± 6dB intra-frequency and inter-frequency
• Needed for setting random access preamble tx power and triggering
coverage-based handover (A5)
• RSRP relative accuracy between two cells under normal conditions
• ± 2dB intra-frequency, ± 6dB inter-frequency
• For triggering better cell handover (A3)
 RSRP reporting range in signalling (handovers)
Measurement accuracy requirement, 3GPP TS
36.133 (simplified)
 RSRQ absolute accuracy under normal conditions
• ± 2.5dB intra-frequency and inter-frequency
 RSRQ relative accuracy between two cells under normal conditions
• ± 3dB inter-frequency (intra-frequency not defined)
 RSRQ reporting range in RRC signalling (handovers)
Impact of serving cell traffic, SINR
Impact of serving cell traffic, RSRQ
Impact of intra eNodeB interference on SINR
Impact of intra eNodeB interference, SINR
Impact of intra eNodeB interference, RSRP & RSRQ
 PCTel and R&S are

showing similar average
RSRP
 UE used internal antenna
 scanners were connected to
the same external antenna
using a power splitter
 RSRQ values are quite
different for UE, R&S and
PCTel
 RSRP seems like the most
reliable based on this
measurement
Impact of intra eNodeB interference, RSRQ
Impact of inter site neighbor, SINR
 Measurement location is
between sites at the cell
edge
 Serving cell SINR is not
impacted by own cell
traffic.
 Neighbor cell SINR is
decreased by serving cell
traffic.
Driving, idle vs. download RSRP
Some Useful LTE Links and References
 EARFCN calculator – convert between frequencies/channels

• http://niviuk.free.fr/lte_band.php
 Excellent resource grid visualization and configuration explorer
• http://paul.wad.homepage.dk/LTE/lte_resource_grid.html
 A good collection of short explanations on many LTE topics
• http://www.sharetechnote.com/html/Handbook_LTE.html
 Excellent blog from the UK:
• http://radioaccess.blogspot.com/

LTE Messaging Analysis and Performance Optimization PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

LTE Messaging Analysis and Performance Optimization PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Course 508

LTE Messaging Analysis

DOWNLOAD THIS COURSE:

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 1

 Introduction to LTE Performance Optimization

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 2

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 3

 LTE is a complex marriage of advanced radio technology with

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 4

 To most closely understand a user’s experience on the network,

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 5

 How are eNodeB counters used to monitor the performance of the

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 6

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 7

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 8

SGSN GPRS CORE PCRF

Uu Evolved Packet Core

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 9

 How much do you remember about each of these protocols?

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 10

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 11

 Downlink Physical Signals

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 12

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 13

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 14

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 15

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 16

 The mapping of transport channels and UL control information

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 21

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 22

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 23

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 24

 A set of radio quality

 The eNodeB can provide these measurements:

LTE Carrier Received Signal Strength Indicator (RSSI)

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 27

LTE Reference Signal Received

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 28

 RSSI = wideband power= noise + serving cell power + interference

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 30

 LTE Reference Signal Received Quality (RSRQ)

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 34

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 35

 SINR is a more practical measure of signal quality than SNR

September, 2013 Course 508 v2.0 (c)2013 Scott Baxter Page 37

 In a good LTE call, SIGNATURE:

• RSRQ will be -9 or stronger -50 -70 -6 +30 +30

• SINR will be +20 or stronger -60 -80

better than +10 --90 -120

-120 -140 -19.5 -23 -23

RSSI RSRP RSRQ SINR Headroom

September, 2013 508 v2.0 (c) 2013 Scott Baxter 508 - 39

 RSRP will be around or below -50 -70 -6 +30 +30

its noise floor, -135 or weaker -60 -80 +20 +20

-120 -140 -19.5 -23 -23

RSSI RSRP RSRQ SINR Headroom

September, 2013 508 v2.0 (c) 2013 Scott Baxter 508 - 40

included interference -40 -60

normal, well below -9 --90 -120

around 0 -120 -140 -19.5 -23 -23

 The uplink-related “Headroom” RSSI RSRP RSRQ SINR Headroom

driven down, even to 0 or -40 -60

-60 -80 +20