Content for TS 23.237 Word version: 18.0.0
5 Architecture model and reference points
5.1 Overview
5.2 Reference Architecture for non emergency session
5.3 Functional Entities
5.4 Signalling and bearer paths for IMS Service Continuity
5.5 IUT Collaborative Sessions
5.6 Reference Architecture for SRVCC emergency session
...
...
5 Architecture model and reference points p. 23
5.1 Overview p. 23
IMS Service Continuity provides intra-UE transfers of one or more components of IMS multi media sessions across different Access Networks. When (5G-)SRVCC enhanced with ATCF is used, IMS Service Continuity may be executed in the serving network (visited if roaming) or in the home network. In addition, Service Continuity enables adding, deleting, and transferring media flows of IMS multi-media sessions or transferring whole IMS multi-media sessions across multiple UEs having IMS subscriptions under the same operator.
The UE shall not invoke Inter-UE Transfer procedures while engaged in an emergency call.
5.2 Reference Architecture for non emergency session p. 24
5.2.1 General |R10| p. 24
IMS Service Continuity requires a Service Centralization and Continuity (SCC) AS, which is an Application Server as described in TS 23.228, and a UE with SC capabilities. When (5G-)SRVCC enhanced with ATCF is used, an Access Transfer Control Function (ATCF) and an Access Transfer Gateway (ATGW) may be used in the serving network (visited if roaming). For the support of IMS sessions with CS media, refer to the reference architecture in TS 23.292, clause 5.2; the functions of ICS and SC are specified as optional functions co-located in the SCC AS in this release.
OMA Device Management [7] is used between the SCC AS and the UE for provisioning of operator policy for Access Transfer.
5.2.2 Architecture when using ATCF enhancements |R10| p. 24
Figure 5.2.2-1 provides the reference architecture for SRVCC using the ATCF enhancements (non-emergency session). The Figure only depicts the specific reference points for the ATCF. For other reference points of the general architecture, refer to the reference architecture in TS 23.292, clause 5.2.
Figure 5.2.2-1: IMS Service Centralization and Continuity Reference Architecture when using ATCF enhancements
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
If the MSC Server is not enhanced for ICS, the interface between MSC Server and ATCF is Mw.
If the MSC Server is enhanced for ICS, the interface between MSC Server and ATCF is I2.
If the ATCF is co-located with P-CSCF, the interface between ATCF and ATGW is Iq, according to TS 23.334.
If the ATCF is co-located with IBCF, the interface between ATCF and ATGW is Ix, according to TS 29.162.
For CS to PS SRVCC scenarios, the interface between MSC Server and ATCF is I2.
5.3 Functional Entities p. 25
5.3.1 SCC AS p. 25
The SCC AS provides IMS-based mechanisms for enabling service continuity of multimedia sessions.
For IMS Service Continuity, the SCC AS implements the following functionalities:
-
Access Transfer: The SCC AS uses the ISC reference point towards the S-CSCF for execution of the Access Transfer. The SCC AS performs the following for enablement and execution of Access Transfers:
- analyzes the information required for Access Transfer as described in the procedure clauses and decides which Access Transfer scenario should be executed; it rejects the Access Transfer request if it is not aligned with the operator policy;
- retrieves from the HSS after third party registration the C MSISDN bound to the IMS Private User Identity stored in the user profile in the HSS;
- correlates the Access Transfer request with the anchored session, using information provided in the incoming SIP INVITE;
- correlates the Access Leg created by Access Transfer Update message from the ATCF with the Remote Leg;
-
when third-party register is received (as a result of a UE is registering) and this third-party register is related to a contact address for which SRVCC is provided, clears any existing STN-SR that has been set and provides to the HSS:
- home-network configured STN-SR if a third-party register without a STN-SR is received; or
- STN-SR received in a third-party register different from the existing STN-SR that has been set into HSS;
- when an ATCF is used, provides after successful IMS registration procedure the C-MSISDN and a routable Access Transfer Update - Session Transfer Identifier (ATU-STI) to the ATCF;
- executes the transfer of the IMS session between different access networks;
- implements 3rd party call control (3pcc) upon session establishment;
- provides Access Transfer specific charging data;
- decides based on analysis of the various service continuity related input factors, whether to update provisioned operator policy for Access Transfer;
- generates and updates operator policy by sending operator policy to the UE via OMA DM [7] including the priority between the operator policy and user preferences that could be used also to initiate Access Transfer procedure for ongoing sessions.
- in case it supports vSRVCC it provides information to the MSC related whether the most recently active bi-directional sessions is voice or voice + video to determine if it is should perform vSRVCC or SRVCC procedure.
-
if CS to PS SRVCC is supported and indicated by the MSC Server, the SCC AS provides to MSC Server:
- updated ATCF management URI for the UE's IMS registration when available.
- updated registration status of the UE's IMS registration.
-
Inter-UE Transfer: The SCC AS performs the functions for enablement and execution of Inter-UE Transfer procedures:
- executes the IMS Inter-UE Transfer related procedures between different UEs having IMS subscriptions under the same operator connected via the same or different access networks;
- authorizes requests for IUT procedures;
- when UEs from different subscriptions are involved in a Collaborative Session, assures that UEs do not create subsequent Collaborative Sessions for media belonging to Access Legs of the original Collaborative Session, by adding an indication to the IUT request;
- when aware that a Hosting SCC AS already exists for a Collaborative Session, forwards received IUT requests to that SCC AS;
- provides Inter-UE Transfer specific charging data.
- Terminating Access Domain Selection (T-ADS): In addition to T ADS specified in TS 23.292. For a terminating session, the SCC AS may select more than one contact amongst multiple registered contacts for each selected UE of the SC User and may split the session into sessions directed to the selected contacts. For multiple contacts in the PS domain, the SCC AS shall be able to select one or more types of access networks through which the session shall be terminated. In this case, the SCC AS includes additional information within the session request(s) to ensure that the corresponding session is terminated via the selected access network type(s). For Inter-UE Transfer procedures to a target UE, the SCC AS shall execute T-ADS to select one or more contacts to establish one or more access legs or to reuse one or more access legs belonging to the same Collaborative Session towards the target UE for the transferred media flow(s). T-ADS in SCC AS may be used in order to enforce user preferences between 3GPP and non-3GPP access networks. UE assisted T-ADS (UE T-ADS) may be used in order to enforce user preferences for CS bearer or PS bearer for voice/video on 3GPP accesses.
- Handling of multiple media flows: The SCC AS provides functionality to combine and/or split media flows over one or more Access Networks as needed for Session Transfers, session termination, or upon request by the UE to add media flows over an additional Access Network during the setup of a session, or upon request by the UE to add and/or delete media flows over one or more Access Networks to existing sessions. When handling media flows of an IMS session, the SCC AS takes into account the services associated with the session.
5.3.2 IMS Service Continuity UE p. 26
5.3.2.1 Access Transfer Functions |R9| p. 26
For supporting Access Transfer, the UE provides the following functions:
- Stores and applies operator policy for Access Transfer.
- Initiates Access Transfer procedure based on trigger criteria including the current operator policy, user preferences and the Local Operating Environment Information, providing the necessary details for conducting an Access Transfer operation to the SCC AS.
- Retrieves and stores STI-rSR in conjunction with the IMS registration.
- Provide the network with information of pre-allocated ports and codec information to be used during CS to PS access transfer.
- Stores the E-STN-DR received from IMS (EATF); and
- Triggers session DRVCC procedure as defined in clause 6d.
5.3.2.2 IUT Functions and Roles |R9| p. 27
5.3.2.2.1 Functions p. 27
For supporting Inter-UE Transfer, the UE may provide the following functions:
- Discovers the target UE(s) for Inter-UE Transfer;
- Initiates Inter-UE Transfer procedures based on user input.
- Takes the role of a Controller UE within a Collaborative Session.
5.3.2.2.2 Controller UE Role p. 27
- The Controller UE can initiate the addition of a media flow to a Collaborative Session, on any of the Controllee UEs already involved in the Collaborative Session.
- The Controller UE can initiate the modification of a media flow that is part of a Collaborative Session it controls.
- The Controller UE can initiate the release of a media flow that is part of a Collaborative Session it controls.
- The Controller UE keeps track of all the UEs and about the state of the media flows which are part of a Collaborative Session it controls. That means it remains aware about the media flows that are established, as well as about the media used for those.
- The Controller UE is the one to accept or refuse requests for media additions initiated by the remote party for a Collaborative Session it controls. In case it accepts a remote party initiated media addition, the controller decides on which terminal the media shall be added.
- The Controller UE for a Collaborative Session can initiate Inter-UE Transfer of one or more of the media flows of the Collaborative Session.
- The Controller UE can initiate the release of a Collaborative Session.
- The Controller UE can add into a Collaborative Session it controls a UE not yet involved in this Collaborative Session.
- The Controller UE can initiate the transfer of Collaborative Session Control.
5.3.2.2.3 Controllee UE Role p. 27
Any IMS UE can take the role of a Controllee UE. In this role the Controllee UE can:
- initiate the modification of a media flow which terminates on it.
- initiate the release of a media flow which terminates on it.
-
accept or refuse:
- media modifications initiated by the remote party or by the Controller UE or other Controllee UEs of the same Collaborative Session, for media flow(s) it terminates;
- media additions initiated by the Controller UE or other Controllee UEs of the same Collaborative Session or by a remote party (in the last case, this assumes that the Controller UE has accepted the addition and selected the Controllee UE);
- media transfers initiated by the Controller UE or other Controllee UEs of the same Collaborative Session, for which the Controllee UE is the target.
- initiate IUT Media Control Related Procedures if the Controllee UE is capable of IUT.
5.3.3 Emergency Access Transfer Function (EATF) |R9| p. 28
The Emergency Access Transfer Function (EATF) provides IMS-based mechanisms for enabling service continuity of IMS emergency sessions and eCall over IMS. It is a function in the serving (visited if roaming) IMS network, providing the procedures for IMS emergency session anchoring and PS to CS Access Transfer. The EATF acts as a routing B2BUA which invokes third party call control (3pcc) for enablement of Access Transfer.
When supporting PS to CS DRVCC for IMS emergency, the EATF provides the following functions:
- Generates and sends an E-STN-DR to UE for session continuity procedure toward the CS domain. The E-STN-DR is used by the EATF to correlate two access legs, and is unique for each access transfer function within an EATF.
5.3.4 Access Transfer Control Function (ATCF) |R10| p. 28
5.3.4.1 General p. 28
The Access Transfer Control Function (ATCF) is a function in the serving (visited if roaming) network. When (v)SRVCC enhanced with ATCF is used or when 5G-SRVCC is used, the ATCF is included in the session control plane for the duration of the call before and after Access Transfer.
The ATCF may be co-located with one of the existing functional entities within the serving network (i.e. P-CSCF or IBCF).
The ATCF shall:
-
based on operator policy, decide to:
- allocate a STN-SR;
- include itself for the SIP sessions; and
- instruct the ATGW to anchor the media path for originating and terminating sessions;
- keep track of sessions (either in pre-alerting state, alerting state, active or held) to be able to perform Access Transfer of the selected session;
- perform the Access Transfer and update the ATGW with the new media path for the (CS) access leg, without requiring updating the remote leg;
- after Access Transfer, update the SCC AS that Access Transfer has taken place to ensure that T-ADS has the information on the currently used access;
- handle failure cases during the Access Transfer.
- Provide a STI-rSR (unique to the ATCF) to the UE.
- Handle CS to PS Access Transfer notification and preparation requests from the MSC Server.
5.3.4.2 ATCF inclusion p. 29
The following implementation methods could be used to determine if the ATCF should be including itself during registration:
- If UE is roaming, based on the roaming agreement (e.g., home operator also support (5G-)SRVCC enhanced with ATCF in SCC AS and UDM/HSS).
- Based on local configuration (e.g. if operator always deploys IBCF, MGCF etc. with media anchor for inter-operator calls).
- Based on registered communication service and media capabilities of the UE.
- Based on the access type over which the registration request is sent.
- Based on whether the UE is roaming or not.
- Based on local configuration (e.g., if operator always deploys IBCF, MGCF etc. with media anchor for inter-operator calls).
- Based on the communication service and media capabilities used for the session.
- Based on knowledge of which network the remote party is in.
- Based on the access type over which the request or response is sent.
- Based on the SRVCC capability of the UE.
5.3.5 Access Transfer Gateway (ATGW) |R10| p. 29
The Access Transfer Gateway (ATGW) is controlled by the ATCF and, if (5G-)SRVCC enhanced with ATCF is used, stays in the session media path for the duration of the call and after Access Transfer, based on the local policy of the serving network.
It supports transcoding after SRVCC handover in case the media that was used prior to the handover is not supported by the MSC server.
Depending on placement of the ATCF, different physical nodes may be considered for the ATGW, i.e. IMS-AGW or TrGW.
5.3.6 HSS |R10| p. 29
The HSS shall allow the SCC AS to update the user profile with a new STN-SR. In the case the ATCF is involved, the STN-SR will address the ATCF, otherwise, it will address the SCC AS.
5.3.7 MSC Server |R11| p. 29
The MSC Server enhanced for SRVCC shall not provide announcement or other in-band media for any calls that have been transferred or are in the process of being transferred (e.g. being in active, held or alerting state).
5.4 Signalling and bearer paths for IMS Service Continuity p. 30
5.4.1 General p. 30
The SCC AS is inserted in the signalling path of all the IMS user's sessions; the SCC AS behaves as a SIP-AS as described in TS 23.228 to set up a 3pcc to control the bearer path of the session for enablement and execution of Session Transfer.
5.4.2 Sessions with PS media flow(s) p. 30
Figure 5.4.2-1 shows 3pcc at the SCC AS, for enablement and execution of Session Transfers, when the media flow(s) for the Access Leg is established via IP CAN.
The Figure is for illustration of the 3pcc at the SCC AS and its use for Session Transfer; hence it only shows the signalling and bearer components relevant to the enablement and execution of Session Transfers.
Figure 5.4.2-1: Signalling and bearer paths for sessions with PS media
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
5.4.2a Sessions with PS media flow(s) using ATCF |R10| p. 30
Figure 5.4.2a-1 shows 3pcc at the ATCF and SCC AS, for enablement and execution of Access Transfers, when the media flow(s) for the Access Leg is established via IP-CAN.
The Figure is for illustration of the 3pcc at the ATCF and SCC AS and its use for Access Transfer; hence it only shows the signalling and bearer components relevant to the enablement and execution of Access Transfers.
Figure 5.4.2a-1: Signalling and bearer paths for sessions with PS media using ATCF
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
5.4.3 Sessions with CS media p. 31
For details of signalling and bearer paths when the media for the Access Leg is established via the CS access, see TS 23.292, clause 7.1.1. For illustration of 3pcc at the SCC AS, for enablement and execution of Session Transfers, with use of the Gm reference point, the I1 reference point and when not using Gm or I1 for service control signalling respectively, refer to figures 7.1.1-1, 7.1.1-2 and 7.1.2-1, in TS 23.292, clause 7.1.
5.4.3a Sessions with CS media flow(s) using ATCF |R11| p. 31
Figure 5.4.3a-1 shows 3pcc at the ATCF and SCC AS, for enablement and execution of CS to PS Access Transfers, when the media flow(s) for the Access Leg is established via CS.
The Figure is for illustration of the 3pcc at the ATCF and SCC AS and its use for Access Transfer; hence it only shows the signalling and bearer components relevant to the enablement and execution of Access Transfers.
Figure 5.4.3a-1: Signaling and bearer paths for sessions with CS media using ATCF
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
5.5 IUT Collaborative Sessions |R9| p. 31
IUT for service continuity allows a multi media session to be split on the local end across two or more UEs that are part of a Collaborative Session. UEs that are part of a single Collaborative Session may belong to different IMS subscriptions under the same operator. Figure 5.5-1: provides signalling and bearer architecture for a Collaborative Session that involves three UEs belonging to two IMS subscriptions.
Figure 5.5-1: Collaborative Session Signalling and Bearer architecture
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
The Controller UE (UE A1) provides the control for a Collaborative Session using IMS signalling on an Access Leg between Controller UE A1 and SCC AS-A. The Controller UE may transfer one or more media flow(s) to one or more target UEs (including itself), by using Collaborative Session control (e.g. in the SDP).
Controllee UE A2 and Controllee UE B1 provide the control for the media established on each respective UE using IMS signalling on the Access Leg associated for the media.
SCC AS-A in this Figure is the Hosting SCC AS of the illustrated Collaborative Session. SCC AS-A combines the media descriptions and Collaborative Session Control on the Access Legs and presents one Remote Leg towards the remote end.
SCC AS-B in this Figure relays service requests associated with the illustrated Collaborative Session towards SCC AS-A using standard IMS signalling. In order for SCC AS-B to determine that it shall simply relay service requests towards the Hosting SCC AS rather than execute them, handling of requests is applied as follows:
- if an SCC AS acts as the Hosting SCC AS of a Collaborative Session, it shall include a piece of service interaction information in the SIP signalling messages sent to other SCC-ASs, indicating that the Service Feature "Collaborative Session" has been performed;
- if an SCC AS receives a SIP message containing indication that the Service Feature "Collaborative Session" has been performed, it shall relay all service requests associated with the Collaborative Session towards the SCC AS that has inserted this indication.
5.6 Reference Architecture for SRVCC emergency session |R9| p. 32
To allow SRVCC or DRVCC for IMS emergency session with PS to CS Access Transfer procedures, an EATF is used for emergency sessions anchoring and transferring. For the overall IMS emergency reference architecture with EATF, refer to the reference architecture in TS 23.167.
