Method and system for handover of video calls from a packet switched network to a circuit switched network in a single radio environment

A method and system for handover of a video call from a packet switched network to a circuit switched network by a first network entity associated with the packet switched network in a single radio environment is provided. A need to perform a video single radio voice call continuity (vSRVCC) handover from a packet switched network to a circuit switched network is detected during a video call session in the packet switched network. Accordingly, a vSRVCC handover request is transmitted to a second network entity associated with the circuit switched network for performing the vSRVCC handover of the video call session where the vSRVCC handover request includes vSRVCC capabilities of a user equipment (UE) associated with the video call session.

PRIORITY

This application is a U.S. National Phase entry from and claims priority to International Appl. No. PCT/KR2011/003322, filed May 3, 2011, and also claims priority to Appl. No. 1244/CHE/2010, filed with the Indian Patent Office on May 3, 2012, the contents of each of which are incorporated herein by reference.

BACKGROUND

1. Field of the Invention

The present invention generally relates to wireless communication systems, and more particularly, to handover of video calls from a packet switched network to a circuit switched network in a single radio environment.

2. Description of the Related Art

An SAE/LTE system is a packet switched (PS) system in which voice and video calls are established through a PS domain. Therefore as a “default option”, voice calls use the PS domain as packet video-calls and underlying call control protocol is SIP supported through an IP multimedia subsystem (IMS). Recently, there has been a slow migration of users from the SAE/LTE domain from a circuit switched (CS) domain to the LTE packet switched domain. Hence, the LTE system may be deployed in “islands” overlaying parts of the CS domain. This means that if a user makes a video-call over the LTE system, the video-call may not be just subject to an intra-domain handover (i.e., radio-level and intra-network-level handover) but is also likely to be subject to an inter-domain handover from the LTE packet domain to the CS domain due to mobility of the user during the video-call. This leads to the development of a functionality called Single Radio Voice Call Continuity (SRVCC) in the Third Generation Partnership Project (3GPP) technology. SRVCC is a functionality that allows a voice/video call in the LTE packet domain to be moved to the CS domain.

CS video-calls support a feature called “Service change for UDI/RDI fallback” (normally referred to as a service change and unrestricted digital information fallback (SCUDIF)). This service is available to UDI/RDI multimedia calls and allows users to achieve successful call establishment when end-to-end CS multimedia is not possible (fallback to speech) or when signaling of the feature is not possible in the CS network (fallback to preferred service or speech). Furthermore, it allows users to swap between a multimedia service and basic speech during an established call.

Nevertheless, in the case that the call (either voice-call or video-call) has been established in the IMS, there is no negotiation that normally takes place between user equipment (UE) and a mobile service centre (MSC) in order to mutually identify whether both the UE and MSC support the SCUDIF feature; hence it is not possible to use the SCUDIF feature when the UE moves to the CS domain from the PS domain. For example, if a voice/video call has been initiated with the PS network and later handed over to the CS network using an SRVCC, there is no communication that takes place between the UE and the MSC during the call setup time. As a consequence, the UE and the MSC are unaware of each other's SCUDIF capabilities (user-initiated or network-initiated) when the voice/video call is transferred to the CS network.

Further, a delay may be introduced by H.324 when performing the following steps for call setup:H.223 Multiplexer level detectionTerminal Capability ExchangeMaster Slave determinationOpen Logical ChannelsMultiplexer Table Entries Exchange

The procedure typically takes 5˜8 seconds. If link quality deteriorates or media configurations between UEs are not well-matched, this delay may increase even further. The delay can be suppressed to as low as a few seconds in limited cases when the acceleration techniques are supported by both UEs and little data is lost during the period. However, the call set up procedure of 3G-324M, outlined above, is likely to occur at cell edges under the SRVCC situations where radio link is unstable.

Given that the period of the current SRVCC handover with voice only is significantly smaller (e.g. in the range of 300-500 ms) if simultaneous transfer of voice and video is performed when a handover from PS-to-CS network with video SRVCC (given that a 64 kbps bearer is established on the UTRAN side and the increased call setup delay of 3G-324M from the negotiation between UEs using H.245 signaling procedures) interruption time might be significantly large, during which a message might be displayed to ask for patience from the user or recently-played video clips might be replayed until newly-decoded scenes become available.

SUMMARY OF THE INVENTION

According to an aspect of the present invention, there is provided a method for performing a handover of a video call from a packet switched network to a circuit switched network by a first network entity associated with the packet switched network in a wireless network environment. The method includes detecting a need to perform a video single radio voice call continuity (vSRVCC) handover from a packet switched network to a circuit switched network during a video call session in the packet switched network, and transmitting a vSRVCC handover request to a second network entity associated with the circuit switched network for performing the vSRVCC handover of the video call session; with the vSRVCC handover request includes vSRVCC capabilities of a user equipment (UE) associated with the video call session.

According to another aspect of the present invention, there is provided a method for performing a handover of a video call from a packet switched network to a circuit switched network by a second network entity associated with the circuit switched network in a wireless network environment. The method includes receiving, from a first network entity associated with the packet switched network, a video single radio voice call continuity (vSRVCC) handover request for performing a vSRVCC handover of a video call session in the packet switched network, wherein the vSRVCC handover request comprises vSRVCC capabilities of a user equipment (UE) associated with the video call session; and performing the vSRVCC handover based on the vSRVCC capabilities of the UE.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

FIG. 1is a block diagram of a wireless communication system100for performing handover of video calls from a packet switched network to a circuit switched network, according to an embodiment of the present invention. InFIG. 1, the wireless communication system100includes a packet switched network102having a network entity (Mobility Management Entity (MME)/SGSN)104(e.g. an MME in LTE networks, a serving general packet radio service (GPRS) node in the case of 3G plus network, etc.) and a user equipment (UE)106communicatively connected to the network entity104. The wireless communication system100also includes the circuit switched network108having a network entity (MSC)110.

As can be seen, the packet switched network102overlaps parts of the circuit switched network108. In consideration of this, the UE106has a video call session through the network entity104of the packet switched network102. When the UE106moves from the packet switched network102to the circuit switched network108, a handover of the video call from the packet switched network102to the circuit switched network has to be performed. The below description is described with reference toFIGS. 1 and 2.

In an embodiment of the present invention, an eNB112connected to the UE106detects a need to perform a video single radio voice call continuity (vSRVCC) handover from the packet switched network102to the circuit switched network108during the video call session (as in step202ofFIG. 2). The term ‘video call session’ refers to an ongoing video call or a video call in alerting state for notifying a reception of a call. For example, the eNB112detects a need to perform a vSRVCC handover based on parameters in measurement reports received from the UE106. The eNB112then communicates the need to perform the vSRVCC handover procedure to the network entity104.

Accordingly, the network entity104sends a vSRVCC handover request to the network entity110for performing a vSRVCC handover of the video call session (as in step204ofFIG. 2). Examples of a vSRVCC handover request is given in Table 1 below. In some embodiments, the network entity104communicates the vSRVCC capabilities of the UE106associated with the video call session to the network entity104in the vSRVCC handover request. The vSRVCC capabilities include a service change and unrestricted digital information fallback (SCUDIF) capabilities, a first set of bearer capabilities, a second set of bearer capabilities, and bearer capability elements associated with the UE106. The SCUDIF capabilities indicate support for user initiated service change and fallback or network initiated in-call modification (ICM). Examples of vSRVCC capabilities of the UE106are given in Table 2 below. In these embodiments, the UE102shares the vSRVCC capabilities with the eNB112during an initial attach procedure with the network entity104.

TABLE 1InformationelementsPCondition/CommentIE TypeIns.IMSICThis IE shall be included in the message except for theIMSI0cases:The UE is emergency attached and it is UICClessThe UE is emergency attached and the IMSI isnot authenticatedME Identity (MEI)CThis IE shall be included in the message if UE isMEI0emergency attached.Sv FlagsCThe following flags are applicable:Sv Flags0EmInd: this flag shall be sent if this session is foran emergency call.ICS: this flag shall be sent to request IMSCentralized Service support.Video SRVCC capability: This 2 bits flag indicatesthe UE capability regarding SCUDIFMME/SGSN SvMThis IE specifies the address for control plane messageIP-Address0Address for Controlwhich is chosen by the source MME/SGSNPlaneMME/SGSN Sv TEIDMThis IE specifies the tunnel for control plane messageTEID-C0for Control Planewhich is chosen by the source MME/SGSN. The targetMM shall include this TEID in the GTP header of allrelated control plane messages which are related tothe requested bearer.C-MSISDNCThe MME/SGSN shall include C-MSISDN IE in theMSISDN0message except for the cases:The UE is emergency attached and it is UICClessThe UE is emergency attached and the IMSI isnot authenticatedThe C-MSISDN is defined in 3GPP TS 23.003 [4].STN-SRCThe MME/SGSN shall include STN-SR IE if thisSTN-SR0session is not for an emergency call.MM Context for E-CThe MME shall include mobile station classmarks,MM Context for E-0UTRAN SRVCCsupported codecs, and CS Security key in MM ContextUTRAN SRVCCfor SRVCC for E-UTRAN SRVCC.The derivation of the CS security keys shall follow theprocedures defined 3GPP TS 33.401 [7].MM Context forCThe SGSN shall include mobile station classmarks,MM Context for0UTRAN SRVCCsupported codecs, and CS Security key in MM ContextUTRAN SRVCCfor SRVCC for UTRAN (HSPA) SRVCC.The derivation of the CS security keys shall follow theprocedures defined 3GPP TS 33.102 [10].Source to TargetMThe MME or SGSN shall include Source to TargetSource to Target0TransparentTransparent Container IETransparantContainerContainer IETarget RNC IDCThis IE shall be used to identify the target access forTarget RNC ID0SRVCC handover to UTRAN (note 1).Target Cell IDCThis IE shall be used to identify the target access forTarget Global Cell0SRVCC handover to GERAN (note 1).IDPrivate ExtensionONonePrivate ExtensionVSVideo SRVCCcapabilityNOTE 1:Based upon the SRVCC Handover procedure, either Target RNC ID or Target Cell ID shall be present in this message

TABLE 2<MS network capability value part> ::=<GEA1 bits><SM capabilities via dedicated channels: bit><SM capabilities via GPRS channels: bit><UCS2 support. bit><SS Screening indicator: bit string(2)><SoL3A Capability : bit><Revision level indicator: bit><PFC feature mode: bit><Extended GFA bits><LCS VA capability: bit><PS inter-RAT HO to UTRAN Iu mode capability: bit><PS inter-RAT HO to E-UTRAN S1 mode capability: bit><CSFB Capability: bit><ISR support: bit><SRVCC to GERAN/UTRAN capability: bit><EPC capability: bit><Selective camping capability. bit><NF capability: bit><Video SRVCC capability: bit string (2)><Spare bits>;<GEA1 bits> ::= < GEA/1 :bit>;<Extended GEA bits> ::= <GEA/2:bit><GEA/3:bit>< GEA/4:bit >< GEA/5:bit >< GEA/6:bit ><GEA/7:bit>;<Spare bits> ::= null | {<spare bit> < Spare bits >};SS Screening Indicator0 0defined in 3GPP TS 24.080 [24]0 1defined in 3GPP TS 24.080 [24]1 0defined in 3GPP TS 24.080 [24]1 1defined in 3GPP TS 24.080 [24]SM capabilities via dedicated channels0Mobile station does not support mobile terminated point to point SMS via CS domain1Mobile station supports mobile terminated point to point SMS via CS domainSM capabilities via GPRS channels0Mobile station does not support mobile terminated point to point SMS via PS domain1Mobile station supports mobile terminated point to point SMS via PS domainUCS2 supportThis information field indicates the likely treatment by the mobile station of UCS2 encoded characterstrings.0the ME has a preference for the default alphabet (defined in 3GPP TS 23.030 [8b])over UCS2.1the ME has no preference between the use of the default alphabet and theuse of UCS2.GPRS Encryption Algorithm GEA/10encryption algorithm GEA/1not available1encryption algorithm GEA/1 availableSoLSA Capability0The ME does not support SoLSA.1The ME supports SoLSA.Revision level indicator0used by a mobile station not supporting R99 or later versions of the protocol6used by a mobile station supporting R99 or later versions of the protocolPFC feature mode0Mobile station does not support BSS packet flow procedures1Mobile station does support BSS packet flow proceduresGEA/20encryption algorithm GEA/2 not available1encryption algorithm GEA/2 availableGEA/30encryption algorithm GEA/3 not available1encryption algorithm GEA/3 availableGEA/40encryption algorithm GEA/4 not available1encryption algorithm GEA/4 availableGEA/50encryption algorithm GEA/5 not available1encryption algorithm GEA/5 availableGEA/60encryption algorithm GEA/6 not available1encryption algorithm GEA/6 availableGEA/70encryption algorithm GEN/7 not available1encryption algorithm GEA/7 availableLCS VA capability (LCS value added location request notification capability)This information field indicates the support of the LCS value added location request notification via PSdomain as defined in 3GPP TS 23.271 [105].0location request notification via PS domain not supported1location request notification via PS domain supportedPS inter-RAT HO to UTRAN Iu mode capabilityThis information field indicates the support of the PS inter-RAT HO to UTRAN Iu mode.0PS inter-RAT HO to UTRAN Iu mode not supported1PS inter-RAT HO to UTRAN Iu mode supportedPS inter-RAT HO to E-UTRAN S1 mode capabilityThis information field indicates the support of the PS inter-RAT HO to E-UTRAN S1 mode.0PS inter-RAT HO to E-UTRAN S1 mode not supported1PS inter-RAT HO to E-UTRAN S1 mode supportedCSFB capabilityThis information field indicates the support of the CS fallback.0Mobile station does not support CS fallback1Mobile station supports CS fallbackISR support0The mobile station does not support ISR.1The mobile station supports ISR.SRVCC to GERAN/UTRAN capability0SRVCC from UTRAN HSPA or E-UTRAN to GERAN/UTRAN not supported1SRVCC from UTRAN HSPA or E-UTRAN to GERAN/UTRAN supportedEPC capabilityThis information field indicates if the MS supports access to the EPC via access networks other thanGERAN or UTRAN.The network can use this information to decide whether to select a PDN Gateway or aGGSN. The MS shall set the indication to “0” if a SIM is inserted in the MS.0EPC not supported1EPC supportedNF capabilityThis information field indicates if the MS supports the notification procedure.0Mobile station does not support the notification procedure.1Mobile station supports the notification procedure.Selective camping capabilityThis information field indicates whether the MS supports the Selective camping capability which allows theMS to send to the network the UE's usage setting and the Voice domain preference. The use of thisinformation is only for input to selection of camping strategies for the MS. Based on operator policy thenetwork can ignore the Selective camping capability when the UE is registered in a VPLMN.0Selective camping capability not supported1Selective camping capability supportedVideo SRVCC from UTRAN HSPA or E-UTRAN to UTRAN CS capability0 0SRVCC from UTRAN HSPA or E-UTRAN to UTRAN CS not supported0 1SRVCC from UTRAN HSPA or E-UTRAN to UTRAN CS supported with support ofservice change and fallback1 0SRVCC from UTRAN HSPA or E-UTRAN to UTRAN CS supported with enhancednetwork initiated ICM1 1SRVCC from UTRAN HSPA or E-UTRAN to UTRAN CS supported with support ofservice change and fallback and enhanced network initiated ICM

In one embodiment, the eNB112shares the SCUDIF capabilities with the network entity104during the initial attach procedure itself. The network entity104then stores the SCUDIF capabilities in its memory. It can be noted that the eNB112communicates the first and second sets of bearer capabilities and bearer capability elements to the network entity104while communicating a need for performing a vSRVCC handover procedure. Upon receiving the vSRVCC handover request, the network entity110performs a vSRVCC handover procedure to handover the video call session from the packet switched network102to the circuit switched network108based on the vSRVCC capabilities of the UE106(as in step206ofFIG. 2). The process of performing the vSRVCC handover procedure is explained in greater detail with respect toFIG. 3.

FIG. 3is a flowchart300illustrating a method of performing the vSRVCC handover procedure based on the vSRVCC capabilities of the UE106, according to an embodiment of the present invention. When the vSRVCC handover request is received from the network entity104, it is determined whether the UE106supports a network initiated in-call modification and services corresponding to the first set of bearer capabilities and the second set of bearer capabilities based on the vSRVCC capabilities in the vSRVCC handover request, at step302.

If the UE106supports the network initiated in-call modification procedure, then at step304, the network initiated in-call modification procedure for handover of the video call session from the packet switched network to the circuit switched network is performed. In an embodiment of the present invention, an SRVCC handover procedure for establishing a voice call session associated with the video call session is performed. Then, a video component is added to the established voice call session by performing the network initiated in-call modification procedure to complete the voice and video SRVCC handover.

If the UE106does not support the network initiated in-call modification procedure, then it is determined whether the UE106supports a user-initiated service change and fallback and services corresponding to the first set of bearer capabilities and the second set of bearer capabilities based on the vSRVCC capabilities in the vSRVCC handover request, at step306. If the UE106supports user-initiated service change and fallback, then at step308, a request to perform the user-initiated service change and fallback procedure is received from the UE106.

At step310, the user initiated service change and fallback procedure is performed based on the received request. In an embodiment of the present invention, a SRVCC handover procedure for establishing a voice call session associated with the video call session is performed based on the received request. Then, a video component is added to the already established voice call session by performing the user-initiated service change and fallback procedure. If the UE106does not support user-initiated service change and fallback, then at step312, the ongoing voice call associated with the UE106is continued based on the vSRVCC capabilities without adding the video media component to the ongoing voice call.

In accordance with the embodiments described above, the present invention includes OEs that indicate to MME/SGSN104, capability of the UE106with respect to supporting user-initiated and/or network-initiated SCUDIF.

The MME/SGSN104can then later (at the time of the SRVCC handover) pass the relevant information related to the SRVCC for video capability with respect to vSRVCC capabilities through an Sv interface to the MSC110in order to determine the right course of action for the handling of the handed over session.

In order for the MSC110to execute SCUDIF based network initiated in call modification procedure, it needs to know the bearer capabilities BC1and BC2which are provided by the UE preferred service and BC2defines a less preferred service. At call setup the required call type, 3G-324M, is indicated by the originating UE in the SETUP message with the bearer capability IE parameter with other Rate Adaptation set to “11.223 and H.245”. The MSC110converts the elements into the basic services subscribed by the UE106and checks these values against the UE106subscription. Based on the response from a Home Subscriber Server (HSS), the MSC110may either proceed with the call or drop it. For the SRVCC handover procedure, since the UE doesn't send the SETUP message towards the MSC110, the MSC110is unaware of BC1and BC2.

The following methods can be used for resolving this issue:

1. Statically configuring the elements BC1and BC2at the MSC110for vSRVCC capable UEs.a. The elements BC1and BC2will be statically configured at the MSC and the MSC uses these statically configured values during the vSRVCC handover procedures.

2. To be transferred during video SRVCC handover via the MME104a. The eNodeB provides the capability elements BC1and BC2to the MME106in the handover request. The MME104then provides these to the MSC110in the vSRVCC handover request over Sv interface during the SRVCC handover procedure.

3. Using SIP procedures

The UE provides BC1and BC2to the SCC AS as SDP extensions in the SIP INVITE during the session establishment procedures. The SCC AS provides the BC1and BC2information to the MSC110as a part of the session transfer procedure using the provisional responses or subscription to the dialog event package.

When the MSC110receives the Sv request from the MME/SGSN104and the value of the IE is other than 00 (i.e. Video SRVCC is supported), alternative Radio Access Bearer (RAB) parameters IE in the RANAP Relocation Request message indicating the RAB configuration for multimedia in addition to the RAB configuration for speech. The MSC110then decides based on the logic indicated in whether to initiate enhanced network initiated ICM procedures, wait for user-initiated service change and fallback or follow up with “existing” SRVCC procedures.

The embodiments of the present invention have been described with reference to specific example embodiments, and it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the various embodiments. Furthermore, the various devices, modules, selectors, estimators, and the like described herein may be enabled and operated using hardware circuitry, for example, complementary metal oxide semiconductor based logic circuitry, firmware, software and/or any combination of hardware, firmware, and/or software embodied in a machine readable medium. For example, the various electrical structures and methods may be embodied using transistors, logic gates, and electrical circuits, such as application specific integrated circuits.