communications

Using PABX for voice and data in large networks Advantages and disadvantages

by BRIAN GILMORE

high

A level of dependence on

networking has built up at Edin- burgh University over the last

15 years, as students and staff have wanted to communicate between de- partments spread around the city.

The current network is based on three packet switches, supporting 35 hosts and 100 synchronous links.

The dispersed nature of the Univer-

sity has resulted in the development of a separate complex speech net- work. When the time came for re- placement, the University looked at

Abstract: Edinburgh liniversiry has taken the opportunity of replacing its speech network to look at PABXs for handling voice and data. A number of advantages and disadvantages are apparent. Future Figure I. PABXILAN project network developments will overcome some of these problems. the possibility of carrying data in the connect a DNX2000 PABX to an ICL

Kqwords: data processing, computer speech network. Open Systems Local Area Network

communication, PABX. The University decided to take up (OSLAN) and to examine the conse-

government grants in a joint tele- quences of carrying data traffic across _

Brian Gilmore is communications manager at phone exchange technology project the PABX onto the LAN. A project

Edinburgh Regional Computing Centre. with ICL. The project’s function is to diagram is shown in Figure 1.

operator

I _ _

EMLAN Ethermonmrs Network

2800 FEP 12) management

station

72 terminals -

4PADports -

4 ERCVax ports -

4 ESCVax ports _

4 sundry ports -

_ PEG - I I I

x8 1 10 Mbit CSMAICD I I

OSLU Etherbridge

Async terminals

~0127 no 8 October 1985 0011-684X185/080025-05$03.00 0 1985 Butterworth & Co (Publishers) Ltd. 25

The project is now one quarter way variety of terminal types, using both Disadvantages of the PABX through the evaluation year giving us different types of protocol and syn- the opportunity to examine the data chronous or asynchronous signalling,

There are a number of disadvantages

capacity of the DNX2000, in a way in a way that cannot be done with an in using a PABX.

which we had not had with the other X.25 packet switch. This can be

manufacturers’ products. useful to users who are running mix- No system is truly nonblocking

tures of differing protocols, such as The new generation of exchanges has Advantages of using a PABX IBM 3270, ICL C03, or specialized been heralded as nonblocking. In

There are a number of potential asynchronous block mode terminals, other words, all extensions on the

advantages to be gained by using a such as those used by the GEAC exchange can be active at one time.

PABX for data traffic. Library machine installed in the Uni- However, although the central core is versity. nonblocking, the makeup and use of a

Common wiring real system cannot guarantee non-

The biggest attraction of using a PABX for data traffic is that the telephone wiring is already in place. Edinburgh University has 2098 tele- phone extensions, supporting 2 835

instruments, and 1520 asynchronous connections. The total number’ of telephone extensions is static but the number of asynchronous connections has risen by about 20% per year for the last few years. So an alternative to laying yet more copper is very attrac-

tive. As the existing telephone wiring is owned by BT and is not sufficient to

support many of the modern features, we will actually be rewiring much of the University when the new ex- changes are installed. This new wiring

will be capable of fully supporting both the speech and data require- ments for most users.

Direct connection of terminals

One disadvantage of the existing Uni- versity network is that some host programs expect very tight control over characters typed by the user and the echo back to the terminal. This can produce a ‘spongy’ effect on network terminals as the echo has to

traverse the network twice. Conse- quently, the terminal image for users is not the same as that of a directly- connected terminal. By using circuit switching, a PABX gives a direct terminal image even across multiple exchanges.

Handling multiple terminal protocols

A PABX can be used to switch a

Connection of a large number of infrequently used terminals

The PABX can effectively handle terminals which are used as much as

the average telephone. With a large number of infrequently used termin- also, say 15 terminal ports to one host port, the cost approximates to that of the terminal connection cost alone. The overall load on the PABX should not create significant blocking prob- lems.

Single exchange management

A conventional PACX (data only ex-

change), such as a Gandalf or a Micom, also provides the last three

advantages. However, a PABX would still be required to handle the tele- phone traffic. The advantage of using the PABX for data traffic is that there is only one system to purchase and

maintain.

Carrying synchronous X. 25 traffic

One method of operation would be to use the exchange to carry a synchro- nous X.25 call from a packet assemb- ler disassembler (PAD) to a centrally- located X.25 switch. This has the advantage of needing only one ‘perm- anent’ 64 kbit/s circuit, i.e., one erlang, while carrying up to 16 or 32 simultaneous user calls. With the hardware currently available, we have been able to connect successfully the

synchronous line output of a PAD through the PABX at speeds up to 19.2 kbit/s.

blocking. This is particularly true if the system was originally designed for speech only.

The situation is made considerably

worse if extensive data traffic is to be carried between exchanges. Consider

the following: a satellite exchange is connected via a 2 Mbit/s trunk to the main exchange. The 2 Mbit/s trunk can carry at maximum 30 calls at 64 kbit/s with the remaining two chan- nels being used for signalling. If more than 30 extensions are installed on the satellite exchange, then the system is not nonblocking. Although multiple trunks could be used, in real systems

this can cause shortages of ports as well as being extremely expensive compared to a system carrying speech

traffic alone. The duration of the average speech

call is much shorter than our experi- ence of the average data call (2-3 min DS 15-25 min). This means that a data

call using the exchange uses up far more than would be expected of the total resource. (Remember that as it is

based on circuit switching, a connec- tion only capable of running at 9.6 kbit/s will still use an entire 64 kbitis

circuit). A group of 30 terminals used simultaneously will use up an entire 2 Mbit/s trunk, whereas if packet switching is used, 38 or 48 kbitls is quite sufficient. It is therefore clear that if a system is being used heavily for data traffic, its configuration will

have to be larger and carefully con- trolled to prevent blocking problems, as compared to an exchange which is being used solely for speech and

26 data processing

communications

IL-I jl f nter erence with the speech service

Figure 2. Data connection to a PABX

where a certain amount of blocking can be tolerated.

A single exchange is capable of

carrying significant data traffic. An estimate for the new Edinburgh Uni- versity exchanges, whichever product is finally chosen, is that each would be

capable of handling some 200 simul- taneous data calls, in addition to the speech traffic.

Cost is greater than conventional solutions

Comparing costs of different solutions is very difficult, the eventual cost being highly dependent on the indivi- dual configuration. The following

comparison uses the marginal costs only. Consider Figure 2 which shows the typical manner of connecting a data terminal or micro to a PABX. The general cost of the data interface unit (DIU) and data port associated with the terminal side is between 5800 and 21 000. A share in a host port and DIU must also be allowed for. In our case, a ratio of approximately one host port to every three terminal ports would be required. The equivalent cost, excluding wiring, in an X.25 network (see Figure 3) is one six-

teenth of a cost of a PAD and its network connection. This comes to about &200. An allowance must also

be made for the X.25 host connection. This is more difficult as the connec-

tion can be shared with other traffic, such as electronic mail, file transfer and printer output. A reasonable esti- mate would be &50., giving a total cost of 5250.

The equivalent incremental cost of a PACX, such as a Gandalf, in this simple configuration is about 580. Add an allowance of &25 for the

~0127 no 8 October IL985

Figure 3. X.25 network connection

shared host port and a total cost of

&105 is reached. It should be stressed that if the total

cost of a solution is taken into account, the circuit switch method

requires multiple host input/output connections as well as the ports within the circuit switch. The packet switch solution requires only one, or at most a few, ports. With this taken into consideration, a Gandalf type of solu- tion is as expensive as an X.25 one.

Limitations of 64 kbitls

A much-quoted limitation of a PABX is that any one user is limited to a speed of 64 kbitis. In fact, this is not as great a limitation as appears at first sight. Most terminals currently only run at 9.6 kbit/s and it will be a long time before a 64 kbit/s limit becomes an embarassment. A more serious situation is file transfer between mi- cros or multiuser machines. The com- parison here is with the scale of

bandwidth that an Ethernet or similar fast LAN can provide. An Ethernet’s wide bandwidth is best utilized when it is supporting the interconnection of a large number of small machines. Our measurements with both Ether- nets and Cambridge Rings, both run- ning at 10 Mbit/s, show that hosts interchanging real data using other than the most lightweight protocols generally have difficulty in achieving a

true point-to-point speed of even 64 kbitls ‘.

The limitation in transfer capacity

is caused by host I/O packet handling limitations. The cost of handling any fast communication channel is deter- mined largely by the total number of packets (data and acknowledgement),

rather than the number of bytes that

the host handles. Very few implemen- tations are capable of negotiating the use of large packets (1024 bytes or over) and consequently severely limit the maximum transfer speed.

Great care must be taken in the overall configuration to ensure that

data traffic, even at its peak, does not degrade the performance of the speech service. In particular, there must always be spare channels throughout the system to ensure that emergency calls and the like can be made.

Lack of network management

None of the products investigated by the University support internal call monitoring. The facilities usually pro-

vided are to monitor the use of trunks and sometimes the use of hunt groups. The consequence of this lack is that it is difficult to monitor the extent of the data traffic for either future planning purposes or to safe- guard the speech service.

There appear to be products avail- able in the USA which support this type of facility but it will be some considerable time before they are available in the UK.

Lack of access to a name directory

It is not possible for a user on a terminal to access the PABX directory

on any of the exchanges investigated by the University. To access another data port, a user needs to remember the telephone number of the port or an associated name. This restriction makes the user interface much more unfriendly than it need be and to a lower standard than that available on either PACXs or some X.25 terminal concentrators.

The future

From the above it is quite clear that it is not yet economic for Edinburgh

University to use a new PABX system for extensive data traffic. The ques- tion which now arises is what is needed to make the use of a PABX more attractive in a general data environment. Considering Figure 2

27

again, each of the elements needs to be examined.

The data port

There are three ways of using the DNX2000 by which a user can estab- lish a call from one data port to

another. The first is to use the tele- phone handset to dial the number of the other port; this procedure can be made very simple by using the ‘speed

call’ feature, although there is an interesting problem with the DNX2000 in that this cannot be done when there is an active speech call unless a ‘featurephone’ is used. The second method, which is only applic- able to RS232 type devices, is to enter into a conversation with software within the exchange. This software announces itself and then prompts the user for a command. The user may then call a port by name. The third

method is by ‘hotlining’, by which a connection is made by default for the user.

Thus data ports are more complex than speech ports and are used in smaller numbers; one can assume that the data port cost will always be

greater than the speech equivalent. The general cost will fall over time but the overall cost will be heavily dependent on what the PABX manu- facturers can charge for their products

in the voice market.

Data interface unit (DI U)

The current cost of the DIU is extremely high; for some time now the manufacturers have been promis- ing a chip to do the job. When these chips are in volume production the cost should only be a few pounds and the expectation is that they will be a standard part of at least the ‘feature- phone’ type of equipment’.

Alternative to the DI U

Products such as the ICL One Per Desk are interesting examples of the combination of a microcomputer and

28

Dan interlace ““ll lDlUl 1-_-J 1 Figure 4. Host connection to a PABX

a telephone, particularly in an office environment where the number of devices and their size is of import- ance. The cost is still quite expensive and they have the disadvantage that the user is locked in to the particular micro used.

Alternatively, the use of gateways should be cheaper than multiple

DIUs and are discussed in detail below.

PABX/LAN gateway The current position

When a large number of ports in one

location are connected to a PABX, to serve a host computer for example, it is necessary to connect an individual

DIU to the end of each port (see Figure 4).

Even when these units can be racked together, as is the case with the

Plessey exchange, the solution is hardly elegant. These problems can be considerably increased when a number of different hosts are con- nected; the maximum number of simultaneous connections to each host must be estimated and that number of lines dedicated to each host. Users are very unforgiving when access to their host is denied because all the ports on the exchange are in use even though the maximum potential of the particu-

lar host has not yet been reached because only a few ‘other’ lines are in use. Our experience has shown that the peak number of users is not usually reached on all hosts simultan- eously. The effects of special courses, lectures, deadlines and the like cause fairly wide fluctuations in the demand for any particular machine. In solving this problem, in common with any PACX use, many more access ports

have to be provided than are actually in simultaneous use.

One partial solution to this problem is to connect some, or all, of the

Figure 5. PABXILAN connection

exchange ports to a PAD. This PAD is then connected in a conventional manner to a data network which could

be based on a number of technologies, e.g. Ethernet, X.25 or Cambridge Ring. The hosts are then also con- nected to this network, the typical form of which will allow a varying number of simultaneous terminal con- nections. (See Figure 5).

In the Edinburgh case, we have connected a number of ports directly from the PABX to separate hosts, some ports from the PABX to three ICL Open System Link Units

(OSLUs) connected to an OSLAN and a few connections from the PABX to a Camtec PAD connected to the

main X.25 network (See Figure 1). This particular configuration was used to allow us as much experience as possible with the varying connec- tion methods, but it can lead to problems for some users because of the differing user images presented by the different routes.

A further problem arises with the

DNX2000 because the ability to set up ‘hunt’ groups is not as flexible for data calls as it is with voice calls. Consequently, it is not possible to have a single hunt group which will

take a direct connection if one is free but also automatically select a PAD port if all the direct ports are in use.

The future

A more elegant solution for connec- ting multiple DIUs is to construct a gateway either directly on to the end of a 2 Mbit/s trunk link or to build a

gateway within the exchange itself. ICL is in the process of constructing a gateway to connect a 2 Mbit/s trunk to its Oslan (See Figure 6).

We had hoped that we would be able to replace the OSLUs before the end of the project with such a gate-

data processing

communications

L __-_-- _ --_-_---I

Figure 6. Trunk connection

wgy, but that is not now going to be possible. The advantage of such a

gateway is that the DIUs are an integral part of the gateway and, more importantly, the gateway can act in a more integrated way with the ex-

change. For example, it would no longer be necessary to allocate differ- ent hunt groups, with preset alloca- tions, to handle various terminal para- meters such as different line speeds or differing protocols - dumb termin- als, 3270, CO3 etc. All 30 available subchannels would be in a single hunt group, the exchange would pass the information to tell the gateway the

type of connection to be used and the gateway would then set the port up as necessary.

There are other considerations

when a terminal is connected to a host via such a gateway (or PAD equiva- lent). The first is what protocol should be used to carry the terminal data across the Oslan. In our case it was reasonably simple; all our ter- minals are ‘dumb teletypes’ and the most obvious choice was to use a variety of XXX called TS293 that could be run over the IS0 Transport Class 4 Service which is used. TS29 allows a free exchange of data bytes but significantly also gives a standard

procedure (X.29) for a host to change various PAD characteristics such as echo control, local edit control and forwarding rules. This protocol was implemented for IUS by ICL, which was using a simpler form which did not allow us the control from the host we considered essential.

One interesting decision which still has to be taken is where the echoing of the user input is to be done. One choice is to do it within the host computer. This allows a terminal image which is identical (or nearly so)

to a terminal which has been directly connected. The problem with this decision is I hat bot.h the input and the

echo need to be carried across the

LAN in single character quantities.

The problem this creates is not one of LAN capacity but that of delays caused by processing overheads in both the host and the gateway. In our

experience, users will complain if

echo is held up for more than about one tenth of a second and more than a few users attempting such single character working leads to an un- acceptable ‘stickiness’ in terminal pre-

sentation. The second way to handle echo is to do it within the gatewayi

PAD itself. A separate decision can then be made of exactly when the user input is forwarded across the LAN. This leads to a much better use of the available performance but means that

the terminal image may be different from a directly connected terminal.

In reality, a mixture of the above

approaches can be used; most of the time user echo can be handled by the gateway, but the host can take control via X.29 at any time to handle special

cases such as screen editing.

Integrated gateways

Building a completely integrated gate- way is being pursued by at least one

other PABX manufacturer, the out- ward connection being X.25-based.

In a multiple exchange environ- ment, it would be extremely useful to be able to pass the X.25 connection

through a subchannel on a trunk to another PABX to avoid the necessity of all the exchanges being connected directly to the X.25 network.

The considerations discussed above will still apply and at the end of the day it will come down to a decision on which type of gateway will fit better in the user’s own data network environ- ment and the overall cost of the gateway.

Conclusions

AS has already been stated, at this

stage the use of a PABX for extensive data traffic is more expensive than the alternative solutions such as packet

switching or a PACX. When the data

interface unit has been integrated into a telephone handset at a reasonable cost, the situation will change and can be divided into two cases, the single and multiple exchange environments.

Single exchange environment

In this situation, the PABX will be comparable to its alternatives, the incremental costs may still be higher but the advantages of only buying one

system should bring the overall sys- tem prices more into line.

Multiple exchange environments

The situation here is much more

complex. The PABX network suffers from severe problems with blocking as was discussed earlier and a practical solution entails mixing the PABXs with more conventional data net-

works, such as X.25. The PABX manufacturers will

lieed to consider much more carefully the needs of the data user and to tackle the overcapacity associated with pure circuit switching before the PABX becomes a satisfactory solu- tion.

Acknowledgements

The author would like to thank F E J

Barratt (telephones project manager) and W S Currie (PABXILAN project officer) for their help and informa- tion.

References

Eabielsky, J ‘Interfacing to the 1OMbps Ethernet: Observations and Conclusions’ Comms, ACM (1984) ~~124-131 Chandra, S ‘Integrated Voice c3r Data PBXs’ Tutorial, Compcon ‘82, IEEE Green Book - Character Terminal Protocols on PSS (Study Group 3, BT PSS User Forum) 0

- ______ Edinburgh Regional Computing Centre, James Clerk Maxwell Building, The King’s Buildings. Mayfield Rd. Edinburgh EH9 3J2, UK.

~0127 no 8 October 1985 29