10 Call Setup & Drop Optimization PDF

WCDMA RF Optimization: Call setup and drop optimization
Chapter 10
Call setup and drop optimization
Page 1
Content
1. Call setup procedure ........................................................................................... 4
1.1. Random Access procedure ........................................................................... 4
1.2. RRC connection establishment ..................................................................... 6
1.3. RAB connection establishment and release ................................................ 12
2. Call setup failure scenarios ............................................................................... 14
3. Call setup optimization ...................................................................................... 15
3.1. Missing neighbour ....................................................................................... 16
3.2. RACH optimization ...................................................................................... 17
3.3. System issue ............................................................................................... 18
3.3.1. RRC setup ............................................................................................ 18
3.3.2. RAB setup ............................................................................................. 21
3.4. Layer 1 synchronization problem ................................................................. 22
4. Call drop ............................................................................................................ 23
4.1. Definition ..................................................................................................... 23
4.1.1. Drive test aspect ................................................................................... 23
4.1.2. Network management aspect ............................................................... 24
4.2. Reasons ...................................................................................................... 26
4.2.1. Poor coverage....................................................................................... 26
4.2.2. Unconfigured neighbour cell ................................................................. 27
4.2.3. Handover .............................................................................................. 29
4.2.4. Interference ........................................................................................... 30
4.2.5. PSC confliction...................................................................................... 33
4.2.6. Engineering error .................................................................................. 37
Page 2
4.3. Analysis ....................................................................................................... 39
4.4. Call drop optimization .................................................................................. 40
Page 3
1. Call setup procedure
1.1. Random Access procedure
The UTRA FDD random access algorithm is a little bit more complex than a simple
slotted ALOHA with centralized access control. Once a terminal obtains permission
to access the PRACH at MAC level (i.e., following a positive outcome of the random
experiment, as described above), the physical layer PRACH transmission procedure
is initiated. The works according to the following steps:
1. For the transmission of the first preamble, terminal picks one access signature of
those available for the given ASC and an initial preamble power level based on the
received primary CPICH power level and some correction factors. To transmit this
preamble, it picks randomly one slot out of the next set of access slots belonging to
one of the PRACH subchannels associated with the relevant ASC. The concept of
access slot sets is illustrated in Figure 4
2. The terminal then waits for the appropriate access indicator sent by the network on
the downlink
AICH access slot that is paired with the uplink access slot on which the preamble
was sent.
Sixteen tri-valued (+1, 0, -1) access indicators fir into an AICH access slot, one for
each access signature.
• If the Acquisition Indication (AI) for the relevant signature signals a positive
acknowledgement (+1), the terminal sends the message after a predefined amount of
time with a power level which is calculated from the level used to send the last
preamble.
• If the AI signals a negative acknowledgement (-1), the terminal stops with the
transmission of preambles and hands control back to the MAC After a backoff period,
which is drawn from a uniform distribution between Nmin and Nmax radio frames, the
terminal may regain access according to the MAC procedure based on persistence
probabilities.
Page 4
• If no acknowledgement is received, then this is taken as an indication that the

network did not receive the preamble. If the maximum number of preambles that can
be sent during a physical layer PRACH transmission procedure is not exceeded, the
terminal sends another preamble with increased power, choosing an access slot in
the same manner as for the first preamble transmission. It then continues by going to
the beginning of step (2).
• If no acknowledgement is received and the maximum number of preambles that can
be sent during a physical layer PRACH transmission procedure is exceeded, control
is handed back to the MAC, where access can be
Page 5
Timing relations and power ramping on the PRACH
Figure 1: Timing relations and power ramping on the PRACH
1.2. RRC connection establishment
A call is an active connection between the UE and the network used to exchange
signaling and data. The exchange of signaling is a prerequisite to establishing a
voice or data call. Hence, analyzing the setup of signaling connections represented
by SRBs is as important as analyzing the establishment of voice and data
connections represented by radio bearers (RBs) and/or radio access bearers (RABs).
Signaling radio bearers are established when an RRC connection between the UE
and the SRNC is set up. This RRC signaling connection establishment is requested
by the UE and executed/controlled by the SRNC.
It does not matter if SRBs are mapped onto common transport channels
(RACH/FACH) or dedicated channels (DCH).
Page 6
RRC Connection Setup & Access and

UE
Active
BTS RNC CN
RRC: RRC connection Request RRC SETUP fails if some of the needed resources (RNC, BTS, AIR, Transport) are
RRC SETUP phase not available. When an RRC setup failure occurs the RNC sends an RRC: RRC
(Resource Reservation in RNC, BTS, Transport) CONNECTION REJECT message to UE
RRC: RRC connection Setup
RRC ACCESS fails if the UE does not reply to RRC: RRC CONNECTION SETUP
RRC ACCESS phase
message with the RRC: RRC CONNECTION SETUP COMPLETE message in
(RNC waits for Reply from UE)
given time, if the BTS reports a radio link synchronisation failure or in an RNC
RRC: RRC connection Setup Complete
internal failure occurs
RRC ACTIVE phase
RRC: Initial Direct Transfer RRC ACTIVE fails when an interface related (Iu, Iur , Iub, or Radio) or RNC internal
RANAP: Initial UE Message
failure occurs, and the failure causes the release of the RRC Connection. When an
RRC active failure occurs, the RRC send a RANAP: IU RELEASE REQUEST to all
UE-CN Signalling involved CNs and waits for RANAP: IU RELEASE COMMAND message (s)
(E.g. RAB Establishment and Release)
RANAP: Iu Release Command
RRC: RRC connection Release RRC ACTIVE release cause can be either ISHO,
RRC: RRC connection Release Complete IFHO, SRSN relocation or pre-emption
Release RRC resources in RNC, BTS,
Transport
Presentation / Author / Date
Figure 2: RRC connection setup & Access procedure
Page 7
RRC Connection Events and KPIs

UE RNC CN
RRC CONNECTION REQUEST
Event 1
Event 1 RRC_CONN_ATT_EST
Setup phase incremented
RRC CONNECTION SETUP Event 2 RRC_CONN_ATT_COMP
Event 2
incremented
Access phase Event 3 RRC_CONN_ACC_COMP
RRC CONNECTION SETUP COMPLETE incremented
Event 3 Event 4 RRC_CONN_ACT_COMP
Active phase incremented
Event 4 IU RELEASE COMMAND
RRC Setup Complete Rate =Sum of RRC_CONN_STP_COMP

Sum of RRC_CONN_STP_ATT x 100 %
RRC Establishment Complete Rate = Sum of RRC_CONN_ACC_COMP x 100 %

Sum of RRC_CONN_STP_ATT
RRC Retainability Rate = Sum of RRC_CONN_ACT_COMP x 100 %

Sum of RRC_CONN_ACC_COMP
Figure 3: RRC connection events and KPIs
The KPI described in Figure 3 are used to indicate whether there’s a failure case or
not
Page 8
If the setup of the RRC connection fails there are three different cases. In case 1 the
RNC is – due to load conditions – not able to offer a sufficient quality for the desired
service in the cell initially selected by the UE. Based on the establishment cause
included in the RRC Connection Setup Request the RNC has already received the
information about why signaling radio bearers are to be established: is it only to
register to the network or does the UE wish to set up a voice or data call? If there are
not enough resources available for the desired service the RRC connection
establishment is blocked by the RNC that sends the RRC Connection Reject
message. Rejecting the desired establishment of an RRC connection is also known
as blocking.
The second failure case is that the UE’s RRC Connection Request is not answered
at all although it is sent several times to the same RNC. The RRC connection setup
procedure on the UE side is guarded by timer T300 and counter N300. The default
value of T300 is one second, the default value of N300 is three. This means that if
the RNC does not answer, the UE will send three RRC Connection Request
messages using a time difference of one second (as shown in Figure 4). If all three
attempts fail the UE falls back into IDLE mode.
Page 9
RRC connection setup procedure
Figure 4: RRC connection setup and success and failure
Page 10
As another failure case it must be taken into account that the UE is not able to
respond to the RRC Connection Request sent by the RNC, because it has again lost
radio contact with cell. Since this failure happens relatively often a number of NEMs
have implemented a proprietary counter/timer function similar to the one in the UE in
their RNC software. In a typical configuration scenario if the UE does not respond
with RRC Connection Setup Complete within one second, then RRC Connection
Setup will be sent again. If a second try is not successful either the RNC will send
RRC Connection Setup a third time and then stop the procedure. From the
perspective of performance measurement software the procedure must be detected
as failed if after the second repetition of RRC Connection Setup plus waiting a typical
maximum response time (not more than one second) there is still no answer from the
UE as illustrated in Figure 5. RRC Connection Setup ‘no answer’ failure.
UE does not answer RRC Connection Setup
Figure 5: RRC connection failure in case “no answer from UE”
Page 11
1.3. RAB connection establishment and release
Establishment of voice and data calls can be checked by analyzing radio bearer
setup or radio access bearer setup procedures. From the protocol point of view an
RAB Establishment Request sent on Iu triggers the setup of the radio bearer on the
lub/Uu interface and a successful RB set up triggers the successful completion of
RAB Establishment. For reasons of root cause analysis it makes sense to analyses
both procedures (but do not add counter results). An analysis focused on the user
perceived quality of service needs to look at only one procedure on one interface.
Regarding aggregation levels it makes sense to show the analysis of this procedure
related to involved network elements: the UE, SRNC, MSC and/or SGSN.
Aggregation on cell level must take into account that when RRC Radio Bearer Setup
is sent the UE might already be in soft handover situation (in contrast to GSM where
handovers are only necessary if traffic channels are already set up). This means that
one and only one RRC radio bearer setup procedure is always performed, but
identical transport blocks containing segments of the same involved RRC messages
are often seen transmitted on multiple lub/Uu interfaces simultaneously.
Page 12
RAB Setup & Access and Active

RAB Access failures are not so
Common
UE BTS RNC CN
RAB SETUP fails if some of the needed resources (RNC, BTS, AIR, Transport) are not
RRC Connection Active Phase, UE-CN Signalling
available. When an RAB setup failure occurs the RNC sends a RANAP: RAB ASSINGMENT
RESPONSE message to the CN with an appropriate failure cause
RANAP: RAB Assignment Request
RAB SETUP phase
RAB Setup time
(Resource Reservation in RNC, BTS, Transport) RAB ACCESS fails if the UE replies with an RRC: RADIO BEARER SETUP FAILURE
RRC: Radio Bearer Setup message or the connection cannot be established in a give time. When a RAB access failure
RAB ACCESS phase occurs, the RNC sends a RANAP: RAB ASSINGMENT RESPONSE message to the CN
(RNC waits for Reply from UE) with an appropriate failure cause. Immediately after this, the RNC sends also a RANAP: IU
RRC: RB Setup Complete RELEASE REQUEST to the CN and waits for RANAP: IU RELEASE COMMAND message
RANAP: RAB Assignment Response
RAB ACTIVE phase
(User Plane Data Transfer)
RANAP: RAB Assignment Request with IE: RAB reconfiguration RAB ACTIVE fails when an interface related (Iu, Iur, Iub, or Radio) or RNC internal failure
RAB Holding Time
occurs, and the failure causes the release of the RAB connection.
RAB Reconfiguration Actions
(Reconfigure RAB resources in RNC, BTS, Transport) • If the UE has more than one RAB connection and the failure is not so critical that it would
RRC: RB Reconfiguration lease to an RRC Connection drop, only the failed RAB connection is released. The RNC
RRC: RB Reconfiguration Complete sends a RANAP: RAB RELEASE REQUEST message to the CN and waits for a RANAP:
RANAP: RAB Assignment Response RAB RELEASE COMMAND or RANAP: IU RELASE COMMAND from CN
RANAP: RAB Assignment Request with IE: RAB Release • Otherwise, both the RRC connection and RAB connection (s) are released. The RNC send
RRC: Radio Bearer Release a RANAP: IU RELASE REQUEST message to the CN and waits for a RANAP: IU
RRC: Radio Bearer Release Complete RELEASE COMMAND MESSAGE from the CN
RANAP: RAB Assignment Response
Release RAB resources in RNC, BTS, Transmission
Figure 6: RAB setup & Access and active
Page 13
2. Call setup failure scenarios
Call Setup Failure Scenarios Summary

–RF issue
• Interference / Dominance / Coverage
• Missing neighbour
–System Issue - BTS
• No response to “RRC Connection Request”
• “RRC Connection Reject” to “RRC Connection Request”
–System issue - RNC
• “CC Disconnect” after “Call Proceeding” due to “DL RRC Connection Release”
–Core NW
• “CM Service Abort” after “CM Service Request”
–System issue (test number)
• “CC Disconnect” after “CC Progress”
Figure 7: call setup failure scenarios summary
Page 14
3. Call setup optimization
Start
Best server’s Coverage Optimization

No
RSCP > -102dBm
Missing No
Dominance Optimization
Yes Neighbour ?
Best server’s No
Ec/No > -12dB Yes Neighbour list Optimization
Yes
UL coverage & RACH
parameter. Optimization No AICH(ACK) received? Report & Finish
(changing serving cell) (Check failure cause)
Yes No
“RRC Connection No “RRC Setup
Setup” received? Reject” received?
Yes
AC optimization (check PrxNoise
Report & Finish No (DCH) “RRC Connection setup Yes & interferer around BTS)
(Reason of problem: L1 sync fail) Completed” sent from UE?
Yes Report & Finish
Report & Finish No “Radio Bearer setup

(Check failure cause) failure”Received?
Yes
Report & Finish
Check failure cause
(Not radio problem/cell update)
Figure 8: call setup failure Analysis process
Page 15
3.1. Missing neighbour
Call setup failures – Missing

Neighbour
-Missing neighbour analysis over the whole route (3G-3G, 3G-2G)

-Search for failures due to missing 3G-3G neighbours
-Search for failures due to missing 3G –2G neighbours
– It is suggested to place 2G scanner to the test vehicle
Figure 9: Call setup failure- missing neighbor
Page 16
3.2. RACH optimization
The purpose of this activity is to check the Random Access Process is working
adequately by investigating whether AI (Acquisition Indicator) has been received
through DL AICH
If AICH was not received by UE, the cause of the problem can be classified into:
– Inadequate RAN parameter related to Random Access: RAN parameter

settings for pre-amble transmission or open loop power control
information is not correct.
– UL Coverage limit: UL coverage of UE is smaller compared to serving

cells DL coverage so that UE’s Tx power cannot reach serving cell.
RACH optimisation
No
Max UE Tx power hit To increase PRACH_Preamble_retrans
the UE_P_MAX? Or PowerRampStepPRACHPreamble
Yes
Yes
Is UL Interference Report there might be an interfering
abnormally HIGH? source Nearby the serving cell
No
Change the Serving cell to cover the problem Area

=> UE is too far to reach the serving cell
Figure 10: call setup failure- RACH optimization
Page 17
3.3. System issue
3.3.1. RRC setup
UE has the appropriate DL/UL coverage but if RNC does not allow to set up the
RRC connection of the requested RAB (Radio Access Bearer), Call setup will fail.
Admission Control (AC) is involved in RRC connection setup. AC can reject RRC
reject RRC connection Setup due the DL Load, UL load or DL Spreading codes
– Marginal Load Area:
• If measured UL (PrxTotal) or DL (PtxTotal) load exceeds target

thresholds (PrxTarget and PtxTarget) AC can still admit new
RAB to the cell if a new non-controllable load keeps below target
thresholds (in practice this means that AC can admit only new
controllable load RABs i.e. NRT RABs)
– Overload Area:
• If measured UL (PrxTotal) or DL (PtxTotal) load exceeds

overload thresholds (PrxTarget + PrxOffset and PtxTarget +
PtxOffset) then AC can't admit more RABs to the cell
During the pre-optimization phase it is unlikely that AC will stop an RRC connection
setup during the drive testing because there are normally very few UEs in the
network. (Traffic loading is trivial)
However, it should be checked that measured PtxTotal and PrxTotal are less than
PtxTarget (e.g. 40dBm) and PrxTarget (e.g. 4dB, 60% loading) respectively.
– If DL AC does not allow RRC setup check the Tx power of WBTS, # of

channels transmitted, Signaling messages.
– If UL AC does not allow RRC setup: Check out if there is an interfering

source nearby the serving cell.
Page 18
System Issue
No response to “RRC Connection Request”
– Good RF conditions
– Wrong MHA settings or cable loss settings can cause the site
not to “hear” the UE
– PrxNoise statistics, receive link parameters and HW units to be
checked (faulty MHA, wrong MHA parameters, wrong cable /
feeder loss parameters, faulty units)
Figure 11: System issue-no response to “RRC connection request”
Page 19
System issue
“RRC Connection Reject” after “RRC Connection Request”
– Good RF conditions
– Admission Control can reject too many (or admit too many)
connection requests due to wrong PrxNoise measurements.
– PrxNoise statistics, receive link parameters and HW units to be
checked
Figure 12: system issue-RRC connection reject
Page 20
3.3.2. RAB setup
System issue
RNC
-“CC Disconnect” after “Call Proceeding”
-Good RF conditions
-Failures in RAB setup occur between the “RAB Assignment Request”
being received from Core Network and the RAN sending out Radio
Bearer Setup. Therefore the failure is between BTS and Core Network.
Core NW
“CM Service Abort” after “CM Service Request”
Good RF conditions
“Security Mode Command”-message not received by UE, thus the
failure is believed to be at Core Network.
Figure 13: System issue in RAB setup
Page 21
3.4. Layer 1 synchronization problem
Layer 1 sychronization (slot/frame) failure
If “RRC Connection Setup” was received by UE but UE does not send

“RRC Connection Setup Completed”, we will report “L1
synchronization failure” and have to check L1 system messages.
Figure 14: Layer 1 synchronization failure
Page 22
4. Call drop
4.1. Definition
4.1.1. Drive test aspect
Air interface signalling at the UE side: Call drops refer to call releases caused by
Not Normal Clearing, Not Normal, or Unspecified when the message on the air
interface satisfying any of the following three conditions:
-The UE receives any BCH information (system information).
-The call is released for Not Normal and the UE receives the RRC Release
information.
-The UE receives CC Disconnect, CC Release Complete, and CC Release

information.
Signalling recorded at the RNC side: Call drops refer to call releases when the
RNC has sent the Iu Release Request to the CN through the Iu interface, or when
the RNC has sent the RAB Release Request information to the CN through the user
panel.
Page 23
4.1.2. Network management aspect
The definition of call drop in a broad sense contains the call drop rates at both the
CN and UTRAN sides. Since the network optimization focuses on the call drop rate
at the UTRAN side, this document only focuses on the KPI analysis at the UTRAN
side. The KPIs at the UTRAN side refers to the number of released RABs of different
services triggered by the RNC. Two aspects are involved:
(1) After the RAB is established, the RNC sends the RAB RELEASE REQUEST
information to the CN.
(2) After the RAB is established, the RNC sends the IU RELEASE REQUEST to the
CN, and then it receives the IU RELEASE COMMAND from the CN. The statistics
can be collected based on specific services. Meanwhile the traffic statistics also
imply reasons that the RNC triggers the release of the RABs of different services.
CSRabrelTriggedByRNC contains the number of RABs included in RAB

RELEASEREQUEST for CS services and that included in IU RELEASE REQUEST
for CS services.
RabrelTriggedByRNC contains the number of RABs included in RAB

RELEASEREQUEST for PS services and that included in IU RELEASE REQUEST
for PS services. It should be specified that the RNC traffic statistics calculates the
times of call drops through the signaling at the Iu interface, and counts the number of
RAB RELEASEREQUEST and the number of IU RELEASE REQUEST initiated by
the RNC. While call drops in the drive test aspect emphasizes the information at
the air interface and non-access stratum and their cause value. It is different from
call drops at the OSS side
Page 24
call drop from network management aspect

The defintion of the network managment
SRABSetup
 CSRabrelTriggeredByRNC+1:( Iu interface
signaling at the RNC side)
• When the RNC send the Iu Release Request or RAB Release Request
message to the CN.
Figure 15: call drop from network management aspect
Page 25
4.2. Reasons
4.2.1. Poor coverage
The decision whether it is problem of uplink or downlink poor coverage is based on

the power of dedicated channel before call drop.
UL Poor Coverage:
-TX power reaches the maximum
-UL BLER is poor
-NodeB report “RL failure”
DL Poor Coverage:
-TX power reaches the maximum
-DL BLER is poor
Scanner:
If the RSCP and Ec/Io of the cell with the best coverage are poor, you can infer that
the coverage is poor.
Page 26
Call drop caused by poor coverage
Figure 16: call drop caused by poor coverage
4.2.2. Unconfigured neighbour cell
4.2.2.1. Missed neighbour cell
Neighbour cell optimization is an important link of radio network optimization.

If certain cells should be included but excluded from the neighbour cell list of one
cell, then call drop would happen and the interference in the network would also
increase and system capacity would be impacted. Therefore, neighbour cell
optimization is an important part of the engineering optimization. It is easy
to estimate whether the cell is configured with any neighbour cell, and you
can playback the call drop data and analyse the scanner data.
During the drive test, the UE would acquire the neighbour cell list from the NodeB,
and the scanner would scan the 512 PSCs and record the Ec/Io. If one of the PSCS
is not included in the neighbour cell list, and its pilot strength is stronger than the
threshold, and the phenomenon lasts for a few seconds, then the missed neighbour
cell problem exists.
Page 27
4.2.2.2. Removal of key neighbour cells
Caused by combination of macro diversity Assign the priority of the neighbour cell
when performing the initial neighbour cell planning, then optimize the priority and
number of neighbour cells periodically as the traffic volume increases.
4.2.2.3. Untimely update of the external cell information
Check the external cells of the RNC periodically, and ensure the cells in the list are
correct.
Unconfigured negihbour cell
-Missed neighbor cell
-Removal of key neighbor cells
-Untimely update of the external cell

information
Figure 16: Unconfigured neighbor cell
Page 28
4.2.3. Handover
Uncomplete handover process
The handover process is incomplete Radio Environment

becoming bad, UE can not receive the “Active Set Update”
Figure 17: Uncomplete handover process
Page 29
Ping-pong Handover
In a short time, UE send different Report for delete or add
cell A
Figure 18: Ping-pong handover
4.2.4. Interference
Distinguish the UL and DL interferences. The interferences from the UL and DL

would both lead to call drop. Generally, when the CPICH RSCP of the active set is
large than -85dBm, and the comprehensive Ec/Iois lower than -
13dB, call drop occurs, then the call drop is caused by the DLinterference. Note that
when the handover is not timely, the RSCP of the serving cell may be good, but the
Ec/Io is bad. However, the RSCP and Ec/Io of the monitored set are both excellent
under this condition. When the UL RTWP is 10dB higher than the normal value,
which is -107~-105, and the interference duration is 2s or 3s longer, call drop may
happen and the problem must
be solved.Two reasons may cause DL interferences, which are pilot pollution and mi
ssedneighbor cell. The missed neighbour cell has already been discussed in the
above partand would not be repeated here. In the pilot pollution area, signals of
multiple cells exist, the RSCP of these cells is good, while Ec/Io is bad, the UE would
frequently reselect the neighbour cell or perform the handover, and the incoming and
Page 30
outcoming of calls can hardly reach the UE. Generally, three factors would lead to
pilot pollution in the network.
of sites at a high location
NodeBs in ring-shaped distribution
Wave-guide effect, large reflectors, and some other effects that may
cause the distortion of signals. The typical feature of DL call drops is that the
RNC sends the Active Set Update message, while the UE cannot receive it,
then the call is dropped for RL Failure. You can judge whether the UL
interferences exist by the Average RTWP and Max RTWP on the OMC-R. For an
idle cell, the Average RTWP is about -105dBm; for a cell carrying 50% of UL load,
the Average RTWP is around -102dBm. If the Average RTWP of an idle cell exceeds
-100dBm, we can believe that UL interferences exist. The UL interferences make the
UL TX power of the cell in connected mode increase, and then an excessively high
BLER is generated. Then call drop happens. During handover, the newly-added link
is out of sync for UL interferences, which further leads to failed handovers and call
drops. The UL interference may be intra-RAT or inter-RAT interferences. In most
cases, the UL interferences are inter-RAT interferences
Page 31
Drop call caused by interference

 Reasons for Pilot Pollution:
Cross-cell coverage of high Node-B
Node-B in ring layout
Signal distortion caused by street effect or strong reflection
 Judgment of DL interference:
CPICH RSCP of the active set is large than -85dBm
Ec/Io is lower than -13dB
 Reason of DL interference:
Pilot pollution
Unconfigured neighboring cell
 Judgment of UL interference:
The average RTWP of an idle cell exceeds -100dBm
The max RTWP is around -90dBm
 Reason of UL interference:
Intra-RAT interferences
Inter-RAT interferences.
Figure 19: drop caused by interference
Page 32
4.2.5. PSC confliction
When analyzing such call drop, check Cell ID in the call drop signaling besides PSCs
because the neighbor relation is identified by Cell ID.
 Cell A and Cell B are configured as neighbor cell for each other
Cell A and Cell B (source cell) are configured as neighbour cell for each other,
however, the geographical distance between Cell A and Cell B is huge. Cell A and
Cell C has the same PSC (for instance PSC=123), and Cell C and Cell B (source
cell) is very close, however, Cell C and Cell B are not configured as neighbour cells
for each other. Under this situation, the UE detects signals from Cell C and sends
Event 1A request to be soft handed over to Cell C. The PSC in the Event 1A request
is 123. After receiving the Event 1A request, the RNC checks from the neighbour cell
list of Cell B (source cell) for cells with PSC of 123, then it finds Cell A. Then the
RNC tries to build the radio link on Cell A. The RNC instructs the UE to add Cell A to
its active set. Then, the update of the active set times out for the cell measured by
the UE is different from the cell where the radio link is built.
Page 33
Cell A and Cell B are configured as

neighbor cell for each other
Figure 20: cell A and cell B are configured as neighbour cell for each other
 Cell C and Cell B are not configured as neighbor cells for each other
In this scenario, the UE has established the radio link with two cells, Cell B and
Cell C. Cell A is the neighbour cell of Cell B, and Cell D is the neighbour cell of Cell
C, and these two cells have the same PSC. When the UE is in soft handover state,
the RNC would combine the neighbour cell lists of Cell B and Cell C, then the same
PSC problem would happen.
Page 34
Cell C and Cell B are not configured

as neighbor cells for each other
Figure 21: Cell C and Cell B are not configured as neighbor cells for each other
 Cell A and Cell C have the same PSC
Cell B and Cell D are not configured as neighbour cell for each other, however,
these two cells are both included in the active set owing to the third-party handover
among Cell B, Cell C, and Cell D. Cell A is the neighbour cell of Cell B, and Cell E is
the neighbour cell of Cell D, and these two cells have the same PSC. The RNC
would combine the neighbour cells of Cell B, Cell C, and Cell D in the active set,
then the same PSC problem may occur.
Page 35
Cell A and Cell C have the same PSC
Figure 22: Cell A and Cell C have the same PSC
Page 36
4.2.6. Engineering error
4.2.6.1. Reversely-connected antenna
You can check whether the diversity is reversely connected by the PSC distribution
figure of the drive test data.The antenna would only generate power when UEs try to
access the network, and the measured value of the power equals to the
demodulation power. You can check the ratio of two antennas, if the power of one
antenna is lower than the other one in a long period of time, then the diversity must
be reversely connected.
4.2.6.2. An excessive VSWR
If the VSWR is large than or equals to 1.4, then it must be adjusted.
4.2.6.3. Multi-band antenna problem
In the network of some cities, multi-band antennas exist. The operator usually
refusesto adjust the parameters of the multi-
band antenna for fearing of affecting thesubscribers of the existing 2G network. Then
pilot pollution or overshooting may occur. To solve this problem, you should try to
persuade the operator to change the antenna, so that 2G and 3G networks can have
separate antennas. If these antennas cannot be changed, then the specific
environment must be carefully studied before taking any actions. You can
optimize the neighbour cells to avoid call drops.
4.2.6.4. Leakage of signals from indoor distribution system.
In most cities, call drops caused by signal leakage from indoor distribution system
exist. You should persuade the operator to reconstruct the indoor distribution
system. Or, the indoor distribution system can be merged to the whole network,
which can be done by optimizing of the coverage of the ambient outdoor cells and
addition of neighbour cells.
Page 37
4.2.6.5. Call drop caused by unsteady transmission
As the bottom level of transmission medium, E1 would report the loss of E1

electricalsignals and reception failures at the remote end. Meanwhile, several E1s
would be bound together as a group, and then E1 would report the fault of IMA
group in non-operating mode.
Call drops caused by engineering error:
-Reversely-connected antenna
-An excessive VSWR
-Multi-band antenna problem
-Leakage of signals from indoor distribution system
-Call drop caused by unsteady transmission
Figure 23: call drop caused by engineering error
Page 38
4.3. Analysis
The goal of call drop analysis is to identify cells suspected to have excessive call
drops problems (cells that overcome a define call drops rate threshold during their
busy hour time).
A second target is to identify potential problems analyzing the drop typologies mostly
occurring in the cells of the network. This identification is useful to better define the
problem that better fit for the further investigations.
Top (N) drops
Neighbours’ Performance Traffic

(use SHO success per adjs
counters to identify badly
Cell and its Neighbour
performing neighbours) & Map
Cells availability Site OK ?
Alarms/Tickets
Audit adjacent sites for alarms,
Availability, configuration and capacity
YES
NO
Configuration &
Parameter audit Conf OK ?
Iur
3G Cell at RNC YES
Investigation Iur
border? performance
YES
SHO Success YES

SHO
Rate < 90%?
NO
New site ?
ISHO NO Analyse last detailed radio RF and IF/IS HO neighbour

ISHO Failures
measurements optimisation
YES
3G cell covers
3G cell at inter-
over a coverage
RNC border ?
Top hole ?
issu
es No cell found YES RF and ISHO neighbour
ratio >40 % optimisation
Core: Inners / Outers

audit
NO
2G : TCH blocking No cell found ratio

YES > 90 % and Coverage issue (new site needed)
3G : Wrong N’ borgs ISHO Success
enough ADJG
definition Rate < 95%
Figure 24: call drop analysis process
Page 39
4.4. Call drop optimization
Solution for call drop optimization 1/2

1. Check high call drop cells and its neighboring cells for any fault alarms
2. Generate call drop root cause distribution and check for main contributors (radio, BTS, Iub, Iur, RNC, Iu,
MS)
3. Check SHO if success rate < 90% (leads to radio link failure)
-Check if cells are at RNC border (check Iur capacity and SRNC relocation problem)
-Detect badly performing neighbors using SHO success rate per adjacency counters -High incoming HO failure rate
from all adjacencies – check sync alarms
-Assess neighbor list plan and do visualization check with map
-Evaluate HO control parameters and trigger thresholds
4. Check ISHO KPI if RT ISHO < 90% or NRT < 80% (leads to radio failure)
-Check missing neighbors -Check GSM frequency plan, RNC and MSC database consistency
-Check alarm of reference clock in 3G or in 2G
-Check 2G TCH congestion
-Check RRC drop during ISHO RT / NRT
Figure 24: call drop optimization
Page 40
Solutions for call drop optimization 2/2

5. Look for DL or UL path loss problem if RAB drop due to radio dominates
 Check UE lost counters (active L1 synchronization failure) to check UL/DL
path loss problem
 Check active set update failure rate (with cause no response from UE)
 Map radio failures with RL power and CPICH related parameters
(CPICHToRefRABOffset, PTxDPCHMax)
 Check call reestablishment timer (T315)
 Check Ec/Io distribution for bad coverage issue
6. Check core network parameter setting if RAB drop due to Iu
 Check SCCP signaling (MSC / SGSN, RNC, IuCS / IuPS)
7. If high RAB drop due to BTS
 Check for any BTS faulty alarm If no alarms.
8. If high RAB drop due to MS
 Check physical channel reconfiguration failure rate (IFHO, ISHO, code
optimization)
Figure 25: call drop optimization
Page 41

10 Call Setup & Drop Optimization PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

10 Call Setup & Drop Optimization PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

WCDMA RF Optimization: Call setup and drop optimization

Call setup and drop optimization

1.1. Random Access procedure ........................................................................... 4

1.2. RRC connection establishment ..................................................................... 6

1.3. RAB connection establishment and release ................................................ 12

2. Call setup failure scenarios ............................................................................... 14

3. Call setup optimization ...................................................................................... 15

3.1. Missing neighbour ....................................................................................... 16

3.2. RACH optimization ...................................................................................... 17

3.3. System issue ............................................................................................... 18

3.3.1. RRC setup ............................................................................................ 18

3.3.2. RAB setup ............................................................................................. 21

3.4. Layer 1 synchronization problem ................................................................. 22

4. Call drop ............................................................................................................ 23

4.1. Definition ..................................................................................................... 23

4.1.1. Drive test aspect ................................................................................... 23

4.1.2. Network management aspect ............................................................... 24

4.2. Reasons ...................................................................................................... 26

4.2.1. Poor coverage....................................................................................... 26

4.2.2. Unconfigured neighbour cell ................................................................. 27

4.2.3. Handover .............................................................................................. 29

4.2.4. Interference ........................................................................................... 30

4.2.5. PSC confliction...................................................................................... 33

4.2.6. Engineering error .................................................................................. 37

4.3. Analysis ....................................................................................................... 39

4.4. Call drop optimization .................................................................................. 40

1. Call setup procedure

1.1. Random Access procedure

• If no acknowledgement is received, then this is taken as an indication that the

Timing relations and power ramping on the PRACH

Figure 1: Timing relations and power ramping on the PRACH

1.2. RRC connection establishment

RRC Connection Setup & Access and

RANAP: Iu Release Command

Figure 2: RRC connection setup & Access procedure

RRC Connection Events and KPIs

Event 4 IU RELEASE COMMAND

RRC Setup Complete Rate =Sum of RRC_CONN_STP_COMP

RRC Establishment Complete Rate = Sum of RRC_CONN_ACC_COMP x 100 %

RRC Retainability Rate = Sum of RRC_CONN_ACT_COMP x 100 %

Figure 3: RRC connection events and KPIs

RRC connection setup procedure

Figure 4: RRC connection setup and success and failure

UE does not answer RRC Connection Setup

Figure 5: RRC connection failure in case “no answer from UE”

1.3. RAB connection establishment and release

RAB Setup & Access and Active

Figure 6: RAB setup & Access and active

2. Call setup failure scenarios

Call Setup Failure Scenarios Summary

Figure 7: call setup failure scenarios summary

3. Call setup optimization

Best server’s Coverage Optimization

Yes Report & Finish

Report & Finish No “Radio Bearer setup

Figure 8: call setup failure Analysis process

3.1. Missing neighbour

Call setup failures – Missing

-Missing neighbour analysis over the whole route (3G-3G, 3G-2G)

Figure 9: Call setup failure- missing neighbor

3.2. RACH optimization

– Inadequate RAN parameter related to Random Access: RAN parameter

– UL Coverage limit: UL coverage of UE is smaller compared to serving