05 FO - NAST3104 - E01 - 1 LTE Rate Optimization Analysis 62P

LTE Rate Optimization
Analysis
Objectives
 Learn about how to calculate theoretical peak rates in
an LTE network
 Learn about how to troubleshoot rate problems in an
LTE network
 Learn about common rate problem troubleshooting
methods
 Learn about typical cases for troubleshooting rate
problems in an LTE network
2
Contents
 LTE Peak Rate Descriptions

 Rate Problem Troubleshooting Guidelines
 Common Rate Problem Troubleshooting
Methods
 Typical Rate Problem Troubleshooting Cases
3
Downlink (DL) Throughput
CFI = 2, commercial configuration
© ZTE All rights reserved 4

Up (UL) Throughput

FDD-LTE Physical-Layer DL Throughput
Calculation
1. PSCH and SSCH resource overheads
 Relation between bits per RE and
per sub-frame modulation schemes
 QPSK: 2 (code rate is set to 1)
 16QAM: 4 (code rate is set to 1)
Bandwidth (MHz) 5 10 15 20
 64QAM: 6 (code rate is set to 1)
PSCH and SSCH
Overheads (%) 0.69 0.34 0.23 0.17
 Relation between bits per RE and
MIMO
2. PBCH resource overheads per sub-  Single stream: multiplied by 1.
frame  2 × 2 MIMO: multiplied by 2.
 4 × 4 MIMO: multiplied by 4
Bandwidth (MHz) 5 10 15 20  Relation between bits per RE and
0.63 0.31 0.21 0.16 code rates
PBCH Overheads (%)
 basic value 1 multiplied by a code rate
3. Calculation of bits contained per RE  Example

 Condition: 64QAM 1/1 and 2 × 2 MIMO.
 Calculation result: number of bits/RE = 6
× 1 × 2 = 12
FDD-LTE Physical-Layer DL Throughput
Calculation
4. FDD-LTE physical-layer DL throughput calculation
 Throughput = (12 × (14 – number of symbols used by PDCCH) – 6) × number
of RBs × 6 × (1 – synchronization channel overheads – PBCH overheads) ×
1000
5. FDD-LTE physical-layer DL throughput calculation example

 Condition: 64QAM 1/1, single stream, and 15 MHz bandwidth (CFI = 1)
 Physical-Layer DL Throughput = (12 × (14 – 1) – 6) × 75 × 6 × (1 – 0.0023 –
0.0021) × 1000 = 67.2 Mbps
 Parameter meanings:
 12: number of sub-carriers per RB
 (14 – 1) : number of symbols, indicating overheads excluding those for control
channels
 – 6: subtracts reference signal overheads
 75: number of RBs at 15 MHz
 6: number of bits per RE
 (1 – 0.0023 – 0.0021): subtracts synchronization and broadcast channel overheads
 1000: 1,000 ms

FDD-LTE Physical-Layer UL Throughput
Calculation
1. FDD-LTE physical-layer UL throughput calculation
 Throughput = (12 × (14 – UL reference signal overheads) ) × number of RBs
× number of bits per RB × 1000
2. FDD-LTE physical-layer UL throughput calculation example

 Condition: 16QAM 1/1, single stream, 15 MHz bandwidth
 Physical-Layer UL throughput = (12 × (14 – 2)) × 75 × 4 × 1000 = 43.2 Mbps
 Parameter meanings:
 12: sub-carriers per RB
 (14 – 2): number of symbols, indicating the overheads excluding UL reference signal
overheads
 75: number of RBs at 15 MHz
 4: number of bits per RE
 1000: 1,000 ms

FDD-LTE MAC-Layer DL Throughput Calculation
1. Factors affecting MAC-Layer DL throughput

 Number of PRBs available
 TBS Index
 Code rate
2. Mappings between system bandwidths and PRBs

System Bandwidth 1.4 MHz 3 MHz 5 MHz 10 MHz 15 MHz 20 MHz
Number of PRBs 6 15 25 50 75 100
3. MAC-layer throughput calculation

 The calculation is based on the 3GPP-protocol-36.213 tables related to
Transport Block Size (TBS).

4. The DL modulation code rate is required to be equal to or less than 0.93.

 In protocol 36.213, it is stipulated that a UE will skip decoding a transport block if the DL
modulation code rate is higher than 0.93. Therefore, the MCS value and the number of
RBs assigned will be adjusted during DL scheduling to ensure that the DL modulation
code rate is no more than 0.93.
 Currently, in an existing network, CFI is set to 2. If MCS is set to 28, the code rate will
exceed 0.93. Therefore, the maximum value of MCS is 27.
5. Single user throughput restricted by UE capabilities

Maximum Number of Maximum Number
Maximum Number of Bits
UE DL-SCH Transport Total Number of Supported
of a DL-SCH Transport
Category Block Bits Received of Soft Layers for Spatial
Block Received Within a TTI
Within a TTI Channel Bits Multiplexing in DL
Category 1 10296 10296 250368 1

Category 2 51024 51024 1237248 2
Category 3 102048 75376 1237248 2
Category 4 150752 75376 1827072 2
Category 5 299552 149776 3667200 4

6. Theoretical MAC-layer DL peak-throughput

Single Stream Code Rate
Single Dual
Cell Number of (Resource Used by
MCS TBS Stream Stream
Bandwidt Correspondi Broadcast and Terminal Type
Index Index Throughput Throughput
h (MHz) ng RBs Synchronization Channels
(kbps) (kbps)
Are Ignored)
5 25 27 25 15840 31704 0.83 3
10 50 27 25 31704 63776 0.83 3
15 75 27 25 46888 93800 0.81 3
20 100 27 25 63776 102048 0.83 3
 In the table, the peak throughputs corresponding to different bandwidths are calculated
in the current 3.10.20 version with default settings. The data is mainly used in field
throughput tests for onsite projects to determine whether the actual results are within
normal ranges.
 If the DL SINR is good enough, meaning that the value is greater than 28, the DL BLER is
very low, maybe almost equal to 0, and the actual peak throughput obtained through
tests can be close to the theoretical value listed above.
 If the SINR value is lower, the BLER value will be higher. However, the system AMC
algorithm will try to reduce MCS, thereby controlling BLER within a 10% range. Therefore,
if DL BLER is 10%, the single-stream MAC-layer rate is about MACTBSzie × (1 – 10%)
(kpbs) , and the dual-stream MAC-layer rate is about 2 × MACTBSzie (1 – 10%) (kpbs).
7. Example of calculating the theoretical MAC-Layer peak-throughout of a single

user in a 20 MHz cell
 20 MHz cell (100 PRBs) : Check the table and find that MCS 28 corresponds to TBSize 75376 and the
code rate is equal to 75376/(100 × (168 – 24 – 12) × 6) = 0.95, which is greater than 0.93.
 If MCS Index is to be reduced to less than 27, meaning that TBS Index is 25, single-stream peak-
throughput is 63776 kbps and the code rate is 0.81.
 Single-user MIMO: The maximum user capability of a CAT3 terminal is 102,048 kbps, meaning 102
Mbps. If CFI is 2, the code rate under the TBSize is 102,048/(100 × (168 – 24 – 12) × 6 × 2) = 0.644,
which is less than 0.93.
 20 MHz cell: Single-stream MAC-layer DL peak-throughput per CAT3 terminal is 63.7 Mbps, and the
corresponding dual-stream throughput is 102 Mbps.
 CAT4 terminal: 100 RBs are selected. The maximum value of TBS Index is 26, the corresponding single-
stream throughput is 75 Mbps, and the dual-stream throughput is 150 Mbps, which is not greater than
the maximum bits allowed to be scheduled for CAT4. If CFI is 1, the code rate is 150000/(100 × (168 –
12 – 12) × 6 × 2) = 0.87, which is less than 0.93, meaning that resources are schedulable. Therefore, the
theoretical peak throughput for a CAT4 terminal when CFI is 1 is 150 Mbps.
 CAT4 terminal: If CFI is 2, the code rate is 150000/(100 × (168 – 24 – 12) × 6 × 2) = 0.95, which is greater
than 0.93, meaning that resources are not schedulable. Therefore, reduce the number of RB to 97, and
TBS Index is still 26, single-stream throughput is 71.112 Mbps, dual-stream throughput is 142.248 Mbps,
and the code rate is 142248/(100 × (168 – 24 – 12) × 6 × 2) = 0.90, which is less than 0.93 (schedulable).
It can be seen that the theoretical value for a CAT4 terminal when CFI is 2 is 142 Mbps.

FDD-LTE MAC-Layer UL Throughput Calculation
 Theoretical FDD-LTE MAC-layer ULpeak-throughput per user

 Calculation conditions for the following table:
 CFI = 2
 Default settings for PUCCH parameters are used
 Use category: CAT3
 In the following table, the MAC-layer UL peak throughputs corresponding to
different bandwidths are calculated based on the default settings of PUCCH
and other relevant parameters. The data is mainly used in field throughput
tests for onsite projects to determine whether the actual results are within
normal ranges.
Cell Number of Number of Number of Single Stream Single Stream
MCS TBS Terminal
Bandwid Correspondin RBs Used RBs Used by Throughput Code Rate (SRS
Index Index Type
th (MHz) g RBs by PUCCHs PUSCHs (kbps) Ignored)
5 25 6 18 24 22 9528 0.918981481 3
10 50 6 40 24 22 21384 0.928125 3
15 75 8 64 24 22 34008 0.922526042 3
20 100 8 90 23 21 45352 0.874845679 3

FDD-LTE Application-Layer Throughput
Calculation
 Generally, the Max Transmission Unit (MTU) on a router is set to less than 1500 Byte. Therefore, the TCP/UDP
packet length is set to 1360 bytes for TCP/UDP rate calculation. This is the default MTU setting.
 During TCP/UDP peak rate calculation, transmission delay and retransmission are ignored, but
MAC/RLC/PDCP/IP-layer protocol header overheads are taken into account. Protocol Header: (25 – 27) bytes
= IP(20) + PDCP(1or 2) + RLC(2) + MAC(2 or 3)
 UDP Peak Throughput(M) = MAC Throughput × (1 – Protocol Header/(Protocol Header + UDP packet length))
 TCP Peak Throughput(M) = MAC Throughput × (1 – Protocol Header/(Protocol Header + UDP packet length))
Theoretical
Theoretical MAC DL Peak- Tolerable UDP/FTP
Cell MIMO Minimal Maximal UDP/FTP DL
MAC DL Peak- Throughput DL Peak-
Bandwidt Configurati Overhead Overhead Peak-
Throughput (Mbps) When Throughput
h (MHz) on Coefficient Coefficient Throughput
(Mbps) BLER is 10% (Mbps)
(Mbps)
Single
5 15.840 14.256 0.982 0.980 15.55 13.97
stream
Single
10 31.704 28.534 0.982 0.980 31.12 27.97
stream
Single
15 46.888 42.199 0.982 0.980 46.03 41.36
stream
Single
20 63.776 57.398 0.982 0.980 62.60 56.26
stream
Dual
5 31.704 28.534 0.982 0.980 31.12 27.97
stream
Dual
10 63.776 57.398 0.982 0.980 62.60 56.26
stream
Dual
15 93.800 84.420 0.982 0.980 92.08 82.74
stream
Dual
20 102.048 91.843 0.982 0.980 100.17 90.02
stream
FDD-LTE Application-Layer Throughput
Calculation
Theoretical MAC UL Theoretical Tolerable
Cell
MIMO MAC UL Peak- Minimal Maximal UDP/FTP UL UDP/FTP UL
Bandw
Configu Peak- Throughput Overhead Overhead Peak- Peak-
idth
ration Throughput (Mbps) When Coefficient Coefficient Throughput Throughput
(MHz)
(Mbps) BLER Is 10% (Mbps) (Mbps)
Single
5 9.528 8.575 0.982 0.980 9.35 8.40
stream
Single
10 21.384 19.246 0.982 0.980 20.99 18.86
stream
Single
15 34.008 30.607 0.982 0.980 33.38 30.00
stream
Single
20 45.352 40.817 0.982 0.980 44.52 40.01
stream

Contents

Methods
16
Fishbone Diagram for LET Rate Problem
Troubleshooting

FDD-LTE Rate Problem Causes and
Troubleshooting Flow
 Field FDD LTE rate problems
are generally caused by the
following factors:
 Site or cell alarms.
 Poor radio environments, for
example, heavy interference or weak
coverage, exist in cells or area
where UEs are tested.
 Cell radio-parameter setting errors.
 Test environments do not meet
peak rate test requirements.
 Based on these causes, rate

problems can be
troubleshooted in accordance
with the flow chart on the right.
Test Computer and Terminal Troubleshooting
 Confirm terminal categories (CAT3 or CAT4). If there are multiple

terminals on site, a faulty terminal can be replaced by an
operational one.
 To guarantee the peak rate, test computers must meet relevant
hardware and software requirements. Otherwise, peak rate
performance will be affected.
Hardware Typical Configuration Minimal Configuration

CPU 2.4 GHz, dual-core 2.0 GHz, dual-core
Memory 4 GB 2 GB
Hard disk capacity 320 GB 160 GB
Hard disk speed 7200 rpm 5400 rpm
Standalone video card,
Video card Standalone video card, 512 MB
256 MB
Display resolution 1280 × 800 1024 × 768
Other optional configurations No requirements. No requirements.

Alarm Alarm Analysis
Board communication interrupted
Cell Alarm Analysis Board communication
disconnected
link This alarm is often raised during BPL/CC
board restart.
Received optical signal strength 1.An RRU operates improperly.
abnormal 2.An optical fiber link is disconnected.
Abnormal power received by an 3.An optical module fails.
 To clear eNodeB alarms, optical module 4.A BPL board operates improperly.
verify and analyze CPRI link abnormal

RRU network interrupted alarm
current and historical RRU link disconnected
Board software fault
alarms of the Software operation exception
DL Output Less/Over Power Alarm An RRU failure causes the power to be
problematic sites or cells. abnormal.
Too low or high DL output power The RRU may need to be replaced.
 Focus on the following Remote antenna VSWR alarm
Antenna or feed-line Standing Wave An RRU RF interface and an antenna are
alarms: Ratio (SWR) exceptions not connected or an RF cable is faulty.
1. S1 interface alarms Alarm Alarm Analysis

SCTP coupling broken 1. Coupling parameter setting errors
2. Alarms about direct SCTP association disconnected 2. Unstable transmission system
transmission between BBUs Link broken between the OMM and 1. Network transmission failures
an NE 2. Transmission parameter setting errors
and RRUs Link between an eNodeB and its
OMMB disconnected
3. Power-related alarms Cell setup failure 1.An association is not established.
2.Parameter setting errors exist, for
example, RF-related parameters are not
set.
Typical alarms affecting rates

Radio Environment Check—Interference
Troubleshooting
•1. Query the received power strength over an UL of the current
eNodeB (note that no terminals are allowed to access the
How to determine surrounding area of the test radio environment) through MTS or the
Network Management System (NMS).
UL interference •2. Based on the background noise calculation equation for the
receiver, determine whether any interference exists.
•3. Locate the interference source.
•A DL interference can be relatively easy to be identified. During a

drive test, the theoretical value of SINR can be roughly obtained
How to determine from the measurement results of the primary serving cell and
neighboring cells. If the actual SINR value and the theoretical SINR
DL interference value are quite different, it can be determined that a DL interference
exists. To confirm and locate the problem, shut down the site and
scan the frequency spectrum for interference.
Receiver background noise = Thermal noise + noise coefficient –118.4

Thermal noise = –174 + 10log (B). B: measured bandwidth –121.4
Noise coefficient dB 3
Measured bandwidth MHz 0.18
Radio Environment Check—Radio Problem
Troubleshooting Method
•The weak coverage of an area can be improved by adjusting the
azimuth, downtilt angle, power, or other parameters of surrounding
Weak coverage cells. If there is not an eNodeB that can well cover this area,
recommend the operator to add an eNodeB in this area.
•A typical example is pilot pollution. After determining the primary

Inter-site interference serving cell, adjust the azimuth, downtilt angle, power, or other
parameters of other cells to reduce the interference.
Abnormal interference •Shut down the site during a period when the system is not busy. Scan
the frequency spectrum for interference sources.
source
•Unreasonable handoff settings can also cause poor rates. For

example, if a handoff occurs relatively late, the rates will be very slow
Other problems since the source serving cell SNR is already poor in the handoff
region. In this case, the rates can be improved by appropriate handoff
optimization.

Parameter Consistency Verification
 Parameters related to network traffic are generally set the same among different
eNodeBs across the entire network. To verify the parameters, compare te
parameters of a problematic eNodeB with those of a normal eNodeB to
determine whether the problem is caused by the parameters. Generally, check the
following parameters:
 Number of ports of a transmitting antenna of a cell
 Reference signal power of a cell
 System bandwidth
 Transmission mode
 UL or DL MCS
 Maximum number of RBs that can be assigned to a UE over a UL or DL
 CFI
 PCI
 Noise matrix
 Encryption and integrity protection algorithm
 DL frequency-selection parameters
 Data transmission rates and operation modes of physical-layer ports
 Bandwidth resource group rates

Cell-Tx-Antenna Port Quantity Verification
Number of Tx Antenna Port in Cell is the DL port quantity, which determines the number
of layers for layer mapping, thereby restricts the number of spatial multiplexing codes. If this
parameter is set to 2, the MIMO 2 × 1 or 2 × 2 multi-antenna mode can be used for DL
transmission of the cell, meaning that DL dual-coding dual-stream is allowed.

Cell-Reference-Signal Power Verification
During an onsite peak rate test, UE RSRP must be around –65 dBm. If this cannot
be guaranteed, adjust this parameter based on RRU capability to ensure that UE
RSRP is from –60 dBm through –70 dBm. Meanwhile, check whether UE SINR is
above 22 dB.

System Bandwidth Verification
The maximum system bandwidth of an LTE system is 20 MHz. In single-carrier

mode, there are 100 RBs that can be assigned. If there is no 20 MHz bandwidth on
a site, configure this parameter based on actual situations.

Transmission Mode Verification
Select a proper mode as required, for example, select it to TM3[2]

(internal handoff mode).

UL or DL MCS Verification
Generally, the default setting is used. This parameter can also be modified as required. For
example, if the UL radio network is poor, the maximum UL MCS value can be reduced to lower
the UL error rate and ensure the UL download rate through FTP. If the DL MCS dispatch
fluctuates widely, the minimal DL MCS value can be increased to prevent the system from
dispatching low MCS when the network is good, thereby causing rate deduction.

Verifying the Maximum Number of RBs That Can
Be Assigned to a UE Over a UL or DL
Based on the bandwidth, set the maximum number of RBs that can be assigned.
Use a 20 MHz bandwidth as an example.
1. Set Maximum RBs Allocated for Downlink UE to 100.
2. Set Maximum RBs Allocated for Uplink UE to 100[33].

CFI Verification
"CFI=1" is only used in limiting-rate tests. For common commercial uses, CFI
should be set to the default value 2. DL rates will be affected when sub-frame
control format indicator CFI is changed or the number of resources contained on
the control plane of each sub-frame is adjusted.

PCI Verification
 Ensure that PCIs are planned correctly and there is no

interference caused by the values of “PCI mod 3" being the
same.

Noise Matrix Verification
 Ensure that the noise matrix is set correctly.

Encryption and Integrity Protection Algorithm
Verification
 Recommended configuration:
 Integrity Protection Priority (from High to Low) is set to EIA2.
 Encryption Algorithm Priority (from High to Low) is set to EEA0.

DL Frequency-Selection Parameter Verification
 Downlink PRB Random Select Mode is set to Allocate RB from

Low Frequency
In the current version, TM3 dual-stream DL resources are assigned by TYPE0 (meaning RBG).
Each RBG packet contains four RBs. For bandwidths 10 MHz and 15 MHz, the number of PRBs
cannot be exactly divided by four, so there will be an RBG that only contains three RBs. If DL
PRB randomization is used, there is a high probability that RBGs with only three RBs will be
selected, thereby causing insufficient number of RBs used.
Verifying Data Transmission Rates and
Operation Modes of Physical-Layer Ports
 Verify that the transmission bandwidth of each physical-layer port is 1000 Mbps.
 Verify that the operation mode is self-adaptive, or Gigabit and full duplex

Verifying Bandwidth Resource Group Rates
 Verify that the maximum egress bandwidth of each bandwidth

resource group is 1000 Mbps.

Peak-Rate Test Environment Verification
 Verify that PDN FTP server settings  Verify and test UE settings
are correct.  Verify that UE versions support the
 Server hardware and software current system version.
requirements  Verify that the terminal version query
 NIC settings errors (for example, tool exists and QXDM is installed for
duplexing mode or CRC) Qualcomm chips.
Rate restriction, or packet changes or
CN configuration verification


interception on firewalls
 Verify that CN QCI settings are
 Verify the settings of the computer
correct.
used for peak rate tests.
 Verify that CN AMBR settings are
 Computer hardware and software correct.
requirements
 UE-AMBR
 Hard disk writing capabilities and CPU
 APN-AMBR
capabilities greatly affect rates.
 Processes irrelevant to tests must be
stopped.
 FTP client software settings

Peak-Rate Test Environment Verification
 Verify transmission network bandwidth settings.

 Verify that the bandwidth assigned to the transmission network meets the requirements (100 Mbps or
above)
 Communicate with transmission network engineers to confirm the actual bandwidth assigned to the
eNodeB.
 Use UDP data stream tests to check whether the transmission bandwidth is restricted.

Transmission or High-Layer Status Verification
 The right diagram shows an

LTE system topology. If the UE
wants to access the PDN, the
UE must pass through the Uu
interface to reach an eNodeB,
pass through the S1 interface
to reach the CN, and then
pass through the S8 interface
to access the PDN. The service
will be affected if any step
goes wrong.

Contents

Methods
40
Troubleshooting by Using the Ping Command
 Description of the ping command

 In a DOS window, a simple ping operation can be performed to
test connectivity and calculate statistics.
 Detailed example of the ping command:
 D:\ > Ping 192.21.62.69 -l 500 -n 1000 >> Test0001.txt
 In the command, 192.21.62.69 is the IP address of an FTP server, "-l 500"
indicates to ping 500-byte packets, "l" indicates the number of bytes per
packet, "-n 1000" indicates the number of packet pinging times, and ">>
Test0001.txt" indicates to save the command output to the Test0001.txt file
located on disk drive D. The extension “txt” can be directly changed to
“xls.”

 Function of the ping command in data service problem troubleshooting

 By default, 32-byte Internet Control Message Protocol (ICMP) packets (normally
called small packets) are pinged. If the 32 byte ping command succeeds, basically
it indicates that links on the control plane are good. Large packets, for example,
of 1,500 or 60,000 bytes, or even larger, can also be pinged. In this case, packets
will be split. This can help determine whether the user-plane packet splitting flow
is normal.
 Ping is bidirectional. Ping operates by sending ICMP echo request packets to the
target host and waiting for an ICMP echo reply. Therefore, ICMP packets can be
used to locate user-plane link status by segment. Over a specified link, capture
packets by segment. The abnormal segment that causes a ping failure can be
easily determined so that you will know where to start to troubleshoot the failure.
 Note that the ping command, especially for large packets, may fail in the network
of an operator because large ICMP traffic may have been blocked on a firewall for
security reasons. Take this into consideration when using the ping command to
troubleshoot problems. A ping failure may not necessarily mean a link failure.

 Operation method of the ping command

 On a terminal, ping an application server to capture packets and
troubleshoot faults segment by segment (if MTS tests are passed, air
interface tests are not required). Determine whether packet loss
occurs over an UL or DL, or through the S1 or S8 interface. The
troubleshooting steps are as follows:
1. On the terminal, ping the server. Meanwhile, use WireShark to capture packets
through the terminal and the server. Compare the number of requests sent by the
terminal and the number of requests received by the server to determine whether
faults exist over the UL. Meanwhile, compare the number of replies sent by the
server and the number of replies received by the terminal to determine whether
faults exist over the DL.
2. If the packet loss is caused by the UL, analyze whether the packet loss occurs
through the S1 or S8 interface. On the switch where S1 or S8 is located, mirror the
relevant interface. On the mirrored port, capture the packets to determine where
the problem occurs.
3. Use the same method to troubleshoot DL packet loss.

Troubleshooting by Using Iperf—UDP Data
Stream Creation
 Disconnect an eNodeB and use Iperf to test UDP capacity
 On the OMM server, ping the multi-core boards of an eNodeB (packet size: 6000 bytes).
Without the need to disconnect the eNodeB, the transmission quality can be determined
roughly. But the eNodeB must be disconnected for a transmission capacity test. Remove
the network cable from the eNodeB to be tested. Connect the network cable to a laptop.
On the OMM server, use Iperf to create UDP data streams and them send them to the
laptop to verify whether DL transmission links are restricted. On the laptop, use Iperf to
create UDP data streams and send them to the OMM server to verify whether UL
transmission links are restricted.
 The detailed steps for the DL transmission link check by using Iperf-created UDP data
streams are as follows:
1. Ensure that the laptop is available. Connect the laptop with the network cable that was used to
connect the eNodeB. On the laptop, configure the IP address that was configured on the eNodeB.
2. On the laptop, run the following command: iperf -s -u -i 1 -o<filename>
3. On the back-end OMM server, run the following command: iperf -u -c eNodeB IP address -i 1 -n
100M -b bandwidth -o<filename>
4. On the OMM, send the created UDP data streams to the laptop with the 4 Mbps, 10 Mbps, 20
Mbps, and 26 Mbps bandwidths being used respectively. Record the corresponding test results
and save the snapshots.
 The detailed steps for the UL transmission link check by using Iperf are almost the same,
and the difference is that you should run the iperf -u -c OMM Server IP address -i 1 -n
100M -b bandwidth -o<filename> command on the laptop and run the iperf -s -u -i 1 -
o<filename> command on the OMM server.
Troubleshooting by Using Iperf—TCP Data
Stream Creation
 Disconnect an eNodeB and use Iperf to test TCP capacity
 Remove the network cable from the eNodeB. Connect the network cable to a laptop. On the OMM
server, use Iperf to create TCP data streams and send them to the laptop to verify whether DL
transmission links are restricted. On the laptop, use Iperf to create TCP data streams and send them to
the OMM server to verify whether UL transmission links are restricted.
 The detailed steps for the DL transmission link check by using Iperf-created TCP data streams are as
follows:
1. Remove the network cable from the eNodeB to be tested. Connect the network cable to the NIC of a laptop.
On the laptop, configure the IP address that was configured on the eNodeB.
2. On the laptop, run the following command: iperf -s -i 1 -w 64K -o<filename>
3. On the OMM server, run the following command: iperf -c eNodeB IP address -n 900M -i 1 -w 64K -P 4 -
o<filename>
4. On the OMM server, send the created TCP data streams to the laptop. Save the snapshots in the Iperf GUI
and command window (test copy, pasting, and saving) of the OMM server and the laptop, and on the
DUmeter GUI of the laptop.
 An example of the detailed steps are as follows:
1. Remove the network cable from the eNodeB to be tested. Connect the network cable to the NIC of a laptop.
On the laptop, configure the IP address that was configured on the eNodeB.
2. On the laptop, run the following command: iperf -c OMM server IP address -n 900M -i 1 -w 64K -P 4 -
o<filename>
3. On the OMM server, run the following command: iperf -s -i 1 -w 64K -o<filename>
4. On the laptop, send the TCP data streams to the OMM server. Record the data and Iperf logs.
 If the results of either the UDP or TCP data stream sending test from the OMM server to the laptop by
means of Iperf show that either rate is much higher than the ultimate rate of the eNodeB, it can be
determined that the transmission capacity of the eNodeB is not restricted.

Troubleshooting by Using RnluPerf—Internal
Data Stream Creation Tool
 Embedded network throughput measurement tool—RnluPerf
 If an on-site environment does not support a UDP capacity test by sing Iperf, you can
simulate data streams on the CC board to help locate traffic problems.
 If the data download rate through FTP is slow and the rate obtained through RnluPerf is
normal, it indicates that the link from the CC board, BPL, RRU, antenna, radio
environment, UE, to the laptop is good, and the problem exists over the link from the
optical module on the CC board, optical fiber, transmission network, CN, to the FTP
server.
eNodeB
PDN server
e
CC board r fac
e
nt
S1 transmission ri
connection
BPL board Ai
(CN) ----------------
U SB
QE
User plane
and baseband

Traffic Trace by Using MTS
 The MTS tool can be used to trace and check the traffic of a
single UE.
The statistics show the traffic at each layer of the user plane. The GTPU traffic in the figure is sent by the CN to the
user plane. If the GTPU traffic is far greater than PDCP-layer traffic, it indicates that packet loss is caused by the IU
test for problem troubleshooting. The RLC-layer traffic is the air interface scheduling traffic. If the PDCP-layer
traffic is greater than the RLC-layer traffic, it indicates that the air interface scheduling bandwidth is less than the
© ZTE All rights reserved
sending end traffic, thereby resulting in the packet loss.
TCP Problem Troubleshooting Flow

TCPProblem Troubleshooting Flow
 Use Wireshark to capture packets for analysis

 Telnet 192.254.1.16 and pad MGR.exe to log in to the management process. Type "MirrorToDebug 0,0"
to perform port mirroring on QE. Start Wireshark and capture packets on the debug interface of the CC
board.
 Common TCP problems

 Retransmission of packets lost due to poor wireline and wireless transmission links
 Packet sequence error. If two packets are transmitted in a wrong sequence, it means that both packets
are lost.
 TCP parameter setting error (for example, the slide window size)
 Traffic deduction due to too long round trip time of a packet

Contents

Methods
50
AMBR Setting Error Causes Low UL Rate
 Fault symptom
 At the signal poirt where RSRP is –80 dbm and SINR is 26 dB, perform
throughput tests. The UL rate remains only 1.5 Mbps for a long period, but
the DL rate is always 50 Mbps or higher, which is normal.

AMBR Setting Error Causes Low UL Rate
 Fault analysis
1. Replace the terminal and computer. The fault persists.
2. Check UL-related parameters and find no errors. Send the setting data to an
R&D engineer. Still no errors are found.
3. Test the rate again. Data analysis shows that no packet is lost on each site.
The NMS shows that KPI values are good.
4. MTS data is normal. Capture the signaling of the eNodeB and find that the UE
AMBR is only 188, meaning 1.5 Mbps (the real UL traffic is AMBR × 8). AMBR
is authorized to users through the CN, meaning that the problem is caused
because the rate of the IMSI is restricted on the CN HSS.
5. On the HSS, modify the AMBR permission for the IMSI. Test the rate again
and the UL rate can be around 21 Mbps steadily.

QCI Setting Error Causes Low UL Rate
 Fault symptom
 When a UE uses an UL FTP services in cell 232-2, the UL BLER is 0, but MCS is
always 0 without stage rise. This causes the UL rate to be only 1 Mbps, which
is very low.
 MTS snapshot
© ZTE All rights reserved

 Fault analysis
 Perform UL data stream sending tests and find no rate improvement. Use MTS to trace packets and find
that there are still very few UL packet errors, and MCS is still 0. Forcibly increase UL MCS level stage by
stage and find that MCS can reach 15 steadily and the UL rate can reach about 5 Mbps.
 Capture the DSP output information, and find that the inner-loop MCS value measured by ULPHY is
relatively low. In addition, after the terminal starts the FTP service, the eNodeB determines that the
service type is DCCH without increasing the ACK/NACK step. In this case, the UL MCS value cannot keep
going up.

 Test signaling analysis

 Front-end message analysis
 The messages show that this is a configuration problem. The CN thinks that the
modification of QCI to 5 only improves the service priority, but does not affect FTP
service rates when the network quality is good. But things are different from the
perspective of the eNodeB system. Based on different QCI settings, the eNodeB
configures the UE service on different logical channel groups. This eventually
results in UL AMC outer-loop invalidation.
 On the CN, change the value of QCI from 5 to 9. The rate is recovered to normal.

CN Packet Loss Causes Low Download Rates and
Rate Fluctuation
 Fault symptom
 During an on-site UDP data transmission test, the rate can be 60 Mbps
steadily.
 But the maximum TCP data transmission rate can only reach 20 Mbps, the
minimal rate is only 10 Mbps, the average rate is about 14 Mbps, and the rate
fluctuates constantly.

Rate Fluctuation
 Fault analysis
 Follow the flow for troubleshooting common data transmission problems and cannot
find the cause. Suspect that packets may be lost during transmission or the receiving
window may be shrunk. The problem can be analyzed only after the TCP packets are
captured.
 Capture the packets on the computer of the service server side, the S1 interface of the
eNodeB, and the computer of the UE side. Analyze the packets.
 Check the packets captured from the UE side to see whether any receiving window is
shrunk. Generally, a poor-performance NIC cannot immediately handle the data in the
receiving cache, thereby causing receiving window shrink. After the check, no exceptions
are found.
 Check the packets captured on the service server side to see whether packets are
retransmitted. After the check, it is found that some packets have been retransmitted.
 Calculate all packets and obtain the following information: a total of 82749 packets have
been sent by the server end, a total of 82639 packets have been captured through
eNodeB mirroring, and a total of 82639 packets have been received by the UE side. After
comparison, it can be seen that 110 packets have been lost over the link between the
server side and the eNodeB side. The packet loss rate is 0.13%. Therefore, the problem is
caused by the packet loss on the transmission side.

Rate Fluctuation
 During TCP data transmission, the rate is determined by the sending window and RTT. If
packet loss is detected, the sender will think that the packet is discarded due to network
congestion and will then lower the packet sending rate. That is the fast retransmit and
recovery algorithm in TCP/IP.
1. Retransmit the lost packet and halve the sending window.
2. Set the sending window to the original size. If new packets are lost during the recovery, the sending window will be
halved again and repeat the first step.
 Therefore, every discarded packet greatly affects TCP data transmission rate.
 The following table shows the data measured when packet loss is simulated during TCP data transmission at a
peak rate of 50 Mbps. The data shows the impact of packet loss on the rates. The actual rate corresponding to
the 0.14% packet loss rate is about 10 to 20 percent of the peak rate.
It is found later that the a too high instant rate of the UGW egress will cause packet loss.
After the rate is restricted, no packets are lost and the TCP rate is recovered.
Cable Connection Error Causes Low Single-
Stream Download Rate
 Fault symptom
 An eNodeB has two sectors with a good radio environment. RSRP is about –80 dBm.
SINR is about 30 db. The highest download rate is only about 50 Mbps at the 20 MHz
bandwidth.
 The figure shows that RI is 1 and nothing is displayed for TB1 MCS. This means the low
rate is caused by the single stream over the LTE DL. The field test shows that SINR is
28.2, which means a good radio environment.

 Troubleshooting
 Check the back-end cell parameter settings and find that the MIMO mode is
TM3, and the RS, PA, PB, and other parameters are the same as planned.
 The RSRP difference between the two antenna interfaces is less than 5 dB.
 The RRU power and SWR are normal without "no power" errors.
 Set the MIMO mode to TM1 to send signals in two channels respectively, and
then find that the RSRP difference is not big, and the download rate per
channel is 50 Mbps and 45 Mbps respectively.
 Change the jumpers between the feed line and the antenna of each cell. Test
the rate again and find that the download rate in the area (60° direction) that
was originally covered by cell 1 is normal, but that in the area (350° direction)
that was originally covered by cell 2 is still low. It can be concluded that the
eNodeB operates properly and the problem is caused by the antenna-and-
fee-line systems of the original two cells.

 Perform drive tests for the site and analyze the test data.
 The following figures show the RSRP distribution of sector 2 (PCI 43) and sector 3 (PCI44)
respectively. The two cells cover almost the same area, which indicates that part of the cables
for one antenna-and-feed-line system may be connected to the other system.
 Check the cables and find that a cable for cell 2 is connected to cell 3. Correct the
connections. Perform the CQT test again. The download rates of both cells are recovered.
Sector-2 RSRP Distribution Sector-3 RSRP Distribution

Thank you

05 FO - NAST3104 - E01 - 1 LTE Rate Optimization Analysis 62P

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

05 FO - NAST3104 - E01 - 1 LTE Rate Optimization Analysis 62P

Uploaded by

Copyright:

Available Formats

LTE Rate Optimization

 LTE Peak Rate Descriptions

CFI = 2, commercial configuration

© ZTE All rights reserved 4

© ZTE All rights reserved 5

3. Calculation of bits contained per RE  Example

5. FDD-LTE physical-layer DL throughput calculation example

© ZTE All rights reserved 7

2. FDD-LTE physical-layer UL throughput calculation example

© ZTE All rights reserved 8

1. Factors affecting MAC-Layer DL throughput

2. Mappings between system bandwidths and PRBs

Number of PRBs 6 15 25 50 75 100

3. MAC-layer throughput calculation

© ZTE All rights reserved 9

4. The DL modulation code rate is required to be equal to or less than 0.93.

5. Single user throughput restricted by UE capabilities

Category 1 10296 10296 250368 1

© ZTE All rights reserved 10

6. Theoretical MAC-layer DL peak-throughput

7. Example of calculating the theoretical MAC-Layer peak-throughout of a single

© ZTE All rights reserved 12

 Theoretical FDD-LTE MAC-layer ULpeak-throughput per user

© ZTE All rights reserved 13

© ZTE All rights reserved 15

 LTE Peak Rate Descriptions

© ZTE All rights reserved 17

 Based on these causes, rate

 Confirm terminal categories (CAT3 or CAT4). If there are multiple

Hardware Typical Configuration Minimal Configuration

© ZTE All rights reserved 19

verify and analyze CPRI link abnormal

1. S1 interface alarms Alarm Alarm Analysis

Typical alarms affecting rates

•A DL interference can be relatively easy to be identified. During a

Receiver background noise = Thermal noise + noise coefficient –118.4

•A typical example is pilot pollution. After determining the primary

•Unreasonable handoff settings can also cause poor rates. For

© ZTE All rights reserved 22

© ZTE All rights reserved 23

© ZTE All rights reserved 24

© ZTE All rights reserved 25

The maximum system bandwidth of an LTE system is 20 MHz. In single-carrier

© ZTE All rights reserved 26

Select a proper mode as required, for example, select it to TM3[2]

© ZTE All rights reserved 27

© ZTE All rights reserved 28

© ZTE All rights reserved 29

© ZTE All rights reserved 30

 Ensure that PCIs are planned correctly and there is no

© ZTE All rights reserved 31

 Ensure that the noise matrix is set correctly.

© ZTE All rights reserved 32

© ZTE All rights reserved 33

 Downlink PRB Random Select Mode is set to Allocate RB from

© ZTE All rights reserved 35

 Verify that the maximum egress bandwidth of each bandwidth

© ZTE All rights reserved 36

© ZTE All rights reserved 37

 Verify transmission network bandwidth settings.

© ZTE All rights reserved 38

 The right diagram shows an

© ZTE All rights reserved 39