Article View: comp.dcom.telecom.tech
Article #47Re: Please critique: When is a B channel only 56K?
From: Al Varney
Date: Sat, 13 Jan 1996 19:51
Date: Sat, 13 Jan 1996 19:51
101 lines
5847 bytes
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-mailReferences:
<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