This is - Helping you get the best performance from your modem
 Troubleshooting News Technical Search
 Home Forum 56 Premium Site Map
Home News & Updates    56k & RBS

56k & RBS - Part 2 (9-Feb-99 Updated 2-Mar-99)

This is an update to previous thinking on How RBS can interfere with 56k.

As explained in the link above, RBS (robbed-bit-signaling) is commonly used in the US by telephone companies. This in-band signaling takes 1 bit out of every 6 8-bit samples for phone company use. Each link between switching facilities can use RBS, so it's possible to have 2 or more RBS links. SS7 (signaling system 7), which allows features like caller ID, can replace the need for RBS. The long distance network relies on SS7, and the use of RBS is practically non-existant on toll facilities. While many local phone companies have deployed SS7, that deployment can actually cause problems with 56k modems. (See this Wired story, The Myth of 56k.)

Since 56k modems attempt to use all 8 bits of each PCM code, RBS links must be identified. I believe the flaw is this: when RBS is actually used for signaling, the robbed bit will remain a constant 1 value through all the samples. Your 56k modem will attempt to identify any robbed-bits during the handshake: the server sends a pattern of constantly changing 1's and 0's in each set of 6 8-bit samples, and the client modem looks for any samples that it receives unchanged. The problem is this: with SS7, the robbed-bits are no longer needed for telco switching, and as a result they may change or 'flip'. The client incorrectly thinks there is no RBS link where one really exists - it just doesn't conform to the incorrect assumption 56k designers made that RBS bit values do not change. It is entirely possible for a customer to be served by "old" equipment that uses RBS and get great 56k. Then, the phone company upgrades, installs SS7, but doesn't remove all traces of RBS... leaving a RBS bit whose value changes, but is not controlled by the server modem's data stream. The result: no more 56k connections.  The phone company may be ready to offer you ISDN, but in my opinion, this loss is not really the fault of the phone company: 56k modem designers erred in not taking this condition into account - the use of RBS, whether it conforms to a non-changing value theory or not, does not impact dial-up voice, fax or v.34 connections - and it shouldn't impact properly designed 56k analog modems, either. But, no manufacturer of 56k modems has firmware that works where the telephone network delivers a data stream with a changing RBS value.

It should be noted that RBS (and digital pads) are widely used in the US, but are very uncommon in some other parts of the world. All switched telco facilities need control information - is the circuit in use? RBS is an in-band signaling method for this control information, and robs (or changes) a small part of the signal sent by the digital server modem. SS7 is an out-of-band signaling method: a separate channel is used to carry signaling, and there is no need to change any part of the signal sent by the digital server modem. The problem is that when a telco implements SS7, a large part of the infrastructure is still using equipment designed for RBS. In many cases, the telco can remove the actual signaling, but the hardware controlling the RBS information may still be in place: this hardware may replace part of the data sent by the server modem which may not conform to the assumption used in designing 56k modems - that this signal will be an unchanging 1 value.

If you have a 3Com modem, you may be able to get an idea of what kinds of impairments are on your line via the V90 status line displayed in the ATi11 diagnostic screen. See my 3Com Diagnostic page for how to decode the status line. Note - if you are suffering from an impairment as described above, as well as in other 'problem' 56k connects, the impairments identified by the modem may not be accurate.

Home  |  Links  |  Send Feedback  |  Privacy Policy  | Report Broken Link
Legal Page  |  Author's Web Sites   |  Log In 1998-2022 v.Richard Gamberg. All rights reserved.