System for managing telecommunications Number:7,394,894 from the United States Patent and Trademark Office (PTO) owispatent

Title: System for managing telecommunications

Abstract: A signaling processor receives a first signaling message indicating a called telephone number for the call. The signaling processor processes the called telephone number from the first signaling message to determine if call validation is required. If the call validation is not required, then the signaling processor processes the called telephone number to determine routing information without the call validation. If the call validation is required, then the signaling processor determines if the call is valid, and if the call is valid, then the signaling processor processes the called telephone number to determine the routing information. The signaling processor transfers a second signaling message indicating the routing information for the call.

Patent Number: 7,394,894 Issued on 07/01/2008 to Christie,   et al.

---

Inventors:	Christie; Joseph Michael (San Bruno, CA), Bahl; Manu Chand (Hillsborough, CA), Duree; Albert Daniel (Independence, MO), Gardner; Michael Joseph (Overland Park, KS), Sbisa; Daniel Charles (Blue Springs, MO), Wiley; William Lyle (Olathe, KS)
Assignee:	Sprint Communications Company L.P. (Overland Park, KS)
Appl. No.:	11/434,843
Filed:	May 16, 2006

---

Related U.S. Patent Documents

---

	Application Number	Filing Date	Patent Number	Issue Date
	09276042	Mar., 1999	7085362
	08525050	Jan., 2001	6181703
	08238605	May., 1994

---

Current U.S. Class:	379/188 ; 379/207.02
Current International Class:	H04M 3/00 (20060101); H04M 3/42 (20060101)
Field of Search:	379/186,188,196,200,207.02,219,220.01,201.01,207.07,91.01-91.03,93.02,93.03,111,112.01,127.01,127.02,127.06,114.24,133-134,145

---

References Cited [Referenced By]

---

U.S. Patent Documents

4491945	January 1985	Turner
4683584	July 1987	Chang et al.
4686669	August 1987	Chang
4686701	August 1987	Ahmad et al.
4991172	February 1991	Cidon et al.
5029199	July 1991	Jones et al.
5084816	January 1992	Boese et al.
5115426	May 1992	Spanke
5274698	December 1993	Jang
5297147	March 1994	Shimokasa
5339318	August 1994	Tanaka et al.
5394463	February 1995	Fischell et al.
5438570	August 1995	Karras et al.
5440563	August 1995	Isidoro et al.
5473679	December 1995	La Porta et al.
5485455	January 1996	Dobbins et al.
5506894	April 1996	Billings et al.
5519770	May 1996	Stein
5533115	July 1996	Hollenbach et al.
5544163	August 1996	Madonna
5563933	October 1996	August et al.
5568475	October 1996	Doshi et al.
5666399	September 1997	Bales et al.
5701301	December 1997	Weisser, Jr.
5703880	December 1997	Miura
5828666	October 1998	Focsancanu et al.
5862334	January 1999	Schwartz et al.
5872779	February 1999	Vaudreuil
RE36416	November 1999	Szlam et al.
6038218	March 2000	Otsuka et al.
6327270	December 2001	Christie et al.
6847611	January 2005	Chase et al.

Foreign Patent Documents

	0 488 399		Jun., 1992		EP

Other References

Manu Bahl, et al.; "The Evolving Intelligent Interexchange Network--An SS7 Perspective," Proceedings of the IEEE; Apr. 1992; pp. 637-643; vol. 80, No. 4. cited by other . IBM International Technical Support Organization; "Networking BroadBand Services (NBBS) Architecture Tutorial;" Jun. 1995; 248 pages; First Edition; Research Triangle Park, North Carolina, USA. cited by other.

Primary Examiner: Deane, Jr.; William J.

---

Parent Case Text

---

CROSS-REFERENCES TO RELATED APPLICATIONS

This patent application is a continuation of U.S. patent application Ser. No. 09/276,042; filed on Mar. 25, 1999 now U.S. Pat. No. 7,085,362; entitled "SYSTEM FOR MANAGING TELECOMMUNICATIONS;" which is a continuation of Ser. No. 08/525,050 filed Sep. 8, 1995 U.S. Pat. No. 6,181,703; issued on Jan. 30, 2001; entitled "SYSTEM FOR MANAGING TELECOMMUNICATIONS;" which is a continuation-in-part of prior U.S. patent application Ser. No. 08/238,605; filed on May 5, 1994 now abandoned; entitled "METHOD, SYSTEM AND APPARATUS FOR TELECOMMUNICATIONS CONTROL" and hereby incorporated by reference into this patent application.

---

Claims

---

What is claimed is:

1. A signaling processor to process signaling for a call from a caller: a signaling interface configured to receive a first signaling message indicating a called telephone number for the call; a call manager configured to process the called telephone number from the first signaling message to determine if call validation is required, and if the call validation is not required, then to process the called telephone number to determine routing information without the call validation, but if the call validation is required, then to determine if the call is valid, and if the call is valid, then to process the called telephone number to determine the routing information; and the signaling interface further configured to transfer a second signaling message indicating the routing in formation for the call.

2. The signaling processor of claim 1 wherein the call manager is configured to validate the call by checking a caller number for the call.

3. The signaling processor of claim 1 wherein The call manager is configured to validate the call by determining if a billing problem exists for the caller.

4. The signaling processor of claim 1 wherein the first signaling message comprises a signaling system seven message.

5. The signaling processor of claim 1 wherein the signaling interface is configured to transfer the second signaling message over an internet protocol link.

6. The signaling processor of claim 1 wherein the first signaling message comprises a signaling system seven message and wherein the signaling interface is configured to transfer the second signaling message over an internet protocol link.

7. The signaling processor of claim 1 wherein a first network element transfers the first signaling message and a second network element receives the second signaling message and wherein the signaling interface and the call manager are external to the first network element and the second network element.

8. The signaling processor of claim 1 wherein the route information indicates a connection.

9. The signaling processor of claim 1 wherein the route information indicates a wireless connection.

10. The signaling processor of claim 1 wherein the route information indicates a virtual connection.

11. A method of operating a signaling processor to process signaling for a call from a caller: receiving a first signaling message indicating a called telephone number for the call; processing the called telephone number from the first signaling message to determine if call validation is required; if the call validation is not required, then processing the called telephone number to determine routing information without the call validation; if the call validation is required, then determining if the call is valid, and if the call is valid, then processing the called telephone number to determine the routing information; and transferring a second signaling message indicating the routing information for the call.

12. The method of claim 11 wherein validating the call comprises checking a caller number for the call.

13. The method of claim 11 wherein validating the call comprises determining if a billing problem exists for the caller.

14. The method of claim 11 wherein the first signaling message comprises a signaling system seven message.

15. The method of claim 11 wherein transferring the second signaling message comprises transferring the second signaling message over an internet protocol link.

16. The method of claim 11 wherein the first signaling message comprises a signaling system seven message and wherein transferring the second signaling message comprises transferring the second signaling message over an internet protocol link.

17. The method of claim 11 wherein a first network element transfers the first signaling message and a second network element receives the second signaling message and wherein the signaling processor is external to the first network element and the second network element.

18. The method of claim 11 wherein the route information indicates a connection.

19. The method of claim 11 wherein the route information indicates a wireless connection.

20. The method of claim 11 wherein the route information indicates a virtual connection.

---

Description

---

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to telecommunications and specifically to a system that manages telecommunications by processing signaling to generate new signaling for the network elements that provide the telecommunications services.

2. Prior Art

Telecommunications networks use switches to process calls and set-up connections. The switches need to communicate with one another in order to accomplish this function. These communications between switches are known as signaling. A prominent example of signaling is Signaling System #7 (SS7). It is important to point out that signaling is different than the actual user traffic transported over the connections set-up by a call. Signaling is the communications which occur in order to set-up and tear down call connections.

A classic example of signaling is where a first switch processes a dialed number and selects a second switch to use on the call. The first switch extends the call connection to the second switch and signals the dialed number to the second switch. This second switch may repeat the process for a third switch, and the process would repeat until the call connection is complete. To facilitate this processing, the switch contains a central processing unit (CPU) and a signaling point. The switch CPU is coupled to the switch matrix and controls the connections established by the matrix. The switch CPU processes the information, such as a dialed number, to select a connection and direct its associated switch matrix to make the connection. The switch signaling point acts as the signaling interface for the switch CPU by transmitting and receiving signaling and converting call information between the signaling protocol and the switch CPU protocol.

Signaling has attained additional functionality with the evolution of what is called the intelligent network. In the intelligent network, switches are supported by external processors and databases. Switches process the signaling they receive to process calls. During this processing, the switch CPU may recognize that it needs the support of external processing or data. To obtain this support, the switch CPU and signaling point will generate a new signaling message to send to an external processor. The new signaling message is known as a query. The external processor will process the query and respond to the same switch with a signal containing additional information to support the switch.

A classic example of intelligent network operation is the 800 call (also known as free phone). For 800 calls, a switch will receive a call set-up message including the dialed number. In SS7, this is an initial address message (IAM). The switch would process the IAM until it recognized that the dialed number had an area code of 800, and that the switch would require support from an external database to obtain a standard telephone number it can use to route the call. This act of recognition is known as a trigger. The standard telephone number is known colloquially as a plain old telephone service (POTS) number. As such, the switch would generate a signaling message to send to an external database. In SS7, this is a transaction capabilities application part (TCAP) message and is commonly known as a query. The external processor that receives the TCAP query is known as a service control point (SCP). The SCP analyzes the query and typically responds to the switch with the appropriate POTS number. The switch can then process the call in a conventional fashion. Those skilled in the art are aware of the many special call processing features that can be implemented through an SCP.

Thus, it is known in the art that a switch initially receives a call set-up message to begin call processing. The switch may trigger during call processing and invoke an external processor with a separate query message. After analysis, the external processor will respond to that same switch with its own message.

At present, the switches are the devices which receive and process the call set-up signaling to route calls and invoke the intelligent network. As a result, current networks are limited to what the switch can accomplish in the form of call processing. In order to add new functionality, the switch CPU must be re-programmed with new call-processing logic or an existing switch trigger must be re-used. Both restrict a network's ability to provide new services. Since the switch remains the primary platform from which call processing is initiated and controlled, networks must wait until switches are developed with the requisite functionality before new services and interworking can be deployed.

A current example of this problem is provided by asynchronous transfer mode (ATM) switches. Although ATM switches are currently functional to transport broadband traffic, ATM switches which can handle extensive call capacity and signaling are not available. Support systems for these switches, such as billing and trigger detection, are not at a robust stage of development. As a result, networks have to wait until ATM switches develop additional capability before the broadband transport functionality can be fully exploited. Systems are needed which do not rely on the signal processing and call processing capabilities of the switches.

At least one system has suggested routing user service requests to a call server that is external to a switch. However, this system requires that the call processing be separated from connection processing. This separation requires the deployment of an entirely new and proprietary signaling system. In this system, a call server receives user signaling and selects services and route characteristics. A separate connection server selects the route, and a separate channel server selects the specific connections on the route. The servers communicate with a proprietary signaling protocol. This system is not yet defined to a point sufficient for implementation. As such, the system could not be as readily implemented as a system which integrates call processing with connection processing and uses conventional signaling protocols.

SUMMARY OF THE INVENTION

Examples of the invention include a signaling processor and its method of operation. The signaling processor receives a first signaling message indicating a called telephone number for the call. The signaling processor processes the called telephone number from the first signaling message to determine if call validation is required. If the call validation is not required, then the signaling processor processes the called telephone number to determine routing information without the call validation. If the call validation is required, then the signaling processor determines if the call is valid, and if the call is valid, then the signaling processor processes the called telephone number to determine the routing information. The signaling processor transfers a second signaling message indicating the routing information for the call.

In some examples of the invention, validating the call comprises checking a caller number for the call.

In some examples of the invention, validating the call comprises determining if a billing problem exists for the caller.

In some examples of the invention, the first signaling message comprises a signaling system seven message.

In some examples of the invention, the second signaling message is transferred over an internet protocol link.

In some examples of the invention, the first signaling message comprises a signaling system seven message and the second signaling message is transferred over an internet protocol link.

In some examples of the invention, a first network element transfers the first signaling message and a second network element receives the second signaling message and wherein the signaling processor is external to the first network element and the second network element.

In some examples of the invention, the route information indicates a connection.

In some examples of the invention, the route information indicates a wireless connection.

In some examples of the invention, the route information indicates a virtual connection.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention can be better understood by reference to the following drawing figures where:

FIG. 1 depicts a block diagram of a version of the invention.

FIG. 2 depicts a logic diagram of a version of the invention.

FIG. 3 depicts a logic diagram of a version of the invention.

FIG. 4 depicts a logic diagram of a version of the invention.

FIG. 5 depicts a logic diagram of a version of the invention.

FIG. 6 depicts a logic diagram of a version of the invention.

FIG. 7 depicts a flow diagram of a version of the invention.

FIG. 8 depicts a flow diagram of a version of the invention.

FIG. 9 depicts a flow diagram of a version of the invention.

FIG. 10 depicts a block diagram of a version of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention provides a system for managing telecommunications which is not as dependent on switch functionality as prior systems. This is accomplished by employing a system which processes call signaling and does not have to be bundled with a switch and associated switch matrix. Using the invention, the switches can be used to provide their switching and transport functions irrespective of their capability to provide other features. In addition, some embodiments of the invention can logically integrate call and connection processing, and can be operational with conventional signaling systems.

On the figures, connections that carry user information are shown as single lines and signaling links that carry signaling messages are shown as double lines. FIG. 1 depicts a basic version of the unique invention. Signaling processor 110 is shown connected to user 115 by link 120. Processor 110 is also connected to switch 125 by link 130 and to element 135 by link 140. User 115 is connected to switch 125 over connection 145. Switch 125 is connected to element 135 over connection 150. Aside from processor 110, these components are known in the art. User 115 could be any entity requesting a service that requires a communication path with a few examples being a telephone, a computer, or a local exchange carrier (LEC) switch. Switch 125 could be any device which establishes communications paths in response to signaling with examples being a Northern Telecom DMS-250 or a Fore Systems ATM Switch. Element 135 could be any device to which calls are connected. A few examples would be a switch, cross-connect, server, enhanced platform, or even, a destination telephone or computer. Connections 145 and 150 could be any media which carries user information with a few examples being DS3 trunks, SONET/ATM virtual connections, or wireless connections. Links 120, 130, and 140 could be media which transfers telecommunications signaling with a few examples being a 56 kbit data line, a virtual channel carrying SS7, or a UDP/IP link. Those skilled in the art will readily appreciate that networks typically deploy numerous other switches, connections, links, and other network elements which are not shown on FIG. 1 for purposes of clarity. Among these other network elements might be SCPs, signal transfer points (STPs), multiplexers, and echo cancellers, but there are many others.

Processor 110 could be any processing platform configured to support the requirements of the invention and is discussed in detail below. In operation, user 115 would request a service that requires a communications path by signaling a network. These signals are directed to processor 110 over link 120. Those skilled in the art are aware that STPs might be used for this purpose. In addition, in-band signals, such as those on a local loop, may pass through a switch before they are separated out-of-band and directed to processor 110. Any technique for directing user signaling to processor 110 is contemplated by the invention. This signaling is known as call set-up signaling and for SS7, it is the IAM.

It is important to note that the call set-up signaling from user 115 is directed to processor 110 and is not processed by switch 125 in order to recognize a trigger or establish a communication path. Processor 110 does not merely receive queries generated by switch 125 that are generated in response to the call set-up signaling from user 115. It is also important to note that processor 110 does not accept connections 145 or 150 which carry the actual user traffic. As such, processor 110 is linked to the switch only by a signaling link. It is not coupled to a switch matrix and can be external to the switch. However, the signaling processor could actually reside physically within a switch if it is not coupled to the switch matrix and only communicates with the switch over a signaling link. Those skilled in the art are aware of how a switch CPU is coupled to the switch matrix.

Processor 110 would process the call-set up signaling. For a typical call, this might include verifying the dialed number, validating the caller, controlling an echo canceller, generating billing information, selecting connections for the call, and generating signaling incorporating the pertinent information to complete the call. This signaling generated by processor 110 would be transmitted over link 130 to switch 125 in order to provide the service. This may include setting up the communications path over connections 145 and 150. If required, processor 110 could also generate and transmit appropriate signaling to element 135 over link 140 or to user 115 over link 120. The signaling could be conventional signaling such as SS7.

FIG. 2 depicts another embodiment of the invention, although the invention is not restricted to this embodiment. Narrowband switch 215 is shown connected to ATM switch 225 by connection 205. Signaling processor 210 is shown linked to narrowband switch 215 by signaling link 220. Signaling processor 210 is also shown linked to ATM switch 225 by signaling link 230.

Those skilled in the art are familiar with the logical breakdown and functionality shown for switches 215 and 225. Both switches 215 and 225 contain switching fabric that is connected by connection 205. The switch fabric and connection 205 carry the user information for a call. Both the switch fabric and connection 205 are well known. An interworking multiplexer would be used to convert the traffic on connection 205 between narrowband and broadband formats. The multiplexer is not shown for purposes of clarity.

Signaling is required to control the switching function. Signaling link 220 is connected to message transfer part (MTP) level 1. The signaling link is typically an SS7 link. MTP level 1 defines the physical and electrical requirements for link 220. MTP level 2 sits on top of level 1 and maintains reliable transport over link 220 by monitoring status and performing error checks. Together, MTP levels 1-2 provide reliable transport over an individual link. A device would need MTP level 1-2 functionality for each link it uses. MTP level 3 sits on top of level 2 and provides a routing and management function for the signaling system at large. MTP level 3 directs messages to the proper signaling link (actually to the MTP level 2 for that link). MTP level 3 directs messages to applications using the MTP levels for access the signaling system. MTP level 3 also has a management function which monitors the status of the signaling system and can take appropriate measures to restore service through the system. MTP levels 1-3 correspond to layers 1-3 of the open systems interconnection basic reference model (OSIBRF). Both the MTP 1-3 and the OSIBRF are well known in the art

Switch 215 has integrated services digital network user part (ISUP) logic which supports basic call processing. ISUP uses MTP to transmit messages across the signaling system. The information contained in ISUP messages is used by telecommunications networks to implement services and establish communications paths. A few examples of ISUP information are the dialed number and the caller's number. ISUP employs many different message types to carry this information with a few examples being the initial address message (IAM) and the answer message (ANM). ISUP is well known in the art.

Narrowband switch 215 has call process logic which processes the call information provided by ISUP in order to control the switch fabric and establish communication paths. A classic example of this would be the analysis of a dialed number to select a route for the call. Narrowband switch call processors are well known in the art.

ATM switch 225 has ATM layer, signaling ATM adaption layer (SAAL), and MTP level 3 logic which provide routing, management, and transport over the signaling system. Signaling link 230, typically an ATM virtual connection transported by SONET or DS3 facilities, is connected to the ATM layer. The ATM layer is analogous to MTP level 1 and transmits and receives ATM cells containing signaling messages on the link specified in the cell header. The SAAL assembles and disassembles these cells, maintains individual virtual connections, performs error checks and is analogous to MTP level 2. The MTP level 3 logic in ATM switch 225 performs the same basic functions as described above for MTP level 3, but the broadband version of MTP level 3 has been updated to support the needs of broadband systems. The ATM layer, the SAAL, and the updated MTP level 3 are known in the art.

ATM Switch 225 has broadband-ISUP (B-ISUP) logic which supports basic call processing in the broadband environment to control the broadband switch fabric. B-ISUP uses MTP level 3, the SAAL, and the ATM layer to transmit messages across the signaling system. The information contained in B-ISUP generated messages is used by telecommunications networks to establish communications paths. A few examples of B-ISUP information are the dialed number and the caller's number. B-ISUP employs many different message types to carry this information with a few examples being the initial address message (IAM) and the answer message (ANM). B-ISUP is known in the art.

ATM switch 225 has call process logic which processes the call information provided by B-ISUP in order to control the switching fabric and establish communication paths. An example of this would be the assignment of a virtual connection to a call based on a dialed number. ATM switch call processors are known in the art.

Processor 210 is connected to signaling links 220 and 230. Processor 210 has the MTP and ATM logic described above which allow it to interface with components using either ISUP or B-ISUP. If ISUP or B-ISUP signaling is not required, the associated functions could be omitted.

Processor 210 has interface logic which transfers signaling between MTP level 3 and the call/connection manager (CCM). Processor 210 has CCM logic which is able to process the information in the signaling received from the interface. For a typical call, this might include verifying the dialed number, validating the caller, controlling an echo canceller, generating billing information, translating the dialed number, selecting a route for the call, and generating signaling to complete the call. The signaling generated by the CCM would be transported back through the interface for transfer to switches 215 or 225.

In one embodiment, narrowband switch 215 might be a LEC switch and ATM switch 225 might be an interexchange carrier (IXC) switch. The IXC faces several problems when trying to interwork existing LEC narrowband switches with its own ATM switches. Current ATM switches do not support many of the features required by an IXC in a robust manner, such as routing and billing. Additionally, switches 215 and 225 are not equipped to exchange signaling without modifying one of the switches with a ISUP to B-ISUP signaling interworking unit. The present invention provides the interworking function between the two switches and provides call processing. This means a much less sophisticated ATM switch can be used.

In this embodiment LEC switch 215 might request a connection through the IXC. As a result, LEC switch 215 would signal the IXC with an SS7 IAM over signaling link 220. Processor 210 would accept the message through its MTP layers and interface. The interface would deliver the signal to the CCM, and the CCM would process the signaling information in the IAM. This may include verifying that the dialed number is legitimate, validating the caller by checking the Automatic Number Identification (ANI), generating a billing record, and controlling an echo canceller. The CCM could also process the dialed number to select a connection for the call. The pertinent portions of this information would be packed into an appropriate B-ISUP message and passed to the interface for subsequent transfer by the MTP 3, the SAAL, and the ATM layer to ATM switch 225 over signaling link 230. Based on the B-ISUP message, ATM switch 225 would connect the call. This would entail extending the communications path beyond connection 205 based on the signaling message from the CCM. As such, a communications path would be set-up through switch 215 and switch 225.

The Call/Connection Manager (CCM)

FIGS. 3-9 depict an embodiment of the signaling processor which is also referred to the a call/connection manager. Although this embodiment is preferred, the invention should not be restricted to this specific embodiment.

Signaling processor 310 is shown. Reference numeral 315 indicates that signaling processor 310 can be equipped with an MTP level 1-2 signaling interface, an ATM layer/SAAL signaling interface, or both. Signaling processor 310 would be equipped with MTP level 3 320 which operates as described above for ISUP and B-ISUP. Also shown for signaling processor 310 is ethernet interface 335. Ethernet interface 335 is a standard ethernet bus supporting TCP/IP which transfers signaling messages from MTP level 3 to platform handler 340. Together, the above components provide a signaling interface for the signaling processor. Those skilled in the art will recognize other interfaces and protocols which could provide a signaling interface in accord with the invention.

The signaling interface would be operational to route select ISUP messages to platform handler 340. One technique for accomplishing this would be to make signaling processor 310 a user part of the STP. A point code converter could be placed between MTP level 2 and MTP level 3 of the STP. The point code converter would convert the destination point code of messages that meet certain criteria to a point code that identifies signaling processor 310. The criteria could be loaded into a table and could include the originating point code (OPC), the destination point code (DPC), the (circuit identification code), and various combinations of these criteria. The conversion at this location in the STP could be specific to the signaling link used by the message, so the conversion tables could inherently account for the link used by the message. After conversion, the distribution function of MTP level 3 would forward signaling messages with the converted DPC to platform handler 340 over ethernet interface 335. A similar conversion function could be placed prior to the route function of MTP level 3 to convert point codes for messages transmitted by platform handler 340 out through the STP. The above technique is disclosed in United States patent application entitled, "TELECOMMUNICATIONS APPARATUS, SYSTEM, AND METHOD WITH AN ENHANCED SIGNAL TRANSFER POINT", filed simultaneously with this application, assigned to the same assignee, and which is incorporated by reference into this application

Alternatively, an SS7 signaling interface to the platform handler could be constructed using commercially available SS7 software tools. An example of such tools would be SS7 interface software provided by Trillium, Inc. Signaling messages with a destination point code (DPC) matching the point code for signaling processor 310 would be routed to the signaling interface of signaling processor 310 by the STP. Additionally, the STP could convert the DPC of a signaling message to the point code of signaling processor 310 as described above. However, since signaling processor 310 is not a user part of the STP, the route function of MTP level 3 in the STP would route the signaling message to signaling processor 310 over a signaling link. The signaling interface would receive the signaling message and transfer it to platform handler 340.

Although point code conversion facilitates a transition from existing systems to one of the present invention, it is not essential. Any method of forwarding signaling the CCM is sufficient.

Also shown are platform handler 340, message handler 345, and data handler 350. Platform handler 340 is a system which accepts ISUP and B-ISUP messages from ethernet interface 335 and routes them to message handler 345. Preferably, platform handler 340 is configured to route messages to a particular message handler processor based on the signaling link selection (SLS) code in the message. Message handler 345 is a system which exchanges signaling with platform handler 340 and controls the connection and switching requirements for the calls. It can select and implement services and initiate echo control. It also converts signaling between ISUP and B-ISUP. Data handler 350 is a set of logic coupled to message handler 345 which processes service requests and provides data to message handler 345. Data handler 350 also controls echo cancellers and generates billing records for the call.

In the discussions that follow, the term ISUP will include B-ISUP as well. In operation, ISUP messages that meet the proper criteria are routed by MTP and/or ATM interface 315, MTP level 3 320, and ethernet interface 335 to platform handler 340. Platform handler 340 would route the ISUP messages to message handler 345. Message handler 345 would process the ISUP information. This might include validation, screening, and determining if additional data is needed for call processing. If so, data handler 350 would be invoked and would provide message handler 345 with the relevant data so message handler 345 could complete call processing. Message handler 345 would generate the appropriate ISUP message to implement the call and pass the signals to platform handler 340 for subsequent transmission to the designated network elements.

The distribution of functional entities among message handler 345 and data handler 350 are shown. These functional entities are well known in the art. Message handler 345 includes at least the call control function (CCF) and the service switching function (SSF). The CCF establishes and releases call connections, and the SSF recognizes triggers during call processing by the CCF and provides an interface between the CCF and the service control function (SCF). The SCF identifies services and obtains data for the service. In some embodiments, message handler 345 can include the SCF and the service data function (SDF). The SDF provides service data in real time to the SCF. Taken together, message handler 345 is able to at least control connections and recognize triggers. In some embodiments, message handler 345 can also identify services, obtain data for the services, and generate the signaling required to implement the services. Message handler 345 can provide signaling interworking (i.e. ISUP to B-ISUP), connection control, service selection and service implementation in a logically integrated package that interfaces with the network through conventional means.

Data handler 350 includes at least the SCF and the SDF. In some embodiments, message handler 345 and data handler 350 both include the SCF and the SDF and services are partitioned among the functional entities. Two other functions are shown in data handler that are not standardized functional entities. Accounting generates a billing record and echo handles the echo cancellers. Typically, an echo canceller is disabled for a data call and enabled after the data call for use on subsequent voice calls, however, other techniques are applicable.

In operation, the CCF would perform basic call processing until the SSF recognized a trigger and invoked the SCF. The SCF would identify the service associated with the trigger. The SCF would access data from the SDF in order to implement the service. The SCF would process the data from the SDF and provide the data to the CCF through the SSF. The CCF would then set-up the connections through conventional signaling to service switching points (SSPs). The SSPs are connected to the communications path and make the connections. Typically, an SSP is a switch. Also, echo cancellers may be controlled for the call, and a billing record could be generated for the call.

Those skilled in the art are aware of various hardware components which can support the requirements of the invention. For example, the platform handler, message handler, and data handler could each reside on a separate SPARC station 20.

The Platform Handler

FIG. 4 shows a possible version of the platform handler. Platform handler 410 is shown. Platform handler 410 includes STP handler 412, supervisor 414, and CCM handler 416

Platform handler 410 transmits and receives ISUP messages to/from a signaling interface. That STP routed ISUP messages with particular characteristics to an application residing on top of the STP. The application could be the CCM and the characteristics could be the originating point code (OPC), destination point code (DPC), signaling link selection (SLS), circuit identification code (CIC), and/or the service information octet (SIO). The connection between platform handler 410 and the STP could be an ethernet LAN transporting ISUP messages encapsulated in TCP/IP packets. STP handler 412 would provide the ethernet--TCP/IP interface. STP handler 412 has a process to buffer and dis-assemble the incoming packets to the CCM, and buffer and assemble outgoing packets. STP handler 412 could also check the messages for basic flaws. Any technique for transfer of signaling messages to platform handler 410 is contemplated by the invention.

Supervisor 414 is responsible for managing and monitoring CCM activities. Among these are CCM start-up and shut-down, log-in and log-off of various CCM modules, handling administrative messages (i.e. error, warning, status, etc.) from the CCM modules, and handling messages from network operations such as queries, configuration instructions, and data updates. The connection to network operations is the man machine interface which allows the CCM to be controlled and monitored by either a remote or a local operator. Supervisor 414 has a process which retrieves configuration data from internal tables to initialize and configure the CCM. The CCM modules also have internal tables which are used in conjunction with this procedure. Supervisor 414 also communicates internally with STP handler 412 and CCM handler 416.

CCM handler 416 exchanges ISUP information with STP handler 412. CCM handler 416 also exchanges ISUP messages and CCM supervisory messages with the message handler. The connection between CCM handler 416 and the message handler could be an ethernet LAN transporting these messages encapsulated in TCP/IP packets, but other methods are known. CCM handler 416 would provide the ethernet--TCP/IP interface. CCM handler 416 has a process to buffer and dis-assemble the incoming packets from the message handler, and buffer and assemble outgoing packets to the message handler. CCM handler 416 could also check the messages for basic flaws.

Internally, platform handler 410 is equipped with bi-directional channels which exchange information among STP handler 412, supervisor 414, and CCM handler 416. The channels between STP handler 412, CCM handler 415, and supervisor 412 carry supervisory and administrative information. The channel between STP handler 412 and CCM handler 416 carries ISUP message information.

Platform handler 410 accepts, disassembles, and buffers ISUP messages received from the network. It can perform basic checks on the messages before transferring them to the message handler. Should more than one message handler be connected to platform handler 410, the ISUP messages could be allocated to the message handlers based on the SLS of the particular ISUP message. CCM handler 416 accepts routing instructions from the message handler for routing certain ISUP messages to select processes of the message handler. Platform handler 410 also provides supervision and a man/machine interface for the CCM.

The Message Handler

FIG. 5 depicts a possible version of the message handler. Message handler 520 is shown and includes call center 521, origination manager 522, termination manager 523, detection point manager 528, feature manager 524, auxiliary manager 525, switching manager 526, and local resource 527. A primary function of message handler 520 is to modify ISUP messages.

Call center 521 is the process which receives call set-up messages from the platform handler. ISUP call set-up is initiated with the IAM. When call center 521 receives an IAM, it creates an instance of an origination manager process with data defined by the information in the IAM. Origination manager 522 represents any of the origination manager processes spawned by call center 521. The CCM handler is instructed of the new instance so that subsequent ISUP messages related to that call can be transferred directly to the appropriate instance of origination manager 522 by the platform handler.

Origination manager 522 sets up a memory block called an originating call control block. The call control block provides a repository for information specific to a call. For example, the originating call control block could identify the following: the call control block, the origination manager, the message handler, the originating LEC, the LEC trunk circuit (CIC), the ATM virtual circuit, the ATM virtual path, the caller's number, the dialed number, the translated dialed number, the originating line information, the ANI service class, the selected route, the number of the selected route, the SLS, the OPC, the DPC, the service indicator (SIO), echo cancellation status, reason of release, call status, and pointers to adjacent call control blocks. In addition, the call control block would also contain the various times that signaling messages are received, such the address complete message (ACM), the answer message (ANM), the suspend message (SUS), the resume message (RES), and the release message (REL). Those skilled in the art would be aware of other pertinent data to include.

Origination manager 522 executes call processing in accordance with the Basic Call State Model (BCSM) recommended by the International Telecommunications Union (ITU), but with some notable exceptions. Origination manager 522 processes the IAM through each point in call (PIC) until a detection point (DP) is encountered. When a detection point is encountered, a message is sent to detection point manager 528 and processing is suspended at origination manager 522 until detection point manager 528 responds. An example of a detection point for origination manager 522 would be to authorize an origination attempt.

Detection point manager 528 accepts messages from originating manager 522 caused by a detection point encountered during call processing. Detection point manager 528 will identify whether or not the detection point is armed. An armed detection point has specific criteria which can affect call processing if met. If the detection point is not armed, detection point manager 528 will send a continue signal back to origination manager 522. A continue message instructs origination manager 522 to continue call processing to the next detection point. If the detection point is armed, detection point manager 528 will take action to see if the detection point criteria are met. If detection point manager 528 requires assistance to process the armed detection point, it will send a message to feature manager 524.

Feature manager 524 would accept messages from detection point manager 528 and either forward the a message to auxiliary manager 525 or to switching manager 526. Particular feature messages would be routed to auxiliary manager 525 which will process these call features. These are typically non-IN features, such as echo control or POTS billing. Other feature messages would be routed to switching manager 526. These are typically IN features. Examples of IN features are 800 number translation or a terminal mobility number translation. Feature manager 524 will pass information back to detection point manager 528 (then to origination manager 522) when it is received back from auxiliary manager 525 or switching manager 526.

Switching manager 526 which will determine if the request will be handled by local resource 527 or by the data handler. Local resource 527 will be structured to provide data more efficiently stored at message handler 520. Examples of such data include: an automatic number identification (ANI) validation table which checks the caller's number, a dialed number translation table to translate POTS numbers into a routing instructions, or NA00 translation tables to translate select 800 numbers into routing instructions. Examples of a routing instruction yielded by the tables would be a switch/trunk or a virtual connection. An example of data in the data handler would be virtual private network (VPN) routing tables or complex 800 routing plans.

Typically, originating manager 522 will execute through the pertinent points in call to a point indicating that set up is authorized. At this point, origination manager 522 will instruct call center 521 to create an instance of a termination manager. Termination manager 523 represents any of these termination managers. Origination manager 522 will also transfer IAM information to termination manager 523. Termination manager 523 sets up a memory block called a terminating call control block. The call control block provides a repository for information specific to a call and is similar in composition to the originating call control block.

Termination manager 523 also operates in accord with the BCSM of the ITU, but also with some exceptions. Termination manager 523 continues processing for the call through its own points in call until detection points are encountered. When a detection point is encountered, a message is sent to detection point manager 528 and processing is suspended at termination manager 523 until detection point manager 528 responds. An example of detection point for termination manager 522 would be to authorize termination which would entail authorizing the call as set-up by origination manager 522. Messages from termination manager 523 to detection point manager 528 are handled as discussed above for messages from originating manager 522. When processing by termination manager 523 is complete, it will produce an IAM to transmit through platform handler 410 to the appropriate network elements.

Message handler 520 communicates with the data handler using a data transfer protocol. Examples include UDP/IP, or the Intelligent Network Applications Protocol (INAP) which is contained within the component sublayer of Transaction Capabilities Application Part (TCAP).

The Data Handler

FIG. 6 shows a possible version of the data handler. Data handler 630 is shown. Data handler 630 includes service control center 631, service selection 632, service logic center 633, feature process 634, service data center 635, service data manager 636, echo control 637, and accounting 638. Data handler 630 receives service request messages from the message handler. These messages result from an armed detection points triggering the message handler to invoke data handler 630. The messages also result from features implemented through the auxiliary manager. Service control center 631, service logic center 633, and service data center 635 are static processes created at start-up. Service control center 631 creates instances of service selection managers on a call by call basis. Service control center 631 notifies the Switching manager to route subsequent service request messages for that call to the appropriate service selection manager. Service selection manager 632 represents any of the service selection managers created by service control center 631.

Service selection manager 632 executes the service portion of the call processing. Service selection manager 632 identifies the various services associated with each message and implements the service through messages to service logic center 633. Service logic center 633 accepts messages from service selection 632 and creates instances of the feature processes required for the identified services. Examples of feature processes are N00, messaging, personal/terminal mobility, and virtual private network (VPN). Feature processes are service logic programs which implement the required services for a call. Feature process 634 represents any of the feature processes created by service logic center 633. Feature process 634 accesses the network resources and data required to implement the service. This would entail executing service independent blocks (SIBs). A SIB is a set of functions. An example of a function would be to retrieve the called number from a signaling message. SIBs are combined to build a service. An example of a SIB is translating a called number.

Those skilled in the are familiar with the above services, although they have never been implemented by a system such as the present invention. N00 services are services such as 800, 900, or 500 calling in which the dialed number is used to access call processing and billing logic defined by the subscriber to the service. Messaging entails connecting the caller to a voice messaging service. For example, the receipt of a release message (REL) with a cause of busy could be a trigger recognized by the message handler. In response, the data handler would create an instance of the messaging feature process and determined if a call placed to a particular dialed number would require the voice messaging platform. If so, the CCM would instruct an SSP to connect the caller to the voice message platform. Personal/Terminal mobility includes recognizing that the dialed number has mobility that requires a database look-up to determine the current number. The database is updated when the called party changes locations. VPN is a private dialing plan. It is used for calls from particular dedicated lines, from particular calling numbers (ANIs), or to particular dialed numbers. Calls are routed as defined for the particular plan.

In the execution of the SIB to provide the service, feature process 634 would invoke service data center 635 to create an instance of service data manager 636. Service data manager 636 accesses the network databases that provide the data required for the service. Access could be facilitated by TCAP messaging to an SCP. Service data manager 636 represents any of the service managers created by service data center 635. Once the data is retrieved, it is transferred back down to feature process 634 for further service implementation. When the feature processes for a call finish execution, service information is passed back down to the message handler and ultimately to the origination or termination manager for the call.

After a release message on a call, billing requests will be forwarded to accounting 638. Accounting 638 will use the call control block to create a billing record. The call control block would contain information from the ISUP messages for the call and from CCM processing. From the address complete message (ACM), the call control block would include the routing label, CIC, message type, and cause indicators. From the answer message (ANM), the call control block would include the routing label, CIC, message type, and backward call indicators. From the initial address message (IAM), the call control block would include the routing label, CIC, message type, forward call indicators, user service information, called party number, calling party number, carrier identification, carrier selection information, charge number, generic address, origination line information, original called number, and redirecting number. From the release message (REL), the call control block would include the routing label, CIC, message type, and cause indicators. From the suspend message (SUS) or the pass along message (PAM), the call control block would include the routing label, CIC, and message type. Those skilled in the art are familiar with other pertinent information for a billing record and appreciate that some of this information could be deleted.

For POTS calls, the billing request will come from the origination and termination managers through the auxiliary manager. For IN calls, the request will come from service selection 632. Accounting 638 will generate a billing record from the call control blocks. The billing record will be forwarded to a billing system over a billing interface. An example of such an interface is the I.E.E.E. 802.3 FTAM protocol.

At some point during call set-up, the origination manager, termination manager or even the detection point process will check the user service information data and originating line information to assess the need for echo control. If the call is a data call, a message is sent to data handler 630. Specifically, the message is routed through the auxiliary manager to the echo control m