01 - LTE Access Fault Diagnosis ISSUE1.02

LTE Access Fault Analysis
Confidential Information of Huawei. No Spreading Without Permission




 After UE select a suitable cell, it initials attach flow, including the following procedures:
 Random access
 RRC connection setup (RRC cause: MO signaling)
 NAS authentication procedure
 E-RAB setup (Activate default EPS bearer)
 Setup dedicated bearer (Optional, only for some Smart UE that support VoIP)
 Above figure shows the detailed procedure

 If UE request service again while in idle status, it initials “Service Request” procedure
 The whole procedure are very similar as initial attach procedure except:
 The cause of RRC connection is “MO Data”
 No authentication and UE capability query procedure as UE context already exists
in MME

 TAU procedure is a UE idle behavior, ensure that UE location is known by MME. The
scenarios of TAU can be:
 UE initial attach
 UE move to a new TA area
 Periodic TA update



 There are maximum 64 preamble index, indicate all possible time slot for preamble sending
 All these preambles are divided into contention based group and dedicated group.
 UE acquires all RACH configuration in SIB2 message.

 There are five RA preamble formats, which are used for cells of different radii. LTE FDD
supports preamble formats 0-3, and LTE TDD supports preamble formats 0-4. The
preamble format can be set through the PreambleFmt parameter, and the cell radius can
be set through the CellRadius parameter.
 Format 4 is a special RACH preamble for LTE-TDD only.
Preamble
Length TCP TSEQ FDD Cell Radius (R) TDD Cell Radius (R)
Format
0 1ms 103.1 µs 800 µs R ≤ 14.5km 1.4 km < R ≤ 14.5 km

1 2ms 684.4 µs 800 µs 29.5 km < R ≤ 77.3 km 29 .5km < R ≤ 77.3 km
1,600
2 2ms 203.1 µs 14 .5km < R ≤ 29.5 km 14.5 km < R ≤ 29.5 km
µs
1,600
3 3ms 684.4 µs 77 .3km < R ≤ 100 km 77 .3km < R ≤ 100 km
µs
167.9 133.33
4 14.58 µs Not involved. R ≤ 1.4 km
µs µs


 Upon receiving the UE preamble, the eNodeB transmits an RA response over DL-SCH.
 The UE monitors the Physical Dedicated Control Channel (PDCCH) in the Transmission Time
Interval (TTI) until it obtains the required RA response.
 The response contains RA-Preamble Identifier, Timing Alignment Information, Initial UL
Grant, and Temporary C-RNTI.
 If multiple-UE send the preamble with the same RA-RNTI, then eNodeB detects that the
conflict occurs. This conflict will be handled in contention resolution procedure.
 A message on the DL-SCH can carry multiple RA responses to be transmitted to multiple
users.
 For the UE ;
 If the received RA-Preamble Identifier is consistent with the identifier that the UE
previously sent, the UE infers that the response is successful. Then, the UE transmits
uplink scheduled data.
 Otherwise, the response fails. In this case, if the number of random access
attempts is smaller than the maximum, the UE attempts random access again.
Otherwise, random access fails.

 With the grant ,the UE transmits uplink scheduled data over the UL-SCH. This message is
scrambled by temporary C-RNTI. In this message, UE will carry its unique ID for contention
resolution if random access conflict.
 Based on different random access scenarios, the message could be
 RRC connection request
 RRC reestablishment request
 RRC reconfiguration complete (Handover confirmation)
 Other user data
 In case of “RRC connection request” message, UE sends its UE ID to identify the different
UE. This UE ID could be:
 If UE already get S-TMIS from MME, then use S-TMIS as UE ID
 If UE initial attach, UE generate a random number according to its IMSI as UE ID
 In the other case, UE at least send its C-RNTI to identify the different UE

 After the UE sends message 3,the contention resolution timer starts. The UE monitors the
PDCCH before the timer expires. In the following situations, the UE infers that the
contention resolution is successful and it notifies the upper layer and stops the :
 The UE obtains the C-RNTI when monitoring the PDCCH.
 Temporary C-RNTI is obtained when the UE monitors the PDCCH. In addition, the
MAC Packet Data Unit (MAC PDU) is successfully decoded.
 If the contention resolution timer expires, the UE infers that the contention resolution fails.
Then, the UE performs RA again if the number of RA attempts is smaller than the
maximum number of attempts.

 Purpose of RRC connection

 Setup SRB1
 Send NAS message to EPC
 Relevant counters:
 A: RRC connection attempts (L.RRC.ConnReq.Att)
 B: RRC connection setup successful (L.RRC.ConnReq.Succ)


 After UE succeed attach to MME, MME initial the ERAB setup procedure, to setup
dedicated S1 control plane for UE. At the same time, the default PDN connectivity and EPS
bearer will also be setup. After ERAB setup, there is already IP connectivity between UE
and gateway which is called “Always on line” function.
 Relevant counters:
 A: ERAB setup attempts (L.E-RAB.InitAttEst)
 B: ERAB setup successful (L.E-RAB.InitSuccEst)




 Trace of UE capability

 After SRB2 setup, all the NAS message on UU interface in carried by SRB2 with the
message RRC_DL_INFO_TRANSF or RRC_UL_INFO_TRANSF




 Note: Access-related KPIs do not cover all access problems. For example, no KPI is
available for the access problem that a UE fails to search an LTE network and
therefore cannot initiate an access request.








 Procedure introduction: Not the required actions need to be performed. Identifying

whether an access problem occurs only in the top cells or on the entire network helps
determine prerequisites for choosing the necessary actions for solving this problem to
avoid unnecessary actions. A top-cell problem and a network-wide problem are
defined as follows:
 Top-cell problem: If an access KPI on the network is significantly improved
before and after the top 10 cells with the lowest access success rates and
the top 10 cells with the largest number of access failures are excluded or
still meets the requirement after these cells are excluded.
 Network-wide problem: If an access KPI on the network remains basically
unchanged before and after the top 10 cells with the lowest access success
rates and the top 10 cells with the largest number of access failures are
excluded.
 To filter out the top cells, a threshold needs to be properly set on the FMA
tool for the access success rate and the number of access failures,
respectively.
 If the access problem occurs in the top cells, perform action 5 to check weak
coverage, improper network planning parameters, and congestion, action 6
to check the RF channels, and action 7 to check top users. If it occurs on the
entire network, perform action 7 to check top UEs of certain types.

 The access problem scenarios are categorized as deterioration scenarios and

optimization/new deployment scenarios to facilitate selection of the top cells.
 Deterioration Scenarios: The access success rate of the live network deteriorates all of
a sudden and stays persistently at a low level. In this scenario, perform action 2 first to
check the operation logs and external events, such as changes in parameter
configurations, enabling of a new feature, a version upgrade, and a network swap. If
the cause is unclear at the present and cannot be located, the problem is also grouped
to this scenario for further analysis.
 Optimization/New Deployment Scenario: The access success rate is keeping below the
requirement and needs to be improved on the live network. If the problem occurs in a new
deployment or network swapping scenario, KPI mapping needs to be performed.
 Procedure Introduction:
 Analyze the recent trend of access KPIs (including access success rate and number of access
attempts) to determine whether the KPI deteriorates suddenly or gradually.
 If the KPI deteriorates suddenly, check whether an upgrade on the EPC or RAN side or a
network cutover has been performed, or whether the network topology is changed and
perform action 2 to check for operation alarms.
 If the KPI deteriorates gradually, check whether the number of users increases gradually
and whether new types of UEs are released.
 Other KPIs can also be correlated for analyzing the access problem.

 Classify problems based on access failure values and associated KPIs so that actions
to be taken and the sequence of taking actions can be determined. You are advised
to focus on causes and associated KPIs of critical problems and determine whether
inventory optimization is required based on provided standards.




 Procedure introduction: perform this action to check whether a KPI change is

caused by an operation. This action helps check for a chronological corresponding
between a KPI change and a performed operation and therefore is mandatory in a
KPI deterioration scenario. This guide provides the external events that are already
known being factors that may cause KPI changes and alarms that will be reported if a
KPI change occurs. If other events or alarms are also chronologically correlated with a
KPI, they also require special attentions.

 Procedure introduction: Perform this action to check for device faults and alarms
related to a KPI change. A fault that directly affects the KPI or the alarm of such fault
needs to be handled in the first place, with a higher priority over the fault or alarm that
is barely related to the KPI change.











 Procedure introduction: This action checks whether an access problem is caused by

weak coverage by analyzing the top cells. If only top UEs are experiencing weak
coverage, perform the following closed-loop actions to solve this problem.

 This action targets at top cells and is performed in any of the following scenarios:
 1. L.RRC.SetupFail.ResFail returns to a non-zero value and the number of
UEs is limited.
 2. L.RRC.SetupFail.NoReply returns to a non-zero value and the BBP CPU
usage is high.
 3. L.RRC.SetupFail.Rej.FlowCtrl returns to a non-zero value.
 4. L.RRC.ConnReq.Msg.disc.FlowCtrl returns to a non-zero value.


 Procedure introduction: If a problem is network-wide problem, check whether it is caused

by a certain type of UEs. This action helps check whether an access KPI deterioration
occurs due to bad performance of a type of UEs or due to incompatibility between these
UEs and Huawei-built networks. If the problem is directly caused by these top UEs, check
whether a known issue has already been identified for these UEs of a version through the
Headquarters' IOT channel. Then, repeat this problem by using UEs of the version.

 The abnormal E-RAB setup signaling process is as follows: After the EPC delivers the
context setup request message of a UE to the eNodeB, the eNodeB fails to respond to the
message, or the EPC delivers the command to release UE's contexts before the eNodeB
responds to the context response.

 Procedure introduction: This action is required if traffic data analysis determines the cause
of L.E-RAB.FailEst.TNL or low S1 signaling message setup success rate at the top sites for
an access problem. A transmission fault must be cleared in the first place under any
condition. Alarms or faults that are not closely related to the access success rate can be
handled with a lower priority than transmission faults.


 Tracing message
Previous Next

 Message tracing
Previous Next










Action Analysis Results Status

1. The onsite KPI monitoring engineer discovers an extremely
low setup success rate of RRC connections and E-RAB
connections at one site during the monitoring period.
Therefore, this problem is a top-cell problem.
Action 1: 2. The cause of RRC connection setup failures is
performing scope L.RRC.SetupFail.ResFail, which indicates that this problem is
identification, KPI caused by allocation failures of resources for RRC connections. OK
trend analysis, and 3. It is confirmed that this problem coincides with a horse race
cause resolution held at the site area and that the top cell covers the horse
face course.
The maximum number of users is 14 in this cell, which stands
below the allowed limit. Therefore, only required actions are
required based on analysis of action 1.

 Parameter analysis:
 As described in the impact of core parameters, this SRS configuration does not
allow SRS resources of this cell to decrease or increase. Therefore, the number of
users of this cell cannot be dynamically adjusted.
 Before the horse race event, the cell has a limited number of users and therefore
an SRS resource increase is not required. However, the number of users
significantly increases during the horse race, yet the SRS resource increase cannot
be performed.
 Description of the SRSSUBFRAMECFG parameter in the LTE access parameters:
 If SrsSubframeCfg is set to SPC9, the cell subframe cycle is 10 ms and the offset is
0. The cell subframe cycle and offset do not allow a cell migration. Therefore, this
cell does not allow resources of this cell to increase or decrease.


01 - LTE Access Fault Diagnosis ISSUE1.02

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

01 - LTE Access Fault Diagnosis ISSUE1.02

Enviado por

Direitos autorais:

Formatos disponíveis

LTE Access Fault Analysis

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

0 1ms 103.1 µs 800 µs R ≤ 14.5km 1.4 km < R ≤ 14.5 km

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

 Purpose of RRC connection

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

 Procedure introduction: Not the required actions need to be performed. Identifying

Confidential Information of Huawei. No Spreading Without Permission

 The access problem scenarios are categorized as deterioration scenarios and

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

 Procedure introduction: perform this action to check whether a KPI change is

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

 Procedure introduction: This action checks whether an access problem is caused by

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

 Procedure introduction: If a problem is network-wide problem, check whether it is caused