Title of Invention	OFFLOADING CALL CONTROL SERVICES ACROSS NETWORKS OF DIFFERENT TYPES
Abstract	Title: METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR OFFLOADING CALL CONTROL SERVICES FROM A FIRST NETWORK OF A FIRST TYPE TO A SECOND NETWORK OF A SECOND TYPE Abstract: Methods, systems, and computer program products for offloading call control services from a first network of a first type (100) to a second network of a second type (102) are disclosed. According to one aspect, a method includes detecting a call originating from a calling party in a first network of a first type. A database (116) may be queried using information identifying the calling party. In response to the query, routing infonnation may be sent for a node in a second network of a second type. Call control services may be offloaded for the call to the second network using the node.

Title of Invention

OFFLOADING CALL CONTROL SERVICES ACROSS NETWORKS OF DIFFERENT TYPES

Abstract

Title: METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR OFFLOADING CALL CONTROL SERVICES FROM A FIRST NETWORK OF A FIRST TYPE TO A SECOND NETWORK OF A SECOND TYPE Abstract: Methods, systems, and computer program products for offloading call control services from a first network of a first type (100) to a second network of a second type (102) are disclosed. According to one aspect, a method includes detecting a call originating from a calling party in a first network of a first type. A database (116) may be queried using information identifying the calling party. In response to the query, routing infonnation may be sent for a node in a second network of a second type. Call control services may be offloaded for the call to the second network using the node.

Full Text	PESCRIPTION METHODS. SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR OFFLOADING CALL CONTROL SERVICES FROM A FIRST NETWORK OF A FIRST TYPE TO A SECOND NETWORK OF A SECOND TYPE RELATED APPLICATIONS This application daims the benefit of U.S. Provisionat Patent Application Serial No. 60/834,103, filed July 26, 2006, and corresponding U.S. Patent Appication (Serial No. not yet assigned) entitled METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR OFFLOADING CALL CONTROL SERVKIES FROM A FIRST NETWORK OF A FIRST TYPE TO A SECOND NETWORK OF A SECOND TYPE, filed July 27,2007. the disclosures of each which are incorporated herein by reference in their entireties. TECHNICAL FIELD The subject matter disclosed herein relates generally to call control services. More particularly, the sutqect matter disckised herein relates to offloading call control services. BACKGROUND Commonly deployed wireless communications networks support both voice and data services. Typically, mobile handsets or mobile subscribers are corviected to a base transceiver station i»ing a radio access network that uses a modulation scheme such as code division muttiple access (CDMA) or global system for mobile communication (GSM). The base transceiver stations are conrtected via fixed links to or>e or rhore base station controners, and the t>ase statton controllers are aggregated into switches called motHle switching centers. Mobile switching centers are connected to the publk; land mobile network / pubHc switched telephone rwtwoik (PLMN / PSTN), typically thiough a gateway switch called the gateway mobile switching center (GMSC). Internet protocol (IP).multimedia subsystem (IMS) is defined by the Third Generation Partnership Project (3GPP) as a mobile network infrastructure that enables the convergence of data, speech, and mobile network technotogy over an IP-based infrastructure. IMS bridges the gap between the existing traditional telecommunrcations technology, such as PSTN, and Internet technology, allowing network operators to offer a standwdized, reusable friatfonn with new, innovative services by enhancing real lime, multimedia mobile services, such as voice services, video telephony, messaging, confererwing. and push services. IMS can be used to pnwtde services for both mobile networks and fixed networks at the same time, providing unk\|ue mixtures of services with transparency to the end-user. IMS is one example of a sassran initiation protocol (SIP)-based network. Another example of a SIP-based network is a next generatkm rtetwork (NGN) network. IMS supports the estabNshment of any type of media sesston (e.g., voice, vkfeo, text, etc.) and provkJes the service creator the ability to cixnbine servk»s in the sarrie session and dynamically modify sessions 'tm ttie fly" (e.g., adding a video component to an existir>g voice session). As a result, rww and innovative user-to-user and muKKiser services become a^ilat>le, such as enhanced voice servkss, vkjeo telephony, chat, push-to-taHi, and multimedia conferencing, aN of w^k:h are based on ttie concept of a muWmedia session. The underlying IMS infrastructure enables mobile IP cxxnmunicatk>n services via its ability to find a user in the network and then to estabPish a session with the user. The key IMS components enabling mobility management are the call sessnn control fuiKrtion (CSCF) and home subscriber server (HSS). The CSCF is essentiatty a proxy, which aids in the setup and management of sesskms and forwards messages between IMS rietworks. The HSS hokls all of Vne key subscriber infomtation and erxables users (or severs) to find axvi communicate with other end users. A wireline or wireless subscnlwr may benefit from the can control services provMed by t»th networks. Sometimes the services operated in the different networks provkled to a subscriber may overlap. For example, an IMS netvrork may provide the same call control senrice as a PSTN or 2G wireless network. In some vistances, it may be advantageous to ofTK>ad call control service from cme network to anottier network of a different type. Exemplary network types Include 2G wireless networks (e.g., Gk>bal System for Mobile Communicafens {G^Jl), Interim Standard - 41 (lS-41)). PubUc Swtched Telephone Network (PSTN), Next Generation Network (NGN), and IMS networks. For example, the services provided by an IMS network may be ctieaper ttian the PSTN. In this case, it would be advantageous to ofrioad call control sennets from the PSTN to the IMS network. Accordirtgly, there exists a need for methods, systems, and computer program products for off)oadir>g call control services from one network to another network of a different type. SUMMARY Acowdlng to one aspect, ttie sutjject matter described herein includes a method for using an originating parly query to offtoad call control ser^ces from a first network of a first type to a second network of a second type. Ttie method includes detecting a call originating from a calling party in a first network of a first type. A database may be queried using information klentifying the calling party. In response to tt>e query, routing information may be for a node in a second network of a second type. Call control ser/ioes may be offloaded for the call to the second network uatng ttie node. BRIEF DESCRIPTION OF THE DRAWINGS Exemplary embodiments of the subject matterwffl now be explair>ed with reference to the accompanying drawings, of whk:h: Figure 1 is a r>etwork diagram of an exemplary system for using an originating party query to offload call control services from a first network of a first type to a second r>etwork of a secorKi type according to an embodiment of Vne sut^ect matter described herein; Figure 2 is a fkiw chart of an exemplary process of using an originating party query to offload call control sendees from a GSM network to an IMS network shown in Figure 1 according to an emt}odiment of the Subject matter described herein; Figure 3 is a network diagram of arrother exemplafy system for using an originating party query to offload call control sen/ices fnsm a GSM network to an IMS network according to an embodiment of the subject matter described herein; Figure 4 is a blocit diagram of an exemplary rwtwork routir\g node including a call control offload (CCO) function according to an embodiment of the subject matter described herein; Figure 5 is a network diagram of an exemplary system for using an originating party query to offload call control services from a GSM r^etwotk to an IMS network according to an embodiment of the subject matter described herein: Figure 6 is a message fkw diagram of an exemplary exchange of messages among a mobile subscriber, a serving mobile switching center (MSC), a CCO functton, an MGC, and IMS network components for using an originating party query to offload caH control sennces frcwn a GSM network to an IMS network accoRfing tothe subject matter described herein; Figure 7 is a network diagram of another exemplary system for using an originating party query to offload call control services from a GSM network to an IMS network according to an emtxxlinrwnt of the subject matter described herein; Figure 8 is a network diagram of yet anottier exemplary system for using an originating party query to offkiad call control servk»s from a GSM network to an IMS network according to an emt>odiment of the subject matter described herein; Figure 9 is a network diagram of yet another exemplary system for using an originating party query to offload call control services from a GSM networtc to an IMS network according to an embodiment of the sut}ject matter described herein; and Figure 10 is a network diagram of another exemplary system for using an originating party query to offload call control servk»s from a GSM network to an IMS network according to an embodiment of the subject matter described herein. DETAILED DESCRIPTION To faoKtate E^ urxterstanding of exemplary embodbnents, many aspects are described In tarms of sequences of actions that tan t>e performed t>y elements of a computer system. For example, it will be recognized that in each of the embodiments, the various actions can be performed by specialized circuits or circuitry (e.g.. discrete logic gates interconnected to perform a specialized ftjnction), t)y program instructions being executed by or>e or n>ore processors, or by a combination of both. Moreover, the sequences of actions can be embodied in any computer-readable medium for use by or in cormection with an instruction execution system, apparatus, or device, such as a computer-based system, processor containing system, or other system that can fetch the instructions from a computer-readable meifium and execute the Instructions. As used herein, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection witti ttie instruction execution system, apparatus, or device. The computer-readable medium can be, for example but not limited to, an ^ele medium can include the followir>g: an electrical connection having or>e or more wires, a portable computer diskette, a rar^om access memory (RAM), a read-onty memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical f%>er, and a portabte compact dtec read-only memory (CDROM). Thus, the subject matter described herein can be embodied in many different forms, and aH such forms are contemplated to be within the scope of what is claimed. Any such form of emtTodiment can t>e referred to herein as logic configured to" perform a described action, or alternatively as "logic thar performs a described action. Methods, systems, and computer program products for using an original party query to offload call control sen/Ices from a first network of a first type to a second network of a second type according to embodiments of ttie si4))ect matter described herein may be implemented in one or more of any suitable network componente or networic devices. For example, the methods, systerm, and computer program products may be implemented in a routing node, a signal transfer point (STP), a router, a switch, a gateway, a media gateway controller, a softswtch. an IMS node with PSTN gateway functionality, an NGN node, a service control point, an appKcatJon server, or other suitable network device. Figure 1 is a network diagr»n fltustrating an ex^nplary system for using an originating party query to offload call control services Uotn a first Twtwork 100 of a first type to a second network 102 of a second type according to an embodiment of the subject matter described herein. In this eicample. networks 100 and 102 are a GSM network and an IMS iwtwork, respectively. Furttier, m this example, the caN is originated by a mobile subscriber device 104. Although Figure 1 itlustrates the offloading of caU cotUrol services from a GSM networtf to an I MS network, those skilled in the art realize that the present sut^ect matter is not Hmtted to the depteted embodiment arKi Is applicable to any system Including networks of different types. Referring to Figure 1, mobile sul>scrit>ef device 104 may be registered with a 2G HLR 106, which maintains authentication and registration information associated with mobile subscriber devioe 104 and otherfnobile &ub&crit>ers. Further, for example, HLR 106 may store service profile, locatkin infomialion, and activity status of mobile subscriber device 104. Duringoperation.mobilesubscTitwr device 104maybe assigned to a serving MSC 108. which may provkle telephony switching services and mc^ility functions. Mobile subscriber device 104 may be any suitable wireless commurncations device for performing calling tuncttons. such as a mobile phone and a smartphorw. In this example, mobile subscritKr device 104 Is a 2G phone capable of operating in GSM network 100. When operating within GSM network 100, call contrd services for mobile subscriber device 104 may be offloaded from GSM network 100 to an IMS serving - call session control function (S^SCF) 110 in accordance with the subject matter described herein. MSC 108 may download initial detection point (IDP) trigger infomnation from HLR 106 for detecting can orlglnatbn attempts from GSM network 100. In particular, MSC 108 maydownk}ad and store an IDP trigger for detecting when a call originates from mobfe Bubscritier device 104, the calling party for the call, while In GSM network 100. An example of triggering Information may Include an kJentifier for mobile subscriber device 104 that Es contained in a received call attempt message. MSC 108 may trigger on detectkm of the triggering infonnation in a received call attempt message 117. After triggering based on the call attempt by mobile subscriber device 104, MSC108 may communicate a query message to an STP 112. Iho query message may be a TCAP Info-Analyzed message that contains the identifier for the caiiing rrwbite subscriber device 104. In one embodiment, the query nrtes&age may t>e simiter to a number portabifty query message, where the query message includes caiiing party Identtfler Information instead of or in addition to caNed party identifier infonnation. The query nwssage may be sent for requestkig a routing number for a node in IMS networtt 102 that may be used to provide call control services for the call. STP 112 may include a caH control offload (CCO) ftjnction 114 for offloading call control services from GSM network 100 to IMS netwoik 102. In particular, STP 112 may receive from MSC 108 the query message contatntng an Identifer for calling mobile subscriier device 104. In response to receiving the query message. CCO function 114 may query a CCO database 116 for routing information using the caiiing party identifier information. In response to the query, function 114 may ob^in routing information for a rK>de in tMS network 102 ttiat is operable to provide call control senrices for the call. Exemplary roufing information indudes a )oca\ roufing nund)er (LRN), a network entity address, an MSC address, a Gateway MSC address, a Gateway rcHJttng node address, a Signaling System 7 (SS7) point code address, an Internet protocol (IP) address, and a uniform resource identifier(URI) address. Next, a 1 response message 124 may be communk:ated to MSC 108 containing routing infonnation (e.o., LRN) for offtoading call control services for the call to IMS network 102. MSC 108 may then route the call to the IMS network by sending an ISUP lAM message to MSC 128 where the lAM message includes the LRN of the IMS node. In or>e embodiment, the LRN may be included in a called party number (CdPN) parameter in the lAM message. M6C128 may tomiinate the lAM message, determine the IMS node corresponding to the LRN (in this case, l-CSCF 130) and may generate and send a SIP INVITE message to I-CSCF 130. MGC128 may, for example, obtain additional routing infonnaton for l-CSCF 130 by performing a ONS or ENUM lookup based on the LRN stored in the CdPN fiekj of the lAM message. In one embodiment, MGC 128 may access a database that associates LRN values to IMS node addresses, and in this manner an LRN may be translated into a routable IMS address-In response to the INVITE nwssage, l-CSCF 130 may query HSS134 to determine the sennng CSCF with which mobile subscriber device 104 is regstered and may generate and transmit a SIP INVFTE message to S-CSCF 110 with which device 104 is registered. S-CSCF 110 may then provide call control services for the call. For example, S-CSCF 110 may route the call through a media gateway (not shown) in IMS network 102 to reduce toll charges. Thus, in one example, offloading call control services from a first network of a first type to a second network of a second type rnay include offloading the caK itself to the second network. In other examples, the call control services may IrKrlude advanced caH control services tt>at can be provkled more efficiently by the second network. For example, S-CSCF 110 may provide advanced call control servk«s such as call fonvarding. calt waiting, presence service, prepaki service, voice mail servKe, etc. using application server 106. Any one or more of these or ottier call control sen/Ices may be cffloaded to the second network of the second type using the methods, systems, and computer program products described herein. Figure 2 is a fkiw chart illustrating an exemplary process of using an originating party query to offload call control servk^s from GSM network 100 to IMS netvrark 102 shown In Figure 1 according to an embodiment of the subject matter deacril3ed herein. Referring to Figures 1 and 2, a call attempt may be initiated when a user of mobile sut}scrit>er device 104 dials a phone number. A call attempt message 117 may be generated based on the dialed phone number. Message 117 may be oimmunicated to MSC108 via a t>ase statkin subsystem (BSS) 118. Message 117 may include a calling party identifier corresporKling to calling mobile subscriber device 104 and a called party klentifier corresponding to the dialed phone number. The calling party Mentiter may be the mobile statkm integrated servkss digital network (MSISDN) number and/or the intemationai mobile subscriber klaitifier (IMSI) of mobile subscriber device 104. In this wcample, the calling party kfentifier of mobile subscriber device 104 is MSISDN number 919-460-5500 and/or IMSI 310150123456789. The called party ktentifier may be any suitable destinatkui number, such as an M^SDN of another phone. At block 200, MSC 108 may receive call attempt message 117. At MSC 108. an IDP trigger may trigger upon detection of the call attempt by calling mobile subscriber device 104 (block 202). In partiojlar, the IDP trigger of MSC 108 may trigger upon receipt of call attempt message 117 containing the calling party identifier of subscriber device 104. In response to triggering, MSC 108 may generate a TCAP InfbAnalyzed query message 120 indicating triggering and detection of a call attempt by calling mobile subscnlier dewe 104. Query message 120 may be transmitted to STP114 (blocK 204). At STP 112, CCO function 114 detects the call nlQJnating from mobile subscriber device 104 based upon query message 120 (block 206). In response to receivlr^ query message 120 that irulicates a call origirtating in GSM network 100, CCO fur>ctlon 114 determines an LRN associated with the calling party kientifier of rrobile subscriber devne 104. tn particular, function 114 queries CCO database 116 using Informabon Mentifying the calling party (block 208). For example, function 114 uses the calling party IMSI In query message 120 to perform a kxAup in database 116 for a call control offload LRN associated with the catling party IMSI. Table 1 below shows exemplary entries in a database for associating a sut>scrit)er ID with a call centred ofHoad LRN. Subscriber ID (CgPN: MSISDN / IMSI) Call Control Offload LRN (LRN of l-CSCF) 310150123456789 LRNx 310150123457789 LRNV Table 1; Exemplary Entries for Associating a Sulsscriber ID with a Call _ Control t-RN The entries shown in Table 1 may be stored, hx example, in database 116. Database 116 may be provisioned with can control offkMd LRNs fc>r subscribers who are registered with IMS nelwoifc 102 and are therefore eltgibte to receive call control servk»3 from IMS rwtwork 102. Function 114 may use a subscriber kientifier in a TCAP query message to perform a lookup In the table for determining whether a 8ubscrit>er identifier is associated wi^ ^e call control offkHd LRN. In one example, if the sut>scriber kientifier 310150123456789 is contained in a TCAP InfoAnatyzed query, function 114 may generate a TCAP AnalyzeRoute response message containing LRN x. In another example, if the subscriber identifier 310150123457789 is contained in a TCAP InfoAnatyzed query, function 114 may generate a TCAP AnalyzeRoute response message containing LRN y. LRN identifiers may include, but are not limited to, an E.164 formatted netiwork entity address identifier, an SS7 point code address, an Internet protocol (IP) address, or a unrfbrm rescHJns identifier (URI). Returning to the example of STP 114 receiving message 120, calling party IMSI 310150123456789 is contained In message 120. Function 114 receives the IMSI and queries database 116 using the IMSI. In block 210. function 114 obtains in response to ttte query, routing infomiation for a node In IMS network 102. In particular, function 114 performs a lookup in database 116 using ihecatllngpartylMSItoc^tain an LRN for l-CSCF node 130. If an entry including the calling party IMSI is found, ftjnction 114 generates a TCAP AnalyzeRoute response message 124 containing the LRN in the entry. STP 112 may forward message 124 to MSC108 for ofRoa In tills example of offloading the call control servKes to l-CSCF node 130. MSC 108 generates an ISUP 1AM 126 containing LRN x as the called party numtwr, the original called party number as the GAP parameter, an FCI_PNTI parameter set to TRANSLATED, and the MSISDN of mobile subscriber device 104 as the calling party numtwr. ISUP lAM 126 is generated in response to receiving response message 124 and serves to offload call control services for the call to IMS network 102. ISUP lAM 126 is transmHled to a media gatevi^y controller (MGC) 128. tn response to receiving ISUP lAM 126, MGC 128 generates and trammits a SIP INVITE message 132 to ar\ interrogating - rail session control function (l-CSCF) node 130. Message 132 contains the original caHed party numfc>er as to the To parameter and the MSISDN of calling mobile subscriber device 104 as tiie From parameter. Further, MGC 128 uses LRN x to detenmine the RequestURI parameter address of SIP INVITE message 132. In one embodiment, the RequestfJRl address may include some or all of the LRN x value. In other emt>odtments, the RequestURI address may be determlr>ed by using ttie LRN x value to access an LRN~to-iMS node address mapping table or database. In this manrwr the LRN x value may l>e translated into a routable l^fS network address. I-CSCF node 130 manages regte^tion, routing and forwaiding of SIP messages and charging. I-CSCF nodo 130 queries HSS134 to determine the location of the S-CSCF130 serving the c^ing party. In this case, S-CSCF 110 is assumed to be serving the calling party. Accordingly, I-CSCF node 130 sends a SIP INVITE message 133, which includes tiie same or similar content as message 132, to S-CSCF 110. In response to receiving message 132, S~ CSCF node 110 assumes management of call control services for the call. An application server (AS) 136 may host and execute sendees, and interface with tfie S-CSCF ftjnctton using SIP. In particular, for example, AS 136 may host and execute services for the call originating from mobile subscrtoer device 104. AS 136 may l>e used as a platform for depfo^ng various services in IMS rwtwork 102 and can prowde SIP functionalrty, 3GPP AS caK control, presence information, ENUM service, prepaid service, voice mail service and other services through the use of application programming interfaces (APIs}. Further. AS 136 can operate in SIP proxy mode, SIP UA (user agent) mode or SIP B2BUA bad(-to-back user agent) mode. In Figure 2, the LRN used to offload call control services to the IMS network was the LRN of an I-CSCF. In an alternate Implementetion of the subject matter described herein, the LRN may correspond to the S-CSCF with which riMbile subscriber device 104 is registered. Figure 3 Is a network diagram illustrating such an emt>odiment. Referring to Figure 3. a call attempt may be initiated when a user of mobile subscriber devne 104 dials a phone number. In response to initiation of the call, call attempt message 117 may be transmitted to MSC108 wtiere an lOP trigger is triggered upon detection of the call attempL In response to the triggering, MSC 108 generates and communicates TCAP trrfoAnatyzed query message 120 to STP 112. At STP 112, ceo function 114 receives query message 120. In response to receiving query message 120. CCO function 114 determines whether an LRN associated with the oalNrtg party kientifier of mot>ile subscritier devk»104exists in database 116. Inparticular. function 114 uses the calling party IMSI in query message 120 to perform a lockup in database 116 for a call control offload LRN associated with the calling party iMSI. The LRN may identify a node in IMS network 102 for the offload of call control services for the call. In one implementation, database 116 may include a range-based data structure and an exception-based data structure. Tables 2 and 3 shown below DIustrate examples of a range-based data structure and an exception-based data structure that may be used to implement database 116 according to an emtiodiment of the subject matter described herein. Subsciftier ID Range Start (CgPN: MSISDN / IMSI) 310150123456000 310150123457000 Sulwcriber ID Range £nd (CgPN: MSISDN / IMSI) 3101S01234S6099 310150123457999 Call Control Offload LRN (LRNcfS-CSCF) LRNy LRNx Table 2: Exemplary Entries for Associating a Subscriber 10 with a Call. Control LRN Subscriber ID Range (CgPN: MSISDN / IMSt) Call Control Offload LRN (LRNofS-CSCF) 310150123456789 LRNx 310150123457254 LRNv Tatile 3: Exemplary Exception Entries for Associating a Subscriber ID with a Call Control LRN The entries shown in Tables 2 and 3 may be stored, for example, in database 116. FuTKtion 114 may use a subscriber identifier ina received query message to first perform a looicup in Jabie 3 (the exception^iased data structure) for determining whether an LRN is associated with the identifier. If the lookup in the exceptiorv-based data structure fails to locate a matching entry, a lookup may then be performed in Tat>le 2 (the range-t»ased data structure). If an ervtry for the 8ubscrit>er identiTer including the LRN is found in either kwkup, it may be determined that the subscriber kJentifier is associated with an LRN. and therefore is eligible for call control offload servk%5- In one example, if ttie calling party number 310150123456123 is contained in a TCAP query message, exceptions-based kxskup will not result in a match, and function 114 will insert LRN y into the TCAP response message. Function 114 will then forward to the TCAP response nrtessage to MSC 108. In another example, if (he called party number 310150123457123 is contained in a TCAP query message, exceptions-based lookup will not resuft in a matt^, and function 114 will insert LRN x into the TCAP response message. Function 114 will then fonward to the TCAP response message to MSC 108. As descrit>ed above. Table 3 includes exceptions to the ranges of numbers provided in the entries of Table 2. In one example, an exception may be a number that is within the range but that has a different LRN or routing njle. For example, fhe first entry in Table 3 corresponds to subscriber identifier 310150123456789. This number is within the range of 310150123456000-310150123456999 that coriespoRds to the first entry m Table 2. However, the entries have different LRNs. Thus, an exc^tion-based table, such as that Hustrated in Table 3, may be used to flexibly allocate different routing instuction for numbers that are assigned to the associated subscritiers. If a received calRng party numt>er matches the calling party number In an entry of Table 3, the LRN in the entry of Table 3 is used for insertion into tiie TCAP response message. For example, if the received calling party number is 310150123456789, the exceptk>n-based kwkup resuKs in a match, the range-t>ased lookup is bypassed, and LRN x is used lor insertion into the response message. In another example, if the received calling party number is 310150123457254, the exception-based kwkup results in a match, the range-based lookup is bypassed, and VRH y is used for ir\sertion into ttte response message. An LRN obtained from Table 2 or Table 3 of database 116 may be inserted in TCAP AnalyzeRoute response message 124. STP 112 may fonward message 124 to MSC 108 for offloading caH control services for the call to IMS network 102. In this example of offloading call control services for the call. MSC 108 generates an ISUP lAM 126 directed to S-CSCF 110 of IMS network 102, whk:h is associated with LRN x. ISUP lAM 126 is generated In response to receiving response message 124. tSUP lAM 126 contains routing number LRN x, the called phone niwnbef. and the calling party number. ISUP lAM 126 is transmitted to a media gateway controller (MGC) 128. In response to receiving (SUP lAM 126. MGC 128 generates and transmits to S-CSCF node 110 a SIP INVITE message 132 containing tfie called party number and the calling party number. SIP INVITE message 132 is transmttted to S-CSCF node 110. In response to receiving message 132, S-CSCF node 110 assumes management of call control sen/ices for the caN. As a result of an exceplicHvbased implementation, flexible assignment of 2G subscrit>ers to S-CSCF elements or other IMS network elements can be accomplished. Mother advantage of an exception-based implementation is that signaling messages may be routed directly to the appropriate S-CSCF node or another IMS network element in the IMS network without requiring involvwnent of an l-CSCF rKXie. Any suitable routir>g node (e.g., an STP and signaling gateway), call processing node (e.g., media gateway controHer, Softswitch, gateway tandem G4fk», gateNway MSC, TDM-to-Packet gateway), or stand-alone processing platform (e.g., service control point, application server) may include a CCO functnn in accordance with the subject matter described herein. For example, a CCO function may tie included In an SS7/IP-capable STP routing node or a signaling gateway (SG) routing node. In one example, a suitable system for using an originating paity query to offload call control sennces from a first rwtwork of a first type to a second r>etwork of a second type according to the subject matter descrtoed herein may include an EAGLE STP* or an IP' SECURE GATEWAY* (both commercially available firom Tekelec of Morrisville, North Carolina). Figure 4 is a bk>ck diagram illustrating an exemplary network routing node 112 (e.g., an STP routing node with SSP/IP gateway functionality) including a CCO functkm according to an embodiment of the subject matter described herein. Referririg to Figure 4, routing node 112 includes an interprocessor message transport (IM7) bus 400 that is the main communk:ation bus among internal subsystems within routir>g node 112. In one embodiment, tfus high-speed communications system includes two counter-rotating serial rings. A number of processing modules or cards may be coupled to IMT bus 400. In Figure 4. IMT bus 400 may be coupled to a link internee module (LtM) 402, a data commumcattons module (DCM) 404, and a database servk» module (DSM) 406, whk:h includes CCO function 114 and CCO database 119. These modules are physkraliy connected to IMT bus 400 such that signaling and ott>er types of messages may be routed internaDy between active cards or modules. For simplicity of iUustration. only a sirigle LIM, a single OCM, and a single DSM card are included in Figure 4. However, routing node 112 may indude multiple other LIMs, DCMs, DSMs, and other cards, all of which may be sJmuKaneousty connected to and communicating via IMT bus 400. Each module 402, 404, and 406 may include an application processor and a communication processor. The communication processes may control communicationwithothermodulBsvialMTt}Us400. The application processor on each nKXlule may execute the applications or functions that reside on each module. For example, the appfication processor on DSM 406 may execute software that implemerrts CCO function 114. Similarly, the application processor on LIM 402 may execute software that implements a screening function for determining whether messages shouU t>e forwarded to DSM 406 for appfication to a CCO function. LIM 402 may include an SS7 MTP level 1 function 408, an SS7 MTP level 2 function 410, an I/O buffer 412, a gateway screening (GWS) ftjnction 414, an SS7 MTP level 3 message handling and discrimination (HMDC) function 41S, including an application screening function 418, a message routing function 420, and a message handling and distribution (HMDT) function 422. MTP level 1 function 408 sends and receives digital data over a particular physical inlerfece. MTP level 2 function 410 provides error detection, error correction, and sequenced delivery of SS7 message padcets. I/O buffer 412 provides temporary buffering of incoming and outgoing signaling messages. GWS function 414 examirws received message padtets and determines wtiether ttie message packets shoukJ t>e allowed in routing node 112 for processing and/or routing. HMDC function 416 performs discrimination operations, which may include determining whether the received message packet requires processing by an internal processing subsystem or is simply to t>e through switched (i.e., routed on to another node in frte rwtwork). Messages that are pemiitted to enter routing node 112 may t>e routed to other communications modules In the system or distributed to an application engine or processing module via IMT bus 400. Routing ftjnction 420 may route received messages that are identified by HMOC function 416 as requiring routing to the appropriate LIM associated with the message destination. Exemplary routing criteria ttiat may be used by routing function 420 to route messages indude destination point code (DPC), origination point code (OPC), circuit identifier code (CIC). senice indicator (SI), inbound Irnltset, or any combination thereof. HMDT function 422 distributes messages identified by HMDC funcfon 416 as requirmg further processing to the appropriate processing module within routing node 112 for providing the processing. Application screening function 418 may examine received message packets and determine whetfier the message padcets should be fonvarded to DSM 406 for application to CCO function 114. For example, application screening hinction 418 may determine whether a received message packet is a TCAP InfoAnalyzed query message. In another ejomple, application screening function 418 may be omitted, EBKI HMOC function 416 may forvrard a(t messages addressed to the point code of routing rKxJe 112 to DSM 406 for further processing. If it is determined that the received message should be fonvarded to DSM 406, the message is fonvarded to DSM 406 for processing by CCO Unction 114. If it is determined that the received message shouU not t>e forwarded to DSM 406, ttie message will tie routed by routing node 112 without being processed by CCO ftjnction 114. For example, HMDC ft^nction 416 may fc»ward messages that are not addressed to the point code of routir>g TTOde 112 to ^outir^g function 420, and routing ftmcUon 420 may route such messages to the LIM of DCM associated with the outbound signaling link. DCM 404 includes functiondity for sending and receiving SS7 messages over IP signaling links. In the iOustrated exampte, DCM 404 includes a physical layer function 424, a network layer function 426, a transport layer function 428, an adaptation layer fur>ction 430, and functions 414,418, 418, 420, and 422, described above with regard to LIM 402. Physical layer Unction 424 perfomis open systems interconnect (OSI) physical layer operations, such as transmitting messages over an undertyir\g electrical or optical interface. In one exampte, physical layer functton 424 may be implemented using Ethernet. Netwoi1( layer function 426 performs operations, such as routir>g messages to other netvrark nodes. In one implementetion. network layer function 426 may implement Internet protocol. Transport layer function 428 implements OSl transport layer operations, such as providing connection oriented transport betvmen network nodes, providing connectionless transport between network nodes, or providing stream oriented transport between network nodes. Transport layer functkin 426 may be implemented using any suitable transport layer protocol, suc^ as stream control transmission pnMocol (SCTP), transmisston control protocol (TCP), or user datagram protocol (UDP). Adaptiition layer functnn 430 perfomns operaittons for sending and receiving SS7 meuages over IP transport Adaptation layer furtction 430 may be implemented using any suitable IETF or other adaptation layer protoco). Examples of suitable protocols include MTP level 2 user peer-to-peer adaptation layer (M2PA), MTP level 3 user adaptation lay»- DSM 406 receives messages ktentiTied as requiring to CCO functkin 114. In one emt)odknent, function 114 determines a call control offioeKJ LRN associated with the calling party numt>er in a received TCAP InfoAnalyzed query message. In particular, functnn 114 may use the calling party numtier in the received message to perfonn a k>okup in database 114 for a call control LRN associated with the calling party number. The call control LRN associated with the calling party number in the received message is inserted into a TCAP response message associated with the received message. After insertion of the call control ofRoad LRN, the message can be fonvarded to a routing functnn 420 for routing to LIM 402 via IMT bus 400. If no call control offtoad LRN is found that is associated witti the calling party number, then no LRN is inserted in the response message. UM 402 may then fonward the response message to ttie MSC that originated the query message. Offtoadir^ call control to another network may include routing at least a portion of the can over an aHemate and possiily less expensive media path. Figure 5 is a network diagram illustrating the same components illustrated in Figures 1 and 3 for offloading call control and also illustrating media path components for routing at least a portion of the media path over an alternate network. Referring to Figure 5, a call attempt may he initiated when » user of mobile subscritwr device 104 dials a phone numtwr of PSTN phone 500. In response to initiation of the call, a call attempt message may be transmitted to a senring MSC 108 where an IDP trigger is triggered upon detection of the call attempt MSC 108 may generate and communicate a TCAP InfcAnatyzed query message to STP112. which includes CCO function 114, COO database 116. and may also include an ENUM database SCO for translating £.164-fonnatted numbers to URIs. The query message includes the callir>g party number of mobile aubsafber device 104. At STP 112, CCO function 114 detects the call originating from mobile sub9crit}er device 104 t>a5ed upon the received query message. In response to rece'Fving the query message, CCO functim 114 determirtes a call control offload routing numt>er associated with the identifier of mobile subscriber device 104. In particular, function 114 may use a callirtg party IM6I in the query message to perform a lookup in CCOdatat>ase 11A for a/outing number associated with the caMng party IMSI. The routing number ot>tained from database 116 based on the lookup may be inserted in a TCAP AnalyzeRoute response message. STP 112 may forward the response message to MSC 108 for offloading call contrtri services for the call to IMS networtc 102. In this example of ofnoading call control services for the call, MSC 108 generates an ISUP lAM containing the routing numt>ercorrespondir>g to a node in the IMS r>etworic. The ISUP lAM is generated in response to receiving the TCAP AnalyzeRoute response message. In one example, the ISUP lAM contains the routing number, the called phone number, and the calling party number. Further, the ISUP lAM is transmitted to MGC 128. In response to receiving the ISUP lAM, MGC 128 generates and transmits to l-CSCF node 130 a SIP INVITE message ccmtainlng ttie original called party number and the calling party numtwr. In response to receiving ttw SIP INVITE message, I-CSCF node 130 and its associated senrice kxation function (SLF) queries HSS 134 to determirw the S-CSCF serving the subscn'ber. In this example, S-CSCF 110 is identified. S-CSCF 110 directs MGC 128 to establish a media trunk twtween MGW 504 and temninatir>g erxl office switch 506 and arx>ther media trunk between serving MSC 108 and media gateway 504 by sending a SIP ceo function 114 determines a routing number associated with the calling party identifier. In step 3, function 114 transmits to MSC 108 a TCAP AnalyzeRoute response message including the routing number. In step 4, MSC 108 transmits to MGC 128 an ISUP lAM message contains the routing number, the called phone number, and thie calling party number. In step 5, MGC 128 transmits to one of IMS network components 130,110, and 134 a SIP INVITE message containing the called party number and the calling party numtwr for offloading call control services to the IMS networtc. In an alternate implementation of the subject matter described herein. MGC 128 may maintain a database lor mapping the LRN to an l-CSCF node. Figure 7 is a network diagram illustrating such an embodknent. Referring to Figure 7. a call attempt may be initiated when a user of calling mobile subscriber device 104 dials a phone number. In response to Initiation of tfw call, call attempt message 117 may be transmitted to MSC 108 where an IDP trigger is triggered upon detection of the call attempt. In response to the triggering, MSC 108 generates and communicates TCAP InfoAnalyzed query message 120 to STP 112. At STT 112, ceo function 114 receives query message 120. In response to receiving query message 120, CCO function 114 determines whether an LRN associated with the identifier of calling mobile subscn'ber device 104 radsts in database 116. In particular, function 114 uses the calling party IMSI in query message 120 to perform a lockup in database 116 fbra can control offload LRN assodated with the caHing party IMSt. The LRN may identify a rwde in IMS network 102forthe offload of can control services for the call. An LRN obtairted from database 116 may be inserted in TCAP AnalyzeRouta response message 124. STP112 may forward message 124 to MSC108 for offloading call control sen/ices for the call to IMS netwrorl(102. In this example of offloading call control services for the call, MSC 108 generates an ISUP lAM 126 directed to l-CSCF 130. which is associated with LRN x. ISUP \fiM 126 is generated in response to receiving response message 124. ISUP lAM 126 contains routing number LRN x, the called phone number, and the calling party number. ISUP iAM 126 is transmitted to MGC 128. In response to receiving ISUP IAM 126, MGC 128 generates and transmits to I-CSCF node 130 a SiP INVITE message 132 contairMng the called party number and the calling party number. Further, SIP INVITE message 132 includes a RequestURI set to address [email protected], which corresponds to l-CSCF 130. MGC 128 maintains a table that maps the LRN to an l-CSCF URI. In this example, LRN x contained in ISUP IAM 126 is mapped to the I-CSCF URI ICSCFi3}vzw.com. SIP INVITE message 132 Is transmitted to I-CSCF 130, which m turn routes SIP INVITE 133 to S-CSCF node 110. In response to receiving message 132. S-CSCF node 110 assumes management of call contrtri services for the call. In arMither implementation of the subject matter described tierein. MGC 128 may append domain nanie information to an LRN to generate a routable URI address for routing a SIP INVITE message to an l-CSCF node. Rgure 6 is a network diagram Hlustrating such an embodiment Referring to Figure 8. ISUP IAM 126 containing LRN x is received at MGC 128. In this example, the domain name information "(givzw-com" is apperuled to "LRNx" to obtain a RequestURI for specifying l-CSCF 130. MGC 128 generates SIP INVITE 132 containing the RequestURI and send SIP INVITE 132 to l-CSCF 130 using the RequestURI. generated in response to receiving response message 124. ISUP lAM 126 contains routing number LRN x, the called phorw number, and the calling party number. ISUP \fiM 126 is transmitted to MGC 128. In response to receiving ISUP lAM 126, MGC 128 generates and transmits to S-CSCF node 110 a SIP INVITE message 132 containing the called party number arxl the calling party number. Further, MGC 128 maintains a table that maps the LRN x to an S-CSCF URI. In this example, LRN x contained in ISUP lAM 126 is mapped to the S.CSCF URI [email protected]. StP INVITE message 122 includes a RequestURI set to address [email protected], which cturesponds to S-CSCF 110. SIP INVITE message 132 is transmitted to S-CSCF 110 using the address specified in the RequestURI. In response to receiving message 132, S-CSCF node 110 assumes management of call control services for the call. In one embodiment, HSS 134 may be qperable to provision database 116 of STP 112 with data that associates calling party numbers with their corresponding S-CSCF nodes. Such data may altemattvely be provisioned by any other suitable IMS network administration center. In this manner, the LRN retumed by a lookup in datat>ase 116 directly identifies the corresponding S-CSCF, thereby alkiwing the SIP INVITE message to be routed directly to the S-CSCF. Further, in this manner, the l-CSCF may be effectively shieMed from traffic, thereby minimtzir^ l-CSCF resource use. In yet arwther implementation of the subject matter described herein, MGC 128 may append domain name information to an LRN to generate a routable URI address for routing a SIP INVITE message to the S-CSCF with which motMie subscriber is registered. Figure 10 is a network diagram illustratirtg such an emtwdiment. Refening to Figure 10, ISUP lAM 126 contairring LRN x is received at MGC 128. In this example, the domain name inforrraAion "@vzw.com" is appended to 'LRNx" to obtain a RequestURI for speclf^ng S-CSCF 110. which convsponds to mobile device 104. MGC 128 generates SIP INVITE 132 containing the RequestURI and send SIP INVITE 132 to S-CSCF 110 using the RequestURI. In yet arwther embodiment of the present inventkm, a CCO database may be co-located writh or Integrated with a number portability database (e.g., mobile number portability database, local number portabjfity database, service provider portability database, and geographic number portability database). The associated CCO ftinction is adapted to access both the number portability data and call control offload data. In one embodiment, the CCO function may receive a query, such as a TCAP query, that contains both called party identifier and calling party identifier information. The CCO function is adapted to use tt>e caRed party identifier informalion to perform a number portabirity lookup in the number portability database, and to use the calling party Identifer information to perform a call control offload lookup in the call control offload datat>ase. The nivnber portabiTity database lookup using the called party kientifier infbmiation may yiekJ a number portability LRN value, while the call control offtoad database lookup using the calling party identrfier infomriatnn may yiekJ a caH control offk>ad LRN value. The CCO functiwi may respond to the TCAP query ortginator wiUi a single response message v&vch irwludes both the number pcMtabflHy and call control ofrk>ad LRN values. AHematively. the CCO functk)n may resporKJ to the query originator with multiple response messages that convey the LRN infomiation. In an altemate embodiment, the CCO function may receive separate queries for number portability service and call control omoad servk». tn this case, the number poftability query ir>cludes called party identilieT information, while the caH control offk>ad query includes calling party klentifter information. The CCO furK:tk>n is adapted to use the called party identifier information to perform a numtin' portability lookup In the number portability database, and to use the calling party kientifier information to perform a call control offk>ad kKtkup in the call control offload database. The number portability database lookup using ttie called party kientifier infomiatkin may yieki a numt>er portability LRN value, while the call control offload database lookup using the calling party kferttifier information may yiekJ a call control offload LRN value. The CCO functton may respond to the TCAP query originator vtrith either a single response message vvhk:h iru:ludes both the number portability arxf call control offload LRN values, or vtrith a separate number portability response message (whk:h includes the number portabilrty LRN value) and a separate call control offload response message (which iitcludes the catl control offload LRN value). N will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation. CLAIMS What is claimed is: 1. A method for offloading call control sendees from a first network of a first type to a second network of a second type, the method comprising: detecting a call originating from a caHing party in a first network of a first type; determining routing information for a hode in a second network of a second type based on information identifying the calling party; and offloading call cortrol services to the second network using tfie node. 2. The method of daim 1 wherein the first network comprises a global system for mobile communications (GSM) and thte second network comprises a session initiatnn protocol (SIP)-based network. 3. The method of claim 1 wherein tfie first network comprises a 2G wireless network and tfie second network comprises a StP-based networic. A. The method of claim 1 wherein detecting a call originating from a calling party includes detecting ttie call using an initial detection point trigger set in a ruxle of the first netwcvk to detect the call originating from the calling party. 5. The method of claim 1 wherein obtaining routing information includes obtaining a routing number of tfie node in the second network. 6. The mettiod of daim 1 wtierein the node comprises a SIP node, and wherein determining routing information iTKdudes determining a routing numtwr associated with the SIP node. 7. The method of claim 6 wtierein the SIP node comprises an interrogating - call session control functior\ (l-CSCF) node. 6. The method of daim 6 wtierein the SIP node comprises a serving - call sesston control function (S-CSCF) riode. 9. The method of cta^ 8 wtierein offkmdlng call control services (ndudes offloading call control sennces for the caH to tfie S-CSCF node. 10. The method of claim 1 wherein determining a routing number inchxJes performing a lookup in an exceptk>n-^a&ed dErta structure for the routing Information, and, in response to failing to locate ttie rou^g infomiation in the exception-based data structure, performing a lookup in a range-based data structure for the routing information. 11. The method of claim 1 comprising, at the node in ttie second network, selecting a med^ path for the call, and routing the call over the selected media path. 12. The method of claim 1 comprising detemrwiing number portability informatk)n t>ased on information identifying a caRed party associated with the caU. 13. The method of claim 12 comprlsfng communfcatfng the number portatMPty informatton to the node in the seccmd network. 14. The method of claim 12 comprising receiving a TCAP query message including the information identifying the calling party and the information identifying a called party associated vwth the cad. 15. Ttie method of claim 12 comprising receiving a first TCAP query message indudirtg the infomiation klentifying the calling party and receiving a second TCAP query message induding the information identifying a called party associated wUh the cat). 16. The method of claim 1 wherein offk}ading call control services includes offk>ading one or more of the call, caH forwarding, call waitirtg, presence service, prepaU service, and voice mail service. 17. A method for offloading a call from a first r>etwork of a first type to a second network of a second type, the method compnsing: detecting a call originating from a calling party in a first networV of a first type; determining routing information for a rKxfe in a second rtetwoik of a second type based on Information identifying the calling party; and offtoading the call to the second network u$ir>g the node. 18. A method for provkJing call control offload Informatnn to a requestor, Vhe method compnsing: , receivirtg from a query originator a query requesting call control offload routing informaton that includes a calling party identifier: perfonning a lool(up in a caN control offload database using the calling party identiAer to obtain call control offload routing information; and returning ttie call control offload routing infomnation to the query originator. 19. A system for offloading call control senrices from a first networtc of a first type to a second network of a secorKl type, the system comprising; a communications module configured to receive a query message indicating detection of a call originating frcwn a calling party in a first network of a ftrst type; a call control offload function configured to d^ennin^ routing information for a node in a secorKl networic of a second type based on information identifying ttie calling party and configured to offkiad call control services to the second network u«ng Uie rK>de. 20. The system of claim 19 wherein the first network comprises a public switched telephone network (PSTN) and the secwid network comprises a sesskm initiation protocol (SIP)-t»8ed network. 21. The system of daim 19 wtwrein the first network comprises a 2G wireless networic and the secorvj network comprises a SIP-based network. 22. The system of claim 19 wherein the fKxIe comprises a SIP node. 23. The system of daim 22 wtierein the SIP node comprises an interrogating - call session control function (l-CSCF) node. 24. The system of claim 22whenBin the SIP node comprises a serving - call session control function (S-CSCF) node. 25. The system of daim 19 comprising a routing node, wherein the communicatk>n module and the can control offload function are located in ttie routing node. 26. The system of daim 19 comprising a caH cor>trol offlo»l datatiase acces8it>le by the call contrc^ offtoad function for locatirtg the routing infonmation. 27. The system of claim 26 wherein the caU control offload database includes an exceptnn-based data stnicture and a range-based data structure, and wherein the call control ftmction is adapted to access the exception-based data structure to locate ttie routir^ information and, in response to locating ttie routing information in ttie exceptlorv-based data structure, to search a range-tiased data structure for the routing information. 28. The system of daim 19 wtierein the communications module is configured to receive irrformation IdentifyHig a called party associated with ttie call, and wherein the call control offload function is configured to determine number portability infomiation l>ased on the infonnation identifying the called party associated with the call. 29. The system of claim 28 wherein ftm call control offload function is configured to communicate the numtier portability information to the n«le in the second netwoA. 30. The system of claim 28 wherein the query message comprises a TCAP query message fnduding the information identrfyirni the calling party and the infonnation identifying a called party associated with the call. 31. The system of claim 28 wherein the query message comprises a first TCAP query message including the information identifying the callir^ party, and wherein the communications module is configured to receive a second TCAP query message Including the information identifying a called party associated with the call. 32. A system for providing call control offload information to a requestor, the system comprising: a call conUol offload function associated with a first network and configured to: receive from a query originator a query requesting call control offload routing information that includes a calling party identifier; perform a lookup in a can control offload database using the callirig party identifier to otitain call control offload routing information; and return ttie call control offload routing information to the query originator. 33. A computer program product comprising computer executable instructions embodied in a computer readable medium for perfwming steps comprising: detecting a call originating from a caHtng party in a first network of a first type; detemiining routir>g information for a node in a second netvvorit of a second type tiased on information Identif^ng the caSIng party, and offloading call control services to the second network using the node. 34. A computer program product comprising consular executable instructnns embodied in a computer readable nwdium for performing steps comprising: receiving from a query originator a query requesting call control offkiad routing information that kicludes a calling party kientifier; performing a lookup in a call control offkiad database using the calling party kJentifier to obtain call control offload routing information; and reluming the call conbol offtoad routing informatnn to the query originator.

Full Text

PESCRIPTION
METHODS. SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR
OFFLOADING CALL CONTROL SERVICES FROM A FIRST NETWORK
OF A FIRST TYPE TO A SECOND NETWORK OF A SECOND TYPE
RELATED APPLICATIONS This application daims the benefit of U.S. Provisionat Patent Application Serial No. 60/834,103, filed July 26, 2006, and corresponding U.S. Patent Appication (Serial No. not yet assigned) entitled METHODS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS FOR OFFLOADING CALL CONTROL SERVKIES FROM A FIRST NETWORK OF A FIRST TYPE TO A SECOND NETWORK OF A SECOND TYPE, filed July 27,2007. the disclosures of each which are incorporated herein by reference in their entireties.
TECHNICAL FIELD The subject matter disclosed herein relates generally to call control services. More particularly, the sutqect matter disckised herein relates to offloading call control services.
BACKGROUND
Commonly deployed wireless communications networks support both voice and data services. Typically, mobile handsets or mobile subscribers are corviected to a base transceiver station i»ing a radio access network that uses a modulation scheme such as code division muttiple access (CDMA) or global system for mobile communication (GSM). The base transceiver stations are conrtected via fixed links to or>e or rhore base station controners, and the t>ase statton controllers are aggregated into switches called motHle switching centers. Mobile switching centers are connected to the publk; land mobile network / pubHc switched telephone rwtwoik (PLMN / PSTN), typically thiough a gateway switch called the gateway mobile switching center (GMSC).
Internet protocol (IP).multimedia subsystem (IMS) is defined by the Third Generation Partnership Project (3GPP) as a mobile network infrastructure that enables the convergence of data, speech, and mobile network technotogy over

an IP-based infrastructure. IMS bridges the gap between the existing traditional telecommunrcations technology, such as PSTN, and Internet technology, allowing network operators to offer a standwdized, reusable friatfonn with new, innovative services by enhancing real lime, multimedia mobile services, such as voice services, video telephony, messaging, confererwing. and push services. IMS can be used to pnwtde services for both mobile networks and fixed networks at the same time, providing unk|ue mixtures of services with transparency to the end-user. IMS is one example of a sassran initiation protocol (SIP)-based network. Another example of a SIP-based network is a next generatkm rtetwork (NGN) network.
IMS supports the estabNshment of any type of media sesston (e.g., voice, vkfeo, text, etc.) and provkJes the service creator the ability to cixnbine servk»s in the sarrie session and dynamically modify sessions 'tm ttie fly" (e.g., adding a video component to an existir>g voice session). As a result, rww and innovative user-to-user and muKKiser services become a^ilat>le, such as enhanced voice servkss, vkjeo telephony, chat, push-to-taHi, and multimedia conferencing, aN of w^k:h are based on ttie concept of a muWmedia session. The underlying IMS infrastructure enables mobile IP cxxnmunicatk>n services via its ability to find a user in the network and then to estabPish a session with the user. The key IMS components enabling mobility management are the call sessnn control fuiKrtion (CSCF) and home subscriber server (HSS). The CSCF is essentiatty a proxy, which aids in the setup and management of sesskms and forwards messages between IMS rietworks. The HSS hokls all of Vne key subscriber infomtation and erxables users (or severs) to find axvi communicate with other end users.
A wireline or wireless subscnlwr may benefit from the can control services provMed by t»th networks. Sometimes the services operated in the different networks provkled to a subscriber may overlap. For example, an IMS netvrork may provide the same call control senrice as a PSTN or 2G wireless network. In some vistances, it may be advantageous to ofTK>ad call control service from cme network to anottier network of a different type. Exemplary network types Include 2G wireless networks (e.g., Gk>bal System for Mobile Communicafens {G^Jl), Interim Standard - 41 (lS-41)). PubUc Swtched

Telephone Network (PSTN), Next Generation Network (NGN), and IMS networks. For example, the services provided by an IMS network may be ctieaper ttian the PSTN. In this case, it would be advantageous to ofrioad call control sennets from the PSTN to the IMS network.
Accordirtgly, there exists a need for methods, systems, and computer program products for off)oadir>g call control services from one network to another network of a different type.
SUMMARY Acowdlng to one aspect, ttie sutjject matter described herein includes a method for using an originating parly query to offtoad call control ser^ces from a first network of a first type to a second network of a second type. Ttie method includes detecting a call originating from a calling party in a first network of a first type. A database may be queried using information klentifying the calling party. In response to tt>e query, routing information may be for a node in a second network of a second type. Call control ser/ioes may be offloaded for the call to the second network uatng ttie node.
BRIEF DESCRIPTION OF THE DRAWINGS
Exemplary embodiments of the subject matterwffl now be explair>ed with reference to the accompanying drawings, of whk:h:
Figure 1 is a r>etwork diagram of an exemplary system for using an originating party query to offload call control services from a first network of a first type to a second r>etwork of a secorKi type according to an embodiment of Vne sut^ect matter described herein;
Figure 2 is a fkiw chart of an exemplary process of using an originating party query to offload call control sendees from a GSM network to an IMS network shown in Figure 1 according to an emt}odiment of the Subject matter described herein;
Figure 3 is a network diagram of arrother exemplafy system for using an originating party query to offload call control sen/ices fnsm a GSM network to an IMS network according to an embodiment of the subject matter described herein;

Figure 4 is a blocit diagram of an exemplary rwtwork routir\g node including a call control offload (CCO) function according to an embodiment of the subject matter described herein;
Figure 5 is a network diagram of an exemplary system for using an originating party query to offload call control services from a GSM r^etwotk to an IMS network according to an embodiment of the subject matter described herein:
Figure 6 is a message fkw diagram of an exemplary exchange of messages among a mobile subscriber, a serving mobile switching center (MSC), a CCO functton, an MGC, and IMS network components for using an originating party query to offload caH control sennces frcwn a GSM network to an IMS network accoRfing tothe subject matter described herein;
Figure 7 is a network diagram of another exemplary system for using an originating party query to offload call control services from a GSM network to an IMS network according to an emtxxlinrwnt of the subject matter described herein;
Figure 8 is a network diagram of yet anottier exemplary system for using an originating party query to offkiad call control servk»s from a GSM network to an IMS network according to an emt>odiment of the subject matter described herein;
Figure 9 is a network diagram of yet another exemplary system for using an originating party query to offload call control services from a GSM networtc to an IMS network according to an embodiment of the sut}ject matter described herein; and
Figure 10 is a network diagram of another exemplary system for using an originating party query to offload call control servk»s from a GSM network to an IMS network according to an embodiment of the subject matter described herein.
DETAILED DESCRIPTION To faoKtate E^ urxterstanding of exemplary embodbnents, many aspects are described In tarms of sequences of actions that tan t>e performed t>y elements of a computer system. For example, it will be recognized that in each

of the embodiments, the various actions can be performed by specialized circuits or circuitry (e.g.. discrete logic gates interconnected to perform a specialized ftjnction), t)y program instructions being executed by or>e or n>ore processors, or by a combination of both.
Moreover, the sequences of actions can be embodied in any computer-readable medium for use by or in cormection with an instruction execution system, apparatus, or device, such as a computer-based system, processor containing system, or other system that can fetch the instructions from a computer-readable meifium and execute the Instructions.
As used herein, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection witti ttie instruction execution system, apparatus, or device. The computer-readable medium can be, for example but not limited to, an ^ele medium can include the followir>g: an electrical connection having or>e or more wires, a portable computer diskette, a rar^om access memory (RAM), a read-onty memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical f%>er, and a portabte compact dtec read-only memory (CDROM).
Thus, the subject matter described herein can be embodied in many different forms, and aH such forms are contemplated to be within the scope of what is claimed. Any such form of emtTodiment can t>e referred to herein as logic configured to" perform a described action, or alternatively as "logic thar performs a described action.
Methods, systems, and computer program products for using an original party query to offload call control sen/Ices from a first network of a first type to a second network of a second type according to embodiments of ttie si4))ect matter described herein may be implemented in one or more of any suitable network componente or networic devices. For example, the methods, systerm, and computer program products may be implemented in a routing node, a signal transfer point (STP), a router, a switch, a gateway, a media

gateway controller, a softswtch. an IMS node with PSTN gateway functionality, an NGN node, a service control point, an appKcatJon server, or other suitable network device. Figure 1 is a network diagr»n fltustrating an ex^nplary system for using an originating party query to offload call control services Uotn a first Twtwork 100 of a first type to a second network 102 of a second type according to an embodiment of the subject matter described herein. In this eicample. networks 100 and 102 are a GSM network and an IMS iwtwork, respectively. Furttier, m this example, the caN is originated by a mobile subscriber device 104. Although Figure 1 itlustrates the offloading of caU cotUrol services from a GSM networtf to an I MS network, those skilled in the art realize that the present sut^ect matter is not Hmtted to the depteted embodiment arKi Is applicable to any system Including networks of different types. Referring to Figure 1, mobile sul>scrit>ef device 104 may be registered with a 2G HLR 106, which maintains authentication and registration information associated with mobile subscriber devioe 104 and otherfnobile &ub&crit>ers. Further, for example, HLR 106 may store service profile, locatkin infomialion, and activity status of mobile subscriber device 104. Duringoperation.mobilesubscTitwr device 104maybe assigned to a serving MSC 108. which may provkle telephony switching services and mc^ility functions.
Mobile subscriber device 104 may be any suitable wireless commurncations device for performing calling tuncttons. such as a mobile phone and a smartphorw. In this example, mobile subscritKr device 104 Is a 2G phone capable of operating in GSM network 100. When operating within GSM network 100, call contrd services for mobile subscriber device 104 may be offloaded from GSM network 100 to an IMS serving - call session control function (S^SCF) 110 in accordance with the subject matter described herein.
MSC 108 may download initial detection point (IDP) trigger infomnation from HLR 106 for detecting can orlglnatbn attempts from GSM network 100. In particular, MSC 108 maydownk}ad and store an IDP trigger for detecting when a call originates from mobfe Bubscritier device 104, the calling party for the call, while In GSM network 100. An example of triggering Information may Include an kJentifier for mobile subscriber device 104 that Es contained in a received call attempt message. MSC 108 may trigger on detectkm of the triggering

infonnation in a received call attempt message 117. After triggering based on the call attempt by mobile subscriber device 104, MSC108 may communicate a query message to an STP 112. Iho query message may be a TCAP Info-Analyzed message that contains the identifier for the caiiing rrwbite subscriber device 104. In one embodiment, the query nrtes&age may t>e simiter to a number portabifty query message, where the query message includes caiiing party Identtfler Information instead of or in addition to caNed party identifier infonnation. The query nwssage may be sent for requestkig a routing number for a node in IMS networtt 102 that may be used to provide call control services for the call.
STP 112 may include a caH control offload (CCO) ftjnction 114 for offloading call control services from GSM network 100 to IMS netwoik 102. In particular, STP 112 may receive from MSC 108 the query message contatntng an Identifer for calling mobile subscriier device 104. In response to receiving the query message. CCO function 114 may query a CCO database 116 for routing information using the caiiing party identifier information. In response to the query, function 114 may ob^in routing information for a rK>de in tMS network 102 ttiat is operable to provide call control senrices for the call. Exemplary roufing information indudes a )oca\ roufing nund)er (LRN), a network entity address, an MSC address, a Gateway MSC address, a Gateway rcHJttng node address, a Signaling System 7 (SS7) point code address, an Internet protocol (IP) address, and a uniform resource identifier(URI) address. Next, a
1
response message 124 may be communk:ated to MSC 108 containing routing infonnation (e.o., LRN) for offtoading call control services for the call to IMS network 102. MSC 108 may then route the call to the IMS network by sending an ISUP lAM message to MSC 128 where the lAM message includes the LRN of the IMS node. In or>e embodiment, the LRN may be included in a called party number (CdPN) parameter in the lAM message. M6C128 may tomiinate the lAM message, determine the IMS node corresponding to the LRN (in this case, l-CSCF 130) and may generate and send a SIP INVITE message to I-CSCF 130. MGC128 may, for example, obtain additional routing infonnaton for l-CSCF 130 by performing a ONS or ENUM lookup based on the LRN stored in the CdPN fiekj of the lAM message. In one embodiment, MGC 128

may access a database that associates LRN values to IMS node addresses, and in this manner an LRN may be translated into a routable IMS address-In response to the INVITE nwssage, l-CSCF 130 may query HSS134 to determine the sennng CSCF with which mobile subscriber device 104 is regstered and may generate and transmit a SIP INVFTE message to S-CSCF 110 with which device 104 is registered. S-CSCF 110 may then provide call control services for the call. For example, S-CSCF 110 may route the call through a media gateway (not shown) in IMS network 102 to reduce toll charges. Thus, in one example, offloading call control services from a first network of a first type to a second network of a second type rnay include offloading the caK itself to the second network. In other examples, the call control services may IrKrlude advanced caH control services tt>at can be provkled more efficiently by the second network. For example, S-CSCF 110 may provide advanced call control servk«s such as call fonvarding. calt waiting, presence service, prepaki service, voice mail servKe, etc. using application server 106. Any one or more of these or ottier call control sen/Ices may be cffloaded to the second network of the second type using the methods, systems, and computer program products described herein.
Figure 2 is a fkiw chart illustrating an exemplary process of using an originating party query to offload call control servk^s from GSM network 100 to IMS netvrark 102 shown In Figure 1 according to an embodiment of the subject matter deacril3ed herein. Referring to Figures 1 and 2, a call attempt may be initiated when a user of mobile sut}scrit>er device 104 dials a phone number. A call attempt message 117 may be generated based on the dialed phone number. Message 117 may be oimmunicated to MSC108 via a t>ase statkin subsystem (BSS) 118. Message 117 may include a calling party identifier corresporKling to calling mobile subscriber device 104 and a called party klentifier corresponding to the dialed phone number. The calling party Mentiter may be the mobile statkm integrated servkss digital network (MSISDN) number and/or the intemationai mobile subscriber klaitifier (IMSI) of mobile subscriber device 104. In this wcample, the calling party kfentifier of mobile subscriber device 104 is MSISDN number 919-460-5500 and/or IMSI 310150123456789. The called party ktentifier may be any suitable destinatkui number, such as an

M^SDN of another phone. At block 200, MSC 108 may receive call attempt message 117.
At MSC 108. an IDP trigger may trigger upon detection of the call attempt by calling mobile subscriber device 104 (block 202). In partiojlar, the IDP trigger of MSC 108 may trigger upon receipt of call attempt message 117 containing the calling party identifier of subscriber device 104. In response to triggering, MSC 108 may generate a TCAP InfbAnalyzed query message 120 indicating triggering and detection of a call attempt by calling mobile subscnlier dewe 104. Query message 120 may be transmitted to STP114 (blocK 204).
At STP 112, CCO function 114 detects the call nlQJnating from mobile subscriber device 104 based upon query message 120 (block 206). In response to receivlr^ query message 120 that irulicates a call origirtating in GSM network 100, CCO fur>ctlon 114 determines an LRN associated with the calling party kientifier of rrobile subscriber devne 104. tn particular, function 114 queries CCO database 116 using Informabon Mentifying the calling party (block 208). For example, function 114 uses the calling party IMSI In query message 120 to perform a kxAup in database 116 for a call control offload LRN associated with the catling party IMSI.
Table 1 below shows exemplary entries in a database for associating a sut>scrit)er ID with a call centred ofHoad LRN.

Subscriber ID
(CgPN: MSISDN / IMSI) Call Control Offload LRN
(LRN of l-CSCF)
310150123456789 LRNx
310150123457789 LRNV
Table 1; Exemplary Entries for Associating a Sulsscriber ID with a Call
_ Control t-RN
The entries shown in Table 1 may be stored, hx example, in database 116. Database 116 may be provisioned with can control offkMd LRNs fc>r subscribers who are registered with IMS nelwoifc 102 and are therefore eltgibte to receive call control servk»3 from IMS rwtwork 102. Function 114 may use a subscriber kientifier in a TCAP query message to perform a lookup In the table for determining whether a 8ubscrit>er identifier is associated wi^ ^e call control offkHd LRN. In one example, if the sut>scriber kientifier 310150123456789 is

contained in a TCAP InfoAnatyzed query, function 114 may generate a TCAP AnalyzeRoute response message containing LRN x. In another example, if the subscriber identifier 310150123457789 is contained in a TCAP InfoAnatyzed query, function 114 may generate a TCAP AnalyzeRoute response message containing LRN y. LRN identifiers may include, but are not limited to, an E.164 formatted netiwork entity address identifier, an SS7 point code address, an Internet protocol (IP) address, or a unrfbrm rescHJns identifier (URI).
Returning to the example of STP 114 receiving message 120, calling party IMSI 310150123456789 is contained In message 120. Function 114 receives the IMSI and queries database 116 using the IMSI. In block 210. function 114 obtains in response to ttte query, routing infomiation for a node In IMS network 102. In particular, function 114 performs a lookup in database 116 using ihecatllngpartylMSItoc^tain an LRN for l-CSCF node 130. If an entry including the calling party IMSI is found, ftjnction 114 generates a TCAP AnalyzeRoute response message 124 containing the LRN in the entry. STP 112 may forward message 124 to MSC108 for ofRoa In tills example of offloading the call control servKes to l-CSCF node 130. MSC 108 generates an ISUP 1AM 126 containing LRN x as the called party numtwr, the original called party number as the GAP parameter, an FCI_PNTI parameter set to TRANSLATED, and the MSISDN of mobile subscriber device 104 as the calling party numtwr. ISUP lAM 126 is generated in response to receiving response message 124 and serves to offload call control services for the call to IMS network 102. ISUP lAM 126 is transmHled to a media gatevi^y controller (MGC) 128. tn response to receiving ISUP lAM 126, MGC 128 generates and trammits a SIP INVITE message 132 to ar\ interrogating - rail session control function (l-CSCF) node 130. Message 132 contains the original caHed party numfc>er as to the To parameter and the MSISDN of calling mobile subscriber device 104 as tiie From parameter. Further, MGC 128 uses LRN x to detenmine the RequestURI parameter address of SIP INVITE message 132. In one embodiment, the RequestfJRl address may include some or all of the LRN x value. In other emt>odtments, the RequestURI address may be determlr>ed by using ttie LRN x value to

access an LRN~to-iMS node address mapping table or database. In this manrwr the LRN x value may l>e translated into a routable l^fS network address. I-CSCF node 130 manages regte^tion, routing and forwaiding of SIP messages and charging. I-CSCF nodo 130 queries HSS134 to determine the location of the S-CSCF130 serving the c^ing party. In this case, S-CSCF 110 is assumed to be serving the calling party. Accordingly, I-CSCF node 130 sends a SIP INVITE message 133, which includes tiie same or similar content as message 132, to S-CSCF 110. In response to receiving message 132, S~ CSCF node 110 assumes management of call control services for the call.
An application server (AS) 136 may host and execute sendees, and interface with tfie S-CSCF ftjnctton using SIP. In particular, for example, AS 136 may host and execute services for the call originating from mobile subscrtoer device 104. AS 136 may l>e used as a platform for depfo^ng various services in IMS rwtwork 102 and can prowde SIP functionalrty, 3GPP AS caK control, presence information, ENUM service, prepaid service, voice mail service and other services through the use of application programming interfaces (APIs}. Further. AS 136 can operate in SIP proxy mode, SIP UA (user agent) mode or SIP B2BUA bad(-to-back user agent) mode.
In Figure 2, the LRN used to offload call control services to the IMS network was the LRN of an I-CSCF. In an alternate Implementetion of the subject matter described herein, the LRN may correspond to the S-CSCF with which riMbile subscriber device 104 is registered. Figure 3 Is a network diagram illustrating such an emt>odiment. Referring to Figure 3. a call attempt may be initiated when a user of mobile subscriber devne 104 dials a phone number. In response to initiation of the call, call attempt message 117 may be transmitted to MSC108 wtiere an lOP trigger is triggered upon detection of the call attempL In response to the triggering, MSC 108 generates and communicates TCAP trrfoAnatyzed query message 120 to STP 112.
At STP 112, ceo function 114 receives query message 120. In response to receiving query message 120. CCO function 114 determines whether an LRN associated with the oalNrtg party kientifier of mot>ile subscritier devk»104exists in database 116. Inparticular. function 114 uses the calling party IMSI in query message 120 to perform a lockup in database 116 for a call

control offload LRN associated with the calling party iMSI. The LRN may identify a node in IMS network 102 for the offload of call control services for the call.
In one implementation, database 116 may include a range-based data structure and an exception-based data structure. Tables 2 and 3 shown below DIustrate examples of a range-based data structure and an exception-based data structure that may be used to implement database 116 according to an emtiodiment of the subject matter described herein.

Subsciftier ID Range Start
(CgPN: MSISDN / IMSI)
310150123456000
310150123457000

Sulwcriber ID Range £nd
(CgPN: MSISDN / IMSI)
3101S01234S6099
310150123457999

Call Control Offload LRN
(LRNcfS-CSCF)
LRNy
LRNx

Table 2: Exemplary Entries for Associating a Subscriber 10 with a Call.
Control LRN

Subscriber ID Range (CgPN: MSISDN / IMSt) Call Control Offload LRN
(LRNofS-CSCF)
310150123456789 LRNx
310150123457254 LRNv
Tatile 3: Exemplary Exception Entries for Associating a Subscriber ID with a
Call Control LRN
The entries shown in Tables 2 and 3 may be stored, for example, in database 116. FuTKtion 114 may use a subscriber identifier ina received query message to first perform a looicup in Jabie 3 (the exception^iased data structure) for determining whether an LRN is associated with the identifier. If the lookup in the exceptiorv-based data structure fails to locate a matching entry, a lookup may then be performed in Tat>le 2 (the range-t»ased data structure). If an ervtry for the 8ubscrit>er identiTer including the LRN is found in either kwkup, it may be determined that the subscriber kJentifier is associated with an LRN. and therefore is eligible for call control offload servk%5- In one example, if ttie calling party number 310150123456123 is contained in a TCAP query message, exceptions-based kxskup will not result in a match, and function 114 will insert LRN y into the TCAP response message. Function 114 will then forward to the TCAP response nrtessage to MSC 108. In another example, if

(he called party number 310150123457123 is contained in a TCAP query message, exceptions-based lookup will not resuft in a matt^, and function 114 will insert LRN x into the TCAP response message. Function 114 will then fonward to the TCAP response message to MSC 108.
As descrit>ed above. Table 3 includes exceptions to the ranges of numbers provided in the entries of Table 2. In one example, an exception may be a number that is within the range but that has a different LRN or routing njle. For example, fhe first entry in Table 3 corresponds to subscriber identifier 310150123456789. This number is within the range of 310150123456000-310150123456999 that coriespoRds to the first entry m Table 2. However, the entries have different LRNs. Thus, an exc^tion-based table, such as that Hustrated in Table 3, may be used to flexibly allocate different routing instuction for numbers that are assigned to the associated subscritiers. If a received calRng party numt>er matches the calling party number In an entry of Table 3, the LRN in the entry of Table 3 is used for insertion into tiie TCAP response message. For example, if the received calling party number is 310150123456789, the exceptk>n-based kwkup resuKs in a match, the range-t>ased lookup is bypassed, and LRN x is used lor insertion into the response message. In another example, if the received calling party number is 310150123457254, the exception-based kwkup results in a match, the range-based lookup is bypassed, and VRH y is used for ir\sertion into ttte response message.
An LRN obtained from Table 2 or Table 3 of database 116 may be inserted in TCAP AnalyzeRoute response message 124. STP 112 may fonward message 124 to MSC 108 for offloading caH control services for the call to IMS network 102. In this example of offloading call control services for the call. MSC 108 generates an ISUP lAM 126 directed to S-CSCF 110 of IMS network 102, whk:h is associated with LRN x. ISUP lAM 126 is generated In response to receiving response message 124. tSUP lAM 126 contains routing number LRN x, the called phone niwnbef. and the calling party number. ISUP lAM 126 is transmitted to a media gateway controller (MGC) 128. In response to receiving (SUP lAM 126. MGC 128 generates and transmits to S-CSCF node 110 a SIP INVITE message 132 containing tfie called party number and the

calling party number. SIP INVITE message 132 is transmttted to S-CSCF node 110. In response to receiving message 132, S-CSCF node 110 assumes management of call control sen/ices for the caN.
As a result of an exceplicHvbased implementation, flexible assignment of 2G subscrit>ers to S-CSCF elements or other IMS network elements can be accomplished. Mother advantage of an exception-based implementation is that signaling messages may be routed directly to the appropriate S-CSCF node or another IMS network element in the IMS network without requiring involvwnent of an l-CSCF rKXie.
Any suitable routir>g node (e.g., an STP and signaling gateway), call processing node (e.g., media gateway controHer, Softswitch, gateway tandem G4fk», gateNway MSC, TDM-to-Packet gateway), or stand-alone processing platform (e.g., service control point, application server) may include a CCO functnn in accordance with the subject matter described herein. For example, a CCO function may tie included In an SS7/IP-capable STP routing node or a signaling gateway (SG) routing node. In one example, a suitable system for using an originating paity query to offload call control sennces from a first rwtwork of a first type to a second r>etwork of a second type according to the subject matter descrtoed herein may include an EAGLE STP* or an IP' SECURE GATEWAY* (both commercially available firom Tekelec of Morrisville, North Carolina).
Figure 4 is a bk>ck diagram illustrating an exemplary network routing node 112 (e.g., an STP routing node with SSP/IP gateway functionality) including a CCO functkm according to an embodiment of the subject matter described herein. Referririg to Figure 4, routing node 112 includes an interprocessor message transport (IM7) bus 400 that is the main communk:ation bus among internal subsystems within routir>g node 112. In one embodiment, tfus high-speed communications system includes two counter-rotating serial rings. A number of processing modules or cards may be coupled to IMT bus 400. In Figure 4. IMT bus 400 may be coupled to a link internee module (LtM) 402, a data commumcattons module (DCM) 404, and a database servk» module (DSM) 406, whk:h includes CCO function 114 and CCO database 119. These modules are physkraliy connected to IMT bus 400

such that signaling and ott>er types of messages may be routed internaDy between active cards or modules. For simplicity of iUustration. only a sirigle LIM, a single OCM, and a single DSM card are included in Figure 4. However, routing node 112 may indude multiple other LIMs, DCMs, DSMs, and other cards, all of which may be sJmuKaneousty connected to and communicating via IMT bus 400.
Each module 402, 404, and 406 may include an application processor and a communication processor. The communication processes may control communicationwithothermodulBsvialMTt}Us400. The application processor on each nKXlule may execute the applications or functions that reside on each module. For example, the appfication processor on DSM 406 may execute software that implemerrts CCO function 114. Similarly, the application processor on LIM 402 may execute software that implements a screening function for determining whether messages shouU t>e forwarded to DSM 406 for appfication to a CCO function.
LIM 402 may include an SS7 MTP level 1 function 408, an SS7 MTP level 2 function 410, an I/O buffer 412, a gateway screening (GWS) ftjnction 414, an SS7 MTP level 3 message handling and discrimination (HMDC) function 41S, including an application screening function 418, a message routing function 420, and a message handling and distribution (HMDT) function 422. MTP level 1 function 408 sends and receives digital data over a particular physical inlerfece. MTP level 2 function 410 provides error detection, error correction, and sequenced delivery of SS7 message padcets. I/O buffer 412 provides temporary buffering of incoming and outgoing signaling messages.
GWS function 414 examirws received message padtets and determines wtiether ttie message packets shoukJ t>e allowed in routing node 112 for processing and/or routing. HMDC function 416 performs discrimination operations, which may include determining whether the received message packet requires processing by an internal processing subsystem or is simply to t>e through switched (i.e., routed on to another node in frte rwtwork). Messages that are pemiitted to enter routing node 112 may t>e routed to other communications modules In the system or distributed to an application engine or processing module via IMT bus 400. Routing ftjnction 420 may route

received messages that are identified by HMOC function 416 as requiring routing to the appropriate LIM associated with the message destination. Exemplary routing criteria ttiat may be used by routing function 420 to route messages indude destination point code (DPC), origination point code (OPC), circuit identifier code (CIC). senice indicator (SI), inbound Irnltset, or any combination thereof. HMDT function 422 distributes messages identified by HMDC funcfon 416 as requirmg further processing to the appropriate processing module within routing node 112 for providing the processing.
Application screening function 418 may examine received message packets and determine whetfier the message padcets should be fonvarded to DSM 406 for application to CCO function 114. For example, application screening hinction 418 may determine whether a received message packet is a TCAP InfoAnalyzed query message. In another ejomple, application screening function 418 may be omitted, EBKI HMOC function 416 may forvrard a(t messages addressed to the point code of routing rKxJe 112 to DSM 406 for further processing. If it is determined that the received message should be fonvarded to DSM 406, the message is fonvarded to DSM 406 for processing by CCO Unction 114. If it is determined that the received message shouU not t>e forwarded to DSM 406, ttie message will tie routed by routing node 112 without being processed by CCO ftjnction 114. For example, HMDC ft^nction 416 may fc»ward messages that are not addressed to the point code of routir>g TTOde 112 to ^outir^g function 420, and routing ftmcUon 420 may route such messages to the LIM of DCM associated with the outbound signaling link.
DCM 404 includes functiondity for sending and receiving SS7 messages over IP signaling links. In the iOustrated exampte, DCM 404 includes a physical layer function 424, a network layer function 426, a transport layer function 428, an adaptation layer fur>ction 430, and functions 414,418, 418, 420, and 422, described above with regard to LIM 402. Physical layer Unction 424 perfomis open systems interconnect (OSI) physical layer operations, such as transmitting messages over an undertyir\g electrical or optical interface. In one exampte, physical layer functton 424 may be implemented using Ethernet. Netwoi1( layer function 426 performs operations, such as routir>g messages to other netvrark nodes. In one implementetion. network layer function 426 may

implement Internet protocol. Transport layer function 428 implements OSl transport layer operations, such as providing connection oriented transport betvmen network nodes, providing connectionless transport between network nodes, or providing stream oriented transport between network nodes. Transport layer functkin 426 may be implemented using any suitable transport layer protocol, suc^ as stream control transmission pnMocol (SCTP), transmisston control protocol (TCP), or user datagram protocol (UDP). Adaptiition layer functnn 430 perfomns operaittons for sending and receiving SS7 meuages over IP transport Adaptation layer furtction 430 may be implemented using any suitable IETF or other adaptation layer protoco). Examples of suitable protocols include MTP level 2 user peer-to-peer adaptation layer (M2PA), MTP level 3 user adaptation lay»- DSM 406 receives messages ktentiTied as requiring to CCO functkin 114. In one emt)odknent, function 114 determines a call control offioeKJ LRN associated with the calling party numt>er in a received TCAP InfoAnalyzed query message. In particular, functnn 114 may use the calling party numtier in the received message to perfonn a k>okup in database 114 for a call control LRN associated with the calling party number. The call control LRN associated with the calling party number in the received message is inserted into a TCAP response message associated with the received message. After insertion of the call control ofRoad LRN, the message can be fonvarded to a routing functnn 420 for routing to LIM 402 via IMT bus 400. If no call control offtoad LRN is found that is associated witti the calling party number, then no LRN is inserted in the response message. UM 402 may then fonward the response message to ttie MSC that originated the query message.
Offtoadir^ call control to another network may include routing at least a portion of the can over an aHemate and possiily less expensive media path. Figure 5 is a network diagram illustrating the same components illustrated in Figures 1 and 3 for offloading call control and also illustrating media path components for routing at least a portion of the media path over an alternate

network. Referring to Figure 5, a call attempt may he initiated when » user of mobile subscritwr device 104 dials a phone numtwr of PSTN phone 500. In response to initiation of the call, a call attempt message may be transmitted to a senring MSC 108 where an IDP trigger is triggered upon detection of the call attempt MSC 108 may generate and communicate a TCAP InfcAnatyzed query message to STP112. which includes CCO function 114, COO database 116. and may also include an ENUM database SCO for translating £.164-fonnatted numbers to URIs. The query message includes the callir>g party number of mobile aubsafber device 104.
At STP 112, CCO function 114 detects the call originating from mobile sub9crit}er device 104 t>a5ed upon the received query message. In response to rece'Fving the query message, CCO functim 114 determirtes a call control offload routing numt>er associated with the identifier of mobile subscriber device 104. In particular, function 114 may use a callirtg party IM6I in the query message to perform a lookup in CCOdatat>ase 11A for a/outing number associated with the caMng party IMSI. The routing number ot>tained from database 116 based on the lookup may be inserted in a TCAP AnalyzeRoute response message. STP 112 may forward the response message to MSC 108 for offloading call contrtri services for the call to IMS networtc 102.
In this example of ofnoading call control services for the call, MSC 108 generates an ISUP lAM containing the routing numt>ercorrespondir>g to a node in the IMS r>etworic. The ISUP lAM is generated in response to receiving the TCAP AnalyzeRoute response message. In one example, the ISUP lAM contains the routing number, the called phone number, and the calling party number. Further, the ISUP lAM is transmitted to MGC 128. In response to receiving the ISUP lAM, MGC 128 generates and transmits to l-CSCF node 130 a SIP INVITE message ccmtainlng ttie original called party number and the calling party numtwr. In response to receiving ttw SIP INVITE message, I-CSCF node 130 and its associated senrice kxation function (SLF) queries HSS 134 to determirw the S-CSCF serving the subscn'ber. In this example, S-CSCF 110 is identified. S-CSCF 110 directs MGC 128 to establish a media trunk twtween MGW 504 and temninatir>g erxl office switch 506 and arx>ther media trunk between serving MSC 108 and media gateway 504 by sending a SIP

ceo function 114 determines a routing number associated with the calling party identifier. In step 3, function 114 transmits to MSC 108 a TCAP AnalyzeRoute response message including the routing number. In step 4, MSC 108 transmits to MGC 128 an ISUP lAM message contains the routing number, the called phone number, and thie calling party number. In step 5, MGC 128 transmits to one of IMS network components 130,110, and 134 a SIP INVITE message containing the called party number and the calling party numtwr for offloading call control services to the IMS networtc.
In an alternate implementation of the subject matter described herein. MGC 128 may maintain a database lor mapping the LRN to an l-CSCF node. Figure 7 is a network diagram illustrating such an embodknent. Referring to Figure 7. a call attempt may be initiated when a user of calling mobile subscriber device 104 dials a phone number. In response to Initiation of tfw call, call attempt message 117 may be transmitted to MSC 108 where an IDP trigger is triggered upon detection of the call attempt. In response to the triggering, MSC 108 generates and communicates TCAP InfoAnalyzed query message 120 to STP 112.

At STT 112, ceo function 114 receives query message 120. In response to receiving query message 120, CCO function 114 determines whether an LRN associated with the identifier of calling mobile subscn'ber device 104 radsts in database 116. In particular, function 114 uses the calling party IMSI in query message 120 to perform a lockup in database 116 fbra can control offload LRN assodated with the caHing party IMSt. The LRN may identify a rwde in IMS network 102forthe offload of can control services for the call.
An LRN obtairted from database 116 may be inserted in TCAP AnalyzeRouta response message 124. STP112 may forward message 124 to MSC108 for offloading call control sen/ices for the call to IMS netwrorl(102. In this example of offloading call control services for the call, MSC 108 generates an ISUP lAM 126 directed to l-CSCF 130. which is associated with LRN x. ISUP \fiM 126 is generated in response to receiving response message 124. ISUP lAM 126 contains routing number LRN x, the called phone number, and the calling party number. ISUP iAM 126 is transmitted to MGC 128. In response to receiving ISUP IAM 126, MGC 128 generates and transmits to I-CSCF node 130 a SiP INVITE message 132 contairMng the called party number and the calling party number. Further, SIP INVITE message 132 includes a RequestURI set to address [email protected], which corresponds to l-CSCF 130. MGC 128 maintains a table that maps the LRN to an l-CSCF URI. In this example, LRN x contained in ISUP IAM 126 is mapped to the I-CSCF URI ICSCFi3}vzw.com. SIP INVITE message 132 Is transmitted to I-CSCF 130, which m turn routes SIP INVITE 133 to S-CSCF node 110. In response to receiving message 132. S-CSCF node 110 assumes management of call contrtri services for the call.
In arMither implementation of the subject matter described tierein. MGC 128 may append domain nanie information to an LRN to generate a routable URI address for routing a SIP INVITE message to an l-CSCF node. Rgure 6 is a network diagram Hlustrating such an embodiment Referring to Figure 8. ISUP IAM 126 containing LRN x is received at MGC 128. In this example, the domain name information "(givzw-com" is apperuled to "LRNx" to obtain a RequestURI for specifying l-CSCF 130. MGC 128 generates SIP INVITE 132

containing the RequestURI and send SIP INVITE 132 to l-CSCF 130 using the RequestURI.

generated in response to receiving response message 124. ISUP lAM 126 contains routing number LRN x, the called phorw number, and the calling party number. ISUP \fiM 126 is transmitted to MGC 128. In response to receiving ISUP lAM 126, MGC 128 generates and transmits to S-CSCF node 110 a SIP INVITE message 132 containing the called party number arxl the calling party number. Further, MGC 128 maintains a table that maps the LRN x to an S-CSCF URI. In this example, LRN x contained in ISUP lAM 126 is mapped to the S.CSCF URI [email protected]. StP INVITE message 122 includes a RequestURI set to address [email protected], which cturesponds to S-CSCF 110. SIP INVITE message 132 is transmitted to S-CSCF 110 using the address specified in the RequestURI. In response to receiving message 132, S-CSCF node 110 assumes management of call control services for the call.
In one embodiment, HSS 134 may be qperable to provision database 116 of STP 112 with data that associates calling party numbers with their corresponding S-CSCF nodes. Such data may altemattvely be provisioned by any other suitable IMS network administration center. In this manner, the LRN retumed by a lookup in datat>ase 116 directly identifies the corresponding S-CSCF, thereby alkiwing the SIP INVITE message to be routed directly to the S-CSCF. Further, in this manner, the l-CSCF may be effectively shieMed from traffic, thereby minimtzir^ l-CSCF resource use.
In yet arwther implementation of the subject matter described herein, MGC 128 may append domain name information to an LRN to generate a routable URI address for routing a SIP INVITE message to the S-CSCF with which motMie subscriber is registered. Figure 10 is a network diagram illustratirtg such an emtwdiment. Refening to Figure 10, ISUP lAM 126 contairring LRN x is received at MGC 128. In this example, the domain name inforrraAion "@vzw.com" is appended to 'LRNx" to obtain a RequestURI for speclf^ng S-CSCF 110. which convsponds to mobile device 104. MGC 128 generates SIP INVITE 132 containing the RequestURI and send SIP INVITE 132 to S-CSCF 110 using the RequestURI.
In yet arwther embodiment of the present inventkm, a CCO database may be co-located writh or Integrated with a number portability database (e.g., mobile number portability database, local number portabjfity database, service

provider portability database, and geographic number portability database). The associated CCO ftinction is adapted to access both the number portability data and call control offload data. In one embodiment, the CCO function may receive a query, such as a TCAP query, that contains both called party identifier and calling party identifier information. The CCO function is adapted to use tt>e caRed party identifier informalion to perform a number portabirity lookup in the number portability database, and to use the calling party Identifer information to perform a call control offload lookup in the call control offload datat>ase. The nivnber portabiTity database lookup using the called party kientifier infbmiation may yiekJ a number portability LRN value, while the call control offtoad database lookup using the calling party identrfier infomriatnn may yiekJ a caH control offk>ad LRN value. The CCO functiwi may respond to the TCAP query ortginator wiUi a single response message v&vch irwludes both the number pcMtabflHy and call control ofrk>ad LRN values. AHematively. the CCO functk)n may resporKJ to the query originator with multiple response messages that convey the LRN infomiation.
In an altemate embodiment, the CCO function may receive separate queries for number portability service and call control omoad servk». tn this case, the number poftability query ir>cludes called party identilieT information, while the caH control offk>ad query includes calling party klentifter information. The CCO furK:tk>n is adapted to use the called party identifier information to perform a numtin' portability lookup In the number portability database, and to use the calling party kientifier information to perform a call control offk>ad kKtkup in the call control offload database. The number portability database lookup using ttie called party kientifier infomiatkin may yieki a numt>er portability LRN value, while the call control offload database lookup using the calling party kferttifier information may yiekJ a call control offload LRN value. The CCO functton may respond to the TCAP query originator vtrith either a single response message vvhk:h iru:ludes both the number portability arxf call control offload LRN values, or vtrith a separate number portability response message (whk:h includes the number portabilrty LRN value) and a separate call control offload response message (which iitcludes the catl control offload LRN value).

N will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.

CLAIMS What is claimed is:
1. A method for offloading call control sendees from a first network of a first
type to a second network of a second type, the method comprising:
detecting a call originating from a caHing party in a first network of a first type;
determining routing information for a hode in a second network of a second type based on information identifying the calling party; and
offloading call cortrol services to the second network using tfie node.
2. The method of daim 1 wherein the first network comprises a global system for mobile communications (GSM) and thte second network comprises a session initiatnn protocol (SIP)-based network.
3. The method of claim 1 wherein tfie first network comprises a 2G wireless network and tfie second network comprises a StP-based networic.
A. The method of claim 1 wherein detecting a call originating from a calling party includes detecting ttie call using an initial detection point trigger set in a ruxle of the first netwcvk to detect the call originating from the calling party.
5. The method of claim 1 wherein obtaining routing information includes obtaining a routing number of tfie node in the second network.
6. The mettiod of daim 1 wtierein the node comprises a SIP node, and wherein determining routing information iTKdudes determining a routing numtwr associated with the SIP node.
7. The method of claim 6 wtierein the SIP node comprises an interrogating - call session control functior\ (l-CSCF) node.
6. The method of daim 6 wtierein the SIP node comprises a serving - call sesston control function (S-CSCF) riode.
9. The method of cta^ 8 wtierein offkmdlng call control services (ndudes offloading call control sennces for the caH to tfie S-CSCF node.
10. The method of claim 1 wherein determining a routing number inchxJes performing a lookup in an exceptk>n-^a&ed dErta structure for the routing

Information, and, in response to failing to locate ttie rou^g infomiation in the exception-based data structure, performing a lookup in a range-based data structure for the routing information.
11. The method of claim 1 comprising, at the node in ttie second network, selecting a med^ path for the call, and routing the call over the selected media path.
12. The method of claim 1 comprising detemrwiing number portability informatk)n t>ased on information identifying a caRed party associated with the caU.
13. The method of claim 12 comprlsfng communfcatfng the number portatMPty informatton to the node in the seccmd network.
14. The method of claim 12 comprising receiving a TCAP query message including the information identifying the calling party and the information identifying a called party associated vwth the cad.
15. Ttie method of claim 12 comprising receiving a first TCAP query message indudirtg the infomiation klentifying the calling party and receiving a second TCAP query message induding the information identifying a called party associated wUh the cat).
16. The method of claim 1 wherein offk}ading call control services includes offk>ading one or more of the call, caH forwarding, call waitirtg, presence service, prepaU service, and voice mail service.
17. A method for offloading a call from a first r>etwork of a first type to a second network of a second type, the method compnsing:
detecting a call originating from a calling party in a first networV of a first type;
determining routing information for a rKxfe in a second rtetwoik of a second type based on Information identifying the calling party; and
offtoading the call to the second network u$ir>g the node.
18. A method for provkJing call control offload Informatnn to a requestor, Vhe
method compnsing:
, receivirtg from a query originator a query requesting call control offload routing informaton that includes a calling party identifier:

perfonning a lool(up in a caN control offload database using the calling party identiAer to obtain call control offload routing information; and
returning ttie call control offload routing infomnation to the query originator.
19. A system for offloading call control senrices from a first networtc of a first
type to a second network of a secorKl type, the system comprising;
a communications module configured to receive a query message indicating detection of a call originating frcwn a calling party in a first network of a ftrst type;
a call control offload function configured to d^ennin^ routing information for a node in a secorKl networic of a second type based on information identifying ttie calling party and configured to offkiad call control services to the second network u«ng Uie rK>de.
20. The system of claim 19 wherein the first network comprises a public switched telephone network (PSTN) and the secwid network comprises a sesskm initiation protocol (SIP)-t»8ed network.
21. The system of daim 19 wtwrein the first network comprises a 2G wireless networic and the secorvj network comprises a SIP-based network.
22. The system of claim 19 wherein the fKxIe comprises a SIP node.
23. The system of daim 22 wtierein the SIP node comprises an interrogating - call session control function (l-CSCF) node.
24. The system of claim 22whenBin the SIP node comprises a serving - call session control function (S-CSCF) node.
25. The system of daim 19 comprising a routing node, wherein the communicatk>n module and the can control offload function are located in ttie routing node.
26. The system of daim 19 comprising a caH cor>trol offlo»l datatiase acces8it>le by the call contrc^ offtoad function for locatirtg the routing infonmation.
27. The system of claim 26 wherein the caU control offload database includes an exceptnn-based data stnicture and a range-based data

structure, and wherein the call control ftmction is adapted to access the exception-based data structure to locate ttie routir^ information and, in response to locating ttie routing information in ttie exceptlorv-based data structure, to search a range-tiased data structure for the routing information.
28. The system of daim 19 wtierein the communications module is configured to receive irrformation IdentifyHig a called party associated with ttie call, and wherein the call control offload function is configured to determine number portability infomiation l>ased on the infonnation identifying the called party associated with the call.
29. The system of claim 28 wherein ftm call control offload function is configured to communicate the numtier portability information to the n«le in the second netwoA.
30. The system of claim 28 wherein the query message comprises a TCAP query message fnduding the information identrfyirni the calling party and the infonnation identifying a called party associated with the call.
31. The system of claim 28 wherein the query message comprises a first TCAP query message including the information identifying the callir^ party, and wherein the communications module is configured to receive a second TCAP query message Including the information identifying a called party associated with the call.
32. A system for providing call control offload information to a requestor, the system comprising:
a call conUol offload function associated with a first network and configured to:
receive from a query originator a query requesting call control offload routing information that includes a calling party identifier;
perform a lookup in a can control offload database using the callirig party identifier to otitain call control offload routing information; and
return ttie call control offload routing information to the query originator.

33. A computer program product comprising computer executable
instructions embodied in a computer readable medium for perfwming
steps comprising:
detecting a call originating from a caHtng party in a first network of a first type;
detemiining routir>g information for a node in a second netvvorit of a second type tiased on information Identif^ng the caSIng party, and
offloading call control services to the second network using the node.
34. A computer program product comprising consular executable
instructnns embodied in a computer readable nwdium for performing
steps comprising:
receiving from a query originator a query requesting call control offkiad routing information that kicludes a calling party kientifier;
performing a lookup in a call control offkiad database using the calling party kJentifier to obtain call control offload routing information; and
reluming the call conbol offtoad routing informatnn to the query originator.

Documents:

http://ipindiaonline.gov.in/patentsearch/GrantedSearch/viewdoc.aspx?id=v0Rig2FskhqDbK4X/2Wa+Q==&loc=egcICQiyoj82NGgGrC5ChA==

« Previous Patent

Next Patent »

Patent Number

269735

Indian Patent Application Number

1107/CHENP/2009

PG Journal Number

45/2015

Publication Date

06-Nov-2015

Grant Date

03-Nov-2015

Date of Filing

27-Feb-2009

Name of Patentee

TEKELEC, INC.

Applicant Address

5200 PARAMOUNT PARKWAY, MORRISVILLE, NC 27560

Inventors:

#	Inventor's Name	Inventor's Address
1	MARATHE ROHINI	111 PAHLMEYER PLACE, CARY, NC 27519
2	MARSICO PETER J.	1415 PRESTON SPRING LANE, CHAPEL HILL, NC 27516

PCT International Classification Number

H04Q7/00

PCT International Application Number

PCT/US2007/016974

PCT International Filing date

2007-07-30

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	11/881,726	2007-07-27	U.S.A.
2	60/834,103	2006-07-28	U.S.A.