T1 line codeing/Framing ?
Ray Cotten
Can someone explain to me Line coding and Framing?
Specifically ami and b8zs on line coding and esf and d4 on framing.
We have several T1's here and they are all setup different and I dont
understand why. Further more one of them is setup as b8zs/esf from the
CO and ami/esf in my PBX and its taking calls ok, HOW?
Thanks for any help. Any suggested reading?
Ray Cotten
ra...@indy.net
Pat
Ray,
The best book I've seen on the subject of T-1 is Bill Flanagan's "The
Guide to T-1 Networking" ISBN 0-936648-26-0. It is published by Telecom
Library, Inc. at 1-800-999-0345. I've recommended it so often, I'm
beginning to think I deserve a commission -- or a free copy of the next
edition for me and a few others here at comp.dcom.telecom.tech.
Framing and line coding are different things. Framing's basic job is to
keep the bits organized so the receiving-end knows where to find the
information for the individual channels. Generally, there are two types
of framing: ESF is one type -- newer and preferable, the other is
called SF or sometimes D4. If you had the framing set to different
types at the ends of the circuit, your T-1 line would not work at all.
AMI line coding overcomes some of the "nasties" inherent with copper
cable used for digital transmission. B8ZS line coding is a slight
variation of AMI and uses AMI as its "foundation." B8ZS gives you
access to the full bandwidth of each channel: 64,000 bits per second.
Without it, you have a bandwidth of 56,000 bits per second. The
advantage is only seen for digital data transmission -- not voice
service or analog data. When using B8ZS, and only when 8 consecutive
zeros are sent by the transmiter, a special "code" is substituted for
the 8 zeros. The receiver recognizes the special code, removes it, and
puts the 8 zeros back in the data stream. If the transmitter is set for
B8ZS, and the receiver is set for AMI, The receiver will see two
bipolar violations (built into the special code) each time a B8ZS code
is sent -- that is, each time the transmitted data stream contains 8
consecutive zeros. If there is never an occurance of 8 consecutive
zeros in the data stream, there will never be a special B8ZS code sent
and the data stream on the B8ZS line would look exacactly like the data
stream on an AMI line.
If you are using the T-1 for voice service, and B8ZS line coding is set
only on one end of the T-1, you will probably never notice. As you
said: "it's taking calls ok." Some folks say there will never be 8
conscutive zeros in voice service.
Sure, its better to set both ends for the same line coding -- and you
should do so. Symptoms would be much more obvious if you were using the
T-1 for digital data service: you would see errors, or some files would
not transfer or be very slow to transfer. Your users would probably
complain -- maybe not though, they accept poor service if that's the
way it's always been.
Regards,
Pat
Floyd Davidson
[emailed and posted]
In article <5he4c1$s98$1...@news.indy.net>, Ray Cotten <ra...@indy.net> wrote:
>Can someone explain to me Line coding and Framing?
>
>Specifically ami and b8zs on line coding and esf and d4 on framing.
>
>We have several T1's here and they are all setup different and I dont
>understand why. Further more one of them is setup as b8zs/esf from the
>CO and ami/esf in my PBX and its taking calls ok, HOW?
>
>Thanks for any help. Any suggested reading?
D3/4 Superframe formatting was introduced in 1973 and consists
of 24 DS0 channels, each with an 8 bit byte per frame, plus 1
sync bit. That makes 24 * 8 = 192 bits plus 1 sync bit for 193
bits per frame. The sync bit (also called the framing bit) is
changed in a sequence that requires 12 frames (1 superframe) to
complete. The pattern is 1000 1101 1100. On the 6th frame and
the 12th frame the 8th bit of each channel is "robbed" to use
for signaling. The 6th frame is the "A" bit for each channel,
and the 12th frame is the "B" bit for each channel. The 4
possible states of the AB bits are onhook, offhook, busy, and
idle.
D5 Extended Superframe formatting was introduced in 1981 and
consists of the same 24 DS0 channels plus 1 sync bit as SF
formatting does, but a complete superframe is 24 frames instead
of 12. The sync bit in frames 4, 8, 12, 16, 20, and 24 is
sequenced with the pattern of 001011. The sync bits in all odd
numbered frames (1, 3, 5 ... 23) are used as a 4Kbps data
channel. The sync bits in frames 2, 6, 10, 14, 18 and 22 are
used to send a CRC-6 value for that frame. Just as with SF
formatting, robbed bit signaling is used, and since the extended
superframe is now 24 frames long, frames 6 and 12 are still the
A and B bits, and also frames 18 and 24 used to provide C and D
bits also.
There are significant differences between SF and ESF in
operation. Since SF has 12 frames per superframe, and because
each framing bit is used for synchronization, the receiving end
can "lock" onto the pattern very quickly compared to ESF
framing. ESF on the other hand has a built in error detection
scheme (the CRC-6 value) which allows better inservice
monitoring. The data channel and the C & D signaling bits are
rarely ever used.
Obviously SF and ESF cannot be mixed, and both ends of a T1 must
be configured the same to achieve frame lock.
AMI and B8ZS are entirely separate from the framing. The
original design was to use AMI (Alternate Mark Inversion) line
encoding. The signal is bipolar, and each 1 bit is a pulse of
the opposite polarity from the previous 1 bit. Bits with 0
values do not produce a pulse. There are a number of advantages
in using this form of coding. The maximum frequency of the data
is half what it would be if each pulse had the same polarity,
the signal is AC with no DC offset, and there are number of
other useful characteristics.
It does suffer one problem, which initially was handily solved
because only PCM (Pulse Code Modulation) voice channels were
using T1 carrier. That problem is called 1's density, and is
needed for the receive end to determine the input clock rate.
Without enough 1's to lock a phased locked loop circuit, the
input circuits can't function. The solution was to never send a
0 byte value from a PCM analog to digital converter! That meant
that the worst case would be this:
24th DS0 framing 1st DS0
byte bit byte
1000 0000 0 0000 0001
which is 15 zero bits in sequence, and which is sufficient to allow
clock recovery.
Then came computer data circuits, and a variety of ways were
developed to encode the data to ensure that a string of 0 bytes
in the data would still have a high enough 1's density. The
system that Bell Labs developed to accomplish that is known as
B8SZ. When a sequence of 8 zero bits in row is detected at the
transmit end, it is replaced with a code that consists of the
pattern 00011011, where the bits 5 and 7 are of the same
polarity and produce a BPV (bipolar violation). At the receive
end that pattern of bits with the BPV is replace with 8 zero
bits.
Hence B8ZS is a special case of AMI. In fact, if no sequence of
8 zero bits is ever sent (as with a PCM voice channel) there is
no way for an AMI receiver to know that the transmitter is
arranged for B8ZS. And an AMI transmitter can never trigger the
B8ZS replacement in an AMI receiver. That can cause a T1 to be
put into service with one end AMI and the other end B8ZS and as
long as only voice circuits are provisioned, there will be no
problems. Then years later a data circuit is added and it
doesn't work! The way to avoid that is to always test a new T1
with at least one test pattern that contains more than 8
consecutive zero bits. If the encoding is not configured
correctly the AMI end will show BPV's. If the circuit is
supposed to be B8ZS a test pattern with more than 15 zeros
should be sent to verify that clock rate recovery can be
accomplished.
From the above, you can see why your PBX voice trunks can be
incorrectly optioned as AMI/B8SZ at opposite ends and still
function perfectly.
Floyd
--
Floyd L. Davidson Salcha, Alaska fl...@tanana.polarnet.com
Dave McGuigan
As a related question to the one Ray brought up, can someone explain the
difference between AMI and ZCS (zero code suppresion) line coding? I
have some T1 cards that indicate they require ZCS signalling but my
service provider assures me that they will work fine with AMI. Is this
likely to be true. I am only concerned with voice (DID) traffic.
Thanks for any help or comments,
Dave
Tim McManus
AMI line code is produced by transmitting a pulse for logical bit 1
and no pulse for logical bit 0. The pulses will alternate in polarity
ie. the first bit will be +3V and the next bit will be -3V ... the ZCS
you mention is probably another term for B8ZS or (B)ipolar with (8)
(Z)ero (S)ubstitution, AMI does not allow long strings of logical bit
0's. B8ZS replaces a string of eight zero's (00000000) with a specific
sequence (not sure the seq.), but the receiving end will convert the
sequence back to eight zero's (00000000).
Hope this information is correct, this was my understanding of the
difference at least ...
Jerry Askew
> As a related question to the one Ray brought up, can someone explain the
> difference between AMI and ZCS (zero code suppresion) line coding? I
> have some T1 cards that indicate they require ZCS signalling but my
> service provider assures me that they will work fine with AMI. Is this
> likely to be true. I am only concerned with voice (DID) traffic.
To elaborate on Tim's comments... (I too am assuming that ZCS is another
term for B8ZS or is at least similar)
AMI coding requires "bit stuffing" of binary 1s into the T-1 stream to
achieve the necessary 1s density on the line, thus the limit of 56Kbps per
channel on an AMI line. B8ZS is actually a modified form of AMI wherein
so-called "bipolar violations" are intentionally transmitted in order to
encode long strings of binary 0s without running afoul of the "1s density"
requirement. Through this technique, one can achieve a full 64Kbs per
channel.
If the card *requires* B8ZS, it may very well not be compatible with AMI
coding. Most hardware that I've worked with, however, is compatible with
both. If you have a choice, you should use ESF/B8ZS since that is more
up-to-date than the old D4/AMI coding format.
Hope this helps,
-Jerry
Floyd Davidson
In article <01bc46cf$30a31520$e63bd4cc@ccn-cc-486>,
Jerry Askew <jda...@primenet.com> wrote:
>> As a related question to the one Ray brought up, can someone explain the
>> difference between AMI and ZCS (zero code suppresion) line coding? I
>> have some T1 cards that indicate they require ZCS signalling but my
>> service provider assures me that they will work fine with AMI. Is this
>> likely to be true. I am only concerned with voice (DID) traffic.
For voice only traffic it makes no difference at all for the
explicit reason that the 8-bit codecs used to generate PCM will
never generate a byte value of 0, by design. That means the
worst case scenario for consecutive 0 bits in a row would be
where the 24th frame has the last 7 bits 0, the framing bit is
0, and the first 7 bits of the 1st frame are 0. That would be
15 consecutive zero bits, which is exactly the maximum allowed
(strange co-incidence, eh?).
Except the fellows who designed it didn't figure on anyone using
a T1 for computer data as well as voice, mostly because there
was no such thing as "computer data" at the time and even a
decade plus later someone made that famous statement that the
total future world market for computers might be 4 or 5.
>To elaborate on Tim's comments... (I too am assuming that ZCS is another
>term for B8ZS or is at least similar)
ZCS is Zero Code Suppression, and pretty much covers any technique
used to accomplish it. Some are much worse that others by modern
concepts. B8ZS is the only method commonly being installed today.
>AMI coding requires "bit stuffing" of binary 1s into the T-1 stream to
Bit stuffing is not used on T1's at any time, as far as I know.
It is used on DS1C (3.152Mb) and other higher levels where
multple DS1 signals are multiplexed together. DS3's for
example, use bit stuffing.
>achieve the necessary 1s density on the line, thus the limit of 56Kbps per
>channel on an AMI line. B8ZS is actually a modified form of AMI wherein
>so-called "bipolar violations" are intentionally transmitted in order to
>encode long strings of binary 0s without running afoul of the "1s density"
>requirement. Through this technique, one can achieve a full 64Kbs per
>channel.
That is true.
>If the card *requires* B8ZS, it may very well not be compatible with AMI
>coding. Most hardware that I've worked with, however, is compatible with
I've never seen or heard of a DS1 interface that required B8ZS.
The other direction, however, is still a serious problem as
there are a significant numbers of old equipments in service
that are AMI only.
But... for voice only it just wouldn't make any difference at all.
>both. If you have a choice, you should use ESF/B8ZS since that is more
>up-to-date than the old D4/AMI coding format.
It is not uncommon to consider ESF (D5) and B8ZS as related, and
SF (D4) and AMI as related, but in fact they can be mixed. D4
framing works with B8ZS too, and D5 framing works with AMI just
fine. But on any new installation ESF and B8ZS should both be
used unless there is some overwhelming reason that it can't be
(such as it must cross-connect to an old switch or whatever that
simply has nothing available except SF and/or AMI.
David G. Lewis
A gratuitous quibble on timing:
In article <4b7cd$16c2e.15c@polarnet>,
Floyd Davidson <fl...@polarnet.com> wrote:
>For voice only traffic it makes no difference at all for the
>explicit reason that the 8-bit codecs used to generate PCM will
>never generate a byte value of 0, by design. That means the
>worst case scenario for consecutive 0 bits in a row would be
>where the 24th frame has the last 7 bits 0, the framing bit is
>0, and the first 7 bits of the 1st frame are 0. That would be
>15 consecutive zero bits, which is exactly the maximum allowed
>(strange co-incidence, eh?).
>
>Except the fellows who designed it didn't figure on anyone using
>a T1 for computer data as well as voice, mostly because there
>was no such thing as "computer data" at the time and even a
>decade plus later someone made that famous statement that the
>total future world market for computers might be 4 or 5.
Actually, Thomas J. Watson made his remark about the market for computers
some time in the late '40s - early '50s, whereas the encoding for the T1
carrier system was probably invented sometime in the late '50s (first
commercial use of T1 carrier was 1962, according to EOBS).
--
David G Lewis AT&T Network & Computing Services
david....@att.com or Network Evolution Planning
dgl...@ems.att.com
The Future: It's a long distance from long distance.
William N. Rapien
Dave McGuigan wrote:
>
> As a related question to the one Ray brought up, can someone explain the
> difference between AMI and ZCS (zero code suppresion) line coding? I
> have some T1 cards that indicate they require ZCS signalling but my
> service provider assures me that they will work fine with AMI. Is this
> likely to be true. I am only concerned with voice (DID) traffic.
>
>
> Dave
AMI should be fine if you are running voice (assuming that is analog and
not digital voice). Bandwidth for voice is only 3K anyway and it is
doubful that the one density problem will arise on analog lines.
However, if you should decide to connect a fast modem, the extra 8K of
bandwidth (from 56K to 64K) could be useful.
I would chose B8ZS if it is available simply because it is better. What
I do not understand is why your service provider would rather have you
use AMI.... unless they are using old pre-B8ZS equipment.
Bill
Chris_Martin
Floyd Davidson wrote:
>
[...]
> That is true.
>
> >If the card *requires* B8ZS, it may very well not be compatible with AMI
> >coding. Most hardware that I've worked with, however, is compatible with
>
> I've never seen or heard of a DS1 interface that required B8ZS.
In the ATM Forum DS1 Physical Layer Specification, there is a
requirement that "The line code used on the DS1 ATM UNI shall be Bipolar
8 Zero Substitution (B8ZS) as specified in ANSI T1.408 Section 5.3.2
..."
> The other direction, however, is still a serious problem as
> there are a significant numbers of old equipments in service
> that are AMI only.
>
> But... for voice only it just wouldn't make any difference at all.
>
> >both. If you have a choice, you should use ESF/B8ZS since that is more
> >up-to-date than the old D4/AMI coding format.
>
> It is not uncommon to consider ESF (D5) and B8ZS as related, and
> SF (D4) and AMI as related, but in fact they can be mixed. D4
> framing works with B8ZS too, and D5 framing works with AMI just
> fine. But on any new installation ESF and B8ZS should both be
> used unless there is some overwhelming reason that it can't be
> (such as it must cross-connect to an old switch or whatever that
> simply has nothing available except SF and/or AMI.
Do you have any idea how much equipment does *not* support ESF? How
whould I find this out?
>
> Floyd
> --
> Floyd L. Davidson Salcha, Alaska fl...@tanana.polarnet.com
--
_____________________________________________________________________
Chris Martin mar...@NetEdge.com http://www.netedge.com
NetEdge Systems PHONE: (919) 991-9253 FAX: (919) 991-9160
P.O. Box 14993, Research Triangle Park, NC 27709-4993
Dave McGuigan
Thanks for all the responses on this question. The service is in and as
almost everyone here indicated, AMI is working just fine for voice. I
still find the T1 card manufacturer's specifications calling for ZCS
line coding (vs B8ZS) to be a little unusual.
Dave
richard neveau
If they sell overseas (E1 trunks) it could be they were looking for
a 'generic term' for both 'ZCS' standards. It might also save a
few lines of software in the user interface.
I use 'RAI' for 'remote alarm indication' on both T1 and E1
trunks instead of special code for 'YEL' in US.
A yellow alarm IS a remote alarm. It is too close to screw
around with that difference JUST for US market. The new ANSI
specs call it RAI also so I can fall back on standard
over tradition. I want 'BLUE' AIS LEDs before I will worry
about tradition !
I do make the configuarion stuff use B8ZS/HDB3/ESF/D4/SF/CRC4 as
is appropriate. Configuring the line is enough of a pain
without using my own terms. I usually allow either D4 or SF
to be entered just to cover all the bases. It is a small pain
so maybe they decided to cut some corners in this area.
Most likely someone was trying to shave a few weeks off of a schedule
(or was a few weeks behind !). Not too unusual.
Kenneth A. Becker
In article <4b7cd$16c2e.15c@polarnet>,
Floyd Davidson <fl...@polarnet.com> wrote:
>ZCS is Zero Code Suppression, and pretty much covers any technique
>used to accomplish it. Some are much worse that others by modern
>concepts. B8ZS is the only method commonly being installed today.
>
>I've never seen or heard of a DS1 interface that required B8ZS.
>The other direction, however, is still a serious problem as
>there are a significant numbers of old equipments in service
>that are AMI only.
>
>But... for voice only it just wouldn't make any difference at all.
>
Oh, well, Hi Floyd: time for me to weigh in again.
Floyd was right in that ZCS is (probably) any method that keeps the
1's density up. In one of the systems I worked on ZCS equated to
what we fondly called "Stomp" mode - if one had an all-zero DS0
octet in a T1 it got bit D2 (the next-to-LSB bit) in it set
to 1. OK for voice, not so good for any kind of data com. But we
also had B8ZS available as well. In the days before B8ZS was widely
available and all one had was AMI, something had to be done in order
to keep the 1's density up so the PLL's in the T1 receivers wouldn't
break. Note that "Stomp" mode only worked with channelized T1's.
Regards,
Ken Becker
DACS Engineering
Lucent Technologies
Al Varney
Floyd, My recall of B8ZS is a little different.....
In article <31c7cd$1725a.15c@PolarNet>,
Floyd Davidson <fl...@polarnet.com> wrote:
>In article <5he4c1$s98$1...@news.indy.net>, Ray Cotten <ra...@indy.net> wrote:
>>Can someone explain to me Line coding and Framing?
>>
>>Specifically ami and b8zs on line coding and esf and d4 on framing.
>>
>AMI and B8ZS are entirely separate from the framing. The
>original design was to use AMI (Alternate Mark Inversion) line
>encoding. The signal is bipolar, and each 1 bit is a pulse of
>the opposite polarity from the previous 1 bit. Bits with 0
>values do not produce a pulse.
>
>It does suffer one problem, which initially was handily solved
>because only PCM (Pulse Code Modulation) voice channels were
>using T1 carrier. That problem is called 1's density, and is
>needed for the receive end to determine the input clock rate.
>Without enough 1's to lock a phased locked loop circuit, the
>input circuits can't function. The solution was to never send a
>0 byte value from a PCM analog to digital converter! That meant
>that the worst case would be this:
>
> 24th DS0 framing 1st DS0
> byte bit byte
>
> 1000 0000 0 0000 0001
>
>which is 15 zero bits in sequence, and which is sufficient to allow
^^^^^^^^^^^^^^^^^^^^^^
(Exhibit 1)
>clock recovery.
>
>Then came computer data circuits, and a variety of ways were
>developed to encode the data to ensure that a string of 0 bytes
>in the data would still have a high enough 1's density. The
>system that Bell Labs developed to accomplish that is known as
>B8SZ. When a sequence of 8 zero bits in row is detected at the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(Exhibit 2)
>transmit end, it is replaced with a code that consists of the
>pattern 00011011, where the bits 5 and 7 are of the same
>polarity and produce a BPV (bipolar violation). At the receive
>end that pattern of bits with the BPV is replace with 8 zero
>bits.
>
>Hence B8ZS is a special case of AMI. In fact, if no sequence of
>8 zero bits is ever sent (as with a PCM voice channel) there is
>no way for an AMI receiver to know that the transmitter is
>arranged for B8ZS.
As I recall, B8ZS is a line coding procedure, applied at the
time the bi-polar pulses are generated. At that point, there is no
knowledge of frame/byte alignment. So Exhibit 2 above applies, but
it applies to the raw bit stream, not just to individual time slots.
Thus ANY 8 zeroes in a row (as in Exhibit 1) causes B8ZS processing.
And they will show up as BPVs at the receiver.
> And an AMI transmitter can never trigger the
>B8ZS replacement in an AMI receiver.
(I disagree, as discussed above.)
>>We have several T1's here and they are all setup different and I dont
>>understand why. Further more one of them is setup as b8zs/esf from the
>>CO and ami/esf in my PBX and its taking calls ok, HOW?
I'd suggest the AMI end is receiving an occasional BPV, but not often
enough to fail the circuit. (Or maybe it ignores BPVs.) Is the ESF
SL (line code event) value set on your AMI end? If the AMI end ignores
BPVs and just considers them as "1-bits", it will distort an occasional
voice call -- can you tell? Do 28.8Kbps modems work OK over this interface?
If my re-call of B8ZS is in error, could someone point me to
a reference?
Al Varney - just my opinion
F
I
L
L
E
R
F
I
L
L
E
R
F
I
L
L
E
R
F
I
L
L
E
R
Floyd Davidson
In article <5jje5p$e...@ssbunews.ih.lucent.com>,
Al Varney <var...@lucent.com> wrote:
>Floyd, My recall of B8ZS is a little different.....
>
>In article <31c7cd$1725a.15c@PolarNet>,
>Floyd Davidson <fl...@polarnet.com> wrote:
>>
>> byte bit byte
>>
>> 1000 0000 0 0000 0001
>>
>>which is 15 zero bits in sequence, and which is sufficient to allow
> (Exhibit 1)
...
>>B8SZ. When a sequence of 8 zero bits in row is detected at the
> (Exhibit 2)
>
...
>>Hence B8ZS is a special case of AMI. In fact, if no sequence of
>>8 zero bits is ever sent (as with a PCM voice channel) there is
error mode on error detected error mode off
>>no way for an AMI receiver to know that the transmitter is
>>arranged for B8ZS.
>
> As I recall, B8ZS is a line coding procedure, applied at the
>time the bi-polar pulses are generated. At that point, there is no
>knowledge of frame/byte alignment. So Exhibit 2 above applies, but
>it applies to the raw bit stream, not just to individual time slots.
>Thus ANY 8 zeroes in a row (as in Exhibit 1) causes B8ZS processing.
>And they will show up as BPVs at the receiver.
>
>> And an AMI transmitter can never trigger the
>>B8ZS replacement in an AMI receiver.
> (I disagree, as discussed above.)
Al is correct, of course. I overstated the case, in that it is
not that it doesn't happen, it does. It isn't often enough to
cause any problems or kick any error detection on that will turn
down a circuit. The practical effect is the same, but the
technical specifics are not. My appologies.
> If my re-call of B8ZS is in error, could someone point me to
>a reference?
>
>Al Varney - just my opinion
Nope, the error was mine.
John Agosta
In article <5jje5p$e...@ssbunews.ih.lucent.com>, var...@ihgp2.ih.lucent.com (Al Varney) says:
>
>Floyd, My recall of B8ZS is a little different.....
>
>
snip
snip
> If my re-call of B8ZS is in error, could someone point me to
>a reference?
>
>Al Varney - just my opinion
Any time 8 consecutive zeros appear, such as in:
000+0000000000-0+-
B8ZS will substitute the 8 zeros with two BPV events.
the first will be in what was the 4th consecutive 0 position,
and the second will be where the 7th consecutive 0 was.
Each one will be of the opposite polarity with respect to each other.
The result is:
000+[000+-0-+]00-0+-
B8ZS
This does not have to be on an octet boundary.
So, Al, whats with all the:
F
I
L
L
E
Rs ????
-ja
Al Varney
In article <5itcae$1...@newsb.netnews.att.com>,>In article <4b7cd$16c2e.15c@polarnet>,
>Floyd Davidson <fl...@polarnet.com> wrote:
>>Except the fellows who designed it [T1] didn't figure on anyone using
>>a T1 for computer data as well as voice, mostly because there
>>was no such thing as "computer data" at the time and even a
>>decade plus later someone made that famous statement that the
>>total future world market for computers might be 4 or 5.
>
>Actually, Thomas J. Watson made his remark about the market for computers
>some time in the late '40s - early '50s, whereas the encoding for the T1
>carrier system was probably invented sometime in the late '50s (first
>commercial use of T1 carrier was 1962, according to EOBS).
Just to complicate the story: The T1 Digital Line is happy to
transmit data or voice -- it's just a bit stream channel (bipolar, 1's
density requirement easily met with any number of line codes). The
D1 Channel Bank, which used T1 to transmit bits, used a 7-bit codec
running at 8KHz and used the 8th bit as a signaling bit (1 = off-hook).
Thus a simple bipolar line code was possible, regardless of the 7-bit
values, since 15-ones density was met even if a bit was dropped.
No super-frame was needed, since every frame was identical -- sending
channels in the sequence 1,13,2,14,...,12,24.
This was introduced in a July, 1962 field trial. Not Toll quality, but
close. Note that the line speed was selected as the highest multiple of
12 (the analog carrier channel bank size) that could be met with existing
cable and a reliable line-powered repeater design with repeaters spaced
6000 feet apart (so existing sites for load coils could be used to
hold the repeaters). J. S. Mayo wrote an interesting description of
the design constraints in the BSTJ, Jan. 1962.
It wasn't until 1971 that the D2 Channel Bank, with Toll-quality
voice, was introduced. This was the first application of 8-bit codecs
(with a robbed-bit every 6th frame used for signaling) using a super-frame
of 12 frames and a high-accuracy thin-film-based A/D converter that didn't
need to be temperature controlled like the D1 diodes. This was also
the introduction of 15-segment (mu=255) mu-law companding, with an 18 dB
improvement in S/N ratio.
The addition of an 8th bit (most of the time) added 2 dB to the S/N ratio.
But the signaling couldn't be moved entirely to the framing bit to eliminate
the bit-robbing (every other framing bit isn't really needed except during
re-frame, so a 1 bit/channel signal could occur every 24 frames). Why?
Because the D2 had to be compatible with Dial Pulse and Revertive Pulse
trunks, which needs to track a very narrow DC pulse.
So why didn't the D2 use a different line code and eliminate the
all-zeros problem from the beginning (you couldn't connect a D1 to a
D2 anyway)? Again, minimizing costs to the Bell System's customers
required that all those D1s not be junked. Instead, the D1D retrofit
allowed old D1's to use the new framing and companding, and only changed
12 of the 31 common circuit packs and didn't require replacement of any
channel plug-ins. Changing the line code would have required changing
most of those 31 packs, and replacement of all test gear.
Note that every digital line system after T1 used a line code that
didn't need the minimum ones-density requirement.
It would appear that every design decision had a compelling reason,
but the result isn't what you would prefer.
1) PCM frames in the US were always in 12-channel multiples, because
a substantial deployment of 12-channel-increment analog carrier
existed in the US, and PCM was required to "fit" so analog-digital
multiplexers wouldn't have unused channels. So the US couldn't afford
the European 30-channel design.
2) Bit-robbing was needed because Dial/Revertive Pulsing signaling units
in the Toll network couldn't be replaced just to add PCM trunks.
And 8-bit codecs were needed because every local tandem and Toll switch
required D-A conversion before switching and A-D conversion after
switching, and the 7-bit encoding didn't have enough slop to tolerate
several conversions.
3) The simple line code used by D1 had to be preserved to reduce the cost
of upgrading all the D1 channel banks (1 million channels as of 1972).
Backward compatibility has its price....
Al Varney
In article <4167cd$15250.2fb@PolarNet>,
Floyd Davidson <fl...@polarnet.com> wrote:
>In article <5jje5p$e...@ssbunews.ih.lucent.com>,
>Al Varney <var...@lucent.com> wrote:
>>In article <31c7cd$1725a.15c@PolarNet>,
>>Floyd Davidson <fl...@polarnet.com> wrote:
>>>Hence B8ZS is a special case of AMI. In fact, if no sequence of
>>>8 zero bits is ever sent (as with a PCM voice channel) there is
>
>>Thus ANY 8 zeroes in a row (as in Exhibit 1) causes B8ZS processing.
>>And they will show up as BPVs at the receiver.
>
>Al is correct, of course. I overstated the case, in that it is
>not that it doesn't happen, it does.
Such errors on your part are very rare. I must say I enjoy your
articles, which are always lucid and precise, with a touch of humor.
I must confess to an error in my article as well. The ESF indicator
of Bipolar Violations is "LV" (Line Violation), not "SL" (Slip). My
eyes don't track as well horizontally as they used to.... :)
Al Varney