WO2011043527A1 - 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
WO2011043527A1
WO2011043527A1 PCT/KR2010/002623 KR2010002623W WO2011043527A1 WO 2011043527 A1 WO2011043527 A1 WO 2011043527A1 KR 2010002623 W KR2010002623 W KR 2010002623W WO 2011043527 A1 WO2011043527 A1 WO 2011043527A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
network
mrfc
casting
media data
Prior art date
Application number
PCT/KR2010/002623
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 WO2011043527A1 publication Critical patent/WO2011043527A1/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/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/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/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • 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

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, 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.
  • 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 (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.
  • a source IP address the one allocated to the UE before the handover procedure
  • a target IP address the one of the MGW which will receive the media from the remote side after the handover
  • the MRFP 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 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • MRFC/MRFP Multimedia Resource Function Controller / Multimedia Resource Function Processor
  • IMS IP Multimedia Subsystem
  • 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 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. 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.
  • the MRFC/MRFP bi-casts the voice data towards a source IP address and a target IP address.
  • the PS domain e.g., E-UTRAN, etc.
  • the CS domain e.g., UTRAN, GERAN, etc.
  • 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).
  • CS-MGW Circuit Switched - Media Gateway Function
  • the MRFP accepts voice data (uplink data) arriving from either of the source IP address or the target IP address.
  • 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).
  • the target IP address the one of the CS-MGW.
  • 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 a UE and a server (voice mail, interworking entity to the fixed network or another SIP network, etc.).
  • specific messages e.g., INVITE, 200 OK, etc.
  • these are mere examples and other suitable types of messages can be used in the present invention.
  • FIG. 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.
  • 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 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.
  • 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.
  • 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.
  • 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).
  • a PS network e.g., E-UTRAN
  • 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.
  • 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.
  • any voice data sent from the UE-2 towards the UE-1 passes through the MRFP 40.
  • 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 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.
  • steps S160a, S160b and S160c 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.
  • 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.
  • 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.
  • 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 Figure 6.
  • 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.
  • 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.
  • 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.
  • Figures 3-6 are preferably implemented in the communication system 100 of Figure 2, but can be implemented in other suitable systems.
  • 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
  • Figure 4 illustrates a scenario where the call is a terminating call, i.e., the UE-1 receives a call from the UE-2.
  • 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.
  • 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 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.
  • 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.
  • 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-1 can be routed through the MRF.
  • 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.
  • 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).
  • 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.
  • 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 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.
  • 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’).
  • SDP remote party SDP information about the 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-CSCF14 causes the message 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 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’).
  • 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.
  • the MRFC 30 uses known H.248 signalling protocols to request the MRFP 40 to set up the proper resources for that call.
  • 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.
  • 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.
  • 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.
  • 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.
  • Step S52 based on the UE measurement reports the eNB 16 decides to trigger an SRVCC handover to, e.g., GERAN or another 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 S52 and 53 can correspond to step S130 of Figure 2.
  • 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.
  • 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.
  • 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 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.
  • 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).
  • 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.
  • 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.
  • the SCC AS 10 sends an INVITE message to the MRFC 30, which includes the SDP-MGW.
  • the INVITE message 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.
  • the MRFC 30 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).
  • source IP address 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.
  • 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.
  • 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’).
  • 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.
  • 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.
  • a response message e.g., 200 OK message
  • Steps S65-S68 can correspond to step S160c of Figure 2.
  • 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.
  • the response message e.g. 200 OK
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • steps S80a-1 through S80a-6 may be performed to stop the bi-casting.
  • 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.
  • the S-CSCF 14 routes the Re-INVITE message(s) to the SCC AS 10.
  • steps S80a-1 and S80a-2 instead of the Re-INVITE message, any other type of message can be used.
  • 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.
  • 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.
  • 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.
  • 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.
  • the SCC AS 10 updates the remote leg if needed.
  • steps S80b-1 through S80b-4 may be performed.
  • 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.
  • IMS IP Multimedia Subsystem
  • 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.
  • 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.
  • 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.
  • a message e.g., a 200 OK message
  • 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.
  • 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.

Landscapes

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

Abstract

L'invention concerne un procédé et un système permettant de fournir un service SRVCC amélioré. Dans un mode de réalisation, le procédé est mis en oeuvre par un SCC AS et consiste : à transmettre un message de sollicitation à un contrôleur de fonction de ressources multimédia (MRFC) qui communique avec un processeur de fonction de ressources multimédia (MRFP) pour établir une session entre un premier et un deuxième équipement utilisateur, pour acheminer des données multimédia entre lesdites premier et deuxième équipements, par l'intermédiaire du MRFP, sur un premier réseau ; à recevoir un message du MRFC en réponse au message de sollicitation qui lui a été envoyé ; à recevoir un message de sollicitation d'une entité se trouvant sur un deuxième réseau, demandant un transfert d'accès du premier au deuxième réseau pour la session ; à transmettre un message au MRFC pour demander une double diffusion des données multimédia pour la session sur les premier et deuxième réseaux ; et à recevoir un message de réponse du MRFC en réponse au message demandant la double diffusion des données multimédia.
PCT/KR2010/002623 2009-10-06 2010-04-27 Procédé et système d'ancrage multimédia et de double diffusion de données multimédia WO2011043527A1 (fr)

Applications Claiming Priority (4)

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

Publications (1)

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

Family

ID=43856964

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2010/002623 WO2011043527A1 (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) WO2011043527A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120307800A1 (en) * 2010-02-12 2012-12-06 Nokia Corporation Enhanced Single Voice Radio Call Continuity Using Packet Data Network Bi-Casting
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
KR101535803B1 (ko) * 2013-10-29 2015-07-10 에스케이텔레콤 주식회사 음성통화 연속성 보장 방법 및 이에 적용되는 서버

Citations (5)

* 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
US20090225725A1 (en) * 2006-11-27 2009-09-10 Huawei Technologies Co., Ltd. System, method, and apparatus for providing multimedia session continuity

Patent Citations (5)

* 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
US20090225725A1 (en) * 2006-11-27 2009-09-10 Huawei Technologies Co., Ltd. System, method, and apparatus for providing multimedia session continuity
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 (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120307800A1 (en) * 2010-02-12 2012-12-06 Nokia Corporation Enhanced Single Voice Radio Call Continuity Using Packet Data Network Bi-Casting
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
KR101535803B1 (ko) * 2013-10-29 2015-07-10 에스케이텔레콤 주식회사 음성통화 연속성 보장 방법 및 이에 적용되는 서버

Similar Documents

Publication Publication Date Title
US8180347B2 (en) Domain transferring method for single radio voice call continuity
US9344920B2 (en) Device and method for performing an rSRVCC procedure
US7746849B2 (en) Providing packet-based multimedia services via a circuit bearer
US7640036B2 (en) Method for performing inter-system handovers in a mobile communication system
KR101022575B1 (ko) 부분 세션 이전 방법 및 이를 위한 단말
WO2011139045A2 (fr) Améliorations relatives à un transfert intercellulaire
US20090147754A1 (en) User equipment, call continuity application server, and network handover method
KR101368708B1 (ko) ＶｏＩＰ 통화의 핸드오버시 인터럽트 시간을 감소시키는 방법 및 장치
WO2011083964A2 (fr) Serveur de centre de commutation mobile
EP2249537B1 (fr) Procédé, équipement utilisateur et serveur de transfert de session multimédia
JP6109928B2 (ja) Ｄｒｖｃｃ携帯端末のアクセス転送
WO2012025007A1 (fr) Procédé et système pour l'obtention d'une capacité d'équipement utilisateur par un équipement utilisateur, un serveur de données d'abonné résidentiel et un élément de réseau central
EP2640030A1 (fr) Mise à jour de capacités dans un réseau de télécommunications
WO2009056059A1 (fr) Procédé, système et dispositif de renvoi automatique d'appel
CA2695394A1 (fr) Procede et systeme pour ancrage d'appel dynamique
TW201220786A (en) Handling a registration timer to provide service continuity in IMS
JP5645329B2 (ja) 回線交換ドメインサービスをパケット交換ドメインにハンドオーバする方法及びシステム
CN101420668A (zh) 一种实现呼叫转移的方法、系统和设备
WO2011043526A1 (fr) Procédé et système d'ancrage multimédia et de double diffusion de données multimédia
WO2011043527A1 (fr) Procédé et système d'ancrage multimédia et de double diffusion de données multimédia
WO2011136569A2 (fr) Améliorations au transfert intercellulaire
WO2013141591A1 (fr) Transmission d'une notification d'alerte personnalisée
WO2009021549A1 (fr) Commutation de média dans des systèmes de communication mobile
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
JP6270343B2 (ja) 移動通信方法、回線交換機及び移動局

Legal Events

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

Ref document number: 10822172

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

Country of ref document: EP

Kind code of ref document: A1