Note: Descriptions are shown in the official language in which they were submitted.
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
1
INTERNET-SS7 GATEWAY
TECHNICAL FIELD
The present invention relates to an interface and a process for arranging said
inter-
face between an information server, e.g. .a WWW-application, and a node in an
in-
s telligent network, e.g. a service control _F'oint (SCP) so that
communication can oc-
cur 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 V~ulti 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 point) in an intelligent) network is,
according to
known technology, connected to World Wide Web via MML-signalling (Man-
V~Iachine 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
stan-
dard services implemented in the SCP. _
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
2
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 Wide V~eb, WWW, to a _Service control point, SCP, in an
intelligent network by using SS7-signalling, specifically intelligent Network
~ppli-
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
Gate-
way. 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 con-
nection to Internet is effected via _Transmission Control ~rotocol/~nternet
protocol,
TCPJIP, by using a suitable protocol, such as X.25 or Ethernet. The Internet-
SS7
Gateway emulates a service twitching _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-
seances.
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
3
The purpose of the present invention is, through a so-called Internet-SS7
Gateway,
to make it possible to communicate witlh the SCP in an intelligent network
from a
WWW-unit via FNAP.
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
obtain-
ed.
Another advantage of the present invention is that the same interface as for
Dual
_Tone I~v ulti 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
em-
bodiments 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.
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
4
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 Internet via the W W W-browser shown
in
the Figure. The user can also connect himself to the Internet via another
independent
application with corresponding properties. The application can be written in
pro-
gram language C, Java, Smalltalk, Basic or some other programming language.
Between the Service Control Point (SCP) and the Internet 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 Internet 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
com-
prises a node in the intelligent network, e.g. the SCP.
Between the above mentioned entities there are arranged three interfaces,
herein-
after called I1, I2, I3, 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 I1 is affected.
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
S
At interface I2 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 ~~ higher level of abstraction. When a
mes-
s sage is sent to the WWW-unit the strucW re of the message is converted into
strings
of characters. The parameters included iin the message are separated in a
suitable
manner, e.g. by so-called "null"-characte:rs in the program language C. The
WWW-
application, or some other application with corresponding function, connected
be-
tween the IWU and the client, can use th,e same structure for the internal
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 I2, 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 predei=lned 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 internal message type, and the
remaining
parameters are used for this conversation.
When applications of WWW-type are used, there is the possibility of
implementing
internal 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
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
6
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 re-
spouse from the SCP as regards the PIN-code, the IWU will send a message to
the WWW-application.
The same structure is used for handling the services. The WWW-application has
knowledge of which information is required to change the PIN-code, for
example.
The W W W-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
send-
ing 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
1 S typed can just as well be done in the WWW-application. Thus, the number of
com-
munications 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
sec-
ondly 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-
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
7
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 lboth from the SCP and from the WWW-
application simultaneously. This can be clone by virtue of the fact that in an
opera-
ting system, UNIX for example, with associated hardware, there are built-in
func-
tions 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
infor-
mation server.
In Figure 2 we see an internal architecture, which shows the SS7 signal and
the sig-
nal from the Internet. 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 Internet and an
application connected to the same shouldl 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 Internet.
In Figure 3 we see a f rst 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 Internet.
Initially, a client can use HTTP, for example, to request an access page on an
infor-
mation server to an IN-node. The server c;an be a WWW-server, for example. The
server can be connected to the Internet.
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
8
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 pro-
grams 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.
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
9
The IWU can consist of a separate phy:;ical 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 alternative, 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 alternative 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 alternative 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 UNI~~ Remote Procedure Call (RPC) or some
other machine-to-machine interface. Regardless of which level of abstraction
is se-
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
lected, TCP/IP or UDP/IP are used as so-called Iow-level protocol. Even X.25
could
be suitable as a protocol.
This alternative is represented in Figure 7. The IWU receives in-parameters
from
5 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 com-
munication.
The out-parameters are then returned from the IWU to the client, whereafter
these
10 parameters can be visualized at the client.
A third alternative 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 internal process calling, i.e.
direct
communication between IWU and information servers, by using the built-in func-
tions of the selected platform to transfer information between two functions
(proces-
ses) 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 alternative 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.
CA 02275584 1999-06-18
WO 98/28885 PCT/SE97/02087
11
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
f rst 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
ex-
ample, can be used as the protocol carrier..
The IWU then communicates with the SS'7-implementation by using socket commu-
nication, for example, or some other corresponding process-to-process
communica-
tion. The SS7-implementation then returns 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 alternative is shown in Figure 6.
The invention is, of course, not limited 1:o the embodiments described above
and
shown in the drawings. Rather, it can be modified within the scope of the
accompa-
nying patent claims.
