Difference between revisions of "Radio Related Problems"

From YateBTS
Jump to: navigation, search
(Created page with "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 f...")
 
Line 1: Line 1:
 
Radio-related problems usually fall into these broad categories:
 
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, 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.  These may be accompanied by very slow call setup signaling.
+
* Uplink Problems, General - There are speech problems in the uplink side of a phone call.  These may be accompanied by very slow call setup signaling.
* Downlink Problems - There are speech problems in the downlink side of a phone call. These may be accompanied by very slow call setup signaling.
+
* Downlink Problems - There are speech problems in the downlink side of a phone call. These may be accompanied by very slow call setup signaling.
  
 
Typical causes of radio-related problems include:
 
Typical causes of radio-related problems include:
* physical damage, like mechanical damage or corrosion
+
* physical damage, like mechanical damage or corrosion
* interference
+
* interference
* power limitations, due to range or misconfiguration
+
* power limitations, due to range or misconfiguration
* excessive power, due to misconfiguration
+
* excessive power, due to misconfiguration
  
 
We will now consider the diagnosis and correction of these problems in detail.
 
We will now consider the diagnosis and correction of these problems in detail.
Line 15: Line 15:
 
Start a diagnosis by checking the configuration.
 
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:
 
Unless you have a specific, known reason, all of the following parameters should match their factory-set values:
* {{{MS.Power.Max}}}
+
* MS.Power.Max
* {{{Radio.RSSITarget}}}
+
* Radio.RSSITarget
* {{{Radio.RxGain}}}
+
* Radio.RxGain
* {{{MinimumRxRSSI}}}
+
* MinimumRxRSSI
* {{{RadioFrequencyOffset}}}
+
* RadioFrequencyOffset
* {{{TxAttenOffset}}}
+
* TxAttenOffset
* {{{Radio.MaxExpectedDelaySpread}}}
+
* Radio.MaxExpectedDelaySpread
  
 
== Machine Checks ==
 
== Machine Checks ==
Line 45: Line 45:
 
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.
 
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 "chains" command relevant to this discussion are:
 
The fields of the "chains" command relevant to this discussion are:
{{{
+
UPFER RSSI TXPWR TXTA DNLEV DNBER
UPFER RSSI TXPWR TXTA DNLEV DNBER
+
pct    dB  dBm  sym  dBm  pct  
pct    dB  dBm  sym  dBm  pct  
+
 
}}}
+
  
 
=== What do those "chans" numbers mean? ===
 
=== 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:
 
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 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.
+
* 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.
 
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 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.
+
* 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".
 
The handset also reports its actual transmitter power level, in dBm, displayed as "TXPWR-dBm".
  
Line 83: Line 82:
  
 
The downlink path loss can be estimated from the 'chans" output as
 
The downlink path loss can be estimated from the 'chans" output as
{{{
+
P_up (dBm) = TXPWR (dB) + RSSI (dB) + 60 (dBm)
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 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  
 
The uplink path loss is estimated as  
{{{
+
P_dn (dBm) = actual downlink power (dBm) + DNLEV (dB)
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.
 
Note that this measurement is valid only when DNLEV is < -40 dBm, since that is the normal saturation point of the handset.
  
Line 105: Line 100:
 
If this noise level is consistently > -50 dB, it can mean one of two things.
 
If this noise level is consistently > -50 dB, it can mean one of two things.
 
Either:
 
Either:
* the receiver gain is set too high or
+
* the receiver gain is set too high or
* there is interference in the uplink side of the link.
+
* there is interference in the uplink side of the link.
  
 
== Diagnosing RACH-Related Radio Problems ==
 
== Diagnosing RACH-Related Radio Problems ==
Line 140: Line 135:
 
||  check at different times  ||  effect may vary with time  ||  effect is constant over time  ||
 
||  check at different times  ||  effect may vary with time  ||  effect is constant over time  ||
  
As the above table indicates, uplink interference can be mitigated by raising {{{MinimumRxRSSI}}} and multipth can be mitigated by raising {{{Radio.MaxExpectedDelaySpread}}}.
+
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.
 
For each of these there is a price to be paid.
  
Raising {{{MinimumRxRSSI}}} will lower the battery life of handsets in the service area.
+
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.
 
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.
 
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.
+
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 (Uplink or Downlink) ===
Line 156: Line 151:
 
If your path loss is large and generally symmetric on both uplink and downlink, this is probably the case.
 
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:
 
The possible solutions to this problem are:
* higher antenna gain
+
* higher antenna gain
* high antenna placement
+
* high antenna placement
* lower cable loss between the antenna and radio
+
* lower cable loss between the antenna and radio
  * by using a better cable or
+
** by using a better cable or
  * by eliminating excess cable length from the path
+
** by eliminating excess cable length from the path
* more output power on the downlink, '''if'''
+
* more output power on the downlink, '''if'''
  * the downlink quality is poorer than the uplink quality '''and'''
+
** the downlink quality is poorer than the uplink quality '''and'''
  * the output power is not already high:
+
** the output power is not already high:
  * >= 5 W/ARFN in a high band (1800/1900) or
+
*** >= 5 W/ARFN in a high band (1800/1900) or
  * >= 10 W in a low band (850/900)  
+
*** >= 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.
 
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.
Line 171: Line 166:
  
 
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.
 
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 that the antenna is properly installed, clear of obstructions in its near field.
* Check for cable damage.
+
* 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 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 connectors are undamaged, free of corrosion and properly torqued.
+
* Check that connectors are undamaged, free of corrosion and properly torqued.
* Check that the power level at the duplexer output is correct.  If not, you may have a damaged duplexer.
+
* Check that the power level at the duplexer output is correct.  If not, you may have a damaged duplexer.
  * Cavity duplexers can be damaged by excessing mechanical shock or vibration.
+
** Cavity duplexers can be damaged by excessing mechanical shock or vibration, especially if the equipment showed signs of abuse from shipping.
  * SAW duplexers can be damaged by ESD or excessive power.
+
** SAW duplexers can be damaged by ESD or excessive power.
  
 
==== Asymmetric ====
 
==== Asymmetric ====

Revision as of 15:42, 7 March 2014

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. These may be accompanied by very slow call setup signaling.
  • Downlink Problems - There are speech problems in the downlink side of a phone call. These may be accompanied by very slow call setup signaling.

Typical causes of radio-related problems include:

  • physical damage, like mechanical damage or corrosion
  • interference
  • power limitations, due to range or misconfiguration
  • excessive power, due to misconfiguration

We will now consider the diagnosis and correction of these problems in detail.

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

Machine Checks

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

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 "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 "chains" 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 Template: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".


Diagnosing with "chans" Output

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 interference or multi-path || || high || < -45 || >= 30 || anything || anything || high uplink path loss || || high || < -45 || < 30 || anything || anything || poor uplink power control || || anything || anything || anything || > -100 || high || downlink interference or multi-path || || anything || anything || anything || < -100 || high || high downlink path loss or low output power ||

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

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 connect 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, the the logging level for {{{RadioResource.cpp}}} to {{{INFO}}}.

||= RACH activity =||= RACH RSSI =||= Diagnosis =|| || uncorrelated with handset activity, every few seconds || < -40 dB || normal false alarms || || uncorrelated with handset activity, several per second || < -40 dB || uplink interference or misconfigured gain || || correlated with handset access attempts || > -20 dB || normal, see Note 1 || || correlated with handset access attempts || < -20 dB || misconfiguration or excessive uplink path loss ||

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 =||= Multipath =|| || check "noise" command || elevated noise ( > -50) || normal || || raise value of {{{MinimumRxRSSI}}} || lower FER || same or higher FER || || raise value of {{{Radio.MaxExpectedDelaySpread}}} || same FER || lower FER || || check at different times || effect may vary with time || effect is constant over 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:
      • >= 5 W/ARFN in a high band (1800/1900) or
      • >= 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 connectors are undamaged, free of corrosion and properly torqued.
  • Check that the power level at the duplexer output is correct. If not, you may have a damaged duplexer.
    • Cavity duplexers can be damaged by excessing mechanical shock or vibration, especially if the equipment showed signs of abuse from shipping.
    • SAW duplexers can be damaged by ESD or excessive power.

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.

Assuming you have already reviewed the critical parameters listed earlier in this section, check the cabling, connectors and other radio hardware components along the affected path. If your system uses separate rx and tx antennas, then check the antenna on the affected path as well. See the section on High Path Loss, Symmetric for guidance on checking radio hardware components.