WO1998028885A1

WO1998028885A1 - Internet-ss7 gateway

Info

Publication number: WO1998028885A1
Application number: PCT/SE1997/002087
Authority: WO
Inventors: Jörgen TRÄNK
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1996-12-20
Filing date: 1997-12-12
Publication date: 1998-07-02
Also published as: AU731122B2; NO992963L; AU5352098A; JP2001507189A; KR20000069647A; CA2275584A1; SE9604784D0; SE516244C2; BR9713750A; NO992963D0; EP0958684A1; CN1247659A; SE9604784L; TW455787B

Abstract

The present invention relates to a device between a unit connected to the Internet and a node in an intelligent network, where the device is provided with means for converting a signal from the node in the intelligent network into a compatible signal for the unit coupled to the Internet and vice versa. The invention also comprises a method for connecting an information server to a node in an intelligent network via the Internet.

Description

INTERNET-SS7 GATEWAY TECHNICAL FIELD

The present invention relates to an interface and a process for arranging said interface between an information server, e.g. a WWW-application, and a node in an in- telligent network, e.g. a Service Control Point (SCP) so that communication can occur between them via CCITT Signal System No. 7.

RELATED ART

The number of different services in modern intelligent networks (IN) has increased rapidly of late. Most services require some form of guidance from an end user. In some simple services, the guidance from the end user only consists of changing a value, such as e.g. changing at which telephone the end user can be reached. Other services require more complicated guidance from the end user, such as the Virtual Private Network Service, where a subscriber can connect an extra telephone to the network and give it a new internal number.

In new services, the end user has a broad range of possibilities for determining the way in which the service will work. This possibility implies increased need for a simple and effective guidance from the end user. In most cases, the guidance is provided from the end user via the telephone with so-called DTMF-signalling (Dual Tone Multi Frequency). This method of guiding IN-services is acceptable when simple services are to be performed. Another method is controlling via a graphic interface in a WWW (World Wide Web) the services in an intelligent network. A so-called SCP (Service Control P_oint) in an intelligent network is, according to known technology, connected to World Wide Web via MML-signalling (Man- Machine Language). A serious disadvantage of this type of connection is that it is slow and that MML-signalling cannot be used to utilize a number of different standard services implemented in the SCP. DESCRIPTION OF THE INVENTION

Recently, end users have been given more and more influence in controlling IN- services. This means that these end users will create a need for that control to be as rapid and user-friendly as possible. With known technology this is not satisfied, and this is a problem.

The purpose of the present invention is thus to solve the above mentioned problems by connecting a World W_ide Web, WWW, to a Service Control Point, SCP, in an intelligent network by using SS7-signalling, specifically Intelligent Network Appli- cation Protocol, INAP.

The WWW-unit to which a user can be connected via a PC, for example, is in turn connected to the SCP in the intelligent network via a so-called Internet- SS7 Gateway. This Gateway makes it possible for the user, through Internet/WWW, for ex- ample, to connect himself via a normal traffic interface to a network node.

The Gateway communicates with the SCP over SS7-links by using INAP. The connection to Internet is effected via Transmission Control Protocol/Internet Protocol, TCP/IP, by using a suitable protocol, such as X.25 or Ethernet. The Internet-SS7 Gateway emulates a Service Switching Point, SCP, or a Service Data Point, SDP, to the SCP. The Gateway supports the same INAP functionality as a normal SCP/SDP. When the Internet-SS7 Gateway functions as a Service Switching Point, SSP, it gains the use of the INAP-operations which makes it possible for the user to change/update his parameters in the IN-services. When it functions as an SDP, it uses a so-called Update/Retrieve function to update the parameters in the IN- services. The purpose of the present invention is, through a so-called Internet-SS7 Gateway, to make it possible to communicate with the SCP in an intelligent network from a WWW-unit via INAP.

An advantage of the present invention is that, by direct contact between a WWW- unit and the SCP in the intelligent network, rapid execution via SS7-links is obtained.

Another advantage of the present invention is that the same interface as for Dual Tone Multi Frequency, DTMF-signalling to the SCP is used, which means that all predefined services controlled by DTMF-signalling can be used.

An additional advantage of the present invention is that services can be triggered from the WWW-unit.

The invention will now be described in more detail with the aid of preferred embodiments and with reference to the accompanying drawings.

DESCRIPTION OF THE FIGURES Figure 1 shows a network topology in which the invention is implemented.

Figure 2 shows an inner structure firstly in the SS7-link and secondly in the Internet link.

Figure 3 shows the portion of a flow chart, which covers step by step how a client can connect himself to a node in an intelligent network via the Internet. Figure 4 shows a first example of the continuation of the flow chart of Figure 3.

Figure 5 shows a second example of the continuation of the flow chart of Figure 3.

Figure 6 shows a third example of the continuation of the flow chart of Figure 3.

Figure 7 shows a fourth example of the continuation of the flow chart of Figure 3. - PREFERRED EMBODIMENTS

In Figure 1 we see one example of a network topology in which the invention is implemented. A user is connected to the Intemet via the WWW-browser shown in the Figure. The user can also connect himself to the Intemet via another independent application with corresponding properties. The application can be written in program language C, Java, Smalltalk, Basic or some other programming language. Between the Service Control Point (SCP) and the Intemet there is, in accordance with the invention, an Internet-SS7 Gateway. The purpose of said Internet-SS7 Gateway is to convert the program language from the Intemet to a language which the SCP can handle and vice versa.

In Figure 1, four logical entities are identified. A first entity comprises the client, e.g. a WWW-browser. A second entity comprises the WWW-server or a unit with the corresponding function. A third entity comprises the inventive Internet-SS7 Gateway which can also be called the Inter Working Unit (IWU). The entities two and three can, as shown in this Figure, be arranged in the same physical machine but can also be arranged in separate physical machines. A fourth and last entity comprises a node in the intelligent network, e.g. the SCP.

Between the above mentioned entities there are arranged three interfaces, hereinafter called II, 12, 13, counted from the WWW-client. The client uses initially Hyper Text Transfer Protocol, HTTP, to pick up an access page on the server. This page can thereafter be manipulated, e.g. by giving a user ID and a password. Now, either HTTP or Common Gateway Interface (CGI) can be used, depending on how the server page is implemented. As a reply to the User ID and the password, a page or a number of Java classes can be sent to the client via HTTP. None of the dialogue up to now interferes with the IWU. Only the interface II is affected. At interface 12 there is an interface protocol between the inventive IWU and the server. The communication between the IWU and the user application, e.g. the WWW, comprises messages of socket type, for example. Socket communication is a process-to-process communication on a higher level of abstraction. When a mes- sage is sent to the WWW-unit the stmcture of the message is converted into strings of characters. The parameters included in the message are separated in a suitable manner, e.g. by so-called "null"-characters in the program language C. The WWW- application, or some other application with corresponding function, connected between the IWU and the client, can use the same structure for the intemal messages as the IWU, but it is not forced to.

The IWU is closely bound to the application it is intended to serve. A message can, for example, include instructions as to which message the transmission is to start, how the message is to be sent and how many characters are to be obtained. The message can also comprise information on how the characters are to be received. This information passes the interface 12, i.e. between the WWW-server and the IWU.

In the IWU there can be a number of predefined messages which the IWU can ob- tain from the SCP. Incoming messages to the IWU are checked to see if they belong to the predefined messages. In the predefined messages, the values of most of the parameters are determined. An incoming message is regarded as accepted when its parameters agree with the parameters in the predefined message. The incoming message is then regarded as a message of intemal message type, and the remaining parameters are used for this conversation.

When applications of WWW-type are used, there is the possibility of implementing intemal functions. In order to save band width and to increase performance, the WWW-application can ask the client for both PUI and PIN at the same time and then send these to the IWU together and at the same time. The IWU will in turn first send the PUI to the SCP, then wait for a response from the SCP as regards the PIN, and then the IWU will send the PIN-code to the SCP. When the IWU receives a response from the SCP as regards the PIN-code, the IWU will send a message to the WWW-application.

The same stmcture is used for handling the services. The WWW-application has knowledge of which information is required to change the PIN-code, for example. The WWW-application collects the required information and sends this to the IWU, which in turn processes the information and completes the operation.

A typical example of the functionality of the WWW-application is that, when sending a new PIN-code, i.e. changing it, the PIN-code need not be sent two times to the IWU to verify the code. The verification of the fact that the PIN-code is correctly typed can just as well be done in the WWW-application. Thus, the number of communications is significantly reduced between the two parties.

In each dialogue where the IWU is involved, the state of the dialogue is analyzed. The state is, in most cases, the most recent message sent from the IWU and is used to check if an incoming message is acceptable. When a message is received, its state is checked. For most states, only a specific message from the WWW-application or the SCP is accepted. This has to do with the fact that after initiation of the dialogue between the SCP and the WWW, the WWW-application only responds to special questions. By checking that the correct message has been obtained, we avoid errors and make it more difficult for unauthorized users to break in.

The IWU can use time spaces to handle the messages, firstly from the SCP and secondly from the WWW-application. The IWU checks for messages from the SCP- during a given time interval. If there are messages in the queue, these will be proc- essed. The IWU then checks for messages from the WWW-application during a given time interval. If there are messages in the queue, these are processed. It is a simple, but absolutely not optimal solution.

The IWU can also check the messages both from the SCP and from the WWW- application simultaneously. This can be done by virtue of the fact that in an operating system, UNIX for example, with associated hardware, there are built-in functions which permit the IWU to work with both queues simultaneously. One method is to use a function in UNIX which is called socket. This function permits the IWU- function to wait simultaneously for messages from both the IN-node and the information server.

In Figure 2 we see an intemal architecture, which shows the SS7 signal and the signal from the Intemet. The different types of SS7 signals are well known for a person skilled in the art and should not need to be described in more detail. The different protocols which are encompassed in the connection between the Intemet and an application connected to the same should not need to be described in more detail here either, since they are also well known to a person skilled in the art.

The Internet-SS7 Gateway can be said to function as a bridge or a link between the SCP and a WWW-like application coupled to the Intemet.

In Figure 3 we see a first part of a flowchart showing how a user of a computer, for example, can link up to an SCP in an intelligent network via the Intemet.

Initially, a client can use HTTP, for example, to request an access page on an information server to an IN-node. The server can be a WWW-server, for example. The server can be connected to the Intemet. In the next step, the information server sends authorization formalities to the client which can comprise questions concerning the client's user identity and password.

In the next step, the client provides his user identity and associated password, which are sent to the information server. Here there are at least two different ways of choosing when this information is to be provided to the information server. A first way is to use HTTP and a second way is to use the Common Gateway Interface, CGI. Common Gateway Interface is a de facto standard for so-called gateway programs to interfaces towards information servers such as WWW. This standard is, of course, well known to a person skilled in the art and therefore need not be described in more detail here.

In the next step, the information server examines the password and the user identity. If the user identity and the password agree, the client will be given access to the re- quested application. If not, the client will, of course, not be given access, and the client can then be given a number of new tries to access the application.

Assuming the above process has occurred and the client is authorized, the next step then follows. In this step, the information server sends a menu of different opera- tions which can be performed in the application.

In the next step, the client selects one of the operations which are available. In this stage, a communication is started between the client, on the one hand, and the IN- node, on the other hand, via the previously mentioned IWU. Here there are a num- ber of conceivable alternatives for how this communication is to be established in practice. The IWU can consist of a separate physical unit or be included in the information server. If we assume that the information server and the IWU are arranged together, there are at least the three following alternatives.

In a first altemative, communication may take place via CGI from the client via the information server. This means that a so-called IWU-binary reads a common text string from standard input which the information server provides it with. The IWU then returns the messages to the client via standard output and via the information server. The protocol between the information server and the IWU could thus be normal so-called file descriptors (stdin/stdout) implemented in UNIX.

This altemative is represented in Figure 4. In a first stage, the information server sends input parameters to the CGI-program, the above mentioned stdin, stdout and the surrounding variables.

In the next step, the CGI-program communicates with the IN-node via SS7-imple- mentation by using socket communication.

In the next step, the CGI-program returns the out-parameters via the information server to the client which in those cases where the parameters are of value to the user, are presented for him.

A second conceivable altemative would be that the client sets up a socket directly to the IWU (for example, in the program language Java and thus completely discon- nects the server from the dialogue) after the initial dialogue with the information server. Thus, the protocol from the IWU to the client would be sockets. Another possibility would be using standard UNIX Remote Procedure Call (RPC) or some other machine-to-machine interface. Regardless of which level of abstraction is se- lected, TCP/IP or UDP/IP are used as so-called low-level protocol. Even X.25 could be suitable as a protocol.

This altemative is represented in Figure 7. The IWU receives in-parameters from the client through one of the above mentioned machine-to-machine protocols. In the next step, the IWU communicates with SS7-implementation by using socket communication.

The out-parameters are then returned from the IWU to the client, whereafter these parameters can be visualized at the client.

A third altemative is that the IWU-process will be included in an information server where the behaviour of the server is increased with the behaviour of the IWU. The communication can then take place by direct intemal process calling, i.e. direct communication between IWU and information servers, by using the built-in functions of the selected platform to transfer information between two functions (processes) within the same machine. This communication takes place at so-called method calling level or possibly wire communication depending on the configuration of the servers.

The third altemative is represented in Figure 6. In a first step, the information server sends in-parameters to the IWU by using the above mentioned communication at method calling level. The IWU-portion of the server then communicates with the SS7-implementation by using socket communication. In the next step, the out- parameters are returned from the IWU-portion of the server to the "core"-server, which in turn sends these to the client. These can, as in the other cases, be made visible to the user if they have any use therefor. The information server and the IWU can be arranged in two separate machines or processes in the same machine. Figure 5 shows a flowchart for this example. In a first step, the information server sends in-parameters to the IWU by using a process- to-process communication protocol or a machine-to-machine communication proto- col. RPC, for example, can be used as protocol and TCP/IP, UD/IP or X.25, for example, can be used as the protocol carrier.

The IWU then communicates with the SS7-implementation by using socket communication, for example, or some other corresponding process-to-process communica- tion. The SS7-implementation then retums the out-parameters to the IWU which in turn, after processing, sends them to the information server. The out-parameters are then forwarded to the client. The out-parameters can then be visualized for the user. This altemative is shown in Figure 6.

The invention is, of course, not limited to the embodiments described above and shown in the drawings. Rather, it can be modified within the scope of the accompanying patent claims.

Claims

1. Device between a unit connected to the Intemet and a node in an intelligent network, characterized in that the device is provided with means for converting a sig- nal from the node in the intelligent network into a compatible signal for the unit connected to the Intemet and vice versa.

2. Device according to Claim 1, characterized in that the means for converting the signals is a program code written in a computer language.

3. Device according to Claim 2, characterized in that the computer language is C, Java, Smalltalk, Pascal, Fortran or Basic.

4. Device according to Claim 1, characterized in that the unit coupled to the Inter- net is an information server.

5. Device according to Claim 4, characterized in that the information server is a World Wide Web unit, a so-called WWW-unit.

6. Device according to one of the above claims, characterized in that the signal from the node in the intelligent network is a signal from Comite Consultatif International Telegraphique et Telephonique Signal System No. 7, CCITT-SS7.

7. Device according to Claim 6, characterized in that the CCITT-SS7-signal is In- telligent Network Application Protocol, INAP.

8. Device according to Claim 1, characterized in that the signal from the WWW- unit is of the type Transmission Control Protocol / Internet Protocol, TCP/IP.

9. Device according to Claim 1, characterized in that the node in the intelligent network is a Service Control Point, SCP.

10. Method of connecting an information server to a node in an intelligent network via the Intemet, characterized in

- that between the information server and the node in the intelligent network there is a so-called Inter Working Unit, IWU,

- that said IWU transforms a signal from the information server to a suitable signal for the node in the intelligent network, - that said IWU transforms a signal from the node in the intelligent network into a suitable signal for the information server.

11. Method according to Claim 10, characterized in that the information server is a WWW-application.

12. Method according to Claim 11, characterized in that the node in the intelligent network is a Service Control Point, SCP.

13. Method according to Claim 12, characterized in that the signal from the SCP is INAP.

14. Method according to Claim 13, characterized in that the signal from the WWW-application is TCP/IP. AMENDED CLAIMS

[received by the International Bureau on 28 May 1998 (28.05.98), original claims 1-14 replaced by new claims 1-15 (2 pages)]

1 Device between a unit connected to the Internet and a node in an intelligent net work (IN), characterized in that the device is provided with means for emulating a Service Switching Point (SSP) or a Service Data Point (SDP) to a Service Central Point (SCP) of the IN by converting a signal from Comite Consultatif International Telegraphique et Telephonique Signal System No. 7, CCITT-SS7 from the node in the IN into a compatible signal for the unit connected to the Internet and vice versa.

2 Device according to claim 1, characterized in that the means for converting the signals is a program code wntten m a computer language.

4. Device according to claim 1, characterized in that the unit coupled to the Internet is an information server.

6. Device according to one of the above claims, characterized in that the signal CCITT-SS7 is Intelligent Network Application Protocol, INAP.

7 Device according to claim 1, characterized in that the signal from the WWWunit is of the type Transmission Control Protocol/Internet Protocol, TCP/IP.

8 Device according to claim 1, characterized in that the node in the intelligent network is a Service Control Point, SCP

9. Device according to one of the above claims, characterized in that the Dual Tone Multi Frequency, DTMF signalling to the node is used.

10. Device according to claim 9, characterized in that predefined services controlled by DTMF controlled by DTMF signalling are used.

11. Method of connecting an information server to a node in an intelligent network (IN) via the Internet, characterized in - that between the information server and the node in the intelligent network there is a so-called Inter Working Unit, IWU, emulating a Service Switching Point (SSP) or a Service Data Point (SDP) to a Service Central Point (SCP) of the IN,

- that said IWU transforms a signal from the information server to a signal from Comite Consultatif International Telegraphique et Telephonique Signal System No. 7, CCITT-SS7 in the intelligent network,

- that said IWU transforms a signal from the'node in the intelligent network into a suitable signal for the information server.

12. Method according to claim 11, characterized in that the information server is a WWW-application.

13. Method according to claim 11, characterized in that the node in the intelligent network is a Service Control Point, SCP.

14. Method according to claim 13, characterized in that the signal from the SCP is INAP.

15. Method according to claim 12, characterized in that the signal from the WWW-application is TCP/IP.