go_na13_e1_1 gsm network speech quality problems & solutions
DESCRIPTION
this ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,TRANSCRIPT
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
Causes of
Wireless Wireless partpart
BTS BTS (software& (software& hardware)hardware)
MSMS
Monologue-Causes
Causes of monologue
MSC MSC (software& (software& hardwarehardware
BSCBSC(softwar(software& hardware)e& hardware)
Abis interfaceAbis interfaceExternal External
interferencinterferencee
A interface A interface (software & (software & hardware)hardware)
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
Monologue appears in the range of some BSCs or a certain number of BTSs under the
BSC
Monologue-Problem handling flow
� 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 pr oblem
is with some BSCs or all BSCs under the MSC
� Find out if the problem is with some sites or all s ites
under a BSC.
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
Monologue appears in the range of some BSCs or a certain number 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 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
Monologue appears in the range of some BSCs or a certain number of BTSs under the BSC
Monologue-Problem handling flow
� 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 appears in the range of some BSCs or a certain number of BTSs under the BSC
Monologue exists in the whole MSC rangeMonologue problem
only occurs in outgoing calls
Monologue problem only exists in the coverage of a BTS
Monologue-Problem handling flow
� first check if the version of BSC DRT is upgraded t o 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 proble m still exists.
� When analyzing and locating this problem, we can ope n 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, calc ulate the corresponding single board to
check the boards and connection wires (all single b oards and connection wires between E3M
and NET, including backboards).
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
Monologue appears in the range of some BSCs or a certain number of BTSs under the BSC
Monologue-Problem handling flow
� check cell’s radio parameters, whether UL/DL power link is balanced or not (collect data through signaling tra cing), whether MS max transmission power is set correct or not.
� make call test and check hardware to find out if ha rdware problems exist, such as equipment connection proble m, 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.
Inter -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.
Intra-office call test
� made calls to local landline phone, monologue happened, and the probability of monologue
happening was about 40%.� it was inferred that the
monologue problem only existed in calls between different offices (our operator’s office – China Telecom), and the cause of problem should be with the outgoing 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
Start
Inter-office monologue case
� Problem handling
Confirmed: trunk circuit data were configured wrong during the expansion and swap of Telecom outgoing circuits.
Process: adjusted configuration mistakeProblem solved
End
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 � 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 occurredwhen MS occupiedthis TRX.this TRX.
� Problem handling� 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� 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.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.
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
� Crossed-wires at A
interface;
� incorrect exchange of
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-
Methods for handling cross-talk
Cross-talk - Causes & handling of problem
timeslots made by timeslot
multiplexing equipment
when the equipment is
used in transmission;
� wrong configuration of
BTS data .
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.
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 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.
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:
�
When MTC answers the call,
it heard a third person’s voice,
and this continued until hang-
up.
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.
Sometimes, the MTC didn’t hear anything at the beginning, but heard cross-talk after a while, and this continued until hang-up.
Typical case - Cross-talk due to intra-office fault� Problem handling
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 were established normally without
Checked E1 head and connection, there was no problem and no crossed wires.
51
To handle the two faulty E1
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 problem continued.
crossed wires.
Changed EDRT board of the corresponding slot in BSC1 with a new one, the problem disappeared, no monologue or cross-talk happened;
4
3
2
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 � 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 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. 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
① Transmission circuits are self-looped; ② The CIC codes at the two sides of the circuit do not meet with each other;
Causes of two-way silence
① 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
Methods for handling two-way silence
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.
② 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� 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:
Typical case- Bidirectional silence due to A interface circuit fault
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.
Typical case- Bidirectional silence due to A interface circuit fault
Third handover, from ZTE 24112 to Siemens 11581, 24112 to Siemens 11581, the call returned to normal.
After handover from ZTE 28722to ZTE 24122, testers still couldn’t 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 didn’t happen.
�Test summary:
�The call was normal at the beginning (both parties could hear each other). 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.
Typical case- Bidirectional silence due to A interface circuit fault� Flow chart of problem
handling
Confirmed single board fault, check the board and wire
Call test engineer MSC engineer
Made call test to catch problem
Kept tracing test phone
The root cause of the problem is Found problem
the board and wire connection
2 pairs of PCM were detected selflooped, amend the mistakeContinued call test
Problem disappeared
Kept tracing test phone
Problem solved
maintenance people’s incorrect
manipulation (during expansion
and swap of BSC A interface).
Contents
� Monologue � Cross-talk� Bidirectional Silence � Poor Speech Quality� Echo
Causes of poor call quality
①①①① First locate the problem area,
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.
①①①① 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 isn’t set correct, speech quality will be affected;
④④④④ BSC EDRT single board fault;⑤⑤⑤⑤ Some timeslots of the transmission
circuit adopted are not good.
①①①① 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� 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 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.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� 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 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, 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 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 not hear anything during calls between digital MSs or between digital MS and landline phone.
Causes of echo problem
Echo in calls Echo in calls between MSsbetween MSs
MS isolation performance isn’t up MS isolation performance isn’t up
to standard in protocolto standard in protocol
Echo problem — Causes of echo
Voice Voice loopbackloopback
Echo in calls Echo in calls between MS between MS and landline and landline
phonephone
Echo canceller isn’t added.Echo canceller isn’t added.
Wrong connection of A interface Wrong connection of A interface
trunk, hardware selftrunk, hardware self--looped.looped.
Judge echo type Calls between MS and landline
phone
Calls between MSs
Voice loopback
Echo problem — Problem handling flow
� Judge echo type from customer feedback and call tes t.
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.
Judge echo type Calls between MS and landline
phone
Calls between MSs
Voice loopback
Echo problem — Problem handling flow
� focus on finding out route data of the calls and ma ke
certain that the data are correct;
� when route data are configured right, check the EC
configuration of mobile network equipment to make s ure
the EC is correct.;
� If the problem occurs during inter-office calls, we need
to check if there are crossed-wires in outgoing off ice
circuits.
Judge echo type Voice loopbackCalls between MS
and landline phone
Calls between MSs
Echo problem — Problem handling flow
� 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, it’s certain the problem was about voice loopback. 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.
Problem location: voice Loopback 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 corresponding single board according to
Start
Typical case- Echo due to self-looped A interface trunk
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.Problem disappeared in retest.
End
Questions for thinking
� What is the relation between call quality and MOS value?
� Please explain the common flow for handling monologue problem.