Patent Publication Number: US-8989179-B2

Title: System and method for originating a call via a circuit-switched network from a user equipment device

Description:
CLAIM OF PRIORITY UNDER 35 U.S.C. §120 &amp; 37 C.F.R. §1.78 
     This nonprovisional application is a continuation application claiming the benefit of the following prior United States patent application entitled: “SYSTEM AND METHOD FOR ORIGINATING A SIP CALL VIA CIRCUIT-SWITCHED NETWORK FROM A USER EQUIPMENT DEVICE”, application Ser. No. 12/732,041, filed on Mar. 25, 2010, pending, which is a continuation of application Ser. No. 11/740,102, filed on Apr. 27, 2007, now issued as U.S. Pat. No. 7,710,950, which in turn is a Continuation-In-Part (CIP) of and claims priority to “SYSTEM AND METHOD FOR EFFECTUATING A SIP CALL IN A NETWORK ENVIRONMENT INCLUDING IMS”, application Ser. No. 11/347,874, filed on Feb. 6, 2006, now issued as U.S. Pat. No. 7,830,868 and is also a CIP of and claims priority to “SYSTEM AND METHOD FOR MANAGING CALL CONTINUITY IN IMS NETWORK ENVIRONMENT USING SIP MESSAGING”, application Ser. No. 11/542,462, filed on Oct. 3, 2006, now issued as U.S. Pat. No. 7,995,565, each of which foregoing applications is hereby incorporated by reference herein. 
     CROSS REFERENCE TO RELATED APPLICATION(S) 
     This patent application discloses subject matter that is related to the subject matter of U.S. patent application entitled: “SYSTEM AND METHOD FOR MANAGING CALL ROUTING IN A NETWORK ENVIRONMENT INCLUDING IMS”, application Ser. No. 11/328,875, filed on Jan. 10, 2006, now issued as U.S. Pat. No. 7,769,000 which is hereby incorporated by reference herein. 
    
    
     FIELD OF THE TECHNOLOGY 
     The present patent disclosure generally relates to call routing in communications networks. More particularly, and not by way of any limitation, the present patent disclosure is directed to a system and method for managing call routing in a network environment including a circuit-switched (CS) network and an IP multimedia subsystem (IMS) network, wherein a CS-originated IP call (e.g., based on the Session Initiation Protocol or SIP) is to be routed using the IMS network infrastructure. 
     BACKGROUND 
     Today&#39;s advanced communication devices are capable of seamlessly operating in a packet-switched IP network domain (using, for example, wireless LAN (WLAN) or Wi-MAX networks, etc.) as well as a circuit-switched cellular network domain. To facilitate such capability, current 3 rd  Generation Partnership Project (3GPP) standards specify a new, IP-based network architecture referred to as the IP multimedia subsystem (IMS) which allows a communication device (referred to as user equipment or UE) to initiate calls to both IP-only subscribers and conventional circuit-switched telephony subscribers using either of the domains. There may arise a situation, however, where a wireless device, i.e. a UE device in 3GPP, is able to make a voice call to a called party using the circuit-switched network domain only because either no packet-switched network is available or the available networks in the packet-switched domain do not support the Voice-over-IP (VoIP) service. In such a situation, if the called party happens to be an IP-only subscriber and is identified with a Uniform Resource Indicator (URI), the originating UE may not be able to make the IP-based call since the UE device can effectuate only E.164 number-based calls while operating in the circuit-switched domain. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A more complete understanding of the embodiments of the present patent disclosure may be had by reference to the following Detailed Description when taken in conjunction with the accompanying drawings wherein: 
         FIG. 1  depicts a network environment including circuit-switched network infrastructure and IM multimedia subsystem (IMS) infrastructure wherein an embodiment of the present patent disclosure may be practiced; 
         FIG. 2  depicts a flowchart associated with one or more exemplary embodiments of the present patent disclosure; 
         FIGS. 3A and 3B  depict exemplary message flow diagrams for originating a SIP call by employing a SIP Invite message with a SIP-URI of the called party in the Request-URI, for mapping with a dynamically-allocated IP multimedia routing number (IMRN) at an application server (AS) node; and 
         FIG. 4  depicts a block diagram of an embodiment of a communications device operable for purposes of the present patent disclosure. 
     
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
     Methods and apparatus for originating a Session Initiation Protocol (SIP) call from a user equipment (UE) device in a network environment including a circuit-switched (CS) network and an IP multimedia subsystem (IMS) network to a called party are disclosed. When the SIP call is originated from the UE device in the CS network domain, a SIP Invite message which includes a SIP Uniform Resource Indicator (URI) or Tel URI of the called party is sent from the UE device to an application server (AS) node in the IMS network. At the AS node, a pool of E.164 numbers are maintained as IP multimedia routing numbers (IMRNs) which are utilized for mapping to or otherwise associating with called party URIs. The AS node dynamically allocates a select E.164 number with respect to the called party&#39;s URI received from the UE device, and returns it to the UE device in a SIP Response message, e.g., a SIP  380  (Alternative Service) message. Subsequently, the dynamically-allocated E.164 number is sent from the UE device in a call setup message for identification of the URI and other suitable call information at the AS node. Thus, the dynamically-allocated E.164 number is utilized for routing the SIP call towards the called party upon interrogating the SIP URI-IMRN mapping, whereupon it may be released back to the pool of IMRNs for future use. Appropriate timers may be provided at the device and AS node endpoints so that it can be verified whether a call reference number associated with the call remains valid (e.g. it has not timed out) or the dynamically-allocated IMRN remains valid (e.g. it has not timed out). Optionally, the released IMRN may be quarantined for a period of time. 
     A system and method of the present patent disclosure will now be described with reference to various examples of how the embodiments can best be made and used. Like reference numerals are used throughout the description and several views of the drawings to indicate like or corresponding parts, wherein the various elements are not necessarily drawn to scale. Referring now to the drawings, and more particularly to  FIG. 1 , an exemplary network environment  100  is depicted wherein an embodiment of the present patent disclosure may be practiced for routing a SIP call originated by a UE device in a circuit-switched network or domain. As depicted, the network environment  100  includes an access space  104  comprised of a number of access technologies available to a plurality of UE devices  102 - 1  through  102 -N. For purposes of the present disclosure, a UE device may be any tethered or untethered communications device, and may include any personal computer (e.g. desktops, laptops, palmtops, or handheld computing devices) equipped with a suitable wireless modem or a mobile communications device (e.g. cellular phones or data-enabled handheld devices capable of receiving and sending messages, web browsing, et cetera), or any enhanced PDA device or integrated information appliance capable of email, video mail, Internet access, corporate data access, messaging, calendaring and scheduling, information management, and the like. Preferably, the UE device is capable of operating in multiple modes in that it can engage in both circuit-switched (CS) as well as packet-switched (PS) communications, and can transition from one mode of communications to another mode of communications without loss of continuity. 
     The access space  104  may be comprised of both CS and PS networks, which may involve wireless technologies, wireline technologies, broadband access technologies, etc. For example, reference numeral  106  refers to wireless technologies such as Global System for Mobile Communications (GSM) networks and Code Division Multiple Access (CDMA) networks, although it is envisaged that the teachings hereof may be extended to any 3 rd  Generation Partnership Project (3GPP)-compliant cellular network (e.g. 3GPP or 3GPP2) as well. Reference numeral  108  refers to broadband access networks including wireless local area networks or WLANs, Wi-MAX networks as well as fixed networks such as DSL, cable broadband, etc. Also exemplified as part of the access space  104  is the conventional wireline PSTN infrastructure  110 . 
     An IP multimedia subsystem (IMS) core network  112  is coupled to the various access networks set forth above, including any CS-based networks. As is well known, the IMS standard defined by the 3GPP is designed to allow service providers manage a variety of services that can be delivered via IP over any network type, wherein IP is used to transport both bearer traffic and SIP-based signaling traffic. Broadly, IMS is a framework for managing the applications (i.e. services) and networks (i.e. access) that is capable of providing multimedia services. IMS defines an “application server” to be the network element that delivers services subscribers use, e.g. voice call continuity (VCC), Push-To-Talk (PTT), IMS Centralized Services (ICS) etc. IMS manages applications by defining common control components that each application server (AS) is required to have, e.g. subscriber profiles, IMS mobility, network access, authentication, service authorization, charging and billing, inter-operator functions, and interoperation with the legacy phone network. 
     It should be understood that whereas IMS is defined by the 3GPP standards body which mainly addresses GSM networks, another group, 3GPP2, is involved in defining a closely analogous architecture referred to as Multimedia Domain (MMD). MMD is essentially an IMS for CDMA networks, and since MMD and IMS are roughly equivalent, the term “IMS” may be used in this present patent disclosure to refer collectively to both IMS and MMD where applicable. 
     Continuing to refer to  FIG. 1 , reference numerals  114 - 1  to  114 -N refer to a plurality of AS nodes operable to support various services, e.g. VCC, PTT, ICS etc. as alluded to hereinabove. Furthermore, in order to effectuate call control of a SIP call using CS as the voice bearer, one of the AS nodes, e.g. AS  114 -(N−1), may be provided for implementing functionality referred to as IMS Centralized Services Control Function (ICCF). ICCF is operable as an IMS application server element that resides in the home IMS network and tracks all call sessions and related mobile Voice-over-IP (VoIP) bearer traffic, between CS and IMS domains. Additional details regarding the functionality of AS  114 -(N−1) may be found in the pending U.S. patent application entitled “SYSTEM AND METHOD FOR MANAGING CALL ROUTING IN A NETWORK ENVIRONMENT INCLUDING IMS”, application Ser. No. 11/328,875, filed Jan. 10, 2006, referenced hereinabove. 
     Additionally, another AS node, AS  114 -N, is provided as part of the core IMS network  112  for facilitating routing of IP/SIP calls originated by one of the UE devices in the CS domain while connectivity in the PS domain is not available or the available PS networks are not capable of supporting the VoIP service (e.g. due to bandwidth limitations). Appropriate database structures (e.g. DB  122 ), timer mechanisms (e.g. timer  124 ) and suitable logic  126  may be provided in association with AS  114 -N for purposes of configuring and managing a pool of IP multimedia routing numbers (IMRNs) from which a select IMRN may be dynamically-allocated for purposes of SIP call routing as will be described in greater detail below. 
     In accordance with the teachings of the present patent disclosure, AS  114 -N is preferably provided with appropriate logic/structure/software/firmware module(s), such as call continuity control function (CCCF)  116 , network domain section (NeDS)  118 , and gsm service capability feature (gsm SCF)  120  for performing the following: maintaining a pool of E.164 numbers that are operable as IMRNs which terminate on the AS node, wherein a select E.164 number may be mapped to the received information in the SIP Invite message, including but not limited to, a called party&#39;s SIP URI or Tel URI, P-Preferred Identity, Privacy Indication, and Network Access Info header; dynamically allocating the select E.164 number to a received called party&#39;s URI (e.g. SIP URI or Tel URI) and other received information and providing the select E.164 number to the originating UE device via a SIP Response message; verifying that the select E.164 number has not timed out when that select E.164 number is returned (via conventional CS call setup) to AS  114 -N for effectuating a SIP call session with respect to the called party; and optionally, quarantining the select E.164 number for a period of time upon releasing it back to the pool for future use. 
     Note that E.164 is indicative of the International Telecommunications Union (ITU) telephone numbering plan, which specifies how and by whom telephone numbers are assigned. The format and notation of E.164 telephone numbers is specified in the ITU standard E.123, for example. To manage a pool of dynamically-allocable IMRNs, the AS node (e.g. AS  114 -N) may be configured in a number of ways with respect to the E.164 numbers. For example, a particular E.164 number may be provided as a “starting address” number of an IMRN range. Another E.164 number may operate as a range delimiter with respect to the IMRN range. To allow flexibility, it may be desirable to provide for different pools of IMRNs to be configured from different number ranges. Further, appropriate timer mechanism(s) may be implemented at AS  114 -N in order to ensure that the allocated IMRNs remain valid (e.g. they have not timed out, that is, they are used within appropriate time limits) or suitable quarantine times are applied. As will be described in detail below, management of timers associated with IMRNs at AS  114 -N and timers associated with call reference numbers at the originating UE device allows for dynamic provisioning of IMRNs that could be used for effectuating SIP calls by the UE device operating in the CS domain. 
       FIG. 2  depicts a flowchart of an exemplary embodiment of an overall methodology of the present patent disclosure for effectuating a CS-originated SIP call by a UE device with respect to a called party identified by a URI (e.g. a SIP URI or Tel URI). The SIP call is initiated by the end user of the UE device, or the originating party. Preferably, the originating party either enters the URI via a suitable interface (e.g. MMI) or selects it from a list stored in the UE. As is well known, a typical SIP address may take on the form of sip: &lt;username&gt;@&lt;hostname&gt;, which may include additional syntax elements and parameters such as those described in, e.g. RFC 3261 entitled:  SIP: Session Initiation Protocol  and Internet Draft entitled  Obtaining and Using Globally Routable User Agent  ( UA )  URIs  ( GRUU )  in the Session Initiation Protocol  ( SIP ) (draft-ietf-sip-gruu-06) (Expires: Apr. 23, 2006). 
     Note that a “Tel URI” is presently defined in Request For Comments (RFC) 3966 (December 2004). Some examples of Tel URIs are as follows: (1) tel:+1-201-555-0123: This URI points to a phone number in the United States. The hyphens are included to make the number more human readable; they separate country, area code and subscriber number; (2) tel:7042;phone-context=example.com: The URI describes a local phone number valid within the context “example.com”; and (3) tel:863-1234;phone-context=+1-914-555: The URI describes a local phone number that is valid within a particular phone prefix. 
     At block  202 , various pieces of information relating to the SIP call (which may be collectively referred to as “call information” herein). The call information may include information such as a call reference number associated with the call, called party&#39;s SIP URI (or, the B-URI), Opaque parameter (if available), GRID parameter (if available), additional URI-related information (e.g. display name), calling party&#39;s SIP URI (or, the A-URI), Opaque parameter, privacy indicator, network access info header etc. If the calling party sends a B-URI that comprises an Address of Record (AOR) as well as Opaque and GRID parameters, they will be provided as part of the call information. Additionally, if the calling party sends its own URI comprising AOR, Opaque and GRID parameters, they will also be provided in the call information. 
     A timer may be initiated on the UE device that is used for monitoring at least a portion of the call information that is transmitted by the originating UE device as described above. In particular, the timer may be implemented for monitoring the elapsed time since a particular call reference number is generated and forwarded to the IMS network node. At the IMS network node, an IMRN selected from the pool of IMRNs is dynamically associated with respect to the call reference number, wherein the IMRN is mapped to the at least a portion of the call information, e.g. the received called party&#39;s SIP URI (block  204 ). In some embodiments, the IMRN may be mapped to all the received SIP call information. Also, a timer may be started at the network node for monitoring a time-to-live variable associated with the dynamically-allocated IMRN. 
     Thereafter, the dynamically-allocated IMRN is provided to the UE device via a SIP  380  (Alternative Service) Response message. Upon receipt of the SIP  380  (Alternative Service) Response message which includes the dynamically-allocated IMRN at the UE device, the elapsed time associated with the call reference number is monitored to ensure that it is not stale (block  206 ). The dynamically-allocated IMRN is accepted by the UE device if the time elapsed satisfies a select condition, e.g. within a time-to-live value (block  208 ). In response, appropriate call setup is then initiated by the UE device using the dynamic IMRN, whereby the accepted IMRN is returned to the AS node since it terminates thereat. Upon receipt of the IMRN at the AS node, its time-to-live variable is monitored to ensure that it has not timed out (block  210 ). Thereafter, the called party&#39;s SIP URI or Tel URI (and any other suitable SIP information originally received that is mapped to the dynamically-allocated IMRN) is utilized by the AS node for effectuating the SIP session with the called party by producing and sending a SIP Invite message (e.g. inserting the A-party URI, Privacy indicator, B-party URI, Opaque parameter, etc., in the SIP Invite message and causing it to be sent to the called party). In one implementation, the dynamic IMRN may optionally be returned back to the pool of IMRNs, wherein it may be quarantined for a certain period of time before it is reused or becomes available for future use (block  212 ). 
     Based on the foregoing, those skilled in the art will appreciate that when the call information, i.e. called party&#39;s SIP URI or Tel URI, call reference number, etc. is sent by the UE device to the serving AS node, appropriate logic at the AS node may create a record that maps the received call information to an E.164-based IMRN, which is transmitted back to the UE device. Upon correlating the IMRN with the call reference number, the UE sets up a call using the IMRN that terminates on the AS node. The IMRN is then interrogated against the record to retrieve the called party&#39;s URI for establishing a SIP session with the called party (i.e. between the calling party (UE device) identified by the A-party address and the called party identified by the B-party address). 
     It should be further recognized by those skilled in the art that the message flow between the UE device and the home IMS network&#39;s AS node may be mediated through a number of other appropriate network infrastructure elements, and may be implemented in a number of ways depending on the device capabilities as well as the network features and protocols being used. Typically, the message flow may be mediated via network elements such as a mobile switching center (MSC) and a media gateway control function (MGCF) element disposed between the UE device and its home IMS AS node operable to facilitate CS-originated SIP calls. 
       FIG. 3A  depicts a message flow embodiment  300 A for effectuating a CS-originated SIP call based on dynamic IMRN allocation where SIP messaging is implemented. A wireless UE device  302  having the CS domain and IMS domain modes of functionality is operable to generate a SIP Invite message  312  towards an application server (AS) node  308  in response to detecting that a SIP call is being initiated from UE device  302  in the CS domain. As described earlier, the SIP Invite message  312  includes applicable call information such as call reference number, called party&#39;s SIP URI, additional URI information, and the like, e.g. A-party AOR in the P_Preferred Identity, Privacy Indicator Opaque parameter, GRID parameter, etc. As described above, the originating party either enters the URI (or SIP address) or Tel URI via a suitable interface (e.g. MMI) or selects it from a list stored in the UE to initiate the call. 
     The SIP Invite message  312  may further include an indicator in an indicator field that indicates whether the message is for a circuit-switched (CS) mobile-originated (MO) call (i.e. whether UE device  302  intends to make this call via CS domain). For example, a new Network-Access-Info value such as “GERAN-CS” may be utilized. Alternatively, a new feature tag or new URI parameter may be provided in the SIP Invite message. Note, however, that an indication may be assumed merely from the inclusion of the SIP URI or Tel URI of the called party (“B-party”) in the SIP Invite message. In one preferred embodiment, the TARGET address in the SIP Invite message is populated with the SIP URI or Tel URI of the called party or B-party. In this case, a SIP URI field of the SIP Invite message is populated with a public service identifier (PSI) of the AS node. A cause value in the SIP Invite message will be set appropriately to indicate that a radio bearer channel for the session is to be established over the CS domain. 
     A suitable timer mechanism  310  may be initiated at the UE device in order to monitor a time-to-live variable associated with the call reference number. It should be appreciated that this timer may be provided in addition to normal SIP timers as this operation is known to provide a SIP  380  Response with specific information within a certain timeframe. 
     Responsive to the Invite message  312 , which may be mediated via I-CSCF and/or S-CSCF nodes, AS node  308  disposed in the user&#39;s home IMS network is operable to launch SIP-URI logic  313  for generating and populating a suitable SIP  380  (Alternative Service) Response message (e.g. SIP  380  Response message) as described above. Upon verifying that the user is allowed to do a SIP call and the Invite message includes the proper CS MO indicator, the network node (in this example, the IMS AS node) dynamically allocates a select IMRN mapped to the call information or parameters (e.g. A-party AOR in the P_Preferred Identity, Privacy Indicator Opaque parameter, GRID parameter, etc.) and returns it back to UE device  302  via SIP  380  message  316 . Again, the dynamically-allocated IMRN may be referred to as an IMS Centralized Service Routing Number or “ICSRN.” The dialog information contained in the Invite Header or in the body of the Invite may be used to correlate the call. 
     A suitable timer mechanism may be started (block  314 ) at the AS node  308  in order to monitor a time-to-live variable associated with the dynamically allocated IMRN. After verifying that the call reference has not timed out based on the UE device&#39;s timer mechanism, responsive to receipt of the SIP  380  Response message  316 , UE device  302  initiates a call setup message  320  that includes the dynamic IMRN (or ICSRN). In response, MSC  304  generates an Initial Address Message (IAM)  322  towards MGCF  306 . A SIP Invite message  324  that contains the IMRN is generated by MGCF  306  towards the AS node  308 , which then uses the IMRN mapping for establishing the SIP session or call to the called party (not shown). It is recognized that various intermediate SIP messages and resource allocation/reservation negotiations may take place between MGCF  306  and the called party subsequent to SIP Invite  324 , which are not described in particular detail herein. Also, additional ISUP messaging that may take place before a bearer path is established between the UE device  302  and the called party understood by those skilled in the art is not shown herein. 
     Upon receipt of the dynamically-allocated IMRN via SIP Invite  324  at the AS node  308 , the timer mechanism may be stopped (block  326 ) to verify if the IMRN has timed out. If timed-out, the SIP Invite message may be discarded and the call routing process may be terminated. If the IMRN has not timed out, the AS node  308  may establish the SIP session based on the IMRN correlation. After using the IMRN for correlation, it may be returned to the IMRN pool, wherein a quarantine timer may be started (block  328 ) such that the IMRN is prohibited from further use until the quarantine timer is stopped after a period of time (block  330 ). 
     As pointed out previously, the timer mechanism at the device side may also be used to ensure that the call reference number has not timed out (e.g., using the timer mechanism  318 ), which reference number is used by the UE device to correlate the information received from the network node (e.g., dynamic IMRN). If the timer expires before the same reference number is received back from the network node, the UE device may reattempt the call process a predetermined number of times (e.g. five attempts), after which if no response has been received, the call procedure may be deemed to have failed. In other words, if the UE device receives a reference number that is no longer valid, it may be discarded and the call procedure may be terminated. 
       FIG. 3B  depicts a message flow diagram  300 B for a mobile-originated SIP call by employing a SIP Invite message with a SIP-URI in the Request-URI wherein certain intermediary nodes in a home network  350  are exemplified. Similar to the flow diagram embodiment  300 A described above, UE device  302  is operable to generate a SIP Invite message  356  towards I-CSCF  352 , wherein the SIP Invite message includes a SIP-URI of the called party contained in the TARGET field. This Invite message is propagated to AS node  308  either directly as SIP Invite  362  or via S-CSCF  354  by way of SIP Invite messages  358  and  360 . As described previously, SIP  380  (Alternative Service) Response message  364  having the ICSRN is generated by AS node  308  towards S-CSCF  354 , which is then propagated to UE device  302  via SIP response  366 . A call setup message  368  having the ICSRN is provided to MSC  304 , which initiates a CS origination procedure  370 . IAM messaging  372  from MSC  304  towards MGCF  306  is operable to generate SIP Invite  374  towards I-CSCF  352 , which may be directly propagated to AS node  308  as Invite message  380  having the ICSRN. Alternatively, I-CSCF  352  first provides a SIP Invite  376  to S-CSCF  354  which then propagates a SIP Invite  378  to AS node  308 . Regardless, once the ICSRN is received at the AS node  308 , appropriate call correlation is made to establish the SIP call between the UE and the called party. 
     Note that, in one variation of the technique described in relation to  FIGS. 2 ,  3 A, and  3 B, the E.164 number is not dynamically allocated but rather merely identified, calculated, or otherwise selected in accordance with any suitable algorithm. 
     Elaborating on the techniques of the present disclosure in further detail, when the UE device detects that it needs to invoke CS call origination, it may produce and send a SIP Invite message to an R-URI that is known to terminate at the IMS centralized services node. In this case, the Target parameter of the SIP Invite message is populated with the B party address (SIP URI or Tel URI) and the Cause value of the SIP Invite message is set to indicate that the call needs to be set up over CS. Alternatively, the R-URI may be populated with the B-party address, and may further include an indicator in an indicator field that indicates whether the message is for a circuit-switched (CS) mobile-originated (MO) call (i.e. whether UE device  302  intends to make this call via the CS domain). For example, a new Network-Access-Info value such as “GERAN-CS” may be utilized. Alternatively, a new feature tag or new URI parameter may be provided in the SIP Invite message. In the first case, the SIP Invite message contains the GRUU of the UE/Public ID combination. The P-Preferred-ID is set to the calling line identity (CLI) associated with the user or subscriber of the UE device for identification in the CS network. The B-Party Public user address (Tel URI, SIP URI) is set in SIP URI Target parameter, and the cause value indicates CS bearer required=YYY. 
     Note that when the Target parameter is used to carry the B party address, the SIP R-URI may be one of many that has been provisioned in the UE device to indicate the ICCF. If so, the UE device could choose one of these at random, the URI could have some indicia that identify a priority order. 
     An example is provided below: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 INVITE sip:icenetworknode@example.com;\ 
               
            
           
           
               
               
            
               
                   
                 target=sip:+15555551002%40example.com;user=phone;\ 
               
            
           
           
               
               
            
               
                   
                 cause=YYY  SIP/2.0 
               
            
           
           
               
               
            
               
                   
                 P-Preferred-Identity: &lt;tel: +1-555-1001&gt; 
               
               
                   
                 P-Access-Network-Info: 3GPP-GERAN; 
               
               
                   
                 Privacy: none 
               
            
           
           
               
               
            
               
                   
                 From:Alice 
               
               
                   
                 &lt;sip:+15551001@example.com;user=phone&gt;;tag=9fxced76sl 
               
            
           
           
               
               
            
               
                   
                 Supported: gruu 
               
               
                   
                 To: sip:+15555551002@example.com;user=phone 
               
               
                   
                 Call-ID: c3x842276298220188511 
               
               
                   
                 CSeq: 1 INVITE 
               
               
                   
                 Max-Forwards: 70 
               
               
                   
                 Contact: &lt;sip:alice@192.0.2.1&gt; 
               
               
                   
                 ;+sip.instance=“&lt;urn:uuid:f81d4fae-7dec-11d0-a765- 
               
            
           
           
               
               
            
               
                   
                 00a0c91e6bf6&gt;” 
               
            
           
           
               
               
            
               
                   
                 Content-Type: application/sdp 
               
               
                   
                 Content-Length: *Body length goes here* 
               
               
                   
                   
               
            
           
         
       
     
     If the R-URI is set to the B-party, the invite shall contain the GRUU of the UE/Public ID combination. The P-Preferred-ID shall be set to the calling line identity that the user wants to be known as in the CS network. The Network-Access-Info header shall be set to a value to indicate that the call is SIP controlled, but the radio bearer goes over the CS domain, in this example the setting is 3GPP-GERAN-CS, another example could be 3GPP-UTRAN-CS. 
     An example is provided below: 
                                            INVITE sip: sip:+15555551002%40example.com;user=phone;\                         SIP/2.0                         P-Preferred-Identity: &lt;tel: +1-555-1001&gt;           P-Access-Network-Info: 3GPP-GERAN-CS;           Privacy: none           From:Alice                 &lt;sip:+15551001@example.com;user=phone&gt;;tag=9fxced76sl                         Supported: gruu           To: sip:+15555551002@example.com;user=phone           Call-ID: c3x842276298220188511           CSeq: 1 INVITE           Max-Forwards: 70           Contact: &lt;sip:alice@192.0.2.1&gt;           ;+sip.instance=“&lt;urn:uuid:f81d4fae-7dec-11d0-a765-                 00a0c91e6bf6&gt;”                         Content-Type: application/sdp           Content-Length: *Body length goes here*                        
Upon receipt of a 380 (Alternative Service) response to the SIP Invite message, the UE shall use the ICSRN that was provided in the 380 (Alternative Service) response as the E.164 number to set up a CS call to. This E.164 number shall be in the contact header of the 380 (Alternative Service) or in fact it could be in the XML body.
 
     Upon receipt of the R-URI, the S-SCSF recognizes that the Invite is for the IMS centralized services node that has been assigned to the UE and forwards it to the this AS node. IMS centralized service node configuration information includes (a) the ICSRN E.164 start address number; and (b) number of ICSRN to be allocated or the last E.164 start address number. To allow for flexibility in numbering plan, there maybe more occurrences of (a) and (b) allowing pools of ICSRN to be allocated from different number ranges. In addition to (a) and (b), other configuration information may include (c) life time an ICSRN can live for; and (d) quarantine time of an ICSRN—how long after an ICSRN has been assigned back to the ICSRN pool it cannot be used for. 
     Behavior at the IMS centralized service node is discussed. If the IMS centralized services node receives an Invite that contains an R-URI is shall examine that R-URI to determine if that R-URI is associated with a request to initiate a MO call over CS. An alternative implementation is that the IMS centralized services node will examine the P-Access-Network-Info header. If it is set to GERAN-CS or some other value to indicate call-set-up over CS, the IMS centralized services node shall assume the received Invite shall be terminated here and the behavior as follows shall take place. 
     The IMS centralized services node will assign a ICSRN to the received GRUU. The following represents a possible mapping of the ICSRN to the other information elements. 
                                            ICSRN --                         GRUU           P-Asserted ID(s)           B-Number (SIP URI or Tel URI)                        
The IMS centralized services node will respond to the INVITE request with a 380 (Alternative Service) response. An example of coding of this response can be found below, which shall include the ICSRN, the Radio Access type that the handover shall be made to that includes (but is not limited to) “IEEE-802.11”/“IEEE-802.11a”/“IEEE-802.11b”/“IEEE-802.11g”/“3GPP-GERAN”/“3GPP-UTRAN-FDD”/“3GPP-UTRAN-TDD”/“ADSL”/“ADSL2”/“ADSL2+”/“RADSL”/“SDSL”/“HDSL”/“HDSL2”/“G.SHDSL”/“VDSL”/“IDSL”/“3GPP2-1X”/“3GPP2-1X-HRPD”/“DOCSIS”/token, 3GPP-GERAN CS, 3GPP-GERAN PS, 3GPP-UTRAN CS, 3GPP-UTRAN PS, 802.11b, 802.11a, 802.11g, EVDO, CDMA1X, WiMAX, etc. The ICSRN is also contained in the Contact Header. It will start a timer against the allocation of the ICSRN that will be cancelled on receipt of an Invite that origination was from a MGCF with the ICSRN as the R-URI. If the timer expires the ICSRN shall be put into a quarantine pool.
 
     If the IMS centralized services node receives a subsequent request from the same UE, identified by the GRUU in the Invite, the IMS centralized services node may do the following: (a) Resend the same ICSRN and reset the timer; (b) Allocate a new ICSRN, start a timer associated with that ICSRN and put the old put into the quarantine pool; and (c) Reject the request altogether and put the old put into the quarantine pool. 
     The following is exemplary code for coding a 380 Alternative Service Response: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;!ELEMENT ICSRN EMPTY&gt; 
               
               
                 &lt;!ATTLIST ICSRN 
               
            
           
           
               
               
            
               
                  TYPE (SIP_URI | Tel_URI) 
                 #REQUIRED 
               
            
           
           
               
            
               
                 &gt; 
               
               
                 &lt;!ELEMENT RAT EMPTY&gt; 
               
               
                 &lt;!ATTLIST RAT 
               
               
                  TYPE (IEEE-802.11 | IEEE-802.11a | IEEE-802.11b | IEEE- 
               
               
                 802.11g | 3GPP-GERAN | 3GPP-UTRAN-FDD | 3GPP-UTRAN-TDD | 
               
               
                 ADSL | ADSL2 | ADSL2+ | RADSL | SDSL | HDSL | HDSL2 | 
               
               
                 G.SHDSL | VDSL | IDSL | 3GPP2-1X | 3GPP2-1X-HRPD | DOCSIS | 
               
               
                 token| 3GPP -GERAN CS | 3GPP -GERAN PS | 3GPP-UTRAN CS | 
               
               
                 3GPP-UTRAN PS | EVDO | CDMA1X | WiMAX) #REQUIRED 
               
               
                 &gt; 
               
               
                 Or 
               
               
                 &lt;!ELEMENT AT EMPTY&gt; 
               
               
                 &lt;!ATTLIST AT 
               
               
                  TYPE (IEEE-802.11 | IEEE-802.11a | IEEE-802.11b \ IEEE- 
               
               
                 802.11g | 3GPP-GERAN | 3GPP-UTRAN-FDD | 3GPP-UTRAN-TDD | 
               
               
                 ADSL | ADSL2 | ADSL2+ | RADSL | SDSL | HDSL | HDSL2 | 
               
               
                 G.SHDSL | VDSL | IDSL | 3GPP2-1X | 3GPP2-1X-HRPD | DOCSIS | 
               
               
                 token | 3GPP -GERAN CS | 3GPP -GERAN PS | 3GPP-UTRAN CS | 
               
               
                 3GPP-UTRAN PS | EVDO | CDMA1X | WiMAX) #REQUIRED 
               
               
                 &gt; 
               
               
                 &lt;?xml version=″1.0″?&gt; 
               
               
                 &lt;!-- Draft DTD for the IMS XML body. --&gt; 
               
               
                 &lt;!DOCTYPE ims-3gpp [ 
               
            
           
           
               
               
            
               
                   
                 &lt;!-- ims-3gpp element: root element --&gt; 
               
               
                   
                 &lt;!ELEMENT ims-3gpp (alternative-service?, service- 
               
            
           
           
               
            
               
                 info?)&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;!ATTLIST ims-3gpp version CDATA #REQUIRED&gt; 
               
               
                   
                 &lt;!-- service-info element: The transparent data 
               
            
           
           
               
            
               
                 received from HSS for AS --&gt; 
               
            
           
           
               
               
               
            
               
                   
                 &lt;!ELEMENT service-info 
                 (#PCDATA)&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;!-- alternative-service: alternative-service used in 
               
            
           
           
               
            
               
                 emergency sessions --&gt; 
               
            
           
           
               
               
               
            
               
                   
                 &lt;!ELEMENT alternative-service 
                 (type, reason)&gt; 
               
            
           
           
               
               
               
            
               
                   
                 &lt;!ELEMENT type 
                 (emergency | vcc- 
               
            
           
           
               
            
               
                 domain-tx, MO call)&gt; 
               
            
           
           
               
               
               
            
               
                   
                 &lt;!ELEMENT reason 
                 (#PCDATA)&gt; 
               
            
           
           
               
            
               
                 &lt;!ELEMENT vcc-domain-tx (uri?, access-type?, domain-type?) 
               
               
                 &lt;!ELEMENT uri (#PCDATA)&gt; 
               
               
                 &lt;!ELEMENT access-type EMPTY&gt; 
               
               
                 &lt;!ATTLIST access-type 
               
               
                  access-technology (IEEE-802.11 | IEEE-802.11a | IEEE- 
               
               
                 802.11b | IEEE-802.11g | 3GPP-GERAN | 3GPP-UTRAN-FDD | 3GPP- 
               
               
                 UTRAN-TDD | ADSL | ADSL2 | ADSL2+ | RADSL | SDSL | HDSL | 
               
               
                 HDSL2 | G.SHDSL | VDSL | IDSL | 3GPP2-1X | 3GPP2-1X-HRPD | 
               
               
                 DOCSIS | token| 3GPP -GERAN CS | 3GPP -GERAN PS | 
               
               
                 3GPP-UTRAN CS | 3GPP-UTRAN PS | EVDO |CDMA1X | WiMAX) 
               
               
                 #REQUIRED 
               
               
                 &gt; 
               
               
                 &lt;!ELEMENT domain-type EMPTY&gt; 
               
               
                 &lt;!ATTLIST domain-type 
               
               
                  domain (IMS | CS) #IMPLIED 
               
               
                 &gt; 
               
               
                 ]&gt; 
               
               
                 &lt;vcc-domain-tx&gt; 
               
            
           
           
               
               
            
               
                   
                 &lt;uri&gt;tel:ffff&lt;/uri&gt; 
               
               
                   
                 &lt;access-type access-technology=”IEEE-802.11”/&gt; 
               
               
                   
                 &lt;domain-type domain=”IMS”/&gt; 
               
            
           
           
               
            
               
                 &lt;/vcc-domain-tx&gt; 
               
               
                 END 
               
               
                   
               
            
           
         
       
     
       FIG. 4  depicts a block diagram of an embodiment of a mobile communication device operable as a wireless UE device, e.g., UE  302 , for purposes of the present patent disclosure. It will be recognized by those skilled in the art upon reference hereto that although an embodiment of UE  302  may comprise an arrangement similar to one shown in  FIG. 4 , there can be a number of variations and modifications, in hardware, software or firmware, with respect to the various modules depicted. Accordingly, the arrangement of  FIG. 4  should be taken as illustrative rather than limiting with respect to the embodiments of the present patent disclosure. A microprocessor  402  providing for the overall control of an embodiment of UE  302  is operably coupled to a communication subsystem  404  that is capable of multi-mode communications (e.g., CS domain, IP domain such as IMS, et cetera). The communication subsystem  404  generally includes one or more receivers  408  and one or more transmitters  414  as well as associated components such as one or more local oscillator (LO) modules  410  and a processing module such as a digital signal processor (DSP)  412 . As will be apparent to those skilled in the field of communications, the particular design of the communication module  404  may be dependent upon the communications networks with which the mobile device is intended to operate (e.g., a CDMA network, a GSM network, WLAN, et cetera). Regardless of the particular design, however, signals received by antenna  406  through appropriate access infrastructure  405  (e.g., cellular base station towers, WLAN hot spots, etc.) are provided to receiver  408 , which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection, analog-to-digital (A/D) conversion, and the like. Similarly, signals to be transmitted are processed, including modulation and encoding, for example, by DSP  412 , and provided to transmitter  414  for digital-to-analog (D/A) conversion, frequency up conversion, filtering, amplification and transmission over the air-radio interface via antenna  416 . 
     Microprocessor  402  may also interface with further device subsystems such as auxiliary input/output (I/O)  418 , serial port  420 , display  422 , keyboard/keypad  424 , speaker  426 , microphone  428 , random access memory (RAM)  430 , a short-range communications subsystem  432 , and any other device subsystems, e.g., timer mechanisms, generally labeled as reference numeral  433 . In this example, display  422 , keyboard/keypad  424 , speaker  426 , microphone  428  are part of the user interface of the mobile communication device through which calls may be initiated by and maintained for the end user. To control access, a SIM/RUIM  434  may also be provided in communication with the microprocessor  402 . In one implementation, SIM/RUIM interface  434  is operable with a SIM/RUIM card having a number of key configurations  444  and other information  446  such as URIs as well as identification and subscriber-related data. Note that, without a SIM/RUIM, the UE device is referred to as mobile equipment (ME) but techniques of the present disclosure are applicable to either device. 
     Operating system software and applicable service logic software may be embodied in a persistent storage module (i.e., non-volatile storage) such as Flash memory  435 . In one implementation, Flash memory  435  may be segregated into different areas, e.g., storage area for computer programs  436  (e.g., service processing logic), as well as data storage regions such as device state  437 , address book  439 , other personal information manager (PIM) data  441 , and other data storage areas generally labeled as reference numeral  443 . A transport stack  445  may be provided to effectuate one or more appropriate radio-packet transport protocols. In addition, a call control logic module  448  is provided for appropriate call message processing according to the present techniques, effectuating SIP-URI and call reference ID generation, validation, verification, and correlation with IMRNs, etc. as set forth hereinabove. 
     Thus, methods and apparatus for originating a Session Initiation Protocol (SIP) call from a user equipment (UE) device in a network environment including a circuit-switched (CS) network and an IP multimedia subsystem (IMS) network to a called party have been described. When the SIP call is originated from the UE device in the CS network domain, a SIP Invite message which includes a SIP Uniform Resource Indicator (URI) or Tele URI of the called party is sent from the UE device to an application server (AS) node in the IMS network. At the AS node, a pool of E.164 numbers are maintained as IP multimedia routing numbers (IMRNs) which are utilized for mapping to or otherwise associating with called party URIs. Thus, the AS node dynamically allocates a select E.164 number with respect to the called party&#39;s URI received from the UE device, and returns it to the UE device in a SIP  380  (Alternative Service) Response message. Subsequently, the dynamically-allocated E.164 number is sent from the UE device in a call setup message for identification of the URI at the AS node. Thus, the dynamically-allocated E.164 number is utilized for routing the SIP call towards the called party upon interrogating the URI—IMRN mapping, whereupon it may be released back to the pool of IMRNs for future use. Appropriate timers may be provided at the device and AS node endpoints so that it can be verified whether a call reference number associated with the call remains valid (e.g. it has not timed out) or the dynamically-allocated IMRN remains valid (e.g. it has not timed out). Optionally, the released IMRN may be quarantined for a period of time. 
     At the AS node, the technique may include the acts of maintaining access to a pool of E.164 numbers as IP multimedia routing numbers (IMRNs); receiving a SIP Invite message for a SIP call originating from a user equipment (UE) device through a circuit-switched network domain, the SIP Invite message having call information which includes a SIP URI or Tel URI of the called party; selecting one of the E.164 numbers and storing a mapping between the selected E.164 number and the call information; causing a SIP  380  (Alternative Service) Response message to be sent to the UE device in response to receiving the SIP Invite message, the SIP  380  (Alternative Service) message including the selected E.164 number; and after the sending of the SIP  380  (Alternative Service) Response message, receiving a call setup message from the UE device for the SIP call, the call setup message having the selected E.164 number; identifying, with use of the selected E.164 number via the stored mapping, the URI identified from the call setup message; and causing a SIP session to be established with the called party with use of the URI identified via the stored mapping. 
     It is believed that the operation and construction of the embodiments of the present patent application will be apparent from the Detailed Description set forth above. While the exemplary embodiments shown and described may have been characterized as being preferred, it should be readily understood that various changes and modifications could be made therein without departing from the scope of the present disclosure as set forth in the following claims.