🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.dcom.telecom.tech
Article #47

Re: Please critique: When is a B channel only 56K?

#47
From: Al Varney
Date: Sat, 13 Jan 1996 19:51
101 lines
5847 bytes
Just some comments that might clear things up a bit --
In article <NEWTNews.820626346.32539.jrhodes@jrhodespc.nwest.mccaw.com>,
 <jrhodes@jrhodespc.nwest.mccaw.com> wrote:
>In article <4c1q90$n37@mercury.near.net>, <fgoldstein@bbn.com> writes:
>> No, RB's "wet hay" is more accurate.  The 56k restriction comes about
>> because 
>> a) T1 carrier using old-fashioned AMI signaling can't allow the
>> all-zero octet to be transmitted, so they ALWAYS set it to 1 during a 
>> call and allow you to send your info on the 7 other bits, thus 56k;
>> this is fixed via B8ZS encoding, and

   True that B8ZS fixes this problem -- but AMI is also an "encoding"
method (strictly, a "line coding method").  Both codings use bi-polar
pulses to indicate a '1' and no pulse for a '0'.  Pulses normally alternate
in polarity so the average DC current is about zero.  B8ZS encodes 8
consecutive zeros from the transmission equipment into a pattern of non-
alternating pulses that does not otherwise occur normally on the T1 line.
The far end decoder reverses the process.

   But the reason for the restriction of 15 or fewer zero bit times between
pulses is not due to equipment such as D4 channel banks and switches.
As someone noted, those end points could and do have much more accurate clocks.
But the real restriction is from the T1 repeaters, which have to accomplish
their task in extreme temperature/humidity/noise/power environments.  No
other clock is available for comparison purposes -- they must use/recreate
the T1 signal with only reference to the signal and some minimal circuitry.

   The original T1 repeater design/implementation has supported several
generations of digital line signaling/encoding.  It's unlikely that any
new standard will require upgrades/replacement of T1 repeaters.

>> b) Sometimes "inband" robbed-bit signaling is used where SS7 is not in
>> place, and in North America, this low-order (eighth) bit is set to 1
>> on every sixth sample (the other 5 are passed cleanly, but who's to 
>> coordinate this end-to-end?) during a call and used for call signaling
>> otherwise.  

   Note that SS7 itself does not FORCE the trunking equipment, which may
have been in place prior to SS7, to stop inserting A/B signaling bits
into the T1 frames.  For example, 1A ESS(tm) switches do not support
64 Kbps data transport over digital trunks, so no effort has been made
to suppress the A/B bits on SS7 trunks from those switches.  Also, some
digital switches may actually require the TELCo to replace hardware to
support 64 Kbps "clear channel" transmission.

   Correctly arranged switches will not, however, direct 64 Kbps data
calls over trunks that do not support 64 Kbps transport.  Voice and 56 Kbps
calls may use facilities that still have A/B bits and/or enforce the
15-consecutive-zero T1 rule.

>> These are both only noticeable for interswitch calls.

   True statement for ISDN-to-switch connections, but for analog lines the
line side may also undergo some restrictions due to digital loop carrier.
>
>Fred, can you help me understand what the yellow alarm on a T-1 for
>"15 zeroes" is? I thought an AMI T-1 could not take 15 consecutive
>zeroes before possibly slipping sync. It needs those 1's to make
>marks. Alternate Mark Inversion (AMI) means successive marks are
>different polarity, unless they are the same polarity, which is
>an AMI violation, which is used to mean something else. I don't 
>think a 1 is automatically inserted by the transmission gear as 
>you suggest in a), else there would be no need for a "15 zeroes"
>alarm.

   The option to insert '1's in an octet of all zeroes is called Zero
Code Suppression.  There is no "15 zeroes" alarm in the transmission
equipment, but some CPE might use Yellow for this and other problems.

>    B8ZS within an ESF allows bi-polar violations within an 
>ESF frame to identify the all zeroes octet by inserting two marks
>with the same polarity within the octet. On non-ESF T-1s, a 
>bi-polar AMI violation is used to indicate the start of a new 
>193 bit non-ESF T-1 frame.

   B8ZS works the same on ESF and non-ESF framing.  No bi-polar violation
identifies framing in either ESF or the older Super Frame (D4) systems.
Framing is a pattern-matching process that examines only "non-violated"
signals.

>Also, in b) aren't many of the channels completely inert with 
>regards to the "inband" robbed-bit signaling? If only three or 
>four channels are affected, then 64kbps DOSBS should work on the
>remaining unaffected channels.

   Sorry - in most cases, robbed-bit signaling occurs in every channel
of a DS1 if it occurs at all.

>   This would be OK unless two DOSBS
>channels are adjacent and both want to send all zeroes, which 
>would cause the yellow alarm. This, I think, is the reason so 
>many carriers don't like DOSBS, not because it deprives them of
>charging more for ISDN data calls.

   Most TELCo equipment will 'fix' your all-zeroes data without any alarm.
Yellow alarm is an indication from the far end that it has lost framing
or is not seeing any pulses.  Some equipment adds other reasons for Yellow,
but ZCS is unlikely to be one of them, particularly from user-controlled
DS0 streams.

Al Varney - just my opinion
Technical Details
Message-ID: <4d92fk$96h@ssbunews.ih.att.com>
Path: arc1-ca.pugleaf.net!ssbunews.ih.att.com!not-for-mail
References: <30DDC4F0.1364@fast.net> <c1a7cb$e2db.1e4@ambra.drcoffsite.com> <4c1q90$n37@mercury.near.net> <NEWTNews.820626346.32539.jrhodes@jrhodespc.nwest.mccaw.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!ssbunews.ih.att.com!not-for-mail
From: varney@ihgp4.ih.att.com (Al Varney)
Newsgroups: comp.dcom.telecom.tech,comp.dcom.isdn
Subject: Re: Please critique: When is a B channel only 56K?
Date: 13 Jan 1996 19:51:16 GMT
Organization: AT&T
Distribution: na
Message-ID: <4d92fk$96h@ssbunews.ih.att.com>
References: <30DDC4F0.1364@fast.net> <c1a7cb$e2db.1e4@ambra.drcoffsite.com> <4c1q90$n37@mercury.near.net> <NEWTNews.820626346.32539.jrhodes@jrhodespc.nwest.mccaw.com>
NNTP-Posting-Host: ihgp4.ih.att.com