Dropped call investigation

REPORT

1 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

1997-09-12

Rev

A

REPORT - DROPPED CALL INVESTIGATION
Edited Summary

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc

File


REPORT

2 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

1997-09-12

Rev

File

A

Abstract
This document describes the results from the Dropped call investigation
The aim was to investigate the reasons for dropped calls and how well the
statistics correspond to the dropped calls.
Three cells were chosen and all signalling on respective A-bis interfaces
were recorded during 14 - 18 hours including peak hour. The A interface
were also recorded during one hour on each cell. The recordings were later
post-processed and every abnormal call was analysed. STS data was
collected as well.
The analysis showed that the majority of the dropped calls was due to low
signal strength, high interference or end of battery in the mobile station. Only
one minor problem in the CME20 system was found. A few cases of
abnormal mobile station behaviour were found, none of them very serious.
The STS counter for dropped calls on TCH, TNDROP, was corresponding
very well to the reality. The equivalent counter for SDCCH, CNDROP, was
counting fewer drops than was found when analysing the recordings. This
can be improved by some changes in the CME20 system.
The overall performance was very good and no problems were found in the
interwork between the CME20 system and the mobile station.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

3 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

1997-09-12

Rev

File

A

Contents

1 INTRODUCTION ............................................................................................................4
2 TEST OBJECT ................................................................................................................4
3 MEASUREMENT AND ANALYSIS...............................................................................5
4 SIGNALLING AND STS COUNTERS ...........................................................................6
4.1 SIGNALLING.................................................................................................................6
4.2 STATISTICS ..................................................................................................................7

5 RESULT ...........................................................................................................................9
5.1.1 Abnormal events on TCH .........................................................................................9
5.1.2 Abnormal events on SDCCH ..................................................................................10
5.1.3 Mobile test .............................................................................................................13
6 SUMMARY ....................................................................................................................14
6.1 TCH ..............................................................................................................................14
6.2 SDCCH .........................................................................................................................14
6.3 MOBILE STATION PROBLEMS .................................................................................15
6.4 STS ACCURACY .........................................................................................................15
6.4.1 TCH .......................................................................................................................15
6.4.2 SDCCH ..................................................................................................................16
7 POSSIBLE ENHANCEMENTS ....................................................................................17
8 SUMMARY ....................................................................................................................18
9 REFERENCES ...............................................................................................................18

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

4 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC
1

Datum - Date

1997-09-12

Rev

File

A

INTRODUCTION
An investigation about the reasons for dropped calls in a CME20 R5 system
was made by ERA/LV/SP Anders Milén, ERA/LV/SP Bengt Norstedt,
ERA/LVR/POC Stefan Svennebring and ERA/LVR/PO Per-Daniel
Ståhlnacke in end of November 1996.
The signalling links from Abis and A interface were recorded and STS data
was collected. These recordings were then post-processed and analysed
internally by Ericsson.

2

TEST OBJECT
The recordings were made on three cells connected to BSC A and MSC A,

both with CME20 R5 software. The A interface had eight C7 signalling links.
The BTS software was R14 (RBS200).
The recorded cells were:

CELL

TRXs

Environment

1

8

Suburban

2

4

Suburban/rural

3

4

Suburban/rural

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc

REPORT

5 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC
3

Datum - Date

1997-09-12

Rev

File

A

MEASUREMENT AND ANALYSIS
The signalling links on the Abis and A interface were recorded using an ELMI
7300 protocol analyser.

MSC
A
BSC

Protocol
analyser

A”
BTS

To avoid too large logs, the recordings were done in intervals of 3 to 12
hours, depending on traffic load.
The recorded data was later post-processed by a tool able to extract all
dropped and abnormal calls. The output was loaded into a data base were
the calls were analysed manually one by one.
It turned out to be enough to examine at the Abis interface to determine the
cause of the dropped calls as the A interface did not add any more
information.
STS data was also collected and post-processed.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

6 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

1997-09-12

4

SIGNALLING AND STS COUNTERS

4.1

SIGNALLING

Rev

File

A

To understand the mechanisms behind dropped calls the reader must have
some basic knowledge about the signalling.
1. Radio Link Time-out
Every time a SACCH message cannot be decoded the radio link time-out
counter is decreased by 1. If the message can be decoded the counter is
incremented by 2. However, the value can not exceed the initial value.
The initial value is set by the parameter RLINKT for radio link time-out in
the mobile station and by RLINKUP for time-out in the BSC.
If the mobile station is lost and no measurement reports are received in
the BSC, there will be a radio link time-out and the message Channel
Release (cause: abnormal release, unspecified) is sent to the mobile
station and the SACCH is deactivated in the BTS. A Clear Request
message is sent to the MSC as well.
To be sure that the mobile has stopped transmitting the BSC now waits
RLINKT SACCH periods before the timeslot is released and a new call
can be established on the channel.
2. Layer 2 time-out
If the BTS never get an acknowledge on a Layer 2 message after the time
T200xN200, the BTS will send Error Indication (cause: T200 expired) to
the BSC which will send Channel release (cause: abnormal release, timer
expired) to the mobile station and a Clear Request to the MSC.
The SACCH is deactivated and the BSC waits RLINKT SACCH periods
before the timeslot is released and a new call can use the channel.
This is only valid if the call is in steady state, i.e. not during handover or
assignment.
3. Release Indication
When the BTS receives a Layer 2 DISC frame from the mobile it replies

with a Layer 2 UA frame to the mobile station and a Release Indication to
the BSC.
In CME20 R5 the system does only react on Release Indication if it is
received during a normal disconnect situation. If such a message is
received unexpectedly this will usually cause radio link time-out or timer
T200 expiration as the mobile station stops the transmitting of
measurement reports.
It is also possible that the release will be normal depending on when the
Release Indication is received.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

7 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

Rev

1997-09-12

File

A

4. MSC time-out
This can manifest itself in different ways:
Normal release: If the MSC never receives a response on a message
(e.g. Identity Request) and there is no radio link time-out or layer 2 timeout, the MSC will send a Clear Command to the BSC. The time-out is
depending on the message.
When receiving Clear Command, the BSC will send a Channel Release
(cause: normal release) and then deactivate the SACCH.
Reject (only SDCCH): If the MSC never receives a response on the first
message after Establish Indication, the MSC will send a reject message. If
the connection was a Location Update it will be a Location Update Reject
(cause: network failure) and if the connection was an MO call (CM Service
Request) a CM Service Reject (cause: network failure) will be sent.
The MSC will then send a Clear Command to the BSC and the call is
cleared by Channel Release (cause: normal release).
5. Assignment to TCH
Before sending an Assignment Command from the BSC at TCH
assignment, the following criteria has to be fulfilled (in CME R5):
a. There must be a TCH channel available, i.e. no congestion
b. The locating must have received at least one valid measurement report

If the criteria is unfulfilled, Assignment Command will not be sent and a
Channel Release (cause: abnormal release, unspecified) will be sent to
the mobile station and a Clear Request to the MSC.

4.2

STATISTICS
Only the counters related to dropped calls are described here.
The counters are defined as follows:
TCALLS: Allocation attempts, incremented at every attempt to seizure a TCH
regardless of whether the seizure succeeded or not.
CCALLS: Allocation attempts, incremented at every attempt to seizure an
SDCCH, including handover attempts, regardless of whether the seizure
succeeded or not.
TMSESTB: MS connection establishment on TCH
CMSESTB: MS connection establishment on SDCCH

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

8 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

ERA/LVR/POC

Kontr - Checked

Datum - Date

1997-09-12

Rev

File

A

TNDROP: Dropped connection due to failure on TCH, incremented when the
- BSC sends CLEAR REQUEST message
- CLEAR COMMAND is received in BSC if the cause code differs from the
cause codes ‘Call control’ and ‘Handover successful’ and CLEAR REQUEST
has not been sent previously.
On Abis this will cause a Channel Release with cause “Abnormal release”.
CNDROP: as TNDROP but for SDCCH.
TDISQA and CDISQA: Low quality up or downlink, incremented if
RxQualUl > QLIMUL or if RxQualDl > QLIMDL. RxQualUl and RxQualDl are
filtered RxQual value up and downlink.
Note! The TDISQA and CDISQA were never be stepped in this case as the
parameters QLIMUL and QLIMDL were set to 100.

TDISSS1 (TCH) and CDISSS1 (SDCCH) : Low signal strength up or
downlink, incremented if SSUl < -104 dBm or if SSUncompDl < - 104 dBm.
SSUl are filtered signal strength value uplink and SSUncompDl are
uncompensated filtered signal strength value downlink.
Note! If no measurement reports at all are received from the mobile station
the counters TDISQA, CDISQA, TDISSS1 and CDISSS1 are not
incremented.
TDISTA: Excessive Timing Advance, incremented if TA > TALIM.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

9 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

1997-09-12

5

RESULT

5.1.1

Abnormal events on TCH

Rev

File

A

Following abnormal cases were found:
1. Radio link time-out
Counters: TNDROP, possible TDISSS1, TDISQA
Cause: Low signal strength or high interference.
2. Time-out on Layer 2: T200 expiration
Counters: TNDROP, possible TDISSS1, TDISQA
Cause: Low signal strength or high interference.
3. Drop after Notify (user suspended)
Counters: TNDROP, possible TDISSS1, TDISQA
Some mobiles seem to drop the connection when the message “Notify:
user suspended” is sent. The message Notify should not cause a drop.
This could be mobile fault but as only two cases are seen there are not

enough statistics to draw any conclusions; it could be a coincidence.
4. No answer on IMSI Detach
Counters: TNDROP, possible TDISSS1, TDISQA
The system does not respond to “IMSI detach” if the message is received
before Setup, which will cause a radio link time-out.
5. Unsuccessful Assignment to TCH
Counter: CNDROP
The mobile never established itself on TCH and failed to return to
SDCCH. After a time-out in the BSC the call is released by sending
Channel Release (cause: abnormal release unspecified) to the mobile
station.
Cause: Low signal strength or high interference.

6. Unsuccessful outgoing handover
Counters: TNDROP
Either the mobile station never received the Handover Command or it
failed both to establish itself on the target cell and to re-establish itself on
the originating cell. The call is released by sending Channel Release
(cause: abnormal release unspecified) to the mobile station.
Cause: Low signal strength or high interference.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

10 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

ERA/LVR/POC

Kontr - Checked

Datum - Date

Rev

1997-09-12

File

A

7. Unsuccessful incoming handover
Counters: TNDROP in originating cell
The mobile never established itself on the target cell and failed to return
to
the originating cell. After a time-out in the BSC the call is released by
sending Channel Release (cause: abnormal release unspecified) to the
mobile station.
Cause: Low signal strength or high interference.

5.1.2

Abnormal events on SDCCH
Following abnormal cases were found:
1. Location Update Reject, normal release
Counter: none
a. No answer on Authentication Request
This happens when the mobile fails to answer Authentication
Request. After 5 - 6 seconds there is a time out in the MSC
and a LU Reject with cause Network Failure is sent.
Cause: Low signal strength or high interference.
b. Other reject causes
Following reject causes have been seen:
IMSI unknown in HLR
PMLN not allowed
2. CM service Reject, normal release
Counter: none
a. Reject cause: Network failure
This happens when the mobile fails to answer Authentication
Request. After 5 - 6 seconds the MSC times out and sends CM
Service Reject.
Cause: Low signal strength or high interference.
b. Reject cause: Message not compatible with call state
The mobile station have probably dropped the previous call and now the
user tries again before the old call is completely cleared in the system.
c. Reject cause: Message type not compatible with protocol state
The mobile station is sending CM Service Request (MO call
establishment) during call set-up, which is not allowed. This is seen on
Motorola M300, M301, M400, Flare and Flare Refresh.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

11 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

Rev

1997-09-12

File

A

d. The mobile disconnects Layer 2 (Release Indication) after Authentication
Request. But as the system does not react to Release Indication there will
be a time-out in MSC after 5 - 6 seconds and a CM Service Reject
with cause Network Failure is sent.
Possible cause: Low signal strength or high interference
e. Other reject causes
Following reject causes have been seen:
IMSI unknown to VLR
IMEI not accepted
3. Time-out on Layer 2: T200 expiration
Counter: CNDROP, possibly CDISSS1 and CDISQA
Cause: Low signal strength or high interference.
4. Error indication (Sequence Error) and Channel Release, abnormal
release:
unspecified.
Counter: CNDROP, possibly CDISSS1 and CDISQA
Cause: A fault have occurred on the radio link layer. (GSM 08.58)
5. Radio link time-out.
Counter: CNDROP, possibly CDISSS1 and CDISQA
Cause: Low signal strength or high interference.
6. MSC time-out.
Counter: None
Cause: Low signal strength or high interference.
7. Unexpected Release Indication
We can only guess why the mobile station behaves like this: it can be that
the mobile station gets confused when the user is behaving strangely,
faulty mobile station, etc.
a. Abnormal Release, unspecified

The behaviour is as case 5 and the same counters are incremented.
b. Release Indication after no response from mobile station, abnormal
release unspecified
In this case the mobile does not respond when it should. In many cases
no Setup message is received from the mobile station. After ten seconds
the mobile station is releasing the connection. This will cause a radio link
time-out (case 5).
This is seen on Motorola M301, M400 and Flare.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

12 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

1997-09-12

Rev

File

A

c. Release Indication SAPI 3, abnormal release unspecified
The system sends an Establish Request SAPI 3 to establish a SAPI 3 link
for sending an SMS. If the mobile fails to reply on SABM the BTS sends
Release Indication and Error Indication: Timer T200. The system
responds to this by a Channel Release, abnormal release: unspecified.
This case can be caused by low signal strength or high interference.
Counters as in case 3.
d. Normal release
In some cases the Release Indication comes just before Location Update
Accept. In this case there will be a normal release and no counters are
increased. This means that the system thinks that the Location Update is
successful when it in fact has failed.
Another case is when the MSC times out before there is a Radio Link
Time-out which will cause a normal release.
See case 2.d for CM Service Reject after a Release Indication.
No counters are incremented.

8. No Assignment Command, abnormal release, unspecified.
Counters: CNDROP, possibly CDISSS1 and CDISQA
a. No Measurement Reports from mobile station

Cause: Low signal strength or high interference.
b. Congestion, no available channels

9. Unsuccessful assignment to TCH, abnormal release unspecified
Counters: CNDROP, possibly CDISSS1 and CDISQA
Cause: Low signal strength or high interference.
a. Assignment Failure is sent, abnormal release unspecified
The assignment to TCH failed but the mobile station succeeded to return
to the old SDCCH. The system disconnects the call after a time-out and
sends Channel Release with cause “abnormal release, unspecified”.
b. Layer 2 time-out on Assignment Command
The mobile station does not send acknowledge on Layer 2, probably
because of low signal strength or bad quality. The mobile is lost.
c. Mobile fails to return to old SDCCH, abnormal release unspecified
The mobile receives the Assignment Command, fails to establish contact
with TCH and finally fails to return to the old SDCCH. The mobile is lost.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

13 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC
5.1.3

Datum - Date

1997-09-12

Rev

File

A

Mobile test
A live test was done to see what response different faults had in the system.
Nothing abnormal was found.
Ericsson 337
1. Power off during conversation
Result: Normal release
2. Battery removed during conversation
Result: radio link time-out - TNDROP stepped
3. Normal disconnection
Result: Normal release
4. Battery dead during conversation

Result: radio link time-out - TNDROP stepped
5. Battery dead during call set-up
Result: layer 2 time-out: T200 - TNDROP stepped
6. Antenna removed
Result: radio link time-out - TNDROP stepped
AEG
1. Normal disconnection
Result: Normal release
2. Power off during conversation
Result: IMSI detach
3. Battery removal
Result: radio link time-out - TNDROP stepped
Siemens
1. Battery removal
Result: radio link time-out - TNDROP stepped

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

14 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

6

Datum - Date

1997-09-12

Rev

File

A

SUMMARY
From the subscribers point of view, the most serious dropped calls are those
that interrupts an ongoing conversation, i.e. call dropped in TCH. If the calls
are dropped on SDCCH the user simply re-dials again and hopefully
succeed with the new call set-up.
On the contrary, drops on SDCCH are more serious from a system point of
view. A radio link time-out on SDCCH will occupy an SDCCH sub-channel for
(RLINKUP+RLINKT)/2 seconds and increase the risk for congestion.

6.1

TCH
Case 5, unsuccessful Assignment to TCH, is covered in chapter 6.2
“SDCCH”.
Case 7, is not discussed here as those drops are treated in the originating
cell, but it can be said that these drops are caused by low signal strength or
interference.
The different cases can be grouped together according to the reasons:
A. Case 1, 2 and 6 are most likely caused by low signal strength,
interference or end of battery in the mobile station.
B. Case 3 could be caused by a faulty mobile station but as the amount of
samples are very few, no conclusion can be drawn.
C. Case 4 is caused by a fault in the CME20 system.

6.2

SDCCH
The different cases can be grouped together according to the reasons:
A. Dropped calls according to case 1.a, 2.a, 3, 5, 6, 7.c, 8.a, 9.a, 9.b and 9.c
are most likely caused by low signal strength, interference or end of
power in the mobile station.
B. Case 2.c and 7.b are probably caused by faulty behaviour in the mobile
station.
C. Case 2.d, 7.a, 7.b and 7.d are caused by a strange behaviour from the
mobile station but does not necessary have to be a fault.
D. 1.b and 2.e are normal and caused by faulty or unknown SIM.
E. 2.b are normal and are only affecting the user for a limited amount of
time.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc

REPORT

15 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

6.3

Datum - Date

1997-09-12

Rev

File

A

MOBILE STATION PROBLEMS
In general, the mobile stations are working very well. However, a small
fragment of the dropped calls are due to strange mobile behaviour. This was
mainly seen on SDCCH where the signalling is more complex.
In case 2.c, the mobile station is sending CM Service Request (cause:
mobile originating call) during the call set-up. The system reacts to this by
sending a CM Service Reject (cause: Message not compatible with call
state). In some cases the mobile seems to accept the reject and the original
call is continued. In other cases the mobile disconnects the call with reason
“user busy”.
This is seen on Motorola M300, M301, M400, Flare and Flare Refresh.
In case 7.b the mobile station does not send the Setup message. Instead
there is a Release indication after approximately 10 seconds. This is seen on
Motorola M301, M400 and Flare.

6.4

STS ACCURACY
One question was how well the STS counters are in accordance with the
dropped calls.
How well the counters TDISSS1 and CDISSS1 are reflecting the reality is not
investigated as this is very time consuming.
First one must define how a dropped call is perceived. Is a rejected message
a drop or not? The user maybe experiences it as a drop while it from a
system point of view is not.
Is a unsuccessful Location update a drop? The user is usually not aware that
the mobile station makes a Location update and does not know whether it
was successful or not. But from the system point of view an unsuccessful
Location update can cause a longer occupation time on SDCCH than

necessary.

6.4.1

TCH
Case 5 and 7 is not taken into consideration as case 5 is affecting the
SDCCH and case 7 the counters in another cell.
All cases will step TNDROP. This is what the system recognises as a drop.
The user does experience all cases except case 4, no answer on IMSI
detach, as a drop.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

16 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

1997-09-12

Rev

File

A

System experienced drops
Observed TNDROP
1
81
83
2
203
212
3
53
55
Table 1.
Table 2 indicates that TNDROP corresponds well to dropped calls on TCH.
The difference is due to mismatch in Abis recording period and TNDROP
period as there will be a gap in the recording every time a new log is started.
It is also possible that a few drops were missed during the analysis.

User experienced drops

Observed TNDROP
1
77
83
2
202
212
3
51
55
Table 2.
Table 3 shows that the user experienced drops is lower that TNDROP,
maybe even lower then shown here as a drop during a normal disconnect
phase will increment TNDROP but is not noticed by the subscriber.

6.4.2

SDCCH
If we look at the dropped calls from a system point of view, Location Update
Reject, CM Service Reject and MSC time-out is not treated as a drop.

System experienced drops
Observed CNDROP
1
86
85
2
607
621
3

300
303
Table 3.
The CNDROP corresponds well to the system experienced drops on SDCCH
according to table 4. The difference in the numbers are due to the same
reasons as for TCH (table 2).
But this does not correspond very well to how the subscriber perceives the
call drops as MSC time-out and CM Service Reject do not step CNDROP. If
this event is taken into account we have following numbers (Location Update
Reject not included):

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

17 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC

Datum - Date

1997-09-12

Rev

File

A

User experienced drops
Observed CNDROP
1
139
85
2
752
621
3
339
303
Table 4.
Table 5 clearly shows that CNDROP is not reflecting the subscribers
experience of dropped call very well.
As mentioned before, the subscriber is usually not aware about a Location
Update Reject. And this is not a big problem as the mobile will try again but
of course this is a bit unnecessary and can be minimised by improving the
cell plan and cell parameters.

7

POSSIBLE ENHANCEMENTS
Following improvements can be done to make the CME20 system even
better and the STS counters more in accordance with the actual dropped
calls:
TCH
TNDROP is quite accurate already. But the IMSI Detach message should
trigger a normal release even if it is received before the Setup message.
SDCCH
1. A Release Indication should always trigger a release even if it is
unexpected.
2. A MSC time-out should increment the TNDROP and CNDROP. It is also
possible to increase the MSC time-out period by one or two seconds to
get a Layer 2 time-out or radio link time-out instead which will increment
the drop counters. Note that the MSC timers can not be set by command.
3. Counters for CM Service Reject and Location Update Reject could be
introduced to get a more complete picture of the unsuccessful calls.
OTHER
QLIMUL and QLIMDL could be set to a more accurate value. For more
information see ref. 1.

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc


REPORT

18 (18)

Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other)

Nr - No.

ERA/LVR/PO Stephan Trzeciak

LVR/PO-97:0148

Dokansv/Godk - Doc respons/Approved

Kontr - Checked

ERA/LVR/POC
8

Datum - Date

1997-09-12

Rev

File

A

SUMMARY
In general the interwork between the CME20 system and the mobile stations
is working very well. The majority of the dropped calls are due to low signal
strength, high interference or battery discharge in the mobile station. That
means that the part of the dropped calls that lacks reasons when the
statistics are analysed usually is caused by battery discharge, which gives a

fast drop without reason, low signal strength, but still above -104 dBm, or
high interference.
The CME20 system is working very well. Except for the fact that the system
does not react on IMSI detach if received on TCH before Setup (which is
very rare), no strange behaviour has been seen.
TNDROP is reflecting the reality very well, but CNDROP can be improved.
Note that CNDROP is sensitive to the parameter settings in the MSC and
then of course also to different MSC types (Ericsson, Siemens, etc.).
Some strange behaviour from mobile stations has been noticed. But not very
serious ditto. This is not very common and seems to be of a type that just
happens occasionally.

9

REFERENCES
1. 1/100 56-FCU 144 01 Uen Rev. A - Engineering guidelines, Locating

E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc