WO2014116757A1

WO2014116757A1 - System and method for concurrent call session(s) handover to ip network or cellular cs network

Info

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

Abstract

Design described in this disclosure provide for the handover of multiple concurrent call sessions 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(s) to a different domain, several pre-configured handover Public Service Identities (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: 1. Only need to configure Anchoring Processing Public Service Identity (APPSI) at the network VAS side; 2. The VAS assigns APPSIs to each concurrent call session and sets anchoring information for each call session according to APPSI assign rule; 3. A VAS saves all concurrent call sessions and anchoring information for each concurrent call session into APS (Anchoring Processing Server) database; 4. A VAS and a VCC mobile device both exchange concurrent call session(s) information, VCC service capability information, and the call session anchoring information for each concurrent call session when IP connection available between the VCC mobile device and the VAS; 5. Based on the VCC service data exchanged, both VAS and VCC mobile device can use APPSI to start handover call session procedure to switch the call session to the new selected network from current network. The main idea is: VAS uses an APPSI to map a combination of a VCC mobile device with a VCC UE ID, a call session, call session status, action of each call session action, a network domain that the call session is switch 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 handover for all concurrent call sessions.

Description

System and method for concurrent call session(s) handover to IP network or Cellular CS network

RELATED APPLICATIONS

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

TECHNICAL FIELD

[001] This disclosure relates to the handover of multiple call sessions to a different domain, and more particularly to the handover between two IP network and also to the handover between the Internet protocol (IP) network and the cellular circuit switch (CS) network of multiple call sessions between a VCC mobile device and several peer party devices attached to a public network (e.g., IP network, PSTN, or PLMN)

BACKGROUND

[002] 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.

[003] Mobile/ cellular communications devices, such as cellular handsets, have also become ubiquitous in modern society. Mobile communications 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.

[004] Voice call continuity represents an aim by the telecommunications industry to allow transitions between the IP domain and 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 calls, can move from the mobile/ cellular network to the 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 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. One VCC mobile device can have several call sessions at the same time and a VCC service should process them together. Video call continuity represents an aim to allow multiple video sessions transitions between different IP domains. [005] Design described in this disclosure provides for the handover of more than one call session; the call session handover procedure can be initiated by a VCC mobile device or by network VAS (Voice/ Video call continuity Application Server). In some existing design or implementation, when need to handover call session to a different domain, several pre- configured handover PSIs (Public Service Identity) stored in both VCC mobile device and VAS are 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 and can't change after system installed. This disclosure provides for the handover of more than one session (each call session includes calling party, called party, time stamp when the call session was created; each session for the same VCC mobile device can differentiates each other by the combination of calling party, called part, call session type, and time stamp: each call session for the same VCC mobile has a different set of {calling party, called party, call session type, time stamp}) in which: only need to configure Anchoring Processing Public Service Identity (APPSI) at the network VAS side; the network VAS assigns APPSls to each call session and sets VCC anchoring information for each 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 VCC mobile device and VAS; based on the VCC service information exchanged, both VAS and VCC mobile device can use APPSls to start handover procedure to switch all call sessions one by one 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 status of the call session, and a network domain that the call session can be handover to. Through this mapping method, both VAS/ APS and VCC mobile device can identify a call session from multiple concurrent call sessions for a same VCC mobile device. 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 procedure.

BRIEF DESCRIPTION OF THE DRAWINGS

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

[007] FIG. 2 is a flow chart illustrating multiple call sessions handover that can be performed by a VAS to facilitate the transfer of multiple call sessions between a VCC mobile device and several peer parties connected to a public network. In this diagram, all call session are established in an IP network first; VAS assigns multiple APPSls to each call session; VAS and VCC mobile device exchange VCC service information in IP network; VAS and VCC mobile device use APPSls to transfer all call sessions to a cellular CS network.

[008] FIG. 3 is a flow chart illustrating multiple call sessions handover that can be performed by a VAS to facilitate the transfer of multiple call sessions between a VCC mobile device and several peer parties connected to a public network. In this diagram, all call session are established in a cellular CS network first; VAS assigns multiple APPSls to each call session; when IP connection between VAS and VCC mobile device available, VAS and VCC mobile device exchange VCC service information in IP network; VAS and VCC mobile device use APPSls to transfer all call sessions to a IP network.

[009] FIG. 4 is a flow chart illustrating multiple call sessions handover that can be performed by a VAS to facilitate the transfer of multiple call sessions between a VCC mobile device and several peer parties connected to a public network. In this diagram, all call session are established in an IP network first; VAS assigns multiple APPSls to each call session; VAS and VCC mobile device exchange VCC service information in IP network; when a new IP connection 2 between VAS and VCC mobile device available, VAS and VCC mobile device exchange VCC service information in the new IP network 2; VAS and VCC mobile device use APPSIs to transfer all call sessions to the new IP network 2.

[010] FIG. 5 is a block diagram illustrating an example of hardware that can be used to process the handover of a session between a mobile communications device and peer CPE connected to a Public network.

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

DETAILED DESCRIPTION

[012] 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 (Voice/ Video Call Continuity) convergence network that can provide for the handover of multiple call sessions, including a handover from the IP network to the mobile network of multiple call sessions between a VCC enabled mobile communications device and several CPE devices connected to an IP network, several CPE devices connected to a PSTN, or several servers connected to an IP network. The components used in supporting this feature can include a VCC Application Server (VAS) operative to facilitate connections between a mobile communications 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 multiple call sessions handover feature in more detail.

[013] FIG. 1 is a block diagram illustrating an example VCC converged services network environment 100 operable to provide handover of multiple concurrent call sessions between domains using Anchoring Processing Public Service Identity (APPSI), wherein each session is between a VCC mobile device and a CPE (e.g., a PSTN land line, another VCC mobile device, or cellular phone). In some design, a 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. In some design, a VAS 150 assigns APPSIs to each call session, sets anchoring information for each call session, and saves call session and anchoring information in APS 160.

[014] The mobile/ cellular network 110 can include a number of mobile communications devices 115a-b, 155 that communicate with cellular towers. Each of the cellular towers can communicate with mobile communications devices 115a-b, 155 in a cell assigned to that cellular tower. Mobile communications 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). Mobile devices 115a-b, 155 can include cellphones, smartphones, portable computing devices, as well as other devices capable of carrying data and voice.

[015] 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.

[016] 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.

[017] 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.

[018] 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.

[019] 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- model 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, WiMAX, Wi-Fi, or CDMA links.

[020] 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).

[021] 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 1305, and/ or CPE devices 1250a-b connected to the PSTN 120.

[022] The VAS 150 can facilitate routing of communications with the VCC mobile device 155 through the use of a APS 160 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 APS 160. The APS 160 stores all call sessions associated with any VCC mobile device; the APS 160 also stores the call session anchoring processing instance, call session VCC anchoring information, and the call session VCC service data. The APS 160 can identify the call session by using combination of different keys: VCC UE ID, APPSI, calling party and called party, etc. A call session anchoring processing instance is the running software at a VAS to processing a call session.

[023] In example designs, when a wireless data link 140a is available, the mobile communications 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 mobile communications 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 call session through the cellular network 110 via communications link 110a.

[024] As an example, VCC mobile device 155 can initiate a call session via the cellular network 110 with a peer CPE device 130a connected to the IP network 130. 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 mobile communications device 155 and the IP peer CPE 130a. For the call session, the VAS 150 creates anchoring information for call session from the VCC mobile device and associates a set of APPSIs (Anchoring Processing PSI) with this call session. APPSIs are assigned to the call session for different purpose: for IP network handover, APPSI1 for normal handover, APPSI2 for on-hold handover, APPSI3 for on-hold release, APPSI4 for conference handover, APPSI5 for conference release, etc.; for cellular CS network, APPSI7 for normal handover, APPSI8 for on-hold handover, APPSI9 for on-hold release, APPSI10 for call-waiting handover, APPSI11 for call-waiting release etc.; for other network, APPSI12 for normal handover, APPSI13 for on-hold handover, etc. The above set of APPSIs and their purpose are part of anchoring information. VAS 150 stores call session and anchoring information into APS 160. 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. A call session anchoring processing instance, which is the running software at a VCC mobile device to process a call session, as a part of call session information, is also stored at the VCC mobile device 155.

[025] In one example in which a call session has been established through the cellular 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. The VAS 150 assigns APPSIs for this call session SI and saves anchoring information and call session SI into APS 160. 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 to the VAS 150 through the IP network 130. The call session SI information includes caller party information, called party information, the timestamp of this call session created, and domain information used for call session, but not limited these information. The VCC mobile device also can sends its VCC service capability (can do handover call request, etc.) to the VAS 150 through the IP network. 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. In case of SIP used for call service in IP network, VAS 150 receives service registration message and gets the call session information. VAS 150 queries APS 160 and APS 160 returns its all concurrent call session(s) and their VCC service data including anchoring information back to VAS 150; then VAS 150 returns 200 OK for service registration back to VCC mobile device 155; the anchoring information (including APPSIs), VAS 150 capability (VAS 150 can initiate handover request, etc.), handover control information (VAS or VCC mobile device does handover call request), and all concurrent call session(s) (including SI) information are part of VCC service data and they are included in this message. VCC mobile device 155 receives APPSIs and all concurrent call session(s) information from VAS 150 and the VCC mobile device 155 initiates a handover request call by using IP network normal APPSI1 as called party number. This handover call request will be sent to VAS 150 through IP network 130.

[026] In some designs, when VAS 150 receives request call from VCC mobile device 155 with called party is APPIS1, VAS 150 treats this call as session handover request from IP domain; then VAS 150 queries APS 160 and gets call session SI anchoring information and call session SI information, and does media handovers for the VCC mobile device 155. VAS 150 also assigns new APPSI set to the call session SI. The VAS 150 updates anchoring information for the call session.

[027] In some designs, when VAS 150 receives call from thirty party D to the VCC mobile device 155 in IP domain because IP network is ready for the VCC mobile device 155, VAS 150 finds out that there are more than one call session for the VCC mobile device 155; VAS 150 assigns different set of APPSIs to the new call session S2 and sets anchoring information for this call session S2; new APPSIs are assigned to the call session S2 for different purpose: for IP network handover, APPSI20 for normal handover, APPSI21 for on-hold handover, APPSI22 for on-hold release, APPSI23 for conference handover, APPSI24 for conference release, etc.; for cellular CS network, APPSI25 for normal handover, APPSI26 for on-hold handover, APPSI27 for on-hold release, APPSI28 for call-waiting handover, APPSI29 for call-waiting release etc.; for other network, APPSI30 for normal handover, APPSI31 for on-hold handover, etc. The two sets of APPSIs (for SI and S2) for the same VCC UE ID don't have common APPSI. VAS 150 saves anchoring information and the call session S2 into APS 160; VAS 150 sends anchoring information to VCC mobile device 155 through IP network. VCC mobile device 155 gets the anchoring information and saves it with the new call session; when need to handover, according to the selected network and call session status, both the VAS 150 and the VCC mobile device 155 can use the right APPSI to do handover request in new selected network.

[028] In case of SIP used for call session in IP network, when there is call to the VCC mobile device 155, VAS 150 can use INVITE message to carry VCC service data but not limited; when there is call from VCC mobile device 155, VAS 150 can use 180, 183 or 200 message to carry VCC service data but not limited.

[029] FIG. 2 is a basic call flow diagram illustrating how and when VCC service related information get exchanged between a VCC mobile device (e.g., VCC mobile device 155) and network VAS 150. This diagram also illustrates how and when VCC mobile device and VAS 150 store and use the anchoring information. In this diagram, a VCC mobile device and a VAS initiate handover request for different call session according to the VCC Service related information exchanged.

[030] At stage (1), a VCC mobile device (e.g., VCC mobile device 155) initiates a call session CI (the called party is the peer party C) to a VAS (e.g., VAS 150) through a Wi-Fi IP network. At the same time, the VCC mobile device sends its VCC service capability information to the VAS through the IP network. The VCC mobile device saves this call session information locally. The call session information in VCC mobile devices includes:

[031] The calling party (User A VCC UE ID), the called party (peer party C), call session handover allowed indicator (all allowed), timestamp for the call session created, network used for current call session (Wi-Fi IP), call status (active), a call session anchoring processing instance.

[032] A timestamp of a call session at a VCC mobile device is a timestamp when the call session is created; a VCC mobile device uses same rule to create timestamp for every call session. This will make sure that each call session has a different timestamp. VAS also creates a call session information for each call session with timestamp. This call session information in the VCC mobile device will be sent to VAS; VAS will compare it with local saved call session to make sure that the VAS side has a call session matched it. The sequence of timestamp for each call session is an element that both VAS and VCC mobile device can use this sequence to compare call session(s) to compare the call session(s) received from peer side.

[033] The call session handover allowed indicator can be set as the following: all allowed, not allowed, or, some network allowed and other not allowed; in this case it was set as all allowed.

[034] The network used for current call session can be set: Wi-Fi IP, Private Wi-Fi IP, 3G IP, LTE, GSM, CDMA, Wi-Max or other network. In this case, it was set as Wi-Fi IP because the Wi-Fi is used for this call session.

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

[036] The call status can be set as: active, on-hold, call-waiting, conference, other. Here set it as active.

[037] The VCC mobile device VCC service capability information includes the following information:

[038] Handover control flag; handover trigger; network type supported list; VCC service protocol type supported list.

[039] After receiving the call request and the VCC mobile device VCC service capability information, the VCC application server (VAS) set this call session as SI. The VAS sets VCC service anchoring information for this call session according to the both network side system VCC service capability and the VCC mobile device VCC service capability. The anchoring information includes anchoring processing information and VCC service handover control information. The most important resource used for VCC call session handover service is Anchoring Processing Public Service Identity (APPSI). 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 which that APPSI is assigned to. One or more APPSIs are assigned to the call session for different purpose. Both VAS and VCC mobile device can use assigned APPSI to start handover procedure; when receiving a session handover request call, the VAS or the VCC mobile device does the request action for the call session that the APPSI is assigned to. In this diagram, the set {APPSI1, APPS2, APPSI3 ..., APPSI18} is assigned to this call session SI.

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

[041] The call session information saved in the VCC service network side includes the following information:

[042] VCC UE ID; the calling party; the called party; call session VCC service allowed; timestamp for the call session created; network used (Wi-Fi IP); call status (active), a call session anchoring processing instance, handover sequence.

[043] The timestamp of a call session is a timestamp when the concurrent call session is created; a VAS uses same rule to create timestamp for each call session. This will make sure that each call session has a different timestamp.

[044] The anchoring processing information is set for each call session and it includes groups of the following 5 elements for each network domain:

[045] (1) network, which can be used for future call session connection: Wi-Fi, LTE, GSM, or CDMA, etc; these networks are supported by both VAS and VCC mobile device.

[046] (2)Handover control indicator: normal handover, on-hold (handover, released), conference control (add to conference, leave conference, other); each call session has different call status and for each status needs different handover action. In order to differentiate different handover action for each status, need to assign different APPSI for different handover action for each status.

[047] (3) APPSI: for each handover action of each status list above, need assign different APPSI for different handover action for each status.

[048] (4) handover control: VCC mobile device, VAS, or other; this shows that which entity starts the handover procedure for this network

[049] (5) network priority: this indicates the priority of the network for VCC call session service.

[050] The VCC service handover control information is set for all call session(s) and it includes groups of the following 4 elements for each network domain:

[051] (1) The network indicator: Public Wi-Fi IP, GSM, or LTE, etc.; the network for future call session connection;

[052] (2) The handover call allowed indicator: allowed or not allowed; the network can be used for handover service or not. If allowed, means call session can be switched to this network is the network fits the handover-in requirement.

[053] (3) The handover trigger: VCC mobile device or Network (VAS); this elements shows who triggers handover procedure.

[054] (4) The handover service triggering rule: packet, signal, other; for example, the packet lost ratio threshold, packet delay time threshold, and wireless signal strength threshold are three elements that can trigger the handover procedure. For handover out scenario, if packet lost ratio hand-out threshold is defined as 10%, when VCC mobile device or VAS detects that packet lost ratio of current connection used for the call session is high than 10%, the VCC mobile device or VAS will trigger handover procedure and system needs to find a new network for the call session; if packet delay hand-out threshold is defined as 100ms, when VCC mobile device or VAS detects that packet delay of current connection used for the call session is high than 100ms, the VCC mobile device or VAS will trigger handover procedure and system needs to find a new network for the call session; if wireless signal strength handout threshold is defined as -90dbm, when VCC mobile device detects that packet lost ratio of current connection used for the call session is less than -90dbm, the VCC mobile device will trigger handover procedure and system needs to find a new network for the call session; if wireless signal strength hand-out threshold is defined as -90dbm, when VCC mobile device detects that wireless signal strength of wireless network used for the call session is less than - 90dbm, the VCC mobile device will trigger handover procedure and system needs to find a new network for the call session. For handover in scenario, if handover procedure to Wi-Fi network is triggered, the following hand-in requirements are defined for a Wi-Fi network: packet lost ratio threshold 5%, packet delay time threshold 50ms, and wireless signal strength threshold -70dbm; VCC mobile device detects available Wi-Fi network: packet lost ratio of Wi-Fi network connection less than 5%, packet delay time less than 50ms, and wireless signal strength bigger than -70dbm; the VCC mobile device finds that hand-in requirements are satisfied and system will choose this Wi-Fi network to hand-in.

[055] The VAS set a anchoring processing information for the session SI as following: cellular CS network (VAS to start handover procedure, normal PSI=APPSI1, on-hold PSI=APPSI2, on-hold active PSI=APPSI3, on-hold release PSI=APPSI4, conference PSI=APPSI5, conference release PSI= APPSI6); Wi-Fi IP network (client to start handover procedure, normal PSI=APPSI7, on-hold PSI=APPSI8, on-hold active PSI=APPSI9, on-hold release PSI=APPSI10, conference PSI=APPSI11, conference release PSI= APPSI12); LTE network(normal PSI=APPSI13, VAS to start handover procedure, on-hold PSI=APPSI14, on- hold active PSI=APPSI15, on-hold release PSI=APPSI16, VAS to start handover procedure, conference PSI=APPSI17, conference release PSI= APPSI18, client to start handover procedure).

[056] For the Cellular CS network APPSI set {APPSI1, APPSI2, APPSI3, APPSI4, APPSI5, APPSI6}, APPSI1, APPSI2, APPSI3, APPSI4, APPSI5, and APPSI6 are different from each other in this set. This rule applies to each APPSI set for every network domain. For example, for Wi- Fi IP network APPSI set {APPSI7, APPSI8, APPSI9, APPSI10, APPSI11, APPSI12}, APPSI7, APPSI8, APPSI9, APPSI10, APPSI11, and APPSI12 are different from each other in this set. The above rule is an easy rule. If the VAS and VCC mobile device both know the status of the call session, there is another rule to save the number of APPSI used: VAS can assign different APPSI for different action for each state: for example, for the Cellular CS network APPSI set {APPSI1, APPSI2, APPSI3, APPSI4, APPSI5, APPSI6}, {APPSI2, APPSI3, APPSI4} are for on- hold state and so APPSI2, APPSI3, and APPSI4 are different from each other; also {APPSI5, APPSI6} are for conference state, these two APPSIs are different from each other. This APPSI assigning rule applies to all call sessions.

[057] For the call session SI anchoring processing information, "cellular CS network (VAS to start handover procedure, normal PSI=APPSI1, on-hold PSI=APPSI2, on-hold active PSI=APPSI3, on-hold release PSI=APPSI4, conference PSI=APPSI5, conference release PSI= APPSI6)" means: when this call session in normal state (status: active) and needs to handover this call to a cellular CS network, VAS needs to use APPSI1 to start handover request (set calling party as APPSI1); when this call session in on-hold state (status: on-hold) and needs to handover this call session to a cellular CS network, VAS needs to use APPSI2 to start handover request (set calling party as APPSI2); when this call session in on-hold state (status: on-hold) and needs to change this call session to active status in a cellular CS network, VAS needs to use APPSI3 to start handover request (set calling party as APPSI3); when this call session in on-hold state (status: on-hold) and needs to release this call in a cellular CS network, VAS needs to use APPSI4 to start handover request (set calling party as APPSI4); when this call session in conference state (status: conference) and needs to handover this to a cellular CS network, VAS needs to use APPSI5 to start handover request (set calling party as APPSI5); when this call session in conference state (status: conference) and needs to release this call session in a cellular CS network, VAS needs to use APPSI6 to start handover request (set calling party as APPSI 6). In cellular CS network, VAS is responsible to start handover procedure for all scenarios.

[058] For the call session SI anchoring processing information, "Wi-Fi IP network (client to start handover procedure, normal PSI=APPSI7, on-hold PSI=APPSI8, on-hold active PSI=APPSI9, on-hold release PSI=APPSI10, conference PSI=APPSI11, conference release PSI= APPSI12)" means: when this call session in normal state (status: active) and needs to handover this call to a Wi-Fi IP network, VCC mobile device needs to use APPSI7 to start handover request (set called party as APPSI7); when this call session in on-hold state (status: on-hold) and needs to handover this call session to a Wi-Fi IP network, VCC mobile device needs to use APPSI8 to start handover request (set called party as APPSI8); when this call session in on-hold state (status: on-hold) and needs to change this call session to active status in a Wi-Fi IP network, VCC mobile device needs to use APPSI9 to start handover request (set called party as APPSI9); when this call session in on-hold state (status: on-hold) and needs to release this call in a Wi-Fi IP network, VCC mobile device needs to use APPSI10 to start handover request (set called party as APPSI10); when this call session in conference state (status: conference) and needs to handover this to a Wi-Fi IP network, VCC mobile device needs to use APPSI11 to start handover request (set called party as APPSI11); when this call session in conference state (status: conference) and needs to release this call session in a Wi-Fi IP network, VCC mobile device needs to use APPSI12 to start handover request (set called party as APPSI12). [059] For the call session SI anchoring processing information, "LTE network(normal PSI=APPSI13,VAS to start handover procedure, on-hold PSI=APPSI14, on-hold active PSI=APPSI15, on-hold release PSI=APPSI16, VAS to start handover procedure, conference PSI=APPSI17, conference release PSI= APPSI18, client to start handover procedure)" means: when this call session in normal state (status: active) and needs to handover this call to a LTE network, VAS needs to use APPSI13 to start handover request (set calling party as APPSI13); when this call session in on-hold state (status: on-hold) and needs to handover this call session to a LTE network, VAS needs to use APPSI14 to start handover request (set calling party as APPSI14); when this call session in on-hold state (status: on-hold) and needs to change this call session to active status in a LTE network, VAS needs to use APPSI15 to start handover request (set calling party as APPSI15); when this call session in on-hold state (status: on-hold) and needs to release this call in a LTE network, VAS needs to use APPSI16 to start handover request (set calling party as APPSI16); when this call session in conference state (status: conference) and needs to handover this to a LTE network, the VCC mobile device needs to use APPSI17 to start handover request (set called party as APPSI17); when this call session in conference state (status: conference) and needs to release this call session in a LTE network, the VCC mobile device needs to use APPSI18 to start handover request (set called party as APPSI18). In LTE network, VAS is responsible to start handover procedure when call session is in normal state or in on-hold state; the VCC mobile device is responsible to start handover procedure when call session is in conference state. VAS can set anchoring information in different way to let VAS or VCC mobile device to control handover procedure when the call session is in status and different action required.

[060] For release action for all status (normal active, on-hold, conference and call waiting), both VAS and VCC mobile device can start handover procedure because of call session's nature (VCC mobile device can release a call session or VAS need to release a call session when peer side release the call session). If any action is operated by the VCC mobile device user, the VCC mobile device has the right to start handover procedure by this nature: for example, the VCC mobile device user can put call session on-hold and retrieve it back and so VCC mobile device can start handover procedure when call session is on on-hold state even it is not set in the anchoring information. This apply to all possible call session actions.

[061] The VAS set a handover control information as following:

[062] Wi-Fi IP network, handover trigger = VAS, handover in trigger rule= rule 1, handover out trigger rule= rule 2; cellular CS network, handover trigger = client, handover out trigger rule= rule 3; LTE network, handover trigger = VAS, handover in trigger rule= rule 4, handover out trigger rule= rule 5; active call session handover first.

[063] For the handover control information, "Wi-Fi IP network, handover trigger control = VAS" means that for Wi-Fi IP network, VAS is responsible to trigger handover procedure; "cellular CS network, handover trigger = client" means that for cellular CS network, VCC mobile device is responsible to trigger handover procedure; "LTE network, handover trigger = VAS" means that for LTE network, VAS is responsible to trigger handover procedure; "active call session handover first" means that when starting handover procedure, the call session in active state is the first one to be switched to the new network: this item can be set as "on-hold call session handover first", which means that the call session in on-hold state has higher priority to be switched to the new network.

[064] The VAS set a trigger rule information (part of handover control information) as following:

[065] rule 1 (packet lost ratio threshold 5%, packet delay time threshold 50ms, and wireless signal strength threshold -70dbm); rule 2(packet lost ratio threshold 10%, packet delay time threshold 100ms, and wireless signal strength threshold -90dbm); rule3 (wireless signal strength threshold -90dbm);rule 4(packet lost ratio threshold 5%, packet delay time threshold 50ms, and wireless signal strength threshold -80dbm); rule5(packet lost ratio threshold 10%, packet delay time threshold 100ms, and wireless signal strength threshold -90dbm);

[066] The handover control information (including trigger rule information) is set for the same VCC mobile device. All call sessions from/ to the same VCC mobile device uses same handover control information (including trigger rule information).

[067] At stage (2), the VAS sends the call session information and its VCC service related information to the APS 160. At stage (3), the VAS 150 sends the call to the peer party C. At stage (4), the VAS 150 sends connection request confirm message back to the VCC mobile device through IP network; at stage (4), the VAS also sends the call session information, the VCC service information, handover control information, and anchoring processing information to the VCC mobile device through the IP network. In this diagram, all VCC service related information (including call session information, the VCC service information, handover control information, and anchoring processing information) are sent at stage (4); when available, all VCC service related information can be sent at any time after the call session SI request received. Whenever receiving the VCC service related information for the call session CI from the VAS, the VCC mobile device saves them with the call session CI.

[068] At stage (5), the peer party C confirms the call request. The VAS 150 forwards the connection confirm message to the VCC mobile device through IP network at stage (6). The call session is established successfully through IP network between the VAS 150 and the VCC mobile device.

[069] At stage (7), the VAS 150 receives a call request from party D to the VCC mobile device A. the VAS 150 sets this call session as session S2, selects a new set of APPSIs for this call session S2, for example, the set {APPSIal, APPSIa2, APPSIa3, APPSIa24}; there is a rule for the VAS 150 to select the new APPSI set: because {APPSI1, APPSI2, APPSI3, APPSI18} are already selected for call session SI for the same VCC mobile device (VCC UE ID), the VAS 150 can't select any of {APPSI1, APPSI2, APPSI3, APPSI18} for the call session S2: there is no common APPSI between set {APPSI1, APPSI2, APPSI3, APPSI18} and {APPSIal, APPSIa2, APPSIa3, APPSIa24}. This rule applies to all call sessions related to the same VCC mobile device (the calling party or called party of the call session is the VCC mobile device's ID).

[070] Same rule that applies for assigning {APPSI1, APPSI2, APPSI3, APPSI18} for call session SI internally (paragraph [054] ) applies {APPSIal, APPSIa2, APPSIa3, APPSIa24} for call session S2.

[071] The VAS 150 sets anchoring information {APPSIal, APPSIa2, APPSIa3, APPSIa24} to the session S2 according the VCC service related information where APPSIal is set for CS network normal APPSI.

[072] The status of the call session S2 is in call waiting state. The call session information of S2 are saved like following:

[073] The calling party (peer party D), the called party (User A VCC UE ID), call session handover allowed indicator (all allowed), time stamp for the call session created, network used for current call session (Wi-Fi IP), call status (call waiting), a call session anchoring processing instance.

[074] The VAS set the anchoring processing information for the session S2 as following: cellular CS network (client to start handover procedure, normal PSI=APPSIal, on-hold PSI=APPSIa2, on-hold active PSI=APPSIa3, on-hold release PSI=APPSIa4, conference PSI=APPSIa5, conference release PSI= APPSIa6, call waiting PSI=APPSIa7, call waiting release PSI= APPSIa8); Wi-Fi IP network (client to start handover procedure, normal PSI=APPSIa9, on-hold PSI=APPSIal0, on-hold active PSI=APPSIall, on-hold release PSI=APPSIal2, conference PSI=APPSIal3, conference release PSI= APPSIal4, call waiting PSI=APPSIal5, call waiting release PSI= APPSIal 6); LTE network(VAS to start handover procedure, normal PSI=APPSIal7, on-hold PSI=APPSIal8, on-hold active PSI=APPSIal9, on-hold release PSI=APPSIa20, conference PSI=APPSIa21, conference release PSI= APPSIa22, call waiting PSI=APPSIa23, call waiting release PSI= APPSIa24).

[075] In above anchoring processing information, because this call session now is in call waiting state, two new APPSIs are added for each network domain by the VAS 150: call waiting handover PSI and call waiting release APPSI.

[076] The VAS use the call session Si's handover control information for the session S2.

[077] At stage (8), the VAS sends the call session S2, its VCC service anchoring information, and VCC UE ID to the Anchoring Processing Server (APS) database.

[078] At stage (9), the VAS 150 sends call session request (from D) to the VCC mobile device. At stage (9), the VAS 150 also sends the all session S2 VCC service related information (call session S2 information, the VCC service information, its VCC service anchoring information) to the VCC mobile device through the IP network. When receiving call session request and its VCC service related information from the VAS, the VCC mobile device set this call session as C2 and saves all information locally.

[079] At stage (10), the VCC mobile device set the call session CI on-hold. At stage (11), the VCC mobile device accepts call request C2 and confirms the connection through the IP N/W. At stage (12), the VAS confirms the connection to the peer party D when receiving confirm message from the VCC mobile device.

[080] The VCC mobile device and the VAS have more call session C3 (from the VCC mobile device) and S4 (to the VCC mobile device) established; for simplification, at stage (13), all call sessions are established one by one and step by step; all VCC service related information are exchanged between the VCC mobile device and the VAS 150. The set of {APPSlbl, APPSIb2, APPSIb3, APPSIb24} is assigned to the call session S3 at the VAS 150; the set of {APPSIcl, APPSIc2, APPSIc3, APPSIc24} is assigned to the call session S4 at the VAS 150. There are four sets of APPSIs assigned to four call sessions:

[081] {APPSI1, APPSI2, APPSI3, APPSI18} for SI; {APPSlal, APPSIa2, APPSIa3, APPSIa24} for S2; {APPSlbl, APPSIb2, APPSIb3, APPSIb24} for S3; {APPSIcl, APPSIc2, APPSIc3, APPSIc24} for S4.

[082] There is no common APPSI between any two sets out of four sets. When any APPSI is used in handover call session request, for the same VCC UE ID, this APPSI can only be found in one call session's anchoring information (APPSI and VCC mobile device VCC UE ID) in both client side (VCC mobile device) and network side (VAS 150 and APS 160).

[083] The VCC mobile device and the VAS save all VCC service related information. Till now, there are 4 sets of APPSIs assigned to 4 call sessions SI, S2, S3, and S4 for the same VCC mobile device with the VCC UE ID. When an APPSI is already assigned to a call session for a VCC mobile device with VCC UE ID, VAS can't assign the APPSI can't to any other call session for the same VCC mobile device with the same VCC UE ID; VAS can assign this APPSI to other call session for a VCC mobile device with a different VCC UE ID.

[084] According to the information exchanged, when handover triggered (at this point, call session S2(C2 for the VCC mobile device) is in active state ("active call session handover first" is set in anchoring information) and all other call sessions are in on-hold state), the VCC mobile device initiates to handover the call session C2 from current IP network to the cellular CS network. The APPSlal is selected because the call session C2 is active and APPSlal is assigned for cellular CS network normal handover PSI; at stage (14), the VCC mobile device (client to start handover procedure is set for cellular CS network in call session anchoring information) sends a call request with APPSlal as called party of the call request and the VCC UE ID as the calling party through the cellular CS network. This call request is a handover request call because APPSlal is used. This call request is forwarded to the VAS 150 at stage (15). The VAS queries the APS 160 at stage (16) and it gets the call session S2 by using APPSIal and VCC mobile device VCC UE ID. The VAS does domain transfer for S2 and sends confirm message back for the call request through the cellular CS network at stage (17). At stage (18), the VCC mobile device receives the handover call request confirm message through the cellular CS network. The VCC mobile device does the call session C2 handover after sending the handover call request message. The VAS also updates the call session S2 VCC service related information at stage (19). At stage (20), the call session C2 (S2 for VAS) connection in the IP network is released and the call session C2 is switched to the cellular CS network successfully at this point.

[085] At the network side, the VAS (only VAS is set to start handover procedure for cellular network in SI call session anchoring information) starts to handover the call session SI from the IP network to the cellular network. The call session SI is on-hold and the APPSI2 was assigned to work as on-hold handover PSI for cellular CS network. At stage (21), the VAS sends a call request to the VCC mobile device with APPSI2 as the calling party of the call request through the cellular CS network and the VAS also updates the VCC service related information at stage (22). At stage (23), the call request is forwarded to the VCC mobile device and the VCC mobile device finds that this call request is for the call session CI handover according to the VCC service related information saved locally; the VCC mobile device does domain transfer for call session CI (APPSI2 matched call session) to the cellular CS network. After finishing domain transfer, at stage (24), the VCC mobile device sends the confirm message back for the handover call request and at stage (25), this call request confirm message is forwarded to the VAS. At stage (26), the IP network connection of the call session SI (CI for the VCC mobile device) is released.

[086] Similar to SI domain transfer, from stage (27) to stage (28) for simplification, the call session C3 (on-hold session, S3 for the VAS side), C4(on-hold session, S4 for the VAS side) are transferred from the IP network to the cellular CS network; the VCC mobile device and the VAS both update their local VCC service related information.

[087] At stage (29), the VAS receives the call session S3 release message from the peer party and the VAS finds the S3 call session VCC service related information from APS 160. At stage (30), the VAS sends a call session request to the VCC mobile device with APPSIb4 (where the APPSIb4 is assigned to the call session S3 as on-hold call session release APPSI for the cellular CS network) as calling party through the cellular CS network. At stage (31), the VCC mobile device gets the call request and at stage (33), it releases the on-hold call session C3. At stage (32), the VAS cleans the S3 call session VCC service related information.

[088] When the VCC mobile device user puts the call session C2 on-hold and puts the call session CI to active, the VCC mobile device sends the C2 call on hold message to the cellular CS network at stage (34) first and then the VAS sends CI handover call request with APPSI3 as the called party (where the APPSI3 is assigned to the call session CI for on-hold active APPSI for the cellular CS network) and the VCC UE ID as the calling party of the call request through the cellular CS network. At the stage (36), the VAS 150 receives the call request. After querying the APS 160 for the VCC service related information at stage (37), the VAS gets call session SI and its VCC service data. The VAS will update the SI from on-hold to active and also connect the session SI to the VCC mobile device (this is also apply that all other call sessions are in on-hold state because only one call session is in active state at one time). At stage (38), the VAS sends call request confirm message back to the VCC mobile device through the cellular network and the call session CI is active at this point.

[089] FIG. 3 is a basic call flow diagram illustrating how and when VCC service related information are saved at both a VCC mobile device (e.g., VCC mobile device 155) and network VAS 150 when the call session are established in cellular CS network first. This diagram also illustrates how and when VCC mobile device and VAS 150 exchange call session information and their VCC service related information when the IP network available between the VCC mobile device and the VAS 150. In this diagram, a VCC mobile device and a VAS both start handover request for different call session according to the exchanged VCC Service related information.

[090] At stage (1), a VCC mobile device (e.g., a VCC mobile device 155) initiates a call session CI (where the called party is the peer party C) through the cellular CS network. At the stage (2), the cellular CS network and the VAS/SCP exchange information to make sure that the call session from the VCC mobile device is routed to the VAS 150 for anchoring. At stage (3), the VCC mobile device receives call setup ACK message from the cellular CS network and it saves the call session information for the call session CI locally. The call session in VCC mobile devices includes:

[091] the calling party, the called party (C), call session VCC service (allowed), time stamp of the call session created, network used (cellular CS network), call status (active).

[092] At stage (4), the VCC application server (VAS) receives the call request and sets this call session as SI; the VAS sets timestamp for session SI and assigns set of APPSI {APPSI1, APPSI2, APPSI3, ...} to the call session SI; then the VAS 150 sets the VCC service related information for the call session SI. At stage (5), the VAS 150 sends the call session SI and all its VCC service data to the APS 160.

[093] From stage (6) to stage (8), the call session between the VCC mobile device and the peer party C is established successfully.

[094] At stage (9), the VCC mobile device user put the call session CI on-hold and starts a new call session request to the peer party D through the cellular network; the VCC mobile device sets this call session as C2 and saves the C2 call session information and the VCC service related information locally.

[095] At stage (10), the cellular CS network and VAS/SCP exchange information and the call request is routed to the VAS 150. Upon receiving the call request, the VAS 150 set this call as S2 and the VAS 150 assigns APPSIs (APPSIal, APPSIa2, APPSIa3, ...) to the call session S2; The VAS sets the VCC service related information for the call session S2, and at stage (11), the VAS 150 sends the call session S2 and all its VCC service related information to the APS 160. From stage (12) to stage (14), the call session between the VCC mobile device and the peer party D is established successfully.

[096] Similar to the above steps, at stage (15) for simplification, more call sessions (C3, C4) are established for the VCC mobile device through cellular network and the VAS saves all call sessions VCC service related information.

[097] At stage (16), an IP network is available between the VCC mobile device and the VAS 150 and the VCC mobile device sets an IP connection with the VAS 150. After IP network connection available, at stage (17), the VCC mobile device sends all call sessions information (CI, C2, C3, C4) and the VCC mobile device VCC service capability information to the VAS 150 through the IP network. The information about the call session includes the following but not limited:

[098] the calling party (VCC UE ID), the called party (C), call session VCC service (allowed), time stamp of the call session created, network used (cellular CS network), call status (active); the calling party(VCC UE ID), the called party (D), call session VCC service (allowed), time stamp of the call session created, network used (cellular CS network), call status (on-hold); the calling party(E), the called party (VCC UE ID), call session VCC service (allowed), time stamp of the call session created, network used (cellular CS network), call status (on-hold); calling party(F), the called party (VCC UE ID), call session VCC service (allowed), time stamp of the call session created, network used (cellular CS network), call status (on-hold).

[099] The VCC service capability information of the VCC mobile device includes the following information:

[100] Handover control (yes); handover trigger (packet lost, packet delay, wireless signal strength); network type supported (Wi-Fi, CDMA, 3G, LTE). [101] Up receiving the message(s), the VAS 150 queries the APS 160 and gets all call sessions and their VCC service related information; the VAS compares call session information for CI, C2, C3, and C4 received with local call session information for SI, S2, S3 and S4; VAS use timestamp of each call session, timestamp sequence for each call session(such as who is first, second, second and forth), called party of call session, caller party of call session to find matched call session. At the client side, the VCC mobile device uses same method.

[102] The VAS 150 updates call sessions and their VCC service related information at stage (18). At stage (19), the VAS sends all call sessions (the called party or calling party is the VCC mobile device 155) and their VCC service related information to the VCC mobile device through the IP network. The following information are include but not limited:

[103] Call session: the calling party (VCC UE ID), the called party (C), call session VCC service (allowed), time stamp of the call session created, network used (cellular CS network), call status (active); Anchoring information: Wi-Fi IP network (VAS to start handover procedure, normal PSI=APPSI1, on-hold PSI=APPSI2, on-hold active PSI=APPSI3, on-hold release PSI=APPSI4, conference PSI=APPSI5, conference release PSI= APPSI6); cellular CS network (client to start handover procedure, normal PSI=APPSI7, on-hold PSI=APPSI8, on- hold active PSI=APPSI9, on-hold release PSI=APPSI10, conference PSI=APPSI11, conference release PSI= APPSI12); LTE network(normal PSI=APPSI13, VAS to start handover procedure, on-hold PSI=APPSI14, on-hold active PSI=APPSI15, on-hold release PSI=APPSI16, VAS to start handover procedure, conference PSI=APPSI17, conference release PSI= APPSI18, client to start handover procedure).

[104] Call session: the calling party(VCC UE ID), the called party (D), call session VCC service (allowed), time stamp of the call session created, network used (cellular CS network), call status (on-hold); Anchoring information: Wi-Fi IP network (client to start handover procedure, normal PSI=APPSIal, on-hold PSI=APPSIa2, on-hold active PSI=APPSIa3, on-hold release PSI=APPSIa4, conference PSI=APPSIa5, conference release PSI= APPSIa6); cellular CS network (client to start handover procedure, normal PSI=APPSIa9, on-hold PSI=APPSIal0, on-hold active PSI=APPSIall, on-hold release PSI=APPSIal2, conference PSI=APPSIal3, conference release PSI= APPSIal4); LTE network(VAS to start handover procedure, normal PSI=APPSIal7, on-hold PSI=APPSIal8, on-hold active PSI=APPSIal9, on-hold release PSI=APPSIa20, conference PSI=APPSIa21, conference release PSI= APPSIa22).

[105] Call session: the calling party(E), the called party (VCC UE ID), call session VCC service (allowed), time stamp of the call session created, network used (cellular CS network), call status (on-hold); Anchoring information: Wi-Fi IP network (VAS to start handover procedure, normal PSI=APPSIbl, on-hold PSI=APPSIb2, on-hold active PSI=APPSIb3, on- hold release PSI=APPSIb4, conference PSI=APPSIb5, conference release PSI= APPSIb6); cellular CS network (client to start handover procedure, normal PSI=APPSIb7, on-hold PSI=APPSIb8, on-hold active PSI=APPSIb9, on-hold release PSI=APPSIbl0, conference PSI=APPSIbll, conference release PSI= APPSIbl2); LTE network(normal PSI=APPSIbl3, VAS to start handover procedure, on-hold PSI=APPSIbl4, on-hold active PSI=APPSIbl5, on-hold release PSI=APPSIbl6, VAS to start handover procedure, conference PSI=APPSIbl7, conference release PSI= APPSIbl8, client to start handover procedure).

[106] calling party(F), the called party (VCC UE ID), call session VCC service (allowed), time stamp of the call session created, network used (cellular CS network), call status (on- hold) ;Anchoring information: Wi-Fi IP network (VAS to start handover procedure, normal PSI=APPSIcl, on-hold PSI=APPSIc2, on-hold active PSI=APPSIc3, on-hold release PSI=APPSIc4, conference PSI=APPSIc5, conference release PSI= APPSIc6); cellular CS network (client to start handover procedure, normal PSI=APPSIc7, on-hold PSI=APPSIc8, on- hold active PSI=APPSIc9, on-hold release PSI=APPSIcl0, conference PSI=APPSIcll, conference release PSI= APPSIcl2); LTE network(normal PSI=APPSIcl3, VAS to start handover procedure, on-hold PSI=APPSIcl4, on-hold active PSI=APPSIcl5, on-hold release PSI=APPSIcl6, VAS to start handover procedure, conference PSI=APPSIcl7, conference release PSI= APPSIcl8, client to start handover procedure).

[107] The "Anchoring information" section followed "Call session" section provides anchoring processing information for the above "Call session".

[108] At the VCC mobile device side, at stage (19), upon receiving the call sessions and all VCC service related information, the VCC mobile device analyses the information received and saves them locally.

[109] The VAS 150 starts session handover procedure after getting handover triggering. At stage (20), the VAS queries the VCC service related information for the VCC mobile devices from the APS 160. After analyzing the data, the VAS gets the APPSI1 that is assigned as normal handover PSI for the session SI in IP network and at stage (21), the VAS 150 sends handover call request where the calling party is set as APPSI1 to the VCC mobile device through the IP network. The VAS 150 also sends the session SI VCC service related information to the VCC mobile device through the IP network. The VCC service related information includes the handover control information, anchoring processing information, and the VAS service capability information. At the VCC mobile device side, upon receiving the handover request call from the VAS 150 through the IP network, the VCC mobile device gets the local session CI, and the VCC mobile device saves received information and transfers the call session CI from the cellular CS network to the IP network. After finishing domain transfer, at stage (22), the VCC mobile device sends handover call request confirm message back to the VAS 150 through the IP network; the VAS 150 updates the anchoring information at stage (23). At stage (24), the VCC mobile device and the VAS 150 work together to release the call session (CI for the VCC mobile device and SI for the VAS 150) connection in the cellular CS network.

[110] The VCC mobile device is triggered to start the on-hold call session C2 domain handover procedure. After getting C2 for on-hold PSI APPSIa2 in IP network, the VCC mobile device sends C2 handover call request (the called party is set as APPSIa2, the calling party is set as the VCC mobile device VCC UE ID) to the VAS 150 through the IP network at stage (26); upon receiving handover request call, the VAS 150 queries the APS at stage (27) and gets session S2 and its VCC service data according to the APPSIa2 and VCC UE ID. The VAS 150 transfers the S2 call session from the cellular CS network to the IP network and at stage (28), the VAS 150 sends the handover call request confirm message to the VCC mobile device through the IP network. At stage (29), the VAS 150 updates S2 VCC service data.

[Ill] At stage (30), the VCC mobile device and the VAS 150 work together to release the call session (C2 for the VCC mobile device and S2 for the VAS 150) connection in the cellular CS network. At stage (31), VAS and VCC mobile device switch rest of call sessions one by one according to the call session's anchoring information.

[112] FIG. 4 is a basic call flow diagram illustrating how and when session and handover information exchanging between a VCC mobile device (e.g., VCC mobile device 155) and a VAS 150 when SIP is used for call session trough IP network. This diagram also illustrates how and when VCC mobile device and VAS store and use the handover information to handover multiple sessions from one IP network to another IP network. In this diagram, a VAS 150 makes decision and initiates handover request.

[113] At stage (1), a VCC mobile device (e.g., VCC mobile device 155) sends a SIP INVITE C user message through an IP network (N/W) 1 (e.g., a 4G network) to a VAS 150. Inside this INVITE message, the VAS add a client VCC service capability header as following for example:

[114] Client- VCC-Capability-information: network support (Wi-Fi IP network, GSM, 3G Network, 4G network), handover trigger rule (packet lost ratio, packet delay, wireless signal strength), session type (voice, video); [115] The VAS creates a timestamp for this call session, assigns APPSIs (APPSI1, APPSI2,...., APPSI10) for this call session, and set an anchoring information for this session and the VAS. At stage (2), the VAS saves the call session information and the anchoring information to the APS 160. At stage (3), the VAS sends the call request to the peer party C and at stage (4), the VAS gets 180 message and then 200 OK message from peer party C. At stage (5), after getting 180 message from the party C, the VAS sends 180 message to the VCC mobile device through IP network 1; the VAS adds an anchoring processing header inside this 180 message. The anchoring processing header includes anchoring information set for this call session; it look like the following for example:

[116] Call-session-AP-information: Wi-Fi IP network(VAS, normal PSI=APPSI1, on-hold (client, handover PSI=APPSI2, , release PSI=APPSI3)), cellular CS network (VAS, normal handover PSI=APPSI4, on-hold (handover PSI=APPSI5, release PSI=APPSI6), call-waiting (handover PSI=APPSI7, release PSI=APPSI8)), 4G network (VAS, normal PSI=APPSI9, on- hold handover PSI=APPSI10);

[117] "Wi-Fi IP network(VAS, normal PSI=APPSI1, on-hold (client, handover PSI=APPSI2, , release PSI=APPSI3))" in the call session AP header means: for Wi-Fi network, VAS is responsible to start handover procedure by default if other entity is not defined; if this call session in normal active state, handover PSI for Wi-Fi network is APPSI1; if call session is in on-hold state, VCC mobile device is responsible to start the handover procedure and on hold normal handover PSI is APPSI2.

[118] The VAS set a handover control information as following:

[119] Session-handover-control-information: Wi-Fi (hand-in = rule 1, hand-out = rule 2); cellular CS (hand-out = rule 3); LTE network(hand-in= rule 4, hand-out= rule 5); rule 1 (packet lost ratio: 5%, packet delay: 50ms, and signal strength: -70dbm); rule 2(packet lost ratio: 10%, packet delay: 100ms, and signal strength: -90dbm); rule3(signal strength: -90dbm);rule 4(packet lost ratio: 5%, packet delay: 50ms, and signal strength: -80dbm); rule5(packet lost ratio: 10%, packet delay: 100ms, and signal strength: -90dbm);

[120] After getting 200 OK message from the party C, the VAS sends 200 OK message to the VCC mobile device through IP network 1 at stage (6).

[121] After getting VCC service data from 180 message, the VCC mobile device save the anchoring information with the call session CI.

[122] At stage (7), the VAS 150 receives a call request (call session S2) from user D to the VCC mobile device; after checking APPSI availability, the VAS assigns APPSIal, APPSIa2, APPSIa3,... to this the anchoring information and at stage (8), the VAS sends call session S2 information and its VCC service data to the APS 160. At stage (9), the VAS sends an INVITE message to the VCC mobile device through the IP network (N/W) 1; the VAS adds a anchoring processing header inside this INVITE message. The anchoring processing header includes anchoring information for this call session; it look like the following for example:

[123] Call-session-AP-information: Wi-Fi IP network(VAS, normal handover PSI=APPSIal, on-hold (handover PSI=APPSIa2, release PSI=APPSIa3)), cellular CS network (VAS, normal handover PSI=APPSIa4, on-hold (handover PSI=APPSIa5, release PSI=APPSIa6), call-waiting (handover PSI=APPSIa7, release PSI=APPSIa8)), 4G network (VAS, normal handover PSI=APPSIa9, on-hold handover PSI=APPSIal0);

[124] At stage (9), the VCC mobile device (e.g., VCC mobile device 155) receives the call session C2 (S2 for the VAS side) and saves C2 session information and its VCC service data locally. From stage (10) to stage (12), the VCC mobile device puts the session CI on-hold, accepts the call C2; the session C2 is established through the IP N/W 1.

[125] At stage (13) for simplification, call session C4 and C3 are established between the VCC mobile device (e.g., VCC mobile device 155) and the VAS 150 160 through the IP network 1; the VAS and the VCC mobile device save call session information and VCC service data.

[126] At stage (14), The VAS and the VCC mobile device finds another IP network 2 (e.g., a Wi-Fi network) available for VCC call session service; the VAS is triggered to start handover procedure. At stage (15), the VAS queries call sessions and VCC service data for the VCC mobile device from the APS 160; the VAS start to handover active session S2 first and after checking session S2 anchoring information, the VAS gets APPSlal which is assigned to Wi-Fi IP network for normal handover PSI; at stage (16), the VAS sends a INVITE message where the calling party is set as APPSlal to the VCC mobile device (e.g., VCC mobile device 155) through the IP network (N/W) 2; the VAS transfers session S2 to the IP network (N/W) 2. At stage (17), the VAS updates session S2 VCC service data to the APS 160.

[127] After receiving the INVITE message at stage (16), the VCC mobile device gets the APPSlal and finds APPSlal maps call session C2 in the C2 session anchoring information; if the VCC mobile device detects that the Wi-Fi connection if not good for call session service, it can reject the call session handover request; if the VCC mobile device finds that everything of the Wi-Fi network is ok (packet lost ratio less than 5%, packet delay less than 50ms, and signal strength bigger than -70dbm), the VCC mobile device transfer C2 session to the IP network 2 and sends 200 OK message back to the VAS to confirm C2 domain transfer to IP network 2 successfully at stage (18).

[128] The VAS starts to transfer session SI to the IP network (N/W) 2; the VAS checks session SI anchoring information and selects APPSI2 which is on-hold handover PSI for Wi-Fi network; at stage (19), VAS sends a INVITE message to the VCC mobile device through the IP network (N/W) 2 where the calling party of the INVITE message is set as APPSI2; the VAS also updates the session SI VCC service data at the APS at stage (20). After receiving the INVITE message at stage (19), the VCC mobile device gets the APPSI2 and finds APPSI2 maps call session CI in the session CI anchoring information; the VCC mobile device transfer CI session to the IP network 2, keeps the session C2 as on-hold state, and sends 200 OK message back to the VAS to confirm C2 domain transfer to IP network 2 successfully at stage (21).

[129] For simplification, similar to steps for the session S2, from stage (22) to stage (23), call session C3 (session S3 for the VAS) and C4 (session S4 for the VAS) are transferred to the IP network 2 and anchoring information are updated. At stage (24), the connection of session CI in IP network 1, the connection of session C2 in IP network 1, the connection of session C3 in IP network 1, and the connection of session C4 in IP network 1 are released. All sessions are transferred to the IP network 2.

[130] FIG. 5 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.

[131] 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.

[132] 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. [133] 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 RJ11 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.

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

[135] 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.

[136] 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.

[137] 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.

[138] 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).

[139] 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 mobile communications 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.

[140] 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.

[141] 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.

[142] 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.

[143] 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

[144] 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.

[145] 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

Claims What is claimed is:

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

providing Voice/ Video Call Continuity (VCC) service for more than one concurrent call session(s) from/ to a VCC mobile device at a same time at a converged service platform;

selecting multiple Anchoring Processing Public Service Identities (APPSls) for a new concurrent call session request from/ to a VCC mobile device that an APPSI in selected APPPSIs is not selected for other concurrent call session(s) linked to the same VCC mobile device at the same time at a converged service platform;

mapping selected APPSls with a combination of a destination domain (where the concurrent call session can be transferred to), a call session status of the concurrent call session, and a processing action of the call session status at the converged service platform;

setting a anchoring information that includes the mapping information for the call session at the converged service platform;

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

sending information of concurrent call session(s) which are linked to a VCC mobile device and their anchoring information to the VCC mobile device through an IP network at the converged service platform;

receiving client concurrent call session(s) information from a VCC mobile device at the converged service platform;

comparing and matching client call session(s) information sent by a VCC mobile device with the local saved concurrent call session(s) linked to the VCC mobile device at the converged service platform;

receiving a call session handover request where an APPSI is the called party of the call session request from a VCC mobile device through a new domain and determining the call session from multiple concurrent call sessions for the same VCC mobile device by using APPSI and the VCC mobile device VCC User Entity Identity (VCC UE ID) from a APS server at the converged service platform;

identifying concurrent call session anchoring processing instance from a Anchoring Processing Server; and

switching the concurrent call session to the domain where the received call session handover request comes from at a 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 which that APPSI is assigned to.

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

4. The method of claim 3, wherein wireless data network domain comprises:

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

5. The method of claim 3, wherein the cellular network domain comprises:

a CDMA network, a GSM network, and an operator defined network.

6. The method of claim 5, wherein the operator defined network comprises: a network that operator can use it to provide call session service for a VCC mobile device

7. The method of claim 1, wherein a call session information comprises:

a VCC service User Entity Identification (VCC UE ID), a called party information, a calling party information, session service type (one of voice, video or multimedia), domain used, a call session status, a call session anchoring processing instance, and a timestamp of a call session.

8. The method of claim 7, wherein a call session status comprises one of an active state, an on- hold state, a conference state, a call-waiting state, or other state.

9. The method of claim 7, wherein the VCC service User Entity Identification (VCC UE ID) is: unique within a public network; representing a VCC service owner who signs the contract with the VCC service provider and uses the VCC mobile device to access a public network for VCC service.

10. The method of claim 7, timestamp of a concurrent call session at a converged service platform is a timestamp when the concurrent call session is created; a converged service platform uses same rule to create timestamp for every concurrent call session.

11. The method of claim 1, wherein a processing action of a call session status comprises one of a handover, a release, an add, or other action.

12. The method of claim 1, wherein an anchoring information for a concurrent call session comprises:

one or more groups of (a domain, a call session status, an Anchoring Processing Public Service Identity (APPSI), and a processing action of a call session status, handover controller (V AS or VCC mobile device: who starts handover procedure));

13. The method of claim 1, wherein a client call session information comprises:

a VCC service User Entity Identification (VCC UE ID), a called party information, a calling party information, session service type (one of a voice, a video, or a multimedia), domain used, call session status, and a timestamp of a client call session, a call session anchoring processing instance.

14. The method of claim 13, timestamp of a client call session at a VCC mobile device is a timestamp when the client call session is created; a VCC mobile device uses same rule to create timestamp for every call session.

15. The method of claim 1, wherein the Anchoring Processing Server (APS) is operable to:

save multiple concurrent call session(s) information and its anchoring information for a VCC mobile device;

update a concurrent call session information and its anchoring information for a VCC mobile device;

identify a concurrent call session through an APPSI for a VCC mobile device;

identify all call session(s) and its anchoring information for a VCC mobile device.

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

provide VCC service for multiple concurrent call session(s) related to a VCC mobile device; select multiple APPSIs for a concurrent call session linked to a VCC mobile device;

set concurrent call session information and it anchoring information for a call session;

send concurrent call session(s) information related to a VCC mobile device and its anchoring information to the VCC mobile device through IP network;

save concurrent call session information and it anchoring information in an APS;

receive client call session(s) information sent by a VCC mobile device;

compare client call session(s) information sent by a VCC mobile device with the local saved concurrent call session(s) information related to the VCC mobile device;

handle call session handover request from a VCC mobile device; identify a call session anchoring processing instance for a concurrent call session from a APS; send call session handover request to a VCC mobile device;

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

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

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

receive concurrent call session(s) information and its anchoring information sent by a VCC Application Server (VAS) through a IP connection;

compare concurrent call session(s) information sent by a VAS with the local saved call session(s);

start call session handover procedure and perform a call session handover for all concurrent call session(s);

identify a client call session through a APPSI;

identify a call session anchoring processing instance for a client call session;

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

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

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

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

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

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

selecting a new domain for a concurrent call session when getting handover procedure triggered for a Voice/Video call Continuity (VCC) mobile device at a converged service platform;

selecting an Anchoring Processing Public Service Identity (APPSI) in the anchoring information of the concurrent call session that the APPSI matches the combination of the new select domain, the current call session status of the call session, and the processing action of the call session status at the converged service platform;

identifying a call session anchoring processing instance through the APPSI and a the call session anchoring information for a VCC mobile device at the converged service platform; sending a call session handover request that the calling party of the call session handover request is set as the selected APPSI through the selected new domain to the VCC mobile device at the converged service platform; and

switching the concurrent call session to the selected new domain at the converged service platform;

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

providing Voice/ Video call Continuity (VCC) service for more than one concurrent call session(s) from/ to a VCC mobile device at a same time a VCC mobile device;

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

sending all client call session information to a VAS through an IP network at the VCC mobile device; receiving call session(s) information and its anchoring information sent by a Voice/ Video call Continuity (VCC) Application Server (VAS) through an IP network at a VCC mobile device; comparing and matching call session(s) information received with the client call session(s) information at the VCC mobile device;

saving concurrent call session(s) information and its anchoring information at the VCC mobile device;

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

identifying a concurrent call session which the APPSI associates with in the concurrent call session anchoring information at the VCC mobile device;

identifying a call session anchoring processing instance through the APPSI and a the call session anchoring information at the VCC mobile device;

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

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

selecting a new domain where concurrent call session can be transferred to when getting handover triggering at a VCC mobile device;

selecting an Anchoring Processing Public Service Identity (APPSI) in the anchoring information of the concurrent call session that the APPSI matches the combination of the new select domain, the current call session status of the call session, and the processing action of the call session status at the VCC mobile device;

identifying a call session anchoring processing instance through the call session information at the VCC mobile device;

sending a call session handover request that the calling party of the call session handover request is set as the selected APPSI through the selected new domain to a VAS at the VCC mobile device; and

switching the concurrent call session to the selected new domain at the VCC mobile device;

starting handover procedure for all concurrent call session(s) to the selected new domain one by one according to call session anchoring information at a converged service platform.

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

starting handover procedure for all concurrent call session(s) to the selected new domain one by one according to call session anchoring information at a VCC mobile device.

26. A system for concurrent call session(s) 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 concurrent call session; an Anchoring Processing Server operable to save, update, and identify the concurrent call session and its anchoring information for a VCC mobile device; a VAS also operable to send concurrent call session(s) and its the anchoring information 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;

A VAS and A VCC mobile device further work together to handover all concurrent call session(s) one by one to the new selected domain as defined in call session anchoring information.