Radio Related Problems

You might also like

You are on page 1of 4

Radio Related Problems

Contents
 Configuration Checks
 Machine Checks
 Diagnosing Radio Problems with Test Calls
 Diagnosing Radio Problems with the “chans” Command
o What do those “chans” numbers mean?
o What do those “chans” numbers mean?
 Path Loss Symmetry
 The “pathloss” option
 Using the “noise” Command
 Diagnosing RACH-Related Radio Problems
 Fixing Radio-Related Problems
o Uplink Interference and Multipath
o High Path Loss (Uplink or Downlink)
 Symmetric
 Asymmetric
 Our solutions

This section will go through the typical problems a user can encounter when using YateBTS.

Radio-related problems usually fall into these broad categories:


 Uplink Problems, Specific to the RACH - The MBTS component is receiving RACH bursts from the handset, but fails to
decode them.
 Uplink Problems, General - There are speech problems in the uplink side of a phone call, and sometimes with slow call
setup signaling.
 Downlink Problems - There are speech problems in the downlink side of a phone call, and sometime with slow call setup
signaling.

Typical causes of radio-related problems are:


 physical damage, like mechanical damage or corrosion
 interference
 power limitations, due to range or misconfiguration
 excessive power, due to misconfiguration
Configuration Checks

Start a diagnosis by checking the configuration. Unless you have a specific, known reason, all of the following parameters should
match their factory-set values:
 MS.Power.Max
 Radio.RSSITarget
 Radio.RxGain
 MinimumRxRSSI
 RadioFrequencyOffset
 TxAttenOffset
 Radio.MaxExpectedDelaySpread

To verify this settings you can check the parameters in the ybts.conf  configuration file or use the ‘mbts config’ telnet command.

Ex:
mbts config MS.Power.Max
GSM.MS.Power.Max 33 [default]
Machine Checks

CPU performance problems can cause the same symptoms as radio problems. Use the Linux ‘top‘ utility to make sure that the CPU is
not overloaded.

Test GSM BTS now!

Diagnosing Radio Problems with Test Calls

A good way to test uplink vs. downlink is to use the echo test and the tone test together:
Echo Test Tone Test Diagnosis
good good no problem
good poor not a radio problem
poor good uplink problem
poor poor downlink problem and possible uplink problem
no service downlink problem or network problem
failure to connect uplink problem, possibly RACH-specific
Diagnosing Radio Problems with the "chans" Command

If you can get a phone call to connect, even with poor quality, the ‘mbts chans’ command is a powerful diagnosis tool.

During either the tone or echo test, you can use the mbts chans command to collect performance measurements from both the uplink
and the downlink. The fields of the chans command relevant to this discussion are:
UPFER RSSI TXPWR TXTA DNLEV DNBER
pct dB dBm sym dBm pct
What do those "chans" numbers mean?

The uplink performance numbers are measured by the MBTS itself and are updated roughly every half second. These numbers are:
 Uplink RSSI ("RSSI-dB"), given in dB (negative) relative to the full scale input of the radio. This is the power level of the
handset as seen by the MBTS. This value is normally within a few dB of the value given in the 'gsm_advanced::Radio.RSSITarget'
configuration parameter.
 Uplink FER ("UPFER-pct"), as a percentage, which is normally close to zero when Uplink RSSI is > -45 dB.

The downlink performance numbers are reported by the handset on the SACCH, which means that they are updated only when the
channel allows data to be received from the phone. Normally, these are also updated roughly every half second, but these updates can
stop or become less frequent if the channel quality is poor.
 Downlink RSSI ("DNLEV-dBm"), given in dBm. This is the received power level of the MBTS as seen by the handset. It is
normally > -100 dBm.
 Downlink BER ("DNBER-pct"), given in percent. This is normally close to zero for downlink RSSI > -100 dBm.

The handset also reports its actual transmitter power level, in dBm, displayed as “TXPWR-dBm”.
What do those "chans" numbers mean?

The output of “chans” can be used to diagnose radio problems using the following table:
UPFER RSSI TXPWR DNLEV DNBER Diagnosis
pct dB dBm dBm pct
small > -45 anything > -100 small normal
high > -45 anything anything anything uplink interfere
high < -45 >= 30 anything anything high uplink pat
high < -45 < 30 anything anything poor uplink pow
anything anything anything > -100 high downlink interf
anything anything anything < -100 high high downlink
Path Loss Symmetry

Here is another way to help distinguish between uplink problems and downlink problems: “path loss symmetry”.

“Path loss” is the signal loss from the output of the transmitter to the input of the receiver, due to the propagation of the signal through
space, usually expressed in dB Path losses are anywhere from 60 to 160 dB for GSM radio links and vary tremendously with distance
and obstacles along the path (trees, buildings, hills, etc.). Across this huge range, though, path losses are normally close to symmetric
for similar frequencies between the same two antennas. Uplink and downlink path losses in a mobile network are about the same, on
average and most of the time. By knowing path loss and comparing uplink and downlink path loss, we can better isolate radio
performance problems.

The downlink path loss can be estimated from the “chans” output as:
P_up (dBm) = TXPWR (dB) + RSSI (dB) + 60 (dBm)

The factor of 60 dBm is due to that fact that a full scale input on the radio corresponds to a power level of -60 dBm at the antenna
input. Note that this estimate is not valid when RSSI is > -3 dB, since the receiver is close to saturation.

The uplink path loss is estimated as:


P_dn (dBm) = actual downlink power (dBm) + DNLEV (dB)

Note that this measurement is valid only when DNLEV is < -40 dBm, since that is the normal saturation point of the handset.

The uplink and downlink path loss, if both are valid, should be within 10 dB of each other. If they are not within 10 dB of each other,
even after moving the handset around about 0.5 meter, that indicates a problem in the link with the larger path loss
The "pathloss" option

This option prints the uplink and downlink path loss for the existing GSM channels, together with the noise value, maximum output
power of the device and the current power attenuation.

This is the output generated by the pathloss option when using YateBTS with a RAD1 radio with no antenna on the RX side:
chan UPFER RSSI TXPWR DNLEV DNBER P_up P_dn Diagnosys
type pct dB dBm dBm pct dB dB
SDCCH/4-0 0.00 0 33 -111 0.00 83.00 144.00 inactive
SDCCH/4-1 0.00 0 33 -111 0.00 83.00 144.00 inactive
SDCCH/4-2 0.00 0 33 -111 0.00 83.00 144.00 inactive
SDCCH/4-3 0.00 0 33 -111 0.00 83.00 144.00 inactive
TCH/F 0.00 0 33 -111 0.00 83.00 144.00 inactive
TCH/F 0.00 0 33 -111 0.00 83.00 144.00 inactive
TCH/F 0.00 -47 5 -48 1.13 102.00 81.00 bad uplink path
TCH/F 0.00 0 33 -111 0.00 83.00 144.00 inactive
TCH/F 0.00 0 33 -111 0.00 83.00 144.00 inactive
TCH/F 0.00 0 33 -111 0.00 83.00 144.00 inactive
TCH/F 0.00 0 33 -111 0.00 83.00 144.00 inactive
Current power attenuation: 0 dB
Maximum output power: 33 dBm
noise RSSI is -69 dB wrt full scale
MS RSSI target is -50 dB wrt full scale
How to use it:
mbts chans pathloss

Possible results for the Diagnosys:


 "bad uplink path" when P_up exceeds P_dn by 15 dB
 "bad downlink path" when P_dn exceeds P_up by 15 dB
 "inactive" for the inactive channels
 "normal" otherwise

If the noise level exceeds -65 dB you will see a warning:


WARNING: excessive uplink noise - possible interference or rxgain miscalibration.

Test GSM BTS now!

Using the "noise" Command

The “noise” command is simple: it returns the receiver noise level in dB relative to full scale. This number should be about -55 dB +/-
3 dB, which corresponds to a noise floor of -115 dBm.

If the noise level is consistently < -60 dB, it means that the receiver gain is set too low.

If this noise level is consistently > -50 dB, it can mean one of two things. Either:
 the receiver gain is set too high or
 there is interference in the uplink side of the link.
Diagnosing RACH-Related Radio Problems

If your handset shows service but cannot connect a call, you must look at the RACH channel to diagnose the problem. RACH
diagnostic activity appears in the output log. To see it, set the logging level for {{{RadioResource.cpp}}} to {{{INFO}}}.
RACH activity RACH RSSI Diagnosis
uncorrelated with handset activity, every few seconds < -40 dB normal fa
uncorrelated with handset activity, several per second < -40 dB uplink int
correlated with handset access attempts > -20 dB normal, se
correlated with handset access attempts < -20 dB misconfig

Note 1: If the RACH activity is normal and calls are not connecting, then there is either radio channel congestion or a problem in a
higher networking layer.
Fixing Radio-Related Problems
Uplink Interference and Multipath

Uplink interference results from another radio transmitter in the area sending signals on the same frequency as your uplink ARFCN. If
the transmitted signal is particularly powerful, it can be a problem anywhere in your uplink band, not just on your specific uplink
ARFCN. Interference can also come from “unintentional radiators”, like poorly-shielded computer and/or networking equipment near
the antenna.

Multipath  is the radio equivalent of a strong, distracting echo that makes it difficult for the receiver to correctly decode the uplink
signal.

Uplink interference and multipath share a common symptom: excessive uplink FER even when the uplink RSSI is at normal levels.
There are some differences, though, that allow you to tell them apart, as shown in the following table.
Action / Check Uplink Interference
check "noise" command elevated noise ( > -50)
raise value of MinimumRxRSSI lower FER
raise value of Radio.MaxExpectedDelaySpread same FER
check at different times effect may vary with time

As the above table indicates, uplink interference can be mitigated by raising MinimumRxRSSI and multipth can be mitigated by
raising Radio.MaxExpectedDelaySpread. For each of these there is a price to be paid.

Raising MinimumRxRSSI will lower the battery life of handsets in the service area. Also, even with this mitigation, the cell will not
be able to achieve its full intended service range unless the interference is removed or avoided. Often, the best solution is to scan the
uplink band (an corresponding downlink band) to choose an ARFCN with less interference.

Raising Radio.MaxExpectedDelaySpread will increase the computational load of the MBTS, but it is usually the only solution to the
multipath problem.
High Path Loss (Uplink or Downlink)

High path loss is usually due to distance or equipment damage, but can also be caused by misconfiguration of the “advanced”
parameters.
Symmetric

Path loss over large distances is normal; you may just be at the operating limit of the radio link. If your path loss is large and
generally symmetric on both uplink and downlink, this is probably the case. The possible solutions to this problem are:
 higher antenna gain
 high antenna placement
 lower cable loss between the antenna and radio

 by using a better cable or


 by eliminating excess cable length from the path
 more output power on the downlink, if

 the downlink quality is poorer than the uplink quality and


 the output power is not already high:
o >= 5 W/ARFN in a high band (1800/1900) or
o >= 10 W in a low band (850/900)

Note that more downlink power, beyond the levels given above, will not improve overall performance, since the power output of the
handset is usually limited to 1 W in the high bands and 2 W in the lower bands. Add more downlink power beyond these limits will
just result in an asymmetric link.

If the path loss is excessively even over modest distances, and your uplink and downlink share a common antenna through a duplexer,
then the problem could be in the shared antenna, the duplexer, or the cabling between them.
 Check that the antenna is properly installed, clear of obstructions in its near field.
 Check for cable damage.
 Check for loose connectors. In outdoor installations, an improperly sealed connector can allow water to enter a cable,
leading to internal corrosion which can be difficult to diagnose directly. If you find a loose connector in an outdoor installation than
has been rained on, chances are high that the entire cable is ruined.
 Check that all connectors are undamaged, free of corrosion and properly torqued.
Asymmetric

Asymmetric path loss means that the path loss is notably larger on one side of the link than the other. This usually means damage to
some component that is specific to one side of the link, but can also be due to misconfiguration or mis-calibration. Double check that
all receive and transmit gain parameters match their calibrated factory settings.

If all configuration parameters are correct, possible causes of asymmetric path loss are:
 Excessive downlink path loss probably means a failure of the power amplifier or the power supply for the power amplifier.
 Excessive uplink path loss probably means a failure of an LNA or its associated power supply.
 A damaged duplexer can also produce asymmetric path loss. However, damage to cavity duplexers is usually cause be
excessive mechanical shock and a unit that has suffered such a shock will also show other signs of mechanical abuse.

You might also like