SRVCC PS-CS Access Transfer

This section describes various scenarios for transferring sessions between Packet-Switched (PS) and Circuit-Switched (CS) networks, providing details about the following cases:

• Mobile Switching Center (MSC) server-assisted mid-call feature supported by the SCC AS
• Call flows for the MSC server-assisted mid-call feature supported by the SCC AS
• Failure cases
• Confirmed dialog
• Early dialog

For PS-CS transfers in SRVCC, the ATCF performs several actions based on the STN-SR when it first receives the SIP INVITE. First, the ATCF determines the set of transferrable sessions. It defines this set as the SRVCC-transferrable sessions that are associated with a C-MSISDN matching the URI in the P-Asserted-Identity header field in the INVITE. The ATCF compares the INVITE to its set of transferrable sessions to see if the INVITE is part of the set; if so, its responds with 2xx response for the initial INVITE.

Active session transfers require the ATCF to act as a back-to-back user agent (B2BUA) if the session undergoing transfer has media anchored at the ATGW. In this case, the ATCF responds with a 200 OK to the INVITE; the OK carries an SDP answer with ATGW IP address and port information. Then the ATCF updates the following information and sends the INVITE to the remote UE:

• Original SDP offer is replaced with an SDP offer containing media information currently in use with the ATGW IP address and port information.
• The Request-URI with the ATU-SI associated with the session being transferred is inserted.
• The Target-Dialog header field with the dialog identifier of the session being transferred is inserted.

When the ATCF receives an SDP answer and if media is anchored at the ATGW for the session being transferred, the ATCF directs the ATGW to start sending and receiving media to/from the remote UE according to the newly received answer.

If it receives a BYE with a 503 Service Unavailable header on the source access leg, the ATCF retains session state information and ATGW resources associated with the session until either:

• The ATCF receives an INVITE request because of STN-SR, or
• An operator-defined time period elapses. The default value for the operator-defined time period is eight (8) seconds.

Thus, the session remains recognizable for SRVCC transfer for a time. Release of the session is also delayed by the ATCF’s forwarding the BYE to the SCC AS. If the transferrable session cannot progress, the ATCF responds with a 404 Not Found. For transfer cases when only hold or alerting sessions exist and the session in question is an early dialog or a confirmed dialog with inactive media, the ATCF replaces the Request-URI received in the original INVITE with the ATU-STI associated with a session in the transferrable set before forwarding the request; this proxy-role behavior complies with the 3GPP standard.

MSC Server-Assisted Mid-Call Feature Supported by SCC AS

The following scenario assumes an active session between UA1 and UA2, and that UA1 attaches to the CS domain. It is also assumed that the CS-MGW supports the codecs used for LTE voice calls, minimizing the likelihood that the ATCF will need to instruct the ATGW to insert codecs.

Upon receiving the Access Transfer message, the ATCF identifies the correct anchored session and proceeds with the transfer of the most recently active session. Using a Configure ATGW message, the ATCF replaces the existing PS access leg media path information with new CS access leg media path information for the ATGW. However, the ATCF might instruct the ATGW to continue using the local port of the PS access leg media path. Once the ATGW acknowledges the ATCF’s Configure message, the ATCF sends the MSC server an Access Transfer response and the media path is moved to the CS when receiving SDP information.

Voice break interruption starts either when media moves to the CS MGW (controlled by the MSC server enhanced for SRVCC) or when the UE relocates to the target—whichever comes first. When the UE tunes to the target or media switches to the CS MGW (whichever is last), the voice break interruption ends. The assumption is that media is switched to the CS MGW during the time to UE tunes to the target.

After receiving the Access Transfer message, the ATCF re-establishes communication with the SCC AS and updates the SCC AS. When the MSC server supports the mid-call feature, the ATCF also communicates this fact to the SCC AS. The ATU message initiates a new dialog between the ATCF and SCC AS, a dialog the SCC AS associates with the old dialog using the C-MSISDN. This new dialog is necessary because it replaces the old dialog set up over PS access, thereby assuring that if the PS user registration expires the new home leg will not be released or even affected.

The following shows a sample INVITE request the ATCF sends to the S-CSCF. Note the following:

• The Request-URI header contains the ATU-STI, as routed to the SCC AS.
• The Target dialog header specifies the existing dialog is associated with this request.
• The P-Asserted-Identity header reflects the C-MSISDN of the UE being served.
• The From header reflects the C-MSISDN of the serving UE.
• The SDP reflects the media information at the ATGW.

INVITE sip:[e-mail] SIP/2.0 
Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87 
Max-Forwards: 70 
P-Asserted-Identity: <tel:[phone]> 
P-Charging-Vector: icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024";orig-ioi=visit1.net 
Privacy: none 
From: <tel:[phone]>;tag=171828 
To: <tel: [phone]> 
Call-ID: cb03a0s09a2sdfg1kj490334 
Cseq: 127 INVITE 
Supported: 100re1, precondition, gruu 
Target-Dialog: me03a0s09a2sdfgjk1491777; to-tag=774321; from-tag=64727891 
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" 
P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel 
Contact: <sip:msc1.home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ggg 
s= 
c=IN IP6 5555::aaa:bbb:ccc:ggg 
t=0 0 
m=audio 3456 RTP/AVP 97 96 
a=tcap:1 RTP/AVPF 
a=pcfg:1 t=1 
b=AS:25.4 
a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20

The SCC AS sends the ATCF a confirmation, including the session state information (SSI) if the SCC AS and the MSC server support the mid-call feature. The MSC server receives the SSI from the ATCF; the access leg for the control has moved to the CS access. When MSC server receives SSI for more multiple active or inactive speech sessions, it initiates transfer directed at the SSC AS for the additional sessions.

The following diagram shows a call session in the active phase for MSC server assisted midcall feature when supported by the SCC AS.

Failure and Cancellation

For cases of failure and/or cancellation, the ATCF behaves in accordance with TS 23.216 [3], Section 8:

• In the case of session failure before the MSC server initiates session transfer, the standard failover procedures (as defined in TS 23.401 [2])apply and no further action is required by the UE.
• In the case of session failure after the UE receives the handover command, the UE attempts to return to the Universal Mobile Telecommunications System (UTRAN) or evolved Universal Mobile Telecommunications System (eUTRAN). The UE initiates signaling to transfer the session back, which the ATCF handles if the ATCF recognizes the session transfer.
• In the case when handover is cancelled, the UE—having received the handover cancellation message—begins the re-establishment procedure as though it needed to transfer the session to the eUTRAN/UTRAN. If he ATCF identifies this as a transfer session, it handles the session transfer back to the eUTRAN/UTRAN.

Confirmed Dialogs

When an SC UE is engaged in one or more ongoing IMS sessions, it will send a re-INVITE containing:

• An SDP offer, including the media characteristics used in the existing dialog, and
• A Reason header field containing the protocol SIP and reason parameters cause with the value 487 (as specified in RFC 3326 [57]), with reason text reading either Handover cancelled or Failure to transition to CS domain.

In all other ways, confirmed dialogs behave in accordance with TS 24.229 [2].

Early Dialogs

If the SC UE engages in a session which is in early dialog state, it will send a SIP UPDATE containing:

• An SDP offer, including the media characteristics used in the existing dialog, and
• A Reason header field containing the protocol SIP and reason parameters cause with the value 487 (as specified in RFC 3326 [57]), with reason text reading either Handover cancelled or Failure to transition to CS domain.

In all other ways, early dialogs behave in accordance with TS 24.229 [2].

SRVCC Handover Support in the Pre-Alerting Phase

In addition to other SRVCC support, the Oracle Communications Session Border Controller (SBC) supports procedures to manage the handover from 4G to 3G/2G of sessions in pre-alerting phase. The conditions by which a session is defined as in the pre-alerting phase include the calling party has not yet received a 180 RINGING message.

Refer to TS 24.237 to review the anchoring endpoints' behavior.

To ensure that calls in a pre-alerting phase are transferred between PS and CS networks, set the sip-feature-caps value as follows:

• Set state to enabled
• Set atcf-management-uri to management or psi
• Set atcf-pre-alerting to enabled

For information on the results of these settings, refer to the SIP Feature Capabilities section.

The SBC, as Proxy Call Session Control Function (P-CSCF) or Active Transfer Control Function (ATCF), selects any of the early dialogs as the session being transferred when:

• There are no confirmed dialogs supporting a session with an inactive speech media component ("sendonly" or "inactive" directionality) in the transferable session set, and
• There are one or more dialogs in the transferable session set supporting one session where the SC UE has completed a reliable offer / answer procedure and has an active speech media component ("recvonly" or "sendrecv" directionality).

Applicable dialogs include those for which:

• A SIP 180 (Ringing) response to the SIP INVITE request has not been received yet in any of the existing dialogs.
• All dialogs are early dialogs created by the same SIP INVITE request.
• The Contact header field provided by the SC UE includes the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag; and
• The Feature-Caps header field provided by the SCC AS towards the SC UE includes the g.3gpp.ps2cs-srvcc-orig-pre-alerting feature-capability indicator.

The range of SBC SRVCC pre-alerting phase support includes:

• SRVCC support for both outgoing (originating) and incoming (terminating) calls
• Responds to media feature tag and fcaps indicator
• SRVCC support of EATF emergency calls
• Handover (HO) cancelling scenarios
• Rx interactions
• SRVCC Error scenarios, including:
  • HO cancellation failures
  • Rx failures
  • Standard SIP transaction failures
• ACLI, SNMP and HDR statistics for applicable, successful and failed SRVCC handovers

The diagram below shows a flow for an outgoing call that includes an SRVCC handover during the pre-alerting phase. Prior to the alerting phase, the SBC, acting as ATCF (IM/CN subsystem) receives and forwards the new INVITE to update the call to the circuit switched (CS) leg. Ultimately, the signaling between the MSC, the ATCF and the SOC AS succeeds. The components proceed through the alerting phase, eliminating the packet switched based (PS) leg and using the MSC server to manage the CS call.

Figure 18-15 Mobile Originating Call in Pre-Alerting Phase

The diagram below shows a flow for an incoming call that includes an SRVCC handover during the pre-alerting phase. Prior to the alerting phase, the SBC, acting as ATCF (IM/CN subsystem) receives and forwards the new INVITE to update the call to the circuit switched (CS) leg. Ultimately, the signaling between the MSC, the ATCF and the SOC AS succeeds. The components proceed through the alerting phase, eliminating the packet switched based (PS) leg and using the MSC server to manage the CS call.

Figure 18-16 Mobile Terminating Call in Pre-Alerting Phase

SRVCC Handover Support in Alerting Phase

The SBC supports handovers between Packet-Switched (PS) and Circuit-Switched(CS) networks for calls in an alerting phase; that is, a 180 ringing response for the initial INVITE has been sent or received and the SIP final response has not been sent or received.

The behavior of the two anchoring points, ATCF and ATGW, is defined by 3GPP in Release 12 of Technical Specification TS 24.237. Oracle Communications developed these functional entities based on the initial version of TS 24.237 Release 10, and has added the sip-feature-caps configuration element to align with Release 12.

To ensure that calls in an alerting phase are transferred between PS and CS networks, set the sip-feature-caps value as follows:

• Set state to “enabled”
• Set atcf-management-uri to "management" or "psi"
• Set atcf-alerting to "enabled"

For information on the results of these settings, refer to the SIP Feature Capabilities section.

The diagram below shows an incoming call session during the alerting phase.

This diagram shows an outgoing call session during the alerting phase.

SIP Feature Capabilities

The ATCF can announce a feature capability in a message by transporting the information in the Feature-Caps header, which is supported by the SBC.

The behavior of the two anchoring points, ATCF and ATGW, is defined by 3GPP in Release 12 of Technical Specification TS 24.237. Oracle Communications developed these functional entities based on the initial version of TS 24.237 Release 10, and has added the sip-feature-caps configuration element to align with Release 12.

When the state is enabled, the SBC includes the Feature-Caps header in applicable SIP messages. The information in the header is dependent on sip-feature-caps configuration.

Specifically, When you enable sip-feature-caps, regardless of other settings, the SBC inserts the Feature-Caps header with:

• The g.3gpp.mid-call capability indicator.
• The g.3gpp.atcf-path parameter with a value set to the ATCF URI for terminating requests

Assume the state is enabled and both atcf-alerting pre-atcf-alerting are disabled. The SBC adds the Feature-Caps header with the above and:

• The g.3gpp.atcf parameter with a value of the configured atcf-stn-sr in sip-config
• The g.3gpp.atcf-mgmt-uri parameter with a value of the configured atcf-psi-dn in sip-config

Finally, when state is enabled, atcf-management-uri is not disabled, and atcf-alerting is enabled, the SBC adds the Feature-Caps header with the above and also adds the g.3gpp.srvcc-alerting capability indicator. Similarly, the SBC adds the g.3gpp.srvcc-pre-alerting capability indicator when atcf-pre-alerting is enabled.

SIP Feature Capabilities Configuration

You can configure Oracle Communications Session Border Controllers to have the ATCF announce a feature capability in a message by transporting the information in the Feature-Caps header.

1. Access the session-router configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# session-router
   ORACLE(session-router)# sip-feature-caps
   ORACLE(sip-feature-caps)#
   

2. state — identifies whether to enable the feature and add the Feature-Caps header to messages. Possible values are "enabled" and "disabled". The default value is "disabled".
3. atcf-alerting — identifies whether to turn on the alerting feature and add the alerting Feature-Caps header to messages. Possible values are "enabled" and "disabled". The default value is "disabled".
4. atcf-pre-alerting — identifies whether to turn on the alerting feature and add the pre-alerting Feature-Caps header to messages. Possible values are "enabled" and "disabled". The default value is "disabled".
5. atcf-management-uri — identifies the feature capability indicator that will be used to transport the ATCF management URI. Possible values are "management" and "psi". The default value is "management". When the value is "management" and the value of state is "enabled", the Feature-Caps header “g.3gpp.atcf-mgmt-uri” is added and the value is the value of atcf-psi-dn in the sip-config configuration element. When the value is "psi" and the value of state is "enabled", the Feature-Caps header “g.3gpp.atcf-psi” is added and the value is the value of atcf-psi-dn in the sip-config configuration element.
6. Type done to save your configuration.

Reporting SRVCC Statistics

You access SRVCC Hand-Over (HO) call counters and statistics from the SBC's via ACLI Show command, SNMP and HDR tools.

Applicable statistic access details include:

• ACLI—Run the command show sipd srvcc to display total, successful and failed calls for each handover phase. Find additional detail on show sipd from the Maintenance and Troubleshooting Guide.
• SNMP—Access the same detail provided by the ACLI command above via SNMP. Get this detail from ap-sip.mib mmm. Find additional detail on ap-sip.mib from the MIB Guide. Example OID and object identifiers include:
  • 1.3.6.1.4.1.9148.3.15.1.1.3.13 — (apSipSRVCCStatsTotalCallsDuringPreAlerting)
  • 1.3.6.1.4.1.9148.3.15.1.1.3.14 — (apSipSRVCCStatsDuringPreAlertingSuccess)
  • 1.3.6.1.4.1.9148.3.15.1.1.3.15 — (apSipSRVCCStatsDuringPreAlertingFailed)
• HDR—Access the same detail provided by the ACLI command above via HDR. Get this detail from the sip-srvcc collect group. Find additional detail on the sip-srvcc group from the HDR Reference Guide. Example HDR objects include:
  • Calls During Pre-Alerting Counter — (0-2^32-1) — Total calls subjected to SRVCC during pre-alerting.
  • During Pre-Alerting Success Counter — (0-2^32-1) — Total successful SRVCC HO during pre-alerting.
  • During Pre-Alerting Failed Counter — (0-2^32-1) — Total failed SRVCC HO during pre-alerting.