Voice
Communication in Business Volume 2
Essays on telecommunications,
1981-2002
Fred
Knight, the illustrious editor of Business Communications Review,
called me one day when an important manuscript from somebody else
had not materialized. I flang myself into the breach and produced
the following on PBXs that could handle both voice and data for the
May-June, 1988, issue, rescuing him from blank pages.
Business
Communications Review put together a huge table to accompany the
article, based on material from the Business Communications
Review Manual of PBXs, which Jerry Goldstone and I wrote and
updated for over a decade.
Comparing PBXs For
Voice-Data Integration
(Business Communications Review, 1988)
Introduction
It has always seemed to
me that one of the main reasons for making a PBX digital is so that
it can handle voice and data the same way, both internally and in
external connections; once a signal is coded into a digital format,
a bit is a bit is a bit, and transporting that bit should be easy
and straightforward no matter what it represents. Others, of course,
have disagreed. Back in the 70's, when I'd visit PBX booths at trade
shows and ask about putting data through a PBX, I'd get the most
withering and disgusted diatribes about how PBXs were for voice,
anybody knew that.
That's not my table. I
don't do windows.
Now, of course,
everybody boasts about integrating voice and data in a PBX in a
variety of ways, some of which may actually be useful. However, the
gap between those who design IVD systems and those who must use them
is so wide that one wonders if the two camps will ever be able to
communicate using either voice or data techniques.
To do something complex
like handling voice and data in a PBX requires a basic understanding
of the situation into which inventors would like to thrust IVD. In
the first place, all businesses have telephones. Some have a few
single line sets or key systems. Others have PBXs and still others
use Central Office switching or Centrex. But in all cases, the great
majority of telephone calls handled are regular voice connections.
Right off, this suggests that, at least in the beginning, the
incremental cost of adding data to the PBX should be very small
indeed, perhaps proportional to the proportion of data calls to be
handled.
That this has not yet
happened is quite evident. Adding data capability to a PBX is viewed
by the designers and manufacturers as a value added feature, one for
which the customer should be eager to pay a premium price. To date,
customers are proving this concept wrong in droves, but part of the
problem is that the telecom people in most businesses are different
from the data processing people, so that the customers buying LANS
and other exotica are not the same ones who buy PBXs.
What is the case for an
IVD PBX vs. some other approach? In many instances, there may not be
a case at all. In particular, when a terminal is always associated
with a fixed port on a nearby main-frame computer, and is connected
for the entire day (as in some CAD/CAM installations, for instance),
there is no reason to insert two ports on a PBX and a nailed up path
through the PBX's switching matrix. Simply go direct and you have to
come out ahead.
To get the full benefit
from IVD in a PBX, the data devices must need flexible
interconnection on demand, just as telephones do. Then the universal
and ubiquitous wiring of the world-wide telephone system is of
value, and the PBX, as one stage of switching which provides this
flexibility on demand begins to make sense.
To summarize, a PBX may
be useful in handling data where FLEXIBLE data connections are
required. It may be viable if it can do the job so inexpensively
that the data people HAVE to give up their parochialism and talk to
the telephone people.
History
One reason to suppose
that people really want to put data through telephone systems is the
fact that modems exist. People buy modems, apparently in
considerable quantities, to translate data signals from terminals
and computers to something which will go down a voice-frequency
channel used for human speech.
Modems used to be
expensive. One spoke of them costing "a buck a bit" and a simple
103A compatible modem might cost $300. Similarly, a high-speed modem
running at 9.6 Kb/s would go for something in the neighborhood of
$10K. Prices have come down considerably, and modem capabilities
have increased greatly so that today you can actually handle 9.6
Kb/s data on dial-up connections, with 14.4 Kb/s possible at higher
cost. But high speed modems are still expensive.
This is what led Danray
to try something different more than ten years ago when they became
the first PBX to offer IVD. Note that the Danray, rest its soul, was
a four-wire analog switch, not the most likely candidate for
handling digital data. But it used proprietary sets with three pair
wiring: one for voice out and signaling incoming, one for voice in
and signaling outgoing, and a third for power. Data was added to the
third pair using a simple terminal interface adapter, a separate
data switching matrix run by the same system control was added, and
voila: internal data switching at 9.6 Kb/s existed, eliminating some
300 high speed modems for Tektronix, a company that needed a lot of
CAD/CAM with information between terminals and computers running at
high speed. Well, it wasn't quite that easy, but Danray brought it
off and showed that the job could be done. (Read the whole story by
Brian Paxson in the July-August, 1979, Business Communications
Review).
Northern Telecom bought
Danray, and after much heated and lengthy internal discussion, the
Danray people convinced the telephone people that data would,
indeed, go through a digital PBX even better than through an analog
PBX. Northern then announced IVD. The SL-1 telephone sets of that
time, which used one pair for conventional voice and one pair for
signaling, simply added data to the signaling pair which was running
largely unused.
At the southern tip of
San Francisco Bay, Rolm sits on the far side of a large amusement
park from Northern Telecom. Rolm, a former computer company,
responded to this novel idea of putting data through a PBX by adding
data to its new ETS-100 telephone set. Unfortunately, the ETS-100D
could only talk to the standby system control on which some rather
good message center software was running; this tended to limit the
scope of the data offering. Later, Rolm introduced the ROLMphones,
connected to the PBX by a protocol called ROLMlink using a single
pair, Northern Telecom introduced Meridian sets with a different
protocol which also ran on a single pair, and salvos of glossy
brochures were fired back and forth across the amusement park. In
the meantime, InteCom, son of Danray, introduced its IBX, designed
from the beginning to use its digital properties to handle voice and
data, making it a true third generation PBX in my book.
To get the full benefit
of real IVD technology, the codec, which converts analog speech into
a digital bit stream and vice versa, has to be in the telephone set,
or at least somewhere near it. Once voice is converted to bits, it
can be multiplexed with data and signaling bits and sent off to the
line card in the PBX cabinet. Thus the wiring and the port are
shared, as are system management and maintenance.
The end-to-end digital
signal, whether voice or data, is then relatively immune to noise.
Digital voice has other advantages: there is no change in level,
phase shift, or any of the other parameters that, in an analog
world, degrade communication. But the real point in the whole
exercise is that data, by NOT being treated as an analog signal,
bypasses the PCM coding process, enters the digital channel
directly, and is no longer inhibited by the analog 3 Khz bandwidth.
It can then take full advantage of the standard 64 Kb/s bit stream
used to code voice in T-Carrier and all compatible switching systems
including PBXs. This is, perhaps, the principal advantage offered by
IVD.
Other companies
introduced products with the same design objectives, and the whole
array of third generation systems came on the market. Needless to
say, some of the older systems retrofitted to handle data, some
quite cleverly. AT&T, for instance, added data capability to the
analog PAM Dimensions (I haven't yet found a customer who actually
tried it, but the approach was quite good from a technical point of
view).
Comparisons - Line Card To
Set - Circuit Switching
So where do we stand
today? With everybody doing IVD, can we just plug tinkertoys
together and have data utopia? Not quite. Nobody does the job quite
the same way, and each solution has its partisans. Let's consider
the path from set to line card first, just to see how designers vary
in their solutions.
In general, we have for
the physical medium either a single pair, as with Rolm/IBM's
ROLMlink or Northern Telecom's Time Compression Multiplexing, or two
pairs, one for each direction of transmission, as with AT&T's DCP,
NEC's Protims, or InteCom's slightly different approach. When one
uses space division, design is somewhat simpler; with a single pair,
directional separation (set to PBX vs. PBX to set) requires more
hardware. ROLMlink uses electronic hybrids; in the ISDN path between
U and V interfaces, echo cancelers are added to improve separation.
Time compression multiplexing (ping-pong), in Northern Telecom's
Meridian sets, requires each end to send its information twice as
fast so that it occupies the pair slightly less than half the time.
In this way, each direction of transmission has the wire all to
itself while it is sending.
The Telex 1200/5000
(originally the Stromberg Carlson System Century, some time ago)
uses a combination of space and time division in a fairly unique
way. Two pairs are used, one in and one out, for three telephone
sets or data units. The two pairs terminate in a little box near the
sets called an InfoTap; it, in turn, has two pairs going to each
set. One, using ping-pong, handles voice or data and signaling,
while the other is for power.
ROLMlink passes 256 Kb/s
in each direction. It uses 64 Kb/s for voice, another 64 Kb/s for
data, and has 128 Kb/s left over for signaling and other functions.
The Meridian approach has 8 bits for voice, 8 bits for data, 2 bits
for signaling, and a couple of housekeeping bits in each frame, 8000
times a second, for a total of 144 useful Kb/s. On two pairs, AT&T's
Digital Communications Protocol runs 144 useful Kb/s, 64+64+16,
while NEC's Protims for the NEAX 2400 has four 64 Kb/s channels.
InteCom has a somewhat different approach. It runs two 64 Kb/s
channels on each pair, but robs a byte from the data channel for
signaling about 167 times a second. The Telex 1200/5000 has an
effective throughput of 80 Kb/s in its ping-pong segment, 64 Kb/s
for voice or data, 8 Kb/s for signaling, and an additional 8 Kb/s in
an auxiliary channel. From the InfoTap to the line card, the two
pairs have a throughput of 256 Kb/s total for the three voice or
data terminals supported (obviously three 64 Kb/s channels with 64
Kb/s used for signaling).
Another technique that
could be used is frequency division multiplexing. With this
approach, we would have two carrier frequencies (say at 20 and 40
Khz), one for each direction of transmission, and we would let these
carrier frequencies transport our information. Although there is a
good deal of short-haul carrier out there doing data over voice (one
thinks immediately of TelTone, among others), and broadband LANs use
such approaches extensively at much higher frequencies, I am not
aware of any PBX using it for IVD.
Just because one or two
pairs may be used, one should not fall into the trap of trying to
economize on new wiring by not pulling extra pairs. Most of the cost
of wiring is for labor, not copper, so it is wise to pull a minimum
of 4 pairs to each location (terminating them on an RJ45 jack) just
to have the flexibility. The Northern Telecom Meridian sets, for
instance, need power when a hands-free unit is added. Further, a
conventional voice telephone feature, voice announce, needs an extra
speech channel in many cases if it is to work when a phone is in
use. IBM/Rolm's Redwood gets around this very nicely by
"conferencing" the voice announce signal with the distant talker on
the receive path to the listener. Unfortunately, Redwood does not,
as yet, handle IVD.
A number of systems such
as the Ericsson MD-110, the Harris 20-20, the Redcom, etc., take
only one 64 Kb/s channel to the set, along with a signaling channel
that is typically 16 Kb/s. Several years ago, this corresponded to a
1B+D tentative ISDN standard, and, particularly for residential
service, has much to recommend it. However, in business it is easy
to visualize a person on the phone looking at a CRT screen for
information while responding to a phone call. This paradigm is
common today in reservation centers and telemarketing operations,
but it could become quite general and would justify 2B+D rather than
B+D.
Harris is taking full
advantage of the B+D with an approach they advertise as "Data for
free." With a separate D channel for signaling, ALTERNATE
voice/data, as opposed to SIMULTANEOUS voice/data can be quite
effective. If you have a data connection up and operating, the
signaling channel can still sound the incoming call alert at your
set, display information about the call, etc. You can then pause the
data (with an X-on/X-off protocol), take the voice call, and then
return to the data call. Because of the modest cost for such an
approach (no separate port on the matrix nor separate path through
the matrix for data), it has much to recommend it at the present
time.
To go one step further,
some of the ISDN field trials, sharing the 16 Kb/s D channel between
signaling and packet transmission, seem to be working fine. Although
many believe that data transmission in the Megabit range is
necessary, most data today that is going via the telephone network
is running at less than 9.6 Kb/s, something that can easily be
handled via a D-like channel.
Under the circumstances,
it may be of considerable value to rethink the alternate vs.
simultaneous voice/data situation very carefully in terms of
particular installations.
Comparisons - Set To
Terminal
Assuming the telephone
system is ubiquitous, and we can get from any telephone to any other
by well known well understood means, how do we connect our
telephones to our data terminals? Obviously, use of the acoustic
coupler peaked some time ago, along with the white switch-hook
button that one pulled up to short out the phone and connect in a
hard-wired modem. The coming of the RJ-11 jack (along with the
RJ-14, RJ-25 and RJ-45), one of the better results of deregulation,
has made it possible to plug many things such as modems, answering
machines, fax machines, etc., directly into the telephone wiring.
Typically, the associated telephone set is then plugged into another
jack on the unit, and away we go.
But this approach is
based on the 3 Khz voice connection with DC supervision and power
ringing. A digital PBX has, as its main reason for existing, the use
of the 64 Kb/s channel, all the way to the work space, that
T-Carrier has made into a de facto standard. We certainly want to
use the same wiring, cross connect frames, and jacks for analog and
digital signals, but it is not always practical to plug a data
device directly into an RJ-11 jack. What we need is some sort of box
that can accept the DC digital signals that come out of an RS-232
data plug and map them into the 64 Kb/s bit stream.
Northern Telecom's
Add-on Data Module or ADM plugged into the side of the SL-1 set and
did just this. It had little knobs and slide switches like a modem
to match the parameters of the device plugged into its RS-232 port.
The 74xx series digital sets used by AT&T's system 75 and 85 have a
similar box to match their DCP to the terminal. System 25 uses a
different system with an asynchronous data module and two pairs to a
separate data port for data only. In general, there are several
different kinds of boxes, depending on parameters of the data to be
switched.
Some telephone sets,
such as the ROLMphones, have the data board built in at the factory.
When some different data parameter is required, a different set must
be substituted since changing the data board in the field is not
practical. Other systems, such as the NEAX 2400, have data boards
that are easily changed in the field. InteCom started out with
factory inserted Data Option Boards (DOB) but has recently upgraded
to separate boxes called ADI or LDI for Asynchronous or LANmark Data
Interface.
In most PBX families,
the digital electronic sets are designed for the top of the line
voice user, specializing in countless voice features which a heavy
data user might have little need for. Rolm/IBM, AT&T and a good many
other companies are now offering a very simple, usually single line,
digital phone at a cost comparable to a 2500 type set. The purpose
is to use only digital line cards, permitting phones of various
different capabilities to all be plugged into the same ports on the
switching matrix. The difficulty is that these simple single line
digital phones do not usually handle data, although they may be all
the data user requires. Interestingly enough, the ROLMphone 120 can
support the data module, while the ROLMphone 240 basic cannot.
InteCom was one of the
companies to bring out an inexpensive digital voice-only phone, but
they recognized that it was silly to force data users to upgrade to
a more expensive set with a factory installed DOB. Now, all you do
is put an ADI (for example) on the desk, plug the simple digital
phone into it and plug the ADI into the wall where the phone was
plugged originally. The ADI has an RS-232 plug for the associated
data terminal, and it does the multiplexing of voice and data on to
the two pairs to the line card. Thus single line digital sets, which
can be "upgraded" to various kinds of data in the field, are now
available. Datapoint, in its ill-fated digital PBX some years ago,
did pretty much the same thing except for using a conventional 2500
type set for voice.
When looking at various
PBXs with an eye to integrating voice and data, life cycle
administrative costs must be considered. This is why it is highly
desirable to have an entire family of telephone sets, data modules,
etc., all supported by the same line card. Then anything from a
simple single-line set to a multi-button set with a full computer
attached can use the same wall jack, wiring, cross connect and
linecard in the PBX.
Other pleasant features,
pioneered by TeleNova and SRX, make set relocation a snap. With only
one kind of line card and a family of sets that match, physical
compatibility is established. But adding a ROM-based serial number
in the set allows you to plug it in anywhere; the line card can read
the serial number of the set, look up in its data base who has that
set, and transfer the complete COS/COR profile for that set to the
matrix port where it is plugged in. The new Northern Telecom Norstar
key system also uses this feature.
Comparisons - Through The
Switch - Circuit Switching
All the early PBX data
was circuit switched, using a standard voice channel which was
usually 64 Kb/s in each direction. The PBX established a connection
from the calling to the called port, left the connection up for the
duration of the call, and remained transparent to the information
passing through. The alternative, packet switching, only uses
interconnecting facilities when data is actually being transmitted,
and some PBXs use packet switching for data, in addition to or
sometimes instead of circuit switching. For the moment, let's stick
to circuit switching. It has some interesting variations such as
bandwidth allocation which was used by Rolm prior to ROLMbus 295,
CXC, and Tadiran, to name a few.
With the original SL-1
set, voice went analog to the line card where the codec was located
and used one port, while data, on the signaling pair, went to the
line card where it was mapped into an internal 64 Kb/s channel using
a different port. ROLMphones use one 64 Kb/s digital channel for
data and another for voice; in the Rolm CBXs, it was necessary to
map voice from standard 8x8 coding (8000 samples per second, each
coded into an 8 bit mu-law companded byte) into Rolm's proprietary
12x12 coding (12,000 samples per second, each coded into a linear 12
bit word), something which had to be prevented with data. Data was
handled differently, using one voice channel sub-multiplexed for up
to 40 data channels. When more bandwidth was needed for higher speed
data, it could be allocated at the user's request.
The new IBM 9751 PBX
still uses ROLMphones, and preserves 8x8 coding through the matrix.
Thus the signal manipulation necessary for voice can be omitted, and
voice and data can now be treated alike. But not quite. In ROLMlink,
one channel is voice, and one is data. They cannot be interchanged.
But this may offer IBM an advantage. The path through the 9751, like
the ROLM CBXs before it, is the 16 bit parallel ROLMbus 295. If
voice needs only 8 bits now, as opposed to the 12 bits in the Rolms,
the other 8 bits might be used for data at some time in the future,
effectively doubling the switching capacity of the system for
negligible cost.
InteCom works
differently. Its voice and data circuit switching do not really care
what the bits stand for. Each port on a particular kind of port card
can handle one voice-data, two voice ports (as for 2500 type sets or
CO trunks), or two data ports. Wiring from line ports to the
cross-connect field uses two pairs per port; with digital sets, one
pair is outgoing, the other incoming. With 2500 type sets and
trunks, each pair is used two way to a different set. Thus when
InteCom advertises an 8000 port system, it can actually support
16,000 separately addressable entities.
In recent years, much
has been made of the need for a non-blocking switching matrix when
voice and data are to be integrated. Whether or not this is true
remains to be seen; however, when one uses today's technology, it is
just about easy and inexpensive to make a switch non-blocking as to
provide concentration. When there is no particular cost penalty
involved, one might as well make the system non-blocking and be done
with it. InteCom was one of the pioneers of this idea; individual
line groups connect to the group selector via coax or fiber optics;
because of the broad bandwidth available, it costs no more to
provide a separate channel for each port in the line group. At the
group selector, two bytes of memory are required to switch each port
in a small system. Even with redundancy and other expansion, InteCom
maintains a non-blocking matrix built with something like 256 K
bytes of inexpensive RAM.
The new Fujitsu 9600/GTE
Omni IV uses a very similar technology, while Siemens and others at
smaller sizes find no particular cost penalty in being non-blocking.
When this is the case, one might as well be non-blocking as not.
AT&T and Mitel still use
concentration but over a considerable size range they can provide
non-blocking service and at larger sizes they can provide savings
from concentration. After all, if the computer only has ten ports,
there may be no point in providing a non-blocking matrix to access
it.
No matter what the
technology, the general idea is to be able to connect voice or data
terminals together easily and inexpensively, using the same
technology to maximize economies of scale and minimize
administrative costs over the life of the system.
Comparisons - Through The
Switch - Packet Switching
Packet switching is
popular today in LANs such as Ethernet, and is one of the more
interesting developments in data communication. But the packet
technology is simply a speeded up version of teletypewriter
switching from the 1950s. In TTY, each teleprinter hung across the
same multi-drop line. Using either polling or contention, any TTY
could send a message to any of the others. At the start of the
message, there was a "header" containing the identity of the called
terminal; all terminals saw all messages, but the "stunt box" in the
addressed terminal would be the only one to recognize its own
address. It would then turn on the rest of the TTY and print out the
message as it went by.
Packet switching runs
several thousand times faster, has more sophisticated polling or
contention protocols to minimize one message overlapping and thus
spoiling another, limits a given message (packet) to a fixed length
to keep one terminal from monopolizing the system, and adds various
data checking capabilities to minimize errors. The general idea is
to give any one terminal the entire bandwidth available for a very
short time, and then make that same bandwidth available to other
terminals in turn, one at a time. With very high speed transmission,
time occupancy by any one terminal is very low, and many terminals
can share a given facility.
A LAN carries out the
switching function by means of the address in the header of each
packet, and the equivalent of a stunt box in each terminal that can
recognize its own address when it sees it. Thus a LAN, contrary to
popular superstition, is NOT non-blocking. Packet LANS are designed
on a delay (queuing) basis, and all use complex protocols to
minimize simultaneous transmission by two or more nodes. They depend
on "bursty" data to work properly; they can fill your screen very
quickly, and while you are sitting there reading your screen, they
can fill many screens for others.
A number of PBXs have
built in optional Packet LANs: examples include InteCom's LANmark,
Northern Telecom's Packet Transport Equipment, the packet bus in the
GTE Omnis I-III, etc. As one might expect, each of these works quite
differently.
InteCom's LANmark had
some early problems but now seems to be running quite well. Although
data can be circuit switched just like voice, one can choose packet
switching as an alternative. Based on physical groupings of 16
voice-data ports, data within any one grouping can be either circuit
or packet switched, but not both. With the packet switching option,
the time slots reserved for the data portions of each port are
grouped together to provide a combined bandwidth of just about 1
Mb/s through the switch. But to take full advantage of this
bandwidth, the same speed is extended over the two pair wiring to
the LANmark Data Interface at the work location. As with the ADI,
the InteCom digital telephone sets plug into the LDI as do data
terminals. At the moment, LANmark can support selected 3270
terminals and cluster controllers, or Ethernet terminals and access
ports.
During a connection,
packets are constructed in the LDI which attaches headers to data
from the data device (actual content may range from one byte,
typical of 3270 operations, to about 1500 bytes with Ethernet). The
packet goes to the line card where it may contend with information
from a maximum of 15 other data ports in that group; it goes into a
central packet router where the packet is buffered and the header is
read. The packet router then arranges for the path through the
switching matrix to take information from the packet router to the
terminating grouping of LANmark ports. All 16 will receive the
packet in parallel, but only the LDI who sees its address in the
header will accept it. An LDI can be receiving and sending a packet
at the same time and, as a result, is full duplex. Further, each
block of 16 LANmark data ports is independent, and the InteCom can
be moving packets between several different groupings at the same
time.
The GTE Omnis I, II and
III handle data with packet switching only, using a 1.544 Mb/s
packet bus as a separate "switching matrix" for data. Actually, up
to eight of these buses will ultimately be available in a single
switch, expanding its data capability considerably. Information
comes from digital sets to a line card on a single pair, ping-pong,
128 Kb/s in each direction, with voice, data and signaling all in
packet format and mixed together. At the line card, voice is
separated and circuit switched, while data is buffered. A Packet
Router polls each active data port to see if it has a packet
available for transmission. When it finds one, that packet is sent
to the packet router via the 1.544 Mb/s packet bus; the router reads
the header for destination, attaches the identity of the source, and
sends the packet to the destination (which may be on the same or a
different packet bus). Because the packets are short and their
transit speed is high, many bursty connections can be supported
simultaneously.
Northern Telecom's PTE
or Packet Transport Equipment is a line group on the SL-1 that is
arranged primarily for packet switching internally, but can be
reached by circuit switching from other line groups via a
multiplexed loop to the group selector. It is intended to support
the Meridian 4020 terminal, a relatively inexpensive CRT device
which, with the help of applications processors, also accessing the
PTE, can emulate most of the popular data terminals that are now in
use or may be developed in the future. The M4020 uses two pairs from
the set to the line card, one for each direction, and running at
2.56 Mb/s. An option card for PCs using the same transmission has
also been described.
Northern Telecom's
Computer to PBX Interface (CPI) gives the PTE access to main-frame
computers. Some Mb/s of bandwidth are available within the PTE for
packet switching of data, and circuit switching the voice phones
that are part of certain M4020 terminals. The PTE does not support
conventional phones or Meridian digital phones; data from the
latter, however, can reach the PTE via circuit switching through the
group selector and multiplexed loop; at the PTE, it will be packet
switched to the desired destination.
One of the main
advantages of a packet network is speed and other parameter
conversions. The Tadiran Coral PBXs switch data several ways, but in
both circuit and packet switching, use a LAN Packet Assembler and
Disassembler (PAD) to interface the source of data. The PAD is set
for the terminal's speed, parity, start and stop bits, etc., and
accepts information in that form. However, it translates it to a
standard form for transmission at high speed through the switch to
the connected PAD which then hands off the data to its own terminal
in the form desired there.
Connecting To The Outside
World
When one wants to move
data inside a given location, it does not matter whether one uses a
PBX or a separate LAN, and there is no particular reason why the PBX
cannot be analog, or digital in some format other than T-compatible
PCM. However, voice calls going outside the system are a major part
of the traffic; it stands to reason that data calls must also be
able to go to other locations as well.
To use the public
network which, at the moment, is made to appear as though it were
still analog although it is constructed of more and more digital
facilities, modems are required. With IVD, modems are not needed
internally, so, for external data calls, two PBX connections are
required: terminal to modem and modem to CO trunk, the latter being
a conventional voice connection. This requires the PBX to be fairly
smart so that it knows which kind of modem to use, and how to make
the connection. For incoming calls, this is even more complex.
However, most PBXs today support modem pools.
With the sudden
availability of T-spans in the last couple of years, digital
facilities can be run directly from one PBX do another, or from a
PBX into one of the mostly digital long distance networks. This can,
under some circumstances, allow modem pools to be omitted, and
digital information to flow end to end through a public network.
This, of course, is why T-compatible PBXs are so important; they
will ultimately permit direct connection through the public network
without modifying the digital signal.
However, at the moment,
a T-span with its 1.544 Mb/s in each direction, designed for 24
voice paths, can support far more than 24 data connections at
conventional speeds like 1.2, 2.4 and 4.8 Kb/s. Indeed, data
multiplexers which can put between 200 and 300 conventional data
channels on a standard T-span abound, and data people are putting in
point-to-point networks at great savings. However, these low speed
channels are not suitable for transmitting voice.
On the other hand, the
voice people are also discovering opportunities to save. Adaptive
Differential PCM, by transmitting only the changes in a PCM signal
from one sample to the next, can cut the bandwidth for voice in
half, allowing a 1.544 Mb/s T-span to carry 44 to 48 voice channels,
doubling its capacity for the price of the ADPCM unit on each end.
Then, with 48 channels to work with, TASI, or time assignment speech
interpolation, originally developed for the Atlantic Cables but now,
through the wonders of LSI, available inexpensively for other
channels, can double the capacity again, permitting something like
96 toll grade voice channels on a single T-span. But ADPCM does not
work with 8 bit bytes that represent data rather than amplitudes of
voice samples, just as TASI will not work with data modems that
establish continuous carriers.
Thus, the variety of
digital techniques available today seems to be separating voice and
data ever further, rather than integrating them. But this is to be
expected: in limited applications, one can take advantage of special
considerations to create economies.
In a public network,
where one wants the ability to connect on demand to millions of
different locations, a different approach to economy must be
considered. One must minimize the number of different options to
maximize the number of points that can be interconnected. Whether
one overall universal network or several specialized networks which,
for reasons of economy, may not reach all possible points, will
ultimately result, is anybody's guess. The longer we wait for ISDN,
the more variations we see being introduced.
What About The Future?
So what do we do today
when we have to acquire a PBX but we want to be sure it will work
with ISDN and other future plans? Should we ignore all different
proprietary sets, forget all the proprietary ways of handling data
internally, and insist on ISDN compatible telephone sets and
protocols?
It seems to me that such
a course is unrealistic. If one already has proprietary sets or is
considering using them on a new PBX, there is nothing at all wrong
with going ahead. ISDN has dragged its feet for ten years already,
and may never really get going. Further, the great majority of
people involved with CCITT are from telephone administrations world
wide, vastly more interested in central office equipment and
residential telephones than in business telecommunications. They can
be counted on to continue to pursue their principal interests at the
expense of the business minority.
In particular, the two
pair connection, from the S or T interface to the telephone set,
while similar to AT&T's DCP, would appear to be more costly for a
PBX over time simply because each cross-connect requires two pairs
rather than the one used with Northern Telecom's Meridian sets or
IBM's ROLMphones. As we have seen, a number of manufacturers use two
pair wiring to the set, but single pair wiring has some major
advantages.
Second, it is not clear
at the moment how circuit, packet and fast packet switching will
actually be employed in future public networks. One convenient
justification for ISDN is that the 64 Kb/s channels of T-Carrier and
digital toll switches interconnected by fiber optics have already
cost justified end to end digital channels, paid for them, and made
them available by saving money on voice calls alone. To delay using
these channels for data, image and other signals in addition to
voice, or to charge more for the same channels for handling a signal
which, at the end points only, can be perceived as being something
other than voice, would not be in the best interest of the customer.
It would seem, then,
that the principal requirement on a PBX would be the Primary Rate
Interface or PRI. The customer should insist that, whatever the
internal proprietary data formats, the PRI should be universal. Then
data from a Meridian SL-1 can be dialed direct to an IBM 9751, or a
terminal in an InteCom can communicate through a public network with
a quite different terminal on an AT&T System 85. If the PRIs on all
PBXs look the same from the outside world, and all map data into the
64 Kb/s bit streams in the same way for outside calls, no matter
what they do internally, we can at least get started. With some sort
of relatively high speed data capability in place, we can move on to
specialized packet networks, fast packet switching, etc., on an
evolutionary basis. But to continue to delay using what we already
have while chasing some future will-o-the-wisp would be almost
criminal.
One of the problems with
modern technology is that it is too good, too creative, and offers
too many possibilities. If we spend all our time trying to find the
ideal combination before we make a choice, we may find ourselves
still using cans and strings in the twenty-first century.
[
Top ] [ Next ] [
Table of Contents
] |
