CSFB for 1xRTT

The MME supports circuit-switched fallback (CSFB) for CDMA2000 1x (single-carrier) radio transmission technology (1xRTT) networks as defined by 3GPP TS 23.272 R10.

CSFB for 1xRTT Feature Description

The primary purpose of circuit-switched fallback (CSFB) for 1xRTT is to take the CDMA2000 messages received from the caller's phone (UE) and relay them to the CSFB interworking solution function for 3GPP2 (1xCS IWS) associated with the mobile switching center (1x RTT MSC) (or vice-versa) through S1-APP and S102 interfaces. This ensures the UE moves seamlessly from an LTE network to a CDMA2000 network.

The MME uses the S102 interface to tunnel the 1xRTT messages between the MME and IWS/MSC to support the following CS services:

  • MO/MT Voice calls
  • MO/MT SMS
  • Emergency calls

This feature requires that a valid license key be installed to use the commands to configure this functionality. Speak with your Cisco Representative for information about this license. For information about the commands and their use, refer to the Configuring CSFB for 1xRTT section later in this chapter.

Supported Features

The MME provides the following features in support of CSFB 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

Both the MSC ID and the cell ID are used to locate the pool / non-pool area. The MME attempts to select an MSC using the following selection order:
  1. The MME attempts to match the MSC ID and the Cell ID:
    • If the match is found in the non-pool area configuration, then the configured MSC is selected.
    • If the match is found in the pool area configuration,
      • then IMSI hashing is used to select the MSC.
      • if no hash corresponds, then the MSC selected is the one configured for the 'non-configured-values'.
  2. If no MSC is found, a failure message is returned.

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.

DSCP Marking for S102 Interface

S102 interface allows Differentiated Services Code Point (DSCP) marking functionality. DSCP marking helps in packet traffic management. DSCP marking can be performed only on IPv4 packets leaving the S102 interface.

Either the pre-defined DSCP values can be used for marking, or any arbitrary value ranging from 0x01 to 0x3F can be assigned. The default DSCP value is 0x00 or be (Best Effort). The default DSCP value is automatically set when the configuration is disabled. 

config 
   context context_name  
      S102-service service_name  
         [no] ip qos-dscp dscp_value 
         end

  • ip defines the Internet Protocol parameters for the packets leaving through the S102 interface.

  • qos-dscp designates the Quality of Service - Differentiated Services Code Point value to the packet leaving through the S102 interface.

  • dscp_value is a value assigned to the packet for DSCP marking. The value can be a pre-defined DSCP value or an arbitrary value ranging from 0x01 to 0x3F.

Relationships to Other Features

CSFB for 1xRTT is related to the SRVCC 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 CSFB and 1xRTT SRVCC 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 SRVCC for 1xRTT feature is described elsewhere in this administration guide.

How It Works

Multiple components enable the MME to support CSFB for 1xRTT.

S1-App

The MME's CSFB for 1xRTT feature complies with 3GPP 36.413 Section 8.8, which define S1 CDMA2000 Tunneling Procedures to carry CDMA2000 signaling between a UE and a CDMA2000 RAT over S1 interface to perform:
  • signaling for preparation for handover from the E-UTRAN to the CDMA2000 /1xRTT, and
  • pre-registration and paging of the UE with the CDMA2000 1xRTT CS system.

These procedures use an established UE-associated logical S1-connection.

The CDMA2000 Tunneled messages are packaged and transported in the following messages:
  • DOWNLINK S1 CDMA2000 TUNNELING: If a CDMA2000 message needs to be sent from an MME to a given UE, the MME uses an existing S1 connection. The MME sends a DOWNLINK S1 CDMA2000 TUNNELING message, which includes the CDMA2000 message in a CDMA2000-PDU IE. Similarly, the MME sends other IE's, such as the CDMA2000 HO Status IE during Handover, through the DOWNLINK S1 CDMA2000 TUNNELING message.
  • UPLINK S1 CDMA2000 TUNNELING: When the eNB receives a CDMA2000 message intended for a UE, the eNB determines which MME has an existing UE-associated logical S1 connection. The eNB sends the UPLINK S1 CDMA2000 TUNNELING message to the MME. The UPLINK S1 CDMA2000 TUNNELING message includes the CDMA2000 message for the UE in the CDMA2000-PDU IE.

S102-App

Messages for the S102

The MME's S102 application is based on the UDP/IP transport medium. S102 (MME-to-IWS) /udp/23272 is the registered destination UDP port number to be used for signaling interconnection between an MME and an IWS for the S102 application.

The S102 application defines a set of messages between the MME and 1xCS IWS to provide CSFB. The MME uses a bound S102 interface to pass signaling messages (A21 messages) between the UE and the IWS:

  • A21-1x Air Interface Signaling message: When the MME receives an Uplink CDMA2000 message from the eNB, the MME sends an A21-1x air interface message to 1xCS IWS. The MME encapsulates the 1x air interface message in an A21-1x air interface signaling message and sends it to the 1xCS IWS via the S102 interface. This message type is used by the MME or 1xCS IWS during registration, paging, and mobile-originated / mobile-terminated SMS procedures.
  • A21-Ack message: This message is sent from an MME or a 1xCS IWS to acknowledge receipt of some A21 message to the peer 1xCS IWS or MME. The Correlation ID in an A21-Ack message is copied from the Request message to which the MME or 1xCS IWS is replying.
  • A21-Event Notification message: This message is sent by either the MME or the 1xCS IWS to notify the peer node of a specific event. The "S102 Redirection" value is used to indicate S102 tunnel redirection during MME relocation.

A21 Network/Transport Messaging Procedures.

The destination port number is set to 23272 in the UDP packet that carries an A21-1x Air Interface Signaling message or an A21-Event Notification message.

The receiver of an A21-1x Air Interface Signaling message or of an A21-Event Notification message shall set the source port and source IP address and the destination port and destination IP address of the UDP packet that carries the corresponding A21-Ack message to the destination port / destination IP address and the source port / source IP address of the UDP packet that carried the A21-1x Air Interface Signaling message or the A21-Event Notification message respectively.

MME-App

The UE performs the 1x-RTT pre-registration when it successfully attaches and then:
  1. The MME receives an S1-UPLINK CDMA2000 message in ATTACHED state from the eNB.
  2. The MME sends an A21 Air Interface message via the S102 interface to the IWS/MSC.
  3. The MME receives an A21 message from the IWS/MSC.
  4. The MME sends an S1 Downlink CDMA2000 message to the eNB.
The MO/MT call or SMS are handled in Idle and Connected modes:
  • In Connected mode, the EMM FSM will be in REGISTERED CONNECTED state. In this state, the messages from the MSC through the S102 messages are directly dispatched over the S1 interface through S1 DOWNLINK CDMA2000 messages.
  • In Idle mode, when an MT-call or an MT-SMS arrives from an MSC, the MME needs to trigger paging to make the UE return to CONNECTED state. During this time, S102 message is stored inside the S102 context. Once the UE returns to connected state the message is dispatched over the S1 interface.

Other Support Functions

Attach Procedure: As parts of the existing Attach procedure, the 1x RTT UE includes an indication of support for enhanced CSFB to 1xRTT. The UE context will be updated with this information for further processing.

TAU Procedure: The 1xRTT UE performs the Tracking Area Update with the MME change. After Location Update Ack is received from the HSS, theMME sends a Context Request to the old MME and the 1x CS IWS ID is sent back in the Context Response message. This information would be stored in the UE's context and would be used when the CSFB procedure performs S102 Tunnel Redirection.

eGTPC: Whenever there is a change of MME, the target MME gets the IWS-ID (the MSC address) through the Context Response message from the source MME. In the case of SRNS relocation, the source MME send the IWS-ID (the MSC address) through the Forward Relocation Request message, which is stored in the UE context and will be used in the S102 Redirection procedures.

Architecture

Figure 1. Architecture of the MME’s CSFB for 1xRTT


Flows

The following call flows are supported as defined by 3GPP TS 23.272, "Circuit Switched (CS) fallback in Evolved Packet System (EPS)":
  • 1xRTT CS Pre-Registration
  • S102 Tunnel Redirection
  • UE-Initiated Detach Procedure
  • MO Call - Normal CSFB to 1xRTT
  • MO Call - enhanced CSFB to 1xRTT
  • MT Call - Normal CSFB to 1xRTT
  • MT Call - enhanced CSFB to 1xRTT
  • Emergency Call
  • SMS Procedures

Limitations

  • SMS procedures will only apply if the UE is 1xRTT CS registered and the CS access domain is chosen by the UE and/or the home PLMN for delivering short messages.
  • The MME only buffers the last received SMS until the UE returns to connected state.

Standards Compliance

The CSFB for 1xRTT complies with the following standards:

  • 3GPP TS 23.401 Release 10, "GPRS enhancements for E-UTRAN access "
  • 3GPP TS 23.402 Release 10, "Architecture enhancements for non-3GPP accesses"
  • 3GPP TS 36.413 Release 10, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN) S1 Application Protocol (S1AP)".
  • 3GPP TS 23.272 Release 10, "Circuit Switched (CS) fallback in Evolved Packet System (EPS)"
  • 3GPP2 A.S0008-C Release 3.0, "Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Access Network".
  • 3GPP2 A.S0009-C Release 3.0, "Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Packet Control Function".
  • 3GPP2 A.S0013-D Release 3.0, "Interoperability Specification (IOS) for cdma2000 Access Network Interfaces"

Configuring CSFB for 1xRTT

If you have the appropriate license, you will be able to see and configure the commands identified below to
  • setup an S102 service for the use of an S102 interface.
  • associate the S102 service configuration with the MME service.
  • configure MSC selection.
  • allow/disallow CSFB service and/or SMS-only service via an Operator Policy.

Important

The first three sets of configuration must be completed for this feature to function.


Important

For more details on commands and keywords indicated below, we recommend that you refer to the Command Line Interface Reference, StarOS Release 19 or higher.

Configuring the S102 Service

This configuration enables you to define the characteristics for a specific S102 interface as an S102 service instance, including:
  • configuring the interface to work with CSFB for the 1xRTT CDMA2000 messaging.
  • binding or unbinding a logical IPv4 address and ports to the S102 service.
  • configuring an IPv4 address and ports for the IWS/MSC in the S102 service configuration. 
configure 
   context context_name 
      [ no ] s102-service service_name 
         [ no ] 1xRTT csfb 
            [ 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 
               end

Notes:

  • context_name enter a string of 1 to 79 alphanumeric characters to define the name of the context in which the S102 service is configured. You can configure the S102 service in the same context in which the associated MME service is configured.
  • service_name enter a string of 1 to 63 alphanumeric characters to define the name. We recommend that each service name be unique on this MME.
  • The MME supports configuration of an undefined number of S102 services (interfaces). As there is a 1-to-1 correlation between S102 service configurations and MME services, the only limiting factor is the maximum number of MME services that can be configured per system maximum number is 8.
  • 1xrtt configures the S102 interface to provide either CSFB or SRVCC capabilities for the 1xRTT CDMA2000 network The 1xrtt command can be repeated so that a single S102 interface provides both CSFB and SRVCC functionality.
  • bind ipv4-address ipv4_address port port_number binds the S102 interface to the specified source (MME) IPv4 interface address, and optionally to a specific port number if the port option is included. The value for the IPv4 address must be entered in standard IPv4 dotted-decimal notation and, if included, the port number must be an integer from 1 to 65535.
  • msc msc_name enter 1 to 63 alphanumeric characters to define a unique name for the MSC. Executing the msc command causes the system to enter the S102-MSC configuration mode to define the target IPv4 address (and optionally the port ID). This associates the S102 interface to the specified MSC.
  • ipv4-address ipv4_address port port_number identifies IPv4 interface address of the MSC, and optionally a specific port number if the port option is include. The value for the IPv4 address must be entered in standard IPv4 dotted-decimal notation and, if included, the port number must be an integer from 1 to 65535.
  • It is possible to associate up to 10 IWS/MSCs with the S102 interface/service configuration. Repeat the msc , ipv4-address , and exit commands sequence as often as needed to identify all MSCs.
  • no prefix included with a command, disables and/or erases the specified configuration from the MME's configuration.
  • default prefix is unused at this time and is available for future development.

Verify the S102 Service Configuration

Use the show s102-service name s102_service_name command to verify the S102 configuration that you have entered following the steps outlined above. The output will appear similar to the following: 

[local]MME show s102-service name s102-mme1 
Service name      : s102-mme1 
Context           : test 
Status            : NOT STARTED 
1xRTT type        : CSFB 
Bind              : Done 
IP Address        : nnn.nnn.nnn.1 
Port              : 54321 
 

Associating the S102 Service

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:

  • context context_name enter a string of 1 to 79 alphanumeric characters to identify the name of the context in which the S102 service is configured. We recommend that you identify the context if it is not the same one in which the associated MME service is configured.

Verifying the S102 Association

Use the show mme-service name mme_service_name command to verify the S102 association that you have entered following the steps outlined above. The output will appear similar to the following: 

[local]MME show mme-service name mme1 
Service name                         : mme1 
Context                              : test 
Status                               : NOT STARTED 
Bind                                 : Not Done 
. . . 
. . . 
IPNE Service                         : Not defined 
S102 Context                         : test 
S102 Service                         : s102-A 
Max bearers per MS                   : 11 
. . . 
. . .

Configuring MSC Selection

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:

  • non_pool_area_name enter a string of 1 to 63 alphanumeric characters to uniquely identify the non-pool-area definition used for MSC selection.
  • msc msc_name enter a string of 1 to 63 alphanumeric characters to identify one of the MSCs previously configured in the S102 service configuration.
  • msc-id msc_id cell-id cell_id +
    • msc_id enter an integer from 1 through 16777215 to identify the unique numeric ID for the MSC.
    • cell_id + enter an integer from 1 through 65535 to identify a CDMA2000 sector cell ID that you are assigning to this non-pool area configuration. Enter up to 24 cell IDs, separated by a single blank space, in the same command.
  • plmnid { any | mcc mcc_id mnc mnc_id } is not operationally supported at this time. The code is included for future development.
  • no prefix included with the command, erases or disables the specified configuration from the MME's configuration.

Defining a Pool Area 

config 
   context context_name 
      [ no ]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:

  • pool-area pool_area_name enter a string of 1 through 63 alphanumeric characters to create a unique name of an MSC pool area configuration. After the command is entered, the system enters the S102-Pool-Area configuration mode.
  • cell-id cell-id [ cell-id + ] enter an integer from 1 through 65535 to identify a CDMA2000 sector cell ID that you are assigning to this pool area configuration. Enter up to 24 cell IDs, separated by a single blank space, in the same command.
  • hash-value
    • hash_value enter an integer from 0 through 999 to identify a specific MSC.
    • non-configured-values msc msc_name assigns all non-configured hash values to use the named MSC.
    • range lower_hash_value to higher_hash_value msc msc_name specifies the range of hash values for an MSC:
      • lower_hash_value enter an integer from 0 through 999 to identify the start value for a range of hash. The lower_hash_value must be lower than higher_hash_value .
      • higher_hash_value enter an integer from 0 through 999 to identify the end value for a range of hash. The higher_hash_value must be higher than lower_hash_value .
  • msc_id enter an integer from 1 through 16777215 to identify the unique numeric ID for the MSC.
  • plmnid { any | mcc mcc_id mnc mnc_id } is not operationally supported at this time. The code is included for future development.
  • no prefix included with the command, erases the specified configuration from the MME's configuration.

Verifying Pool and Non-Pool Area Configuration

Use the show configuration command to view the S102 pool area and S102 non-pool area configuration. It should appear similar to the following: 

[local]MME show configuration  
 ... 
     s102-service s102test 
      bind ipv4-address 209.165.200.225 port 54321 
      1xrtt CSFB 
      msc msc1 
        ipv4-address nn2.nn2.nn2.2 port 33333 
      exit 
      msc msc10 
        ipv4-address nn1.nn2.nn1.2 port 23272 
      exit 
      pool-area poolone 
        cell-id 2 4 5 
        hash-value 34 msc msc10 
      exit 
      non-pool-area np1 msc msc1 msc-id 1233 cell-id 223 
      non-pool-area np3 msc msc1 msc-id 14441 cell-id 6 7 8

Allowing CSFB and/or SMS-only in the Operator Policy

The operator can configure the type of CSFB service the MME provides at the Operator Policy level.

Enabling SMS-only

The following configuration sequence instructs the MME that the CSFB function will only support SMS. 

config 
   call-control-profile ccprof_name 
      [ remove ] csfb sms-only 
      end

Notes:

  • remove prefix included with the command, erases the specified configuration from the Call-Control Profile configuration.

Enabling CSFB for Voice and SMS

The following configuration sequence instructs the MME that the CSFB function is

  • not allowed for both voice and SMS, or
  • only allowed for SMS. 
config 
   call-control-profile ccprof_name 
      [ remove ] csfb policy { not-allowed | sms-only } 
      end

Notes:

  • remove prefix included with the command, erases the specified configuration from the Call-Control Profile configuration.

Verifying the Call-Control Profile Configuration

Use the show call-control-profile full name command to display the configuration entered with the procedures outlined above. The output should appear similar to the following: 

[local]MME show call-control-profile full name ccprof1 
Call Control Profile Name = ccprof1 
SAMOG Home PLMN                                                        : Not configured 
CSFB Restrictions 
     SMS Only                                                          : TRUE 
     Not Allowed                                                       : FALSE 
   

Monitoring and Troubleshooting the CSFB for 1xRTT

Monitoring Protocol

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

Show Command(s) and/or Outputs

show s102-service statistics name

The show s102-service statistics name s102_service_name command 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

Bulk statistics are described in the Statistics and Counters Reference.

MME Schema

The MME tracks the number of CSFB 1xRTT calls using the following variables:

  • s1ap-transdata-dlinktunnel
  • s1ap-recdata-ulinktunnel

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) :

  • vpnname
  • vpnid
  • servname
  • servid
  • s102ap-tx-a21-air-signal-msg
  • s102ap-tx-a21-ack-msg
  • s102ap-tx-a21-evt-ntfy-msg
  • s102ap-tx-unknown-msg
  • s102ap-retx-a21-air-signal-msg
  • s102ap-retx-a21-ack-msg
  • s102ap-retx-a21-evt-ntfy-msg
  • s102ap-retx-unknown-msg
  • s102ap-rx-a21-air-signal-msg
  • s102ap-rx-a21-ack-msg
  • s102ap-rx-a21-evt-ntfy-msg
  • s102ap-rx-unknown-msg
  • s102ap-encode-errors
  • s102ap-missing-mandatory-ies
  • s102ap-corelation-mismatch
  • s102ap-decode-errors
  • s102ap-syntax-errors
  • s102ap-misc-errors

Traps

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