WO2011043526A1 - Procédé et système d'ancrage multimédia et de double diffusion de données multimédia - Google Patents

Procédé et système d'ancrage multimédia et de double diffusion de données multimédia Download PDF

Info

Publication number
WO2011043526A1
WO2011043526A1 PCT/KR2010/002621 KR2010002621W WO2011043526A1 WO 2011043526 A1 WO2011043526 A1 WO 2011043526A1 KR 2010002621 W KR2010002621 W KR 2010002621W WO 2011043526 A1 WO2011043526 A1 WO 2011043526A1
Authority
WO
WIPO (PCT)
Prior art keywords
mrfc
message
casting
media data
session
Prior art date
Application number
PCT/KR2010/002621
Other languages
English (en)
Inventor
Arnaud Vedrine
Saso Stojanovski
Original Assignee
Lg Electronics Inc.
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 Lg Electronics Inc. filed Critical Lg Electronics Inc.
Publication of WO2011043526A1 publication Critical patent/WO2011043526A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/16—Discovering, processing access restriction or access information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Definitions

  • the present invention relates to a method and system for media anchoring and bi-casting media data in SRVCC (Single Radio Voice Call Continuity).
  • SRVCC Single Radio Voice Call Continuity
  • SRVCC Single Radio Voice Call Continuity 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.
  • FIG 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.
  • 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.
  • 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).
  • SCC AS Service Centralization and Continuity Application Server
  • 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 anchors the session and uses a 3rd party call control to start the session between the UE-1 and UE-2.
  • 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.
  • 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 decides to trigger an SRVCC handover to UTRAN/GERAN and sends a handover required message to the MME (Mobility Management Entity) 18 (step S3).
  • 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.
  • CS-MGW Circuit Switched - Media Gateway Function
  • 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 (target IP address), i.e., to the CS-MGW 22, instead of sending the voice data to the IP address of the UE-1 (source IP address) 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.
  • 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.
  • 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.
  • the UE-2 can now send its speech data (voice data) to the CS-MGW 22 in the CS domain.
  • step S7a the MSC server 20 sends a SRVCC PS to CS HO response message to the MME 18.
  • 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.
  • step S7c the eNB 16 sends a HO command message to the UE-1, instructing the UE-1 to handover or tune to GERAN.
  • 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.
  • 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.
  • the present invention provides a method and system in which an MRFC/MRFP or an IBCF/TrGW in IMS anchors voice media data in a SRVCC (Single Radio Voice Call Continuity) procedure.
  • the MRFC/MRFP or IBCF/TrGW 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 they are instructed by an AS (e.g., TAS) or IBCF to stop sending the voice data towards the source IP address.
  • an AS e.g., TAS
  • IBCF IBCF
  • the MRFP or TrGW accepts uplink packet data arriving from either the source IP address or the target IP address.
  • the present invention eliminates or significantly reduces any unpredictability and speech interruptions associated with the related art SRVCC procedure in an effective manner.
  • the present invention provides a method for providing a call service in a communication system, the communication system including an SCC AS (Service Centralization and Continuity Application Server), an AS (Application Server), an MRFC (Multimedia Resource Function Controller), an MRFP (Multimedia Resource Function Processor), a first UE (User Equipment) and a second UE, the method performed by the AS and comprising: receiving an invite message for a session from the SCC AS; determining whether or not the MRFC is to be involved for the session upon receipt of the invite message; transmitting an invite message to the MRFC which communicates with the MRFP for establishing the session between the first and second UEs to route media data between the first and second UEs through the MRFP, if the determining step indicates that the MRFC is to be involved; receiving a message from the MRFC in response to the invite message to the MRFC; receiving a message indicating that a bi-casting of the media data is needed for the session, from the SCC AS
  • the present invention provides an Application Server (AS) device for providing a call service in a communication system, the communication system including a SCC AS, the AS, a MRFC, a MRFP, a first UE and a second UE, the AS device comprising: a processor configured to perform the steps of: receiving an invite message for a session from the SCC AS; determining whether or not the MRFC is to be involved for the session upon receipt of the invite message; transmitting an invite message to the MRFC which communicates with the MRFP for establishing the session between the first and second UEs to route media data between the first and second UEs through the MRFP, if the determining step indicates that the MRFC is to be involved; receiving a message from the MRFC in response to the invite message to the MRFC; receiving a message indicating that a bi-casting of the media data is needed for the session, from the SCC AS; performing either a transmission of a message to the MRFC for requesting the bi-cast
  • AS Application
  • FIG. 1 is a diagram of a communication system for illustrating a Single Radio Voice Call Continuity (SRVCC) procedure according to a related art
  • Figures 2 is diagrams of a communication system for illustrating a SRVCC procedure according to an embodiment of the present invention
  • Figure 4 is a flow diagram illustrating a method of anchoring media data in a mobile originated multimedia session according to an embodiment of the present invention
  • Figure 5 is a flow diagram illustrating a method of anchoring media data in a mobile terminated multimedia session according to an embodiment of the present invention
  • Figure 6 is a flow diagram illustrating a part of a SRVCC procedure according to an embodiment of the present invention.
  • Figures 7 and 8 are flow diagrams illustrating a method of bi-casting media data in a SRVCC procedure according to an embodiment of the present invention.
  • an application server is involved in the signalling path between a SCC AS (Service Centralization and Continuity Application Server) and the remote end such as the UE-2.
  • SCC AS Service Centralization and Continuity Application Server
  • An example of the AS is a MMTel (Multimedia Telephony Service) AS or a Telephony Application Server (TAS).
  • the AS e.g., TAS or MMTel AS
  • the AS checks operator policies and information included in the received INVITE message, and thereby determines whether or not the called user has the same home operator as the calling user. If both UEs belong to the same operator, then the AS decides to involve an MRFC/MRFP (Multimedia Resource Function Controller / Multimedia Resource Function Processor) in IMS (IP Multimedia Subsystem) in the call for the purpose of anchoring it.
  • MRFC/MRFP Multimedia Resource Function Controller / Multimedia Resource Function Processor
  • IMS IP Multimedia Subsystem
  • the AS decides to not get the MRFC/MRFP involved and forwards the INVITE towards the aforementioned network node/entity, so that it can anchor the media (in the case of an IBCF, a TrGW (Translation Gateway) is inserted by the IBCF in the media path between the UE-1 and UE-2).
  • IBCF Interconnect Border Control Function
  • TrGW Translation Gateway
  • the SCC AS When a SRVCC (Single Radio Voice Call Continuity) procedure starts and the SCC AS initiates the remote access update, the SCC AS indicates in a message sent towards the remote end that bi-casting of media data (preferably voice data only) is desirable for a certain time duration.
  • This indication included in the message may be referred to herein as ‘bi-casting desirable’ indication.
  • this indication can be called something else, and can indicate a need, desire, or requirement for the bi-casting of the media data, according to the system set up or need.
  • the AS When the AS receives the message including the ‘bi-casting desirable’ indication from the SCC AS and if the AS has involved the MRFC/MRFP at the call setup, the AS asks the MRFC/MRFP to start the bi-casting. However, if the AS has not involved the MRFC/MRFP at the call setup, the AS forwards the ‘bi-casting desirable’ indication towards the remote end (e.g., to the IBCF), which in turn controls a media processing entity (e.g. the TrGW in the case of the IBCF) to start the bi-casting based on the indication.
  • the AS when making a decision to bi-cast the call, the AS can also use policies locally configured in the node instead of/together with the ‘bi-casting desirable’ indication sent by the SCC AS.
  • the bi-casting of the media data involves duplicating the media data and sending the same media data towards both the source IP address (e.g., IP address of the UE-1) and the target IP address (e.g., IP address of the CS-MGW) at the same time.
  • the source IP address e.g., IP address of the UE-1
  • the target IP address e.g., IP address of the CS-MGW
  • the MRFP, theTrGW, or another media processing entity sends the media data from one UE to the source IP address (which preferably may be the address information allocated to the other UE while on the source PS access and which is used prior to the handover) and also sends the same media data from one UE to the target IP address (which preferably may be the address information of the CS-MGW (Circuit Switched - Media Gateway Function) in the CS domain).
  • the source IP address which preferably may be the address information allocated to the other UE while on the source PS access and which is used prior to the handover
  • the target IP address which preferably may be the address information of the CS-MGW (Circuit Switched - Media Gateway Function) in the CS domain.
  • the node performing the bi-casting is also accepting all uplink packets that are arriving from either of the source IP address (IP address of the source access) or the target IP address (IP address of the target access). That is, during the duration of the bi-casting performed by the MRFP, theTrGW or another media processing entity in the SRVCC procedure, the MRFP or TrGW accepts voice data (uplink data) arriving from either of the source IP address or the target IP address.
  • 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’.
  • selective anchoring anchoring of only the voice data
  • the present invention fully covers anchoring of all media data including voice data and non-voice data, if desired.
  • 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,the TrGW or another media processing entity. 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 home network for anchoring and then back to the visited network.
  • the AS can instruct the media processing entity that is bi-casting (the MRFP, the TrGW or another entity) to stop the bi-casting (i.e., to stop sending the voice data to the source IP address) or the media processing entity may stop the bi-casting after a certain time duration, so that it sends the voice data only to the target IP address (e.g., the one of the CS-MGW). This minimizes a waste of radio resources once the PS-to-CS handover is completed.
  • 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, MRFP, IBCF, TrGW, etc.
  • 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.
  • 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 one or more UEs and a server (voice mail, interworking entity to the fixed network or another SIP network, etc.).
  • the SCC AS and the AS can reside in one entity, in which case communication between these components can be internal communications. For instance, such these communications may not be SIP (Session Initiation Protocol) signals.
  • the SCC AS, the AS and the MRFC may reside in one entity, in which case communications between these components may be internal communications. For instance, such communications may not be SIP Session Initiation Protocol) signals.
  • the term ‘bi-casting’ of media data in the present invention covers both directions, i.e., receiving and transmitting contents, for each of the MRFP and TrGW.
  • the MRFP may make a copy of the content (e.g., voice data) sent from a content-sending UE (e.g., UE-2) and bi-cast the content to a receiving UE (e.g., UE-1) over the first network (one copy) and the second network (one copy), and may receive contents of a UE from either or both of the paths via the first and second networks.
  • FIG. 2 is diagrams of a communication system 100 for illustrating a Single Radio Voice Call Continuity (SRVCC) procedure according to an embodiment of the present invention.
  • SSVCC Single Radio Voice Call Continuity
  • 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.
  • SCC AS Service Centralization and Continuity Application Server
  • P-CSCF Proxy - Call Session Control Function
  • S-CSCF Server - Call Session Control Function
  • eNB E-Utran Node B
  • MME Mobility Management Entity
  • 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 an AS (Application Server) 50, a MRFC (Multimedia Resource Function Controller) 30 and a MRFP (Multimedia Resource Function Processor) 40, which are components of the PS network/IMS.
  • AS 50 Application Server
  • MRFC Multimedia Resource Function Controller
  • MRFP Multimedia Resource Function Processor
  • AS 50 Application Server
  • MMTel Multimedia Telephony Service
  • TAS Telephony Application Server
  • the MMTel AS is an application server in IMS, which offers converged, fixed and mobile real-time multimedia communication using the media capabilities such as voice, real-time video, text, file transfer and sharing of pictures, audio and video clips, etc.
  • the TAS is an application server for controlling telephony services in a communication system.
  • 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.).
  • the communication system 100 of Figure 2 can further include an IBCF (Interconnect Border Control Function) 60 and a TrGW (Translation Gateway) 70.
  • the IBCF 60 controls operations when two networks or operators are involved.
  • the TrGW 70 is a gateway used in IMS, which provides translation of IPv4/IPv6 address and port numbers, as well as translation of IPv4 and IPv6 protocols. These are known nodes found at administrative interfaces between two domains/networks.
  • the IBCF 60 and TrGW 70 are used to provide interface functions between these operators/networks/domains.
  • the operations performed by the MRFC 30 and MRFP 40 can be performed by the IBCF 60 and TrGW 70, respectively, when the AS 50 determines that two or more operators/networks are involved in the current call session.
  • the AS 50 can include a storage, a timer 11 ( Figures 7 and 8), and a controller/processor/programs for controlling the timer 11 and implementing the operations of the AS 50.
  • the invention utilizes the existing components of the communication system to perform new functions/operations to provide an enhanced SRVCC procedure.
  • the steps of Figures 2 are preferably implemented in the communication system 100 of Figures 2, but can be implemented in other suitable systems.
  • the UE-1 establishes an IMS multimedia session with the UE-2 wherein, based on operator policies and other information, the AS 50 decides whether or not to introduce the MRF (MRFC 30 and MRFP 40) in the signaling path over a PS network (e.g., E-UTRAN) at step S110-1. For instance, if the AS 50 determines that only one operator is involved for the multimedia session, then the AS 50 decides to anchor the call by using the MRF as shown in Figure 2, step S110-1. On the other hand, if the AS 50 determines that two or more operators are involved for the multimedia session, then the AS 50 decides to anchor the call by using the IBCF/TRGW as shown in Figure 2, step S110-2.
  • MRF MRFC 30 and MRFP 40
  • step S100 only voice data of the media data of the call are exchanged between the UE-1 and UE-2 through the MRFP 40 or TrGW 70 (depending on which entity anchors the call), while the remainder of the media data of the call is exchanged between the UE-1 and UE-2 directly according to known techniques.
  • any voice data sent from the UE-1 is now received by the MRFP 40 or TrGW 70 which in turn sends the received voice data to the UE-2.
  • any voice data sent from the UE-2 towards the UE-1 passes through the MRFP 40 or TrGW 70.
  • 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 decides to trigger an SRVCC handover to UTRAN/GERAN and sends a Handover Required message to the MME 18, at step S130.
  • 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 Handover, 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 6.
  • steps S160a, S160b (S160b-1 or S160b-2) and S160c (S160c-1 or S160c-2) occur first before steps S170a, S170b and S170c are performed.
  • the MSC server 20 initiates the session transfer (access transfer) by sending a message to the SCC AS 10 via the S-CSCF 14, and then the SCC AS 10 sends a request to update the remote leg to the AS 50.
  • This request includes a bi-casting desirable indication.
  • the AS 50 recognizes that the bi-casting of the voice data is needed based on the received request, and determines that the MRFC/MRFP is involved in the anchoring of the call.
  • the AS 50 instructs the MRFC 30 to bi-cast the voice data and the MRFC 30 controls the MRFP 40 to start the bi-casting of the voice data at step S160c-1.
  • step S160a if the AS 50 determines that the MRFC/MRFP is not involved in the anchoring of the call, the AS 50 forwards an indication indicating that a bi-casting of media data is needed, to the IBCF 60 at step S160b-2 of Figure 2. Then the IBCF 60 controls the TrGW 70 to start the bi-casting of the voice data at step S160c-2.
  • 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 (in the case of Figure 2) or the TrGW (in the case of Figure 2) has already been introduced between the UE-1 and UE-2 at step S100.
  • 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.
  • the MSC server 20 sends a SRVCC PS to CS HO response message to the MME 18.
  • 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.
  • 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 Figures 7 and 8.
  • the AS 50 instructs the MRFC 30 (in the case of Figure 2) or the IBCF 60 (in the case of Figure 2) to stop the transmission of the voice data to the source IP address, which in turn instructs the MRFP 40 or the TrGW 70 to carry it out.
  • the bi-casting may be stopped after a preset time expires. Once the bi-casting stops, the voice data is transmitted to the target IP address (the one of the CS-MGW), and not to the source IP address. The details on stopping/controlling the bi-casting of the voice data will be discussed later referring to Figures 7 and 8.
  • the invention allows the AS 50 to selectively anchor (voice data only) using the MRFC/MRFP or IBCF/TrGW in a SRVCC procedure and allows the MRFP or TrGW 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.
  • Figures 3-7 are preferably implemented in the communication system 100 of Figures 2, but can be implemented in other suitable systems.
  • the TAS 50 as an example of the AS 50 is discussed, but the AS 50 can be other type.
  • Figures 3 and 4 are flow diagrams illustrating the details of step S100 including steps S110-1 (Alternative #1) and S110-2 (Alternative #2) of Figures 2 according to an embodiment of the invention.
  • Figure 4 illustrates a scenario where the call is an originating call, i.e., the UE-1 places a call to the UE-2
  • Figure 5 illustrates a scenario where the call is a terminating call, i.e., the UE-1 receives a call from the UE-2.
  • Step S110-1 in Figure 2 and step S110-2 in Figure 2 can correspond respectively to steps S8a and S9a of Figure 4.
  • 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, e.g., IP address of the UE-1 (IP address of the source access).
  • SDP Session Description Protocol
  • 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.
  • the SCC AS 10 anchors the session and decides not to involve the MRFC 30 for anchoring the media data and the session. That decision could be made based on various information, e.g. operator policies, content of a Request-URI, etc. As a variation, the SCC AS 10 may defer this decision to the TAS 50.
  • the SCC AS 10 issues an INVITE message to the S-CSCF 14 towards the remote end.
  • the INVITE message includes the SDP UE-1.
  • the service logic with iFC in the S-CSCF 14 causes the INVITE message to be forwarded to the TAS 50.
  • the TAS 50 makes a determination whether or not the session is to be anchored by the MRFC/MRFP.
  • Alternative #1 below discusses the steps performed when the TAS 50 determines to use the MRFC/MRFP to anchor the session, whereas Alternative #2 below discusses the steps performed when the TAS 50 determines not to use the MRFC/MRFP to anchor the session.
  • the TAS 50 decides that the TAS 50 needs to anchor the session and the media data (i.e., voice data) using the MRFC/MRFP 30/40 based on the operator policy information, the contents of the received INVITE message, etc. As mentioned, this decision can be made based on, e.g., operator policies, content of the Request-URI or other information in the INVITE message, etc. For instance, if the TAS 50 determines that only one operator is involved in the session/call, then the TAS 50 determines to anchor the voice data using the MRFC/MRFP. The TAS 50 can determine whether or not only one operator is involved in the call by looking at the calling party information included in the received INVITE message or obtained in some other manner.
  • the TAS 50 decides that the MRFP/MRFC can be involved in anchoring the call/session.
  • the session anchoring (including anchoring of the voice data) is performed by the TAS 50 in the MRF (MRFC 30 and MRFP 40).
  • the TAS 50 may send an INVITE message to the MRFC 30, instructing the MRFC 30 to allocate MRFP resources for anchoring the voice component of the call.
  • This INVITE message can indicate to the MRFC 30 that the voice data of the call session should be anchored.
  • preferably only the voice component of the media data is anchored by the MRF.
  • all or a selected part of the media data indicated by the UE-1 can be routed through the MRF for anchoring.
  • the MRFC 30 then may use H.248 signalling protocols or other known 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.
  • the MRFC 30 may send a 183 Session Progress message to the TAS 50, which may include the media flow description for the voice component at the MRFP 40 (which is referred to as ‘SDP MRFP for the voice component’ in Figure 4).
  • the TAS 50 sends an INVITE message, of which the SDP is built on the SDP received from the UE-1 in step S7, and on information received from the MRFC 30 in step S8b, to the S-CSCF 14.
  • This INVITE message includes the SDP MRFP for the voice component combined with the remainder of the SDP UE-1 for the non-voice components, and is forwarded to the remote party (UE-2) by the S-CSCF 14.
  • 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.
  • the TAS 50 decides not to anchor the session using the MRFC/MRFP.
  • the basis of that decision is that the call is destined to a UE belonging to another operator/domain, and that the signalling will therefore go through another node such as the IBCF, which then can be used as an anchor in the present SRVCC handover.
  • this decision can be made based on, e.g., operator policies, content of the Request-URI or other information in the INVITE message, etc. For instance, if the TAS 50 determines that more than one operator is involved in the session/call (i.e.
  • the TAS 50 determines to anchor the voice data using the IBCF (or another node).
  • the TAS 50 can determine whether or not only one operator is involved in the call by looking at the calling party information included in the received INVITE message or obtained in some other manner. If the domain information in the calling party information is different from the domain information of the TAS 50 itself, then this indicates that there is not one domain/operator involved in the call/session, but there are two (or more) operators involved in the call. As a result, the TAS 50 decides that the MRFP/MRFC may not be involved in anchoring the call/session, and decides that another node such as the IBCF can anchor the session/call instead.
  • the TAS 50 then sends an INVITE message, of which the SDP is built on the SDP received from the UE-1 in step S7.
  • That INVITE message includes the SDP UE-1 information and instructions to allocate resources for anchoring the voice component of the call, and is routed to the IBCF 60 by the S-CSCF 14.
  • the IBCF 60 anchors the session and involves the TrGW 70 for anchoring the voice data.
  • the TrGW 70 may be similar to step S8b.
  • the IBCF 60 then may use H.248 signalling or other protocols to request the TrGW 70 to set up the proper resources for that call.
  • the TrGW 70 may send a message to the IBCF 60, which may include the media flow description for the voice component at the TrGW 70 (which is referred to as ‘SDP TrGW' in the figure).
  • the IBCF 60 sends an INVITE message towards the remote party (UE-2).
  • the SDP included in that INVITE message contains the information related to the TrGW 70 (e.g., ‘SDP TrGW’) as configured in step S9d.
  • This INVITE message may include the SDP TrGW for the voice component combined with the remainder of the SDP UE-1 for the non-voice components.
  • Step S9f the session setup is completed.
  • Step S9f may be similar to step S8e.
  • the session setup may be completed, including updating the IBCF 60 with the voice component connection information and ports about the UE-1, and informing the local end the connection information and ports about the TrGW 70 (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).
  • the voice media data between the UE-1 and UE-2 are exchanged through the TrGW 70 over the PS network, while the non-voice media data between the UE-1 and UE-2 are exchanged directly over the PS network.
  • Step S110-1 in Figure 2 and step S110-2 in Figure 2 can correspond respectively to steps S14a and S15a of Figure 5.
  • the UE-2 (remote party) initiates an 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 UE-2’).
  • the message is forwarded to the S-CSCF 14 of the UE-1 following normal IMS session set up procedures.
  • the service logic with iFC in the S-CSCF 14 causes the INVITE message including the SDP UE-2 to be forwarded to the TAS 50 for providing call terminating services.
  • the TAS 50 makes a determination whether or not the session is to be anchored by the MRFC/MRFP.
  • Alternative #1 below discusses the steps performed when the TAS 50 determines to use the MRFC/MRFP to anchor the session, whereas Alternative #2 below discusses the steps performed when the TAS 50 determines not to use the MRFC/MRFP to anchor the session.
  • the TAS 50 decides that the TAS 50 needs to anchor the session and the media data (i.e., voice data) using the MRFC/MRFP 30/40. As mentioned, this decision can be made based on, e.g., operator policies, contents of the received INVITE message, Via-header indicating that the INVITE message has not traversed any node in the UE-1’s home network before reaching the TAS 50, etc. For instance, if the TAS 50 determines that the INVITE message has not traversed any node in the UE-1’s home network before reaching the TAS 50 and/or that only one operator is involved in the session/call, then the TAS 50 may decide to anchor the voice data using the MRFC/MRFP.
  • the TAS 50 can determine whether or not only one operator is involved in the call (i.e. that both the calling party and the called party belong to the same operator) by looking at the calling party information included in the received INVITE message or obtained in some other manner. If the domain information in the calling party information is the same as the domain information of the TAS 50 itself, then this indicates that there is only one domain/operator involved in the call/session. By analyzing the various information, the TAS 50 decides that the MRFP/MRFC can be involved in anchoring the call/session, e.g., assume in this example that only one operator is involved in the call.
  • the session anchoring is performed by the TAS 50 in the MRF (MRFC 30 and MRFP 40).
  • Step S14b can be the same as or similar to step 8b.
  • the TAS 50 may send an INVITE message to the MRFC 30, instructing the MRFC 30 to allocate MRFP resources for anchoring the voice component of the call.
  • This INVITE message indicates to the MRFC 30 that the voice data of the call session must be anchored.
  • the voice component of the media data is anchored by the MRF.
  • all or a selected part of the media data indicated by the UE-2 can be routed through the MRF.
  • the MRFC 30 then may use H.248 signalling protocols or other protocols to request the MRFP 40 to set up the proper resources for that call.
  • the MRFC 30 may send a 183 Session Progress message to the TAS 50, which may include the media flow description for the voice component at the MRFP 40 (which is referred to as ‘SDP MRFP for the voice component’ in Figure 5).
  • the TAS 50 sends an INVITE message, of which the SDP is built on the SDP UE-2 received in the INVITE message of step S13, and on the information received from the MRFC 30 in step S14b.
  • This INVITE message includes the SDP MRFP for the voice component combined with the remainder of the SDP UE-2 for the non-voice components, and is sent to the S-CSCF 14 by the TAS 50.
  • the TAS 50 decides not to anchor the session using the MRFC/MRFP.
  • the basis of that decision is that the that the received INVITE message (at step S13) has traversed an IBCF node (or another node) before reaching the TAS 50, which then can be used as an anchor in the present SRVCC handover.
  • this decision can be made based on, e.g., operator policies, contents of the INVITE message, Via-header indicating that the INVITE message has traversed another node in the UE-1’s home network before reaching the TAS 50, etc.
  • the TAS 50 determines that the call is anchored in an IBCF/TrGW.
  • the TAS 50 can determine whether or not only one operator is involved in the call by looking at the calling party information included in the received INVITE message or obtained in some other manner. If the domain information in the calling party information is different from the domain information of the TAS 50 itself, then this indicates that there are two (or more) operators involved in the call. As a result, the TAS 50 decides that the MRFP/MRFC may not be involved in anchoring the call/session.
  • the TAS 50 sends an INVITE message, of which the SDP is built on the SDP UE-2 received in the INVITE message of step S13, to the S-CSCF 14.
  • the service logic with iFC in the S-CSCF 14 causes the received INVITE message (from step S14c or S15b) to be forwarded to the SCC AS 10 for anchoring the sessions to enable a session transfer.
  • the SCC AS 10 anchors the session and decides not to involve the MRFC 30 for anchoring the session. That decision could be based on e.g. operator policies, etc. or can follow the decision of the TAS 50 or an indication from the TAS 50.
  • the SCC AS 10 routes the INVITE message to the UE-1 through the S-CSCF 14.
  • the session setup is completed. Accordingly as shown, the voice media data between the UE-1 and UE-2 are exchanged through the MRFP 40 (in the case of Alternative #1) or the TrGW 70 (in the case of Alternative #2) 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 6 illustrates the details of steps S120 - S150 of Figures 2 according to an embodiment of the invention. As shown in Figure 6, the following steps are performed to initiate a SRVCC PS-to-CS handover procedure.
  • Step S31 the UE-1 sends measurement reports to a network entity in E-UTRAN, e.g., the eNB 16.
  • Step S31 can correspond to step S120 of Figures 2.
  • Step S32 based on the UE measurement reports the eNB 16 decides to trigger an SRVCC handover to, e.g., GERAN or another CS access.
  • 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 S32 and S33 can correspond to step S130 of Figures 2.
  • 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.
  • 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 S34 and S35 can correspond to step S140 of Figures 2.
  • 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.
  • the target MSC 24 may be part of the MSC server 20.
  • the target MSC 24 performs resource allocation with the BSS 21 by exchanging Handover Request / Acknowledge messages.
  • the target MSC 24 sends a Prepare Handover Response message to the MSC server 20.
  • step S39 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 S36-S39 can correspond to step S150 of Figures 2.
  • Figures 7 and 8 illustrate the details of steps S160a - S170c of Figures 2 according to an embodiment of the invention.
  • the method in Figure 7 is continued in Figure 8 in that after the end of Figure 7, the method continues at the beginning of Figure 7.
  • the following steps are performed to control the start and end of the bi-casting of voice data towards the source IP address (e.g., IP address of the UE-1) and the target IP address (e.g., IP address of the CS-MGW 22) by the MRFP 40 (Alternative #1) or the TrGW 70 (Alternative #2).
  • the MSC server 20 transmits 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 MSC server 20 sends the INVITE message to IMS intermediate nodes 23 (such as an IBCF or an I-CSCF).
  • 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).
  • SDP-MGW SDP-MGW parameter
  • the MSC server 20 enhanced for the SRVCC may include a C MSISDN as the calling party number.
  • the INVITE message is routed to the S-CSCF 14 of the UE-1, and the S-CSCF 14 routes the INVITE message to the SCC AS 10.
  • the SCC AS 10 uses the STN-SR included in the received INVITE message to determine that Access Transfer using SRVCC is requested.
  • the SCC AS 10 may retrieve the C MSISDN from the HSS.
  • the SCC AS 10 is able to identify the correct anchored session.
  • the SCC AS 10 sends then a re-INVITE or UPDATE message for updating the remote leg, which includes the SDP of the CS-MGW 22 (‘SDP-MGW’).
  • the SCC AS 10 also includes, in the re-INVITE or UPDATE message, an indication that bi-casting is needed (‘bi-casting desirable’ indication) for a certain period of time for that update.
  • Step S46 the re-INVITE or UPDATE message from the SCC AS 10 is routed to the TAS 50 by the S-CSCF 14 using standard IMS routing procedures.
  • Steps S42-S46 can correspond to step S160a of Figures 2.
  • the TAS 50 makes a determination whether or not the call is anchored in the MRFC/MRFP.
  • Alternative #1 below discusses the bi-casting configuration steps performed when the TAS 50 determines that the call is anchored in the MRFC/MRFP, whereas Alternative #2 below discusses the bi-casting configuration steps performed when the TAS 50 determines that the call is not anchored in the MRFC/MRFP.
  • step S47a upon receiving the ‘bi-casting desirable’ indication in the re-INVITE/UPDATE message from the SCC AS 10 and recognizing that the call has previously been anchored in the MRF, the TAS 50 decides to have the MRF (MRFC/MRFP) bi-cast the voice data for a certain duration of time to avoid loss of speech frames due to the imminent handover.
  • the TAS 50 can start a supervision timer 11 for the bi-casting of the media data at this time, or when the bi-casting actually starts.
  • the supervision timer 11 can be included in the TAS 50 or can be located at another location.
  • Step S47a can correspond to step S160b-1 of Figure 2.
  • the TAS 50 configures the bi-casting of the voice data in the MRFC 30 and the MRFP 40.
  • the MRFC 30 may be able to understand that it should 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.
  • source IP address the IP address of the target access
  • target IP address e.g., IP address of the CS-MGW 22.
  • 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 or substantially the same time.
  • the MRFC 30 interacts with the MRFP 40 using known H.248 signalling protocols or other known protocols to set up the proper resources and topology in the MRFP 40 to perform such bi-casting.
  • the TAS 50 answers to the message (e.g., re-INVITE or UPDATE message) received in step S46 by sending a response message to the S-CSCF 14.
  • This response message may be a 200 OK message including MRFP related information in the SDP answer.
  • this response message may include SDP information about the MRFP 40 (‘SDP-MRFP’).
  • the supervision timer 11 may be started at the start of the bi-casting of the voice data or when the TAS 50 sends this response message to the S-CSCF 14. The timer 11 can be set to expire after a pre-determined time duration.
  • step S47b or S47c or at an appropriate time the MRFP 40, under control of the MRFC 30, starts the bi-casting of the voice data towards the source and target IP addresses, as shown in step S47d.
  • step S46 at steps S48a ⁇ S48c, the TAS 50 determines that the TAS 50 has not anchored the call in the MRF. Thus, the TAS 50 does not apply the ‘bi-casting desirable’ indication received from the SCC AS 10 to itself. Instead, the TAS 50 processes the message and sends a re-INVITE/UPDATE message to the S-CSCF 14 towards the remote end, where this message includes the ‘bi-casting desirable’ indication or similar indication. This message is then routed to the IBCF 60 according to standard IMS routing procedures. Steps S48a-S48c can correspond to step S160b-2 of Figure 2.
  • the IBCF 60 upon receiving the message including the ‘bi-casting desirable’ indication, configures the bi-casting of the voice data in the TrGW 70. This step may be similar to step S47b. For instance, upon receipt of the re-INVITE/UPDATE message, the IBCF 60 may be able to understand that it needs to start bi-casting the media data (voice data) received from the remote party (UE-2) to both the old connection/port (i.e., the 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., the target IP address), e.g., IP address of the CS-MGW 22.
  • the media data voice data
  • UE-2 the remote party
  • the target 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
  • 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 IBCF 60 may interact with the TrGW 70 using known signalling protocols to set up the proper resources and topology in the TrGW 70 to perform such bi-casting.
  • a supervision timer 13 may be started when the bi-casting starts.
  • the timer 13 may be part of the TrGW 70 or may be located at another location. In lieu of the timer 13, if applicable, the timer 11 may be used.
  • the IBCF 60 answers to the message received in step S48c by sending a response message such as a 200 OK message to the S-CSCF 14.
  • This response message includes the ‘SDP-TrGW’.
  • This response message is then routed from the S-CSCF 14 to the TAS 50, which in turn sends the response message to the S-CSCF 14.
  • the bi-casting of the voice data between the UE-1 and UE-2 through the TrGW 70 occurs as shown in step S48h.
  • the S-CSCF 14 routes the received 200 OK message to the MSC server 20 through the SCC AS 10 and the IMS intermediate node(s) 23 using standard IMS routing mechanisms.
  • Steps S47b-S47d (in the case of Alternative #1) along with steps S49-S52 can correspond to step S160c-1 of Figure 2.
  • Steps S48d-S48h (in the case of Alternative #2) along with steps S49-S52 can correspond to step S160c-2 of Figure 2.
  • the MSC server 20 recognizes that the IMS session transfer procedure has been completed, so then the MSC server 20 sends a PS to CS Response message to the MME 18 at step S53a. Then the MME 18 sends a HO command message to the eNB 16 in E-UTRAN and the eNB 16 (or another entity in E-UTRAN) sends a HO command message to instruct the UE-1 to tune to GERAN, at step S53b.
  • Steps S53a and S53b can correspond to steps S170a-S170c of Figures 2.
  • step S53a is performed. This ensures hat certain events associated with the SRVCC procedure occur in a synchronized manner to reduce or eliminate speech interruptions and delays during the SRVCC session.
  • any voice data from the UE-2 is sent to the MRFP 40 or TrGW 70 (depending on which entity is anchoring the session), 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 S47d or S48h.
  • the MRFP 40 or TrGW 70 (depending on which entity is anchoring the session) 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.
  • 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.
  • 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 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.
  • this Re-INVITE is routed to the TAS 50 via the S-CSCF 14 and the SCC AS 10.
  • steps S54a-S54d instead of the Re-INVITE message, any other type of message can be used.
  • the TAS 50 may recognize it to mean that the TAS 50 needs to send a request message to stop the bi-casting of the voice data.
  • step S54e if the TAS 50 has anchored the session in the MRF, and if the TAS 50 has configured the bi-casting for that session due to the reception of the ‘bi-casting desirable’ indication from the SCC AS 10, the TAS 50 detects that the Re-INVITE is an update of the session for whose speech is currently being bi-cast.
  • the TAS 50 uses the Re-INVITE message as a signal to stop the bi-casting of the voice data in the session, if the supervision timer 11 has not yet expired.
  • the TAS 50 therefore interacts with the MRF (MRFP and MRFC) to stop the bi-casting of the voice data, whereby the MRFP 40 stops the bi-casting of the voice data.
  • the MRFC 30 may release the MRFP resources and the MRFP 40 may stop the transmission of the voice data over the source access by using, e.g., H.248 signalling protocols.
  • the MRFC 30 may confirm the release of the session associated with the bi-casting to the TAS 50 by sending a message.
  • the bi-casting of the voice data by the MTFP 40 may be stopped when the supervision timer 11 expires.
  • steps S54f ⁇ S54g if the TAS 50 determines that the MRF is not involved in the bi-casting, then the TAS 50 processes the re-INVITE message and forwards it towards the remote party (UE-2). That message is then routed by the S-CSCF 14 to the IBCF 60.
  • step S54h if the IBCF 60 has configured the bi-casting for that session due to the reception of the ‘bi-casting desirable’ indication from the SCC AS 10 or TAS 50, the IBCF 60 detects that the Re-INVITE is an update of the session for whose speech is currently being bi-cast.
  • the IBCF 60 uses this message as a signal to stop the bi-casting of the voice data, if the supervision timer 13 has not yet expired. Therefore the IBCF 60 interacts with the TrGW 70, which in turn stops the bi-casting. The bi-casting of the voice data by the TrGW 70 may be stopped when the supervision timer 13 (or timer 11) expires.
  • the IBCF 60 processes the re-INVITE message and forwards it towards the remote party (UE-2). Further, the IBCF 60 may send a confirmation message to the TAS 50 in response to the request message to stop the bi-casting.
  • 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).
  • 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).
  • the TAS 50 stops the bi-casting of the voice data by the MRFP 40 at the expiry of the supervision timer 11.
  • the MRFC 30 may release the MRFP resources and the MRFP 40 may stop the transmission of the voice data over the source access by using, e.g., H.248 signalling protocols.
  • the MRFC 30 may confirm the release of the session associated with the bi-casting to the TAS 50 by sending a message.
  • step S55c if the IBCF 60 has configured the bi-casting for that session due to the reception of the ‘bi-casting desirable’ indication from the SCC AS 10 or TAS 50, the IBCF 60 stops the bi-casting by controlling the TrGW 70 at the expiry of the supervision timer 13 (or timer 11). Further, the IBCF 60 may send a confirmation message to the TAS 50 in response to a request to stop the bi-casting.
  • the voice data between the UE-2 and UE-1 are exchanged through the MRFP 40 and the CS-MGW 22 over the CS domain (in the case of Alternative #1) as shown in step S57 or through the TrGW 70 and the CS-MGW 22 over the CS domain (in the case of Alternative #2) as shown in step S58.
  • 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.
  • the first one matches the access leg between the UE-1 on the source access and the SCC AS
  • the second one matches the access leg between the MSC server and the SCC AS.
  • the SIP messages are routed directly from the SCC AS to the MRFC.
  • the messages could also be routed through the S-CSCF.
  • the MRFC and the SCC AS could be collapsed in a single node.
  • the invention encompasses applying the same or similar concepts in other handover procedures using a different network component.
  • 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.
  • various types of messages in addition to the specific types discussed above, can be used in the present invention when communicating indications, messages, commands, SDP information, etc. among the components of the communication system of the present invention.

Abstract

Un mode de réalisation de la présente invention concerne un procédé consistant : à déterminer si un contrôleur de fonction de ressources multimédia (MRFC) doit être impliqué dans la session ; à transmettre un message de sollicitation au MRFC qui communique avec un processeur de fonction de ressources multimédia (MRFP), pour établir la session entre le premier et le deuxième équipement utilisateur (UE) pour acheminer des données multimédia entre lesdits premier et deuxième équipements, par l'intermédiaire du MRFP, si l'étape précédente a permis de déterminer que le MRFC devait être impliqué ; à recevoir un message du MRFC en réponse au message de sollicitation qui lui a été envoyé ; à recevoir d'un SCC AS un message indiquant qu'une double diffusion des données multimédia est nécessaire pour cette session ; et à effectuer soit une transmission d'un message au MRFC pour demander la double diffusion des données multimédia soit une retransmission du message indiquant que la double diffusion des données multimédia est nécessaire pour une autre entité, en fonction du résultat de l'évaluation.
PCT/KR2010/002621 2009-10-06 2010-04-27 Procédé et système d'ancrage multimédia et de double diffusion de données multimédia WO2011043526A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US24924109P 2009-10-06 2009-10-06
US61/249,241 2009-10-06
US26108609P 2009-11-13 2009-11-13
US61/261,086 2009-11-13

Publications (1)

Publication Number Publication Date
WO2011043526A1 true WO2011043526A1 (fr) 2011-04-14

Family

ID=43856963

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2010/002621 WO2011043526A1 (fr) 2009-10-06 2010-04-27 Procédé et système d'ancrage multimédia et de double diffusion de données multimédia

Country Status (1)

Country Link
WO (1) WO2011043526A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014077752A1 (fr) * 2012-11-16 2014-05-22 Telefonaktiebolaget L M Ericsson (Publ) Procédé et système permettant un transfert intercellulaire amélioré d'un réseau à commutation de paquets à un réseau à commutation de circuits d'un équipement utilisateur
WO2017101512A1 (fr) * 2015-12-16 2017-06-22 中兴通讯股份有限公司 Procédé et dispositif permettant une continuité d'appel vocal radio avant sonnerie
WO2017127268A1 (fr) * 2016-01-19 2017-07-27 T-Mobile Usa, Inc. Contrôle d'accès à un service de réseau
WO2017211165A1 (fr) * 2016-06-07 2017-12-14 中兴通讯股份有限公司 Serveur multimédia et procédé de service multimédia

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070014281A1 (en) * 2005-06-15 2007-01-18 Azaire Networks Voice call continuity application server between IP-CAN and CS networks
US20080267128A1 (en) * 2007-04-17 2008-10-30 Andrew Jonathan Bennett Handover from E-UTRAN to UTRAN/GERAN CS
US20090141683A1 (en) * 2007-11-30 2009-06-04 Edward Grinshpun Method of best effort handoff to maintain radio bearer and mip session continuity for multi-mode mobile units
US20090207807A1 (en) * 2006-06-14 2009-08-20 Nortel Networks Limited Inter-subsystem transfers

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070014281A1 (en) * 2005-06-15 2007-01-18 Azaire Networks Voice call continuity application server between IP-CAN and CS networks
US20090207807A1 (en) * 2006-06-14 2009-08-20 Nortel Networks Limited Inter-subsystem transfers
US20080267128A1 (en) * 2007-04-17 2008-10-30 Andrew Jonathan Bennett Handover from E-UTRAN to UTRAN/GERAN CS
US20090141683A1 (en) * 2007-11-30 2009-06-04 Edward Grinshpun Method of best effort handoff to maintain radio bearer and mip session continuity for multi-mode mobile units

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014077752A1 (fr) * 2012-11-16 2014-05-22 Telefonaktiebolaget L M Ericsson (Publ) Procédé et système permettant un transfert intercellulaire amélioré d'un réseau à commutation de paquets à un réseau à commutation de circuits d'un équipement utilisateur
EP2920998A4 (fr) * 2012-11-16 2016-06-15 Ericsson Telefon Ab L M Procédé et système permettant un transfert intercellulaire amélioré d'un réseau à commutation de paquets à un réseau à commutation de circuits d'un équipement utilisateur
US9622118B2 (en) 2012-11-16 2017-04-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for improved PS to CS handover of a user equipment
WO2017101512A1 (fr) * 2015-12-16 2017-06-22 中兴通讯股份有限公司 Procédé et dispositif permettant une continuité d'appel vocal radio avant sonnerie
CN106888486A (zh) * 2015-12-16 2017-06-23 中兴通讯股份有限公司 振铃前双模单待无线语音呼叫连续性方法和装置
CN106888486B (zh) * 2015-12-16 2021-01-22 中兴通讯股份有限公司 振铃前双模单待无线语音呼叫连续性方法和装置
WO2017127268A1 (fr) * 2016-01-19 2017-07-27 T-Mobile Usa, Inc. Contrôle d'accès à un service de réseau
US10015671B2 (en) 2016-01-19 2018-07-03 T-Mobile Usa, Inc. Network service access control
US10334440B2 (en) 2016-01-19 2019-06-25 T-Mobile Usa, Inc. Network service access control
WO2017211165A1 (fr) * 2016-06-07 2017-12-14 中兴通讯股份有限公司 Serveur multimédia et procédé de service multimédia
CN107483518A (zh) * 2016-06-07 2017-12-15 中兴通讯股份有限公司 一种媒体服务器及媒体服务方法
CN107483518B (zh) * 2016-06-07 2022-08-02 中兴通讯股份有限公司 一种媒体服务器及媒体服务方法

Similar Documents

Publication Publication Date Title
US7640036B2 (en) Method for performing inter-system handovers in a mobile communication system
US7450565B2 (en) Conversational bearer negotiation
US8948127B2 (en) Method, apparatus and computer program for supporting a session identifier in case of a transfer between different radio access networks
EP3096584B1 (fr) Optimisation de retard de transfert
KR101078676B1 (ko) 호 전환 방법, 시스템, 및 디바이스
WO2011139045A2 (fr) Améliorations relatives à un transfert intercellulaire
US9025553B2 (en) Capability update in a telecommunications network
US20090036128A1 (en) Method and system for dynamic call anchoring
KR20120024823A (ko) 액세스 네트워크들 사이에서의 세션 전송을 위한 방법들 및 장치
WO2009148173A1 (fr) Système de communications mobiles, dispositif de nœud, et procédé de gestion de la migration entre réseaux
US8547935B2 (en) Method and apparatus for SR-VCC revocation procedure
WO2011043526A1 (fr) Procédé et système d'ancrage multimédia et de double diffusion de données multimédia
CN101242665B (zh) 一种多媒体会话连续性的切换方法
US8072934B2 (en) Method and node of controlling the allocation of transmission resources to wireless terminals within a radio access network
WO2011043527A1 (fr) Procédé et système d'ancrage multimédia et de double diffusion de données multimédia
EP2575320A1 (fr) Système de télécommunications et procédé pour transfert de réseau entre accès
WO2009021549A1 (fr) Commutation de média dans des systèmes de communication mobile
JP5255120B2 (ja) 集中化及び連続性アプリケーションサーバに対するサービス連続性を維持するための方法及び装置
WO2011023054A1 (fr) Procédé et système de synchronisation pour capacité multisession dans le sous-système multimédia ip (ims) de réseau d'infrastructure
WO2012019532A1 (fr) Procédé et système permettant d'ancrer une session

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: 10822171

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: 10822171

Country of ref document: EP

Kind code of ref document: A1