This document provides an explanation of transmit (Tx) and receive (Rx) levels on modems.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
There are no specific prerequisites for this document.
This document is not restricted to specific software and hardware versions.
The Tx level is the power in decibels per milliwatt (dBm) at which a modem transmits its signal. The Rx level is the power in dBm of the received signal. The server modems normally transmit at -13 dBm by default. Ideally, the Rx level should be in the range of -18 to -25 dBm. If the Rx level is under -25 dBm, the Signal-to-Noise Ratio (SNR) is likely to decrease, meaning that the speed also decreases. If the Rx level is too high, you may see signal distortion or the receiver's Digital Signal Processor (DSP) being overdriven, and erratic connections are possible.
In some modulation standards, such as V.34, a receiver can tell its peer that the signal level is too high and the transmitter then reduces the level at which it transmits. (If this behavior is widespread, try configuring the transmitter to transmit at a lower level.) Modems that use other modulation standards (such as K56 Flex) may not be able to do this, resulting in problems.
Therefore, an effective Rx level is a function of the peer's initial Tx level, the negotiated dBm reduction (if any), and the attenuation in the voice circuit. The voice circuit attenuation is, in turn, a function of link attenuation and of analog or digital pads, which are telephone company circuitry designed to insert attenuation into the voice circuits.
If you need to reduce or increase your Tx level, this is attainable with the following modems and modulation standards:
Microcom through T51???For details, refer to the AT Command Set and Register Summary for V.34, 56K, and V.90 12-Port Module.
Modem ISDN Channel Aggregation (MICA) through S39 or S59???For details, refer to the AT Command Set and Register Summary for Cisco MICA Six-Port Modules.
NextPort through S39 or S59???For details, refer to the NextPort AT Commands and S Registers Reference.
If you need to reduce or increase your Rx level, you need to do this either at the peer transmitter (although this is not feasible if there are thousands of peers) or within the telephone company (more likely), by increasing or decreasing the padding.
On a live connection, you can see or infer the Rx and Tx levels as follows:
Microcom modems???Initiate a reverse telnet session and issue the AT@E1 command.
MICA modems???Issue the show modem operational-status command.
NextPort modems???Issue the show port operational-status command.
Some MICA modem examples are as follows:
router#show modem operational-status 1/0 Parameter #8 Connected Standard: V.34+ Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #22 Receive Level: -22 dBm
In this case the Rx level is -22, which is fine. The peer has not requested that the modem attenuate its Tx, so you can infer that it is transmitting at the default output level of -13 dBm. You can also infer that the signal level is not too high for the peer's receiver, because the peer has not requested a reduction in signal strength (though it could still possibly be too high???you cannot be certain without directly interrogating the peer).
Another example is as follows:
router#show modem operational-status 2/14 Parameter #8 Connected Standard: V.34 Parameter #20 TX,RX Xmit Level Reduction: 0, 3 dBm Parameter #22 Receive Level: -19 dBm
In this case there is a good Rx level of -19, but the peer has asked this modem to reduce its Tx level by 3 dBm. Therefore, it starts to transmit at -16 dBm instead. This modem's signal is arriving with excessive strength at the peer. If this occurrence is widespread, you might want to cut back on your configured Tx level globally through S39. In this case, the problem appears to be an issue with this particular peer, so there is no need to do so.
Telephone companies can insert a digital or analog pad, which is circuitry designed to add attenuation on a per-channel basis. Padding ensures that end-to-end circuits that take various paths through the Public Switched Telephone Network (PSTN) end up with comparable signal levels. For instance, if a modem transmits at -13 dBm, the receivers see a signal at the right level.
For purely analog carriers (V.34 and earlier standards), pads are useful if they result in the desired levels being received. If the Rx levels being observed are too high on a widespread basis, then pad insertion can make analog carriers perform better.
However, the effect of pads on a digital (Pulse Code Modulation (PCM)) carrier (K56 Flex and V.90) can be problematic. An analog pad (line pad), which merely attenuates the signal, is not a problem for a PCM carrier. However, a pad in the Network Access Server's (NAS's) T1 line to trunk, or within the telephone company's trunk-to-trunk connection, can have implications for PCM connects.
Digital pads remap the PCM data, which can disrupt communication. The general rule is that zero-dB digital pads are optimal for PCM connects. However, zero-level padding is less than optimal in other cases; for example, K56 Flex modems are less tolerant of Rx levels that are too high.
Different kinds of PCM modems can adapt to different flavors of digital pads. Rockwell K56 Flex modems (as well as Microcom and MICA modems) can handle zero-, three-, or six-dB pads. Lucent modems have a finer granularity of pad handling, and can cope with one-, four-, five-, and seven-dB pads as well. V.90 modems can handle zero to seven dB of padding in one-dB increments. If you see good V.34 connections, but poor or no K56 Flex connections, and if you know that there is no extra A-to-D conversion in the circuit path, then you may have a digital padding issue. In that case you need to contact your telephone company to resolve the problem. In such a case it may be helpful to conduct circuit traces of the suboptimal connections.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.