On Tue, 25 Jan 2000, Jeff Mcadams wrote:
OK...you're closer than Garlic Whatziname...but still not quite there. :) I wish, I wish, I wish I knew of an online source for this printout that I have in my hand...its *very* instructive about how T1's work...but alas, you all will have to deal with my summarization. :)
This just in <sound of teletype here>...found it online :) http://duracef.shout.net/~wildixon/telecom/t1/t1.html
Thus spake Aaron Nabil
Second problem with the signalling bits is that they only occur every 6th and 12th frames. So even if they were always ones, they would only affect ones density during those frames.
Correct so far (assuming D4 framing of course...which is what was being discussed, so a good assumption :)
Gee, thanks. Nice to know that "I'm closer than Garlic Whatziname", and that I haven't managed to make any major blunders in my first sentence. I don't know why you'd say "assuming D4 of course" as RBS occurs at the same rate in both D4 and ESF.
So "lots" (8) consecutive zero can and do occur on a CT1 line.
Depends on the application. With voice calls in the DS0's, the encoding of the voice data into the DS0's actually enforces one's density inherently. The encoding algorithm won't generate bit patterns that don't meet one's density requirements.
Are you talking about CCITT mu-law encoding? Sure, CCITT mu-law enforces ones-density IN A SINGLE PCM CHANNEL. But when you stack mulitple channels together into a T1, how is one PCM channel supposed to know what's in the next channel? Well, it doesn't, and it's trivial to violate ones density with something like +127 in the DS0 1 (1000 0000) and -126 (0000 0010) in DS0 2, as they are simply catenated together in the T1 frame. 1000 0000 0000 0010 has a run of 13 zeros.
Without B8ZS, the framer has to enforce ones density by stuffing ones, this causes a drop in the S/N ratio. (I seem to remember 4db as the figure, but I don't have any reference material in front of me to back that up.)
I don't know what it translates into as far as a db loss, but it eats up one out of every eight bits of data meaning a loss of 192kbps on a T1 total...dropping the total useable bandwidth to 1.344Mbps
It only "eats" that bit in DATA. In voice (modems), that bit is still there, it's just noisy.
B8ZS is able to handle these strings of zeros by inserting a bipolar violation that the receiver knows to remove.
Actually, its two bipolar violations in a specific pattern...but you had the right idea. :) The specific pattern is 00011011, with BPV's at the 4th and 7th bits.
Yeah, I was simplifying. In the context of the original message, I didn't see any value in driving home and looking up the exact substitution value in a reference book or on the web. Obviously you did. Good for you.
Since B8ZS doesn't have to force ones, it doesn't have the associated S/N degradation of AMI only.
Actually...AMI doesn't have any S/N degradation. I think you're thinking of ZCS, or Zero Code Substitution (I've also seen it referred to as simply "Ones Insertion"). Basically, with ZCS, the equipment jams a bit to one to enforce the one's density...of course the receiving equipment doesn't have any way to tell whether this bit was on because of the data or because of the need to maintain one's density, so you basically just cannot put any data into the bit used like this...this drops the data rate down to 1.344Mbps as above.
I'm "thinking" of the two alternatives the original author had available to him, a CT1 with B8ZS or without B8ZS (AMI only). One has a poorer S/N than the other. Your definition of ZCS (Zero code _supression_) would best be forgotten.
Again, with voice encoding, neither ZCS or B8ZS is really needed as the encoding won't generate codes that don't meet one's density requirements...its when you get into data transmision that you have to be concerned about one's density since that can generate all zero's.
You are simply wrong. You are again confusing ones density in a single PCM channel with ones density in the T1 frame.
. . .
Jeff, it's simply marvellous that you are able to use a search engine and come up with these "answers". In fact, it's a skill that I've wished would be more commonplace on a majority of mailing lists (especially inet-access). But in future, note that there is a difference between "knowing where to find something" and "knowing something". Both very useful, but in this case you are in the former category, not the latter. -- Aaron Nabil - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.