@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 n).  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 numbe 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 causes 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 insimultaneous use.
   One partial solution to this problem is to connect some, or all, of
the exchange ports to a Packet Assembler Disassembler (PAD). This PAD
is then connected in a conventional manner to a data network which
could be based on a number of technologies, be it 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 n+1).
   In the Edinburgh case we have connected a number of ports directly
from the PABX to separate hosts, some ports from the PABX to two ICL
OSLUs (Open System Link Units (PADs)) connected to an OSLAN and a few
connections from the PABX to a Camtec PAD connected to the main X25
network.  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
Mitel because for an unknown reason, 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 Data Interface
Units is to construct a Gateway either directly on to the end of a 2Mb
trunk link or build a Gateway within the exchange itself.  ICL are in
the process of constructing a Gateway to connect a 2Mb trunk to ICLs
OSLAN (See fig n+2).  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 Data Interface Units 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 is no longer 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 will pass the
information to tell the Gateway the type of connection to be used and
the Gateway will 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 termianl data accross 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 (ref n) that could be run over the ISO Transport Class 4
Service that 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 which was using a simpler form that did not allow us the control
we considered essential from the host.  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 that is identical (or possibly almost) 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 accross the LAN in
single character quantities.  The problem this creates is not one of
ethernet 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 seperate
decision can then be made of exactly when the user input is forwarded
accross the LAN.  This leads to a much better use of the available
performance but means that the terminal image can 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 PBX manufacturer, the outward connection being X25
based.  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.