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.