Patent Application
20060123431
Intelligent networks (INs) are being used to provide an increasing number of services to communication networks. INs deliver these services to a number of wireline and wireless 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 physical switches when a new service is introduced. For example, in a publicly switched telephone network (PSTN) a physical circuit based switch 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. INs can provide enhanced voice, video, and data services and dynamic routing capabilities by using a number of different program switches. In both INs and the PSTN, the actual voice call can be transmitted over a circuit-switched network, but the signaling, e.g., control signal transmission, can be accomplished by executing program instructions on a separate SS7 packet-switched network.
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 (SCGs), or other service capability server (SCS), etc., as the same are known and understood by one of ordinary skill in the art. The data exchanged between an originating switch and, for example, a SCG is commonly formatted into intelligent network application part (INAP) messages and communicated between these network elements using a transaction capabilities application part (TCAP) messages. INAP and TCAP are examples of protocol layers within the SS7 protocol architecture. At the end of the exchange of INAP messages 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. 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.
Service logic programs (SLPs) are used in telecommunication networks to handle sessions, e.g., message exchanges, between various requested services on a network. For example, SLPs can operate in a service logic execution environment (SLEE) to provide a service control function (SCF) within a network device, e.g., a service control point (SCP). As processor and memory capabilities have increased, it has become possible to facilitate multiple SLEEs (multi-SLEEs) on a given network device. The number of SLEEs in a multi-SLEE environment is associated with the amount of processing resources available, e.g., number of processors (CPUs), on a given network device. Each SLEE is generally assigned to a particular processor, however, multiple SLEEs can be assigned to one processor and the associated memory allocated to that particular processor.
SLPs are instantiated in a SLEE to execute instructions to perform various functions. Generally, the term “instance” refers to a running program, and is used in programming parlance to refer to a process running in user space. A process refers to a running program which has a state and may have an input and output. Each process has one or more threads. A thread is an executable set of instructions being executed on a processor. An SLP “instance” can also be referred to as a user level thread for a user level program, e.g., SLP as opposed to a kernel or operating system program. “To instantiate”, or “instantiating”, an SLP means creating or launching a particular SLP instance.
A SLP may be instantiated in a given SLEE to handle a session with a service application on the network. A different SLP may be instantiated to invoke and/or control the operation of another device on the network, e.g., an intelligent peripheral (IP) having a specialized resource function (SRF) (discussed below). Previously, in single SLEE environments, the SLP handling a session was also the same SLP responsible for invoking other network resources, e.g., SRFs, and as such was provided with control over the operations of such IPs. In more modern INs more of the session control has been allocated, or provided to, the network applications, e.g., Parlay applications, residing elsewhere on the network, and not with the SLP instance in the SLEE. Control instructions are exchanged with SLEE via network messages through an SCG and/or SCS, for example. Parlay web services are one of a development tool which can accommodate the development of next generation telecommunication network applications. 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. A Parlay application, or other network application, can generate a call, e.g. has the capability to initiate a call session to a particular called number. In such cases a SRF may be used to collect the digits of the called number, etc.
In a multi-SLEE, different SLPs may be used for handling a session with a network application and for controlling a SRF. The different SLPs may even be in different SLEEs altogether. A SLP handling a session with a network application should be able to communicate with a SLP handling another network device associated with or being used by that network application. However, in situations where much of the session control instructions are provided to a network application located elsewhere in the network, one SLP may be instantiated to handle a session with a network application and another SLP be instantiated to control a requested SRF. In such cases, the SLP handling the session with the network application may not have a direct communication connection to a SLP controlling the SRF (also referred to as a “SRF SLP instance”) even though the SRF invoked on behalf of the network application. For example, when a network application requests a SRF, a first SLP handling the session with the network application can launch a new, second SLP, possibly in another SLEE, to invoke the SRF. In this scenario, the first SLP connected to the network application will not have control over the second SLP invoking the SRF. In this multi-SLEE environment the second SLP may not have any communication connection with the first SLP connected to the network application. Thus, messages exchanged between the network application and the SLP connected thereto are not communicated, or forwarded, to the SRF SLP instance.
Embodiments of the present invention cover networks, methods, and devices, etc., for SLP instance (SLPi) connections. For example, a network device is provided including a processor coupled to a memory. Program instructions are provided, storable in the memory and executable by the processor, to instantiate a first SLP to handle a session with a Parlay application. The program instructions can execute to instantiate a second SLP to handle a specialized resource function (SRF) for use with the Parlay application. The program instructions are executable to forward a correlation ID from the first SLP to the second SLP and establish an inter-process communication (IPC) connection between the second SLP and the first SLP based on the correlation ID. Thus, in this embodiment, the program instructions are executable to receive Parlay application messages to the first SLP, forward the messages between the first SLP and the second SLP, terminate the second SLP when the a connection to the SRF is complete, and continue to execute the first SLP to continue handling the session with the Parlay application.
Method embodiments are provided for managing SLPis in a multiple service logic execution environment (multi-SLEE). One method embodiment for SLP instance connection includes instantiating a first SLP to handle a session with a network based application. A second SLP is instantiated to handle an intelligent peripheral (IP) for use with the network based application. The method includes establishing a communication connection between the second SLP and the first SLP such that messages exchanged between the network application and the first SLP can also be exchanged with the second SLP handling the IP dialog.
Example of Communications Network
Wireless networks 100 include one or more mobile switching centers (MSCs). For example,
A MSC 112/126 is a telephone switch specialized for wireless and mobility support. 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 to the mobile device 134 according to various interface protocol standards, e.g., according to an american national standards institute (ANSI), a global systems for mobile (GSM), or other standards interface, etc.
In the embodiment of
As illustrated in the exemplary network of
A SCP 120 is used to handle the message exchange, e.g., session, between devices 134 and/or applications 150. That is, the SCP 120 can receive a service request from a mobile device 134 or wireline device (e.g., through the PSTN 110) via the GMSC 116 or SMSC 126. The SCP 120 can then instantiate a program, e.g., an SLP, to handle a subsequent message exchange with a service control gateway (SCG) 140-1 (shown connected to the Internet 152) and/or service capability server (SCS) 140-M (shown connected to other network applications 150), etc. Both SCG 1401-1 and SCS 140-M can serve as gateways as the same are known and understood in the art. The designator “M” is used to indicate that a given SCP 120 may handle message exchanges, or sessions, with a number of different network entities, whether SCSs or otherwise. That is, a SCG 140-1 and/or SCS 140-M can also provide access to other network functionality such as network service applications (e.g., web-based Parlay applications through the Internet 152), home location registers (HLRs), visiting location register (VLRs), etc. For example, a SCG 140-1 and/or SCS 140-M may be used to communicate a service request for a web service provided by a Parlay application. One of ordinary skill in the art will appreciate that a Parlay application, or other network application, can generate a call, e.g., has the capability to initiate a call session to a particular called number. More detail is not provided here so as not to obscure embodiments of the present application.
Parlay web services are one example of a development tool which can accommodate the development of next generation telecommunication network applications. 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.
Embodiments of the invention include program instructions which can instantiate a first SLP in a SLEE to handle a session, e.g., message exchange, with a Parlay application. For example, a Parlay application may initiate a call session on a telecommunications network. While the first SLP will handle the message exchange, the control resides with the Parlay application. In this example, a call initiated by the Parlay application will further employ the use of a SRF (discussed more in connection with
Each of the physical components of the network 100 can include access to processor and memory resources, as the same are known and understood in the art. Such memory resources can include SLPs executable by the processor resources in a SLEE to handle a message exchange with the Parlay application and can include SLPs executable to invoke a SRF. The network example of
Exemplary Mapping of Functional Entities to Physical Entities
Program instructions, e.g., computer executable instructions, within a network, can be broken down into particular functions (also referred to as functional entities (FEs)), associated with hardware including processor and memory resources, serving as SSPs and SCPs, as illustrated in
The physical component of an SSP 201 provides stored program instruction control switches that interface to the SS7 signaling network 200. The SS7 network 200 includes signal transfer points (STPs) (not shown) as the same are known in the art. The SSP 201 includes software executable to perform a call control function (CCF) 202, and software executable to perform a service switching function (SSF) 203. The physical component of an SSP 201 can associate with the FEs of a CCF and SSF in a distributed manner, e.g., the software is distributed across multiple network computers such as in a local area network (LAN), a wide area network (WAN), and/or the Internet. Generally, a CCF includes executable instructions to control call processing and provides network connection services. An SSF includes executable instructions to support IN triggering during call processing and to access to IN functionality. The SSF recognizes IN service calls and routes the appropriate queries to a service control function (SCF) (discussed below) that resides in a SCP via the SS7 network through STPs.
The SSP 201 can also include software executable to perform a SRF 204 and software executable to perform a call control agent function (CCAF) 205. The SRF 204 includes executable instructions to support interaction between call processing software on the switch, e.g., SSP 201, and a SCF. The CCAF 205 includes executable instructions to support specialized network resources generally associated with caller interaction and to provide user access to the network.
The physical component of an SCP 206 provides stored program commands, e.g., computer executable instructions, which 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. The SCP 206 includes software executable to perform a SCF 208 and can include software executable to perform a service data function (SDF) 210. The SCF 208 includes instructions to execute IN service logic and influence call processing on the switch, e.g., SSP 201, via its interface to the SSF 204 through the SS7 network 200.
The physical component of a service management point (SMP) 212 provides operation, administration, and maintenance functions for the IN. The physical component of an SMP 212 includes the 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 216 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 mentioned above and 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 those afforded through a Parlay application. 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 discussed below, the SCF 208 can be implemented by SLPs executing in a SLEE. The SRF 220 is coupled to the SCP 206 through the SS7 network 200 and possibly relayed by an SSP 201.
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, which includes instructions to manage customer and network data for real-time access by the SCF 208 in the execution of an IN service.
As noted above, 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. The INAP is used to define 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,
Example of Multi-SLEE Including Program Embodiments
The plug-in container 306 and SLEE can be provided as part of a service control function (SCF) in a SCP and/or as part of a SCG or SCS as shown in
Instances of one or more SLPs 304 can be created and executed within a SLEE (e.g., in response to a service request received to an SCP, SCS, SCG, etc., from a SSP as shown in
According to embodiments of the present invention, a dispatcher program 316 is provided to the plug-in container 306. The dispatcher program 316 includes instructions which can execute to identify the signal's source, e.g., from a particular network application and/or device. For example, 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. The point code or signaling source information may be extracted from a TCAP message or via other techniques as the same are known and understood in the art. As noted above, TCAP is the layer within the SS7 protocol that is used to communicate between IN elements, e.g., switching points/centers, control points, end points, etc. That is, TCAP protocol is used to communicate messages between different entities such as databases and end stations. For example, TCAP messages are typically used for communication between SSPs and SCPs within a communication network or between networks. The TCAP and/or other layer in the SS7 architecture contain “called number” information and/or “session type”. One of ordinary skill in the art will appreciate the manner in which program instructions can execute to identify and extract a called number (or portion thereof) and/or a session type from a TCAP and/or other SS7 layer message, e.g., a called number may be extracted from a MAP message. More detail is not provided here so as not to obscure embodiments of the present invention.
The various SLPs 304 within the SLEEs, 302-1, . . . , 302-P, provide connection information, message exchanges, etc., for accessing user space network applications, such as the web-based Parlay application in the example above, which are located elsewhere in a network and coupled to the SLEEs, 302-1, . . . , 302-P, via the bus 301 and the plug-in container 306. The application logic, e.g., control, for these other network applications is generally not contained in the SLEEs, 302-1, . . . , 302-P. The SLPs 304 in the SLEEs, 302-1, . . . , 302-P, however, do provide the connection information, and session handling (e.g., exchange messages for calls and services) as part of the SCF to access the application logic for user applications wherever they may be located in the network. Various SLPs 304 may also be used to handle operations with IPs. In other words, certain SLPs 304 can be written by a program developer, stored in memory, and executed as part of a SLEE, to handle network application sessions. Further, other SLPs 304 can be written by a program developer, stored in memory, and executed as part of a SLEE for invoking a SRF or other network function, as the same have been described in connection with
Operational Embodiments of a SLEE having SLP Instances Connected
An operational service logic program (O-SLP) 410 can execute instructions to startup and shutdown the SLEE 402 environment. The SLEE 402 can receive instructions to spawn, e.g., create other SLPis as illustrated at 412. Upon startup, the O-SLP will create a SLEE dispatcher 414 which itself is an SLP. When an SLP instance begins 412 it communicates with the dispatcher SLP 414. SLPs can instantiate other SLPs, e.g., 418 and 424 as shown by arrows 430. By way of example, and not by way of limitation, a SLP handling a network application may receive a message that a network application wants the use of another network component, e.g., an IP having a SRF. As mentioned above, a SRF includes executable instructions to support specialized network resources generally associated with caller interaction with the IN and can also manage resources such as announcements, speech recognition, digit collection, protocol conversions, etc. In such an example, a first SLP handling a session with the network application will execute instructions to instantiate a second SLP to invoke the SRF and to control the operation thereof through a message exchange between the second SLP and the SRF. In the case of a network application session (e.g., where the control logic is with the network application itself and not with the first SLP which instantiated the second SLP to invoke the SRF) the network application will want to communicate with the SLP instance having control of the SRF, e.g., in this example the second SLP.
To achieve the same, program embodiments of the present invention are provided to the SLEE (e.g., storable in memory and executable by a processor as shown in
Program embodiments, provided to the SLEE, execute instructions to construct a correlation ID as a variable length bit string implemented in one or more octets to identify a particular SLEE and a particular SLP. 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 which instantiates another SLP within the SLEE to invoke a SRF. When a SLP instance is created in the SLEE to invoke a SRF (e.g., a first SLP instantiating a second to invoke a SRF), the program instructions can execute to combine the two above described values as a unique correlation ID and save the same to memory associated with the particular SLEE.
According to various embodiments, program instructions additionally execute instructions such that when one SLP instantiates another SLP instance 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. That is, 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. Correlation IDs are first received by a plug-in container 406 associated with the multi-SLEE as part of a SCG or SCS as described above in connection with
The example embodiment of
By communicating with the channel context state table 422, the dispatcher 414 can additionally identify which SLP instances, for example, SLPis 424 and 418, have been assigned to which particular channels 420. The dispatcher in the plug-in container 406 and the SLEE dispatcher 414 both execute instruction to communicate and exchange information. The SLEE dispatcher 414 can receive and process a request to establish a connection between a first SLP handling a session with a network application and a second SLP controlling a SRF being used for that application based on the information returned in the correlation ID. The socket interface 408 will execute instructions to use a given channel 420 for an appropriate SLP instance identified by the SLEE dispatcher 414, e.g., to connect with the first SLP. That is, the socket interface will receive instructions from the SLEE dispatcher 414 and will execute instructions to use a given channel 420 as an IPC between a first SLP handling a session with a network application and a second SLP controlling a SRF being used for that application.
According to the various embodiments, program instructions execute using the plug-in dispatcher (e.g., dispatcher 316 in
As 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.
