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.

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.

The MME implementation of SRVCC complies with the following standards:

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 egtpc-sv-service egtpc_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

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:

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

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

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:

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

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

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

show mme-service name service_name

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