WO2014116613A1 - Système et procédé de transfert de session d'appel vers un réseau ip ou un réseau à multiplexage par répartition dans le temps (tdm) cellulaire - Google Patents

Système et procédé de transfert de session d'appel vers un réseau ip ou un réseau à multiplexage par répartition dans le temps (tdm) cellulaire Download PDF

Info

Publication number
WO2014116613A1
WO2014116613A1 PCT/US2014/012407 US2014012407W WO2014116613A1 WO 2014116613 A1 WO2014116613 A1 WO 2014116613A1 US 2014012407 W US2014012407 W US 2014012407W WO 2014116613 A1 WO2014116613 A1 WO 2014116613A1
Authority
WO
WIPO (PCT)
Prior art keywords
vcc
call session
network
mobile device
handover
Prior art date
Application number
PCT/US2014/012407
Other languages
English (en)
Inventor
Xiao Hua Wang
Original Assignee
Wang xiao hua
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wang xiao hua filed Critical Wang xiao hua
Publication of WO2014116613A1 publication Critical patent/WO2014116613A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies

Definitions

  • This disclosure relates to the handover of a call session to a different domain, and more particularly to the handover to an IP network or to a cellular CS (circuit switch) network of a session between a VCC mobile device and a peer party device attached to a public network (e.g., IP network, PSTN, PLMN).
  • a public network e.g., IP network, PSTN, PLMN
  • broadband IP Internet protocol
  • 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.
  • broadband networks have also allowed users to make telephone calls (voice calls) over the broadband IP network using Voice over IP (VoIP) technology.
  • VoIP Voice over IP
  • Mobile/ cellular communications devices such as cellular handsets
  • VCC mobile devices can typically allow users to make telephone calls, send or receive electronic mail (e-mail), browse the World Wide Web, check appointments, and get directions, as well as perform many other functions.
  • Telephone calls are typically handled via cellular networks.
  • 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.
  • Voice call continuity represents an aim by the telecommunications industry to allow transitions between the IP domain and/ or the mobile domain.
  • VCC Voice/ Video call Continuity
  • a user's in-progress communication session which may be a voice call, can move from a mobile/ cellular network to a Wi-Fi IP network while the user is on the same mobile device.
  • This "handover" from cellular to IP should occur without any significant notice of interruption or disconnection by the user.
  • VCC should allow, for example, a user that initiates a cellular phone call on his or her mobile device out of the home to continue with the same call on the same mobile device (but on the IP network) when the user arrives in his/her home.
  • Video call continuity represents an aim to allow transitions between the different IP networks as well as between IP network and cellular CS network.
  • Design described in this disclosure provide for the handover of one session initiated by VCC mobile device or by the network service server: a VCC (Voice/ Video call continuity) service Application Server (VAS).
  • VCC Voice/ Video call continuity
  • VAS Voice Application Server
  • PSI Public Service Identity
  • PSI Public Service Identity
  • This disclosure provides for the handover of one session in which: only need to configure Anchoring Processing Public Service Identity (APPSI) at the network VAS side; the network VAS assigns APPSls to call session and sets VCC anchoring information for call session; VAS saves call session and anchoring information into APS (Anchoring Processing Server) database; the VAS and the VCC mobile device both exchange call session information, VCC service information, VCC service control information, and Anchoring information when IP connection available between a VCC mobile device and a VAS; based on the VCC service information exchanged, both VAS and VCC mobile device can use APPSI to initiate handover call sessions to the new selected network from current network.
  • APPSI Anchoring Processing Public Service Identity
  • VAS uses an APPSI to map a combination of a VCC mobile device with a VCC UE ID, a call session, a network domain that the call session can be handover to.
  • VAS sends the mappings to a VCC mobile device through IP network.
  • VCC mobile device and VAS both can use the mapping to control a call session handover.
  • FIG. 1 is a block diagram illustrating an example network environment operable to provide holdover of sessions in converged networks.
  • FIG. 2 is a flow chart illustrating a call session process that can be performed by a VAS (VCC Application Server) to facilitate the transfer of a session between a VCC mobile device and peer CPE connected to an IP network.
  • VAS VCC Application Server
  • the VCC mobile device sends the call session to the VAS and the VCC mobile device initiates session handover request.
  • FIG. 3 is a flow chart illustrating a call session process that can be performed by a VCC Application Server to facilitate the transfer of a session between a VCC mobile device and the VAS connected to an IP network.
  • the VAS is responsible to send call session to a VCC mobile device and the VAS initiates handover call request.
  • FIG. 4 is a flow chart illustrating an example process that can be performed by a VCC Application Server to facilitate the transfer of a session between a VCC mobile device and peer CPE connected to an IP network in case that CS is using GSM network and IP network, SIP is used as call session control.
  • VCC client in the VCC mobile device initiates handover request call.
  • FIG. 5 is a session flow diagram illustrating an example implementation of a handover process of a session between a VCC mobile device and peer CPE connected to either an IP network or PSTN.
  • network side VAS initiates handover request call.
  • the CS network is using GSM network and in IP network, SIP is used as call session control.
  • FIG. 6 is a session flow diagram illustrating another example implementation of a handover process of a session between a VCC mobile device and peer CPE connected to an IP network.
  • a VAS works as IMS application server to provide VCC service for VCC mobile device.
  • FIG. 7 is a block diagram illustrating an example of hardware that can be used to process the handover of a session.
  • systems and methods can operate to provide session handovers between domains in converged networks.
  • This disclosure describes various implementations of systems and methods of a VCC convergence network that can provide for the handover of a session, including a handover from the IP network to the mobile network of a session between a VCC enabled mobile device and a CPE device connected to an IP network, or a CPE device connected to a PSTN.
  • the components used in supporting this feature can include a VCC Application Server (VAS) operative to facilitate connections between a VCC mobile device and user devices connected to a cellular network, PSTN network, or a broadband IP network.
  • VAS VCC Application Server
  • FIG. 1 is a block diagram illustrating an example VCC converged services network environment 100 operable to provide handover of session between domains using anchoring processing handover public service identity (APPSI), wherein the sessions is between a mobile device and a CPE (e.g., a PSTN land line or cellular phone).
  • a VCC application server (VAS) 150 is operable to serve as a converged services platform that interconnects and routs communications to user devices, which can be connected to a mobile/cellular network 110, a broadband IP network 130, or a PSTN network 120.
  • the mobile/ cellular network 110 can include a number of VCC mobile devices 115a-b, 155 that communicate with cellular towers. Each of the cellular towers can communicate with VCC mobile devices 115a-b, 155 in a cell assigned to that cellular tower. VCC mobile devices 115a-b, 155 can communicate with the cellular towers via wireless links llOa-c.
  • the cellular network can be of any variety, including a Global System for Mobile communications (GSM), Universal Mobile telecommunications System (UMTS), Long Term Evolution (LTE), Code Division multiple access (CDMA) system, General Packet Radio Service (GPRS), Evolution- Data Optimized (EV-DO), Enhanced Data Rates for GSM Evolution (EDGE), 3GSM, Digital Enhanced Cordless Telecommunications (DECT), Digital AMPS (IS-136/TDMA), and Integrated Digital Enhanced Network (iDEN).
  • GSM Global System for Mobile communications
  • UMTS Universal Mobile telecommunications System
  • LTE Long Term Evolution
  • CDMA Code Division multiple access
  • GPRS General Packet Radio Service
  • EV-DO Evolution- Data Optimized
  • EDGE Enhanced Data Rates for GSM Evolution
  • 3GSM Digital Enhanced Cordless Telecommunications
  • DECT Digital Enhanced Cordless Telecommunications
  • AMPS IS-136/TDMA
  • iDEN Integrated Digital Enhanced Network
  • Typical multiplexing schemes used by these networks include frequency division (FDM), time division multiple access (TDM), code division multiplex (CDM), and space division multiplex (SDM), each of which can use appropriate access schemes (e.g., FDMA, TDMA, CDMA, and SDMA).
  • VCC mobile devices 115a-b, 155 can include cellphones, smartphones, portable computing devices, as well as other devices capable of carrying data and voice.
  • 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.
  • WLAN wireless local area network
  • 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.
  • the CPE 130a-b can have internal wireless routing functionality incorporated into it.
  • 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.
  • customer premises equipment 130a-b 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.
  • 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.
  • 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.
  • VCC communication device 155 which can also be referred to herein as VCC mobile device 155, can have client software that enables it to operate as a multi- modem handset that can communicate via both a cellular network and an IP network.
  • VCC mobile device 155 can communicate via cellular network 110, using wireless link 110a.
  • Wireless link 110a can include GSM, UMTS, or CDMA links.
  • VCC mobile device 155 can access IP network 130, by communicating with the wireless access point 140 via wireless data link 140a.
  • VCC mobile device 155 can access IP network 130, by communicating with the wireless access point 145 via wireless data link 145a which can include IP, GSM, LTE, Wi-MAX, Wi-Fi, or CDMA links.
  • 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.
  • 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).
  • 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.
  • SIP Session Initiation Protocol
  • URIs SIP universal resource identities
  • the VAS 150 can be operative to facilitate the establishment, tear-down, or modification of sessions between VCC mobile device 155 and other peer devices, including mobile devices 115a-b, CPE devices 130a-b connected to the IP network 130, and / or CPE devices 120a-b connected to the PSTN 120.
  • the VAS 150 can facilitate routing of communications with the VCC mobile device 155 through the use of a anchoring processing server and its database, which can periodically receive updates (e.g., a sip registration) from the VCC mobile device 155.
  • the VAS 150 assigns APPSIs to each call session and uses APPSIs to set anchoring information for call session; VAS 150 saves all VCC service data into Anchoring Processing Server (APS 160).
  • the Anchoring Processing Server (APS 160) stores all call sessions associated with the VCC mobile device 155; the Anchoring Processing Server (APS 160) also stores the call session anchoring processing instance, call session VCC anchoring information, and other VCC service data.
  • the Anchoring Processing Server can identifies the call session by using combination of different keys: VCC UE ID (VCC User Entity Identity), APPSI, calling party and called party, etc.
  • VCC UE ID VCC User Entity Identity
  • APPSI APPSI
  • calling party and called party etc.
  • a call session anchoring processing instance is the running software at a VAS to process the call session.
  • the VCC mobile device 155 can communicate through the IP network 130 with the VAS 150 via the wireless access point 140 and the wireless data link 140a.
  • the VCC mobile device can be operative to send and receive IP voice packets through the IP network 130.
  • the VCC mobile device 155 can also initiate a session through the cellular network 110 via communications link 110a.
  • VCC mobile device 155 can initiate a session via the cellular network 110 with a peer CPE device 130a-b connected to the IP network 130.
  • a call session anchoring processing instance is the running software at a VCC mobile device to process a call session.
  • the VCC mobile device 155 can send an active session request (e.g., a session setup request) through the cellular network 110 to the VAS 150.
  • the VAS 150 upon receiving the request, facilitates the session setup between the VCC mobile device 155 and the IP peer CPE 130a-b.
  • the VAS 150 assigns multiple APPSIs (Anchoring Processing PSI) with this call session and creates anchoring information for the call session from the VCC mobile device.
  • APPSIs Anchoring Processing PSI
  • the APPSIs are part of call session anchoring information.
  • VAS 150 stores call session and its anchoring information into an Anchoring Processing Server (APS 160). Multiple APPSIs are assigned to the call session for different network domain: an APPSI for Wi-Fi IP network handover request; an APPSI for LTE IP network handover request; an APPSI for cellular CS network handover request; an APPSI for other network, etc.
  • APS 160 Anchoring Processing Server
  • Multiple APPSIs are assigned to the call session for different network domain: an APPSI for Wi-Fi IP network handover request; an APPSI for LTE IP network handover request; an APPSI for cellular CS network handover request; an APPSI for other network, etc.
  • VAS 150 sends anchoring information to the VCC mobile device 155 through IP network and the VCC mobile device 155 store call session and anchoring information locally.
  • the VAS sets handover-in trigger and handover-out trigger for each network domain in anchoring information: e.g., for Wi-Fi IP network, the handover-in trigger is: packet delay is less than 50ms, Wi-Fi wireless signal strength is bigger than -60dbm and packet lost ration is less than 5%; for Wi-Fi IP network, the handover-out trigger is: Wi-Fi wireless signal strength is less than -90dbm or packet lost ration is bigger than 10% or packet delay is bigger than 80ms.
  • the VCC mobile device also sends its VCC service capability (network support list, handover triggers capability, handover control capability) to the VAS 150.
  • the VAS 150 stores VCC mobile device VCC service capability into the APS 160.
  • the VAS 150 can be operative to accept and handle the VCC mobile device 155 service request message from the IP network 130.
  • This linking of the home wireless local area network and a user's VCC mobile device 155 provides convenience when VCC mobile device 155 is within the range of the user's on-premises wireless LAN.
  • VCC mobile device 155 reports its call session information and its VCC service capability information to VAS 150 through the IP network 130.
  • the call session information includes VCC UE ID (VCC User Entity Identity, which represents the VCC mobile device identity), calling party, called party, domain used for the call session, and a call session anchoring processing instance.
  • VCC mobile device 155 can report call session information in SIP registration message but not limited on this way; VAS 150 receives service registration message and gets the call session information. VAS 150 queries APS 160 and APS 160 returns call session VCC service data including APPSIs back to VAS 150. Then VAS 150 returns 200 OK for service registration message with VCC service data back to VCC mobile device 155; the VCC service data includes the following information but not limited: VAS VCC service capability, VCC mobile device VCC service capability, anchoring information (including APPSIs to domain mapping), and call session information. The VCC mobile device 155 receives the VCC service data from VAS 150.
  • the VCC mobile device 155 In case of VCC mobile device starting handover procedure to switch a call session to an IP network, the VCC mobile device 155 initiates a handover request call by using the IP network APPSI as called party number. This handover call request will be sent to the VAS 150 through IP network 130; in case of VAS starting handover procedure to switch a call session to an IP network, the VAS initiates a handover request call (using IP network APPSI as calling party number) to the VCC mobile device 155. This handover call request will be sent to VCC mobile device 155 through IP network 130.
  • VAS 150 when VAS 150 receives request call from VCC mobile device 155 with called party is APPIS, VAS 150 treats this call as handover request to the domain which the call request comes from; when VAS 150 receives handover request call from VCC mobile device 155, VAS 150 queries APS 160 and gets call session anchoring information, and does media handovers for the call session. VAS 150 also assigns new APPSIs to the call session and updates the APS 160 about the new anchoring information.
  • VAS 150 when VAS 150 receives a call session request from/ to a VCC mobile device 155 in IP domain, VAS 150 assigns multiple APPSIs to the call session; If this call is not a handover call, VAS 150 sets anchoring information where multiple APPSls are assigned and associated with the call session; If this call is a handover call (an APPSI is the called party of the call request), VAS 150 gets the call session anchoring processing instance from the APS 160 according to the VCC UE ID and the APPSI and does handover for this call session; VAS 150 also updates the APS 160 with new anchoring information; VAS 150 sends VCC service data to the VCC mobile device 155 through the IP network.
  • the VCC mobile device 155 gets the APPSls for future to do handover call request.
  • the VAS 150 can use INVITE message to carry VCC service data but not limited.
  • the VAS 150 can use 180, 183 or 200 message to carry VCC service information but not limited. If any VCC service information changed, the VAS 150 updates the APS 160.
  • the VCC mobile device 155 can initiates a handover request in Cellular network 110 when IP network 130 is not good for the call session service.
  • the called party is the cellular CS network APPSI which is received through the IP network 130.
  • FIG. 2 is a basic call flow diagram illustrating how and when session and anchoring information exchanging between a VCC mobile device (e.g., VCC mobile device 155) and networks. This diagram also illustrates how and when VCC mobile device and VAS store and use the anchoring information. In this diagram, a VCC mobile device makes decision and initiates handover request.
  • VCC mobile device e.g., VCC mobile device 155
  • a VCC mobile device e.g., VCC mobile device 155 initiates a call in cellular CS network 110, and at stage (2), the Cellular CS network 110 and the VAS/SCP 150 will exchange information to make sure that the call session is routed to the VAS 150 for call session anchoring (ANSI-standard Wireless Intelligent Network (WIN) or 3GPP-standard Customised Applications for Mobile networks Enhanced Logic (CAMEL) service can be used to support call session anchoring).
  • call session anchoring ANSI-standard Wireless Intelligent Network (WIN) or 3GPP-standard Customised Applications for Mobile networks Enhanced Logic (CAMEL) service can be used to support call session anchoring.
  • the cellular CS network 110 sends response message to the VCC mobile device 155 and at stage (4), the cellular CS network 110 routes the call session to the VAS 150.
  • the VAS/SCP 150 After receiving the call, the VAS/SCP 150 gets all call session information, assigns APPSls, and sets an anchoring information for the call session according to the client VCC service capability, and at stage (5), the VAS sends the VCC UE ID, the call session information, its anchoring information to the APS 160.
  • Several APPSls are assigned to the call session, e.g. : APPSI1 for Wi-Fi IP network 1, APPSI2 for LTE IP network 2, APPSI3 for default IP network, APPSI5 for cellular CS network 1, APPSI6 for cellular CS network 2, etc.
  • the assigned APPSI is used in call request.
  • stage (8) From stage (6) to stage (8), the call session connection is established between two end devices.
  • the VCC mobile device 155 send call session information and its VCC service capability information to the VAS through IP network.
  • the VCC service capability information includes the network supported, VCC service type support (voice, video), capability of triggering handover, capability to start the handover procedure.
  • the VAS When receiving call session information and client VCC service capability information, at stage (10), the VAS queries anchoring information from the APS 160, and updates anchoring information for the call session according to the client VCC service capability; at stage (11), the VAS 150 sends session anchoring information including multiple APPSls back to the VCC mobile device 155 through IP network.
  • the VCC mobile device 155 associates the anchoring information with the call session and at stage (12), the VCC mobile device 155 sends handover call request (IP network 1 APPSI is used as called party) to the VAS 150 through IP network.
  • the VAS 150 Upon receiving handover request call, using the VCC UE ID and the APPSI, the VAS 150 gets the call session information at stage (13) from APS 160 and the VAS 150 does the domain transfer for the call session; the VAS 150 also sets new anchoring information with the call session. At the stage (14), new anchoring information and the VCC service control information are sent back to the VCC mobile device 155 through the IP network; the VCC mobile device 155 stores all information for future use. In this diagram, the VCC mobile device starts the handover request call.
  • VCC mobile device 155 When VCC mobile device 155 decides to handover the call session to the cellular network 1, it sends a handover call request (the called party of the call is set as the cellular CS network 1 APPSI) through the cellular network 1 at stage (18).
  • the Cellular network 110 and the VAS/SCP 150 will exchange information to make sure the handover call request should be routed to VAS for VCC service.
  • the Cellular network 110 send response message to the VCC mobile device 155 and at stage (21), the Cellular network 110 routes the call to the VAS 150.
  • the VAS 150 gets the detail call session information at stage (22).
  • the VAS associates new anchoring resource to the call session, and at stage (23), updates the APS 160 with new anchoring information.
  • stage (26) From stage (24) to stage (26), the connection of call session in cellular CS network is established and the IP connection of the call session is release. When the call session is released at stage (27), the anchoring information in the APS 160 is cleared at stage (28).
  • FIG. 3 is a basic call flow diagram illustrating how and when a call session and VCC service data exchanging between a VCC mobile device (e.g., VCC mobile device 155) and network server VAS 150. This diagram also illustrates how and when a VCC mobile device and the VAS store and use the VCC service data. In this diagram, a VAS makes session handover decision and starts handover procedure.
  • VCC mobile device e.g., VCC mobile device 155
  • VAS 150 network server
  • a VCC mobile device (e.g., VCC mobile device 155) initiates a call through an IP network to the VAS 150.
  • the VCC mobile device also sends its VCC service capability information to the VAS 150.
  • Second option sending it as separate VCC service information message from VCC mobile device to the VAS.
  • This separate VCC service information message is total new message.
  • the VAS assigns multiple APPSIs to this call session and sets anchoring information for this call session where APPSI-domain mappings are included in the anchoring information.
  • the VAS sends the VCC service data back to the VCC Mobile device; the VCC service data includes the anchoring information such as multiple APPSI-domain mapping (APPSI1 is assigned as cellular CS network handover APPSI), VCC service control information, and other VCC service data.
  • the VCC mobile device associates the anchoring information with the call session.
  • the VAS 150 saves VCC service data including the anchoring information to the APS 160 at stage (3). From stage (4) to stage (6), the connection of the call session is established successfully through the IP network between the VCC mobile device 155 and the VAS 150.
  • the VAS 150 decides to handover the session to the Cellular network 110.
  • the VAS 150 gets the VCC mobile device call session and its anchoring information;
  • the VAS sends handover request call (the calling party of the call is set as APPSI1, which is the cellular CS network APPSI) through the cellular network 110 where the VCC mobile device (e.g., VCC mobile device 155) attaches.
  • the VAS 150 switches the call session connection from IP network to the cellular network after sending the call out.
  • the handover request call is received by the VCC mobile device (e.g., VCC mobile device 155) and the VCC mobile device (e.g., VCC mobile device 155) switch session connection from the IP network to the cellular network after checking the call session information and the VCC service data.
  • the VCC mobile device e.g., VCC mobile device 155
  • the VCC mobile device e.g., VCC mobile device 155
  • switch session connection from the IP network to the cellular network after checking the call session information and the VCC service data.
  • session connection is switched to the cellular network; the old connection in the IP network is released; the anchoring information in the APS 160 is updated by the VAS 150.
  • the VCC mobile device e.g., VCC mobile device 155) and the VAS 150 find IP network 1 available for call session VCC service.
  • the VAS 150 gets the VCC mobile device (e.g., VCC mobile device 155) call session information and the call session anchoring information.
  • the VAS 150 and the VCC mobile device exchanges call session information and VCC service data (including call session anchoring information) through IP network 1; the VAS can sends the call session information to the VCC mobile device (e.g., VCC mobile device 155) or the VCC mobile device (e.g., VCC mobile device 155) can sends the call session information to the VAS 150 through IP network 1.
  • the VAS sends the server VCC service capability information to the VCC mobile device and the VCC mobile device sends the client VCC service capability information to the VAS.
  • the VAS also sends the anchoring information (APPSI2 is assigned as the IP network 1 APPSI) and VCC service data to the VCC mobile device (e.g., VCC mobile device 155).
  • the VCC mobile device e.g., VCC mobile device 155) associates the anchoring information with the call session.
  • the VAS 150 decides to handover the call session from the CS domain to the IP domain 1, at stage (17), it sends handover call request (the calling party of the call is set as APPSI2, which is IP network 1 APPSI) to the VCC mobile device (e.g., VCC mobile device 155) through IP domain.
  • APPSI2 IP network 1 APPSI
  • VCC mobile device e.g., VCC mobile device 155
  • the VAS 150 also does the call session domain transfer from the CS domain to the IP domain.
  • VCC mobile device e.g., VCC mobile device 155
  • the VCC mobile device finds the matched call session and then the VCC mobile device switches the call session connection to the IP network 1.
  • the connection of the call session between the VCC mobile device (e.g., VCC mobile device 155) and the VAS 150 is through the IP network 1.
  • the cellular CS connection of the call session between the VCC mobile device (e.g., VCC mobile device 155) and the VAS 150 is released and the VAS 150 also updates the remote peer side about the session connection change. Because of new connection established, the VAS 150 sets the new anchoring information for the call session.
  • the VAS 150 sends the anchoring information and VCC service control information to the VCC mobile device (e.g., VCC mobile device 155) at stage (22) through the IP network.
  • the VCC mobile device e.g., VCC mobile device 155) updates the call session anchoring information upon receiving the anchoring information at stage (22).
  • the VAS 150 sends the new anchoring information to the APS 160 at stage (23).
  • the VAS 150 find IP network 2 available for call session service and the IP network 2 has higher priority than current IP network 1 has, at stage (24), the VCC mobile device and the VAS 159 exchange call session information, VCC service data, and call session anchoring information (APPSI2 is assigned as the IP network 2 APPSI) through IP network 2.
  • the VAS 150 decides to handover the call session from IP network 1 to IP network 2 and at stage (25), the VAS 150 get the call session information as well as associated anchoring information.
  • the VAS 150 sends handover call request (the calling party of the handover call request is set as the APPSI3, which is IP network 2 APPSI) to the VCC mobile device (e.g., VCC mobile device 155) through the IP network 2.
  • the VAS 150 also does the call session domain transfer from the IP network 1 to IP network 2.
  • the VCC mobile device e.g., VCC mobile device 155) finds the call session and switches the call session connection from the IP network 1 to IP network 2.
  • the call session connection is established through IP network 2.
  • the VAS 150 sets the new anchoring information for the call session, and the VAS 150 sends the anchoring information and VCC service data to the VCC mobile device (e.g., VCC mobile device 155) at stage (28).
  • the VCC mobile device e.g., VCC mobile device 155) updates the anchoring information association upon receiving the anchoring information at stage (28).
  • the VAS 150 also sends the new anchoring information to the APS 160 at stage (29).
  • FIG. 4 is a call flow diagram illustrating call session set up in cellular GSM CS domain and being transferred to IP domain.
  • Session Initiation Protocol SIP, RFC 3261
  • This call session is initiated by a VCC mobile device (e.g., VCC mobile device 155) and the peer party is a CPE device connected to an IP network (e.g., IP peer CPE 130a).
  • a VCC mobile device (e.g., VCC mobile device 155) initiates a call in cellular GSM CS domain network 110 and the call reaches the VAS/SCP 150.
  • the VAS e.g., VAS 150
  • the VAS 150 saves VCC UE ID, anchoring information (including APPSIs), and the call session information into the APS 160.
  • stage (9) From stage (7) to stage (9) the call is established successfully between the VCC mobile device 155 and the peer CPE 130a.
  • the VCC mobile device 155 when VCC mobile device 155 decides to do domain transfer from the cellular network 110 to the IP network 130, the VCC mobile device 155 sends a SIP registration message to the VAS 150 through the IP network.
  • the SIP registration message includes a new SIP call session header that carries the call session information that the VCC mobile device 155 current has.
  • the new SIP call session header includes following information: caller party, called party, domain used for call session. The following are the example of the header:
  • the VAS 150 gets call session information from the registration message.
  • the VAS 150 gets the VCC mobile device VCC UE ID, queries anchoring information from the APS 160.
  • the APS 160 returns anchoring information (including APPSIs) and call session information back to the VAS 150.
  • VCC AP header looks like but not limited to this format:
  • VCC mobile device 155 After VCC mobile device 155 receives 200 OK message, it saves anchoring information locally; because the IP network has high priority for call session, at stage (14), the VCC mobile device 155 generates a SIP INVITE message(the called party is set as APPSIl and the calling party is set as the VCC mobile device UE ID) and sends the message to VAS 150.
  • the VAS 150 gets the message, finds that the call is handover request call.
  • the VAS 150 gets the calling party VCC UE ID, and at stage (15), the VAS 150 queries anchoring information from the APS 160 with VCC UE ID and APPSIl. At stage (16), the APS 160 returns response call session information including the call session anchoring processing instance back to the VAS 150.
  • the VAS 150 Upon receiving response from the APS 150 at stage (16), the VAS does the domain transferring. Because this handover call request creates a new connection between the VCC mobile device 155 and the VAS 150, the VAS 150 assigns multiple APPSIs to this session. At stage (17), the VAS 150 sends 200 OK message for the handover request call to the VCC mobile device 155. Inside the 200 OK message, VAS 150 inserts a new VCC AP header that indicates the multiple APPSIs can be used for next handover request when applicable. The following is an example of this header looks like but not limited to this format:
  • VDN When APPSI is used in a cellular CS network, it works like VDN; When APPSI is used in an IP network, it works like VDI.
  • the VAS 150 informs the remote end user 130a of media changing because of domain transfer.
  • the remote end user 130a responses the media update.
  • the VAS 150 releases the cellular CS connection between the VAS 150 and the VCC mobile device 155.
  • the VAS 150 sends the new anchoring information to the APS 160.
  • the call session domain transferring from the cellular CS network to the IP network finishes.
  • FIG. 5 is a call flow diagram illustrating call session set up in IP domain and transferred to cellular GSM CS domain and then back to IP network again.
  • This call session is initiated by a CPE device connected to an IP network (e.g., IP CPE 130a) and destination party is a VCC mobile device (e.g., VCC mobile device 155).
  • IP network e.g., IP CPE 130a
  • VCC mobile device e.g., VCC mobile device 155
  • SIP Session Initiation Protocol
  • RFC 3261 Session Initiation Protocol
  • the VCC mobile device 155 sends SIP registration message to the VAS 150 through IP network (for example through a Wi-Fi access point).
  • VCC service capability header that indicates the VCC mobile device's VCC service and its service capability.
  • the new VCC service capability header is added in the SIP register message as following but not limited in this format:
  • VCC-Service-Capability-information Network support (Wi-Fi, GSM network, CDMA network, GSM 3G, CDMA 3G, LTE, TD LTE, 4G, 5G), handover trigger (packet lost ratio threshold, packet delay threshold, wireless signal strength threshold), session type(voice, video), VCC handover control(yes);
  • the network support includes all networks that the VCC mobile device can connect. This list can include any new type wireless network that can support VCC service.
  • Handover trigger has three items: packet lost ratio threshold, packet delay threshold, and wireless signal strength threshold. It means the VCC mobile device can support three functions for all wireless networks if applicable. For example, when a Wi-Fi network is used for call session, the VCC mobile device can detect the packet lost ratio of the connection: if the number is bigger than the packet lost ratio hand-out threshold, then VCC mobile device will trigger the handover procedure to switch the call session to another network if applicable.
  • the VCC mobile device can detect the wireless signal strength: if the number is less than the wireless signal strength hand-out threshold, then VCC mobile device will trigger the handover procedure to switch the call session to another network if applicable; the VCC mobile device can also detect the end-to end packet delay of the connection: if the number is bigger than the packet delay hand-out threshold, then VCC mobile device will trigger the handover procedure to switch the call session to another network if applicable.
  • the VCC mobile device finds a Wi-Fi network available: the VCC mobile device measures packet lost ratio, packet delay, and wireless signal strength of the Wi- Fi network; if the wireless signal strength is bigger than the wireless signal strength hand-in threshold and/ or the packet lost ratio is less than the packet lost ratio hand-in threshold and/ or packet delay is less than the packet delay hand-in threshold, then VCC mobile device will trigger the handover procedure to switch the call session to the Wi-Fi network.
  • VCC handover control(yes) indicates that the VCC mobile device can start handover procedure at any network. If “VCC handover control(no)” set, means the VCC mobile device can't start handover procedure at any network; if “VCC handover control(IP)” set, means the VCC mobile device can start handover procedure at any IP network; if “VCC handover control(cellular CS)” set, means the VCC mobile device can start handover procedure at any cellular CS network.
  • the VAS 150 confirms registration successful by sending 200 OK back to VCC mobile devise 155; inside this 200 OK message, there is the VAS VCC service capability header added as following for example but not limited:
  • VCC-Service-Capability-information Network support (IP, GSM, CDMA, GSM 3G, CDMA 3G, LTE, TD LTE, 4G, 5G), handover trigger (packet lost ratio threshold, packet delay threshold), session type(voice, video), VCC handover control (yes);
  • the network support includes all networks that the VAS can connect. This list can include any new type wireless network that can support VCC service.
  • the "handover trigger" defines the VAS server capability of detecting packet lost ratio and packet delay for all kinds of network.
  • VCC handover control(yes) indicates that the VAS can start handover procedure at any network. If “VCC handover control(no)” set, means the VAAS can't start handover procedure at any network; if “VCC handover control(IP)” set, means the VAS can start handover procedure at any IP network; if “VCC handover control(cellular CS)” set, means the VAS can start handover procedure at any cellular CS network.
  • the IP CPE 130a initiates a call to the VCC mobile device 155 which phone number is A.
  • the VAS 150 gets the called party VCC UE ID, assigns multiple APPSIs to this call session, and sets anchoring information for the call session of VCC UE ID.
  • the VAS 150 sends an INVITE message to the VCC mobile device 155 which includes a new VCC AP header and several handover trigger rules headers. These new headers carry the call session anchoring information.
  • the VCC AP header includes the APPSIs information where the VCC mobile device 150 will use for future handover request.
  • the VCC AP header looks like following but not limited to this format:
  • the handover trigger rules headers looks like following but not limited to this format:
  • handover in trigger rulel
  • rulel rulel
  • handover trigger header define Wi-Fi network hand-in trigger detail information: if packet lost ratio threshold of connect is less than 5% and wireless signal strength threshold of Wi-Fi wireless signal is bigger than -70dbm and packet delay of end-to-end connection is less than 50ms, then this Wi-Fi network can be used for call session service.
  • Wi-Fi network hand-out trigger detail information if packet lost ratio threshold of the connect through Wi-Fi network is bigger than 10% or wireless signal strength threshold of Wi-Fi wireless signal is less than -90dbm or packet delay of end-to-end connection through Wi-Fi AP is bigger than 80ms, then this Wi-Fi network can't be used for call session service, and needs to switch the call session from Wi-Fi network to another network.
  • the VCC mobile device 155 Upon receiving INVITE message from the VAS 150, at stage (5), the VCC mobile device 155 saves all VCC service data with the call session SI, returns 18x back to the VAS 150. [094] Upon receiving 18x message from the VCC mobile device 155, at stage (6), the VAS 150 saves VCC UE ID, call session information and anchoring information to the APS 160. At stage (6), The VAS 150 forwards 18x to the IP CPE 130a.
  • the VCC mobile device 155 answers the call session request and the call session is established between two end users.
  • the VAS 150 decides to handover the call session to the cellular CS network; at stage (9), using VCC UE ID, the VAS 150 sends query message to the APS 160 to get the call session information and its anchoring information. At stage (10), the APS 160 returns call session information and its anchoring information (including APPSIs) back to the VAS 150. At stage (11), the VAS 150 uses the APPSI2 as the calling party to send handover call request to the VCC mobile device 155 through the GSM cellular CS network 110. The called party is the VCC mobile device GSM ID. The VAS 150 makes the call session connection switching from the IP network to the cellular GSM CS network.
  • the VCC mobile device 155 upon receiving the handover call request, gets the call session associated with the APPSI2 and transfer call session connection from IP network to the new GSM CS connection.
  • stage (14) From stage (13) to stage (14), the connection in the CS network is confirmed and the new connection is also updated up to the peer side; at stage (15), the IP connection of the call session is released between the VCC mobile device 155 and the VAS 150.
  • VAS assigns new anchoring information to the call session and at stage (16), the VAS 150 sends the new anchoring information to the APS 160.
  • VCC mobile device finds an IP network available (for example, a LTE IP network's priority is higher than current cellular CS network's priority), it sends registration message to the VAS at stage (17) through the new IP network.
  • VAS finds the VCC UE registered and the VAS gets the VCC UE anchoring information and the call session information from stage (18) to stage (19).
  • the VAS 150 sends the call session information and anchoring information to VCC mobile device through the new IP network.
  • the following two new headers are added in the 200 OK register message to carry the call session information and anchoring information but not limited:
  • the VCC mobile device associates the new anchoring information with the call session.
  • the VAS 150 can send the call session information and the VCC anchoring information to the VCC mobile device through SIP Notify message or other new defined SIP message with these kinds of headers.
  • the VCC mobile device detects that the LTE network wireless signal strength is higher than handover-in threshold (-60dbm); the VCC mobile device reports this to the VAS 150.
  • the VAS 150 When the VAS 150 detects that the packet lost ratio of the IP network is less than hand- in threshold (5%), the packet delay of connection between the VAS and the VCC mobile device is less than 50ms, and upon receiving the VCC mobile device reporting of the wireless signal strength (better than -70dbm defined in the header), it starts handover procedure to switch the call session to the new IP network as indicated in the anchoring information.
  • the VAS 150 sends the handover request to the VCC mobile device at stage (21) through the LTE IP network. Inside the SIP INVITE message, the From header contains APPSI3 information and the To header includes the VCC UE ID. The VAS does domain transfer for the call session.
  • the VCC mobile device Upon receiving the call request and getting the APPSI3, the VCC mobile device switches the call session connection from the GSM CS network to the LTE IP network. At stage (22), the VCC mobile device sends 200 OK back to the VAS to confirm the connection request. At stage (23), the CS connection of the call session between the VCC mobile device and VAS is released.
  • FIG. 6 is a call flow diagram illustrating call session set up in IP domain and transferred to cellular CS domain.
  • This call session is initiated by a VCC mobile device (e.g., VCC mobile device 155) and destination party is a CPE device connected to an IP network (e.g., IP CPE 130a).
  • VCC mobile device e.g., VCC mobile device 155
  • destination party is a CPE device connected to an IP network (e.g., IP CPE 130a).
  • IP network e.g., IP CPE 130a
  • IMS network is involved and the VAS 150 works as an IMS application server. All call session to/from the VCC mobile device 155 goes through the IMS network/ GW 135.
  • the VCC mobile device 155 sends SIP registration message to the VAS 150 through IP IMS network 135.
  • This SIP registration message includes the VCC mobile device VCC service capability header.
  • the IMS network 135 forwards this message to the VAS 150 including the VCC service capability header.
  • the VAS confirms registration successful by sending 200 (including the VAS VCC service capability header) back to VCC mobile devise 155 through the IMS network 135.
  • the VCC mobile device 155 initiates a call to the IP CPE 130a which phone number is C.
  • the IMS network 135 forwards the call to the VAS 150.
  • the VAS 150 gets the calling party VCC UE ID, assigns multiple APPSls to this call session.
  • the VAS 150 sets an anchoring information to the call session; at stage (7), the VAS 150 sends the call session information, VCC UE ID, and call session anchoring information to the APS 160.
  • stage (8) to stage (9) the call is forwarded to the IP CPE 130a.
  • the IP CPE 130a Upon receiving INVITE message, at stage (10), the IP CPE 130a sends SIP 18X back to the IMS network 135 and at stage (11), the IMS network forwards the SIP 18X to the VAS 150.
  • the VAS Upon receiving SIP 18X message from the IP CPE 130a side, at stage (12) the VAS sends a SIP 18X message to the VCC mobile device 155 with the new VCC AP header that carries the anchoring information for this call session. At stage (13), the IMS network 135 forwards the SIP 18X message with the VCC AP header to the VCC mobile device 155.
  • the VCC AP header looks like following but not limited to this format:
  • Wi- Fi IP network is the first one so it has the highest priority
  • T-Mobile CS network is the second one, so it has second highest priority for call session service
  • all other cellular CS network is at last place, so it has the lowest priority for call session service
  • the VCC mobile device 155 Upon receiving the 18X message from the VAS 150, at stage (13), the VCC mobile device 155 saves the anchoring information with the call session SI.
  • the remote end user IP CPE 130a answers the call and sends 200 OK message back to the IMS network 135.
  • the IMS network 135 forwards the 200 OK message to the VAS 150.
  • the VAS 150 can add a new VCC AP header with APPSls into 200 OK message and sends to the VCC mobile device 155.
  • the IMS network 135 finally forwards the 200 Ok message to the VCC mobile device 155.
  • the VCC AP header looks like following but not limited to this format:
  • Wi-Fi IP network APPSI APPSI1
  • LTE IP network APPSI APPSI1
  • Verizon CS network PSI APPSI2
  • AT&T 4G network APPSI APPSI2
  • cellular CS network APPSI APPSI2
  • Wi- Fi IP network is the first one so it has the highest priority
  • LTE IP network is the second one, so it has second highest priority for call session service and so on.
  • VCC mobile device 155 decides to handover the call to the cellular network, at stage (18), the VCC mobile device 155 sends call setup message to the cellular network where the called party number is set as APPSI2. Camel service triggered and the IDP message is sent to the VAS/SCP 150 at stage (19). The VAS/SCP 150 sends connection message with IMRN back to the cellular network at stage (20). At stage (21), the cellular network sends call proceeding message to the VCC mobile device 155.
  • the IMRN call is forwarded to the VAS/SCP 150.
  • the VAS/SCP 150 receives the call from the IMS network 135, the VAS/SCP 150 gets the calling party number and APPSI2, and then gets the VC UE ID of the VCC mobile device 155.
  • the VAS/SCP 150 sends query anchoring info message to the APS 160 and at stage (25), the APS 160 returns the call session information and its anchoring information back to the VAS/SCP 150.
  • the VAS/SCP 150 Upon receiving the anchoring info response message, the VAS/SCP 150 does the domain transfer the VCC mobile device 155 from the IP network to the cellular CS network. At stage (26), the VAS/SCP 150 sends confirm connection and finally to the VCC mobile device 155 through the cellular CS network.
  • the VAS/SCP 150 sends the media change to the remote end user IP CPE 130a and the remote end user IP CPE 130a confirms the media change.
  • the VAS 150 releases the IP connection between the VCC mobile device 155 and the VAS 150. Till now, the procedure of the call session domain transferring from IP to cellular CS network finishes.
  • the VAS 150 sets new anchoring information for the call session and sends the new information to the APS 160 for updating.
  • stage (36) From stage (33) to stage (36), call session released by the IP CPE 130a; the VAS 150 releases connection with the VCC mobile device 155 and clear anchoring information in the APS 160. All call session and related anchoring information are cleared.
  • FIG. 7 is a block diagram illustrating an example VCC services platform operable to provide call handover.
  • the VCC services platform 500 can include a processor 510, a memory 520, a storage device 530, and an input/ output device 540. Each of the components 510, 520, 530, and 540 can, for example, be interconnected using a system bus 550.
  • the processor 510 is capable of processing instructions for execution within the system 500. In one implementation, the processor 510 is a single-threaded processor. In another implementation, the processor 510 is a multi-threaded processor.
  • the processor 510 is capable of processing instructions stored in the memory 520 or on the storage device 530.
  • the memory 520 stores information within the device 500.
  • 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.
  • the storage device 530 is capable of providing mass storage for the device 300.
  • the storage device 530 is a computer-readable medium.
  • 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.
  • the input/ output device 540 provides input/ output operations for the device 500.
  • the input/ output device 540 can include one or more of a PSTN interface (e.g., an Tl/El connector), an IP network interface device, e.g., an Ethernet card, a cellular network interface, a serial communication device, e.g., and RS-232 port, and/ or a wireless interface device, e.g., and 802.11 card.
  • 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.
  • Any of the devices e.g., soft-switch servers, cellular network side equipment, IMS servers, Mobile devices, etc.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • a computer need not have such devices.
  • a computer can be embedded in another device, e.g., a VCC mobile device, a telephone, a cable modem, a set-top box, a mobile audio or video player, or a game console, to name just a few.
  • a VCC mobile device e.g., a telephone, a cable modem, a set-top box, a mobile audio or video player, or a game console, to name just a few.
  • 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.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto optical disks e.g., CD ROM and DVD ROM disks.
  • the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
  • 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.
  • a display e.g., a CRT (cathode ray tube), LCD (liquid crystal display), LED (light emitting diode) monitor
  • a keyboard and a pointing device e.g., a mouse or a trackball
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne une conception permettant le transfert d'une session initiée par un dispositif mobile VCC ou par le serveur de service de réseau : un serveur d'application de service (VAS) VCC (continuité d'appel Vocal/Vidéo). Dans les conceptions ou réalisations existantes, en cas de besoin de transfert de session d'appel vers un domaine différent, une identité de service public de transfert pré-configurée (PSI) stockée à la fois dans le dispositif mobile VCC et dans le VAS est utilisée pour effectuer une demande de transfert dans un domaine cible; de même, en cas de besoin de transfert de session d'appel vers un domaine différent, seule une entité pré-configurée, qu'il s'agisse du dispositif mobile VCC ou du VAS, peut initier une demande d'appel de transfert.
PCT/US2014/012407 2013-01-23 2014-01-21 Système et procédé de transfert de session d'appel vers un réseau ip ou un réseau à multiplexage par répartition dans le temps (tdm) cellulaire WO2014116613A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201361755471P 2013-01-23 2013-01-23
US61/755,471 2013-01-23
US201414145934A 2014-01-01 2014-01-01
US14/145,934 2014-01-01

Publications (1)

Publication Number Publication Date
WO2014116613A1 true WO2014116613A1 (fr) 2014-07-31

Family

ID=51227972

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/012407 WO2014116613A1 (fr) 2013-01-23 2014-01-21 Système et procédé de transfert de session d'appel vers un réseau ip ou un réseau à multiplexage par répartition dans le temps (tdm) cellulaire

Country Status (1)

Country Link
WO (1) WO2014116613A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111031581A (zh) * 2018-10-09 2020-04-17 中兴通讯股份有限公司 一种4/5g互切换场景下锚定smf+pgw-c的方法及系统

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070218906A1 (en) * 2006-03-17 2007-09-20 Nec Corporation Method for controlling a mobile node
US20090080382A1 (en) * 2007-09-21 2009-03-26 Motorola, Inc. Method and apparatus for inter-technology handoff of a user equipment
US20090207807A1 (en) * 2006-06-14 2009-08-20 Nortel Networks Limited Inter-subsystem transfers
US20100118830A1 (en) * 2008-11-10 2010-05-13 Cisco Technology, Inc. Mobile Intelligent Roaming Using Multi-Modal Access Point Devices
US20110110331A1 (en) * 2009-11-10 2011-05-12 Telefonaktiebolaget Lm Ericsson (Publ) Handover Delay Optimization
US20110238845A1 (en) * 2008-09-29 2011-09-29 Ralf Keller Correlation of Sessions in Case of Session Transfer in IMS Domain
US20120142357A1 (en) * 2009-08-11 2012-06-07 Nec Corporation Handover control system, target control apparatus, source control apparatus, handover control method, and computer readable medium
US20120182970A1 (en) * 2009-09-22 2012-07-19 Huawei Device Co., Ltd. Method, system and device for network handover
US20120224564A1 (en) * 2009-11-09 2012-09-06 Samsung Electronics Co. Ltd. Method and system to support single radio video call continuity during handover

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070218906A1 (en) * 2006-03-17 2007-09-20 Nec Corporation Method for controlling a mobile node
US20090207807A1 (en) * 2006-06-14 2009-08-20 Nortel Networks Limited Inter-subsystem transfers
US20090080382A1 (en) * 2007-09-21 2009-03-26 Motorola, Inc. Method and apparatus for inter-technology handoff of a user equipment
US20110238845A1 (en) * 2008-09-29 2011-09-29 Ralf Keller Correlation of Sessions in Case of Session Transfer in IMS Domain
US20100118830A1 (en) * 2008-11-10 2010-05-13 Cisco Technology, Inc. Mobile Intelligent Roaming Using Multi-Modal Access Point Devices
US20120142357A1 (en) * 2009-08-11 2012-06-07 Nec Corporation Handover control system, target control apparatus, source control apparatus, handover control method, and computer readable medium
US20120182970A1 (en) * 2009-09-22 2012-07-19 Huawei Device Co., Ltd. Method, system and device for network handover
US20120224564A1 (en) * 2009-11-09 2012-09-06 Samsung Electronics Co. Ltd. Method and system to support single radio video call continuity during handover
US20110110331A1 (en) * 2009-11-10 2011-05-12 Telefonaktiebolaget Lm Ericsson (Publ) Handover Delay Optimization

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111031581A (zh) * 2018-10-09 2020-04-17 中兴通讯股份有限公司 一种4/5g互切换场景下锚定smf+pgw-c的方法及系统

Similar Documents

Publication Publication Date Title
US11496868B2 (en) Request to hand over a session between a mobile communication device and a customer premises equipment
CN112640372B (zh) 提供移动设备连接性的方法、系统和计算机可读介质
US8467350B2 (en) Conferencing PSTN gateway methods and apparatus to facilitate heterogeneous wireless network handovers for mobile communication devices
KR100954512B1 (ko) 상이한 네트워크 타입의 액세스 포인트에 대한 무선ＶｏＩＰ/ＶＩＰ 로밍
US8358647B2 (en) System and method for provision of IMS based services for legacy CS UE with home node B access
US20110268110A1 (en) Providing Packet-Based Multimedia Services via a Circuit Breaker
KR101263741B1 (ko) 멀티미디어 세션 전달을 위한 방법, 사용자 디바이스 및 서버
US8107956B2 (en) Providing over-the-top services on femto cells of an IP edge convergence server system
US20060165064A1 (en) Method and apparatus for a network element to track the availability of other network elements
CN104040998A (zh) 基于ice的nat遍历
KR20090091285A (ko) 대응하는 사용자 식별자들을 이용한 기업 및 통신 사업자 서비스로의 액세스 제공
US20050282575A1 (en) Routing calls to facilitate call handover
CN103491641A (zh) 长期演进企业网内实现语音业务的方法和企业网系统
JP2008511206A (ja) 管理されたモバイル・ボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）オーバーレイ方法およびアーキテクチュア
WO2014116757A1 (fr) Système et procédé pour le transfert de session(s) d'appel en simultané à un réseau ip ou un réseau st de téléphonie mobile
EP3139565A1 (fr) Analyseur syntaxique pour routage local vocal sur de petites cellules d'un réseau d'évolution à long terme
WO2014116613A1 (fr) Système et procédé de transfert de session d'appel vers un réseau ip ou un réseau à multiplexage par répartition dans le temps (tdm) cellulaire
JP2011244192A (ja) 内線電話システムおよび内線電話方法
Ito et al. Mechanism of reducing signaling processing load in epc/ims using service-specific network virtualization
Karthik et al. Optimized local call routing
US8948160B1 (en) Controlling services in a circuit-switched network from a packet network
JP2011188128A (ja) 移動通信システム、基地局、移動管理装置、加入者情報管理装置および移動機内線接続方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14742755

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14742755

Country of ref document: EP

Kind code of ref document: A1