🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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

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

#40
From: Fred R. Goldstein
Date: Wed, 03 Jan 1996 16:51
48 lines
3110 bytes
In article <NEWTNews.820626346.32539.jrhodes@jrhodespc.nwest.mccaw.com>, 
jrhodes@jrhodespc.nwest.mccaw.com says...

>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. 

A conformant CSU for "AMI" (better known as AMI/ZCS, for Zero Code
Suppression) coding will  NEVER send the 15 zeroes, and WILL insert
a zero if the source doesn't conform.  Thus the alarm means the CSU
is not working or connected -- a disconnected wire looks like a
string of zeroes, no?

>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. 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.

With "inband" robbed-bit signaling, EVERY channel (24 out of 24)
has robbed bits.  In Europe, they don't rob bits, but the US system
takes from EVERY channel.  Hence the "OCUDP" 56 kilobit channel bank
insert, which sets the low-order bit and leaves 7 clear.

>ps. with 64kbps DOSBS using V.120 error correction, would the 
>infrequent "robbed" bits in b) be corrected anyway? Half the 
>robbed bits will match the DOSBS data stream, so a V.120 packet
>would usually get 11 out of 12 octets thru unharmed. How long 
>is a V.120 packet and is there a Hamming code included to 
>correct transmission errors?

V.120 doesn't do error correction, except perhaps via retransmission.
No "Hamming" code is used.  It's based on HDLC and LAPD.  Even
if there were only one AMI/ZCS span, it would lose 1/6 of all octets.
With multiple hops it gets worse.  Thus ANY AMI/ZCS or RBS would
clobber your 64k DOSBS.
-- 
Fred R. Goldstein   k1io   fgoldstein@bbn.com   +1 617 873 3850
Opinions are mine alone; sharing requires permission.
Technical Details
Message-ID: <4cec6n$fm7@mercury.near.net>
Path: arc1-ca.pugleaf.net!mercury.near.net!news
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!mercury.near.net!news
From: fgoldstein@bbn.com (Fred R. Goldstein)
Newsgroups: comp.dcom.telecom.tech,comp.dcom.isdn
Subject: Re: Please critique: When is a B channel only 56K?
Date: 3 Jan 1996 16:51:35 GMT
Organization: Bolt Beranek & Newman Inc.
Message-ID: <4cec6n$fm7@mercury.near.net>
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: isdnip.near.net
Mime-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
X-Newsreader: WinVN 0.99.7