Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.237  Word version:  18.0.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.4…   6…   6.2…   6.2.2…   6.3…   6.3.2…   6.3.2.1.3…   6.3.2.1.7…   6.3.2.1.9…   6.3.2.2…   6.3.2.3…   6.3.2.3.6…   6.3.3…   6.4…   6a…   6a.3…   6a.4…   6a.4.3…   6a.4.5…   6a.4.7…   6a.4a…   6a.5…   6a.6…   6a.7…   6a.8…   6a.9…   6a.10…   6a.11…   6c…   7…   A…   B…   C… 
5 Architecture model and reference points  5.1 Overview  5.2 Reference Architecture for non emergency session  5.2.1 General  5.2.2 Architecture when using ATCF enhancements  5.3 Functional Entities  5.3.1 SCC AS  5.3.2 IMS Service Continuity UE  5.3.2.1 Access Transfer Functions  5.3.2.2 IUT Functions and Roles  5.3.3 Emergency Access Transfer Function (EATF)  5.3.4 Access Transfer Control Function (ATCF)  5.3.5 Access Transfer Gateway (ATGW)  5.3.6 HSS  5.3.7 MSC Server 
...

 

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.
Up

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 clause 5.2 of TS 23.292; 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.
Up

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 clause 5.2 of TS 23.292.
Reproduction of 3GPP TS 23.237, Fig. 5.2.2-1: IMS Service Centralization and Continuity Reference Architecture when using ATCF enhancements
Figure 5.2.2-1: IMS Service Centralization and Continuity Reference Architecture when using ATCF enhancements
Up
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.
Up

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.
Up

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.
When supporting CS to PS SRVCC, the UE provides the following functions:
  • 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.
When supporting PS to CS DRVCC for IMS emergency, the UE provides the following functions:
  • Stores the E-STN-DR received from IMS (EATF); and
  • Triggers session DRVCC procedure as defined in clause 6d.
Up

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.
Any IMS UE can take the role of a Controllee UE.
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.
Up
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.
Up

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.
The EATF performs the session continuity when the Access Transfer request indicated by the E-STN-SR is received.
Up

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.
After access transfer, and based on local policy, the ATCF may remove the ATGW from the media path. This step requires remote end update.
If MSC Server assisted mid-call feature is used, then the SCC AS provides required session state information on pre-alerting, alerting, held and/or conference state for any transferred session.
The ATCF shall not modify the dynamic STI that is exchanged between the UE and SCC AS.
When CS to PS SRVCC is supported, the ATCF shall:
  • 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.
Up

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.
The following implementation methods could be used to determine if the ATCF should anchor the media in the ATGW for an originating or terminating call:
  • 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.
The decision to anchor media at the ATGW, during the session origination or termination, can occur either at receipt of SDP offer or after a round trip of SIP signalling with the remote party depending on the method(s) used for determining whether to anchor media or not.
Up

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).

Up   Top   ToC