WO2011043527A1

WO2011043527A1 - Method and system for media anchoring and bi-casting media data

Info

Publication number: WO2011043527A1
Application number: PCT/KR2010/002623
Authority: WO
Inventors: Arnaud Vedrine; Saso Stojanovski
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2009-10-06
Filing date: 2010-04-27
Publication date: 2011-04-14
Anticipated expiration: 2012-04-06

Abstract

A method and system for providing an improved SRVCC service. According to an embodiment, the method is performed by a SCC AS and includes transmitting an invite message to a MRFC which communicates with a MRFP for establishing a session between first and second UEs to route media data between the first and second UEs through the MRFP over a first network; receiving a message from the MRFC in response to the invite message; receiving an invite message from an entity in a second network for requesting an access transfer for the session from the first network to the second network; transmitting a message to the MRFC for requesting a bi-casting of the media data for the session over the first and second networks; and receiving a response message from the MRFC in response to the message for requesting the bi-casting of the media data.

Description

METHOD AND SYSTEM FOR MEDIA ANCHORING AND BI-CASTING MEDIA DATA

The present invention relates to a method and system for media anchoring and bi-casting media data in SRVCC (Single Radio Voice Call Continuity).

Single Radio Voice Call Continuity (SRVCC) refers to having continuity between IMS (IP Multimedia Subsystem) over PS (Packet Switched) access and CS (Circuit Switched) calls that are anchored in IMS when a mobile terminal or UE (User Equipment) is capable of transmitting and receiving media data on only one of these access networks at a give time. SRVCC has been standardized and provides continuity in a voice call established over IMS when a UE moves from one network such E-UTRAN to another network such as UTRAN/GERAN.

Figure 1 is a diagram of a communication system for illustrating a Single Radio Voice Call Continuity (SRVCC) procedure according to a related art. This procedure is also discussed in a telecommunication standards document, 3GPP TS 23.216, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Single Radio Voice Call Continuity (SRVCC); Stage 2 (Release 9)”, version 9.0.0 (2009-06), which is incorporated by reference.

As shown in Figure 1, a UE-1 has established an IMS multimedia session with a UE-2 (step S1). This involves the UE-1 sending an INVITE message to a SCC AS (Service Centralization and Continuity Application Server) 10 through network entities like a P-CSCF (Proxy - Call Session Control Function) 12 and a S-CSCF (Serving - Call Session Control Function) 14 if the session is an originating session (e.g., call is made from the UE-1). On the other hand, if the session is a terminating session (e.g., call is received by the UE-1), it involves the UE-2 sending an INVITE message to the SCC AS 10 through the P-CSCF 12 and S-CSCF 14 The SCC AS 10 then anchors the session and uses a 3rd party call control to start the session between the UE-1 and UE-2. As a result, a communication path is established between the UE-1 and UE-2 and media data including voice data and non-voice data are exchanged during the session.

Then, at some point, assume that the UE-1 goes out of coverage (e.g., moves to another area). This then causes the UE-1 to send a measurement report to a network entity, eNB (E-Utran Node B) 16 in E-UTRAN (step S2). The eNB 16 then decides to trigger an SRVCC handover to UTRAN/GERAN and sends a handover required message to the MME (Mobility Management Entity) 18 (step S3). Then the MME 18 determines that a PS-to-CS handover is needed for voice/speech data only and sends a SRVCC PS to CS HO (Handover) request message to a MSC (Mobile-services Switching Center) server 20 (step S4). The MSC server 20 is responsible for controlling CS domain calls.

The MSC server 20 communicates with a BSS (Base Station System) 21 in UTRAN/GERAN by exchanging Handover request/response messages, and thereby reserves appropriate radio resources for the SRVCC handover (step S5). The MSC server 20 also reserves resources in a CS network entity, CS-MGW (Circuit Switched - Media Gateway Function) 22.

Once the resources have been allocated, then two major operations need to occur: (1) the MSC server 20 needs to let the UE-2 know that the UE-2 now needs to send any voice data to a new address, i.e., to the CS-MGW 22, instead of sending the voice data to the IP address of the UE-1 as it was doing previously; and (2) the MSC server 20 needs to instruct the UE-1 to complete the PS-to-CS handover, i.e., move to UTRAN or GERAN network. The operation (1) corresponds to steps S6a and S6b and the operation (2) corresponds to steps S7a, S7b and S7c in Figure 1.

More specifically, in step S6a, the MSC server 20 initiates the session/access transfer by sending a message to the SCC AS 10 (IMS entity) via the S-CSCF 14. During this session transfer, in step S6b, the SCC AS 10 communicates with the UE-2 and updates the remote end that the voice data from the UE-2 needs to be sent to a new connection/port that is posted at the CS-MGW 22. This is also discussed in a telecommunication standards document, 3GPP TS 23.237, “3rd Generation Partnership Project; Technical Specification Group Services and Architecture; IP Multimedia Subsystem (IMS) Service Continuity; Stage 2 (Release 9)”, version 9.1.0 (2009-06), which is incorporated by reference herein. As a result, the UE-2 can now send its speech data (voice data) to the CS-MGW 22 in the CS domain.

On the other hand, independent of the operation (1) including the above discussed steps S6a and S6b, the operation (2) including steps S7a, S7b and S7c is performed. In step S7a, the MSC server 20 sends a SRVCC PS to CS HO response message to the MME 18. In step S7b, the MME 18 then sends a HO command message to the eNB 16 in E-UTRAN, where this message includes information about the voice data only. Then in step S7c, the eNB 16 sends a HO command message to the UE-1, instructing the UE-1 to handover or tune to GERAN.

However, because the operation (1) is performed independent of the operation (2) and vice versa, these operations are not synchronized at all in any manner and it is not possible to determine in advance how long each of these operations would take to complete. Generally the operation (1) which is the IMS-level session transfer can take a long time, particularly in cases where the remote side is roaming, and the length of completing the operation (1) can also vary depending on how quickly the application can switch media flows and start sending and receiving voice to and from the CS-MGW 22. Due to this unpredictability and lack of coordination between the operations (1) and (2), users at the UE-1 and UE-2 during the session in the SRVCC procedure experience speech interruptions and delays, which are problematic and are not desirable for the users.

The present invention provides a method and system for selectively anchoring a multimedia session and bi-casting multimedia data, which address the limitations and disadvantages associated with the related art.

According to one aspect, the present invention provides a method and system in which an MRFC/MRFP (Multimedia Resource Function Controller/ Multimedia Resource Function Processor) in IMS anchors voice media data only in a SRVCC (Single Radio Voice Call Continuity) procedure under control of a SCC AS (Service Centralization and Continuity Application Server). The MRFC/MRFP then can bi-cast the voice data towards a source IP address (the one allocated to the UE before the handover procedure) and a target IP address (the one of the MGW which will receive the media from the remote side after the handover), until the SCC AS instructs the MRFP to stop sending the voice data towards the source IP address. Further, during the duration of such bi-casting, the MRFP accepts uplink packet data arriving from either the source IP address or the target IP address. As a result, the present invention eliminates or significantly reduces any unpredictability and speech interruptions associated with the related art SRVCC procedure in an effective manner.

According to another aspect, the present invention provides a method for providing a call service in a communication system, the communication system including a SCC AS, a MRFC, a MRFP, a first UE (User Equipment) and a second UE, the method performed by the SCC AS and comprising: transmitting an invite message to the MRFC which communicates with the MRFP for establishing a session between the first and second UEs to route media data between the first and second UEs through the MRFP over a first network; receiving a message from the MRFC in response to the invite message, the received message including information about the MRFP; receiving an invite message from an entity in a second network for requesting an access transfer for the session from the first network to the second network; transmitting a message to the MRFC for requesting a bi-casting of the media data for the session over the first and second networks; and receiving a response message from the MRFC in response to the message for requesting the bi-casting of the media data.

According to another aspect, the present invention provides a SCC AS device for providing a call service in a communication system, the communication system including the SCC AS device, a MRFC, a MRFP, a first UE and a second UE, the SCC AS device comprising: a processor configured to perform the steps of: transmitting an invite message to the MRFC which communicates with the MRFP for establishing a session between the first and second UEs to route media data between the first and second UEs through the MRFP over a first network; receiving a message from the MRFC in response to the invite message, the received message including information about the MRFP; receiving an invite message from an entity in a second network for requesting an access transfer for the session from the first network to the second network; transmitting a message to the MRFC for requesting a bi-casting of the media data for the session over the first and second networks; and receiving a response message from the MRFC in response to the message for requesting the bi-casting of the media data.

These and other features of the present application will become more readily apparent from the detailed description given hereinafter. However, it should be understood that the detailed description and specific examples, while indicating preferred embodiments of the invention, are given by way of illustration only, since various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art from this detailed description.

The present invention will become more fully understood from the detailed description given hereinbelow and the accompanying drawings which are given by way of illustration only, and thus are not limitative of the present invention and wherein:

Figure 1 is a diagram of a communication system for illustrating a Single Radio Voice Call Continuity (SRVCC) procedure according to a related art;

Figure 2 is a diagram of a communication system for illustrating a SRVCC procedure according to an embodiment of the present invention;

Figure 3 is a flow diagram illustrating a method of anchoring media data by a MRFC/MRFP in a mobile originated multimedia session according to an embodiment of the present invention;

Figure 4 is a flow diagram illustrating a method of anchoring media data by a MRFC/MRFP in a mobile terminated multimedia session according to an embodiment of the present invention;

Figure 5 is a flow diagram illustrating a part of a SRVCC procedure according to an embodiment of the present invention; and

Figure 6 is a flow diagram illustrating a method of bi-casting media data in a SRVCC procedure according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the invention will be described in detail with reference to the attached drawings. The embodiments described below are intended to exemplify the technical spirit of the invention, but are not intended to limit the scope of the invention.

In the present invention, during a multimedia session (e.g., call session) between two UEs or mobile terminals, a SCC AS (Service Centralization and Continuity Application Server) anchors voice data by using an MRFC/MRFP (Multimedia Resource Function Controller / Multimedia Resource Function Processor) in IMS (IP Multimedia Subsystem) in a SRVCC procedure. Although the multimedia session may involve exchanging of media data other than voice data (e.g., video data) between the two UEs, the present invention preferably anchors only the voice data (and not non-voice data) in a SRVCC procedure, which is also referred to herein as ‘selective anchoring’. Such selective anchoring (anchoring of only the voice data) in the SRVCC procedure according to the invention is beneficial because, without it, the voice data exchanges between the UEs in the SRVCC procedures causes voice/speech interruptions, which can significantly hinder voice communications between the users of the UEs. The present invention, however, covers anchoring of all media data including voice data and non-voice data, if desired. In such instances, the benefits of anchoring the non-voice data in a SRVCC procedure may be weighed in against exhausting additional resources to re-route the non-voice data through the MRFP. For instance, if the user at the UE is roaming in a visited network, it may not be necessary to re-route the non-voice media data from the visited network to the MRFP of the home network for anchoring and then back to the visited network.

Further, according to the invention, after anchoring the voice data in the SRVCC procedure, during the on-going multimedia session, the MRFC/MRFP bi-casts the voice data towards a source IP address and a target IP address. As a result, while the handover from the PS domain (e.g., E-UTRAN, etc.) to the CS domain (e.g., UTRAN, GERAN, etc.) takes place, the MRFP sends the voice data from one UE to a source IP address (which was the one allocated to the other UE while on the source PS access and which is used prior to the handover) and also sends the same voice data from one UE to a target IP address (which is the one of the CS-MGW (Circuit Switched - Media Gateway Function) in the CS domain). This guarantees that that the receiving UE would still receive the voice data even during the handover procedure in a timely manner. Further, during the duration of the bi-casting performed by the MRFP in the SRVCC procedure, the MRFP accepts voice data (uplink data) arriving from either of the source IP address or the target IP address.

According to the invention, once the PS-to-CS handover or SRVCC procedure is completed, the SCC AS instructs the MRFP to stop sending the voice data to the source IP address so that the MRFP sends the voice data only to the target IP address (the one of the CS-MGW). This minimizes a waste of radio resources once the PS-to-CS handover is completed. Accordingly, the present invention is extremely beneficially in eliminating or significantly reducing voice interruptions and delays associated with the SRVCC procedure, and offers an improved method of addressing the problems associated with the related art SRVCC procedure using existing network components such as MRFC and MRFP.

Although the invention preferably anchors and bi-casts only the voice data and not necessarily the non-voice data during the multimedia session, the invention encompasses anchoring and bi-casting all media data including voice and non-voice data in a SRVCC procedure as well as other types of handover procedures, if desired. Further, although a session among two UEs is discussed, the invention is fully applicable to a session among three or more UEs, or to a session between a UE and a server (voice mail, interworking entity to the fixed network or another SIP network, etc.). In addition, although specific messages (e.g., INVITE, 200 OK, etc.) are used in the present invention, these are mere examples and other suitable types of messages can be used in the present invention.

Having described the general concepts of the invention, specific examples of the invention will now be described referring to the figures.

Figure 2 is a diagram of a communication system 100 for illustrating a Single Radio Voice Call Continuity (SRVCC) procedure according to an embodiment of the present invention.

As shown in Figure 2, the communication system 100 includes a UE-1 and a UE-2 and various components for implementing a SRVCC according to an embodiment of the invention. These components can include a SCC AS (Service Centralization and Continuity Application Server) 10, a P-CSCF (Proxy - Call Session Control Function) 12, a S-CSCF (Serving - Call Session Control Function) 14, an eNB (E-Utran Node B) 16, a MME (Mobility Management Entity) 18, a MSC (Mobile-services Switching Center) server 20, a BSS (Base Station System) 21, and a CS-MGW (Circuit Switched - Media Gateway Function) 22, which have been described in connection with Figure 1. The P-CSCF 12 is generally the first contact point for the users of IMS. The MSC server 20, the BSS 21 and the CS-MGW 22 are components of the CS network while the SCC AS 10, the P-CSCF 12, the S-CSCF 14, the eNB 16 and the MME 18 are components of the PS network/IMS. The S-CSCF 14 is generally located in the home network and performs session control and registration services for UEs. The SCC AS 10 is an application server for providing a SCC service for UEs in IMS.

The communication system 100 further includes a MRFC (Multimedia Resource Function Controller) 30 and a MRFP (Multimedia Resource Function Processor) 40, which are components of the PS network/IMS. The MRFC 30 generally is used to support bearer related services such as conferencing, announcements to a user or bearer transcoding, etc. and controls the MRFP 40. The MRFP 40 is generally known to provide user-plane resources that are requested and instructed by the MRFC 30 and can provide media stream processing (e.g. audio transcoding, media analysis, etc.).

All the components of the communication system 100 are operatively configured and each of the components can include processor(s), application(s), computer program(s), controller(s), storage unit(s), etc. to carry out the operations discussed herein. For instance, the SCC AS 10 can include a storage, a timer 11 (Figure 6), and a controller/processor/programs for controlling the timer 11 and implementing the operations of the SCC AS 10. Further, all the components of the communication system 100 are known in communication systems and are discussed in various standards documents such as 3GPP TS 23.002, “3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Network Architecture (Release 9)”, version 9.1.0 (2009-09), which is fully incorporated by reference herein. The invention utilizes the existing components of the communication system to perform new functions/operations to provide an enhanced SRVCC procedure. The steps of Figure 2 are preferably implemented in the communication system 100 of Figure 2, but can be implemented in other suitable systems.

As shown in Figure 2, at step S100, the UE-1 establishes an IMS multimedia session with the UE-2 wherein the SCC AS 10 introduces the MRF (MRFC 30 and MRFP 40) in their signaling path over a PS network (e.g., E-UTRAN). In this session, only voice data of the media data of the call are exchanged between the UE-1 and UE-2 through the MRFP 40, while the remainder of the media data of the call is exchanged between the UE-1 and UE-2 directly according to known techniques. As a result, any voice data sent from the UE-1 is now received by the MRFP 40 which in turn sends the received voice data to the UE-2. Likewise, any voice data sent from the UE-2 towards the UE-1 passes through the MRFP 40. The details of step S100 will be discussed later referring to Figures 3 and 4.

Then, at some point, if the UE-1 goes out of coverage, this causes the UE-1 to send a measurement report to the eNB 16 in E-UTRAN, at step S120. The eNB 16 then decides to trigger an SRVCC handover to UTRAN/GERAN and sends a Handover Required message to the MME 18, at step S130. Then the MME 18 determines that a SRVCC PS-to-CS handover is needed for voice/speech data only and sends a SRVCC PS to CS HO (handover) request message to the MSC server 20, at step S140.

The MSC server 20 communicates with the BSS 21 in UTRAN/GERAN by exchanging Hanover request/response messages, and thereby reserves appropriate radio resources for the SRVCC Hanover, at step S150. The MSC server 20 also reserves resources in the CS-MGW 22. Steps S120, S130, S140 and S150 correspond and can be identical or similar to steps S2, S3, S4 and S5 of Figure 1, respectively. The details of steps S120-S150 will be discussed later referring to Figure 5.

Once the resources have been allocated, then steps S160a, S160b and S160c occur first before steps S170a, S170b and S170c are performed. In step S160a, the MSC server 20 initiates the session transfer (access transfer) by sending a message to the SCC AS 10 via the S-CSCF 14. During this session/access transfer, in steps S160b and S160c, the SCC AS 10 requests the MRFC 30 to bi-cast the voice data and then the MRFC 30 controls the MRFP 40 to start the bi-casting. Here the bi-casting of the voice data involves duplicating the voice data, and then sending the same voice data to the IP address of the UE-1 and also to the CS-MGW 22. This is possible since the MRFP 40 has already been introduced between the UE-1 and UE-2 at step S100.

After the bi-casting has started in step S160c, only then steps S170a - S170c are performed wherein the MSC server 20 instructs the UE-1 to complete the handover by moving and tuning to the CS network, e.g., UTRAN/GERAN. In step S170a, the MSC server 20 sends a SRVCC PS to CS HO response message to the MME 18. In step S170b, the MME 18 then sends a HO command message to the eNB 16 (or another entity) in E-UTRAN, where this message includes information about the voice data only. Then in step S170c, the eNB 16 (or another entity in E-UTRAN) sends a HO command message to the UE-1 and thereby instructing the UE-1 to handover or tune to the CS network/domain such as GERAN. The details of steps S160a - S160c and S170a - S170c will be discussed later referring to Figure 6.

Then, after the handover is completed (e.g., once the SCC AS 10 detects that the UE-1 has moved to the CS network), the SCC AS 10 instructs the MRFC 30 to stop the transmission of the voice data to the source IP address, which in turn instructs the MRFP 40 to carry it out. As a result, the voice data is transmitted to the target IP address (the one of the CS-MGW) (i.e., the bi-casting is stopped). The details on stopping/controlling the bi-casting of the voice data will be discussed later referring to Figure 6.

Accordingly, the invention allows the SCC AS 10 to selectively anchor (voice data only) using the MRFC 30 and MRFP 40 in a SRVCC procedure and allows the MRFP 40 to bi-cast the voice data while the SRVCC handover takes place, whereby voice interruptions and delays are minimized and the call experience of the users is significantly enhanced.

Now the steps of Figure 2 will be discussed in more detail referring to Figures 3-6 according to embodiments of the invention. The steps of Figures 3-6 are preferably implemented in the communication system 100 of Figure 2, but can be implemented in other suitable systems.

Particularly, Figures 3 and 4 are flow diagrams illustrating the details of step S100 of Figure 2 according to an embodiment of the invention. Figure 3 illustrates a scenario where the call is an originating call, i.e., the UE-1 places a call to the UE-2, and Figure 4 illustrates a scenario where the call is a terminating call, i.e., the UE-1 receives a call from the UE-2.

For a call originating session, as shown in Figure 3, the following steps are performed to anchor the voice media exchanged between the UE-1 and UE-2 in the MRFP 40, which can correspond to step S100 of Figure 2.

At step S11, the UE-1 initiates a multimedia session with the UE-2 over the PS network by sending an INVITE message. The INVITE message is forwarded to the S-CSCF 14 of the UE-1 following normal IMS session set up procedures. The INVITE message includes SDP (Session Description Protocol) about the UE-1 (‘SDP UE-1’), which describes information about the multimedia session.

At steps S12 and S13, the service logic with iFC in the S-CSCF 14 causes the INVITE message to be forwarded to the SCC AS 10 for anchoring the session to enable a session transfer, e.g., PS-to-CS handover.

At step S14, the SCC AS 10 anchors the session and determines that part of the media data, i.e., the voice component of the SDP UE-1, needs to be routed through the MRFP 40.

At step S15, the SCC AS 10 sends an INVITE message to the MRFC 30, instructing the MRFC 30 to allocate MRFP resources for anchoring the voice component of the call. That is, this INVITE message indicates to the MRFC 30 that the voice data of the call session must be anchored. Here, preferably only the voice component of the media data is anchored by the MRF. However, as an alternative, all or a selected part of the media data indicated by the UE-1 can be routed through the MRF.

At step S16, the MRFC 30 uses H.248 signalling protocols to request the MRFP 40 to set up the proper resources for that call. H.248 signalling is a known process, which is discussed in more detail in a telecommunication standards document, 3GPP TR 29.333, “Multimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp Interface; Stage 3”, version 8.4.1 (2009-03), which is herein incorporated by reference.

At step S17, the MRFC 30 sends a 183 Session Progress message to the SCC AS 10, which includes the media flow description for the voice component at the MRFP 40 (which is referred to as ‘SDP MRFP for voice’ in Figure 3).

At steps S18 and S19, the SCC AS 10 forwards an INVITE message which includes the SDP MRFP for the voice component combined with the remainder of the SDP UE-1 for non-voice components, to the UE-2 (remote party) via the S-CSCF 14.

At step S20, the session setup is completed, including updating the MRFC 30 with the voice component connection information and ports about the UE-1, and informing the local end the connection information and ports about the MRFP 40 (for the voice components of the multimedia session) and the connection information and ports about the UE-1 (for the non-voice components for the multimedia session). Accordingly as shown, the voice media data between the UE-1 and UE-2 are exchanged through the MRFP 40 over the PS network, while the non-voice media data between the UE-1 and UE-2 are exchanged directly over the PS network.

For a terminating call, as shown in Figure 4, the following steps are performed to anchor the MRFP 40 in the signal path between the UE-1 and UE-2 for voice data only, which can correspond to step S100 of Figure 2.

At step S31, the UE-2 (remote party) initiates a voice IMS session with the UE-1 over the PS domain/network by sending an INVITE message including SDP information about the UE-2 (referred to in the figure as ‘SDP remote party’). The message is forwarded to the S-CSCF 14 of the UE-1 following normal IMS session set up procedures.

At steps S32 and S33, the service logic with iFC in the S-CSCF14 causes the message to be forwarded to the SCC AS 10 for anchoring the sessions to enable a session transfer.

At step S34, the SCC AS 10 anchors the session and determines that part of the media data (i.e., voice data) needs to be anchored in the MRFP 40 (the voice component of the ‘SDP remote party’).

At step S35, the SCC AS 10 sends an INVITE message to the MRFC 30, instructing the MRFC 30 to allocate MRFP resources for anchoring the voice component of that session.

At step S36, the MRFC 30 uses known H.248 signalling protocols to request the MRFP 40 to set up the proper resources for that call.

At step S37, the MRFC 30 sends a 183 Session Progress message to the SCC AS 10, which includes the ‘SDP MRFP for voice’ from the MRFP 40 to be sent to the local end.

At steps S38 and S39, the SCC AS 10 combines the SDP MRFP for the voice component with the remainder of the ‘SDP remote party’ for the non-voice component, and forwards an INVITE message including these pieces of information towards the UE-1 via the S-CSCF 14, indicating the connection information and ports allocated by the MRFP 40.

At step S40, the session setup is completed, including updating the MRFC 30 with the connection information and ports of the UE-1. Accordingly as shown, the voice media data between the UE-1 and UE-2 are exchanged through the MRFP 40 over the PS domain, while the non-voice media data between the UE-1 and UE-2 are exchanged directly over the PS domain.

Figure 5 illustrates the details of steps S120 - S150 of Figure 2 according to an embodiment of the invention. As shown in Figure 5, the following steps are performed to initiate a SRVCC PS-to-CS handover procedure.

At step S51, the UE-1 sends measurement reports to a network entity in E-UTRAN, e.g., the eNB 16. Step S51 can correspond to step S120 of Figure 2.

At step S52, based on the UE measurement reports the eNB 16 decides to trigger an SRVCC handover to, e.g., GERAN or another access. At step S53, the eNB 16 sends a Handover Required (SRVCC HO Indication) message to the MME 18. The SRVCC HO message indicates to the MME 18 that target is only CS capable, hence this is a SRVCC handover operation only towards the CS domain. Steps S52 and 53 can correspond to step S130 of Figure 2.

At step S54, based on a QCI associated with the voice bearer (QCI 1) and the SRVCC HO indication, the MME18 splits the voice bearer from the non-voice bearers and initiates the PS-to-CS handover procedure for the voice bearer only towards the MSC server 20. At step S55, the MME 18 sends a SRVCC PS to CS Request (STN-SR) message to the MSC server 20. The MME 18 received the STN-SR (Session Transfer Number for Single Radio) from a HSS (Home Subscriber Server) as part of the subscription profile downloaded during the E UTRAN attach procedure. The HSS is a known network component that functions as main data storage for storing all subscriber and service-related data of IMS. Steps S54 and S55 can correspond to step S140 of Figure 2.

At step S56, the MSC server 20 interworks the PS-CS handover request with a CS inter MSC handover request by sending a Prepare Handover Request message to a target MSC 24. In an example, the target MSC 24 may be part of the MSC server 20. At step S57, the target MSC 24 performs resource allocation with the BSS 21 by exchanging Handover Request / Acknowledge messages. At step S58, the target MSC 24 sends a Prepare Handover Response message to the MSC server 20. At step S59, establishment of circuit connection between the target MSC 24 and the MGW associated with the MSC server 20 e.g. using ISUP IAM and ACM messages, is made. Steps S56-S59 can correspond to step S150 of Figure 2.

Figure 6 illustrates the details of steps S160a - S170c of Figure 2 according to an embodiment of the invention. As shown in Figure 6, the following steps are performed to control the start and end of bi-casting of the voice data towards both the source and target IP addresses by the MRFP 40.

At step S61, the MSC server 20 sends an INVITE message with an STN-SR (Session Transfer Number for Single Radio) indicating the use of SRVCC procedures for Access Transfer to CS access. The INVITE message also includes a SDP-MGW parameter (SDP of the MGW) containing the voice media flow description at the CS-MGW 22 (‘SDP-MGW’ in the figure).

At step S62, the S-CSCF 14 routes the INVITE message to the SCC AS 10. Steps S61 and S62 can correspond to step S160a of Figure 2.

At step S63, the SCC AS 10 uses the STN-SR included in the INVITE message to determine that Access Transfer using SRVCC is requested. The SCC AS 10 is thus able to identify the correct anchored session.

At step S64, the SCC AS 10 sends an INVITE message to the MRFC 30, which includes the SDP-MGW. As a variation, instead of the INVITE message, another message such as a re-INVITE message or an UPDATE message may be used. Steps S63 and S64 can correspond to step S160b of Figure 2.

At step S65, upon receipt of the message from the SCC AS 10 at step S64, the MRFC 30 is able to understand that it shall start bi-casting the media data (voice data) received from the remote party (UE-2) to both the old connection/port (i.e., the IP address of the source access (source IP address), e.g., IP address of the UE-1 allocated while the UE-1 was on the source PS access and which was used prior to the handover) and to the connection/port provided in the message just received (i.e., IP address of the target access (target IP address), e.g., IP address of the CS-MGW 22). As mentioned, bi-casting of the media data includes duplicating the media data and transmitting the same media data to both the source and target IP addresses at the same time. The MRFC 30 interacts with the MRFP 40 using known H.248 signalling protocols to set up the proper resources and topology in the MRFP 40 to perform such bi-casting, and the MRFP 40 starts the bi-casting of the voice data towards the source and target IP addresses.

At step S66, the MRFC 30 answers to the bi-casting request of the SCC AS 10 by sending a response message to the SCC AS 10. This response message includes SDP information about the MRFP 40 (referred to in the figure as ‘SDP-MRFP’). For instance, the MRFC 30 can send a 200 OK message including the SDP-MRFP (e.g., the media flow description at the MRFP 40). The SCC AS 10, which includes a supervision timer 11, starts the timer at the start of the bi-casting of the voice data, e.g., when the SCC AS 10 receives the response message from the MRFC 30. The timer 11 can be set to expire after a pre-determined time duration.

At steps S67 and S68, the SCC AS 10 sends a response message (e.g., 200 OK message) including the SDP-MRFP to the MSC server 20 through the S-CSCF 14. Steps S65-S68 can correspond to step S160c of Figure 2.

At step S69, at the reception of the response message the MSC server 20 recognizes that the IMS session transfer procedure has been completed, so it can send a PS to CS Response message to the MME 18. Step S69 can correspond to step S170a of Figure 2. That is, only after the MSC server 20 receives the response message (e.g., 200 OK) from the SCC AS 10 through steps S66-S68, then step S69 is performed. This ensures that certain events associated with the SRVCC procedure occur in a synchronized manner to reduce or eliminate speech interruptions and delays during the SRVCC session.

At step S70, the MME 18 sends a HO command message to the eNB 16 in E-UTRAN. Step S70 can correspond to step S170b of Figure 2.

At step S71, the eNB 16 (or another entity in E-UTRAN) sends a HO command message to instruct the UE-1 to tune to GERAN. Step S71 can correspond to step S170c of Figure 2.

As a result, during the duration of the SRVCC PS-to-CS handover, any voice data from the UE-2 is sent to the MRFP 40, which in turn bi-casts the voice data to the UE-1 both through the source access over the PS domain (using the source IP address) and through the target access (using the target IP address) over the CS domain, as shown in step S72. During this bi-casting, if the UE-1 sends media data towards the UE-2, then the MRFP 40 can accept such media data arriving from the source IP address or the target IP address and forward them to the UE-2. Due to the bi-casting of the voice data during the handover procedure, even if the UE-1 is transitioning from one network to another, it guarantees that the UE-1 will receive such voice data without much delay or interruption.

Unless desired, non-voice data exchanges in the call session between the UE-1 and UE-2 during the SRVCC PS-to-CS handover need not be affected by the bi-casting and can occur according to known techniques.

Now, once the bi-casting of the voice data is started by the MRFP 40, the SCC AS 10 can stop this bi-casting in two possible ways, which are discussed referring to step S80. More specifically, steps S80a-1 through S80a-6 describe one way (option 1) that the bi-casting may be stopped, and steps S80b-1 through S80b-4 describe another way (option 2) that the bi-casting may be stopped. These are just some examples and there may be other ways.

If a Gm reference point (interface between the CSCF and UE) is retained upon the PS-to-CS handover procedure (which is generally the case if the target access is UTRAN), then steps S80a-1 through S80a-6 may be performed to stop the bi-casting.

More specifically, at step S80a-1, the UE-1 sends a Re-INVITE message to the S-CSCF 14 via the PS access/network to update the remaining non-voice media flows associated with the recently added active session. For instance, once the UE-1 has tuned to the new access network like UTRAN, then the UE-1 may send the Re-INVITE message. If the UE-1 is using ICS capabilities, this Re-INVITE message also adds Gm service control to the active session and the UE-1 subsequently sends Re-INVITEs for any remaining inactive bi-directional speech sessions that are to be transferred.

At step S80a-2, the S-CSCF 14 routes the Re-INVITE message(s) to the SCC AS 10. In steps S80a-1 and S80a-2, instead of the Re-INVITE message, any other type of message can be used. In fact, as long as any message from the UE-1 over the new network (like UTRAN, GERAN, etc.) is received by the SCC AS 10 at this time, the SCC AS 10 recognizes it to mean that the SCC AS 10 needs to send a request message to stop the bi-casting of the voice data.

At step S80a-3, the SCC AS 10 determines that the Re-INVITE message is an update of the session for whose speech is currently being bi-cast. The SCC AS 10 uses this as a signal to stop the bi-casting of the voice data, if the supervision timer 11 in the SCC AS 10 for the bi-casting has not yet expired. Then the SCC AS 10 terminates the session towards the MRFC 30 that corresponds to the source access, e.g., by sending a BYE message.

At step S80a-4, the MRFC 30 releases the MRFP resources and the MRFP 40 stops the transmission of the voice data over the source access by using, e.g., H.248 signalling protocols.

At step S80a-5, the MRFC 30 confirms the release of the session associated with the bi-casting to the SCC AS 10 by sending a message such as a 200 OK message.

At step S80a-6, the SCC AS 10 updates the remote leg if needed.

As a variation, if the Gm reference point is not retained upon the PS-to-CS handover procedure (which is generally the case if the target access is GERAN), then steps S80b-1 through S80b-4 may be performed.

More specifically, at step S80b-1, the SCC AS 10 releases the source access . This can occur according to the procedures as set forth in 3GPP TS 23.237, “3rd Generation Partnership Project; Technical Specification Group Services and Architecture; IP Multimedia Subsystem (IMS) Service Continuity; Stage 2 (Release 9)”, clause 6.3.1.6, version 9.1.0 (2009-06), which was discussed above.

At step S80b-2, when the supervision timer 11 expires, the SCC AS 10 terminates the session towards the MRFC 30 that corresponds to the source access by sending a message such as a BYE message to the MRFC 30.

At step S80b-3, in response, the MRFC 30 releases the MRFP resources and the MRFP 40 stops the transmission of the voice data over the source access, by using, e.g., H.248 signalling protocols.

At step S80b-4, the MRFC 30 confirms the release of the session associated with the source access by sending a message (e.g., a 200 OK message) to the SCC AS 10.

Once the bi-casting of the voice data is stopped (i.e., transmission of the voice data over the source access is stopped while the transmission of the voice data over the target access is continued), the voice data between the UE-2 and UE-1 are exchanged as shown in step S82 through the MRFP 40 and the CS-MGW 22 over the CS domain.

Accordingly, the present invention provides effective ways to improve the SRVCC procedure using the selective anchoring and bi-casting of media data during an IMS multimedia session.

As a variation, in the call flows above, during the time of the SRVCC procedure, there can be one or two SIP dialogs between the SCC AS and the MRFC, from the Stage 3 perspective. In the example of two dialogs, the first one matches the access leg between the UE-1 on the source access and the SCC AS, and the second one matches the access leg between the MSC server and the SCC AS.

In the call flows above, it is assumed that the SIP messages are routed directly from the SCC AS to the MRFC. However, the messages could also be routed through the S-CSCF.

Also, as an implementation option, the MRFC and the SCC AS could be collapsed in a single node.

Even though in the sequences above, only the voice component is anchored by the SCC AS using an MRFC/MRFP, the invention encompasses applying the same or similar concepts in other handover procedures using a different network component. Further, although the session between two UEs has been discussed, the invention is equally applicable to a session among more than two UEs or other devices. The selection of media components to anchor, as well as the types of sessions subject to anchoring of media components could be based on operator policies.

The present invention has been explained with reference to the embodiments which are merely exemplary. It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims

A method for providing a call service in a communication system, the communication system including a SCC AS (Service Centralization and Continuity Application Server), a MRFC (Multimedia Resource Function Controller), a MRFP (Multimedia Resource Function Processor), a first UE (User Equipment) and a second UE, the method performed by the SCC AS and comprising:

transmitting an invite message to the MRFC which communicates with the MRFP for establishing a session between the first and second UEs to route media data between the first and second UEs through the MRFP over a first network;

receiving a message from the MRFC in response to the invite message, the received message including information about the MRFP;

receiving an invite message from an entity in a second network for requesting an access transfer for the session from the first network to the second network;

transmitting a message to the MRFC for requesting a bi-casting of the media data for the session over the first and second networks; and

receiving a response message from the MRFC in response to the message for requesting the bi-casting of the media data.
The method of claim 1, wherein the media data is voice data.
The method of claim 1, wherein the information about the MRFP includes session description protocol (SDP) information associated with the MRFP.
The method of claim 1, wherein the entity in the second network is a MSC (Mobile-services Switching Center) server.
The method of claim 1, wherein the message for requesting the bi-casting of the media data includes session description protocol (SDP) information associated with a MGW (Media Gateway Function) entity in the second network.
The method of claim 1, wherein the first and second networks are a PS network and a CS network, respectively.
The method of claim 1, further comprising:

transmitting a request message to stop the bi-casting of the media data to the MRFC after a predetermined time period has elapsed; and

receiving a confirmation message from the MRFC in response to the request message to stop the bi-casting.
The method of claim 1, further comprising:

receiving a message from the first UE over the second network;

transmitting a request message to stop the bi-casting of the media data to the MRFC in response to the message received from the first UE over the second network; and

receiving a confirmation message from the MRFC in response to the request message to stop the bi-casting.
The method of claim 1, further comprising:

when the response message from the MRFC in response to the message for requesting the bi-casting of the media data is received, starting a timer for controlling a duration of the bi-casting of the media data.
The method of claim 1, wherein the bi-casting of the media data involves transmitting the same media data over the first network and also over the second network at the same time.
A Service Centralization and Continuity Application Server (SCC AS) device for providing a call service in a communication system, the communication system including the SCC AS device, a MRFC (Multimedia Resource Function Controller), a MRFP (Multimedia Resource Function Processor), a first UE (User Equipment) and a second UE, the SCC AS device comprising:

a processor configured to perform the steps of:

transmitting an invite message to the MRFC which communicates with the MRFP for establishing a session between the first and second UEs to route media data between the first and second UEs through the MRFP over a first network;

receiving a message from the MRFC in response to the invite message, the received message including information about the MRFP;

receiving an invite message from an entity in a second network for requesting an access transfer for the session from the first network to the second network;

transmitting a message to the MRFC for requesting a bi-casting of the media data for the session over the first and second networks; and

receiving a response message from the MRFC in response to the message for requesting the bi-casting of the media data.
The SCC AS device of claim 11, wherein the media data is voice data.
The SCC AS device of claim 11, wherein the information about the MRFP includes session description protocol (SDP) information associated with the MRFP.
The SCC AS device of claim 11, wherein the entity in the second network is a MSC (Mobile-services Switching Center) server.
The SCC AS device of claim 11, wherein the message for requesting the bi-casting of the media data includes session description protocol (SDP) information associated with a MGW (Media Gateway Function) entity in the second network.
The SCC AS device of claim 11, wherein the first and second networks are a PS network and a CS network, respectively.
The SCC AS device of claim 11, further comprising:

transmitting a request message to stop the bi-casting of the media data to the MRFC after a predetermined time period has elapsed; and

receiving a confirmation message from the MRFC in response to the request message to stop the bi-casting.
The SCC AS device of claim 11, the processor further configured to perform the steps of:

receiving a message from the first UE over the second network;

transmitting a request message to stop the bi-casting of the media data to the MRFC in response to the message received from the first UE over the second network; and

receiving a confirmation message from the MRFC in response to the request message to stop the bi-casting.
The SCC AS device of claim 11, further comprising:

a timer, and

wherein the processor is further configured to perform the step of:

when the response message from the MRFC in response to the message for requesting the bi-casting of the media data is received, starting the timer for controlling a duration of the bi-casting of the media data.
The SCC AS device of claim 11, wherein the bi-casting of the media data involves transmitting the same media data over the first network and also over the second network at the same time.