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.
Feedback