On Tue, 25 Jan 2000, Jeff Mcadams wrote:
Thus spake Aaron Nabil
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.
Yeah...my apologies...mostly it was terminology thing. Of course the RBS occurs at the same rate in SF and ESF...didn't mean to imply otherwise. :) Just that it would occur at the 6th, 12th, 18th, and 24th frame in ESF since ESF has 24 frames compared to SF's 12. Same diff really...mostly a terminology thing.
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.
Uhm...ones-density requires no more than 15 consecutive zero's, so your run of 13 is fine. It also requires an minimum average of 12.5% of ones (I don't know the period over which this average applies), which is where the one in eight idea comes from I believe.
The original T1 spec was 3 ones in 24 bits, with no more than 15 zeros. But the AT&T spec, (ie, the defacto standard) requires one pulse every 8 bits, not just 3 every 24.
It only "eats" that bit in DATA. In voice (modems), that bit is still there, it's just noisy.
True...the bit is still interpretted in voice applications...so its not eaten per se...effectively, however, the bit is unuseable for practical purposes...that's all I was trying to say there.
The application in question _was_ a voice application, where it's perfectly usable. Surprising enough, the majority of T1's in the world are carrying voice, so I would hardly call that bit "unusable for practical purposes".
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.
Actually I waited until I got back to work since all my reference material was at work...I didn't wait just so I could put the B8ZS pattern though...I wanted to confirm a few other things. :)
Your definition of ZCS (Zero code _supression_) would best be forgotten.
Dang...got that one wrong...my apologies...right idea...wrong acronym expansion.
The reason I said it should be forgotten was because it is a term that has different meaning in different contexts, of which your example would almost always be the LEAST likely to be what someone meant. Most typically by ZCS people are referring to "a ZCS technique" like B8ZS, ZBTSI or HDB3, not one-stuffing done by a CSU. -- 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.