MME is a StarOS application that runs on Cisco ASR 5500 and virtualized platforms. For additional platform information, refer to the appropriate System Administration Guide and/or contact your Cisco account representative.

The MME is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

The following figure illustrates the specific network interfaces supported by the MME. Refer to the following section Supported Logical Network Interfaces (Reference Points) for detailed information about each interface illustrated in these figures..

Provides the identity allocation of following type:

Within the MME, the mobile is identified by the M-TMSI.

The Globally Unique MME Identifier (GUMMEI) is constructed from MCC, MNC and MME Identifier (MMEI). In turn the MMEI is constructed from an MME Group ID (MMEGI) and an MME Code (MMEC).

The GUTI is constructed from the GUMMEI and the M-TMSI.

For paging, the mobile is paged with the S-TMSI. The S-TMSI is constructed from the MMEC and the M-TMSI.

The operator needs to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools.

The GUTI is used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable more efficient radio signaling procedures (e.g. paging and Service Request).

ANSI T1.276 specifies security measures for Network Elements (NE). In particular it specifies guidelines for password strength, storage, and maintenance security measures.

ANSI T1.276 specifies several measures for password security. These measures include:

• Password strength guidelines

• Password storage guidelines for network elements

• Password maintenance, e.g. periodic forced password changes

These measures are applicable to the system and an element management system since both require password authentication. A subset of these guidelines where applicable to each platform will be implemented. A known subset of guidelines, such as certificate authentication, are not applicable to either product. Furthermore, the platforms support a variety of authentication methods such as RADIUS and SSH which are dependent on external elements. ANSI T1.276 compliance in such cases will be the domain of the external element. ANSI T1.276 guidelines will only be implemented for locally configured operators.

The APN-Restriction value may be configured for each APN in the P-GW and transferred to the MME. It is used to determine, on a per-MS basis, whether it is allowed to establish EPS bearers to other APNs.

The APN-Restriction value is defined in clause 15.4 of 3GPP TS 23.060. APN-Restriction affects multiple procedures, such as Initial Attach, TAU, PDN connectivity, and inter-MME handovers. The MME saves the APN-Restriction value received in create session response for an APN and uses the maximum of the values from the currently active PDNs in the next create session request. If a PDN is disconnected, then the maximum APN-Restriction is adjusted accordingly.

The MME provides EPS Authentication and Key Agreement mechanism for user authentication procedure over the E-UTRAN. The Authentication and Key Agreement (AKA) mechanism performs authentication and session key distribution in networks. AKA is a challenge- response based mechanism that uses symmetric cryptography. AKA is typically run in a Services Identity Module.

AKA is the procedure that take between the user and network to authenticate themselves towards each other and to provide other security features such as integrity and confidentiality protection.

In a logical order this follows the following procedure:

This feature allows the back up of a small set of MME key KPI counters for recovery of the counter values after a session manager (SessMgr) crash.

KPI calculation involves taking a delta between counter values from two time intervals and then determines the percentage of successful processing of a particular procedure in that time interval. When a SessMgr crashes and then recovers, the MME loses the counter values as they are reset to zero. So, the KPI calculation in the next interval will result in negative values for that interval. With this feature, it is possible to perform reliable KPI calculations even if a SessMgr crash occurs.

For details about the feature, commands, and new MME-BK schema, refer to the Backup and Recovery of Key KPI Statistics feature in this guide.

The system's support for bulk statistics allows operators to choose to view not only statistics that are of importance to them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.

When used in conjunction with an element manager, the data can be parsed, archived, and graphed.

The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema. Following is a partial list of supported schemas:

The system supports the configuration of up to 4 sets (primary/secondary) of receivers. Each set can be configured with to collect specific sets of statistics from the various schemas. Statistics can be pulled manually from the chassis or sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.

The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, chassis host name, chassis uptime, the IP address of the system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.

When an element manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.

The Bulk Statistics Server component of an element manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a Northbound NMS or an alternate bulk statistics server for further processing.

Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on an element manager server.

The MME provides support for Commercial Mobile Alert System (CMAS): SBc interface and underlying protocols. Warning Messages can be received from a Cell Broadcast Center (CBC) over the SBc-AP interface and relayed to all relevant eNodeBs over the S1-AP interface.

Refer to the Cell Broadcast Center - SBc Interface chapter in the MME Administration Guide for more information.

Closed Subscriber Group identifies a group of subscribers who are permitted to access one or more CSG cells of the PLMN as a member of the CSG for a Home eNodeB.

Refer to the Closed Subscriber Groups chapter in the MME Administration Guide for more information.

MME uses the canonical name of the selected S-GW (from DNS response) for the previously established Pens and compares it with the statically configured P-GW collocation string in the LTE emergency profile to select the P-GW. The static P-GW collocation string must be configured with the canonical node name of the P-GW to ensure to select collocated node for emergency call.

Important

This behavior applies only to the PDN connectivity request for Emergency Bearer Service.

pgw co-location

Use the following configuration to configure P-GW co-location:

configure 
   lte-policy  
      lte-emergency-profile profile_name 
         [ no ] pgw co-location 
         end 

NOTES:

• no Disables the P-GW co-location configuration.

• co-location Configures to select the co-located S-GW/P-GW node based on static P-GW configuration and S-GW selected through DNS.

show lte-policy lte-emergency-profile <profile_name>

The output of this command includes "pgw co-location" to indicate if the P-GW co-location feature is enabled or disabled.

The congestion control feature allows you to set policies and thresholds and specify how the system reacts when faced with a heavy load condition.

Congestion control monitors the system for conditions that could potentially degrade performance when the system is under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an impact the system's ability to service subscriber sessions. Congestion control helps identify such conditions and invokes policies for addressing the situation.

Congestion control operation is based on configuring the following:

Congestion control can be used in conjunction with the load balancing feature provided on the MME. For more information on MME load balancing, refer to the Load Balancing and Rebalancing section in this guide.

For more information or to configure Overload Control using the basic Congestion Control functionality, refer to the Congestion Control chapter in the ASR 5500 System Administration Guide.

For more information about the Enhanced Congestion Control functionality (a licensed feature), refer to the Enhanced Congestion Control and Overload Control chapter in this guide.

Configured APN is considered as IMS APN and UE is allowed to attempt IMS PDN connection only if it is subscribed to that APN. If the configured IMS APN is present in the subscription in ULA, then MME sets "IMS voice over PS session in S1 mode" in the Attach Accept/TAU Accept message.

If the configured IMS APN is not present in the subscription in ULA, then "IMS voice over PS session in S1 mode" must be unset. If there is any change in subscription due to ISDR/DSR, then the updated parameter must be sent to the UE during the next IM-Exit.

The ims-apn CLI command in the Call Control Profile Configuration mode is enhanced to configure the network identifier on MME.

The MME could have a tracking area in only one tracking area list (TAI List). Consequently, the tracking area list assigned to subscribers attaching from different TAIs will be same, even if the adjacency of these tracking areas is not same. This results in MME getting TAUs even as subscribers moved to the adjacent area.

The MME will allow operators to configure adjacency lists as TAI Lists, thus reducing the Tracking Area Updates (TAU) received by MME. This feature enables the MME to send configured customized TAI List in ATTACH_ACCEPT/TAU_ACCEPT when a request is received from the custom or border TAIs.

The reduced TAU results in less signaling load on the MME and better operational efficiency.

MME sends configured delay value as “Data Notification Delay" in DDN-ACK and "Delay Downlink Packet Notification Request" IE in Modify-Bearer-Request to SGW. When the delay value is not configured, this IE will not be included in DDN-ACK and Modify bearer request messages.

ddn-delay

Use the following configuration to configure ddn-delay value.

configure  
   context  context_name 
      mme-service mme-service_name 
         ddn-delay ddn-delay_value 
         no ddn-delay 
         end 

NOTES:

• no : Removes the configured downlink-data-notification delay value.

• ddn-delay Configures the downlink-data-notification delay value in multiples of 50 milliseconds. ddn-delay_value is an integer and it must be between 0 and 255.

show mme-service all

The output of this command includes "DDN Delay Value".

To retrieve the geographical position of a UE, the MME includes the location estimate and the eCGI value in the PLA/LRR messages that is sent to the GMLC. The eCGI value is independent of the response received from the E-SMLC.

In releases prior to 21.5: During a location service request (to the MME), when the E-SMLC is configured, the MME sends the location service request to the E-SMLC. The E-SMLC processes the location service request and sends only the location estimate information back to the MME, which forwards the data in the PLA/LRR messages to the GMLC. The location estimate in the PLA/LRR messages sent to the GMLC is based on the response received from the E-SMLC.

Notifying the GMLC of the emergency call release event allows the GMLC to delete all information previously stored for the emergency call in accordance with regulations.

In compliance with 3GPP TS 29.172, the MME location services (LCS) feature supports sending the EMERGENCY_CALL_RELEASE event in a subscriber location report (SLR) request message to the gateway mobile location center (GMLC) when an emergency call is released or when an emergency PDN is disconnected at the MME.

With this new functionality, the MME notifies the GMLC of Emergency Call Release. The call release event enables the GMLC to clear the cache for existing calls and to correctly log the duration of an emergency call. Without call release facilitating the clearing of the cache, the location platform could send the old (erroneous) location information in response to a new location request for an E-911 call.

The MME supports the creation of emergency bearer services which, in turn, support IMS emergency sessions. Emergency bearer services are provided to normally attached UEs and to UEs that are in a limited service state (depending on local service regulations, policies, and restrictions).

Provides support for subscriber default and dedicated Evolved Packet System (EPS) bearer contexts in accordance with the following standards:

EPS bearer context processing is based on the APN that the subscriber is attempting to access. Templates for all of the possible APNs that subscribers will be accessing must be configured within the system. Up to 1024 APNs can be configured on the system.

Each APN template consists of parameters pertaining to how UE contexts are processed such as the following:

A total of 11 EPS bearer per subscriber are supported. These could be all dedicated, or 1 default and 10 dedicated or any combination of default and dedicated context. Note that there must be at least one default EPS Bearer context in order for dedicated context to come up.

Support for the EPS GTPv2 on S11 interface in accordance with the following standards:

The system supports the use of GTPv2 for EPS signaling context processing.

When the GTPv2 protocol is used, accounting messages are sent to the charging gateways (CGs) over the Ga interface. The Ga interface and GTPv2 functionality are typically configured within the system's source context. As specified by the standards, a CDR is not generated when a session starts. CDRs are generated according to the interim triggers configured using the charging characteristics configured for the MME, and a CDR is generated when the session ends. For interim accounting, STOP/START pairs are sent based on configured triggers.

GTP version 2 is always used. However, if version 2 is not supported by the CGF, the system reverts to using GTP version 1. All subsequent CDRs are always fully-qualified partial CDRs. All CDR fields are R4.

Whether or not the MME accepts charging characteristics from the SGSN can be configured on a per-APN basis based on whether the subscriber is visiting, roaming or, home.

By default, the MME always accepts the charging characteristics from the SGSN. They must always be provided by the SGSN for GTPv1 requests for primary EPS Bearer contexts. If they are not provided for secondary EPS Bearer contexts, the MME re-uses those from the primary.

If the system is configured to reject the charging characteristics from the SGSN, the MME can be configured with its own that can be applied based on the subscriber type (visiting, roaming, or home) at the APN level. MME charging characteristics consist of a profile index and behavior settings. The profile indexes specify the criteria for closing accounting records based specific criteria.

Important

For more information on GTPv2 configuration, refer to the Creating and Configuring the eGTP Service and Interface Association section in the Mobility Management Entity Configuration chapter of the MME Service Administration Guide.

MME will start Timer (Tm) after the reception of "E-RAB Setup Response" with cause "Interaction with other procedure." Once the timer expires, MME re-transmits the "E-RAB Setup Request." MME supports the maximum retry count. This behavior is CLI controlled.

erab-setup-rsp-fail retry-timer

Use the following configuration to configure the ERAB Setup retry handling:

configure 
   context context_name 
      mme-service service_name 
         policy erab-setup-rsp-fail retry-timer retry_timer  max-retries max_retries  
         { default | no } policy erab-setup-rsp-fail retry-timer 
         end 

NOTES:

• no Disables the retry timer mechanism.

• default Restores the default value to existing behavior by disabling the retry timer mechanism.

• policy Specifies the user-defined policies like idle mode detach behavior and so on.

• erab-setup-rsp-fail Sets the handling for ERAB-SETUP-RESPONSE failure message.

• retry-timer retry_timer Configures the retry timer for ERAB Setup Procedure. retry_timer must be an integer value in the range of 1-15.

• max-retries max_retries Configures the maximum retry limit for ERAB Setup Procedure. max_retries must be an integer value in the range of 1-10.

UE triggers TAU, results in MME sending Location Update Request/Response. MME sends TAU Accept to UE (with S1 downlink-nas to eNB). With UE sending TAU Complete, MME sends TMSI Relocation Complete to MSC and Modify Bearer Request towards S-GW.

Provides a mechanism for performing Diameter-based authorization, authentication, and accounting (AAA) for subscriber bearer contexts based on the following standards:

The S6a protocol is used to provide AAA functionality for subscriber EPS Bearer contexts through Home Subscriber Server (HSS).

During the initial attachment procedures the MME sends to the USIM on AT via the HSS the random challenge (RAND) and an authentication token AUTN for network authentication from the selected authentication vector. At receipt of this message, the USIM verifies that the authentication token can be accepted and if so, produces a response. The AT and HSS in turn compute the Cipher Key (CK) and Integrity Key (IK) that are bound to Serving Network ID. During the attachment procedure the MME requests a permanent user identity via the S1-MME NAS signaling interface to eNodeB and inserts the IMSI, Serving Network ID (MCC, MNC) and Serving Network ID it receives in an Authentication Data Request to the HSS. The HSS returns the Authentication Response with authentication vectors to MME. The MME uses the authentication vectors to compute the cipher keys for securing the NAS signaling traffic.

At EAP success, the MME also retrieves the subscription profile from the HSS which includes QoS information and other attributes such as default APN name and S-GW/P-GW fully qualified domain names.

Among the AAA parameters that can be configured are:

Support for Extension IEs in Bearers_SubjectToStatusTransfer_Item is added to enable MME to include the extension IEs in MME status transfer message to target eNB.

Bearers_SubjectToStatusTransfer_Item Extension IEs are sent from source eNB in eNB-Status-Transfer message.

The support for the expanded capacities of the VPC-DI and ASR5500 platforms, the IMSIMgr Scaling feature increases the number of IMSI managers on the MME to a maximum of 4. This number is configurable.

The IMSIMgr is the demultiplexing process that selects the SessMgr instance to host a new session based on a demux algorithm logic to host a new session by handling new call requests from the MMEMgr, the EGTPC Mgr, and the (e)SGTPCMgr (New MME handoffs). The new call requests or signaling procedures include Attach, Inter-MME TAU, PS Handover, and SGs, all of which go through the IMSIMgr. The IMSIMgr process also maintains the mapping of the UE identifier (for example, IMSI/GUTI) to the SessMgr instance.

Important

IMSIMgr scaling is only available on the ASR5500 and VPC-DI platforms.

By increasing the number of IMSIMgr instances, the new call handling capacity (primarily for Attach and SGs procedures) of the MME is increased as the calls are distributed across multiple instances. The call distribution logic across IMSIMgrs utilizes a simple hash operation on IMSI/GUTI to select the IMSIMgr instance.

It is the MMEMgr/EGTPC Mgr/SGTPC Mgr that selects an IMSIMgr instance to be contacted for session setup. Each subscriber session in a SessMgr will maintain the IMSIMgr instance number that hosts the mapping for the IMSI. The SessMgrs now remembers the IMSIMgr instance IDs per subscriber for the target IMSIMgr instance number (IMSIMgr instance ID calculated by hash on the IMSI).

All IMSIMgr instances will send the current count of sessions per MME service to the MMEMgr via existing response messaging. The MMEMgr will send the same data received from multiple IMSIMgr instances back to the IMSIMgr in existing request messaging. As a result, each IMSIMgr will know the session count per MME service for all IMSIMgr instances. Given this information, the per MME service session limits can now be enforced by each IMSIMgr instance.

This feature does not require a special license.

The following changes are observed when the number of IMSI managers set is more than 1:

• It is possible to initiate an audit request for a single, specific IMSIMgr instance.

• Increased tolerance for configurable MME per service session limits. This can be noticed when configuring commands such as bind in the MME Service configuration mode.

• Increased tolerance for Attach rate control as the MME Attach rate control will be independently enforced by each IMSIMgr instance.

Important

The task facility imsimgr max command sets the number of IMSI managers. This is a boot-time configuration and must be added in the configuration file to be implemented at startup and before any MME related configuration takes effect, that is before any IMSIMgr is started. The run-time configuration of this CLI does not have any effect.

Important

After you configure the task facility imsimgr max command, you must save the configuration and then reload the chassis for the command to take effect. For information on saving the configuration file and reloading the chassis, refer to the System Administration Guide for your deployment.

The S10 interface facilitates user mobility between two MMEs providing for the transfer of the UE context from one to the other. It is a GTPv2 control plane interface that supports the following handover types and features:

This section describes various interworking and handover scenarios supported by the MME, including:

MME will not allow the UE to get connected to PDN Type IPv6. This means that MME will not allow the UE to include IPv6 address even if the UE has requested and subscribed for the IPv6 address.

MME will ensure that PDN will not receive any IPv6 address either by rejecting with PDN Connectivity Request or by overriding it only with IPv4 address.

The following table explains the behavior of MME when the pdn-type-override ipv4-only CLI command is enabled.

• In the Call Control Profile Configuration mode, the pdn-type-override CLI command is enhanced to enable the MME to allow only IPv4 addresses to a PDN connection. The default behavior allows PDN to have IPv6 addresses when subscription allows it.

  configure 
     call-control-profile profile_name 
        [ remove ] pdn-type-override ipv4-only 
        end 

• The PDN Type IPv6 Denied field in the output of the show call-control-profile full all command displays "Configured" or "Not Configured" to indicate whether the MME is enabled to allow only IPv4 addresses to a PDN connection.

This feature allows IPv6 subscribers to connect via the LTE/SAE infrastructure in accordance with the following standards:

The MME allows an APN to be configured for IPv6 EPS Bearer contexts. Also, an APN may be configured to simultaneously allow IPv4 EPS Bearer contexts.

The MME supports IPv6 stateless dynamic auto-configuration. The mobile station may select any value for the interface identifier portion of the address. The link-local address is assigned by the MME to avoid any conflict between the mobile station link-local address and the MME address. The mobile station uses the interface identifier assigned by the MME during the stateless address auto-configuration procedure. Once this has completed, the mobile can select any interface identifier for further communication as long as it does not conflict with the MME's interface identifier that the mobile learned through router advertisement messages from the MME.

Control and configuration of the above is specified as part of the APN configuration on the MME, e.g., IPv6 address prefix and parameters for the IPv6 router advertisements. RADIUS VSAs may be used to override the APN configuration.

Following IPv6 EPS Bearer context establishment, the MME can perform either manual or automatic 6to4 tunneling, according to RFC 3056, Connection of IPv6 Domains Via IPv4 Clouds.

Load balancing functionality permits UEs that are entering into an MME pool area to be directed to an appropriate MME in a more efficient manner, spreading the load across a number of MMEs.

Load balancing is achieved by setting a weight factor for each MME so that the probability of the eNodeB selecting an MME is proportional to its weight factor. The weight factor is typically set according to the capacity of an MME node relative to other MME nodes. The weight factor is sent from the MME to the eNodeB via S1-AP messages.

Refer to the Load Balancing and Rebalancing chapter for more information about this feature.

MME load balancing can be used in conjunction with congestion control. For more information on congestion control, refer to the Congestion Control section in this chapter.

Local cause code mapping provides the operator with the flexibility to ignore the default EPS Mobility Management (EMM) cause code and to configure a preferred EMM cause code to be sent to a UE in response to a procedural failure. For example, the operator can instruct the MME to return one of six different EMM cause codes other than the default when the context received from a peer SGSN (during a TAU procedure) does not contain any active PDP contexts.

Local cause code mapping can be configured in either or both the MME-Service configuration or in the Call-Control Profile configuration. Refer to these two configuration modes in the Command Line Interface Reference to see the current list of local-cause-code-mapping commands.

The Operation and Maintenance module of the system offers comprehensive management capabilities to the operators and enables them to operate the system more efficiently. There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces. For up-to-date details on the management options, refer to the System Administration Guide.

Operator-based MME configuration and monitoring functionality is enabled by default for console-based access via the command line interface. For more information on command line interface based management, refer to the Command Line Interface Reference.

MME will not fetch UUT from HSS if it has already received from peer MME/SGSN and also in case of reroute scenarios.

In case of Initial attach (including local GUTI attach), when DECOR and the new CLI are configured, MME will fill the AIR-Flags to fetch UUT from HSS, irrespective of the UUT stored in MME-DB.

MME has undergone architectural changes to allow enhanced operations on Cisco's Virtual Packet Core (VPC)- Distributed Instance (DI) platform. VPC (Cisco's brand name for StarOS VM instances) is StarOS running as a virtual machine (VM). Multiple VMs act as a single StarOS instance with shared interfaces, shared service addresses, load balancing, redundancy, and a single point of management.

For the MME to take advantage of next generation platforms, such as the VPC-DI and USP, the MME architecture has been changed to allow:

• Linear capacity (memory) growth to support greater numbers of UEs and ENBs

• Signaling performance growth in term of CEPS

• Improved redundancy for RAN connections

• MMEMgr tasks are distributed across session PSC/DPC/SF-VM

• MMEDemux tasks are moved to demux PSC/DPC/SF-VM

• IMSIMgr scaling has increased the number of possible IMSIMgr tasks

• The maximum number of MME managers supported per SF is 4 for USP and VPC-DI platforms.

• In 21.9 and later releases: The maximum number of MMEMgrs supported per chassis is 48 for USP and VPC-DI platforms.

  In releases prior to 21.9: The number of MMEMgrs is increased to 24 on the VPC-DI platform.

• Two models of configuration, normal density and high density

For more information on the VPC platform, contact your Cisco Representative.

Provides support to configure MME pool area consisting multiple MMEs within which a UE may be served without any need to change the serving MME.

The benefits of MME pooling are:

An MME Pool Area is defined as an area within which a UE may be served without need to change the serving MME. An MME Pool Area is served by one or more MMEs in parallel. MME Pool Areas are a collection of complete Tracking Areas. MME Pool Areas may overlap each other.

The Cisco MME supports MME Pooling functionality as defined in 3GPP TS 23.401. MME pooling allows carriers to load balance sessions among pooled MMEs.

The Cisco MME supports configuration of up to a pool size of 32 nodes.

The MME selection function selects an available MME for serving a UE. This feature is needed for MME selection for handover with minimal MME changes.

MME selection chooses an available MME for serving a UE. Selection is based on network topology, i.e. the selected MME serves the UE's location and in case of overlapping MME service areas, the selection function may prefer MME's with service areas that reduce the probability of changing the MME.

The Mobile Equipment Identity Check Procedure permits the operator(s) of the MME and/or the HSS and/or the PDN-GW to check the Mobile Equipment's identity with EIR.

The mobile equipment (ME) identity is checked through the MME by passing it to an Equipment Identity Register (EIR) over the S13 interface and then the MME analyzes the response from the EIR in order to determine its subsequent actions like rejecting or attaching a UE.

The following types of mobility restriction are supported on the MME:

Monitor Protocol is enhanced to display the newly introduced dcnr flag and rDCNR flag.

This feature provides multiple PDN connectivity support for UE initiated service requests.

The MME supports an UE-initiated connectivity establishment to separate P-GWs or a single P-GW in order to allow parallel access to multiple PDNs. Up to 11 PDNs are supported per subscriber.

Refer to PDN Type Control in this chapter for information about the ability to control the PDN type (IPv4, IPv6) to which a given UE can be connected.

MME provides this protocol support between the UE and the MME. The NAS protocol includes following elementary procedures for EPS Mobility Management (EMM) and EPS Session Management (ESM):

The NAS Signaling Security feature provides integrity protection and encryption of NAS Signaling. The NAS security association is between the UE and the MME.

The MME uses the NAS security mode command procedure to establish a NAS security association between the UE and MME, in order to protect the further NAS Signaling messages.

See the NAS Signaling Security chapter for more information.

With release 21.14, for the NBIOT devices, If the Extended DRX parameter values are 4, 6, 7 or 8, it is interpreted as 2 and sent in the Attach-Accept or in the TAU Accept.

The LTE architecture enables service providers to reduce the cost of owning and operating the network by allowing the service providers to have separate Core Network (CN) elements (MME, SGW, PDN GW) while the E-UTRAN (eNBs) is jointly shared by them. This is enabled by the S1-flex mechanism by enabling each eNodeB to be connected to multiple CN entities. When a UE attaches to the network, it is connected to the appropriate CN entities based on the identity of the service provider sent by the UE.

In such a network sharing configuration, complete radio (access) network and partial core network is shared among different operators. Each operator has its own network node for S-GW/P-GW, etc., while sharing a MME and the rest of the radio network.

To support this network sharing configuration, the MME service can be configured with multiple local PLMNs per service. This means that each mme-service will handle multiple PLMNs and will indicate this to the eNodeb during S1 SETUP procedure (as well using the S1 MME CONFIGURATION UPDATE message).

The configuration of these additional PLMNs is implemented using the network-sharing command within the MME service configuration mode. Refer to the Command Line Reference for detailed information on using this command.

When a UE attaches to the MME, the GUTI assignment will use the mme id corresponding to the PLMN configuration. The plmn-id filter in the operator policy selection criteria allows PLMN-specific configurations in an operator policy.

The operator policy provides mechanisms to fine tune the behavior of subsets of subscribers above and beyond the behaviors described in the user profile. It also can be used to control the behavior of visiting subscribers in roaming scenarios, enforcing roaming agreements and providing a measure of local protection against foreign subscribers.

An operator policy associates APNs, APN profiles, an APN remap table, and a call-control profile to ranges of IMSIs. These profiles and tables are created and defined within their own configuration modes to generate sets of rules and instructions that can be reused and assigned to multiple policies. In this manner, an operator policy manages the application of rules governing the services, facilities, and privileges available to subscribers. These policies can override standard behaviors and provide mechanisms for an operator to get around the limitations of other infrastructure elements, such as DNS servers and HSSs.

The operator policy configuration to be applied to a subscriber is selected on the basis of the selection criteria in the subscriber mapping at attach time. A maximum of 1,024 operator policies can be configured. If a UE was associated with a specific operator policy and that policy is deleted, the next time the UE attempts to access the policy, it will attempt to find another policy with which to be associated.

A default operator policy can be configured and applied to all subscribers that do not match any of the per-PLMN or IMSI range policies.

Changes to the operator policy take effect when the subscriber re-attaches and subsequent EPS Bearer activations.

Refer to the Operator Policy chapter in this guide for more information.

With this feature, the MME selects / re-selects an operator policy for call handling based on the user equipment's (UE's) unique international mobile equipment identity - type allocation code (IMEI-TAC) rather than the normal selection method, which is based on the UE's international mobile subscriber identity (IMSI) and PLMN-ID. The TAC (the first 8 digits of the 15 or 16-digit IMEI / IMEI-SV) serves to identify the equipment type - enabling the operator to configure how calls are handled based on the equipment type. And the operator can configure up to 25,000 IMEI-TAC in groups of individual IMEI-TAC or ranges.

For more information on configuring this functionality, refer to Operator Policy Selection Based on IMEI-TAC chapter of the MME Administration Guide.

Using the Congestion Control functionality or the Enhanced Congestion Control functionality, the MME can signal to the eNodeBs to which it is connected to redirect traffic to other MMEs in the MME pool. This is accomplished using the S1 interface Overload Procedure (3GPP TS 36.300 and 3GPP TS 36.413).

For more information or to configure Overload Control using the basic Congestion Control functionality, refer to the Congestion Control chapter in the System Administration Guide.

For more information or to configure Overload Control using the Enhanced Congestion Control functionality, refer to the Enhanced Congestion Control and Overload Control chapter in this guide.

PDN Type Control enables the MME to override the requested Packet Data Network (PDN) type based on the inbound roamer PLMN, and assign the UE to an IPv4 only or IPv6 only PDN.

If a UE requests an IPv4v6 PDN, it can be downgraded to an IPv4- or IPv6-only address. The MME signals the appropriate cause to the UE to account for the PDN type change.

This functionality enables operators to control resource usage for roaming and home subscribers differently, and ensures that IP network continuity works for inbound roamers.

PDN Type Control is configured in a call control profile that is applied via an operator policy. Refer to the Call Control Profile Configuration Mode chapter of the Command Line Reference for more information.

Provides a straightforward method based on a default APN provided during user attachment and authentication to assign the P-GW address in the VPLMN or HPLMN. The MME also has the capacity to use a DNS transaction to resolve an APN name provided by a UE to retrieve the PDN GW address.

P-GW selection allocates a P-GW that provides the PDN connectivity for the 3GPP access. The function uses subscriber information provided by the HSS and possibly additional criteria. For each of the subscribed PDNs, the HSS provides:

The HSS also indicates the default APN for the UE. To establish connectivity with a PDN when the UE is already connected to one or more PDNs, the UE provides the requested APN for the PDN GW selection function.

If the HSS provides an APN of a PDN and the subscription allows for allocation of a PDN GW from the visited PLMN for this APN, the PDN GW selection function derives a PDN GW address from the visited PLMN. If a visited PDN GW address cannot be derived, or if the subscription does not allow for allocation of a PDN GW from the visited PLMN, then the APN is used to derive a PDN GW address from the HPLMN.

Radio resource management functions are concerned with the allocation and maintenance of radio communication paths, and are performed by the radio access network.

To support radio resource management in E-UTRAN, the MME provides the RAT/Frequency Selection Priority (RFSP) parameter to an eNodeB across S1. The RFSP is a "per UE" parameter that is used by the E-UTRAN to derive UE specific cell reselection priorities to control idle mode camping. The RFSP can also be used by the E-UTRAN to decide on redirecting active mode UEs to different frequency layers or RATs.

The MME receives the RFSP from the HSS during the attach procedure. For non-roaming subscribers, the MME transparently forwards the RFSP to the eNodeB across S1. For roaming subscribers, the MME may alternatively send an RFSP value to the eNodeB across S1 that is based on the visited network policy, such as an RFSP pre-configured per Home-PLMN or a single RFSP's values to be used for all roamers independent of the Home-PLMN.

The MME supports RAN Information Management (RIM) procedures as defined in 3GPP TS 23.401 on the S1-MME, S3, Gn, and S10 interfaces.

RIM procedures allow the MME to exchange information between applications belonging to the RAN nodes. The MME provides addressing, routing and relaying support for the RAN information exchange.

It provides a mechanism to track a UE which is in idle state for EPS connection management.

To reach a UE in idle state the MME initiates paging to all eNodeBs in all tracking areas in the TA list assigned to the UE. The EPS session manager have knowledge about all the eNodeB associations to the MME and generates a list of eNodeBs that needs to be paged to reach a particular UE.

The location of a UE in ECM-IDLE state is known by the network on a Tracking Area List granularity. A UE in ECM-IDLE state is paged in all cells of the Tracking Areas in which it is currently registered. The UE may be registered in multiple Tracking Areas. A UE performs periodic Tracking Area Updates to ensure its reachability from the network.

This sections describes multi-homing support for specific interfaces on the MME.

The S-GW supports independent service areas from MME pooling areas. Each cell is associated to a pool of MMEs and a pool of Serving Gateways. Once a cell selects an MME, that MME is able to select an S-GW which is in an S-GW pool supported by the cell.

Static S-GW pools can be configurable on the MME. Each pool is organized as a set of S-GWs and the Tracking Area Identities (TAIs) supported by them, known as a service area (SA). The incoming TAI is used to select an SA. Then, based on protocol and statistical weight factors, an S-GW is selected from the pool serving that SA. The same list of S-GWs may serve multiple TAIs. Static S-GW pools are used if there is no DNS configured or as a fallback if DNS discovery fails.

For additional Information on TAI lists, refer to the Tracking Area List Management section in this overview.

The Serving Gateway (S-GW) selection function selects an available S-GW to serve a UE. This feature reduces the probability of changing the S-GW and a load balancing between S-GWs. The MME uses DNS procedures for S-GW selection.

The selection is based on network topology the selected S-GW serves the UE's location, and in the case of overlapping S-GW service areas, the selection may prefer S-GWs with service areas that reduce the probability of changing the S-GW. If a subscriber of a GTP-only network roams into a PMIP network, the PDN GWs (P-GWs) selected for local breakout supports the PMIP protocol, while P-GWs for home routed traffic use GTP. This means the S-GW selected for such subscribers may need to support both GTP and PMIP, so that it is possible to set up both local breakout and home routed sessions for these subscribers.

This support provides a foundation for contributing towards improved Quality of User Experience (QoE) by enabling deterministic end-to-end forwarding and scheduling treatments for different services or classes of applications pursuant to their requirements for committed bandwidth resources, jitter and delay. In this way, each application receives the service treatment that users expect.

The MME Operator Policy configuration allows the specification of QoS for each traffic class that can either be used as a default or as an over ride to the HSS settings.

In LTE-EPC 4G architectures, QoS management is network controlled via dynamic policy interactions between the PCRF and PDN GW. EPS bearer management is used to establish, modify or remove dedicated EPC bearers in order to provide service treatments tied to the needs of specific applications/service data flows. The service priority is provisioned based on QoS Class Identifiers (QCI) in the Gx policy signaling. PCRF signaling interaction may also be used to establish or modify the APN-AMBR attribute assigned to the default EPS bearer.

When it is necessary to set-up a dedicated bearer, the PDN GW initiates the Create Dedicated Bearer Request which includes the IMSI (permanent identity of mobile access terminal), Traffic Flow Template (TFT - 5-tuple packet filters) and S5 Tunnel Endpoint ID (TEID) information that is propagated downstream via the S-GW over the S11 interface to the MME. The Dedicated Bearer signaling includes requested QoS information such as QCI, Allocation and Retention Priority (ARP), Guaranteed Bit Rate (GBR - guaranteed minimum sending rate) and Maximum Bit Rate (MBR- maximum burst size).

The MME allocates a unique EPS bearer identity for every dedicated bearer and encodes this information in a Session Management Request that includes Protocol Transaction ID (PTI), TFT's and EPS bearer QoS parameters. The MME signals the Bearer Setup Request in the S1-MME message toward the neighboring eNodeB.

The subscriber-level Session Tracing provides a 3GPP standards-based session-level trace function for call debugging and testing new functions and access terminals in an LTE environment. In general, the Session Tracing capability records and forwards all control activity for the monitored subscriber on the monitored interfaces. This is typically all the signaling and authentication/subscriber services messages that flow when a UE connects to the access network.

For more information about this functionality, see the Session Tracing chapter in this guide.

In compliance with 3GPP TS 29.272 v11.9.0, the MME sends the "State/Location-Information-Retrieval" flag set in the Feature-List AVP of the Update Location Request (ULR) message over the S6a interface to the HSS at the time the UE attaches. With the "State/Location-Information-Retrieval" flag set, the HSS knows to set the "EPS User State Request", "EPS Location Information Request" and "Current Location Request" bits in the IDR-Flags AVP in IDR messages towards the MME. This subscriber data provides the UE's current location information needed in multiple service scenarios, such as VoLTE services on the IMS side.

For more information about this functionality, see the State-Location Information-Retrieval Flag feature chapter in this guide.

This enhancement is a 3GPP TS (29.274 and 29.060) release compliance enhancement. As per 3GPP TS 29.274 and TS 29.060,the source-serving node (MME/SGSN) is allowed to reject SGSN Context Request (GTPv1) and Context Request (GTPv2) mobility management messages with "Target Access Restricted for the subscriber" cause if target access is restricted for the subscriber based on the Access-Restriction-Data in the subscription profile. The target node (MME/SGSN) is allowed to reject RAU/TAU with anyone one of the following NAS Causes:

New statistics have been introduced under "show egtpc statistics verbose" and "show sgtpc statistics verbose" to reflect the context response sent and received with the new reject cause "Target Access Restricted for the subscriber".

Rejecting RAU/TAU much early in call cycle results in reduced signaling.

Important

No new CLI is provided for GTP cause code mapping to EMM/NAS cause. RAU Reject will always be sent with NAS cause "No suitable cells in location area" and TAU Reject will always be sent with EMM cause "No suitable cells in Tracking Area".

Important

The MME and SGSN revert to the old behavior as per earlier releases if the peer node is not capable of sending the RAT-TYPE IE in CONTEXT-REQ message.

For more information refer to the 3GPP TS 29.274 (section 7.3.6), TS 29.060 (section 7.5.4), TS 29.060 Annex B (Table B.5: Mapping from Gn/Gp to NAS Cause values Rejection indication from SGSN) and TS 29.274 Annex C ( Table C.5: Mapping from S3/S16 to NAS Cause values Rejection indication from MME/S4-SGSN)

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage. Typically, these conditions are temporary (i.e high CPU utilization, or packet collisions on a network) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.

The system supports Threshold Crossing Alerts for certain key resources such as CPU, memory, number of sessions etc. With this capability, the operator can configure threshold on these resources whereby, should the resource depletion cross the configured threshold, a SNMP Trap would be sent.

The following thresholding models are supported by the system:

Thresholding reports conditions using one of the following mechanisms:

Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get displayed. SNMP traps are supported in both Alert and Alarm modes.

Logs are supported in both the Alert and the Alarm models.

The Alarm System is used only in conjunction with the Alarm model.

Important

For more information on threshold crossing alert configuration, refer to the Thresholding Configuration Guide.

Provides the functions to allocate and reallocate a Tracking Area Identity (TAI) list to the UE to minimize Tracking Area Updates (TAUs).

The MME assigns the TAI list to a UE so as to minimize the TAUs that are sent by the UE. The TAI list should be kept to a minimum in order to maintain a lower paging load.

The MME allows up to 16 tracking areas configured locally to be included and sent to the mobile station in Tracking Area List IE as part of Attach/TAU Accept message.

The MME allows seamless inter-RAT interworking when the operator's networks are configured with LACs allocated from the reserved space of 32K to 64K. 3GPP Specifications have reserved this space for LTE MME Group IDs. The MME and SGSN can distinguish between UMTS IDs (P-TMSI/RAI) and LTE IDs (GUTI) by configuring an MME group ID to PLMN ID mapping.

Use Case 1: When a UE moves from 3G to LTE, the UE maps the P-TMSI and RAI to GUTI and uses this mapped GUTI in the TAU Attach Request that it sends to the MME. At the MME, this mapped GUTI gets reverse mapped to P-TMSI and RAI, which are used to fetch the UE's Context from the old SGSN.

Use Case 1: When a UE moves from LTE to 3G, the UE maps the GUTI to P-TMSI and RAI, and performs a RAU Attach to the SGSN. A Pre-Rel8 SGSN would attempt to fetch the UE's context over the Gn/Gp interface using the mapped P-TMSI and RAI. At the MME, the P-TMSI and RAI are reverse mapped to GUTI to fetch the locally stored UE's context. An S3-SGSN also behaves similar to Pre-Rel8 SGSN except for the way it discovers the source MME. S3-SGSN identifies the P-TMSI & RAI received in RAU Request as a mapped one and performs LTE specific DNS query using MME ID, to discover the source MME.

For the two use cases above, the MME/S3-SGSN would need to identify whether a given UMTS or LTE ID is a native one or a mapped one. MME GroupID or LAC is used to make this distinction. If the Most Significant Bit(MSB) in LAC is set then the UMTS ID is mapped from LTE. Similarly, if the MSB of MME Group ID is zero then the LTE ID is mapped from UMTS. If the standard defined ranges are not complied, the target MME/S3-SGSN may incorrectly conclude the source node as S3-SGSN/MME. This misinterpretation would lead to unsuccessful attempt to resolve the source node since the DNS query is formulated with the assumption that the source node is either MME or S3-SGSN.

In order to address networks where the 1/0 MSB logic does not apply, the MME and SGSN can rely on a global database of MME Group IDs (configured via CLI) instead of the standards specified MSB, to distinguish between mapped and native UMTS and LTE IDs.

The MME consults this database of MME Group IDs when the below two conditions apply:

1. The MME is not aware of the received GUTI Type, such as when either the UE or the network are not Release 10 compliant.

2. MME-Service is associated with the MME Group ID database.

Refer to Configuring UMTS to LTE ID Mapping in Chapter 2 of this document for steps to create and configure this database and to associate the MME service to this database.

Offloading of a certain percentage of users can be configured using the mme offload command. The MME sends S1 Release (with cause "load balancing TAU required" for offload) to the configured percentage of UEs attached to the MME. The MME does not distinguish between VoLTE and Non-VoLTE subscribers. Some subscribers with voice bearers are also offloaded as a result calls are dropped. This feature enhancement is targeted to preserve VoLTE voice bearers during MME offloading. A new CLI keyword is added to the mme offload command to preserve VoLTE subscribers (QCI = 1) from offloading until voice calls are terminated.

Note	This feature enhancement is license controlled. Contact your Cisco Account or Support representative for information on how to obtain a license.

MME sends "Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions" to HSS only for SRVCC capable UEs. Once MME is configured with the network-feature-support-ie ims-voice-over-ps supported srvcc-ue CLI command, only "SRVCC capable" and "SRVCC subscribed" UEs are allowed to make VoLTE calls. SRVCC non-capable UEs have to do CSFB to get the voice services. This ensures that the UEs not capable of SRVCC will not experience any call disconnects if they move between 4G and 3G networks.

In releases prior to 21.5, MME used to allow all subscribed users to make VoLTE call irrespective of whether SRVCC was supported by the UE or not when network-feature-support-ie ims-voice-over-ps support CLI command was configured.

128K eNodeB Connection Support

The MME now supports 128K eNodeB connections for VPC-DI and ASR5500-DPC2 platforms; it has been enhanced from 64K eNodeB connections. A MME manager instance supports 4K eNodeBs, a minimum of 32 MME managers are required to support 128K eNodeB's. If the network has more than 32 MME managers, 128k eNodeB connections limit is not enforced. The support for 128K eNodeB connections is per chassis and not per MME service.

The maximum number of MME managers that can be configured per chassis for the VPC-DI platform has been enhanced from "24" to "48".

Distribution of Multiple SCTP Association - VLR

The SCTP associations of a VLR are now distributed across MME managers. Distribution of VLR SCTP associations across MME managers helps in achieving better load distribution at the MME managers.

There is no change for load balancing of SGs messages sent by MME across multiple SCTP associations of a VLR.

S1-SCTP Rate Limiting

The operator can now configure a rate limit for incoming S1 SCTP connections from the eNodeB. This prevents an overload at the MME in case there is a surge of S1 SCTP connections from the eNodeBs. New command keywords s1-sctp rate limit are introduced in the task facility mmedemux command, they can be used to specify the rate limit value of connections per second for the chassis. New MME Demux subsystem statistics are introduced to display the number of packets that are dropped due to the configured rate limit.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

This feature enables operators to limit the rate at which the MME processes new connections (attaches, TAU requests, and forward relocation requests) which in turn reduces the signaling on the external nodes.

See the network-overload-protection mme-new-connections-per-second command in the Global Configuration Mode Commands chapter of the Command Line Reference for more information.

The Cell Traffic Trace feature provides a 3GPP standard-based cell trace function for tracing all calls in a single cell or multiple cells. Cell Tracing provides the capability to log on to data on any interface at a call level for a specific user or mobile type or a service initiated by a user. In addition, Cell Tracing provides instantaneous values for a specific event.

The Cell Traffic Trace feature is license controlled. Contact your Cisco Account or Support representative for information on how to obtain a license.

For more information on Cell Traffic Trace refer to the Cell Traffic Trace feature chapter.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

Circuit Switched Fallback (CSFB) enables the UE to camp on an EUTRAN cell and originate or terminate voice calls through a forced switch over to the circuit switched (CS) domain or other CS-domain services (e.g., Location Services (LCS) or supplementary services). Additionally, SMS delivery via the CS core network is realized without CSFB. Since LTE EPC networks were not meant to directly anchor CS connections, when any CS voice services are initiated, any PS based data activities on the E-UTRAN network will be temporarily suspended (either the data transfer is suspended or the packet switched connection is handed over to the 2G/3G network).

For additional information, refer to the CSFB and SMS over SGs Interface section in this guide.

This functionality requires valid license keys be installed. Contact your Cisco Account or Support Representative for information required licenses.

The MME already supports circuit switched fallback (CSFB) and single radio voice call continuity (SRVCC) for E-UTRAN. The MME has expanded support to normal and enhanced CSFB and SRVCC for CDMA 1xRTT (single-carrier radio transmission technology) networks.

The primary purpose of either CSFB or SRVCC for CDMA is to enable a UE from an LTE network to move seamlessly to a CDMA network and ensure that CDMA2000 messages are received from the UE and then relayed to the MSC (or vice-versa) through S1-APP and S102 interfaces. The MME will use the S102 interface to tunnel the 1xRTT messages between the MME and IWF/MSC.

For details on these functions and their configuration, refer to the CSFB for 1xRTT and SRVCC for 1xRTT feature chapters in this administration guide.

In the Public Safety LTE (PS-LTE) network, every MME is co-located with an S-GW and at least one P-GW, and the MME must always use the co-located S-GW and a co-located P-GW for all calls that it handles. This requires configuring the IP addresses of the S11 interface of the S-GW as part of the MME service configuration, and the S5/S8 interface of the P-GW as part of an APN profile configuration. An MME configured for PS-LTE network operation will not send any DNS queries for S-GW or P-GW lookup, it will only use the S-GW configured for PS-LTE operation and the P-GW configured in the matching APN profile regardless of any other configuration present.

All intra-MME S1 and X2 handovers and all TAU Requests with a local GUTI will be serviced by the same S-GW that is configured for PS-LTE network operation with the P-GW(s) used at the time of the initial Attach or relocation to the MME. S-GW relocation is neither necessary nor supported for intra-MME handovers or intra-MME TAU Requests

This feature allows the co-location of the MME, P-GW and S-GW nodes for Public Safety deployments.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

The DDN Throttling feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

In this feature, MME is provisioned to reject non-priority (traffic based on ARP and LAPI) Downlink Data Notification (DDN) requests when the UE is in idle mode. Additionally, MME dynamically requests S-GW to reduce the number of DDN requests based on a throttling factor and a throttling delay specified in the DDN Ack message.

For more information on configuring this functionality, refer to DDN Throttling chapter of the MME Administration Guide.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

This feature builds on the functionality provided by the Congestion Control and Overload Control features described in the Features and Functionality - Base Software section.

For more information on configuring this functionality, refer to Enhanced Congestion Control and Overload Control chapter of the MME Administration Guide.

This feature is developed to provide MME support for eMPS (Enhanced Multimedia Priority Service) in PS (Packet Switched) and CS (Circuit Switched) domains. If UEs subscription information contains MPS-Priority AVP and the MPS-EPS-Priority bit set, the MME classifies such UEs for Enhanced Multimedia Priority Service (eMPS) in PS domain. The MME includes paging priority IE in S1 AP Paging message if it receives events like DDN/CBR/UBR for users having MPS EPS subscription. The MME also supports priority SRVCC handovers by providing ARP information to the MSC in SRVCC PS to CS Request message.

The HSS-based P-CSCF Restoration feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

PCSCF Restoration aids in successful establishment of MT VoLTE calls when the serving P-CSCF has failed or unreachable.

The HSS-based P-CSCF Restoration mechanism is executed when a terminating request cannot be serviced due to a P-CSCF failure. The execution is possible if there are no other registration flows available for the terminating UE using an available P-CSCF.

The HSS-based P-CSCF restoration consists of a basic mechanism that makes usage of a path through HSS and MME/SGSN to request the release of the IMS PDN connection to the corresponding UE and an optional extension that avoids the IMS PDN deactivation and re-activation.

The HSS-based P-CSCF Restoration complies with the following standard: 3gpp TS 23.380 section 5.4 HSS-based P-CSCF Restoration.

For more information on configuring this functionality, refer to HSS-based P-CSCF Restoration chapter of the MME Administration Guide.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

Idle-mode Signaling Reduction (ISR) allows a UE to be registered on (and roam between) E-UTRAN and UTRAN/GERAN networks while reducing the frequency of TAU and RAU procedures and overall signaling.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

IP Security (IPSec) is a suite of protocols that interact with one another to provide secure private communications across IP networks. These protocols allow the system to establish and maintain secure tunnels with peer security gateways.

IPSec can be implemented on the system for the following applications:

Important

Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.

The following figure shows IPSec configurations.

Important

For more information on IPSec support, refer to the Cisco StarOS IP Security (IPSec) Reference.

The MME supports the IP Network Enabler (IPNE), a Mobile and IP Network Enabler (MINE) client component that collects and distributes session and network information to MINE servers.

Important

This feature, with its CLI commands, counters, and statistics, are all under development for future use and are not yet fully qualified.

The MINE cloud service provides a central portal for wireless operators and partners to share and exchange session and network information to realize intelligent services.

Implementation of this feature requires configuration of an IPNE Service that is then associated with the MME Service refer to the IPNE Service Configuration Mode Commands and MME Service Configuration Mode Commands in the Command Line Interface Reference manual. This feature and its configuration are described in greater detail in the IPNE Service chapter in this guide.

IPNE and MINE clients are each licensed Cisco features. Contact your Cisco account representative for information on licensing requirements. For additional information about this feature and how to configure it, refer to the section on IPNE Service in this guide.

The Lawful Intercept feature-use license is included in the MME session-use license.

The Cisco Lawful Intercept feature is supported on the MME. Lawful Intercept is a license-enabled, standards-based feature that provides telecommunications service providers with a mechanism to assist law enforcement agencies in monitoring suspicious individuals for potential illegal activity. For additional information and documentation on the Lawful Intercept feature, contact your Cisco account representative.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

LoCation Services (LCS) on the MME and SGSN is a 3GPP standards-compliant feature that enables the system (MME or SGSN) to collect and use or share location (geographical position) information for connected UEs in support of a variety of location services.

The SLs interface is used to convey LCS Application Protocol (LCS-AP) messages and parameters between the MME to the Evolved Serving Mobile Location Center (E-SMLC). It is also used for tunnelling LTE Positioning Protocols (LPP between the E-SMLC and the target UE, LPPa between the E-SMLC and the eNodeB), which are transparent to the MME.

Refer to the Location Services chapter in the MME Administration Guide for more information.

The MME provides full 3GPP TS 23.246 support for the LTE version of multimedia broadcast / multicast service (MBMS) -- eMBMS. Running the Cisco MME-eMBMS service on the MME, the MME communicates with the MBMS GW and the MCE using Sm and M3 interfaces. MME-eMBMS facilitates sessions scheduled by the BM-SC, identifies service areas to be served by a particular MBMS session, and handles session start, update, and stop as well as setup and configuration requests from the MCEs.

The Sm and M3 interfaces for MME-eMBMS require that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

For more information on configuring this functionality, refer to MBMS for MME (eMBMS) chapter of the MME Administration Guide.

This feature requires that a valid MME Resiliency license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

P-GW Restart Notification Procedure is a standards-based procedure supported on the S-GW to notify detection of P-GW failure to the MME/S4-SGSN. P-GW failure detection is performed by the S-GW when it detects that the P-GW has restarted (based on restart counter received from the restarted P-GW) or when it detects that P-GW has failed but not restarted (based on path failure detection). When an S-GW detects that a peer P-GW has restarted, it deletes all PDN connection table data and bearer contexts associated with the failed P-GW and notifies the MME via P-GW Restart Notification. The S-GW indicates in the echo request/response on S11/S4 interface that the P-GW Restart Notification procedure is supported.

P-GW Restart Notification Procedure is an optional procedure and is invoked only if both the peers, MME/S4-SGSN and S-GW, support it.

In the absence of this procedure, the S-GW will initiate the Delete procedure to clear all the PDNs anchored at that failed P-GW, which can lead to flooding of GTP messages on S11/S4 interface if there are multiple PDNs using that S-GW and P-GW.

The MME adds support for the P-GW restart handling procedures as specified in 3GPP TS 23.007 v11.6.0. An S-GW will send the "PGW Restart Notification" message only to the SGSNs / MMEs that indicated their support of this feature through the Echo Request -> Node Features IE -> PRN bit.

This feature reduces the S11 signaling load between the S-GW and MME in case of a P-GW restart.

PDN Deactivation Behavior

PDN Deactivation Rate

By default, the MME will perform deactivations at the rate of 100 PDNs ( 50 Idle + 50 Connected) per session manager per second. This rate will be applied to MME specific pacing queues ( Idle & Connected).

This default pacing rate can be altered using the MME Messaging Rate Control feature.

Refer to the MME Administration Guide and to the network-overload-protection mme-tx-msg-rate command in the Global Configuration Mode Commands chapter of the Command Line Interface Reference for more information about this feature.

Note: Configuration of this deactivation rate should be based on appropriate dimensioning exercise to arrive at the appropriate rate.

PDN Reactivation Behavior

After the affected subscribers have been deactivated, the MME will prioritize the re-activation of impacted PDN connections based on subscribed APN restoration priority, if received from the HSS. If an APN restoration priority is not received from the HSS, then this locally configured value is used. If there is no local configuration then by default such PDNs will be assigned the lowest restoration priority.

Limitations

Currently, the MME does not deactivate a PDN connection upon receiving P-GW Restart Notification when the P-GW serving the PDN is dual IP stack.

The PGW Restart Notification is received with cause PGW-NOT-RESPONDING, however the MME is not able to find the matching P-GW entry as the MME stores either IPv4 or IPv6 PGW address.

This occurs when the PGW Restart Notification does not contain the P-GW IP address stored by MME.

This feature requires that a valid MME Resiliency license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

This feature provides controls to mitigate the undesirable effects of congestion due to excessive S1 Paging load or upon failure of an EGTPC path.

See the network-overload-protection mme-tx-msg-rate-control command in the Global Configuration Mode Commands chapter of the Command Line Reference for more information.

The feature implements the Network Triggered Service Restoration (NTSR) procedures defined in 3GPP TS 23.007 Release 11 (DDN with IMSI) on the MME.

By implementing the extensions to the standard MME restoration, the robustness of the network is greatly enhanced and potential issues due to the MME downtime are mitigated.

The solution to recover from MME node failures proposed in the 3GPP standards rely on the deployment of MME pools where each pool services a coverage area. Following a MME failure, the S-GW and MSC/VLR nodes may select the same MME that used to service a UE, if it has restarted, or an alternate MME in the same pool to process Network-initiated signaling that it received in accordance with the NTSR procedures defined in 3GPP TS 23.007 Release 11.

Upon receipt of a DDN without any TAI list or other previously sent information from the S-GW after a MME failure or restart, the MME shall proceed with regular IMSI-based paging.

The MME can be configured to throttle IMSI-based DDN requests as needed to maintain adequate service performance for normal procedure processing. Refer to the network-overload-protection mme-new-connections-per-second command in the Global Configuration Mode Commands chapter of the Command Line Interface Reference.

The MTC feature set allows the operator to handle the signaling storm MTC devices can bring to the network thus ensuring a more robust network and more efficient resource utilization The MME supports several of the 3GPP TS23.401 R10 machine type communications (MTC) overload control mechanisms to be used in the handling of signaling bursts from machine-to-machine (M2M) devices.

The MTC feature set requires that a valid license key be installed.This license will be enforced for usage of related commands. Contact your Cisco Account or Support representative for information on how to obtain a license.

Network provided Location Info (NPLI) enables the MME to send user location information (ULI) to the P-GW/S-GW (and consequently PCRF) in a number of Session Management messages. This information is required for Lawful Intercept (LI), VoLTE, aids in charging in the IMS domain.

The MME supports the PCC-EPC based framework is defined in 3GPP TR 23.842 section 6.4, which allows the P-CSCF to request the user location through PCRF when it needs it (for example at voice call establishment).

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

No special configuration is required to enable this functionality.

Note: NPLI related IEs in CSReq and DSReq messages will be sent only in case of PDN establishment, but not in case of SGW relocation.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

Also known as heuristic or idle-mode paging, this feature reduces network operations cost through more efficient utilization of paging resources and reduced paging load in the EUTRAN access network.

Idle mode paging over EUTRAN access networks is an expensive operation that causes volumes of signaling traffic between the S-GW and MME/SGSN. This problem is acute in the radio access network, where paging is a shared resource with finite capacity. When a request for an idle mode access terminal is received by the S-GW, the MME floods the paging notification message to all eNodeBs in the Tracking Area List (TAI). To appreciate the magnitude of the problem, consider a network with three million subscribers and a total of 800 eNodeBs in the TAI. If each subscriber was to receive one page during the busy hour, the total number of paging messages would exceed one million messages per second.

To limit the volume of unnecessary paging related signaling, the Cisco MME provides intelligent paging heuristics. Each MME maintains a list of "n" last heard from eNodeBs inside the TAI for the UE. The intent is to keep track of the eNodeBs that the AT commonly attaches to such as the cells located near a person's residence and place of work. During the average day, the typical worker spends the most time attaching to one of these two locations. When an incoming page arrives for the idle mode user, the MME attempts to page the user at the last heard from eNodeB. The MME uses Tracking Area Updates to build this local table. If no response is received within a configurable period, the MME attempts to page the user at the last "n" heard from eNodeBs. If the MME has still not received acknowledgment from the idle mode UE, only then does it flood the paging messages to all eNodeBs in the TAI.

In the majority of instances with this procedure, the UE will be paged in a small set of eNodeBs where it is most likely to be attached.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

Overcharging Protection helps in avoiding charging subscribers for dropped downlink packets while the UE is in idle mode. This feature helps ensure subscribers are not overcharged while the subscriber is in idle mode.

Refer to the Overcharging Protection chapter in the MME Administration Guide for more information.

In Release 20.0, MME has been enhanced to support new standardized QCIs 65, 66, 69 and 70. Also, MME also supports operator specific (non-standard) QCIs from 128 to 254. The non-standard QCIs provides Operator Specific QoS for M2M and other mission critical communications.

The operator-defined-qci command under the QoS profile configuration is provisioned to enable or disable Operator Specific QCI. When enabled, MME accepts Operator Specific QCI values (128-254) both from HSS and PGW. If not enabled, MME will reject the procedure on receiving any Operator Specific QCI value.

Additionally, this chapter describes the mapping of operator specific QCIs to Pre-Release8 QoS parameters during a handover to UTRAN/GERAN.

The Operator Specific and Non-Standard QCI Support feature is license controlled. Contact your Cisco Account or Support representative for information on how to obtain a license.

For a complete description of this feature and its configuration requirements, refer to the Operator Specific QCI chapter in MME Administration Guide.

GTP echo and GTP message retry timer can be configured separately. The maximum retry number can also be configured separately, in a similar fashion as the timer configuration.

In egtp-service, the echo-max-retransmissions keyword is added to allow the separate configuration of GTPC echo retransmission.

Previous Behavior: The maximum number of retransmission for Echo Requests was configured by max-retransmissions configuration option.

New Behavior: echo-max-retransmissions is introduced explicitly for the configuration of echo max retransmission in the eGTPC Service Configuration Mode.

The feature use license for Session Recovery on the MME is included in the MME session use license.

The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system preventing a fully connected user session from being disconnected.

The SGSN-MME Combo Optimization feature enables the co-located SGSN and MME to co-operate with each other in order to achieve lower memory utilization, lower CPU utilization, and reduced signaling towards other nodes in the network.

The SGSN and MME can be enabled simultaneously in the same chassis and, though co-located, they each behave as independent nodes. When functioning as mutually-aware co-located nodes, the SGSN and MME can share UE Subscription data.

For detailed Combo Optimization feature and implementation description see the SGSN-MME Combo Optimization section in the MME Administration Guide, StarOS Release 18.

Combo Optimization functionality for both the SGSN and the MME is a licensed Cisco feature. Contact your Cisco account representative for information on acquiring this separate feature license or for any other licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section in the System Administration Guide.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

Voice over IP (VoIP) subscribers anchored in the IP Multimedia Subsystem (IMS) network can move out of an LTE coverage area and continue the call over the circuit-switched (CS) network through the use of the Single Radio Voice Call Continuity (SRVCC) feature. The smooth handover of the VoIP call does not require dual-mode radio.

For more information about SRVCC, refer to the Single Radio Voice Call Continuity chapter in this document.

This feature helps the MME to reduce network load from periodic TAU signaling and to increase the time until the UE detects a potential need for changing the RAT or PLMN.

The feature enables the Operator to configure longer values for the periodic TAU timer and Mobile Reachable timer using new commands on the MME.

A new configuration is supported under the MME Service to define an EMM extended-3412 timer value. Refer to the Command Changes section below for more information.

The UE must include the "MS network feature support" IE in the Attach Request/TAU Request. This IE indicates to the MME that the UE supports the extended periodic timer T3412, in which case the MME sends the extended-3412 IE in the attach/TAU response. The MME will not forward the extended-T3412 timer value to any UE which has not indicated that it supports this extended-t3412 timer.

The MME supports storing the Subscribed-Periodic-RAU-TAU-Timer value if received as part of subscription data, and deleting this stored value if the corresponding withdrawal flag is received in the DSR command.

For homers, the MME will send the extended-3412 IE value as received in Subscribed-Periodic-RAU-TAU-Timer IE in subscription data.

For roamers, the MME takes the presence of Subscribed-Periodic-RAU-TAU-Timer IE in subscription data as an indication and shall send the extended-3412 IE with the value from the local configuration.

The MME adjusts the configured mobile reachability timer value if the subscribed extended-3412 timer value received from HSS is greater than the sum of the mobile reachability timer + implicit detach timer such that the extended-3412 timer value becomes 10 less than the mobile reachability timer + implicit detach timer.

Refer to 3GPP TS 23.401 Section 4.3.17.3 (Version 10.4.0) & 29.272 for more details.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

Under congestion, the MME can now assign EMM or ESM back-off timer to the UEs and request the UEs not to access the network for a given period of time.

Refer to 3GPP TS 23.401 Section 4.3.7.4.2.4 (Version 10.4.0) for more details.

EMM T3346 Timer

The MME now allows configuration of the T3346 back-off timer value. EMM timer value. The default value of this timer will be set to 25 minutes.

With this feature, when any EMM request rejected by MME because of congestion, the reject will have EMM cause of "congestion" (22) and will include the back-off timer (T3346) IE. This back-off timer is chosen randomly and will be 10 below or above the configured T3346 timer value.

While storing the back-off timer expiry time, MME shall adjust the mobile reachability timer and/or implicit detach timer. This is to make sure that the sum of the mobile reachability timer + implicit detach timer is greater than the back-off timer duration.

The MME will store the DB for at least the EMM back-off timer duration even if the attach is rejected because of congestion. The MME will not start any timer for EMM back-off. Instead, back-off timer expiry time will be stored in the DB as the DB is stored for at least back-off timer duration.

If an EMM call is rejected due to congestion control for EMM, the DB created during ULA will not be cleared and the purge timer will be started for a time period 10 greater than the back-off timer duration. This is done to make sure that DB is available during back-off timer duration to reject any requests during this period and also to avoid the HSS signaling again if the UE comes back immediately after the back-off timer duration.

The MME will not reject any TAU received in EMM-CONNECTED state.

The MME will not reject any requests related to handovers as part of this feature even if EMM back-off timer is running.

The MME will drop attach requests received during congestion while EMM back-off timer is running based on configuration in congestion-action-profile. For example, if configuration is enabled to reject new call only when low priority indication is set and the UE comes without low priority indication while back off timer is running, the MME will accept the new call attempt from the UE.

The MME will not reject/drop attach requests received even if EMM back-off timer is running if the congestion gets cleared.

The MME will forward SGS paging requests received from MSC for a UE attached in MME even if back-off timer is running.

ESM T3396 Timer

The MME allows configuration of the T3396 back-off timer value. When any ESM request is rejected because of congestion, the reject will have ESM cause "Insufficient resources" and will include a back-off timer IE (T3396). This back-off timer is chosen randomly and will be 10 below or above the configured T3396 timer value.

The MME will not start any timer for SM back-off and store the SM back-off timer expiry time. If an SM request is received and if congestion exists, the request will be rejected and a new random value will be sent as the ESM back-off timer value. The MME will reject any subsequent requests from the UE targeting the same APN based on the presence of congestion at that time and not based on the SM back-off time previously sent to the UE.

The T3396 timeout is configurable only for the ESM cause values - 26 'insufficient resources' or 27 'missing or unknown APN'. If the ESM cause value is 26 "insufficient resources" or 27 "missing or unknown APN", the MME will include a value for timer T3396 in the reject message. If the ESM cause value is 26 "insufficient resources" and the request message was sent by a UE accessing the network with access class 11 - 15 or if the request type in the PDN CONNECTIVITY REQUEST message was set to "emergency", the MME will not include a value for timer T3396.

In 21.3 and later releases, the T3396 timer can be configured at APN Profile and Call Control Profile to control the UE behavior depending on the APN and subscriber type. This is compliant with 3GPP TS 24.301 (section 6.5.1.4) and specifically intended for VoLTE signaling control for subscribers that have no IMS subscription. This enhancement can also limit the number of Attach attempts for such subscribers and reduce the signaling impact on EPC nodes.

The T3396 timeout configuration will be applied from APN Profile, Call Control Profile and MME service in decreasing order of precedence. In releases prior to 21.3, the T3396 timeout could only be configured at the MME service level and the cause value could not be specified. If the ESM message is rejected with either of the cause values, the network will include a value for T3396 timer in ESM reject message. UE will not retry the ESM request message until the T3396 timer expires.

This feature requires that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

User Location Information (ULI) Reporting allows the eNodeB to report the location of a UE to the MME, when requested by a P-GW.

The start/stop trigger for location reporting for a UE is reported to the MME by the S-GW over the S11 interface. The Change Reporting Action (CRA) Information Element (IE) is used for this purpose. The MME updates the location to the S-GW using the User Location Information (ULI) IE.

Important

Information on configuring User Location Information Reporting support is located in the Configuring Optional Features on the MME section of the Mobility Management Entity Configuration chapter in this guide.

These features require that a valid license key be installed. Contact your Cisco Account or Support representative for information on how to obtain a license.

Refer to the VLR Management chapter in the MME Administration Guide for more information about these features.

EPS Bearer context processing is based on the APN that the subscriber is attempting to access. Templates for all of the possible APNs that subscribers will be accessing must be configured within the P-GW system.

A total of 11 EPS bearer contexts are supported per subscriber. These could be all dedicated, or 1 default and 10 dedicated or any combination of default and dedicated context. Note that there must be at least one default EPS bearer context in order for dedicated context to come up.

The purge procedure is employed by the Cisco MME to inform the concerned node that the MME has removed the EPS bearer contexts of a detached UE. This is usually invoked when the number of records exceeds the maximum capacity of the system.

Paging is initiated when there is data to be sent to an idle UE to trigger a service request from the UE. Once the UE reaches connected state, the data is forwarded to it.

Paging retransmission can be controlled by configuring a paging-timer and retransmission attempts on system.

The following figure and the text that follows describe the message flow for a successful user-initiated subscriber attach procedure.

Service Request procedures are used to establish a secure connection to the MME as well as request resource reservation for active contexts. The MME allows configuration of the following service request procedures:

For call flow details for these procedures, refer to the following sections.

• 3GPP TS 23.007 V13.3.0:Technical Specification Group Core Network and Terminals Restoration procedures

• 3GPP TS 23.041 V10.6.0: Technical realization of Cell Broadcast Service (CBS)

• 3GPP TS 23.216 V12.2.0: 3rd Generation Partnership Project Technical Specification Group Services and System Aspects Single Radio Voice Call Continuity (SRVCC) Stage 2

• 3GPP TS 23.251 V12.1.0: Network Sharing; Architecture and Functional Description

• 3GPP TS 23.271, v10.4.0 (2013-03): Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE. Functional stage 2 description of Location Services (LCS)

• 3GPP TS 23.272 V12.5.0: 3rd Generation Partnership Project Technical Specification Group Services and System Aspects Circuit Switched (CS) fallback in Evolved Packet System (EPS) Stage 2

• 3GPP TS 23.401 V13.11.0: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access

• 3GPP TS 23.682 V13.9.0: Architecture enhancements to facilitate communications with packet data networks and applications

• 3GPP TS 23.842 V11.0.0:3rd Generation Partnership Project Technical Specification Group Services and System Aspects Study on Network Provided Location Information to the IMS

• 3GPP TS 24.008 V13.0.0 (2016-06): Mobile radio interface Layer 3 specification; Core network protocols; Stage 3

• 3GPP TS 24.008 V13.6.0 (2016-06): Mobile radio interface Layer 3 specification; Core network protocols; Stage 3

• 3GPP TS 24.080, V12.8.0: Mobile radio interface layer 3 supplementary services specification Formats and coding

• 3GPP TS 24.301 V12.8.0: 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) Stage 3

• 3GPP TS 24.301 V13.10.0: 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) Stage 3

• 3GPP TS 29.118 V10.9.0: 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals Mobility Management Entity (MME) - Visitor Location Register (VLR) SGs interface specification

• 3GPP TS 29.168 V12.8.0: Cell Broadcast Centre Interfaces with the Evolved Packet Core

• 3GPP TS 29.171 V12.1.0: 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals Location Services (LCS) LCS Application Protocol (LCS-AP) between the Mobile Management Entity (MME) and Evolved Serving Mobile Location Centre (E-SMLC) SLs interface

• 3GPP TS 29.172 V12.5.0 : 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals Location Services (LCS) Evolved Packet Core (EPC) LCS Protocol (ELP) between the Gateway Mobile Location Centre (GMLC) and the Mobile Management Entity (MME) SLg interface

• 3GPP TS 29.272 V12.7.0: 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals 3GPP Evolved Packet System (EPS) Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol

• 3GPP TS 29.274 V12.8.0: 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals 3GPP Evolved Packet System (EPS) Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C) Stage 3

• 3GPP TS 29.277 V12.0.0: 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals Optimised Handover Procedures and Protocol between EUTRAN access and non-3GPP accesses (S102) Stage 3

• 3GPP TS 29.280 V10.4.0 (2012-06): 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals 3GPP Evolved Packet System (EPS) 3GPP Sv interface (MME to MSC, and SGSN to MSC) for SRVCC

• 3GPP TS 29.305 V12.4.0: 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals InterWorking Function (IWF) between MAP based and Diameter based interfaces

• 3GPP TS 32.422 V12.4.0: 3rd Generation Partnership Project Technical Specification Group Services and System Aspects Telecommunication management Subscriber and equipment trace Trace control and configuration management

• 3GPP TS 32.423 V12.1.0: 3rd Generation Partnership Project Technical Specification Group Services and System Aspects Telecommunication management Subscriber and equipment trace: Trace data definition and management

• 3GPP TS 36.413 V13.6.0: 3rd Generation Partnership Project Technical Specification Group Radio Access Network Evolved Universal Terrestrial Radio Access Network (E-UTRAN) S1 Application Protocol (S1AP)