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.