SRVCC functionality is required within VoLTE systems to enable the packet domain calls received in LTE to be handed over to a legacy circuit-switched (CS) voice system, such as CDMA2000 1xRTT. SRVCC for 1xRTT, also referred to as enhanced SRVCC, enables the MME to move a VoLTE UE between an LTE and a 1xRTT network with smooth, seamless handovers. The MME acts as a relay agent to ensure CDMA2000 messages received from the UE are delivered to the interworking solution function (for 3GPP2, 1xCS IWS) associated with the mobile switching center (1x RTT MSC) (or vice-versa) through the S1-AP and S102 interfaces.

By using the MME's SRVCC for 1xRTT capabilities, the operator performs handovers while maintaining existing quality of service (QoS) and ensuring call continuity that meets the critical requirements for emergency calls.

This feature is license-controlled and the commands to configure and manage the feature interfaces require a feature license key. Speak with your Cisco Representative for information about this license. For information about the commands and their use, refer to the Configuring SRVCC for 1xRTT section later in this chapter.

The MME provides the following features in support of SRVCC for 1xRTT functionality:

MSC Pool Areas: Multiple MSCs would be handled by pooling all the MSCs mapping to a particular cell for load distribution. MSC pool areas can be configured for load balancing and intelligent selection of MSC servers based on IMSI hash values. Up to 10 MSC servers can be defined per S102 service.

MSC Non-Pool Areas: MSC selection, based on local MSC configuration.

MSC Selection: If an MSC pool area has been configured, the selection logic for the pool area is based on the CDMA2000 sector cell ID (includes the MSC ID and the Cell ID) in the CDMA2000 1xRTT network

Important

When the UE attaches with IMEI, the MSC configured for the non-pool area is always selected because IMSI hashing cannot be performed for that UE.

SRVCC for 1xRTT is related to the CSFB for 1xRTT feature. Each requires a separate license to take advantage of the separate functionality and use the configuration commands.

If licenses for both features are installed in the system and both features are configured, then the MME can use the S102 interface for both CSFB for 1xRTT and SRVCC for 1xRTT.

1xRTT SRVCC and 1xRTT CSFB calls will be decided based on the presence or absence of the CDMA2000 1xRTT SRVCC Info IEs in an Uplink S1 CDMA2000 Tunneling message. This IE should not present for a 1xRTT CSFB call. If only one feature is licensed and configured and if the above condition is not appropriately satisfied for any received call, then that call will be dropped.

The CSFB for 1xRTT feature is described elsewhere in this administration guide.

The call originating from the UE, and anchored as part of the voice-call continuity,.is part of a bidirectional process. The MME communicates with the 1xCS IWS (a circuit-switched fallback interworking solution function for 3GPP2 1xCS) to enable a single radio UE (an eSRVCC-enabled UE) to communicate in parallel with both the source system and the target system.

Typical SRVCC Call Flow

Step 19 of the SRVCC Call Flow procedure (outlined above), as defined by TS 23.216, provides a Subscriber Location Report to the GMLC. This function is currently not supported by the MME.

The MME's SRVCC for 1xRTT complies with the following standards:

config 
   context context_name 
      [ no ] s102-service service_name 
         [ no ] 1xRTT srvcc 
         [ no ] bind ipv4-address ipv4_address port port_number 
         [ no ] msc msc_name 
            [ no ] ipv4-address ipv4_address port port_number 
            exit 
         [ no ] msc msc_name 
            [ no ] ipv4-address ipv4_address port port_number 
            exit 
         end 

Notes:

Use the following to add an association between a previously configured MME service and an S102 service.

config 
   context context_name 
      mme-service mme_service_name  
         associate s102-service s102_service_name [ context context_name ] 
         end 

Notes:

The following process configures up to 10 MSC pool/non-pool areas per S102 service in support of MSC selection. Both the MSC-Id and the Cell-Id are used to locate the pool or non-pool area for the MSC selection process.

Prerequisite: Each of the MSCs must have been defined and associated with an S102 service (see Configuring the S102 Service noted above) before the MSC can be included in the non-pool-area or pool-area configuration.

Defining a Non-Pool Area

config 
      context context_name 
      [ no ] s102-service service_name 

Important

The plmn option that is visible in the code is not supported at this time and is included for future development.

         non-pool-area non_pool_area_name msc msc_name msc-id msc_id cell-id cell_id +   
         no non-pool-area non_pool_area_name cell-id cell_id +  

Notes:

Defining a Pool Area

config 
   context  context_name 
      s102-service service_name 
         [ no ] pool-area pool_area_name 
            [ no ] cell-id cell-id cell-id 
            [ no ] hash-value { hash_value | non-configured-values | range lower_hash_value to higher_hash_value } { msc msc_name } 
            [ no ] msc-id msc-id  
            [ no ] plmnid { any | mcc mcc_id mnc mnc_id } 
            end 

Notes:

When using the monitor protocol command, enable option 86 to see all A21 messages.

show s102-service statistics name s102_service_name

The command noted above generates statistical output indicating the status and activity of the interface. The output generated will appear similar to the following:

S102-AP Statistics: 
  S102-AP Data:                                Tx   ReTx   Rx 
    A21-1x Air Interface Signaling message     0     0     0 
     A21-Ack message                           0     0     0 
Unknown MSG                                    0     0     0 
Error Statistics: 
  Encoding Errors:                                0 
  Mismatch in Correlations:                       0 
  Decoding Errors:                                0 
    Missing Mandatory IEs:                        0 
    Syntax Errors:                                0 
  Misc Errors:                                    0 

Bulk statistics are described in the Statistics and Counters Reference.

MME Schema

The MME tracks the number of SRVCC 1xRTT calls and 4G-to-1xRTT handovers using the following variables:

S102 Schema

The MME will use the S102 interface to tunnel the 1xRTT messages between the MME and IWS/MSC. The S102 schema has been created to track performance over this interface and includes all of the following stat variables (which are described in detail in the Statistics and Counters Reference) :

Traps are defined to indicate when an S102 service starts or stops. The trap information includes the context identification in which the S102 service is configured the unique identification of the S102 service. The following are examples of how the traps would appear :

Internal trap notification <XXXX> (S102ServiceStop) context S102 service s102-service  

Internal trap notification <YYYY> (S102ServiceStart) context S102 service s102-service