Patent Application
20060083367
Intelligent networks (INs) are being used to provide an increasing number of services to communication networks. INs deliver these services to a number of wireless or wireline stations, e.g., a number of communications devices such as phones, PDA's, etc. The service functions that deliver the services to these stations can be separated from the equipment that is providing the switching functionality to the stations. One benefit of this separation is that network providers do not have to perform major modifications on multiple switches when a new service is introduced.
For instance, a switch in a publicly switched telephone network (PSTN) connects a call signal, or other media data traffic, on one media channel to another available media channel in order to continue routing the signal to the intended destination. A switch can perform its function based, for example, on Signaling System 7 (SS7) control signals. The SS7 can set up and tear down a call, handle the routing decisions, and support telephony services such as 800 numbers, call forwarding, caller ID, local number portability (LNP), etc.
INs can provide enhanced voice, video, and data services and dynamic routing capabilities by using a number of different networks. That is, the actual voice call can be transmitted over a circuit-switched network, but the signaling, e.g., control signal transmission, can be accomplished on a separate SS7 packet-switched network.
An originating switch in a local exchange carrier (LEC) network may determine when processing for services is requested for a telephone call. When processing for services is requested, the originating switch opens a dialogue with another media platform, e.g., a service control gateway, and exchanges protocol messages embedded within SS7 protocol messages with the service control gateway.
Since changes in the services provided do not typically affect or use the functionality of the switching system, by keeping the programs and/or data from the switching and services functions separate, the separation allows changes to be made to one without influencing the other. Additionally, since the service functions are separate, they can be programmed to be used by a variety of communication protocols used by a network.
For example, protocols are defined to permit interaction between switching equipment and other equipment, e.g., IN nodes, which contain the service logic and service data. Networks can use one or more protocols to handle different data formats and data for different purposes. Protocol examples include, but are not limited to, intelligent network application part (INAP), mobile application part (MAP), customized applications for mobile network enhanced logic (CAMEL), and capability set (CS) protocols, to name a few.
The transaction capabilities application part (TCAP) is defined as a layer in the SS7 protocol stack that defines the messages and protocol used to communicate between applications (deployed as subsystems) in SS7 nodes, such as switching points/centers, control points, end points, and the like. The TCAP works to send and receive messages from a variety of different protocols including those discussed above. In the SS7 network, a TCAP is used to add transaction-based functionality to the Public Switch Telephone Network (PSTN) and to mobile communication networks. TCAP messaging is defined within the SS7 specifications as a communications protocol that maintains dialogue processing, activates remote processes or features, and transfers switched-based information from one telephony application to another.
TCAP protocol is used to communicate messages between different entities, such as databases and end stations. For example, TCAP messages are typically used for communications between service switching points (SSPs) and service control parts (SCPs) within a communication network or between networks.
The TCAP protocol handles numerous processing functions within the PSTN and mobile networks such as 800 or free phone processing, 911 emergency service, repeat dialing, calling card services, call forwarding, call waiting, call return, etc. For example, an SSP sends a TCAP query to determine the routing number associated with a dialed 800/888 number or to check the personal identification number (PIN) of a calling card user. In mobile networks (e.g., networks operating under American National Standards Institute's standard number 41 (ANSI-41), Interim Standard number 41 (IS-41) or Global System for Mobile (GSM) communications networks, among others), a TCAP message establishes connectivity between mobile switches and databases to support user authentication, equipment identification, roaming, and other such functions.
Although service application programs can be written to work with a number of protocols, current service application programs cannot identify from which protocol messages are received when TCAP messaging is used to communicate the messages. This is because the messages are routed to and from a service application program using point code to provide the routing directions.
Point code is a SS7 address of a network component, used to identify the signaling point in SS7 messages. Point code typically includes location information such as a network identifier. However, this information does not identify the protocol that is being used to communicate the information.
Since services may be provided for communications using different protocols, in order for the service application to provide the correct interaction with a protocol, the services typically have a single service logic program (SLP) that can interpret the information being communicated between the service and the switch from all available protocols. As such, the SLP is typically a large program where small pieces of the program are used to deal with each type of protocol interaction. Invoking and utilizing this program can use substantial processor and memory resources to operate.
Embodiments of the present invention provide for routing of TCAP messages. According to various embodiments, a computing device, such as in a communication network, can include program instructions storable in memory and executable by a processor. The program instructions can include instructions executable to receive a protocol identifier from within a transaction capabilities application part (TCAP) message to identify a particular protocol to use in routing the TCAP message. The instructions can also execute to route the TCAP message to the particular protocol. In this way, TCAP messages can be handled in a protocol-specific manner by a number of protocol-specific service logic programs.
The computing device can include program instructions to route subsequent TCAP messages to a particular protocol-specific service logic program. The routing is based upon the received protocol identifier. Additionally, in some embodiments, the protocol identifier in a first TCAP message is used to route one or more subsequent messages to a particular service logic program.
The protocol identifier can be provided with or in a TCAP message. For example, the protocol identifier can be provided in an application context field in the TCAP message. In some embodiments, the application context field can be an unused field. In such instances, the field can be empty when not used to provide the protocol identifier.
Additionally, in some embodiments, the application context field can be used for other purposes and, in such cases, one or more particular codes can be used to identify the different protocols from other information that may be provided in the application context field. In these cases, the protocol information can be identified in various manners.
For example, the protocol identifier can be checked against a list of various identifiers corresponding to a number of protocols. If the protocol identifier, accompanying the TCAP message, corresponds to an identifier on the list, then the message is routed according to program instructions associated with the matched identifier. If the information within the application context field does not match one of the protocol identifiers listed, then the information can be disregarded.
The receiving and routing functionality of these program embodiments can be provided by various computing devices of a communication network. For example, a computing device used as a service control point (SCP) can be a suitable device for providing such functionality. Additionally, the receiving and routing functions can be provided in connection with other functions provided within the network. For example, the program instructions for receiving and routing can be associated with service control functions (SCFs) of a network.
The present invention also includes various communication network embodiments. Communication network embodiments can include a number of service switching points (SSPs), a number of signal transfer points (STPs) coupled to one or more of the SSPs, and a number of SCPs coupled to one or more of the STPs. The SCPs can include executable program instructions associated with a SCF.
The program instructions can be executable to route a TCAP message to a particular protocol based upon a protocol identifier from the TCAP message. The protocol identifier can be received from the TCAP message or the TCAP message can be accessed to allow program instructions to identify the protocol identifier. The protocol identifier can be contained in a particular field of the TCAP message. For example, the application context field can contain the protocol identifier. In such cases, a bit or string of bits can be used to provide the protocol identification information.
The protocol identifier can be used to identify the protocol of a message to a service or group of services. For example, some IN systems utilize Parlay services which have a number of service applications provided within the Parlay environment.
Parlay services refer to a set of web-services that can be described using web services definition language (WSDL) by application and service creation designers. The Parlay services can include Parlay APIs (not shown) which are designed to enable creation of telephony applications as well as to enable information technology applications.
Parlay services accommodate the development of next generation network applications. The interaction between an application incorporating a Parlay web service and a server implementing the web service, e.g., a service capability server (SCS) or service control gateway (SCG) implementing the embodiments described herein, can be performed using an extensible markup language (XML) based message exchange through the high speed bus, for example. Parlay services are not network equipment specific, and are not network specific where a particular capability is relevant to more than one type of network.
One of ordinary skill in the art will appreciate upon reading this disclosure that Parlay applications to invoke Parlay services, and/or other service application layers, can interact with an SS7 network including the use of a SCF in a SCP, according to the embodiments described above.
The protocol identifier can be used to identify which protocol is requesting the service in order to provide the correct response to the request. This will allow a Parlay service application to use a particular protocol-specific SLP to provide the service.
These wireless networks 100 include one or more mobile switching centers (MSCs), e.g., gateway MSC/service switching point (GMSC/SSP) 112 and serving MSC/service switching point (SMSC/SSP) 126 described in more detail below, which are connected to a plurality of base stations (BS) 130 that are dispersed throughout the geographic area serviced by the network 100. Each MSC 112 and 126 is responsible for, among other things, establishing and maintaining calls between mobile devices and/or between a mobile device and a wireline device which is connected to the wireless network from a local and/or long-distance network, e.g., the regional Bells, Sprint, MCI, etc, in the public switched telephone network (PSTN) 110. Network devices in a wireline network can provide similar functions to those discussed with respect to
A MSC 112/126 is a telephone switch specialized for wireless and mobility support. As mentioned above, a MSC 112/126 performs various functions, including mobility management, call handoffs, call admission, call control, resource allocation, and so forth. A call and/or other data can be relayed from the MSC 112/126 to base stations 130. This relay can be via a wireless communication interface (e.g., via an ANSI, GSM, or other standards interface, etc.) to the mobile device 134.
In the embodiment of
Additionally, the MSCs 112 and 126 of the embodiment of
As shown in
Likewise, a computing device can also include a processor for executing program instructions, memory for storing program instructions, and data for use in providing the various network functions. For example, SCP 120 includes a processor 121 and memory 123. As the reader will appreciate, each of the physical components of the network can include processor and memory resources, e.g., as illustrated with respect to the SCP component 120.
Various network functions include, but are not limited to, HLR, VLR, SSP, SCP, billing (e.g., billing device 122), MSC, and the like. For example, a BS 130 may transmit subscriber identity information to a SMSC 126, via communication line, where it can be stored in a database associated with the SMSC 126. Messages such as a MAP based signals, e.g., a registration notification signal (IS-41 message) or location update signal (GSM message), can further be transmitted from the SMSC 126 to a HLR 114. As shown in
As shown in
As one of ordinary skill in the art will appreciate upon reading this disclosure, the multiple physical components, which are described above and elsewhere herein, can include both hardware and software resources. Among the hardware resources, a component can include logic in the form of one or more processors, field programmable gate arrays (FPGAs), firmware, etc., as well as memory. Memory can include non-volatile and volatile memory such as Flash memory, read only memory (ROM), random access memory (RAM), and optically readable memory, etc.
Memory can store computer readable and executable instructions related to a variety of functions and telecommunication service applications executable on and by the physical components described herein. The programs operate as functional entities (FEs) described in more detail in connection with
A SCP, such as SCP 120, in a SS7 telephone network provides an interface to databases, which may reside within the SCP node or in other nodes accessible on or through a network. As noted, the SCP may also be combined with the STP to route messages. The SSP sends SS7 messages to SCPs to retrieve subscriber and routing information as well as other information from various databases which support such features as 800 and 900 numbers, calling card validation, collect and third-party billing calls as described above.
The SCP includes computer executable instructions to provide service control functionality as discussed in more detail in connection with
The embodiment of
In the example illustrated, SSP 216-M is used by a roaming mobile station 234 (MS), e.g., a number of mobile devices or a connection to a number of mobile devices, and includes the SMSC 226 and a visiting service switching function (VSSF) 228. Although the discussion below is generally directed to the interaction of the SSP 216-1, and its components, with SCP 220 and HLR 214, the interaction with the SSP 216-M, and its components, and the VLR 224 with the SCP 220 can be described in a similar manner and, accordingly, will not be discussed in the same level of detail.
As shown in the embodiment of
The physical component of an SCP 220 provides stored program commands, e.g., computer executable instructions that are interfaced to the STP nodes (not shown) within the SS7 signaling network 200. SCP commands are used by the SSPs 216-1 to 216-M to process calls. The SCP 220 is a transaction-processing entity that provides call-handling information in response to SSP 216-1 queries. As shown in the embodiment of
When a service, such as call forwarding or other such services, as have been mentioned above, is requested, a TCAP message provides the request from an SSF 218 to the SCF 236 in a SCP 220. In order for the request to be fulfilled, the SCF 236 invokes a SLP instance. A SLP instance is created to handle a communication session, e.g., message exchange. The message exchange in this example is a request and response to the request. However, a session can include various numbers of messages between computing devices.
The reader will appreciate that within the network environment 200 there is a finite amount of memory that can be used for SLP instances and that each SLP instance has a certain static memory footprint and that the larger the program that the SLP is, the larger the memory footprint that will be used. Accordingly, smaller SLP instances will allow for more memory to be used for other purposes.
By using a number of protocol-specific SLPs, the SLP instances created will be smaller than when a single general SLP was invoked for use with various protocols. In addition, the processor resources used with respect to the single general SLP will can also be reduced.
The requests are directed to the SCP 336 via TCAP messages 340. In the various embodiments, the TCAP messages 340 contain a protocol identifier that is used to identify which protocol-specific SLP 343-1, 343-2, 343-3, . . . 343-N within a service logic execution environment (SLEE) 342 is to be used during the communication session. The designator “N” is used to illustrate that a number of such SLPs can be created, however, the illustration of a number of SLPs 343 should not be viewed as limiting the quantity of the other components shown and described herein. The SLEE is the environment in which SLP instances are created. The SLEE 342 typically exists within the SCF 341 on the SCP 336. Based upon the protocol identifier, an appropriate SLP instance can be created in the SLEE 342.
The SLP instance communicates via a communication link 344 with one of a number of service applications 346 and/or service data 348 to fulfill the request. In some embodiments, service applications can be of various types and can be grouped based upon the type of services they provide. For example, Parlay service applications or other such service application groups can be used.
Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed at the same point in time.
In block 410, the method of
In various embodiments, the method can include routing the TCAP messages from multiple protocols. In some embodiments, the protocol identifier can be read and the TCAP messages can be routed, for example, to an INAP, MAP, CS, CAMEL, or other such protocol. If the protocol identifier is within the TCAP message file, the protocol identifier can be read to identify a particular protocol in which to route the TCAP message.
In block 510, the method of
The method embodiment shown in
Although specific embodiments have been illustrated and described herein, those of ordinary skill in the art will appreciate that an arrangement calculated to achieve the same techniques can be substituted for the specific embodiments shown. This disclosure is intended to cover adaptations or variations of various embodiments of the invention. It is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one.
Combination of the above embodiments, and other embodiments not specifically described herein will be apparent to those of skill in the art upon reviewing the above description. The scope of the various embodiments of the invention includes other applications in which the above structures and methods are used. Therefore, the scope of various embodiments of the invention should be determined with reference to the appended claims, along with the full range of equivalents to which such claims are entitled.
In the foregoing Detailed Description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the embodiments of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
