go_na13_e1_1 gsm network speech quality problems & solutions 47

7/28/2019 GO_NA13_E1_1 GSM Network Speech Quality Problems & Solutions 47

http://slidepdf.com/reader/full/gona13e11-gsm-network-speech-quality-problems-solutions-47 1/47



Contents

Monologue Cross-talk

Bidirectional Silence

Poor Speech Quality Echo



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.

Confirm monologue

problem area

Monologue exists inthe whole MSC range

Monologue problemonly occurs in

outgoing calls

Monologue

problem only exists

in the coverage of a

BTS

Monologue

appears in therange of someBSCs or a certainnumber of BTSs

under the BSC

Monologue － Problem handling flow



Check corresponding outgoing trunk and data.

As for problems inside the office, check all parts

in the problem area.

Confirm monologueproblem area

Monologue exists in

the whole MSC range Monologue problem

only occurs in

outgoing calls

Monologue

problem only exists


BTS

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.

Confirm

monologue

problem area

Monologue exists

in the whole MSC

range

Monologue

problem only

occurs in

outgoing calls

Monologue

problem only

exists in the

coverage of a

BTS

Monologueappears in the

range of some

BSCs or a

certain number

of BTSs 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 MSCmaintenance 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).

Confirm monologue

problem area

Monologue

appears in therange of some

BSCs or a certain

number of BTSs

under the BSC

Monologue exists inthe whole MSC rangeMonologue problem

only occurs in

outgoing calls

Monologue

problem only exists


BTS




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.

Confirm monologueproblem area

Monologue exists inthe whole MSC rangeMonologue problemonly occurs in

outgoing calls

Monologueproblem only exists


BTS

Monologue

appears in the

range of some

BSCs or a certain

number of BTSs

under the BSC




Inter-office monologue cases Problem description

The operation and maintenance department of an operator complained to ZTE engineers that monologue existed inMeilong town.

In communication, ZTE engineers found that most sites under BSC4 have the problem, but BSC11 in the town didn’t have theproblem.

Problem analysis

ZTE engineers went to the site and made 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.

Intra-office call test

made calls to local landlinephone, monologuehappened, and theprobability of monologue

happening was about 40%. it was inferred that themonologue problem onlyexisted in calls betweendifferent offices (our operator’s office – ChinaTelecom), and the cause of problem should be with theoutgoing trunk and data.

Inter-office call test

Call test

method



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.

Process: adjustedconfiguration mistake

Problem solved

Start

End

Inter-office monologue case

Problem handling



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 concludedthat the monologueproblem was mainlycaused by thedefective TRX;monologue occurred

when MS occupiedthis TRX.

Problem handling When the defective TRX was replaced, engineers made CALL

TEST again and monologue problem disappeared, and theproblem didn’t 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 theprefectural government building area and a normal school (covered byBTS 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 DLspeech 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.

Repeater

Seriousmonologue

existed



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 causedby repeater interference. Closed repeater and made calltest again, metallic noise and monologue disappearedin calls.



Contents






Crossed-wires at A

interface;

incorrect exchange of

timeslots made by timeslot

multiplexing equipment

when the equipment is

used in transmission;

wrong configuration of

BTS data .

Causes of cross-talk

Locate problem area;

If cross-talk appears during intra-

office calls, check if there are crossed

wires at A interface first;

If cross-talk appears during inter-

office calls, check if there are crossed

wires in 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.

Methods for handling cross-talk

Cross-talk － Causes & handling of problem



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 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.




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:

When MTC answers the

call, it heard a third person’s

voice, and this continued

until hang-up.

Sometimes, both the MOCand MTC could hear nothing, and after a whilethey both heard the talkbetween another twopeople, and this continueduntil hang-up.

Sometimes, the MTC didn’t

hear anything at the

beginning, but heard cross-

talk after a while, and this

continued until hang-up.




fault

Problem handling

To handle the two

faulty E1

6 Made call test to timeslot of A interface,

finding that the problem 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 board back to

position, the

problem

phenomena didn’t

return, calls wereestablished

normally without

monologue or

cross-talk /

Changed DTI board of the

corresponding slot in MSCA

with a new one, the problem

continued

Connected the faulty

E1 to BSC1 and

MSCA, the cross-

talk problemcontinued.

Checked E1 head and

connection, there was

no problem and nocrossed wires.

Changed EDRT board of

the corresponding slot in

BSC1 with a new one, the

problem disappeared, no

monologue or cross-talk

happened;

5

4

3

2

1



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;

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 Problem handling

Engineers checked BTS data, and it was discovered that there wassomething wrong with the sub-timeslot ID configured to the channelcorresponding to timeslot2 on the BCCH TRX, which was the same asthat 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 toTCH 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






Two-way silence － Causes & handling of

problem

a.Transmission circuits are self-

looped;

b.The CIC codes at the two sides

of the circuit do not meet with eachother;

c.Some timeslots of the

transmission circuit adopted are not

good;

d.In the shared E1, timeslot

multiplexing equipment is notconfigured with timeslots correctly;

e.DRT/EDRT or TIC fault.

Causes of two-way silence

a. First locate the problem area,

make certain if the problem is

prevalent in most sites or it

just appears in some sites;b. If the problem is prevalent, we

can refer to cause 1, 2 and 5,

and make investigation

accordingly;

c. If the problem just exists in

some sites, we can refer to

cause 3 and 4, and make

investigation accordingly.

Methods for handling two-way silence



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.



Analysis of test phenomena:



After handover from

Siemens cell to ZTE

cell, testers couldn’t

hear each other.



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 ZTE24112 to Siemens 11581,

the call returned to

normal.

After handover from ZTE

28722to ZTE 24122,

testers still couldn’t hear

each other.





Analysis of test phenomena: 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 (bothparties 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.




interface circuit fault Flow chart of problem

handling

Found problem

Confirmed singleboard fault, checkthe board and wireconnection

2 pairs of PCM weredetected selflooped,amend the mistakeContinued call test

Problem

disappeared

Kept tracing

test phone

Call test engineer MSC engineer

Made call test

to catch

problem

Kept tracing

test phone

Problem solved

The root cause of the problem is

maintenance people’s incorrect

manipulation (during expansion

and swap of BSC A interface).



Contents






a. Low receive level;

b. internal or external interference;

c. BTS hardware fault, including

clock, TRX, and antenna, etc.; and

for BTS (V2.0) equipment, if the

toggle switch of the matchedresistance of E1 on CMM single

board isn’t set correct, speech

quality will be affected;

d. BSC EDRT single board fault;

e. Some timeslots of the transmission

circuit adopted are not good.

Causes of poor call quality

a. First locate the problem area,

make certain if the problem is

prevalent in most sites or it just

appears in some sites;

b. If the problem is prevalent, we

can refer to cause 2, 4 and 5,

and make investigationaccordingly;

c. If the problem just exists in

some sites, we can refer to

cause 1 and 3, and make

investigation accordingly.

Methods of handling poor call quality

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.



Typical case- Poor call quality due to EDRT

fault

Problem description Subscriber’s 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 couldn’t be heard. This

meant that there was something wrong with the BTS ULsignal, 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 subscriber’s 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 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 Problem description

An operator reported that in the area of a site near the capital city,background noise often emerged during calls, which has affectednormal 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, thetwo parties could hear the same noise. When making calls with PSTN,only the PSTN terminal could hear the noise, it was normal with MSside. At V1 sites, no noise appeared. While the same problemhappened to calls at V2 sites.

Summary: Cause of background noise should be wrong dataconfiguration 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






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 cannot hear anything during calls between digital MSs or between digital MS

and landline phone.



Causes of echoproblem

Causes of echoproblem

Echo in callsEcho in calls

between MSsbetween MSs


between MSsbetween MSs

VoiceVoice

loopbackloopback

VoiceVoice

loopbackloopback


between MSbetween MS

and landlineand landline

phonephone


between MSbetween MS

and landlineand landline

phonephone

MS isolation performance isn’t upMS isolation performance isn’t up

to standard in protocolto standard in protocol

Echo canceller isn’t added.Echo canceller isn’t added.

Wrong connection of A interfaceWrong connection of A interface

trunk, hardware self-looped.trunk, hardware self-looped.

Echo problem — Causes of echo



Judge echo type from customer feedback and call test.

Judge echo type Calls between MS

and landline

phone

Calls between

MSs

Voice loopback

Echo problem — Problem handling flow



Collect the MS type;

Use speech monitor;

Judge MS isolation performance, export explanatory document.


and landline

phone

Calls between

MSsVoice 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 theEC is correct.;

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

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


and landline

phone

Calls between

MSsVoice loopback




Find out MSC call list according to number and time of

call;

Make call test to all intra-office and inter-office trunksone by one;

Check the faulty trunk circuit according to CIC.

Judge echo type Voice loopbackCalls between MS

and landline

phone

Calls between

MSs


T i l E h d t lf l d A



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, 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.

T i l E h d t lf l d A



Problem location: voiceLoopback appeared

under MSC04

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 correspondingsingle 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. Problem disappearedin retest.

Start

End

Typical case- Echo due to self-looped A

interface trunk



Questions for thinking

What is the relation between call quality and MOSvalue?

Please explain the common flow for handling

monologue problem.

go_na13_e1_1 gsm network speech quality problems & solutions 47

Documents