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.

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.

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.

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.

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.

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.

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.

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.