History
The 5ESS came to market as the Western Electric No. 5 ESS. It commenced service in Seneca, Illinois on March 25, 1982, and was destined to replace the Number One Electronic Switching System (1ESS and 1AESS) and other electromechanical systems in the 1980s and 1990s. The 5ESS was also used as a Class-4 telephone switch or as a hybrid Class 4/Class 5 switch in markets too small for the 4ESS. Approximately half of all US central offices are served by 5ESS switches. The 5ESS was also exported, and manufactured outside the US under license.[2]
The 5ESS–2000 version, introduced in the 1990s, increased the capacity of the switching module (SM), with more peripheral modules and more optical links per SM to the communications module (CM). A follow-on version, the 5ESS–R/E, was in development during the late 1990s but did not reach market. Another version was the 5E–XC.[citation needed]
The 5ESS technology was transferred to the AT&T Network Systems division upon the 1984 breakup of the Bell System. The division was divested by AT&T in 1996 as Lucent Technologies,[3] and after becoming Alcatel-Lucent in 2006,[4] it was acquired by Nokia in 2016.[5]
The 5ESS switch is still in widespread use in the public switched telephone network (PSTN) in the United States and elsewhere, but they are being replaced with more modern packet switching systems. 5ESS switches in service in 2021 also included several operated by the United States Navy.[6]
Architecture
The 5ESS switch has three main types of modules: the Administrative Module (AM) contains the central computers; the Communications Module (CM) is the central time-divided switch of the system; and the Switching Module (SM) makes up the majority of the equipment in most exchanges. The SM performs multiplexing, analog and digital coding, and other work to interface with external equipment. Each has a controller, a small computer with duplicated CPUs and memories, like most common equipment of the exchange, for redundancy. Distributed systems lessen the load on the Central Administrative Module (AM) or main computer.[citation needed]
Power for all circuitry is distributed as –48 VDC (nominal), and converted locally to logic levels or telephone signals.[citation needed]
Switching Module
Each Switching Module (SM) handles several hundred to a few thousand telephone lines or several hundred trunks or combination thereof. Each has its own processors, also called Module Controllers, which perform most call handling processes, using their own memory boards. Originally the peripheral processors were to be Intel 8086, but those proved inadequate and the system was introduced with Motorola 68000 series processors. The name of the cabinet that houses this equipment was changed at the same time from Interface Module to Switching Module.[citation needed]
Peripheral units are on shelves in the SM. In most exchanges the majority are Line Units (LU) and Digital Line Trunk Units (DLTU). Each SM has Local Digital Service Units (LDSU) to provide various services to lines and trunks in the SM, including tone generation and detection. Global Digital Service Units (GDSU) provide less-frequently used services to the entire exchange. The Time Slot Interchanger (TSI) in the SM uses random-access memory to delay each speech sample to fit into a time slot which will carry its call through the exchange to another or, in some cases, the same SM.
T-carrier spans are terminated, originally one per card but in later models usually two, in Digital Line Trunk Units (DLTU) which concentrate their DS0 channels into the TSI. These may serve either interoffice trunks or, using Integrated Subscriber Loop Carrier, subscriber lines. Higher-capacity DS3 signals can also have their DS0 signals switched in Digital Network Unit SONET (DNUS) units, without demultiplexing them into DS1. Newer SM's have DNUS (DS3) and Optical OIU interfaces (OC12) with a large amount of capacity.
SMs have Dual Link Interface (DLI) cards to connect them by multi-mode optical fibers to the Communications Modules for time-divided switching to other SMs. These links may be short, for example within the same building, or may connect to SMs in remote locations. Calls among the lines and trunks of a particular SM needn't go through CM, and an SM located remotely can act as distributed switching, administered from the central AM. Each SM has two Module Controller/Time Slot Interchange (MCTSI) circuits for redundancy.
In contrast to Nortel's DMS-100 which uses individual line cards with a codec, most lines are on two-stage analog space-division concentrators or Line Units, which connect as many as 512 lines, as needed, to the 8 Channel cards that each contain 8 codecs, and to high-level service circuits for ringing and testing. Both stages of concentration are included on the same GDX (Gated Diode Access) board. Each GDX board serves 32 lines, 16 A links and 32 B links. Limited availability saves money with incompletely filled matrixes. The Line Unit can have up to 16 GDX boards connecting to the channel boards by shared B links, but in offices with heavier traffic for lines a lesser number of GDX boards are equipped.
ISDN lines are served by individual line cards in an ISLU (Integrated Services Line Unit).
Administrative Module
The Administrative Module (AM) is a dual-processor mini main frame computer of the AT&T 3B series, running UNIX-RTR. AM contains the hard drives and tape drives used to load and backup the central and peripheral processor software and translations. Disk drives were originally several 300 megabyte SMD multi-platter units in a separate frame. Now they consist of several redundant multi-gigabyte SCSI drives that each reside on a card. Tape drives were originally half inch open reel at 6250 bits per inch, which were replaced in the early 1990s with 4 mm Digital Audio Tape cassettes.
The Administrative Module is built on the 3B21D platform and is used to load software to the many microprocessors throughout the switch and to provide high speed control functions. It provides messaging and interface to control terminals. The AM of a 5ESS consists of the 3B20x or 3B21D processor unit, including I/O, disks, and tape drive units. Once the 3B21D has loaded the software into the 5ESS and the switch is activated, packet switching takes place without further action by the 3B21D, except for billing functions requiring records to be transferred to disk for storage. Because the processor has duplex hardware, one active side, and one standby side, a failure of one side of the processor will not necessarily result in a loss of switching.
Communication Module
The Communications Module (CM) forms the central time switch of the exchange. 5ESS uses a time-space-time (TST) topology in which the Time-Slot-Interchangers (TSI) in the Switching Modules assign each phone call to a time slot for routing through the CM.
CMs perform time-divided switching and are provided in pairs; each module (cabinet) belonging to Office Network and Timing Complex (ONTC) 0 or 1, roughly corresponding to the switch planes of other designs. Each SM has four optical fiber links, two connecting to a CM belonging to ONTC 0 and two to ONTC 1. Each optical link consists of two multimode optical fibers with ST connectors to plug into transceivers plugged into backplane wiring at each end. CMs receive time-multiplexed signals on the receive fiber and send them to the appropriate destination SM on the send fiber.
Very Compact Digital Exchange
The Very Compact Digital Exchange (VCDX) was developed with the 5ESS-2000, and marketed to mostly non-Bell telephone companies as an inexpensive, effective way to offer ISDN and other digital services in an analog switching center. This avoided the capital expense of retrofitting the entire analog switch into a digital one to serve all of the switch's lines when many wouldn't require it and would remain POTS lines.
An example would be the (former) GTE/Verizon Class-5 telephone switch, the GTD-5 EAX. Like the Western Electric 1ESS/1AESS, it served mostly medium to large wire centers.
The standalone VCDX was also capable of serving as a switch for very small wire centers (a CDX- Community dial office) of fewer than ~400 lines. However, for small wire centers, 400-4000 lines, that function was usually served by RSM's, a 5ESS "Remote SM", ORM's or Wired ORM's.
The RSM is controlled by T1 lines connected to a DLTU unit. The first 2 T1's are the control of the RSM and are necessary for any Recent Changes to take place. RSM's can have up to 10 T1's. There can be multiple RSM's in an office. An ORM can be fed via direct fiber or via coax thus called Wired ORM's. An RSM or ORM can have many of the same peripheral units that are part of a full 5ESS switch. An RSM has a limited distance and can serve parts of a larger metro area or rural offices. An ORM or wired ORM can be anywhere technically, and preferred over the RSM once the ORM became available. Both the RSM and ORM is often used as a Class-5 wire center for small to medium towns hosted from a 5ESS located in a larger city. The Wired ORM is connected via coax from a MUX unit and fed to a TRCU which converts the coax to connection to the DLI, There was also a two-mile ORM that was used when an office was broken out or took an area from another office. The distance on this was 2 miles from a host office and fed direct via fiber. As with any SM, the size is dictated by the number of time slots needed for each peripheral unit. ORM's are linked with DS3, RSM's are linked with T1 lines.
The VCDX was also used as a large private branch exchange (PBX).
Small communities of less than 400 lines or so were also provided with SLC-96 units or Anymedia units.
The standalone VCDX has a single Switching Module, and no Communications Module. Its Sun Microsystems SPARC workstation runs the UNIX-based Solaris (operating system) that executes a 3B20/21D processor MERT OS emulation system, acting as the VCDX's Administrative Module. The VCDX uses the CO's normal telephone power sources (which are very large uninterruptible power supplies), and has connections to the CO Digital cross connect system for T1 access, etc.
Signaling
The 5ESS has two different signaling architectures: Common Network Interface (CNI) Ring and Packet Switching Unit (PSU)-based SS7 Signaling.
Software
The development effort for 5ESS required five thousand employees, producing 100 million lines of system source code, mostly in the C language, with 100 million lines of header files and makefiles. Evolution of the system took place over 20 years, while three releases were often being developed simultaneously, each taking about three years to complete. The 5ESS was originally U.S.-only and the international sales resulted in a complete development system and team, in parallel to the U.S. version.
The development systems were Unix-based mainframe systems. There were around 15 of these systems active at the peak. There were development machines, simulator machines, and build machines, etc. Developers' desktops were multi-window terminals (versions of the Blit developed by Bell Labs) until the mid 1990s, when Sun workstations were deployed. Developers continued to login into the servers for their work, using X11 on their workstations as a multi-window environment.
Source code management was based on SCCS and utilized "#feature" lines to separate source code between releases, between features specific to US or Intl, and the like. Customisation around the vi and Emacs text editors allowed developers to work with the appropriate view of a file, hiding the parts that were not applicable to their current project.
The change request system used the SCCS MR to create named change sets, tied into the IMR (initial modification request) system which had purely numeric identifiers. An MR name was created with subsystem prefix, IMR number, MR sequence characters, and a character for the release or "load". So, for the gr (generic retrofit) subsystem, the first MR created for the 2371242 IMR, destined for the 'F' load, would be gr2371242aF.
The build system used a simple mechanism of build configuration that would cause makefile generation to occur. The system always built everything, but used checksum results to decide if a file had actually changed, before updating the build output directory tree. This provided a huge reduction in build time when a core library or header was being edited. A developer could add values to an enum, but if that did not change the build output, then subsequent dependencies on that output would not have to be relinked or libraries built.
