Method of asynchronous duplex data communication between two stations relating to specific services to be performed through a common communication channel, and stations for carrying out the method

Abstract: Through an asynchronous duplex data communication between a pair of stations, a PABX and a telephone management system (TMS) relating to specific services to be performed by one of the two stations, the one station requests, by means of an initialization request, a specific service and the number of times that this service is to be performed simultaneously, the so-called window, and the other station, depending on its capacity, allocates, by means of an initialization response, a number of times that the service can be performed simultaneously, which number is equal to or smaller than the requested number; a window size being allocated it is possible to proceed by means of transaction messages the actual performing of the services; these services for example applying to specific applications of a telephone system in a hotel.

Description: The invention relates to a method of asynchronous duplex data communication between two stations through a common communication channel, this communication relating to a plurality of services to be performed by one of the two stations. A system operating according to such a method is known from the European Patent Application EP-A-0 192 894. With this known method the one station is a PABX exchange providing the link between the external telephone lines of a local telephone network and a plurality of internal telephone lines of a private telephone network, while the other station is the central processing unit (CPU) of a personal computer; the communication channel comprises the common data bus of the personal computer, through which bus data communication can be effected between the CPU and the various peripheral units of the personal computer, such as the memory, the printer and the display unit, and also between the CPU and the PABX. It is an object of the known method to intergrate thus the PABX with the personal computer so that the CPU thereof can also provide the control of the PABX, as a consequence of which the latter can actually be regarded as a peripheral unit of the personal computer and for example the printer, the display unit and the memories can also be used for the benefit of the PABX for performing specific services, such as call recording, call accounting, automatic telephone call response and the like. The invention relates to the method by which such services can be performed, specifically in the case when the one station is a PABX and the other station a telephone management system (TMS). Such telephone management systems are described, for example, in an article by C.N. Smits: "Telephone Management Functions", Philips Telecommunication Review, Vol. 43, No. 2, June 1985, pp. 172-181. Thereto, it is an object of the invention to provide a method of the above type in which one of the two stations initializes a communication link by transmitting through the channel an initialization request comprising data that are representative of the requested service and the number of times n (n = 1, 2, 3, ...n) that simultaneous performing of this service is requested (the window) and in which the other station sends back through the channel an initialization response comprising data that are representative of the requested service and the allocated number of times m (m = 0, 1, 2, 3, ... m) that a simultaneous performing of the requested service is feasible with m ≦ n. A method of data communication as described in the opening paragraph is described in European Patent Application No. 0 187 945. However, the data communication between those two stations is not directed to the situation in which one station wants to be informed by the other station about the type of service the other station can provide and about the number of the number of times that simultaneous performing can be provided. Accordingly, the characterising measures of the invention are not known from this document. If the window allocated to the relevant service is ≠ 0, messages respecting the relevant service can be exchanged between the two stations, i.e. the so-called transaction. According to another aspect of the invention the transaction messages are composed of a byte sequence, the first byte indication whether a transaction request or response is concerned, the second byte indicating the relevant service, the third byte indicating a unique identification code for this specific service between these two stations, the fourth byte indicating the function code of the service and the fifth byte the number of parameters still to follow in the messages. The invention also provides stations for implementing the method according to the invention. With the measures according to the invention an efficient communication between various types of PABX and the various types of TMS is feasible, as will be further explained hereinbelow by means of a drawing with reference to an embodiment, in which drawing: Fig. 1a shows a possible structure of an initialization request for a specific service, Fig. 1b shows a possible structure of an initialization response to the request according to Fig. 1a, Fig. 2 shows a status diagram representing the possible conditions when establishing a connection between two stations, and Fig. 3 shows the exchange of a series of possible messages between the PABX and the TMS and between TMS and the PABX, Fig. 4 shows a block diagram of the structure of a PABX and TMS which are suitable for implementing the method according to the invention. Fig. 1a shows the structure of an initialization request consisting of three bytes 11, 12 and 13. Byte 11 indicates that an initialization request is concerned, byte 12 indicates which service is requested and byte 13 indicates how many times this type of service is requested to be performed simultaneously, i.e. the so-called window. Fig. 1b shows the structure of the response transmitted in reaction to the initialization request according to Fig. 1a, again consisting of three bytes 14, 15 and 16. Byte 14 indicates that an initialization response is concerned, byte 15 indicates which service is concerned, which byte is thus equal to byte 12, and byte 16 indicates the allocated number of times the service can be performed simultaneously, i.e. the so-called allocated window. For example, this number can be equal to zero if, with a TMS as the requesting station and the PABX as the responding station, this PABX does not know by far the service concerned. The number can also be smaller than the requested window size because, for example, the same service has already been allocated to other TMS systems, so that the maximum number of times that the service can be performed simultaneously has already been reached or because the number of times that the PABX can simultaneously perform this service is smaller than the requested number of times. After the exchange of messages according to Fig. 1a and Fig. 1b, a connection has basically been established and, subsequently, the messages proper can be exchanged. Such an exchange of messages between the two stations will be called a transaction hereinafter. Fig. 2 diagrammatically shows the conditions that can be assumed by the system according to the invention comprising a pair of stations and one communication channel. These conditions are denoted I to V in Fig. 2, and relate to: I: channel free, service unavailable; II: an initialization is being effected; III: channel free, service is available; IV: one or more transactions are being effected, there is room left for more transactions; V: one or more transactions are being effected, there is no room left for more transactions. The change from one to the other condition, or sometimes back to the same condition, takes place as a result of a number of happenings indicated in Fig. 2 by the arrows 1, 2, 3, 4a, 4b, 5a, 5b and 6 and having the meaning described hereinbelow. For brevity, R is the station requesting the services and D the responding station performing the service. 1: R transmits request for initialization; 2: D responds to request for initialization and allocates a window = 0; 3: D responds to request for initialization and allocates a window > 0; 4: R transmits request for transaction and a) there are still transaction-identification codes free or b) there no more transaction-identification codes free; 5: D responds to request for transaction and a) this response is the response to the latest active request for a transaction, or b) there are still one or more active requests for transactions; 6: The allocated time interval has passed; no or no valid response was received in a predetermined time interval after the transmission of the request. In each condition I to V that the system has assumed, only those happenings are recognized that may belong to the relevant condition; all other happenings are disregarded with the exception of happening I, the initialization request, which is recognized in each condition and results in this system ending up in condition II. The allocated time interval, in which a request is to be reacted to, is actually of minor importance. In practice, however, a time interval of for example 150 seconds is chosen. It is important, however, that a specific time interval be agreed upon in which a response is to be received, because otherwise a number of transactions can remain active for an unspecified length of time, so that no room or insufficient room remains for new transactions with respect to the same service. It should be pointed out that Fig. 2 shows the diagram of the condition of no more than one service. However, with the method according to the invention, the communication relating to different services, whose messages can be transmitted crossing each other, can be effected simultaneously. This is also the reason why the messages always contain an indication as to the service concerned and also an identification code for that specific service. So, the system behaves as a plurality of point-to-point connections, with one connection per service. Fig. 3 shows an example of an exchange of 27 messages between a PABX and a TMS system, the left-hand column in the Figure providing the messages from the TMS to the PABX and the right-hand column the messages from the PABX to the TMS, which messages consist of initialization messages (lines 1 to 7, 10, 11 and 16) and transaction messages on the remaining lines. The data on the various lines are represented in a hexadecimal form, two characters always forming one byte. According to the example, byte 11 is intended for an initialization request, whose structure is shown in Fig. 1a, equal to 00, while byte 14 for the subsequent initialization response is equal to 80. The code for the various services as indicated in the bytes 12 and 15 are: 81: service indication on the display screen; 82: room status; 83: message management; 84: night watchman; 04: direct automatic calling and 02: wake-up service. In the scope of the present invention it is of minor importance to describe exactly the contents of the various services. For a further explanation of these services the reader is referred to the above-mentioned article in Philips Telecommunication Review. The bytes 13 and 16 which indicate the requested and allocated window respectively, can vary from 00 implying that the window is 0, to FE implying that the window is 254. All initialization requests and responses consist of three bytes, as shown in the Figs. 1 and 3. Transaction requests and responses, however, can consist of a much larger number of bytes. On line 8 the first transaction request is represented for service 83, the first byte, 01, indicating that a transaction request is concerned, the second byte, 83, indicating the service and the third byte the identification code for this transaction in the relevant window. The fourth byte, 01, relates to the function code further to be explained hereinbelow, the fifth byte, 02, indicates how many parameters follow, thus 2 in this case, the first parameter being equal to 22, 23, 15. Herein, the first part of the first byte, 2, indicates that a so-called type-2 parameter is concerned, which stands for a sequence of digits and the second part of the first byte, 2, that two bytes are to follow. These two next bytes, 23, 15 relate to an extension number. The second parameter starts with 2A, the first part, 2, of this byte again indicating that a so-called type-2 parameter is concerned, thus a sequence of digits, and the second part, A, that ten bytes are to follow. In the example shown these ten bytes relate to a selected number 00, the signs FF being filler characters. Line 9 shows the response to the transaction request of line 8; that this is a response appears from the header 81, the response being intended for service 83 having identification code 00. The function code, which is represented by the fourth byte, is 01, the number of parameters as indicated by the fifth byte is 01, and the parameter itself is 1100, this is a type-1 parameter, which stands for a one-byte transaction completion code, the code itself is 00, which stands for a successful completion. So, a transaction message is always constructed as follows: Byte 1: 01: transaction request 81: transaction response; Byte 2: code of the service concerned; compare the above Table in this respect. Basically, 255 different services are possible. Byte 3: identification code for this transaction relating to the service indicated by byte 2. The maximum number of identification codes for a specific service is equal to the size of the window allocated to this service. Byte 4: the function of the service to be performed; needless to observe that this function strongly depends on the service to be performed, but is for example with service 83 the automatic reporting of a message, equal to 01 for starting the service and 02 for stopping this service. For other services the function codes that may range from 0 to 254 naturally have another meaning and can be selected freely depending on the relevant service. Byte 5: the number of parameters to follow; Byte 6: the first byte of the first parameter. The four least significant bits of this byte denote the length of the data sequence to follow and the four most significant bits the type of the data sequence; this can be a completion code, a digit sequence or the like. Byte x: the first byte of every next parameter is structured in a manner equal to that of byte 6. With the aid of the above explanation the series of transaction messages according to Fig. 3 can now be followed in a simple way and therefore, it will only be briefly discussed hereinbelow. Line 12 shows a request for service 04, the automatic direct calling, extension 1409 being requested to be connected to extension 2358. The response to this request is found on line 13. The completion code appears to be 04 which in this service implies that the source has not assumed the proper condition for automatic direct calling. The order is repeated by the user on line 14 while it now appears that the completion code on line 15 is equal to 00, which implies that the connection has been established. Line 16 shows an initialization request for service 02, the wake-up service. The requested window is 10 but the allocated window, as indicated on line 17, is equal to 5. On lines 18, 19 and 20 there are transaction requests for waking up extensions 1402, 1403 and 1404, transaction codes 00, 01 and 02 being issued successively. The second parameter is always a type-3 parameter which stands for a port identification, in this case the identification of port 04, which is indicated by the last byte. Port 4 in the PABX can be an automatic speech circuit for a wake-up message, but also an ordinary extension with which a receptionist can wake the guests up. On line 21 is shown the response to line 19 with completion code 05, which stands for the source being engaged, so the extension 1403 is engaged. The next request, which is found on line 22, gets the transaction identification code 01 because it is free again. The lines 25, 26 show the responses to the requests on lines 20, 22 respectively, with 00 as a completion code, which means success, whereas line 27 shows the response to line 18 with 07 as a completion code, which means that the maximum time has elapsed because extension 1402 has not responded. Fig. 4 shows in a block diagram the structure of a PABX 1 that is connected to a TMS 3 through a data bus 2. The PABX comprises a central control unit 4 with a memory 4′, an interface 5 for connecting the PABX to a number of internal lines 6; an interface 7 for connecting the PABX to a number of external telephone lines 8 and an interface 9 through which a control unit 10 can be connected by means of a data bus 11. The TMS 3 comprises at least a central control unit 12 with a memory 12′, a display unit 13 and a keyboard 14, by means of which data concerning requested services can be applied to the TMS. The requested data can be displayed on the display unit. For the way in which communication can be effected between the TMS and the PABX for transmitting and receiving messages according to the method of the invention under the control of the central control units 4 and 12 respectively, the reader is referred to the aforementioned article from Philips Telecommunication Review. From the foregoing it will be evident that by means of the method according to the invention a very efficient communication between two stations is feasible with respect to specific services to be performed, it likewise being feasible to interlink stations of different types, for example older and newer stations without this causing problems, because if one station knows a specific service and the other station does not, the other station, if requested to provide this specific service, only needs to react by allocating a window 0. Even if a station has a specific capacity for a specific service, it can be eschewed that communication problems arise in case a larger capacity is requested, by allocating a window size tuned to the capacity of the responding station. It should be stressed that the specific structure of the initialization and transaction messages has been given hereinbefore only by way of example and that, depending on the specific use, within the scope of the invention not only the initialization messages but also especially transaction messages can be tuned to specific desires on a large number of points

Claims: A method of asynchronous duplex data communication between two stations (1, 3) through a common communication channel (2), this communication relating to a plurality of services to be performed by one of the two stations, characterized in that a communication link is initialized by one of the two stations (1, 3) by transmitting through the channel an initialization request (11, 12, 13) comprising data that are representative of the requested service and for the number of times n (n = 1, 2, 3, ..., n) that simultaneous performing of this service is requested (i.e. the so-called window) and in which the other station sends back through the channel (2) an initialization response (14, 15, 16) comprising data that are representative for the requested service and the allocated number of times m (m = 0, 1, 2, 3, ..., m) that a simultaneous performing of the requested service is feasible, with m ≦ n. A method as claimed in Claim 1, characterized in that initialization request (11, 12, 13) and the response thereto (14, 15, 16) are each composed of three bytes, the first byte indicating whether a request or a response is concerned, the second byte indicating the requested service and the third byte indicating the requested window in case of a request and the allocated window in ease of a response. A method as claimed in Claim 1 or 2, characterized in that a service can be performed by means of a transaction if the allocated window is > 0. A method as claimed in Claim 3, characterized in that a transaction consists of a request and a response, each comprising a byte sequence, the first byte indicating whether a transaction request or response is concerned, the second byte indicating the relevant service, the third byte indicating a unique identification code for this specific transaction, the fourth byte indicating the function code of the service and the fifth byte the number of parameters still to follow. A method as claimed in Claim 4, characterized in that the first byte of each parameter comprises an identification with respect to the type of data sequence that is to follow and with respect to the length of that data sequence. A station (3) for carrying out synchronous duplex data communication with another station (,1) through a common communication channel (2), this communication relating to a plurality of services to be performed by the another station (1), characterized by means (12, 12') for transmitting an initialization request consisting of a first byte sequence (11, 12, 13), means (12, 12') for receiving an initialization response (14, 15, 16) also consisting of a first byte sequence, means (12, 12') for determining whether an initialization is successful and means for transmitting a transaction request consisting of a second byte sequence and means for receiving a transaction response also consisting of a second byte sequence. A station (1) for carrying out synchronous duplex data communication with another station (3) through a common communication channel (2), this communication relating to a plurality of services to be performed by the first mentioned station (3), characterized by means (4, 4') for receiving an initialization request (11, 12, 13) consisting of a first byte sequence, means for transmitting an initialization response (14, 15, 16) also consisting of a first byte sequence in response to the received initialization request (11, 12, 13), means (4, 4') for receiving a transaction request consisting of a second byte sequence and means for transmitting a transaction response also consisting of a second byte sequence in response to the received transaction request. A station as claimed in claim 6 or 7, in which the length of the first sequence is equal to 3 and in which the length of the second sequence is at least equal to 6.

Inventors: DAMS FRANCISCUS JOHANNES LAMBE, DAMS, FRANCISCUS JOHANNES LAMBERTUS
Applicants: PHILIPS NV, N.V. PHILIPS' GLOEILAMPENFABRIEKEN
Application year: 1989
Main classification: H04Q3
IPC codes: H04M11, H04L29, H04M3, H04Q3