Everything Your Parents Told You About ESS Was a Lie

by dalai  (dalai@swbt.net)

Let's say two hypothetical people - we'll call them Mike and Tristan - decide to communicate over a long distance via telephone.  Their calls are routed through the high-tech digital telephone grid of the new millennium and they talk about their favorite topic, procrastination, while enjoying a crisp and noise-free signal.

The systems which make up the network their voices will be routed over have changed dramatically over the years, especially in the long-haul nets.  SS7 and the local offices however have remained surprisingly consistent, at least at theory of operation, their most notable changes being some growth to support modern trends such as residential broadband.

I guess I could just find a piece of software, grep it for strepy(), write a played-out stack overflow exploit for it, and consider myself a hacker.  Why not, everyone else does, it's the trend nowadays.  Nobody actually thinks or does their own thing anymore.  To me at least, that doesn't cut it.  I want more.  So here I am venturing into a topic that has gone without much attention for the last couple of years, telephone switching.  In particular I want to help people get up to speed on the way things are, and to get out of the mentality of the old, misleading telephony materials.

First, some background.  The 5ESS is still in play.  Minus occasional upgrades like the recent major 5ESS-2000 package, it still operates basically the same as it did ten years ago.  Software centric and digital, the switch is the biggest Class-5 in operation.  It is modular in design and certain components can be added to the switch to facilitate the flexibility that may be required by a certain BOC or serving area.  I'm going to talk about ASM, but first some background on AM.

AM/ASM

The Administrative Module is stored in a hospital-blue cabinet, and if you've ever seen an 5ESS up close you know what I'm talking about.  It's just like any other shelf in the cabinet array.  Its purpose is similar to the proverbial ESS control channel of which you've read in old LoD texts.  The AM allows for centralization of administrative input for common configuration and operational tasks.  Many aspects of the switch can be controlled by this module.

You can connect things to the AM, and that's the foundation for the creation of the ASM.  The ASM is a rack-mounted Sun, at least in any configuration that I've seen.  Suns are amazing creatures in the telecom industry.  You can even throw an SS7 stack on them nowadays.  Can you wheel your UltraSPARC into your CO and emulate an SS7 node?  I don't see why not.  Would it make you an asshole?  Yea.  But most of you don't care.

Anyways, the ASM connects to the AM of an ESS and is used for many things.  For instance, software driven AMADNS runs via ASM.  A lot of the things you think that you know about have already been replaced by applications running with the aid of the AM or ASM through AM.  Telephony is a dynamic business folks.  Trash your yellowed 1980s textfile printouts and order some AT&T manuals.

ASM stands for Administrative Services Module.  It connects directly to the AM via a bi-directional serial channel.  The module itself is typically a Netra T-1120 "telco server" by Sun.  It runs Solaris like any well-behaved Sun product.  Thanks to Paul Rixon for dirt on the Netra.

The system obviously has its own IP stack and connects to a proprietary local point of control network for regional switches, as well as a much larger network for software updates.  It openly utilizes FTP and Telnet for administrative tasks.  UUCP is used to some degree.  ASMs are connected to a centralized point.  This point may control several 5ESSes.  That point is firewalled and connected VPN to another network for a little something called RSD.

The Remote Software Delivery system is there to speed up the process of switch software updates.  Not necessarily just the software that drives the switch, more like the enhancements that are sent out on disk by Lucent periodically throughout the year.  The claim is that RSD can reduce time to service for new features by half.  The ASM plays a major role in the update.

I mentioned that ASMs are connected to "another network" for RSD.  The ASM takes the in-core switch and merges it with the update, and then copies it back to the ESS.  The quickest way to get a software package onto ASM is to download it directly from the developers.  Lucent maintains a "feature server," called the Software Change Administration and Notification System (SCANS).  SCANS will be connected via VPN to either a centralized server for a group of switches, after which the clients can grab from this server, or the switches can connect directly to SCANS itself.  In case a switch tech forgets how to use UUCP, SCANS accepts dial-in downloads.

Since it is handled in the AM, ASM can take over the recent change duties as well.  RCMAC is usually handled in the AM nowadays, and since ASM was created to simplify and expand the AM's duties, it was ported over.  There's a nice little user friendly system to administer RC now.  It also makes for a nice centralization of Recent Change administration for your OSS group.  So you see that theoretically if nothing ever needs to be troubleshot and no new circuits appear, we don't need anyone in the switch office at all.  That's where RNMS comes in... but I'll save that for another day.

SS7 and FACS

The current ESS software version (generic) is 5E15.  This version provides some SS7 enhancements which were not available in previous versions (although the software has always worked with SS7).  A package now available to most switches is the "7R/E Packet Driver."  Using this system developed by Lucent, POTS calls destined for an ISP are trunked away from the voice switch and towards the ISP using a dedicated backbone.  For once the telco makes a move for the service providers and not the other way around.

SS7 is all grown up.  It's a full fledged protocol with its own layer model and everything.  AT&T has created something called the Customer Routing Point (CRP), which works basically like a customer premise's IP router, except it acts on WATS numbers.  Where is this all leading?  Routers that switch SS7 on the same wire as IP and voice?  Equipment that conditions or switches without sticking to a specific group of protocols?  Centralization of all public networks?  Pretty cool stuff.  You can dig Trauma Inc.'s nifty SS7 project, SevenStack (SS7 stack for x86).

What about the old systems you remember reading about?  FACS is still used for handling service orders.  The office where the entries are entered into FACS is connected to each of its client switching offices by a network which I know nothing about.  What I do know is that FACS will propagate the orders to each switch that needs to be involved with the circuit maintenance or activation.

RCMAC and order processing haven't changed much.  The bureaus you're familiar with are for the most part still intact and operating the same.  Bell is really cultic and Telcordia (Bellcore) a dog chasing its tail.  They'd all prefer things to stay exactly the way they are.  It can take a long time to move up to switch tech, if you know what I mean.

Broadband and Security

POTS outside plant hasn't changed much minus the pair gain and other loop concentrators.  What has changed is the way people connect to data networks.  Residential broadband is huge these days.  To facilitate the large amounts of people who desire things like DSL, the telco wires up a Fiber Central Office Terminal (FCOT) in some or every area office.  The FCOT pushes an OC link to whichever serving area where it will connect with a Remote Data Terminal.  The RDT can feed out ISDN or DSL or whatever.  This setup works similar to its copper equivalent in that lines are sent out in bulk and gradually stripped down to individual "pairs."

In some Lucent setups there is a system called ACA, Automatic Circuit Assurance.  The job of this system is to spot potentially fraudulent calls.  That is, calls which are extremely long in duration, or many calls of short duration in succession.  The time limits imposed on either short or long calls are managed by the individual switch.  If when the switch notices the ACA alarm the call is still active, the call will be monitored using "Busy Verification."

If you are dropped in on by a Bell tech using Busy Verification you will be notified with a tone.  ACA is a feature used mostly on large PBX setups and is accompanied by the similar system CMS.  Are you curious about tracing?  You're traced the second you pick up the handset, plain and simple.  No matter how careful you are, somewhere there's an office with a record of your call.

Dalai's Final Thoughts

Jerry Springer has it, why not me?

This has been made possible by Chick-O-Stick and lots of Mountain Dew.  Programming Winsock Trojan's might have been cool in the 1990s, but let's try to grow up in the new millennium.

There's a lot more out there in telecom than you think, but no one's going to write it all down for you.  Learning to research productively is a hack in itself.

If you enjoyed this you'll probably like what I've set up here: www.swbt.net/~dalai/bell/bell.html