 |
Claims  |
|
|
I claim:
1. In a distributed processing system having at least an originating and a responding node connected through a communication path wherein the responding node comprises a plurality of
processors and a memory device, wherein each of said processors has a corresponding database associated therewith and residing within said memory device, a method for use in processing successive portions of a conversational transaction using different
ones of said processors comprising the steps of:
in a first one of the processors in said responding node:
processing a first portion of a conversational transaction as specified by a first record, wherein the first record defines a manner in which the conversational transaction is to be completely processed and is located within a first database
residing within the memory device and associated with the first processor;
storing context information for the conversational transaction as a second record at a pre-defined address in the first database, wherein the context information defines a current state of the conversational transaction; and
producing a first message, as part of the conversational transaction for transmission from said responding node over said communication path to said originating node wherein the first message contains a request for application information from
the originating node, and a first transaction identifier field having a value that corresponds to said pre-defined address, said application information being defined by the first record and required for processing a second portion of the conversational
transaction subsequent to said first portion;
in said originating node;
generating a second message, as part of said conversational transaction and in response to said first message, for transmission over said communication path to said responding node, wherein said second message contains the application
information, furnished in response to said request, and a second transaction identifier field having the same value as the first transaction identifier field; and
in a second one of said processors in said responding node and different from the first one of said processors:
receiving said second message;
generating the pre-defined address from the value of the second transaction identifier field contained in the second message;
accessing, in response to said pre-defined address generating step, the context information from said first database; and
processing the second portion of the conversational transaction using the application information contained in said second message and commencing at a point in the first record defined by the context information.
2. The method of claim 1 wherein, in said first one of the processors, said producing step comprises the step of inserting an instruction field into said first message wherein said instruction field specifies a pre-defined item of the
application information, said item being defined by said first record and required by said responding node to process the second portion of the conversational transaction;
and wherein, in said originating node, the second message generating step comprises the step of inserting a protocol field into the second message wherein said protocol field contains the item of application information.
3. The method in claim 2 further comprising, in said second one of the processors, the step of updating the context information stored in said second record to reflect the current state of the conversational transaction.
4. The method of claim 3 wherein the first record is a customer record and, in the first one of the processors, the first message producing step comprises the step of preforming a database look up operation into the customer record to determine
the pre-defined item of information required to process the second portion of the conversational transaction.
5. The method in claim 4 further comprising, in the first one of the processors, the steps of:
receiving a request from said originating node to process a conversational transaction; and
performing said first portion processing step in response to said request.
6. The method of claim 4 further comprising, in said first one of the processors, the step of forming said first transaction identifier to contain a plurality of separate fields wherein first, second and third ones of said separate fields
contain corresponding numbers that respectively identify a specific one of the processors, a specific software process executing on the specific processor and a relative address pointing to a desired one of a plurality of second records residing within a
context file situated in said first database.
7. The method in claim 4 wherein said communication path comprises a signalling network having an internal node and being interconnected between said originating and responding nodes wherein each of the processors in the responding node is
connected through a separate corresponding front end processor located in said responding node to a physical link in a link set that connects the responding node to the internal node and said method further comprises the step of distributing messages
being transmitted from said internal node to said responding node on a substantially equal basis over individual physical links then active in the link set.
8. The method in claim 7 in which the originating node is a service switching point, the responding node is a service control point and the internal node is a signal transfer point.
9. The method in claim 4 wherein said first database comprises a context file formed of a plurality of second records and further comprises, in said first one of the processors, the steps of:
storing a relative address to a first one of the second records in the context file as an index value, said second records forming the context file within said first database; and
incrementing the index value after each successive one of the second records has been established in the context file.
10. The method of claim 9 further comprising the step of permitting the index value to roll over to a relative address associated with the first one of the second records in the context file after said index has been incremented past a relative
address associated with a last one of the second records in the context file.
11. The method in claim 10 wherein said first message producing step comprises the step of forming said first transaction identifier to contain a plurality of separate fields wherein first, second and third ones of said separate fields contain
corresponding numbers that respectively identify a specific one of the processors, a specific software process executing on the specific processor and a relative address pointing to a desired one of the plurality of second records residing within the
context file situated in said first database.
12. In a distributed processing system having at least an originating and a responding node connected through a communicating path wherein the responding node comprises a plurality of processors and a memory device, wherein each of said
processors has a corresponding database associated therewith and residing within said memory device, a method for use in processing successive portions of a conversational transaction using different ones of said processors comprising the steps of:
in said originating node:
generating, in response to an incoming request for a specific service, a corresponding request to begin a conversational transaction;
transmitting the corresponding request over said communication path to said responding node;
in a first one of the processors in said responding node:
receiving said corresponding request;
processing, in response to said corresponding request, a first portion of a conversational transaction as specified by a first record, wherein the first record defines a manner in which the conversational transaction is to be completely processed
and is located within a first database residing within the memory device and associated with the first processor;
creating a second record at a pre-defined address in the first database;
storing context information for the conversational transaction within the second record, wherein the context information defines a current state of the conversational transaction;
producing a first message, as part of the conversational transaction for transmission from said responding node over said communication path to said originating node wherein the first message contains a request for application information from
the originating node, and a first transaction identifier field having a value that corresponds to said pre-defined address, said application information being defined by the first record and required for processing a second portion of the conversational
transaction subsequent to said first portion; and
transmitting said first message to said originating node;
in said originating node;
receiving said first message; and
generating a second message, as part of said conversational transaction and in response to said first message, for transmission over said communication path to said responding node, wherein said second message contains the application
information, furnished in response to said request, and a second transaction identifier field having the same value as the first transaction identifier field; and
in a second one of said processors in said responding node and different from the first one of said processors:
receiving said second message;
generating the pre-defined address from the value of the second transaction identifier field contained in the second message;
accessing, in response to said pre-defined address generating step, the context information from said first database;
processing the second portion of the conversational transaction using the application information contained in said second message and commencing at a point in the first record defined by the context information so as to provide a response
message; and
transmitting said response message to said originating node to conclude the conversational transaction such that the originating node is able to provide the specific service.
13. The method of claim 12 further comprising, in said second one of the processors, the step of updating the context information stored in said second record to reflect the current state of the conversational transaction.
14. The method of claim 13 wherein the first record is a customer record and, in the first one of the processors, the first message producing step comprises the step of preforming a database look up operation into the customer record to
determine the pre-defined item of information required to process the second portion of the conversational transaction.
15. The method of claim 14 wherein said communication path comprises a signalling network having an internal node and being interconnected between said originating and responding nodes wherein each of the processors in the responding node is
connected through a separate corresponding front end processor located in said responding node to a physical link in a link set that connects the responding node to the internal node and said method further comprises the step of distributing messages
being transmitted from said internal node to said responding node on a substantially equal basis over individual physical links then active in the link set.
16. The method of claim 14 wherein said first database comprises a context file formed of a plurality of second records and further comprises, in said first one of the processors, the steps of:
storing a relative address to a first one of the second records in the context file as an index value, said second records forming the context file within said first database; and
incrementing the index value after each successive one of the second records has been established in the context file.
17. The method of claim 16 wherein said first message producing step comprises the step of forming said first transaction identifier to contain a plurality of separate fields wherein first, second and third ones of said separate fields contain
corresponding numbers that respectively identify a specific one of the processors, a specific software process executing on the specific processor and a relative address pointing to a desired one of the plurality of second records residing within the
context file situated in said first database.
18. In a system for processing calls for network services, said system having a service switching point (SSP) and a service control point (SCP) connected through a signalling network containing a signal transfer point (STP) and wherein the SCP
comprises a plurality of processors and a memory device, wherein each of the processors has a corresponding database associated therewith and residing within said memory device, a method for use in processing successive portions of a conversational
transaction using different ones of said processors comprising the steps of:
in the SSP:
generating a query message to begin a conversational transaction in response to an incoming call for a desired network service; and
transmitting the query message over said network to the SCP;
in a first one of the processors in the SCP:
receiving said query message;
processing, in response to said query message, a first portion of a conversational transaction as specified by a first record, wherein the first record defines a manner in which the conversational transaction is to be completely processed and is
located within a first database residing within the memory device and associated with the first processor;
creating a second record at a pre-defined address in the first database;
storing context information for the conversational transaction within the second record, wherein the context information defines a current state of the conversational transaction;
producing a first message, as part of the conversational transaction for transmission from said SCP over said communication path to said SSP wherein the first message contains a request for application information from the SSP, and a first
transaction identifier field having a value that corresponds to said pre-defined address, said application information being defined by the first record and required for processing a second portion of the conversational transaction subsequent to said
first portion; and
transmitting said first message to the SSP; in the SSP:
receiving said first message; and
generating a second message, as part of said conversational transaction and in response to said first message, for transmission over said network to said SCP, wherein said second message contains the application information, furnished in response
to said request, and a second transaction identifier field having the same value as the first transaction identifier field; and
in a second one of said processors in the SCP and different from the first one of said processors:
receiving said second message;
generating the pre-defined address from the value of the second transaction identifier field contained in the second message;
accessing, in response to said pre-defined address generating step, the context information from said first database;
processing the second portion of the conversational transaction using the application information contained in said second message and commencing at a point in the first record defined by the context information so as to provide a response
message; and
transmitting said response message to said SSP to conclude the conversational transaction such that the SSP is able to provide the desired network service.
19. The method of claim 18 wherein the first record is a customer record and, in the first one of the processors, the first message producing step comprises the step of preforming a database look up operation into the customer record to
determine the pre-defined item of information required to process the second portion of the conversational transaction.
20. The method of claim 19 wherein each of the processors in the SCP is connected through a separate corresponding front end processor located in the SCP to a physical link in a link set that connects the SCP to the STP and said method further
comprises the step of distributing messages being transmitted from the STP to said SCP on a substantially equal basis over individual physical links then active in the link set.
21. The method of claim 20 wherein said first database comprises a context file formed of a plurality of second records and further comprises, in said first one of the processors, the steps of:
storing a relative address to a fist one of the second records in the context file as an index value, said second records forming the context file within said first database; and
incrementing the index value after each successive one of the second records has been established in the context file.
22. The method of claim 21 wherein said first message producing step comprises the step of forming said first transaction identifier to contain a plurality of separate fields wherein first, second and third ones of said separate fields contain
corresponding numbers that respectively identify a specific one of the processors, a specific software process executing on the specific processor and a relative address pointing to a desired one of the plurality of second records residing within the
context file situated in said first database. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE DISCLOSURE
The invention relates to a method for handling conversational transactions in a distributed processing environment and specifically to such a method suited for use in real time fault tolerant transaction processing system employed in a service
control point.
A service control point ("SCP") is a fault tolerant transaction processing system that controls routing of telephone calls, within the telephone network, that require special handling, such as 800 and calling ("credit") card calls. In
particular, whenever a telephone subscriber dials such a call, the call is first routed to an equal access switch, located either at a local office or elsewhere, which has service switching point capability (such a switch will hereinafter be referred to
as an "SSP"). Primarily, the SSP processes calls that require remote data base translation. Now, whenever the SSP recognizes a call as one that requires special handling, the SSP suspends normal call processing, launches a message over a common channel
signalling ("CCS") network to an SCP to determine how the call is to be routed, and finally upon receipt of a response message from the SCP, routes the call in a manner specified by the response message.
Specifically, whenever a subscriber places a call to an 800 number, the local switch routes the call to an SSP. The SSP fabricates a query in the form of a packet. This packet contains the 800 called number and a request for a destination
routing number associated with the 800 number and, additionally, identification of a particular long distance (inter-exchange) carrier over which the call is to be routed. This packet is then routed over a common channel signalling line in a CCS network
to a particular one of several geographically separated signalling transfer points (STPs). Specifically, the CCS network typically consists of a multi-level hierarchy of STPs, wherein each STP is primarily a packet switch. The first STP to receive the
packet, i.e. the "originating" STP, then routes the packet, over an available link to an SCP for processing or, via a specified link, to another STP for eventual routing to an SCP.
The SCP itself is a fault tolerant transaction processing system that contains various databases that collectively provide desired call routing information. These databases contain a "customer record" which for 800 calls to a particular customer
specifies how each such call is to be routed. For example, this record frequently contains one or more destination routing numbers associated with a particular 800 number and specifies the manner in which one of these destination routing numbers is to
be selected, e.g. in accordance with the time of day, day of month, originating numbering plan area of the caller or other pre-defined method. Each transaction processed by an SCP for 800 service typically involves receipt of a packet followed by
generation of a corresponding response. In particular, whenever a query is received, via an incoming packet, the SCP performs associated database access operations to obtain a necessary destination routing number and an inter-exchange carrier
identification for the corresponding 800 call. The resulting information is then transmitted, as a packet, over the CCS network by the SCP, and via one or more STPs, back to an "originating" SSP which generated the corresponding query. Once a packet
containing the destination routing number and inter-exchange carrier selection is received, the originating SSP appropriately routes the 800 call to the destination routing number.
Various architectures can be used to implement an SCP. One such architecture is disclosed in detail in Boese et al United States patent application, "A REAL-TIME FAULT TOLERANT TRANSACTION PROCESSING SYSTEM" , filed Nov. 25, 1987, Serial Number
07/125,463 now abandoned and succeeded by continuation application filed Dec. 12, 1989, Ser. No. 07/453,042 both of which are currently owned by the present assignee and is disclosed to a much lesser extent in J. O. Boese et al, "Service control
point--Database for 800 Service", Conference Record of Globecon '86: IEEE Global Telecommunications Conference December 1-4, 1986 Houston, Tex. Vol. 3, December 1986, pages 1316-1319. This architecture, hereinafter referred to as the replicated front
end--back end architecture, is a network based communication system that employs: (a) a layered communication protocol that adaptively distributes packets on an approximately equal basis over multiple active physical links that connect two points (nodes)
within the network, such as, for example, an SCP and an STP, and (b) a pair of non-fault tolerant front end (FE) and back end (BE) processors that is connected within the SCP to each physical link for handling the processing of packets appearing on that
link. Each FE processor is connected to a corresponding link in a link set and is, also, connected to an associated BE processor. All the BE processors are connected through an appropriate coupling device, such as a star coupler, to a shared disk farm
in order to provide access to files stored therein. The protocol, hereinafter referred to as signalling system 7 (SS7), is the ANSI (American National Standards Institute) implementation, as recommended by the ANSI T1X1.1 working group of the signalling
system 7 standard that has been initially promulgated by CCITT. All the FE and BE processors are loosely coupled together, through various local area networks, for purposes of processor synchronization and re-assignment.
Each FE processor handles the SS7 protocol which includes framing, synchronization, error checking and correction, and other associated communication tasks. Its corresponding BE processor provides database access operations to support query
processing. One of the BE processors within the SCP executes various software procedures to co-ordinate the operation of all the FE and BE processors therein so that individual processors within the SCP and/or any application software executing on any
of the BE processors can be gracefully brought into or taken out of service.
Now, in the event any physical link in a link set or either a FE or BE processor connected thereto fails, then that link is declared to be out of service. When this occurs, the STP that is connected to that link set, through processing of the
SS7 protocol, merely re-assigns all subsequently occurring packets among all the remaining active links in the set until such time as the fault is cleared. By virtue of link re-assignment, there is no need to connect a fault tolerant processor to each
physical link. As such, a number of loosely coupled FE-BE processor pairs can be substituted within an SCP for a number of fault tolerant processors. Now, by eliminating the need to use fault tolerant processors, advantageously the replicated FE-BE
architecture substantially reduces the complexity and cost of an SCP.
The replicated FE-BE architecture provides excellent fault tolerant performance for simple "Query--Response" type transactions. Such a transaction is typified by one, as discussed above, in which a query, such as an 800 call query, is sent out
by an SSP to an SCP and a needed response, i.e. the destination routing information, is furnished through a single database access and then sent by the SCP back to the SSP. Unfortunately, not all transactions that require SCP processing are quite so
simple.
In particular, in certain enhanced network services, such as those needed to implement a private virtual network (PVN), the transactions are much more complex than simple "Query--Response" transactions. Specifically, these services often require
a caller to enter information, in addition to the called number, on an interactive basis before the SCP can fully process the call. In particular, for such a service, the caller generally dials an appropriate telephone number to gain access to the
service. Once this occurs, the SSP associated with this caller routes a request to the SCP that handles this service. The SCP performs a database access into a customer record to determine the next piece of needed information, e.g. a personal
identification number (PIN) and authorization code, that has to be obtained from the caller. Once this occurs, the SCP requests this piece of additional information by in effect questioning the caller. In particular, the SCP inserts an appropriate op
code within a transaction capability application part (TCAP) message, and then transmits this message as an SS7 packet via the CCS network back to the SSP. In response to this op code, the SSP synthesizes a pre-defined voice message to prompt the caller
to enter the desired piece of additional information. Once the caller provides an answer, it is transmitted as a TCAP message within another SS7 packet by the SSP back to the SCP that requested it. In response to the answer, the SCP then re-accesses
the customer record in order to determine the next piece of information it needs from the caller, and so on. Inasmuch as the nature of each additional piece of information often varies in response to the previous answer, the question and answer session
occurring between the caller and the SCP is carried out on an interactive basis. Each question and answer session, henceforth referred to as a conversation with each TCAP message that carries part of the conversation being referred to as a
conversational message, continues until the SCP has collected enough information from the caller via the SSP, as defined by the customer record, to fully determine how the call is to be routed. Once this occurs, the SCP sends its response containing
destination routing information back to the SSP which, in turn, routes the call accordingly. At this point the SCP has fully processed the transaction. As such, a conversation based transaction can be viewed as "Query--Conversation--. . .
--Conversation--Response".
Unfortunately, the replicated FE-BE architecture is not suited for readily processing conversational transactions. As noted, incoming packets to an SCP are distributed by the SS7 protocol on an approximately even basis among the active physical
links in a link set connected to an SCP and from there to corresponding FE-BE processor pairs located within the SCP. A typical conversational transaction typically involves a series of incoming packets to an SCP. As a result of packet distribution
occurring over a link set, individual packets that form the conversational transaction will probably be scattered among all the FE processors in the SCP that are associated with active links in that set. Consequently, if conversational transactions were
to be processed in the replicated FE-BE architecture, then the particular ("starting") BE processor that starts processing the transaction and generates the first conversational message will generally not be the BE processor that will process the answer
to that conversation or all the remaining conversational messages in the transaction. Inasmuch as the state ("context") of the transaction will be stored in a database associated with the starting BE processor, none of the other BE processors will be
able to associate a conversational message with this transaction and appropriately continue processing this transaction. Consequently, once a packet that forms this transaction reaches any BE processor other than the starting BE processor, the former BE
processor will likely discard the transaction. As such, the SCP will not provide the caller with a desired enhanced service. The same result follows if a BE processor fails and the transaction must be taken over by another BE processor.
Hence, an SCP in its present form and based on the replicated FE-BE architecture is not suited to handling conversational transactions. For that reason, such an SCP would be generally unable to provide certain enhanced network services, such as
PVN, that require an interactive conversation with a caller.
Thus, a need exists in the art for a method for handling conversational transactions in a distributed processing environment, particularly one suited for use in real time fault tolerant transaction processing system employed in an SCP. Use of
such a method will advantageously enable an SCP that utilizes a replicated FE-BE architecture to provide enhanced network services that require the collection of successive pieces of information on an interactive basis from a caller.
SUMMARY OF THE INVENTION
The inability of certain distributed processing systems to handle conversational transactions is advantageously eliminated by use of the present invention. In particular, in a distributed processing system having at least an originating node and
a responding node connected through a communication path, wherein the responding node comprises a plurality of processors and a memory device and where each of these processors is capable of accessing information from a corresponding database residing
within the memory device, the inventive method involves: storing context information for an associated conversational transaction using a first processor situated within the responding node wherein the context information is stored at a pre-defined
address in a first database residing within the memory device and associated with the first processor; producing a first message using the first processor for transmission from the responding node over the communication path to the originating node
wherein the first message contains a first transaction identifier field having a value that corresponds to the pre-defined address; generating within the originating node a second message for transmission from the originating node over the communication
path to the responding node wherein the second message contains a second transaction identifier field having substantially the same value as the first transaction identifier field; and accessing the record using a second processor located within the
responding node in response to reception of the second message at the second processor by generating the pre-defined address within the second processor using the value of the second transaction identifier field so as to permit the second processor to
incrementally process said conversational transaction within the responding node.
Specifically, use of the present inventive method advantageously provides conversational transaction processing capability to an SCP that employs a replicated FE-BE architecture and a shared file structure residing on a shared memory device, e.g.
a shared disk farm. Through this method, a "starting" back end processor that begins processing a current conversational transaction within the SCP stores context information regarding this transaction in a record located at a pre-defined address on a
particular file associated with this processor and residing on the shared memory device. Thereafter, this processor embeds this address as a value of a transaction identifier within a TCAP conversational message that will be subsequently transmitted by
the SCP back to an SSP. This conversational message contains both a transaction identifier, here a specific address value, and an op-code that instructs the SSP to provide a particular item of information defined by an appropriate customer record. By
virtue of the SS7 protocol, the SSP copies the value of the transaction identifier it received into a subsequent TCAP conversational message that it will then send back to the SCP. This conversational message also includes the item of information
requested by the SCP. Now, whenever any back end processor on the SCP receives this subsequent conversational message, regardless of whether that processor is the starting back end processor or not, that processor uses the value of the address embedded
within the transaction identifier to access the context information stored within the corresponding record from a database associated with the starting back end processor. With the accessed context information and the additional information provided by
the SCP, this back end processor can incrementally process the transaction. As a result of this incremental processing, this back end processor, as defined by the customer record, will either produce a response message to the SSP to appropriately route
a call or a conversational message containing an appropriate op-code to instruct the SSP to provide additional information for subsequent incremental processing of the current conversational transaction. In the event a conversational transaction
contains several conversations, then each back end processor in the SCP that incrementally processes the transaction will appropriately update the record to reflect the new state of the transaction prior to transmitting a conversational message to the
SSP.
Through use of the inventive method, handling of conversation transactions can be advantageously facilitated in substantially any distributed processing environment that has a shared file system, a mechanism that distributes packets (or messages)
among individual processors in the system and permits application specific identifiers to be embedded in the distributed packets (or messages).
BRIEF DESCRIPTION OF THE DRAWING
The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawing, in which:
FIG. 1 is a simplified diagram of the architecture of the telephone signalling network that utilizes signalling system 7;
FIG. 2 shows the correct alignment of the drawing sheets for FIGS. 2A and 2B;
FIGS. 2A and 2B collectively depict a block diagram of SCP 200 shown in FIG. 1;
FIG. 3 depicts a block diagram of front end processor 210.sub.1 situated within SCP 200 shown in FIGS. 2A and 2B;
FIG. 4 diagrammatically depicts message flow that would be expected to occur between an SCP and an SSP during a typical conversational transaction;
FIG. 5 diagrammatically shows an illustrative message flow that could occur within SCP 200, in the absence of using my inventive method, in processing the conversational transaction depicted in FIG. 4;
FIG. 6 shows the constituent parts of a SS7 TCAP message;
FIG. 7 shows the use of a pre-defined address placed in the transaction identifier field by SCP 200 and the relationship of this address to a specific record stored within a context file at this SCP according to the teachings of the present
invention;
FIG. 8 shows the correct alignment of the drawing sheets for FIGS. 8A and 8B;
FIGS. 8A and 8B collectively and diagrammatically show an illustrative message flow that could occur within SCP 200 whenever my inventive method is used in processing the conversational transaction depicted in FIG. 4;
FIG. 9 shows a flowchart of CREATE Routine 900;
FIG. 10 shows a flowchart of LOCATE Routine 1000;
FIG. 11 shows the correct alignment of the drawing sheets for FIGS. 11A and 11B;
FIGS. 11A and 11B collectively show a flowchart of OPEN Routine 1100;
FIG. 12 shows a flowchart of CLOSE Routine 1200;
FIG. 13 shows a flowchart of ADD Routine 1300; and
FIG. 14 shows a flowchart of GET Routine 1400.
To facilitate understanding, identical reference numerals have been used to designate identical elements, with certain exceptions noted below, that are common to the figures.
DETAILED DESCRIPTION
The teachings of the present invention can be used to impart conversational transaction processing ability to a wide variety of real-time distributed processing systems. For the sake of brevity, the present invention will be discussed in the
context of a real-time fault tolerant transaction processing system that is used in a service control point (SCP) that implements the signalling system 7 (SS7) protocol in a telephone signalling network. Such a system processes packets supplied over any
link existing within a link set in the network that connects a signalling transfer point (STP) to the SCP. Clearly, after reading the following description, those skilled in the art will readily appreciate how the teachings of the present invention can
be incorporated into other distributed processing systems to readily impart conversational transaction processing capability therein.
To clearly understand the basic operation of a telephone signalling network and the advantages conveyed by the present invention, the following discussion will first discuss salient aspects of the network and primarily center on one of the
simplest network services: 800 number calls. Next, the discussion will turn to addressing a limitation that exists in this network which effectively prevents enhanced network services, such as private virtual networks (PVN), from being readily provided. Thereafter, the discussion will conclude with a detailed explanation of the present invention and the manner by which it advantageously allows this network to easily provide these enhanced network services.
I. Common Channel Signalling Network
In particular, FIG. 1 shows a simplified diagram of an illustrative architecture of a telephone signalling network that utilizes signalling system 7 (SS7), employs transaction processing and is described in detail in Boese et al U.S. patent
application, "A REAL-TIME FAULT TOLERANT TRANSACTION PROCESSING SYSTEM", filed Nov. 25, 1987, Ser. No. 07/125,463 now abandoned and succeeded by continuation application filed Dec. 12, 1989, Ser. No. 07/453,042 both of which are currently owned by
the present assignee.
In general, this network provides special telephone call destination routing information to support a variety of special network services, such as illustratively 800 service and calling card calls. This information is obtained through remote
database translations, using caller supplied information such as a called number or a credit card number, to appropriately access one or more databases that are embedded within a telephone signalling network.
Now, assume for the moment that a caller dials a call for a network service, such as an 800 number. The caller (not shown) is generally connected to a local switch, such as local switch 12 or 14. An 800 telephone number is actually a logical
telephone number. To route such a call to its proper destination, the 800 number must be translated to an appropriate destination routing number to which the call can be subsequently routed. The specific destination routing number is specified in a
customer record stored within one or more databases residing within a service control point (SCP). This record typically contains one and often more destination routing numbers and associated inter-exchange carrier selections that are associated with a
dialed 800 number and the manner in which one of these destination routing numbers and its associated inter-exchange carrier is to be selected, e.g. time of day, day of month, originating numbering plan of the caller and the like. An SCP is an on-line
real time fault tolerant transaction processing system that provides call processing information (responses) in response to queries received via STPs connected within the signalling network. This call processing information includes call routing
instructions, and for enhanced network services, as discussed below, instructions to obtain additional information from a caller. In particular, several different database applications can be concurrently executing on an SCP. To understand the
operation of the network, the following discussion addresses one such application, 800 service.
Whenever a local switch, typified by either local switch 12 or 14, receives an 800 call, this switch routes the call onward, either through trunk 22 or through trunk 24, respectively, to an equal access switch, located either at a local office or
elsewhere, that has service switching point capability (such a switch will be collectively referred to as an "SSP"), such as SSP 30. The function of the SSP is to first recognize an incoming call as one that requires special handling--such as 800 number
calls, then suspend normal call processing for this call, thereafter obtain appropriate routing instructions through the telephone signalling network and finally route the call according to the resulting instructions. Specifically, in response to an 800
number call, SSP 30 fabricates a query in the form of a packet. This query contains the called 800 number and a request for a destination routing number associated with the dialed 800 number and a designation of a specific inter-exchange carrier, such
as inter-exchange carrier 1 or 2, that is to carry this call. This packet also contains a network address of the SSP, i.e. SSP 30, that originated the query. Once this packet is generated, it is transmitted through regional common channel signalling
(CCS) network 50 to an appropriate SCP, such as SCP 200 or SCP 290, which processes the packet and provides the desired routing information as a response message. Inasmuch as the transactions associated with 800 calls merely contain a query and a
subsequent response, they can be viewed as "Query--Response" type transactions. Other transactions which are associated with enhanced network services, such as PVN, additionally contain one or more interactive conversations between an SCP and an SSP,
and, as discussed in detail below, take the form of "Query--Conversation--. . . --Conversation--Response".
Generally speaking, the CCS network consists of a multi-level hierarchy of signalling transfer points (STPs) which primarily act as packet switches to: carry a message, in this case an SS7 packet, from an "originating" SSP to a particular
"destination" SCP; carry, when appropriate for enhanced network services, one or more conversational messages between the destination SCP and the originating SSP; and then carry a packet containing a response message (call routing instructions) from that
SCP back to the originating SSP which, in turn, routes the call according to the call routing instructions. As shown, CCS network 50 contains STPs 52, 54, 56 and 58 which are situated at different geographic locations within a given service region.
STPs 52 and 54 receive incoming packets from SSP 30 for subsequent routing through the CCS network. As a result, these STPs function as "originating" STPs. STPs 56 and 58 receive incoming packets that have been routed through CCS network 50 for
delivery to SCP 200 or 290 for appropriate processing therein. As such, STPs 56 and 58 function as "destination STPs".
In actuality, CCS network 50 typically contains more than two originating and two destination STPs, and more than two STP levels wherein one or more levels of STPs are situated between the originating and destination STPs to provide additional
packet routing therebetween. Each individual SSP, STP and SCP that exists within a signalling network is often referred to as a node.
In conjunction with this network, a multi-layered protocol is used to provide point-to-point communication between different nodes in the signalling network--such as between an SSP and an STP, between separate STPs, and between and STP and an
SCP. This protocol, hereinafter referred to as signalling system 7 (SS7), is the ANSI (American National Standards Institute) implementation, as recommended by the ANSI T1X1.1 Working Group, of the signalling system 7 standard initially promulgated by
CCITT. This protocol includes mechanisms, such as error detection and correction, to insure reliable transfer of signalling information between two points in a CCS network in the presence of transmission disturbances or a network (link or node, e.g. STP
or SCP) failure. In implementing this protocol, each pair of nodes is | | |
