[lug] [OT] WIC T1 or 56k

[carl.wagner at level3.com]

D4, also called SF (Super Frame) has A and B bits for signaling when using
MF or DTMF for signaling.  D4 is composed of 12 frames.  (D4 was a type of
channel bank used in the Bell system)  I have not looked into how D4 works
at the bit level.

ESF (Extended Super Frame) has A, B, C, and D bits for signaling.  I don't
remember
what the C and D bits were used for but the A and B are used normally (in E&M
signaling)
ESF has 24 frames (8 bits / channel * 24 channels + 1 framing bit = 193 bits)
1,544,000mhz/ 193bits = 8000 ESFs/second.  8000 * 8 bits = 64K bits.

ESF robs the low order bit of each channel from frames 6, 12, 18 and 24 when
not 
using clear channel signaling.  Frame 6 = the A bit, 12 = the B bit, etc.

To use a clear channel T1 you need to be running ISDN or SS7 (from a voice T1
perspective,  you may be able to get a clear channel data circuit).

In summary, D4, ESF, AMI, B8ZS have nothing to do with robed bit signaling.
B8ZS does handle strings of 0s more gracefully by inserting 2 bipolar
violations 
in the line and therefore not changing the data stream.

Corrections welcomed,
Carl.




Nate Duehr wrote:
> 
> On Thu, 2002-09-26 at 00:28, TJ Schuler wrote:
> > This is correct. A DS0 by definition in the US is a 64K channel - the
> > difference between 56K and 64K is how the equipment handles the actual zeros
> > and ones on the line. DS-1 lines require no more that 15 "0" bits before a
> > "1" bit being sent. This is a requirement to keep timing on the line
> > correct.
> 
> This is only true on D4 coded spans.  ESF coding on the spans move the
> signaling bits out of band and you can run all the zeros or ones through
> the channels you like.  Well, at least they "kinda" do... they make it
> look to you like all your ones and zeros are there after passing them
> through a "clear" 64K timeslot...
> 
> How it does this is that most ESF spans are configured to also use
> Bit-Eight-Zero-Supression (B8ZS) typically, and the equipment handles
> this for you... yes, the right number of zeros and ones go out on the T1
> line, but the zeros and ones the equipment inverted on the line to
> follow the DS-1 rules are presented to the the DTE equipment properly
> after being run through the algorithm.
> 
> The weird part about routers with internal DS1 interfaces is that each
> manufacturer can choose to fiddle with the alarm and header bits and
> whatnot as they please... allow the user to fiddle or not to fiddle,
> etc.
> 
> So this generic discussion of the line codings may not apply to Cisco
> specifically, as I don't know what they truly do... from what I've seen
> they follow the telco and real-world specs pretty well and usually "just
> work".
> 
> > Anyways one of the ways to do this is to make every 8th bit a "1" and only
> > use the first 7 bits for the data. This is how we get 56K service with DDS.
> 
> Eeeek.  DDS.  I hated troubleshooting those things.
> 
> > The other way to do this is to use a mechanism like B8ZS, which replaces
> > blocks of 8 zeros with the B8ZS code value. So you have a 64k timeslot but a
> > certain amount is overhead, some say it is 56K usable - but it really
> > varies.
> 
> Again, you don't "lose" anything with B8ZS.  The equipment inverts
> certain ones and zeros on the physical line to match the rules, but
> presents you a full 64K pipe that acts "normally" when this is done
> properly.
> 
> > I like to use the example of videoconferencing of the WAN. In the old days
> > with H.320 we used to channalize a T1 and use certain timeslots for data and
> > certain for video.  Now this worked fine and looked alright the problem was
> > that you couldn't ever use the "video" timeslots for data if they were not
> > being utilized. This is similar to the 7/8 method used in DDS. Now with
> > H.323 and Video over IP we can dynamically allocate the bandwidth to the
> > video over the data timeslots and reclaim that bandwidth when not in
> > use -works just as good if not better and a lot more flexible.
> 
> Back then, this was more a function of the way the timeslots were
> allocated to DTE equipment than their suitability to carry different
> types of data.  There were only VERY expensive ways to share time-slots
> on DS-1's prior to everyone just jumping up a stack level and putting
> everything over IP.  You could easily have purchased a monster Tadiran
> or other manufacturer's mux that could be reconfigured as needed when
> the video wasn't up, and you could also have scripted those changes, but
> what a PAIN that would have been...
> 
> Most modern "we're using X amount of bandwidth for overhead" problems
> are either...
> a) The span is D4/AMI.
> b) The protocol RIDING on the span has overhead or signaling that has to
> be accounted for in design of the network.
> 
> Now I never had to work on them, but for the curious... the reasoning
> behind all these "there must be a certain number of ones and a certain
> number of zeros" on a T1 circuit stems from OLD (very old, mostly long
> gone except in rural areas where the Bell is too cheap to replace them)
> digital repeaters that were line-powered... if you never had a voltage
> swing... (too many zeros or too many ones all in a row), the thing would
> lose power... and it would have to be kickstarted by some poor guy with
> a battery pack in a manhole -- also the rules relate back to when
> Phase-Locked-Loops weren't all that great at staying locked... hard to
> keep a synchronous circuit going if the PLL's are unlocking all the time
> and re-synching.
> 
> Nate
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug