PDF(118.1 KB) View with Adobe Reader on a variety of devices
ePub(89.8 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(84.2 KB) View on Kindle device or Kindle app on multiple devices
Updated:October 14, 2019
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to troubleshoot the problem that occurs when an audio call in VoLTE does not seamlessly transfer at the time of the SRVCC handover.
Cisco recommends that you have knowledge of these topics:
Hardware knowledge of 5000/5500
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Voice over Long Term Evolution
Single Radio Voice Call Continuity
Credit Control Request
Credit Control Answer
Attribute Value Pair
Policy and Charging Rule Function
Policy and Charging Enforcement Function
Packet Data Network Gateway
Mobility Management Entity
The Service provider reported that even though SRVCC handover was successful at MME, the VoLTE call was not seamlessly transferred to the legacy 2G/3G network. After SRVCC handover was completed, MME sent DELETE_BEARER_COMMAND message to SGW with voice bearer flag as true and the bearer release at PGW was successful. But, on further communication from PGW to PCRF, it was observed that PGW does not notify PCRF as PS_to_CS_Handover even though SRVCC was successful at MME end.
This section provides information in order to troubleshoot the problem of audio call handling when it is transferred from VoLTE to legacy 2G/3G network through SRVCC handover.
Collected "mon sub" traces with the SRVCC handover. Here is the sequence of messages exchanged between MME, SGW, PGW, and PCRF.
DELETE_BEARER_COMMAND message from MME to SGW as voice bearer flag true:
INBOUND>>>>> 12:17:24:406 Eventid:141004(3) [SGW-S11/S4]GTPv2C Rx PDU, from 10.206.33.X:30464 to 10.206.31.Y:2123 (57) TEID: 0x81E0418E, Message type: EGTP_DELETE_BEARER_COMMAND (0x42) Sequence Number: 0xD2101D (13766685) GTP HEADER Version number: 2 TEID flag: Present Piggybacking flag: Not present Message Priority flag: Not present Message Priority: NA Message Length: 0x0035 (53)
Further, DELETE_BEARER is accepted by PGW and initiates delete of the bearer:
<<<<OUTBOUND 12:17:24:408 Eventid:141005(3) [PGW-S5/S2a/S2b]GTPv2C Tx PDU, from 223.224.A.B:2123 to 223.224.X.Y:36368 (17) TEID: 0x80F3C18E, Message type: EGTP_DELETE_BEARER_REQUEST (0x63) Sequence Number: 0xAD818E (11370894) GTP HEADER Version number: 2 TEID flag: Present Piggybacking flag: Not present Message Priority flag: Not present Message Priority: NA Message Length: 0x000D (13)
INFORMATION ELEMENTS EPS BEARER ID: Type: 73 Length: 1 Inst: 1 Value: 7
Further, PGW initiates CCR update message towards PCRF. Here, in Charging-Rule-Report AVP, PGW informs PCRF about Charging-Rule-Name, PCC-Rule-Status, and Rule-Failure-Code.
Here it is found that PGW sends the wrong Rule-Failure-Code to PCRF. As MME indicated the release of Voice bearer(as the flag was true), PGW should inform to PCRF as PS_to_CS handover. Instead of this, there is a Resource_Allocation_failure that is reported to PCRF.
As a result, PCRF was considering failure in 4G network and informing the same to IMS. Hence IMS was initiating VoLTE call termination. So, Although SRVCC was successful, the call was not seamlessly transferred to the legacy 2G/3G network.
In 3GPP TS 29.212 V13.5.0 (2016-03) As mentioned in section 3.6, Request of IP-CAN Bearer Termination If the IP-CAN bearer termination is caused by the PS to CS handover, the PCEF shall report related PCC rules for this IP-CAN bearer by including the Rule-Failure-Code AVP set to the value PS_TO_CS_HANDOVER.
In 3GPP TS 29.212 V14.3.0 (2017-03) As mentioned in section 4.5.6 Indication of IP-CAN Bearer Termination Implications When the PCEF detects that a dedicated IP-CAN bearer could not be activated or has been terminated it shall remove the affected PCC rules and send a CCR command to the PCRF with CC-Request-Type AVP set to the value "UPDATE_REQUEST", including the Charging-Rule-Report AVP specifying the affected PCC rules with the PCC-Rule-Status set to inactive and including the Rule-Failure-Code AVP assigned to the value RESOURCE_ALLOCATION_FAILURE.
SRVCC PS-to-CS Handover Indication Support in starOS This feature helps in notifying the PCRF about the exact reason for PCC rule deactivation on Voice bearer deletion. This exact cause will help PCRF to then take further action appropriately. This feature ensures complete compliance for SRVCC, including support for PS-to-CS handover indication when voicebearers are released. If the IP-CAN bearer termination is caused by the PS to CS handover, the PCEF may report related PCC rules for thisIP-CAN bearer by including the Rule-Failure-Code AVP set to the value PS_TO_CS_HANDOVER.
CCR update message from PGW to PCRF with regards to Charging-Rule-Report AVP:
In the customer network rel-8 diameter dictionary was used. It is found PS_CS_Handover was not supported in rel-8. So, you need to update the dictionary to 3gpp-r10. After you have updated the dictionary to 3gpp-r10, the cause is properly sent as PS_CS_Handover. After this, the end-users audio calls might be able to seamlessly handover to legacy 2G/3G network from VoLTE.
Appropriate diameter dictionary needs to be used for seamless handover of an audio call from VoLTE in 4G to legacy 2G/3G network through SRVCC handover. This was supported after the diameter dictionary was updated to 3gpp-rel10 under ims-auth-service.