ATCF and EATF Support

Introduction

The main function of SRVCC is to engage the capable UE in a voice call which determines to be moving away from LTE coverage, and it notifies the LTE network. The LTE network determines that the voice call needs to be moved to the legacy circuit domain. It notifies the MSC server of the need to switch the voice call from the packet to the circuit domain and initiates a handover of the LTE voice bearer to the circuit network. The MSC server establishes a bearer path for the mobile in the legacy network and notifies the IMS core that the mobile’s call leg is moving from the packet to the circuit domain. The circuit-packet function in the IMS core then performs the necessary inter-working functions. When the mobile arrives on-channel in the legacy network, it switches its internal voice processing from VoIP to legacy-circuit voice, and the call continues.

To minimize the voice interruption delay during a voice call transition, Access Transfer Control Function (ATCF) and Access Transfer Gateway (ATGW) are deployed.

The SBC sends policy requests to PSX to fetch information on Access Transfer Profile (ATP) and on receipt of PSX policy response, the SBC evaluates the profile and associated inclusion policy to determine whether the co-located ATCF/EATF functionality needs to be executed or not.

The SBC sends policy requests to PSX and as part of policy response PSX returns the following information:

• Access Transfer Profile—SBC evaluates the profile (received from PSX) and associated inclusion policy to determine if the co-located ATCF/EATF functionality needs to be executed or not.
• UE Roaming—PSX informs about the UEs roaming status to the SBC.  
• SRVCC Support—For a roaming user, PSX informs the SBC if the UE home operator supports eSRVCC in its SCC AS.

Access Transfer Control Function (ATCF)

To minimize the voice interruption delay during a voice call transition, 3GPP has specified in Release 10 the SRVCC architecture that includes the ATCF and Access Transfer Gateway (ATGW) are deployed in the VPLMN. An ATCF can be co-located with existing nodes, for example, P-CSCF or Interconnection Border Control Function (IBCF). An existing MGW is used in case of ATGW.

The Access Transfer Control Function (ATCF) in the serving (visited if roaming) network provides the proxy role as well as B2BUA functionality (based on the call flow being processed) as defined in the IMS specifications. When SRVCC is enhanced with ATCF, 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, depending upon operator policy, accomplishes the following:

• Allocate a STN-SR
• Include itself for SIP sessions
• 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 have the information on the currently used access
• Handle failure cases during the Access Transfer

When CS to PS SRVCC is supported, the ATCF accomplishes the following:

• 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

Access Transfer Gateway (ATGW)

The Access Transfer Gateway (ATGW) is controlled by the ATCF and, if SRVCC enhanced with ATCF is used, continues to be in the session media path for the duration of the call and after Access Transfer, based on the local policy of the serving network. ATGW supports transcoding after SRVCC handover in case the media used prior to the handover is not supported by the MSC server. 

ATCF Call Flow Summary

• The UE sends normal REGISTER towards home network through P-CSCF.
• The SBC as P-CSCF does a PSX policy dip.
• The PSX as part of policy response returns the ATCF profile information.
• On receipt of PSX policy response, the SBCas P-CSCF evaluates the ATCF profile and associated inclusion policy to determine whether the co-located ATCF functionality needs to be executed or NOT. 
• The SBC as ATCF inserts a Feature-Caps header field containing the STN-SR allocated to ATCF if it includes itself in the registration path.
• The SCC AS sends the SIP MESSAGE request with SRVCC related information towards the ATCF serving the registered UE.

ATCF Handover Call Flow Summary

• UE sets up an outgoing call with the media of the outgoing call anchored at the ATCF.
• Both ends shall reserve the resources and UE receives a SIP 180 (Ringing) response.
• UE sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS SRVCC handover to CS access.
• The MSC server initiates the session transfer with the STN-SR.
• The UE continues ringing.
• The MSC server sends an initial SIP INVITE request transferring the session with the received STN-SR and populates the INVITE message.
• ATCF determines the transferable session set and provides the role of a B2BUA, and then initiates a new dialog towards the SCC AS (that is, a target access leg) by sending an initial SIP INVITE request. 

• The SIP INVITE is routed towards the SCC AS, based on filter criteria in S-CSCF.
• The SCC AS correlates the initial SIP INVITE request to the local and remote call legs of the existing session between the UE and the remote end.
• The SCC AS performs the Remote Leg update by sending SIP UPDATE request towards the Remote Leg.
• The SCC AS acting as a B2BUA generates a SIP UPDATE request based upon the received initial SIP INVITE request and the information previously stored against this session.

• The intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE.
• Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the remote UE sends a SIP 200 (OK) response.
• The intermediate IM CN subsystem entities forwards the SIP 200 (OK) response to the SCC AS.
• The SCC AS sends a 183 (Session Progress) containing the SDP answer as received from the remote UE.
• The SDP answer indicates that the resources are available.
• The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the ATCF.
• Upon receiving a SIP 180OK  or 200 OK response to the SIP INVITE request due to ATU-STI from the SCC AS, the ATCF generates and send a SIP response to the SIP INVITE request

• The ATCF forwards the 183 (Session Progress) response to the MSC server.
• The MSC acknowledges the receipt of the 183 (Session Progress) response.
• The ATCF forwards the SIP PRACK request to intermediate IM CN subsystem entities.
• The intermediate IM CN subsystem entities forward the SIP PRACK request to the SCC AS.
• The SCC AS acknowledges the PRACK request.
• The intermediate IM CN subsystem entities forward the SIP 200 (OK) reponse to the ATCF.
• The ATCF forwards the SIP 200 (OK) reponse to the MSC server.

• The SCC AS sends a SIP INFO request that indicates that the call is an early dialog and that the SC UE was the initiator.
• The intermediate IM CN subsystem entities forward the SIP INFO request to the ATCF.
• The intermediate IM CN subsystem entities forward the SIP INFO request to the ATCF.
• The MSC server is now aware that the call that is transferred is in originating alerting phase.
• The ATCF forwards the SIP 200 (OK) response to intermediate IM CN subsystem entities.
• The ATCF forwards the SIP 200 (OK) response to the intermediate IM CN subsystem entities.
• The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS.
• The MSC enters Call delivered (N4) state due to the information received in the SIP INFO request.
• The remote UE accepts the call and sends a SIP 200 (OK) response.

• The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to SCC AS.
• The SCC AS sends the SIP 200 (OK) response to indicate that the remote UE has accepted the call.
• The SIP 200 (OK) response is forwarded to the ATCF.
• The SIP 200 (OK) response is forwarded to the ATCF.
• The MSC server indicates to the SC UA A that the remote UE has accepted the call in accordance with 3GPP TS 24.008.

• The MSC server acknowledges the SIP 200 (OK) response received from SCC AS.
• ATCF forwards the SIP ACK request to the intermediate IM CN subsystem entities.
• The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS.
• The SCC AS starts a operator specific timer supervising the release of the original source leg.
• The SCC AS acknowledges the SIP 200 (OK) response received towards the remote UE.
• The SIP ACK request is forwarded towards the remote UE. SC UE acknowledges the CC CONNECT.

• The SCC AS releases the original source leg towards the SC UE after the operator specific timer has expired by means of a SIP 404 (Not Found) response.
• The SIP ACK request is sent to SCC AS.
•  Intermediate IM CN subsystem entities sends a SIP 404 (Not Found) response in order to release to original source dialog towards the SC UE.

• The SIP ACK request is sent to the intermediate IM CN subsystem entities.
• The ATCF releases all media terminations (including termination created due to forking on remote end) of the used for media anchoring during call setup in.
• The ATCF sends a SIP 404 (Not Found) response in order to release to original source dialog towards the SC UE through P-CSCF.

Call Flow For External P-CSCF Co-located with ATCF Summary

This call flow is similar to the the P-CSCF located with the ATCF functionality:

• Access SBC co-located with ATCF is provisioned to perform only ATCF functionality in addition to SBC functionality. And all the functionality related to P-CSCF are disabled (P-CSCF functionality is controlled by individual feature flags which is turned off).
• ATCF adds to path URI as well as feature tags so as to be in the path for UE terminating requests.
• Routing of REGSITER requests from ATCF to P-CSCF are achieved by appropriately provisioning PSX username based routing.

Emergency Access Transfer Function (EATF)

Emergency Access Transfer Function (EATF) provides IMS-based mechanisms for enabling service continuity of IMS emergency sessions. 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) to enable Access Transfer.

EATF performs session continuity when the Access Transfer request indicated by the E-STN-SR is received

EATF Call Flow Summary

• UE sends the SIP INVITE request P-CSCF. P-CSCF forwards the request to E-CSCF. 
• E-CSCF insert URI of the EATF to be contacted into the Route header field as the topmost entry followed by own URI to be used to receive the request from EATF. 
• The EATF (acting as a routing B2BUA) anchors the emergency session, that is, the EATF is inserted in the signalling path which invokes a 3pcc for enablement of Access Transfers.
• The E-CSCF uses the routing information to format the SIP INVITE message, and sends it directly to the PSAP.
• E-CSCF forwards the SIP 200 (OK) response to E-CSCF.
• UE responds to the SIP 200 (OK) response with a SIP ACK request.

EATF Handover Call Flow Summary

• An ongoing IP bearer between the UE and the remote end PSAP is present. The call is anchored at EATF.
• UE sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS SRVCC handover to CS access.
• When an MSC server enhanced for SRVCC using SIP interface receives an indication for a session transfer for an emergency session, the MSC server enhanced for SRVCC using SIP interface initiates a SIP INVITE request and:
  • sets the request URI to the E-STN-SR for the session with speech media component to be transferred;
  • includes the instance-id feature tag with a value based on the IMEI in the Contact header field;
  • sets the P-Asserted-Identity header field to the Correlation MSISDN if one is available; and
  • includes an SDP offer with media which the MSC server wishes to use in the session.

• I-CSCF routes the SIP INVITE request directly to the EATF by using the procedure for PSI based application server termination.
• The EATF based on the content in the Contact header field correlates the SIP INVITE request to the local and remote call legs of the existing session between the UE and the remote end. 
• The EATF performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg.
• When the EATF receives a SIP INVITE request, the EATF acting as a routing B2BUA generates a SIP INVITE request based on the received SIP INVITE request and the information previously stored against this session and routes it towards PSAP through the intermediate IM CN subsystem entities.

• E-CSCF forwards the SIP re-INVITE request to the PSAP.
• Upon receiving the SIP re-INVITE request containing the SDP offer, since the PSAP has all resources available, it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer.
• The SDP answer indicates that the resources are available.
• E-CSCF forwards the SIP 200 (OK) response to the SIP re-INVITE request to the EATF in the originating network.
• The EATF generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to the PSAP. 
• The E- SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) response to the interworking entities.

• The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward the SIP ACK request to the EATF.
• Upon receiving the SIP ACK request from the Target Access Leg, and after an operator specific timer has expired, the EATF releases the source access leg which was using the old IP-CAN by sending a SIP BYE request to the UE.
• Upon receiving the SIP BYE request over the old IP-CAN, the UE sends a SIP 200 (OK) response over the old IP-CAN to the EATF.
• Subsequently, the UE relinquishes all resources pertaining to the old IP-CAN and establishes the CS and IP bearer connection.

PS-to-PS Handover

The Packet-Switched-to-Packet-Switched (PS-to-PS) handover process is optimized in IMS networks to accelerate the handover time, which improves call quality/call drop behavior.

When the User Equipment (UE) engaged in a call roams from a WiFi network to an long term evolution (LTE) network and the other way, the call continues seamlessly across both the networks. This PS-PS handover procedure is described in the  3GPP Specification 24.237. To execute this procedure, the application server (AS) and the UE must support SCC functionality. However, this process can take an unacceptable amount of time to complete due to the following reasons:

• The PS-PS handover procedure is anchored at SCC-AS
• The PS-PS handover procedure involves remote leg updating

 The goal of this optimization is to reduce the time it takes to complete the PS-PS handover under the following conditions:

• The UEs in the customer’s network use an Over-The-Top (OTT) application to make/receive calls. Therefore, the call is not identified as voice call by LTE or WiFi networks; instead, it is identified as a data call.
• Customer is using an IMS core network but does not have application server enhanced with SCC.

VoDC Logical Network Architecture

The UE is connected to IMS core network through A-SBC/P-CSCF both from Wifi access and from LTE access. The client is an Android- or iOS-based application that connects to the IMS core network using SIP. However, the IMS core network and LTE are provided by two different operators. When the UE is connected through LTE access, from LTE network perspective the SIP/VoIP call is more like an OTT application. Therefore, there will be no Rx interactions with PCRF when the call is connected through LTE access. Note that the VMC serves as an AS in this case.

The call flow of the optimized PS-to-PS handover is:

PS-to-PS Handover Call Flow

Assumptions:

• The UE is engaged in a WiFi network
• The UE moves from the WiFi to the LTE access network
• The UE registers with the LTE network
• The UE triggers the handover procedure

The optimized PS-to-PS handover as shown in the figure PS-to-PS Handover Call Flow is described below:

1. When the UE moves from WiFi to LTE access, it sends an INVITE with Request-URI as pstopsSti (where STI represents Session Transfer Identifier) and with Replaces header containing the Call ID, From-tag, and To-tag of the old access call-leg.
2. The SBC/PCSCF identifies the call-leg to be replaced based Replaces header contents and locally responds to INVITE with 200 OK.
3. It also performs media switching towards the new access leg and thus, the media from remote call-leg is switched towards the new access leg. (This assumes that there is no need to inform VMC AS that an access-change-over happened.)

The same call flow is applicable when the UE moves from an LTE to a WiFi network.