Dropped Call and Blocked Call Analysis for ** MCC Drive

Test Log

CET/N&TC Daniel. Quan

(一) Dropped Call analysis

If we take a quick look at these 5 dropped call cases, before

digging deeply into detailed analysis, it’s easy to find out that the
direct reason for each dropped call is the abominable downlink
signal quality while the signal strength is good enough. Obviously,
the dissatisfying quality comes from frequency interference. But
the frequency point allocation is not the only reason for
interference. In our 5 call dropped instances, the signal quality
never become intolerable before the MS hands into improper
neighbor, and a cell reselection always brings in? MS good quality
soon after call dropped. Common sense tells us to optimize
parameters setting of neighbor relation to solve this kind of
problem. Further consideration then invokes us to adjust cells’
main coverage area (via antenna down tilt/direction adjustment) to
improve handover performance.

1 LOG: 060915_160150_0002
Description: Call dropped after handover occurred
 Analysis: Before a normal handover occurred during the call, the signal
quality from the severing cell CHUNFUNLOU2 was fairly good (enough to keep
the connection). A remote cell 750SHIYANCHANG2 was assigned as the
handover target, instead of some nearby cells with good signal strength. Call
dropped due to intolerable RxQual thereafter. Further investigation is needed to
check if parameters for handover judgment were with proper setting, or not.
However, it is safe to say that ,in this case, Overshooting/Frequency
Interference/Indistinct_Main_Severing_Cell (within this area) contributed a lot to
bad signal quality, and to unexpected handover as well, which resulted in dropped
call directly. Please refer to the following plots.
Snapshot before Handover:
Snapshot after Handover:

Suggestion: Optimize BTSs’ antenna direction/down tilt to adjust main

coverage of certain cells involved. Check/Adjust parameters setting of neighbor
relations for cell CHUNFUNLOU2 according to DT log and BSC handover
statistics.

2 LOG: 060915_171924_0001
Description: Call dropped after handover occurred
 Analysis: Same as in the above scene, before the handover occurred
during the call, the downlink signal quality from the severing cell
YOUDIANLOU2 was fairly good. Cell WENHUAGONG1 was assigned as the
handover target, instead of some other neighbors of better signal strength. Call
dropped due to intolerable RxQual thereafter. We still need farther investigation to
check if parameters for handover judgment were with proper setting, or not. It is
safe to say Overshooting/Frequency Interference/Indistinct_Main_Severing_Cell
(within this area) did contribute a lot not only to bad signal quality, but also to
unexpected handovers, which resulted in dropped call directly. Please refer to the
following plots.
Snapshot before Handover:
Snapshot after Handover:

Suggestion: Optimize BTSs’ antenna direction/down tilt to adjust main coverage

of certain cells involved. Check/Adjust parameters setting of neighbor relations for
cell YOUDIANLOU2 according to DT log and BSC handover statistics. Try to
optimize ARFCN allocation for cell WENHUAGONG1 with the help of OSS
NCS&RIR function.

3 LOG: 060915_171924_0001
Description: Call dropped after handover into a Micro?
Analysis: Before the handover occurred during the call, the downlink
signal quality from the severing cell JINDAOYIN2 was quite good. Two issues to
be investigated here. First of all, under such circumstances, we don’t have to
transfer the connection to any neighbor-cell unless a Congestion Control
procedure was triggered somehow (Cell Load Sharing), which needs further
investigation into BSS traffic statistics to verify. Then, cell LAIYINGBAO1 was
assigned as the handover-target while many neighbors with good, even better,
signal strength were near. By checking cells’ CGI, we find both cells belong to one
BSC. That means, if this Micro LAIYINGBAO1 is not only for indoor coverage,
the reason of dropped call must lie in improper HO setting.;or the problem is
micro-site overshooting.
Dropped call due to intolerable RxQual after handover occurred Frequency
interference did result in dropped call directly. Please refer to the following plots.
Snapshot before Handover:
Snapshot after Handover:

Suggestion: Optimize BTSs’ antenna direction/down tilt to adjust main coverage

of certain cells involved. Check/Adjust parameters setting of neighbor relations for
cell JINDAOYIN2 according to DT log and BSC handover statistics. Try to
optimize ARFCN allocation for cell LAIYINGBAO1 with the help of OSS
NCS&RIR function, which is the most effective way to reduce/avoid frequency
interference after site on-air.
(二) Blocked Call Analysis
Many reasons may lead to blocked calls. It’s difficult, and
unreasonable, to some extent, to decide the most important reason
with only DT log analysis at hand. However, we can still find some
helpful information, when auditing layer 3 messages deeply, to
help direct our trouble-shooting. However, with regard to the
requirements of the job network consulting, focusing on testing
just one kind of logs does help to make clear some signaling flow
processes, but not the root of the problem. We suggest the BSS
traffic statistics be investigated at the same time when undertaking
blocked call analysis.

LOG: 060912_103714_0343
Description: Blocked call due to Location Updating (update?)
Analysis: From the following DT log snapshots, we are clear of the whole
process of blocked call in this case. As MS originated a call in its severing cell
DONGHUA2, it delivered channel request messages on RACH, and then it waited
for the immediate assignment to arrive. As we know, the MS will continuously
measure the signal strength on and recalculate the value of C1&C2 for its current
serving cell and neighbors at the same time; if any one of the five Cell Reselection
criteria is satisfied it will trigger a cell reselection procedure. In this log, we notice
that the severing cell was not barred, the downlink signal strength was strong (-
75db), and the signal quality (C/I) was quite good. But the signal strength from the
neighbor SHUGUANG1 was always 10db+2 higher than from the current serving
cell. Hence, we suppose it was the C2 criteria satisfied to incur a cell reselection,
which triggered a Location Updating procedure, and then resulted in a blocked
call. On the other hand, we couldn’t exclude the possibility that poor Paging
performance might cause the blocked call, because there isn’t any Immediate
Assignment Message which was directed to our test mobile exiting in our
signaling records. This could imply SDCCH resources limited in the severing cell,
Paging queuing overflowed or SDCCH resources limited in the BTS of the
terminal MS. Please refer to the snapshots.
Snapshot when MS originating a call:
Snapshot when MS started a cell reselection:
Snapshot when MS originating a location updating (Call Blocked):

Suggestion: Check the BSS statistics on SDCCH performance, RACH

performance and Paging performance. If statistics show that these kind of channels
perform well in both busy and non-busy hours, we can draw a conclusion that this
kind of blocked calls which happened alone the Location Areas’ border are OK.
Otherwise we need to optimize cells’ coverage area and parameter setting for cell
reselection, handover, PCH&SDCCH administration.
Besides: Blocked calls in log 060919_164733_0001&
060918_182530_0479 are not real blocked calls.
Blocked call in log 060919_164805_0003 came from Radio resource limited?. It
can be easily identified by looking into layer 3 message.
Other blocked calls are due to the same cause as of log 060912_103714_0343.