Explore Cisco
How to Buy

Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

MME Administration Guide, StarOS Release 21.6

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

MME Administration Guide, StarOS Release 21.6

Chapter Title

IMSI Manager Scaling on the MME

Results

Updated:
January 25, 2018

Chapter: IMSI Manager Scaling on the MME

IMSI Manager Scaling on the MME

Simply put, IMSI Manager Scaling enables multiple IMSI Managers per MME. To facilitate MME operations on Cisco's higher capacity platforms, such as ASR 5500 and Cisco's Virtual Packet Core (VPC)- Distributed Instance (DI) platform, the MME enables scaling up the number of IMSI Managers supported on ASR 5500 and VPC-DI platforms. Scaling the number of IMSI Managers means the MME's IMSI Manager is not a bottleneck on enhanced platforms.

Feature Description

Overview

The IMSI Manager (IMSIMgr) is the de-multiplexing process that selects the Session Manager (SessMgr) instance to host a new session. The IMSIMgr selects the SessMgr instance based on a demux algorithm logic to host a new session by handling new calls requests from the MME Manager (MMEMgr), EGTPC Mgr, and the (e)SGTPCMgr (handles 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 (e.g., IMSI/GUTI) to the SessMgr instance.

With the addition of support for the expanded capacities of the VPC-DI and ASR5500 platforms, the MME's IMSIMgr had become a bottleneck. With Release 18.0, the IMSI Manager Scaling feature increases the number of IMSIMgrs that can be made available on the MME - scaling from 1 to a maximum of 4 in releases prior to 21.0 and a maximum of 8 from release 21.0 onwards. The number is configurable (see Configuration section below).

Important:

IMSIMgr Scaling is only available on the ASR 5500 and the VPC-DI platforms. The maximum number of IMSIMgrs supported on the SSI platform remains at "1".

Customers will notice the following when the configured number of IMSIMgrs setting is changed for 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 visualized 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 IMSI Mgr instance.

Relationships to Other Features

The MME's use of the following features has been changed when multiple IMSIMgrs are configured:

  • Attach Rate Throttling
  • MME per service session limits
  • Monitor Subscriber 'next call'
  • Congestion Control
  • MME traps generated by IMSI Manager

For details about the changes, refer to the How It Works section.

How It Works

Workings of IMSIMgr Scaling

It is the MMEMgr/EGTPC Mgr/SGTPC Mgr that selects an IMSIMgr instance to be contacted for session setup. Each subscriber session in the SessMgr maintains the IMSIMgr instance ID that 'hosts' the mapping for this IMSI. This information is required when communicating during audit and session recovery scenarios.

With a single IMSIMgr instance present, there in only one centralized entry point for new calls into the system. By increasing the number of IMSIMgr instances, the new call handling (primarily for Attach and SGs procedures) capacity 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.

The IMSIMgr and SessMgr interactions are the same as those employed when IMSIMgr scaling is not implemented. Once the IMSI is found, the SessMgr performs hash on the IMSI to acquire the "target" IMSIMgr instance ID. Once the IMSI is known, the NOTIFY-IMSI Request will be sent from the SessMgr to the "target" IMSIMgr instance. The "target" IMSIMgr instance updates the mapping table with this "IMSIMgr ID" mapping. This ensures that any further IMSI-based requests from this subscriber will land on the correct SessMgr.

Attach Rate Throttling

With multiple IMSIMgrs, the configured number of allowed Attaches is divided between the configured number of IMSIMgrs. As throttling is now distributed, 100 accuracy cannot be achieved as with a single IMSIMgr, so a minor impact in accuracy based on the incoming rate in every IMSIMgr will result in a limited number of calls being dropped/rejected.

MME Service Session Limits

As a result of IMSIMgr Scaling, a behavior change has been implemented with regard to MME service session limits. Now all IMSIMgr instances will send the current count of sessions per MME service to the MMEMgr via existing response messaging. The MMEMgr shall send the same data received from multiple IMSIMgr instances back to the IMSIMgr in existing request messaging. As a result, each IMSIMgr shall 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. The per service session limit is configured by the command bind s1-mme max-subscribers number (refer to the Command Line Interface Reference for command details).

Monitor Subscriber 'next-call'Option

The monitor subscriber next-call option is used to trace the next incoming call into the system. With multiple IMSIMgr instances, the session controller now sends the next-call details to IMSIMgr instance 1. So, the next incoming call through IMSIMgr instance 1 is monitored.

Congestion Control

All IMSIMgrs will be involved in congestion control and traps will be generated by all IMSIMgrs. The IMSIMgrs are updated with information on critical parameters that lead to congestion control and each IMSIMgr instance sends traps indicating congestion status.

IMSIMgr ID in Traps

Each IMSIMgr instance independently generates traps for each new allowed or disallowed call. The trap information includes the IMSIMgr instance ID.

SessMgr Instance Mapping

From Release 18 and forward, the Diameter Proxy Server queries the MME's IMSIMgr instances to obtain IMSI information in support of SessMgr instance mapping.

Configuring IMSI Manager Scaling

This section documents configuration of IMSI Manager Scaling and configuration for related functionality.

Configuring Support for Multiple IMSIMgrs

The commands illustrated below configure the IMSI Managers parameters. In support of the IMSI Manager Scaling feature, the max keyword has been added to set the maximum number of IMSIMgrs that can be spawned on the MME.

Important:

The max keyword is only visible when the MME is running on an ASR 5500 or a VPC platform. 

config
   task facility imsimgr { avoid-sessmgr-broadcast | max <number_imsimgrs> | sessmgr-sessions-threshold high-watermark <high_value> low-watermark <low_value> }
   end

Notes:

  • max number_imsimgrs must be an integer from 1 to 4 for release prior to 21.0. From release 21.0 onwards the maximum number of IMSI Managers per chassis is enhanced to “8”. The table below lists the default and maximum values for each platform:

    Platform and card type

    Default number of IMSI managers per chassis

    Maximum number of IMSI managers per chassis

    ASR5500 with DPC

    4

    4

    ASR5500 with DPC2

    8

    Note   

    For releases prior to 21.0, the default number of IMSI managers per chassis was "4"

    8

    Note   

    For releases prior to 21.0, the default number of IMSI managers per chassis was "4"

    VPC-SSI LARGE/MEDIUM

    1

    1

    1

    1

    VPC-SSI SMALL/FORGE

    1

    1

    SCALE LARGE/MEDIUM

    4

    4

    ASR5700

    4

    4

  • For further information on the other command keywords and the use of the command prefixes, refer to the Command Line Interface Reference for release 18.0 or higher.
Important:

max is a boot-time configuration setting. It should be added in the configuration file before any MME related configuration is created or any IMSI Manager is started. Run-time (dynamic) configuration of this parameter is stored but not effective until after the next reboot. Any attempt at dynamic configuration of this parameter results in a display of the following error message:

IMSImgrs already started. So modify the configuration file and reboot the system with updated configuration.

Verifying the IMSI Mgr Scaling Configuration

Either of the following commands can be used to display/verify the number of IMSIMgrs configured per chassis. 
show task resources facility imsimgr all

show configuration

Note:

The task facility imsimgr max field has been added to the output of the show configuration command.

Configuring IMSIMgr Audit

With the ability to configure the MME to support more than one IMSIMgr instance, it becomes important to be able to selectively monitor each IMSIMgr instance. With the following command issued from the Exec mode, the operator can initiate an audit request for just one IMSIMgr instance at a time: 

mme imsimgr instance instance_id audit-with sessmgr { all | instance instance_id }

Notes:

  • imsimgr instance instance_id: Enter an integer from 1 to 4 to identify the specific IMSIMgr instance for which the audit is to be performed.
  • all | instance instance_id: Select all to initiate an audit for all SessMgr instances or select instance and for instance_id enter an integer from 1 to 1152 to identify a specific SessMgr for the audit.

Monitoring and Troubleshooting the IMSIMgr Scaling

Displaying IMSIMgr Instance Information

The following commands generate output that displays information about IMSIMgr Instances:

show subscribers mme-only full all - This command displays IMSIMgr instance information for subscriber session(s).

show mme-service session full all - This command displays IMSIMgr instance information for MME service session(s).

show mme-service db record call-id - This command displays IMSIMgr instance information based on call-id records.

Displaying IMSIMgr Selection Counter Information

The following commands generate output that displays selection counter information for an IMSIMgr instance:

show demux-mgr statistics sgtpcmgr instance instance - This command updates to display IMSI Mgr selection counter information.

show demux-mgr statistics egtpegmgr all - This command updates to display IMSI Mgr selection counter information.

show session subsystem facility mmemgr instance instance - This command updates to display IMSIMgr selection counter information.

Displaying IMSIMgr Instance Information in the SNMP Trap

Use the following command to display IMSIMgr instance specific fields in the SNMP trap:

show snmp trap history - SNMP trap now includes the IMSIMgr instance information
  • Internal trap notification 1249 Imsimgr instance: 1 (MMENewConnectionsDisallowed) - MME new connections disallowed, initial reason test
  • Internal trap notification 1249 Imsimgr instance: 1 (MMENewConnectionsDisallowed) - MME new connections allowed

Bulk Statistics

Currently, there are no bulk statistics used to track IMSIMgr instance-specific information.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco