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. This section also includes suggestions about the types of information that are needed to be able to configure the MME, as well as information about how the MME works based on some of the possible configurations.
The configurations in this section assume the following:
- A single context (other than the Local context) for all interfaces and services
- Static S-GW/P-GW selection (MME Policy configuration)
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.
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
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.
-
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.
-
The MME service receives the Attach Request message and references the HSS peer service for authentication and location resolution.
-
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).
-
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.
-
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.
-
The MME then sends an Update Location Request to the HSS and obtains relevant subscription data for the IMSI in the response.
-
The MME policy is accessed to determine the S-GW and P-GW to which the UE should be attached.
-
The MME uses the S11 interface bound to the eGTP service to communicate with the S-GW specified by the MME policy configuration.
-
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.
-
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 acknowledgment 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.
-
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.
Procedure
Step 1 |
Set system configuration parameters such as activating PSCs by applying the example configurations found in the System Administration Guide. |
Step 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 section. |
Step 3 |
Create the eGTP service and associate it with the S11 interface by applying the example configuration in the section. |
Step 4 |
Create the HSS peer service and associate it with the S6a interface and S13 interface by applying the example configuration in the section. |
Step 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
network-sharing plmnid mcc mcc_value mnc mnc_value mme-id group-id id mme-code code
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. For more information on configuring multi-homing for the S1-MME and/or S6a interface(s), refer to Configuring SCTP Multi-homing Support.
- 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 network-sharing command is used to configure an additional PLMN ID for this MME service.
- The eGTP service is configured in the following section.
- The HSS peer service is configured in the configuration sequence for Creating and Configuring the HSS Peer Service and Interface Associations.
- 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.
Important |
If you modify the interface-type command, the parent service (service within which the eGTP/GTP-U service is configured) will automatically restart. Service restart results in dropping of active calls associated with the parent service. |
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. For information on configuring SCTP multi-homing for the S6a interface, refer to Configuring SCTP Multi-homing Support.
Caution |
On a PSC2 setup, all diamproxy tasks might go in to a warning state if the number of hss-peer-services configured are more than 64 since the memory usage may exceed the allocated value. |
Configuring Dynamic Destination Realm Construction for Foreign Subscribers
For a foreign subscriber, the MME does not know the HSS nodes in all the foreign PLMNs. In this case the MME routes S6a/S6d requests directed to foreign PLMNs via a Diameter Routing Agent (DRA) using only the destination realm. The DRA in turn routes the request to the correct HSS based on the destination realm. In order to accomplish this, the MME needs to dynamically construct requests to the DRA/HSS with a Destination Realm representing the foreign PLMN of the UE.
The MME can be configured to derive the EPC Home Network Realm/Domain based on the user's IMSI (MNC and MCC values) and use it as the Destination Realm in all diameter messages.
For home subscribers, the MME will always use the configured peer realm as destination-realm, regardless if dynamic-destination-realm is enabled.
Because MNCs can be 2 or 3 digits long, to provide the ability for an operator to configure the MCC and MNC of foreign PLMNs, the operator policy of the subscriber map is used to determine the MNC value and the length of the MNC. The following steps outline how this configuration can be implemented.
First, enable the dynamic destination realm functionality for the HSS Peer Service:
configure
context ctxt_name
hss-peer-service HSS1
dynamic-destination-realm
end
Then configure the foreign PLMNs in the LTE subscriber map. For example:
configure
lte-policy
subscriber map SM1
precedence 10 match-criteria imsi mcc 232 mnc 11 operator-policy-name OP.HOME
precedence 20 match-criteria imsi mcc 374 mnc 130 msin first 700000000 last 800000000 operator-policy-name OP.ROAMING
end
Then associate the subscriber map to the MME Service. For example:
configure
context ingress
mme-service mmesvc
associate subscriber-map SM1
end
A static route entry must also be added in the diameter endpoint configuration for each foreign realm. For example:
configure
context ingress
diameter endpoint s6a1
peer HSS1 realm HSS-Realm1 address ip-address sctp
route-entry realm epc.mnc045.mcc123.3gppnetwork.org peer HSS1
end
With this sample configuration, an MNC of length 2 and value of 11 is matched with first operator policy (OP.HOME), and an MNC length of 3 and value of 130 is matched with the second operator policy (OP.ROAMING). With this configuration, the MME will find the MNC based on the operator policy for the foreign subscriber.
If there is no matching entry present in the operator policy, the MME will use the global static table to decide the MNC length and pass that information to Diameter layer to construct the dynamic realm. The following list of MCCs are all considered as 3 digit MNCs. All other MCCs are considered 2 digit MNCs.
302 | 334 | 354 | 405 |
310 | 338 | 356 | 708 |
311 | 342 | 358 | 722 |
312 | 344 | 360 | 732 |
316 | 346 | 365 | |
348 | 376 |
The show hss-peer-service service name command displays this configuration in the Destination Realm field, either Configured Peer Realm (default), or Dynamic Realm.
Request Auth-vectors : 1
Notify Request Message : Enable
Destination Realm : Dynamic Realm