56k & RBS Problem

Getting Technical - Thinking out loud ( Posted 6/28/98, updated 22-Aug-98)

Also see - my RBS/56k update published 9-Feb-99

I get good 56k connects on 1-in-6 calls (on average).

I'm not the only one.

This happens with V.90, x2, and Flex. All known (to me) releases.

Why??????????

(Some of what follows are facts; some of it is based upon guesses that may or may not be entirely accurate.)

================

The switched telephone network is based upon a 64kbps channel of digital data representing an analog (voice) signal.

The 64kbps signal is derived from 8000 8-bit samples a second (8000x8=64k)

56k (PCM) modems sample the analog signal 8000 times per second (for the downstream only; the client modem transmits using v.34 at a maximum of 33.6bps).

Each 8-bits of the digital channel has 256 possible values, which are translated (by a codec) into 256 possible voltages. Because the codec is designed for voice, the 256 voltages are not evenly spaced, making the closely spaced voltages more difficult to accurately decode. The voltage levels the PCM modem will use is referred to as the 'constellation'.

Every time we reduce the constellation (# of voltage levels used) by 1/2, the available bit rate for the modem link is reduced by 8k:
# Voltage Levels   Bit rate (bps)  # telco bits "used" per 8-bits
 ---------------   --------------  ---------------------------
256                   64k               8
128                   56k               7
 64                   48k               6
 32                   40k               5
 16                   32k               4
  8                   24k               3                               
PCM modems are not restricted to using these bit-related voltage levels. That, and RBS (more on that later), is why 56k modems aren't restricted to these 8k bit-rate increments. Flex, with its 2k increments is easiest to understand:

Let's take the Flex rates between 40 & 48k:

There are 32 voltage levels between the 40 & 48k rate, and there are 4 Flex rates between 40 to 48k. 32/4=8. If we use 40 voltage levels, for each sample we can define 5 bits, and have 8 extra voltage levels; after 4 samples, we've accumulated 32 extras - enough to define an extra bit. With 8000 samples per second, we can accumulate 2000 (8000/4) extra bits per second:
# Voltage Levels    Bit rate (bps)  
----------------    --------------
32                  40k
40                  42k
48                  44k
56                  46k
64                  48k                               
The number of levels needed for rates between 48k and 56k are doubled. There are 64 levels between the 48 and 56k rates, and still 4 Flex rates. 64/4=16. Thus
# Voltage Levels   Bit rate (bps)
----------------   --------------
64                 48k
80                 50k
96                 52k
112                54k
128                56k                               
If it only takes 32 out of a possible 256 voltage levels to get 40kbps, why are many 56k modems users getting rates in the low-mid 30's, and finding that throughput often doesn't live up to even that poor connect? And what about those "weird" rates like 46,667bps? How many voltage levels are needed for that rate?

There are plenty of complications!

One of the biggest is "processing" the telco does that alters the bit pattern produced by the digital server modem. This processing, often referred to as "impairments", includes Pads (used to reduce the signal level), and RBS (robbed-bit-signaling used for trunk/channel supervision). A call can be subject to 0 or more RBS-links*. Each RBS-link "steals" 1 bit out of every 48. If there is only 1 RBS link, the level of every 6th sample could be altered by 1 voltage step. If we are using a 48k rate detecting 64 voltage levels, on that 6th sample, we can only reliably detect 32 levels. ((48k * 5/6)+(40k * 1/6)) = 46.667k. 2 RBS links further decreases the rate: (48k * 4/6)+(40k * 2/6) = 45.333k. For this to work, it is essential to accurately determine which sample(s) are affected by RBS. (Flex, with its 2k rates uses a 2k-multiple reduction in the RBS sample frame(s) resulting in no effect for the 3rd or 6th RBS link: 1 RBS drops the rate 2k; 2 RBS drops 4k; 3 RBS drops 4k, etc.) And this is how we get the unusual rates - the telco signaling is based upon 6 frames, and the constellation used (= bit rate) does not have to be the same for all 6 frames.

One reason 56k does not work well in many situations is the inability to locate the RBS frames. When this occurs, even though a very small constellation has been selected, the modems aren't really reducing the samples in (all) the correct frames, causing high error rate, retrains, confused modems and poor throughput. I believe I've positively identified one manifestation of this problem: whenever there are 2 or more RBS links, there is a 1-in-6 chance of 2 of these links aligning - ie, they use the same frame, so the effect is as if there is only 1 RBS link. I encounter this to my ISP, and that's why (on average) 1 in 6 calls gives me a good connection, and 5 out of 6 don't. (Think LasVegas when you translate that to the real world - somedays you'll "win", somedays you'll "lose", but with 1-in-6 odds, you're going to go broke (have poor connections) most of the time.)

Why not assume all the frames have a robbed bit? If that were done, we've got 128 levels to work with. But, because the robbed bits will still affect the actual voltages, and because of the non-linear nature of the a/d conversion, we'd have to throw out 1/2 of the 128 levels, leaving 64 (48k max rate) and we'd no longer be dealing with a "56k" modem! And with all of the above, the calculations assume no modem overhead on the bitstream for protocol/control which reduces the real data bps.

Let's try and determine the effect of a misidentified RBS link. If the modem detects RBS but places it in the incorrect frame we've got a double-whammy: we've reduced the recovery on 1/6th of the samples by 8k unnecessarily (hit=1.33k/sec), and since we're trying to sample the frame where the robbed-bit occurs without taking that into account, we've got a 50-50 chance of decoding the wrong value on another 1/6th of the samples. So, in 3 seconds (24,000 samples), 1/12=2000 are likely to be in error and must be re-sent. When these are re-sent, 1/12=166.67 are likely to be in error, etc. Ignoring these secondary errors, let's calculate the 'hit' based upon a connect of 48kbps:

First, we take a hit of 1.33kbps on the misidentified frame that does not have RBS - the connect could have been 49.3k.

Then, we need to resend 2000 samples which takes 2000/8000seconds or 1/4 second. At 48kbps, this amounts to 12kbps/3(seconds) or 4k bringing the rate to 44kbps. (When secondary errors are considered, the hit approaches 4.4k/sec.) If we have the problem with more than 1 RBS frame --- well, it starts to make sense how you can get a 56k connection that can be worse than v.34! (Especially if the modems try and re-train and just don't have the firmware to make the needed impairment identifications.)

Assume 2 RBS links, both unidentified, and 1 incorrectly identified link with a connect rate of 48k. In 3 seconds, 1/6=4000 samples are likely to be in error, and must be resent. 1/6 of the resends are likely to be in error 4000/6=666.67, etc. or about 4800/3=1600 samples per second for retransmission. This brings the rate down to 38.4k/second. In making the misidentification, it is likely that the modem also misidentified other factors like padding, so it is likely that a certain number of errors will be introduced related to the improper compensation for the other impairments.

Now these examples above probably aren't realistic. (I'm guessing...but) I think that x2/V90 modems will only really "connect" at one of these rates (4k increments): 28k, 32k, 36k, 40k, 44k, 48k, 52k, and 56k. The rates in between these are all the effect of RBS compensation, and the connect rate can give you a positive indication of whether RBS signaling has been identified on the call if it is a rate between these 4k increments:
Effect of identified RBS links on connect rate:

48k - (1.333k*1) = 46.666k = 1 RBS link
52k - (1.333k*4) = 46.666k = 4 RBS links
48k - (1.333k*2) = 45.333k = 2 RBS links
52k - (1.333k*5) = 45.333k = 2 RBS links
48k - (1.333k*3) = 44k     = 3 RBS links
52k - (1.333k*6) = 44k     = 6 RBS links                               
(Added 8/22): Another possibility is that in selecting the constellation, the modems can effectively get "a portion of a bit" from some of the samples: knowing that RBS and other impairments can affect the proper conversion to bits, more than 1 sample can be processed to make a decision as to what the bit value is.

A further confirmation of problems resulting from misidentified RBS links comes from the experience of one user I've communicated with who gets either a 54,667 rate (in this case 2 RBS links that align to look like 1), or horrible low-mid 30k rates to a local 56k server. (You thought 53k was the maximum in the United States? This user was able to get the telco to adjust the digital pad from his line - so the only significant impairment left is RBS!) This user is served by SLC using AMI signaling which means RBS. The link from his serving switch to the ISP's switch is an RBS link. When these align, a "perfect" 56k - 1.333k = 54.667k connection is obtained. When the links don't align, the modem firmware is unable to identify the RBS link on the SLC, and goes to a constellation that produces an extremely low rate. (This user's phone company is GTE - same as me.) In a situation like this (SLC or remote office using RBS), there can never be a call that doesn't have at least 1 RBS link.

I know that my line is served by a remote office (AMI/RBS-link), and on the 1-in-6 calls where this link is aligned with another, I get either a 46.6k or 48k rate; but my throughput is more like 42-44k. What's happening? I think there is still an unidentified RBS link (giving the ~4k hit calculated above for an unidentified RBS link); but, when the link from my local office isn't identified, there are two misidentified links, giving the much higher +10k hit and unreliable connection as the modem attempts to deal with unexpected errors. With my [good] line conditions, the 56k protocol is able to 'deal with' 1 unidentified link and yield throughput around 44k, but not more than 1. (This means that there is still room for improvement in my "good" connections if this other link were identified - I should be getting a 45.3k or 49.3k connect and matching throughput with 2 RBS links.)

(Added 8/21) There's more: Prodigy, my ISP, is installing new POPs in Hawaii to (I hope not too soon) replace their IBM-provided nodes. The new POPs are in 'beta', and I've been able to help 'test' them. When calling the new POP, I get approximately 1-in-36 good calls! I think this is a case where 3 RBS links must align in order for the modem to properly identify the impairments. What's different about the new POP? 2 major things: the actual Prodigy equipment is on Oahu (another island) while the number I call is local; the local # is provided by a CLEC (competitive local exchange carrier). When I call this Hilo number, I've got an RBS link from my remote to switching office; another (I think) from the switching office to GTE's Hilo office, and 1 or more additional RBS links involving the GTE->CLEC connection. This new RBS link must align with the other 2 - producing the 1-in-36 good call rate.

When I call the new Prodigy POP from another location, not served by the remote switch [connected directly to the office that switches my calls], I get a 6-in-6 good call rate! (This location also gets a 6 100% good call rate to the IBM POP where I get 1-in-6.) This leads me to conclude that the "killer" is the RBS link between the switching and remote office: any other RBS links will match those I get on my line. The other difference may be the PAD (combined with the last RBS link): on my line, the padding is digital, done by the switch, followed by the RBS link to my remote office. The copper line at the location connected directly to the switch has an analog PAD, done in the line card. (An analog PAD is easier for the modem to handle since there is no manipulation of the digital data stream, and the effect of the PAD is linear; however, a digital PAD - controlled by software - alters the digital datastream with the intent of producing an attenuated analog signal. There is no guarantee that the digital PAD will produce a linear or consistent attenuation.

Adding even more confusion to the issue is how to explain the fact that I can get a 100% success rate on calls to 2 other ISPs whose dial-in number is located in Kailua-Kona as opposed to Hilo. This is still an inter-office call, and I still have the digital PAD and RBS link between the remote and real switch. My guess is that calls to this office do not add any more RBS links (ie, the phone company trunking is B8ZS/ESF vs D4/AMI).

I believe that availability of ISDN to one's location results in a greater chance of 56k modem success. ISDN isn't offered to me. If it were, the phone company would have to change the trunking between the remote and switching office to eliminate RBS on that link (because ISDN calls can not be routed over RBS-links, and both voice and ISDN calls have to be trunked between the remote and switching offices).

(<more to come later>)

------------

* RBS-link: A portion of the path a call takes to reach its final destination where RBS-signaling is used for supervision. For example, a single call could have a RBS-link between the client's SLC or Remote Switching Office to the Central Office Switch, another between the Central Office Switch and the destination Central Office Switch, and a third between the ISP and the Central Office switch serving the ISP.