TCPmag.com for Cisco Internetworking Professionals Thursday, September 02, 2010  
Search:
Advanced Search        
-- advertisement --
  Resources
  Articles
  Community
.. Home .. Q & A .. Q & A Answers


 
print article printable format
e-mail article e-mail to a friend
comment on the newscomment on article

More Q & A
read... Video Killed the Data Stream
read... Distance Training with IS-IS
read... Theory, Reality and Total T-1 Bandwidth
read... 'Area 257' De-Classified
read... Follow That Packet!
read... Back-to-Back Connections and ADSL
read... Split-Scope DHCP Servers
read... VRRP Implementation

Q & A Archive


Q & A

Why B8ZS Isn't The Way To Go in Convergence

by Scott Morris

Question:

March 30, 2004

Scott,

If one has to provide circuits for voice, data and video, then B8ZS is the way to go. You get an additional 192 bits. If one is only concerned with voice then AMI is the way to go. Normally, AMI is cheaper than B8ZS. One other item that plays an important part is in-band signaling (CAS) or out- band signaling (CCS).

My two cents.

Thanks,
-- Jake
CCNA, 32 years of telecommunication experience

Answer:

Jake,

No offense intended, but I don’t really think the difference is quite that clear cut -- or necessarily that accurate in the signaling methodology!

B8ZS represents a different electrical method of the 0/1 signaling, which is most certainly important in data lines where the transmission may actually require a long string of 0s being sent (represents loss of signal in AMI signaling). The difference in bits actually comes from the framing format (D4/SF vs. ESF).

I’m interested in why you’re looking for AMI to be the preferred deployment for voice lines. With an AMI encoded T1, where we often see Robbed Bit Signaling used, we are actually only transmitting 56k of data per channel. Now, being that voice is sampled in 8 bit chunks at a rate of 8,000 times per second, that means 64k of voice sampling is occurring (and has been for 40-plus years now!). So with AMI we’re losing 8k of that information in order to handle extra synchronization information to avoid the shortcomings of the electrical signaling methods being deployed. PCM can handle losing some information because it’s fast enough that we mere humans don’t notice it.

Both D4 and ESF frames utilize a single bit out of every channel each sixth frame for signaling. D4 uses 12 frames per superframe, giving the ability to use A and B bits for signaling. Other bits are used for synchronization and verification of the frame (referred to as robbed bit, kicking things back to 56k instead of 64k). In an ESF extended superframe, the same bit in every sixth frame is taken, but there are 24 frames per superframe, giving an A, B, C and D bit for signaling and the creation of a CRC within the use of the same number of bits. Think of this as being twice as efficient with the same number of missing “planned” bits.

-- advertisement (story continued below) --

Not requiring separate synchronization and verification, the extra 8k of bits used becomes our interpretation of a “clear channel” signal -- or an otherwise unimpaired representation of exactly the same bits that started a signal.

The only argument that I can think of for a preference of this encoding for voice lines would be the “enhanced” stability from the extra synchronization capabilities. However, in today’s network deployments, the quality of lines and repeater equipment has significantly improved over what things were 10, 20 or 30 years ago. So I really don’t think that’s an issue in most areas. If you are in a location with relatively old equipment, you may have a different outlook though. However, for most people’s deployment, older robbed-bit signaling lines are actually not very pleasant to do things like modem communication over.

As for which is cheaper, again, I think the economics of newer equipment makes AMI an afterthought in many areas. At least that has been my experience in deploying T-1 lines across the U.S.

Looking to the CAS vs. CCS, this part confuses me with what we are mentioning here. Both AMI/D4 and B8ZS/ESF utilize a CAS method of signaling. Bits are taken within the framing to handle all of the line usage. T-1 signaling has been like this for many, many years.

In an ISDN PRI deployment (or an E-1 if you’re in Europe), we have the concept of CCS or Common Channel Signaling. In these deployments, one of the 24 channels (or one of 32 if E-1) is dedicated to signaling and control information. In order to accomplish this in ISDN PRI, the T-1 carrying the information MUST be running B8ZS/ESF coding and framing structures.

We have other extended versions of this deployed along with ISDN PRI lines. NFAS, or Non-Facility Associated Signaling, allows a single D-channel to carry all of the signaling information for multiple ISDN PRI lines (up to four). So instead of the 23:1 ratio of bearer channels to a control channel with each PRI, we now can maintain a 95:1 ratio over the span of bearer channels in four PRI lines. You may require a backup D-channel in this deployment model though, but 94:2 is still pretty good!

There are many interesting sites out there with information about T-1s and the different signaling methods used. A few of them are listed here, with links to PDFs to break down a number of the technical items I’ve discussed.

As the quality of facilities increases, the quality of transmission capabilities should get better along with it. As we move into the increasingly digital world, it seems to become less and less often that any T-1 deployment is for “voice only.” The convergence gets us!

http://www.pulsewan.com/data101/cas.pdf
http://www.patton.com/support/pdf/t1-e1-pri_tech_over_lo-res.pdf
http://pdfserv.maxim-ic.com/en/an/telecomFAQ.pdf

-- Scott

Send your toughest CCIE-level technical questions to editor@tcpmag.com.
Scott Morris, quadruple CCIE, JNCIE and all-around uber-geek, can often be seen traveling around the world consulting and delivering CCIE training. He recently accepted a new Senior CCIE Instructor position with Internetwork Expert! For more information on him check out http://www.uber-geek.net or for CCIE training check out http://www.internetworkexpert.com. You can contact Scott via editor@tcpmag.com. You can contact Scott about "Why B8ZS Isn't The Way To Go in Convergence" at editor@tcpmag.com.

Current TCPmag.com user comments for "Why B8ZS Isn't The Way To Go in Convergence"
No postings yet.
Post your comment about " Why B8ZS Isn't The Way To Go in Convergence" here:
Name: (optional)
Location: (optional)
E-mail Address: (optional)
Comments:  
 
top







home | certification basics | features | exams | exam reviews | salary surveys
forums | link state update | news | q & a | article archive | tech library webcasts | Rss Feeds from TCPmag.com
Application Development Trends | Campus Technology | CertCities.com | The Data Warehousing Institute
E-Gov | EduHound | ENTmag.com | Enterprise Systems | Federal Computer Week | FTPOnline.com | Government Health IT
IT Compliance Institute | MCPmag.com | Recharger | Redmond Developer News | Redmond
Redmond Channel Partner | Redmond Events | Redmond Report | T.H.E. Journal | TechMentor Conferences
Virtualization Review | Visual Studio Magazine | VSLive!
Free Print or Digital Subscriptions: Redmond | Redmond Channel Partner | Redmond Developer News
Virtualization Review | Visual Studio Magazine
Copyright 1996-2009 1105 Media, Inc. See our Privacy Policy.
1105 Redmond Media Group