Professional Documents
Culture Documents
1.
2.
3.
Throughput Considerations...........................................................................................................................................3
4.
5.
6.
3.1.
Data Rate......................................................................................................................................................3
3.2.
4.2.
6.2.
CPRI cables..................................................................................................................................................5
6.3.
Ue and RF conditions...................................................................................................................................6
6.4.
IP Settings.....................................................................................................................................................6
6.5.
6.6.1.
6.6.
6.6.1.
6.6.2.
6.6.3.
6.6.3.1.
Traces to see DTX, TA, RxPower PRB allocation RankIndication (RI) :.................................................8
6.6.3.2.
Trace UL grant:........................................................................................................................................9
6.6.3.3.
The trace below shows if there is enough data in the buffer to be scheduled:.......................................9
6.6.3.4.
The trace below shows the reasons for packets discards by eNB:........................................................9
6.6.3.5.
6.6.3.6.
GINR on DL:..........................................................................................................................................10
6.6.3.7.
6.6.3.8.
UL Scheduler Checks:...........................................................................................................................12
6.6.3.9.
Other Checks:........................................................................................................................................12
6.6.3.9.1.
6.6.3.9.2.
The following pmCounters may be used to identify a low data rate from core to eNB:..................13
6.6.4.
References.............................................................................................................................................................................15
1.
2.
Page 1
2/5/2015
Slow
Throughput
issue reported
One
eNodeB
No Subs
affected?
Many or
All
How
many
eNodeB
s
affected
?
Multiple
eNodeBs
Commo
n point
of
failure?
Yes
Yes
Engage other
Core Groups
No
All
eNodeBs
No
Subs
affecte
d?
Multiple
Is this
considere
d an
Outage?
No
Check
eNodeB
for issues
One
Implement troubl
shooting guideli
ne
Check the
Ue config
or laptop
config
Page 2
2/5/2015
2.
3.
Is the issue happening at 1 enodeB, several enodeBs or all enodeBs? (traceroute from SGW S1-U context to
enodeB S1 interface IP can help determine what network devices are common)
4.
5.
6.
When was the last time the throughput was observed to be ok?
7.
What has changed since the last time throughput was observed to be ok?
8.
Does the issue occur during certain times of day (i.e. busy hour)
9.
Does the issue occur during certain times of the week (i.e. During local event)
1. Throughput Considerations
The UE estimates SINR (Signal to Interference Noise Ratio) based on the PSD (Power Spectral Density) of the downlink
Reference Signals (RS) and PSD offset between Physical Downlink Shared Channel (PDSCH) and RS. The SINR is
converted to Channel Quality Indicator (CQI) and reported to the RBS in the Channel Feedback Report (CFR). The CQI
indicates the radio quality, and is used by the link adaptation function to select the transport format matching the channel
conditions. This leads to improved radio resource use.
CFRs contain CQI, and Rank Indicator (RI). RI is used only when a Multiple Input Multiple Output (MIMO) channel is
present. CFRs are transmitted when the RBS triggers one over the Physical Uplink Shared Channel (PUSCH) based on
downlink data activity and the age of the earlier received CFR.
The RBS performs an adaptive adjustment of the SINR derived from CQI to compensate for errors and mismatches, and
fulfills the targeted operating point.
Mapping of CQI to MCS (Modulation Coding Schemes) is performed by DL Link Adaptation, Included are guiding tables
as defined in 3GPP (36213-920).
Since UE will report lower CQI values when using MIMO as opposed to SIMO in same RF environment (SINR), UE will
typically use lower Modulation/MCS. This is due to that the UE will take the inter-stream interference into account when
reporting CQI and for SIMO transmission no such interference will exist and the CQI will typically be higher. For example
when the UE is configured in SIMO it will report CQI 15 but when it is configured in MIMO it will report CQI 10.
Note, further fine tuning of MCSs is performed with HARQ based Outer Loop Link Adaptation (maintain a certain Block
Error Rate).
1.1.
Data Rate
The transport format for the transmission, and the required set of PRB (Physical Resource Block) resources out of the
candidate set, are determined based on the channel measurements provided by the UE in CQI reports and the available
number of bits. Link adaptation will use the smallest amount of PRBs that can empty the buffer. If the source (SGW and
northbound all the way up to the server) is not able to keep the DL RLC buffers full, primarily the transmission bandwidth
(number of PRBs) will be decreased and not the MCS.
Most common reason for not keeping up data rates is:
Page 3
2/5/2015
1.2.
The HARQ outer-loop will adjust the CQI, based on HARQ ACK and NACK, to Link Adaptation in order to maintain same
BLER after first transmission. For example if UE is reporting to good CQI when running the MIMO this feature will see this
is too many NACKs which will trigger decrease of CQI. Therefore BLER should be same for SIMO and MIMO. Change
(decreases) is in the Transport Block Size (TBS).
2.
3.
Note: Please note that MME is handling the signaling part of the network and does not have direct contribution to
throughput.
2.1.
This segment of the network is the air interface between the mobile and the enodeB. Various tools can be used at the Ue
to capture the messaging and RF conditions between the Ue and the enodeB. If these tools are not available a good
place to start is with a Wireshark sniffer capture on the laptop connected to the Ue. One of the tools is LLDM with LG
phone. The tool to decode the LLDM logs can be downloaded from:
\\erinas1.lmc.ericsson.se\LMCY\yr\Integration\LTE\MPCS\Mops and Workshops\UE
2.2.
This segment of the network is made up of routers and switches and may use third party transport products to carry the
traffic. We can ping and traceroute on the enodeB and MPG to help isolate the devices in this segment. If a sniffer
capture is possible that will also help. A sniffer capture at the enodeB and at the MPG is ideal.
Whether or not a sniffer capture is available, use the steps below to troubleshoot this segment of the network and help
determine the problematic device:
1.
2.
From the SGW VRF-S1-U context ping the S1 interface IP of the enodeB
3.
4.
If the delay is large, backup 1 hop in the traceroute list and ping again. Keep doing this until the ping response
time is ok. This will isolate the link that is introducing the delay.
5.
Ping with different size packets see how large the packet can be before it fails. The MTU setting in the network
is 1500 so a ping of 1470 should work fine.
6.
If a large packet ping does not work, there may be MTU size issues.
7.
Determine the maximum size packet that can be used to ping the enodeB S1 interface.
8.
From the traceroute list back up 1 hop and see if you can ping with larger size packets.
9.
Keep backing up through the network to see where the pings start to succeed, this will isolate the device with
the incorrect MTU setting.
If we perform a packet capture on this network segment below is the list of areas we need to monitor and we should ask
for PCAP format of the packet capture which can be analyzed by Wireshark:
1.
At Ue
2.
S1/X2 on enodeB
3.
S1-U on SGW
4.
S5/S8 on SGW
5.
6.
7.
Page 4
2/5/2015
8.
Note: The items marked optional above are signaling interfaces and not directly involved in user payload. It may be
necessary to sniff on these interfaces if there are issues with QOS or other signaling that is not working properly.
2.
3.
4.
5.
6.
Check the SGW to ensure the Ue has the correct bearers and QCI
#show eps ue imsi <IMSI> d
7.
8.
9.
10. Check the MME to ensure the Ue has the correct bearers setup with the correct QCI and it matches the SGW.
#gsh get_subscriber -imsi <IMSI> -dl 2
11. Check the mobility logs and isp logs on the MME
# /tmp/DPE_COMMONLOG/isp.log
# /tmp/OMS_LOGS/mobility_event_log/ready/
Attach Ue
2.
Perform a traceroute from PC attached to Ue to media-server, e.g. FTP-server, HTTP-server where throughput
is suspected to be bad:
In a Windows command prompt:
tracert -d 10.74.3.17
3.
4.2.
When media-server is located close to EPC core - Round-Trip-Time is around 30-40 milliseconds.
CPRI cables
Check that CPRI (Common Public Radio Interface) cables are correctly connected (not crossed between sectors). Effect
of crossing cables can be transmitting of incorrect Physical Cell Identity (PCI). Correct mounting of CPRI cables:
Page 5
2/5/2015
Ue and RF conditions
Requirements for MTU size and TCP Window size settings at laptop
1.
2.
See document Characteristics Requirements for LTE Backhaul (5/100 56-HSC 105 50/1 Uen F) in CPI for additional
details.
Optimal RF conditions:
1.
2.
SNR: maximum DL 15M (if its MIMO: SINR around 8, For Tx div. around 10); UL 7M (it depends on UL SINR,
but approx around 5db DL)
3.
4.
Rank Information: We need to make sure the terminal is in MIMO (no TXD).
This information can be obtained by having LLDM logs from LG phone under the coverage of the site. The Tool can be
downloaded from this link to decode the LLDM logs:
\\erinas1.lmc.ericsson.se\LMCY\yr\Integration\LTE\MPCS\Mops and Workshops\UE
4.4.
IP Settings
1.
2.
3.
Page 6
2/5/2015
4.5.
6.6.1.
dlMaxRetxThreshold
dlPollPDU
headerCompression
0 (NULL)
pelr
rlcMode
0 (AM)
tPollRetransmitDl
50
tPollRetransmitUl
50
tReorderingDl
35
tReorderingUl
35
tStatusProhibitDl
25
tStatusProhibitUl
25
ulMaxRetxThreshold
ulPollPDU
ENodeBFunction=1,RadioBearerTable=default,MACConfiguration=1
=================================================================================
================================
MACConfigurationId
dlMaxHARQTx
dlPathlossChange
tPeriodicBSRTimer
tPeriodicPHRTimer
200
tProhibitPHRTimer
200
tTimeAlignmentTimer
5120
ulMaxHARQTx
=================================================================================
================================
Total: 2 Mos
In the printout above check
Page 7
2/5/2015
SignalingRadioBearer
MACConfiguration
4.6.
6.6.2.
From a DL UPC perspective, the validatorFO is the software entity that orders the SE's for transmission based on weight.
In a HARQ config, the order would be SI - retx - newtx. The following traces can be used to verify the validatorFO
behaviour/decision making.
lhsh gcpu00768 te e all UpDlRrcCPeBl_Ieic
lhsh gcpu01024 te e all UpcDlMacCeFt_UE
lhsh gcpu01024 te e all UpcDlMacCeFt_DL_VALIDATION
6.6.3.
4.6.3.1.
Page 8
2/5/2015
Trace UL grant:
lhsh gcpu01024 te e trace5 trace6 UpcUlMacCeFt_UL_SCHEDULER
4.6.3.3.
The trace below shows if there is enough data in the buffer to be scheduled:
lhsh gcpu01024 te e trace4 UpcDlMacCeFt_DL_SCHEDULER
The trace below shows the reasons for packets discards by eNB:
lhsh gcpu00768 te e trace1 UpDlRlcPeFt_DISCARD
Page 9
2/5/2015
reportList[0] {
puschReport {
meas2DlUlReportType = 2
padding0 = 0
bbUeRef = 201326912
isDtx { isDtx = 0, padding0 = 0 }
rxPower { prbListStart = 1, prbListEnd = 4, rxPowerReport = -695, padding0 =
2908, sinr = 1078027011 }
}
pucchSrReport {
meas2DlUlReportType = 2
padding0 = 0
bbUeRef = 201326912
}
}
}
4.6.3.6.
GINR on DL:
lhsh gcpu01024 te e trace4 UpcDlMacCeFt_DL_SCHEDULER
Page 10
2/5/2015
nrOfPucchReports = 1
totalNrOfReports = 1
reportList[0] {
puschReport {
meas2DlUlReportType = 1
padding0 = 0
bbUeRef = 201326912
isDtx { isDtx = 0, padding0 = 0 }
dlHarqInfo { dlHarqValid = 1, detectedHarqIndication = 0, dlHarqProcessId =
2, nrOfTb = 2, swapFlag = 0, padding0 = 0 }
timingAdvanceError { timingAdvanceError = 0, padding0 = 0 }
cfrPusch { ElibBbBaseCfrInfoS cfrInfo { ri = 7, cfrLength = 118, cfrFormat =
1, cfrValid = 0, cfrExpected = 1, cfrCrcFlag = 0, padding0 = 0 }, cfr[] = [0, 0,
0, 0] as hex: [00 00 00 00 00 00 00 00] }
}
pucchReport {
meas2DlUlReportType = 1
padding0 = 0
bbUeRef = 201326912
isDtx { isDtx = 0, padding0 = 0 }
dlHarqInfo { dlHarqValid = 1, detectedHarqIndication = 0, dlHarqProcessId =
2, nrOfTb = 2, swapFlag = 0, padding0 = 0 }
rxPower { prbListStart = 0, prbListEnd = 0, rxPowerReport = -630, padding0 =
0, sinr = 0 }
timingAdvanceError { timingAdvanceError = 0, padding0 = 0 }
cfrPucch { ElibBbBaseCfrInfoS cfrInfo { ri = 0, cfrLength = 0, cfrFormat =
0, cfrValid = 0, cfrExpected = 0, cfrCrcFlag = 0, padding0 = 0 }, cfr[] = [0, 0]
as hex: [00 00 00 00] }
}
}
}
Note: Check which report (pucch or pusch) is valid:
nrOfPuschReports = 0
nrOfPucchReports = 1
totalNrOfReports = 1
The above print outs shows pucch report is valid.
Page 11
2/5/2015
UL Scheduler Checks:
lhsh gcpu01024 te e trace3 trace4 trace5 trace6 trace7 UpcUlMacCeFt_UL_SCHEDULER
lhsh gcpu01024 te e trace1 trace3 trace4 trace7 trace9 UpcUlMacCeFt_UL_VALIDATION
lhsh gcpu01024 te e trace3 trace4 trace5 UpcUlMacCeFt_UL_LINKADAPTATION
lhsh gcpu01024 te e trace5 UpcUlMacCeBl_SseSession
lhsh gcpu01024 te e trace4 UpcDlMacCeFt_DL_SCHEDULER
lhsh gcpu00256 te e all UpUlPdcpPeFt_DISCARD
lhsh gcpu00256 te e all UpUlRlcPeFt_DISCARD
lhsh gcpu00768 te e all UpDlPdcpPeFt_DISCARD
lhsh gcpu00768 te e all UpDlRlcPeFt_DISCARD
lhsh gcpu00768 te e all UpDlRlcPeFt_RETRANSM
lhsh gcpu00768 te e trace1 UpDlL1*
lhsh gcpu01024 te e trace1 UpcDlMacCeBl
mtd peek -ta ulMacPeBl -signal LPP_UP_ULMACPE_CI_UL_L1_MEAS2_DL_IND -pe 2 -rep
65535
mtd peek -ta ulMacPeBl -signal LPP_UP_ULMACPE_CI_UL_UE_ALLOC_IND -pe 1 -rep 65535
mtd peek -ta ulMacPeBl -signal LPP_UP_ULMACPE_CI_UL_L1_MEAS2_UL_IND -pe 2 -rep
65535
mtd peek -tar ulMacPeBl -sig LPP_UP_ULMACPE_CI_UL_MAC_CTRL_INFO_IND -dir 1
Note! HiCap tracing needed
4.6.3.9.
Other Checks:
Page 12
2/5/2015
Page 13
2/5/2015
By sampling them at, e.g. 10 sec intervals, and calculating the difference the low input can be identified. In such cases the
operator must be notified that its transport network needs corrections. For more details please see PRIMUS solution
SCS1100666:
[http://e-support.ericsson.se/reader_iview/ui/eserver.asp?ID=SCS1100666].
6.6.4.
Troubleshooting on MPG (2010B CP04):
Check S1 interface (enodeB and MME/MPG) and S5/S8 (SGW/PGW) ports/interfaces/connections for errors or
dropped packets:
> #show interfaces
> #show interfaces terse:
Tracing operations provide more detailed information about the operation of the GGSN, its routing-protocols, and
services. It is used as a troubleshooting tool rather than as a tool for continuous information collection
Tracing can be configured to collect general routing information, interface, protocol, or service specific information.
All trace files are created in /var/log unless otherwise specified.
The symptoms of a problem in the network are usually quite obvious, such as the failure to reach a remote host.
Solution: To identify the symptoms of a problem on the network, start at one end of network and follow the routes to the
other end, entering all or one of the following
user@host> ping (ip-address | host-name)
user@host> show route (ip-address | host-name)
user@host> traceroute (ip-address | host-name)
Page 14
2/5/2015
References :
1.
http://lte-plm.rnd.ki.sw.ericsson.se/lte_trsh_wiki/L12A/index.php?n=UseCases.UserThroughputDegraded
2.
LTE-SAE Slow
Throughput_Rev_0.1.doc
Page 15
2/5/2015