AMI and B8ZS together
Larry L. Langrehr
I have a simple question. If CPE on side of a T span is set to AMI line
encoding and CPE on the other end is set to B8ZS, and the span is only
used for voice traffic, not data, and the span is clean, no errors, will
either end detect a problem or not? Has anyone run into such a condition
before? Theoretically it sounds as if it should work. Would appreciate
any and all comments either by a response to this post or direct email,
thanks.
Larry Langrehr
Steve Uhrig
Span line repeaters would have to put out B8ZS in both
directions. I don't know of any that will run one format in
one direction and a different one in the other. Also if the
T1 goes through a DAC you are in trouble there.
************************
Steve Uhrig
Chillicothe, Ohio USA
************************
Floyd Davidson
suh...@bright.net wrote:
>lang...@cais.com (Larry L. Langrehr) wrote:
>
>>I have a simple question. If CPE on side of a T span is set to AMI line
>>encoding and CPE on the other end is set to B8ZS, and the span is only
>>used for voice traffic, not data, and the span is clean, no errors, will
>>either end detect a problem or not? Has anyone run into such a condition
>>before? Theoretically it sounds as if it should work. Would appreciate
>>any and all comments either by a response to this post or direct email,
>>thanks.
>
> Span line repeaters would have to put out B8ZS in both
>directions. I don't know of any that will run one format in
>one direction and a different one in the other. Also if the
>T1 goes through a DAC you are in trouble there.
With voice only it won't make any difference because there will
never be enough 0 bits in a row to trigger the B8ZS encoding of
bipolar violations that would trip up the receiver at the CPE end.
In the other direction, which would be towards a DACS (or a span
line repeater) for example, it won't make any difference at all
because those receivers are enabled for B8ZS, and the CPE end
never encoding BPV's won't bother it at all.
Floyd
--
Floyd L. Davidson Salcha, Alaska fl...@tanana.polarnet.com
Wayne E. Amacher
Subject: Re: AMI and B8ZS together
Newsgroups: comp.dcom.telecom.tech
References: <4ltvnv$b...@news2.cais.com>
Organization: a2i network
Distribution:
Larry L. Langrehr (lang...@cais.com) wrote:
: I have a simple question. If CPE on side of a T span is set to AMI line
: encoding and CPE on the other end is set to B8ZS, and the span is only
: used for voice traffic, not data, and the span is clean, no errors, will
: either end detect a problem or not? Has anyone run into such a condition
: before? Theoretically it sounds as if it should work. Would appreciate
: any and all comments either by a response to this post or direct email,
: thanks.
: Larry Langrehr
Try it it might work for voice. The codecs at the end not expecting B8ZS
might make funny noises. I do not know of a situation where AMI (Alternate
Mark Inversion is not used. It definately will not work for data.
AMI inverts every other "1" or mark bit. Zeros are sent as zeros. Ones
alternate between -3 volt pulses and + 3 volt pulses at the originating point.
AMI essentially cuts the fundemental frequency in half, for T1 that's 772
kHz instead of 1544 KHz.
The transmission must have a certain number of 1's in order to extract
a clock signal. Long strings of zeros are not allowed. B8ZS is defined
to substitute 000VB0VB anytime it sees a string of eight zeros, 00000000,
where B's and V's are 1's, but the V's violate the AMI inversion rule.
Note that this keeps the average voltage of the signal at 0 volts
(another requirement).
The receiving end knows to change 000VB0VB back into 00000000. If the
receiving end is not set to B8ZS, it might see 000VB0VB as 00011011,
which would be audible as a click or something. The recieving end might
also
see 000VB0VB as two bipolar violations and set off an alarm signal, in which
case the receiving end might change to all 1's. Alarms are very
complicated and require a number of the CCITT G.xxx specs to interpret.
The end expecting B8ZS simply would never get an opportunity to make the
B8ZS substitution. However, it very well might set off an alarm
condition when it sees a string of two many zeros.
A codec receiving all 1's should be silent.
It is very unlikely that the two ends of a T1 or E1 transmission would be
set differently in real life. It would be very interesting to try it,
however. You would very likely get different results with different
manufacturer's equipment!
Wayne E. Amacher
wama...@rahul.net
Wayne E. Amacher
fo...@earthlink.net
This is the way I understand your question: You have cpe equipment on
two ends of a point to point t1 circuit. One is optioned ami and the
other is b8zs. What is the t1 span optioned for??
It doesn't really matter because in either case, unless you're doing
some magic with CSU settings then you have a mismatch. As the amount
of voice traffic picks up on this span, the number of errored seconds
will also pick up. Disconnected calls can be the result. Sometimes
all calls will remain up UNTIL the 24th channel on the t1 is seized,
and then they all drop at once. This of course will cause complaints
because it is very noticeable. On the other hand, things may proceed
for a long time before any symptoms appear.
I've experienced b8zs / ami mismatches on many occasions because 1)
the span was not ordered b8zs and 2) a frame tech, believing he's
spotted an error changes my line coding to b8zs. (I have resoved that
from now on any new span's ordered will be b8zs/ESF as this is the
most common configuration and doesn't freak out my carriers!)
Tom Lynn
On Sat, 27 Apr 1996 22:18:35 GMT, suh...@bright.net (Steve Uhrig)
wrote:
>lang...@cais.com (Larry L. Langrehr) wrote:
>
>>I have a simple question. If CPE on side of a T span is set to AMI line
>>encoding and CPE on the other end is set to B8ZS, and the span is only
>>used for voice traffic, not data, and the span is clean, no errors, will
>>either end detect a problem or not? Has anyone run into such a condition
>>before? Theoretically it sounds as if it should work. Would appreciate
>>any and all comments either by a response to this post or direct email,
>>thanks.
>
> Span line repeaters would have to put out B8ZS in both
>directions. I don't know of any that will run one format in
>one direction and a different one in the other. Also if the
>T1 goes through a DAC you are in trouble there.
>
>
Mike McCammant
In article <4lv4ba$p...@samba.rahul.net>,
Wayne E. Amacher <wama...@rahul.net> wrote:
>Subject: Re: AMI and B8ZS together
>Newsgroups: comp.dcom.telecom.tech
>References: <4ltvnv$b...@news2.cais.com>
>Organization: a2i network
>Distribution:
>
>: I have a simple question. If CPE on side of a T span is set to AMI line
>: encoding and CPE on the other end is set to B8ZS, and the span is only
>: used for voice traffic, not data, and the span is clean, no errors, will
>: either end detect a problem or not? Has anyone run into such a condition
>: before? Theoretically it sounds as if it should work. Would appreciate
>: any and all comments either by a response to this post or direct email,
>Try it it might work for voice. The codecs at the end not expecting B8ZS
>might make funny noises. I do not know of a situation where AMI (Alternate
>Mark Inversion is not used. It definately will not work for data.
If it is all on copper, you will have some problems. Noise, dropouts, etc.
But if it ever hits a higher level type of mux eqpt (ie M13 DS1-> DS3
mux), it will work fine with voice, and will also work fine for any data
applications in multiples of 56kbs. If it leaves your building and goes
more than a few miles, you probably hit higher level mux equipment.
AMI and B8ZS are not end-end protocols, but only pertain to the
equipment at both ends of a copper span. As long as the equipment is
set the same, there is no mismatch.
As long as you are not trying 64kbs multiples of data, you will never hit
the > 15 0's threshold that will cause problems w/AMI. You can even run
ISDN PRI on AMI facilities without any problems using 56kbs B channels.
--
Mike - mik...@macshack.com - Home of the JEO-Counter, graphic WWW counter
/---------------------------------------\ My opinions belong to me,
| Visit us at http://www.macshack.com | myself and I, not my employer,
\......................................./ the government or my wife...:)
Kenneth A. Becker
Well, I'm going to weigh into this discussion. I have
experience in the topic, since I've been involved in building and
testing DACS II line cards for a while.
Point #1: AMI is a subset of B8ZS.
Point #2: If you don't have eight continuous 0 bits on a line
configured for B8ZS, you won't see any difference between that
line and a similar line configured for AMI.
Point #3: Lines configured for voice or data calls and AMI have
"alternative" means of getting the one's density up. Such as
the infamous "stomp" mode, where bit D6 gets set to a 1 when the
other seven bits in the time slot are set to 0 for some reason.
So: putting an AMI based line into a T1 receive configured for
B8ZS is not going to cause any strangenesses at that receive. The
AMI subset will keep the receive happy, at least until one starts
sending more than 15 contiguous zeroes in a row. Then, you start
giving the PLL's in the receiver the fits, since it doesn't have
enough energy to maintain bit synchronization. Stomp mode fixes
that, but it has to be turned on somewhere.
However, the other direction gets kind of interesting. Refer back
to Point #2. I said "8 contiguous zeroes". Those 8 could span two
time slots, be in one time slot, or, for more fun, span one time
slot, the framing bit (one every 193 bits!) and another time
slot. Back-to-back bipolar violations (which is what you get with 8
zeroes on a B8ZS line) will show up as BPV's. If it happens during
a framing bit you get LOF errors as well. At least some of these
errors can cause the signalling bits (assuming that you're using
the T1 as a POTS equivalent) to freeze up for a frame or two while
the receiver figures out if this is a real alarm or not. Since
voice data and data data is going to be pretty random, B8ZS
configured lines are going to be generating these back-to-back
BPV's on a pretty regular basis. Get 'em a little too regular and
you'll start to see some of the problems previous respondents have
been mentioning. Worst of all, it'll be flaky, hard to track down
kinds of errors - because the data, the occurences of the B8ZS
codes, and the location of those B8ZS codes will be random with
variations over time, the phase of the moon, and so on.
So: If you got a choice, >>don't do this thing<<. Keep your AMI
with AMI and your B8ZS with B8ZS. Your life will be simpler and the
probability of midnight wake-up calls vastly reduced.
Ken Becker
kenneth....@att.com
DACS Hardware Engineering
John Agosta
In article <4ltvnv$b...@news2.cais.com>, lang...@cais.com (Larry L. Langrehr) says:
>
>I have a simple question. If CPE on side of a T span is set to AMI line
>encoding and CPE on the other end is set to B8ZS, and the span is only
>used for voice traffic, not data, and the span is clean, no errors, will
>either end detect a problem or not? Has anyone run into such a condition
>before? Theoretically it sounds as if it should work. Would appreciate
>any and all comments either by a response to this post or direct email,
A CSU that can be configured independently on DTE or LINE
side for AMI/B8ZS will allow both the appropriate conversion.
However, for voice "only" your CODEC will never create an all
zero octet, making B8ZS word generation a moot point - so you
shouldn't be experiencing "errors."
Its best to configure your CSU appropriately, however - if only for
the sake of consistency... and in the future when someday you
"may" have a need to carry data.....
ja
Martin DAnjou
May I ask a question on this AMI/B8ZS thing?
What is the prefered setting option for the user of the equipment to
select between AMI and B8ZS? Dip switch or software interface. S/W interface
can do it remotely, dip switch can't; but which one is prefered?
Martin.
--
| Martin d'Anjou | tel: (613) 765-3058 |
| Nortel | fax: (613) 763-9535 |
| P.O. Box 3511, Station C | email: mda...@nortel.ca|
| Ottawa, Ontario, CANADA K1Y 4H7 | These are my opinions |
| http://www.nortel.com/ | Not Nortel's |
Floyd L. Davidson
In article <4m1eje$3...@nntpa.cb.att.com>,
Kenneth A. Becker <k...@hokab.tbu.att.com> wrote:
>Point #1: AMI is a subset of B8ZS.
>Point #2: If you don't have eight continuous 0 bits on a line
>configured for B8ZS, you won't see any difference between that
>line and a similar line configured for AMI.
Point #2a: "Digitized voice DS-0 channels using PCM and ADPCM
never cause 8 consecutive zeros" (quoted from page T1-18 of "The
T1 Fact Finder Book" from Phoenix Microsystems, published 1
January 1989, Part # T1-1189.
The original question related to a voice only system.
>However, the other direction gets kind of interesting. Refer back
>to Point #2. I said "8 contiguous zeroes". Those 8 could span two
>time slots, be in one time slot, or, for more fun, span one time
>slot, the framing bit (one every 193 bits!) and another time
>slot. Back-to-back bipolar violations (which is what you get with 8
>zeroes on a B8ZS line) will show up as BPV's. If it happens during
>a framing bit you get LOF errors as well. At least some of these
That assumes either that one sync bit error will cause LOF or that
the condition exists for multiple frames. Both are unlikely, and
in the case of voice only, impossible.
>errors can cause the signalling bits (assuming that you're using
>the T1 as a POTS equivalent) to freeze up for a frame or two while
>the receiver figures out if this is a real alarm or not. Since
>voice data and data data is going to be pretty random, B8ZS
>configured lines are going to be generating these back-to-back
>BPV's on a pretty regular basis. Get 'em a little too regular and
>you'll start to see some of the problems previous respondents have
>been mentioning. Worst of all, it'll be flaky, hard to track down
>kinds of errors - because the data, the occurences of the B8ZS
>codes, and the location of those B8ZS codes will be random with
>variations over time, the phase of the moon, and so on.
That is very true for data data, but not true if and only if there
are _no_ data services on the T1. For voice only it will not make
any difference at all.
>So: If you got a choice, >>don't do this thing<<. Keep your AMI
>with AMI and your B8ZS with B8ZS. Your life will be simpler and the
>probability of midnight wake-up calls vastly reduced.
Even though it won't show up with voice only use, the above is
_EXCEEDINGLY_ good advice. Sooner or later someone is going to
put data services on that voice only T1... and then the fits
begin to happen. Proper engineering is to match both ends, and
good engineering is to use B8ZS (and ESF too) unless there is
a specific reason that it can not be used.
Floyd
AT&T Alascom
--
Floyd L. Davidson fl...@polarnet.com
Salcha, Alaska or: fl...@ims.alaska.edu
Al Varney
In article <4m3240$g...@icefog.polarnet.com>,
Floyd L. Davidson <fl...@polarnet.com> wrote:
>In article <4m1eje$3...@nntpa.cb.att.com>,
>Kenneth A. Becker <k...@hokab.tbu.att.com> wrote:
>>Point #1: AMI is a subset of B8ZS.
>>Point #2: If you don't have eight continuous 0 bits on a line
>>configured for B8ZS, you won't see any difference between that
>>line and a similar line configured for AMI.
>
>Point #2a: "Digitized voice DS-0 channels using PCM and ADPCM
>never cause 8 consecutive zeros" (quoted from page T1-18 of "The
>T1 Fact Finder Book" from Phoenix Microsystems, published 1
>January 1989, Part # T1-1189.
>The original question related to a voice only system.
>>However, the other direction gets kind of interesting. Refer back
>>to Point #2. I said "8 contiguous zeroes". Those 8 could span two
>>time slots, be in one time slot, or, for more fun, span one time
>>slot, the framing bit (one every 193 bits!) and another time
>>slot. Back-to-back bipolar violations (which is what you get with 8
>>zeroes on a B8ZS line) will show up as BPV's. If it happens during
>>a framing bit you get LOF errors as well. At least some of these
>
>That assumes either that one sync bit error will cause LOF or that
>the condition exists for multiple frames. Both are unlikely, and
>in the case of voice only, impossible.
I think Kenneth is correct here (but us switching folks have been
known to be wrong). B8ZS doesn't know or care about DS-0 channels;
it's a DS-1 thing. So ANY 8 consecutive zeros seen at the DS-1 level
will cause a B8ZS line-coder to substitute BPVs. Even 8 zeros caused by
the 4 low bits of channel 1 and the 4 high bits of channel 2.
It is my understanding that B8ZS is a line-coding mechanism; that is,
it applies to un-framed lines as well as those framed as SF, ESF, etc.
If so, then B8ZS detection of 8 zeros occurs after framing, so the framing
bit could indeed be one of the bits counted in the "consecutive zero"
mechanism. Thus the layering (non OSI!) at the transmitter is:
Layer 3) Determine DS-0 content (8-bit units); apply Zero Code Suppression
(ZCS) if required to insure non-zero value.
Repeat for each channels.
Layer 2) Determine framing bit value based on SF, ESF, etc.
Layer 1) Take bits from 1) & 2) as needed, convert to bi-polar line code.
If B8ZS, any 8 consecutive zeros are converted to double-BPV
pattern.
It would appear you will see some BPVs at a non-B8ZS receiver....
Al Varney - just my (non-lucent) opinion
Floyd Davidson
var...@ihgp4.ih.att.com wrote:
>In article <4m3240$g...@icefog.polarnet.com>,
>Floyd L. Davidson <fl...@polarnet.com> wrote:
>>In article <4m1eje$3...@nntpa.cb.att.com>,
>>Kenneth A. Becker <k...@hokab.tbu.att.com> wrote:
>>>Point #1: AMI is a subset of B8ZS.
>>>Point #2: If you don't have eight continuous 0 bits on a line
>>>configured for B8ZS, you won't see any difference between that
>>>line and a similar line configured for AMI.
>>
>>Point #2a: "Digitized voice DS-0 channels using PCM and ADPCM
>>never cause 8 consecutive zeros" (quoted from page T1-18 of "The
>>T1 Fact Finder Book" from Phoenix Microsystems, published 1
>>January 1989, Part # T1-1189.
>
>>The original question related to a voice only system.
There are four points above, and all have to be kept in mind for
the right perspective on this. What Ken is saying is not wrong,
and what Al is saying is not wrong... but neither are addressing
the specifics of the question.
> I think Kenneth is correct here (but us switching folks have been
>known to be wrong). B8ZS doesn't know or care about DS-0 channels;
>it's a DS-1 thing. So ANY 8 consecutive zeros seen at the DS-1 level
>will cause a B8ZS line-coder to substitute BPVs. Even 8 zeros caused by
>the 4 low bits of channel 1 and the 4 high bits of channel 2.
... [ lots of correct info deleted ]
> It would appear you will see some BPVs at a non-B8ZS receiver....
Yes, _if_ there are 8 zeros in a row. And with data services,
either on framed or unframed DS-1's, that will happen. But on
voice only PCM or ADPCM it will never happen. And the question
related to will that be the case with a voice only DS-1 circuit.
Indeed, that will be the case...
But once again, despite the fact that someone thinks they are
designing a "voice only" DS-1, it would be very poor engineering
to try mixing plain AMI with B8ZS encoding because as sure as the
sun comes up in the morning someone will put a DDS circuit on the
DS-1 immediately after everyone has forgotten that it was never to
be anything but a voice system. And everyone _will_ forget simply
because there will never be any BPV's as long as it is voice only.
BTW, I've never seen anyone purposely engineer a DS-1 that way,
but I've seen DS-1s accidentally installed that way and work for
years until a DDS circuit is installed. Circuit Order turns it
up, and Maintenance starts chasing BPV's. Of course the best part
is when that happens in someone else's office and they call and
tell you they are getting BPV's right off the digital radio and
want the transmit end checked. (Since BPV's are a wire facility
phenomenon, they don't get transmitted over digital radios...)
Steve Daggett
fl...@polarnet.com (Floyd Davidson) wrote:
>>>encoding and CPE on the other end is set to B8ZS, and the span is only
>>>used for voice traffic, not data, and the span is clean, no errors, will
>>>either end detect a problem or not? Has anyone run into such a condition
>>>before? Theoretically it sounds as if it should work. Would appreciate
>>>any and all comments either by a response to this post or direct email,
>>>thanks.
>>
>>directions. I don't know of any that will run one format in
>>one direction and a different one in the other. Also if the
>>T1 goes through a DAC you are in trouble there.
>
>never be enough 0 bits in a row to trigger the B8ZS encoding of
>bipolar violations that would trip up the receiver at the CPE end.
>In the other direction, which would be towards a DACS (or a span
>line repeater) for example, it won't make any difference at all
>because those receivers are enabled for B8ZS, and the CPE end
>never encoding BPV's won't bother it at all.
>
Actually there could be octects of all zero's in a voice
environment. The T1 Framer chip in the CPE, when set to AMI,
will force a "1" into bit seven if it receives a "all zeros"
octet from the device. This is called ZCS (Zero Code Suppression)
coding. When you set a voice channel for AMI, it usually implies
ZCS.
To the original question. The network you discribe will
"probally" not cause a problem as long as you ONLY carry voice
traffic. It will not support data communications. It will also
probably be considered unsupportable by your carrier if you have
voice quality problems.
If the B8ZS side of you network attempts to send out a "all
zeros" octet into the network it will insert an octet with an
intentional "known" set of bipolar violation instead. The the
first piece of carrier equiment that is not configured for B8ZS
will "clean up" the BPV's and they will never be seen at the far
end. This "could" effect voice quality. I've never tried it...
A better solution would be to use a CSU that supports AMI
coding on the network side and B8ZS on the equipment side.
Most good quality CSU's will do this. You would end up with
an AMI span with only the tail between the CSU and the CPE
being B8ZS.
Steve D...
Al Varney
In article <4mf08s$9...@newsvr.cyberway.com.sg>,
Steve Daggett <sdag...@cyberway.com.sg> wrote:
>fl...@polarnet.com (Floyd Davidson) wrote:
>>suh...@bright.net wrote:
>>>lang...@cais.com (Larry L. Langrehr) wrote:
>>>
>>>>I have a simple question. If CPE on side of a T span is set to AMI line
>>>>encoding and CPE on the other end is set to B8ZS, and the span is only
>>>>used for voice traffic, not data, and the span is clean, no errors, will
>>>>either end detect a problem or not? Has anyone run into such a condition
>>>>before?
>>With voice only it won't make any difference because there will
>>never be enough 0 bits in a row to trigger the B8ZS encoding of
>>bipolar violations that would trip up the receiver at the CPE end.
>>In the other direction, which would be towards a DACS (or a span
>>line repeater) for example, it won't make any difference at all
>>because those receivers are enabled for B8ZS, and the CPE end
>>never encoding BPV's won't bother it at all.
> If the B8ZS side of you network attempts to send out a "all
>zeros" octet into the network it will insert an octet with an
>intentional "known" set of bipolar violation instead. The the
>first piece of carrier equiment that is not configured for B8ZS
>will "clean up" the BPV's and they will never be seen at the far
>end. This "could" effect voice quality. I've never tried it...
OK, folks, one more time. (And again, I may be wrong on this one....)
B8ZS is NOT an encoding scheme that uses intentional BPV's to encode
octets of all zeroes. B8ZS works even on un-framed DS1's, so how could
the encoder know where an "octet" begins.
B8ZS is a "line code" scheme that uses intentional BPV's to replace any
string of 8 consecutive zeroes (even if they aren't in the same octet).
This is similar to the B6ZS scheme used at the DS2 rate, or the B4ZS scheme
used at higher rates. B4ZS is commonly known as HDB3 (High Density Bipolar,
3 zeroes).
With voice-only DS1 encoding, it is certainly possible for the last 4
bits of one time slot and the first 4 bits of the next time slot to each
contain 0000. B8ZS will convert this to the double BPV pattern, and a non-
B8ZS receiver will observe unexpected BPV's.