Professional Documents
Culture Documents
Call Drop Analysis
Call Drop Analysis
Call Drop Analysis
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- Parameters involved
• KPIs:
- Important KPIs/Counters
- Target values and NSN and Project References
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- parameters involved
LTE_5025a E-RAB Drop Ratio:(abnormal E-RAB release requests / all E-RAB release
commands)*100%
LTE_5570c E-UTRAN E-RAB active drop ratio with data in the buffer due to RNL Radio Connection with
UE Lost
LTE_5581a E-UTRAN E-RAB Retainability Rate, RAN View, RNL Failure with UE Lost
LTE_5571b E-UTRAN E-RAB QCI1 with data in the queue drop ratio, RAN View, RNL Failure with UE
Lost
LTE_5090b E-UTRAN E-RAB Drop Ratio per Cause RNL (E-RAB drop ratio due to Radio Network Layer
(RNL) cause initiated by eNodeB – visible to NSN user)
LTE_5575a E-UTRAN Total E-RAB Active Time
LTE_5576a E-UTRAN E-RAB Active Time QCI1 Note: For non-GBR data services can be
high because always-on services may keep
LTE_5577a E-UTRAN E-RAB Active Time QCI2 UE all the time in RRC-Connected mode. A
LTE_5578a E-UTRAN E-RAB Active Time QCI3 very small number of drops can result in high
LTE_5580a E-UTRAN E-RAB Active Time nonGBR drop ratio. For example, when user removes
UE from laptop this results in a E-RAB drop
M8008C0 REJ_RRC_CONN_RE_ESTAB (Counter)
For internal use
5 Presentation / Author / Date ©2013 Nokia Solutions and Networks. All rights reserved.
List of important KPIs
Handover Related
Observation:
• The majority of EPS Bearer connection
establishments problems (if RRC SR is good)
indicate the transport or the core network issues
• E-RAB drop ratio depends on RRC inactivity timer
• 3GPP recommends normalizing drops by time
(drops per minute) for non-GBR bearers
NSN Recommendation
Core network KPIs need to be analyzed for further
problem isolation
Example KPI analysis
For internal use
8 ©2013 Nokia Solutions and Networks. All rights reserved.
EPS Bearer Connection Establishment
EPS Bearer Connection Establishment
Success Ratio, Release Ratio & Attempts
E-RAB Drop Ratio, Attempts
Scope:
• KPI LTE_5025d describes E-RAB Drop ration with
out pre-emptions (RAN point of view)
.
Observation:
• The majority of EPS Bearer connection
establishments problems (if RRC SR is good)
indicate the transport or the core network issues
•E-RAB drop ratio depends on RRC inactivity timer
•3GPP recommends normalizing drops by time
(drops per minute) for non-GBR bearers
NSN Recommendation
Core network KPIs need to be analyzed for further
problem isolation
• KPIs:
- Important KPIs/Counters
- Target values and NSN and Project References
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- parameters involved
• When UE is in RRC_CONNECTED and RRC security is active, it can trigger Radio Link
Failure (RLF) and initiate RRC connection re-establishment procedure after following
events (3GPP 36.331, 36.300):
UE EUTRAN
RRCConnectionReestablishment
RRCConnectionReestablishmentComplete
UL-CCCH-Message
message
c1
rrcConnectionReestablishmentRequest
criticalExtensions
rrcConnectionReestablishmentRequest-r8
ue-Identity This is the PCI of the cell where UE
c-RNTI was last successfully connected to. In
Bin : 4C F0 (= 19696) HO case it’s the source cell.
physCellId : 30
shortMAC-I
Bin : AB 7D (= 43901)
reestablishmentCause : otherFailure
spare
Bin : 0 (2 bits)
Data (hex):
09 9E 01 EA B7 D8
For internal use
16 Presentation / Author / Date ©2013 Nokia Solutions and Networks. All rights reserved.
RRC Re-Establishment procedure
Successful
RRC SIGNALING MESSAGE
RRC Re-Establishment message
Time: 16:49:06.085 sets up SRB1 again
RRCConnectionReestablishment (3GPP TS 36.331 ver 8.7.0 Rel 8)
DL-CCCH-Message
message
c1
rrcConnectionReestablishment
rrc-TransactionIdentifier :2
criticalExtensions
c1
rrcConnectionReestablishment-r8
radioResourceConfigDedicated
srb-ToAddModList SRB1 re-establishment in RRC Conn
srb-ToAddModList value 1 Re-establishment message.
srb-Identity :1
mac-MainConfig
explicitValue
ul-SCH-Config
maxHARQ-Tx : n5
periodicBSR-Timer : infinity
retxBSR-Timer : sf2560
For internal use ttiBundling : false
17 drx-Config : release ©2013 Nokia Solutions and Networks. All rights reserved.
-----------------KLIP-----------------------
RRC Re-Establishment procedure
Unsuccessful
UE EUTRAN
RRCConnectionReestablishmentRequest
RRCConnectionReestablishmentReject
Legend
HO Decision
Source C-RNTI, target short
Handover Request User Data MAC-I and source PCI sent
Admission Control and
Resource Allocation to target cell in X2AP HO
TX2RELOCOverall
Handover Request Acknowledge
TX2RELOCexec Req
.RRC Connection Reconfiguration
SN Status Transfer
Data Forwarding
Failes to access target cell
T304 expires
Cell selection to source cell Buffer Packets from
Source eNB
RRC Connection
Reestablishment
Request(Cause: handover
Failure; c-RNTI of source cell)
UE can try re-establishment
Accept RCR
Stop data forwarding
Handover Cancel
to any cell, but only source
RRC Connection
Reestablishment and target cell are prepared
RRC Connection
Reestablishment Complete
RRC Connection
Reconfiguration
RRC Connection
Reconfiguration Complete
radio
normal operation problem no recovery during T310 no recovery during T311 goes back to idle
detection
RRC_CONNECTED RRC_IDLE
• When the downlink radio link quality estimated over the last [200] ms period becomes worse than the threshold Qout,
Layer 1 of the UE shall send an out-of-sync indication to the higher layers within [200] ms Qout evaluation period.
• When the downlink radio link quality estimated over the last [100] ms period becomes better than the threshold Q in,
Layer 1 of the UE shall send an in-sync indication to the higher layers within [100] ms Qin evaluation period.
• The threshold Qout is defined as the level at which the downlink radio link cannot be reliably received and shall
correspond to [10%] block error rate of a hypothetical PDCCH transmission taking into account the PCFICH errors with
transmission parameters specified in Table 7.6.1-1 of 3GPP TS 36.133.
• The threshold Qin is defined as the level at which the downlink radio link quality can be significantly more reliably
received than at Qout and shall correspond to [2%] block error rate of a hypothetical PDCCH transmission taking into
account the PCFICH errors with transmission parameters specified in Table 7.6.1-2 of 3GPP TS 36.133.
• UE timer T310 is started after n310 successive out-of-sync indications from physical layer. Two successive in-
sync/out-of-sync indications from physical layer shall be separated by at least [10] ms.
• NOTE: 3GPP notation [.] means that the final numerical values have not been agreed in the specification.
• Window to estimate if BLER > out-sync threshold is [200ms] Hence: out of last 200 TTIs at least 20
PDCCH have been received in error
• Window to estimate if BLER < in-sync threshold is [100ms] Hence: out of last 100 TTIs at most 2
PDCCH have been received in error
BLER of reference
PCFICH + PDCCH
out-sync
out-sync
out-sync
out-sync
out-sync
out-sync
out-sync
out-sync
in-sync
in-sync
in-sync
10%
2%
>10ms time
NOTE: 3GPP notation [.] means that the final numerical values have not been agreed in the specification.
Reference For
PDCCH and PCFICH configuration used in the BLER estimation is defined by 3GPP
internal use
24 Presentation / Author / Date ©2013 Nokia Solutions and Networks. All rights reserved.
2. RLF due to maximum UL RLC Retransmission reached
normal operation RLC retransmissions until max value no recovery during T311 goes back to idle
RRC_CONNECTED RRC_IDLE
normal operation Attempting PRACH to target cell no recovery during T311 goes back to idle
RRC_CONNECTED RRC_IDLE
normal operation Attempting PRACH to serving cell no recovery during T311 goes back to idle
RRC_CONNECTED RRC_IDLE
- if the re-establishment procedure was initiated due to RRC reconfiguration failure (i.e., the UE is
unable to comply with the reconfiguration), UE sets the reestablishmentCause to the value
'reconfigurationFailure‘
- if the re-establishment procedure was initiated due to intra-LTE handover failure or inter-RAT
mobility from EUTRA failure, UE sets the reestablishmentCause to the value 'handoverFailure‘
- Otherwise UE sets the reestablishmentCause to the value 'otherFailure‘. NOTE: This includes
T310 RLF failure.
Upon finding a suitable cell on an LTE frequency, the UE stops the timer T311, starts
the timer T301 and initiates a contention based random access procedure to enable
the RRCConnectionReestablishmentRequest message to be sent. In the
RRCConnectionReestablishmentRequest message, the UE includes the identity used
100ms (0), 200ms (1), 300ms (2), in the cell in which the failure occurred, the identity of that cell, a short Message
400ms (3), Authentication Code and a cause. Timer T301 supervises the RRC connection
t301 200 ms
600ms (4), 1000ms (5), 1500ms reestablishment Procedure.
(6), 2000ms (7) Start: Transmission of RRCConnectionReestabilshmentRequest
Stop: Reception of RRCConnectionReestablishment
or RRCConnectionReestablishmentReject
message as well as when the selected cell becomes unsuitable. At expiry: Go to
RRC_IDLE
• KPIs:
- Important KPIs/Counters
- Target values and NSN and Project References
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- parameters involved
• Multiple methods (“link monitors”) are defined to detect a radio link problem in the eNodeB. eNodeB
can drop the call due to following triggers
• eNodeB-detected radio link problems
- Uplink PUSCH DTX detection for scheduled uplink data.
- CQI DTX detection for periodic CQI reports in PUCCH and PUSCH.
- Uplink Ack/Nack DTX detection for transmitted downlink data.
- PDCCH Order failure
- SRS RLF
• TA timer expiry
• Maximum RLC retransmissions exceeded
• GTP-U failure
• When UE is scheduled for PUSCH transmission, eNodeB expects to receive UL transmission on the scheduled PRBs
• If signal from UE cannot be detected at all, PUSCH DTX is declared
NOTE: The case where UL TBS is received but it fails CRC check is not DTX (it’s a NACK)
• The result is received by LTE MAC in reliableULtransmissionFlag parameter (which can be seen in UL TTI trace).
• The recovery of the radio link is indicated when for a configurable number of contiguous UL resource assignments data is
detected on PUSCH (ACK or NACK received).
- Defined by parameter rlpDetEndNoUl.
• LTE MAC shall start timer rrmUlPuschDtxTimer with value for the UE to which indication with
reliableULtransmissionFlag=FALSE is received when the previous indication was
reliableULtransmissionFlag=TRUE.
• If the timer rrmUlPuschDtxTimer reaches rlpDetMaxTUl value, LTE MAC shall indicate RLF of
the UE to LTE UEC (UE Control program block) by using MAC_RadioLinkStatusInd message with
rlsCause value RlsCause_PuschRlf_ON.
• LTE MAC shall initialize the counter to zero and reset it after every indication with
reliableULtransmissionFlag=TRUE.
• If the counter rrmUlPuschDtxDetections for the UE reaches rlpDetMaxNUl value, LTE eNodeB
MAC layer indicates RLF to higher layers by using MAC_RadioLinkStatusInd message with
rlsCause value RlsCause_PuschRlf_ON.
• LTE MAC shall count consecutive indications with reliableULtransmissionFlag=TRUE for those UEs
for which the indication is sent and store the counter value to internal parameter
rrmUlPuschTxDetections.
• LTE MAC shall initialize the counter to zero and reset it after every indication of
reliableULtransmissionFlag=FALSE.
vendor-file parameters
in this example:
<p name="rlpDetMaxNUl">3</p>
<p name="rlpDetEndNUl">2</p>
uplink
PUSCH_RLF time
downlink ON
PUSCH_R
LF OFF
UL UL UL UL UL UL UL UL UL UL UL UL UL
grant grant grant grant grant grant grant grant grant grant grant grant grant
• The eNodeB supports CQI DTX detection for periodic CQI reports on PUCCH and PUSCH.
• If MAC layer receives nCqiDtx consecutive reports from UL PHY, the MAC declares CqiRLF_ON
- can be seen in BTS log and Emil
• If the MAC has set CqiRLF_ON for a specific UE and nCqiRec consecutive CQI reports are again
detected successfully for that UE, the MAC sets CqiRLF_OFF
• The parameters nCqiDtx and nCqiRec are in the vendor-specific parameter file
• For both PUSCH and PUCCH the periodic CQI is encoded using a Reed Muller block code and comes
along without any CRC. Hence, the UL PHY indicates a DTX detection for periodic CQI reports on
PUCCH or PUSCH whenever a report is configured but no reliable transmission from the UE could be
detected. So the output of the detector shall be either the detected CQI report or a DTX indication.
• NOTE: CQI_RLF detection does not apply to aperiodic CQI report on PUSCH
For internal use
41 Presentation / Author / Date ©2013 Nokia Solutions and Networks. All rights reserved.
2. Periodic CQI RLF: RlsCause_CqiRlf
Example
CQI_RLF time
ON
LNCEL/cqiPerNp=10ms CQI_RLF
OFF
vendor-file parameters in this example:
<p name="nCqiDtx">6</p>
<p name="nCqiRec">1</p>
For internal use
42 Presentation / Author / Date ©2013 Nokia Solutions and Networks. All rights reserved.
Emil example
Example of
UL Problems
• After DL scheduled data, eNodeB expects HARQ ACK or NACK on PUCCH or PUSCH at known UL
TTI
• The recovery of the RLF is indicated when for a configurable number of contiguous ACK/NACK
opportunities ACK or NACK is detected on PUSCH or PUCCH (no DTX):
- Defined by parameter rlpDetEndNoDl.
• If both counter-based and time-based options are disabled, radio problem detection based on UL
For internal use
44 Ack/Nack is disabled
Presentation completely.
/ Author / Date ©2013 Nokia Solutions and Networks. All rights reserved.
4. PDCCH Order RLF
Source: L2 SFS
• If there DL data in eNodeB buffer and UE is out-of-sync, UE must be brought back to in-sync (time
aligned) with a RA procedure before DL data can be sent
• Signaling of dedicated RA preamble via PDCCH (so-called PDCCH order) is done using DCI format
1A
• In case that PDCCH order fails for a UE (i.e., no transmission of assigned dedicated preamble
detected by eNodeB, or no msg3 transmission) the PDCCH order shall be repeated
noRepPdcchOrder times (R&D configurable parameter, range 0-3, default 1), again using the selected
preamble and considering DRX status of the UE accordingly.
• Final failure of the PDCCH order process shall be indicated as radio link problem to higher layers
with cause “PDCCH order failure” (see UESTATE.1496).
• If inactivity timer for the UE has expired then there is no T_RLF timer involved S1 and RRC
released immediately
For internal use
45 Presentation / Author / Date ©2013 Nokia Solutions and Networks. All rights reserved.
5. SRS RLF
Source: L1 TD SFS
• The eNodeB supports SRS DTX detection for radio link problem detection
• If MAC layer receives nSrsDtx consecutive reports from UL PHY, the MAC declares SRS RLF
• If the MAC has set SRS RLF for a specific UE and nSrsRec consecutive SRS transmissions are
succesfully detected the UE, the MAC sets SRS RLF OFF
- Hence the SRS RLF has similar mechanism as CQI DTX RLF
• The parameters nSrsDtx and nSrsRec are operator-configurable
• default values from RL50 SCF:
<p name="nSrsDtx">50</p>
<p name="nSrsRec">1</p>
<p name="nCqiDtx">50</p>
<p name="nCqiRec">2</p>
<p name="rlpDetEndNoDl">3</p>
<p name="rlpDetEndNUl">3</p>
<p name="rlpDetMaxNoDl">1000</p>
<p name="rlpDetMaxNUl">1000</p>
<p name="rlpDetMaxTimeDl">0</p>
<p name="rlpDetMaxTUl">0</p>
• 3GPP does not specify eNodeB radio link failures, but NSN eNodeB mimics the behavior of the UE
RLF specified in 3GPP.
• When a radio link problem is detected, an eNodeB-internal timer (T_RLF) is started. The timer T_RLF
is stopped when in case of radio link failure recovery.
• For a given UE, T_RLF is started when any of the PUSCH RLF, CQI RLF, SRS RLF or AckNack RLF
is set to ON state
• For a given UE, T_RLF is stopped only if all RLFs are OFF
• When the timer T_RLF expires, the UE is released from the eNodeB using eNodeB initiated S1
release + RRC connection release –> call drop
Only L2 Ack needed for successful RRC Conn Release. If L2 Ack not received after timer tL2AckRrcRel expires
(def=800ms), RRC is released anyway.
NOTE: No RLC Ack needed for RRC Connection Release. No reTx for RRC Connection Release
E-UTRA
RRC_CONNECTED
Expiry of DRX Short Inactivity Timer (intentional)
Timing maintenance issue (unintentional)
Uplink RA SR or downlink
PDCCH order to bring UE
TA TA back in-sync (RL30)
UL in-sync UL out-of-sync
E-UTRA
RRC_IDLE
• As UE detects Out-of-Sync status using a Timing Alignment Timer, the timer shall be started or restarted
whenever an initial TA or a TA update command is received (see [3GPP-36.321], section 5.2). If the timer
expires, the UE detects out-of-sync status.
• 3GPP TS 36.331: Upon receiving a PUCCH/ SRS release request from MAC layer, the UE RRC shall:
- release periodic CQI reporting config, i.e. it stops CQI reporting on PUCCH
- release Scheduling Request Config
• UL TA update is done periodically and in addition on per-need basis. MAC entity provides PHY layer
the information when a TA update is needed together with the TA update value. MAC entity in eNodeB
shall send it to UE via Timing Alignment MAC control element.
• The interval between periodic TA update commands is based on the Timing Alignment Timer reduced
by a configurable offset taTimerMargin.
• Radio L2 SFS: TA command period = TimeAlignTimer – taTimerMargin
• A configurable parameter TimeAlignmentMaxOffset is used to determine the maximum allowed timing
alignment offset before a per-need timing alignment update is required.
• If the TA offset measured by the UL PHY layer is greater than the configurable threshold
TimeAlignmentMaxOffset then a TA command is sent to the UE.
• If the reported TA offset also exceeds a threshold calculated as taSchedulingThreshold =
max(taOffsetSchedMgn, TimeAlignmentMaxOffset +0.5µs), the UL scheduler is informed that the UE
is drifting out of alignment
• When HARQ ACK feedback is received for the TA command then:
- For a per-need TA command and when taSchedulingThreshold (see above) was exceeded: the UL scheduler is
informed that the TA is OK again.
- The periodic timing alignment timer is (re)started.
•If no HARQ ACK feedback is received for a TA command within the maximum number of DL HARQ
transmissions then:
- The TA update command shall be repeated up to a configurable maximum number of times taCommandMaxRetries
or until the timing alignment timer expires; the latest available timing advance estimation shall be used for every
repetition.
• If the maximum number of retries is exceeded or the timing alignment timer has expired, then status
UE UL out-of-sync is detected TatExpiry seen in UDP Log and Emil
• Immediate release of RRC and S1 follows (there is no waiting for T_RLF expiry)
Harq Ack
UE in
TA timer expires
RRC-CONNECTED
TaTExpiry followed by
immediate S1 + RRC
release)
- RLC AM transmitter requests a STATUS PDU from RLC receiver (sets poll bit on in RLC header)
• After the number of bytes transmitted since previous poll exceeds the value of amRlcPBTab3ulPollByte (uplink, ue
cat3) or amRlcPBTab3dlPollByte (downlink, ue cat3), or
• After pollPdu RLC PDUs have been transmitted since previous poll
• in the last data PDU in the RLC transmit buffer
- The RLC AM receiver responds to polling request by transmitting a STATUS PDU which acknowledges successfully
received PDUs and also selectively nacks unsuccessfully received PDUs.
• RLC receiver also sends STATUS PDU if tReord timer expires.
• RLC receiver will not send STATUS PDU more often than interval defined by parameter tProhib.
• NOTE: default PDDB settings tProhib=50ms and tReord=50ms.
- If RLC transmitter receives no STATUS PDU within tPollretr, a new poll request along with unacknowledged data will be
sent to RLC receiver
- RLC AM window size is fixed to 512 RLC PDUs (segments of an RLC PDU are counted as one PDU).
• RLC transmitter will retransmit all data that is NACKed in the STATUS PDU
• Maximum number of UL and DL RLC retransmissions is defined by vendor parameter drbAmMxRtxTh
(default=16)
Ttransfer-1 Twait<= tProhib Ttransfer-2
Rx
R
bi U
LC
ll PD
et
ts
Po LC
St
at
R
us
Tx
time
Polling trigger reached ACKed RLC PDUs can
be removed from buffer
• eNodeB never resumes the SRB/DRB without an intra-cell handover or RRC connection reestablishment
because the affected RLC entity is still blocked
- intra-cell handover cannot be initiated if the event “Maximum number of RLC retransmissions” has
occurred for SRB1 (the RRC message RRCConnectionReconfiguration cannot be sent to UE) i.e. only
applicable for SRB2 and DRBs
SBR ID Usage
0 for RRC messages using the CCCH logical channel e.g. RRC Connection Setup message
1 for RRC messages (which may include a piggybacked NAS message) as well as for NAS
messages prior to the establishment of SRB2 (prior security activation), all using DCCH
logical channel;
2 for NAS messages, using DCCH logical channel. SRB2 has a lower-priority than SRB1 and is
always configured ONLY after security activation.
•
t-PollRetransmit ms120,
t-PollRetransmit is by default set to 100ms for SRB and 120ms for DRB (tPollRetr) pollPDU p64,
• maxRetxThreshold is set to 16 for SRB and also 16 for DRB (drbAmMxRtxTh) pollByte kB500,
maxRetxThreshold t16},
• Note that the parameters above are hard coded for SRB dl-AM-RLC {
•
t-Reordering ms50,
Above means that the RLC (re)transmissions takes t-StatusProhibit ms50}},
• If eNodeB RLC layer notifies that the RLC AM entity of a DRB has reached the event “Maximum
number of RLC retransmissions” for an RLC PDU
- eNodeB starts the timer T_RLC based on the value of the RRC timer T311
- The timer T_RLC is stopped if the eNodeB accepts an RRC message
RRCConnectionReestablishmentRequest from UE or the RLF timer T_RLF has expired
- When the timer T_RLC expires, eNodeB checks whether the timer T_RLF is running:
• If T_RLF is running, eNodeB ignores all subsequent indications that a problem triggering an
RLF has recovered and wait for the expiration of T_RLF or an accepted RRC message
RRCConnectionReestablishmentRequest from the UE
• Otherwise eNodeB sends the S1AP message UE CONTEXT RELEASE REQUEST with cause
“RNL Cause Radio Connection with UE Lost” to MME to initiate the UE release as for the radio
link failure procedure
T_RLC expiry
• eNodeB may receive a “GTP-U Error Indication” on an active (single) S1 bearer (S-GW has rejected
the reception of uplink data packets) - for more details see [DATAPATH SFS].871. In that case
eNodeB shall send the S1AP message UE CONTEXT RELEASE REQUEST with cause “TNL Cause
Transport Resource Unavailable” to MME - for details see [UESTATE SFS].720).
• KPIs:
- Important KPIs/Counters
- Target values and NSN and Project References
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- parameters involved
M8008C5 RRC_CON_RE_ESTAB_SUCC
M8008C7 RRC_CON_RE_ESTAB_SUCC_HO_FAIL
M8008C9 RRC_CON_RE_ESTAB_SUCC_OTHER
ECM_CONNECTED
eNodeB MME
MME initiated EPS bearer release (abnormal)
Abnormal M8006C8 EPC_EPS_BEARER_REL_REQ_RNL
release
M8006C9 EPC_EPS_BEARER_REL_REQ_OTH
• KPIs:
- Important KPIs/Counters
- Target values and NSN and Project References
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- parameters involved
• Counters of group M8009 Intra-eNodeB HO measurement give information per source cell only
• Counters of group M8014 Inter-eNodeB HO measurement give information per source cell only
• Counters of group M8015 give information per neighbor
- M8015C0: Failed intra eNodeB HO preparations
- M8015C1: Intra eNodeB HO attempts
- M8015C2: Intra eNodeB HO successes
- M8015C15: Intra eNodeB HO failures (any reason)
100*sum(SUCC_INTRA_eNodeB_HO) / sum(INTRA_eNodeB_HO_PREP)
RRC Measurement Report M8009 Intra eNodeB Handover Measurements, triggered in source
cell
No Intra-eNodeB
Handover decision
M8009C0 TOT_NOT_START_HO_PREP
Intra-eNodeB
Handover
decision
Admission control and
resources allocation fails
on target cell M8009C3 FAIL_eNodeB_HO_PREP_AC
RAC failure
Intra-eNodeB
Handover
decision
HO preparation not
triggered
M8009C5 FAIL_eNodeB_HO_PREP_OTH
Other reason that does not fit
any other cause
M8007C2 DATA_RB_STP_FAIL
Counter triggered in target cell
RRC Measurement Report M8014 Inter eNodeB Handover Measurements, triggered in source
cell
inter-eNodeB
Handover M8014C0 INTER_eNodeB_HO_PREP
decision
X2AP Handover Request
Admission control
and resources
allocation on target
eNodeB (RAC+TAC) M8014C6 ATT_INTER_eNodeB_HO
RRC Conn Reconfiguration X2AP Handover Request Ack M8007C0 DATA_RB_STP_ATT (triggered in target
cell)
w/ mobilityControlInfo IE
UP Update Response
Path Switch Request Ack
• 100*sum(SUCC_INTER_eNodeB_HO) / sum(INTER_eNodeB_HO_PREP)
Timer tX2RelocPrep
M8014C2 FAIL_eNodeB_HO_PREP_TIME
tX2RelocPrep expiry
X2AP Handover Cancel
For internal use
101 ©2013 Nokia Solutions and Networks. All rights reserved.
Inter eNodeB Handover
Negative 3, Preparation
M8014C5 FAIL_eNodeB_HO_PREP_OTHER
All other failure causes
X2AP Handover Cancel
UE Ctx release
For internal use
103 ©2013 Nokia Solutions and Networks. All rights reserved.
Inter eNodeB Handover
Negative 2, Execution
M8007C2 DATA_RB_STP_FAIL
Timer TX2RELOCexec
RRC Conn Re-Establishment Request (received at any time during preparation or execution)
M8021C21 MRO_EARLY_TYPE1_HO
• LTE533 Mobility Robustness includes counters and Optimizer algorithms for fixing HO problems.
• Failure events are detected by RRC Connection Re-Establishment
• Too late HO
• Too Early HO type I
• Too Early HO type II
• Can be visualised in Optimizer or analyze the counters directly
• LTE_5174a E-UTRAN Number of Late HO Events
• LTE_5175a E-UTRAN Number of Type 1 Early HO Events
• LTE_5176a E-UTRAN Number of Type 2 Early HO Events
• Can help optimizing neighbours and basic RF
• MRO related counters
• M8015C16 LTE_Neighb_Cell_HO MRO_LATE_HO_NB
• M8015C17 LTE_Neighb_Cell_HO MRO_EARLY_TYPE1_HO_NB
• M8015C18 LTE_Neighb_Cell_HO MRO_EARLY_TYPE2_HO_NB
• M8021C20 LTE_Handover MRO_LATE_HO
• M8021C21 LTE_Handover MRO_EARLY_TYPE1_HO
• M8021C22 LTE_Handover MRO_EARLY_TYPE2_HO
• Too late HO : Suitable HO target candidate is reported by UE too late, or not at all.
– UE stays too long in HO source cell – degrading cell quality enforces radio link failure on UE
side
– UE re-establishes connection to another cell
– Could indicate missing neighbours
RLF at UE side
(detected at cell A)
T310 T311
Incremented in cell A
For internal use
108 ©2013 Nokia Solutions and Networks. All rights reserved.
LTE533: Too Early Handover Type I
Feature
• Too early HO Type I : HO triggered too early , UE tries to re-establish to source cell
– UE tries to enter too early the HO target cell – insufficient cell quality enforces HO failure or
radio link failure right after HO completion
– UE re-establishes connection to HO source cell again
RRCConnectionReestablishmentRequest
cause ”HO Failure” sent to cell A
HO procedure start HO failure
from cell A at UE side
T304 T311
UE
Counters:
M8021C21 MRO_EARLY_TYPE1_HO
Incremented in cell A
For internal use
109 ©2013 Nokia Solutions and Networks. All rights reserved.
LTE533: Too Early Handover Type II
Case A
RRCConnectionReestablishmentRequest sent
to cell C
HO procedure start Successful
from cell A HO to cell B
tStoreUeCntxt timer
UE
Counters: cell C sends X2AP HO REPORT
to cell B
M8021C22 MRO_EARLY_TYPE2_HO
Incremented in cell B
For internal use
110 ©2013 Nokia Solutions and Networks. All rights reserved.
LTE533: Too Early Handover Type II
Case B
RRCConnectionReestablishmentRequest sent
Successful to cell C
HO procedure start PRACH phase
from cell A Missing RRC Reconfig
to cell B
Complete in cell B
UE
cell C sends X2AP HO REPORT
to cell B
Counters:
M8021C22 MRO_EARLY_TYPE2_HO
Incremented in cell B
• KPIs:
- Important KPIs/Counters
- Target values and NSN and Project References
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- Parameters involved
• Wrong parameter configuration can increase the call drop rate significantly
• For handover access related drops, the PRACH phase in target cell should be optimized. See call
setup optimization material in this training.
• Prolonging UE and eNodeB initiated drop timers and constants may improve probability of recovery
• Missing neighbors result in UL interference and user-perceived coverage gaps in the network
drops
• The best way to improve retainability is to optimize basic physical RF: improve coverage and
cell dominance!!! “Can’t fix bad RF with parameters (except by fixing missing neighbors).”
• KPIs:
- Important KPIs/Counters
- Target values and NSN and Project References
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- Parameters involved
• KPIs:
- Important KPIs/Counters
- Target values and NSN and Project References
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- parameters involved
• UE received RrcConnection-
Reconfiguration (handover
command) for target cell: PCI 29.
• UE completed the contention-free
random access to the target cell
(preamble id = 45) by receiving
Random Access Response (RACH
RSP) from eNodeB and sent
RrcConnection
ReconfigurationComplete message to
eNodeB.
• RLC layer detected issue on DL data acknowledgements and triggered RLC retransmissions until
maximum number of retransmissions (16) were reached.
- The UE context release was initiated by eNodeB on a source cell with cause: tx2relocoverall-expiry
(tx2relocoverall=T304max+T311+T301+ tx2relocoverallDelta = 5350ms).
• The UE receives successfully random access response from a target cell (C-RNTI=22729) but
RrcConnectionReconfigurationComplete message (Msg3) was never received for some reason (e.g.
interference or poor uplink coverage) by a target cell and thus, the handover was not further proceeded.
No RRC reconfiguration
MaxRlcRetrans Exceeded in a complete message received
source cell in a target cell.
Tx2RelocOverall timer
expires
normal operation Attempting PRACH to serving cell no recovery during T311 goes back to idle
RRC_CONNECTED RRC_IDLE
• The source eNodeB sends multiple X2AP: HANDOVER REQUEST messages but target eNodeB does not
respond with X2AP: HANDOVER ACKNOWLEDGE and thus, after the expiry of tX2RelocPrep timer
(500ms) the X2AP: HANDOVER CANCEL procedure is started.
For internal use
132 / ©2013 Nokia Solutions and Networks. All rights reserved.
Inter-eNodeB X2 Handover
Message Flow
No Handover Request
Acknowledge from
target eNodeB, i.e.
HO cancel handover preparation
fails
• The message: rrcConnectionRelease was sent by eNodeB to release the call after UE successfully
handover from PCI:56 (Suhun1A1) to PCI:4 (Suhun1A0).
tx2reloccomp timer = 2s
• The timer tx2reloccomp setting was changed to 2000ms (max. value) in order to allow more time for MME
for path switch but it failed as well.
- UE is sending consecutive
measurement reports until
RrcConnectionRelease is received
from eNodeB.
- The event A2 is triggered: RSRP 27
(-113 dBm) < threshold4 (-110
dBm)
• The UE sends measurement reports but the eNodeB doesn’t react to them (i.e. it doesn’t start the HO
preparation) because the PCI=168 in the measurement report is not configured as eNodeB neighbour.
• The handover was completed in a target cell (C-RNTI= 14248) by receiving RRC connection reconfiguration complete
message from UE.
• However, UE initiates random access for scheduling requests.
For internal use
145 / ©2013 Nokia Solutions and Networks. All rights reserved.
UE Log: Random Access for Scheduling Request
• The eNodeB detects uplink DTX on PUSCH and indicates radio link problems to higher layers, i.e.
PuschRlf_ON.
• The detection of the radio link problem by the uplink scheduler is based on the comparison of grant
assignment and the DTX detection on PUSCH for the assigned PRBs. The detection shall take into
account the DTX PUSCH indication provided by the physical layer.
• This could occur due to insufficient UE Tx power for PUSCH. The uplink power control parameter for
PUSCH may need to be adjusted.
For internal use
148 / ©2013 Nokia Solutions and Networks. All rights reserved.
BTS Log: eNodeB Detected RLF – CqiRlf
• The eNodeB supports CQI DTX detection for periodic CQI reports on PUCCH and PUSCH .
• The CqiRlf_ON indicates the number of consecutive CQI DTX detections causing radio link failure.
• This could occur due to insufficient UE tx power for CQI reports on PUSCH. The parameter puschCqiOffI
may need to be adjusted based on CQI misdetection on eNodeB or dFpucchF2 for carrying CQI reports on
PUCCH.
• Eventually, the RRC connection re-establishment is triggered by UE due to radio link failure because UE
never received RrcConnectionRelease from eNodeB.
• The UE context was earlier released by eNodeB with cause: radio-connection-with-ue-lost and thus, the
request was rejected by eNodeB.
• KPIs:
- Important KPIs/Counters
- Target values and NSN and Project References
• Optimization actions/analysis
- UE initiated Drop Call analysis: signalling flows and counter triggering
- eNodeB initiated Drop Call analysis: signalling flows and counter triggering
- Drop Call counter triggers
- Handover related Drop Call analysis
• Summary
- Possible Observations and recommendations
- parameters involved