GO - NAST3024 - E01 - 1 GSM Network Speech Quality Problems and Solutions 47

GSM Network Speech Quality
Problems & Solutions

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 BTS
MS BTS
MS (software&
(software&
hardware)
hardware)
Causes of
External Causes of
External monologue Abis
interference
interference monologue Abis
interface
interface
BSC(softwar
MSC BSC(softwar
MSC e&
(software& e&
(software& hardware)
hardware A interface hardware)
hardware A interface
(software &
(software &
hardware)
hardware)
© ZTE Corporation. All rights reserved

Monologue － Problem handling flow
Confirm Monologue Monologue Monologue Monologue

problem only exists in the appears in the problem only
monologue
occurs in outgoing whole MSC range of some
problem area exists in the
range BSCs or a certain
calls number of BTSs coverage of a BTS
under the BSC
 We can tell if it’s an inter-office or intra-office problem
from subscriber’s feedback and call test .

 If it’s 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 Monologue
Confirm Monologue Monologue appears in the problem only
monologue problem only exists in the range of some exists in the
problem area occurs in whole MSC BSCs or a certain coverage of a
outgoing calls range number of BTSs BTS
under the BSC
 Check corresponding outgoing trunk and data.

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

Monologue
Monologue Monologue appears in the Monologue
Confirm
problem only exists in the range of some problem only
monologue
occurs in whole MSC BSCs or a exists in the
problem area
outgoing calls range certain number coverage of a
of BTSs under BTS
the BSC
 Try to find out if customer or other relevant

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

Confirm Monologue Monologue Monologue

Monologue
monologue exists in the appears in the problem only
problem only
problem area whole MSC range of some exists in the
occurs in
range BSCs or a certain coverage of a
outgoing calls
number of BTSs BTS
under the BSC
 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 Monologue
Confirm Monologue Monologue appears in the problem only
monologue problem only exists in the range of some exists in the
problem area occurs in whole MSC BSCs or a coverage of a
outgoing calls range certain number BTS
of BTSs under
the BSC
 check cell’s 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 didn’t have the problem.
 Problem analysis
 ZTE engineers went to the site and made call test.
Intra-office call test Inter-office call test

 made calls to local landline
 CALL TEST between MSs phone, monologue happened,
inside the office, both MOC and the probability of
and MTC were under the monologue happening was
same BSC (BSC4) ;MOC was about 40%.
under BSC4, and MTC was
 it was inferred that the
under BSC11; no monologue monologue problem only
problem occurred in both Call test existed in calls between
different offices (our
situations. method operator’s office – China
Telecom), and the cause of
problem should be with the
outgoing trunk and data.

Inter-office monologue case
 Problem handling
Checked: if Any
changes on MSC
data or operations
Problem location: inter-office were performed
Start
during site swap?
Confirmed: trunk circuit

data were configured
wrong during the
expansion and swap of
Telecom outgoing circuits.
End
Process: adjusted
Problem solved configuration mistake

Typical case-Monologue due to TRX fault
 A great number of subscribers complained about monologue problem in a
town .
 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
 Engineers concluded that the
monologue problem was mainly
caused by the defective TRX;
monologue occurred when MS
occupied this TRX.
 When the defective TRX was
replaced, engineers made CALL TEST
again and monologue problem
disappeared, and the problem
didn’t occur in the following days.

Typical case-Monologue due to repeater fault
 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) .
 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


 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
 Echo
Cross-talk － Causes & handling of problem
Causes of cross-talk Methods for handling cross-talk
 Locate problem area;

 Crossed-wires at A interface;  If cross-talk appears during intra-office
calls, check if there are crossed wires at A
 incorrect exchange of timeslots
interface first;
made by timeslot multiplexing
 If cross-talk appears during inter-office
equipment when the equipment calls, check if there are crossed wires in
is used in transmission; outgoing office circuits ;
 wrong configuration of BTS data  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
 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 person’s voice or the
talk between another two people;
 The other was that when call drop happened to MOC or MTC, the
counterparty didn’t release the call but heard a third person’s voice after
more than 10 seconds.

 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:
When MTC answers the call, it Sometimes, the MTC didn’t

heard a third person’s voice, hear anything at the
and this continued until hang- beginning, but heard cross-
up. talk after a while, and this
Sometimes, both the MOC and continued until hang-up.
MTC could hear nothing, and

after a while they both heard
the talk between another two
people, and this continued
until hang-up.

6 Made call test to timeslot of A
interface, finding that the problem 5
1 centered on the A interface frame of
the first layer in BSC1. After the
backboard of the frame was
replaced with a new one, the
problem was solved. Put the original EDRT
Checked E1 head and board back to position,
connection, there was no the problem phenomena
problem and no crossed didn’t return, calls were
wires. established normally
without monologue or
cross-talk /
To handle the two
faulty E1 4
2 Connected the faulty E1
to BSC1 and MSCA, the Changed EDRT board of
cross-talk problem the corresponding slot in
continued. BSC1 with a new one, the
problem disappeared, no
3 monologue or cross-talk
happened;
Changed DTI board of the
corresponding slot in MSCA
with a new one, the problem
continued

Typical case - Cross-talk due to wrong data
configuration
 Many subscribers complained about cross-talk problem in a town, the
problem centered in the area covered by a site.
 Made call test on site;
 It’s 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
 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 cross-talk 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
 Echo
Two-way silence － Causes & handling of
problem
Causes of two-way silence Methods for handling two-way silence
① Transmission circuits are self- ① First locate the problem area,

looped; make certain if the problem is
② The CIC codes at the two sides prevalent in most sites or it just
of the circuit do not meet with appears in some sites;
each other; ② If the problem is prevalent, we
③ Some timeslots of the can refer to cause 1, 2 and 5,
transmission circuit adopted and make investigation
are not good; accordingly;
④ In the shared E1, timeslot ③ If the problem just exists in
multiplexing equipment is not some sites, we can refer to
configured with timeslots cause 3 and 4, and make
correctly; investigation accordingly.
⑤ DRT/EDRT or TIC fault.

Typical case- Bidirectional silence due to A
interface circuit fault
 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.
 From the problem phenomena, it was certain that the problem existed widely
in most sites.
 Engineers made call test on site.

 Analysis of test phenomena:
After handover from
Siemens cell to ZTE
cell, testers couldn’t
hear each other.

 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 couldn’t hear
each other.

 Afterwards, test of handover during calls was made between cells under ZTE
BSC9, but the problem mentioned above didn’t 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
inter-BSC handover happened again, the call returned to normal.

Inter-cell handover within one BSC wouldn’t 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.

 Flow chart of problem Call test engineer MSC engineer
handling
Kept tracing
Made call test to test phone
catch problem
The root cause of the

problem is maintenance Confirmed single
board fault, check the
board and wire
people’s incorrect Found problem connection
manipulation (during
expansion and swap of BSC A 2 pairs of PCM were
Continued detected selflooped,
amend the mistake
interface). call test
Problem Kept tracing

disappeared test phone
Problem solved
Contents
 Monologue
 Cross-talk
 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 Methods of handling poor call quality
① First locate the problem area, make

① Low receive level;
certain if the problem is prevalent in
② internal or external interference; most sites or it just appears in some
③ BTS hardware fault, including clock, sites;
TRX, and antenna, etc.; and for BTS ② If the problem is prevalent, we can
(V2.0) equipment, if the toggle refer to cause 2, 4 and 5, and make
investigation accordingly;
switch of the matched resistance of
③ If the problem just exists in some
E1 on CMM single board isn’t set sites, we can refer to cause 1 and 3,
correct, speech quality will be and make investigation accordingly.
affected;
④ BSC EDRT single board fault;
⑤ Some timeslots of the transmission
circuit adopted are not good.
Typical case- Poor call quality due to EDRT fault
 Subscriber’s complaint about poor speech quality in a swapped network
gradually increased after Spring Festival.
 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 couldn’t 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
 An operator reported subscriber’s complaint about poor speech quality in
the serving area of a site, metallic noise appeared in calls.
 Since the problem subscriber complained was in a single site area, engineers
tentatively confirmed the cause was BTS fault.
 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 didn’t 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
 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.
 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.
 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
 Echo
Echo problem － Phenomena
 Two types of echo:

 Generally speaking, echo means one party can hear his/her own voice apart
from the counterparty’s 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 counterparty’s 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 isn’t

Echo in calls
Echo in calls
between MSs up to standard in protocol
between MSs
Echo in calls
Echo in calls
between MS
between MS Echo canceller isn’t added.
and landline
and landline
phone
phone
Wrong connection of A
Voice
Voice
loopback interface trunk, hardware self-
loopback
looped.

Echo problem — Problem handling flow
Judge echo Calls between Voice

Calls between
MS and loopback
type MSs
landline phone
 Judge echo type from customer feedback and call test.

Calls between
Judge echo Calls between MS and landline Voice loopback
type MSs phone
 Collect the MS type;

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

Calls between
Judge echo Calls between Voice loopback
MS and landline
type MSs
phone
 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.

Calls between Voice

Judge echo Calls between
MS and landline loopback
type MSs
phone
 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
 Subscribers at an area complained about echo problem in calls. 。
 After checking large number of complaint letters and performing call tests,
it’s certain the problem was about voice loopback. One party could only
his/her own voice, but the counterparty’s voice; the counterparty could hear
nothing.
 The problem only appeared under MSC 04.

Typical case- Echo due to self-looped A interface
trunk
Solution to problem:
A group of engineers made
call test on site to recreate
the problem;
A group of MSC engineers
Problem location: voice traced test phone.
Start Loopback appeared
under MSC04
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.
End
Handled problem:
Problem disappeared adjusted
in retest. connection mistake.

Questions for thinking
 What is the relation between call quality and MOS value?

 Please explain the common flow for handling monologue
problem.

GO - NAST3024 - E01 - 1 GSM Network Speech Quality Problems and Solutions 47

Uploaded by

Copyright:

Available Formats

You might also like

GO - NAST3024 - E01 - 1 GSM Network Speech Quality Problems and Solutions 47

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GO - NAST3024 - E01 - 1 GSM Network Speech Quality Problems and Solutions 47

Uploaded by

Copyright:

Available Formats

GSM Network Speech Quality

Problems & Solutions

 To know the causes of speech quality problems

© ZTE Corporation. All rights reserved

Confirm Monologue Monologue Monologue Monologue

 We can tell if it’s an inter-office or intra-office problem

from subscriber’s feedback and call test .

is with some BSCs or all BSCs under the MSC

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

© ZTE Corporation. All rights reserved

 Check corresponding outgoing trunk and data.

in the problem area.

© ZTE Corporation. All rights reserved

 Try to find out if customer or other relevant

© ZTE Corporation. All rights reserved

Confirm Monologue Monologue Monologue

© ZTE Corporation. All rights reserved

 check cell’s radio parameters, whether UL/DL power link is

© ZTE Corporation. All rights reserved

Intra-office call test Inter-office call test

© ZTE Corporation. All rights reserved

Confirmed: trunk circuit

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

Causes of cross-talk Methods for handling cross-talk

 Locate problem area;

 wrong configuration of BTS data  Block the E1 equipment that uses

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

When MTC answers the call, it Sometimes, the MTC didn’t

Sometimes, both the MOC and continued until hang-up.

MTC could hear nothing, and

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

It is suggested that the operation (change of channel

© ZTE Corporation. All rights reserved

Causes of two-way silence Methods for handling two-way silence

① Transmission circuits are self- ① First locate the problem area,

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

Third handover, from ZTE

After handover from ZTE

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved

The root cause of the

Problem Kept tracing

Causes of poor call quality Methods of handling poor call quality

① First locate the problem area, make

© ZTE Corporation. All rights reserved

 Result of primary analysis:

© ZTE Corporation. All rights reserved

© ZTE Corporation. All rights reserved