(usr-tc) AMI/D4 provisioning on CT1
I don't like surprises. Especially when I order a CT1 provisioned with B8ZS/ESF, and on the day of the turnup the switch tech tells me "oh, your stuff is configured wrong, it needs to be set up for AMI and D4, the DTC you're on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up like everyone else's." AFAIK, it is a trunk-side circuit (don't hold me to this). We have no problem hitting 45333-50333 both local and long-distance dialing into the TC at this POP, with an assortment of modems. Will AMI/D4 cause things to break, or should I contact the telco and beg to have it reprovisioned for B8ZS/ESF? --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net - 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.
Thus spake Bryan Wann
I don't like surprises.
Especially when I order a CT1 provisioned with B8ZS/ESF, and on the day of the turnup the switch tech tells me "oh, your stuff is configured wrong, it needs to be set up for AMI and D4, the DTC you're on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up like everyone else's."
AFAIK, it is a trunk-side circuit (don't hold me to this). We have no problem hitting 45333-50333 both local and long-distance dialing into the TC at this POP, with an assortment of modems.
Will AMI/D4 cause things to break, or should I contact the telco and beg to have it reprovisioned for B8ZS/ESF?
How about a 6 week lead time and the day the circuits are supposed to be turned up, "Oh, we don't have the right cards and cables at the switch, so sorry." We're at a week and counting past FOC with a 6 week lead time...what do these telco's do during that 6 weeks?! Anyway...you shouldn't see any problems with AMI/D4, if you're getting 45333-50333, you might be getting 46000-51000 with B8ZS/ESF or so, but I'm not even sure about that. I'd go ahead and not worry about fighting with the telco on this one and be happy. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - 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.
We use only B8ZS/ESF on CT1's with Nortel DMS-100 switches. Only the oldest of DTC's on the DMS can't do B8ZS/ESF. All the new ones (past 5 years or more) CAN do it. At 12:15 PM 1/22/00 -0600, you wrote:
I don't like surprises.
Especially when I order a CT1 provisioned with B8ZS/ESF, and on the day of the turnup the switch tech tells me "oh, your stuff is configured wrong, it needs to be set up for AMI and D4, the DTC you're on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up like everyone else's."
AFAIK, it is a trunk-side circuit (don't hold me to this). We have no problem hitting 45333-50333 both local and long-distance dialing into the TC at this POP, with an assortment of modems.
Will AMI/D4 cause things to break, or should I contact the telco and beg to have it reprovisioned for B8ZS/ESF?
--- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net
- 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.
--- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009 - 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.
If you are paying for it then get what you ordered. Period. Ask them to change it and in the mean time you will use the T1's provided. They are a public utility so make them work for you. Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com
-----Original Message----- From: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Bryan Wann Sent: Saturday, January 22, 2000 12:15 PM To: usr-tc@lists.xmission.com Subject: (usr-tc) AMI/D4 provisioning on CT1
I don't like surprises.
Especially when I order a CT1 provisioned with B8ZS/ESF, and on the day of the turnup the switch tech tells me "oh, your stuff is configured wrong, it needs to be set up for AMI and D4, the DTC you're on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up like everyone else's."
AFAIK, it is a trunk-side circuit (don't hold me to this). We have no problem hitting 45333-50333 both local and long-distance dialing into the TC at this POP, with an assortment of modems.
Will AMI/D4 cause things to break, or should I contact the telco and beg to have it reprovisioned for B8ZS/ESF?
- 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.
Before you go demand they do something, make sure you are not going to waste your time. B8ZS is of no help on a CT1. The purpose of B8ZS is to ensure timing by preventing lots of consecutive zeros on the line. This can't happen with a CT1. The control bits in each channel will ensure enough ones density to maintain timing. ESF is better than D4 is you are doing monitoring of the line or are going to run advanced diagnostics using test equipment. Not having ESF doesn't hurt untill you have problems then its a benefit. The bad news is that ESF requires that both ends of the line be ESF capable. Many switches aren't ESF capable on CT1s. Marshall Morgan wrote:
If you are paying for it then get what you ordered. Period. Ask them to change it and in the mean time you will use the T1's provided. They are a public utility so make them work for you.
Marshall Morgan
Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com
-----Original Message----- From: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Bryan Wann Sent: Saturday, January 22, 2000 12:15 PM To: usr-tc@lists.xmission.com Subject: (usr-tc) AMI/D4 provisioning on CT1
I don't like surprises.
Especially when I order a CT1 provisioned with B8ZS/ESF, and on the day of the turnup the switch tech tells me "oh, your stuff is configured wrong, it needs to be set up for AMI and D4, the DTC you're on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up like everyone else's."
AFAIK, it is a trunk-side circuit (don't hold me to this). We have no problem hitting 45333-50333 both local and long-distance dialing into the TC at this POP, with an assortment of modems.
Will AMI/D4 cause things to break, or should I contact the telco and beg to have it reprovisioned for B8ZS/ESF?
- 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.
- 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.
On Sun, 23 Jan 2000, Garlic wrote:
Before you go demand they do something, make sure you are not going to waste your time.
B8ZS is of no help on a CT1. The purpose of B8ZS is to ensure timing by preventing lots of consecutive zeros on the line. This can't happen with a CT1. The control bits in each channel will ensure enough ones density to maintain timing.
ESF is better than D4 is you are doing monitoring of the line or are going to run advanced diagnostics using test equipment. Not having ESF doesn't hurt untill you have problems then its a benefit. The bad news is that ESF requires that both ends of the line be ESF capable. Many switches aren't ESF capable on CT1s.
Garlic, Thanks, this is exactly what I was needing to know; if I would be wasting my time for something that would have little noticable affect other than making me look [more] like an demanding, irate asshole telco customer. :-) --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net - 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.
Thus spake Bryan Wann
Thanks, this is exactly what I was needing to know; if I would be wasting my time for something that would have little noticable affect other than making me look [more] like an demanding, irate asshole telco customer. :-)
I tend to be all for anything that causes ILECs problems, but this is one that I'd probably bypass. I might make a few calls and see if you can confirm that the switch really can't do B8ZS/ESF...then maybe make a few calls to various folks disparaging the telco for using outdated technology, then probably drop it. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - 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.
This isn't for garlic's benefit, as I don't interact or answer questions from people who won't post under their name. Life is too short to waste time on such foolishness. But since he's posting gobs of misinformation to the list, I'll explain for everyone else's benefit. First bit of misleading information is that the control (signalling) bits can somehow maintain ones density. It should be obvious to a anyone that this is impossible as the signalling bits need to have multiple values if they are going to signal anything. The only way the signalling bits could enforce ones density would be if they were always ones, and if the were, they wouldn't actually be able to signal anything. 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. So "lots" (8) consecutive zero can and do occur on a CT1 line. 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.) B8ZS is able to handle these strings of zeros by inserting a bipolar violation that the receiver knows to remove. Since B8ZS doesn't have to force ones, it doesn't have the associated S/N degradation of AMI only. So try and get B8ZS if you can. On Sun, 23 Jan 2000, Garlic wrote:
Before you go demand they do something, make sure you are not going to waste your time.
B8ZS is of no help on a CT1. The purpose of B8ZS is to ensure timing by preventing lots of consecutive zeros on the line. This can't happen with a CT1. The control bits in each channel will ensure enough ones density to maintain timing.
-- 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.
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 :)
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.
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
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.
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. 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. AMI, for what its worth, is pretty much universal on all T1's. Basically, all AMI (Alternate Mark Inversion) means is that a "mark" or one bit, has the opposite voltage polarity from the previous mark or one bit. If two successive marks (with 0 or more interveaning spaces or zero bits) have the same voltage polarity, then you have a BiPolar Violation (BPV). As you can see...since B8ZS uses BPV's to indicate an all zero timeslot, B8ZS assumes AMI. :)
So try and get B8ZS if you can.
If you're only running voice calls...B8ZS isn't really needed...now, having ZCS enabled (as our telco did on some of their trunks at one point) can cause some problems since that fairly significantly cuts down the total bandwidth...you're gonna see speed drops in that case. But as long as ZCS is off, you should be OK as far as transmission speeds even without B8ZS. As someone else mentioned...if you have problems B8ZS and ESF will be nice to have as they do have some trouble-shooting capabilities...but in general operation...its not really a problem if all you're doing is voice calls. Now, when you go to ISDN PRI, you have to have B8ZS with ESF because at that point you're encoding data onto the circuit which can result in all-zero timeslots. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - 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.
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.
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.
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.
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. ZCS is almost never used any more...but it is something to be aware of...as I said...I ran into some trunks that had it configured and were causing considerable problems.
You are simply wrong. You are again confusing ones density in a single PCM channel with ones density in the T1 frame.
Sorry...I'm well aware of the possibilities of interactions between different DS0's in a frame...I am still correct though...mu-law encoding will enforce ones-density (up to 15 consecutive zeros) on its own, with no need for B8ZS (or the sucky ZCS).
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.
Hey...I don't claim to be an expert on this...and I'll acknowledge that I didn't communicate well here (and got at least one detail wrong)...but I do have a fairly decent understanding of common T1 technologies. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - 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.
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.
Thus spake Aaron Nabil
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.
Hrmm...all I can go on is my experience, what I've read, and what I've talked to telco folks about...I have almost never heard it put as no more than 8 zeros...virtually everyone I've talked to about it says it can be up to 15 zeros. This includes websites of many equipment vendors that make this stuff (including at least Lucent, Motorola, Cisco, and virtually every T1 tutorial/overview site that I've found...oh...and the U.S. Department of Agriculture...don't ask me why, but that one turned up).
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.
OK...again...I've never heard of ZCS used those other ways...only as the bit-stuffing...though I have heard plenty of other terms for it as well...I'll be careful in using that then...thanks for the warning. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - 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.
So after you throw out all the crap and gobblegook that the others use, the basic answer is still the same. * For a CT1, B8ZS is of no value. There is sufficent one's density for the equipment to operate just fine without it. * ESF is a diagnostic tool and is a good thing but a lot of voice equipment doesn't have the capability. As far as rest, the signal to noise ratio for this mailing list is one of the poorest of the other equipment support lists that I subscribe to. I would have hoped this was a list of network professionals that were trying to help each other. Some participants seem to want to just be very caustic. To the rest, I apologize for leaving off my signature if that's important to you Roy - 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.
U>Depends on the application. With voice calls in the DS0's, the U>encoding of the voice data into the DS0's actually enforces one's U>density inherently. The encoding algorithm won't generate bit U>patterns that don't meet one's density requirements. U>>Without B8ZS, the framer has to enforce ones density by stuffing U>ones, >this causes a drop in the S/N ratio. (I seem to remember 4db U>as the >figure, but I don't have any reference material in front of me U>to back >that up.) U>I don't know what it translates into as far as a db loss, but it eats U>up one out of every eight bits of data meaning a loss of 192kbps on a U>T1 total...dropping the total useable bandwidth to 1.344Mbps Not quite. AMI has nothing to do with the amount of available bandwith per se'. What is getting mixed up here is that folks are assuming inband signalling (i.e. Robbed Bit Signalling) equals AMI. This is not true. RBS equals CTI because there is no out of band signalling like a D channel on a PRI for a CTI T-1. Thus A/B bit inband signalling is used. Now RBS does eat ever so slightly into the S/N ratio because in teh 6/12th timeslots the Least Significant Bit (LSB) is used out of the 64kbs PCM encoding process for each channel. Thus you have 56kbs of PCM data instead of 64kbs. How much does that equate to on the S/N ratio ? There are two answers to this. First if the samlping values of the lost PCM bits is lower than the ambient noise of the local facility connected to them, then you probably will see no S/N degredation (a likely scenario). Otherwise there might be some but since the data transmission power level used is also much higher than the lost PCM bits, the effect should be neglible. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999 - 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.
We are in the process of merging two ISPs. Our ISP runs on the 3Com Hiper Arch Chassis the other ISP runs on Ascend. Since we both use ELI for our Channelized T-1s we are considering porting their dial in number over to our 3Com chassis at our location.. What problems should we anticipate moving customers from an ASCEND unit to 3com? Both are using the "V90 standard." protocol. Would we be better off using their ASCEND equipment? Any feedback is appreciated. Thanks -Brian
On Wed, 26 Jan 2000, Brian Burgmeier wrote:
We are in the process of merging two ISPs. Our ISP runs on the 3Com Hiper Arch Chassis the other ISP runs on Ascend. Since we both use ELI for our Channelized T-1s we are considering porting their dial in number over to our 3Com chassis at our location..
Regular dialup should not have any problems, however, Ascend uses radius attributes that are speicific to certain versions and its radius attributes overlap standard attributes. Other than that you should not have any other problems. Oh, one other - modems that connect v.90 (but actually connection k56 ) would have problems with v90 if not using the correct protocol.
What problems should we anticipate moving customers from an ASCEND unit to 3com? Both are using the "V90 standard." protocol. Would we be better off using their ASCEND equipment? Any feedback is appreciated.
No just use 3com its better....:-) krish
Thanks -Brian
- 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.
On Thu, 27 Jan 2000, Tatai SV Krishnan wrote:
No just use 3com its better....:-)
Personally, I'd be much more likely to continue to use 3Com if somebody from logistics would ever call me with an RMA for my bad Dual PRI NAC. Brian - 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.
Brian, We are having to make the same decision. Our decision is to move everything over to Ascend Maxes because they are a much more stabile unit than the 3Com gear. We hardly ever have any problems with our Maxes yet it seems like we always have issues with the 3Com TCH. Also, Ascend (now called Lucent) doesn't have as many problems with v.90 and very few problems with the Rockwell chipset. And Lucent's support is better than 3coms. Bryan NOC Technician COX Internet ----- Original Message ----- From: "Brian Burgmeier" <brianb@ntwrld.com> To: <usr-tc@lists.xmission.com> Sent: Wednesday, January 26, 2000 5:06 PM Subject: (usr-tc) Ascend to 3com
We are in the process of merging two ISPs. Our ISP runs on the 3Com Hiper Arch Chassis the other ISP runs on Ascend. Since we both use ELI for our Channelized T-1s we are considering porting their dial in number over to our 3Com chassis at our location.. What problems should we anticipate moving customers from an ASCEND unit to 3com? Both are using the "V90 standard." protocol. Would we be better off using their ASCEND equipment? Any feedback is appreciated.
Thanks -Brian
- 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.
participants (11)
-
Aaron Nabil -
Brian Burgmeier -
Brian Elfert -
Bryan Wann -
Clayton Zekelman -
Garlic -
Jeff Mcadams -
jeff.binkley@asacomp.com -
Marshall Morgan -
Tatai SV Krishnan -
The NOC (COX Internet)