Subject: Fw: [USR-TC] Anyone using the May release of v.92?

From: Justin Kendall <[email-masked]>
Date: Fri, 24 May 2002 21:50:30 +0000

Sure,
As with pretty much anything right out of the box there was a lot of up
front configuration to be done. Trunking, templates, etc. But once
everything seemed like it was how I wanted it something still wasn't quite
right. Intermittent and seemingly random problems included MANY carrier
drops where we are used to almost none, DSP's not filling over 20%, cards
taking 3 to 4 hours to start accepting calls after booting up, and connect
speeds averaging between 1200 and 28000 ( not too hot, I say ).
Anyhow, after trying hundreds of configurations and almost resigning myself
to swear off networking and join the priesthood we discovered that during
the upgrade our Telco had changed our line coding to AMI when we were
running B8ZS. I didn't think it would be that big of a deal because I
thought it wouldn't even synchronize if the coding was off but it sure made
a difference! So by "tweaking" I mean to say that after everything was
working correctly our settings look quite different than I had assumed they
would when I started the process.
By the way, I'm not very familiar with line coding, would there be any
reason to use AMI on a T1 if all equipment supports B8ZS? Is there some
advantage to it?
Cheers,

Justin Kendall
Network Administrator
NetEase, Inc.
Santa Rosa, CA
[email-masked]

----- Original Message -----
From: "Oliver Francke" <[email-masked]>
To: "Justin Kendall" <[email-masked]>
Sent: Friday, May 24, 2002 10:06 PM
Subject: Re: [USR-TC] Anyone using the May release of v.92?

> Hi Justin,
>
> as I can steal some time to do first testing with the 4.5 release...
>
> On Fri, May 24, 2002 at 01:56:05PM +0100, Justin Kendall wrote:
> > The only update I've used since 4.5 is 3.5.100 for DSP and it's working
like
> > a charm so far.
> > Took a lot of tweaking but we're using it on 45 cards now with almost no
> > trouble.
>
> ... what do you mean with "tweaking", perhaps it's even of interest to
> the complete mailing-list?!
>
> Thnx in @vance, Oliver.
>
> >
> > Justin Kendall
> > Network Administrator
> > NetEase, Inc.
> > Santa Rosa, CA
> > [email-masked]
> >
> [...]
>
> --
> Was hat bei uns die geringste PopulariTAET?
>
> [email-masked]               fon. +49-5246-80-1389
>                                            mob.  +49-171-5597734
> I used to have a sig, but I've stopped smoking now.
>

---

From: RG <[email-masked]>
Date: Sat, 25 May 2002 12:00:04 +0000

Re - Line Coding - see:
www.modemsite.com/56k/coding.asp

Aloha,
Richard

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Justin Kendall
> Sent: Friday, May 24, 2002 3:53 AM
> To: [email-masked]
> Subject: Fw: [USR-TC] Anyone using the May release of v.92?
>
>
> Sure,

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 28 May 2002 17:19:40 +0000

Also sprach Justin Kendall
>reason to use AMI on a T1 if all equipment supports B8ZS? Is there some

Well...yes or no really doesn't strictly cut it here.  :)

First, expanding some acronyms
AMI = Alternate Mark Inversion
B8ZS = Binary 8 Zero Suppression

As you may be aware, T1 signals are synchronous (meaning there is no
start and stop bits, and that it is assumed that the two ends of the
connection have a clock that provides accurate enough timing that the
bits can be reliably sent and received from one side to the other just
by maintaining, very precisely, the rate at which they are sent.

T1 signals are also "self-timed" meaning that if you don't have a clock
available to you that is precise enough to serve the purpose described
above, that you can use the pulses of the signals on the T1 itself to
"derive" the frequency of the data coming in.

Data is put onto the line in a fairly basic manner in T1's, basically no
voltage on the line indicates a 0 bit, and a high voltage (sorry, don't
remember the exact voltages in the specs) indicates a 1 bit.  0 bits are
called spaces, and 1 bits are called marks, so the "M" in AMI refers to
the 1 bits, marks.

Alternate mark inversion means that each mark that is sent on the line
is of the reverse polarity from the previous mark.  So if you have a
positive voltage for a mark sent, you can have any number of spaces
(0's), then the next mark will be of negative voltage (same magnitude of
voltage just negative in polarity rather than positive).

This inversion is done so that clock can reliably be recovered from the
line.  So how does this happen?  Well, to recover the clock, you have to
have changes in the signal frequently enough so that the receiver can
determine how frequently the signal is changing and bits are being sent.
T1's do this though the use of the inversion of the marks....if you have
a string of consecutive marks, rather than just having a constant high
positive voltage, it will jump back and forth between positive and
negative voltage...once per bit, the clock is therefore easily recovered
from that.

So, what happens when you have a whole string of spaces, where there is
no voltage jumping back and forth?  Guy goes to a doctor and says, "Doc,
it hurts when I do this."  Doc says, "Then don't do that."  Same thing
goes for T1's...you just make sure that you don't ever send a long
string (more than 15 specifically) of spaces.  This is known as
maintaining ones density...it ensures that there is enough marks in the
bit stream that the receiver can be sure that its clock isn't drifting
too much from the "standard."

There are a variety of ways to maintain ones density.  AMI, on its own,
does nothing to maintain ones density, it just specifies that the marks
switch their polarity back and forth, it says nothing about how
frequently they occur.  Voice calls over T1 channels just ensure that
the way the voice is encoded onto the line doesn't result in a timeslot
that ever has all 0's which is sufficient to ensure ones density.  In
other words, u-law PCM encoding will never generate a timeslot that has
all 0's, so with voice calls on T1's you just don't need to worry about
ones density, it just will always be there.  That's why most old
channelized T1's will just run D4/AMI...there's no need to worry about
ones density.

With the advent of ISDN, though, ones density is now a problem.  Both
the D channel, as well as the B channels, can now send all 0's timeslots
(think of when a PPP connection over ISDN is negotiating an asyncmap
with no characters escaped....it sends 6 consecutive bytes of 0x00,
which goes across the actual T1 as 6 timeslots in that channel of all
0's...and that's just a single example...all 0's can occur in data
streams quite frequently).  All that has to happen is two of these
timeslots with all 0's in it have to line up, and you then have 16
consecutive spaces, which can result in desyncronization of the line.

So, engineers came up with B8ZS, which works at a low level on the T1
line and replaces any all zero's timeslots with a specific pattern that
cannot occur in a data stream.  But, you say, "With ISDN, any data
pattern is possible."  And you would be almost right.  Any *legal* data
pattern is possible with ISDN.  B8ZS takes the all zeros timeslots and
replaces it with a pattern that contains two Bi-Polar Violations in
specific locations.

A Bi-Polar Violation (BPV) occurs when two marks (with 0 or more spaces
in between them) have the same polarity, ie, a positive mark is followed
by some number of spaces (possibly none), and then another positive mark
when it should have been a negative one.

B8ZS will insert two of these BPV in a timeslot when the timeslot would
have nominally had all zero's...this means that there are now 4 marks in
the timeslot that nominally would have had none, which is sufficient to
ensure ones density.  Specifically, a B8ZS substituted frame will look
like the following (assuming the last mark seen on the line was a
positive mark):

Bit position
1 2 3 4 5 6 7 8
0 + - 0 0 - + 0

The receiver can then know, when it sees BPV's in this specific pattern
on a time slot, to replace the bit stream with all zero's again.

So...back to the original question.  B8ZS is a superset of AMI (indeed,
B8ZS depends on AMI to function properly...without AMI, there are no
BPV's and without BPV's there is no pattern that can be used to
substitute for all zeros), so if you have B8ZS available on all of the
equipment involved in the connection, there is no reason not to use it.

Be aware that all equipment that the T1 traverses (well...all of the
equipment that addresses the T1 at the T1 level anyway), will need to
support B8ZS for it to work, otherwise you could have a mux in the
middle of the connection that doesn't support B8ZS that would flag all
nominally all zeros timeslots as BPV's and blow away the
BPV's...resulting in a truely all zeros frame again...this can result in
the desyncronization of the line, and the equipment that doesn't support
B8ZS will report large numbers of BPV's

Incidentally, this whole B8ZS/AMI thing is the reason for "all-zero's"
test patterns in test equipment for T1's.  Running all zero's over the
line will test that all of the equipment that deals with the line
supports and is correctly set up to use B8ZS.

Anyway...that's probably way more than many of you wanted to know...but
I didn't see a way to easily answer the question, as posed, without a
fairly significant amount of background information.  :)

Let me know if you have questions.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456