Background
for Telephone Switching
2nd Edition (Revised and Expanded)
Chapter 2:
Data Processing Functions
OUTLINE
OBJECTIVES: The
objectives of this chapter are
-
to discuss both new and traditional functions required to
control and administer a telephone switch, and
-
to show how readily these functions can be implemented through
the use of the computer control which they were largely
responsible for bringing about.
PREVIEW QUESTIONS:
As you read, watch for he answers to the
following important questions:
1. How does computer control simplify switching system
operation?
2. How were all these functions carfried out before computers?
DATA PROCESSING
FUNCTIONS
The
telephone is older than electrical power systems, the automobile and
the airplane. Automatic switching is slightly younger, dating from
Strowger's cutover in LaPorte, Indiana, in 1892. Strowger invented
the SXS switch in an effort to eliminate the load-sharing common
control of the day, the telephone operator, and succeeded rather
well; almost all further developments in automatic switching have
continued to expand the ability of the machine to emulate the human.
Local and long distance dialing, automatic billing (AMA), and
automatic line insulation testing (ALIT) are now over 40 years old;
more exotic functions such as voice mail, automated PBX attendant,
synthesized and recorded announcements and responses are already
commonplace, and practical voice recognition and security
identification are just around the corner. Indeed, it is hard to
imagine any telephone function that machines haven't already
attempted, one way or another.
When
some things are done before their time, however, they can only be
accomplished with great ingenuity and a variety of hardware-specific
limitations which become part of the way of life of their partisans.
As a result, radical new approaches, which make a lifetime of skill,
training and hard work suddenly irrelevant, are not always met with
enthusiasm. Stored program control is perhaps the principal example
of such a new approach. For outside observers, it is hard to be
sympathetic; computers do certain things so easily, directly and
inexpensively that any other approach seems folly. But needs existed
and had to be met long before there were computers.
Looking back through the literature of telephone switching, we see
many wonderful, and now unnecessary, approaches which have been
devised to count dial pulses and store telephone numbers, for
instance, or to translate dialed numbers into route codes. We must
stand in awe when confronted with such wonders, and heave a sigh of
relief that nothing of the sort will ever have to be developed
again. This chapter expands in some detail certain telephone
functions introduced in Chapter 1 which best illustrate the
application of computers to communication.
STORAGE
A
great variety of information must be stored, one way or another, in
a telephone switch. Some is constantly changing: dialed digits,
circuits in use, etc. We can characterize this as per-call
information. Then, there is information that changes at a much
slower rate; class-mark information, hunt-group and pick-up group
membership, and translation tables. We can think of this as
per-circuit information. Finally, there is information that is
almost fixed: the basic programs that control the operation of the
system as a whole. Clearly, this is per-system information.
Some
systems are designed around RAM (read-write memory) for per-call
information, PROM (programmable read-only memory) for per-line
information, and ROM (read only memory) for the program. Having
non-volatile memory for things that don't very often change provides
a level of reliability that can be quite helpful. Even in earlier
hardware, this approach was followed: AT&T's 1ESS originally used
core-like memory for per-call information, but had a memory based on
permanent magnets for the program; an earlier field trial used a
cathode-ray-tube volatile memory with a program memory based on
photographic storage.
Per call information
The
called number is probably the most important of the per-call
information to be stored because without it, a telephone connection
cannot be set up. Further, if the call goes beyond the local area,
the called number is needed for the billing record. All automatic
systems store digits dialed or keyed in by the customer. Many
approaches have been used: SXS stored digits in the positions of the
switches making a connection, while electromechanical common control
systems used relay groups, reed relay packages and crossbar-switch
verticals. Such approaches have a major disadvantage: a lot of
hardware is involved, and it has to be augmented and/or rewired to
accommodate numbering plan changes.
A
switching system can expect to receive anywhere from 1 to 20 or more
digits when a customer dials a call, depending on the type of call
and its ultimate destination. With computer control, memory is
inexpensive; it can be made available in large quantities and, more
important, it can be reorganized fairly easily by changing the
program rather than the hardware. However, inexpensive memory allows
the luxury of making call registers larger than might seem to be
needed initially to allow for future developments. And as we will
see, a register storing control information for a call must have
space for a great deal more than just the called number.
In
systems using the call-back principle, which includes all electronic
switches and most non-SXS lectromechanical systems built since 1970,
the callING line's equipment number (cabinet, shelf, card and port
on card, for instance), must also be stored in the call register.
This allows the switch, after it drops the connection to the
signaling detector, to find the calling line for a new connection to
the called party or trunk. A translation of the equipment number to
obtain the calling directory number for billing provides an
additional item for the call register, along with the calling line's
class of service, needed to identify signaling and features.
In
electromechanical systems where the call information was actually
stored in the signaling detector (originating register), the
accumulated information had to be moved to some other point (an
outgoing sender) to continue processing the call. With the coming of
stored program control, where the call record is kept in system
memory, separate from the signaling detector, there is no need to
move the call information from one register to another; the register
can be set up once per call to handle dialing, call set-up, answer
and hang-up supervision. By storing answer and hang-up time in the
call register, a complete billing record is available by the time
the call is over. It is then written to magnetic tape or a hard or
floppy disk for later processing.
Most
of the information in a billing record must be obtained and stored,
at least momentarily, to enable the system to set up the connection.
It took a number of years for the designers of competitive PBXs
after the Carterfone decision to realize they could respond to their
customers' desires and accumulate this information profitably rather
than throw it away.
Although only completed call records are used for billing,
unanswered or aborted calls tie up system resources. Thus traffic
studies can benefit almost as much from records of incomplete calls
as calls that are successful. The number of signaling detectors, for
instance, is independent of whether or not a call is answered;
sizing the detector group only on the basis of completed calls may
lead to unpleasant surprises. Records of incomplete calls are also
one of the best sources of information for finding troubles within
the switch as well as in connecting facilities.
Originally, call detail in central offices was only recorded for
toll calls. However, as the cost of memory has fallen, usage
sensitive pricing, whether billed in detail or not, is easy to do,
and makes possible "life-line" service at a low monthly cost for
those who don't make many calls or who cannot afford to pay a higher
fee for flat rate service. Further, both PBX and Centrex systems
need call detail for intra-switch and local calls for a variety of
reasons such as studying intra-company work flow and controlling
fraud. Thus call records offer a whole new range of possibilities to
designers who are willing to use them.
Handling dialed digits and other per-call information is not
particularly difficult, but the job cannot be done in a vacuum.
Because much of the per-call information has to be obtained from
other parts of system memory, the organization of that memory must
also be considered.
Per-circuit information: class of service
Each
line and trunk on a switch must be assigned a class of service
(COS), usually made up of "class marks," each of which indicates the
presence or absence of a particular feature or privilege available
to it. During the recording process, "originating" class marks tell
the system what type of signaling to expect (dial pulse, DTMF, MF,
digital, etc.); calling area restrictions; long distance vendor;
physical region for 911 service; priority and secrecy levels
(primarily in military systems, but probably soon to be required in
business systems); special feature indications such as abbreviated
dialing; compatibility code, a feature that the many kinds of data
and image transmission may impose; Centrex customer identity, etc.
During the completing process, "terminating" class-marks include
kinds of sources from which calls will not be accepted, type of
ringing to be used, availability of various features discussed in
Chapter 5 such as camp-on or call waiting, pick-up group membership,
hunt group membership, call forwarding indication, intercept code if
the line is unassigned, etc. Once the call is established, the
modifying process waits for features such as hold, transfer,
consultation and conference, whose availability is defined by
"modifying" class marks.
Trunks, at least those operating in a pre-CCIS mode, also require
class marks. In particular, they may be identified as one way out,
one way in, or two-way; hand shaking protocols such as wink start
and delay dial must be specified along with the kind of signaling to
be transmitted or received (see Chapter 4).
The
coming of common channel signaling and digital long-distance
transmission has given trunks much greater flexibility. Features
such as "call by call service selection" can actually change a
physical facility from one trunk group to another on a per-call
basis. The much greater signaling capability also permits call
record information to accompany the call as it is set up, with
additional information added as needed. For instance, the calling
directory number can be sent along with the called number to support
Calling Number ID, and such "traveling class marks" as the presence
of a satellite hop or echo suppressor in the connection can, at
least in principle, be appended. Length of each trunk (which implies
loss needed for echo control) could be collected and sent to the
distant end so that the correct loss can be inserted at the two-wire
interface.
Along with line and trunk classes of service, routing tables are
needed. The system must examine the called number and the class of
service associated with the calling line so that the proper trunk
can be selected. Even relatively small PBXs often have highly
complex routing tables to take advantage of particular savings from
offerings of different long distance vendors. Within the various
local and long distance public networks, routing tables are rapidly
being moved to the network's associated common channel signaling
system. These signaling systems, with their own data bases, are
taking over the routing functions formerly an integral part of each
switching system. Now it is no longer necessary to set up an
inter-switch connection trunk by trunk; the whole path is found
first, and the participating switches told which trunks to connect
together. In many instances, line busy or ATB can be detected prior
to establishing the connection and the originating switch can be
instructed to return the appropriate call progress tone.
COS
storage in the past usually took the form of system wiring: SXS
lines in a hunt group were on a particular level in a group of
connectors so that a strap placed between two terminals could
activate stepping to the next line when the first was busy. Customer
lines with toll diversion or DTMF signaling (see Chapter 3) might be
lumped together in one line group containing only similar lines.
Trunks expecting MF pulsing might be wired through a special access
switch to a group of MF digit receivers. Obviously, such constraints
imposed limits on the use of equipment, and required manual
intervention when changes had to be made. Perhaps the greatest
advantage of COS storage in system memory is the much greater
flexibility available in the use of the switching system and its
lines and trunks, and the ease with which changes can be effected
from remote administrative centers via data connections or even the
CCIS network itself.
Per-system information: the program.
The
actual program in a switching system requires a great deal of
memory; it includes all the features and functions needed by the
system for both operation and administration, and enables the system
to serve hundreds or even thousands of calls simultaneously. The
availability of inexpensive memory is sometimes a mixed blessing;
not having to fight for every memory word allows programmers to move
ahead much faster, but sometimes leads to duplication that makes
debugging more difficult.
Programs are sometimes classified as "generic" and "building block."
With the former, the entire program is stored in system memory, the
same way in all switches using it, but with only the parts required
by the particular switch activated. A building block program, on the
other hand, contains only those portions of the program that the
particular system actually uses, saving a certain amount of memory
that was, at one time, important.
Generic programs are easier to design, code, test, debug, and train
technicians to support because there is only one program. For
building block programs, each combination provided must be
separately compiled, and then supported over its life by the
manufacturer. A field update, whether to fix a bug or provide a
feature enhancement, need only be done once on a generic program,
but will probably have to be done differently for each version of a
building block program, a high price to pay for saving a few memory
words.
The
part of the program for system maintenance and administration can be
very large, particularly in central offices; further, many parts of
it are needed only on rare occasions. Such program segments are
sometimes stored on a hard disk and loaded into RAM when required,
allowing the RAM to be smaller and relatively uncluttered. In such
instances, the hard disk also provides back-up for per-line
information, and can even store traffic and billing information. The
balance between different kinds of memory gives designers
considerable latitude in developing a system architecture.
The
program directs the system control to monitor all idle lines for
call originations. When an origination is detected, the "recording"
function begins. The line's equipment number is put in a list (or
queue) to which the program will return shortly. When it does, it
establishes call registers for each origination on the list, inserts
the equipment number, and obtains by translation the directory
number along with the calling line's originating class of service.
Based on its COS, each line is associated with the proper kind of
signaling, dial tone is returned, and each call register is assigned
to a new list to which to processor returns at a higher rate to
acquire digits as sent by the caller.
To
enter the "completing" phase of the call, each register with the
calling and called number is reassigned to a list for either
intra-switch calls or calls via trunks to other switches. For an
intra-switch call, the called line's equipment number is obtained by
translation so that its physical location will be known and, using
its terminating class of service, the proper kind of ringing is
applied and ringback tone is returned to the caller. The system then
monitors calls in the "ringing" list for answer by the called party
and abandon by the caller. When the called party responds, the talk
path through the matrix is established and answer time from the
system clock is stored in the call register which is then assigned
to a "modifying" list to detect hangup or feature requests.
The
procedure is fairly straightforward: the program directs the
processor to each "list" which contains all the calls at a certain
stage. The processor then runs down the list at lightning speed,
doing whatever needs to be done and assigning calls with that
function completed to another list. Because the processor runs at
very high speeds, it can handle many calls simultaneously on a time
sharing basis, returning to each call so often that the calling and
called parties feel that they have the system's full attention.
System administrators, particularly those responsible for PBXs,
often imply that they "reprogram" their systems every so often. This
usually means that they change the tables in the data base which
assign directory numbers to equipment numbers, assign class marks
which identify features or functions for lines or trunks, and make
changes in routing instructions. Changing parameters in these tables
is relatively easy; it should never be confused with changing the
program itself. Modifying a complex program for a multi-user system
such as a PBX or CO switch is a job for specialists.
Although a small PBX or a small CO switch with light traffic can
easily be controlled by a single processor, increasing the number of
lines and/or traffic soon reaches the system's limits. Although
today it is easy enough to substitute a more powerful processor, it
is often more useful to adopt the hierarchical control structure
with a separate "front-end" processor to do the routine, repetitive
work in each port group. The program for such tasks is relatively
simple and can be stored in ROM for reliability and speed, making it
easy for each added line group to bring most of its own processing
capability. By interfacing information to and from a variety of
different sources to a format more useful to the main processor,
front-end processors can greatly increase the latter's efficiency.
Electromechanical common control systems such as 5XBAR worked in the
"interrupt mode," as has been mentioned. With no calls in the
system, it was quiescent; there was no furious action scanning lines
and trunks over and over to detect originations. A phone going off
hook would operate its line relay which would trigger a marker to
make a matrix connection to an originating register. The register
would return dial tone and detect digits, and then call in another
marker to perform a busy test. The marker, aided by a translator,
found the called equipment number. If the called line was free, the
marker then established two new matrix connections, one from the
calling line to an intra-office trunk, and a second from the
intra-office trunk to the called line. The trunk would apply
ringing, trip it on answer, and supervise the call for hang-up. For
an outgoing call, the marker would have to find a suitable trunk,
connect a sender to it, move information from the register to the
sender, tell the sender to outpulse, and connect the calling line to
the trunk. The sender would drop off when finished, leaving the line
to listen for ringback and answer, or busy tone from far away.
There might be anywhere from 10 to several hundred originating
registers in a 5XBAR office, depending on the number of callers
expected to be dialing at once, and up to 12 markers. Stored program
control, by moving most of the complexity of individual circuits
from hardware to software, greatly simplified traditional circuits
such as registers, senders and markers, substituting new circuitry
consisting of standardized memory chips. Further, by taking over the
relationships among individual circuits, stored program went even
further in achieving hardware simplification. Eliminating the
lockout circuitry in 5XBAR, which permitted multiple markers to work
in load sharing, was a major triumph of SPC running on a single
high-speed processor. Today, however, the point has been reached
where multiple processors in load sharing is again becoming
fashionable, and the sophistication of SPC is being put to the test.
TRANSLATION
The
need for flexible numbering within a telephone switch is evident to
everyone who has ever tried to live with a SXS system where
telephone numbers and trunk groups are defined by the operation of
the switches themselves. Quite often, an administrator would find
matrix ports available which couldn't be used because they weren't
consecutive for hunting, or because traffic balancing required them
to be left empty. This lack of flexibility was a major failing of
SXS.
Directory number to equipment number
In
Chapter 1, we saw how the sender in the panel system had to change
the first two decimal digits of a customer's four-digit number into
three non-decimal digits to accommodate the system's 500-output
switches. Although a classic example of directory to equipment
number translation, the fixed relationship between the two numbers
did little to provide flexibility for the system administrator.
5XBAR, developed right after World War II, had much greater
flexibility. Based on register-sender-translator operation, it
needed only the equipment number of a line to connect to it. The
calling line's equipment number was stored in the originating
register to allow it to be called back from a trunk as the
connection was set up, but the system had to use a translator named
a "number group" to convert the called directory number provided by
the user into an equipment number for the other end of the
connection. Automatic Message Accounting (AMA) was developed
simultaneously with 5XBAR; it had a "Dimond Ring" Translator (named
after its inventor and similar in many ways to the magnetic core
memories of a decade later) to convert the equipment number of the
calling line into a directory number which could be used for
billing. If the Dimond Ring translator had been available earlier,
it would have also been used to do the job of the number group.
All
modern telephone switching systems offer more or less complete
flexibility between number dialed by the customer and the equipment
number where the desired facility is located, usually via a look-up
table in computer memory. With such an arrangement, lines and
trunks, even in hunt groups, can be scattered across different
switch modules and relocated at will for both system reliability and
traffic balancing, all the while retaining an identity that is
convenient and useful to the customer. Switch position need not be
dictated by either function or class-mark.
Directory and class-mark information
Class-marks are used to tailor features and calling privileges to
the needs of the individual user, particularly in PBX and Centrex
service where the most extensive list of features is required (see
Chapter 5). Although there are many alternatives, it is reasonable
to associate class of service information with the directory number
which identifies the user rather than with the equipment number
which merely identifies the port on the switching matrix where the
line happens to be connected at the moment. When features are
associated with the directory number, all that has to be changed
when the user moves from one location to another is the equipment
number in the translation, assuming the phone at the new location
and the new line card serving it are the same as those serving the
old.When class-mark information is paired with the directory number,
other related information can be included in the same memory area.
Two items of importance are office records (cabling, etc.) and the
telephone directory itself (in particular, the name of the user and
the location of the phone). Several 1975 vintage PBXs experimented
along these lines, and made name, office location, department, etc.,
available via an administrative terminal. With such an arrangement,
it was impossible for the telephone system and its records to get
"out of phase." In hotel and hospital PBXs, which traditionally have
a very high rate of customer turnover, availability of name, room
number, etc., instantly available at consoles and administrative
terminals, can greatly improve service. In central offices, as well
as PBXs serving housing developments and other large, dispersed
groups of users, having name and address in the data base can
simplify 911 service, call tracing, etc.
There is always an argument, however, about how much information,
not used in normal call processing, should be stored in the switch
control. The alternative is to store such records off-line in a
mainframe or mini-computer or even a PC; this off-line computer can
then be arranged to upload just those parts of its data base that
the switch control actually needs. In this way, records and system
can be kept related without the control's memory being overloaded
with irrelevancies.
By using the telephone system itself to access the off-line
computer, duplicate company data bases can sometimes be
consolidated; note that the telecommunications and
personnel must both store a great deal of similar data which, if
kept in separate data bases, again tends to get out of phase.
Theoretical offices
Sometimes growth projections for an area indicate that a new central
office will be needed in the near future: a housing development,
office or shopping mall might be in the planning stage, for
instance. If a new office code can be established for pioneer
customers in that area on an existing nearby switch even before the
new switch is installed, it is possible to eliminate a number change
when the new switch is cut over.
This
is accomplished with "theoretical" offices which became possible
when translation reached the level offered by 5XBAR. At about 30,000
lines maximum size, 5XBAR could support three office codes; however,
office codes are seldom completely filled, and one machine could
serve several more at a lower level of fill. The 1ESS, with a
maximum of 100,000 lines and much more powerful translation
capability, can assign its lines to a great many more office codes,
as needed. Thus it is quite straightforward to serve a new community
initially from ports available on an existing switch, using a
separate office code. When the new CO is opened, its intended and
already thriving office code is moved from the older machine, lines
and trunks are rerouted, and customer behavior is not upset in any
way. Further, the growth space in the older office then becomes
available for its original purpose.
With
the coming of digital local central offices, this process can be
carried a step further. Digital switching makes remote line groups
economical and practical at distances up to 100 miles or so. Such
remote switching units (RSUs) can be housed in very small buildings,
and can minimize the loop lengths needed to reach customers; with
T-carrier on optical fiber or copper connecting the RSU to the main
switch, the RSU can be controlled and administered from that central
point to provide further economies. If and when the area served by
the RSU has enough growth to warrant a whole CO, the RSU, already in
place, can become part of a new digital switch.
There is, of course, no real need for a separate office code to
serve each community, particularly when only a few thousand lines
are involved; indeed, with all-number-calling (ANC), there is less
identification of office codes with geographical areas than there
once was. An additional advantage of the translation capabilities of
digital switches is that several nearby communities can share an
office code, even if on different RSUs, relieving somewhat the
shortage of office codes. RSUs can also bring the full power of
stored program control to rural areas which, with older
technologies, couldn't afford such advantages in small line sizes.
Pretranslation
Over
the years, there has been a great deal of discussion of "uniform
numbering plans" in the technical and advertising literature.
Although uniform numbering plans have some advantages, it must be
clearly understood that their use is based on a major shortcoming of
all common control switching systems: the need to know when the
customer has finished dialing. In SXS, a variable number of digits
posed no problem because, when the customer dialed the last digit,
the connection reached the called phone. With common control
systems, the customer dials into a register and only later, usually
when all digits are thought to be present, can the system begin to
establish the connection. If the customer always dials the same
number of digits, the telephone system knows when dialing is
complete.
Unfortunately, it is very difficult to construct networks, even in
theory, that have uniform numbering plans. People always expect to
be able to dial 0 for operator, and asking them to dial an area code
to reach a next-door neighbor provokes considerable resistance.
Further, PBX and Centrex systems usually require only three or four
digits for internal calls, and thus differ from the seven digits
dialed into the public network.
Two
ways of letting a common control system know that dialing is
complete are to use a unique end-of-dialing signal or to provide a
time-out; if no further digits are received in, say, three seconds,
the control is free to assume it has all it is going to get.
Unfortunately, there usually aren't enough signals available to
dedicate one to end of dialing, and a time-out always increases post
dialing delay and sometimes isn't long enough to let the user check
the directory for the last several digits of a ten digit number.
Thus a third approach, called "pretranslation," is employed to
assist the common control.
With
pretranslation, the system examines each digit as it is dialed and
uses the information so obtained to estimate the number of digits to
follow. For instance, if the first digit is 2-9, a central office
knows it can very probably expect six more, while if the first digit
is 1, ten digits are likely. However, in both instances, subsequent
digits must be examined and may change the control's expectations.
NUMBERING PLANS AND ROUTING
Every telephone must have a unique address so that a caller can
specify it unambiguously. However, traditional telephone numbering
plans have also been designed to locate the called number
geographically to simplify routing. Thus the design of a numbering
plan is not to be taken lightly.
In
the United States and Canada, at the present time, a telephone
number consists of ten digits: a three digit area code, a three
digit office code, and a four digit station number. The area code
need not be dialed when the called party is in the same area as the
caller, but a caller with the same office code must dial the office
code plus four digits to reach a neighbor. As we will see, this is
just the tip of the iceberg.
Phone systems for businesses and hotels have specialized numbering
plan needs which will be discussed in Chapter 5, but mobile phones,
where the called party can be anywhere, have numbering and routing
requirements which have only recently begun to be explored.
Route codes and destination codes
A
route code actually selects the trunks used in a given connection,
while a destination code identifies the location of the called
number and depends on translation to produce the desired route code.
In general, systems based on route codes can have different
addresses for a called number, depending on the location of the
calling number. Destination codes simplify matters considerably for
the caller in that the same number, within limits, can be used no
matter where the caller is or how the telephone company changes the
actual routing.
AT&T's Panel System was one of the first switching systems to
separate route codes from destination codes. We have already seen
how the panel sender, when connected to the terminating office,
could make the fixed translation from directory number (four decimal
digits) to equipment number (five digits, three of which were not
decimal); far more impressive was the "decoder," called in by the
sender, to translate the first three dialed digits into the
instructions necessary to select the right trunk group to reach the
terminating switch. The originating half of the switch, like the
terminating half, had two stages of 500-output switches. It was
capable of reaching some 1500 different routes maximum, although the
nature of the numbering plan at that time usually limited the choice
to something less than 500.
A
Panel decoder could make three translations a second, and a group of
six could serve some 400 senders and deal easily with 46,000 busy
hour call attempts. The whole idea was to allow inter-office
trunking to be changed as needed, without changing the telephone
book, directory assistance, or user behavior. All one had to do was
change the decoders to match the new routing; a user dialed the same
destination code, but the panel sender obtained from its decoder the
new signals its switches needed to make the connection.
Although destination codes are necessary in large networks where
trunk groups are added, deleted and modified with some frequency and
routing is changed from hour to hour as a function of traffic in the
system, route codes can still be quite effective in smaller private
networks such those used by businesses. Until recently, SXS
dial-tandem systems were efficient and inexpensive, and many stored
program systems chose to copy them in various ways. For instance,
someone in the New York headquarters office dials 6 to select a
tie-trunk to the Philadelphia sales division, or 7 for the warehouse
in Yonkers.
A
problem with route code operation shows up when somebody in the
sales office wants to call the warehouse. They must dial a
particular digit, 5 for example, to access the trunk group to New
York, and then dial a 7 to get to the warehouse. Someone from
headquarters, visiting Philadelphia and wanting to call the
warehouse, has to remember to add the 5. In larger networks, such
routing digits can become considerably more cumbersome.
With
its enormous flexibility, SXS could make route codes take on some of
the advantages of destination codes by adding a rank of switches at
the hub. Suppose tie trunks to the warehouse, the sales office, and
the New Haven factory were put on levels 7, 6 and 5, respectively,
of this new rank of switches, and people in the New York office
dialed 8 to reach the new switches and then 7, 6 or 5 to select a
trunk. Now, if the tie trunks were accessed at each remote PBX by
dialing 8, callers at those locations would dial exactly the same
code to reach another PBX as the people in New York: 87, 86 or 85.
For uniformity, people at the remote locations might access the New
York switch by dialing 88 (and might even dial 89 to get dial tone
from the New York Telephone Co.). One telephone directory could be
printed for all four locations; the rule for dialing would be to use
the extension number alone for intra-PBX calls, but dial 8 plus
another digit followed by the extension number to reach someone on
another PBX.
SXS
systems driven by dial pulses were ideally suited to this sort of
arrangement. A user could dial from one PBX to another without
having to wait for dial tone at intermediate or terminating PBXs; if
a trunk was idle, its incoming selector at the distant PBX was ready
to accept dial pulses. With a common control PBX (or a central
office) on the far end of the trunk, however, the customer had to be
fended off until a digit receiver could be attached. This made it
necessary for the customer to "wait for dial tone," a delay which
people unfamiliar with technology attributed to SXS.
From
their beginning, electronic PBXs had difficulty passing dial pulses
through their matrices. On connections to either tie-trunks or CO
trunks from dial pulse sources, the pulses had to be picked off at
the incoming side of the matrix and regenerated by the system
control at the outgoing trunk. As electronic PBXs began to replace
SXS in the late 1970s, tone signaling (DTMF, to be discussed in
Chapter 3) took over; once a path was established through a switch,
it could pass DTMF digits to the next switch as easily as any other
voice frequency signal. Unfortunately, tone signaling required the
caller to "wait for dial tone" until the distant end, even when it
was a SXS switch, attached a digit receiver to convert the analog
tones into digital pulses for system control. Thus tone signaling
and not SXS was another factor in the proliferation of multiple dial
tones in private networks.
Early common control tie-trunk networks (such as one called CCSA,
based on 5XBAR and marketed by AT&T) were not economical in sizes
too small to justify the cost of their complex registers and
markers. To prove that money wasn't everything, their partisans
attacked the ubiquitous and inexpensive SXS for all the things it
supposedly could not do, such as automatic alternate routing.
However, SXS was perfectly capable of a limited but widely used form
of alternate routing based on a technique called "digit absorbing."
Suppose the volume of traffic between the factory and the warehouse,
in our example above, increased considerably. Tie-trunks from New
Haven and Yonkers to the hub in down-town New York City could be
added to meet the need, but trunks from New Haven directly to
Yonkers would be less expensive and wouldn't require switching
equipment in New York. The ideal approach would be to put in a few
direct "first choice" trunks, and allow only the calls overflowing
them to join the traffic to the hub. Trunk selection would, of
course have to be automatic to keep from confusing the user.
A
new small trunk group might be put on the first three or four rotary
steps of level 3 at both New Haven and Yonkers, but trunks to the
New York hub, on level 8, would also be connected to the remaining
terminals on the 3 level. Users at Yonkers would dial 35 to get the
factory, and New Haven callers would dial 37 to get the warehouse.
If they reached a direct trunk upon dialing 3, the 5 or 7 would be
"absorbed" by the selector at the other end: it would go up to the
level dialed and fall back instead of going into a rotary hunt, and
await the first digit of the extension number. If all the direct
trunks were busy, however, the switch would hunt on into the
"backbone" trunks to the hub. In this instance, the second digit
would steer the call through the hub and back to the desired
destination. By properly proportioning the direct and backbone trunk
groups, considerable savings could be realized while maintaining a
good grade of service.
The
advantage of common control in electronic systems over SXS was not
that it could do automatic alternate routing, but that it can do it
without changing the users' dialing habits. In our example, a caller
at the factory would continue to dial 87 plus the extension number
to get the warehouse. The system would look first at the direct
trunk group and, if one was free, seize it and outpulse the
extension number. Otherwise, a backbone trunk to the hub would be
seized and the whole number outpulsed. At the hub, the electronic
PBX there would examine the first two digits, make the connection to
the warehouse, and outpulse the extension number. Although this
requires a smarter control, once the smarter control is available,
there is every reason to use it, particularly when it simplifies
life for the system user.
In
Europe, where for many years SXS was nearly universal in the public
network, customer-dialed destination codes would be intercepted by a
register-sender upon entering the toll network and translated to a
route code. The sender would then outpulse digits to various
intermediate switches until the called office was reached. If an ATB
condition was discovered, the sender could drop the whole connection
and ask for a new route code. This ability to back off and retry had
some advantages before common channel signaling and common control
tandem switches made other approaches more useful.
Access codes and area codes
In
the United States and Canada, users dial a three digit office code
and a four digit station number to reach people in their immediate
vicinity via the public network. Four decimal digits permit a
maximum of 10,000 lines (0000 to 9999), and it happens that 10,000
jacks were just about the maximum that could be put within reach of
an operator at a manual switchboard. Early automatic central offices
were designed around four-digit numbering in a given "office," but
later systems, able to handle far more than 10,000 lines, lost the
one-to-one relationship between office code and switch. While an
office code identifies a particular CO switch, knowing the location
of the CO leaves the identify of a customer's office code in
question.
As
an example, any one of 12 different office codes will identify the
switching system in Haddonfield, NJ, but knowing that someone is
served by the Haddonfield switch does not specify his or her office
code. Indeed, an intra-switch call from one user to another would
need at least two digits to identify the particular "office." In
actual practice, three digit office codes in a "uniform numbering
plan" allow a caller to reach any of the 196 office codes in South
Jersey as easily as those on the Haddonfield switch by dialing
exactly the same number of digits. As suggested earlier, this makes
it easier for the CO switch to know when the user making a local
call has finished dialing, but it also lets the user dial the same
seven digit number from anywhere in South Jersey to reach a
particular telephone.
Internal calls in PBX and Centrex systems seldom need more than two
or three digits to identify the called party, although large systems
may need four or even five digits. As a result, these systems are
designed to expect the appropriate number of digits for an internal
call unless an access code of some sort tells the system via
pre-translation that the call is not intra-switch. To escape from a
PBX, it is almost universal to dial 9 and be cut through to
dial-tone from the serving central office into which the local or
long distance number is then dialed. With Centrex, where the caller
is already in the central office, dial tone simply continues, a
procedure that sometimes makes the user wonder if the system has
responded properly (a similar problem exists in PBXs with automatic
route selection which do not cut through to the CO after seeing the
initial 9). Clearly, 9 cannot be both the escape code and the first
digit of a PBX or Centrex extension number.
Dial
9 for outside is often modified when FX lines (trunks to a distant
CO, discussed in Chapter 4) are provided. Sometimes 9 is the local
suburban CO, while 8 gets a nearby metropolitan CO (or vice versa).
In other instances, 91 may get one CO and 92 may get a more distant
one, with WATS lines "on levels" 93, 94 and 95. (A PBX WATS line,
functionally, is simply a CO trunk; only the billing approach is
different. A Centrex WATS line often has no physical existence and
is a billing algorithm only).
Once
the CO is accessed, local calls require seven digits, while more
distant areas must be selected by an additional three digits.
Three-digit area codes were set up in the 1950s; they were intended
to have 0 or 1 for the middle digit to facilitate pretranslation
(office codes did NOT have 0 or 1 for a middle digit in those days).
Switching systems were designed (or modified) to look at the first
three digits dialed and, if the second digit was a 0 or 1, the call
was routed to toll and the whole number, including the area code,
was outpulsed. Routing then became the responsibility of the toll
switch.
Unfortunately, we began running out of telephone numbers at just
about the predicted time. To get more office codes within each area
code, use of 0 and 1 was added to the digits 2-9 for the second
office code digit, starting in the 1970s. This did not produce
enough numbers, and in 1995, a huge number of new area codes became
available when the second area code digit, originally 0 or 1, was
permitted to take on the values 2-9. In the jargon of the business,
N is any digit 2-9 and X is any digit. When both area and office
codes can be described as NXX instead of N0/1X and NNX, something
else is needed to differentiate between 609 as an office code in Los
Angeles and 609 as the area code for South Jersey.
To
accomplish this, 1 and 0, which are never the first digit (N) of an
area or office code, simplify pretranslation. As the standard is
intended to evolve, the digit 1 means that a ten digit number (NXX
NXX XXXX) will follow, unless the next digit is not an N (in which
case, the user may be about to dial an overseas call or signal a
desire to use a different long distance carrier). If the first digit
dialed is an N, then a seven digit number will follow. Thus an NXX
following a 1 will always be an area code.
There are political complications, however, because certain states
require a 1 to be dialed before a toll call, even if the destination
is in the caller's own area code. If local public service
commissions continue to inflict this "toll alert" on their subjects,
requiring them to tell the CO something it already knows but they,
in many cases, do not, customers will have to dial 1 plus 10 digits
for many calls within their own area code. Telephone companies are
modifying their central office switches to always accept 1 plus ten
digits, even for local calls; among other things, this allows users
of mobile phones, who have no way of knowing which area code they
happen to be driving through at the moment, to store frequently
called numbers in their phones in a form which will always work.
When
a 0 is the first digit, the services of an operator are expected.
Certain classes of operator-handled calls are referred to as 0+
(zero plus) and require the caller to dial 0 plus the called number.
On a credit-card call, for instance, the operator (or a robot) then
obtains the caller's billing number and allows the call to advance.
It will become standard for 0, like 1, to be followed by ten digits,
even when the called number is in the caller's area code.
Regular or coin phones, when used for credit card calls, may or may
not have the same long distance company as the caller. To specify
the desired carrier, the user must dial a carrier code, preceded by
10 as an access code and followed by 0 or 0+. To dial an overseas
call direct, the user dials an access code such as 011, followed by
whatever else the foreign numbering plan requires (usually country
code, city code and telephone number).
Today, 0 by itself calls in an operator from the local telephone
company, while 00 invokes an operator from the customer's long
distance carrier. Upon seeing the first 0, the switch has no way of
knowing if additional digits are to follow. As a result, a three to
five second time-out is started and, if no more digits are received,
the call is routed to the local operator.
Clearly, the translation capability of a switching system must be
quite general, and capable of being changed easily and quickly to
meet requirements imposed by outsiders with no knowledge of the
technology involved. When competition with local telephone companies
is permitted, "portability" of a caller's telephone number will be
expected to facilitate customer migration. Locating a given
directory number which may correspond to an equipment number on any
one of several different switches owned by different telephone
companies will raise the need for ingenuity in the field of
translation to new heights.
Service codes
A
number of three-digit codes of the form N11 are in use at the
present time. For instance, 211 is often used for the long distance
operator, 411 for information, 611 for repair, and 811 for business
office. Further, 911 is slowly being installed across the country as
a universal emergency number. The use of 611 and 811 is apparently
being discouraged, but 911 is going ahead.
In
many SXS areas, 11N codes have been used instead of the N11 codes.
This use is not in accord with the national numbering plan and
someday will vanish. However, 1XX codes are used in certain kinds of
tie-trunk switching although the 1XX is followed by more digits, and
the 10 code, as mentioned above, warns that a long distance
carrier's identity will follow.
It
is fortunate that the digits 0 and 1 were available to provide an
escape from the national numbering plan with its seven and ten digit
"uniform" numbering. The digit 0 (sometimes called "oh" but not to
be confused with the letter "o" associated with the digit 6) had
been reserved to reach the operator almost from the beginning of
automatic telephony, but the availability of the digit 1 is a little
more obscure. It turns out that the old candle-stick phones would
frequently generate a false pulse when going off-hook; thus early
numbering plans did not use 1 as a first digit and, when an initial
1 came in, switching systems ignored it.
In
SXS areas, the 11X service codes were developed to prevent wasting
numbers; the first digit, if a 1, would be ignored, but the second
would select a path to the selector that picked the desired service.
If a third 1 came in (as when a false 1 was followed by a 11N code)
it, too, would be ignored, although any other digit would pick a
service. The ingenuity with which such problems were solved in
pre-computer days has to be admired, but even with computers
available, it is desirable to develop a feel for the kinds of
unexpected problems which may have to be dealt with.
The
national numbering plan is becoming more and more complex as the
number of telephones increases, Centrex service demands more office
codes, and portable and mobile telephone companies and long distance
carriers proliferate. AT&T's Notes on the Network, which succeeded
Notes on Distance Dialing, was taken over by Bellcore for the
operating telephone companies, but new competitors and others are
demanding a say in who "owns" a telephone number and who should be
permitted to settle numbering plan disputes. Perhaps the FCC will
take over numbering plan standards.
Three and six-digit screening
In
the literature, reference is frequently made to three and six digit
screening (or translation), where the switching system looks at both
the office code and the area code or just at one of them to route a
call. Prefix digits, access codes, etc., are examined separately.
Obviously, a system that can do six-digit screening has more
flexibility than one that can only examine three digits. However,
even six-digit screening may not be enough in some instances.
Once
again, modern technology makes almost trivial a problem that was
difficult with older hardware. Similarly, deleting digits, adding
digits and altering digits is no longer the problem it used to be.
Any computer-controlled switch can take in a number, check the
digits as dialed against various look-up tables and, when it has
enough information, establish a connection either internally or to
another switch, outpulse whatever digits the distant switch will
need, and monitor the call for answer and hang-up.
Until recently, the called number was sent forward via the trunk to
be used for conversation; today, the term "outpulsing" must be
expanded to include sending signaling via CCIS. With the ISDN
standard SS7 rapidly taking over, few trunks carrying their own
signaling remain.
Automatic alternate routing and automatic route selection
The
simplest way to allow customers on one switch to talk to those on
another would be to provide direct trunks between the two switches.
However, the 20,000 central offices in the United States would need
about a billion and a quarter trunk groups to do this; a more
economical approach taking advantage of intermediate switches was
implemented quite early. Progressive controlled switches such as SXS
and Panel worked well this way; in the example discussed in the
section on Route Codes and Destination Codes, the stage of tandem
SXS switches at the hub was shared by all, and could be considered
as much a part of the remote PBXs as the PBX at headquarters where
it was located. The originating half of a Panel System, with its
decoder to get route codes from destination codes, could also share
selectors with its peers in vastly more complex networks, allowing a
number of nearby systems to share trunks to the remaining several
hundred central offices in the metropolitan area.
Translating the destination code to a route code is the first step
in economic routing; allowing the system to choose an alternate
route if it finds the first route ATB is the next step. As we have
seen, simple networks using digit absorbing can get good results,
but when there might be five or six alternate routes available for
each possible connection between switches in a group of three or
four hundred, common control is vastly more desirable. Three and six
digit screening may be necessary, but it is insufficient if one
cannot detect an ATB and go on to the next route.
There have been three stages in automatic call routing. In the
first, each switch selected the outgoing trunk group and sent
forward, via the trunk chosen, the information the next switch would
need to continue or complete call setup. In the second stage, each
switch retained the power to select the outgoing trunk group, but
used common channel signaling rather than the trunk to speed
information to the connected switch. Today, in the third stage,
routing control has moved from the switch to the signaling network;
once the "intelligent network" knows what is wanted, it searches
over the multiple routes available, finds a path, end to end, and
tells switches which trunks to connect together. Common channel
signaling is fast but, because it does not use the selected path as
did older signaling technologies, testing is required after the
connection is established but before it is turned over to the user.
It
is evident that the earlier procedures, even when carried out by
common control switches, were a form of "progressive control," each
switch blindly choosing what it hoped was the best path forward.
Today, the intelligent network brings to trunk connections the
equivalent of true "common control," where all the "links" are found
before the path is established.
Hierarchical and other networks. Prior to
the breakup of the Bell System, a five-level hierarchy of switches
had been established to facilitate call routing. Local central
offices served customers; all the others were central offices for
central offices, and made only trunk-to-trunk connections. In
principle, a call could be routed through as many as 12 switching
systems as a long distance connection was set up, but routing
procedures where such that only a very small proportion of calls
went through more than five switches, including the originating and
terminating local COs.
In
the hierarchy, the great majority of switches were Class 5 or local
central offices homing on about 1400 entry level toll switches,
designated Class 4. At the top of the pyramid were about 200 Control
Switching Points or CSPs, Classes 1-3. The United States and Canada
were divided into twelve geographical regions, with one Class 1
office, called a Regional Center, in each. The Regional Centers were
all connected to one another with direct trunk groups; these trunk
groups represented the final chance for a long distance call to get
from one region to another.
In
large metropolitan areas, tandem switches are provided where a
number of local COs are very close together. A tandem switch is
"local," rather than "toll," and is not considered part of the toll
hierarchy. Its principal purpose is to provide large (efficient)
trunk groups to and from tandem where a switched connection is made
for local calls, rather than a much larger number of inefficient
trunk groups directly from each local CO to all the others in the
same exchange area. However, when local COs developed alternate
routing capability, it became common to have small direct trunk
groups overflowing to the large backbone group to tandem. Tandem
switches also offered an opportunity to provide efficient trunk
groups to and from the toll network for their client switches;
today, in many areas, local telephone companies have been required
to put in "access tandems" to provide "equal access" to the many new
long distance carriers.
A
hierarchical network makes sense in that it acts as a concentrator
of long distance traffic; there is, for example, a certain amount of
traffic between King of Prussia, PA, and Novato, CA., but hardly
enough to require direct trunks. However, there is a considerable
amount of traffic from the Philadelphia area to the San Francisco
area if one adds up the traffic to and from all the offices within
each area. A hierarchical network allows these central offices to
participate in the economies of scale made possible by using a large
trunk group rather than many small ones.
Modern computer control for switches, much larger switches made
possible by digital technology, CCIS for more efficient call set-up,
and the lower cost of trunks due to optical fiber, have tended to
reduce the need for hierarchical networks. At the local level,
100,000 line central office switches make tandem networks serving
10,000 line CO switches obsolete, and at the toll network level,
switches for 100,000 trunks can incorporate several of the old
hierarchical levels in a similar way. All these switching systems,
terminating digital trunks on fiber directly (without demultiplexing),
reduce costs and avoid many of the traditional problems of analog
transmission.
Unfortunately, economies possible with direct toll trunks between
two widely separated local COs with a high community of interest
have been eliminated by the divestiture of the Bell operating
companies from AT&T, as have the economies possible with switches
designed to combine the functions of local, tandem and toll
switching. Further, as a result of the fragmentation of traffic
among proliferating long distance carriers, local switches have had
to increase the number of trunk groups and, thus, ports on their
matrices, to handle the same amount of traffic.
Routing approaches. The design of a
telephone network consists of balancing cost against grade of
service. Too many trunks may provide a good grade of service (low
probability of blocking) but drive up the price the customer must be
charged, while too few trunks, resulting in frequent connections to
reorder tone, the "fast busy" that means ATB, will cause complaints
to regulatory bodies and, worse, a migration of customers to a
competing long distance company.
The
economics of networking is not based on the cost of a trunk, but
rather on the cost per minute of use. Clearly, if two trunks cost
the same, but one runs at 90% occupancy and the other at only 45%,
the latter costs twice as much per minute of traffic carried. The
trick is to get high usage on each trunk to minimize the number of
trunks needed, but still not to have the trunks so loaded that calls
are blocked.
It
turns out to be a fact of statistical life that one large trunk
group runs at higher occupancy per trunk, for the same grade of
service, than do several small groups with the same total number of
trunks. Thus large trunk groups are more efficient. A second fact is
that, if you always offer traffic in the same order to trunks in a
group, the first will carry the most while the second, offered only
the traffic that overflows the first, will carry slightly less. If
there are enough trunks, the last in the group is reached only when
all the others are in use, and it will carry the smallest amount of
traffic. As the traffic falls off, the cost per minute on later
choice trunks goes up.
Most
routing schemes are based on having a few direct trunks between
specific switches to act as first choice and allow overflow traffic
to join that on a backbone trunk group going to a large number of
other destinations via a tandem switch higher in the hierarchy. The
direct or high usage (HU) trunks "skim the cream" by getting first
chance at the traffic between their specific locations, while the
backbone group, carrying traffic to many destinations, takes
advantage of its large size to get high occupancy. The trick is to
proportion the HU group so that the cost per minute on its least
used member is just slightly lower than the cost per minute on the
most used trunk in the backbone group. Note that the cost of the
path through the backbone includes at least two trunks and switching
at intermediate points. Elaborate schemes have been devised by the
telephone industry to handle many alternate routes among hundreds of
switches.
When
a network contains many switches, progressive routing from one
switch to another can lead to "ring around a rosie" patterns, where
traffic from switch A to switch D via switch B finds ATB and is
routed to switch C. When C also has ATB to D, it may route the call
back to B where the process is repeated. Routing rules took
advantage of hierarchical networks to prevent this: a call could
only go "up" in the originating hierarchy, and "down" in the
terminating hierarchy; at each level in the originating hierarchy,
it would look for appropriate paths to the terminating hierarchy,
perhaps directly to the local CO, but never to a switch more than
one level above its own rank. Only when all such avenues were
exhausted would the call overflow up the backbone to the next higher
switch in the originating hierarchy.
These network design techniques, developed by the telephone
industry, have been applied extensively to private networks since
the mid-1970s under the unfortunate name of "least cost routing."
Unless traffic, costs, and options available are constantly
monitored and the trunk selection process is adjusted accordingly,
there is no assurance that costs will be minimum or even less than
simply using a public network. Thus a more accurate name is
"automatic route selection" (ARS); it emphasizes the ability of a
switch to do what it is told, whether or not that choice continues
to make sense. In PBXs, it is not uncommon to combine ARS with
queuing to increase trunk occupancy, lowering the cost per minute.
Terminology in PBXs sometimes also differentiates between automatic
alternate routing (AAR) and ARS, reserving the former for tie-trunks
and the latter for various types of trunks such as WATS lines that
simply represent access to lower cost switched service in the
several local and long distance public networks.
In
any event, all modern switches, including small PBXs, should be able
to provide AAR/ARS. That is, the switch must be able to look at the
dialed digits, either individually as they come in or collectively
or both, and either decide which route is to be used to complete the
call or request help from a centralized data base. Naturally, the
route chosen is not only a function of the desired destination, but
also a function of the trunk routes actually available and their
occupancy (and sometimes, time of day and the rank of the caller)
until the route is established. Although the problem is trivial for
computer control, lack of computers 30 or 40 years ago did not
prevent the job from being done well with the tools at hand.
In-WATS and similar services
With
"800 service," originally called in-WATS, the called party pays for
incoming calls. 900 service puts many similar requirements on a
switch, but here the caller is billed not only for the call but also
for some product or service for which the telephone company acts as
a collection agent for the vendor.
Both
800 and 900 service require translation and routing that, prior to
the coming of CCIS, tended to get a little more complicated than
might be supposed. All such numbers are identified by their
distinctive area code; this permits users and equipment alike to
recognize them easily. However, the seven digits following the 800
or 900 do not contain enough information to test the call for
validity, determine which long distance carrier is involved, and
then route the call to its destination.
The
approach used today is relatively simple: the local switch uses CCIS
to access a central data base where the 800 or 900 number is used to
look up the required parameters. A conventional telephone number is
provided for routing, and CCIS also conveys information needed for
billing to the appropriate locations.
There are two kinds of 800 Service: one with its own group of access
trunks to the customer PBX, Centrex or automatic call distributor
(ACD), and the other using the trunks associated with the customer's
regular listed directory number. The latter approach is particularly
useful for small customers in that they do not need to make any
changes in their equipment to take advantage of 800 service; the
former, much more suitable for high volumes of traffic, often uses
direct trunks from the long distance carrier to the ACD. When this
trunk group is ATB, CCIS can prevent network congestion, perhaps
caused by TV screens all over the country showing the 800 number at
the same time, by causing reorder tone to be returned locally or the
call to be routed to another ACD which may be accessible.
The
centralized data base needed for 800 service was an early
application that has since been expanded to handle the set-up of all
long distance calls. As of the early 1990s, local central offices
are being modified to use SS7, allowing local and long distance
companies to cooperate to take advantage of busy testing before
trunk selection, etc. However, it will take more time to extend CCIS
into customer-owned PBXs. Unfortunately, both PBXs and Centrex use a
variety of features to deal with incoming calls (Chapter 5) so that
a simple busy test will not make sense. Indeed, in a properly
implemented business system, busy and ring-no-answer conditions need
not exist.
A
major advantage in having a centralized data base accessed by a data
network is that information can be stored and updated at a single
point for a large number of CO switches all over the country. With
this kind of flexibility, it is possible to have the same 800 number
route calls differently as a function of time of day, day of week,
traffic, etc., useful when, for example, a customer wishes to close
the east coast ACD at 5:30 p.m., and have the west coast ACD pick up
the traffic. But routing and billing are only two functions that a
CCIS network can provide. A whole range of network-wide features is
being developed to make full use of this new capability.
Prior to the coming of centralized data bases and high speed data
networks to access them, 800 service was incredibly difficult to
provide, particularly with electromechanical switches such at 5XBAR.
Future historians of technology will doubtless be amused at the
quaint behavior of their ancestors when they read the "WATS" section
of Notes on Distance Dialing, 1975.
RESTRICTION
Automatic routing techniques are used to select the proper facility
over which to complete a call. Restriction, in all its various
forms, checks to see if the particular caller is permitted the make
the call in the first place.
Toll diversion and restriction
Toll
diversion and restriction are features of particular interest to
business customers, and are usually associated with PBX service
although Centrex offers something similar. Traditionally, toll
diversion is a central office feature, while restriction is provided
by equipment on the customer's premises. When a PBX-CO trunk is
class marked for toll diversion, the CO checks the dialed digits as
they arrive. If a toll call is indicated, the CO returns a signal,
usually a battery reversal, which then calls in the console
attendant or activates reorder tone. Restriction is more flexible in
that it can identify calling regions in much greater detail, it can
be set to define either the region to be blocked or the region to
which calls are permitted, depending on which is easier to program,
and in current versions built into PBXs, it can usually take into
consideration who is placing the call as well as the call's
destination.
Restriction was originally provided by a separate equipment unit
inserted into CO trunks at the PBX. It watched the dialed digits as
they went by, using either three or six digit screening; when it
found a call going into a forbidden area it, like toll diversion,
would return a signal via the trunk to allow the PBX to take action.
Restriction's flexibility compared with toll diversion was
particularly valuable in calling areas such as Los Angeles where a
local call to a remote part of the city might cost more than a toll
call to New York. By restricting calls on regular CO trunks to the
lowest cost local area, and providing similarly restricted FX lines
(see Chapter 4) to other parts of the city, a great deal of money
could be saved. In such situations, the restrictor took on some of
the functions of ARS by letting the call complete only when the
right access code was chosen.
After some years, PBX designers began to offer restriction
capability comparable to external units, often coupling restriction
with ARS to eliminate the need for the user to dial the right access
code for a particular FX group. However, many systems continued to
cling to the equivalent of toll diversion, blocking calls starting
with 0 or 1, or having 0 or 1 as the second digit after the access
code. As early as 1975, office codes started having 0 and 1 as their
second digit, and since then, there have been ever-increasing
numbers of "troubles" where a PBX could not call a nearby number
because a simple restriction algorithm thought a local office code
was a long distance area code.
Another major restriction difficulty frequently found in both PBX
and Centrex systems is a sort of hierarchical restriction pattern
where "facilities restriction levels" are assigned in such a way
that each less restricted level includes all the more restricted
levels. For instance, some totally restricted phones might only be
able to call other phones on the PBX. The next level would be
intra-PBX plus local calls only. The next levels might add
intra-area-code, then intra-state, then adjoining states, then a
larger region, ending finally with totally unrestricted phones
permitted to call anywhere in the world.
Although this seems to offer considerable flexibility, it does not
permit setting up one group of phones to place calls to states west
of the Mississippi and another to place calls to the eastern states,
nor does it permit blocking of selective area codes, both near and
far. Another problem is that such restriction is a function of the
class of service of the calling extension only; it eliminates the
option of allowing certain people to place calls to a given
destination via FX lines but not via toll, and it allows
unrestricted phones to make long distance calls from the "open end"
of FX lines. Some of these problems can be controlled by carefully
combining restriction and ARS, but this is not always an available
option.
In
recent years, the ability to block calls to 900 numbers has become a
major function of restriction for switches serving both residential
and business phones. In passing, it should also be noted that
screening on the full ten-digit number should be possible to block
calls to specific undesirable numbers while permitting calls to
other numbers with the same office code.
Cut-through vs. senderization
After every digit, the switch in a SXS system receiving it would
"cut through" to the next switch. Electromechanical PBXs operated
"cut through" on access codes for the CO or tie trunks, limiting the
number of digits that had to be stored in relay registers by
requiring subsequent digits to be dialed into the connecting system.
This practice was widely copied in many electronic PBXs where the
register problem did not exist, and continues to this day in some
systems. There is, of course, no longer any excuse to continue
copying SXS; in both PBX and Centrex systems, "senderized operation"
should be used. Here the caller dials the entire number as well as
the access code into the system's memory; the caller may be
encouraged by a second dial tone after the access code, but there is
no technical reason to provide it.
Once
the system has the number, it can make full use of restriction to be
sure the call is permitted and, if it is, ARS can be used to relieve
the caller of the need to select the proper trunk group. It can then
transmit the called number, modified as required, to the next
switching system at speeds beyond human capability. Senderized
outpulsing using DTMF can send 10 digits in one second, while a
human might need six or seven seconds. CCIS, to be available with
the ISDN Basic and Primary Rate Interfaces (BRI and PRI, to be
discussed in Chapter 3), will be even faster. Thus senderized
outpulsing provides better use of trunks by not seizing them at all
for restricted calls and by not tying them up with incomplete or
slow dialing by humans.
Until BRI and PRI make CCIS standard between PBXs and COs, dial
pulse and DTMF senders will continue to emulate humans. As such,
they will have to wait for dial tone or some other signal from the
connecting switch to be sure it is ready, and only then spill digits
forward. Dial pulsing is still more widely used than is generally
realized, largely because of the high price charged by telephone
companies to detect DTMF. DP, even when senderized, is very slow. To
minimize "post dialing delay," the time between the end of user
dialing and the return of ringing, senderized systems usually send
dial pulses in what is called "overlap out-pulsing." When
pretranslation has enough digits, a trunk is seized and outpulsing
commences; typically, the sender transmits the area and office code
while the user is still dialing the called party's four digit
number. With DTMF, of course, overlap out-pulsing should be avoided.
Signaling between the user and the PBX can be digital, DP or DTMF;
once the called number is stored in system memory, it can be
transmitted to the CO or another PBX by whatever means that switch
requires, including CCIS. Thus conversion from intra-PBX signaling
to that required by the outside world is not a problem for
senderized systems. There is a problem, however, when electronic
telephones, using digital signaling to their PBX, wish to use DTMF
to access electronic banking, voice mail, an automated attendant or
something similar once the call is set up. To accommodate this, some
electronic phones generate DTMF in addition to digital signals,
while other systems have the user push a button requesting a tone
signaling sender be bridged onto the connection to follow the
digital digits sent by the caller.
Unlocking codes
A
PBX feature which will almost certainly become valuable in
residential service is the "unlocking code," a number which, when
dialed into the system, changes the line's class of service to
permit the following call to violate restriction. Although
originally intended to allow executives to make outside or toll
calls from restricted phones such as those found on the loading dock
on in the reception room, this feature is far more general. It can,
for instance, allow otherwise blocked calls to 900 numbers, and when
related to the caller's billing or credit card number, assure proper
allocation of cost.
Out-WATS
Although in-WATS calls require more elaborate translation and
routing procedures than out-WATS calls, the latter require fairly
careful use of restriction. Interstate "banded" WATS calls must be
prevented from going beyond the range purchased by the user, or
being completed intra-state. Thus for any given state and, in some
with many telephones, for different regions within the state, the
restriction patterns for a given WATS band will be unique. Band 1
for New York southeast is totally different from Band 1 for Nevada,
or even New York west.
Intra-state WATS may cover the entire state or only some particular
portion. Again, flexibility in restriction and/or ARS is required to
insure placing the call on the correct facility, if the call is
permitted at all.
DATA RECORDING
Electromechanical telephone switches did not include data recording
facilities in their basic design. Rather, they added banks of
counters, an occasional traffic usage recorder (TUR), an automatic
message accounting (AMA) system, and various other separate pieces
of equipment. Although there was an obvious relation between traffic
and billing, separate systems were developed for accumulating the
appropriate records. Traffic systems obtained usage on particular
groups of facilities independent of each call's ultimate source or
destination, while billing worked between source and destination
with little interest in the particular facilities used.
When
minicomputers and microprocessors became readily available, they
were equipped with sensors, printers, tape and later disk recorders,
and other peripheral equipment, to assume the above
responsibilities. As computer control developed for the switches
themselves, the switches began collecting and formatting necessary
data and outputting it for storage in separate units.
Today, almost all new systems have elaborate means for acquiring
internal data for both traffic and billing, and recording it
off-line in non-volatile memory for subsequent use. However, add-on
units, monitoring lines and trunks and developing their own
information, are also used, particularly with Centrex systems where
the customer does not always have immediate access to information
produced by the CO switching system itself. Further, the information
available is all too often inadequate. Another reason for separate
units is that switches, when they are overloaded at high-calling
peaks, sometimes cease doing administrative functions to cope with
the call processing load. Losing either traffic or billing
information just when it is needed most is, of course, undesirable,
and some PBXs, designed around a multi-processor control
architecture, have a separate processor as part of the control
complex to monitor system behavior independent of the computers
actually processing calls.
Because both traffic and billing information, in addition to their
obvious importance in system administration, are vital for
diagnosing various classes of troubles as they develop, it is most
important for new systems to be designed to include means for
analyzing and presenting such data in useful formats. As with
routing and restriction, the incremental cost required to obtain the
full benefit of billing and traffic information is quite modest if
an overall design approach is used rather than assuming each aspect
is a separate and independent branch of the program.
Billing
Telephone companies earn money, a few cents at a time, on telephone
calls custom-made to order while the caller waits. Toll calls are
usually billed individually, and many local calls are billed on the
basis of distance and duration, even though the customer is not
given billing detail. "Flat rate" calls are not billed individually
and require no record keeping; extended area service (EAS), where
the customer pays more per month for a wider flat-rate calling area,
has been popular with telephone companies where collecting billing
information is expensive. Because modern switching systems can
collect, store and make available in convenient form billing
information even for local calls, flat rate service and EAS will
continue to decline in favor of usage sensitive pricing. In PBXs,
where call detail recording (CDR), in addition to its traditional
role of billing back to individual users or departments, is used for
a variety of things including control of telephone abuse, detecting
communities of interest within a work force, and management
planning, detailed billing should include local calls and even
intra-PBX connections.
There are two parts to recording billing information. The first
obtains the identity of the calling and called parties so that
distance can be calculated, and the second detects answer and hangup
time for the calculation of call duration. As has been described,
translating the originating equipment number to a directory number
is necessary to identify the party to be billed but it is not always
sufficient. A party line or an ISDN BRI channel (see Chapter 3) will
also require the identity of the particular customer or device to
whom the call should be charged, and business calls from the same
extension may have to be billed to different accounts. The callED
number, of course, is provided by the customer.
In
the not too distant past, both PBXs and Community Dial Offices (CDOs)
identified the calling number and transmitted it to the CO on which
they homed so that it could keep the billing record. Usually, a
separate device for Automatic Number Identification (ANI) would
detect the calling line (which defined the calling number in SXS
systems) and transmit it to the recording CO via the trunk to be
used for the conversation or, more commonly, via a separate data
link. The term CAMA for centralized automatic message accounting was
applied to this form of recording, and AIOD, or automatic identified
outward dialing, was used with PBXs when the CO billed toll calls to
the calling extension.
In
the early days of DDD, many CDOs and PBXs were not equipped for ANI.
In such instances, the CAMA offices on which they homed might use
ONI, or operator number identification; that is, the operator would
be brought into the call to obtain the calling number verbally and
enter it into the billing record. With PBXs, the term QZ billing
referred to ONI for per-extension billing. Early Centrex CU,
provided by a PBX on the customer's premises, included (A)IOD and
allowed the telephone company to phase out the less profitable QZ
billing.
Today, Centrex is only provided by CO switches, almost always
computer controlled to simplify billing and other features. Thus ONI
and separate devices for ANI are not needed. The term ANI itself is
now usually used in connection with calling number ID, where the
number of the calling line is passed to the called party via CCIS
and made available concurrent with ringing the phone. Another change
has come about as a result of having several long distance carriers,
some doing their own billing. When this is the case, the first toll
switch takes on a sort of CAMA function, and the originating CO must
pass forward the identity of the calling line.
At
present, PBXs can obtain DID unbundled from billing, and usually
keep their own CDR records for cost allocation. Thus the several COs
on which they may home for outgoing calls need not provide billing
by extension number. This is just as well because AIOD usually
worked with only one CO, and PBXs were not able to obtain proper
billing for calls going through switches via FX or WATS lines, tie
trunks, etc.
In PBX and Centrex service, there are
occasions where a billing or account code must be added to the call
record (as when a lawyer wants to bill not only the cost of the
phone call but professional time to a particular client). Similarly, unlocking codes may have
to be recorded to insure responsibility. With stored program
systems, it is no great problem to allow for these extra digits, and
to add them to the call record when necessary, although maintaining
compatibility over several generations of software needs careful
attention.
Detail-billed calls usually provide the customer with answer time
and call duration. Often the call record includes answer and hang-up
time from which duration is later calculated, although modern
switches have no difficulty making such calculations themselves.
PBXs and other equipment on customer premises are seldom provided
with answer supervision by the CO switches on which they home,
although an indication of hang-up is available. As a result, many
PBXs identify a call by its hang-up time and calculate duration from
an estimated time of answer. One algorithm assumes a call is
answered a selectable interval after the last digit has been
outpulsed. Shorter calls are rejected from the billing process,
sometimes incorrectly, as having been unanswered, while no answer
after 10 rings may appear as a valid call.
Where the information is available, off-hook time, dialing time, and
ringing time or number of rings may be recorded for traffic
purposes, while circuits used and the disposition of calls that are
not completed can be stored to facilitate maintenance. Availability
of this sort of information can increase the value of a PBX or CO
switch considerably. Various other pieces of information, including
billing indexes (WATS, EAS, toll, coin phone, etc.) and trunk used
may also be recorded.
Early Bell System AMA records were made by punching holes in wide
paper tape, and several entries per call were used to reduce relay
memory in the switch. The first entry included the calling and
called numbers, the trunk number and various other data. The second
entry recorded only the trunk number and the answer time. The third
entry recorded trunk number and hang-up time. Off-line processing
sorted on trunk number, and in reverse order. Thus, if it didn't
find the second and third entries, it knew that the first entry was
for an aborted call.
Modern computer memory being smaller and cheaper than relays,
single-entry recording is now more attractive. Thus buffers in
system RAM assemble all the data concerning the call and only pump
that data out to magnetic tape or disk when the record is complete.
Hard disks are preferred over tape. In addition to low cost, they
have the advantage of being able to record each individual call
record as it is completed. This is more convenient than accumulating
a block of records needed for efficient recording when a tape must
be brought up to the proper speed, and then stopped when recording
is finished.
The relation between billing and directory
As
has been mentioned, some PBXs include the telephone directory and
equipment records as part of their database. In a business, where
expenses are charged back to each department, the relation between
the billing software and the directory and equipment records must,
of necessity, be quite close. In the first place, a bill needs more
than an extension number to identify it. The responsible user's name
must be added and, to simplify delivery, the appropriate mail stop
or other internal address should be included. To control costs
properly, the user should be responsible for equipment as well as
usage; otherwise, everybody will want a phone with 50 buttons.
In
addition to an alphabetical listing, most internal business
directories include a sort of yellow pages in which people (and
support items such as conference rooms, labs, etc.) are listed by
function. This reflects the company's structure, and makes it easier
to locate someone to deal with a specific problem even when names
aren't known. The bill-back process also uses this structure: the
summary of phone costs for each work group will be made available to
supervisors, supervisory summaries will be provided for department
heads, and department summaries to divisional directors, on up the
organizational chart. In addition to their value in cost control,
such summaries are far more useful in budgeting than stacks of
individual user bills.
Central office switches, being far larger in size than PBXs, usually
store billing records off line and have them processed elsewhere on
main-frame computers at telco billing centers. Similarly, plant
records and directory assistance data bases are located on separate
systems. Although telephone company billing, directory and office
records show some of the same relations as those found in business,
the enormous difference in size requires different approaches. This
is unfortunate because new services such as 911 and calling number
ID could profit by having direct access to the directory/equipment
number translation and customer name and address. The key thing that
must be remembered in the design of both public and private systems
is that all these functions are related, and their software should
not be developed by isolated groups of programmers for use on
isolated computer systems.
Traffic
Internal circuits in any switching system (signaling detectors and
paths through the matrix, for instance) must be monitored for
traffic purposes. Even more important, traffic on trunk groups to
other switches must be measured. In either instance, if there are
too many circuits, money is being wasted; if there are too few,
service is degraded, and the opportunity to earn money is being
lost.
In
general, circuit groups are monitored for total duration of use
(occupancy) and "peg count" (number of calls), all during an hour.
Hourly measurements are usually used because most phone calls are
appreciably shorter than an hour and traffic activity is relatively
stable in morning, afternoon, and evening calling periods for
somewhat longer than an hour, allowing mathematical models to assume
"statistical equilibrium." Telephone companies often measure traffic
at both ends of various trunk groups simultaneously, with the
measuring intervals synchronized for greater accuracy. Note that for
traffic purposes, occupancy includes non-paid holding time such as
that needed for signaling and ringing (prior to CCIS), and peg count
includes unsuccessful as well as successful calls. This, of course,
differs from billing requirements.
Units used for occupancy have been minutes per hour, CCS per hour,
and Erlangs, or hours of use per hour. Erlangs are numerically equal
to the average number of circuits in use during the hour and give
immediate information. Unfortunately, many tables used for traffic
administration are still given in terms of the CCS which is now
obsolete. A CCS can be thought of as a minute 100 seconds long
(Centum Call Seconds); thus there are 36 CCS per hour. To obtain the
average number of trunks in use when given data in CCS, divide by
36.
In
early switching systems, electromechanical scanners built with
rotary switches were available to count busy trunks in a trunk group
every ten seconds (360 times an hour); the count on a message
register acting as an output would thus read directly in tenths of a
CCS. If read hourly and reset, CCS per hour could be obtained.
Otherwise, the count just accumulated. Designers of modern systems
have all too often followed this procedure, providing the unwary
administrator with information over an undetermined period of time.
Traffic studies in older systems were only made occasionally, and
required considerable manual effort to carry out and interpret.
Modern systems can accumulate information continuously, store it for
later study, and present it in a variety of useful formats. This
makes it easy to find "busy hours" in different trunk groups, and
lets network designers take advantage of the way sources with
different busy hours can be packed into a smaller number of trunks.
Continuous recording of hourly traffic information shows clearly
variations as a function of time of day, day of week, week in month,
and season of the year. Without such information, optimum designs
are very nearly impossible.
A
traditional measurement, "mean time to dial tone," is often recorded
in central offices and duly reported to regulatory bodies.
Unfortunately, its meaning has changed in recent years. In the days
of manual systems, a similar measurement, "mean time to answer,"
made a certain amount of sense because telephone offices were not
always properly staffed in the middle of the night, and emergency
calls were sometimes delayed or ignored. In automatic switches, the
full complement of signaling equipment is always available, and in
the middle of the night, when little of it is in use, dial tone is
nearly instantaneous, reducing the overall average.
In
heavy traffic periods during the day, however, mean time to dial
tone can sometimes alert management to a lack of signaling
detectors, but its main value lies in detecting too high a
concentration ratio in a line group, or processor overload when very
large numbers of call attempts occur. Note that a call attempt, even
if unsuccessful, requires almost as much effort from a system's
control as a completed call. In certain circumstances such as
outgoing telemarketing, call attempts may be an order of magnitude
greater than the number of successful calls, and control capability
as well as outgoing trunk groups, engineered on the basis of "calls"
or "call completions," may lead to excessive "mean time to dial
tone" symptomatic of more serious problems.
Most
traffic measurements are designed to adjust the size of trunk groups
and groups of service circuits; however, it does little good to
engineer a trunk group to carry the offered traffic at the right
grade of service when traffic is not being routed economically in
the first place. Proper configuration of a network depends on
point-to-point data which is best obtained from billing information.
Outgoing traffic from each node is all that is needed; the
destination code allows sorting by destination. If a matrix is
constructed with sources as rows and destinations as columns, the
sum across a row equals the total traffic a node originates, while
adding a column gives the traffic received by a given node from all
the rest.
Measuring traffic from nearby switches to each other as well as
their combined output to remote regions, as would be needed even by
a flattened hierarchical network, can easily be provided by modern
systems, and appropriate routing laid out accordingly. For proper
network design, it is highly desirable to have software that can
make direct use of both traffic and billing measurements in machine
readable form. Needless to say, switches should also be designed to
provide these outputs in some sort of a standard format.
The
use of traffic information in diagnosing switch and trunk faults
will be discussed in Chapter 8.
Traffic information for automatic call distributors
Automatic Call Distributors, whether stand-alone or built into PBX
or Centrex systems, have special needs with regard to traffic.
Specifically, they deal with clients often waiting in queues for
service, agents who provide that service, and supervisors
responsible for agent behavior. Supervisors need real-time knowledge
of system traffic so that they can optimize use of the agents
available, while system administrators need archived information to
plan for the longer run.
In
general, ACDs have more incoming trunks than agents, and queuing is
required to be sure that incoming calls are handled efficiently and
fairly. The purpose of queuing is to make better use of expensive
resources; in the case of ACDs, this means agents. Queuing is seldom
used in designing trunk groups in public toll or private tie-trunk
networks because ARS is usually more effective in obtaining full use
of trunks, and "instant" service is more convenient for customers.
ACDs, however, make extensive use of queuing for agents most of the
time.
Because queues only exist when all suitable resources are busy,
systems based on queuing tend to run at nearly full occupancy.
However, most ACD agents are not available 100% of the time because
they must write up orders, make notes, or carry out some other
business-related work after a call is over. An agent's terminal is
usually made busy during such tasks, so an ACD traffic system has to
measure both the talk time when the agent is connected to the
customer, and the work time which follows.
Although measuring the number and duration of calls handled by each
agent is important for a variety of reasons, it provides almost no
clue about the grade of service encountered by the caller. For that,
the system needs to display the current, average and peak number of
calls in queue, average and maximum delay, number of calls which
drop out of the queue before reaching an agent, etc. All such
information is needed by the ACD supervisor to deal with immediate
staffing concerns. Further, if the number of calls waiting can be
displayed to agents, they can adjust their work patterns
accordingly, speeding up if the queue is long and giving a little
more personal attention if the queue is short.
Because ACDs are particularly sensitive to daily, weekly, monthly
and yearly traffic cycles, history files are necessary for planning,
scheduling vacation and break time, and managing other functions.
Ideally, the system should make appropriate projections for the
immediate future based on current traffic and past behavior and
display them for the supervisor. It should also make longer range
projections available to those who manage the system.
How
much traffic information should be kept on line, and how much should
be delegated to an off-line computer is an option which differs from
one designer to another. Hard disk systems make internal archiving
relatively easy, but the availability of inexpensive mini-computers
and powerful PCs, along with a wealth of specialized management
programs to run on them, offer other approaches. As it happens, a
great many ACD functions work in conjunction with a main-frame
computer (catalog or reservation system, for example); thus there is
a tendency today to allow these computers to have access to many ACD
control functions, interfacing via "open architecture" to the
switching system. Indeed, some PBX/ACD systems have been designed to
act as peripherals on the computer which controls the rest of the
business.
Some
of the earliest ACDs were used by the telephone industry for
directory assistance; prior to that, manual switchboards had many
staffing requirements which correspond to those of ACDs. Force
Administration Data Systems (FADS) were highly developed in the
1920s and 30s, and have been used for guidance with ACD management
in modern times. The term FADS would seem more logical to retain
compared, for instance, to MIS (Management Information System),
because MIS applies to many different kinds of systems while FADS is
more appropriate to groups of agents, attendants or operators.
PRESENTATION OF DATA
There is no real point in collecting data if nobody is going to look
at it. The principal reason why system data is often ignored by
administrators is that designers of both hardware and software
apparently give no thought at all to its presentation. By and large,
"human factors" is as important in the design of printouts and
displays as it is in the design of switching systems and station
apparatus.
Printouts
Many
switches store important traffic data internally and print it out
(usually via an RS-232C port) on demand. Unfortunately, some insist
on printing out columns of numbers without headings, requiring the
administrator to look up their meaning in a separate book; this is
clearly not the way to do things, but it has provided a niche market
for PC software developers to exploit. Raw traffic information is
down-loaded to a PC which then sorts, summarizes and provides useful
outputs showing date, time, all column headings and other
explanatory information and even tentative projections for future
action. For companies with several different kinds of switching
systems in their networks, such software, with a "front end" for
each make of switch, can provide management with uniform reports for
easier interpretation.
If
the reader has to reach for a hand-held calculator to interpret a
printout, the printout is a failure; computers can add across and
down and provide sub-totals far more easily and accurately than
humans. If a printout has to be delivered on a dolly, it may again
be considered a failure. The purpose of data processing is to ingest
huge quantities of raw data and then provide meaningful summaries
displayed on a minimum number of pages, with "exception reporting"
emphasizing areas which need attention.
Individual telephone bills have traditionally listed calls made by
each user more or less in the order made. However, sorting by called
area code or by called number is a possible source of revenue or
good will for telephone companies, and can be a convenience for
business administrators. Sorting by account code is also useful for
law offices, defense contractors and other businesses where a person
may work on several different projects during the day. Multi-line
systems such as key systems, PBXs, and Centrex, in addition of
billing by each extension, also need to provide sorts and summaries
corresponding to various levels in the company hierarchy for
budgeting, cost control, and abuse limitation as has been mentioned.
Electronic displays
In
the past, telephone systems have made extensive use of lamps, on,
off and blinking at various rates, to convey information. When
computers took control, more possibilities became available. In
particular, computers could operate "dumb" terminals to allow full
alpha-numeric and later graphic input and output. PCs quickly
replaced terminals, adding another level of versatility. But liquid
crystal displays and touch screens, built into electronic telephones
or sitting next to older conventional sets, offered an even more
universal opportunity for communication between human and machine.
Both
LCDs and light emitting diodes (LEDs) have been used to replace the
functions of older incandescent lamps; however, different colored
LEDs and the ability of LCDs to display text and graphics make for a
great variety of possibilities. For full use, a separate signaling
channel between the switch and the display is vital. Even the
earliest electronic phones with PBXs recognized this, and ISDN
telephones follow up with their standardized D channel.
As
will be discussed in Chapter 5, it is relatively easy to design
modern multi-line telephone sets that show which lines are busy, on
hold, or idle, indicate the presence of a message in a message
center, etc. Most PBXs will display the number and even the name of
the caller on an intra-PBX connection, and some have allowed the
attendant, answering an outside call, to type in the calling party's
name and number for similar use and to facilitate calling back.
Public networks have followed suit with Calling Number ID (based on
CCIS), and should have little trouble in displaying the name of the
calling party in addition to or instead of the number.
Automatic call distributors require special attention with regard to
traffic; unlike billing information, which is needed daily in hotels
and hospitals but monthly in most other situations, and traffic
information which may be studied three or four times a year, ACDs
must know what is going on continuously in real time. It addition to
lamps flashing faster and faster to suggest the length of queues to
agents, supervisors need more detailed information that can best be
provided on video display terminals. The number of calls being
served, the number of calls waiting in various queues, etc., can
often be presented better with graphics than with tables of numbers.
Although small printers as well as VDTs have been used in the past,
PCs with suitable programming are more desirable for presenting FADS
data today. PCs relieve the PBX control of the effort of formatting
displays, and can easily store traffic history files and provide
printouts when necessary. However, it is important that the switch
collect all the FADS information needed (such as the number of calls
abandoning prior to reaching an agent, etc.) because obtaining this
information elsewhere is almost impossible.
OTHER DATA PROCESSING
FUNCTIONS.
A
modern telephone system with its powerful control computer and
wiring into every nook and cranny of its environment can offer many
possibilities in addition to phone calls.
External Computing
Large PBXs are often controlled with two computers to insure
reliability; if one fails, the other takes over. Because the standby
computer is not doing useful work, some designers have pressed it
into other service until it is needed in an emergency. For instance,
it can be used to process payroll and other business functions. We
have seen that the telephone data base already has much of the
necessary information available, and could easily accommodate the
rest. There is no reason why this sort of thing shouldn't be
encouraged as long as the basic communication function of the system
is not impaired, but the general availability of inexpensive
computers minimizes the possible savings.
External Control
Computer controlled systems have scanners that monitor internal
supervisory points and distributors that can operate relays or other
activating devices. These "eye and hand" functions need not be
limited to points internal to the telephone system. Clearly,
scanners can monitor fire and burglar alarm sensors, distributor
outputs can control air conditioning or heat, and software can be
written to relate scan points, individually or in groups, with
distributor outputs for a variety of purposes, and to display
appropriate information on a VDT. Whether the telephone control
should do the actual work, or simply collect and format information
for delivery to an external Energy or Property Management System is,
once again, a matter of individual choice among designers.
Data and Other Non-voice Connections
Telephones are universally available today, and voice connections
can be established immediately between almost any two locations on
earth. However, there has always been a need for more than voice
communication. Indeed, data transmission in the form of telegraph
preceded the telephone by some 40 years, and TTY networks, provided
by both telephone and telegraph utilities, have until quite recently
been used for text. Facsimile has been available for decades for
image transmission via telephone channels, mostly for weather maps,
wire photos for the press services, and fingerprints for law
enforcement. Only since Carterfone and the standardization of
transmission among many manufacturers has it become common in small
businesses and even residences. Data transmission itself, between
computers or from remote terminals to computers, became relatively
common with time-sharing systems in the 1960s, and blossomed with
the widespread use of personal computers about 1980.
Data
transmission on conventional analog telephone lines requires a
modem, or MOdulator/DEModulator, to convert a digital signal into
something that behaves like voice and can, as a result, be sent via
a voice channel. A modem puts out a whistle at about 1800 Hz, and
the digital signal to be transmitted changes the frequency,
amplitude, phase, or some combination thereof to various discrete
and easily differentiated symbols. Early modems, circa 1960, ran at
300 bits per second; as of 1991, modems at 2.4 and 4.8 Kbps became
inexpensive enough to be widely used with home computers, only to be
superseded within a few years by modems running at 9.6, 14.4 and
28.8 Kbps, pioneered by business use. Modems built into fax machine
run at 9.6 Kbps and higher rates.
As
we have seen, T-carrier uses 64 Kbps in a "DS0" channel which is
normally used for voice. One need not have a PhD in communication
science to recognize the waste involved in first converting a data
signal into a whistle and then coding the whistle, as though it were
voice, into the DS0 format when one could map it directly into the
bit stream in the first place. Western Union did just this, using
DS0 channels for local high speed data distribution, about 1970.
Companies such as Vicom used Western Union specifications to develop
T-carrier channel banks that could accommodate either voice or data
channels, and could even work with digital microwave radio systems.
This kind of thinking ultimately led to ISDN.
Starting in the late 1970s, digital PBXs began to offer circuit
switched data transmission in conjunction with digital telephone
sets; with the voice codec in the set itself, digitized voice, data,
and control could all be multiplexed into a single bit-stream
between phone and line card, and data rates could approach 64 Kbps.
Visualizing that desktop terminals and later, PCs, would connect to
mainframe and mini-computers, both AT&T and Northern Telecom
developed PBX interfaces to computers at the "DS1" rate of 1.544
Mbps, or 24 DS0 channels, to handle multiple data connections.
Computer manufacturers used these specifications to accept
multiplexed bit streams directly and separate them in the computer
for processing. Northern Telecom's CPI (Computer to PBX Interface)
simply multiplexed 24 digital channels onto two pairs, while AT&T's
DMI (Digital Multiplexed Interface) provided 23 channels and a
separate signaling channel. The DMI approach was intended to
approximate the ISDN Primary Rate Interface (PRI). Most PBXs can
interface DS1 transmission directly, either in the conventional
format or ISDN PRI, but local area networks (LANs) have very nearly
taken over data connections within business offices.
Going beyond the PBX, universal standards for mapping data into DS0
or DS1 bit streams (rate adaptation) will be required; ISDN appears
to be the only hope of such standardization. Circuit switched
connections based on one or more channels at the DS0 rate (often
combined in an external "inverse multiplexer" to support a broadband
channel) are being used for data and, more commonly, video
teleconferencing applications, but the digital telephone network is
still used mostly for analog voice.
An
interesting development is the ability of SS7 to carry information
across the public network for delivery to the control of a PBX or
ACD. When calling number ID, for instance, arrives with a call, the
ACD control can pass that number to the computer handling the
company data base. The computer then calls up the customer file
matching the calling number, delivers it to a display at an idle
agent position, and tells the ACD control where to connect the
incoming call. Usually the display is connected to the computer via
a LAN, but use of one B channel in a BRI for data while the other is
used for voice would have a sort of natural elegance.
TERMS TO REMEMBER
-
ROM, PROM, RAM
-
Generic vs. building block program
-
Translation
-
Access Code, Area Code, Office Code
-
Tandem Switch
-
Restriction
-
Cut-through
-
Centrex
-
PBX, ACD
-
Erlang
REVIEW QUESTIONS
Click Here for
Answers
1.
Name three kinds of information stored in a telephone switch.
Suggest a kind of memory for each.
2.
Give some examples of per-call information.
3.
What is COS? Give illustrations.
4 If
a line can be given up to 6 different features, how many class marks
are required?
5.
What is the difference in a building-block and a generic program?
6.
How does a computer controlling a switch deal with many calls at the
same time?
7.
How can control increase the number of lines and trunks it can
serve?
8.
What is "translation" in a telephone switch?
9.
Does COS relate to a directory or to an equipment number?
10.
What is a theoretical office? How does modern technology deal with
situations where a theoretical office might be used?
11.
What is pretranslation, and why is it used?
12.
Does pretranslation always work? If not, what alternatives are
possible?
13.
What is the difference in a route code and a destination code?
14.
What is the purpose of dial tone?
15.
Why did SXS not need multiple dial tones in tandem nets?
16.
Is a central office switch limited to one office code?
17.
Must a PBX use an access code to get "outside"?
18.
How did area codes and office codes used to differ?
19.
What is meant by three and six digit screening?
20.
List two advantages of a hierarchical network.
21.
Are these advantages still relevant?
22.
Explain the analogy between progressive and common control as
applied to trunk connections in the text.
23.
What is the difference between restriction and toll diversion?
24.
Can restriction substitute for ARS?
25.
What is "cut-through" operation and why is it popular?
26.
Why should overlap outpulsing not be used with DTMF?
27.
Why was the original automatic message accounting system based on
three entries?
28.
What are the advantages of flat-rate billing? The disadvantages?
29.
What are ANI and AIOD?
30.
How does traffic information differ from that collected for billing?
31.
You are told that a group of 6 trunks is carrying 220 CCS in the
busy hour. How do you know this is untrue?
32.
List some special traffic recording needs of ACDs.
33.
Why should some effort be taken to present data gathered by a switch
in a format that is easy to read and understand?
34.
What advantages does a PBX have for non-telephone control and
management in the area where it is installed?
[ Top ] [
Next Chapter ] [
Table of
Contents ] |
