U.S. patent application number 12/715166 was filed with the patent office on 2010-06-24 for methods and apparatus for interoperating communication networks.
This patent application is currently assigned to VERIZON SERVICES CORP.. Invention is credited to William D. Goodman, Douglas R. Jones.
Application Number | 20100158221 12/715166 |
Document ID | / |
Family ID | 42103244 |
Filed Date | 2010-06-24 |
United States Patent
Application |
20100158221 |
Kind Code |
A1 |
Goodman; William D. ; et
al. |
June 24, 2010 |
METHODS AND APPARATUS FOR INTEROPERATING COMMUNICATION NETWORKS
Abstract
PSTN functionality is enhanced by the addition of an external
service bridging device (ESBD) between one or more devices, e.g.,
signal switching points (SSPs), and a service control point (SCP).
The ESBD serves as a coupling device to one or more control
devices, e.g., other SCPs or IP servers, in addition to the SCP. To
support the passing of messages between the SS7 network and the
control devices, the ESBD includes message reformatting
capabilities. The ESBD monitors for messages directed to SCPs
and/or replies to messages directed to an SCP. In response to
detecting a message the ESBD checks to determine if the detected
message is to be processed or simply forwarded to the SCP. Messages
to be processed are intercepted, duplicated, modified, replaced,
broadcast, redirected, etc. Replies to broadcast query messages are
detected and processed so that a single reply, in the format of an
SCP response, is returned.
Inventors: |
Goodman; William D.;
(Collegeville, PA) ; Jones; Douglas R.; (Medford,
NJ) |
Correspondence
Address: |
VERIZON;PATENT MANAGEMENT GROUP
1320 North Court House Road, 9th Floor
ARLINGTON
VA
22201-2909
US
|
Assignee: |
VERIZON SERVICES CORP.
Arlington
VA
|
Family ID: |
42103244 |
Appl. No.: |
12/715166 |
Filed: |
March 1, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10316426 |
Dec 11, 2002 |
7702091 |
|
|
12715166 |
|
|
|
|
Current U.S.
Class: |
379/93.01 |
Current CPC
Class: |
H04M 7/126 20130101;
H04Q 3/0045 20130101; H04Q 3/0025 20130101 |
Class at
Publication: |
379/93.01 |
International
Class: |
H04M 11/00 20060101
H04M011/00 |
Claims
1. A method of providing enhanced telephone network capabilities,
the method comprising: monitoring a communications link to detect
messages of at least one of a first type and a second type, the
first type of message being a message directed to a service control
point, the second type of message being a reply to a message
directed to a service control point; in response to detecting a
message of either the first or second type: determining if a
message format conversion operation is required; and in response to
determining that a message format conversion operation is required,
performing the required format conversion operation on the detected
message.
2. The method of claim 1, further comprising: wherein determining
if a message format conversion operation is required is based on
information on the message format required by a destination to
which the message is directed.
3. The method of claim 1, wherein the step of performing the
required format conversion operation includes reformatting the
detected message from an SS7 format to an IP format.
4. The method of claim 1, wherein the step of performing the
required format conversion operation includes reformatting the
detected message from an IP format to an SS7 format.
5. The method of claim 1, further comprising, in response to
detecting a message of the second type: determining if message
processing is to be suspended for a period of time, prior to
determining if a message format conversion operation is
required.
6. The method of claim 1, wherein it is determined that message
processing is to be suspended for a period of time when the
detected message is the first detected reply to a broadcast query
message.
7. The method of claim 6, further comprising: discarding all but
one detected reply to a broadcast query message.
8. The method of claim 7, wherein a reply from a server is selected
to be retained over a reply from a service control point when
discarding all but one detected reply to a broadcast query
message.
9. The method of claim 7, wherein the step of performing the
required format conversion operation includes reformatting the
detected reply that was not discarded to appear as though it were
from a service control point.
10. A communications system comprising: a first device; an external
control device capable of controlling a telephone call processing
operation; a first service control point; a bridging device coupled
to said external control device, said first device, and said first
service control point, said bridging device including: means for
detecting at least one of a query message from said first device
directed to said first service control point and a reply to a
message directed to said first service control point; and means for
performing at least one of a message modification operation, a
message redirection operation, and a message multicast operation on
at least one detected message.
11. The communication system of claim 10, wherein said bridging
device further includes: means for reformatting said at least one
message prior to transmitting said at least one message to said
external control device.
12. The communication system of claim 11, wherein said means for
reformatting includes logic for reformatting an SS7 query message
into an IP format.
13. The communication system of claim 10, wherein said bridging
device further comprises: means for selecting one of a plurality of
reply messages received by said bridging device, in response to a
multicast query message, to be returned to said first device; means
for reformatting the selected one of a plurality of reply messages
from an IP format to an SS7 format.
14. The communication system of claim 10, wherein said bridging
device includes logic for determining if a detected message is to
be subjected to a modification operation, a redirection operation
or a multicast operation.
15. The communications system of claim 10, where said first device
is a telephone switch; where said external control device is an IP
server; and where said first service control point is a service
control point in an SS7 network and which generates and receives
SS7 compliant messages.
16. A bridging device for use in a communications system including
a first device, a control device capable of controlling a telephone
call processing operation, and a first service control point, the
bridging device comprising: a processor; an interface coupled to
said first device, said control device, and to said service control
point; and a memory including a module for controlling said
processor to: detect at least one of a query message from said
first device directed to said first service control point and a
reply to a message directed to said first service control point;
and perform at least one of a message modification operation, a
message redirection operation, and a message multicast operation on
at least one detected message.
17. The bridging device of claim 16, wherein said module further
includes instructions for controlling said processor to: reformat
said at least one message prior to transmitting said at least one
message to said external control device.
18. The bridging device of claim 17, wherein said module further
includes instructions for controlling the processor to reformat an
SS7 query message into an IP format.
19. The bridging device of claim 16, wherein said module further
includes instructions for controlling said processor to: select one
of a plurality of reply messages received by said bridging device,
in response to a multicast query message, to be returned to said
first device; and reformat the selected one of a plurality of reply
messages from an IP format to an SS7 format.
20. The bridging device of claim 16, wherein said module further
includes: instructions for controlling the processor to determine
if a detected message is to be subjected to a modification
operation, a redirection operation or a multicast operation.
Description
RELATED APPLICATIONS
[0001] The present application is a continuation of U.S. patent
application Ser. No. 10/316,426, filed on Dec. 11, 2002 and
entitled "METHODS AND APPARATUS FOR INTEROPERATING COMMUNICATION
NETWORKS" and which is hereby expressly incorporated by reference
in its entirety.
FIELD OF THE INVENTION
[0002] The present invention is directed to communication networks,
and more particularly, to methods and apparatus for adding
functionality and/or network interoperability features to a
communications network such as, e.g., the public switched telephone
network (PSTN).
BACKGROUND OF THE INVENTION
[0003] When networks for communications are created, they are
usually designed for use with existing standards and protocols in
mind. Significant investment may have been made to deploy an
existing network. Accordingly, it is often commercially impractical
to replace an entire network or large portions of an existing
network that remains operational. The existing telephone network,
also known as the PSTN, is an example of an existing functional
network that remains functional, is large, and represents a huge
investment in equipment. Unfortunately, in many situations desired
enhancements to existing networks, e.g., the PSTN, such as some
multicast services or web based services utilize resources that are
beyond the capabilities of the network as it was originally
designed. It would be desirable if a way could be found to add new
functionality to the PSTN without requiring major modifications to
the existing network and/or previously deployed equipment.
[0004] As new generations of service control technologies are
becoming available, resulting in non-SS7 (non-Signaling System 7)
based networks, many based on computer industry and Internet
standards, interoperation and integration with established SS7
networks such as the PSTN is a significant problem which needs to
be addressed.
[0005] Two commonly discussed methods of accessing these next
generation control platforms from within the PSTN include 1)
enhancements to PSTN control platforms, e.g., upgrades to service
control points (SCPs), and 2) gateways to new SS7 domains, e.g., IP
feature server behind a gateway that acts as an SS7 Service
Switching Point (SSP). Each of these methods require significant
new investment in the PSTN such as upgrading SCP systems, along
with ongoing administrative costs such as provisioning new point
codes and updating routing tables. Both methods are also limited in
their utility, as they will normally be limited to acting on
requests that are specifically made to an external control
platform. Given the shortcomings of the above techniques, there is
a need for additional network integration approaches that can
provide greater flexibility and thereby allow for new services or
better execution of existing services in addition to supporting
interoperation of different networks.
[0006] In addition to a need to support network interoperability,
there is a need for improved methods of supporting SCP load
balancing to reduce the need to replace or upgrade existing SCPs as
new services and/or more customers subscribe to advanced services
in a given service region. Existing telephone services can be
negatively affected when an SCP that provides advanced telephone
services is used to capacity. Without load sharing, overloading of
an SCP may occur while other SCPs that can provide the same
services are under utilized, e.g., because of differences in
regional customer demographics. There is a desire to alleviate this
type of network congestion to provide better service to customers
and to optimize the use of already deployed hardware.
[0007] From the above discussion it is apparent that there is a
need to link the existing legacy (PSTN/SS7 network) with new
external control platforms, e.g., IP based systems, existing in
non-SS7 domains, to allow new services and/or enhanced services to
be provided to PSTN users. The links to the new control platforms
should, preferably, be performed in a manner that allows such
external control platforms to interact with PSTN elements in a
relatively transparent manner that does not require major
modifications to existing PSTN elements. If this can be achieved,
large additional investments in PSTN/SS7 upgrades and/or
administration costs can be reduced or avoided while still allowing
for new or enhanced services.
[0008] In view of the above discussion, it is apparent that there
is a need for new methods of supporting PSTN system
interoperability with non-SS7 based systems or networks, a need for
a method of providing new services without requiring significant
changes to already deployed SCPs and SSPs, and for improving SCP
load balancing.
SUMMARY OF THE INVENTION
[0009] The present invention is directed to methods and apparatus
for adding functionality and/or network interoperability features
to a communications network such as, e.g., the public switched
telephone network (PSTN). In accordance with the present invention,
an external service bridging device (ESBD) is inserted to into a
communications network on a link to monitor for messages sent to a
service control point and/or replies to query messages sent to a
service control point. The monitored communications link may be an
SS7 link positioned between one or more signal switching points
(SSPs) and a service control point (SCP).
[0010] The ESBD may be inserted in a conventional SS7 network at a
point, e.g., link, used to couple conventional SSPs to a
conventional SCP. Thus, the ESBD of the present invention may be
used in the existing PSTN without requiring hardware modifications
to already deployed SSPs and SCPs. The ESBD is coupled to one or
more control devices in addition to the SCP. The control devices
may be additional SCPs, intelligent peripheral devices (IPs), or
Internet Protocol (IP) servers which provide advanced functionality
and/or, in some cases, services not available from a conventional
SCP. To support the passing of messages between the SS7 network and
the additional control devices, the ESBD includes the capability to
reformat messages to/from various formats such as IP packets and an
SS7 format, e.g., TCAP message format. Reformatting of messages may
involve, e.g., reordering message fields and/or the data included
in a field. The ESBD may also perform protocol conversion
operations. While reformatting may be part of a protocol conversion
operation, protocol conversion may involve the introduction of
entirely new fields as opposed to simply reformatting/reordering of
existing fields.
[0011] The ESBD may be implemented as a pass through device with
the ability to detect and intercept query messages from a SSP and
reply messages directed to a SSP. In some embodiments, only the
return links are implemented as pass-through devices with the ESBD
being coupled, in parallel, to the link from the SSP to the SCP. In
such a case, reply messages may be intercepted while query messages
will proceed to the SCP whether or not they trigger an additional
processing action by the ESBD.
[0012] The ESBD of the present invention monitors for messages
directed to SCPs, e.g., TCAP messages which represent queries for
call processing instructions.
[0013] Detected messages directed to an SCP or which are in
response to a message directed to an SCP are intercepted,
duplicated, modified, replaced, broadcast, redirected and/or
otherwise processed as desired or necessary, e.g., to support
interoperability with, and services provided by one or more control
devices other than the SCP to which the message is directed or the
message which initiated the detected reply message was
directed.
[0014] In the case of redirecting a message, the original query
message may be directed to an SCP other than the normal SCP. This
may be done for load balancing or other purposes. Alternatively,
the detected message may be reformatted and sent to an advanced
control device such as an IP based server. When a redirect
operation is implemented by the ESBD of the invention, the original
message will not be sent to the SCP to which the query message was
originally directed. The reply from the device to which the message
is redirected will be detected by the ESBD and reformatted as
necessary to make it appear as if from the SCP to which the message
was originally directed. The reply message is then sent to the
device from which the original query message originated which then
responds as if the message was from the SCP to which it was
originally directed. Thus, loading of the existing SCP can be
reduced and/or new functionality can be added without having to
make hardware modifications to the existing SCP and/or SSP.
[0015] Multicasting is another option which is supported by the
ESBD of the present invention. In the case of multicasting, a
detected query message may trigger the ESBD to transmit query
messages to multiple control devices. The original detected TCAP
message may also be sent to the SCP to which it was originally
directed. The ESBD monitors for replies to the multicast query
message and selects one reply to be returned to the SCP. In various
embodiments, the reply from the SCP to which the query message was
originally directed is used as the default selection when replies
are not received from one or more advanced control devices. Since a
single reply, in the proper format, is returned to the requesting
device, the SSP and SCP are shielded from the complexity associated
with a multicast operation and act in a conventional manner in
generating and responding to TCAP messages. Defaulting to the reply
from the conventional SCP is useful in cases where the advanced
control devices, e.g., IP servers, only control call processing
when the user is logged into one of the IP servers.
[0016] In addition to performing redirection and multicasting the
ESBD of the present invention can be used to modify query messages
prior to the messages being forwarded to the SCP or modify replies
received from an SCP without changing the recipient. Such
modification of messages is useful where a different individual
with different MN services may be temporarily using another
individual's telephone but would like to receive one or more of the
features to which the different individual subscribes.
[0017] The ESBD of the present invention allows for monitoring of
any or all SS7 messages on an SS7 link to provide added
functionality that may not be possible with other proposed
techniques for interoperating two control platforms. This allows
the ESBD to provide service enhancements to already established
telephone service. Such enhancements include, e.g., redirecting
traffic at heavily used network elements or acting as a proxy for
some telephone services. Since the ESBD operates in a manner that
is relatively or completely transparent to existing PSTN elements,
the ESBD provides a convenient way to upgrade and/or add additional
features to the existing PSTN without requiring major changes to
already deployed SS7 equipment.
[0018] Numerous additional features, benefits and details of the
methods and apparatus of the present invention are described in the
detailed description which follows.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] FIG. 1 illustrates a communications system implemented in
accordance with the present invention.
[0020] FIG. 2 illustrates an exemplary external service bridging
device (ESBD) implemented in accordance with the present
invention.
[0021] FIG. 3 is a flow chart illustrating the steps of an
exemplary method of the present invention which may be implemented
by the ESBD of FIG. 2.
DETAILED DESCRIPTION
[0022] FIG. 1 illustrates a communications system 100 implemented
in accordance with the present invention. The system 100 includes a
public switched telephone network (PSTN) 102, a customer premise
114, various other external service networks 104, 104', 104'' and
some exemplary external control devices such as servers 108, 110,
112 and an SCP, e.g., a competitive local exchange carrier (CLEC)
SCP 106. Sever 108 is a Web based services server which provides
Internet services, server 110 is a customer feature server 110
which provides various features to subscribes, while server 112 is
a PSTN feature server which is designed to provide enhanced PSTN
serves to customers, some of which may involve the use of IP
connections and/or information received via an IP based network.
These devices 106, 108, 110, 112 are coupled to the PSTN 102 via
their corresponding external service networks 104, 104', 104'' and
serve as external control platforms that provide services, e.g.,
enhanced services, to the users of the PSTN 102. The provided
services can be services which are not offered in the PSTN/SS7
environment or services which are offered but that are being
provided by a provider other than the user's local telephone
company. In some cases the SCP 106 coupled to the PSTN may be
operated by the local telephone company which provides use of the
SCP 106 to a competitor for a charge while also using the SCP 106,
in accordance with the invention, for load balancing purposes. Some
of the servers, e.g., web based services server 108, use a
different protocol from SS7, i.e., TCP/IP (Transmission Control
Protocol/Internet Protocol), to communicate data. Therefore,
different addressing and routing schemes are used, and a packet of
data formatted for the PSTN's SS7 network cannot be delivered
directly on such a non-SS7 network without reformatting and/or
other processing.
[0023] PSTN 102 includes one or more signal switching points (SSPs)
126, a Service Control Point (SCP) 118, Signal Transfer Points
(STPs) 122, 124, and an External Service Bridging Device (ESBD) 120
which are coupled together using SS7 links. In accordance with the
present invention, the ESBD 120 is positioned so that it can
monitor and/or intercept communications between STPs 122, 124 and
the SCP 118. As will be discussed below, this allows the ESBD 120
to support network interoperability, provision of enhanced
services, and SCP load balancing in a manner that can be relatively
transparent to the STPs 122, 124, the ssP 126 and the SCP 118. STPs
122, 124, SCP 118 and SSP 126 may be implemented as conventional
PSTN components. In fact, they may correspond to previously
deployed PSTN components. The SSP 126, as is known in the art, may
be implemented using known Class 4 and/or Class 5
telecommunications switches, e.g., telephone switches, capable of
supporting the SS7 protocol. For purposes of simplification only
one SSP 126 is shown in FIG. 1. Trunk lines, which may comprise,
e.g., one or more T1 lines, interconnect the various SSPs included
in the PSTN 102.
[0024] The system 100 is implemented using advanced intelligent
network (MN) techniques. Accordingly, the processing of calls
directed to a customer's telephone line and/or received by a SSP
from a telephone customer's line may encounter MN triggers set at a
SSP. In response to the MN trigger, call processing is controlled
by instructions included in customer call processing records (CPRs)
stored in the SCP 118. The instructions implement the services or
part of the services to which the customer subscribes. In
accordance with the present invention, services can also be
provided by any of the devices 106, 108, 110, 112 coupled to the
SCP 126 in response to activation of an MN trigger.
[0025] In system 100, CPRs are stored at a Services Control Point
(SCP) 118. Additional CPRs may be stored in CLEC 106. Updates to
customer service information and setting triggers at SSP 126 maybe
controlled by various components of the SCP 118. The SSP 126 is
coupled to the SCP 118, via one or more signal transfer points
(STPs) 122, 124. The STPs 122, 124 use Signaling System Seven (SS7)
links, e.g., interconnects, to transmit messages, data, and
requests for call processing control instructions in accordance
with the SS7 protocol and to receive call processing information,
e.g., relies including call handling instructions, from the SCP
118. An example of a transmitted message includes a Transaction
Capabilities Application Part (TCAP) query, which is transmitted by
the SSP 126 in response to an internal MN trigger being hit, e.g.,
a trigger event being satisfied by an incoming or outgoing
call.
[0026] In addition to storing CPRs, the SCP 118 normally includes a
list of the services to which the customers serviced by the SCP
subscribe. The exemplary SCP 118 supports several telephone
services, e.g., a call forwarding service and a call screening
service. New generations of telephone services and/or other
advanced communications services may utilize functions that are
beyond the scope of SCPs as currently implemented in the existing
PSTN. To support such services the system 100 includes the ESBD 120
in accordance with the present invention. The ESBD 120 is used to
transparently support external control platforms without requiring
hardware modifications to existing SCPs, STPs, and/or SSPs. The
ESBD 120 is placed between the STPs 122, 124 and the SCP 118 so
that SS7 signals, e.g., TCAP messages and SCP replies, going to and
from the SCP 118, can be monitored, intercepted, duplicated,
modified, replaced, broadcast, redirected and/or otherwise
processed as desired or necessary, e.g., to support
interoperability with, and services provided by, external devices
106, 108, 110, 112.
[0027] Customer premise (CP) 114, which may be, e.g., a residence
and/or office, is coupled to the PSTN 102 via SSP 126. Connections
between the SSP 126 and CP 114 may be by POTS lines, ISDN lines,
DSL, or other known communications lines. The CP 114 includes a
communications device 116, e.g., a telephone, which is used by a
customer to obtain communications services via the PSTN 102. The
obtained services may be, e.g., conventional telephone services or
various next generation services that are supported through the use
of the ESBD 120 of the present invention. While CP 114 is
illustrated as including only a landline phone, it is to be
understood that it may have any number of communications devices
including, e.g., telephones, faxes, and/or computer devices. In
addition, it is to be understood that normally multiple customer
premises are coupled to the SSP 126 at any given time and that
calls from multiple SSPs 126 will normally be serviced by the SCP
118 at any given time.
[0028] FIG. 2 illustrates an exemplary ESBD 120, implemented in
accordance with the present invention. The external service
bridging device 120 includes a processor 204, an I/O interface 206
and a memory 202, coupled together by a bus 203. The processor 202
is used to execute the instructions included in module 208 thereby
control signal processing in accordance with the invention may be
implemented, e.g., using a general purpose CPU. The I/O interface
206 may be implemented using one or more line cards, e.g., with
each line card supporting a particular communications protocol
and/or line interface.
[0029] The memory 206 includes a communication network bridging
module 208, and stored information that may be used to implement
the steps of the present invention. The communication network
bridging module 208 may be implemented as a set of software
instructions used to control processing of signals, e.g., SS7
messages, and/or signals from one or more external devices received
by the ESB 120. When executed by the processor 204, the
communications network bridging module 208 can cause signals
received by I/O interface 206 to be monitored, intercepted,
duplicated, replaced, broadcast, redirected and/or otherwise
processed as necessary or desired. Processing may involve
reformatting and/or generating new messages or signals in a format
that differs from the original format in which as signal is
received. This is particularly useful for supporting passage of
messages and/or other information between the PSTN's SS7 network
and the additional networks 104, 104' 104'' used to coupled the
ESBD 120 to the devices 106, 108, 110, 112.
[0030] The stored information included in memory 102 includes an
actionable TCP message information database 209, information about
outstanding actionable TCAP messages 210 which were detected, TCAP
messages 212 which were detected and temporarily stored during
processing, and reply messages 214 which are stored prior to
processing and/or transmission to the SSP 126. Actionable TCP
message information database 209 may be implemented as a look-up
table listing a TCP message identifiers, e.g., user IDs such as
telephone numbers, which can be used to identify actionable TCP
messages and also listing the action to be taken for each
actionable TCP messages. Different actions may be associated in the
database 209 with different TCP message identifiers.
[0031] FIG. 3 illustrates the steps of an exemplary method 300 for
monitoring and processing signals, e.g., TCAP messages, in
accordance with the present invention. The method 300 is
implemented by the ESBD 120 operating under control of
communication network bridging module 208. The method 300 starts in
step 302, e.g., with the system components being powered up.
Operation proceeds from step 302 to initialization step 304 wherein
the ESBD 120 is initialized to provide services to subscribers in
accordance with the invention. The initialization process includes,
e.g., logging in with external servers to determine their
availability and for receiving updates to the contents of the
actionable TCAP message information database 209 maintained by the
ESBD 120. As part of the update process information on how to
process specific TCAP messages and TCP message identifiers, e.g.,
specific user Ids, telephone number, or portions of telephone
numbers used to identify actionable TCAP messages may be stored in
the database 209.
[0032] As mentioned earlier, the system 100 is implemented using
advanced intelligent network (AIN) techniques. Accordingly, as part
of initializing the system 100 customer CPRs are generated and AIN
triggers, e.g., Originating and/or Termination Attempt Triggers,
are set at the SSP 126.
[0033] SSP 126 is operated to receive calls on an ongoing basis. As
each call is received, the SSP 126 checks to determine if an
incoming call activates an AIN trigger. If no trigger is set on the
line, e.g., because the called party or the calling party does not
subscribe to an AIN or enhanced telephone service, the call is
allowed to complete in a normal manner.
[0034] However, if it is determined that an AIN trigger is set on
the line, call processing is halted at the SSP 126 and a query,
e.g., a TCAP message, is sent to the SCP 118 for call processing
instructions.
[0035] In the exemplary communication system 100 of FIG. 1, the
ESBD 120 is positioned so that it can monitor and/or intercept
transmissions to and/or from the SCP 118. In addition to SCP 118,
an external server or other device 106, 108, 110, 112 may be used
to provide enhanced telephone services. In cases where an external
device is used, ESBD 120 is used to support interoperability
between the external service server and the PSTN. In cases where
the external device used to provide the service a SCP, e.g., CLEC
SCP 106, this may involve copying and/or redirecting a received
TCAP message. In other cases it may involve duplicating,
reformatting, and/or broadcasting a received TCAP message.
[0036] Following initialization, operation proceeds to step 306
wherein the ESBD 120 monitors for messages between the SCP 118 and
another device, e.g., SSP 126. The messages may be directed to, or
may be from, the SCP 118. The ESBD 120 also monitors for message
that are in response to a message originally directed an SCP
118.
[0037] Monitoring for messages, e.g., TCAP messages and/or reply
messages from one or more servers, occurs on an ongoing basis in
step 306. However, in response to detecting a monitored message,
processing of the detected message proceeds to step 308. In
decision step 308, the ESBD 120 determines if processing associated
with a detected message should be suspended. Request for call
processing instructions directed to an SCP are normally not delayed
with processing proceeding directly from step 308 to step 312.
However, processing of reply messages may be suspended temporarily,
e.g. to provide time for multiple replies to be received.
[0038] In one embodiment, determining if message processing should
be suspended involves determining if the detected message is a
reply to a broadcast message sent to multiple devices, e.g., SCP
118 and one or more feature servers 110, 112. Suspending of message
processing for a brief period of time after the first reply to a
broadcast message is received allows time for other replies
corresponding to the same broadcast request message to be received
before deciding which reply to forward, e.g., to SSP 126 in
response to a TCAP request message seeking call processing
instructions. If in step 308 it is determined that message
processing is to be suspended, e.g., because the detected message
is a reply to a broadcast request message, operation proceeds to
step 310 wherein a period of time is allowed to pass before
processing of the message is resumed. During this period of time,
other reply messages corresponding the same request message may be
received. In one embodiment, the time period for suspending
processing messages corresponding to a broadcast request message
begins running from the time the first reply message is detected.
Accordingly, processing of replies corresponding to the same
request message may vary with the processing of the reply messages
corresponding to the same request resuming at the same time.
[0039] Operation proceeds from step 310 to step 312. In step 312 a
determination is as to whether one or more messages to be processed
should be discarded and which particular messages are to be
discarded. In the case of a reply to a broadcast request message
this will normally involve selecting all but one reply received in
response to a broadcast request message to be discarded. This will
normally result in the reply from SCP 118 being discarded in favor
of a reply from one of the servers 108, 110, 112 or CLEC SCP 106
being retained for further processing. The ESBD may include a set
of rules used for selecting which one of a plurality of replies
should be retained and which ones should be discarded. In the case
of messages directed to an SCP 118, such messages normally will not
be discarded and will pass through steps 308, 312 without
unnecessary delay.
[0040] Processing of messages to be discarded proceeds from step
312 to step 314 wherein the messages to be discarded are discarded.
Processing with regard to the individual messages to be discarded
proceeds from step 314 to step 316 wherein processing associated
with the individual messages stops.
[0041] Processing of messages which are not selected to be
discarded, proceeds from step 312 to step 318. These messages will
normally include, e.g., messages directed to an SCP requesting call
processing instructions and an individual reply message received in
response to an earlier request message. In step 318, the ESBD 120
determines the destination or destinations to which the detected
message is to be transmitted. In step 318, it may be determined
that a message being processed is to be broadcast to multiple
destinations. An external server, Intelligent peripheral device or
other external device may be consulted for information when making
such a decision. For example, a decision on whether or not to
forward a detected request message may, in part, be based on
information obtained from the customer feature server indicating
whether a particular service subscriber has a call processing
service provided the by the server 110 activated at a particular
point in time. Rather than contact an external device, it is also
possible for the ESBD 120 to rely on internal information and/or
rules to make a message destination decision. For example, the ESBD
120 may be programmed to route request messages corresponding to
particular telephone number to CLEC SCP 106 instead of SCP 118. The
ESBD 120 may decide that, in some cases, a received message is to
be broadcast to multiple destinations. This feature is particularly
useful when a feature server 110, 112 is to provide call processing
instructions at some points in time while the SCP 118 serves as the
default source of call processing instructions in the event that
one of the feature servers 110, 112 does not proved the requested
call processing information.
[0042] For each message destination identified in step 318, message
processing proceeds to step 310. In the case of broadcast messages,
this results in step 310 being traversed for each of multiple
message destinations. In step 310 a determination is made as to
whether message destination information included in the detected
message needs to be modified. This determination is made, e.g., on
a difference between the determined destination of step 318 and the
original destination of the message as indicated, e.g., in a
message header field.
[0043] Modification of message destination information will be
required when the message is being directed to a destination other
than its original destination. In the case of redirected messages
or messages which are part of a broadcast operation which are
directed to a destination other than the original destination, the
destination identification information will be changed to reflect
the new destination, in step 310 it is determined that the
destination identification information needs to be modified and
operation proceeds to step 312. In step 312, the destination
identification information in the message being processed is
modified, e.g., to reflect the new destination, and then message
processing proceeds from step 314.
[0044] In cases where a message destination matches the original
intended destination, the destination identifier included in the
message being processed need not be modified and operation will
proceed directly from step 310 to step 314.
[0045] If in step 314, a determination is made as to whether the
message content, which may include one or more header fields, needs
to be modified. This determination may be based on information
included in the ESBD 120 about processing to be performed for
messages corresponding to particular customers and/or services,
e.g., as indicated by one or more message header fields. For
example, for some enhanced services the message content may be
modified so that the message appears to correspond to a different
service subscriber.
[0046] If in step 314 it is determined that the message content is
to be modified, operation proceeds to step 316 wherein a message
content modification operation is performed. Operation proceeds
from step 316 to step 318. Operation proceeds from step 314
directly to step 314, when it is determined that the message
content need not be modified.
[0047] In step 318 a determination is made as to whether protocol
and/or format conversion is required for the message to be
transmitted to the intended destination. In one exemplary
embodiment, the ESBD 120 stores information indicating the protocol
and/or format requirements associated with each of a variety of
possible destinations. Using the indicated message destination, the
protocol and/or format requirement information is accessed and
compared to the current format and/or protocol associated with the
message being processed. If the format and/or protocol required by
the destination differs from that of the message, protocol and/or
format conversion is required and operation will proceeds from step
318 to step 320.
[0048] In cases where the message was originally directed to the
SCP 118 and has been redirected or broadcast to a server or other
IP based device, both protocol and/or format conversion will
normally be required. In cases of simply redirecting a message to
another device of the same type, e.g., CLEC SCP 106 instead of SCP
118, over the same type of network, protocol and/or format
conversion are normally not necessary. Reply messages from a server
110, 112 transmitted over an IP network to an SSP 126 will normally
require both format and protocol conversion.
[0049] In step 320 the message is formatted to comply with the
protocol and/or format requirements associated with the message's
destination. Operation then proceeds to step 322. If in step 318 it
is determined that protocol and/or format conversion is not
required, operation proceeds directly to step 322.
[0050] In step 322, the processed message is transmitted to its
intended destination. From step 322 operation proceeds to step 316
wherein processing associated with the individual message, e.g.,
the message transmitted in step 322, stops.
[0051] In accordance with the method illustrated in FIG. 3,
messages on a SS7 communications link, e.g., query messages for
call processing instructions directed to an SCP, can be detected
and processed. Processing may allow the message to pass to its
original destination unaltered, to redirect the detected message to
another destination, to broadcast the message to various servers
and/OR SCPs as an alternative to transmitting the message to an SCP
to which it was originally directed or, to broadcast the message to
one or more devices in addition to transmitting the message to an
SCP to which it was originally directed. In the case of detected
messages which are replies to a query message originally directed
to an SCP, message processing may be suspended temporarily to
provide time to receive any additional replies that may correspond
to a query message that was broadcast. Normally, in the case where
multiple reply messages are received only one will be forwarded to
the ultimate destination, e.g., the telephone switch 126 to which
the replies are directed. Assuming a reply from a server and not an
SCP is selected to be forwarded to the SSP 126 it will normally be
reformatted to appear as if it came from the SCP 118 to which the
original query for call processing instructions was sent. Since the
reply message appears to the SSP 126 as though it were from the SCP
118 as expected, the method of the present invention provides a
convenient and relatively transparent manner by which devices other
than a conventional SCP, or an alternative SCP, can be used to
control call routing functions and the provision of telephone
services. Significantly, this can be done without requiring
hardware modifications to existing SCPs 118 or switches in the PSTN
102.
[0052] Using the above described methods and apparatus, services
that run on or require the use of external servers, which may use
different communication protocols than the SS7 protocol used by the
PSTN 102, can be integrated with the PSTN. In addition, the methods
and apparatus of the present invention can add functionality to the
existing PSTN without requiring modifications to existing SSPs 126
or SCPs 118.
[0053] The steps of the various methods of the invention discussed
above may be implemented in a variety of ways, e.g., using
software, hardware or a combination of software and hardware to
perform each individual step or combination of steps discussed.
Various embodiments of the present invention include means for
performing the steps of the various methods. Each means may be
implemented using software, hardware, e.g., circuits, or a
combination of software and hardware. When software is used, the
means for performing a step may also include circuitry such as a
processor for executing the software. Accordingly, the present
invention is directed to, among other things, computer executable
instructions such as software for controlling a machine or circuit
to perform one or more of the steps or signal processing operations
discussed above.
[0054] Although the above descriptions relate primarily to SS7 TCAP
messages, which are used for service control, the present invention
can also be applied to the call routing portion of an SS7 network,
i.e., SS7 ISUP messages that route between end offices. Query
messages in the context of the present application are to be
interpreted broadly as information, messages or other signals to
which a response including call processing instructions or other
call handling information is expected in reply.
[0055] It is to be understood that numerous variations on the above
described methods and apparatus are possible without departing from
the scope of the invention and that a wide range of applications
are possible. For example, the present invention can be used to
offload Global Title Translation (GTT) functionality from STPs.
This reduces the requirement for multiple Translation Types (a
limited resource) needed in the SS7 to accommodate alternative
Service Control platforms, e.g., for CLEC SCP access, Customer
Feature Server.
[0056] Other services include routing AIN/TCAP queries to non-SS7
SCP's; receiving service requests from external entities, e.g.,
with IP feature servers, a TCAP query is formulated and sent to an
SCP, and the reply is intercepted, formatted and sent to the
originating feature server; implementing Web services protocols,
e.g. SOAP, XML, to make service logic on the Internet available to
PSTN services, or service logic within the PSTN/SS7 network
available to external services; incorporating SIP proxy function;
incorporating signaling gateway function, e.g., to/from IP network;
and incorporating SS7 firewall and gateway screening functions.
[0057] The above examples and embodiments are exemplary. Numerous
variations on the above described methods and apparatus are
possible while still remaining within the scope of the present
invention.
* * * * *