Mobility Management Entity Configuration

This chapter provides configuration information for the Mobility Management Entity (MME).

Because each wireless network is unique, the system is designed with a variety of parameters allowing it to perform in various wireless network environments. In this chapter, only the minimum set of parameters are provided to make the system operational. Optional configuration commands specific to the MME product are located in the Command Line Interface Reference.

The following procedures are located in this chapter:

IMPORTANT:

At least one Packet Services Card (PSC/PSC2) must be made active prior to service configuration. Information and instructions for configuring PSCs/PSC2s to be active can be found in the Configuring System Settings chapter of the System Administration Guide.

CAUTION:

While configuring any base-service or enhanced feature, it is highly recommended to avoid conflicting or blocked IP addresses and port numbers when binding or assigning these to your configuration. In association with some service steering or access control features, the use of inappropriate port numbers may result in communication loss. Refer to the respective feature configuration document carefully before assigning any port number or IP address for communication with internal or external networks.

IMPORTANT:

Information about all commands in this chapter can be found in the Command Line Interface Reference.

Configuring the System as a Standalone MME (base configuration)

This section provides a high-level series of steps and associated configuration file examples for configuring the system to perform as an MME in a test environment. For a more robust configuration example, refer to the Sample Configuration Files appendix.

The configuration in this section assumes the following:

  • A single context for all interfaces and services (excepting the Local context)
  • static S-GW/P-GW selection (MME Policy configuration)

Information provided in this section includes the following:

Information Required

The following sections describe the minimum amount of information required to configure and make the MME operational on the network. To make the process more efficient, it is recommended that this information be available prior to configuring the system.

There are additional configuration parameters that are not described in this section. These parameters deal mostly with fine-tuning the operation of the S-GW in the network. Information on these parameters can be found in the appropriate sections of the Command Line Interface Reference.

Required MME Context Configuration Information

The following table lists the information that is required to configure the MME context.
Table 1. Required Information for MME Context Configuration
Required Information Description

MME context name

An identification string from 1 to 79 characters (alpha and/or numeric) by which the MME context is recognized by the system.

S1-MME Interface Configuration (To/from eNodeB)

Interface name

An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system.

Multiple names are needed if multiple interfaces will be configured.

IP address and subnet

IPv4 or IPv6 address assigned to the S1-MME interface. This address will be used for binding the SCTP (local bind address(es)) to communicate with the eNodeBs using S1-AP.

Multiple addresses and subnets are needed if multiple interfaces will be configured.

Physical port number

The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17.

A single physical port can facilitate multiple interfaces.

S11 Interface Configuration (To/from S-GW)

Interface name

An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system.

Multiple names are needed if multiple interfaces will be configured.

IP address and subnet

IPv4 address assigned to the S11 interface.

Multiple addresses and subnets are needed if multiple interfaces will be configured.

Physical port number

The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17.

A single physical port can facilitate multiple interfaces.

S6a Interface Configuration (To/from HSS)

Interface name

An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system.

Multiple names are needed if multiple interfaces will be configured.

IP address and subnet

IPv4 or IPv6 addresses assigned to the S6a interface.

Multiple addresses and subnets are needed if multiple interfaces will be configured.

Physical port number

The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17.

A single physical port can facilitate multiple interfaces.

S6a Diameter Endpoint Configuration

End point name

An identification string from 1 to 63 characters (alpha and/or numeric) by which the S6a Diameter endpoint configuration is recognized by the system.

Origin realm name

An identification string between 1 through 127 characters.

The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.

Origin host name

An identification string from 1 to 255 characters (alpha and/or numeric) by which the S6a origin host is recognized by the system.

Origin host address

The IP address of the S6a interface.

Peer name

The S6a endpoint name described above.

Peer realm name

The S6a origin realm name described above.

Peer address and port number

The IP address and port number of the HSS.

Route-entry peer

The S6a endpoint name described above.

S13 Interface Configuration (To/from EIR)

Interface name

An identification string between 1 and 79 characters (alpha and/or numeric) by which the interface is recognized by the system.

Multiple names are needed if multiple interfaces will be configured.

IP address and subnet

IPv4 or IPv6 addresses assigned to the S13 interface.

Multiple addresses and subnets are needed if multiple interfaces will be configured.

Physical port number

The physical port to which the interface will be bound. Ports are identified by the chassis slot number where the line card resides followed by the number of the physical connector on the card. For example, port 17/1 identifies connector number 1 on the card in slot 17.

A single physical port can facilitate multiple interfaces.

S13 Diameter Endpoint Configuration

End point name

An identification string from 1 to 63 characters (alpha and/or numeric) by which the S13 Diameter endpoint configuration is recognized by the system.

Origin realm name

An identification string between 1 through 127 characters.

The realm is the Diameter identity. The originator’s realm is present in all Diameter messages and is typically the company or service name.

Origin host name

An identification string from 1 to 255 characters (alpha and/or numeric) by which the S13 origin host is recognized by the system.

Origin host address

The IP address of the S13 interface.

Peer name

The S13 endpoint name described above.

Peer realm name

The S13 origin realm name described above.

Peer address and port number

The IP address and port number of the EIR.

Route-entry peer

The S13 endpoint name described above.

MME Service Configuration

MME service name

An identification string from 1 to 63 characters (alpha and/or numeric) by which the MME service can be identified on the system. It is configured in the Context configuration mode.

Multiple names are needed if multiple MME services will be configured.

PLMN identifier

The identifier of Public Land Mobile Network (PLMN) of which MME belongs to. PLMN identifier is consisting of MCC and MNC.

MME identifier

The identifier of MME node. The MME Id is consisting of MME group and MME code.

TAI management database name

An identification string from 1 to 64 characters (alpha and/or numeric) by which the TAI management database service can be associated with the MME service.

This is required for static S-GW selection. Refer to the Required MME Policy Configuration Information section below.

P-GW IP address

IPv4 or IPv6 address of a PDN Gateway (P-GW). This is required for static S-GW/P-GW selection.

eGTP Service Configuration

eGTP service name

An identification string from 1 to 63 characters (alpha and/or numeric) by which the eGTP service can be associated with MME system.

Multiple names are needed if multiple eGTP services will be used.

Interface type

Identifies the type of interface to which the eGTP service is bound. This interface type is “interface-mme”.

GTP-C binding IP address

The IPv4 address of the S11 interface.

HSS Peer Service Configuration

HSS peer service name

An identification string from 1 to 63 characters (alpha and/or numeric) by which the HSS peer service is recognized by the system.

Multiple names are needed if multiple HSS peer services will be used.

Diameter HSS peer

The name for a pre-configured Diameter endpoint, configured on system to associate with this MME service to access an HSS and an EIR. This is the S6a Diameter endpoint name.



Required MME Policy Configuration Information

The following table lists the information that is required to configure the MME Policy on an MME.
Table 2. Required Information for MME Policy Configuration
Required Information Description

Tracking Area Identifier (TAI) management database name

An identification string from 1 to 64 characters (alpha and/or numeric) by which the TAI management database is recognized by the system.

Tracking Area Identifier (TAI) management object name

An identification string from 1 to 64 characters (alpha and/or numeric) by which the TAI management object is recognized by the system.

MCC, MNC, and TAC

The Mobile Country Code, Mobile Network Code, and Tracking Area Code for the S-GW this management object represents.

S-GW IP address

The IPv4 or IPv6 address of the S-GW this management object represents.


How This Configuration Works

The following figure and supporting text describe how this configuration with a single context is used by the system to process a subscriber call originating from the GTP LTE network.

  1. The eNodeB forwards an Attach Request message from the UE to the MME containing the IMSI, last visited TAI (if available), the UE’s core network capability, the PDN Type, and the Attach Type.
  2. The MME service receives the Attach Request message and references the HSS peer service for authentication and location resolution.
  3. The HSS peer service configuration specifies the Diameter configuration and S6a interface to use to communicate with the HSS and the Diameter configuration and S13 interface to use to communicate with the Equipment Identity Register (EIR).
  4. Assuming that the MME has no previous security context, it sends an S6a Authentication Request to the HSS and uses the authentication vectors received in the response to complete the authentication procedure with UE.
  5. After authentication, the MME proceeds to do a security setup with the UE. During this procedure, the ME identity is transferred to the MME which then queries the EIR.
  6. The MME then sends an Update Location Request to the HSS and obtains relevant subscription data for the IMSI in the response.
  7. The MME policy is accessed to determine the S-GW and P-GW to which the UE should be attached.
  8. The MME uses the S11 interface bound to the eGTP service to communicate with the S-GW specified by the MME policy configuration.
  9. The MME then sends a Create Session Request to S-GW which is also forwarded to the specified P-GW (assuming GTP-S5/S8) P-GW establishes the S5/S8 GTPU bearers and then responds with a Create-Session-response which is forwarded to the MME by the S-GW. The S-GW includes the relevant S1-U bearer information.
  10. The MME then sends a NAS Attach Accept embedded in the S1 Init Ctxt Setup request to the eNodeB. The Attach Accept contains the IP address allocated to the PDN and the temporary identifier (GUTI) assigned to the UE. The MME waits for positive acknowledgement from both the eNodeB (Init Ctxt Setup response) and UE (Attach Complete). The Init Ctxt Setup Response contains the S1-U bearer endpoint information. The MME then uses the S11 Modify Bearer Request to update the eNodeB endpoints with the S-GW. The receipt of the S11 Modify Bearer Response completes the end-to-end bearer setup.
  11. The MME then uses the S6a Notify Request to update the HSS with the APN and P-GW identity.

MME Configuration

To configure the system to perform as a standalone eGTP S-GW, review the following graphic and subsequent steps.

  1. Set system configuration parameters such as activating PSCs by applying the example configurations found in the System Administration Guide.
  2. Create the MME context, service, and all interfaces, and bind the S1-MME interface to an IP address by applying the example configuration in the Creating and Configuring the MME Context and Service section.
  3. Create the eGTP service and associate it with the S11 interface by applying the example configuration in the Creating and Configuring the eGTP Service and Interface Association section.
  4. Create the HSS peer service and associate it with the S6a interface and S13 interface by applying the example configuration in the Creating and Configuring the HSS Peer Service and Interface Associations section.
  5. Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

Creating and Configuring the MME Context and Service

Use the following example to configure the MME context and all supported interfaces:

configure
   context
<mme_context_name>
-noconfirm
      interface
<s1-mme_intf_name>
         ip
address <ipv4_address>
         exit
      interface <s11_intf_name>
         ip
address <ipv4_address>
         exit
      interface <s6a_intf_name>
         ip
address <ipv4_address>
         exit
      interface <s13_intf_name>
         ip
address <ipv4_address>
         exit
      mme-service
<mme_svc_name>
-noconfirm
         mme-id
group-id <grp_id>
mme-code <mme_code>
         plmn-id
mcc <mcc_value>
mnc <mnc_value>
         associate
egtp-service <egtp-service_name>
context <mme_context_name>
         associate
hss-peer-service <hss_peer_service_name>
context <mme_context_name>
         policy
attach imei-query-type imei-sv verify-equipment-identity
         pgw-address
<pgw_ip_address> 
         bind
s1-mme ipv4-address <ip_address>
         exit
      exit
   port
ethernet <slot_number/port_number>
      no
shutdown
      bind
interface <s1-mme_intf_name> <mme_context_name>
      end
Notes:
  • All interfaces in this configuration can also be specified as IPv6 addresses using the ipv6 address command.
  • Multi-homing is supported on the S1-MME and S6a interfaces. Refer to the Configuring SCTP Multi-homing Support section in this chapter for more information on configuring multi-homing for the S1-MME and/or S6a interface(s).
  • A maximum of 256 services (regardless of type) can be configured per system.
  • The bind s1-mme command can also be specified as an IPv6 address using the ipv6-address keyword.
  • The eGTP service is configured in the following section.
  • The HSS peer service is configured in the Creating and Configuring the HSS Peer Service and Interface Associations section.
  • In the above example, the mobile equipment identity (IMEI) is checked during the attach procedure. This is configured in the policy attach command. Another option is to check IMEI during the tracking area update (TAU). This can be accomplished instead of, or, in addition to, the EIR query during the attach procedure. To check during the TAU, use the policy tau command.
  • The pgw-address command is used to statically configure P-GW discovery.

Creating and Configuring the eGTP Service and Interface Association

Use the following example to create an eGTP service and associate it with the S11 interface.

configure
   context <mme_context_name>
      egtp-service <egtp_service_name>
         interface-type
interface-mme 
         gtpc
bind ipv4-address <s11_infc_ip_address>
         exit
      exit
   port
ethernet <slot_number/port_number>
      no
shutdown
      bind
interface <s11_interface_name> <mme_context_name>
      end
Notes:
  • The gtpc bind command can be specified as an IPv6 address using the ipv6-address keyword. The interface specified for S11 communication must also be the same IPv6 address.

Creating and Configuring the HSS Peer Service and Interface Associations

Use the following example to create and configure the HSS peer service:

configure
   context <mme_context_name>
      hss-peer-service hss_peer_service_name
         diameter
hss-endpoint <hss_endpoint_name>
eir-endpoint <eir-endpoint_name>
         exit 
      exit 
   diameter
endpoint <hss-endpoint_name>
      origin
realm <realm_name>
      origin
host <name>
address <S6a_interface_address>
      peer
<peer_name>
realm <realm_name>
address <hss_ip_address>
      route-entry
realm <realm_name> peer
<peer_name>
      exit
   diameter
endpoint <eir-endpoint_name>
      origin
realm <realm_name>
      origin
host <name>
address <S13_interface_address>
      peer
<peer_name>
realm <realm_name>
address <eir_ip_address>
      route-entry
realm <realm_name> peer
<peer_name>
      exit
   port
ethernet <slot_number/port_number>
      no
shutdown
      bind
interface <s6a_interface_name> <mme_context_name>
      exit
   port
ethernet <slot_number/port_number>
      no
shutdown
      bind
interface <s13_interface_name> <mme_context_name>
      end
Notes:
  • The origin host and peer commands can accept multiple IP addresses supporting multi-homing on each endpoint. Refer to the Configuring SCTP Multi-homing Support section for information on configuring SCTP multi-homing for the S6a interface.

Configuring Optional Features on the MME

The configuration examples in this section are optional and provided to cover the most common uses of the MME in a live network. The intent of these examples is to provide a base configuration for testing.

The following optional configurations are provided in this section:

Configuring Circuit Switched Fallback

The configuration example in this section creates an SGs interface and an SGs service for communicating with a Mobile Switching Center/Visitor Location Register (MSC/VLR) for Circuit Switched Fallback capability.

IMPORTANT:

Circuit Switched Fallback is a licensed feature and requires the purchase of the Circuit Switched Fallback feature license to enable it.

Use the following configuration example to enable Circuit Switched Fallback capability on the MME:

configure
   lte-policy
      tai-mgnt-db <db_name>
         tai-mgmt-obj <object_name>
            lai
mcc <number>
mnc <number>
lac <area_code>
            tai
mcc <number>
mnc <number>
tac <area_code>
            exit
         exit
      exit
   context
<mme_context_name>
-noconfirm
      interface <sgs_intf_name>
         ip
address <ipv4_address>
         exit
      sgs-service
<name>
-noconfirm
         sctp
port <port_number>
         tac-to-lac-mapping
tac <value>
map-to lac <value> +
         vlr
<vlr_name>
ipv4-address <ip_address>
port <port_number>
         pool-area <pool_name>
            lac
<area_code> +
            hash-value
non-configured-value use-vlr <vlr_name>
            hash-value
range <value> to
<value>
use-vlr <vlr_name>
            exit
         bind
ipv4-address <sgs-intf_ipv4_address>
         exit
      mme-service <service_name>
         associate
tai-mgmt-db <db_name>
         associate
sgs-service <sgs_svc_name>
         end
Notes:
  • The SGs IP address can also be specified as an IPv6 address. To support this, the ip address command can be changed to the ipv6 address command and the bind ipv4-address command can be changed to bind ipv6-address command.This command also allows for the configuration of a secondary IP address in support of SCTP multi-homing.
  • Multiple TAC-to LAC values can be entered in the same configuration line.
  • Multiple LAC values can be entered in the same configuration line.
  • The VLR interface (vlr command) also supports IPv6 addressing and SCTP multi-homing.

Configuring Dual Address Bearers

This example configures support for IPv4/v6 PDNs.

Use the following configuration example to enable support on the MME for dual-address bearers:

configure
   context
<mme_context_name>
-noconfirm
      mme-service <mme_svc_name>
         policy
network dual-addressing-support
         end

Configuring Dynamic Peer Selection

The configuration in this section replaces static configurations on the MME for the following peer components: MME, P-GW, S-GW, SGSN.

Use the following example to configure dynamic P-GW, S-GW, and peer MME selection through a DNS interface:

configure
   context
<mme_context_name>
-noconfirm
      interface <dns_intf_name>
         ip
address <ipv4_address>
         exit
      ip
domain-lookup
      ip
name-servers <dns_ip_address>
      dns-client <name>
         bind
address <dns_intf_ip_address>
         exit
      mme-service <mme_svc_name>
         dns
pgw
         dns
sgw
         dns
peer-mme
         dns
peer-sgsn
         end
Notes:
  • For the dns pgw, dns sgw, dns peer-mme, and dns peer-sgsn commands, the DNS client service must exist in the same context as the MME service. If the DNS client resides in a different context, the contex <ctx_name> command/variable must be added to the command(s).

Configuring Gn/Gp Handover Capability

The example configuration in this section provides 3G to 4G handover capabilities between the MME and a Gn/Gp SGSN. The configuration creates the Gn interface used for control signalling during the handover.

Use the following configuration example to create a Gn interface and configure the control interface on the MME for Gn/Gp handovers:

configure
   context
<mme_context_name>
-noconfirm
      interface <Gn_intf_name>
         ip
address <ipv4_address>
         exit
      sgtp-service <sgtp_svc_name>
         gtpc
bind address <Gn_intf_ip_address>
         exit
      mme-service <mme_svc_name>
         associate
sgtpc-service <sgtp_svc_name>
         peer-sgsn
rai mcc <mcc_value> mnc
<mnc_value>
rac <value>
lac <value>
address <ip_address> capability
gn
         nri
length <length>
plmn-id mcc <mcc_value>
mnc <mnc_value>
         end
Notes:
  • The peer-sgsn command is used to statically configure a peer SGSN. SGSN selection can also be performed dynamically through the DNS client. For more information about dynamic peer selection, refer to the Configuring Dynamic Peer Selection section in this chapter.
  • If dynamic peer-SGSN selection is configured, an additional gtpc command must be added to the SGTP service: gtpc dns-sgsn contex <cntxt_name>
  • In the absence of an NRI length configuration, the MME treats the NRI as invalid. The MME will use a plain RAI-based FQDN (and not an NRI-based FQDN) for DNS queries made to resolve the source SGSN.

Configuring Inter-MME Handover Support

Use the following example to configure inter-MME handover support:

configure
   context
<mme_context_name>
-noconfirm
      interface <s10_intf_name>
         ip
address <ipv4_address>
         exit
      egtp-service <egtp_service_name>
         interface-type
interface-mme 
         gtpc
bind ipv4-address <s10_infc_ip_address>
         exit
      exit
      mme-service <mme_svc_name>
         peer-mme
gummei mcc <number> mnc
<number>
group-id <id>
mme-code <code>
address <ipv4_address> 
         exit
      exit
   port
ethernet <slot_number/port_number>
      no
shutdown
      bind
interface <s10_interface_name> <mme_context_name>
      end
Notes:
  • The peer-mme command can also be configured to acquire a peer MME through the use of a TAI match as shown in this command example: peer-mme tai-match priority <value> mcc <number> mnc <number> tac any address <ipv4_address>
  • The peer-mme command is used to statically configure a peer MME. MME selection can also be performed dynamically through the DNS client. For more information about dynamic peer selection, refer to the Configuring Dynamic Peer Selection section in this chapter.
  • The peer MME IP address can also be specified as an IPv6 address.

Configuring X.509 Certificate-based Peer Authentication

The configuration example in this section enables X.509 certificate-based peer authentication, which can be used as the authentication method for IP Security on the MME.

IMPORTANT:

Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

The following configuration example enables X.509 certificate-based peer authentication on the MME.

In Global Configuration Mode, specify the name of the X.509 certificate and CA certificate, as follows:

configure
   certificate
name <cert_name>
pem url <cert_pem_url>
private-key pem url <private_key_url>
   ca-certificate
name <ca_cert_name> pem
url <ca_cert_url>
   end
Notes:
  • The certificate name and ca-certificate list ca-cert-name commands specify the X.509 certificate and CA certificate to be used.
  • The PEM-formatted data for the certificate and CA certificate can be specified, or the information can be read from a file via a specified URL as shown in this example.

When creating the crypto template for IPSec in the Context Configuration Mode, bind the X.509 certificate and CA certificate to the crypto template and enable X.509 certificate-based peer authentication for the local and remote nodes, as follows:

configure
   context <mme_context_name>
      crypto
template <crypto_template_name>
ikev2-dynamic
         certificate
name <cert_name>
         ca-certificate
list ca-cert-name <ca_cert_name>
         authentication
local certificate
         authentication
remote certificate
         end
Notes:
  • A maximum of sixteen certificates and sixteen CA certificates are supported per system. One certificate is supported per service, and a maximum of four CA certificates can be bound to one crypto template.
  • The certificate name and ca-certificate list ca-cert-name commands bind the certificate and CA certificate to the crypto template.
  • The authentication local certificate and authentication remote certificate commands enable X.509 certificate-based peer authentication for the local and remote nodes.

Configuring Dynamic Node-to-Node IP Security on the S1-MME Interface

The configuration example in this section creates an IKEv2/IPSec dynamic node-to-node tunnel endpoint on the S1-MME interface.

IMPORTANT:

Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

The following configuration examples are included in this section:

Creating and Configuring an IPSec Transform Set

The following example configures an IPSec transform set which is used to define the security association that determines the protocols used to protect the data on the interface:

configure
   context <mme_context_name>
      ipsec
transform-set <ipsec_transform-set_name>
         encryption
aes-cbc-128
         group
none
         hmac
sha1-96
         mode
tunnel
         end
Notes:
  • The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IPSec transform sets configured on the system.
  • The group none command specifies that no crypto strength is included and that Perfect Forward Secrecy is disabled. This is the default setting for IPSec transform sets configured on the system.
  • The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IPSec transform sets configured on the system.
  • The mode tunnel command specifies that the entire packet is to be encapsulated by the IPSec header including the IP header. This is the default setting for IPSec transform sets configured on the system.

Creating and Configuring an IKEv2 Transform Set

The following example configures an IKEv2 transform set:

configure
   context <mme_context_name>
      ikev2-ikesa
transform-set <ikev2_transform-set_name>
         encryption
aes-cbc-128
         group
2
         hmac
sha1-96
         lifetime <sec>
         prf
sha1
         end
Notes:
  • The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IKEv2 transform sets configured on the system.
  • The group 2 command specifies the Diffie-Hellman algorithm as Group 2, indicating medium security. The Diffie-Hellman algorithm controls the strength of the crypto exponentials. This is the default setting for IKEv2 transform sets configured on the system.
  • The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.
  • The lifetime command configures the time the security key is allowed to exist, in seconds.
  • The prf command configures the IKE Pseudo-random Function, which produces a string of bits that cannot be distinguished from a random bit string without knowledge of the secret key. The sha1 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

Creating and Configuring a Crypto Template

The following example configures an IKEv2 crypto template:

configure
   context <mme_context_name>
      crypto
template <crypto_template_name>
ikev2-dynamic
         authentication
local pre-shared-key key <text>
         authentication
remote pre-shared-key key <text>
         ikev2-ikesa
transform-set list <name1>
. . . <name6>
         ikevs-ikesa
rekey
         payload
<name>
match childsa match ipv4
            ipsec
transform-set list <name1>
. . . <name4>
            rekey
            end
Notes:
  • The ikev2-ikesa transform-set list command specifies up to six IKEv2 transform sets.
  • The ipsec transform-set list command specifies up to four IPSec transform sets.

Binding the S1-MME IP Address to the Crypto Template

The following example configures the binding of the S1-MME interface to the crypto template:

configure
   context <mme_context_name>
      mme-service <mme_svc_name>
         bind
s1-mme ipv4-address <address>
ipv4-address <address> crypto-template <enodeb_crypto_template>
         end
Notes:
  • The bind command in the MME service configuration can also be specified as an IPv6 address using the ipv6-address command.
  • This example shows the bind command using multi-homed addresses. The multi-homing feature also supports the use of IPv6 addresses.

Configuring ACL-based Node-to-Node IP Security on the S1-MME Interface

The configuration example in this section creates an IKEv2/IPSec ACL-based node-to-node tunnel endpoint on the S1-MME interface.

IMPORTANT:

Use of the IP Security feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

The following configuration examples are included in this section:

Creating and Configuring a Crypto Access Control List

The following example configures a crypto ACL (Access Control List), which defines the matching criteria used for routing subscriber data packets over an IPSec tunnel:

configure
   context <mme_context_name>
      ip
access-list <acl_name>
         permit
tcp host <source_host_address>
host <dest_host_address>
         end
Notes:
  • The permit command in this example routes IPv4 traffic from the server with the specified source host IPv4 address to the server with the specified destination host IPv4 address.

Creating and Configuring an IPSec Transform Set

The following example configures an IPSec transform set which is used to define the security association that determines the protocols used to protect the data on the interface:

configure
   context <mme_context_name>
      ipsec
transform-set <ipsec_transform-set_name>
         encryption
aes-cbc-128
         group
none
         hmac
sha1-96
         mode
tunnel
         end
Notes:
  • The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IPSec transform sets configured on the system.
  • The group none command specifies that no crypto strength is included and that Perfect Forward Secrecy is disabled. This is the default setting for IPSec transform sets configured on the system.
  • The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IPSec transform sets configured on the system.
  • The mode tunnel command specifies that the entire packet is to be encapsulated by the IPSec header including the IP header. This is the default setting for IPSec transform sets configured on the system.

Creating and Configuring an IKEv2 Transform Set

The following example configures an IKEv2 transform set:

configure
   context <mme_context_name>
      ikev2-ikesa
transform-set <ikev2_transform-set_name>
         encryption
aes-cbc-128
         group
2
         hmac
sha1-96
         lifetime <sec>
         prf
sha1
         end
Notes:
  • The encryption algorithm, aes-cbc-128, or Advanced Encryption Standard Cipher Block Chaining, is the default algorithm for IKEv2 transform sets configured on the system.
  • The group 2 command specifies the Diffie-Hellman algorithm as Group 2, indicating medium security. The Diffie-Hellman algorithm controls the strength of the crypto exponentials. This is the default setting for IKEv2 transform sets configured on the system.
  • The hmac command configures the Encapsulating Security Payload (ESP) integrity algorithm. The sha1-96 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.
  • The lifetime command configures the time the security key is allowed to exist, in seconds.
  • The prf command configures the IKE Pseudo-random Function which produces a string of bits that cannot be distinguished from a random bit string without knowledge of the secret key. The sha1 keyword uses a 160-bit secret key to produce a 160-bit authenticator value. This is the default setting for IKEv2 transform sets configured on the system.

Creating and Configuring a Crypto Map

The following example configures an IKEv2 crypto map:

configure
   context <mme_context_name>
      crypto
map <crypto_map_name> ikev2-ipv4
         match
address <acl_name>
         peer <ipv4_address>
         authentication
local pre-shared-key key <text>
         authentication
remote pre-shared-key key <text>
         ikev2-ikesa
transform-set list  <name1>
. . .  <name6>
         payload
<name>
match ipv4
            lifetime <seconds>
            ipsec
transform-set list <name1>
. . . <name4>
            exit
         exit
      interface
<s1-mme_intf_name>
         ip
address <ipv4_address>
         crypto-map <crypto_map_name>
         exit
      exit
   port
ethernet <slot_number/port_number>
      no
shutdown
      bind
interface <s1-mme_intf_name> <mme_context_name>
      end
Notes:
  • The type of crypto map used in this example is IKEv2-IPv4 for IPv4 addressing. An IKEv2-IPv6 crypto map can also be used for IPv6 addressing.
  • The ipsec transform-set list command specifies up to four IPSec transform sets.

Configuring Load Balancing on the MME

In networks that contain multiple MMEs configured as a pool, load balancing is a necessary feature allowing UE attachments to be spread accross the pool instead of a small number of MMEs.

The following example configures load balancing on an MME:

configure
   context <mme_context_name>
      mme-service <mme_svc_name>
         relative-capacity <number>
         end
Notes:
  • The relative-capacity command specifies a weight factor used in comparing the capacity of the MME to other MMEs in a pool.

Configuring Mobility Restriction Support

Mobility or handover restriction is performed by handover restriction lists configured on the MME. These lists restrict inter-RAT, 3G location area, and/or 4G tracking area handovers based on the configuration in the Handover Restriction List Configuration Mode.

IMPORTANT:

Mobility restriction support is only available through the operator policy configuration. For more information on operator policy, refer to the Operator Policy chapter in this guide.

Configuring Inter-RAT Handover Restrictions on the MME

Inter-RAT handover restriction configurations on the MME restrict subscribers from participating in handovers to defined radio access network types.

Use the following example to configure this feature:

configure
   lte-policy
      ho-restrict-list <name>
         forbidden
inter-rat cdma2000
         end
Notes:
  • Other forbidden inter-RAT choices are: all, GERAN, and UNTRAN.
  • This configuration will only become operational when it is associated with a call control profile. Only one handover restriction list can be associated with a call control profile.

Configuring Location Area Handover Restrictions on the MME

Location area handover restriction lists on the MME restrict subscribers from participating in handovers to specific 3G location area codes.

Use the following example to configure this feature:

configure
   lte-policy
      ho-restrict-list <name>
         forbidden
location-area plmnid <id>
            lac
<area_code> <area_code>
<area_code> +
            end
Notes:
  • Up to 16 forbidden location areas can be configured per handover restriction list.
  • Up to 128 location area codes can be entered in a single lac command line.
  • This configuration will only become operational when it is associated with a call control profile. Only one handover restriction list can be associated with a call control profile.

Configuring Tracking Area Handover Restrictions on the MME

Tracking area handover restriction lists on the MME restrict subscribers from participating in handovers to specific 4G tracking area codes.

Use the following example to configure this feature:

configure
   lte-policy
      ho-restrict-list <name>
         forbidden
tracking-area plmnid <id>
            tac
<area_code> <area_code>
<area_code> +
            end
Notes:
  • Up to 16 forbidden tracking areas can be configured per handover restriction list.
  • Up to 128 tracking area codes can be entered in a single tac command line.
  • This configuration will only become operational when it is associated with a call control profile. Only one handover restriction list can be associated with a call control profile.

Configuring S4-SGSN Handover Capability

This configuration example configures an S3 interface supporting inter-RAT handovers between the MME and an S4-SGSN.

Use the following example to configure this feature:

configure
   context
<mme_context_name>
-noconfirm
      interface <s3_interface_name>
         ip
address <ipv4_address>
         exit
      mme-service <mme_svc_name>
         peer-sgsn
rai mcc <mcc_value> mnc
<mnc_value>
rac <value>
lac <value>
address <ip_address> capability
s3
         nri
length <length>
plmn-id mcc <mcc_value>
mnc <mnc_value>
         exit
      exit
   port
ethernet <slot_number/port_number>
      no
shutdown
      bind
interface <s3_interface_name> <mme_context_name>
      end
Notes:
  • The peer-sgsn command is used to statically configure a peer SGSN. SGSN selection can also be performed dynamically through the DNS client. For more information about dynamic peer selection, refer to the Configuring Dynamic Peer Selection section in this chapter.
  • In the absence of an NRI length configuration, the MME treats the NRI as invalid. The MME will use a plain RAI-based FQDN (and not an NRI-based FQDN) for DNS queries made to resolve the source SGSN.

Configuring SCTP Multi-homing Support

SCTP multi-homing can be configured on the S1-MME interface (to/from eNodeB), the S6a interface (to/from HLR/HSS), and the SGs interface (to/from the MSC/VLR).

Configuring SCTP Multi-homing on the S1-MME Interface

Up to two IPv4 or IPv6 addresses for the S1-MME interface can be entered to allow for SCTP multi-homing.

The configuration example in this section is intended as a replacement for the S1-MME interface configuration located in the Creating and Configuring the MME Context and Service section. Use the following example to configure S1-MME multi-homing between the MME and the eNodeB:

configure
   context
<mme_context_name>
-noconfirm
      interface
<s1-mme_intf_name>
         ip
address <ipv4_address>
         ip
address <secondary_ipv4_address>
         exit
      mme-service <mme_svc_name>
         bind
s1-mme ipv4-address <ipv4_address>
ipv4-address <secondary_ipv4_address>
         exit
      exit
   port
ethernet <slot_number/port_number>
      no
shutdown
      bind
interface <s1-mme_intf_name> <mme_context_name>
      end

Configuring SCTP Multi-homing on the S6a Interface

Up to four IPv4 or IPv6 addresses for the S6a interface can be configured to allow for SCTP multi-homing.

The configuration example in this section is intended as a replacement for the S6a interface configuration located in the Creating and Configuring the MME Context and Service section and the Diameter configuration for the S6a interface located in the Creating and Configuring the HSS Peer Service and Interface Associations section. Use the following example to configure S6a multi-homing between the MME and theHLR/HSS:

configure
   context <mme_context_name>
      interface <s6a_intf_name>
         ip
address <s6a_intf_primary_ip_addr> <ip_mask>
         ip
address <s6a_intf_secondary_ip_addr2> <ip_mask>
secondary
         ip
address <s6a_intf_secondary_ip_addr3> <ip_mask>
secondary
         exit
      exit
   diameter
endpoint <hss-endpoint_name>
      origin
realm <realm_name>
      origin
host <name>
address <s6a_intf_primary_ip_addr>
port <number>
address <s6a_intf_secondary_ip_addr2>
port <number>
address <s6a_intf_secondary_ip_addr3>
port <number>
      peer
<peer_name>
realm <realm_name>
address <hss_ip_addr1> port
<number>
address <hss_ip_addr2> port
<number>
sctp
      route-entry
realm <realm_name> peer
<peer_name>
      exit
   port
ethernet <slot_number/port_number>
      no
shutdown
      bind
interface <s6a_intf_name> <mme_context_name>
      exit
Notes:
  • The S6a IP addresses can also be specified as IPv6 addresses using the ipv6 address keyword.

Configuring Static S-GW Pools

The MME supports static TAI list configuration which allows for the mapping of TAIs, TACs, and S-GWs to facilitate S-GW pooling for UEs moving between TAIs in their TAI lists.

Creating and Configuring a TAI Management Database and Object

This section provides configuration examples for creating and configuring the TAI/S-GW associations for S-GW pooling.

Use the following example to configure this feature on the MME:

configure
   lte-policy
      tai-mgmt-db <db_name>
         tai-mgmt-obj <object_name>
            tai
mcc <number>
mnc <number>
tac <value>
            sgw-address
<ipv4_address> s5-s8-protocol
gtp weight <number>
            end
Notes:
  • Up to four databases can be configured on the system.
  • Up to 500 management objects can be configured per database.
  • Up to 16 TAIs can be configured per management object.
  • Up to 16 TACs can be configured per TAI.
  • The sgw-address variable can also be specified as an IPv6 address.
  • Up to 32 S-GW IP addresses can be configured per management object.
  • The s5-s8-protocol can also be specified as pmip or both (GTP and PMIP).

Associating a TAI Management Database with an MME Service

In order for an MME service to use a statically configured S-GW pool, it must be associated with the TAI Management Database.

Use the following example to configure the TAI Management Database-to-MME service association:

configure
   context <mme_context_name>
      mme-service <mme_svc_name>
         associate
tai-mgmt-db <database_name>
         end
Notes:
  • Only one TAI Management Database can be configured per MME service.
  • This association can also be performed in the Call Control Profile Configuration Mode supporting Operator Policy. If both associations are configured, the Operator Policy association is preferred by the system.

Associating a TAI Management Database with a Call Control Profile

MME service can access a statically configured S-GW pool through an Operator Policy instance, specifically through the Call Control Profile.

Use the following example to configure the TAI Management Database-to-MME service association:

configure
   call-control-profile <name>
      associate
tai-mgmt-db <database_name>
      end
Notes:
  • Only one TAI Management Database can be configured per Call Control Profile.
  • This association can also be performed in the MME Service Configuration Mode. If both associations are configured, the Operator Policy association is preferred by the system.

Configuring User Location Information Reporting Support

This feature allows the MME to query and receive UE location reports from an eNodeB.

IMPORTANT:

User Location Information Reporting is a licensed feature and requires the purchase of the ULI Reporting feature license to enable it.

Use the following example to configure User Location Information (ULI) reporting support on the MME:

configure
   context <mme_context_name>
      mme-service <mme_svc_name>
         location-reporting
         end