Patent Application
20060040650
In an intelligent network (IN) services are separated from switching equipment and organized in a system such that network providers do not have to perform major modifications on multiple switches when a new service is introduced. IN development involves providing separate service data to databases outside of switching equipment nodes. Service programs (service logic) are similarly separated outside of the switching equipment nodes. Further, protocols are defined to permit interaction between switching systems and the intelligent nodes which contain the separated service logic and data.
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 on Signaling System 7 (SS7) control signals. The SS7 protocol sets up and tears down the call, handles all the routing decisions and supports all modem telephony services, e.g., 800 numbers, call forwarding, caller ID, local number portability (LNP), etc.
Advanced INs provide enhanced voice, video, and data services and dynamic routing capabilities by using two different networks. That is, the actual voice call is transmitted over a circuit-switched network, but the signaling, e.g., control signal transmission, is done on a separate SS7 packet-switched network. For example, an originating switch in a local exchange carrier (LEC) network may determine when processing for enhanced services is required for a telephone call. When processing for enhanced services is requested, the originating switch opens a dialogue with another media platform, e.g., a service control gateway as the same are known and understood in the art, and exchanges higher-level protocol messages embedded within lower-level SS7 protocol messages with the service control gateway.
Signaling System 7 (“SS7”) is a well known dialogue-based communications protocol used for signaling and which may be used for communications with computing platforms such as telecommunications platforms, e.g., mobile switching center (MSC) gateways, service control gateways, or other service capability servers (SCSs), etc., as the same are known and understood by one of ordinary skill in the art. The data exchanged using the SS7 protocol between an originating switch and, for example, a service control gateway is commonly formatted into intelligent network application protocol (“INAP”) messages. At the end of the exchange of INAP messages, e.g., that comprises the dialogue between the originating switch and the service control gateway, the service control gateway directs the originating switch to connect the telephone call to a final destination in order to facilitate the transfer of a media stream, e.g., voice, data, and/or video, etc, over a media channel, e.g., DS0, T1, DS3, SONET, etc., as the same are known and understood by one of ordinary skill in the art. Messages can be arranged in an octet format. Each octet represents a byte, or 8 bits of data, presented as a pair of hexadecimal values.
An MSC 104/124 is a telephone switch specialized for wireless and mobility support. As mentioned above an MSC 104/124 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 104/124 to base stations 110/126 and via a wireless communication interface 105 (e.g., via an ANSI, GSM, standards interface, etc., as the same are known and understood by one of ordinary skill in the art) to the mobile device 102.
A base station 110/126 may transmit subscriber identity information to a serving MSC 104, via communication line 112, where it can be stored in a database associated with the MSC. Messages such as a Mobile Application Part (MAP) based signal, e.g., a registration notification signal (IS-41 message) or location update signal (GSM message), can further be transmitted from the serving MSC 104 to a home location register (HLR) 116 via a signaling link such as a signal transfer point (STP) 114. An STP is an intelligent node in the SS7 telephone network that routes messages between exchanges and between exchanges and databases that hold subscriber and routing information. In the embodiment of
In voice networks, voice switches known as service switching points (SSPs) query service control point (SCP) databases using packet switches known as signal transfer points (STPs). As shown in
As one of ordinary will appreciate upon reading this disclosure the multiple physical components (also sometimes referred to as physical entities (PEs)), 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 gates arrays (FPGAs), firmware, etc., as well as memory. Memory can store software (e.g., computer readable and executable instructions and other programs) related to a variety of functions and telecommunication service applications executable on and by the components described herein. A processor can operate on computer executable instructions as part of the control logic for controlling operations of a component. Memory can include non-volatile and volatile memory such as Flash memory, read only memory (ROM), random access memory (RAM), and optical memory, among others.
As mentioned above, signal transfer points (STPs) are associated with service switching points (SSPs) and service control point (SCPs). STPs are high-capacity, high-reliability (as those terms will be recognized by one of ordinary skill in the art) packet switches, within the SS7 network, that transport signaling messages, using large routing databases, between the IN nodes, e.g., the service switching points (SSPs) and service control point (SCPs). These IN nodes include access to hardware and software resources such as the processor and memory capabilities described above. A SCP is a physical component node in a SS7 telephone network that provides an interface to databases, which may reside within the SCP node or in other nodes on a network. As noted, the SCP may also be combined with the STP to route messages. The SSP is a physical component node that 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.
The software resources, e.g., computer executable instructions, within a network, can be broken down into particular functions (also referred to as functional entities (FEs)), associated with SSPs and SCPs, as illustrated in
The physical component of an SSP 201 provides stored program control switches, e.g., computer executable instructions, that interface to the SS7 signaling network 200. The SS7 network 200 includes STPs (not shown) as the same have been described above. As shown in the embodiment of
As shown in the embodiment of
The physical component of an SCP 206 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 SSP 201 to process calls. The SCP 206 is a fault-tolerant, high-capacity (as those terms will be recognized by one of ordinary skill in the art) transaction-processing entity that provides call-handling information in response to SSP 201 queries. As shown in the embodiment of
The physical component of a service management point (SMP) 212 provides operation, administration, and maintenance functions for the IN. As one of ordinary will appreciate, the physical component of an SMP 212 includes the functional components (FEs) of a service management function (SMF) 214 and a service management access function (SMAF) 216. The SMF 214 includes executable instructions to allow deployment and provision of IN services and to allow the support of ongoing operation. The SMAF includes executable instructions to provide an interface between service managers and the SMF 214.
The physical component of an intelligent peripheral (IP) 218 generally includes software to perform a SRF 220, as the same has been described above and will be described further below. The IP 218 can be connected to an SSP 201 over a high speed bus, e.g., a common object request broker architecture (CORBA) bus. The IP 218 uses the SRF 220 to provide enhanced services or functions, e.g., web enabled application services, such as a Parlay application, as the same will be known and understood by one of ordinary skill in the art. The IP 218 can also employ a SRF 220 to manage resources such as announcements, speech recognition, digit collection, protocol conversions, etc. In other words, a SRF includes executable instructions to support specialized network resources generally associated with caller interaction with the IN. The SRF 220 starts a dialog, e.g., message exchange, under the control of an SCF 208 in the SCP 206. As shown in
The physical component of a service creation environment point (SCEP) 222 can include a service creation environment function (SCEF) 224. The SCEF includes executable instructions to allow services provided in the IN to be defined, developed, tested, and input to the SMF 214. The physical component of a service data point (SDP) 226 can include a service data function (SDF) 228. The SDF 228 includes instructions to manage customer and network data for real-time access by the SCF 208 in the execution of an IN service.
The IN architecture is fundamentally based on SS7 and its protocol architecture. In a first level a signaling transport capability, known as the message transfer part (MTP), handles the corresponding open systems interconnection (OSI) physical, data-link, and network layers, as the same are known within the OSI model. A next level, referred to as the signaling connection control part (SCCP), augments the MTP by providing both connectionless and connection-oriented message transport, as well as enabling addressing capabilities for message routing. A next level, referred to as the transaction capabilities application part (TCAP) provides procedures for real-time transaction control. The TCAP is used to send database queries to a SCP 206. It is also used to send non-circuit related messages between switches, e.g., SSPs 201. TCAP keeps track of multiple queries that are part of the same session, e.g., message exchange associated with a call or service request. A final layer, referred to as the IN application protocol (INAP), defines the operations required between IN network elements, such as SSPs 201 and SCPs 206. INAP protocols are used to initiate non-circuit related functions (e.g., not dealing with connect/disconnect) throughout the network 200. INAP protocols use TCAP to access remote devices.
In summary,
The general operation of a SLEE 302 includes processor and memory resources as well as computer executable instructions (e.g., software, firmware, etc.), storable in memory and executable by a processor therein. As shown in the embodiment of
In reference to
Embodiments of the present invention provide for efficient management of SLP instances within a multi-SLEE environment. According to various embodiments, in association with a multi-SLEE service control platform, e.g., service control gateway or service capability server, SRF interaction overhead is reduced by utilizing existing SLP instances when possible. When a SLP instance is created to invoke a SRF and start a SRF dialog, program instructions execute in conjunction with the invoking SLP to save SLEE instance information (e.g., the information on the SLEE containing the invoking SLP instance and information identifying the invoking SLP) keyed by a correlation ID. Program embodiments execute instructions using a SLEE dispatcher to look up the SLEE instance of each invoking SLP based on correlation ID information received in a return message to the dispatcher from an invoked SRF. When the correlation ID in the received message matches the correlation ID of the SLEE instance, program embodiments execute instructions to forward the SRF dialog to the invoking SLP instance. In a multi-SLEE environment, when the SLEE instance is matched in a look up (i.e., the same), an instance of the SLP can be conserved. Thus, the number of SLP instances employed to handle a session, e.g., message exchange/dialog, is reduced. Conservation of SLP instances conserves memory and thus allows more instances to handle more sessions on identical hardware.
A network computing device such as a server, having processor logic and memory, includes an operating system layer and an application layer to enable the device to perform various functions or roles. The operating system layer includes a “kernel”, e.g., master control program, that runs the computing device. The kernel provides task management, device management, and data management, among others. In other words, the kernel sets the standards for application programs that run on the computing device or for interfacing to application program which reside elsewhere in the network. The application layer includes programs applications, e.g., executable instructions, which are located above the operating system layer and accessible by a user. Before a computing device may accomplish a desired task, it receives an appropriate set of instructions. Executed by a device's processor(s), these instructions direct the operation of the device. These instructions can be stored in a memory of the computer. Instructions can invoke other instructions. As used herein, “user level” implies a layer of code which is more easily accessible, e.g., includes open-source code, than the layer of code which is in the operating system layer or “kernel” space. User space applications, or programs, reside above the kernel space of a network computing device and can reside elsewhere with the network.
As illustrated in the example of
In the example illustration of
As messages are exchanged between the plug-in container 406 and the bus 401 they are handled by an external component interface 412 provided to the plug-in container 406. Program instructions can execute in connection with the external component interface 412 to retrieve message definitions from a message database 414 and provide the same to a thread manager 416. A thread manager includes logic control for the execution of various processes and their associated threads.
The example illustration of
The various SLPs 404 within the multiple SLEEs, 402-1, . . . , 402-P, can contain the connection information to various user applications, or programs, e.g., web-enabled applications such as a Parlay application, which are located elsewhere in a network and coupled to the multiple SLEEs, 402-1, . . . , 402-P, via the bus 401 and the plug-in container 406. The application logic itself is not contained in the multiple SLEEs, 402-1, . . . , 402-P, but rather the multiple SLEEs, 402-1, . . . , 402-P, provide the connection information as part of the SCF to access user applications, or programs located elsewhere in the network.
As shown in the embodiment of
As shown in
An SLP instance can be created to invoke a specialized resource function (SRF) as the same has been described above. Generally, when a SLP instance, e.g., 518, 524, establishes connection information, it exchanges a transaction ID with the device or network element with which the connection is being formed. These transaction IDs can be included within INAP and/or TCAP protocols, etc., as the same will be known and understood by one of ordinary skill in the art. However, in the case of an SLP instance created to invoke a SRF a different issue arises. By its very nature the SRF is intended to start a new dialog altogether with another network resource. As such, the SRF starts a new message transaction with its own associated transaction ID with that other network resource. Hence, when SRF messages are returned to the SLEE, they do not contain the same transaction ID as the invoking SLP instance. Without more of an identifier in a multi-SLEE environment, the receiving SLEE will simply create a new SLP instance to handle the SRF and thus expending memory resources.
Program embodiments of the present invention provide a solution to this issue by executing to save SLEE instance information to a memory associated with the SLEE when a service logic program (SLP) instance is created to invoke a specialized resource function (SRF). Further program embodiments execute to use a dispatcher to perform a look up of the SLEE information in memory when a message is returned from a SRF. The SLEE instance information includes a correlation identifier (ID) representative of a particular SLEE (e.g., particular SLEE within a multi-SLEE) and representative of the particular SLP instance in that SLEE that invoked the SRF. Program embodiments execute instructions such that if a correlation ID received in a return SRF message matches the correlation ID of a SLEE instance found by the dispatcher the SRF dialog can be forwarded to the invoking SLP instance. Thus, in a multi-SLEE environment, rather than having to create a new SLP instance each time a new SRF dialog is received, when a SLEE instance match is found, a SLP instance can be conserved.
As one of ordinary skill in the art will understand upon reading this disclosure, embodiments of the invention can be performed by software and/or firmware, application modules, e.g., computer executable instructions, operable on the systems and devices shown herein or otherwise. The invention, however, is not limited to any particular operating system environment or to software and/or firmware written in a particular programming language. Software, firmware, and application modules, suitable for carrying out embodiments of the present invention, can be resident in one or more devices or locations or in several locations in a distributed network. And, as mentioned above, a given SLEE 502 will have processor and memory resources assigned to it as the same are known and understood by one of ordinary skill in the art.
To achieve the above described solution, various program embodiments execute instructions to construct a correlation ID as a variable length bit string implemented in one or more octets. As mentioned above, an octet represents a byte, or 8 bits of data, presented as a pair of hexadecimal values. Each hexadecimal value can represent a numerical value. The part of the variable length bit string representative of a particular SLEE can be composed of a numerical identifier value assigned to a particular SLEE when the SLEE was created by the O-SLP in the multi-SLEE environment. This numerical identifier value can be stored in memory associated with the SLEE in a look up table, as the same are known, and can be accessed by executing program instructions. Further, the part of the variable length bit string representative of the particular SLP instance in that SLEE that invoked the SRF can be composed of a numerical identifier value assigned to each SLP instance created in the SLEE to invoke a SRF. As each new SLP instance is created in the SLEE to invoke a SRF, the program instructions can execute to combine these two values as a unique correlation ID and save the same to memory associated with the particular SLEE.
According to various embodiments, program embodiments additionally execute instructions such that when a SLP instance is created to invoke a SRF, the correlation ID, as described above, is transmitted to the SRF in part with invoking the SRF. Instructions are provided in connection with invoking the SRF instructing the SRF to return the correlation ID in a message back to the multi-SLEE. That is, program embodiments execute to instruct the SRF that once the SRF begins a SRF dialog it is to return the correlation ID in a message to the multi-SLEE.
As part of a SRF dialog messages are exchanged with a dispatcher in a SLEE environment providing a service control function (SCF) in association with a service control point (SCP) in the above described networks. In a multi-SLEE environment, however, the dispatcher receiving this return message may or may not be contained in the SLEE having the invoking SLP. Embodiments of the present invention allow the dispatcher to check if it does.
According to the various embodiments, program instructions execute using the SLEE dispatcher which received the return SRF message, e.g., the return message having the correlation ID, to look up the SLEE instance of each invoking SLP in memory associated with that SLEE in reference to the correlation ID in the message. Program embodiments execute instructions such that if a correlation ID received in a return SRF dialog message from an invoked SRF matches with a correlation ID of a SLEE instance found by the dispatcher then the SRF dialog can be forwarded to the invoking SLP instance, as illustrated generally at 530. If the correlation ID does not match with a correlation ID in memory associated with the SLEE, then the SLEE can create a new SLP instance to handle the SRF dialog. One of ordinary skill in the art will appreciate the manner in which program instructions can execute to forward the SRF dialog to the invoking SLP instance when a match is found. Further detail relating to the same is not provided here so as not to obscure embodiments of the invention.
Thus, in a multi-SLEE environment, rather than having to create a new SLP instance each time a new SRF dialog is received, when a SLEE instance match is found, a SLP instance can be conserved. By virtue of the various embodiments described herein, the number of SLP instances employed to handle a session, e.g., message exchange/dialog, can be reduced. If the SRF dialog is controlled by the same SLEE that contains the invoking SLP instance, the dialog is forwarded to the existing SLP instance rather than creating a new SLP instance. The reader will appreciate that a conservation of SLP instances conserves memory and thus allows more instances to handle more sessions on identical hardware.
Parlay web services 630 are intended to 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 web services 630 can include Parlay APIs (not shown) which are designed to enable creation of telephony applications as well as to enable information technology applications.
Parlay web 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 multi-SLEE embodiments described herein, can be performed using an extensible markup language (XML) based message exchange through the high speed bus 601. Parlay web 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 web services 630, and/or other service application layers 640, can interact with an SS7 network including the use of a service control function (SCF) in a service control point (SCP), having a multi-SLEE environment according to the embodiments described above.
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.
