GSM Network Speech Quality Problems &

Solutions

ZTE university

Training goals
To know the causes of speech
quality problems and problem
handling procedures.

Contents
Monologue
Cross-talk
Bidirectional Silence
Poor Speech Quality
Echo

Monologue Causes

Wireless
Wireless
part
part

MS
MS

Causes of
Causes of
monologue
monologue

External
External
interferen
interferen
ce
ce
MSC (software&
MSC (software&
hardware
hardware

A interface
A interface
(software &
(software &
hardware)
hardware)

BTS
BTS
(software
(software
&
&
hardware
hardware
)
)
Abis
Abis
interface
interface

BSC(softw
BSC(softw
BSC(softw
BSC(softw
are&
are&
hardware)
hardware)

Monologue Problem handling flow

Monologue problem
only occurs in
outgoing calls

Confirm monologue
problem area

Monologue exists in
the whole MSC range

Monologue
appears in the
range of some
BSCs or a certain
number of BTSs
under the BSC

We can tell if its an inter-office or intra-office problem

from subscribers feedback and call test

If its an intra-office problem, find out if the problem

is with some BSCs or all BSCs under the MSC

Find out if the problem is with some sites or all sites

under a BSC.

Monologue
problem only exists
in the coverage of a
BTS

Monologue Problem handling flow

Confirm monologue
problem area

Monologue problem
only occurs in
outgoing calls

Monologue exists in
the whole MSC range

Monologue
appears in the
range of some
BSCs or a certain
number of BTSs
under the BSC

Check corresponding outgoing trunk and data.

As for problems inside the office, check all parts
in the problem area.

Monologue
problem only exists
in the coverage of a
BTS

Monologue Problem handling flow

Confirm monologue
problem area

Monologue problem
only occurs in
outgoing calls

Monologue exists in
the whole MSC range

Monologue
appears in the
range of some
BSCs or a certain
number of BTSs
under the BSC

Try to find out if customer or other relevant personnel

made changes on MSC data or performed operations
during site swap.

Monologue
problem only exists
in the coverage of a
BTS

Monologue Problem handling flow

Confirm monologue
problem area

Monologue problem
only occurs in
outgoing calls

Monologue exists in
the whole MSC range

Monologue
appears in the
range of some
BSCs or a certain
number of BTSs
under the BSC

Monologue
problem only exists
in the coverage of a
BTS

first check if the version of BSC DRT is upgraded to be able to solve monologue problem

if the version is right, change over the active and standby DSN boards of BSC;

make test after the changeover to see if the problem still exists.

When analyzing and locating this problem, we can open the GSM subscriber interface trace at MSC
maintenance platform, make circuit dialing test at A interface; with the interface message, analyze the
trunk occupied by the problem call, calculate the corresponding single board to check the boards and
connection wires (all single boards and connection wires between E3M and NET, including
backboards).

Monologue Problem handling flow

Confirm monologue
problem area

Monologue problem
only occurs in
outgoing calls

Monologue exists in
the whole MSC range

Monologue
appears in the
range of some
BSCs or a certain
number of BTSs
under the BSC

Monologue
problem only exists
in the coverage of a
BTS

check cells radio parameters, whether UL/DL power link is balanced or

not (collect data through signaling tracing), whether MS max
transmission power is set correct or not.
make call test and check hardware to find out if hardware problems
exist, such as equipment connection problem, TRX fault, combiner
fault, antenna fault, etc..
further confirm the problem is about UL or DL with MS calling landline
phone.

Inter-office monologue cases

Problem description

The operation and maintenance department of an operator

complained to ZTE engineers that monologue existed in Meilong
town.
In communication, ZTE engineers found that most sites under BSC4
have the problem, but BSC11 in the town didnt have the problem.

Problem analysis

ZTE engineers went to the site and made call test.

Inter-office call test

Intra-office call test

CALL TEST between MSs

inside the office, both MOC
and MTC were under the same
BSC (BSC4) ;MOC was under
BSC4, and MTC was under
BSC11; no monologue
problem occurred in both
situations.

made calls to local landline

phone, monologue happened,
and the probability of monologue
happening was about 40%.

Call test
method

it was inferred that the

monologue problem only existed
in calls between different offices
(our operators office China
Telecom), and the cause of
problem should be with the
outgoing trunk and data.

Inter-office monologue case

Problem handling

Start

Problem location: inter-office

Checked: if Any
changes on MSC data
or operations were
performed during site
swap?

Confirmed: trunk circuit

data were configured
wrong during the
expansion and swap of
Telecom outgoing circuits.

End

Problem solved

Process: adjusted
configuration mistake

Typical case-Monologue due to TRX fault

Problem description

A great number of subscribers complained about monologue

problem in a town .
Problem analysis

Engineers made DT and CALL TEST on site;

Among the 50 times of CALL TEST, monologue or two-way silence

occurred about 15 times.;

Through observing the situation of MS seizing frequency and

timeslot, engineers found that monologue occurred when MS
seized a frequency of a cell;

The MS receive level fluctuated greatly, which even reached 30dB,

as shown in the following figure.

Typical case-Monologue due to TRX fault

Problem description

Engineers concluded
that the monologue
problem was mainly
caused
by
the
defective
TRX;
monologue occurred
when MS occupied
this TRX.

Problem handling
When the defective TRX was replaced, engineers made CALL
TEST again and monologue problem disappeared, and the
problem didnt occur in the following days.

Typical case-Monologue due to repeater fault

Problem

description

In a network, subscribers in the coverage area of a BTS (BTS A) complained about

monologue problem, which was even serious at the prefectural government
building area and a normal school (covered by BTS A Cell 1) .

Problem handling

Engineers went to the site and made call test, finding the monologue problem was
related to the level. When DL level was under 80dBm, metallic noise and
monologue appeared in calls.

It was also found in call test that UL speech quality was poor, while DL speech
quality was good, so the monologue was due to UL problem.

After checking OMCR data, engineers found that interference band of BCCH 113
and TCH 99 in BTS A was very serious, the interference class even reached 5.

Serious
monologue
existed
Repeater

Typical case-Monologue due to repeater fault

Typical case-Monologue due to repeater fault

Problem handling
The monologue at BTS A was confirmed to be caused by repeater interference.
Closed repeater and made call test again, metallic noise and monologue
disappeared in calls.

Contents
Monologue
Cross-talk
Bidirectional Silence
Poor Speech Quality
Echo

Cross-talk Causes & handling of problem

Methods for handling cross-talk

Causes of cross-talk

Locate problem area;

If cross-talk appears during intra-office

Crossed-wires at A interface;

incorrect exchange of timeslots

calls, check if there are crossed wires at A

made by timeslot multiplexing

interface first;

equipment when the equipment is

calls, check if there are crossed wires in

used in transmission;

wrong configuration of BTS data .

If cross-talk appears during inter-office

outgoing office circuits ;

Block the E1 equipment that uses timeslot

multiplexing device, and make test, so as to
check if the problem is caused by timeslot
multiplexing equipment fault;

As for dealing with cross-talk at one BTS,

focus on checking of BTS transmission,
hardware and data configuration.

Typical case - Cross-talk due to intra-office fault

Problem description

Frequent monologue and a few cross-talks occurred in a network after it

started commissioning;
In many times of call test, we caught several times of cross-talk;
One phenomenon was that monologue happened to MOC or MTC, and the
counterparty could not hear MOC or MTC but a third persons voice or the talk
between another two people;
The other was that when call drop happened to MOC or MTC, the counterparty
didnt release the call but heard a third persons voice after more than 10
seconds.

Typical case - Cross-talk due to intra-office fault

Problem analysis

From the complaint letters collected on site and many times of call test, it was
discovered that monologue happened to the 12th and 13th E1 in BSC1. When
MOC seized timeslots on the two E1 to originate a call, the following
phenomena appeared:
Sometimes, the MTC

When MTC answers the

didnt hear anything at

call, it heard a third

the beginning, but heard

persons voice, and this

cross-talk after a while,

continued until hang-up.

and this continued until

Sometimes, both the MOC and
MTC could hear nothing, and
after a while they both heard the
talk between another two people,
and this continued until hang-up.

hang-up.

Typical case - Cross-talk due to intra-office fault

Problem handling

Made call test to timeslot of A interface,

finding that the problem centered on
6the A interface frame of the first layer in
5
1
BSC1. After the backboard of the frame
was replaced with a new one, the
problem was solved.
Put the original EDRT board back
to position, the problem
Checked E1 head
phenomena didnt return, calls
and connection,
were established normally without
there was no
problem and no
monologue or cross-talk
crossed wires.

To handle the two

faulty E1

Connected the faulty E1

to BSC1 and MSCA, the
cross-talk problem
continued.

Changed EDRT board of

the corresponding slot in
BSC1 with a new one, the
problem disappeared, no
monologue or cross-talk
3
Changed DTI board of the happened;
corresponding slot in
MSCA with a new one,
the problem continued

Typical case - Cross-talk due to wrong data configuration

Problem description

Many subscribers complained about cross-talk problem in a

town, the problem centered in the area covered by a site.
Problem analysis

Made call test on site;

Its discovered that cross-talk occurred when MS occupied

BCCH timeslot2 of a cell under the site; while no similar
problem happened to other timeslots of other TRXs;

Changed the faulty TRX, but cross-talk still existed.

Typical case - Cross-talk due to wrong data configuration

Problem handling

Engineers checked BTS data, and it was discovered that there was
something wrong with the sub-timeslot ID configured to the channel
corresponding to timeslot2 on the BCCH TRX, which was the same as
that configured to the channel corresponding to timeslot3, hence crosstalk was resulted.
After further investigation, it was found that data configuration mistake
happened when OMCR engineers changed timeslot2 from SDCCH to
TCH in radio resource management.

it is suggested that the operation (change of channel

types) be performed in integrated configuration
management, so as to avoid data configuration mistakes.

Contents
Monologue
Cross-talk
Bidirectional Silence
Poor Speech Quality
Echo

Two-way silence Causes & handling of problem

Methods for handling two-way silence

Causes of two-way silence

Transmission circuits are selflooped;

The CIC codes at the two sides
of the circuit do not meet with each
other;
Some timeslots of the
transmission circuit adopted are not
good;
In the shared E1, timeslot
multiplexing equipment is not
configured with timeslots correctly;
DRT/EDRT or TIC fault.

First locate the problem area,

make certain if the problem is
prevalent in most sites or it just
appears in some sites;
If the problem is prevalent, we can
refer to cause 1, 2 and 5, and
make investigation accordingly;
If the problem just exists in some
sites, we can refer to cause 3 and
4, and make investigation
accordingly.

Typical case- Bidirectional silence due to A interface circuit fault

Problem description

An operator that subscribers in an area complained about

silence, monologue and echo problems in calls, which
returned to normal after a while (keep hang-on). These
problems also happened to BSC18, BSC19 (Siemens) and
BSC9 (ZTE) under ZTE MSC04.
Problem analysis

From the problem phenomena, it was certain that the

problem existed widely in most sites.

Engineers made call test on site.

Typical case- Bidirectional silence due to A interface circuit fault

Analysis

of test phenomena:
After handover from
Siemens cell to ZTE
cell, testers couldnt
hear each other.

Typical case- Bidirectional silence due to A interface circuit fault

Analysis

of test phenomena:

Speech was normal after establishment of call, but when inter-BSC handover
happened, testers could not hear each other but echo (their own voice), which
lasted for 15 seconds. When inter-BSC handover happened again, the call
returned to normal.
Third handover, from ZTE
24112 to Siemens 11581,
the call returned to
normal.
After handover from ZTE
28722to ZTE 24122,
testers still couldnt hear
each other.

Typical case- Bidirectional silence due to A interface circuit fault

Analysis of test phenomena:

Afterwards, test of handover during calls was made between cells

under ZTE BSC9, but the problem mentioned above didnt
happen.
Test

summary:

The call was normal at the beginning (both

parties could hear each other).

When inter-BSC handover occurred, two-way

silence emerged immediately;; when interBSC handover happened again, the call
returned to normal.

Inter-cell handover within one BSC wouldnt

bring such problem.

Because inter-BSC handover involves the

participation of MSC and the circuit exchange
connection at A interface, engineers
suspected that there was something wrong
with A interface circuit or MSC.

Typical case- Bidirectional silence due to A interface circuit fault

Flow chart of problem

handling

Call test engineer

Kept
tracing test
phone

Made call test

to catch
problem

The root cause of the problem is

maintenance peoples incorrect

Found problem

manipulation (during expansion

and swap of BSC A interface).

MSC engineer

Continued call test

Problem
disappeared
Problem solved

Confirmed single
board fault,
check the board
and wire
connection
2 pairs of PCM
were detected
selflooped,
amend the
mistake
Kept tracing
test phone

Contents
Monologue
Cross-talk
Bidirectional Silence
Poor Speech Quality
Echo

Poor call quality Causes & handling of problem

Poor

speech quality is mainly caused by the high speech error rate at radio

interface.
The

phenomenon of poor speech quality is: both MOC and MOC can get

through, but the speech quality is too bad, and there is clear noise in calls.

Causes of poor call quality

Low receive level;

internal or external interference;
BTS hardware fault, including
clock, TRX, and antenna, etc.; and
for BTS (V2.0) equipment, if the
toggle switch of the matched
resistance of E1 on CMM single
board isnt set correct, speech
quality will be affected;
BSC EDRT single board fault;
Some timeslots of the transmission
circuit adopted are not good.

Methods of handling poor call quality

First locate the problem area, make

certain if the problem is prevalent in
most sites or it just appears in some
sites;
If the problem is prevalent, we can
refer to cause 2, 4 and 5, and make
investigation accordingly;
If the problem just exists in some
sites, we can refer to cause 1 and 3,
and make investigation accordingly.

Typical case- Poor call quality due to EDRT fault

Problem description

Subscribers complaint about poor speech quality in a

swapped network gradually increased after Spring Festival.
Problem analysis

Subscribers who lodged complaint were scattered in

different counties, which meant that the problem was
prevalent in most BTSs.

Phenomena of on-site test:

When dialing or receiving calls, the party at the BTS area
could hear the counterparty, but couldnt be heard. This
meant that there was something wrong with the BTS UL
signal, which was reflected in on-and-off speech, trembling
voice accompanied with high current hum or background
noise.

Typical case- Poor call quality due to EDRT fault

Result of primary analysis:

The problem was caused by BSC hardware fault, like EDRT

board fault, etc..
Problem handling:

Made call test to all DSP of each EDRT in the BSC, found out
and replaced the faulty EDRT, the problem was solved.
Problem location:

Faulty DSP chips of BSC EDRT single boards resulted in

disorder in code conversion and rate adaptation and poor
speech quality.

Typical case- Poor call quality due to clock cable fault

Problem description

An operator reported subscribers complaint about poor

speech quality in the serving area of a site, metallic noise
appeared in calls.
Problem analysis

Since the problem subscriber complained was in a single site

area, engineers tentatively confirmed the cause was BTS
fault.
Problem handling

During the call test metallic knocking suddenly appeared and

it lasted for 30 seconds and then disappeared. In this
process, the MS remained busy.

Engineers carried out call test on TRXs one by one, and

finally found one faulty TRX. While the problem didnt
disappear even after the faulty TRX was replaced.

When clock cable of the TRX was replaced, the problem

disappeared.

Typical case- Poor call quality due to DTX fault

Problem description

An operator reported that in the area of a site near the capital city, background
noise often emerged during calls, which has affected normal communication.

Problem analysis

No BTS hardware fault: in test with YBT250, no UL interference was detected.

Result of call test: when both MOC and MTC were under the site, the two parties
could hear the same noise. When making calls with PSTN, only the PSTN
terminal could hear the noise, it was normal with MS side. At V1 sites, no noise
appeared. While the same problem happened to calls at V2 sites.

Summary: Cause of background noise should be wrong data configuration or

discrepancy in BTS or BSC versions.

Problem handling

After blocking UL power control and UL DTX of V2 site in OMCR, no background

noise was detected.

BTS V2 and BS30 (12M) could lead to the appearance of background noise. In the
future version 12O, this kind of problem will be solved.

Contents
Monologue
Cross-talk
Bidirectional Silence
Poor Speech Quality
Echo

Echo problem Phenomena

Two types of echo:

Generally speaking, echo means one party can hear his/her own
voice apart from the counterpartys voice during calls between digital
MSs or between digital MS and landline phone.

Another kind of echo-the loopback of voice means one party can hear
himself/herself but not the counterpartys voice, while the counterparty
can not hear anything during calls between digital MSs or between
digital MS and landline phone.

Echo problem Causes of echo

Causes of echo
Causes of echo
problem
problem
MS isolation performance isnt up
Echo in calls
Echo in calls
between MSs
between MSs

Echo in calls
Echo in calls
between MS
between MS
and landline
and landline
phone
phone

to standard in protocol

Echo canceller isnt added.

Wrong connection of A interface

Voice
Voice
loopback
loopback

trunk, hardware self-looped.

Echo problem Problem handling flow

Judge echo type

Calls between
MSs

Calls between MS
and landline
phone

Voice loopback

Judge echo type from customer feedback and call test.

Echo problem Problem handling flow

Judge echo type

Calls between
MSs

Calls between MS
and landline
phone

Voice loopback

Collect the MS type;

Use speech monitor;
Judge MS isolation performance, export explanatory document.

Echo problem Problem handling flow

Judge echo type

Calls between
MSs

Calls between MS
and landline
phone

Voice loopback

focus on finding out route data of the calls and make certain
that the data are correct;

when route data are configured right, check the EC

configuration of mobile network equipment to make sure the
EC is correct.;

If the problem occurs during inter-office calls, we need to

check if there are crossed-wires in outgoing office circuits.

Echo problem Problem handling flow

Judge echo type

Calls between
MSs

Calls between MS
and landline
phone

Voice loopback

Find out MSC call list according to number and time of

call;
Make call test to all intra-office and inter-office trunks
one by one;
Check the faulty trunk circuit according to CIC.

Typical case- Echo due to self-looped A interface trunk

Problem description

Subscribers at an area complained about echo problem in

calls.
Problem analysis

After checking large number of complaint letters and

performing call tests, its certain the problem was about
voice loopback. One party could only his/her own voice,
but the counterpartys voice; the counterparty could hear
nothing.

The problem only appeared under MSC 04.

Typical case- Echo due to self-looped A interface trunk

Start

Problem location: voice

Loopback appeared
under MSC04

End

Problem disappeared
in retest.

Solution to problem:
A group of engineers
made call test on site to
recreate the problem;
A group of MSC
engineers traced test
phone.
Figured out
corresponding single
board according to the A
interface trunk CIC taken
by MS, checked relevant
single board and wire
connection, finding PCM
was self-looped.
Handled problem:
adjusted
connection mistake.

Questions for thinking

What is the relation between call quality and MOS

value?
Please explain the common flow for handling
monologue problem.