- Email: [email protected]
An implementation of the programming communications interface for EuroISDN
Computer Standards & Interfaces 17 (1995) 169-180
lementation of the programming commu interface for EuroISD Ahmed Pate1 *, John Reilly Computer
Networks
and Distributed
System
Research
Croup, University
College Dublin,
Belfield,
Dublin
4, Ireland
bstract
This paper describesa prototype implementation of an important new recommendationfrom the European TelecommunicationsStandardsInstitute (ETSI) which defines a manufacturer-independentProgrammingCommunications Interface (PCI) for the Integrated ServicesDigital Network (ISDN). The ETSI PC1 recommendation.is analysedand comparedwith other current ISDN programminginterfaces. The designpresentedin this paper is criticaliy analysedand possibleimprovementsare suggested.The resultsof a survey undertaken to investigate the approachof the ISDN equipment manufacturersto the ETSI PC1is alsopresented. Integrated ServicesDigital Network (ISDN); ProgrammingCommunicationsInterface (PCI); Information interfaces and presentation Keywords:
of the draft specification that allows app~ieati~~~s that use the PC1 to be developed and tested. The overall objective of this research was to design and implement software that would allow PCs to make use of the emerging ISDN. Currently, the development of new ISDN applications and the take-up of ISDN are being hindered by the lack of a standardised programming interface. The new ETSI ISDN Programming Communications Interface (PCI) Specification aims to offer a solution to this problem by providing a manufacturer independent interface to EuroISDN. This paper describes a prototype implementation
* Corresponding author. Email: [email protected]
I. I Background
ISDN is defined by the CCITT as digital end to end connectivity through a limited set of network interfaces providing a wide range of service features evolving from the telephone integrated digital network to meet the needs of the 21st century [ll]. The aim of ISDN is to provide a fast high quality digital communication service ahowing the user to access a wide range of services through a single connection 11121. Manufacturers of ISDN terminal equipment currently provide their own application programming interfaces which means that an application written for one card would have to be substan-
0920-5489/95/$09.50 0 1995 Elsevier Science B.V. All rights reserved SSDI 0920-5489(94)0036-G
170
A. Pate& J. Reilly/Computer
Standards
tially modified to run on any other card. This limitation discourages the development of new ISDN applications and increases the cost of existing applications as each application has a relatively small market. The ETSI ISDN PC1 aims to provide a manufacturer independent interface for ISDN applications. The PCI specification covers a wide variety of operating systems but in the research project described in this paper the prototype implementation has been developed on a PC using MSDOS. Ivlounting an ISDN application on a PC provides a relatively cheap yet powerful means through which business and domestic users can access the range of service offered by ISDN. 1.2 Appiication programming interfaces
The term Application Programming Interface (API) refers to a wide range of software interfaces which provide access to a local computer system. These services may be related to the OS1 model but they are mainly concerned with the control of local computer system resources such as memory, disks and other special devices. The operating system interfaces defined for UNIX and MS-DOS are good examples of this. The purpose of producing a networking API is to bide the complexity of the underlying network from the application developer. Thus the developer does not have to become an expert in the underlying protocols and this means that applications can be produced more cheaply and more quickly than would otherwise be the case. APIs may be divided into two categories, namely those for non-communication purposes and those for communication purposes [l]. The first category is concerned with the provision of overall non-communication oriented local system services while the second category of APIs is those defined for communication purposes. This category is termed “Programming Communication Interfaces’ (PCIs).
& Interfaces
17 (1995)
159-180
regard to this research is the ETSI IS Some current ISDN APIs/PCIs are described below: a The Common ISDN API (CAP11 is a German recommendation for a manufacturer independent ISDN PCI. CAP1 which provides a hardware independent interface to ISDN boards of different vendors [6]. It supports voice and data services over ISDN. The CAP1 interface is located between layers 3 and 4 of the OSI model. a The COM/APPLI functional model, originally proposed by France Telecom. This model consists of two interfaces: an OS1 layer 7 interface known as APPLI/COM and an OS1 layer 3/4 interface known as CO~/~~OT~C~L. The APPLI/COM interface has been adopted by ETSI and the CCITT [5]. C~~/~~LI provides a simple method to exchange documents and related information between an application and the Telex, Teletex and Facsimile services defined by the CCITT. a The Application Software Interface (ASI). This recommendation has been proposed by the North American ISDN Users Forum (NIIJF) [7]. The goal of AS1 is to provide a portable, extensible and layered manufacturer independent interface to ISDN hardware.
2. The ETSP ISDN PC1
The basic model of the ETSI PC1 consists of two entities, the PC1 User Facility (FIJI;) (or the service user) and the Network Access Facility (NAF) (or the service provider), with an interface between the two across which messages flow as shown in Fig. 1. These messages request that the
1.3 Some current ISDN APIs
Several ISDN APIs and PCIs specifications have been proposed [4]. The most important with
Fig. 1. Basic model of the ETSI ISDN PCI.
A. Pate& J. Reilly /Computer
Standards
NAF perform actions on request from the PUF and return the result of the actions to the PUF. The PCI is l.ocated between layers 3 and 4 of the 8% model. It is divided into 3 planes called the Administration Plane, the Control Plane and the User Plane. The Control Plane provides operations which facilitate the establishment and release of physical connections between the connetting peer entities and also provides a limited capability for data exchange using the services provided by the ISDN D channel. The Administration Plane provides operations which facilitate the management of connections such as the definition and management of address and attribute sets and the management of network connection objects (NCOs). It is also concerned with error reporting, security, external equipment operation and manufacturer specific
Fig. 2. Sequence
& Interfaces
I7 (1995)
169-180
i7i
operation. The User Plane provides operations which facilitate establishment, data exchange and release of logical connection channels between the connected peer entities using a variety of protocols. The PC1 messages make extensive use of REQUEST, INDICATION, CONFIRM OSI service primitives. An application using the PC1 must first use the operations of the administration plane to allocate and configure the required resources It then uses the resources of the control and user planes to perform further operations on the allocated resources. The sequence of PC1 messages is shown in Fig. 2. The interaction between the BSDN network and the application is split into three phases termed registration, conversation and deregistration. During the registration phase a unique identification is established between the
of PC1 messages.
A. Patel, J. Reilly /Computer
172
Standards
application and the ISDN card hardware and the necessary resources are allocated within the network. In the conversation phase the application uses the operations provided by the administration, control and user planes. After the conversation phase the application uses the deregistration phase to disconnect from the ISDN network and to release the allocated resources. The main data structure defined in the PC1 recommendation is called a Network Connection Object (NCO3. NCOs are defined using the administration plane messages and are used in both the control and user planes to establish use and remove connections. NCOs are created from attribute and address sets which contain all the details necessary to define connections. 2.1 Data management The PC1 provides two kinds of message access at the top of the ISDN network layer. These are Network Message Access (NMA) and Transparent Message Access (TMA). NMA provides access to the user plane protocols running in the ISDN network layer. Thus it provides access to a network layer connection. TMA provides access to transparent network and link layers and provides direct access to the physical layer of ISDN, providing byte-synchronised control over a B channel. 2.2 Information
exchange
The information exchanged using the PC1 is logically grouped by the three planes. Accessing the functionality of the PC1 is done by means of messages. The PUF and the NAF use the functionality of the information exchange mechanism to exchange messages. The messages inform the entities of the operations to perform or of the results of performed operations. The exchange of messages is realised by means of two functions PciPutMessage and PciGetMessage which may be called once the PUF is associated with the NAF. A data structure called the PC1 Message Parameter Block (MPB), which is one of the arguments to PciPutMessage and PciGetMessage, contains the type of the message that is passed.
c? Interfaces
17 (1995)
169-180
The arguments are encoded using the Type, Length, Value (‘I’LV) convention which is defined in the PC1 recommendation 2.3 Current status of the PCI specification Currently, the public enquiry stage within ETSI for the PCI recommendation has been completed. The public enquiry stage means that the members of ETSI can provide comments on a draft recommendation and suggest le changes to it. A meeting was held in in October 1993 to finalise the public enquiry for the PCI. It has been assigned the reference number pr ETS 300 325 [2]. Since the implementation described in this paper was completed a revised version of the PC1 specification was released [3]. This version only contains minor changes over the version implemented. The PCI recommendation will be voted on by the members of ETSI in Spring 1994. It currently has the status of a draft ETSI recommendation. 2.4 Requirements The main requirements as follows [S]:
of the software -were
a This research project should specifically target PCs and MS-DOS. . The software should be implement the mandatory features of the ETSI ISDN PCI s tion. B The layout of the project documents should follow the European Space Agency (ESA) Software Engineering Standards [lo]. . The software should use proprieta~ IS and APIs. . Although the software be prirnar~~~ designed to run on a PC S-DOS, it should be written in such a way that it could be easily ported to another environment e.g. a Sun Workstation. . The design should use a top down a~~roacb~ . The software should be designed in a modular manner to minimise coupling between modules and maximise independence.
A. Patel, J. Reilly /Computer
Standards
should be implemented as a library N. of f~~ctio~§ which should be called by the PI-IF. c The card specific code should be localised in one module so that it should be easy to modify software to support other ISDN PC card Is. e The software should use polling to detect incoming events rather than an interrupt based mechanism. e Debugging information should be provided when required to aid testing and application development. e A state machine should be included to ensure the correct operation of the PC1 by an application. . Telecom l%reann’s pilot ISDN network should be used to test the software.
0 The
of the PC1 software
This section of the paper describes the design of the prototype ETSI ISDN PC1 implementation [9]. An overview of the design has been presented in an earlier paper [13]. 3.1 De&r2
issues
esign in this paper is described using a top down approach. The system was designed in a modular way to minimise coupling and maximise independence between modules. All of the card specific code has been localised in one module (the service layer). This means that the only changes required to the code to support another ISDN PC card API are to the service layer. The system was designed to be generic and machine independent even if this meant the code was less efficient and compact. The code can be easily ported to another type of machine, e.g. a Sun workstation. In this implementation a polling mechanism was chosen for dealing with incoming events. This approach was chosen as an interrupt based mechanism would make the implementation dependent on MSDOS and would require significant changes to be made to the code to port it to
& Interfaces
17 (1995)
169-180
1’73
another operating system environment. so it was felt that, while less satisfactory than an mterrupt mechanism, a polling rnec~a~ism was sufficient for this prototype implementation. The program could be modified to use interrupts by implementing a TSR (terminate and resident) program that would remain loade memory while the main program was running. Then this program would signal to the main program that an incoming event has occurred when it happened. In this scenario, the ~ci~e~~ign~l message function would inform the PUF of an incoming event and the NAFPoll function would be no longer required. Optional features that were not implementer were: support for external equipment, optional PC1 message classes higher than class one, security features, concurrent applications and conformance testing. The major limitations of the proto are due to the limitations of the ISDN cards used and those of MS-DOS. In this prototype implementation the system has been built using the proprietary ISDN PC card APIs. This is due to the fact that ISDN PC cards at the lower end of the market do not allow the manipulation of their on-board protocol software. Cards, such as the Mite1 KQXV Express Card, that do allow direct calls to the ISDN Network Layer (Q.931) are available but at considerable cost. 3.2 Design
The software consists of four components. The design of each component is described in detail in the following sections. The software operates in the following manner. The application (or PUF) using the PC1 calls the PC1 interface routines. These in turn make use of the services of the NAP management layer. This layer then invokes the PCI operations layer functions. The PC1 Operations in turn make calls to routines in the service layer, The service layer functions are mapped onto the card functions. The five components of the PCI software and the messages that are passed between them are shown in Fig. 3.
174
A. Patel, J. Reilly/Computer
Standards
3.3 Function description of each component The PUF layer is the PUF or the application using the PCI. It must be fully compatible with the ETSI ISDN PC1 Specification. The PUF layer calls the interface Zayer functions. The Interface layer provides an interface for the PUF to access the NAF functions. It also provides a pass through function which allows the application to bypass the PC1 and access the card API directly. The NAF layer handles incoming calls and manages the Network Connection Objects (NCOsS. It also manages messages sent to or from the PUF and is responsible for the state machine. This layer receives data sent from the PUF and decodes the message for use by the PC1 operations layer. On receiving a valid message it determines whether or not the message can be executed by referring to the state machine. The NAF layer also polls for incoming messages and stores them in a message queue. The service layer provides operations which may be called by the PC1 Operations Layer functions and contains all the card-specific code. The
& Interfaces
17 (1995)
169-180
routines provide a card-independent interface between the PC1 message functions and the ISDN PC card API. In this prototype im~lemcntatio~ the service layer has been implemented for the two ISDN PC cards that were used. Two different ISDN PC cards were purchased to demonstrate that the PC1 implementation would operate correctly on more than one card. These were SCII Datavoice SO I§DN PC card has a high level API called PCDEV and the OST PC S.NET card. The service layer could easily be modified to support other proprietary APIs. 3.4 Data structures The principal data structure of the PCI is known as a Network Connection In this implementation an array an NCOList was defined as an array of structures in C. For this implementation a further array of structures called a NCOExtraList was defined which contains data needed by the PCI that is not defined in a NCO. 3.5 Debugging information
r--
There is a facility provided for the PCI to display debugging information. This information is useful during the testing phase of the PC1 software as well as during the development of a PC1 application. The facility allows the values of all the arguments of the routines to be displayed before and after any action takes place. The debugging information is only displayed if specifically requested by the user.
~ Component 1:
3.4 State machine Component
Component
Fig. 3. Components
Service Layer
of the PC1 software.
~
A state machine has been included in this PCI implementation to ensure that an application using the PC1 is only able to call the XI operation layer functions in a predefined sequence. The state machine implements the state diagram for the PCI. The state diagram, which is derived from the SDL diagrams given in the PCI Specification [3] is presented in Fig. 4. There is a logically separate state machine for each of the ISDN B channels with a global array
A. Patel, J. Reilly/Computer
Standards
keeping track of the current state of the PC1 for each channel. Two separate state machines are required as each of the B channels may be in a different state at a given time.
4. Critica
analysis
4.1 Comments
and evaluation
on the design
The design presented in this paper is not ideal but has allowed a prototype implementation of the PC1 to be provided quickly in advance of full PCI implementations becoming available. The primary limitation as described above was building the prototype on top of proprietary ISDN PC card APIs as opposed to Q.931, the ISDN net.work layer. This approach was chosen due to the high cost of the ISDN PC cards and their associated software that do allow direct access to Q.931. Qne such card produced by Mite1 called the l,TDiV Express card in addition to being costly was
& Interfaces
cconnectReq
\ /
169-180
!75
not approved for connection to the Telecom I?ireann ISDN network used in the project. The design has several features worth commenting on. Firstly, the software has been designed in a modular manner with each of the four layers of the PC1 implementation completely separate from each other. The card dependent code has been localised in one module-the service layer. This feature makes the software easy to modify to support other card APIs. This features also means that if in a future release of the PC1 specification changes were made to the PCI message functions but to no other area of the specification, it would only be necessary to change one of the four main modules to upgrade the software. Secondly, the software has been written in a generic machine independent manner. It does not make use of any DOS specific features such as interrupts or TSRs. This means that the software could be easily ported onto a Sun workstation running UNIX without having to make any
Reject Req”T%Y
17 (1995)
\ Idle 0
Fig. 4. PC1 state diagram.
A. Patel, J. Reiily /Computer
176
Standards
anges to the code. In this situation the service layer would have to be modified to support the appropriate API. 4.2 Analysis of the draft PCI specification The current version of the PC1 recommendation offers many useful features not currently offered by some proprietary ISDN AF’Is such as a call suspend and resume facility, and support for external equipment and security. Compared to other ISDN programming interfaces such as SCIIs PCDEV the ETSI PC1 is difficult to use. However, the ETSI PC1 is a OS1 3/4 layer interface rather than an OS1 layer 7 interface like PCDEV and therefore some extra functionality and consequently complexity is to be expected. A layer 3/4 interface requires more precise control over the ISDN network than a layer 7 interface and the additional complexity is inevitable. Some suggestions on how the recommendation could be improved are given in this section. These suggestions have been forwarded to ETSI. The messages containing the values of the arguments to the PC1 message function being called in a PciPutMessage function have to be entered ‘by the programmer in the TLV format as follows: Type of argument, Length of argument, Value of argument
~
For example, the message for a CConnectReq message function (which sets up an outgoing call) might look like this: C_CQN_REQ[15OI = {ll, 10,255, 1, 0, 3, ‘3’, ‘5’, ‘3’, ‘2’, 1, 0, ‘I’, ‘O’, ‘O’, ‘4’, , 1, ‘3’, 9, ‘3’, ‘2’, ‘3’, ‘l', 1 ‘1' ‘0' ‘(y ‘2’ , ,,“,,; 6g ‘A:, , ‘T’, ‘e’, ‘s’, ‘t’}; This means that the application has to be capable of encoding the message in a TLV format as above as the value of many of the CConneceq arguments such as CalledNumber (type 7,
& Interfaces
I7 (1995)
169-180
line 4 above), CalledSubaddress (Type 8: line 5 above) and Bearer Capability c above) are provided to the XI tion. The PC1 recommendation s function for doing this. The application wQ~Id call this function to convert the value of the CConnectReq arguments into the TLV format and construct the message which would then be one of the arguments to PciPutMessage. The user plane messages in ETSI PCI are clearly oriented towards the X.25 protocol. It would be better if the messages were more general or a separate set of messages were defined for X.25 and other sets were defined for other layer three protocols such as T.70 or 8208 sages that might be used. In addition, a set of should be defined for OS1 layer two protocols such as frame relay to supplement the layer three and transparent protocols already defined. It could also be argued that the PC1 recommendation is too comprehensive for some situations even though a layer 3/4 interface does require some complexity. A clearly defined subset or subsets of the recommendation should be defined for different circumstances. This issue is addressed in the current PCI recommendation to some extent as the PC1 message functions are divided into 4 classes in the recomme~dat~Q~ only the first of which is mandatory. However, the meaning of classes two to four is not defined in the recommendation. Defining subsets of the reeommendation would not give rise to inc~~~~at~bility problems because the application (PUF) can query the NAF property database to determine what classes of optional messages have been implemented. In conclusion, the compiexity of the PCI is a consequence of it being a much lower level gramming interface (OS1 layer 3/4) than PCDEV (OS1 layer 7) and other similar ISDN programming interfaces. Overall the PC1 recommenda~ tion represents a well balanced draft that contains a high level of functionality at the expense of added complexity. 4.3 Comparison of the PCI with other PCIs Several other PC1 specification have been proposed. The APPLX/COM specification originally
A. Pate& J. Reilly /Computer
Standards
roposed by France Telecom (as part of the COM/APPLI model) and later adopted by the CCITT. Unlike the ETSI PC1 this PC1 is located at layer 7 in the OS1 model, also unlike the ETSI PC1 this PCI is not specific to ISDN but rather supports a variety of telecommunications services namely; Fax Group 3 and Group 4, Teletex and Telex which may use ISDN. wever, the basic architecture of APPLI/ is similar to the PC1 in that it consists of c two entities communicating using messages and using fit and Get functions to transfer these messages. Also there is a registration and deregistration phase as there is in the ETSI PC1 and the Data Descriptions (TDDs) defined in APCOM are similar in concept to the ETSI essages and MPBs. APPLI/COM defines both a polling and an interrupt based mechanism for dealing with incoming events whereas the ETSI PCI only defines an interrupt based mechanism. The #CAPI and AS1 specifications in contrast are direct equivalents to the ETSI PC1 in that they are ISDN Network Related PCIs which are located between layer 3 and layer 4 of the OS1 model. The architecture in both cases is similar to the PC1 with AS1 being an interface between the AE (AH Entity) and PE (Program Entity) and CAPI being an interface between an application and an ISDN driver. They both use messages to communicate between the two entities. Like the PC1 ASI is divided into three planes, a management plane, a control plane and a user plane. The messages defined in both cases are very similar to the PC1 messages though they differ in detail. I provides a facility for manufacturer spenctions like the ETSI PC1 and a message function to select the layer two and layer three protocol which the ETSI PC1 does not support. CAP1 also supports facilities for Fax Group 3, permanent and semi-permanent connections and 0 interfaces which EuroISDN or the ETSI do not support. AS1 supports primary and basic rate ISDN and user-to-user information transfer as does the ETSI PCI. The AS1 messages use the RE ST, INDICATION, RESPONSE and CQNF OS1 service primitives.
& Interfaces
17 (1995)
169-180
177
In conclusion, APPLI/COM is a different kind of PC1 to the ETSI PC1 in terms of i.ts location in the OS1 model and the telecommunications services it supports. CAP1 and ASI are similar to the ETSI PC1 in terms of their objectives and the overall solution they arrive at although they differ in detail. 4.4 How the design could be impror;ed There are two major limitations of the design presented this paper. Firstly, a proper PCI implementation should interact directly with Q.931, the ISDN network layer. Instead, this prototype PCI implementation has been built on top of the ISDN APIs provided with the two ISDN cards used. Secondly, basing the im~l~mentatlon on an operating system like DOS that only allows one process to be activ a given time is not ideal. In a full implementation based on cards such as the Mite1 ISDN Express Card, which allow direct access to Q.931, the service layer could be removed altogether and the PCI Me tions would interact directly with ISDN Network Layer. There is a ciose correspondence between Q.931 messages and parameters and those of the PCI. This me ns that producing an implementation of the PC on top of Q.931 wauld be straightforward. It is not ideal to implement the NAF as a library of functions that are called by the PUF. It would be better, the PUF and the NAF were two separate processes on the same machine in a multi-tasking environment such as UNIX. This would be a more efficient design. The NAF would accept messages in a device independent manner for the PUF. The NAF would the.n translate these messages into (2.931 messages and send them to the network. Similarly, incoming 0,931 messages from the network would be transiated into PC1 messages by the NAF and passed to the PUF. In conclusion, while the design presented in this paper is not ideal it is a useful initial attempt at implementing the PC1 recommendation in a PC environment. The implementation could be modified later into a full PCI imp~eme~tati~~ in
178
A. Patel, J. Reilly /Computer
Standards
the event of direct access being possible to Q.931 messages. The testing phase has shown that the PC1 functions correctly. This implementation will allow PCI applications to be written and tested in advance of full PCI implementation becoming available next year. 4.5 How some of the optional features could be implemented
of the PCI
These are several optional features of the PC1 recommendation that were not implemented in this design. The mandatory Primary Rate support was not implemented due to the lack of a Primary Rate ISDN network on which to test the system. To support primary rate the service layer would have to be modified to support the primary rate I being used. The mandatory X.25 support (NMA) was not considered necessary for this prototype implementation. However, this feature could easily be added to the design if required at a later stage. It would involve implementing the NMA PC1 Messages defined in the recommendation and when opening a connection, request an ISDN connection with X.25 rather than a transparent ISDN connection. Finally, the security features could be implemented by adding the ASecurityReq message and ASecurityCnf. ASecurityReq would cause data being sent over the ISDN line to be encrypted using a suitable security algorithm. A mechanism for decrypting any incoming data would have to be implemented. 4.6 Suruey of 4SDN PC card manufacturers
A survey was undertaken as part of this research to establish some insight into the approach of the major ISDN PC card manufacturers to the PCI. In all twenty manufacturers were contacted and eight replies have been received. Replies were received from SCII, QST, ICL, Ascom Zelcorn, Loewe Qpta, Diehl ISDN, Mite1 Semiconductor and Telenorma GmbH. This does not constitute a statistically significant sample but nevertheless some conclusions may be drawn from the results which are summarised in this section.
& interfuces
I7 (1995)
169-180
Each manufacturer five questions:
was asked the following
Have you previously heard of the ETSI ISD PCI? Do you consider it to be comprehensive and easy to use? Would you consider implementing the ETSI ISDN PC1 in place of your current ISDN API(s)? What is your company’s attitude to manufacturer independent APIs in general? Do you think that the provision of a manufacturer independent ISDN API would lead to a reduction in the cost of ISDN applications? This limited survey has produced some interesting replies though a higher response rate would have been needed to draw any firm conclusions. The answer to the first question in all cases was yes, which is not surprising since most of the companies concerned are members of ET Most companies felt the ETSI PCI recommendation was comprehensive but they also felt that it would be more difficult to use than their current API. All of the manufacturers said they would at least consider implementing the PCI which is encouraging though most adopted a “wait and see’ approach to determine if their competitors would first adopt the rec~mme~~atio~. Therefore, if some of the major ISDN PC card manufacturers were to adopt the PCI recommendation then the other smaller companies would follow suit whereas if this doesn’t happen the PCI may only be implemented by a small minority and the recommendation may not succeed. All of manufacturers who replied supported the concept of manufacturer independent APIs. SCII suggested that their existing API was easier to use than the PCI. The manufacturers did not anticipate that the PC1 would not reduce the cost of ISDN applications.
This research project has demonstrated that the ETSI PC1 can be implemented on a PC using
A. Patel, J. Reilly /Computer
Standards
existing ISDN PC card APIs. The current ETSI PCI specification has been discussed in detail and possible extensions and improvements have been suggested. The PC1 specification has also been compared with other current ISDN programming interfaces. Finally, ISDN PC card manufacturers have been consulted to determine what their approach to the PCI specification is and whether they intend to implement the specification in the future. The PCI implementation described in this paper has been demonstrated at the Communications 1993 Exhibition held at the Royal Dublin Society in October 1993 using a PC1 test application which could setup and receive ISDN voice and data calls. A research paper entitled High Level Generic Design of a Programming Communications Interface for EuroISDN [13] was presented at the IFIP Conference ‘93 (Advanced Information Processing Techniques for LAN and Management) held in Versailles, France in April 1993.
& interfaces
I7 (1995)
169-280
119
and manufacturer specific barriers that are currently hindering the take-up of ISDN. The prototype implementation has shown that the PC1 specification can be irnple~~e~t~d using proprietary ISDN PC card APIs and allows applications to be written and tested that use the PCI in advance of full PC1 implementations becoming available. The prototype could be extended in the future to become a full PCI implementations Acknowledgements
We would like to thank the members of the Computer Networks and Distributed Systems search Group in LJCD, especially Niall Down&y, for their advice and assistance with our work on this project. We would also like to thank Teltec Ireland, EOLAS (through the HEIC schemeS and Euristix Ltd. for financial support for the project. Finally, we would like to thank Telecom &rearm for the use of their pilot ISDN network the testing and evaluation phase.
4.8 Future direction It is up to the ISDN PC card manufacturers to decide whether the ETSI PC1 will succeed. The prototype implementation described here could be later extended into a full PC1 implementation. The optional features not implemented in this prototype could be added. Currently, research work is in progress on defining programming interfaces which support multimedia applications for the emerging broadband ISDN (B-ISDN). The current narrowband ISDN programming interface may serve as a basis for the broadband programming interfaces of the future.
Overall the draft PC1 specification strikes a well judged balance between ease of use and functionality provided. The implementation of a single ISDN standard throughout Europe and the availability of a single programming interface for EuroISDN will help to break down the country
References
1116. Vogt, Recommendations for standard application programming interfaces relevant to ISDN and related management issues, Technical Report, DBP Telekcm, May 1991. PI ETSI, Programming communications interface for EuroISDN (pr ETS 3003251, Final Draft, Version 1.2, Nov. 1992. [31 ETSI, Integrated Services Digital Network; Programming communications interface for EuroISDN, reference number: pr ETS 300325 (rev 2), ETSI Oct. 1993. Communication Interfaces [41 A. Chaillat, Programming (PCIs)-An Overview, Technical Report, France Telecorn, Nov. 1991. Draft Specification, Study Group is1 CCITT, APPLI/COM VIII Report R32, 1992. 161Telematic Services GmbH, Common ISDN A.PII (CAPI) specification, Version 1.1, 1991. I71 North American ISDN Users Forum (NIUF), Application Software Interface (ASI) specification, Version 1.0, NIUF, Oct. 1991. 181 J. Reilly and N. Downey, Requirements document-ISDN PC1 Project. Version 2.0 March 1992, internal document (unpublished). [9] 3. Reilly and N. Downey. Design document PC1 software, Version 2.0, Oct. 6th, 1992, internal document (nnpublished).
A. Patel, J. Reilly /Computer
Standards
European Space Agency (ESA), ESA software engineering standards (issue 2 Feb. 1991), ESA PSS-05-0, ESA Publications Division, Noordwijk, The Netherlands. XI., Helgert, Integrated Services Digital Network, (Addison-Wesley, Reading, MA, 1991). A. Tanenbaum, Computer Networks (Addison-Wesley, Reading, MA, 1988). N. Downey and A. Patel, High Level Generic Design qf a Programming
Communications
Interface
for
EuroISDN,
IFIP Transactions C-17 (Elsevier Science BV, Amsterdam, 1994). Ahmed Pate1 received his MSc. and Ph.D. in computer science from Trinity College Dublin in 1977 and 1984, respectively. From 1978-82 he was responsible for developing the Irish University Data Network and from 1982-85 he developed the EuroKom computer conferencing and electronic mail service used by R&D project in Europe. At University College Dublin he is a lecturer in computer science and head of the Computer Network and Distributed Systems Research
d Interfaces
17 (199.5) 169-180
Group. He is involved in various multi-national R&D projects in ESPRIT, RACE,, INFOSEC, AIM COST and Irish National Telecommunication programmes. His main research interests include network management, security, protocol, performance evaluation, intelligent networks, CSCW and open distributed processing systems. He has published many technical oaoers and co-authored two books on comouter network security and one book on group communication’s. He is member of the Editorial Advisory Board of the Computer Communication and Collaborative Compufing journals. John Reilly received his B.Sc. from St. Patrick’s College Maynooth, Co. Kildare, Ireland in 1989. He joined the Computer Networks and Distributed Systems Research Group at the Department of Computer Science in University College Dublin in October 1991 and he completed his M.Sc. in November 1993. At present he is employed as a Systems Engineer with Mentec Picturecom Ltd. in Dublin where he is engaged in the development of PC-based videoconferencing applications. His researich interests include the Integrated Services Digital Networ -k (ISDN). Integrated Broadband Networks, Application Programming Inteaaces and Multimedia Applications.
lementation of the programming commu interface for EuroISD Ahmed Pate1 *, John Reilly Computer
Networks
and Distributed
System
Research
Croup, University
College Dublin,
Belfield,
Dublin
4, Ireland
bstract
This paper describesa prototype implementation of an important new recommendationfrom the European TelecommunicationsStandardsInstitute (ETSI) which defines a manufacturer-independentProgrammingCommunications Interface (PCI) for the Integrated ServicesDigital Network (ISDN). The ETSI PC1 recommendation.is analysedand comparedwith other current ISDN programminginterfaces. The designpresentedin this paper is criticaliy analysedand possibleimprovementsare suggested.The resultsof a survey undertaken to investigate the approachof the ISDN equipment manufacturersto the ETSI PC1is alsopresented. Integrated ServicesDigital Network (ISDN); ProgrammingCommunicationsInterface (PCI); Information interfaces and presentation Keywords:
of the draft specification that allows app~ieati~~~s that use the PC1 to be developed and tested. The overall objective of this research was to design and implement software that would allow PCs to make use of the emerging ISDN. Currently, the development of new ISDN applications and the take-up of ISDN are being hindered by the lack of a standardised programming interface. The new ETSI ISDN Programming Communications Interface (PCI) Specification aims to offer a solution to this problem by providing a manufacturer independent interface to EuroISDN. This paper describes a prototype implementation
* Corresponding author. Email: [email protected]
I. I Background
ISDN is defined by the CCITT as digital end to end connectivity through a limited set of network interfaces providing a wide range of service features evolving from the telephone integrated digital network to meet the needs of the 21st century [ll]. The aim of ISDN is to provide a fast high quality digital communication service ahowing the user to access a wide range of services through a single connection 11121. Manufacturers of ISDN terminal equipment currently provide their own application programming interfaces which means that an application written for one card would have to be substan-
0920-5489/95/$09.50 0 1995 Elsevier Science B.V. All rights reserved SSDI 0920-5489(94)0036-G
170
A. Pate& J. Reilly/Computer
Standards
tially modified to run on any other card. This limitation discourages the development of new ISDN applications and increases the cost of existing applications as each application has a relatively small market. The ETSI ISDN PC1 aims to provide a manufacturer independent interface for ISDN applications. The PCI specification covers a wide variety of operating systems but in the research project described in this paper the prototype implementation has been developed on a PC using MSDOS. Ivlounting an ISDN application on a PC provides a relatively cheap yet powerful means through which business and domestic users can access the range of service offered by ISDN. 1.2 Appiication programming interfaces
The term Application Programming Interface (API) refers to a wide range of software interfaces which provide access to a local computer system. These services may be related to the OS1 model but they are mainly concerned with the control of local computer system resources such as memory, disks and other special devices. The operating system interfaces defined for UNIX and MS-DOS are good examples of this. The purpose of producing a networking API is to bide the complexity of the underlying network from the application developer. Thus the developer does not have to become an expert in the underlying protocols and this means that applications can be produced more cheaply and more quickly than would otherwise be the case. APIs may be divided into two categories, namely those for non-communication purposes and those for communication purposes [l]. The first category is concerned with the provision of overall non-communication oriented local system services while the second category of APIs is those defined for communication purposes. This category is termed “Programming Communication Interfaces’ (PCIs).
& Interfaces
17 (1995)
159-180
regard to this research is the ETSI IS Some current ISDN APIs/PCIs are described below: a The Common ISDN API (CAP11 is a German recommendation for a manufacturer independent ISDN PCI. CAP1 which provides a hardware independent interface to ISDN boards of different vendors [6]. It supports voice and data services over ISDN. The CAP1 interface is located between layers 3 and 4 of the OSI model. a The COM/APPLI functional model, originally proposed by France Telecom. This model consists of two interfaces: an OS1 layer 7 interface known as APPLI/COM and an OS1 layer 3/4 interface known as CO~/~~OT~C~L. The APPLI/COM interface has been adopted by ETSI and the CCITT [5]. C~~/~~LI provides a simple method to exchange documents and related information between an application and the Telex, Teletex and Facsimile services defined by the CCITT. a The Application Software Interface (ASI). This recommendation has been proposed by the North American ISDN Users Forum (NIIJF) [7]. The goal of AS1 is to provide a portable, extensible and layered manufacturer independent interface to ISDN hardware.
2. The ETSP ISDN PC1
The basic model of the ETSI PC1 consists of two entities, the PC1 User Facility (FIJI;) (or the service user) and the Network Access Facility (NAF) (or the service provider), with an interface between the two across which messages flow as shown in Fig. 1. These messages request that the
1.3 Some current ISDN APIs
Several ISDN APIs and PCIs specifications have been proposed [4]. The most important with
Fig. 1. Basic model of the ETSI ISDN PCI.
A. Pate& J. Reilly /Computer
Standards
NAF perform actions on request from the PUF and return the result of the actions to the PUF. The PCI is l.ocated between layers 3 and 4 of the 8% model. It is divided into 3 planes called the Administration Plane, the Control Plane and the User Plane. The Control Plane provides operations which facilitate the establishment and release of physical connections between the connetting peer entities and also provides a limited capability for data exchange using the services provided by the ISDN D channel. The Administration Plane provides operations which facilitate the management of connections such as the definition and management of address and attribute sets and the management of network connection objects (NCOs). It is also concerned with error reporting, security, external equipment operation and manufacturer specific
Fig. 2. Sequence
& Interfaces
I7 (1995)
169-180
i7i
operation. The User Plane provides operations which facilitate establishment, data exchange and release of logical connection channels between the connected peer entities using a variety of protocols. The PC1 messages make extensive use of REQUEST, INDICATION, CONFIRM OSI service primitives. An application using the PC1 must first use the operations of the administration plane to allocate and configure the required resources It then uses the resources of the control and user planes to perform further operations on the allocated resources. The sequence of PC1 messages is shown in Fig. 2. The interaction between the BSDN network and the application is split into three phases termed registration, conversation and deregistration. During the registration phase a unique identification is established between the
of PC1 messages.
A. Patel, J. Reilly /Computer
172
Standards
application and the ISDN card hardware and the necessary resources are allocated within the network. In the conversation phase the application uses the operations provided by the administration, control and user planes. After the conversation phase the application uses the deregistration phase to disconnect from the ISDN network and to release the allocated resources. The main data structure defined in the PC1 recommendation is called a Network Connection Object (NCO3. NCOs are defined using the administration plane messages and are used in both the control and user planes to establish use and remove connections. NCOs are created from attribute and address sets which contain all the details necessary to define connections. 2.1 Data management The PC1 provides two kinds of message access at the top of the ISDN network layer. These are Network Message Access (NMA) and Transparent Message Access (TMA). NMA provides access to the user plane protocols running in the ISDN network layer. Thus it provides access to a network layer connection. TMA provides access to transparent network and link layers and provides direct access to the physical layer of ISDN, providing byte-synchronised control over a B channel. 2.2 Information
exchange
The information exchanged using the PC1 is logically grouped by the three planes. Accessing the functionality of the PC1 is done by means of messages. The PUF and the NAF use the functionality of the information exchange mechanism to exchange messages. The messages inform the entities of the operations to perform or of the results of performed operations. The exchange of messages is realised by means of two functions PciPutMessage and PciGetMessage which may be called once the PUF is associated with the NAF. A data structure called the PC1 Message Parameter Block (MPB), which is one of the arguments to PciPutMessage and PciGetMessage, contains the type of the message that is passed.
c? Interfaces
17 (1995)
169-180
The arguments are encoded using the Type, Length, Value (‘I’LV) convention which is defined in the PC1 recommendation 2.3 Current status of the PCI specification Currently, the public enquiry stage within ETSI for the PCI recommendation has been completed. The public enquiry stage means that the members of ETSI can provide comments on a draft recommendation and suggest le changes to it. A meeting was held in in October 1993 to finalise the public enquiry for the PCI. It has been assigned the reference number pr ETS 300 325 [2]. Since the implementation described in this paper was completed a revised version of the PC1 specification was released [3]. This version only contains minor changes over the version implemented. The PCI recommendation will be voted on by the members of ETSI in Spring 1994. It currently has the status of a draft ETSI recommendation. 2.4 Requirements The main requirements as follows [S]:
of the software -were
a This research project should specifically target PCs and MS-DOS. . The software should be implement the mandatory features of the ETSI ISDN PCI s tion. B The layout of the project documents should follow the European Space Agency (ESA) Software Engineering Standards [lo]. . The software should use proprieta~ IS and APIs. . Although the software be prirnar~~~ designed to run on a PC S-DOS, it should be written in such a way that it could be easily ported to another environment e.g. a Sun Workstation. . The design should use a top down a~~roacb~ . The software should be designed in a modular manner to minimise coupling between modules and maximise independence.
A. Patel, J. Reilly /Computer
Standards
should be implemented as a library N. of f~~ctio~§ which should be called by the PI-IF. c The card specific code should be localised in one module so that it should be easy to modify software to support other ISDN PC card Is. e The software should use polling to detect incoming events rather than an interrupt based mechanism. e Debugging information should be provided when required to aid testing and application development. e A state machine should be included to ensure the correct operation of the PC1 by an application. . Telecom l%reann’s pilot ISDN network should be used to test the software.
0 The
of the PC1 software
This section of the paper describes the design of the prototype ETSI ISDN PC1 implementation [9]. An overview of the design has been presented in an earlier paper [13]. 3.1 De&r2
issues
esign in this paper is described using a top down approach. The system was designed in a modular way to minimise coupling and maximise independence between modules. All of the card specific code has been localised in one module (the service layer). This means that the only changes required to the code to support another ISDN PC card API are to the service layer. The system was designed to be generic and machine independent even if this meant the code was less efficient and compact. The code can be easily ported to another type of machine, e.g. a Sun workstation. In this implementation a polling mechanism was chosen for dealing with incoming events. This approach was chosen as an interrupt based mechanism would make the implementation dependent on MSDOS and would require significant changes to be made to the code to port it to
& Interfaces
17 (1995)
169-180
1’73
another operating system environment. so it was felt that, while less satisfactory than an mterrupt mechanism, a polling rnec~a~ism was sufficient for this prototype implementation. The program could be modified to use interrupts by implementing a TSR (terminate and resident) program that would remain loade memory while the main program was running. Then this program would signal to the main program that an incoming event has occurred when it happened. In this scenario, the ~ci~e~~ign~l message function would inform the PUF of an incoming event and the NAFPoll function would be no longer required. Optional features that were not implementer were: support for external equipment, optional PC1 message classes higher than class one, security features, concurrent applications and conformance testing. The major limitations of the proto are due to the limitations of the ISDN cards used and those of MS-DOS. In this prototype implementation the system has been built using the proprietary ISDN PC card APIs. This is due to the fact that ISDN PC cards at the lower end of the market do not allow the manipulation of their on-board protocol software. Cards, such as the Mite1 KQXV Express Card, that do allow direct calls to the ISDN Network Layer (Q.931) are available but at considerable cost. 3.2 Design
The software consists of four components. The design of each component is described in detail in the following sections. The software operates in the following manner. The application (or PUF) using the PC1 calls the PC1 interface routines. These in turn make use of the services of the NAP management layer. This layer then invokes the PCI operations layer functions. The PC1 Operations in turn make calls to routines in the service layer, The service layer functions are mapped onto the card functions. The five components of the PCI software and the messages that are passed between them are shown in Fig. 3.
174
A. Patel, J. Reilly/Computer
Standards
3.3 Function description of each component The PUF layer is the PUF or the application using the PCI. It must be fully compatible with the ETSI ISDN PC1 Specification. The PUF layer calls the interface Zayer functions. The Interface layer provides an interface for the PUF to access the NAF functions. It also provides a pass through function which allows the application to bypass the PC1 and access the card API directly. The NAF layer handles incoming calls and manages the Network Connection Objects (NCOsS. It also manages messages sent to or from the PUF and is responsible for the state machine. This layer receives data sent from the PUF and decodes the message for use by the PC1 operations layer. On receiving a valid message it determines whether or not the message can be executed by referring to the state machine. The NAF layer also polls for incoming messages and stores them in a message queue. The service layer provides operations which may be called by the PC1 Operations Layer functions and contains all the card-specific code. The
& Interfaces
17 (1995)
169-180
routines provide a card-independent interface between the PC1 message functions and the ISDN PC card API. In this prototype im~lemcntatio~ the service layer has been implemented for the two ISDN PC cards that were used. Two different ISDN PC cards were purchased to demonstrate that the PC1 implementation would operate correctly on more than one card. These were SCII Datavoice SO I§DN PC card has a high level API called PCDEV and the OST PC S.NET card. The service layer could easily be modified to support other proprietary APIs. 3.4 Data structures The principal data structure of the PCI is known as a Network Connection In this implementation an array an NCOList was defined as an array of structures in C. For this implementation a further array of structures called a NCOExtraList was defined which contains data needed by the PCI that is not defined in a NCO. 3.5 Debugging information
r--
There is a facility provided for the PCI to display debugging information. This information is useful during the testing phase of the PC1 software as well as during the development of a PC1 application. The facility allows the values of all the arguments of the routines to be displayed before and after any action takes place. The debugging information is only displayed if specifically requested by the user.
~ Component 1:
3.4 State machine Component
Component
Fig. 3. Components
Service Layer
of the PC1 software.
~
A state machine has been included in this PCI implementation to ensure that an application using the PC1 is only able to call the XI operation layer functions in a predefined sequence. The state machine implements the state diagram for the PCI. The state diagram, which is derived from the SDL diagrams given in the PCI Specification [3] is presented in Fig. 4. There is a logically separate state machine for each of the ISDN B channels with a global array
A. Patel, J. Reilly/Computer
Standards
keeping track of the current state of the PC1 for each channel. Two separate state machines are required as each of the B channels may be in a different state at a given time.
4. Critica
analysis
4.1 Comments
and evaluation
on the design
The design presented in this paper is not ideal but has allowed a prototype implementation of the PC1 to be provided quickly in advance of full PCI implementations becoming available. The primary limitation as described above was building the prototype on top of proprietary ISDN PC card APIs as opposed to Q.931, the ISDN net.work layer. This approach was chosen due to the high cost of the ISDN PC cards and their associated software that do allow direct access to Q.931. Qne such card produced by Mite1 called the l,TDiV Express card in addition to being costly was
& Interfaces
cconnectReq
\ /
169-180
!75
not approved for connection to the Telecom I?ireann ISDN network used in the project. The design has several features worth commenting on. Firstly, the software has been designed in a modular manner with each of the four layers of the PC1 implementation completely separate from each other. The card dependent code has been localised in one module-the service layer. This feature makes the software easy to modify to support other card APIs. This features also means that if in a future release of the PC1 specification changes were made to the PCI message functions but to no other area of the specification, it would only be necessary to change one of the four main modules to upgrade the software. Secondly, the software has been written in a generic machine independent manner. It does not make use of any DOS specific features such as interrupts or TSRs. This means that the software could be easily ported onto a Sun workstation running UNIX without having to make any
Reject Req”T%Y
17 (1995)
\ Idle 0
Fig. 4. PC1 state diagram.
A. Patel, J. Reiily /Computer
176
Standards
anges to the code. In this situation the service layer would have to be modified to support the appropriate API. 4.2 Analysis of the draft PCI specification The current version of the PC1 recommendation offers many useful features not currently offered by some proprietary ISDN AF’Is such as a call suspend and resume facility, and support for external equipment and security. Compared to other ISDN programming interfaces such as SCIIs PCDEV the ETSI PC1 is difficult to use. However, the ETSI PC1 is a OS1 3/4 layer interface rather than an OS1 layer 7 interface like PCDEV and therefore some extra functionality and consequently complexity is to be expected. A layer 3/4 interface requires more precise control over the ISDN network than a layer 7 interface and the additional complexity is inevitable. Some suggestions on how the recommendation could be improved are given in this section. These suggestions have been forwarded to ETSI. The messages containing the values of the arguments to the PC1 message function being called in a PciPutMessage function have to be entered ‘by the programmer in the TLV format as follows: Type of argument, Length of argument, Value of argument
~
For example, the message for a CConnectReq message function (which sets up an outgoing call) might look like this: C_CQN_REQ[15OI = {ll, 10,255, 1, 0, 3, ‘3’, ‘5’, ‘3’, ‘2’, 1, 0, ‘I’, ‘O’, ‘O’, ‘4’, , 1, ‘3’, 9, ‘3’, ‘2’, ‘3’, ‘l', 1 ‘1' ‘0' ‘(y ‘2’ , ,,“,,; 6g ‘A:, , ‘T’, ‘e’, ‘s’, ‘t’}; This means that the application has to be capable of encoding the message in a TLV format as above as the value of many of the CConneceq arguments such as CalledNumber (type 7,
& Interfaces
I7 (1995)
169-180
line 4 above), CalledSubaddress (Type 8: line 5 above) and Bearer Capability c above) are provided to the XI tion. The PC1 recommendation s function for doing this. The application wQ~Id call this function to convert the value of the CConnectReq arguments into the TLV format and construct the message which would then be one of the arguments to PciPutMessage. The user plane messages in ETSI PCI are clearly oriented towards the X.25 protocol. It would be better if the messages were more general or a separate set of messages were defined for X.25 and other sets were defined for other layer three protocols such as T.70 or 8208 sages that might be used. In addition, a set of should be defined for OS1 layer two protocols such as frame relay to supplement the layer three and transparent protocols already defined. It could also be argued that the PC1 recommendation is too comprehensive for some situations even though a layer 3/4 interface does require some complexity. A clearly defined subset or subsets of the recommendation should be defined for different circumstances. This issue is addressed in the current PCI recommendation to some extent as the PC1 message functions are divided into 4 classes in the recomme~dat~Q~ only the first of which is mandatory. However, the meaning of classes two to four is not defined in the recommendation. Defining subsets of the reeommendation would not give rise to inc~~~~at~bility problems because the application (PUF) can query the NAF property database to determine what classes of optional messages have been implemented. In conclusion, the compiexity of the PCI is a consequence of it being a much lower level gramming interface (OS1 layer 3/4) than PCDEV (OS1 layer 7) and other similar ISDN programming interfaces. Overall the PC1 recommenda~ tion represents a well balanced draft that contains a high level of functionality at the expense of added complexity. 4.3 Comparison of the PCI with other PCIs Several other PC1 specification have been proposed. The APPLX/COM specification originally
A. Pate& J. Reilly /Computer
Standards
roposed by France Telecom (as part of the COM/APPLI model) and later adopted by the CCITT. Unlike the ETSI PC1 this PC1 is located at layer 7 in the OS1 model, also unlike the ETSI PC1 this PCI is not specific to ISDN but rather supports a variety of telecommunications services namely; Fax Group 3 and Group 4, Teletex and Telex which may use ISDN. wever, the basic architecture of APPLI/ is similar to the PC1 in that it consists of c two entities communicating using messages and using fit and Get functions to transfer these messages. Also there is a registration and deregistration phase as there is in the ETSI PC1 and the Data Descriptions (TDDs) defined in APCOM are similar in concept to the ETSI essages and MPBs. APPLI/COM defines both a polling and an interrupt based mechanism for dealing with incoming events whereas the ETSI PCI only defines an interrupt based mechanism. The #CAPI and AS1 specifications in contrast are direct equivalents to the ETSI PC1 in that they are ISDN Network Related PCIs which are located between layer 3 and layer 4 of the OS1 model. The architecture in both cases is similar to the PC1 with AS1 being an interface between the AE (AH Entity) and PE (Program Entity) and CAPI being an interface between an application and an ISDN driver. They both use messages to communicate between the two entities. Like the PC1 ASI is divided into three planes, a management plane, a control plane and a user plane. The messages defined in both cases are very similar to the PC1 messages though they differ in detail. I provides a facility for manufacturer spenctions like the ETSI PC1 and a message function to select the layer two and layer three protocol which the ETSI PC1 does not support. CAP1 also supports facilities for Fax Group 3, permanent and semi-permanent connections and 0 interfaces which EuroISDN or the ETSI do not support. AS1 supports primary and basic rate ISDN and user-to-user information transfer as does the ETSI PCI. The AS1 messages use the RE ST, INDICATION, RESPONSE and CQNF OS1 service primitives.
& Interfaces
17 (1995)
169-180
177
In conclusion, APPLI/COM is a different kind of PC1 to the ETSI PC1 in terms of i.ts location in the OS1 model and the telecommunications services it supports. CAP1 and ASI are similar to the ETSI PC1 in terms of their objectives and the overall solution they arrive at although they differ in detail. 4.4 How the design could be impror;ed There are two major limitations of the design presented this paper. Firstly, a proper PCI implementation should interact directly with Q.931, the ISDN network layer. Instead, this prototype PCI implementation has been built on top of the ISDN APIs provided with the two ISDN cards used. Secondly, basing the im~l~mentatlon on an operating system like DOS that only allows one process to be activ a given time is not ideal. In a full implementation based on cards such as the Mite1 ISDN Express Card, which allow direct access to Q.931, the service layer could be removed altogether and the PCI Me tions would interact directly with ISDN Network Layer. There is a ciose correspondence between Q.931 messages and parameters and those of the PCI. This me ns that producing an implementation of the PC on top of Q.931 wauld be straightforward. It is not ideal to implement the NAF as a library of functions that are called by the PUF. It would be better, the PUF and the NAF were two separate processes on the same machine in a multi-tasking environment such as UNIX. This would be a more efficient design. The NAF would accept messages in a device independent manner for the PUF. The NAF would the.n translate these messages into (2.931 messages and send them to the network. Similarly, incoming 0,931 messages from the network would be transiated into PC1 messages by the NAF and passed to the PUF. In conclusion, while the design presented in this paper is not ideal it is a useful initial attempt at implementing the PC1 recommendation in a PC environment. The implementation could be modified later into a full PCI imp~eme~tati~~ in
178
A. Patel, J. Reilly /Computer
Standards
the event of direct access being possible to Q.931 messages. The testing phase has shown that the PC1 functions correctly. This implementation will allow PCI applications to be written and tested in advance of full PCI implementation becoming available next year. 4.5 How some of the optional features could be implemented
of the PCI
These are several optional features of the PC1 recommendation that were not implemented in this design. The mandatory Primary Rate support was not implemented due to the lack of a Primary Rate ISDN network on which to test the system. To support primary rate the service layer would have to be modified to support the primary rate I being used. The mandatory X.25 support (NMA) was not considered necessary for this prototype implementation. However, this feature could easily be added to the design if required at a later stage. It would involve implementing the NMA PC1 Messages defined in the recommendation and when opening a connection, request an ISDN connection with X.25 rather than a transparent ISDN connection. Finally, the security features could be implemented by adding the ASecurityReq message and ASecurityCnf. ASecurityReq would cause data being sent over the ISDN line to be encrypted using a suitable security algorithm. A mechanism for decrypting any incoming data would have to be implemented. 4.6 Suruey of 4SDN PC card manufacturers
A survey was undertaken as part of this research to establish some insight into the approach of the major ISDN PC card manufacturers to the PCI. In all twenty manufacturers were contacted and eight replies have been received. Replies were received from SCII, QST, ICL, Ascom Zelcorn, Loewe Qpta, Diehl ISDN, Mite1 Semiconductor and Telenorma GmbH. This does not constitute a statistically significant sample but nevertheless some conclusions may be drawn from the results which are summarised in this section.
& interfuces
I7 (1995)
169-180
Each manufacturer five questions:
was asked the following
Have you previously heard of the ETSI ISD PCI? Do you consider it to be comprehensive and easy to use? Would you consider implementing the ETSI ISDN PC1 in place of your current ISDN API(s)? What is your company’s attitude to manufacturer independent APIs in general? Do you think that the provision of a manufacturer independent ISDN API would lead to a reduction in the cost of ISDN applications? This limited survey has produced some interesting replies though a higher response rate would have been needed to draw any firm conclusions. The answer to the first question in all cases was yes, which is not surprising since most of the companies concerned are members of ET Most companies felt the ETSI PCI recommendation was comprehensive but they also felt that it would be more difficult to use than their current API. All of the manufacturers said they would at least consider implementing the PCI which is encouraging though most adopted a “wait and see’ approach to determine if their competitors would first adopt the rec~mme~~atio~. Therefore, if some of the major ISDN PC card manufacturers were to adopt the PCI recommendation then the other smaller companies would follow suit whereas if this doesn’t happen the PCI may only be implemented by a small minority and the recommendation may not succeed. All of manufacturers who replied supported the concept of manufacturer independent APIs. SCII suggested that their existing API was easier to use than the PCI. The manufacturers did not anticipate that the PC1 would not reduce the cost of ISDN applications.
This research project has demonstrated that the ETSI PC1 can be implemented on a PC using
A. Patel, J. Reilly /Computer
Standards
existing ISDN PC card APIs. The current ETSI PCI specification has been discussed in detail and possible extensions and improvements have been suggested. The PC1 specification has also been compared with other current ISDN programming interfaces. Finally, ISDN PC card manufacturers have been consulted to determine what their approach to the PCI specification is and whether they intend to implement the specification in the future. The PCI implementation described in this paper has been demonstrated at the Communications 1993 Exhibition held at the Royal Dublin Society in October 1993 using a PC1 test application which could setup and receive ISDN voice and data calls. A research paper entitled High Level Generic Design of a Programming Communications Interface for EuroISDN [13] was presented at the IFIP Conference ‘93 (Advanced Information Processing Techniques for LAN and Management) held in Versailles, France in April 1993.
& interfaces
I7 (1995)
169-280
119
and manufacturer specific barriers that are currently hindering the take-up of ISDN. The prototype implementation has shown that the PC1 specification can be irnple~~e~t~d using proprietary ISDN PC card APIs and allows applications to be written and tested that use the PCI in advance of full PC1 implementations becoming available. The prototype could be extended in the future to become a full PCI implementations Acknowledgements
We would like to thank the members of the Computer Networks and Distributed Systems search Group in LJCD, especially Niall Down&y, for their advice and assistance with our work on this project. We would also like to thank Teltec Ireland, EOLAS (through the HEIC schemeS and Euristix Ltd. for financial support for the project. Finally, we would like to thank Telecom &rearm for the use of their pilot ISDN network the testing and evaluation phase.
4.8 Future direction It is up to the ISDN PC card manufacturers to decide whether the ETSI PC1 will succeed. The prototype implementation described here could be later extended into a full PC1 implementation. The optional features not implemented in this prototype could be added. Currently, research work is in progress on defining programming interfaces which support multimedia applications for the emerging broadband ISDN (B-ISDN). The current narrowband ISDN programming interface may serve as a basis for the broadband programming interfaces of the future.
Overall the draft PC1 specification strikes a well judged balance between ease of use and functionality provided. The implementation of a single ISDN standard throughout Europe and the availability of a single programming interface for EuroISDN will help to break down the country
References
1116. Vogt, Recommendations for standard application programming interfaces relevant to ISDN and related management issues, Technical Report, DBP Telekcm, May 1991. PI ETSI, Programming communications interface for EuroISDN (pr ETS 3003251, Final Draft, Version 1.2, Nov. 1992. [31 ETSI, Integrated Services Digital Network; Programming communications interface for EuroISDN, reference number: pr ETS 300325 (rev 2), ETSI Oct. 1993. Communication Interfaces [41 A. Chaillat, Programming (PCIs)-An Overview, Technical Report, France Telecorn, Nov. 1991. Draft Specification, Study Group is1 CCITT, APPLI/COM VIII Report R32, 1992. 161Telematic Services GmbH, Common ISDN A.PII (CAPI) specification, Version 1.1, 1991. I71 North American ISDN Users Forum (NIUF), Application Software Interface (ASI) specification, Version 1.0, NIUF, Oct. 1991. 181 J. Reilly and N. Downey, Requirements document-ISDN PC1 Project. Version 2.0 March 1992, internal document (unpublished). [9] 3. Reilly and N. Downey. Design document PC1 software, Version 2.0, Oct. 6th, 1992, internal document (nnpublished).
A. Patel, J. Reilly /Computer
Standards
European Space Agency (ESA), ESA software engineering standards (issue 2 Feb. 1991), ESA PSS-05-0, ESA Publications Division, Noordwijk, The Netherlands. XI., Helgert, Integrated Services Digital Network, (Addison-Wesley, Reading, MA, 1991). A. Tanenbaum, Computer Networks (Addison-Wesley, Reading, MA, 1988). N. Downey and A. Patel, High Level Generic Design qf a Programming
Communications
Interface
for
EuroISDN,
IFIP Transactions C-17 (Elsevier Science BV, Amsterdam, 1994). Ahmed Pate1 received his MSc. and Ph.D. in computer science from Trinity College Dublin in 1977 and 1984, respectively. From 1978-82 he was responsible for developing the Irish University Data Network and from 1982-85 he developed the EuroKom computer conferencing and electronic mail service used by R&D project in Europe. At University College Dublin he is a lecturer in computer science and head of the Computer Network and Distributed Systems Research
d Interfaces
17 (199.5) 169-180
Group. He is involved in various multi-national R&D projects in ESPRIT, RACE,, INFOSEC, AIM COST and Irish National Telecommunication programmes. His main research interests include network management, security, protocol, performance evaluation, intelligent networks, CSCW and open distributed processing systems. He has published many technical oaoers and co-authored two books on comouter network security and one book on group communication’s. He is member of the Editorial Advisory Board of the Computer Communication and Collaborative Compufing journals. John Reilly received his B.Sc. from St. Patrick’s College Maynooth, Co. Kildare, Ireland in 1989. He joined the Computer Networks and Distributed Systems Research Group at the Department of Computer Science in University College Dublin in October 1991 and he completed his M.Sc. in November 1993. At present he is employed as a Systems Engineer with Mentec Picturecom Ltd. in Dublin where he is engaged in the development of PC-based videoconferencing applications. His researich interests include the Integrated Services Digital Networ -k (ISDN). Integrated Broadband Networks, Application Programming Inteaaces and Multimedia Applications.