@make[article] @device[x2700] @style[spacing 2] @modify[hd2,facecode=k] blank @newpage @section[Introduction] Edinburgh University is spread across many parts of Edinburgh with two main "campus" areas and a number of other scattered departments. This situation has led to a very high dependence on data networking which has been built up over fifteen years in order to ensure that students and staff can communicate with either the main University Services or local department machines. The current network (see fig 1) is based on three GEC packet switches supporting 35 hosts and 100 synchronous links [1]. The dispersed nature of the University has resulted in the development of a separate complex speech network (see fig 2)[2]. The University telephone exchanges are of Strowger type and the University has evaluated nine submissions for their replacement. This has allowed an extensive examination of the possibilities of using the speech network for carrying some, or all, of the University data traffic. The University was able to take the opportunity of early exposure to one of the latest technology telephone exchanges in the form of a joint project with ICL, partly funded by grants from the DTI under a 'Focus' and Preproduction Order scheme. The project's function is to connect a DNX2000 PABX to an ICL OSLAN (Open Systems Local Area Network) and to examine the consequences of carrying data traffic across the PABX onto the LAN. A project diagram is shown in Fig 3. The project is now one quarter way through the evaluation year giving us the opportunity to examine the data capacity of the DNX2000, in a way which we had not had with the other manufacturers' products. @section[Advantages] There are a number of potential advantages to be gained by using a PABX for data traffic, they are:- @subsection[Common Wiring] The biggest attraction of using a PABX for data traffic is that the wiring is already in place. The penetration of telephones is greater than that of terminals. Edinburgh University has 2098 telephone extensions, supporting 2835 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 attractive. 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 exchanges are installed. This new wiring will be capable of fully supporting both the speech and data requirements for most users. @subsection[Direct connection of terminals] One disadvantage of the existing University network for connection to certain hosts is that is that some host programs expect very tight control over characters typed by the user and what is then echoed back to the terminal. This can produce a 'spongy' effect on network terminals as the echo has to traverse the network twice and consequently the terminal image for users is not the same as that of a directly connected terminal. A PABX, by using circuit switching, gives a direct terminal image even across multiple exchanges. @subsection[Handling multiple terminal protocols] A PABX can be used to switch a variety of terminal types using both different types of protocol and synchronous or asynchronous signalling in a manner that cannot be done with an X25 packet switch. This can be of use to users who are running mixtures of differing protocols such as IBM 3270, ICL CO3 or specialised asynchronous block mode terminals such as those used by the GEAC Library machine installed in the University. @subsection[Connection of a large number of infrequently used terminals] Terminals whose use matches the same sort of profile as that of the average telephone call can be effectively handled by a PABX. With a large number of terminals being only lightly used a far smaller number of host ports than terminal ports can be installed. With a large ratio, say 15:1, the cost approximates to that of the terminal connection cost alone, whilest the overall load on the PABX should not create significant blocking problems. @subsection[Single exchange management] A conventional PACX (data only exchange) such as a Gandalf or a Micom also provides the last three advantages. However, a PABX would still be required to handle the telephone traffic. The advantage of using the PABX for data traffic is that there is only one system to purchase and maintain. @subsection[Carrying synchronous X25 traffic] One method of operation would be to use the exchange to carry a synchronous X25 call from a PAD (Packet Assembler Disassembler) to a centrally located X25 switch. This has the advantage of needing only one 'permanent' 64kb/s circuit, ie, one erlang, while carrying up to 16 or 32 simultaneous user calls. With the hardware currently available to us we have been able to successfully connect the synchronous line output of a PAD through the PABX at speeds up to 19.2kb/s. @section[Disadvantages] There are a number of disadvantages in using a PABX:- @subsection[No system is truly non-blocking] The new generation of exchanges has been heralded as non-blocking. In other words all extensions on the exchange can be active at one time. Although the central core is non-blocking, the make-up and use of a real system can not guarantee non-blocking. This is particularily 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 2Mb/s trunk to the main exchange. The 2Mb/s trunk can carry at maximum 30 calls at 64kb/s, the remaining two channels being used for signalling. If more than 30 extensions are installed on the satellite exchange then the @b[system] is not non-blocking. 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 experience of the average data call (2-3 mins vs 15-25 mins). 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 connection only capable of running at 9.6kb/s will still use an entire 64kb/s circuit). A group of thirty terminals used simultaneously will use up an entire 2Mb/s trunk, whereas if packet switching is used, 38 or 48kb/s is quite sufficient. It is therefore clear that if a @b[system] is being used heavily for data traffic, its configuration will have to be larger and carefully controlled to prevent blocking problems as compared to an exchange which is being used solely for speech and a certain amount of blocking can be tolerated. A single exchange is capable of carrying significant data traffic. An estimate for the new Edinburgh University exchanges (whichever product is chosen) is that each would be capable of handling some 200 simultaneous data calls in addition to the speech traffic. @subsection[The cost is greater than conventional solutions] Comparing costs of different solutions is very difficult, the eventual cost being very dependant on the individual configuration. The following comparison uses the marginal costs only. Consider Fig 4, which shows the typical manner of connecting a data terminal (or micro) to a PABX. The general cost of the DIU and data port associated with the terminal side is between @t[#]800 and @t[#]1000. 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 X25 network (see Fig 5) is one sixteenth of a cost of a PAD and its network connection. This comes to about @t[#]200. An allowance must also be made for the X25 host connection, this is more difficult as the connection can be shared with other traffic, such as electronic mail, file transfer and printer output. A reasonable estimate would be @t[#]50, giving a total cost of @t[#]250. @need[2.5in] The equivalent incremental cost of a PACX, such as a Gandalf, in this simple configuration is about @t[#]80, with an allowance of @t[#]25 for the shared host port, a total cost of @t[#]105 is reached. It must 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 solution is as expensive as an X25 one. @subsection[Limitations of 64K baud] A much quoted limitation of a PABX is that any one user is limited to a speed of 64kb/s. In reality this is not as great a limitation as appears at first sight. Most terminals currently only run at 9.6kb/s and it will be a long time before a 64kb/s limit becomes an embarassment. A more serious situation is file transfer between micros or multi-user machines. The comparison here is with the scale of bandwidth that an Ethernet@+(TM) or similar fast LAN can provide. An Ethernet's wide bandwidth is best utilised when it is supporting the interconnection of a large number of small machines. And our measurements with both Ethernets and Cambridge Rings, both running at 10Mb/s, show that hosts interchanging real data using other than the most light weight protocols generally have difficulty in achieving a true point-to-point speed of even 64kb/s (See also [3]). The limitation in transfer capacity is caused by host I/O packet handling limitations. The cost of handling any fast communication channel is determined largely by the total number of packets (data and acknowledgment), rather than the number of bytes, that the host handles. Very few implementations are capable of negotiating the use of large packets (1024 bytes or over) and consequently severly limit the maximum transfer speed. @subsection[Interference with the Speech Service] 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. @subsection[Lack of Network Management] None of the products investigated by the University support @b[internal] call monitoring. The facilities usually provided 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 safeguard the speech service. There appear to be products available in the USA that support this type of facility but it will be some considerable time before they are available in Britain. @subsection[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 X25 terminal concentrators. @section[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 question which now arises is what is needed to make the use of a PABX more attractive in a general data environment. Considering Fig 4 again, each of the elements needs to be examined. @subsection[The Data Port] There are three ways using the DNX2000 by which a user can establish a call from one data port to another. The first is to use the telephone 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 can't be done when there is an active speech call unless a 'feature phone' is used. The second method, which is only applicable 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 is going to be heavily dependent on what the PABX manufacturers can charge for their products in the voice market. @subsection[Data Interface Unit (DIU)] The current cost of the DIU is extremely high; for some time now the manufacturers have been promising a chip to do the job. When these chips are in volume production one can expect the cost to be only a few pounds and the expectation is that they will be a standard part of at least the 'feature-phone' type of equipment [4]. @subsection[Alternatives to the DIU] @paragraph[Combined micro/telephone] Products such as the ICL 'One Per Desk' are interesting examples of the combination of a micro computer and a telephone, particularily in an office environment where the number of devices and their size is of importance. The cost is still quite expensive and they have the disadvantage that the user is locked-in to the particular micro used. @paragraph[Data Network Gateways] The use of Gateways should be cheaper than multiple DIUs and are discussed in detail below. @need[1.5in] @section[PABX/LAN Gateways] @subsection[The current position] When a large number of ports in one location are connected to a PABX, for example, to serve a host computer, it is necessary to connect an individual Data Interface Unit to the end of each port (see Fig 6). @need[2.5in] 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 connected; 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 particular 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 simultaneously, 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 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, eg, Ethernet, X25 or Cambridge Ring. The hosts are then also connected to this network, the typical form of which will allow a varying number of simultaneous terminal connections. (See Fig 7). @need[2.5in] 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 OSLUs (Open System Link Units) connected to an OSLAN and a few connections from the PABX to a Camtec PAD connected to the main X25 network (see Fig 3). This particular configuration was used to allow us as much experience as possible with the varying connection 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. @subsection[The future] A more elegant solution for connecting multiple DIUs is to construct a Gateway either directly on to the end of a 2Mb/s trunk link or to build a Gateway within the exchange itself. ICL are in the process of constructing a Gateway to connect a 2Mb/s trunk to their OSLAN (See fig 8). @need[2.5in] We had hoped that we would be able to replace the OSLUs before the end of the project with such a Gateway 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 exchange. For example, it would no longer be necessary to allocate different hunt groups, with pre-set allocations, to handle various terminal parameters such as different line speeds or differing protocols - dumb terminals, 3270, CO3 etc. All thirty available sub-channels 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 equivalent). 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 terminals are 'dumb teletypes' and the most obvious choice was to use a variety of XXX called TS29 [5] that could be run over the ISO Transport Class 4 Service which is used. TS29 allows a free exchange of data bytes but significantly also gives a standard procedure (X29) for a host to change various PAD characteristics such as echo control, local edit control and forwarding rules. This protocol was implemented for us by ICL who were using a simpler form which did not allow us the control from the host we considered essential. One interesting decision that 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 that both 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 unacceptable 'stickiness' in terminal presentation. The second way to handle echo is to do it within the Gateway/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 X29 at any time to handle special cases such as screen editing. @subsection[Integrated Gateways] Building a completely integrated Gateway is being pursued by at least one other PABX manufacturer, the outward connection being X25 based. In a multiple exchange environment it would be extremely useful to be able to pass the X25 connection through a sub-channel on a trunk to another PABX to avoid the necessity of all the exchange's being connected directly to the X25 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 environment and the overall cost of the Gateway. @need(1in) @section[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 changes and can be divided into two cases, the single and multiple exchange environments. @subsection[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 system prices more into line. @subsection[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 networks such as X25. The PABX manufacturers will need 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 solution. @section[Acknowledgements] The author would like to thank F.E.J. Barratt (Telephones Project Manager) and W.S. Currie (PABX/LAN Project Officer) for their help and information. @section[References] @begin[enumerate] ERCC - Services and Facilities, 1985, ERCC Operation Requirement for Replacement of PABX Network, Edinburgh University, April 1984 Jose Eabielsky, Interfacing to the 10Mbps Ethernet: Observations and Conclusions, Comms,ACM 1984 pp124-131 Satish Chandra, Integrated Voice & Data PBXs, Tutorial, Compcon '82, IEEE "Green Book" - Character Terminal Protocols on PSS (Study Group 3, BT PSS User Forum) @end(enumerate) @section[Trade Marks] Ethernet is a trademark of the Xerox Corporation.