WO2014116613A1

WO2014116613A1 - System and method for call session handover to ip network or cellular tdm network

Info

Publication number: WO2014116613A1
Application number: PCT/US2014/012407
Authority: WO
Inventors: Xiao Hua Wang
Original assignee: Wang xiao hua
Priority date: 2013-01-23
Filing date: 2014-01-21
Publication date: 2014-07-31

Abstract

Design described in this disclosure provide for the handover of one session initiated by VCC mobile device or by the network service server: a VCC (Voice/Video call continuity) service Application Server (VAS). In existing design or implementation, when need to handover call session to a different domain, a pre-configured handover Public Service Identity (PSI) stored in both VCC mobile device and VAS is used to make handover request in destination domain; also in existing design or implementation, when need to handover call session to a different domain, only pre-configured entity, either VCC mobile device or VAS can start handover call request.

Description

System and method for call session handover to IP network or Cellular

TDM network

RELATED APPLICATIONS

[001] This application is a non-provisional application claiming the benefit of U.S. Provisional Application Serial No. 61755471 , entitled "System and method of VCC call handover between IP network and Cellular TDM network," the entirety of which is hereby incorporated by reference.

TECHNICAL FIELD

[002] This disclosure relates to the handover of a call session to a different domain, and more particularly to the handover to an IP network or to a cellular CS (circuit switch) network of a session between a VCC mobile device and a peer party device attached to a public network (e.g., IP network, PSTN, PLMN).

BACKGROUND

[003] With the advent of modern communications, a variety of communications modalities and devices exist within a user's premises. Traditionally, customers made (and still make) telephone calls via the cellular network. Data communications modalities have since been introduced, including several broadband Internet protocol (IP) communications solutions that provide access to the Internet and World Wide Web. Although these broadband IP networks have been referred to as "fixed" because of the lack of mobility of the on-premises access point, they can still include the use of wireless technology. For example, wireless communications can be incorporated in the delivery infrastructure of the broadband network (such as satellite or radio transmission towers), and broadband IP networks can also be accessed via a local wireless network, such as a Wi-Fi network. These broadband networks have also allowed users to make telephone calls (voice calls) over the broadband IP network using Voice over IP (VoIP) technology.

[004] Mobile/ cellular communications devices, such as cellular handsets, have also become ubiquitous in modern society. VCC mobile devices can typically allow users to make telephone calls, send or receive electronic mail (e-mail), browse the World Wide Web, check appointments, and get directions, as well as perform many other functions. Telephone calls are typically handled via cellular networks. However, cellular networks can vary in quality and coverage area. It is typical for users having a cellular phone service to still use a fixed communications phone, such as a VoIP phone, to communicate once the users are in their premises.

[005] Voice call continuity represents an aim by the telecommunications industry to allow transitions between the IP domain and/ or the mobile domain. As an example of such a desired VCC (Voice/ Video call Continuity) process, a user's in-progress communication session, which may be a voice call, can move from a mobile/ cellular network to a Wi-Fi IP network while the user is on the same mobile device. This "handover" from cellular to IP should occur without any significant notice of interruption or disconnection by the user. VCC should allow, for example, a user that initiates a cellular phone call on his or her mobile device out of the home to continue with the same call on the same mobile device (but on the IP network) when the user arrives in his/her home. Conversely, if a user having a mobile device places a call over the IP network, and the signal to the Wi-Fi IP network degrades (for example if the user moves outside the premises), a VCC service should allow the user to continue with the communication on the same mobile device over the cellular CS network or another IP network. Video call continuity represents an aim to allow transitions between the different IP networks as well as between IP network and cellular CS network.

[006] Design described in this disclosure provide for the handover of one session initiated by VCC mobile device or by the network service server: a VCC (Voice/ Video call continuity) service Application Server (VAS). In existing design or implementation, when need to handover call session to a different domain, a pre-configured handover Public Service Identity (PSI) stored in both VCC mobile device and VAS is used to make handover request in destination domain; also in existing design or implementation, when need to handover call session to a different domain, only pre-configured entity, either VCC mobile device or VAS can start handover call request. This disclosure provides for the handover of one session in which: only need to configure Anchoring Processing Public Service Identity (APPSI) at the network VAS side; the network VAS assigns APPSls to call session and sets VCC anchoring information for call session; VAS saves call session and anchoring information into APS (Anchoring Processing Server) database; the VAS and the VCC mobile device both exchange call session information, VCC service information, VCC service control information, and Anchoring information when IP connection available between a VCC mobile device and a VAS; based on the VCC service information exchanged, both VAS and VCC mobile device can use APPSI to initiate handover call sessions to the new selected network from current network. VAS uses an APPSI to map a combination of a VCC mobile device with a VCC UE ID, a call session, a network domain that the call session can be handover to. VAS sends the mappings to a VCC mobile device through IP network. VCC mobile device and VAS both can use the mapping to control a call session handover.

BRIEF DESCRIPTION OF THE DRAWINGS

[007] FIG. 1 is a block diagram illustrating an example network environment operable to provide holdover of sessions in converged networks.

[008] FIG. 2 is a flow chart illustrating a call session process that can be performed by a VAS (VCC Application Server) to facilitate the transfer of a session between a VCC mobile device and peer CPE connected to an IP network. In this diagram, the VCC mobile device sends the call session to the VAS and the VCC mobile device initiates session handover request.

[009] FIG. 3 is a flow chart illustrating a call session process that can be performed by a VCC Application Server to facilitate the transfer of a session between a VCC mobile device and the VAS connected to an IP network. In this diagram, the VAS is responsible to send call session to a VCC mobile device and the VAS initiates handover call request.

[010] FIG. 4 is a flow chart illustrating an example process that can be performed by a VCC Application Server to facilitate the transfer of a session between a VCC mobile device and peer CPE connected to an IP network in case that CS is using GSM network and IP network, SIP is used as call session control. In this diagram, VCC client in the VCC mobile device initiates handover request call.

[011] FIG. 5 is a session flow diagram illustrating an example implementation of a handover process of a session between a VCC mobile device and peer CPE connected to either an IP network or PSTN. In this diagram, network side VAS initiates handover request call. In this case, the CS network is using GSM network and in IP network, SIP is used as call session control.

[012] FIG. 6 is a session flow diagram illustrating another example implementation of a handover process of a session between a VCC mobile device and peer CPE connected to an IP network. A VAS works as IMS application server to provide VCC service for VCC mobile device.

[013] FIG. 7 is a block diagram illustrating an example of hardware that can be used to process the handover of a session.

[014] Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

[015] In some design of this disclosure, systems and methods can operate to provide session handovers between domains in converged networks. This disclosure describes various implementations of systems and methods of a VCC convergence network that can provide for the handover of a session, including a handover from the IP network to the mobile network of a session between a VCC enabled mobile device and a CPE device connected to an IP network, or a CPE device connected to a PSTN. The components used in supporting this feature can include a VCC Application Server (VAS) operative to facilitate connections between a VCC mobile device and user devices connected to a cellular network, PSTN network, or a broadband IP network. The following disclosure describes various implementations and changes operable to facilitate the session handover feature in more detail.

[016] FIG. 1 is a block diagram illustrating an example VCC converged services network environment 100 operable to provide handover of session between domains using anchoring processing handover public service identity (APPSI), wherein the sessions is between a mobile device and a CPE (e.g., a PSTN land line or cellular phone). In some design, a VCC application server (VAS) 150 is operable to serve as a converged services platform that interconnects and routs communications to user devices, which can be connected to a mobile/cellular network 110, a broadband IP network 130, or a PSTN network 120.

[017] The mobile/ cellular network 110 can include a number of VCC mobile devices 115a-b, 155 that communicate with cellular towers. Each of the cellular towers can communicate with VCC mobile devices 115a-b, 155 in a cell assigned to that cellular tower. VCC mobile devices 115a-b, 155 can communicate with the cellular towers via wireless links llOa-c. The cellular network can be of any variety, including a Global System for Mobile communications (GSM), Universal Mobile telecommunications System (UMTS), Long Term Evolution (LTE), Code Division multiple access (CDMA) system, General Packet Radio Service (GPRS), Evolution- Data Optimized (EV-DO), Enhanced Data Rates for GSM Evolution (EDGE), 3GSM, Digital Enhanced Cordless Telecommunications (DECT), Digital AMPS (IS-136/TDMA), and Integrated Digital Enhanced Network (iDEN). Typical multiplexing schemes used by these networks include frequency division (FDM), time division multiple access (TDM), code division multiplex (CDM), and space division multiplex (SDM), each of which can use appropriate access schemes (e.g., FDMA, TDMA, CDMA, and SDMA). VCC mobile devices 115a-b, 155 can include cellphones, smartphones, portable computing devices, as well as other devices capable of carrying data and voice.

[018] The broadband IP network 130 can be any type of broadband network and can include a communications network capable of using Internet Protocol to deliver voice and data. CPE devices 130a-b can have the functionality of telephones or other computing devices integrated into the CPE device 130a-b. The CPE 130a-b can also be connected to a wireless local area network (WLAN) device, such as, for example, wireless access point 140. Wireless access point 140 can be a wireless router that operates in accordance with the IEEE 802.11 family of standards and serve as an access point to the IP network 130. Alternatively, the CPE 130a-b can have internal wireless routing functionality incorporated into it.

[019] The IP network 130 can also be provided using asynchronous transfer mode (ATM), digital subscriber line (DSL), or asymmetric digital subscriber line (ADSL) technology. ATM and DSL/ ADSL equipment can be located at an exchange or central office, and can include integrated DSL/ ATM switches, multiplexers such as digital subscriber line access multiplexers (DSLAMS), and broadband remote access servers (B-RAS), all of which can contribute to the aggregation of communications from user equipment onto a high-capacity uplink (ATM or Gigabit Ethernet backhaul) to internet service providers (ISPs). Transmission media connecting the central office and user equipment can include both twisted pair and fiber. For the user to access the DSL network, customer premises equipment 130a-b, each of which can have its own MAC address, can be, for example, a DSL modem. The DSL modem can also have wireless routing functionality or be connected to a wireless access point, the examples of which were discussed above.

[020] In addition to data over DSL based solution as described above, the IP network 130 can also be provided via cellular data network 3G, 4G, as well as via WiMAX networks implementing, the IEEE 802.16 family of wireless networking standards. [021] Customer premises devices 120a-b, such as telephones, can also be connected to a PSTN 120. The PSTN 120 can be connected to the cellular network 110 and the IP network 130 via the VCC Application Server 150.

[022] In example designs, VCC communication device 155, which can also be referred to herein as VCC mobile device 155, can have client software that enables it to operate as a multi- modem handset that can communicate via both a cellular network and an IP network. For example, it can communicate via cellular network 110, using wireless link 110a. Wireless link 110a can include GSM, UMTS, or CDMA links. As another example, VCC mobile device 155 can access IP network 130, by communicating with the wireless access point 140 via wireless data link 140a. VCC mobile device 155 can access IP network 130, by communicating with the wireless access point 145 via wireless data link 145a which can include IP, GSM, LTE, Wi-MAX, Wi-Fi, or CDMA links.

[023] In example designs, a VCC mobile device 155 can be operative to communicate with the VAS 150. The VAS 150 can handle messaging and routing between the cellular network 110, IP network 130, and the PSTN 120. The VAS 150 can be a computing device having software that makes it operative to provide the functionalities described herein. In example designs, the VAS 150 can be operative to process signaling protocols, for example SIP, and handle session setup, session connect, session management, and session teardown. The VAS 150, operating as a SIP server, can serve as one or more of a registrar server, a location service database, a redirect server, or a proxy server. The VAS 150 can be placed or reside on any of the networks (e.g., within a headend of the IP network 130).

[024] In some designs, the VAS 150 can perform gateway functions. VAS routes the call among IP, PSTN and cellular. The VAS 150 can process one or more signaling protocols, including but not limited to SIP, SIP-T, GSM, CDMA, MAP, and SS7. In example implementations using Session Initiation Protocol (SIP) communications, SIP universal resource identities (URIs) can be used to carry telephone numbers, as the mapping between SIP and telephony protocols has already been defined. The VAS 150 can be operative to facilitate the establishment, tear-down, or modification of sessions between VCC mobile device 155 and other peer devices, including mobile devices 115a-b, CPE devices 130a-b connected to the IP network 130, and / or CPE devices 120a-b connected to the PSTN 120.

[025] The VAS 150 can facilitate routing of communications with the VCC mobile device 155 through the use of a anchoring processing server and its database, which can periodically receive updates (e.g., a sip registration) from the VCC mobile device 155. The VAS 150 assigns APPSIs to each call session and uses APPSIs to set anchoring information for call session; VAS 150 saves all VCC service data into Anchoring Processing Server (APS 160). The Anchoring Processing Server (APS 160) stores all call sessions associated with the VCC mobile device 155; the Anchoring Processing Server (APS 160) also stores the call session anchoring processing instance, call session VCC anchoring information, and other VCC service data. The Anchoring Processing Server (APS 160) can identifies the call session by using combination of different keys: VCC UE ID (VCC User Entity Identity), APPSI, calling party and called party, etc. A call session anchoring processing instance is the running software at a VAS to process the call session.

[026] In example designs, when a wireless data link 140a is available, the VCC mobile device 155 can communicate through the IP network 130 with the VAS 150 via the wireless access point 140 and the wireless data link 140a. In the case of a voice call, the VCC mobile device can be operative to send and receive IP voice packets through the IP network 130. The VCC mobile device 155 can also initiate a session through the cellular network 110 via communications link 110a.

[027] As an example, VCC mobile device 155 can initiate a session via the cellular network 110 with a peer CPE device 130a-b connected to the IP network 130. A call session anchoring processing instance is the running software at a VCC mobile device to process a call session. The VCC mobile device 155 can send an active session request (e.g., a session setup request) through the cellular network 110 to the VAS 150. The VAS 150, upon receiving the request, facilitates the session setup between the VCC mobile device 155 and the IP peer CPE 130a-b. For the call session, the VAS 150 assigns multiple APPSIs (Anchoring Processing PSI) with this call session and creates anchoring information for the call session from the VCC mobile device. The APPSIs are part of call session anchoring information. VAS 150 stores call session and its anchoring information into an Anchoring Processing Server (APS 160). Multiple APPSIs are assigned to the call session for different network domain: an APPSI for Wi-Fi IP network handover request; an APPSI for LTE IP network handover request; an APPSI for cellular CS network handover request; an APPSI for other network, etc. At this time, VAS 150 sends anchoring information to the VCC mobile device 155 through IP network and the VCC mobile device 155 store call session and anchoring information locally. The VAS sets handover-in trigger and handover-out trigger for each network domain in anchoring information: e.g., for Wi-Fi IP network, the handover-in trigger is: packet delay is less than 50ms, Wi-Fi wireless signal strength is bigger than -60dbm and packet lost ration is less than 5%; for Wi-Fi IP network, the handover-out trigger is: Wi-Fi wireless signal strength is less than -90dbm or packet lost ration is bigger than 10% or packet delay is bigger than 80ms. When IP network available, the VCC mobile device also sends its VCC service capability (network support list, handover triggers capability, handover control capability) to the VAS 150. The VAS 150 stores VCC mobile device VCC service capability into the APS 160.

[028] In one example in which a session has been established through the cellular CS network 110, the VAS 150 can be operative to accept and handle the VCC mobile device 155 service request message from the IP network 130. This linking of the home wireless local area network and a user's VCC mobile device 155 provides convenience when VCC mobile device 155 is within the range of the user's on-premises wireless LAN. VCC mobile device 155 reports its call session information and its VCC service capability information to VAS 150 through the IP network 130. The call session information includes VCC UE ID (VCC User Entity Identity, which represents the VCC mobile device identity), calling party, called party, domain used for the call session, and a call session anchoring processing instance. In case of SIP used for call service in IP network, VCC mobile device 155 can report call session information in SIP registration message but not limited on this way; VAS 150 receives service registration message and gets the call session information. VAS 150 queries APS 160 and APS 160 returns call session VCC service data including APPSIs back to VAS 150. Then VAS 150 returns 200 OK for service registration message with VCC service data back to VCC mobile device 155; the VCC service data includes the following information but not limited: VAS VCC service capability, VCC mobile device VCC service capability, anchoring information (including APPSIs to domain mapping), and call session information. The VCC mobile device 155 receives the VCC service data from VAS 150. In case of VCC mobile device starting handover procedure to switch a call session to an IP network, the VCC mobile device 155 initiates a handover request call by using the IP network APPSI as called party number. This handover call request will be sent to the VAS 150 through IP network 130; in case of VAS starting handover procedure to switch a call session to an IP network, the VAS initiates a handover request call (using IP network APPSI as calling party number) to the VCC mobile device 155. This handover call request will be sent to VCC mobile device 155 through IP network 130.

[029] In some designs, when VAS 150 receives request call from VCC mobile device 155 with called party is APPIS, VAS 150 treats this call as handover request to the domain which the call request comes from; when VAS 150 receives handover request call from VCC mobile device 155, VAS 150 queries APS 160 and gets call session anchoring information, and does media handovers for the call session. VAS 150 also assigns new APPSIs to the call session and updates the APS 160 about the new anchoring information.

[030] In some designs, when VAS 150 receives a call session request from/ to a VCC mobile device 155 in IP domain, VAS 150 assigns multiple APPSIs to the call session; If this call is not a handover call, VAS 150 sets anchoring information where multiple APPSls are assigned and associated with the call session; If this call is a handover call (an APPSI is the called party of the call request), VAS 150 gets the call session anchoring processing instance from the APS 160 according to the VCC UE ID and the APPSI and does handover for this call session; VAS 150 also updates the APS 160 with new anchoring information; VAS 150 sends VCC service data to the VCC mobile device 155 through the IP network. The VCC mobile device 155 gets the APPSls for future to do handover call request. In case of SIP used for call session, when there is call to the VCC mobile device 155, the VAS 150 can use INVITE message to carry VCC service data but not limited. In case of SIP used for call session service in an IP network, when there is call from the VCC mobile device 155, the VAS 150 can use 180, 183 or 200 message to carry VCC service information but not limited. If any VCC service information changed, the VAS 150 updates the APS 160.

[031] The VCC mobile device 155 can initiates a handover request in Cellular network 110 when IP network 130 is not good for the call session service. The called party is the cellular CS network APPSI which is received through the IP network 130.

[032] FIG. 2 is a basic call flow diagram illustrating how and when session and anchoring information exchanging between a VCC mobile device (e.g., VCC mobile device 155) and networks. This diagram also illustrates how and when VCC mobile device and VAS store and use the anchoring information. In this diagram, a VCC mobile device makes decision and initiates handover request.

[033] At stage (1), a VCC mobile device (e.g., VCC mobile device 155) initiates a call in cellular CS network 110, and at stage (2), the Cellular CS network 110 and the VAS/SCP 150 will exchange information to make sure that the call session is routed to the VAS 150 for call session anchoring (ANSI-standard Wireless Intelligent Network (WIN) or 3GPP-standard Customised Applications for Mobile networks Enhanced Logic (CAMEL) service can be used to support call session anchoring). At stage (3), the cellular CS network 110 sends response message to the VCC mobile device 155 and at stage (4), the cellular CS network 110 routes the call session to the VAS 150.

[034] After receiving the call, the VAS/SCP 150 gets all call session information, assigns APPSls, and sets an anchoring information for the call session according to the client VCC service capability, and at stage (5), the VAS sends the VCC UE ID, the call session information, its anchoring information to the APS 160. Several APPSls are assigned to the call session, e.g. : APPSI1 for Wi-Fi IP network 1, APPSI2 for LTE IP network 2, APPSI3 for default IP network, APPSI5 for cellular CS network 1, APPSI6 for cellular CS network 2, etc. When handover to a new network, the assigned APPSI is used in call request.

[035] From stage (6) to stage (8), the call session connection is established between two end devices.

[036] When an IP network connection between the VCC mobile device 155 and the VAS 150 is available, at stage (9), the VCC mobile device 155 send call session information and its VCC service capability information to the VAS through IP network. The VCC service capability information includes the network supported, VCC service type support (voice, video), capability of triggering handover, capability to start the handover procedure.

[037] When receiving call session information and client VCC service capability information, at stage (10), the VAS queries anchoring information from the APS 160, and updates anchoring information for the call session according to the client VCC service capability; at stage (11), the VAS 150 sends session anchoring information including multiple APPSls back to the VCC mobile device 155 through IP network. The VCC mobile device 155 associates the anchoring information with the call session and at stage (12), the VCC mobile device 155 sends handover call request (IP network 1 APPSI is used as called party) to the VAS 150 through IP network. [038] Upon receiving handover request call, using the VCC UE ID and the APPSI, the VAS 150 gets the call session information at stage (13) from APS 160 and the VAS 150 does the domain transfer for the call session; the VAS 150 also sets new anchoring information with the call session. At the stage (14), new anchoring information and the VCC service control information are sent back to the VCC mobile device 155 through the IP network; the VCC mobile device 155 stores all information for future use. In this diagram, the VCC mobile device starts the handover request call.

[039] From Stage (15) to stage (17), the connection in the cellular network between VCC mobile device 155 and the VAS 150 is released and the anchoring information in the APS 160 database is also updated.

[040] When VCC mobile device 155 decides to handover the call session to the cellular network 1, it sends a handover call request (the called party of the call is set as the cellular CS network 1 APPSI) through the cellular network 1 at stage (18). At stage (19), the Cellular network 110 and the VAS/SCP 150 will exchange information to make sure the handover call request should be routed to VAS for VCC service. At stage (20), the Cellular network 110 send response message to the VCC mobile device 155 and at stage (21), the Cellular network 110 routes the call to the VAS 150.

[041] When finding the call is handover request call, the VAS 150 gets the detail call session information at stage (22). The VAS associates new anchoring resource to the call session, and at stage (23), updates the APS 160 with new anchoring information.

[042] From stage (24) to stage (26), the connection of call session in cellular CS network is established and the IP connection of the call session is release. When the call session is released at stage (27), the anchoring information in the APS 160 is cleared at stage (28).

[043] FIG. 3 is a basic call flow diagram illustrating how and when a call session and VCC service data exchanging between a VCC mobile device (e.g., VCC mobile device 155) and network server VAS 150. This diagram also illustrates how and when a VCC mobile device and the VAS store and use the VCC service data. In this diagram, a VAS makes session handover decision and starts handover procedure.

[044] At stage (1), a VCC mobile device (e.g., VCC mobile device 155) initiates a call through an IP network to the VAS 150. The VCC mobile device also sends its VCC service capability information to the VAS 150. There are two ways for the VCC mobile device to send its VCC service capability information to the VAS 150:

[045] First option: sending it as part of existing message (part of call request INVITE message or service registration REGISTER message if using SIP) from VCC mobile device to the VAS 150;

[046] Second option: sending it as separate VCC service information message from VCC mobile device to the VAS. This separate VCC service information message is total new message.

[047] The VAS assigns multiple APPSIs to this call session and sets anchoring information for this call session where APPSI-domain mappings are included in the anchoring information. At stage (2), the VAS sends the VCC service data back to the VCC Mobile device; the VCC service data includes the anchoring information such as multiple APPSI-domain mapping (APPSI1 is assigned as cellular CS network handover APPSI), VCC service control information, and other VCC service data. Upon receiving anchoring information from VAS 150, the VCC mobile device associates the anchoring information with the call session. The VAS 150 saves VCC service data including the anchoring information to the APS 160 at stage (3). From stage (4) to stage (6), the connection of the call session is established successfully through the IP network between the VCC mobile device 155 and the VAS 150.

[048] If the VAS 150 detects that the IP connection is not good for the call session, the VAS 150 decides to handover the session to the Cellular network 110. At stage (7), the VAS 150 gets the VCC mobile device call session and its anchoring information; at stage (8), the VAS sends handover request call ( the calling party of the call is set as APPSI1, which is the cellular CS network APPSI) through the cellular network 110 where the VCC mobile device (e.g., VCC mobile device 155) attaches. The VAS 150 switches the call session connection from IP network to the cellular network after sending the call out. At stage (9), the handover request call is received by the VCC mobile device (e.g., VCC mobile device 155) and the VCC mobile device (e.g., VCC mobile device 155) switch session connection from the IP network to the cellular network after checking the call session information and the VCC service data. From stage (10) to stage (12), session connection is switched to the cellular network; the old connection in the IP network is released; the anchoring information in the APS 160 is updated by the VAS 150.

[049] At stage (13), the VCC mobile device (e.g., VCC mobile device 155) and the VAS 150 find IP network 1 available for call session VCC service. At stage (14), The VAS 150 gets the VCC mobile device (e.g., VCC mobile device 155) call session information and the call session anchoring information. At stage (15), the VAS 150 and the VCC mobile device (e.g., VCC mobile device 155) exchanges call session information and VCC service data (including call session anchoring information) through IP network 1; the VAS can sends the call session information to the VCC mobile device (e.g., VCC mobile device 155) or the VCC mobile device (e.g., VCC mobile device 155) can sends the call session information to the VAS 150 through IP network 1. At this stage, the VAS sends the server VCC service capability information to the VCC mobile device and the VCC mobile device sends the client VCC service capability information to the VAS.

[050] At stage (16), the VAS also sends the anchoring information (APPSI2 is assigned as the IP network 1 APPSI) and VCC service data to the VCC mobile device (e.g., VCC mobile device 155). At stage (16), the VCC mobile device (e.g., VCC mobile device 155) associates the anchoring information with the call session.

[051] When the VAS 150 decides to handover the call session from the CS domain to the IP domain 1, at stage (17), it sends handover call request (the calling party of the call is set as APPSI2, which is IP network 1 APPSI) to the VCC mobile device (e.g., VCC mobile device 155) through IP domain. The VAS 150 also does the call session domain transfer from the CS domain to the IP domain.

[052] After the VCC mobile device (e.g., VCC mobile device 155) receives handover call request at stage (17), it finds the matched call session and then the VCC mobile device switches the call session connection to the IP network 1. At stage (18), the connection of the call session between the VCC mobile device (e.g., VCC mobile device 155) and the VAS 150 is through the IP network 1.

[053] From stage (19) to stage (21), the cellular CS connection of the call session between the VCC mobile device (e.g., VCC mobile device 155) and the VAS 150 is released and the VAS 150 also updates the remote peer side about the session connection change. Because of new connection established, the VAS 150 sets the new anchoring information for the call session. The VAS 150 sends the anchoring information and VCC service control information to the VCC mobile device (e.g., VCC mobile device 155) at stage (22) through the IP network. The VCC mobile device (e.g., VCC mobile device 155) updates the call session anchoring information upon receiving the anchoring information at stage (22). The VAS 150 sends the new anchoring information to the APS 160 at stage (23).

[054] When the VAS 150 find IP network 2 available for call session service and the IP network 2 has higher priority than current IP network 1 has, at stage (24), the VCC mobile device and the VAS 159 exchange call session information, VCC service data, and call session anchoring information (APPSI2 is assigned as the IP network 2 APPSI) through IP network 2. The VAS 150 decides to handover the call session from IP network 1 to IP network 2 and at stage (25), the VAS 150 get the call session information as well as associated anchoring information. [055] At stage (26), the VAS 150 sends handover call request (the calling party of the handover call request is set as the APPSI3, which is IP network 2 APPSI) to the VCC mobile device (e.g., VCC mobile device 155) through the IP network 2. The VAS 150 also does the call session domain transfer from the IP network 1 to IP network 2. Upon receiving handover request from the IP network 2 at stage (26), the VCC mobile device (e.g., VCC mobile device 155) finds the call session and switches the call session connection from the IP network 1 to IP network 2. At stage (27), the call session connection is established through IP network 2.

[056] Because of new connection established, the VAS 150 sets the new anchoring information for the call session, and the VAS 150 sends the anchoring information and VCC service data to the VCC mobile device (e.g., VCC mobile device 155) at stage (28). The VCC mobile device (e.g., VCC mobile device 155) updates the anchoring information association upon receiving the anchoring information at stage (28). The VAS 150 also sends the new anchoring information to the APS 160 at stage (29).

[057] FIG. 4 is a call flow diagram illustrating call session set up in cellular GSM CS domain and being transferred to IP domain. In IP domain, Session Initiation Protocol (SIP, RFC 3261) is used for call session service. This call session is initiated by a VCC mobile device (e.g., VCC mobile device 155) and the peer party is a CPE device connected to an IP network (e.g., IP peer CPE 130a).

[058] From stage (1) to stage (5), a VCC mobile device (e.g., VCC mobile device 155) initiates a call in cellular GSM CS domain network 110 and the call reaches the VAS/SCP 150. After analyzing the call isn't a handover call, the VAS (e.g., VAS 150) gets the VCC mobile device UE ID (VCC UE ID), assigns multiple APPSIs to this call session SI (caller party number, called party number, domain used for call, service type, call session anchoring processing instance) for the VCC UE ID (the VCC mobile device ID). At stage (6) the VAS 150 saves VCC UE ID, anchoring information (including APPSIs), and the call session information into the APS 160.

[059] From stage (7) to stage (9) the call is established successfully between the VCC mobile device 155 and the peer CPE 130a.

[060] At stage (10), when VCC mobile device 155 decides to do domain transfer from the cellular network 110 to the IP network 130, the VCC mobile device 155 sends a SIP registration message to the VAS 150 through the IP network. The SIP registration message includes a new SIP call session header that carries the call session information that the VCC mobile device 155 current has. The new SIP call session header includes following information: caller party, called party, domain used for call session. The following are the example of the header:

[061] Call-session: VCC UE ID: 5551212, calling party=5551212,called party=5551234,domain used: GSM, session service type=voice;

[062] At stage (11), when the VAS 150 receives the VCC mobile device 155 registration message, the VAS 150 gets call session information from the registration message. The VAS 150 gets the VCC mobile device VCC UE ID, queries anchoring information from the APS 160. At stage (12), the APS 160 returns anchoring information (including APPSIs) and call session information back to the VAS 150.

[063] At stage (13), when the VAS 150 sends 200 OK Registration back to the VCC mobile device 155. Inside the 200 OK registration message, a VCC AP header is included. The following is an example of this header looks like but not limited to this format:

[064] Call-session-AP-information: calling party=5551212,called party=5551234, IP APPSI=APPSI1, IP network priority=l, cellular CS APPSI=APPSI2, cellular CS network priority =3, session service type=voice, handover control=VCC Mobile Device;

[065] Inside the VCC AP header, "IP APPSI=APPSI1" means when handover to IP network, APPSI1 will be used to make handover request call; "IP network priority=l" means any available IP network has highest priority to be used for call session handover; "cellular CS APPSI=APPSI2" means when handover to a cellular CS network, APPSI2 will be used to make handover request call; "cellular CS network priority =3" means priority of cellular CS network for VCC service is 3 and it's lower than that of IP network; "handover control=VCC Mobile Device" means that VCC mobile device start handover procedure if the call session needs to be switched to a new domain.

[066] After VCC mobile device 155 receives 200 OK message, it saves anchoring information locally; because the IP network has high priority for call session, at stage (14), the VCC mobile device 155 generates a SIP INVITE message(the called party is set as APPSIl and the calling party is set as the VCC mobile device UE ID) and sends the message to VAS 150. The VAS 150 gets the message, finds that the call is handover request call. The VAS 150 gets the calling party VCC UE ID, and at stage (15), the VAS 150 queries anchoring information from the APS 160 with VCC UE ID and APPSIl. At stage (16), the APS 160 returns response call session information including the call session anchoring processing instance back to the VAS 150.

[067] Upon receiving response from the APS 150 at stage (16), the VAS does the domain transferring. Because this handover call request creates a new connection between the VCC mobile device 155 and the VAS 150, the VAS 150 assigns multiple APPSIs to this session. At stage (17), the VAS 150 sends 200 OK message for the handover request call to the VCC mobile device 155. Inside the 200 OK message, VAS 150 inserts a new VCC AP header that indicates the multiple APPSIs can be used for next handover request when applicable. The following is an example of this header looks like but not limited to this format:

[068] Call-session-AP-information: calling party=5551212,called party=5551234, Wi-Fi IP network APPSI= APPSIl, Wi-Fi IP network priority=l, LTE IP network APPSI=APPSI2, LTE IP network priority =2, cellular CS network APPSI=APPSI3, cellular CS network priority =3, session service type=voice, handover control=VCC mobile device;

[069] Inside the VCC AP header, "Wi-Fi IP network APPSI=APPSI1" means when handover to Wi-Fi IP network, APPSIl will be used to make handover request call; "Wi-Fi IP network priority=l" means Wi-Fi IP network has highest priority to be used for call session service; "LTE IP network APPSI=APPSI2" means when handover to LTE IP network, APPSI2 will be used to make handover request call; "LTE IP network priority=2" means LTE IP network has second highest priority to be used for call session handover; "cellular CS APPSI=APPSI3" means when handover to a cellular CS network, APPSI3 will be used to make handover request call; "cellular CS network priority =3" means that priority of cellular CS network for VCC service is 3 and it's lower than that of any IP network; "handover control=VCC Mobile Device" means that VCC mobile device start handover procedure if the call session needs to be switched to a new domain.

[070] When APPSI is used in a cellular CS network, it works like VDN; When APPSI is used in an IP network, it works like VDI.

[071] At stage (18), the VAS 150 informs the remote end user 130a of media changing because of domain transfer. At stage (19), the remote end user 130a responses the media update.

[072] At stage (20), the VAS 150 releases the cellular CS connection between the VAS 150 and the VCC mobile device 155. At stage (21), the VAS 150 sends the new anchoring information to the APS 160. The call session domain transferring from the cellular CS network to the IP network finishes.

[073] From stage (21) to stage (23), call is released between the VCC mobile devices and the remote end user 130a; at stage (24), the VAS 150 clears the anchoring information.

[074] FIG. 5 is a call flow diagram illustrating call session set up in IP domain and transferred to cellular GSM CS domain and then back to IP network again. This call session is initiated by a CPE device connected to an IP network (e.g., IP CPE 130a) and destination party is a VCC mobile device (e.g., VCC mobile device 155). In IP domain, Session Initiation Protocol (SIP, RFC 3261) is used for call session service. [075] At stage (1), the VCC mobile device 155 sends SIP registration message to the VAS 150 through IP network (for example through a Wi-Fi access point). Inside the SIP registration message, there is a VCC service capability header that indicates the VCC mobile device's VCC service and its service capability. The new VCC service capability header is added in the SIP register message as following but not limited in this format:

[076] VCC-Service-Capability-information: Network support (Wi-Fi, GSM network, CDMA network, GSM 3G, CDMA 3G, LTE, TD LTE, 4G, 5G), handover trigger (packet lost ratio threshold, packet delay threshold, wireless signal strength threshold), session type(voice, video), VCC handover control(yes);

[077] The network support includes all networks that the VCC mobile device can connect. This list can include any new type wireless network that can support VCC service.

[078] Handover trigger has three items: packet lost ratio threshold, packet delay threshold, and wireless signal strength threshold. It means the VCC mobile device can support three functions for all wireless networks if applicable. For example, when a Wi-Fi network is used for call session, the VCC mobile device can detect the packet lost ratio of the connection: if the number is bigger than the packet lost ratio hand-out threshold, then VCC mobile device will trigger the handover procedure to switch the call session to another network if applicable. In another case, when a Wi-Fi network is used for call session, the VCC mobile device can detect the wireless signal strength: if the number is less than the wireless signal strength hand-out threshold, then VCC mobile device will trigger the handover procedure to switch the call session to another network if applicable; the VCC mobile device can also detect the end-to end packet delay of the connection: if the number is bigger than the packet delay hand-out threshold, then VCC mobile device will trigger the handover procedure to switch the call session to another network if applicable. For handing in Wi-Fi case, when a cellular CS network is used for a call session, the VCC mobile device finds a Wi-Fi network available: the VCC mobile device measures packet lost ratio, packet delay, and wireless signal strength of the Wi- Fi network; if the wireless signal strength is bigger than the wireless signal strength hand-in threshold and/ or the packet lost ratio is less than the packet lost ratio hand-in threshold and/ or packet delay is less than the packet delay hand-in threshold, then VCC mobile device will trigger the handover procedure to switch the call session to the Wi-Fi network.

[079] "VCC handover control(yes)" indicates that the VCC mobile device can start handover procedure at any network. If "VCC handover control(no)" set, means the VCC mobile device can't start handover procedure at any network; if "VCC handover control(IP)" set, means the VCC mobile device can start handover procedure at any IP network; if "VCC handover control(cellular CS)" set, means the VCC mobile device can start handover procedure at any cellular CS network.

[080] At stage (2), the VAS 150 confirms registration successful by sending 200 OK back to VCC mobile devise 155; inside this 200 OK message, there is the VAS VCC service capability header added as following for example but not limited:

[081] VCC-Service-Capability-information: Network support (IP, GSM, CDMA, GSM 3G, CDMA 3G, LTE, TD LTE, 4G, 5G), handover trigger (packet lost ratio threshold, packet delay threshold), session type(voice, video), VCC handover control (yes);

[082] The network support includes all networks that the VAS can connect. This list can include any new type wireless network that can support VCC service. The "handover trigger" defines the VAS server capability of detecting packet lost ratio and packet delay for all kinds of network.

[083] "VCC handover control(yes)" indicates that the VAS can start handover procedure at any network. If "VCC handover control(no)" set, means the VAAS can't start handover procedure at any network; if "VCC handover control(IP)" set, means the VAS can start handover procedure at any IP network; if "VCC handover control(cellular CS)" set, means the VAS can start handover procedure at any cellular CS network.

[084] At stage (3), the IP CPE 130a initiates a call to the VCC mobile device 155 which phone number is A. Upon receiving this INVITE message, the VAS 150 gets the called party VCC UE ID, assigns multiple APPSIs to this call session, and sets anchoring information for the call session of VCC UE ID.

[085] At stage (4), the VAS 150 sends an INVITE message to the VCC mobile device 155 which includes a new VCC AP header and several handover trigger rules headers. These new headers carry the call session anchoring information. The VCC AP header includes the APPSIs information where the VCC mobile device 150 will use for future handover request. The VCC AP header looks like following but not limited to this format:

[086] Call-session-AP-information: Wi-Fi IP network APPSI=APPSI1, Wi-Fi IP network priority=l, handover control=VAS, handover in trigger = rulel, handover out trigger = rule2; cellular CS network APPSI=APPSI2, cellular CS network priority=3, handover control=VAS; LTE network APPSI=APPSI3, LTE network priority=2, handover control=VAS, handover in trigger = rule3, handover out trigger = rule4; session service type=video;

[087] The handover trigger rules headers looks like following but not limited to this format:

[088] Call-session-handover-trigger: rule 1 (packet lost ratio threshold=5%,&,wireless signal strength threshold = -70dbm,&,packet delay threshold = 50ms), rule 2 (packet lost ratio threshold=10%, | /wireless signal strength threshold = -90dbm, | ,packet delay threshold = 80ms), rule 3(wireless signal strength threshold = -60dbm), rule 4(wireless strength level threshold = -80dbm);

[089] Combining two headers together, for Wi-Fi IP network, "handover control=VAS" means that for Wi-Fi network, the VAS starts handover procedure; "handover in trigger = rulel" in VCC AP header and "rule l(packet lost ratio threshold=5%,&,wireless signal strength threshold = -70dbm,&,packet delay threshold = 50ms)" in handover trigger header define Wi-Fi network hand-in trigger detail information: if packet lost ratio threshold of connect is less than 5% and wireless signal strength threshold of Wi-Fi wireless signal is bigger than -70dbm and packet delay of end-to-end connection is less than 50ms, then this Wi-Fi network can be used for call session service.

[090] Combining two headers together, for Wi-Fi IP network, "handover out trigger = rule2" in VCC AP header and "rule 2 (packet lost ratio threshold=10%, | /wireless signal strength threshold = -90dbm, | ,packet delay threshold = 80ms)" in handover trigger header define Wi-Fi network hand-out trigger detail information: if packet lost ratio threshold of the connect through Wi-Fi network is bigger than 10% or wireless signal strength threshold of Wi-Fi wireless signal is less than -90dbm or packet delay of end-to-end connection through Wi-Fi AP is bigger than 80ms, then this Wi-Fi network can't be used for call session service, and needs to switch the call session from Wi-Fi network to another network.

[091] Combining two headers together, for LTE network, "handover in trigger = rule3" in VCC AP header and "rule 3(wireless signal strength threshold = -60dbm)" in handover trigger header define LTE network hand-in trigger detail information: if wireless signal strength threshold of LTE wireless signal is bigger than -60dbm, then this LTE network can be used for call session service.

[092] Combining two headers together, for LTE network, "handover out trigger = rule4" in VCC AP header and "rule 3(wireless signal strength threshold = -80dbm)" in handover trigger header define LTE network hand-out trigger detail information: if wireless signal strength threshold of LTE wireless signal is less than -80dbm, then this LTE network can' be used for call session service, and needs to switch call session from Wi-Fi network to another network.

[093] Upon receiving INVITE message from the VAS 150, at stage (5), the VCC mobile device 155 saves all VCC service data with the call session SI, returns 18x back to the VAS 150. [094] Upon receiving 18x message from the VCC mobile device 155, at stage (6), the VAS 150 saves VCC UE ID, call session information and anchoring information to the APS 160. At stage (6), The VAS 150 forwards 18x to the IP CPE 130a.

[095] At stage (8), the VCC mobile device 155 answers the call session request and the call session is established between two end users.

[096] When the VAS finds the packet lost ratio of the call session connection is bigger than packet lost ratio handover threshold (10%), the VAS 150 decides to handover the call session to the cellular CS network; at stage (9), using VCC UE ID, the VAS 150 sends query message to the APS 160 to get the call session information and its anchoring information. At stage (10), the APS 160 returns call session information and its anchoring information (including APPSIs) back to the VAS 150. At stage (11), the VAS 150 uses the APPSI2 as the calling party to send handover call request to the VCC mobile device 155 through the GSM cellular CS network 110. The called party is the VCC mobile device GSM ID. The VAS 150 makes the call session connection switching from the IP network to the cellular GSM CS network.

[097] At stage (12), upon receiving the handover call request, the VCC mobile device 155 gets the call session associated with the APPSI2 and transfer call session connection from IP network to the new GSM CS connection.

[098] From stage (13) to stage (14), the connection in the CS network is confirmed and the new connection is also updated up to the peer side; at stage (15), the IP connection of the call session is released between the VCC mobile device 155 and the VAS 150.

[099] Because of new CS connection, VAS assigns new anchoring information to the call session and at stage (16), the VAS 150 sends the new anchoring information to the APS 160.

[100] When VCC mobile device finds an IP network available (for example, a LTE IP network's priority is higher than current cellular CS network's priority), it sends registration message to the VAS at stage (17) through the new IP network. VAS finds the VCC UE registered and the VAS gets the VCC UE anchoring information and the call session information from stage (18) to stage (19). At stage (20), the VAS 150 sends the call session information and anchoring information to VCC mobile device through the new IP network. For example, the following two new headers are added in the 200 OK register message to carry the call session information and anchoring information but not limited:

[101] Call-session-AP-information: calling party=5551212,called party=5551234, Wi-Fi IP network APPSI=APPSI1, Wi-Fi IP network priority=l, handover control=VAS, handover in trigger = rulel, handover out trigger = rule2; cellular CS network APPSI=APPSI2, cellular CS network priority=3, handover control=VAS; LTE network APPSI=APPSI3, LTE network priority=2, handover control=VAS, handover in trigger = rule3, handover out trigger = rule4; session service type=video;

[102] Call-session-handover-trigger: rule 1 (packet lost ratio threshold=5%, wireless signal strength threshold = -70dbm,&, packet delay threshold 50ms), rule 2 (packet lost ratio threshold=10%,wireless signal strength threshold = -90dbm, | , packet delay threshold 80ms), rule 3(wireless signal strength threshold = -60dbm), rule 4(wireless strength level threshold = - 80dbm);

[103] The VCC mobile device associates the new anchoring information with the call session. As an option way, the VAS 150 can send the call session information and the VCC anchoring information to the VCC mobile device through SIP Notify message or other new defined SIP message with these kinds of headers. The VCC mobile device detects that the LTE network wireless signal strength is higher than handover-in threshold (-60dbm); the VCC mobile device reports this to the VAS 150.

[104] When the VAS 150 detects that the packet lost ratio of the IP network is less than hand- in threshold (5%), the packet delay of connection between the VAS and the VCC mobile device is less than 50ms, and upon receiving the VCC mobile device reporting of the wireless signal strength (better than -70dbm defined in the header), it starts handover procedure to switch the call session to the new IP network as indicated in the anchoring information. The VAS 150 sends the handover request to the VCC mobile device at stage (21) through the LTE IP network. Inside the SIP INVITE message, the From header contains APPSI3 information and the To header includes the VCC UE ID. The VAS does domain transfer for the call session.

[105] Upon receiving the call request and getting the APPSI3, the VCC mobile device switches the call session connection from the GSM CS network to the LTE IP network. At stage (22), the VCC mobile device sends 200 OK back to the VAS to confirm the connection request. At stage (23), the CS connection of the call session between the VCC mobile device and VAS is released.

[106] FIG. 6 is a call flow diagram illustrating call session set up in IP domain and transferred to cellular CS domain. This call session is initiated by a VCC mobile device (e.g., VCC mobile device 155) and destination party is a CPE device connected to an IP network (e.g., IP CPE 130a). IMS network is involved and the VAS 150 works as an IMS application server. All call session to/from the VCC mobile device 155 goes through the IMS network/ GW 135.

[107] At stage (1), the VCC mobile device 155 sends SIP registration message to the VAS 150 through IP IMS network 135. This SIP registration message includes the VCC mobile device VCC service capability header. At stage (2), the IMS network 135 forwards this message to the VAS 150 including the VCC service capability header. At stage (3) and stage (4), the VAS confirms registration successful by sending 200 (including the VAS VCC service capability header) back to VCC mobile devise 155 through the IMS network 135.

[108] At stage (5), the VCC mobile device 155 initiates a call to the IP CPE 130a which phone number is C. After receiving this INVITE message, at stage (6), the IMS network 135 forwards the call to the VAS 150. Upon receiving this INVITE message, the VAS 150 gets the calling party VCC UE ID, assigns multiple APPSls to this call session. The VAS 150 sets an anchoring information to the call session; at stage (7), the VAS 150 sends the call session information, VCC UE ID, and call session anchoring information to the APS 160.

[109] From stage (8) to stage (9), the call is forwarded to the IP CPE 130a. Upon receiving INVITE message, at stage (10), the IP CPE 130a sends SIP 18X back to the IMS network 135 and at stage (11), the IMS network forwards the SIP 18X to the VAS 150.

[110] Upon receiving SIP 18X message from the IP CPE 130a side, at stage (12) the VAS sends a SIP 18X message to the VCC mobile device 155 with the new VCC AP header that carries the anchoring information for this call session. At stage (13), the IMS network 135 forwards the SIP 18X message with the VCC AP header to the VCC mobile device 155. The VCC AP header looks like following but not limited to this format:

[111] Call-session-AP-information: Wi-Fi IP network APPSI=APPSI1, T-Mobile CS network PSI=APPSI2, cellular CS network APPSI=APPSI2, session service type=voice, handover control=VCC mobile device;

[112] The above AP header uses sequence of the network to indicate the network priority: Wi- Fi IP network is the first one so it has the highest priority; T-Mobile CS network is the second one, so it has second highest priority for call session service; all other cellular CS network is at last place, so it has the lowest priority for call session service, "handover control=VCC mobile device" means that VCC mobile device always starts the handover procedure.

[113] Upon receiving the 18X message from the VAS 150, at stage (13), the VCC mobile device 155 saves the anchoring information with the call session SI.

[114] At stage (14), the remote end user IP CPE 130a answers the call and sends 200 OK message back to the IMS network 135. At stage (15), the IMS network 135 forwards the 200 OK message to the VAS 150.

[115] At stage (16), the VAS 150 can add a new VCC AP header with APPSls into 200 OK message and sends to the VCC mobile device 155. At stage (17), the IMS network 135 finally forwards the 200 Ok message to the VCC mobile device 155. The VCC AP header looks like following but not limited to this format:

[116] Call-session-AP-information: Wi-Fi IP network APPSI=APPSI1, LTE IP network APPSI=APPSI1, Verizon CS network PSI=APPSI2, AT&T 4G network APPSI=APPSI2, cellular CS network APPSI=APPSI2, session service type=voice, handover control=VCC mobile device

[117] The above AP header uses sequence of the network to indicate the network priority: Wi- Fi IP network is the first one so it has the highest priority; LTE IP network is the second one, so it has second highest priority for call session service and so on. "handover control=VCC mobile device" means that VCC mobile device always starts the handover procedure. All IP networks can share same APPSI1 and all cellular CS networks can share the same APPSI2.

[118] When VCC mobile device 155 decides to handover the call to the cellular network, at stage (18), the VCC mobile device 155 sends call setup message to the cellular network where the called party number is set as APPSI2. Camel service triggered and the IDP message is sent to the VAS/SCP 150 at stage (19). The VAS/SCP 150 sends connection message with IMRN back to the cellular network at stage (20). At stage (21), the cellular network sends call proceeding message to the VCC mobile device 155.

[119] At stage (22) and stage (23), the IMRN call is forwarded to the VAS/SCP 150. When the VAS/SCP 150 receives the call from the IMS network 135, the VAS/SCP 150 gets the calling party number and APPSI2, and then gets the VC UE ID of the VCC mobile device 155.

[120] At stage (24), the VAS/SCP 150 sends query anchoring info message to the APS 160 and at stage (25), the APS 160 returns the call session information and its anchoring information back to the VAS/SCP 150.

[121] Upon receiving the anchoring info response message, the VAS/SCP 150 does the domain transfer the VCC mobile device 155 from the IP network to the cellular CS network. At stage (26), the VAS/SCP 150 sends confirm connection and finally to the VCC mobile device 155 through the cellular CS network.

[122] From stage (27) to stage (30), the VAS/SCP 150 sends the media change to the remote end user IP CPE 130a and the remote end user IP CPE 130a confirms the media change. At stage (31), the VAS 150 releases the IP connection between the VCC mobile device 155 and the VAS 150. Till now, the procedure of the call session domain transferring from IP to cellular CS network finishes. At stage (32), the VAS 150 sets new anchoring information for the call session and sends the new information to the APS 160 for updating.

[123] From stage (33) to stage (36), call session released by the IP CPE 130a; the VAS 150 releases connection with the VCC mobile device 155 and clear anchoring information in the APS 160. All call session and related anchoring information are cleared.

[124] FIG. 7 is a block diagram illustrating an example VCC services platform operable to provide call handover. The VCC services platform 500 can include a processor 510, a memory 520, a storage device 530, and an input/ output device 540. Each of the components 510, 520, 530, and 540 can, for example, be interconnected using a system bus 550. The processor 510 is capable of processing instructions for execution within the system 500. In one implementation, the processor 510 is a single-threaded processor. In another implementation, the processor 510 is a multi-threaded processor. The processor 510 is capable of processing instructions stored in the memory 520 or on the storage device 530. The memory 520 stores information within the device 500.

[125] In one implementation, the memory 520 is a computer-readable medium. In one implementation, the memory 520 is a volatile memory unit. In another implementation, the memory 520 is a non-volatile memory unit.

[126] In some implementations, the storage device 530 is capable of providing mass storage for the device 300. In one implementation, the storage device 530 is a computer-readable medium. In various different implementations, the storage device 530 can, for example, include a hard disk device, an optical disk device, flash memory or some other large capacity storage device.

[127] The input/ output device 540 provides input/ output operations for the device 500. In one implementation, the input/ output device 540 can include one or more of a PSTN interface (e.g., an Tl/El connector), an IP network interface device, e.g., an Ethernet card, a cellular network interface, a serial communication device, e.g., and RS-232 port, and/ or a wireless interface device, e.g., and 802.11 card. In another implementation, the input/ output device can include driver devices configured to receive input data and send output data to other input/ output devices, as well as sending communications to, and receiving communications from various networks.

[128] The above descriptions contained in each section are example designs.

[129] Any of the devices (e.g., soft-switch servers, cellular network side equipment, IMS servers, Mobile devices, etc.) and components thereof, or software modules/ programs described in this disclosure, can be realized by instructions that upon execution cause one or more processing devices to carry out the processes and functions described above. Such instructions can, for example, comprise interpreted instructions, such as script instructions, e.g., JavaScript or, or executable code, or other instructions stored in a computer readable medium.

[130] Implementations of the subject matter and the functional operations described in this specification can be provided in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible program carrier for execution by, or to control the operation of, data processing apparatus. The tangible program carrier can be a propagated signal or a computer readable medium. The propagated signal can be an artificially generated signal, e.g., a machine generated electrical, optical, or electromagnetic signal that can be generated to encode information for transmission to suitable receiver apparatus for execution by a computer. The computer readable medium can be a machine readable storage device, a machine readable storage substrate, a memory device, a composition of matter effecting a machine readable propagated signal, or a combination of one or more of them.

[131] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[132] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output thereby tying the process to a particular machine (e.g., a machine programmed to perform the processes described herein). The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[133] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The elements of a computer typically include a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a VCC mobile device, a telephone, a cable modem, a set-top box, a mobile audio or video player, or a game console, to name just a few.

[134] Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[135] To provide for interaction with a user, embodiments of the subject matter described in this specification can be operable to interface with a computing device having a display, e.g., a CRT (cathode ray tube), LCD (liquid crystal display), LED (light emitting diode) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

[136] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or of what might be claimed, but rather as descriptions of features that might be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features might be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination might be directed to a subcombination or variation of a subcombination.

[137] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing might be advantageous

[138] Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[139] Particular embodiments of the subject matter described in this specification have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results, unless expressly noted otherwise. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some designs, multitasking and parallel processing may be advantageous.

Claims

1. A method for a call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising:

assigning multiple Anchoring Processing Public Service Identities (APPSIs) to a call session from/ to a VCC mobile device at a converged service platform;

mapping selected APPSIs with destination domains where the call session can be

transferred to at the converged service platform;

setting anchoring information that including APPSIs mapping information for the call session at the converged service platform;

saving the call session and its anchoring information to an Anchoring Processing Server (APS) at the converged service platform;

querying the call session and its anchoring information from the Anchoring Processing Server (APS) at the converged service platform;

sending the call session information and its anchoring information to the VCC mobile device through an IP network at the converged service platform.

2. The method of claim 1, the Anchoring Processing Public Service Identity (APPSI) is a Public Service Identity (PSI) assigned to a VCC Application Server (VAS) in public network; in a public network that provides call session service, a call request with a APPSI as the called party of the call request is routed to the VAS that the APPSI is assigned to.

3. The method of claim 1, wherein the call session comprises a call session that a VCC mobile device sends through a cellular CS network:

4. The method of claim 1, wherein the call session comprises a call session that a VCC mobile device sends through an IP network:

5. The method of claim 1, wherein the call session comprises a call session to a VCC mobile device that the VCC mobile device receives the call session in a cellular network.

6. The method of claim 1, wherein the call session comprises a call session to a VCC mobile device that the VCC mobile device receives the call session in an IP network.

7. The method of claim 1, wherein anchoring information comprises multiple pairs of handover control information.

8. The method of claim 7, wherein the handover control information comprises a handover controller that indicates who will start call session handover procedure;

9. The method of claim 8, wherein the handover controller comprises one of VCC server or VCC mobile device:

10. The method of claim 7, wherein the handover control information comprises one or more handover trigger rule(s) that the rule(s) is used to trigger handover procedure;

11. The method of claim 10, wherein the handover triggering rule(s) comprises one or more a packet based trigger rule(s).

12. The method of claim 11, wherein the packet based trigger rule comprises a packet lost ratio handover-in threshold for an IP connection between a VCC mobile device and a VAS (the network can be used for call session handover-in if packet lost ratio of the IP connection is equal or less than this number).

13. The method of claim 11, wherein the packet based trigger rule comprises a packet lost ratio handover-out threshold of a IP connection between a VCC mobile device and a VAS (the network for the IP connection can't be used for call session and the call session need to be transferred to another domain if packet lost ratio of the IP connection is equal or higher than this number).

14. The method of claim 11, wherein the packet based trigger rule comprises a packet dealy handover-in threshold for an IP connection between a VCC mobile device and a VAS (the network can be used for call session handover-in if packet delay of the IP connection is equal or less than this number).

15. The method of claim 11, wherein the packet based trigger rule comprises a packet delay handover-out threshold of a IP connection between a VCC mobile device and a VAS (the network for the IP connection can't be used for call session and the call session need to be transferred to another domain if packet delay of the IP connection is equal or higher than this number).

16. The method of claim 10, wherein the handover triggering rule(s) comprises one or more wireless signal strength based trigger rule(s).

17. The method of claim 14, wherein the wireless signal strength trigger rule comprises a wireless signal strength handover-in threshold for a VCC mobile device in a wireless network (the network can be used for call session handover-in if actual wireless signal strength is equal or higher than this number).

18. The method of claim 14, wherein the wireless signal strength trigger rule comprises a wireless signal strength handover-out threshold for a VCC mobile device in a wireless network (the network can't be used for call session and the call session need to be transferred to another domain if actual signal strength is equal or less than this number).

19. The method of claim 7, wherein the handover control information comprises an APPSI;

20. The method of claim 7, wherein the handover control information comprises a destination domain.

21. The method of claim 7, wherein the handover control information comprises a destination domain priority that indicates this domain priority for a call session handover.

22. The method of claim 1, wherein the call session information comprises:

a VCC User Entity Identity (VCC UE ID) that represents a VCC mobile device user identity and is unique within a public network;

a call session anchoring processing instance that process the call session handover service.

23. The method of claim 1, wherein the call session information comprises a calling party.

24. The method of claim 1, wherein the call session information comprises a called party.

25. The method of claim 1, wherein the call session information comprises a domain that the call session uses for the call session connection.

26. The method of claim 1, wherein the domain comprises one of a wireless data network, a cellular network, or an operator defined network.

27. The method of claim 26, wherein the wireless data network domain comprises:

a Wi-Fi network, a cellular data network, a Wi-MAX network, a 3G network, and a 4G network.

28. The method of claim 26, wherein a cellular network domain comprises:

a CDMA network, a GSM network, and an operator defined network (e.g., AT&T network, Verizon)

29. The method of claim 26, wherein an operator defined network comprises:

a network that operator can use it to provide call session service for VCC mobile device.

30. The method of claim 1, wherein the Anchoring Processing Server (APS) is operable to: save a call session information and its anchoring information related to a VCC mobile device; update a call session information and its anchoring information related to a VCC mobile device; identify a call session information and its anchoring information related to a VCC mobile device;

31. The method of claim 1, wherein the VCC mobile device is operable to:

access a Wi-Fi network;

access one or more following networks: GSM network, CDMA network;

access one or more following networks: 2.5G wireless network, 3G wireless network, 4G wireless network, Wi-MAX;

send a client VCC service capability information to a VCC Application Server (VAS) through IP network when IP connection available between the VCC mobile device and the VAS;

send call session information to a VAS through an IP network;

receive call session information and its anchoring information from a VCC Application Server (VAS) through an IP connection;

start call session handover procedure if getting handover trigger event;

receive a call session handover request and perform the call session handover.

32. The method of claim 31, wherein the VCC service capability comprise:

a supporting Network domain list, a handover trigger list, a session type support list, and a handover control flag.

33. The method of claim 32, wherein the handover trigger list comprises a packet lost ratio threshold.

34. The method of claim 32, wherein the handover trigger list comprises a wireless signal strength threshold.

35. The method of claim 32, wherein the handover trigger list comprises a packet delay threshold.

36. The method of claim 32, wherein the session type support list comprises a voice service.

37. The method of claim 32, wherein the session type support list comprises a video service.

38. The method of claim 32, wherein the handover control flag comprises one of yes or no which indicates the entity can start handover procedure or not.

39. The method of claim 2, wherein the VCC Application Server (VAS) is operable to:

receive a VCC call session request to a VCC mobile device;

assign APPSIs to a call session;

set anchoring information for a call session;

send a call session request to a VCC mobile device through the domain that the VCC mobile device connects;

receive a call session request from a VCC mobile device through the domain that the VCC mobile device connect;

send a server VCC service capability information to a VCC mobile device through IP network when IP connection available between the VCC mobile device and the VAS;

send a call session information and its anchoring information to a VCC mobile device through IP network when IP connection available between the VCC mobile device and the VAS;

save a call session information and its anchoring information into a Anchoring Procession Server (APS);

identifying call session anchoring processing instance from the Anchoring Processing Server;

40. A method for a call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising: sending server VCC service capability information to a VCC mobile device through an IP network at a converged service platform;

41. The method of claim 31, wherein the VCC service capability information comprises domains which a VAS or a VCC mobile client can connect for a VCC call session service.

42. The method of claim 31, wherein the VCC service capability information comprises handover triggers for each domain which a VCC Application Server (VAS) or a VCC mobile device can support.

43. The method of claim 31, wherein the VCC service capability information comprises handover capability for each domain which a VAS or a VCC mobile client can start session handover procedure.

44. A method for a call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising:

receiving call session information from a VCC mobile device at a converged service platform; comparing and matching received call session information from th2 VCC mobile device with the local saved call session related to the VCC mobile device at the converged service platform;

45. A method for a call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising:

receiving a call session handover request where a APPSI is the called party in the call session handover request from a VCC mobile device through a new domain at a converged service platform;

determining call session anchoring processing instance is associated with the VCC mobile device at the converged service platform;

identifying call session anchoring processing instance from the Anchoring Processing Server at the converged service platform;

switching call session to the new domain where the received call session handover request comes from at the converged service platform;

46. A method for a call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising:

receiving client VCC service capability information from a VCC mobile device at a converged service platform;

47. A method for call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising:

receiving a call session request at a Voice/ Video call Continuity (VCC) mobile device;

sending a call session request at a VCC mobile device;

saving a client call session information for the call session at the VCC mobile device;

sending client call session information to the VAS through an IP network at the VCC mobile device;

48. A method for call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising:

receiving call session information and its anchoring information from a VCC Application Server (VAS) at the VCC mobile device;

comparing and matching received call session information with the client call session information at the VCC mobile device;

saving received call session information and its anchoring information at the VCC mobile device;

49. A method for call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising:

sending client VCC service capability information through an IP network to a VAS at a VCC mobile device;

50. A method for call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising:

receiving a call session handover request where a Anchoring Processing Public Service Identity (APPSI) is the calling party in the call session handover request through a new domain at the VCC mobile device;

identifying call session that the APPSI associates at the VCC mobile device; and

switching call session to the new domain where the received call session handover request goes through at the VCC mobile device.

51. A system for call session handover to a cellular circuit switch (CS) domain or an Internet Protocol (IP) domain, comprising:

a Voice/ Video call Continuity (VCC) Application Server (VAS) operable to set an anchoring information for a VCC call session; an Anchoring Processing Server operable to save, update, and identify the call session information and its anchoring information for a VCC mobile device; a VAS also operable to send the anchoring information and the call session to the VCC mobile device through IP network; the VCC mobile device operable to receive the call session information and its anchoring information from the VAS;

wherein the VAS or the VCC mobile device is operable to use the anchoring information to send a call session handover request when handover procedure triggered; the VAS or the VCC mobile device is further operable to identify the call session processing instance to perform the call session handover when receiving a call session handover request.