[TUHS] Known Specimens of Pre-5ESS UNIX Telephone Switching Software?

Brad Spencer brad at anduin.eldar.org
Tue Sep 26 21:28:19 AEST 2023


Andrew Hume <andrew at humeweb.com> writes:

> i’m sure there are standing references to all this. but as i recall,
> the 5ESS was a more or less local switching system.
>
> the guts of the long distance network were embedded in the (roughly) 140 1ESS’s. they ran
> a completely separate (and substantially older) code that supported things like SS7 (signaling code
> that was NOT embedded in the voice channel). the 1ESS was a complex piece of equipment.
>
> my interaction with this was tangential. throughout the 1980-90s, i had a tight grip on how
> accounting messages were handled within AT&T and wrote some C code that handled a
> a transition from one level of the standard software to another level. and that code ran inside
> the 1ESS.
>
> but this was a long time ago.
>
>> On Sep 25, 2023, at 6:24 PM, segaloco via TUHS <tuhs at tuhs.org> wrote:
>> 
>> Hello, my studies lately bring me to the question: Are there any extant examples of telephone switching software, built on UNIX, from the various parts of the Bell System prior to the introduction of the 5ESS and 3B20D?  My focus veers earlier as some 5ESS/3B20D/DMERT technology is still in active use, that sleeping dragon can lie.
>> 
>> What's gotten me curious is reading about 1ESS in a BSTJ volume I picked up, noting the particulars on how previous concerns of manual and electro-mechanical systems were abstracted into software.  Even without surviving examples, were previous systems such as the 1ESS central control ever ported to or considered for porting to UNIX, or was the hardware interface to the telco lines too specific to consider a future swap-out with, say, a PDP11 running arbitrary software?  Columbus's SCCS (switching, not source code) also comes to mind, although all I know that survives of that is the CB-UNIX 2.3 manual descriptions of bits and pieces.
>> 
>> By the way, it's funny, I have UNIX to thank for my current experiments with telephones and other signalling stuff, what with making me study the Bell System more generally.  It's starting to come full circle in that I want to take a crack at reading dialing, at least pulse, into some sort of software abstraction on a SBC that can, among other things, provide a switching service on top of a UNIX-like kernel.  I don't know what I'd do with such a thing other than assign work conference call rooms their own phone numbers to dial with a telephone on a serial line...but if I can even get that far I'd call it a success.  One less dependency on the mobile...
>> 
>> - Matt G.


So...  I am speaking from a single point of view about stuff I worked on
a very long time ago....

On the operations support system I worked on at AT&T/Lucent...  we
supported all manor of switches, all of those made by AT&T/Lucent and a
whole lot made by other companies.  This is what I recall...

I believe that the 1A had left the building and no longer existed in any
installed base in the US when I started, although we supported it still
in our software because of the pain of ripping it out.  The 1E did exist
in some numbers (I may have these backwards, BTW... it might have been
the 1A that existed and the 1E had crossed the rainbow bridge).  I do
recall that either the 1A or 1E had a lot of features, but it may have
been more of a case of it just being around a long time and was infected
with warts.  The work horses, however, were the 4ESS and the 5ESS.  The
4E did the long haul work and was often configured in a tandem set up
(that was the term used, Tandem, which meant something specific at the
time).  The 4E was also a very large monster of a device... taking up
pretty much an entire floor of a building.  The software in it was very
old with lots of add on sub-devices to provide new ability (our product
used some of those sub-devices).  Those sub-devices might have run their
own operating systems and could have been computers all by themselves...
that is, there were multiple glued together computers to get the 4E
effect.  The 5E was a lot cleaner and much smaller.  It also had some
sub-device stuff going on but nothing like what the 4E had.  I do seem
to recall that the 5E runs some version of Unix, at least on part of the
device, but I don't remember if the main switching engine did, however
(I suspect not, BTW).  I am almost 100% sure that the 4E did not run
Unix on the main switching engine, but it would not surprise me that it
found its way into it somewhere or other (probably in multiple places
given how large the device was).

The 5E and 4E may have started out life with particular roles, but this
wasn't very strict.  That is it was completely ok for a 5E to do long
haul work if so configured and it was very possible for a 4E to
terminate a call.  There was a great deal of flexibility present.  AT&T
long wire was a bit of a different place with respect to the 4E..  I
seem to remember that at the time I was there they had something like
800 4E configured to do long distance service in the US.  At least the
traffic management part was managed by a set of Amdauls (using Unix as
the operating system I believe) running an operation system product that
was very much related to the one I worked on...  simular internals for
example and in my early days we all sat in the same group.

The product I worked on also supported the SS7 switches (I say
"switches" here, but that probably isn't exactly what they were.  I also
don't remember their actual names...  STM, maybe??).  I worked with the
SS7 development group on a new operations system interface and during
that conversation they mentioned that the SS7 switch ran a more or less
unmodified Unix Solaris (one would assume on a Sparc).  They also
mentioned that they had performed kernel modifications in the past, but
the cost of maintaining that sort of thing was very high, so they had
moved away from doing that towards a more "push it to userland" way of
thinking.






-- 
Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org


More information about the TUHS mailing list