Location update procedure and troubleshootingOne-way audio failure
troubleshooting methods
Echo failure troubleshooting methods
Noise failure troubleshooting methods
HUAWEI TECHNOLOGIES CO., LTD.
Chapter 2 Call Accompanied by Echoes
Chapter 3 Cross-talking
Symptom
*
One-way Audio or No Audio
*
Possible Causes
The common causes of one-way audio or no audio are as
follows:
Access faults on the TDM side
Faults in the interconnected device such as the base station
controller (BSC) or in the device on the network such as the public
switched telephone network (PSTN)
Incorrect TDM cable connection, for example, crossed pairs of TDM
cables or inconsistent configurations of the TDM interfaces on the
UMG8900 and the interconnected device
Faults in internal TDM processing on the UMG8900
TDM timeslot management error
Incorrect cascading optical fiber connection or cascading board
failure on the UMG8900
Faults in the hardware of the TDM switching network boards such as
the TNU, TNB, TNC, and TCLU, or the TDM resource boards such as the
E32, T32, S1L, S2L, and PIE on the UMG8900
Poor-quality IP bearer network
The bearer interface on the UMG8900 does not receive packets from
the interconnected device or the interconnected device does not
receive packets from the UMG8900.
Incorrect interconnection parameters on the IP side
*
One-way Audio or No Audio
The general troubleshooting procedure is as follows for One-Way
Audio Failure in TDM-IP Paths
Assume that user B can hear user A but user A cannot hear user B if
one-way audio occurs. To locate the fault, perform the following
operations:
Create user message trace tasks on the MGC and the UMG8900:
Perform a dialing test and keep the call connected when one-way
audio occurs:
Obtain the termination ID (TID) used by the caller and the callee
from the traced messages and check for the corresponding physical
timeslot on the UMG8900:
Perform an inloop or outloop for the timeslot used by the caller
and the callee and locate where the fault occurs:
If the fault occurs outside the UMG8900, check the cable connection
outside the UMG8900 or check the interconnected device; if the
fault occurs on the UMG8900, check the UMG8900:
*
Trace the messages
On the LMT of the MGC, create a task.
Create a user call trace task on the UMG8900.
*
Trace the messages
Perform a dialing test by using the traced user number.
When one-way audio or no audio occurs, keep the call
connected.
*
Trace the messages
Determine the TID used by the caller and the callee on the UMG8900.
Run DSP CTXINFO to query for the TID used by the caller and the
callee on the UMG8900.
The output description of the TID(Low) column is as follows:
The TID that starts with 0x40 corresponds to a TDM
termination.
The TID that starts with 0x30 corresponds to an IP
termination.
*
Locate the fault on the TDM side of user B.
*
Locate the fault on the TDM side of user B.
Perform an outloop for the TDM termination on user B side. The b
point in Figure shows the position of the outloop. Run LOP E1 to
perform a channel outloop.
LOP E1: FN=X, SN=Y, LOC=PORT, MODE=SCHOLOP, PN=Z, CN=S;
Figure Loopback on the TDM side
X is the number of the frame that houses the TDM interface board
(E32/S2L/S1L) where the TID of user B is located.
Y is the number of the slot that houses the TDM interface board
where the TID of user B is located.
Z is the number of the interface where the TID of user B is located
on the TDM interface board.
*
Locate the fault on the TDM side of user B.
After the outloop for user B, check whether user B can hear his/her
own voice.
Yes -> 14
No -> 12
Run DSP E1PORT to query for the settings of the TDM interface.
Check whether the related settings on the interfaces of the UMG8900
and its interconnected device are consistent.
Yes -> 13
No -> Contact technical support engineers of the interconnected
device on user B side, and execute 13.
Check whether the TDM cable connection on the two interconnected
devices are incorrect. For example, check whether crossed pairs of
TDM cables are present; check whether the TDM cable connection
between the transmitting and receiving interfaces on the two
interconnected devices is incorrect.
Yes -> Contact technical support for the interconnected device
on the user B side and modify the TDM connection, and execute
14.
No -> 14
Cancel the outloop on user B side. Run LOP E1 to cancel the outloop
on user B side.
*
Locate the fault on user A side.
Determine the bearer access mode on user A side.
IP mode -> 27
TDM mode -> 16
Run LOP E1 to perform an inloop for user A. The a and a1 points in
Figure show the positions of the inloop. Perform inloops segment by
segment along the TDM path.
*
Locate the fault on user A side.
After the inloop for user A, check whether user B can hear his/her
own voice.
Yes -> 20
No -> 18
Run DSP E1PORT to query for the settings of the TDM interface.
Check whether the related settings on the interfaces of the two
interconnected devices are consistent.
Yes -> 19
No -> Contact technical support engineers of the interconnected
device on user A side, and execute 19.
Check whether the TDM cable connection on the two interconnected
devices are incorrect. For example, check whether crossed pairs of
TDM cables are present; check whether the TDM cable connection
between the transmitting and receiving interfaces on the two
interconnected devices is incorrect.
Yes -> Contact technical support for the interconnected device
on the user A side and modify the TDM connection, and execute
20.
No -> 20
Run LOP E1 to cancel the inloop on user A side.
*
Locate the fault in TDM processing on the UMG8900
Check whether the related alarms are generated. Run LST ALMAF to
check whether the following alarms are generated:
ALM-0818 Cascading link connection fault
Clock related alarms on the CLK, and NETs.
Yes -> Handle the alarms according to the alarm help ->
22
No -> 23
Check whether the fault of one-way audio or no audio is
rectified.
Yes -> 39
No -> 23
Yes -> 25
No -> 24
Clear the fault in the cascading and check whether the fault of
one-way audio or no audio is rectified.
Yes -> 39
No -> 25
Locate the fault in TDM processing on the UMG8900
Check whether a board on the path between the two TDM interface
boards is faulty. Run SWP BRD to switch the master and slave boards
on the path between the two TDM interface boards in the sequence
from the TNU on the caller side, BLU in the central switching
frame, TNB in the central switching frame, BLU in the central
switching frame, to the TNU on the callee side.
After you switch one pair of master and slave boards, check whether
the fault of one-way audio or no audio is rectified.
Yes -> 26
No -> 38
Replace the faulty board, that is, the master board before the
switchover. After the board starts normally, perform a dialing test
and check whether the fault of one-way audio or no audio is
rectified.
Yes -> 39
No -> 38
Locate the fault in the IP bearer network.
Determine the local and remote IP addresses. Run DSP TERMINFO to
query for the information about the IP termination, including the
local and remote IP addresses, of the call.
*
Locate the fault in the IP bearer network.
Run PING to ping the remote IP address. PING: BT=HRB, SN=X, NUM=32,
IP="XX.XX.XX.XX", PKTSIZE=200;
Check whether the ping packets are returned normally.
Yes -> 30
No -> Contact Huawei technical support engineers to locate the
fault in the IP transport network.
Check the duplex mode of the IP bearer interface. Run DSP IPIF to
check whether the duplex mode of the IP bearer interface is
full-duplex.
Yes -> 32
No -> 31
Change the duplex mode of the IP bearer interface. Run MOD IPIF to
change the duplex mode of the IP bearer interface to
full-duplex.
Clear the statistics about the IP bearer interface. Run CLR IPIFSTS
to clear the statistics about the IP bearer interface.
Check the status of the IP bearer interface. After 10 seconds, run
DSP IPIF to query for the status of the IP bearer interface and
check whether a large number of error packets, for example, cyclic
redundancy check (CRC) error packets, are present.
Yes -> Contact Huawei technical support engineers to locate the
fault in the IP transport network.
No -> 34
.
Check the attributes of the IP termination in the traced H.248
messages.
*
.
Change the payload type of the codec to be consistent with the
payload type on the interconnected device. Run SET PAYLOADTYPE to
change the payload type of the codec. Then, perform a dialing test
and check whether the fault of one-way audio or no audio is
rectified.
Yes -> 39
No -> 36
Check whether the payload type of the IP termination conflicts with
the payload type of RFC2833 or RFC2198 packets. Run LST RFC2833 to
query for the values of Named Packet Payload Type and Tone Packet
Payload Type. Run LST TCPARA to query for the value of RFC2198
redundant RTP payload type. Check whether the payload type of the
IP termination conflicts with the payload type of RFC2833 or
RFC2198 packets.
Yes -> 37
No -> 38
Change the payload type. The settings of payload types must be
consistent on the entire network. Determine whether to modify the
payload type of the IP termination, or the payload type of RFC2833
or RFC2198 packets according to the planning. Run SET PAYLOADTYPE
to modify the payload type of the IP termination. Run SET RFC2833
to modify the payload type of RFC2833 packets. Run SET TCPARA to
modify the payload type of RFC2198 packets. Check whether the fault
of one-way audio or no audio is rectified.
Yes -> 39
No -> 38
.
Collect fault information and contact Huawei technical support
engineers.
The software abnormality is complex. Therefore, you need to collect
sufficient information, including running logs, operation logs,
call logs, system logs, and alarm information, for fault
location.
Run the following command to collect operation logs: LST LOG:
LTP=OPER, CNT=1000;
Run the following command to collect running logs: LST LOG:
LTP=RUN, CNT=1000;
Run the following command to collect call logs: LST LOG: LTP=CALL,
CNT=1000;
Run the following command to collect system logs: LST SYSLOG:
CNT=1000;
End.
One-Way Audio Failure in TDM-TDM Paths
Fault Symptom
2. Fault Analysis
The possible causes of one-way audio faults in TDM paths are as
follows:
Fault in the interworking device
Crossed pairs of TDM cables or inconsistent configurations of the
TDM
interfaces on the UMG8900 and the peer device
Incorrect connections of optical fibers of the UMG8900
Fault in the TDM switching network board or TDM resource board of
the
UMG8900
Introduction to loopback
A loopback refers to a troubleshooting technique in which a data
flow is returned to its source so that the data flow can be
analyzed for fault location at a certain end.
After the loopback function is enabled on an interface, all
services specific to the interface are interrupted. Therefore,
enable the loopback function only when you locate faults, and
disable the loopback function after the loopback test is
complete.
The UMG8900 supports three types of loopback modules:
TDM loopback (the loopback on the TDM interface board)
IP loopback (the loopback on the IP interface board)
ATM loopback (the loopback on the ATM interface board)
*
One-Way Audio Failure in TDM-TDM Paths
Step 1: Check whether the fault is caused by device A if user A
cannot hear the voice of
user B.
To locate the fault, you can perform an inloop on device A that
does not use any
EC resources. If user A cannot hear his/her own voice after the
inloop, it indicates that the fault is
caused by device A interconnected with the UMG8900. The possible
causes are
as follows:
Wrong connections of TDM cables. Check the cable connections
between
the UMG8900 and device A.
Inconsistent configurations of the TDM interfaces.
*
One-Way Audio Failure in TDM-TDM Paths
Step 2 Perform an outloop on the interface of the UMG8900 on the
side of device A.
*
One-Way Audio Failure in TDM-TDM Paths
Step 3 Perform an inloop on the interface of the UMG8900 on the
side of device B.
If user A cannot hear his/her own voice and the UMG8900 does not
use any EC resource, it indicates that the UMG8900 is faulty. If
user A can still hear his/her own voice, it indicates that the
bearer path along user A, device A, and the UMG8900 is normal. In
this case, check whether the cable connections between the UMG8900
and device B are correct and whether device B is normal.
*
One-Way Audio Failure in TDM-TDM Paths
Step 4 Record voices on the TDM interface through which the UMG8900
is interconnected with device B.
*
One-Way Audio Failure in TDM-TDM Paths
Step 5 Perform an inloop on the TDM interface through which the
UMG8900 is interconnected with device A. Then, record the voices on
the TDM interface to locate the device that introduces the
fault.
*
One-Way Audio Failure in TDM-TDM Paths
Step 6
Determine whether the optical fiber connections of the UMG8900 are
correct by checking whether "ALM-0818 Fault of CASCADE CONFLICT" is
generated and whether the transmitting and receiving of the TDM
cascading optical fibers are consistent with those of the TDM
cascading optical interfaces of the peer device and consistent with
MML configurations.
b. You can check whether one-way audio is caused by board faults by
querying information about active alarms. To check whether a
failure mode effective analysis (FMEA) alarm is generated, you need
to collect information about active alarms related to the TDM
interface board that connects device A and device B, active alarms
related to the master and slave TNUs in the frame where the TDM
interface board is located, and active alarms related to the
TNUs and BLUs in the central switching frame.
c. You can check whether the clock of the CLK is synchronous with
that of the
*
Fault Symptom
Fault Analysis
The possible causes of one-way audio in IP-IP paths are as
follows:
The UMG8900 does not receive any packet from the peer end or the
peer end does not receive any packet from the UMG8900.
2) The packets from the IP side are discarded during the check
because of errors.
3) The bearer table of the upper layer control software is
configured incorrectly, and thus the packets are discarded. The
bearer table includes the bearer processing information that is
negotiated by the upper layer control software when the call is
connected. Therefore, the wrong configurations of the bearer table
may be due to failure of the upper layer control software.
4) The packets are discarded because the GE plane of the UMG8900
fails.
*
One-way Audio or No Audio
One-Way Audio in IP-IP Paths
For causes 1), 2), and 5), you need to capture packets on the
mirrored bearer interface of the UMG8900 or record voices on the
UMG8900 to check whether the UMG8900 receives any packets from the
peer end or check whether the packet contents are correct.
For cause 3), you need to query the bearer table of the one-way
audio session, and then submit the table to Huawei R&D
engineers.
*
Echo
Symptom
Echo is the reflected copy of one's voice heard some time later and
a delayed version of the original
While effective, this approach leads to several problems:
Double-talk: It is fairly normal in conversation for both parties
to speak at the same time, at least briefly. Because each echo
suppressor will then detect voice energy coming from the far-end of
the circuit, the effect would ordinarily be for loss to be inserted
in both directions at once, effectively blocking both parties. To
prevent this, echo suppressors can be set to detect voice activity
from the near-end speaker and to fail to insert loss (or insert a
smaller loss) when both the near-end speaker and far-end speaker
are talking. This, of course, temporarily defeats the primary
effect of having an echo suppressor at all.
Clipping: Since the echo suppressor is alternately inserting and
removing loss, there is frequently a small delay when a new speaker
begins talking that results in clipping the first syllable from
that speaker's speech.
*
Possible Cause
The two factors of echoes in a communication network are as
follows:
1. Echo sources
Echoes occur due to low-quality handsets, cross-talking of
handsets, or echoes in surroundings are called acoustic echoes.
Acoustic echoes easily occur for a poor-quality phone in handfree
mode, cordless telephone, personal handyphone system,
teleconferencing terminal, or PC phone.
Echoes caused by the hybrid, which is the transformer that joins
the two-wire analog local loop to the four-wire transmission
network, are called electrical echoes.
2. Long network delay
*
The common causes of echoes are as follows:
Echoes are acoustic echoes. Acoustic echoes are usually not handled
on the media gateway (MGW).
The echo canceller chip on the MGW is faulty.
The echo cancellation (EC) configurations are incorrect. For
example, the echo canceller is disabled; EC parameters such as the
bypass EC switch are incorrect; the tail length of the echo
canceller is insufficient; EC option is set to YES.
*
Echo
A mobile station (MS) calls another MS and the two MSs are
controlled by one MGW
*
Echo
An MS calls a fixed-line phone in the public switched telephone
network (PSTN).
*
The general troubleshooting procedure is as follows:
Rectify the fault in the echo canceller chip on the UMG8900:
Rectify the EC configurations:
Check whether EC resources are added to the UMG8900 during the
call:
*
Echo
Check whether the echo canceller chip on the UMG8900 is
faulty.
Check whether the echo canceller chip is faulty. If echoes occur
sporadically or periodically, the EC chip on the VPU or ECU is
faulty. Run DEA BRD to deactivate the VPU or ECU. Then, perform
dialing tests to check whether echoes still occur sporadically or
periodically.
*
Check whether the EC configurations on the UMG8900 are
correct.
Run LST ECPARA to check settings of the bypass EC switches.
LST ECPARA: BT=VPU;
LST ECPARA: BT=ECU;
The bypass EC switch on the VPU or ECU is enabled or disabled
Change the EC tail length. Run SET ECPARA to change the EEC tail
length from 64 ms to 128 ms. Then, perform a dialing test to check
whether echoes still occur.
Check whether EC option is set to YES. Run LST ECPARA to check
whether EC option is set to YES.
*
Echo
Check whether EC resources are added to the UMG8900 during the
call.
Create a user call tracing task on the UMG8900. Perform a dialing
test by using the traced user number. When echoes occur, keep the
call connected.
Check whether EC resources are added for the call by analyzing
H.248 signaling messages. Check whether EC resources are added in
the ADD REQ and MOD REQ messages
3. enable the EC function on the MGC
*
Echo
Check whether EC resources are added to the UMG8900 during the
call.
*