Patent Application
20100232417
The present invention relates to the field of mobile communications and, more particularly, to moving service control within a mobile telephony service provider network from a channel access domain to an IP domain.
Convergence has long been a goal in telecommunications, where fixed resources (e.g., a communication infrastructure) are highly leveraged to provide multiple differentiated services, which were previously distinct from each other. Convergence ideally benefits both end-users and service providers as it lowers overall costs for services while expanding markets that a service provider can penetrate. Two terms often associated with convergence include a triple play (providing fixed telephony, mobile telephony and fixed-line internet services) and a quadruple play, which adds television services to a triple play. It is not uncommon for telecommunication, internet, and other companies to form cooperative agreements in order to provide triple and quadruple play services to end customers.
One problem with conventional converged telecommunication services relates to the level of integration among different services. At present, most service providers loosely integrate different types of services. For example, fixed telephony services are associated with one phone number, mobile telephony services are associated with a different telephone number, fixed internet are associated with a discrete URL, etc. These services fail to interact cooperatively from an end user viewpoint, meaning that in absence of explicit call forwarding that has been manually established by a user, an incoming call to a disabled mobile phone is not transferred to the fixed line phone and vice versa. Further, settings and knowledge relating to a user via one of the services (e.g., a presence detection service, a calendar system, and the like) are not leveraged by other services to facilitate seamless communication across different service boundaries. Customers increasingly desire their communication assets join into a ubiquitous whole, where a user can choose a communication technology most suitable for a given situation (e.g., telephony calling, PTT communication, IMing, Text Messaging, co-browsing, media or file sharing, etc.), and can use this communication technology to communicate with a set of selected people.
Before different services can be integrated seamlessly at low levels, tighter integration of communication environment assets than presently exists is needed. This is especially true regarding integration of fixed network assets (internet, fixed telephony) and mobile network assets (mobile telephony towers, base stations, and the like). More specifically, today's mobile voice services provided by mobile telephony infrastructure assets are provided as 2G services (TDMA, CDMA, GSM) that do not directly integrate with IP technologies, such as SIP or VOIP, at lower levels. Thus, advanced features of an advanced intelligent network (AIN) are unavailable. The current limitations largely relate to a manner in which service call control is handled. Basically, it is presently difficult to move a mobile telephony session from a 2G channel accessed telephony domain (TDMA, CDMA, GSM, etc.) to an IP domain.
Current solutions to communications to an IP domain all have substantial drawbacks. In some instances, for example, tighter integration has been achieved through use of proprietary techniques and protocol extensions. These, however, are of limited utility as the proprietary extensions, which are not supported by other providers, become unavailable when a communication extends beyond the infrastructure assets of a single provider. Further, in the rapidly changing space of telecommunications, proprietary techniques are often hard to maintain and to integrate with emerging protocols, infrastructure improvements, and communication standards.
Other solutions require customers to purchase and use IP-PBX equipment. Use of IP-PBX equipment can be expensive, can result in customer experienced lock-in, can degrade service quality (when excessive analog to digital conversions occur). Further, IP-PBX equipment use is inherently limiting in mobile communication situations, as users of mobile devices connect to a provider's network from different geographic locations (as opposed to always connecting first to IP-PBX equipment, which converts communications to the IP domain, and then connects to the provider's network.)
The present solution achieves integration between mobile telephony infrastructure assets and an IP based enterprise infrastructure through use of standards based interfaces that do not require any premise based IP-PBX. In one embodiment, the solution can move service control for specific numbers from a mobile switching center to a higher network element, such as a media gateway controller (MGC). The MGC can then be used to bridge SS7 signaling understood by a class five switch in the MSC to SIP. Thus, a call is moved from a channel access (TDMS, CDMA, GSM) domain to an IP domain, where the IP Media System (IMS) core can provide signaling and routing for a call.
Any voice application can be registered using this approach, which makes the disclosed solution a highly flexible and general purpose one. It should be appreciated that in various embodiments, the integration provided by the disclosed solution can enable notification of incoming calls, call routing, presence, location, call history, and a use of more advanced services (e.g., dynamic, real-time text-to-speech and speech-to-text conversions between typed messages at one communication endpoint and voice communication at another communication endpoint, dynamic language translations, transcription services, call routing based upon a detected user current location, etc.).
As will be appreciated by one skilled in the art, the present invention may be embodied as a system, method or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.
Any combination of one or more computer usable or computer readable medium(s) may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CDROM), an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, for instance, via optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc.
Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
Passing call control to the IMS core can allow the provider network to identify an application in the SIP registry associated with a particular endpoint (e.g., phone number). That is, any voice application (SIP based) can be registered in this manner and can therefore be automatically executed when previously designated circumstances are satisfied. In one embodiment, the voice application can be a premise based SAMETIME UNIFIED TELEPHONY server from IBM. In other embodiments, the voice application can be another unified telephony solution, a cloud based solution (e.g., GOOGLE's GRAND CENTRAL), or a sophisticated call center application.
As illustrated, method 100 can begin in step 105, where at least one SIP application can be registered with a SIP registry of a mobile telephony service provider network. In one embodiment, the provider network can be Wireless Intelligent Network (WIN) compliant network. Registered SIP applications can be logically related (e.g., via database associations) with a set of phone numbers, as shown by step 110. These phone numbers can include mobile phone numbers handled by the provider network.
The provider network can receive a communication attempt in step 115. One endpoint of the communication attempt can correspond to a phone number in the SIP registry. In step 120, a determination can be made to ascertain whether the domain of the communication needs to be changed. That is, the communication can be initially for the IP domain, in which case no conversion is necessary, as shown by the method selectively skipping from step 120 to step 140.
When the communication is in the channel access domain or otherwise needs converted, a previously established trigger, such as a WIN trigger, can execute, as shown by step 125. In step 130, responsive to the trigger execution, service control can be moved from a mobile switching controller (MSC) to a media gateway controller (MGC). In step 135, communications can occur between the MGC and the IMS core, where the IMS core provides signaling and routing functionality for the communication attempt.
In step 140, the IMS core can query a SIP registry for SIP applications applicable to the communication attempt. When an application is found, a SIP communication can be established between the IMS core and a remote location (e.g., an enterprise) associated with the SIP application, as shown by step 145. In step 150, the SIP application can execute in the application environment. Results from this execution can be conveyed to the IMS core over the SIP communication, as shown by step 155.
In step 160, the IMS core can process the execution result, which can change signaling and/or routing behavior of the communication attempt. In step 165, a communication session can be established in accordance with the changes submitted to the IMS core.
It should be appreciated, that integrating a users mobile phone via the WIN network can add a myriad of functionality, which is not typically available to mobile telephony subscribers for 2G communications (e.g., channel access based calls). By moving call control to the IP domain as described, numerous functional enhancements can be realized. For example, subscribers can be notified of incoming calls and call details when engaged in a voice call, calls directed to mobile phones can be routed, presence features can be enabled, and advanced services (e.g., Web services) can be enabled. An example of an advanced service can include adding speech processing (e.g., text-to-speech, speech-to-text, speaker identification and verification (SIV), etc.) capabilities to a mobile telephony communication.
As shown, the provider environment 210 can be connected to a Web service environment 240 and an enterprise environment 230 through an IP network 250. Communications handled by the IMS core 216 can make use of zero or more Web services 242 executing in environment 240 and zero or more SIP applications 232 executing in the enterprise environment 230. A SIP registry 218 can associate device 226 identifiers with the applications 232 and services 242.
The provider environment 210 can be a mobile telephony service provider's network supporting 2G, 2.5G, 3G, 4G (Beyond 3G), etc. wireless communications. The provider environment 210 can be communicatively linked to the public switched telephone network (PSTN) 252, which permits communications with devices 226 linked to the PSTN 252. Environment 210 can be capable of channel accessed based wireless communications involving one or more base transceiver station 220 wirelessly linked to a mobile station (e.g., device 225). In one contemplated embodiment, the provider environment 210 can be a Wireless Intelligent Network (WIN) compliant one or can be compliant to another such standard.
A channel accessed wireless communication is one that permits several mobile stations connected to the same multi-point EM spectrum to transmit over it and to share its capacity. Channel access wireless communication techniques can utilize numerous schemes including those based on time division multiple access (TDMA) techniques, code division multiple access (CDMA) techniques, frequency division multiple accessed (FDMA) techniques, and/or space division multiple access (SDMA). Hybrid communication schemes (e.g., Global System for Mobile communications (GSM), those based upon the IEEE 802.XX family of protocols— including WLAN and WIMAX, etc.) can be supported by the provider environment 210. Environment 210 can further support circuit based voice communications (e.g., TDMA, GSM, etc.) and packet based ones (e.g., Evolution-Data Optimized (EVDO), Voice over Internet Protocol (VOIP), etc.).
As shown, provider environment 210 can include an MSC 212 component, a MGC component 214, an IMS core component 216, a SIP registry 218, and one or more base transceiver station 220. Additional components (not shown) can be included in the environment 210, yet have been excluded in
The MSC 212 component can be a primary service delivery node for 2G mobile calls. The MSC 212 can be typically responsible for handling voice calls and SMS, as well as other services, such as conference calls, FAX, and circuit switched data. The MSC 212 can set up and release the end-to-end connection, can handle mobility and hand-over requirements during the call, and can take care of charging and real time pre-paid account monitoring.
Trigger 222 can be a programmatic trigger that automatically moves service control from the MSC 212 to the MGC 214. For example in one embodiment, trigger 222 can be a WIN trigger conforming to the WIN call model. The trigger 222 can be a decision point in a call. Specifically, trigger 222 can be designed to move calls from a wireless channel access (2G) domain to an IP domain. This occurs without hosting calls on a premise based IP-PBX.
The MGC component 214 can function as a translation unit between disparate telecommunication networks, such as PSTN, SS7, TDMA, GSM, CDMA, and the like. The MGC 214 can convert (e.g., transcode) between different transmission and coding techniques.
The IMS core component 216 can be a core component for delivering Internet protocol (IP) multimedia services. The IMS core 216 together with the MGC can provide signaling and routing functionality. The IMS core 216 can include a number of Call Session Control Function (CSCF) proxies, such as a Proxy-CSCF (P-CSCF), a Serving-CSCF (S-CSCF), and an Interrogating-CSCF (I-CSCF).
The SIP registry 218 can be implemented as a master user database. Thus, the SIP registry can be implemented within a home subscriber server (HSS), a user profile server function (UPSF), a Home Location Register (HLR), or even a Visitor Local Register (VLR). The SIP registry 218, when associated with a HLR or VLR, can be used in conjunction with an authentication center (AUC).
One specific embodiment 300 of a provider environment 210 is shown in
In embodiment 300, an IMS core 320 can deliver IP media services, which include voice services which have been moved from the MSC 334 to the MGC 336. A session border controller (SBC) 314, 340 can exert control over media streams and can be involved in setting up, conducting, and tearing down calls. A service delivery platform (SDP) 342 can be a set of components that provide a service delivery architecture (e.g., service creation, session control, protocols) for a type of service. The SDP 342 can be used to enable externally provided Web services (the Web services 242 of system 200 for example).
Embodiment 300 supports multiple different communication protocols including WIMAX, EVDO, and TDMA, each of which can be associated with its own set of base transceiver stations 310, 320, 330 and base station controllers. WIMAX communications can be conducted through an access service network (ASN) component 312. EVDO communications can be conducted through a public data switched network (PDSN) component 322. Channel based, circuit switched (e.g., TDMA) communications can include an integrated services control point (ISCP) communicatively linked to the MSC 334.
One specific embodiment 400 of an enterprise environment 230 is shown in
In embodiment 400, a telephony control server 420 can interface over an IP network (e.g., network 250) with a provider network (such as with IMS core 216). Interactions can be conducted through a PBX abstraction layer 422, which includes a SIP Back-To-Back User Agent (SIP B2BUA) 424 and a CSTA user agent 426.
The telephony control server 420 can interface with telephony application server 410, which can interface with both the SAMETIME server 430 and a softphone 444 of a SAMETIME client 440. The SAMETIME client 440 can also include telephony plug-ins 442.
In one implementation, the inventive arrangements disclosed here permit a mobile telephony subscriber to have a unified experience in that calls directed to/from a mobile phone number are able to be handled in a same manner as land-based calls. Historically, this required a premise based PBX, a costly wireless integration service (e.g., AVAYA WIRELESS INTEGRATION), or proprietary non-standards based solution programming that was generally highly limited. Combining embodiment 300 and 400, a wireless service provider network is directly integrated into an enterprise environment, with call control functionality occurring within the mobile telephony network. Thus, a SPRINT network (embodiment 300) can be integrated into a unified communication (U2) enterprise environment (embodiment 400) to produce a U3 environment, which is an integration of UC2 and wireless telephony.
Capabilities realizable by the present disclosure can be described utilizing a set of use cases. In one use case, a telephony call can be initiated directed to John, who receives UC3 services. The call is directed to John's mobile telephony number. The call attempt is initially directed to the wireless provider's network. Before ringing any phone, the mobile provider via IMS services informs the UC2 application executing within an enterprise of the call attempt (including caller ID). The UC2 application can look up John's schedule, calendar, and presence information, which along with the caller ID determines where to route the incoming call. Because John is logged onto SAMETIME at his home office and is available, the UC2 can inform the service provider that the call should be redirected to John's home phone number. In this use case, it should be noted that the call attempt was redirected, not answered and forwarded. Additionally, no enterprise telephony resource is required in the above use case.
In another use case, John can be participating in a conference call using his mobile phone. A call can be initiated from Jane, which is directed to John's mobile telephony number. Jane's call attempt can be conveyed to the mobile provider's network, where the IMS services communicate with the UC2 application executing in the enterprise environment. The UC2 application can check John's schedule, calendar, presence, and caller ID. Because John is currently in a meeting, the call can be routed to Voice Mail by default. John's mobile phone can include a UC3 application that shows incoming calls and offers a number of options relating to them. John, who may be almost done with the conference call, can elect to type a message (using text messaging capabilities of his mobile phone) for Jane, such as “In a meeting be done in 5 min. I'll call you.” The message can be conveyed to the provider network, where speech-to-text conversion occurs (through a Web service, for example) and the message is played to Jane over a voice phone connection. When John finishes his conference call, the U3C application on the mobile phone can initiate the call with Jane. While John and Jane are talking, a question can arise that Sue knows the answer to. John can start a SAMETIME chat with Sue during which he determines that Sue should join the call. From the SAMETIME chat window, John can select to add Sue to the call.
Diagram 520 is a network/flow diagram for a call coming in on a TDMA 522 circuit, which is routed to a home office phone. When the TDMA call 522 attempt is received by the provider, it is routed through the MSC to a MGC, where it is converted to the IP domain. A SIP channel 524 is established between the provider and an enterprise. The enterprise can communicate over the SIP channel 524, conveying results that potentially alter routing and/or signaling of the call. This call is established between the mobile phone and the phone office phone that is linked to the Public Switched Telephone Network (PSTN).
Diagram 540 uses Web services and SIPS rather than a virtual private network (VPN) for presences and SIP signal flowing. In diagram 540, the TDMA 542 call attempt is received by the provider, where it is routed through the MSC, to the MGC, to the IMS core, to a SDP. The SDP can communicate with one or more Web services. Each executing Web service can communicate with the enterprise over a SOAP connection 548. The SDP can communicate through a SBC with enterprise over a SIP connection 544. The call modified by the Web service and/or enterprise application results can be established between the mobile device and a home phone network (connected via PSTN).
In an alternative embodiment, still based on diagram 540, the mobile phone can initiate a communication having a softphone as an endpoint. This can require RTP 546 communications be established between the provider and the enterprise and between (see RTP 547) the enterprise and a softphone.
Diagram 560 shows that the solution works seamlessly across multiple generations of mobile communications and wire-line endpoints. As shown in diagram 560, a 4G device (e.g., WIMAX device) can communicate with the provider using RTP 562. The provider can route the call through a ASN and SBC to the MGC, which can communicate with the IMS core of the provider. The provider can then initiate a SIP 564 communication with the enterprise and can optionally execute a Web service (through a SDP, for example) for the WIMAX call.
The flowchart and block diagrams in the
