WO2006105223A1 - Ip and circuit-switched network interop-erability - Google Patents

Ip and circuit-switched network interop-erability Download PDF

Info

Publication number
WO2006105223A1
WO2006105223A1 PCT/US2006/011511 US2006011511W WO2006105223A1 WO 2006105223 A1 WO2006105223 A1 WO 2006105223A1 US 2006011511 W US2006011511 W US 2006011511W WO 2006105223 A1 WO2006105223 A1 WO 2006105223A1
Authority
WO
WIPO (PCT)
Prior art keywords
telephony network
message
network
circuit
client device
Prior art date
Application number
PCT/US2006/011511
Other languages
French (fr)
Inventor
Felipe Alvarez Del Pino
Niranjan Avula
Steffen Engmann
Vassilios Koukoulidis
Chenghui Wang
Tri Leminh
Original Assignee
Nokia Siemens Networks Gmbh & Co. Kg
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Siemens Networks Gmbh & Co. Kg filed Critical Nokia Siemens Networks Gmbh & Co. Kg
Publication of WO2006105223A1 publication Critical patent/WO2006105223A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/0024Services and arrangements where telephone services are combined with data services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1043Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2250/00Details of telephonic subscriber devices
    • H04M2250/06Details of telephonic subscriber devices including a wireless LAN interface
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W60/00Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/30Connection release
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08Upper layer protocols
    • H04W80/10Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]

Definitions

  • Embodiments may generally relate to mobile telephony. More particularly, some embodiments are concerned with interoperation of a mobile client telephony device with both a circuit-switched telephony network and an Internet Protocol (IP) telephony network.
  • IP Internet Protocol
  • GSM Global System for Mobile Telecommunications
  • IP telephony networks e.g., IP Multimedia Subsystem (IMS) networks
  • IMS IP Multimedia Subsystem
  • An IP telephony network client device may communicate wirelessly (e.g., via WiFi) with such a network.
  • WiFi wireless Local Area Networks
  • an IP telephony network client device may provide user mobility among wireless Local Area Networks (WLANs) as long as the device remains in communication with at least one WLAN.
  • WLANs wireless Local Area Networks
  • an IP telephony wireless client device may place calls to and receive calls from a phone number associated with another IP telephony client device (wireless or wired).
  • An IP telephony wireless client device may also place calls to and receive calls from a phone number associated with a client device of conventional circuit-switched (CS) network (e.g., GSM, Public Switch Telephone Network (PSTN), etc.).
  • CS circuit-switched
  • GSM Global System for Mobile communications
  • PSTN Public Switch Telephone Network
  • Systems are desired that allow a client telephony device to register with either a CS telephony network or an IP telephony network. Such systems may support efficient roaming of a single wireless telephony client device between CS telephony networks and IP telephony networks. Handover of existing calls between the two types of networks may also be supported.
  • Some embodiments provide a system, method, program code and/or means to provide selectable registration of a client telephony device with a circuit-switched telephony network or with an IP telephony network.
  • a first message to register the client device with the IP telephony network is received, the first message including a first identifier of the client device within the IP telephony network.
  • a second identifier of the client device within the circuit-switched telephony network is determined based on the first identifier
  • a server of the circuit-switched telephony network associated with the client device is determined based on the second identifier
  • a second message is transmitted to the server to update a location of the client device, the second message comprising the second identifier and a third identifier of a server of the IP telephony network.
  • a first message is received from a server of the circuit-switched telephony network associated with the client device to deregister the client device from the IP telephony network
  • a database record of a server of the IP telephony network and associated with the client device is updated based on the first message
  • a request is transmitted to a second server of the IP telephony network to deregister the client device from the IP telephony network.
  • aspects to terminate calls from the circuit-switched telephony network to a client device roaming in the IP telephony network may include reception of a message from a server of the circuit-switched telephony network to generate a roaming number associated with the client device, the message including a first identifier of the client device within the circuit-switched telephony network, determination of a second identifier of the client device within the IP telephony network based on the first identifier, determination of whether the client device is registered within the IP telephony network based on the second identifier, and generation of a roaming number associated with the client device.
  • the roaming number may be transmitted to the server of the circuit-switched telephony network, a call may be received to the roaming number at a gateway between the circuit-switched telephony network and the IP telephony network, a query including the roaming number may be received from the gateway, and the second identifier may be transmitted to the gateway in response to the query.
  • a first message to register the client device with the IP telephony network may be received, the first message including a first identifier of the client device within the IP telephony network, a second message may be received from the circuit-switched telephony network, the second message requesting a handover of a call within the circuit-switched telephony network to the IP telephony network, and a handover number associated with the client device within the IP telephony network may be transmitted to the circuit-switched telephony network in response to the second message.
  • a call to the handover number may be received at a gateway between the circuit-switched telephony network and the IP telephony network, a query may be received from the gateway, the query including the handover number, the first identifier may be transmitted to the gateway in response to the query, and a third message may be transmitted to the circuit-switched telephony network to terminate the call within the circuit-switched telephony network.
  • a first message is received from the client telephony device requesting a handover of a call within the IP telephony network to the circuit-switched telephony network, a second message is transmitted to the circuit-switched telephony network, the second message requesting the handover of the call within the circuit-switched telephony network to the IP telephony network, and a third message is received from the circuit-switched telephony network, the third message including a handover number and data usable to communicate with the circuit-switched telephony network.
  • the data may be transmitted to the client telephony device in response to the first message, a request may be transmitted to a gateway between the circuit-switched telephony network and the IP telephony network, the request to establish a call to the circuit-switched telephony network using the handover number, a fourth message may be received from the circuit- switched telephony network requesting termination of the call within the IP telephony network, and, in response to the fourth message, a fifth message may be transmitted to the gateway to join the call within the IP telephony network with the call to the circuit-switched telephony network.
  • a first message is received from the client telephony device requesting a handover of a call within the IP telephony network to the circuit-switched telephony network
  • a second message is transmitted to the client telephony device including a handover number associated with the IP telephony network and with the client device
  • a call is received to the handover number within the circuit-switched telephony network at a gateway between the circuit-switched telephony network and the IP telephony network
  • an identifier of the client device within the IP telephony network is determined based on the handover number
  • an acknowledgement of the first message is transmitted to the client device
  • a third message is transmitted to the gateway to join the call to the handover number within the circuit-switched telephony network call with the call within the IP telephony network.
  • FIG. 1 is a block diagram of a system according to some embodiments
  • FIG. 2 is a block diagram of IP and circuit-switched network components according to some embodiments
  • FIG. 3 is a functional block diagram of a Mobility Management Application Server (MM-AS) according to some embodiments;
  • MM-AS Mobility Management Application Server
  • FIG. 4 is a block diagram of a hardware architecture of a client telephony device according to some embodiments.
  • FIG. 5 is a block diagram of a software architecture to support IP-based and circuit-switched-based telephony signaling according to some embodiments
  • FIG. 6 is a block diagram of a software architecture to support telephony audio signals according to some embodiments.
  • FIG. 7 is a flow diagram of a process to support roaming from a circuit- switched telephony network to an IP telephony network according to some embodiments
  • FIG. 8 is a diagram to illustrate roaming from a circuit-switched telephony network to an IP telephony network according to some embodiments
  • FIG. 9 is a flow diagram of a process to support roaming from an IP telephony network to a circuit-switched telephony network according to some embodiments
  • FIG. 10 is a diagram to illustrate roaming from a circuit-switched telephony network to an IP telephony network according to some embodiments
  • FIG. 11 is a flow diagram of a process to support termination of calls from a circuit-switched telephony network a client telephony device roaming in an IP telephony network according to some embodiments;
  • FIG. 12 is a diagram to illustrate termination of calls from a circuit- switched telephony network a client telephony device roaming in an IP telephony network according to some embodiments;
  • FIG. 13 is a flow diagram of a process to support handover of a call within a circuit-switched telephony network to an IP telephony network according to some embodiments;
  • FIGS. 14A and 14B illustrate handover of a call within a circuit-switched telephony network to an IP telephony network according to some embodiments
  • FIG. 15 is a flow diagram of a process to support handover of a call within an IP telephony network to a circuit-switched telephony network according to some embodiments;
  • FIGS. 16A through 16C illustrate handover of a call within an IP telephony network to a circuit-switched telephony network according to some embodiments
  • FIG. 17 is a flow diagram of a process to support handover of a call within an IP telephony network to a circuit-switched telephony network according to some embodiments.
  • FIGS. 18A through 18C illustrate handover of a call within an IP telephony network to a circuit-switched telephony network according to some embodiments.
  • FIG. 1 is a block diagram of system 1 according to some embodiments.
  • System 1 comprises device 10, IP telephony network 20 and CS telephony network 30.
  • System 1 may provide selectable registration of device 10 with IP telephony network 20 or with CS telephony network 30. Registration of device 10 with one of networks 20 or 30 may determine to which network a terminating call (or other terminating service) is first routed.
  • Device 10 may comprise a mobile telephony client device, and may also be configured to support a "fixed" connection to one or both of networks 20 and 30.
  • Examples of device 10 according to some embodiments include cellular telephones, personal digital assistants (PDAs), digital media players, digital cameras, wireless email devices, and any other device for supporting wireless telephony that is or becomes known.
  • Device 10 includes processor 12 for executing program code to enable some or all of the functions attributed herein to device 10. Also included are hardware, software and/or firmware elements of IP network I/O 14 and CS network I/O 16. IP network I/O 14 and CS network I/O 16 support wireless communication with IP telephony network 20 and CS telephony network 30, respectively. Further details of hardware elements and software stacks of device 10 according to some embodiments are set forth below.
  • IP telephony network 20 may comprise any number of LANs, Wide Area Networks (WANs), and/or the Internet itself. IP telephony network 20 provides at least one wireless access point that may be accessed by device 10. According to some embodiments, IP telephony network supports the IMS protocol.
  • CS telephony network 30 also provides at least one wireless access point to device 10.
  • Network 30 may comprise one or a combination of CS telephony networks, including but not limited to CDMA/IS-41 , WCDMA/UMTS, TDMA, GSM, PCS, and PSTN networks. As described above, such telephony networks may be owned by more than one separate providers.
  • system 1 may provide roaming of device 10 between IP telephony network 20 and CS telephony network 30, termination of calls to device 10 roaming in IP telephony network 20 from CS telephony network 30, and handover of calls between IP telephony network 20 and CS telephony network 30. Details of each of the foregoing operations according to some embodiments are provided below.
  • FIG. 2 is a more detailed block diagram of system 1 according to some embodiments.
  • MM-AS Mobility Management Application Server
  • the core functionality of each illustrated element is known.
  • some embodiments may require one or more illustrated elements to function differently than is currently known.
  • CS telephony network 30 includes PSTN 305, which is in communication through known interfaces with GSM network 310.
  • GSM network 310 may comprise one or more GSM networks having different ownership.
  • GSM network 310 comprises Home Location Registers (HLRs) 312, Mobile Switching Centers (MSCs) 314, and Visitor Location Registers (VLRs) 316. Current usage often combines the functions of an MSC and a VLR under the label MSC/VLR.
  • HLRs Home Location Registers
  • MSCs Mobile Switching Centers
  • VLRs Visitor Location Registers
  • embodiments may be used in conjunction with additional or alternative CS mobile telephony networks (e.g., CDMA/IS-41 , WCDMA/UMTS, TDMA, PCS).
  • additional or alternative CS mobile telephony networks e.g., CDMA/IS-41 , WCDMA/UMTS, TDMA, PCS.
  • Such embodiments utilize known messages and protocols of the additional or alternative wireless networks.
  • the messages and protocols may be roughly analogous to the messages described below with respect to GSM networks.
  • an HLR provides a central subscriber database that maintains a location of a client device within a GSM network.
  • a GSM network may include many HLRs.
  • a location of a client device is maintained in a single HLR, and a single HLR may maintain locations of many client devices within several geographic areas.
  • An MSC/VLR is assigned to each geographic area, which may include several cellular communication towers.
  • a client device is registered an MSC/VLR if the client device is located in a geographic area to which the MSC/VLR is assigned. This registration is stored in an HLR associated with the MSC/VLR.
  • Session control unit 210 includes Home Subscriber Server (HSS) 212, Call Session Control Function (CSCF) 214, and MM-AS 400. Core functions of HSS and CSCF are known and are roughly equivalent, within the IP domain, to the core functions of an HLR and an MSC/VLR, respectively.
  • HSS Home Subscriber Server
  • CSCF Call Session Control Function
  • MM-AS 400 may provide much of the functionality described herein. MM-AS may therefore provide roaming of device 10 between IP telephony network 20 and CS telephony network 30, termination of calls to device 10 roaming in IP telephony network 20 from CS telephony network 30, and handover of calls between IP telephony network 20 and CS telephony network 30.
  • MM-AS 400 emulates a CS-domain MSC/VLR. Consequently, roaming and call handover between network 20 and network 30 may be implemented using existing GSM protocols for inter-MSC roaming and handover.
  • MM-AS 400 may implement IP-based interfaces for communicating with HSS 212, CSCF 214 and Media Gateway Control Function (MGCF) 222, and may implement Mobile Application Part (MAP) interfaces for communicating with GSM elements such as HLRs 312, MSCs 314 and VLRs 316.
  • MGCF 222 is an element of legacy internetworking unit 220 and may allow interoperability between IP telephony network 20 and CS network 30 signaling protocols over a legacy interface, such as a Signaling System No. 7 (SS7) interface.
  • SS7 Signaling System No. 7
  • Media Gateway 224 of unit 220 enables the transfer of audio data between IP telephony network 20 and CS network 30.
  • Applications unit 230 provides telephony applications to IP network 20.
  • instant messaging server 232 may provide instant messaging services
  • Rich Voice-over-IP (VoIP) Application Server 234 may provide other telephony applications such as call forwarding, call transfer, call waiting, etc. within IP telephony network 20.
  • IP telephony network 20 may support conventional IP telephony client devices using conventional means.
  • Such conventional devices may include fixed IP client devices 50 (e.g., coupled to network 20 via a Digital Subscriber Line connection) and mobile IP client devices 40 (e.g., coupled to network 20 via a General Packed Radio System connection).
  • Fixed IP client devices may comprise desktop computers, fixed IP telephones, conventional PSTN telephones coupled to an IP-PSTN telephone router, or the like.
  • Mobile IP client devices 40 may include, but are not limited to, cellular telephones, PDAs, digital media players, digital cameras, and wireless email devices.
  • FIG. 3 is a functional block diagram of MM-AS 400 according to some embodiments.
  • the illustrated functional blocks may be implemented by any combination of hardware and/or software, some of which may be located remote from one another. According to some embodiments, the functional blocks are implemented in program code for execution by a processor of a computer server.
  • MM-AS 400 includes subscriber and call data module 410, mobility management module 420 and protocol stacks 430.
  • Subscriber and call data module 410 includes information for tracking client devices within IP telephony network 20 and CS telephony network 30 and for associating CS- based telephone numbers with client devices during certain scenarios. Accordingly, module 410 provides an ENUM interface to MGCF 222 for receiving a CS-based telephone number from MGCF 222 and transmitting an identifier of an associated client device to MGCF 222 in response. MGCF 222 may use the identifier to connect a call from network 30 to the client device.
  • Mobility management module 420 includes mobility management state event handling block 422, MAP state event handling block 424, and Session Initiation Protocol (SIP) state event handling block 426 for executing the processes described herein in response to received SIP and MAP messages.
  • the MAP messages are received from GSM network 310 via MAP protocol stack 432 and the SIP messages are received from CSCF 214 via the SIP protocol stack 434.
  • SIP Session Initiation Protocol
  • FIG. 4 is a block diagram of an internal hardware architecture of device 10 according to some embodiments.
  • Device 10 may be referred to as a Dual Mode Handset (DMH), in reference to its capability to operate as a wireless IP telephony network client and a wireless CS telephony network client.
  • DMH Dual Mode Handset
  • Device 10 may include primarily conventional components, and may include program code to perform certain functions described herein. Embodiments may differ in part or in whole from device 10 of FIG. 4.
  • Device 10 includes microphone 50 to receive audio signals that may represent speech of a user.
  • the audio signals may comprise commands for operating device 10, such as a command to dial a particular telephone number.
  • Speaker 55 emits audio signals from device 10.
  • the audio signals may comprise speech or other audio signals received from telephony networks and/or ring tones, beeps and other tones used during operation of device 10.
  • Analog/digital coder/decoder (A/D codec) 60 may receive analog signals from microphone 50, convert the analog signals to digital signals, and pass the digital signals to processor 12. Conversely, processor 12 may transmit digital signals to A/D codec 60, which converts the digital signals to analog signals and passes the analog signals to speaker 55. Speaker 55 then emits sound based on the analog signals.
  • Processor 12 may be a conventional microprocessor, microcontroller and/or digital signal processor (DSP) or other control circuit conventionally provided in a mobile telephony client device.
  • DSP digital signal processor
  • Processor 12 is also in communication with input 65 and display 70.
  • Input 65 may comprise any system to receive input from a user, including but not limited to an alphanumeric keypad, dedicated function keys, a touchscreen, etc.
  • Display 70 may comprise any system to display a user interface for presenting information to a user.
  • Antennae 75 and 85 may receive and transmit radio frequency signals from and to a CS telephony network and an IP telephony network, respectively.
  • Antennae 75 and 85 may be configured to transmit and receive any types of signals that comply with the communication protocol of a CS telephony network or IP telephony network in which device 10 is employed.
  • GSM transceiver 80 is operatively coupled to antenna 75 and WiFi transceiver 90 is operatively coupled to antenna 85.
  • GSM transceiver 80 and WiFi transceiver 90 may be configured to operate at different frequencies.
  • Transceivers 80 and 90 may, in accordance with conventional practices, each comprise a combination of two or more different receive/transmit modules (not separately shown) that operate in accordance with mutually different radio communication protocols to provide various services for device 10.
  • Device 10 also includes internal memory 95 and removable memory 100.
  • Internal memory 95 may include one or more of ROM (read only memory), RAM (random access memory, e.g., static RAM), and flash memory.
  • Removable memory 100 may comprise a flash memory, a Subscriber Identity Module (SIM) card or any other removable memory that is or becomes known.
  • SIM Subscriber Identity Module
  • Such a SlM card may store an International Mobile Subscriber Identity (IMSI), which is an identifier of a subscriber within a GSM network.
  • IMSI International Mobile Subscriber Identity
  • Memories 95 and 100 may store program code that is executable by processor 12 to control device 10 in accordance with the processes described herein.
  • the program code may include but is not limited to operating system program code, application program code, device driver program code, and database connector program code.
  • Memories 95 and 100 may also store data used in the operation of device 10. Such data may include contacts, phone numbers, addresses, voice mailbox access numbers, voice mailbox access codes, and other data. Some or all of the data may be read-only, while other of the data may be rewritable.
  • FIG. 4 is simplified in a number of ways. For example, all power and power management components of device 10 are omitted from the diagram. Also, some embodiments may employ an internal architecture somewhat different or completely different from that shown in FIG. 4. Each illustrated element of device 10 may comprise any combination of hardware and/or software components suitable for providing the functions attributed thereto herein.
  • FIG. 5 is a block diagram of a software architecture for device 10 to signal speech in accordance with some embodiments. Accordingly, each block of FIG. 5 may be implemented in software.
  • the architecture of FIG. 5 supports operation in conjunction with GSM and ISM networks, but other CS or IP networks may be supported.
  • User interface 110 may provide a common user experience regardless of whether device 10 is registered with a GSM network or an IMS network. User interface 110 may provide an indication of a current mode of operation, a menu for changing the mode of operation, and a common dialing application for GSM and ISM-based modes.
  • Mode manager 115 may support automatic roaming and handover between GSM and ISM networks. For example, mode manager 115 may monitor signal strengths of GSM and WiFi signals, determine a mode to register based on the determined signal strengths, manage a handover algorithm during a call, and route a user request and indication to GSM services 120 or IMS services 125 depending on the mode of operation. Mode manager 115 or any other software block of FIGS. 5 and 6 may comprise a plug-in application written in Java or C and may also or alternatively be embodied in native program code of device 10.
  • GSM signaling stack 130 and IMS signaling stack 135.
  • seamless handover may require a change to the known function of Radio Resource layer 132 of GSM signaling stack 130.
  • SIP/RTP layer 137 complies with the 3 rd Generation Partnership Project (3GPP) SIP call control specification.
  • FIG. 6 is a block diagram of a software architecture for device 10 to support speech in accordance with some embodiments. Again, each block of FIG. 6 may be implemented in software, and the architecture of FIG. 6 is intended for use with GSM and ISM networks.
  • the FIG. 6 architecture includes audio driver 140 for execution by processor 12, mode manager 115, GSM audio stack 145 and WiFi ISM audio stack 150.
  • FIG. 7 is a flow diagram of process 500 to support roaming from a CS telephony network to an IMS telephony network according to some embodiments.
  • process 500 and the flow diagrams herein are described below in reference to a GMS telephony network, an IMS telephony network and associated signaling protocols, the teachings thereof may be applied to implementations associated with other CS telephony networks and IP telephony networks.
  • Process 500 may be executed by MM-AS 400 using any suitable hardware and/or software arrangement, and may be executed by any suitable device or devices that are or become known.
  • process 500 may be embodied in program code executed by a processor of a hardware server.
  • device 10 may be registered with a GSM network and may be periodically polling for a WLAN signal. Upon detecting a suitable WLAN signal and registering with the WLAN, device 10 attempts to register with the IMS network. Following standard IMS registration procedures, device 10 transmits an SIP Register message to the IMS network. The message includes an SIP Uniform Resource Identifier (URI) associated with device 10. The SIP URI is an identifier of device 10 within the IMS network. Referring back to FIG. 2, the SIP Register message is received by CSCF 214. HSS 212 includes a user profile that associates the SIP URI with an instruction to forward received SIP Register messages to MM-AS 400. Accordingly, at step S510, CSCF 214 transmits the SIP Register message to MM-AS 400.
  • FIG. 8 illustrates transmission of the message from device 10 to MM-AS 400, with the intermediate elements of session control unit 210 being omitted for clarity.
  • a second identifier of the client device within the CS telephony network is determined based on the first identifier.
  • HSS 212 includes a table mapping an SIP URI of each supported dual mode device to an IMSI.
  • MM-AS 400 therefore accesses the table at step S520 to determine an IMSI that is associated with the SIP URI received with the SIP Register message.
  • the determined IMSI is an identifier of client device 10 within GSM network 30.
  • a server of the CS telephony network is determined based on the second identifier determined at step S520.
  • MM-AS 400 may perform Global Title Translation on the IMSI at step S530 to determine that HLR 310 of FIG. 8 is associated with client device 10.
  • a second message is transmitted to the determined server of the CS telephony network at step S540.
  • the second message includes the second identifier and a third identifier of a server of the IP telephony network.
  • FIG. 8 illustrates transmission of a MAP Update Location message at step S540 according to some embodiments.
  • the message is sent to HLR 312 that is associated with device 10.
  • HLR 312 may return profile data associated with client device 10 to MM-AS 400 for storage in user profile database 410. In some embodiments, HLR 312 then transmits a MAP Cancel Location message to MSC 314 that is associated with client device 10 in GSM network 30. HLR 312 may also acknowledge the MAP Update Location message received from MM-AS 400, in which case MM-AS 400 updates a record of VLR database 420 associated with client device 10. As a result, IP network 20 is maintained as the location of device 10 in HLR 312.
  • Process 500 may thereby provide roaming between a GSM network and an IMS network.
  • MM-AS 400 emulates a GSM MSC/VLR to provide such roaming. Accordingly, process 500 does not require HLR 312 and MSC 314 to deviate from conventional GSM protocols.
  • FIG. 9 is a flow diagram of process 600 to support roaming from an IP telephony network to a CS telephony network according to some embodiments.
  • device 10 Prior to process 600, it is assumed that device 10 is registered in the IP network and determines to join to the CS network based on some criteria. In some embodiments, device 10 periodically checks its WLAN signal strength, and attempts to register with the CS telephony network if the signal strength drops below a threshold.
  • device 10 attempts to register with the CS telephony network by transmitting a Location Update message to MSC 314.
  • Device 10 transmits the message using Radio Resource information of an MSC that was last associated with device 10 according to some embodiments. If the message successfully reaches an MSC, the MSC transmits a MAP Update Location message to associated HLR 312. To this point, the discussion of FIG. 10 complies with existing GSM protocols.
  • a first message is received from a server of the CS network associated with the client device.
  • the message comprises an instruction to deregister the client device from the IP telephony network.
  • MM-AS 400 receives a MAP Cancel Location message from HLR 312.
  • MM-AS 400 at step S620 updates a record of VLR database 420 that is associated with device 10 and acknowledges the message from HLR 312.
  • a request is transmitted to a second server of the IP telephony network at S630.
  • the request comprises a request to deregister the client device from the IP telephony network.
  • MM-AS 400 transmits such a request to CSCF 214 via an IMS Service Creation interface. Consequently, HSS 212 may update a record to indicate that client device 10 (i.e., an SIP URI of client device 10) is no longer registered with IP telephony network 20.
  • MM-AS 400 emulates a GSM MSC/VLR in process 600 to provide roaming between a GSM network and an IMS network.
  • Process 600 therefore does not require HLR 312 and MSC 314 to deviate from conventional GSM protocols.
  • FIG. 11 is a flow diagram of process 700 to support calls from a CS telephony network to a client telephony device that is registered with and roaming in an IP telephony network (i.e., Mobile Terminating Calls (MTCs).
  • MTCs Mobile Terminating Calls
  • Other MTC scenarios e.g., CS network to CS network, IP network to CS network, and IP network to IP network, may be implemented using conventional protocols.
  • a call is placed from a CS telephony network (e.g., PSTN, GSM, etc) to a telephone number associated with a client device that is registered with an IP telephony network.
  • a CS telephony network e.g., PSTN, GSM, etc
  • the call may be routed to Gateway MSC (GMSC) 314 since the telephone number is owned by the CS domain.
  • GMSC Gateway MSC
  • IAM Initial Address Message
  • GMSC 314 may query HLR 312 for an MSC/VLR with which client device 10 is currently registered.
  • This query may comprise an MAP Send Routing Info message that includes the telephone number received from PSTN 305. Since client device 10 is currently registered with the IP telephony network, the central subscriber database of HLR 312 indicates that the MSC/VLR currently serving device 10 is MM-AS 400. Therefore, again according to conventional GSM protocols, HLR 312 transmits a message requesting MM-AS 400 to generate a roaming number associated with client device 10.
  • the message is received at step S710 of process 700.
  • the message may comprise an MAP Provide Roaming Number message including the IMSI of client device 10, which HLR 312 has determined from the received telephone number.
  • a second identifier of the client device within the IP network is determined.
  • MM-AS 400 may access the table of HSS 212 described with respect to step S520 at step S720 to determine an SIP URI that is associated with the received IMSI.
  • MM-AS 400 may determine whether an associated client device is registered with the IP network at step S730. This determination may comprise a query to HSS 212 via CSCF 214 to determine whether the client device is registered.
  • a roaming number associated with the client device is generated at step S740.
  • the generated roaming number is a number that terminates to a gateway between the CS network and the IP network (e.g., MGCF 222).
  • MM- AS 400 may store the roaming number in association with a record of client device 10 in VLR database 420.
  • the roaming number is transmitted to the requesting server of the CS network.
  • MM-AS 400 transmits roaming number to HLR 312 via a response to the MAP Provide Roaming Number message received in step S710.
  • GMSC 314 receives the roaming number from HLR 312 and places a call thereto using an ISUP IAM message including the roaming number.
  • the call is received at the gateway at which the roaming number terminates.
  • the gateway is configured to perform an ENUM query for the roaming number to MM-AS 400.
  • MM-AS 400 receives such a query at step S770.
  • the query for the roaming number may comprise an alternative type of query (e.g. SOAP/XML query, TCAP query, IN query) according to some embodiments.
  • MM-AS 400 determines an SIP URI corresponding to the roaming number based on VLR database 420. Then, at step S780, MM-AS 400 transmits the SIP URI to the gateway. According to conventional CS-to-IP call setup protocols, the gateway may transmit an SIP Invite message to the received SIP URI, as also illustrated in FIG. 12. Alternative mechanisms for this mapping.
  • HSS 212 stores a user profile indicating that CSCF 214 is to forward all SIP calls to RVAS 234 and MM-AS 400.
  • a call may be first forwarded to RVAS 234 for handling any call-specific voice features (e.g. Call Forwarding, etc.).
  • RVAS 234 then returns the call to CSCF 214 for forwarding to MM-AS 400.
  • MM-AS 400 may remain passively in the call leg as a Back-to-Back User Agent (BBUA) for use during any subsequent handover procedure.
  • BBUA Back-to-Back User Agent
  • FIG. 13 is a flow diagram of process 800 to provide handover from a CS telephony network to an IP telephony network.
  • a client telephony device may be registered with a CS network and may be periodically polling for WLAN network signal. Upon detecting a suitable signal and registering with the associated WLAN network, the device requests a temporary registration with the IP network.
  • the request is received at step S810, and the request includes an identifier of the client device within the IP telephony network (e.g., an SIP URI).
  • MM-AS 400 may receive the request according to some embodiments of step S810. However, contrary to step S540 above, MM-AS 400 does not transmit a MAP Update Location message to an associated HLR 312 in response to the request.
  • the client device may transmit a periodic GSM Radio Resource Measurement Report to a serving MSC 314 of the CS network.
  • the Report may include an identifier that identifies the IP network as providing a best signal level.
  • MSC 314 then transmits a MAP Handover Request message to MM-AS 400.
  • the MSC 314 may have access to a mapping that associates the identifier received from the client device with an address of MM- AS 400.
  • MM-AS 400 then generates a handover number that is associated with the client device within the IP network, and to which a call may be placed using an ISUP IAM message.
  • the handover number may terminate to a gateway between the CS network and the IP network (e.g., MGCF 222).
  • MM-AS 400 may also store the handover number in association with a record of client device 10 in VLR database 420.
  • the handover number is transmitted to MSC 314 at step S830 in response to the MAP Handover Request message.
  • MSC 314 then places a call to the handover number using an ISUP IAM message.
  • the call is received at the gateway at which the handover number terminates.
  • the gateway is configured to perform an ENUM (or other) query for the handover number in response to the received call.
  • MM- AS 400 receives the query at step S850.
  • MM-AS 400 determines an SIP URI corresponding to the handover number based on VLR database 420. Then, at step S860, MM-AS 400 transmits the SIP URI to the gateway. According to conventional CS-to-IP call setup protocols, the gateway may then transmit an SIP Invite message to the received SIP URI.
  • MM-AS 400 may transmit a MAP Send End Signal message to the serving MSC 314.
  • the third message requests the MSC 314 to terminate the call within the CS telephony network.
  • client device 10 then performs a standard (i.e., non-temporary) SIP registration procedure in order to update its registration information in HLR 312.
  • FIGS. 14A and 14B generally illustrate process 800 according to some embodiments.
  • client device 10 is registered with and connected in a call to serving MSC 314.
  • MSC 314 in turn connects client device 10 with a caller registered with a CS or IP telephony network via HLR 312.
  • Process 800 results in establishment of a call between client device 10 and the IP network via MM-AS 400 and HLR 312, and termination of the HLR 310/MSC 314 call leg.
  • FIG. 15 is a flow diagram of process 900 to provide handover from an IP telephony network to a CS telephony network.
  • MM-AS 400 sets up a second call leg to client device 10, and then instructs MGCF 222 to connect an existing call leg to the second call leg.
  • a client telephony device may be registered with an IP network and in a call with another calling device that is registered with an IP or a CS telephony network.
  • the first client telephony device may be periodically polling for an IP network signal.
  • the device Upon detecting unsuitable WLAN signal strength, the device transmits a handover request to MM-AS 400 via an SIP Invite message.
  • the request is received at step S910, and the request includes various CS network parameters from which an MSC may be determined.
  • MM-AS 400 therefore refers to internal provisioning tables to map the parameters to an identifier of a particular MSC 314.
  • MM-AS then transmits a MAP Prepare Handover message at step S920 to the particular MSC 314 via MGCF 222.
  • MM-AS receives a handover number from MSC 314 at step S930 in response to the MAP Handover Request message. Also received at step S930 is data usable to communicate with the CS network. This data may comprise GSM Radio Resource information, and is usable to access an MSC at which the handover number terminates.
  • MM-AS 400 transmits the data to client device 10 at step S940 in response to the SIP Invite message received at step S910.
  • Client device 10 may initialize Radio Resource layer 132 of GSM signaling stack 130 with the received data.
  • MM-AS 400 transmits an SIP Invite message including the handover number to a gateway between the CS network and the IP network (e.g., MGCF 222).
  • the gateway places a call to the handover number (which terminates at a particular MSC) using an ISUP IAM message.
  • client device 10 attempts to access the particular MSC via the CS network by using the data provided at step S940.
  • Client device 10 then transmits a signal to the CS network indicating successful access of the particular MSC via the CS network.
  • the MSC transmits a MAP Send End Signal message to MM-AS 400.
  • the message requests termination of the call within the IP telephony network, and is received by MM-AS 400 at step S960.
  • MM-AS 400 transmits an SIP Refer message to the gateway.
  • the message comprises an instruction to join the ISUP call leg between the MSC and the gateway with the ISUP call leg between the gateway and the other client device that is in the call with client device 10.
  • FIGS. 16A through 16C generally illustrate process 900 according to some embodiments.
  • client device 10 is registered with MM-AS 400 and connected in a call to MGCF 222.
  • MSC 314 represents one MSC of GSM network 310 within CS network 30.
  • a first call is established between MGCF 222 and MSC 314 and a second call is established between client device 10 and MSC 314.
  • FIG. 16C illustrates joining of the call between MGCF 222 and MSC 314 with the call between MGCF 222 and the other calling device located in one of networks 20 and 30.
  • FIG. 16C also illustrates termination of the IP call leg between client device 10 and the IP telephony network.
  • Process 1000 of FIG. 17 sets forth an alternative procedure to handover a call from an IP telephony network to a CS telephony network.
  • client device 10 sets up a second call leg over the CS network to the IP telephony network, and a gateway between the two networks connects a leg of the existing call to the second call leg.
  • a first message is received from client device 10 at step S1010.
  • the message may comprise an SIP Invite message requesting handover of an existing call from the IP network to a CS network.
  • the existing call may connect the client device with another calling device registered with the IP telephony network or the CS telephony network.
  • Client device 10 may transmit the first message upon detecting unsuitable WLAN signal strength or based on any other reason.
  • MM-AS 400 generates a handover number that terminates at MGCF 222 and transmits the handover number to client device 10 at step S1020.
  • the handover number may be transmitted via an SIP 183 Session Progress message.
  • MM-AS 400 may also store an association between the handover number and an SIP URI of client device 10 in VLR database 420.
  • Client device 10 then transmits a MAP Location Update message to register with an MSC of the CS network, and places a call to the handover number via the CS network. Since the handover number terminates at MGCF 222, the call is received by MGCF 222 at step S1030. MGCF 222 performs an ENUM query for the handover number in response to the received call. The query is received by MM-AS 400, which, at step S1040, determines the SIP URI associated with the handover number in VLR database 420.
  • MM-AS 400 transmits an acknowledgement of the first message to client device 10.
  • the acknowledgement causes device 10 to transfer its audio resources to the call to the handover number.
  • MM-AS 400 transmits a message to MGCF 222 at step S1060.
  • the message instructs MGCF 222 to join the CS call to the handover number with the call between the gateway and the other client device.
  • FIGS. 18A through 18C generally illustrate process 1000 according to some embodiments. As shown in FlG. 18A, process 1000 begins with client device 10 being registered with MM-AS 400 and connected in a call to MGCF 222. MGCF 222 is also connected, via CS network 30 or IP network 20, to another calling device.
  • FIG. 18B illustrates establishment of a CS call from device 10 to a handover number terminating at MGCF 222.
  • FIG. 18C illustrates joining of the CS call between MGCF 222 and device 10 with the call between MGCF 222 and the other calling device located in one of networks 20 and 30.
  • FIG. 18C also illustrates termination of the IP call leg between client device 10 and the IP telephony network.
  • the above-mentioned signals and messages may pass through any number of networks, devices and protocols before reaching their intended recipient.
  • networks include but are not limited to local area networks, wide area networks, telephone networks, cellular networks, fiber-optic networks, satellite networks, infra-red networks, radio frequency networks, and any other type of networks which may be used to transmit information between devices.
  • data may be transmitted using one or more currently- or hereafter-known network protocols, including but not limited to Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP) and Wireless Application Protocol (WAP).
  • ATM Asynchronous Transfer Mode
  • IP Internet Protocol
  • HTTP Hypertext Transfer Protocol
  • WAP Wireless Application Protocol

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Disclosed herein are systems to provide selectable registration of a client telephony device (10) with a circuit-switched telephony network (30) or with an Internet Protocol (IP) telephony network (20). Such systems may provide one or more of: roaming of the client device between the circuit-switched telephony network (30) and the IP telephony network; termination of calls to the client device roaming in the IP telephony network (20) from the circuit-switched telephony network; and handover of calls between the IP telephony network and the circuit-switched telephony network.

Description

IP AND CIRCUIT-SWITCHED NETWORK INTEROPERABILITY
CROSS-REFERENCE TO RELATED APPLICATIONS
The present application claims priority to U.S. Provisional Patent Application Serial No. 60/666,433, filed on March 30, 2005 and entitled "IMS CS Voice Continuity", and to U.S. Provisional Patent Application Serial No. 60/671 ,244, filed on April 14, 2005 and entitled "IMS CS Voice Continuity", the contents of which are incorporated herein by reference for all purposes.
BACKGROUND Field
Embodiments may generally relate to mobile telephony. More particularly, some embodiments are concerned with interoperation of a mobile client telephony device with both a circuit-switched telephony network and an Internet Protocol (IP) telephony network.
Description
Conventional wireless telephony networks (e.g., Global System for Mobile Telecommunications (GSM) networks) provide user mobility and uninterrupted service across many geographical areas. Using a single wireless handset and a single telephone number, a user may roam between networks of different providers with seamless handover of calls therebetween.
IP telephony networks (e.g., IP Multimedia Subsystem (IMS) networks) are used increasingly to place and receive telephone calls. An IP telephony network client device may communicate wirelessly (e.g., via WiFi) with such a network. Accordingly, an IP telephony network client device may provide user mobility among wireless Local Area Networks (WLANs) as long as the device remains in communication with at least one WLAN.
Currently, an IP telephony wireless client device may place calls to and receive calls from a phone number associated with another IP telephony client device (wireless or wired). An IP telephony wireless client device may also place calls to and receive calls from a phone number associated with a client device of conventional circuit-switched (CS) network (e.g., GSM, Public Switch Telephone Network (PSTN), etc.). Again, however, such capabilities are provided only in a case that the IP telephony wireless client device remains in communication with at least one WLAN.
Systems are desired that allow a client telephony device to register with either a CS telephony network or an IP telephony network. Such systems may support efficient roaming of a single wireless telephony client device between CS telephony networks and IP telephony networks. Handover of existing calls between the two types of networks may also be supported.
SUMMARY
Some embodiments provide a system, method, program code and/or means to provide selectable registration of a client telephony device with a circuit-switched telephony network or with an IP telephony network.
According to some aspects, provided are roaming of the client device between the circuit-switched telephony network and the IP telephony network, termination of calls to the client device roaming in the IP telephony network from the circuit-switched telephony network, and handover of calls between the IP telephony network and the circuit-switched telephony network.
In some aspects to provide roaming from the circuit-switched telephony network to the IP telephony network, a first message to register the client device with the IP telephony network is received, the first message including a first identifier of the client device within the IP telephony network. A second identifier of the client device within the circuit-switched telephony network is determined based on the first identifier, a server of the circuit-switched telephony network associated with the client device is determined based on the second identifier, and a second message is transmitted to the server to update a location of the client device, the second message comprising the second identifier and a third identifier of a server of the IP telephony network.
According to some aspects to provide roaming from the IP telephony network to the circuit-switched telephony network, a first message is received from a server of the circuit-switched telephony network associated with the client device to deregister the client device from the IP telephony network, a database record of a server of the IP telephony network and associated with the client device is updated based on the first message, and a request is transmitted to a second server of the IP telephony network to deregister the client device from the IP telephony network.
Aspects to terminate calls from the circuit-switched telephony network to a client device roaming in the IP telephony network may include reception of a message from a server of the circuit-switched telephony network to generate a roaming number associated with the client device, the message including a first identifier of the client device within the circuit-switched telephony network, determination of a second identifier of the client device within the IP telephony network based on the first identifier, determination of whether the client device is registered within the IP telephony network based on the second identifier, and generation of a roaming number associated with the client device. The roaming number may be transmitted to the server of the circuit-switched telephony network, a call may be received to the roaming number at a gateway between the circuit-switched telephony network and the IP telephony network, a query including the roaming number may be received from the gateway, and the second identifier may be transmitted to the gateway in response to the query.
In aspects providing handover of a call within the circuit-switched telephony network to the IP telephony network, a first message to register the client device with the IP telephony network may be received, the first message including a first identifier of the client device within the IP telephony network, a second message may be received from the circuit-switched telephony network, the second message requesting a handover of a call within the circuit-switched telephony network to the IP telephony network, and a handover number associated with the client device within the IP telephony network may be transmitted to the circuit-switched telephony network in response to the second message. A call to the handover number may be received at a gateway between the circuit-switched telephony network and the IP telephony network, a query may be received from the gateway, the query including the handover number, the first identifier may be transmitted to the gateway in response to the query, and a third message may be transmitted to the circuit-switched telephony network to terminate the call within the circuit-switched telephony network.
In some aspects that provide handover of a call within the circuit- switched telephony network to the IP telephony network, a first message is received from the client telephony device requesting a handover of a call within the IP telephony network to the circuit-switched telephony network, a second message is transmitted to the circuit-switched telephony network, the second message requesting the handover of the call within the circuit-switched telephony network to the IP telephony network, and a third message is received from the circuit-switched telephony network, the third message including a handover number and data usable to communicate with the circuit-switched telephony network. The data may be transmitted to the client telephony device in response to the first message, a request may be transmitted to a gateway between the circuit-switched telephony network and the IP telephony network, the request to establish a call to the circuit-switched telephony network using the handover number, a fourth message may be received from the circuit- switched telephony network requesting termination of the call within the IP telephony network, and, in response to the fourth message, a fifth message may be transmitted to the gateway to join the call within the IP telephony network with the call to the circuit-switched telephony network.
According to alternative aspects that provide handover of a call within the circuit-switched telephony network to the IP telephony network, a first message is received from the client telephony device requesting a handover of a call within the IP telephony network to the circuit-switched telephony network, a second message is transmitted to the client telephony device including a handover number associated with the IP telephony network and with the client device, a call is received to the handover number within the circuit-switched telephony network at a gateway between the circuit-switched telephony network and the IP telephony network, an identifier of the client device within the IP telephony network is determined based on the handover number, an acknowledgement of the first message is transmitted to the client device, and a third message is transmitted to the gateway to join the call to the handover number within the circuit-switched telephony network call with the call within the IP telephony network.
With these and other advantages and features that will become hereinafter apparent, further information may be obtained by reference to the following detailed description and appended claims, and to the figures attached hereto. BRIEF DESCRIPTION OF THE DRAWINGS
Some embodiments are illustrated in the accompanying figures, in which like reference numerals designate like parts, and wherein:
FIG. 1 is a block diagram of a system according to some embodiments;
FIG. 2 is a block diagram of IP and circuit-switched network components according to some embodiments;
FIG. 3 is a functional block diagram of a Mobility Management Application Server (MM-AS) according to some embodiments;
FIG. 4 is a block diagram of a hardware architecture of a client telephony device according to some embodiments;
FIG. 5 is a block diagram of a software architecture to support IP-based and circuit-switched-based telephony signaling according to some embodiments;
FIG. 6 is a block diagram of a software architecture to support telephony audio signals according to some embodiments;
FIG. 7 is a flow diagram of a process to support roaming from a circuit- switched telephony network to an IP telephony network according to some embodiments;
FIG. 8 is a diagram to illustrate roaming from a circuit-switched telephony network to an IP telephony network according to some embodiments; FIG. 9 is a flow diagram of a process to support roaming from an IP telephony network to a circuit-switched telephony network according to some embodiments;
FIG. 10 is a diagram to illustrate roaming from a circuit-switched telephony network to an IP telephony network according to some embodiments;
FIG. 11 is a flow diagram of a process to support termination of calls from a circuit-switched telephony network a client telephony device roaming in an IP telephony network according to some embodiments;
FIG. 12 is a diagram to illustrate termination of calls from a circuit- switched telephony network a client telephony device roaming in an IP telephony network according to some embodiments;
FIG. 13 is a flow diagram of a process to support handover of a call within a circuit-switched telephony network to an IP telephony network according to some embodiments;
FIGS. 14A and 14B illustrate handover of a call within a circuit-switched telephony network to an IP telephony network according to some embodiments;
FIG. 15 is a flow diagram of a process to support handover of a call within an IP telephony network to a circuit-switched telephony network according to some embodiments;
FIGS. 16A through 16C illustrate handover of a call within an IP telephony network to a circuit-switched telephony network according to some embodiments; FIG. 17 is a flow diagram of a process to support handover of a call within an IP telephony network to a circuit-switched telephony network according to some embodiments; and
FIGS. 18A through 18C illustrate handover of a call within an IP telephony network to a circuit-switched telephony network according to some embodiments.
DETAILED DESCRIPTION
FIG. 1 is a block diagram of system 1 according to some embodiments. System 1 comprises device 10, IP telephony network 20 and CS telephony network 30. System 1 may provide selectable registration of device 10 with IP telephony network 20 or with CS telephony network 30. Registration of device 10 with one of networks 20 or 30 may determine to which network a terminating call (or other terminating service) is first routed.
Device 10 may comprise a mobile telephony client device, and may also be configured to support a "fixed" connection to one or both of networks 20 and 30. Examples of device 10 according to some embodiments include cellular telephones, personal digital assistants (PDAs), digital media players, digital cameras, wireless email devices, and any other device for supporting wireless telephony that is or becomes known.
Device 10 includes processor 12 for executing program code to enable some or all of the functions attributed herein to device 10. Also included are hardware, software and/or firmware elements of IP network I/O 14 and CS network I/O 16. IP network I/O 14 and CS network I/O 16 support wireless communication with IP telephony network 20 and CS telephony network 30, respectively. Further details of hardware elements and software stacks of device 10 according to some embodiments are set forth below.
IP telephony network 20 may comprise any number of LANs, Wide Area Networks (WANs), and/or the Internet itself. IP telephony network 20 provides at least one wireless access point that may be accessed by device 10. According to some embodiments, IP telephony network supports the IMS protocol.
CS telephony network 30 also provides at least one wireless access point to device 10. Network 30 may comprise one or a combination of CS telephony networks, including but not limited to CDMA/IS-41 , WCDMA/UMTS, TDMA, GSM, PCS, and PSTN networks. As described above, such telephony networks may be owned by more than one separate providers.
In some embodiments, system 1 may provide roaming of device 10 between IP telephony network 20 and CS telephony network 30, termination of calls to device 10 roaming in IP telephony network 20 from CS telephony network 30, and handover of calls between IP telephony network 20 and CS telephony network 30. Details of each of the foregoing operations according to some embodiments are provided below.
FIG. 2 is a more detailed block diagram of system 1 according to some embodiments. With the exception of Mobility Management Application Server (MM-AS) 400, the core functionality of each illustrated element is known. Of course, some embodiments may require one or more illustrated elements to function differently than is currently known.
CS telephony network 30 includes PSTN 305, which is in communication through known interfaces with GSM network 310. GSM network 310 may comprise one or more GSM networks having different ownership. GSM network 310 comprises Home Location Registers (HLRs) 312, Mobile Switching Centers (MSCs) 314, and Visitor Location Registers (VLRs) 316. Current usage often combines the functions of an MSC and a VLR under the label MSC/VLR.
As mentioned above, embodiments may be used in conjunction with additional or alternative CS mobile telephony networks (e.g., CDMA/IS-41 , WCDMA/UMTS, TDMA, PCS). Such embodiments utilize known messages and protocols of the additional or alternative wireless networks. The messages and protocols may be roughly analogous to the messages described below with respect to GSM networks.
Generally, an HLR provides a central subscriber database that maintains a location of a client device within a GSM network. A GSM network may include many HLRs. A location of a client device is maintained in a single HLR, and a single HLR may maintain locations of many client devices within several geographic areas. An MSC/VLR is assigned to each geographic area, which may include several cellular communication towers. Conventionally, a client device is registered an MSC/VLR if the client device is located in a geographic area to which the MSC/VLR is assigned. This registration is stored in an HLR associated with the MSC/VLR.
IP telephony network 20 is illustrated as comprising three sub-units, although actual implementations might not reflect such distinctions. Session control unit 210 includes Home Subscriber Server (HSS) 212, Call Session Control Function (CSCF) 214, and MM-AS 400. Core functions of HSS and CSCF are known and are roughly equivalent, within the IP domain, to the core functions of an HLR and an MSC/VLR, respectively.
MM-AS 400 may provide much of the functionality described herein. MM-AS may therefore provide roaming of device 10 between IP telephony network 20 and CS telephony network 30, termination of calls to device 10 roaming in IP telephony network 20 from CS telephony network 30, and handover of calls between IP telephony network 20 and CS telephony network 30. In some embodiments, MM-AS 400 emulates a CS-domain MSC/VLR. Consequently, roaming and call handover between network 20 and network 30 may be implemented using existing GSM protocols for inter-MSC roaming and handover.
MM-AS 400 may implement IP-based interfaces for communicating with HSS 212, CSCF 214 and Media Gateway Control Function (MGCF) 222, and may implement Mobile Application Part (MAP) interfaces for communicating with GSM elements such as HLRs 312, MSCs 314 and VLRs 316. In this regard, MGCF 222 is an element of legacy internetworking unit 220 and may allow interoperability between IP telephony network 20 and CS network 30 signaling protocols over a legacy interface, such as a Signaling System No. 7 (SS7) interface. Media Gateway 224 of unit 220 enables the transfer of audio data between IP telephony network 20 and CS network 30.
Applications unit 230 provides telephony applications to IP network 20. For example, instant messaging server 232 may provide instant messaging services, and Rich Voice-over-IP (VoIP) Application Server 234 may provide other telephony applications such as call forwarding, call transfer, call waiting, etc. within IP telephony network 20.
Accordingly, IP telephony network 20 may support conventional IP telephony client devices using conventional means. Such conventional devices may include fixed IP client devices 50 (e.g., coupled to network 20 via a Digital Subscriber Line connection) and mobile IP client devices 40 (e.g., coupled to network 20 via a General Packed Radio System connection). Fixed IP client devices may comprise desktop computers, fixed IP telephones, conventional PSTN telephones coupled to an IP-PSTN telephone router, or the like. Mobile IP client devices 40 may include, but are not limited to, cellular telephones, PDAs, digital media players, digital cameras, and wireless email devices.
FIG. 3 is a functional block diagram of MM-AS 400 according to some embodiments. The illustrated functional blocks may be implemented by any combination of hardware and/or software, some of which may be located remote from one another. According to some embodiments, the functional blocks are implemented in program code for execution by a processor of a computer server.
As shown, MM-AS 400 includes subscriber and call data module 410, mobility management module 420 and protocol stacks 430. Subscriber and call data module 410 includes information for tracking client devices within IP telephony network 20 and CS telephony network 30 and for associating CS- based telephone numbers with client devices during certain scenarios. Accordingly, module 410 provides an ENUM interface to MGCF 222 for receiving a CS-based telephone number from MGCF 222 and transmitting an identifier of an associated client device to MGCF 222 in response. MGCF 222 may use the identifier to connect a call from network 30 to the client device.
Mobility management module 420 includes mobility management state event handling block 422, MAP state event handling block 424, and Session Initiation Protocol (SIP) state event handling block 426 for executing the processes described herein in response to received SIP and MAP messages. The MAP messages are received from GSM network 310 via MAP protocol stack 432 and the SIP messages are received from CSCF 214 via the SIP protocol stack 434.
FIG. 4 is a block diagram of an internal hardware architecture of device 10 according to some embodiments. Device 10 may be referred to as a Dual Mode Handset (DMH), in reference to its capability to operate as a wireless IP telephony network client and a wireless CS telephony network client. Device 10 may include primarily conventional components, and may include program code to perform certain functions described herein. Embodiments may differ in part or in whole from device 10 of FIG. 4.
Device 10 includes microphone 50 to receive audio signals that may represent speech of a user. In some embodiments, the audio signals may comprise commands for operating device 10, such as a command to dial a particular telephone number. Speaker 55 emits audio signals from device 10. The audio signals may comprise speech or other audio signals received from telephony networks and/or ring tones, beeps and other tones used during operation of device 10.
Analog/digital coder/decoder (A/D codec) 60 may receive analog signals from microphone 50, convert the analog signals to digital signals, and pass the digital signals to processor 12. Conversely, processor 12 may transmit digital signals to A/D codec 60, which converts the digital signals to analog signals and passes the analog signals to speaker 55. Speaker 55 then emits sound based on the analog signals. Processor 12 may be a conventional microprocessor, microcontroller and/or digital signal processor (DSP) or other control circuit conventionally provided in a mobile telephony client device.
Processor 12 is also in communication with input 65 and display 70. Input 65 may comprise any system to receive input from a user, including but not limited to an alphanumeric keypad, dedicated function keys, a touchscreen, etc. Display 70 may comprise any system to display a user interface for presenting information to a user.
Antennae 75 and 85 may receive and transmit radio frequency signals from and to a CS telephony network and an IP telephony network, respectively. Antennae 75 and 85 may be configured to transmit and receive any types of signals that comply with the communication protocol of a CS telephony network or IP telephony network in which device 10 is employed.
GSM transceiver 80 is operatively coupled to antenna 75 and WiFi transceiver 90 is operatively coupled to antenna 85. GSM transceiver 80 and WiFi transceiver 90 may be configured to operate at different frequencies. Transceivers 80 and 90 may, in accordance with conventional practices, each comprise a combination of two or more different receive/transmit modules (not separately shown) that operate in accordance with mutually different radio communication protocols to provide various services for device 10.
Device 10 also includes internal memory 95 and removable memory 100. Internal memory 95 may include one or more of ROM (read only memory), RAM (random access memory, e.g., static RAM), and flash memory. Removable memory 100 may comprise a flash memory, a Subscriber Identity Module (SIM) card or any other removable memory that is or becomes known. Such a SlM card may store an International Mobile Subscriber Identity (IMSI), which is an identifier of a subscriber within a GSM network.
Memories 95 and 100 may store program code that is executable by processor 12 to control device 10 in accordance with the processes described herein. The program code may include but is not limited to operating system program code, application program code, device driver program code, and database connector program code. Memories 95 and 100 may also store data used in the operation of device 10. Such data may include contacts, phone numbers, addresses, voice mailbox access numbers, voice mailbox access codes, and other data. Some or all of the data may be read-only, while other of the data may be rewritable.
Those in the art will understand that the block diagram of FIG. 4 is simplified in a number of ways. For example, all power and power management components of device 10 are omitted from the diagram. Also, some embodiments may employ an internal architecture somewhat different or completely different from that shown in FIG. 4. Each illustrated element of device 10 may comprise any combination of hardware and/or software components suitable for providing the functions attributed thereto herein.
FIG. 5 is a block diagram of a software architecture for device 10 to signal speech in accordance with some embodiments. Accordingly, each block of FIG. 5 may be implemented in software. The architecture of FIG. 5 supports operation in conjunction with GSM and ISM networks, but other CS or IP networks may be supported.
User interface 110 may provide a common user experience regardless of whether device 10 is registered with a GSM network or an IMS network. User interface 110 may provide an indication of a current mode of operation, a menu for changing the mode of operation, and a common dialing application for GSM and ISM-based modes.
Mode manager 115 may support automatic roaming and handover between GSM and ISM networks. For example, mode manager 115 may monitor signal strengths of GSM and WiFi signals, determine a mode to register based on the determined signal strengths, manage a handover algorithm during a call, and route a user request and indication to GSM services 120 or IMS services 125 depending on the mode of operation. Mode manager 115 or any other software block of FIGS. 5 and 6 may comprise a plug-in application written in Java or C and may also or alternatively be embodied in native program code of device 10.
The above-mentioned requests and indications are processed by GSM signaling stack 130 and IMS signaling stack 135. As will be described below, seamless handover may require a change to the known function of Radio Resource layer 132 of GSM signaling stack 130. Also, according to some embodiments, SIP/RTP layer 137 complies with the 3rd Generation Partnership Project (3GPP) SIP call control specification.
FIG. 6 is a block diagram of a software architecture for device 10 to support speech in accordance with some embodiments. Again, each block of FIG. 6 may be implemented in software, and the architecture of FIG. 6 is intended for use with GSM and ISM networks. The FIG. 6 architecture includes audio driver 140 for execution by processor 12, mode manager 115, GSM audio stack 145 and WiFi ISM audio stack 150.
FIG. 7 is a flow diagram of process 500 to support roaming from a CS telephony network to an IMS telephony network according to some embodiments. Although process 500 and the flow diagrams herein are described below in reference to a GMS telephony network, an IMS telephony network and associated signaling protocols, the teachings thereof may be applied to implementations associated with other CS telephony networks and IP telephony networks.
Process 500, as well as the other processes described herein, may be executed by MM-AS 400 using any suitable hardware and/or software arrangement, and may be executed by any suitable device or devices that are or become known. For example, process 500 may be embodied in program code executed by a processor of a hardware server.
Prior to step S510, device 10 may be registered with a GSM network and may be periodically polling for a WLAN signal. Upon detecting a suitable WLAN signal and registering with the WLAN, device 10 attempts to register with the IMS network. Following standard IMS registration procedures, device 10 transmits an SIP Register message to the IMS network. The message includes an SIP Uniform Resource Identifier (URI) associated with device 10. The SIP URI is an identifier of device 10 within the IMS network. Referring back to FIG. 2, the SIP Register message is received by CSCF 214. HSS 212 includes a user profile that associates the SIP URI with an instruction to forward received SIP Register messages to MM-AS 400. Accordingly, at step S510, CSCF 214 transmits the SIP Register message to MM-AS 400. FIG. 8 illustrates transmission of the message from device 10 to MM-AS 400, with the intermediate elements of session control unit 210 being omitted for clarity.
At step S520, a second identifier of the client device within the CS telephony network is determined based on the first identifier. According to some embodiments, HSS 212 includes a table mapping an SIP URI of each supported dual mode device to an IMSI. MM-AS 400 therefore accesses the table at step S520 to determine an IMSI that is associated with the SIP URI received with the SIP Register message. The determined IMSI is an identifier of client device 10 within GSM network 30.
Next, at step S530, a server of the CS telephony network is determined based on the second identifier determined at step S520. Continuing with the present example, MM-AS 400 may perform Global Title Translation on the IMSI at step S530 to determine that HLR 310 of FIG. 8 is associated with client device 10.
A second message is transmitted to the determined server of the CS telephony network at step S540. The second message includes the second identifier and a third identifier of a server of the IP telephony network. FIG. 8 illustrates transmission of a MAP Update Location message at step S540 according to some embodiments. In this regard, the message is sent to HLR 312 that is associated with device 10.
In response to the received message, HLR 312 may return profile data associated with client device 10 to MM-AS 400 for storage in user profile database 410. In some embodiments, HLR 312 then transmits a MAP Cancel Location message to MSC 314 that is associated with client device 10 in GSM network 30. HLR 312 may also acknowledge the MAP Update Location message received from MM-AS 400, in which case MM-AS 400 updates a record of VLR database 420 associated with client device 10. As a result, IP network 20 is maintained as the location of device 10 in HLR 312.
Process 500 may thereby provide roaming between a GSM network and an IMS network. According to some embodiments, MM-AS 400 emulates a GSM MSC/VLR to provide such roaming. Accordingly, process 500 does not require HLR 312 and MSC 314 to deviate from conventional GSM protocols.
FIG. 9 is a flow diagram of process 600 to support roaming from an IP telephony network to a CS telephony network according to some embodiments.
Prior to process 600, it is assumed that device 10 is registered in the IP network and determines to join to the CS network based on some criteria. In some embodiments, device 10 periodically checks its WLAN signal strength, and attempts to register with the CS telephony network if the signal strength drops below a threshold.
As illustrated in FIG. 10, device 10 attempts to register with the CS telephony network by transmitting a Location Update message to MSC 314. Device 10 transmits the message using Radio Resource information of an MSC that was last associated with device 10 according to some embodiments. If the message successfully reaches an MSC, the MSC transmits a MAP Update Location message to associated HLR 312. To this point, the discussion of FIG. 10 complies with existing GSM protocols.
At step S610, a first message is received from a server of the CS network associated with the client device. The message comprises an instruction to deregister the client device from the IP telephony network. As shown in FIG. 10, MM-AS 400 receives a MAP Cancel Location message from HLR 312. MM-AS 400, at step S620 updates a record of VLR database 420 that is associated with device 10 and acknowledges the message from HLR 312.
A request is transmitted to a second server of the IP telephony network at S630. The request comprises a request to deregister the client device from the IP telephony network. In some embodiments, MM-AS 400 transmits such a request to CSCF 214 via an IMS Service Creation interface. Consequently, HSS 212 may update a record to indicate that client device 10 (i.e., an SIP URI of client device 10) is no longer registered with IP telephony network 20.
Again, MM-AS 400 emulates a GSM MSC/VLR in process 600 to provide roaming between a GSM network and an IMS network. Process 600 therefore does not require HLR 312 and MSC 314 to deviate from conventional GSM protocols.
FIG. 11 is a flow diagram of process 700 to support calls from a CS telephony network to a client telephony device that is registered with and roaming in an IP telephony network (i.e., Mobile Terminating Calls (MTCs). Other MTC scenarios (e.g., CS network to CS network, IP network to CS network, and IP network to IP network), may be implemented using conventional protocols.
Prior to process 700, a call is placed from a CS telephony network (e.g., PSTN, GSM, etc) to a telephone number associated with a client device that is registered with an IP telephony network. As illustrated in FIG. 12, the call may be routed to Gateway MSC (GMSC) 314 since the telephone number is owned by the CS domain. Moreover, the call may be routed via an Integrated Service Digital Network User Part (ISUP) Initial Address Message (IAM) that includes the telephone number.
In response to the ISUP IAM message, and according to conventional GSM protocols, GMSC 314 may query HLR 312 for an MSC/VLR with which client device 10 is currently registered. This query may comprise an MAP Send Routing Info message that includes the telephone number received from PSTN 305. Since client device 10 is currently registered with the IP telephony network, the central subscriber database of HLR 312 indicates that the MSC/VLR currently serving device 10 is MM-AS 400. Therefore, again according to conventional GSM protocols, HLR 312 transmits a message requesting MM-AS 400 to generate a roaming number associated with client device 10.
The message is received at step S710 of process 700. As shown in FIG. 12, the message may comprise an MAP Provide Roaming Number message including the IMSI of client device 10, which HLR 312 has determined from the received telephone number. Next, at step S720, a second identifier of the client device within the IP network is determined. MM-AS 400 may access the table of HSS 212 described with respect to step S520 at step S720 to determine an SIP URI that is associated with the received IMSI.
Based on the second identifier, MM-AS 400 may determine whether an associated client device is registered with the IP network at step S730. This determination may comprise a query to HSS 212 via CSCF 214 to determine whether the client device is registered.
If so, a roaming number associated with the client device is generated at step S740. The generated roaming number is a number that terminates to a gateway between the CS network and the IP network (e.g., MGCF 222). MM- AS 400 may store the roaming number in association with a record of client device 10 in VLR database 420. Next, at step S750, the roaming number is transmitted to the requesting server of the CS network. According to the FIG. 12 scenario, MM-AS 400 transmits roaming number to HLR 312 via a response to the MAP Provide Roaming Number message received in step S710.
GMSC 314 receives the roaming number from HLR 312 and places a call thereto using an ISUP IAM message including the roaming number. At step S760, the call is received at the gateway at which the roaming number terminates. In response to the received call, the gateway is configured to perform an ENUM query for the roaming number to MM-AS 400. MM-AS 400 receives such a query at step S770. The query for the roaming number may comprise an alternative type of query (e.g. SOAP/XML query, TCAP query, IN query) according to some embodiments.
MM-AS 400 determines an SIP URI corresponding to the roaming number based on VLR database 420. Then, at step S780, MM-AS 400 transmits the SIP URI to the gateway. According to conventional CS-to-IP call setup protocols, the gateway may transmit an SIP Invite message to the received SIP URI, as also illustrated in FIG. 12. Alternative mechanisms for this mapping.
In some embodiments, HSS 212 stores a user profile indicating that CSCF 214 is to forward all SIP calls to RVAS 234 and MM-AS 400. A call may be first forwarded to RVAS 234 for handling any call-specific voice features (e.g. Call Forwarding, etc.). RVAS 234 then returns the call to CSCF 214 for forwarding to MM-AS 400. MM-AS 400 may remain passively in the call leg as a Back-to-Back User Agent (BBUA) for use during any subsequent handover procedure.
In a case that a client device registers with a new network (i.e., CS to IP, IP to CS) during a call, it is preferable for the call to continue substantially seamlessly. FIG. 13 is a flow diagram of process 800 to provide handover from a CS telephony network to an IP telephony network.
Prior to process 800, a client telephony device may be registered with a CS network and may be periodically polling for WLAN network signal. Upon detecting a suitable signal and registering with the associated WLAN network, the device requests a temporary registration with the IP network.
The request is received at step S810, and the request includes an identifier of the client device within the IP telephony network (e.g., an SIP URI). MM-AS 400 may receive the request according to some embodiments of step S810. However, contrary to step S540 above, MM-AS 400 does not transmit a MAP Update Location message to an associated HLR 312 in response to the request.
Instead, the client device may transmit a periodic GSM Radio Resource Measurement Report to a serving MSC 314 of the CS network. The Report may include an identifier that identifies the IP network as providing a best signal level. MSC 314 then transmits a MAP Handover Request message to MM-AS 400. In this regard, the MSC 314 may have access to a mapping that associates the identifier received from the client device with an address of MM- AS 400.
MM-AS 400 then generates a handover number that is associated with the client device within the IP network, and to which a call may be placed using an ISUP IAM message. The handover number may terminate to a gateway between the CS network and the IP network (e.g., MGCF 222). MM-AS 400 may also store the handover number in association with a record of client device 10 in VLR database 420. The handover number is transmitted to MSC 314 at step S830 in response to the MAP Handover Request message. MSC 314 then places a call to the handover number using an ISUP IAM message. At step S840, the call is received at the gateway at which the handover number terminates. The gateway is configured to perform an ENUM (or other) query for the handover number in response to the received call. MM- AS 400 receives the query at step S850.
MM-AS 400 determines an SIP URI corresponding to the handover number based on VLR database 420. Then, at step S860, MM-AS 400 transmits the SIP URI to the gateway. According to conventional CS-to-IP call setup protocols, the gateway may then transmit an SIP Invite message to the received SIP URI.
After a call between the IP network and the client device is established, MM-AS 400 may transmit a MAP Send End Signal message to the serving MSC 314. The third message requests the MSC 314 to terminate the call within the CS telephony network. According to some embodiments, client device 10 then performs a standard (i.e., non-temporary) SIP registration procedure in order to update its registration information in HLR 312.
FIGS. 14A and 14B generally illustrate process 800 according to some embodiments. As shown in FIG. 14A, client device 10 is registered with and connected in a call to serving MSC 314. MSC 314 in turn connects client device 10 with a caller registered with a CS or IP telephony network via HLR 312. Process 800 results in establishment of a call between client device 10 and the IP network via MM-AS 400 and HLR 312, and termination of the HLR 310/MSC 314 call leg.
FIG. 15 is a flow diagram of process 900 to provide handover from an IP telephony network to a CS telephony network. According to some embodiments of process 900, MM-AS 400 sets up a second call leg to client device 10, and then instructs MGCF 222 to connect an existing call leg to the second call leg.
Prior to process 900, a client telephony device may be registered with an IP network and in a call with another calling device that is registered with an IP or a CS telephony network. The first client telephony device may be periodically polling for an IP network signal. Upon detecting unsuitable WLAN signal strength, the device transmits a handover request to MM-AS 400 via an SIP Invite message.
The request is received at step S910, and the request includes various CS network parameters from which an MSC may be determined. MM-AS 400 therefore refers to internal provisioning tables to map the parameters to an identifier of a particular MSC 314. MM-AS then transmits a MAP Prepare Handover message at step S920 to the particular MSC 314 via MGCF 222.
MM-AS receives a handover number from MSC 314 at step S930 in response to the MAP Handover Request message. Also received at step S930 is data usable to communicate with the CS network. This data may comprise GSM Radio Resource information, and is usable to access an MSC at which the handover number terminates.
MM-AS 400 transmits the data to client device 10 at step S940 in response to the SIP Invite message received at step S910. Client device 10 may initialize Radio Resource layer 132 of GSM signaling stack 130 with the received data.
Next, at step S950, MM-AS 400 transmits an SIP Invite message including the handover number to a gateway between the CS network and the IP network (e.g., MGCF 222). The gateway then places a call to the handover number (which terminates at a particular MSC) using an ISUP IAM message. Once the call from the gateway to the handover number is established, client device 10 attempts to access the particular MSC via the CS network by using the data provided at step S940.
Client device 10 then transmits a signal to the CS network indicating successful access of the particular MSC via the CS network. As a result, the MSC transmits a MAP Send End Signal message to MM-AS 400. The message requests termination of the call within the IP telephony network, and is received by MM-AS 400 at step S960.
Next, at step S970, MM-AS 400 transmits an SIP Refer message to the gateway. The message comprises an instruction to join the ISUP call leg between the MSC and the gateway with the ISUP call leg between the gateway and the other client device that is in the call with client device 10.
FIGS. 16A through 16C generally illustrate process 900 according to some embodiments. At the beginning of process 900, and as shown in FIG. 16A, client device 10 is registered with MM-AS 400 and connected in a call to MGCF 222. MSC 314 represents one MSC of GSM network 310 within CS network 30. Next, as shown in FIG. 16B, a first call is established between MGCF 222 and MSC 314 and a second call is established between client device 10 and MSC 314.
Finally, FlG. 16C illustrates joining of the call between MGCF 222 and MSC 314 with the call between MGCF 222 and the other calling device located in one of networks 20 and 30. FIG. 16C also illustrates termination of the IP call leg between client device 10 and the IP telephony network.
Process 1000 of FIG. 17 sets forth an alternative procedure to handover a call from an IP telephony network to a CS telephony network. In some embodiments of process 1000, client device 10 sets up a second call leg over the CS network to the IP telephony network, and a gateway between the two networks connects a leg of the existing call to the second call leg.
A first message is received from client device 10 at step S1010. The message may comprise an SIP Invite message requesting handover of an existing call from the IP network to a CS network. The existing call may connect the client device with another calling device registered with the IP telephony network or the CS telephony network. Client device 10 may transmit the first message upon detecting unsuitable WLAN signal strength or based on any other reason.
MM-AS 400 generates a handover number that terminates at MGCF 222 and transmits the handover number to client device 10 at step S1020. The handover number may be transmitted via an SIP 183 Session Progress message. MM-AS 400 may also store an association between the handover number and an SIP URI of client device 10 in VLR database 420.
Client device 10 then transmits a MAP Location Update message to register with an MSC of the CS network, and places a call to the handover number via the CS network. Since the handover number terminates at MGCF 222, the call is received by MGCF 222 at step S1030. MGCF 222 performs an ENUM query for the handover number in response to the received call. The query is received by MM-AS 400, which, at step S1040, determines the SIP URI associated with the handover number in VLR database 420.
Next, at step S1050, MM-AS 400 transmits an acknowledgement of the first message to client device 10. The acknowledgement causes device 10 to transfer its audio resources to the call to the handover number. MM-AS 400 transmits a message to MGCF 222 at step S1060. The message instructs MGCF 222 to join the CS call to the handover number with the call between the gateway and the other client device. FIGS. 18A through 18C generally illustrate process 1000 according to some embodiments. As shown in FlG. 18A, process 1000 begins with client device 10 being registered with MM-AS 400 and connected in a call to MGCF 222. MGCF 222 is also connected, via CS network 30 or IP network 20, to another calling device.
FIG. 18B illustrates establishment of a CS call from device 10 to a handover number terminating at MGCF 222. Lastly, FIG. 18C illustrates joining of the CS call between MGCF 222 and device 10 with the call between MGCF 222 and the other calling device located in one of networks 20 and 30. FIG. 18C also illustrates termination of the IP call leg between client device 10 and the IP telephony network.
The above-mentioned signals and messages may pass through any number of networks, devices and protocols before reaching their intended recipient. Such networks include but are not limited to local area networks, wide area networks, telephone networks, cellular networks, fiber-optic networks, satellite networks, infra-red networks, radio frequency networks, and any other type of networks which may be used to transmit information between devices. Additionally, data may be transmitted using one or more currently- or hereafter-known network protocols, including but not limited to Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP) and Wireless Application Protocol (WAP).
Embodiments described above are not intended to be limited to the specific form set forth herein, but are intended to cover such alternatives, modifications and equivalents as can reasonably be included within the spirit and scope of the appended claims.

Claims

WHAT IS CLAIMED IS:
1. A method comprising: providing selectable registration of a client telephony device with a circuit-switched telephony network or with an Internet Protocol (IP) telephony network.
2. A method according to Claim 1 , further comprising: providing roaming of the client device between the circuit-switched telephony network and the IP telephony network, termination of calls to the client device roaming in the IP telephony network from the circuit-switched telephony network, and handover of calls between the IP telephony network and the circuit-switched telephony network.
3. A method according to Claim 1 , further comprising: receiving a first message to register the client device with the IP telephony network, the first message including a first identifier of. the client device within the IP telephony network; determining a second identifier of the client device within the circuit- switched telephony network based on the first identifier; determining a server of the circuit-switched telephony network associated with the client device based on the second identifier; and transmitting a second message to the server to update a location of the client device, the second message comprising the second identifier and a third identifier of a server of the IP telephony network.
4. A method according to Claim 3, wherein the first message comprises a Session Initiation Protocol Register message, wherein the second message comprises a Mobile Application Part Update Location message, wherein the first identifier comprises a Session Initiation Protocol Uniform Resource Identifier, wherein the second identifier comprises an International Mobile Subscriber Identity, and wherein the server of the circuit-switched telephony network comprises a Home Location Register.
5. A method according to Claim 3, further comprising: receiving user profile data associated with the client device from the server of the circuit-switched telephony network; and updating a database record of the server of the IP telephony network with the user profile data, wherein the database record is associated with the client device.
6. A method according to Claim 1 , further comprising: receiving a first message from a server of the circuit-switched telephony network associated with the client device to deregister the client device from the IP telephony network.
7. A method according to Claim 6, further comprising: updating a database record of a server of the IP telephony network and associated with the client device based on the first message; and transmitting a request to a second server of the IP telephony network to deregister the client device from the IP telephony network.
8. A method according to Claim 7, wherein the first message comprises a Mobile Application Part Cancel Location message, and wherein the second server of the IP telephony network comprises a Home Subscriber Server.
9. A method according to Claim 1 , further comprising: receiving a message from a server of the circuit-switched telephony network to generate a roaming number associated with the client device, the message including a first identifier of the client device within the circuit- switched telephony network; determining a second identifier of the client device within the IP telephony network based on the first identifier; determining whether the client device is registered within the IP telephony network based on the second identifier; generating a roaming number associated with the client device; transmitting the roaming number to the server of the circuit-switched telephony network; receiving a call to the roaming number at a gateway between the circuit- switched telephony network and the IP telephony network; receiving a query from the gateway, the query including the roaming number; and transmitting the second identifier to the gateway in response to the query.
10. A method according to Claim 9, wherein the server of the circuit-switched telephony network comprises a Home Location Register, wherein the first identifier comprises an International Mobile Subscriber Identity, wherein the second identifier comprises a Session Initiation Protocol Uniform Resource Identifier, wherein the message comprises a Mobile Application Part Provide Roaming Number message, wherein the call to the roaming number comprises an Integrated Service Digital Network User Part Initial Address Message, and wherein the gateway comprises a Media Gateway Control Function.
11. A method according to Claim 1 , further comprising: receiving a first message to register the client device with the IP telephony network, the first message including a first identifier of the client device within the IP telephony network; receiving a second message from the circuit-switched telephony network, the second message requesting a handover of a call within the circuit- switched telephony network to the IP telephony network; transmitting a handover number to the circuit-switched telephony network in response to the second message, the handover number being associated with the client device within the IP telephony network; receiving a call to the handover number at a gateway between the circuit-switched telephony network and the IP telephony network; receiving a query from the gateway, the query including the handover number; transmitting the first identifier to the gateway in response to the query; and transmitting a third message to the circuit-switched telephony network to terminate the call within the circuit-switched telephony network.
12. A method according to Claim 11 , wherein the first message comprises a Session Initiation Protocol Register message, wherein the second message comprises a Mobile Application Part Prepare Handover message, wherein the first identifier comprises a Session Initiation Protocol Uniform Resource Identifier, wherein the gateway comprises a Media Gateway Control Function, wherein the call to the handover number comprises an Integrated Service Digital Network User Part Initial Address Message, and wherein the third message comprises a Mobile Application Part End of Signal message.
13. A method according to Claim 1 , further comprising: receiving a first message from the client telephony device requesting a handover of a call within the IP telephony network to the circuit-switched telephony network; transmitting a second message to the circuit-switched telephony network, the second message requesting the handover of the call within the circuit-switched telephony network to the IP telephony network; receiving a third message from the circuit-switched telephony network, the third message including a handover number and data usable to communicate with the circuit-switched telephony network; transmitting the data to the client telephony device in response to the first message; transmitting a request to a gateway between the circuit-switched telephony network and the IP telephony network, the request to establish a call to the circuit-switched telephony network using the handover number; receiving a fourth message from the circuit-switched telephony network requesting termination of the call within the IP telephony network; and in response to the fourth message, transmitting a fifth message to the gateway to join the call within the IP telephony network with the call to the circuit-switched telephony network.
14. A method according to Claim 13, wherein the first message comprises a Session Initiation Protocol Invite message, wherein the second message comprises a Mobile Application Part Prepare Handover message, wherein the third message comprises a Mobile Application Part Handover Request message, wherein the data comprises Global System for Mobile Telecommunication Radio Resource information, wherein the gateway comprises a Media Gateway Control Function, wherein the fourth message comprises a Mobile Application Part End of Signal message, and wherein the fifth message comprises a Session Initiation Protocol Refer message.
15. A method according to Claim 1 , further comprising: receiving a first message from the client telephony device requesting a handover of a call within the IP telephony network to the circuit-switched telephony network; transmitting to the client telephony device a second message including a handover number associated with the IP telephony network and with the client device; receiving a call to the handover number within the circuit-switched telephony network at a gateway between the circuit-switched telephony network and the IP telephony network; determining an identifier of the client device within the IP telephony network based on the handover number; transmitting an acknowledgement of the first message to the client device; and transmitting a third message to the gateway to join the call to the handover number within the circuit-switched telephony network call with the call within the IP telephony network.
16. A method according to Claim 15, wherein the first message comprises a Session Initiation Protocol Invite message, wherein the gateway comprises a Media Gateway Control Function, wherein the first identifier comprises a Session Initiation Protocol
Uniform Resource Identifier, and wherein the third message comprises a Session Initiation Protocol Refer message.
18. A medium storing program code, the program code comprising: code to provide selectable registration of a client telephony device with a circuit-switched telephony network or with an Internet Protocol (IP) telephony network.
19. A medium according to Claim 18, the program code further comprising: code to provide roaming of the client device between the circuit-switched telephony network and the IP telephony network, termination of calls to the client device roaming in the IP telephony network from the circuit-switched telephony network, and handover of calls between the IP telephony network and the circuit-switched telephony network.
20. A medium according to Claim 18, the program code further comprising: code to receive a first message to register the client device with the IP telephony network, the first message including a first identifier of the client device within the IP telephony network; code to determine a second identifier of the client device within the circuit-switched telephony network based on the first identifier; code to determine a server of the circuit-switched telephony network associated with the client device based on the second identifier; and code to transmit a second message to the server to update a location of the client device, the second message comprising the second identifier and a third identifier of a server of the IP telephony network.
21. A medium according to Claim 20, wherein the first message comprises a Session Initiation Protocol Register message, wherein the second message comprises a Mobile Application Part Update Location message, wherein the first identifier comprises a Session Initiation Protocol Uniform Resource Identifier, wherein the second identifier comprises an International Mobile Subscriber Identity, and wherein the server of the circuit-switched telephony network comprises a Home Location Register.
22. A medium according to Claim 20, the program code further comprising: code to receive user profile data associated with the client device from the server of the circuit-switched telephony network; and code to update a database record of the server of the IP telephony network with the user profile data, wherein the database record is associated with the client device.
23. A medium according to Claim 18, the program code further comprising: code to receive a first message from a server of the circuit-switched telephony network associated with the client device to deregister the client device from the IP telephony network.
24. A medium according to Claim 23, the program code further comprising: code to update a database record of a server of the IP telephony network and associated with the client device based on the first message; and code to transmit a request to a second server of the IP telephony network to deregister the client device from the IP telephony network.
25. A medium according to Claim 24, wherein the first message comprises a Mobile Application Part Cancel Location message, and wherein the second server of the IP telephony network comprises a Home Subscriber Server.
26. A medium according to Claim 18, the program code further comprising: code to receive a message from a server of the circuit-switched telephony network to generate a roaming number associated with the client device, the message including a first identifier of the client device within the circuit-switched telephony network; code to determine a second identifier of the client device within the IP telephony network based on the first identifier; code to determine whether the client device is registered within the (P telephony network based on the second identifier; code to generate a roaming number associated with the client device; code to transmit the roaming number to the server of the circuit-switched telephony network; code to receive a call to the roaming number at a gateway between the circuit-switched telephony network and the IP telephony network; code to receive a query from the gateway, the query including the roaming number; and code to transmit the second identifier to the gateway in response to the query.
27. A medium according to Claim 26, wherein the server of the circuit-switched telephony network comprises a Home Location Register, wherein the first identifier comprises an International Mobile Subscriber Identity, wherein the second identifier comprises a Session Initiation Protocol Uniform Resource Identifier, wherein the message comprises a Mobile Application Part Provide Roaming Number message, wherein the call to the roaming number comprises an Integrated Service Digital Network User Part Initial Address Message, and wherein the gateway comprises a Media Gateway Control Function.
28. A medium according to Claim 18, the program code further comprising: code to receive a first message to register the client device with the IP telephony network, the first message including a first identifier of the client device within the IP telephony network; code to receive a second message from the circuit-switched telephony network, the second message requesting a handover of a call within the circuit- switched telephony network to the IP telephony network; code to transmit a handover number to the circuit-switched telephony network in response to the second message, the handover number being associated with the client device within the IP telephony network; code to receive a call to the handover number at a gateway between the circuit-switched telephony network and the IP telephony network; code to receive a query from the gateway, the query including the handover number; code to transmit the first identifier to the gateway in response to the query; and code to transmit a third message to the circuit-switched telephony network to terminate the call within the circuit-switched telephony network.
29. A medium according to Claim 28, wherein the first message comprises a Session Initiation Protocol Register message, wherein the second message comprises a Mobile Application Part Prepare Handover message, wherein the first identifier comprises a Session Initiation Protocol Uniform Resource Identifier, wherein the gateway comprises a Media Gateway Control Function, wherein the call to the handover number comprises an Integrated Service Digital Network User Part Initial Address Message, and wherein the third message comprises a Mobile Application Part End of Signal message.
30. A medium according to Claim 18, the program code further comprising: code to receive a first message from the client telephony device requesting a handover of a call within the IP telephony network to the circuit- switched telephony network; code to transmit a second message to the circuit-switched telephony network, the second message requesting the handover of the call within the circuit-switched telephony network to the IP telephony network; code to receive a third message from the circuit-switched telephony network, the third message including a handover number and data usable to communicate with the circuit-switched telephony network; code to transmit the data to the client telephony device in response to the first message; code to transmit a request to a gateway between the circuit-switched telephony network and the IP telephony network, the request to establish a call to the circuit-switched telephony network using the handover number; code to receive a fourth message from the circuit-switched telephony network requesting termination of the call within the IP telephony network; and code to transmit, in response to the fourth message, a fifth message to the gateway to join the call within the IP telephony network with the call to the circuit-switched telephony network.
31. A medium according to Claim 30, wherein the first message comprises a Session Initiation Protocol Invite message, wherein the second message comprises a Mobile Application Part Prepare Handover message, wherein the third message comprises a Mobile Application Part Handover Request message, wherein the data comprises Global System for Mobile Telecommunication Radio Resource information, wherein the gateway comprises a Media Gateway Control Function, wherein the fourth message comprises a Mobile Application Part End of Signal message, and wherein the fifth message comprises a Session Initiation Protocol Refer message.
32. A medium according to Claim 18, the program code further comprising: code to receive a first message from the client telephony device requesting a handover of a call within the IP telephony network to the circuit- switched telephony network; code to transmit to the client telephony device a second message including a handover number associated with the IP telephony network and with the client device; code to receive a call to the handover number within the circuit-switched telephony network at a gateway between the circuit-switched telephony network and the IP telephony network; code to determine an identifier of the client device within the IP telephony network based on the handover number; code to transmit an acknowledgement of the first message to the client device; and code to transmit a third message to the gateway to join the call to the handover number within the circuit-switched telephony network call with the call within the IP telephony network.
33. A medium according to Claim 32, wherein the first message comprises a Session Initiation Protocol Invite message, wherein the gateway comprises a Media Gateway Control Function, wherein the first identifier comprises a Session Initiation Protocol Uniform Resource Identifier, and wherein the third message comprises a Session Initiation Protocol Refer message.
34. An Internet Protocol (IP) telephony network comprising: an IP Multimedia Subsystem (IMS) Home Subscriber Server; an IMS Call Session Control Function; and an application server in communication with the IMS Call Session Control Function to provide selectable registration of a client telephony device with a circuit-switched telephony network or with the IP telephony network.
35. A system according to Claim 34, wherein the application server is to emulate at least a Global System for Mobile Telecommunication (GSM) Mobile Switching Center/Visitor Location Register (MSC/VLR).
36. A system according to Claim 34, wherein the application server is to provide roaming of the client device between the circuit-switched telephony network and the IP telephony network, termination of calls to the client device roaming in the IP telephony network from the circuit-switched telephony network, and handover of calls between the IP telephony network and the circuit-switched telephony network.
37. A system according to Claim 34, wherein the circuit-switched telephony network comprises a Global System for Mobile Telecommunication (GSM) network, and wherein the application server is to: receive a Session Initiation Protocol Register message to register the client device with the IP telephony network, the Session Initiation Protocol Register message including a Session Initiation Protocol Uniform Resource Identifier of the client device within the IP telephony network; determine a International Mobile Subscriber Identity of the client device within the GSM network based on the Session Initiation Protocol Uniform Resource Identifier; determine a Home Location Register of the GSM network associated with the client device based on the International Mobile Subscriber Identity; and transmit a Mobile Application Part Update Location message to the Home Location Register to update a location of the client device, the Mobile Application Part Update Location message comprising the International Mobile Subscriber Identity and a GSM MSCVVLR identifier associated with the application server.
38. A system according to Claim 37, wherein the application server is to: receive user profile data associated with the client device from the Home Location Register; and update a database record of the application server with the user profile data, and wherein the database record is associated with the client device.
39. A system according to Claim 34, wherein the circuit-switched telephony network comprises a Global System for Mobile Telecommunication (GSM) network, and wherein the application server is to: receive a Mobile Application Part Cancel Location message from a Home Location Register of the GSM network associated with the client device to deregister the client device from the IP telephony network; update a database record of the application server and associated with the client device based on the Mobile Application Part Cancel Location message; and transmit a request to the Home Subscriber Server to deregister the client device from the IP telephony network.
40. A system according to Claim 34, wherein the circuit-switched telephony network comprises a Global System for Mobile Telecommunication (GSM) network, and wherein the application server is to: receive a Mobile Application Part Provide Roaming Number message from a Home Location Register of the GSM network to generate a roaming number associated with the client device, the Mobile Application Part Provide Roaming Number message including an International Mobile Subscriber Identity of the client device within the GSM telephony network; determine a Session Initiation Protocol Uniform Resource Identifier of the client device within the IP telephony network based on the International Mobile Subscriber Identity; determine whether the client device is registered within the IP telephony network based on the Session Initiation Protocol Uniform Resource Identifier; generate a roaming number associated with the client device; transmit the roaming number to the Home Location Register of the GSM network; receive an Integrated Service Digital Network User Part Initial Address Message including the roaming number at a Media Gateway Control Function between the GSM network and the IP telephony network; receive a query from the Media Gateway Control Function, the query including the roaming number; and transmit the Session Initiation Protocol Uniform Resource Identifier to the Media Gateway Control Function in response to the query.
41. A system according to Claim 34, wherein the circuit-switched telephony network comprises a Global System for Mobile Telecommunication (GSM) network, and wherein the application server is to: receive a Session Initiation Protocol Register message to register the client device with the IP telephony network, the Session Initiation Protocol Register message including a Session Initiation Protocol Uniform Resource Identifier of the client device within the IP telephony network; receive a Mobile Application Part Prepare Handover message from the GSM network, the Mobile Application Part Prepare Handover message requesting a handover of a call within the GSM network to the IP telephony network; transmit a handover number to the GSM network in response to the Mobile Application Part Prepare Handover message, the handover number being associated with the client device within the IP telephony network; receive an Integrated Service Digital Network User Part Initial Address Message including the handover number at a Media Gateway Control Function between the GSM network and the IP telephony network; receive a query from the Media Gateway Control Function, the query including the handover number; transmit the Session Initiation Protocol Register identifier to the Media Gateway Control Function in response to the query; and transmit a Mobile Application Part End of Signal to the GSM network to terminate the call within the GSM network.
42. A system according to Claim 34, wherein the circuit-switched telephony network comprises a Global System for Mobile Telecommunication (GSM) network, and wherein the application server is to: receive a Session Initiation Protocol Invite message from the client telephony device requesting a handover of a call within the IP telephony network to the GSM network; transmit a Mobile Application Part Prepare Handover message to the GSM network, the Mobile Application Part Prepare Handover message requesting the handover of the call within the GSM network to the IP telephony network; receive a Mobile Application Part Handover Request message from the GSM network, the Mobile Application Part Handover Request message including a handover number and Global System for Mobile Telecommunication Radio Resource information associated with the GSM network; transmit the Global System for Mobile Telecommunication Radio Resource information to the client telephony device in response to the Session Initiation Protocol Invite message; transmit a request to a Media Gateway Control Function between the GSM network and the IP telephony network, the request to establish a call to the GSM network using the handover number; receive a Mobile Application Part End of Signal message from the GSM network requesting termination of the call within the IP telephony network; and transmit, in response to the Mobile Application Part End of Signal message, a Session Initiation Protocol Refer message to the Media Gateway Control Function to join the call within the IP telephony network with the call to the GSM network.
43. A system according to Claim 34, wherein the circuit-switched telephony network comprises a Global System for Mobile Telecommunication (GSM) network, and wherein the application server is to: receive a Session Initiation Protocol Invite message from the client telephony device requesting a handover of a call within the IP telephony network to the GSM network; transmit to the client telephony device a Session Initiation Protocol 183 Session Progress message including a handover number associated with the IP telephony network and with the client device; receive a call to the handover number within the GSM network at a Media Gateway Control Function between the GSM network and the IP telephony network; determine an identifier of the client device within the IP telephony network based on the handover number; transmit an acknowledgement of the first message to the client device; and transmit a Session Initiation Protocol Refer message to the Media Gateway Control Function to join the call to the handover number within the GSM network call with the call within the IP telephony network.
PCT/US2006/011511 2005-03-30 2006-03-28 Ip and circuit-switched network interop-erability WO2006105223A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US66643305P 2005-03-30 2005-03-30
US60/666,433 2005-03-30
US67124405P 2005-04-14 2005-04-14
US60/671,244 2005-04-14

Publications (1)

Publication Number Publication Date
WO2006105223A1 true WO2006105223A1 (en) 2006-10-05

Family

ID=36677041

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2006/011511 WO2006105223A1 (en) 2005-03-30 2006-03-28 Ip and circuit-switched network interop-erability

Country Status (1)

Country Link
WO (1) WO2006105223A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007124306A2 (en) * 2006-04-19 2007-11-01 Qualcomm Incorporated Method and apparatus for dynamic anchoring of cs calls for cs-to-voip handoffs
WO2008047126A1 (en) * 2006-10-19 2008-04-24 Orange Sa Telecommunications system and method for inter access network handover
WO2008046303A1 (en) 2006-10-12 2008-04-24 Huawei Technologies Co., Ltd. Method for providing access mode selection to multimode terminal, system and apparatus thereof
WO2009058541A1 (en) * 2007-10-31 2009-05-07 Motorola, Inc. Method and system for providing a seamless handoff between communication networks
WO2009155285A1 (en) * 2008-06-20 2009-12-23 Interdigital Patent Holdings, Inc. Handling mobile terminated circuit-switched calls using an 802.21 media independent handover (mih) framework
EP2214375A1 (en) * 2009-01-30 2010-08-04 Alcatel Lucent Method for controlling voice communications in the absence of an IMS core network, and associated interoperation agent
US11729588B1 (en) 2021-09-30 2023-08-15 T-Mobile Usa, Inc. Stateless charging and message handling

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020141358A1 (en) * 2000-11-29 2002-10-03 Requena Jose Costa Mobile system, terminal and interface, as well as methods for providing backward compatibility to first and second generation mobile systems
US20030027569A1 (en) * 2001-07-31 2003-02-06 Ejzak Richard Paul Communication system for providing roaming between an internet protocol multimedia system and a circuit-switched domain
US20040184435A1 (en) * 2001-06-20 2004-09-23 Ilkka Westman System, device and method for providing call forwarding in dual subscription mode

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020141358A1 (en) * 2000-11-29 2002-10-03 Requena Jose Costa Mobile system, terminal and interface, as well as methods for providing backward compatibility to first and second generation mobile systems
US20040184435A1 (en) * 2001-06-20 2004-09-23 Ilkka Westman System, device and method for providing call forwarding in dual subscription mode
US20030027569A1 (en) * 2001-07-31 2003-02-06 Ejzak Richard Paul Communication system for providing roaming between an internet protocol multimedia system and a circuit-switched domain

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WANJIUN LIAO ET AL: "VoIP Mobility in IP/Cellular Network Internetworking", IEEE COMMUNICATIONS MAGAZINE, IEEE SERVICE CENTER, PISCATAWAY, US, vol. 38, no. 4, April 2000 (2000-04-01), pages 70 - 75, XP011091266, ISSN: 0163-6804 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8023497B2 (en) 2006-04-19 2011-09-20 Qualcomm Incorporated Method and apparatus for dynamic anchoring of CS calls for CS-to-VoIP handoffs
WO2007124306A3 (en) * 2006-04-19 2008-03-06 Qualcomm Inc Method and apparatus for dynamic anchoring of cs calls for cs-to-voip handoffs
WO2007124306A2 (en) * 2006-04-19 2007-11-01 Qualcomm Incorporated Method and apparatus for dynamic anchoring of cs calls for cs-to-voip handoffs
JP2009534943A (en) * 2006-04-19 2009-09-24 クゥアルコム・インコーポレイテッド Method and apparatus for dynamically anchoring a CS call for CS-to-VOIP handoff
WO2008046303A1 (en) 2006-10-12 2008-04-24 Huawei Technologies Co., Ltd. Method for providing access mode selection to multimode terminal, system and apparatus thereof
EP2061269A1 (en) * 2006-10-12 2009-05-20 Huawei Technologies Co Ltd Method for providing access mode selection to multimode terminal, system and apparatus thereof
US20090190533A1 (en) * 2006-10-12 2009-07-30 Huawei Technologies Co., Ltd. Method, system and apparatus for providing access mode selection to multimode terminal
US8750201B2 (en) 2006-10-12 2014-06-10 Huawei Technologies Co., Ltd. Method, system and apparatus for providing access mode selection to multimode terminal
US8699419B2 (en) 2006-10-12 2014-04-15 Huawei Technologies Co., Ltd. Method, system and apparatus for providing access mode selection to multimode terminal
EP2061269A4 (en) * 2006-10-12 2010-11-03 Huawei Tech Co Ltd Method for providing access mode selection to multimode terminal, system and apparatus thereof
WO2008047126A1 (en) * 2006-10-19 2008-04-24 Orange Sa Telecommunications system and method for inter access network handover
EP2575320A1 (en) * 2006-10-19 2013-04-03 France Télécom Telecommunications system and method for inter access network handover
WO2009058541A1 (en) * 2007-10-31 2009-05-07 Motorola, Inc. Method and system for providing a seamless handoff between communication networks
WO2009155285A1 (en) * 2008-06-20 2009-12-23 Interdigital Patent Holdings, Inc. Handling mobile terminated circuit-switched calls using an 802.21 media independent handover (mih) framework
FR2941839A1 (en) * 2009-01-30 2010-08-06 Alcatel Lucent METHOD FOR CONTROLLING VOICE COMMUNICATIONS IN THE ABSENCE OF IMS-TYPE NETWORK HEART AND ASSOCIATED INTERWORKING AGENT
EP2214375A1 (en) * 2009-01-30 2010-08-04 Alcatel Lucent Method for controlling voice communications in the absence of an IMS core network, and associated interoperation agent
US11729588B1 (en) 2021-09-30 2023-08-15 T-Mobile Usa, Inc. Stateless charging and message handling

Similar Documents

Publication Publication Date Title
US8521170B2 (en) System and method for routing an incoming call to a proper domain in a network environment including IMS
JP4800327B2 (en) Method and system for switching circuit-switched call connection
US9148288B2 (en) Conditional telecommunications
US20090185665A1 (en) Method and server/module for service configurations test
JP2010519790A (en) System and method for identifying voice call continuity (VCC) subscribers
WO2006105223A1 (en) Ip and circuit-switched network interop-erability
WO2016078290A1 (en) Method and apparatus for routing short message, and computer storage medium
MX2007014254A (en) Terminal, method and system for performing combination service using terminal capability version.
US20080004051A1 (en) SMS delivery over a multimedia subsystem
WO2006127417A1 (en) System to provide dual registration with an ip telephony network and a circuit-switched telephony network
US8340713B2 (en) Method and devices for supporting message services to a dual mode mobile station via a session initiation protocol
EP1794972A1 (en) Operating and supporting dual mode user equipment
EP1817871B1 (en) Method and devices for supporting a flexible handling of connections towards a dual mode mobile station
KR100953987B1 (en) Method and apparatus for notifying/receving change of service information according to state of terminal in wireless telecommunications system
WO2006058553A1 (en) Handing off a mobile station between a first access network supporting sip (session initiation protocol) and a second cellular access network
WO2016071073A1 (en) Provision of caller information
KR101743578B1 (en) Voice call continuity service providing systemn and method thereof
KR100800442B1 (en) Method for emergency calling wifi mobile communication terminal using it
CN101330752B (en) Method for implementing stride of individual network to network system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 06748886

Country of ref document: EP

Kind code of ref document: A1