Single Radio Voice Call Continuity

Voice over IP (VoIP) subscribers anchored in the IP Multimedia Subsystem (IMS) network can move out of an LTE coverage area and continue the voice call over the circuit-switched (CS) network through the use of the Single Radio Voice Call Continuity (SRVCC) feature. Unlike other methods like CSFB, it does not require a dual-mode radio.

Feature Summary and Revision History

Summary Data

Applicable Product(s) or Functional Area

MME

Applicable Platform(s)

ASR 5500

Feature Default

Disabled - Configuration Required

Related Changes in This Release

Not Applicable

Related Documentation

  • Command Line Interface Reference

  • MME Administration Guide

  • Statistics and Counters Reference

Revision History

Revision Details

Release

MME is enhanced to disable Single Radio Voice Call Continuity (SRVCC) handovers for subscribers availing VoLTE services from a roaming network.

21.5

First introduced.

Pre - 21.3

Feature Description

SRVCC requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

To support SRVCC functionality on the MME, an Sv interface is created to the Mobile Switching Center (MSC) server responsible for communicating with the MME during the handover process.
Figure 1. SRVCC Architecture


Supported SRVCC Features

The MME supports the following SRVCC features:

SRVCC CS-PS Handover Continuity on PS Handover Failure: During S1-based CS-PS SRVCC handover, if one of the following types of failures occurs

  • Peer SGSN DNS query failed

  • Fwd Relocation Response timeout

  • Fwd Relocation Response was received with a failure cause

then the handover will continue for CS calls if CS handover on the Sv interface succeeds. This means that the S1 SRVCC handover will continue as partially successful and the handover command message will not carry any bearer related information.

MSC Selection using DNS: As defined in 3GPP TS 29.303 V10.4.0, the MME supports DNS-based MSC selection. In the NAPTR query response, the MME will analyze the "Service Parameter" of "x-3gpp-msc:x-sv", and select a specific MSC from a pool list provided in the DNS response. The provisioned weights and priorities on the DNS server are used to load share proportionally between the MSC servers.

If DNS lookup fails, the MSC will be selected from local configuration. If an MSC pool area has been configured, the selection logic for the pool area will be used.

MSC Pool Areas: MSC pool areas can be configured for load balancing and intelligent selection of MSC servers based on PLMN and/or IMSI hash values. Up to 24 MSC servers can be defined per MME service. Each pool-area can optionally be associated with a PLMN, which is the target PLMN as specified in the SRVCC Handover request.

The MME attempts to select an MSC using the following selection order: 1) Pool-area that matches the PLMN and of type hash 2) Pool-area that matches the PLMN and of type round-robin 3) Pool-area that does not have PLMN and of type hash 4) Pool-area that does not have PLMN and of type round-robin.

MSC Offload: The MME allows an administrator to place one or more MSC server in maintenance mode. This action removes the MSC server as a possible selection target.

MSC Fallback on Failure: The MME automatically attempts to resend the Sv PS to CS Request to a different MSC if: 1) no response is received (timeout) from the MSC to a Sv PS to CS Request, or 2) any failure response is received from the MSC to a Sv PS to CS Request.

If no alternate MSC is configured, or if the second MSC fails as well, the SRVCC handover fails. A new MSC is attempted only for the initial PS to CS Request. No additional configuration is needed to enable this functionality.

When an MSC is selected by DNS, and multiple results are returned, the second MSC result will be used for fallback. In case DNS selection returns just one MSC, the second MSC for fallback will be from local configuration if it exists. If DNS lookup fails, the MSC for fallback will be selected from local configuration.

Disabling MSC Fallback on Failure: If so configured, the MME rejects handover based on the SRVCC failure cause received from the MSC. So that in some situations, the MME will ignore MSC fallback procedures outlined above. If a voice call can be handed over to one of multiple MSC IP addresses during SRVCC handover, and if the PS-CS Response from the first MSC returns with a negative cause, and if that cause has been included in the MME's Call-Control Profile configuration with the msc-fallback-disable command, then the MME fails the SRVCC HO and does not try the next available MSC. For configuration details, refer to 'Disabling MSC Fallback Based on SRVCC Cause' in the section on Configuring an MSC Pool Area.

SRVCC Handover Restriction: MME is enhanced to disable Single Radio Voice Call Continuity (SRVCC) handovers for subscribers availing VoLTE services from a roaming network. The administrator can control SRVCC services for a set of subscribers using IMSI values where the configurable range of the IMSI values is not limited.

A new CLI command srvcc unauthorized is added in the Call Control Profile Configuration mode to disable an SRVCC handover for a roaming area network. When this CLI is configured, MME does not send a "SRVCCOperationPossible" IE in the Initial-Context-Setup-Request message to the eNodeB during the ATTACH/TAU Accept phase. As a result, the eNodeB will not trigger an SRVCC handover for that subscriber. If the eNodeB overrides the configuration and sends a handover request with the “SRVCCHOIndication” IE, the MME responds with a handover failure message to the eNodeB.

Refer to Configuring SRVCC Handover Restriction section for the configuration information

Other Supported SRVCC Features: The MME implementation of SRVCC also supports:

  • IMS Centralized Service call handling as specified in 3GPP TS 29.280, enabling call flow handling for advanced scenarios.

  • Emergency Calls as defined in 3GPP TS 29.280.

  • GTP echo path management messages as defined in 3GPP TS 29.280.

  • GTP-C DSCP marking.

MSC Fallback on Sv Interface

In Release 20.0, MME is modified to maintain the reachability status of MSCs on the Sv interface. Only reachable MSCs are selected for PS to CS handovers (SRVCC procedures). The MSC Fallback feature is currently applicable only when MSC IP address is statically configured in StarOS, and not when MME determines MSC IP using DNS resolution.

When the MSC Fallback feature is enabled, MME acquires the status information independent of any ongoing SRVCC procedures, from the EGTPMGR. The status of an MSC will be unknown until MME acquires its status by sending ECHO requests to the MSCs. If a response is received from the MSC, the status of the MSC is moved to UP state. If no response is received, the MSC is considered to be in the DOWN state (unreachable).

If the status of an MSC is DOWN, ECHO Requests will be sent to the MSCs based on a configured reconnect-interval value. If an MSC responds to the request within this interval, the status of the MSC is changed to UP state. For more information related to reconnect-interval configuration, please refer to the Configuring MSC Fallback section.

For PS to CS handovers, MME does not select the MSCs in the DOWN state. The status information of the MSC provided by the EGTPMGR helps to select only reachable MSCs. This process reduces latency during fallback to reachable MSCs.

Relationships to Other Features

If the UE supports circuit-switch fallback (CSFB) and/or IMS voice, or both, the UE shall include the information element "Voice domain preference and UE's usage setting" in Attach Request and Tracking Area Update Request messages. The UE's usage setting indicates whether the UE behaves in a voice centric or data centric way. The voice domain preference for E-UTRAN indicates whether the UE is configured as CS Voice only, CS Voice preferred and IMS PS Voice as secondary, IMS PS Voice preferred and CS Voice as secondary, or IMS PS Voice only. The purpose of this information element is to signal to the network the UE's usage setting and voice domain preference for E-UTRAN.

The UE also includes the SRVCC capability indication as part of the "MS Network Capability" in the Attach Request message and in Tracking Area Updates. This capability needs to be accessed and stored on the MME.

If the UE reflects SRVCC along with IMS voice in the "Voice domain preference" in a Combined Attach, the MME will treat it as a EPS Attach with SRVCC capability.

How It Works

The existing eGTP-C service is enhanced to support the Sv reference point. A new instance of the eGTP-C service must be configured for Sv messages.

SRVCC requires the following elements:
  • SRVCC requires the STN-SR to be sent to the MSC for all non-emergency calls. If the STN-SR is not present in the HSS during the Attach procedure, SRVCC handover will not be allowed for non-emergency calls. In case of situations like STN-SR not being configured for non-emergency calls, the MME will send a HANDOVER PREPARATION FAILURE message back with the cause code set to Handover Failure in Target System.
  • MSC Server that has been enhanced for SRVCC.
  • UE that has ICS (IMS Service Continuity) capabilities with single radio access. The UE includes the ICS Capability indication as part of the UE network capability in the Attach Request message. The MME stores this information for SRVCC operation.
  • IMS network and SCC-AS in which the call is anchored. The MME signals to the UE the presence of VoIMS in the Attach Response

SRVCC is agnostic as to the whether S3 or GnGP is used for the SGSN interface.

Flows

The following SRVCC call flows are supported:
  • SRVCC from E-UTRAN to GERAN without DTM support (TS 23.216 V10.5.0; Section 6.2.2.1).
  • SRVCC from E-UTRAN to GERAN with DTM but without DTM HO support and from E-UTRAN to UTRAN without PS HO (TS 23.216 V9.6.0; Section 6.2.2.1A).
  • SRVCC from E-UTRAN to UTRAN with PS HO or GERAN with DTM HO support (TS 23.216 V9.6.0; Section 6.2.2.1A).
  • Emergency calls for all of the above three SRVCC scenarios

Standards Compliance

The MME implementation of SRVCC complies with the following standards:

  • 3GPP TS 23.216 Single Radio Voice Call Continuity (SRVCC) V10.5.0
  • 3GPP TS 29.280 Sv Interface (MME to MSC and SGSN to MSC) for SRVCC V10.4.0
  • 3GPP TS 36.413 S1 Application Protocol (S1AP) V10.5.0
  • 3GPP TS 29.303 Domain Name System Procedures; Stage 3 V10.4.0

Configuring Single Radio Voice Call Continuity

Configuring SRVCC

Use the following example to configure basic SRVCC support on the MME, including:

  • Creating the eGTP-C Sv service and binding it to an IPv4/v6 address.

  • Associating the eGTP-C service to the MME service.

  • Configuring one or more MSC servers within the MME service.


Important

If you modify the interface-type command, the parent service (service within which the eGTP/GTP-U service is configured) will automatically restart. Service restart results in dropping of active calls associated with the parent service.


configure 
   context mme_context_name 
      interface sv_intf_name 
         ip address ipv4_address 
         exit 
      egtp-service egtpc_sv_service_name 
         interface-type interface-mme  
         gtpc bind ipv4-address sv_infc_ip_address  
         exit 
      mme-service mme_service_name  
         associate egtp-sv-service egtp_sv_service_name  
         msc name  msc_name ip-address ip_address  
         exit 
      exit 
   port ethernet slot_number/port_number  
      no shutdown 
      bind interface sv_intf_name mme_context_name  
      end 

Notes:

  • The gtpc bind command can be specified as an IPv6 address using the ipv4-address oripv6-address keyword or both. The interface specified for Sv communication must also be the same IP address type.

Configuring MSC Selection Using DNS

DNS based MSC selection can be defined for an MME service, or for a Call Control Profile. Both configuration options specify the context in which a DNS client configuration has been defined.

Refer to Configuring Dynamic Peer Selection in the MME Configuration chapter of this document for details on configuring the DNS client.

Configuration via Call Control Profile takes precedence in cases where both options are configured.

MSC selection using DNS take precedence over MSC pool-areas and locally configured MSCs.

To configure DNS selection of an MSC for a specific MME service, refer to the following example:

configure 
   context ctxt_name 
      mme-service service_name 
         dns msc context <ctxt_name> 
         end 

To configure DNS selection of an MSC based on a Call Control Profile, refer to the following example.

configure 
   call-control-profile profile_name 
      dns-msc context ctxt_name 
      end 

Notes:

  • Configuration via Call Control Profile takes precedence if DNS is configured via both mme-service and call control profile.

To define an MSC server that should be selected by DNS, the msc command must be used without the ip-address keyword, as follows

configure 
   context ctxt_name 
      mme-service mme_service_name 
         msc name msc_name  
         end 

Configuring an MSC Pool Area

In order to support pooling, multiple MSC servers and pool-areas for Sv interface are allowed to be configured within the MME service. A maximum of 24 MSC servers can be configured for a given MME Service. Each MME Service can also have be a maximum of 24 pool areas. Each pool-area can have a maximum of 24 MSC's.

The pool can be either based on IMSI hash or a round-robin scheme. In the IMSI hash scheme, an MSC is chosen based on the result of the IMSI [(IMSI div 10) modulo 1000]. In case of round-robin, the MME selects the next MSC based on the round-robin scheme.

Each pool-area is associated with a unique name. Within a pool-area of type hash, up to 24 hash-values can be defined. Pool-area of type round-robin can have up to 24 entries.

Each pool-area can be associated with a PLMN which is the target PLMN as specified in the SRVCC Handover request.

MME attempts to select a MSC using the following selection order:1) Pool-area that matches the PLMN and of type hash2) Pool-area that matches the PLMN and of type round-robin3) Pool-area that does not have PLMN and of type hash4) Pool-area that does not have PLMN and of type round-robin

IMSI Hash MSC Pool

Use the following example to configure an MSC server pool with a selection scheme based on the IMSI hash value.

configure 
   context ctxt_name 
      mme-service service_name 
         pool-area pool_area_name type hash-value 
            hash-value { hash_value | range start_value to end_value } use-msc msc_id  
            plmnid mcc code mnc code 
            end 
Notes:
  • The pool-area command creates a Mobile Switching Center (MSC) server pool area and defines that the MSC servers be selected from within the pool using the result of the IMSI (using the hash-value keyword).
  • The optional plmnid command associates a Public Land Mobile Network (PLMN) identifier with this Mobile Switching Center (MSC) pool area. This is used to select an MSC based on the target PLMN as specified in the SRVCC handover request. If a pool does not have any PLMN id associated with it, the pool area is assumed to be able to serve any PLMN.

    If this command is used, the PLMN id values specified must be unique within a given MSC pool area type. For example, multiple pool areas of type hash cannot use the same PLMN. However, you can configure one pool area of type hash and another of type round-robin and have both use the same PLMN id.

  • The hash-value command configures the selection of a Mobile Switching Center (MSC) server in a MSC pool area based on the hash value derived from the IMSI [(IMSI div 10) modulo 1000].

    The use-msc keyword associates an MSC to use for this hash value, where msc_name is the name of the MSC as previously configured in the MME service using the msc command. A maximum of 24 MSCs can be defined per pool area.

  • See the MME MSC Server Pool Area Configuration Mode chapter of the Command Line Interface Reference for more information.

Round-Robin MSC Pool

Use the following example to configure an MSC server pool with a round-robin selection scheme.

configure 
   context ctxt_name 
      mme-service service_name 
         pool-area pool-area-name type round-robin 
            plmnid mcc code mnc code 
            use-msc msc_id 
            end 

Notes:

  • The pool-area command creates a Mobile Switching Center (MSC) server pool area and defines that the MSC servers be selected from within the pool using a round-robin scheme (using the round-robin keyword).
  • The optional plmnid command associates a Public Land Mobile Network (PLMN) identifier with this Mobile Switching Center (MSC) pool area. This is used to select an MSC based on the target PLMN as specified in the SRVCC handover request. If a pool does not have any PLMN id associated with it, the pool area is assumed to be able to serve any PLMN.

    If this command is used, the PLMN id values specified must be unique within a given MSC pool area type. For example, multiple pool areas of type hash cannot use the same PLMN. However, you can configure one pool area of type hash and another of type round-robin and have both use the same PLMN id.

  • The use-msc command associates an MSC with this pool area, where msc_name is the name of the MSC as previously configured in the MME service using the msc command. A maximum of 24 MSCs can be defined per pool area.
  • See the MME MSC Server Pool Area Configuration Mode chapter of the Command Line Interface Reference for more information.

Configuring MSC Fallback on Sv Interface

This section describes the configuration to enable the MSC Fallback feature.

To enable the MSC Fallback feature, the echo parameters should be configured under the MME Service Configuration Mode.

The MSC Fallback feature is license controlled. Contact your Cisco Account or Support representative for information on how to obtain a license.

To configure the echo parameters use the following configuration:

configure 
   context context_name 
      mme-service service_name 
         [ no ] msc-echo-params interval echo_interval retransmission-timeout timer_value max-retransmission number_of_retries reconnect-interval interval_value  
         end 
 

Notes:

  • By default, the MSC Fallback feature is disabled.

  • msc-echo-params configures EGTPC echo parameters for MSC Fallback. The msc-echo-params configuration overrides any echo parameter configured in the egtp-service configuration for the corresponding SV service.

  • interval is used to configure the time interval to send echo requests to an MSC. The interval ranges from 2 to 3600 seconds.

  • retransmission-timeout configures the echo retransmission timeout in seconds. The timer value ranges from 1 to 20 seconds.

  • max-retransmission configures the maximum number of echo retransmissions. The number of retransmissions is an integer from 0 to 15.

  • reconnect-interval configures the echo interval to be used once an MSC is detected to be unreachable. The time interval ranges from 60 to 86400 seconds.

  • Retransmission of ECHO requests is not applicable during the reconnect interval.

Disabling MSC Fallback Based on SRVCC Cause

By default, the MME supports MSC Fallback on Failure -- as explained in the section under Supported SRVCC Features. With the following configuration, the operator can selectively disable MSC fallback on failure during voice call handover.

The selection process is based on the SRVCC cause codes configured in the call-control profile. It there is a match with the MSC failure cause received in the PS-CS Response from the first MSC, then the MME fails the SRVCC HO and does not try the next available MSC.

configure 
   call-control-profile profile_name 
      msc-fallback-disable srvcc-cause cause 
      end 
 

Notes:

  • srvcc-cause : Use this keyword to define a single SRVCC cause code. The cause must be any integer from 0 to 255, as defined in 3GPP TS 29.280.

  • Repeat the command as needed to define additional SRVCC cause codes in the call-control profile.

  • This command is only applicable for PS-CS Requests and not for PS to CS complete messages.

MSC Offload

The MME allows an administrator to place one or more MSC server in maintenance mode. This action removes the MSC server as a possible selection target.

To offload and MSC, use the offline keyword at the end of the msc configuration command .

When the configuration is changed back to online , the MSC will be added back as a selection target and normal operation is returned.

configure 
   context <ctxt_name> 
      mme-service <service_name> 
         msc name [ ip-address address ] [ offline | online ] 
         end 

Notes:

  • No actual GTPv2 messages are generated when the configuration is changed to offline. The MSC is only removed as a selection target for future load sharing.

HSS Purge After SRVCC Handoff

The MME supports an optional configuration capability to perform the Purge UE procedure to the HSS for UEs which support Dual Transfer Mode (DTM). This feature is configurable via the CLI and is disabled by default. If configured, the MME initiates an HSS Purge after the following two SRVCC HO scenarios:
  • For SRVCC Handoff with PS Handoff support, the Purge S6a message is sent immediately after successful completion of the Handoff. For this scenario, the configurable purge timer is not used.
  • For SRVCC Handoff without PS Handoff support, a configurable timer is initiated and the Purge S6a message is sent if a SGSN Context Request is received prior to timer expiry. If a Context Failure occurs, no HSS Purge S6a message is sent.
This feature ensures the HSS has a reliable UE status on whether it is currently operating on the LTE network.

The following commands configure the MME to initiate an HSS Purge after the SRVCC HO where the UE supports DTM. It also allows configuration of a purge timeout value in seconds.

configure 
   context ctxt_name 
      mme-service service_name 
         policy srvcc purge-timer seconds  
         [ no ] policy srvcc purge-timer 
         end 
Notes:
  • purge-timer seconds : defines how long in seconds the Purge Timer will run. This is applicable only for SRVCC Handoff without PS Handoff support scenarios.
  • For example, if purge-timer is set to 20 seconds :

    If the Context Transfer happens 10 seconds after SRVCC HO, the MME initiates an HSS Purge.

    If the Context Transfer happens 30 seconds after SRVCC HO, the MME will NOT initiate an HSS Purge because the Purge Timer has expired.

Configuring SRVCC Handover Restriction

Use the following configuration to restrict SRVCC handovers to a roaming network:

configure 
   call-control-profile profile_name 
      [ remove ] srvcc unauthorized 
      end 

Notes:

  • srvcc : Configures the basic SRVCC support on the MME.

  • unauthorized : Restricts the SRVCC handovers for a set of subscribers.

  • remove : Removes the SRVCC confirmation from the Call Control Profile

Verifying SRVCC Handover Restriction

show call-control-profile full name name

The following new field is added to the output of this command to indicate the status of the SRVCC handover restriction:

  • When the srvcc command is not configured, the output of the command displays the following information:

    SRVCC Service        : Authorized
  • When the srvcc command is configured, the output of the command displays the following information:

    SRVCC Service        : Unauthorized

Verifying the SRVCC Configuration

The following command displays the MSC servers configured in the specified MME service:

show mme-service name service_name 
In the following example output:
  • msc1, msc2, and msc3 are configured with an IPv4 address.
  • msc3 is currently configured for MSC offload (offline).
SCTP Alternate Accept Flag           : Enabled 
MSC                                  : msc1  10.10.1.1 
MSC                                  : msc2  10.10.1.2 
MSC                                  : msc3  10.10.1.3   Offline 

The same command displays the context in which the DNS client configuration has been defined for the specified MME Service for DNS based MSC selection.

SGW DNS Context                      : Not defined 
MSC DNS Context                      : ingress 

The following command displays the context in which the DNS client configuration has been defined for the specified Call Control Profile for DNS based MSC selection:

show call-control-profile full name profile_name 
DNS MSC Context                      : ingress 

Monitoring and Troubleshooting SRVCC

SRVCC Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of SRVCC.

show mme-service all name

On executing the above command the following new fields are displayed:

  • MSC Echo Parameters:

    • Interval

    • retransmission-timeout

    • max retransmissions

    • reconnect interval

show mme-service msc-status

On executing the show mme-service msc-status [ mme-service-name name | msc-name name ] command, the following status information is displayed:

MSC Status 
Name:                 msc1 
IP:                   192.80.80.57 
Node Status:          Online 
Path State:           up 
MME Service Name:     mmesvc 
Static/DNS IP:        Static 

Note

  • When the MSC Fallback Feature is enabled, that is, when msc-echo-params is configured, the possible Path State values indicated are - Up, Down, and Unknown.

  • The Path State will indicate 'NA' if msc-echo-params is not configured or if the node is made "offline" using suitable commands.

  • New trace level logging event-id(s):

    • 147151 has been added in the MME-APP facility to monitor reachability status of the MSC, when the status changes.

    • 141120 to 141123 has been added for EGTPC layer debugging.

    • 143802 to 143815 for has been added for EGTPMGR layer debugging.


show mme-service statistics

This command displays SRVCC statistics for CS handovers with no Dual Transfer Mode (DTM), CS-only transfers, and CS and PS transfers.

EUTRAN-> UTRAN/GERAN using Sv Interface: 
      CS only handover with no DTM support: 
            Attempted:                        0  Success:                            0 
            Failures:                         0 
      CS only handover: 
            Attempted:                        0  Success:                            0 
            Failures:                         0 
      CS and PS handover: 
            Attempted:                        0  Success:                            0 
            Failures:                         0 

show egtpc statistics

This command displays EGTPC Sv interface statistics statistics for CS handovers with no Dual Transfer Mode (DTM), CS-only transfers, and CS and PS transfers.

SRVCC Messages: 
PS to CS  Request: 
 Total   TX:                          0 
 Initial TX:                          0 
 Retrans TX:                          0 
  Discarded:                          0 
 No Rsp Rcvd:                         0 
PS to CS Response: 
 Total   RX:                          0 
 Initial RX:                          0 
   Accepted:                          0 
     Denied:                          0 
  Discarded:                          0 
PS to CS Complete Notification: 
 Total   RX:                          0 
 Initial RX:                          0 
 Retrans RX:                          0 
  Discarded:                          0 
PS to CS Complete Acknowledge: 
 Total   TX:                          0 
 Initial TX:                          0 
   Accepted:                          0 
     Denied:                          0 
 Retrans TX:                          0 
  Discarded:                          0 
PS to CS Cancel Notification: 
 Total   TX:                          0 
 Initial TX:                          0 
 Retrans TX:                          0 
  Discarded:                          0 
 No Rsp Rcvd:                         0 
PS to CS Cancel Acknowledge: 
 Total   RX:                          0 
 Initial RX:                          0 
   Accepted:                          0 
     Denied:                          0 
  Discarded:                          0 

SRVCC Bulk Statistics

eGTP-C Schema

The following statistics are included in the eGTP-C Schema in support of SRVCC:

For descriptions of these variables, see "eGTP-C Schema Statistics" in the Statistics and Counters Reference.

  • srvcc-sent-pstocsreq
  • srvcc-sent-retranspstocsreq
  • srvcc-recv-pstocsrsp
  • srvcc-recv-pstocsrspDiscard
  • srvcc-recv-pstocsrspaccept
  • srvcc-recv-pstocsrspdenied
  • srvcc-recv-pstocscmpnotf
  • srvcc-recv-pstocscmpnotfDiscard
  • srvcc-recv-retranspstocscmpnotf
  • srvcc-sent-pstocscmpack
  • srvcc-sent-retranspstocscmpack
  • srvcc-sent-pstocscmpackaccept
  • srvcc-sent-pstocscmpackdenied
  • srvcc-sent-pstocscancelnotf
  • srvcc-sent-retranspstocscancelnotf
  • srvcc-recv-pstocscancelack
  • srvcc-recv-pstocscancelackDiscard
  • srvcc-recv-pstocscanelackaccept
  • srvcc-recv-pstocscancelackdenied

MME Schema

The following statistics are included in the MME Schema in support of SRVCC:

For descriptions of these variables, see "MME Schema Statistics" in the Statistics and Counters Reference.

  • s1-ho-4gto3g-cs-nodtm-sv-attempted
  • s1-ho-4gto3g-cs-nodtm-sv-success
  • s1-ho-4gto3g-cs-nodtm-sv-failures
  • s1-ho-4gto3g-cs-sv-attempted
  • s1-ho-4gto3g-cs-sv-success
  • s1-ho-4gto3g-cs-sv-failures
  • s1-ho-4gto3g-csps-sv-attempted
  • s1-ho-4gto3g-csps-sv-success
  • s1-ho-4gto3g-csps-sv-failures