Troubleshoot Audio Call Transfer Problem at the Time of SRVCC Handover in VoLTE
Available Languages
Download Options
Bias-Free Language
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.
Contents
Introduction
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.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
- Hardware knowledge of 5000/5500
- StarOS
Components Used
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.
Abbreviations
| VoLTE | Voice over Long Term Evolution |
| SRVCC | Single Radio Voice Call Continuity |
| CCR | Credit Control Request |
| CCA | Credit Control Answer |
| AVP | Attribute Value Pair |
| PCRF | Policy and Charging Rule Function |
| PCEF | Policy and Charging Enforcement Function |
| SGW | Serving Gateway |
| PGW | Packet Data Network Gateway |
| MME |
Mobility Management Entity |
Problem
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.
Troubleshoot
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)
INFORMATION ELEMENTS
BEARER CONTEXT:
Type: 93 Length: 10 Inst: 0
Value:
EPS BEARER ID:
Type: 73 Length: 1 Inst: 0
Value: 7
BEARER FLAGS:
Type: 97 Length: 1 Inst: 0
Value:
VB : 1 >> voice bearer as true
ULI TIMESTAMP:
Type: 170 Length: 4 Inst: 0
Value:
Seconds: 3766718840
USER LOCATION INFO:
Type: 86 Length: 13 Inst: 0
Value:
Location type: TAI
MCC: XYZ
MNC: AB
TAC: 0x7D5
Location type: ECGI
MCC: XYZ
MNC: AB
ECI: 0xE02F902
UE TIME ZONE:
Type: 114 Length: 2 Inst: 0
Value:
TZ: +5:30
DST: +0 hour
Further, SGW sends EGTP_DELETE_BEARER_COMMAND message to PGW:
INBOUND>>>>> 12:17:24:407 Eventid:141004(3)
[PGW-S5/S2a/S2b]GTPv2C Rx PDU, from 223.224.X.Y:36368 to 223.224.A.B:2123 (57)
TEID: 0x80F0E1DB, Message type: EGTP_DELETE_BEARER_COMMAND (0x42)
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: 0x0035 (53)
INFORMATION ELEMENTS
BEARER CONTEXT:
Type: 93 Length: 10 Inst: 0
Value:
EPS BEARER ID:
Type: 73 Length: 1 Inst: 0
Value: 7
BEARER FLAGS:
Type: 97 Length: 1 Inst: 0
Value:
VB : 1 >> voice bearer as true
ULI TIMESTAMP:
Type: 170 Length: 4 Inst: 0
Value:
Seconds: 3766718840
USER LOCATION INFO:
Type: 86 Length: 13 Inst: 0
Value:
Location type: TAI
MCC: XYZ
MNC: AB
TAC: 0x7D5
Location type: ECGI
MCC: XYZ
MNC: AB
ECI: 0xE02F902
UE TIME ZONE:
Type: 114 Length: 2 Inst: 0
Value:
TZ: +5:30
DST: +0 hour
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:
<<<<OUTBOUND 12:17:24:413 Eventid:81990(5)
Diameter message from 10.0.232.X:32933 to 10.5.40.Y:3869
Base Header Information:
Version: 0x01 (1)
Message Length: 0x000260 (608)
Command Flags: 0xc0 (192) REQ PXY
Command Code: 0x000110 (272) Credit-Control-Request
Application ID: 0x01000016 (16777238) 3GPP-Gx
Hop2Hop-ID: 0xb7cf10ce (3083800782)
End2End-ID: 0x3b6b4886 (996886662)
AVP Information:
[M] Session-Id
Code: 0x00000107 (263) Session-Id
Flags: 0x40 (64) [M]
Length: 0x00004f (79)
Data: 0003-diamproxy.asr55k.gx;1385806608;584234203;5cd9037d-1db02
[M] Auth-Application-Id
Code: 0x00000102 (258) Auth-Application-Id
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 16777238
[M] Origin-Host
Code: 0x00000108 (264) Origin-Host
Flags: 0x40 (64) [M]
Length: 0x00002b (43)
Data: 0003-diamproxy.asr55k.gx
[M] Origin-Realm
Code: 0x00000128 (296) Origin-Realm
Flags: 0x40 (64) [M]
Length: 0x00001a (26)
Data: cisco.com
[M] Destination-Realm
Code: 0x0000011b (283) Destination-Realm
Flags: 0x40 (64) [M]
Length: 0x00002a (42)
Data: PCRF.MNC0AB.MCCXYZ.3GPPNETWORK.ORG
[M] CC-Request-Type
Code: 0x000001a0 (416) CC-Request-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: UPDATE_REQUEST (2)
[M] CC-Request-Number
Code: 0x0000019f (415) CC-Request-Number
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 2
[M] Destination-Host
Code: 0x00000125 (293) Destination-Host
Flags: 0x40 (64) [M]
Length: 0x000037 (55)
Data: PCRF01.PCRF.MNC0AB.MCCXYZ.3GPPNETWORK.ORG
[M] Origin-State-Id
Code: 0x00000116 (278) Origin-State-Id
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 1552081338
[M] Subscription-Id
Code: 0x000001bb (443) Subscription-Id
Flags: 0x40 (64) [M]
Length: 0x000028 (40)
[M] Subscription-Id-Type
Code: 0x000001c2 (450) Subscription-Id-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: END_USER_E164 (0)
[M] Subscription-Id-Data
Code: 0x000001bc (444) Subscription-Id-Data
Flags: 0x40 (64) [M]
Length: 0x000014 (20)
Data: 121234567891
[M] Subscription-Id
Code: 0x000001bb (443) Subscription-Id
Flags: 0x40 (64) [M]
Length: 0x00002c (44)
[M] Subscription-Id-Type
Code: 0x000001c2 (450) Subscription-Id-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: END_USER_IMSI (1)
[M] Subscription-Id-Data
Code: 0x000001bc (444) Subscription-Id-Data
Flags: 0x40 (64) [M]
Length: 0x000017 (23)
Data: XYZAB1234567891
[M] Framed-IPv6-Prefix
Code: 0x00000061 (97) Framed-IPv6-Prefix
Flags: 0x40 (64) [M]
Length: 0x000012 (18)
Data: Reserved: 00 Prefixlen: 64 IPv6 prefix: 2401:4900:4097:f050::
[M] User-Equipment-Info
Code: 0x000001ca (458) User-Equipment-Info
Flags: 0x40 (64) [M]
Length: 0x00002c (44)
[M] User-Equipment-Info-Type
Code: 0x000001cb (459) User-Equipment-Info-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: IMEISV (0)
[M] User-Equipment-Info-Value
Code: 0x000001cc (460) User-Equipment-Info-Value
Flags: 0x40 (64) [M]
Length: 0x000018 (24)
Data: 9876543211234
[M] Called-Station-Id
Code: 0x0000001e (30) Called-Station-Id
Flags: 0x40 (64) [M]
Length: 0x00000b (11)
Data: ims
[V] [M] Charging-Rule-Report
Code: 0x000003fa (1018) Charging-Rule-Report
Flags: 0xc0 (192) [V] [M]
Length: 0x00006c (108)
Vendor-Id: 0x000028af (10415) 3GPP
[V] [M] Charging-Rule-Name
Code: 0x000003ed (1005) Charging-Rule-Name
Flags: 0xc0 (192) [V] [M]
Length: 0x00001e (30)
Vendor-Id: 0x000028af (10415) 3GPP
Data: I_AD_VOLTE00F72513
[V] [M] Charging-Rule-Name
Code: 0x000003ed (1005) Charging-Rule-Name
Flags: 0xc0 (192) [V] [M]
Length: 0x00001e (30)
Vendor-Id: 0x000028af (10415) 3GPP
Data: I_AD_VOLTE00F72512
[V] [M] PCC-Rule-Status
Code: 0x000003fb (1019) PCC-Rule-Status
Flags: 0xc0 (192) [V] [M]
Length: 0x000010 (16)
Vendor-Id: 0x000028af (10415) 3GPP
Data: INACTIVE (1)
[V] [M] Rule-Failure-Code
Code: 0x00000407 (1031) Rule-Failure-Code
Flags: 0xc0 (192) [V] [M]
Length: 0x000010 (16)
Vendor-Id: 0x000028af (10415) 3GPP
Data: RESOURCE_ALLOCATION_FAILURE (10) >> failure code is incorrect. It should be PS_CS_Handover
[V] [M] Access-Network-Charging-Address
Code: 0x000001f5 (501) Access-Network-Charging-Address
Flags: 0xc0 (192) [V] [M]
Length: 0x000012 (18)
Vendor-Id: 0x000028af (10415) 3GPP
Data: IPv4 223.224.X.Y
Solution
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.
ims-auth-service DRA_Gx_SPG
policy-control
diameter dictionary r8-gx-standard
diameter update-dictionary-avps 3gpp-r10 << diameter dictionary updated to 3gpp-r10
DELETE_BEARER_COMMAND message from SGW to PGW as voice bearer flag true:
INBOUND>>>>> From sessmgr:205 tpc_interface.c:1338 (Callid 3cda3ef4) 13:28:21:659 Eventid:141004(3)
[PGW-S5/S2a/S2b]GTPv2C Rx PDU, from 223.224.M.N:39632 to 223.224.P.Q:2123 (57)
TEID: 0x845800CD, Message type: EGTP_DELETE_BEARER_COMMAND (0x42)
Sequence Number: 0xE9625A (15295066)
GTP HEADER
Version number: 2
TEID flag: Present
Piggybacking flag: Not present
Message Priority flag: Not present
Message Priority: NA
Message Length: 0x0035 (53)
INFORMATION ELEMENTS
BEARER CONTEXT:
Type: 93 Length: 10 Inst: 0
Value:
EPS BEARER ID:
Type: 73 Length: 1 Inst: 0
Value: 7
BEARER FLAGS:
Type: 97 Length: 1 Inst: 0
Value:
VB : 1 >> voice bearer as true
ULI TIMESTAMP:
Type: 170 Length: 4 Inst: 0
Value:
Seconds: 3769747091
USER LOCATION INFO:
Type: 86 Length: 13 Inst: 0
Value:
Location type: TAI
MCC: XYZ
MNC: AB
TAC: 0x844
Location type: ECGI
MCC: XYZ
MNC: AB
ECI: 0xDCF8C02
UE TIME ZONE:
Type: 114 Length: 2 Inst: 0
Value:
TZ: +5:30
DST: +0 hour
Further, it is accepted by PGW and initiates the release of the bearer.
<<<<OUTBOUND From sessmgr:205 sessmgr_egtp.c:2984 (Callid 3cda3ef4) 13:28:21:670 Eventid:141005(3)
[PGW-S5/S2a/S2b]GTPv2C Tx PDU, from 223.224.M.N:2123 to 223.224.P.Q:39632 (17)
TEID: 0x8064A25A, Message type: EGTP_DELETE_BEARER_REQUEST (0x63)
Sequence Number: 0xE9625A (15295066)
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
CCR from PGW to PCRF with regards to the Charging-Rule-Report AVP with failure code seen as PS_CS_Handover.
<<<<OUTBOUND From diamproxy:55 diamproxy_rlf.c:553 (Callid 3cda3ef4) 13:28:21:679 Eventid:81990(5)
Diameter message from 10.206.17.X:51119 to 10.5.40.Y:3007
Base Header Information:
Version: 0x01 (1)
Message Length: 0x000260 (608)
Command Flags: 0xc0 (192) REQ PXY
Command Code: 0x000110 (272) Credit-Control-Request
Application ID: 0x01000016 (16777238) 3GPP-Gx
Hop2Hop-ID: 0xaebac4d3 (2931475667)
End2End-ID: 0x19b8ec95 (431549589)
AVP Information:
[M] Session-Id
Code: 0x00000107 (263) Session-Id
Flags: 0x40 (64) [M]
Length: 0x00004e (78)
Data: 0007-diamproxy.asr55k.dra.gx;1020935924;202167245;5d0747d1-cd02
[M] Auth-Application-Id
Code: 0x00000102 (258) Auth-Application-Id
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 16777238
[M] Origin-Host
Code: 0x00000108 (264) Origin-Host
Flags: 0x40 (64) [M]
Length: 0x00002b (43)
Data: 0007-diamproxy.asr55k.dra.gx
[M] Origin-Realm
Code: 0x00000128 (296) Origin-Realm
Flags: 0x40 (64) [M]
Length: 0x00001a (26)
Data: cisco.com
[M] Destination-Realm
Code: 0x0000011b (283) Destination-Realm
Flags: 0x40 (64) [M]
Length: 0x00002a (42)
Data: PCRF.MNC0AB.MCCXYZ.3GPPNETWORK.ORG
[M] CC-Request-Type
Code: 0x000001a0 (416) CC-Request-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: UPDATE_REQUEST (2)
[M] CC-Request-Number
Code: 0x0000019f (415) CC-Request-Number
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 2
[M] Destination-Host
Code: 0x00000125 (293) Destination-Host
Flags: 0x40 (64) [M]
Length: 0x000037 (55)
Data: PCRF01.NO.DC.PCRF.MNC0AB.MCCXYZ.3GPPNETWORK.ORG
[M] Origin-State-Id
Code: 0x00000116 (278) Origin-State-Id
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: 1559087623
[M] Subscription-Id
Code: 0x000001bb (443) Subscription-Id
Flags: 0x40 (64) [M]
Length: 0x000028 (40)
[M] Subscription-Id-Type
Code: 0x000001c2 (450) Subscription-Id-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: END_USER_E164 (0)
[M] Subscription-Id-Data
Code: 0x000001bc (444) Subscription-Id-Data
Flags: 0x40 (64) [M]
Length: 0x000014 (20)
Data: 121234567891
[M] Subscription-Id
Code: 0x000001bb (443) Subscription-Id
Flags: 0x40 (64) [M]
Length: 0x00002c (44)
[M] Subscription-Id-Type
Code: 0x000001c2 (450) Subscription-Id-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: END_USER_IMSI (1)
[M] Subscription-Id-Data
Code: 0x000001bc (444) Subscription-Id-Data
Flags: 0x40 (64) [M]
Length: 0x000017 (23)
Data: XYZAB1234567891
[M] Framed-IPv6-Prefix
Code: 0x00000061 (97) Framed-IPv6-Prefix
Flags: 0x40 (64) [M]
Length: 0x000012 (18)
Data: Reserved: 00 Prefixlen: 64 IPv6 prefix: 2401:4900:4071:32ec::
[M] User-Equipment-Info
Code: 0x000001ca (458) User-Equipment-Info
Flags: 0x40 (64) [M]
Length: 0x00002c (44)
[M] User-Equipment-Info-Type
Code: 0x000001cb (459) User-Equipment-Info-Type
Flags: 0x40 (64) [M]
Length: 0x00000c (12)
Data: IMEISV (0)
[M] User-Equipment-Info-Value
Code: 0x000001cc (460) User-Equipment-Info-Value
Flags: 0x40 (64) [M]
Length: 0x000018 (24)
Data: 9876543211234
[M] Called-Station-Id
Code: 0x0000001e (30) Called-Station-Id
Flags: 0x40 (64) [M]
Length: 0x00000b (11)
Data: ims
[V] [M] Charging-Rule-Report
Code: 0x000003fa (1018) Charging-Rule-Report
Flags: 0xc0 (192) [V] [M]
Length: 0x00006c (108)
Vendor-Id: 0x000028af (10415) 3GPP
[V] [M] Charging-Rule-Name
Code: 0x000003ed (1005) Charging-Rule-Name
Flags: 0xc0 (192) [V] [M]
Length: 0x00001e (30)
Vendor-Id: 0x000028af (10415) 3GPP
Data: I_AD_VOLTE03D4E98A
[V] [M] Charging-Rule-Name
Code: 0x000003ed (1005) Charging-Rule-Name
Flags: 0xc0 (192) [V] [M]
Length: 0x00001e (30)
Vendor-Id: 0x000028af (10415) 3GPP
Data: I_AD_VOLTE03D4E989
[V] [M] PCC-Rule-Status
Code: 0x000003fb (1019) PCC-Rule-Status
Flags: 0xc0 (192) [V] [M]
Length: 0x000010 (16)
Vendor-Id: 0x000028af (10415) 3GPP
Data: INACTIVE (1)
[V] [M] Rule-Failure-Code
Code: 0x00000407 (1031) Rule-Failure-Code
Flags: 0xc0 (192) [V] [M]
Length: 0x000010 (16)
Vendor-Id: 0x000028af (10415) 3GPP
Data: PS_TO_CS_HANDOVER (13) >> failure code seen as PS_to_CS_Handover
[V] [M] Access-Network-Charging-Address
Code: 0x000001f5 (501) Access-Network-Charging-Address
Flags: 0xc0 (192) [V] [M]
Length: 0x000012 (18)
Vendor-Id: 0x000028af (10415) 3GPP
Data: IPv4 223.224.X.Y
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.
Contributed by Cisco Engineers
- Satya Narayan PandaCisco TAC Engineer
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)