RCEM 2.2 Ag Latest PDF

Roaming Customer Experience
Management
Administration Guide
Version2.2.R190301
Mobileum, Inc.
20813 Stevens Creek Boulevard, Ste. 200
Cupertino, CA 95014 USA
Phone: +1-408-844-6600
Fax: +1-408-252-1566
www.mobileum.com
LEGAL INFORMATION
© 2019 Mobileum, Inc. All rights reserved. This document is subject to change. This document and the information
herein are provided for the sole use of the intended recipient(s) and for information purposes only. This document
contains contents which are the confidential and proprietary information of Mobileum and/or its licensors. Mobileum
may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering the
subject matter hereof. Unless specifically set forth in a separate written agreement signed by Mobileum, the
furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other
intellectual property. Mobileum, the names of its products, services, and their respective logos are registered trade
or service marks of Mobileum, Inc. This document may not be modified, reproduced, or transmitted in any form or by
any means, electronic or mechanical, for any purpose, without Mobileum’s prior written permission. Mobileum, Inc.
makes no warranty, express or implied, with this document or the information contained herein.
Revision hist or y
Date Revision no. Description
Apr-23-2019 01 Initial release.

For more information about the additions, modifications, and
deprecations made to this release, refer to "What's new in this guide" on
page 212.
Contents
Preface ix
Purpose of this guide ix
Intended audience ix
Related documents ix
Document conventions x
How to contact Mobileum xi
Documentation support xi
Customer support xi
Getting started 12
Supported administrative roles 12
Logging in to Mobileum Administrator Studio 13
Security guidelines for using Mobileum Administrator Studio 14
Logging out of Mobileum Administrator Studio 14
Introduction to the RCEM application 15

RCEM Architecture 16
Components used by the RCEM application 16
Modules in the RCEM application 19
Where the RCEM application fits in the network 22
Managing classes of subscribers 24

Mapping CoSes to RCEM users 25
Generating dashboards 27
MAP transaction failure dashboard 28
KPIs in the MAP transaction failure dashboard 29
Filters available in the MAP transaction failure dashboard 29
Widgets in the MAP transaction failure dashboard 31
Supported MAP messages and message groups 34
Supported MAP error messages 35
MAP Performance dashboard 37
What details does the MAP Performance dashboard provide? 38
Which KPIs does the MAP Performance dashboard use? 38
Which filters does the RCEM application use to generate the MAP Performance dashboard? 38
Which widgets does the RCEM application display in the MAP Performance dashboard? 39
Diameter failure dashboard 41
KPIs in the Diameter failure dashboard 42
Filters available in the Diameter failure dashboard 42
Widgets in the Diameter failure dashboard 43
Supported Diameter messages and message groups 46
Supported Diameter error messages 46
DIAMETER Performance dashboard 51
What details does the DIAMETER Performance dashboard provide? 51
How does the RCEM application determine successful DIAMETER transactions for a network? 52
RCEM 2.2 Administration Guide
Contents
Which KPIs does each widget display in the DIAMETER Performance dashboard? 53
Which filters does the RCEM application use to generate the DIAMETER Performance dashboard? 53
Which widgets does the RCEM application display in the DIAMETER Performance dashboard? 54
Voice service accessibility dashboard 56
KPIs in the Voice service accessibility dashboard 57
Filters available in the Voice service accessibility dashboard 57
Widgets in the Voice service accessibility dashboard 58
Supported voice service messages 60
Supported voice service error codes 60
Voice connection establishment dashboard 62
KPIs in the Voice connection establishment dashboard 63
Filters available in the Voice connection establishment dashboard 63
Widgets in the Voice connection establishment dashboard 64
Voice connection retainability dashboard 66
KPIs in the Voice connection retainability dashboard 67
Filters available in the Voice connection retainability dashboard 67
Widgets in the Voice connection retainability dashboard 67
Data session establishment dashboard 69
KPIs in the Data session establishment dashboard 70
Filters available in the Data session establishment dashboard 70
Widgets in the Data session establishment dashboard 71
Supported packet data messages 73
Supported packet data error messages 73
Data session retention dashboard 77
KPIs in the Data session retention dashboard 77
Filters available in the Data session retention dashboard 77
Widgets in the Data session retention dashboard 78
Registration dashboards 79
Registration latency dashboard 81
Registration performance dashboard 87
GRQ dashboard 91
KPIs in the GRQ dashboard 91
Filters for generating the GRQ dashboard 93
Widgets in the GRQ dashboard 94
VIP performance dashboard 96
Prerequisites for generating the VIP performance dashboard 96
KPIs in the VIP performance dashboard 97
Filters for generating the VIP performance dashboard 97
Widgets in the VIP performance dashboard 97
Voice usage dashboard 100
KPIs in the Voice usage dashboard 100
Filters for generating the Voice usage dashboard 100
Widgets in the Voice usage dashboard 101
Data usage dashboard 102
KPIs in the Data usage dashboard 102
Filters for generating the Data usage dashboard 102
Widgets in the Data usage dashboard 103
SMS usage dashboard 104
KPIs in the SMS usage dashboard 104
Filters for generating the SMS usage dashboard 104
Widgets in the SMS usage dashboard 105
Unique roamers dashboard 106
KPIs in the Unique roamers dashboard 107
Filters for generating the Unique roamers dashboard 107
Widgets in the Unique roamers dashboard 107
Roamer trip dashboard 109
Confidential and proprietary information of Mobileum, Inc. v

Contents
KPIs in the Roamer trip dashboard 109

Filters for generating the Roamer trip dashboard 110
Widgets in the Roamer trip dashboard 110
Interconnect SMS dashboard 112
KPIs in the Interconnect SMS dashboard 112
Filters for generating the Interconnect SMS dashboard 112
Widgets in the Interconnect SMS dashboard 113
Advanced packet data dashboard 115
KPIs in the Advanced packet data dashboard 115
Filters for generating the Advanced packet data dashboard 115
Widgets in the Advanced packet data dashboard 116
DPI dashboard 118
KPIs in the DPI dashboard 118
Filters for generating the DPI dashboard 119
Widgets in the DPI dashboard 119
DPI by technology dashboard 120
KPIs in the DPI by technology dashboard 121
Filters for generating the DPI by technology dashboard 121
Widgets in the DPI by technology dashboard 121
SCCP carrier dashboard 122
KPIs in the SCCP carrier dashboard 123
Filters for generating the SCCP carrier dashboard 123
Widgets in the SCCP carrier dashboard 124
Session handover analysis dashboard 126
KPIs in the Session handover analysis dashboard 126
Filters for generating the Session handover analysis dashboard 126
Widgets in the Session handover analysis dashboard 126
First time registration dashboard 127
KPIs in the First time registration dashboard 128
Filters for generating the First time registration dashboard 128
Widgets in the First time registration dashboard 128
NQS dashboard 129
Computing network quality score 129
KPIs used in the NQS dashboard 130
Network quality score 132
Weighted network quality score 133
Filters for generating the NQS dashboard 137
Widgets in the NQS dashboard 138
Network R-CX dashboard for the Steer to Quality feature 140
Steer to Quality feature 140
Network R-CX dashboard 145
What information does the Network R-CX dashboard display? 145
How is the information populated and displayed in each widget? 146
How does the RCEM application compute quality score for each event? 147
How does the RCEM application compute aggregated quality score that is displayed in each widget? 147
Which widgets does the RCEM application display in the Network R-CX dashboard 148
Which filters are available in the Network R-CX dashboard? 151
Interconnect Voice dashboard 152
What details does the Interconnect Voice dashboard provide? 152
Which KPIs does the Interconnect Voice dashboard use? 152
Which filters does the RCEM application use to generate the Interconnect Voice dashboard? 153
Which widgets does the RCEM application display in the Interconnect Voice dashboard? 154
Configuring GRQ SLAs 157

Dynamic threshold learning 158
What is the dynamic threshold learning feature? 158
Confidential and proprietary information of Mobileum, Inc. vi

Contents
How does the dynamic threshold learning feature work? 159

How do you configure the dynamic threshold feature in the RCEM application GUI? 160
Which method does the RCEM application use to learn and forecast the optimal value for threshold
settings? 160
Modifying a GRQ SLA configuration 161
Searching for a GRQ SLA configuration 164
Deleting a GRQ SLA configuration 165
Configuring CoS thresholds 166

Modifying a CoS threshold configuration 166
Searching for a CoS threshold configuration 168
Deleting a CoS threshold configuration 168
Configuring thresholds and alerts 170

Adding alert configuration 170
Searching for, modifying, and deleting alert configuration 176
Generating trace reports 179

Trace 179
Assess 187
CRM 192
Roaming Status 195
Roaming Activity 196
Learn 200
Pattern matching support in a standalone trace/CRM 202
Correlating alarms in the alarm history table 203
Upgrading the Trace application 205

Upgrading the Trace application 205
Enabling CRM application for a user under a user group other than 'RIS' 208
Configuring settings to view DIAMETER pcap in Wireshark 211
What's new in this guide 212

R190301 - Initial release 212
Additions 213
Modifications 213
Deprecations 213
Documentation enhancements 213
R181218 - Revised release 213
Additions 214
Modifications 214
Deprecations 214
Additions 214
Modifications 215
Deprecations 215
Confidential and proprietary information of Mobileum, Inc. vii

Contents

Additions 215
Modifications 215
Deprecations 215
Additions 216
Modifications 216
Deprecations 216
Additions 217
Modifications 217
Deprecations 217
Additions 217
Modifications 217
Deprecations 217
Additions 218
Modifications 218
Deprecations 218
Additions 219
Modifications 219
Deprecations 219
Additions 219
Modifications 219
Deprecations 220
Additions 220
Modifications 220
Deprecations 220
Additions 221
Modifications 221
Deprecations 221
Additions 221
Modifications 221
Deprecations 222
Confidential and proprietary information of Mobileum, Inc. viii

Preface

Important
Effective February 24, 2014, Roamware, Inc. has been renamed Mobileum, Inc. However, this
document may contain references to Roamware, particularly in program artifacts, product and
platform component names, and so on.
This preface describes the purpose of and intended audience for the Roaming Customer Experience
Management 2.2 Administration Guide.It also describes how this guide is organized, publications related to this
guide, conventions used across this guide, and how to contact Mobileum, if required.
Purpose of this guide

This guide provides information for setting up and managing the RCEM application by using Mobileum
Administrator Studio.
Intended audience
This guide is intended for administrators and network planners. Administrators are typically involved in the
operations and maintenance of the RCEMapplication on a daily basis. They also troubleshoot Level 1 (L1)
product issues.
Network planners prepare technical reports about the performance of the RCEMapplication, analyze network
traffic, and so on.
Both administrators and network planners must have advanced experience with the hardware, software, and
network prerequisites described in the “Installation prerequisites” topic of the RCEM2.2 Installation Guide.
Related documents
Table 1 on page x lists and describes the other documents related to this guide.
Preface
T A B L E 1 : R EL A T ED D OC U M EN T S
Document Description
RCEM 2.2 Installation Describes how to install and configure the RCEM application for Oracle Solaris 9
Guide and 10, and RHEL operating systems.
RCEM 2.2 SNMP Describes the SNMP objects and traps used by the RCEM application.
Reference Guide

Document conventions
Table 2 on page x describes the conventions used in all Mobileum product documentation.
T A B L E 2 : D OC U M EN T C ON VEN T I ON S
Convention Description
Italic nEmphasis
nReferences to other guides and documents
“Quotation Messages displayed on the screen
marks”
Bold n GUI text
n User input
{Fixed A placeholder for something that you must customize. For example, in your environment, replace
Width} {Roamware_Home} with the directory where all Mobileum SDS files are installed.
Fixed Width n Code snippets
n File and directory names
n File extensions
n Function names
n CLI text
n Output samples
Fixed Width Target file or directory name in a network path
Bold
Link n Links within a guide
n URL links
n Email addresses
Note The Note admonition describes additional information about a particular topic. Ignoring a note
does not have any negative consequences.
Warning The Warning admonition should not be ignored. Ignoring warnings will most likely cause data
loss.
Tip The Tip admonition describes shortcuts and alternative approaches to a task. Ignoring a tip does
not have any negative consequences.
Important The Important admonition highlights information that might be easily missed, for example,
configuration changes that apply only to the current session, or services that might need restarting
before an update is applied. Ignoring this admonition will not cause data loss but might cause
task rework.
Confidential and proprietary information of Mobileum, Inc. x

Preface
How to contact Mobileum

The following topics provide information on how to provide feedback on Mobileum product documentation and
obtain support for Mobileum products.
Documentation support
To provide feedback on documentation, send email to docsupport@mobileum.com
Customer support
If you have any problems with, questions on, or feedback about Mobileum products, send email to
customer.support@mobileum.com
Confidential and proprietary information of Mobileum, Inc. xi

1
Getting started

This topic describes the various administrative roles that the RCEM 2.2 application supports out-of-the-box. It
also lists the steps for logging in to Mobileum Administrator Studio, provides security recommendations for
using Mobileum Administrator Studio, and lists the steps for logging out of Mobileum Administrator Studio.
This guide assumes that you have successfully installed and started the RCEM application. For information
about installing and configuring the RCEM application, refer to the RCEM 2.2 Installation Guide.
This topic contains the following subtopics:
n "Supported administrative roles" on page 12

n "Logging in to Mobileum Administrator Studio" on page 13
n "Security guidelines for using Mobileum Administrator Studio" on page 14
n "Logging out of Mobileum Administrator Studio" on page 14
Supported administrative roles

Table 3 on page 12 lists the administrative roles that the RCEM application supports out-of-the-box.
T A B L E 3 : D ET A I L S OF SU PPOR T ED A D M I N I ST R A T I VE R OL ES
Default
Default
Group name user Details
password
name
Administrator admin admin@123 Root administrative user for Mobileum Administrator Studio. When you
log in with this administrative role, you can perform the following
actions:
n Create, modify, and delete the following entities:
n Users
n Roles
n Groups
Chapter 1 - Getting started
Default
Default
Group name user Details
password
name
n Assign users and roles to groups.
n Create, modify, and delete menu structures.
n View audit trails.
For more information about this administrative role, refer to the

Mobileum SDS 6.0 User Guide.
RIS risuser risuser@1234 Root administrative user for the RCEM application. When you log in
with this administrative role, you can perform the following actions:
n Configure CoSes, thresholds, and GRQ SLAs.
n Generate and view the RCEM application reports.
n View summary and detail level traces for all the messages.
Note
n You cannot modify the out-of-the-box administrative roles and default user names. However,
you can create custom roles, which may have either the same access rights as the out-of-the-
box roles or custom access rights.
n The default passwords mentioned in Table 3 on page 12 are used only for first-time logins.
Mobileum Administrator Studio prompts you to change these passwords at the time of your first
login.
1. Logging in to Mobileum Administrator

Studio

Important
Mobileum Administrator Studio supports the following browsers:
n Internet Explorer 10
n Mozilla Firefox 32.0
n Google Chrome 44.0

Mobileum Administrator Studio allows you to configure and manage the RCEM application. You must use the
risuser account to Log in to Mobileum Administrator Studio for the first time.
To log in to Mobileum Administrator Studio, perform the following steps:
1. Open a web browser window.

2. Type the following default URL in the address field:
http://<hostname>:<port>/imas
Confidential and proprietary information of Mobileum, Inc. 13

Chapter 1 - Getting started
In the preceding URL, replace the following:

n <hostname> with the host name or the IP address of the system where Mobileum Administrator Studio
is deployed.
n <port> with the port number on which Mobileum Administrator Studio is listening. This is usually 8080
for Apache Tomcat.
The login page appears.
3. Type the following values and click Login.
n User name: risuser
n Password: risuser@1234
4. If this is a first-time login, you will be prompted to change the password. After you change the password,
the login page appears again.
5. Log in now with the risuser user name and the new password you set in step 4.
The landing page of Mobileum Administrator Studio appears.

Note
For more information about using Mobileum Administrator Studio, refer to the Mobileum SDS 6.0
User Guide.
Security guidelines for using Mobileum

Administrator Studio
To protect the RCEM application from malicious attacks through the browser session, adhere to the following
guidelines when using Mobileum Administrator Studio:
n Do not share the browser session with other applications.

n Do not access any other site when working with Mobileum Administrator Studio.
n Enforce strict password restrictions for Mobileum Administrator Studio.
n Always log out after using Mobileum Administrator Studio.
n Close the browser window after your session is over.
n Assign appropriate roles to administrators according to the tasks they need to perform.
Logging out of Mobileum Administrator

Studio
To log out of Mobileum Administrator Studio, click Logout from the RoamInSight drop-down list at the top right
corner.

2
Introduction to the RCEM application

Roaming Customer Experience Management (RCEM) is an integrated and real-time monitoring application
that allows a 360-degree view of network, service and customer performance. The application provides near
real-time reports across many Key Performance Indicators (KPIs) covering various aspects of business and
network issues, pertaining to roaming.
RCEM monitors the operation and performance of roaming services as experienced by individual subscribers
in a roaming environment.
Chapter 2 - Introduction to the RCEM application
RCEM Architecture
F I GU R E 1 : R C E M A R C H I T EC T U R E
Components used by the RCEM application

The RCEM application uses the following components:
n Probe component
n TxnWriter
n SS7TxnWriter
n SIPTxnWriter
n DIATxnWriter
n GTPTxnWriter
n CoSEngine
The following sections describe the components used by the RCEM application:
Probe component
RCEM obtains network traffic feed from the following data sources:

n GTP probe
n Diameter probe
n SIP probe
n DK (SS7) probe
Each of these probes captures the raw network traffic as seen on the roaming links. A state machine layer is
built on top of the probes to combine multiple events of an underlying roaming transaction to generate a
Transaction Data Record (TDR). In case of SS7, it is the TCAP transaction. This state machine layer is either a
plug-in library running on top of the probe binaries (in case of GTP, Diameter, and SIP) or a separate
component (Transaction Writer) that takes feed from the probe over an IP connection. For more information
about probes, refer to the IPProbe 6.0 Installation Guide.
TxnWr it er
The TxnWriter component generates the following types of files:
n Summary file (TDR)

This file captures an entire underlying transaction with some key fields. For example, a complete UL
transaction. It also contains a link to the individual events of the transaction the TxnWriter component
captures separately in another file (detail file).
Each of the txnwriters provide basic enrichment for a raw transaction. For example, deriving MCC, MNC,
and network IDs from the IMSI, VLR, and SGSN. Deriving the type of roamer (inbound or outbound), type
of call (roaming or interconnect).
n Detail file
This file captures the raw hex dump of an event, as it is, and provides links between multiple events of
an underlying transaction. On every MSU or raw event obtained from the probe, the TxnWriter
component writes a record in this file with a link to the past record of that transaction. When the
transaction itself completes, aborts, or times out, the TxnWriter writes a record for the transaction in the
summary file with a link to the last record in the detail file.
Following diagram displays an example for a successful UL transaction. The detail events for one
completed transaction could be spread across multiple files.
F I GU R E 2 : E XA M PL E D I SPL A YI N G A SU C C ESSF U L UL T R A N SA C T I ON
n Event file
This file is similar to the detail file but contains the event details for an individual event in a human
readable ASCII format.
Note
You can configure the Anritsu probe for RCEM if it is applicable to your deployment.

Do not configure Mobileum Probes and TxnWriter if you have configured the Anritsu probe on the
specific deployment.
For information about configuring the Anritsu probe, refer to the "Configuring Anritsu Probe" section
in the RCEM 2.2 Installation Guide.
CoSEngine
Note
This configuration is not mandatory and is applicable only if you have installed CoSEngine at a site
where the RCEM application is deployed.
CoSEngine is a module in the Mobileum SDS 7.0 platform. The RCEM application uses CoSEngine for the
following requirements:
n To query about a CoS of a specific subscriber or various features, when required

n To fetch the CoS details along with a subscriber profile or a calculated CoS for a feature
When you deploy and configure CoSEngine for the RCEM application, CoSEngine performs the following
actions:
n Interacts with the RCEM application by using RPC servers over the TCP/IP interface.
n Responds to the CoS queries that are received from the RCEM application.
n Stores the received subscriber profile and CoS attributes.
n Processes and maps the subscriber profile to a CoS when the RCEM application sends CoS queries for
a subscriber.
n Sends the subscriber profile with the corresponding CoS attributes to the RCEM application.
CoSEngine interacts with the following modules of the RCEM application:
n TxnProcessor interacts with CoSEngine for populating extended information in each master log while
processing for any protocol. For example, to fetch a subscriber's CoS.
n The Trace application supports both internal CoS and the CosEngine component as the sources for CoS
provisioning. The following scenarios are possible:
n If you configure the value of the cos.source.name parameter as sds, the Trace application displays
the internal CoS in the class of subscriber drop-down list. The CoS is determined by the SDS_
SUBSCRIBER_COS_MASTER database table.
n If you configure the value of the cos.source.name parameter as cosengine, the Trace application
displays only those CoSes, in the class of subscriber drop-down list that are determined by the
CoSEngine platform component.
For more information about configuring CoS source for the Trace application, refer to the "Configuring
CoS source for Trace application" section in the RCEM 2.2 Installation Guide.
Note
In both the aforementioned scenarios, the list of CoS excludes those CoS which are configured in
the RI_COS_MASTER table for the currently logged in user.

For information about the RI_COS_MASTER table, refer to "Managing classes of subscribers" on page
24.
n RCEM Dashboards consider CoSEngine platform component as a source for CoS. For more information
about mapping CoSes to RCEM users, refer to "Managing classes of subscribers" on page 24.
n RIS Management considers CoSEngine when CoS information is fetched from CoS source, for
configuring CoS specific thresholds.
For more information about configuring CoSEngine, refer to the "Configuring CoSEngine" section of the
Mobileum SDS 7.0 Installation Guide.
Modules in the RCEM application

The RCEM application consists of the following modules:
n TxnProcessor
n WISDOM platform:
n HDFS
n Data ingestion job
n Data model job
n Feature factory
n Dynamic dataset manager
n Hive
n Presto
n RCEM dashboards
n Indexer
n Alerter
n Trace
The following sections describe the modules in the RCEM application:
TxnProcessor
The TxnProcessor component processes the log files that the Transaction Writer platform component generates.
The TxnWriter generates the following logs:
n SS7 (generated by SS7TxnWriter)

n SIP (generated by SIPTxnWriter)
n DIA (generated by DIATxnWriter)
n GTP (generated by GTPTxnWriter)
The TxnProcessor component generates the registration, trip, trip metrics, GRQ, and VIP tracker trace files.
These log files are sent to HDFS for further processing for KPIs related to reports and dashboards.
WI SDO M plat f or m
The new enriched files are copied to the Hadoop Distributed File System (HDFS) component available in the
WISDOM platform. The RCEM application uses Apache Spark framework to process data real-time.
Subsequently, Spark jobs available in the WISDOM platform, process the files to generate KPIs and the desired
output.

The Apache Spark framework processes the data by using the following jobs and modules:
n HDFS: The Hadoop Distributed File System (HDFS) is data storage used by Hadoop ecosystem. It
employs a NameNode and DataNode architecture to implement a distributed file system.
n Data ingestion job: Data ingestion job fetches the desired data sources from local files system of node
on which the Transaction processor runs and feeds them to HDFS at a predefined location.
n Data model job: Data model job processes the following set of input data sources:
n MAP
n CAP
n ISUP
n Diameter
n SIP
n GTP-C/GTP-MMS
n GTP-U/GTP-DPI
The data model job normalizes, partitions, and stores data sources in a file format called ORC.
n Feature factory: Feature factory job defines and creates the aggregate of data and dumps the aggregate
in Hive tables based on the protocol and granularity (such as, every 15 minutes, hour, day, and month).
n Dynamic dataset manager: The dynamic dataset manager module distinguishes the processed and
unprocessed set of files. The module ensures that each file is processed by jobs such as data model or
feature factory job, only once. Additionally, the dynamic dataset manager module is integrated with the
data model and feature factory jobs.
n Apache Hive: Hive is a data warehousing system to store structured data on HDFS. Hive helps to
process large-scale data and supports SQL-based queries. Hive can run programs both in memory and
on disk.
In RCEM, Hive is used to store metadata of the aggregated tables. When a query is sent to Presto from
the RCEM GUI, Presto fetches the information of metadata from hive meta store and subsequently
processes the query.
The output data generated by the Spark jobs are populated in the Hive tables with the help of SparkSQL.
The aggregated data is stored in Hive tables based on the protocol and granularity (such as, every 15
minutes, hour, day, and month). Hive uses Online Analytical Processing (OLAP) Cubes to store, view,
and analyze data in a multidimensional format.
n Presto: Presto is a distributed SQL engine that is used to query the data sources.
Unlike Hive, Presto runs in the memory only. This functionality allows Presto to run simple queries on
Hadoop in a few hundred milliseconds with more complex queries taking only a few minutes.
In contrast, scanning over an entire dataset using Hive, which relies on Spark jobs, can take anywhere
from several minutes to several hours. Presto has also been proven to be up to seven times more
efficient on the CPU than Hive. In addition, Presto can combine data from multiple sources into a single
query, allowing data analysis across an entire organization.
In RCEM, instead of Hive, Presto is used for analyzing data required by the RCEM dashboards.
RCEM dashboar ds
You can access all RCEM dashboards from the RCEM GUI. You can extract data in each of the dashboards
based on various global filters. The moment a query is submitted in the dashboards, RCEM sends a relevant
query to Presto. Presto then responds with the query result and the same data is displayed in the dashboard in
a graphical or tabular view.

The RCEM dashboards perform the following functions:
n Segregates quality-related KPIs from business-oriented KPIs (for example, failure rates from usage)
n Provides a multi-dimensional view of the KPIs
n Provides higher level aggregate KPIs based on underlying GRQ KPIs (for example, network quality
score, voice quality score, data quality score, and so on)
Indexer
The RCEM provides the summary files as input to the Indexer component. The Indexer component indexes
these summary files on specified index fields. This helps search these files based on the indexed fields and
return results quickly. The Indexer component uses an in-memory database (Gigabase) that stores the data and
indexes in a proprietary format (DBS files).
RCEM purges the summary files after a couple of days, whereas the DBS files can be stored for a longer
duration based on the operator’s requirements for trace retention. The Indexer also implements a day-wise
partitioning mechanism so that it can restrict searches to specific days as given in the search criteria.
Aler t er
The RCEM application uses Alerter to send alerts to the deploying operators through SMS, SNMP alarms, and
e-mails. The feature factory job provides input to the Alerter. Subsequently, Alerter:
n Computes the KPIs based on the threshold that you configure

n Monitors the KPIs
n Sends alerts based on the configured values
Trace
The Trace application displays the transaction details that are fetched from Indexer. The Trace application
queries the Indexer data source and fetches transaction details for various application activities.
The Trace application performs the following functions:
n Fetches and displays on the RCEM GUI, the transaction details that are derived from the extended
summary traces. The extended summary traces that are generated by TxnProcessor, are stored in
Indexer.
n Generates the event and PCAP traces by using the event and detail files, respectively. The event and
detail files are generated by TxnWriter.
The Trace application presents an intuitive search facility to allow searches based on individual IMSIs or GTs.
You can access the Trace application from the RCEM GUI. Using the Trace application, an operator can find
historical data of any transaction. To find the transaction details of the subscriber, operator may use any of the
following filters:
n Start Date (DD/MM/YYYY) & End Date (DD/MM/YYYY)

n Start Time (HH:MI) & End Time (HH:MI)
n IMSI
n Host GT, Partner GT
n Host Node IP, Partner Node IP
n Host Node Address (URL), Partner Node address (URL)
n My PC, Carrier PC
n APN

n IMEI
n Subscriber IP Address
n Camel Phase
n Message Type
n Error code
n Protocol
Note
When using the Trace application, some fields are mandatory, such as the following:
n Start Date (DD/MM/YYYY) & End Date (DD/MM/YYYY)

n Start Time (HH:MI) & End Time (HH:MI)
n Protocol
When you submit a search query by using the Trace application, the Trace application triggers the Indexer over
an RPC connection. The first level of search is in the DBS files (created by the Indexer) from where the
summarized search results are displayed.
Then the user can fetch event traces or PCAP traces using the event files or PCAP files respectively, for a
transaction. All the events for a transaction are combined to form an event trace and sequence diagrams.
The detail file is used to generate the PCAP traces. You can download the PCAP traces for a transaction. The
PCAP trace represents the information (in a PCAP format file) captured about the raw network traffic.
Where the RCEM application fits in the

network
The RCEM application is deployed in the passive mode in the deploying operator’s network and, hence, does
not reside in any of the active paths connecting the deploying operator’s network elements. The Transaction
Writer platform component receives copies of all messages related to international roamers through the
Mobileum Probe module, which taps the international roaming links between the deploying operator and the
roamers’ home networks.
The RCEM application also communicates with the following components:
n SNMP Manager
For example, the RCEM application sends performance notifications to and receives changed threshold
values from the SNMP manager.
n Database
The RCEM application processes database rules and looks up database tables to provide valuable
insights, for the deploying operator, into roamers’ activities and the performance of partner networks.
n Mobileum Administrator Studio
Administrators can use this component to configure thresholds required to send alerts, view the reports
and dashboards provided by the RCEM application, and view the details of a particular transaction in
pcap trace files.

n Probe module
An application that receives MAP messages that are tapped or duplicated from international roaming
links between HPMNs and the deploying VPMN. The RCEM application receives copies of all MAP,
GTP, SIP, and Diameter messages related to international roamers from the Mobileum Probe module.
All these interactions are shown in Figure 3 on page 23.
F I GU R E 3 : W H ER E THE RCEM A PPL I C A T I ON F I T S I N T H E N ET W OR K

3
Managing classes of subscribers

A class of subscribers (CoS) is a group of subscribers characterized by a common set of services and network
attributes. These services and network attributes determine the type and quality of service available to the
individual members of the CoS.
Mobileum applications such as RCEM use CoS for providing services to the deploying operator’s subscribers.
Managing Class of Subscribers (CoS) refers to identifying and creating CoS for specific policies. You can also
search for, modify, and delete existing CoS configurations specific to the RCEM application in the CoS
Management page in the RCEM application's GUI.
Managing a class of subscribers also refers to creating a CoS and associating it with an individual or a range of
IMSI or MSISDN (belonging to a set of VIP subscribers as defined by the deploying operators).
This configuration helps the RCEM application to identify issues in the services offered to these VIP
subscribers and report them to the deploying operators in a timely manner, thereby helping the deploying
operators to analyze the issues and resolve them on priority.
You can add a CoS in the CoS Management section of Mobileum Administrator Studio. You can also search
for, view, and delete CoS configurations.
Note
For more information about creating and managing a CoS, refer to the Mobileum SDS 7.0 User
Guide.
In addition to adding CoSes, the deploying operators can configure thresholds for KPIs associated with specific
CoSes. When a threshold is breached, the RCEM application raises an alarm to the configured user to alert the
operators. Configure the thresholds in the CoS Threshold Configuration section of Mobileum Administrator
Studio.
For more information about configuring CoS thresholds, refer to "Configuring CoS thresholds" on page 166.
Based on the CoS and CoS thresholds configurations, the RCEM application generates the GRQ dashboard to
provide an analysis of the issues observed by the VIP subscribers.
For information about the GRQ dashboard, refer to "GRQ dashboard" on page 91.
Chapter 3 - Managing classes of subscribers
Mapping CoSes to RCEM users

Note
The functionality of the RI_COS_MASTER database table is modified.
If you associate the CoSes to the corresponding RCEM user, that RCEM user cannot view the
CoSes that are mapped to the RI_COS_MASTER database table. The CoSes that are mapped to the RI_
COS_MASTER database table will not be displayed in the CoS filters in the RCEM dashboards and
Class of Subscriber filter in the Trace application.
However, you can view the CoSes that are not mapped to the RI_COS_MASTER database table.
This functionality of the RI_COS_MASTER database table is applicable to the following screens of the
RCEM GUI:
n GRQ threshold
n CoS Management
n CoS Threshold Configuration
n Threshold Configuration
n Dashboards
n Trace
The CoSes that you create in the CoS Management section of Mobileum Administrator Studio are stored in the
SDS_SUBSCRIBER_COS_MASTER database table. However, if you want a CoS that must not appear in the CoS filters
in the RCEM dashboards, you must associate the CoSes to the corresponding users, for example, risuser, in
the RI_COS_MASTER database table.
Note
You must read this note when you want to know about the user-specific CoS association for
Trace application.
The RCEM application supports multiple CoS sources specifically for the Trace application.
Therefore, you can configure the CoS source as one of the following options:
n CoS you create in the CoS Management section of Mobileum Administrator Studio.
n CoS that the CoSEngine platform component computes.
CoS that are computed by the CoSEngine platform component are stored in the SDS_COS_
DEFINITION table.
In the Trace application, you can associate the CoS to the corresponding users, for example,
risuser, in the RI_COS_MASTER database table.

Chapter 3 - Managing classes of subscribers
For information about how you can configure CoS sources for Trace application, refer to the
"Configuring CoS source for Trace application" section in the RCEM 2.2 Installation Guide.
To map CoSes to RCEM users

1. Create the CoS in the CoS Management section of Mobileum Administrator Studio.
2. Log into the Oracle database.
3. To associate a CoS with a user, for example, risuser user, execute the following command in the RI_
COS_MASTER database table:
Insert into RI_COS_MASTER (USERID,COS_ID) values ('risuser',<COSID>);
Where, <COSID> is the ID of the CoS that you want to associate with the user. The <COSID> is obtained
from the SDS_COS_MASTER database table.
Repeat this step for other CoSes that you want to associate with users in the RI_COS_MASTER database
table.
Note
You must read this note when you want to know about the user-specific CoS association for
Trace application.
CoS that are computed by the CoSEngine platform component are stored in the SDS_COS_DEFINITION
table. You must map CoSes to RCEM users if you want to associate a CoS with a user. You can
associate these CoS or CoS created in step 1 with the user to hide the user-specific CoS information
in the Trace application.

4
Generating dashboards

The RCEM application provides, to operators, statistics, reports, and dashboards that summarize the
performance of a network, based on the quality of roaming services provided to the subscribers by the partner
networks.
Dashboards are generated with the help of the reporting application that is integrated and accessed through
Mobileum Administrator Studio. You can control the details in a dashboard based on values that you specify in
the report’s search criteria and duration. The dashboards contain widgets that display statistics across various
dimensions.
Multi-dimensional analysis and drill-down in widgets
The widgets provide a unidimensional view of the information. However, if you click any criterion in one widget,
the same criterion is applied in the other widgets to provide a multi-dimensional analysis of the information.
For example, in the MAP transaction failure dashboard, if you click UL in the MAP Txn Failure Rate by
Message Type widget, the dashboard applies the UL filter in the other widgets and refreshes the other widgets
with information corresponding to the UL filter.
The dashboard also allows operators to drill down through the dimensions to display dimension-specific
information in the widgets. The dashboard supports the following drill-down options:
n Region-based: Country à Network à Node

n Time-based: Monthly à Daily à Hourly à15 Minutes
n Message group-based: Message Group à Individual Message
When you click a country in the region widget, the widget drills down to display the network-wise breakup of
information and also automatically applies the selected country filter in the other widgets.
The RCEM application provides the following dashboards:
n "MAP transaction failure dashboard" on page 28

n "MAP Performance dashboard" on page 37
n "Diameter failure dashboard" on page 41
n "DIAMETER Performance dashboard" on page 51
n "Voice service accessibility dashboard" on page 56
Chapter 4 - Generating dashboards
n "Voice connection establishment dashboard" on page 62

n "Voice connection retainability dashboard" on page 66
n "Data session establishment dashboard" on page 69
n "Data session retention dashboard" on page 77
n "Registration latency dashboard" on page 81
n "Registration performance dashboard" on page 87
n "GRQ dashboard" on page 91
n "VIP performance dashboard" on page 96
n "Voice usage dashboard" on page 100
n "Data usage dashboard" on page 102
n "SMS usage dashboard" on page 104
n "Unique roamers dashboard" on page 106
n "Roamer trip dashboard" on page 109
n "Interconnect SMS dashboard" on page 112
n "Advanced packet data dashboard" on page 115
n "DPI dashboard" on page 118
n "SCCP carrier dashboard" on page 122
n "Session handover analysis dashboard" on page 126
n "First time registration dashboard" on page 127
n "NQS dashboard" on page 129
n "Network R-CX dashboard for the Steer to Quality feature" on page 140
n "Interconnect Voice dashboard" on page 152

Important
Not all the dashboards in the preceding list are applicable to all the sites. For a list of reports that are
applicable to your deployment, check with your Mobileum PSO representative.
MAP transaction failure dashboard

The MAP transaction failure dashboard provides an analysis of the MAP transaction failures observed on the
roaming links. Transactions can fail because of any of the participating nodes and will impact the end service
provided to the subscribers. Analyzing the failures from multiple dimensions is important to fix the failures. The
MAP transaction failure helps operators to analyze transaction failures across the following dimensions:
n Region
n Message type
n Error code
n Error causing network
n Time

n Message group
The dashboard helps operators to obtain the cause for the failures and help fix these errors.
KPIs in the MAP transaction failure dashboard

Following are the KPIs that are computed and displayed in the widgets:
n Total transaction count: The total MAP transactions that occurred between the HPMN and VPMN.
n Transaction failure rate: Number of MAP transactions that have failed for a particular dimension.
The transaction failure rate for a particular dimension is computed as follows:
Transactions failed (grouped for a dimension) / Total transactions
Filters available in the MAP transaction failure dashboard

Table 4 on page 29 lists and describes the filters available for generating the MAP transaction failure
dashboard.
T A B L E 4 : F I L T ER S F OR GEN ER A T I N G T H E MAP T R A N SA C T I ON F A I L U R E D A SH B OA R D
Filter Required? Description
Host Name No The name of the host networks for which you want to generate the dashboard.
From the drop-down list, select the required host networks.
Partner Yes Type of roaming partner for which you want to generate the dashboard. Based on the
Type option you select, the dashboard displays aggregated data for that partner type.
The following options are available:
n Countrywise: “Dashboard displays aggregated data based on the partner
countries you specify in the Partner Country field.”
n Networkwise: “Dashboard displays aggregated data based on the partner
networks you specify in the Partner Network field.”
n Nodewise: “Dashboard displays aggregated data based on the partner nodes
you specify in the Partner GT field.”
n Alliancewise: "Dashboard displays aggregated data based on the alliances
that you specify in the Alliance drop-down list.
From the drop-down list, select the required partner type.
Partner No ---
Country Note: This field is applicable only if you select the Countrywise option in the Partner
Type filter.
---
Countries to which the roaming partner networks belong, for which you want to
generate the dashboard.
From the drop-down list, select the required partner countries.
Partner No ---
Network Note: This field is applicable only if you select the Networkwise option in the Partner
Type filter.
---
Names of the partner networks for which you want to generate the dashboard.
From the drop-down list, select the required partner networks.
Partner GT No ---
Note: This field is applicable only if you select the Nodewise option in the Partner
Type filter.

---
GT of a partner network’s node for which you want to generate the dashboard.
Specify the GT (in integer format) in the text box.
Alliance No Note:
n This field is applicable only if you select the Alliancewise option from the
Partner Type filter.
n An alliance is a collection of networks that you create in the Alliance
Management module of the IRDB platform component GUI. You create a
collection based on several properties that a group of networks share. For
example, you create an alliance of networks that support only LTE technology.
Therefore, you create an alliance named LTEalliance. For information about
how to create an alliance, add networks to an alliance, modify an alliance, refer
to the "Alliance Management" chapter of theIRDB 6.0 Administration Guide
n This drop-down list displays only those alliances that you created by using the
Alliance Management module of the IRDB platform component GUI. You
cannot create or modify an alliance in the RCEM application GUI.
---
Alliance to which the roaming partner network belong, for which you want to generate
the dashboard.
From the drop-down list, select the required alliances.
Class of Yes The CoS for which you want to generate the dashboard.
Subscriber From the drop-down list, select the required CoS.
---
Note: You must specify one of the following set of filters for specifying the period to fetch data for the
dashboard:
n Time Granularity, Start date, and End date
n Within last
---
Time Yes Frequency at which you want to view the data in the dashboard.
Granularity The following options are available:
n Hourly
n Daily
n Monthly
Start date Yes Start date of the period for which you want to fetch the data and view in the dashboard.
Perform one of the following actions:
n Type the date in the dd-mm-yyyy format.
n Click the icon to specify the date in the date picker.

End date Yes End date of the period for which you want to fetch the data and view in the dashboard.
Perform one of the following actions:
n Type the date in the dd-mm-yyyy format.
n Click the icon to specify the date in the date picker.

Within last Yes Period for which you want to fetch the data and view in the dashboard.
You must specify values in the following input parameters in this filter:
n Unit: Text box in which you can specify an integer value corresponding to the
type of granularity that you select in the drop-down list that follows the Unit text
box.
n Granularity: Following types of granularity options are available:
n Days
n Weeks
n Months

n Quarters
n Years
From the drop-down list, select the granularity type.
Roamer No Type of roamer for which you want to generate the dashboard.
Type The following options are available:
n Inbound: “Report is generated for inbound roamers from the selected regions.”
n Outbound: “Report is generated for outbound roamers to the selected regions.”
From the drop-down list, select the required roamer type.

MAP No Name of the MAP message group for which you want to generate the dashboard.
Message The following options are available:
Group n Authentication
n Call
n Fault recovery
n Operation and maintenance
n Location management
n Registration
n SMS
n Subscriber management
n USSD
From the drop-down list, select the required message group names.
For a list of the message types included in the groups, refer to "Supported MAP
messages and message groups" on page 34.
MAP No The MAP messages for which you want to generate the dashboard.
Message From the drop-down list, select the required MAP messages.
Type
For a list of supported MAP messages, refer to "Supported MAP messages and
message groups" on page 34.
MAP Error No The MAP error codes for which you want to generate the dashboard.
Code From the drop-down list, select the required MAP error codes.
For a list of supported MAP error codes, refer to "Supported MAP error messages" on
page 35.
Error No Type of network that is responsible for the MAP transaction failures.
Causing The following options are available:
Network n Host: “Dashboard displays the distribution of failures that have occurred
Type because of issues in the host network.”
n Partner: “Dashboard displays the distribution of failures that have occurred
because of issues in the partner networks.”
From the drop-down list, select the required network types.

Widgets in the MAP transaction failure dashboard

Figure 4 on page 32 displays the MAP Transaction Failure dashboard.

F I GU R E 4 : M A P T R A N SA C T I ON F A I L U R E D A SH B OA R D
Table 5 on page 33 lists and describes the widgets available in the MAP transaction failure dashboard.

T A B L E 5 : W I D GET S IN THE MAP T R A N SA C T I ON F A I L U R E D A SH B OA R D
Widget Description
MAP Txn Failure Rate Displays region-wise (partner country, network, node) trend of total MAP transactions
by Region and the transaction failure rate. The widget displays the top 10 partner countries,
networks, or nodes (depending on the criteria you select) that have the most number
of failures. The regions are sorted first on the basis of total transactions and then by
failure rate.
The widget helps the operator to identify the regions where transaction failures are
high.
MAP Txn Failure Rate Displays the trend of total MAP transactions and the transaction failure rate over time
by Time for the selected duration.
MAP Txn Failure Rate Displays the message-wise trend of total MAP transactions and the transaction
by Message Type failure rate. The widget displays the message types with the maximum failure rate.
For a list of the MAP messages that the RCEM application considers for generating
the dashboard, refer to "Supported MAP messages and message groups" on page
34.
MAP Txn Failure Rate Displays the message group-wise trend of total MAP transactions and failure rate.
by Message Group MAP transactions are initiated between the networks to provide services
(registration, call, SMS, and so on) to subscribers. The message types are grouped
together to form specific message groups based on the services offered to the
subscribers.
The widget displays the information for the following message groups:
n Authentication
n Call
n Fault recovery
n Location management
n Registration
n SMS
n USSD
For a list of the MAP message types included in the groups, refer to "Supported MAP
MAP Txn Failure Rate Displays the distribution of error codes that cause the transaction failures that are
by Error Code observed.
For a list of the MAP error codes supported by the RCEM application, refer to
"Supported MAP error messages" on page 35.
MAP Txn Failure Rate Transaction failures can occur because of issues in either the host network or partner
by Error Causing PLMN networks.
This widget displays the distribution of failures across the following groups:
n host network–induced
n partner network–induced
For example, when a UL (for an outbound subscriber in a non-preferred network) is
rejected by the home operator’s steering application, this failure is categorized as a
host network–induced failure.
MAP Txn Top Failures Displays a detailed list of transaction failures that have occurred during the period
that you have selected.
The top transaction failures table displays the following information:

Widget Description
Columns in the
Description
widget
Partner Network Name of the partner network for which the MAP transaction
Name failures have occurred.
Message Name The MAP message from which the transaction failures have
occurred.
For a list of the MAP messages, refer to "Supported MAP
Error Code Error codes causing the transaction failures.
For a list of the MAP error codes, refer to "Supported MAP error
messages" on page 35.
Click the error code to generate the trace details.
Error Causing The type of network that causes the transaction failures.
Network Type
Total Transaction Total number of MAP transactions that have occurred between
the host and partner networks for the error codes that have
caused the failure.
Supported MAP messages and message groups

Table 6 on page 34 lists the MAP messages and the groups to which the messages belong that are supported
by the RCEM application.
T A B L E 6 : S U PPOR T ED M A P M ESSA GES A N D M ESSA GE GR OU PS
MAP message group MAP message name
Authentication Authentication Failure Report

Send Authentication Information (SAI)
Registration Update Location (UL)
Cancel Location (CL)
GPRS UL
GPRS CL
Subscriber Management Any Time Interrogation
Insert Subscriber Data (ISD)
Delete Subscriber Data (DSD)
Provide Subscriber Information (PSI)
Purge Mobile Station (Purge MS)

MAP message group MAP message name
SMS Report SM Delivery Status

Alert Service Center
Inform Service Center
Send Routing Info for Short Message (SRI_SM)
Mobile Originated Forward SMS Message (MO_FW_SM)
Mobile Terminated Forward SMS Message (MT_FW_
SM)
Ready for SM
End to End SMS
SMS Status Report
Call Send Routing Information
Provide Roaming Number (PRN)
Set Reporting State
Resume Call Handling
USSD Activate SS
Register SS
Erase SS
Interrogate SS
Deactivate SS
Get Password
Register Password
Process USSD Request
USSD Request
USSD Notify
Process Unstructured SS_Data
Process Unstructured SS_Request
SS Invocation Notify
Notify SS
Begin Subscriber Activity
Location Management Provide Subscriber Location
Subscriber Location Report
Operation and Maintenance Send IMSI
Activate Trace Mode
Deactivate Trace Mode
Fault Recovery Restore Data
Reset Data
Forward Check SS Indication
Register CC Entry
Erase CC Entry
Remote User Free
SRI-GPRS
Note Subscriber Data Modified

Supported MAP error messages

Table 7 on page 36 lists the standard MAP error messages that the RCEM application supports.

T A B L E 7 : S U PPOR T ED M A P ER R OR M ESSA GES
MAP error group name MAP error
Tcap error Abort-badlyFormattedTransactionPortion

Abort-incorrectTransactionPortion
Abort-resourceLimitation
Abort-unrecognizedMessageType
Abort-unrecognizedTransactionID
Absent Subscriber
Dialogue Service Provider Abort
Dialogue Service User Abort
Facility Not Supported
Reject Invoke-unrecognizedLinkedID
Provider Abort No Common Dialogue
Provider Abort No Reason Given
Provider Abort Null
Reject General-badlyStructuredComponent
Reject General-mistypedComponent
Reject General-unrecognizedComponent
Reject Invoke-duplicateInvokeID
Reject Invoke-initiating Release
Reject Invoke-linkedResponseUnexpected
Reject Invoke-mistypedParameter
Reject Invoke-resourceLimitation
Reject Invoke-unexpectedLinkedOperation
Reject Invoke-unrecognizedOperation
Reject RE-mistypedParameter
Reject RE-returnErrorUnexpected
Reject RE-unexpectedError
Reject RE-unrecognizedError
Reject RE-unrecognizedInvokeID
Reject RR-mistypedParameter
Reject RR-returnResultUnexpected
Reject RR-unrecognizedInvokeID
User Abort ACN Not supported
User Abort No Reason Given
User Abort Null
TCAP Reject Unknown
TCAP Timeout
Provider error Call Barred
Illegal Equipment
Resource Limitation
Teleservice Not Provisioned

MAP error group name MAP error
User error ATI-Not Allowed

Absent SubscriberSM
Busy Subscriber
Illegal Subscriber
Incompatible Terminal
Message Waiting List Full
Position Method Failure
Roaming Not Allowed
Success Message
Tracing Buffer Full
UDTS
Unauthorized LCS Client
Unauthorized Requesting Network
Unidentified Subscriber
Unknown or Unreachable LCS Client
Unknown Subscriber
Supplementary service error Number of Password Attempts
SS error status
SS incompatibility
SS not available
SS subscription violation
USSD Busy
Unknown Alphabet
illegal SS operation
long term denial
negative password check
password registration failure
short term denial
Others Data Missing
No Roaming Number Available
OR-NotAllowed
SM-DeliveryFailure
SubscriberBusyForMT-SMS
System Failure
Unexpected Data Value

MAP Performance dashboard

This section contains the following topics:
n "What details does the MAP Performance dashboard provide?" on page 38

n "Which KPIs does the MAP Performance dashboard use?" on page 38
n "Which filters does the RCEM application use to generate the MAP Performance dashboard?" on page

38
n "Which widgets does the RCEM application display in the MAP Performance dashboard?" on page 39
What details does the MAP Performance dashboard

provide?
n MAP Performance dashboard provides a collaborative view of successful MAP transactions (includes
messages such as UL, SAI, PSI, and so on) that occurred for a home network.
n The dashboard segregates successful MAP transactions by various levels such as region, time, and so
on.
Which KPIs does the MAP Performance dashboard use?

The MAP Performance dashboard uses the following KPIs to display information in each widget:
n : Total number of MAP transactions that occurred between the home and visited
network.
n : Total number of MAP transactions for which ACK messages were

exchanged between the home and visited network.
n : Number of MAP transactions (in percentage) for which an ACK message was
exchanged between the home and visited network. The RCEM application uses the following formula to
determine Success Rate:
n Successful Transaction / Total Transactions * 100
Exam ple t hat pr ovides det ails about count s t hat ar e

consider ed f or Tot al and Successf ul t r ansact ions
n Consider a scenario where a roamer attempts to register with a visited network, N1.
n The N1 VLR generates a UL message, which the home network receives.
n The home network has deployed an SoR application. Therefore, based on the SoR application logic, the
application steers four UL messages from N1.
n The roamer leaves network N1 and attempts to register with network N2.
n The SoR application allows the first UL message from N2.
In this scenario, following are corresponding counts:
n Total Transaction = 4+1=5

n Successful Transactions =1
n Success Rate = 1/5*100 = 20%
Which filters does the RCEM application use to generate

the MAP Performance dashboard?
Filters in this dashboard and in the MAP Transaction Failure dashboard are identical. For more information,
refer to "Filters available in the MAP transaction failure dashboard" on page 29.

Which widgets does the RCEM application display in the

MAP Performance dashboard?
F I GU R E 5 : W I D GET S IN THE M A P P ER F OR M A N C E D A SH B OA R D
As shown in Figure 5 on page 39, the MAP Performance dashboard displays the following widgets:
n MAP TXN SUCCESS RATE BY REGION

n MAP TXN SUCCESS TREND
n MAP TXN SUCCESS RATE BY MESSAGE TYPE
n MAP TXN SUCCESS RATE BY MESSAGE GROUP
M AP TXN SUCCESS RATE BY REG I O N
F I GU R E 6 : M A P TX N S U C C E S S R A TE B Y R E GION W I D GET
n The MAP TXN SUCCESS RATE BY REGION widget displays region-wise trend of total MAP transaction
and success rate of MAP transactions.

n The widget displays the top 10 partner countries, networks, or nodes (depending on the criteria you
select) that have the most number successful MAP transactions. The regions are sorted first on the basis
of total transactions and then by success rate.
n Subsequently, you can drill-down to node-wise distribution
M AP TXN SUCCESS RATE BY TI M E
F I GU R E 7 : M A P TX N S U C C E S S R A TE B Y TIM E W I D GET
n The MAP TXN SUCCESS RATE BY TIME widget displays the trend of total MAP transactions and the
transaction success rate over time for the selected duration.
M AP TXN SUCCESS RATE BY M ESSAG E TYPE
F I GU R E 8 : M A P TX N S U C C E S S R A TE B Y M E S S A GE TY P E W I D GET
n The MAP TXN SUCCESS RATE BY MESSAGE TYPE widget displays the message-wise trend of total
MAP transactions and the transaction success rate. The widget displays the message types with the
maximum success rate. For a list of the MAP messages that the RCEM application considers for
generating the dashboard, refer to "Supported MAP messages and message groups" on page 34.

M AP TXN SUCCESS RATE BY M ESSAG E G RO UP
F I GU R E 9 : M A P TX N S U C C E S S R A TE B Y M E S S A GE GR OU P W I D GET
n The MAP TXN SUCCESS RATE BY MESSAGE GROUP widget displays the message group-wise trend
of total MAP transactions and success rate.
n MAP transactions are initiated between the networks to provide services (registration, call, SMS, and so
on) to subscribers. The message types are grouped together to form specific message groups based on
the services offered to the subscribers. The widget displays the information for the following message
groups:
n Authentication
n Registration
n SMS
n Call
n USSD
n Fault Recovery
For a list of the MAP messages that the RCEM application considers for generating the dashboard, refer to
"Supported MAP messages and message groups" on page 34.
Diameter failure dashboard

The Diameter failure dashboard provides an analysis of the DIAMETER transactions failures observed on the
roaming links. Transactions can fail because of any of the participating nodes and will impact the end service
provided to the subscribers. Analyzing the failures from multiple dimensions is important to fix the failures. The
Diameter failure dashboard helps operators to analyze the transaction failures across the following dimensions:
n Region
n Time
n Message type
n Message group

n Error code
n Error causing network
KPIs in the Diameter failure dashboard

n Total transaction count: The total Diameter transactions that occurred between the HPMN and VPMN.
n Transaction failure rate: Number of Diameter transactions that have failed for a particular dimension.
The transaction failure rate for a particular dimension is computed as follows:
Transactions failed (grouped for a dimension) / Total transactions
Filters available in the Diameter failure dashboard

Table 8 on page 42 lists and describes the filters available for generating the Diameter failure dashboard.
T A B L E 8 : F I L T ER S F OR GEN ER A T I N G T H E D I A M ET ER F A I L U R E D A SH B OA R D
Host Name No For description, refer to Table 4 on page 29.

Partner Type Yes
Partner Country No
Partner Network No
Alliance No
Class of Yes
Subscriber
Time Granularity Yes
Start date Yes
End date Yes
Within last Yes
Roamer Type No
Error Causing No
Network Type
Partner MME No ---
Note: This field is applicable only if you select the Nodewise option in the
---
Address of a partner network’s MME for which you want to generate the
dashboard.
Specify the address (in string format) in the text box.
DIA Message No Name of the Diameter message group for which you want to generate the
Group dashboard.
n Registration
n Fault recovery
From the drop-down list, select the required message group names.

For a list of the message types included in the groups, refer to "Supported
Diameter messages and message groups" on page 46.
DIA Message No The Diameter messages for which you want to generate the dashboard.
Type From the drop-down list, select the required Diameter messages.
For a list of supported Diameter messages, refer to "Supported Diameter
DIA Error Code No The Diameter error codes for which you want to generate the dashboard.
From the drop-down list, select the required Diameter error codes.
For a list of supported Diameter error codes, refer to "Supported Diameter error

Widgets in the Diameter failure dashboard

Figure 10 on page 44 displays the Diameter Failure dashboard.

F I GU R E 1 0 : D I A M ET ER F A I L U R E D A SH B OA R D
Table 9 on page 45 lists and describes the widgets available in the Diameter failure dashboard.

T A B L E 9 : W I D GET S IN THE D I A M ET ER F A I L U R E D A SH B OA R D
Widget Description
DIA Txn Failure Rate by Displays host network-wise (in a multi-tenant deployment) distribution of total
Host Diameter transactions and the transaction failure rate.
DIA Txn Failure Rate by Displays region-wise (partner country, network, node) distribution of total Diameter
Region transactions and the transaction failure rate. The widget displays the top 10 partner
countries, networks, or nodes (depending on the criteria you select) that have the
most number of failures. The regions are sorted first on the basis of total transactions
and then by failure rate.
The widget helps the operator to identify the regions where transaction failures are
high.
DIA Txn Failure Rate by Displays the message-wise distribution of total Diameter transactions and the
Message Type transaction failure rate. The widget displays the message types with the maximum
failure rate.
For a list of the Diameter messages that the RCEM application considers for
generating the dashboard, refer to "Supported Diameter messages and message
groups" on page 46.
DIA Txn Failure Rate by Displays the message group-wise distribution of total Diameter transactions and
Message Group failure rate.
Diameter transactions are initiated between the networks to provide services (such
as registration and subscriber management) to subscribers. The message types are
grouped together to form specific message groups based on the services offered to
the subscribers.
The widget displays the information for the following message groups:
n Registration
n Fault recovery
For a list of the Diameter message types included in the groups, refer to "Supported
DIA Txn Failure Rate by Displays the distribution of Diameter error codes that cause the transaction failures
Error Code that are observed.
For a list of the Diameter error codes supported by the RCEM application, refer to
"Supported Diameter error messages" on page 46.
DIA Txn Failure Rate by The Diameter transaction failures can occur because of issues in either the host
Error Causing PLMN network or the partner networks.
This widget displays the distribution of failures across the following groups:
n Host
n Partner
For example, when a ULR (for an outbound subscriber in a non-preferred network) is

rejected by the home operator’s steering application, this failure is categorized as a
host network–induced failure.
DIA Txn Failure Trend Displays the trend of total Diameter transactions and the transaction failure rate over
time for the selected duration.
DIA Txn Top Failures Displays a detailed list of transaction failures that have occurred during the period
that you have selected.
The top transaction failures table displays the following information:
Columns in the widget Description
Partner Network Name Name of the partner network for which the Diameter
transaction failures have occurred.
Message Name The Diameter message from which the transaction failures

Widget Description
have occurred.
For a list of the Diameter messages, refer to "Supported
Error Code Error codes causing the transaction failures.
For a list of the Diameter error codes, refer to "Supported
Diameter error messages" on page 46.
Click the error code to generate the trace details.
Error Causing Network The type of network that causes the transaction failures.
Type
Total Transaction Total number of Diameter transactions that have occurred
between the host and partner networks for the error codes
that have caused the failure.
Supported Diameter messages and message groups

Table 10 on page 46 lists the Diameter messages and the groups to which the messages belong that are
supported by the RCEM application.
T A B L E 1 0 : S U PPOR T ED D I A M ET ER M ESSA GES A N D M ESSA GE GR OU PS
Diameter message
Diameter message name
group
Registration Update Location Request/Answer (ULR/ULA)
Cancel Location Request/Answer (CLR/CLA)
Authentication Information Request/Answer
(AIR/AIA)
Subscriber Management Insert subscriber Data Request/Answer (IDR/IDA)
Delete Subscriber Data Request/Answer (DSR/DSA)
Purge UE Request/Answer (PUR/PUA)
Fault Recovery Reset Request/Answer (RSR/RSA)
Notify Request/Answer (NOR/NOA)

Supported Diameter error messages

Following is a list of Diameter error messages that the RCEM application supports:
n DIAMETER ADC RULE EVENT

n DIAMETER ADMINISTRATIVE
n DIAMETER AN GW FAILED
n DIAMETER APPLICATION UNSUPPORTED
n DIAMETER AUTH DATA UNAVAILABLE
n DIAMETER AUTH EXPIRED

n DIAMETER AUTH REJECTED

n DIAMETER AUTHENTICATION REJECTED
n DIAMETER AVP NOT ALLOWED
n DIAMETER AVP OCCURS TO MANY TIMES
n DIAMETER AVP UNSUPPORTED
n DIAMETER BAD ANSWER
n DIAMETER BEARER EVENT
n DIAMETER COMMAND UNSUPPORTED
n DIAMETER CONTRADICTING AVPS
n DIAMETER ELECTION LOST
n DIAMETER ERROR PROSE NOT ALLOWED
n DIAMETER ERROR SUBSESSION
n DIAMETER ERROR UE LOCATION UNKNOWN
n DIAMETER ERROR ABSENT USER
n DIAMETER ERROR ABSENT USER
n DIAMETER ERROR ANNOUNCING UNAUTHORIZED IN PLMN
n DIAMETER ERROR APP REGISTER REJECT
n DIAMETER ERROR AUTH SCHEME NOT SUPPORTED
n DIAMETER ERROR AUTHORIZATION REJECT
n DIAMETER ERROR BEARER NOT AUTHORIZED
n DIAMETER ERROR CAMEL SUBSCRIPTION PRESENT
n DIAMETER ERROR CONFIGURATION EVENT NON EXISTANT
n DIAMETER ERROR CONFIGURATION EVENT STORAGE NOT SUCCESSFUL
n DIAMETER ERROR CONFLICTING REQUEST
n DIAMETER ERROR DETACHED USER
n DIAMETER ERROR DISCOVERY NOT PERMITTED
n DIAMETER ERROR DSAI NOT AVAILABLE
n DIAMETER ERROR EQUIPMENT UNKNOWN
n DIAMETER ERROR FACILITY NOT SUPPORTED
n DIAMETER ERROR FEATURE UNSUPPORTED
n DIAMETER ERROR IDENTITIES DONT MATCH
n DIAMETER ERROR IDENTITY ALREADY REGISTERED
n DIAMETER ERROR IDENTITY NOT REGISTERED
n DIAMETER ERROR ILLEGAL EQUIPMENT
n DIAMETER ERROR ILLEGAL USER
n DIAMETER ERROR IMPI UNKNOWN
n DIAMETER ERROR IN ASSIGNMENT TYPE
n DIAMETER ERROR INITIAL PARAMETERS
n DIAMETER ERROR INVALID APPLICATION CODE
n DIAMETER ERROR INVALID APPLICATION DATA

n DIAMETER ERROR INVALID DISCOVERY TYPE

n DIAMETER ERROR INVALID SME ADDRESS
n DIAMETER ERROR INVALID TARGET PDUID
n DIAMETER ERROR INVALID TARGET RPAUID
n DIAMETER ERROR LATE OVERLAPPING REQUEST
n DIAMETER ERROR MAP REQUEST REJECT
n DIAMETER ERROR MISSING APPLICATION DATA
n DIAMETER ERROR MWD LIST FULL
n DIAMETER ERROR NBIFOM NOT AUTHORIZED
n DIAMETER ERROR NO ACCESS INDEPENDENT SUBSCRIPTION
n DIAMETER ERROR NO ASSOCIATED DISCOVERY FILTER
n DIAMETER ERROR NO ASSOCIATED RESTRICTED CODE
n DIAMETER ERROR NO AVAILABLE POLICY COUNTERS
n DIAMETER ERROR NO PROXIMITY REQUEST
n DIAMETER ERROR NO SUBSCRIPTION TO DATA
n DIAMETER ERROR NOT AUTHORIZED
n DIAMETER ERROR NOT SUPPORTED USER DATA
n DIAMETER ERROR ONGOING SESSION ESTABLISHMENT
n DIAMETER ERROR OPERATION NOT ALLOWED
n DIAMETER ERROR ORIGIN ALUID UNKNOWN
n DIAMETER ERROR ORIGINAL MESSAGE NOT PENDING
n DIAMETER ERROR OUT OF_RESOURCES
n DIAMETER ERROR PFID UNKNOWN
n DIAMETER ERROR POSITIONING DENIED
n DIAMETER ERROR POSITIONING FAILED
n DIAMETER ERROR PROSE MAP REQUEST DISALLOWED
n DIAMETER ERROR PROXIMITY CANCELLED
n DIAMETER ERROR PROXIMITY REJECTED
n DIAMETER ERROR PROXIMITY UNAUTHORIZED
n DIAMETER ERROR RAT NOT ALLOWED
n DIAMETER ERROR RAT TYPE NOT ALLOWED
n DIAMETER ERROR REQUESTED LOCATION NOT SERVED
n DIAMETER ERROR REQUESTED RANGE IS NOT ALLOWED
n DIAMETER ERROR REQUESTING RPAUID UNKNOWN
n DIAMETER ERROR ROAMING NOT ALLOWED
n DIAMETER ERROR SC CONGESTION
n DIAMETER ERROR SCEF REFERENCE ID UNKNOWN
n DIAMETER ERROR SERVICE AREA
n DIAMETER ERROR SERVICE BARRED
n DIAMETER ERROR SERVICE NOT SUBSCRIBED

n DIAMETER ERROR SERVING NODE FEATURE UNSUPPORTED

n DIAMETER ERROR SM DELIVERY FAILURE
n DIAMETER ERROR SM PROTOCOL
n DIAMETER ERROR START INDICATION
n DIAMETER ERROR STOP INDICATION
n DIAMETER ERROR SUBS DATA ABSENT
n DIAMETER ERROR SUSPENDED USER
n DIAMETER ERROR TARGET ALUID UNKNOWN
n DIAMETER ERROR TARGET RPAUID UNKNOWN
n DIAMETER ERROR TIMED OUT REQUEST
n DIAMETER ERROR TOO MUCH DATA
n DIAMETER ERROR TRAFFIC MAPPING INFO REJECTED
n DIAMETER ERROR TRANSACTION IDENTIFIER INVALID
n DIAMETER ERROR TRANSPARENT DATA OUT OF SYNC
n DIAMETER ERROR TRIGGER EVENT
n DIAMETER ERROR TRIGGER RECALL FAILURE
n DIAMETER ERROR TRIGGER REPLACE FAILURE
n DIAMETER ERROR UNAUTHORIZED CHARGEABLE PARTY
n DIAMETER ERROR UNAUTHORIZED REQUESTING ENTITY
n DIAMETER ERROR UNAUTHORIZED REQUESTING NETWORK
n DIAMETER ERROR UNAUTHORIZED SERVICE
n DIAMETER ERROR UNAUTHORIZED SERVICE IN THIS PLMN
n DIAMETER ERROR UNKNOWN EPS SUBSCRIPTION
n DIAMETER ERROR UNKNOWN MBMS BEARER SERVICE
n DIAMETER ERROR UNKNOWN OR INVALID TARGET SET
n DIAMETER ERROR UNKNOWN POLICY COUNTERS
n DIAMETER ERROR UNKNOWN PROSE SUBSCRIPTION
n DIAMETER ERROR UNKNOWN UNREACHABLE LCS CLIENT
n DIAMETER ERROR UNKOWN SERVING NODE
n DIAMETER ERROR UNREACHABLE USER
n DIAMETER ERROR UNSUITABLE NETWORK
n DIAMETER ERROR USER BUSY FOR MT SMS
n DIAMETER ERROR USER DATA CANNOT BE MODIFIED
n DIAMETER ERROR USER DATA CANNOT BE NOTIFIED
n DIAMETER ERROR USER DATA CANNOT BE READ
n DIAMETER ERROR USER DATA NOT RECOGNIZED
n DIAMETER ERROR USER NO APN SUBSCRIPTION
n DIAMETER ERROR USER NO NON 3GPP SUBSCRIPTION
n DIAMETER ERROR USER NO W-APN SUBSCRIPTION
n DIAMETER ERROR USER NO WLAN SUBSCRIPTION

n DIAMETER ERROR USER UNKNOWN

n DIAMETER ERROR W-APN UNUSED BY USER
n DIAMETER INVALID AVP BIT COMBO
n DIAMETER INVALID AVP BITS
n DIAMETER INVALID AVP LENGTH
n DIAMETER INVALID AVP VALUE
n DIAMETER INVALID BIT IN HEADER
n DIAMETER INVALID HDR BITS
n DIAMETER INVALID MESSAGE LENGTH
n DIAMETER LIMITED SUCCESS
n DIAMETER LINK BROKEN
n DIAMETER LOGOUT
n DIAMETER LOOP DETECTED
n DIAMETER MISSING AVP
n DIAMETER MULTI ROUND AUTH
n DIAMETER NO COMMON APP
n DIAMETER NO COMMON SECURITY
n DIAMETER OUT OF SPACE
n DIAMETER PCC BEARER EVENT
n DIAMETER PCC RULE EVENT
n DIAMETER PENDING TRANSACTION
n DIAMETER PRIOR UPDATE IN PROGRESS
n DIAMETER QOS RULE EVENT
n DIAMETER REALM NOT SERVED
n DIAMETER REDIRECT INDICATION
n DIAMETER RESOURCES EXCEEDED
n DIAMETER SERVICE NOT PROVIDED
n DIAMETER SESSION TIMEOUT
n DIAMETER SUCCESS
n DIAMETER TIMEOUT
n DIAMETER TOO BUSY
n DIAMETER UNABLE TO COMPLY
n DIAMETER UNABLE TO DELIVER
n DIAMETER UNKNOWN PEER
n DIAMETER UNKNOWN SESSION ID
n DIAMETER UNSUPPORTED VERSION
n DIAMETER USER DATA NOT AVAILABLE
n DIAMETER USER MOVED
n DUPLICATED AF SESSION
n FILTER RESTRICTIONS

n INVALID SERVICE INFORMATION

n IP-CAN SESSION NOT AVAILABLE
n REQUESTED SERVICE NOT AUTHORIZED
n REQUESTED SERVICE TEMPORARILY NOT AUTHORIZED
n RTEMPORARY NETWORK FAILURE
n UNAUTHORIZED NON EMERGENCY SESSION
n UNAUTHORIZED SPONSORED DATA CONNECTIVITY
DIAMETER Performance dashboard

n "What details does the DIAMETER Performance dashboard provide?" on page 51

n "How does the RCEM application determine successful DIAMETER transactions for a network?" on
page 52
n "Which KPIs does each widget display in the DIAMETER Performance dashboard?" on page 53
n "Which filters does the RCEM application use to generate the DIAMETER Performance dashboard?" on
page 53
n "Which widgets does the RCEM application display in the DIAMETER Performance dashboard?" on
page 54
What details does the DIAMETER Performance

dashboard provide?
n DIAMETER Performance dashboard provides a collaborative view of successful DIAMETER
transactions (includes messages such as ULR, Purge UE Request, Insert-Subscriber data, and so on)
that occurred for a home network.
n The dashboard segregates successful DIAMETER transactions by various levels such as region, time,
and so on.

How a successf ul DI AM ETER t r ansact ion occur s
F I GU R E 1 1 : D IA M E TE R SU C C ESS
n Figure 11 on page 52, depicts the successful the DIAMETER transaction.

n The DIAMETER_SUCCESS result code and 12001 AVP value denotes DIAMETER success.
n The aforementioned result code and AVP is sent is in a ULA message by HSS to the MME.
How does the RCEM application determine successful

DIAMETER transactions for a network?
n For each DIAMETER messages for a network, the RCEM application monitors successful
ACK messages. If the RCEM application observes 12001 AVP value in the ULR ACK message, the
application increments the count for Successful Transactions that is displayed in the each widget of the
DIAMETER Performance dashboard.
n If the RCEM application does not observe an ACK message for the corresponding DIAMETER message,
the application identifies such occurrences as failures and does not consider such events for successful
transactions.
Exam ple f or t ot al and successf ul t r ansact ions

n Consider a scenario where a roamer attempts to register with a visited network, N1.
n The N1 MME generates a ULR message, which the home network receives.
n The home network has deployed an SoR application. Therefore, based on the SoR application logic, the
application steers four

n ULR messages from N1.

n The roamer leaves network N1 and attempts to register with network N2.
n The SoR application allows the first ULR message from N2.
In this scenario, following are corresponding counts:
n Total Transaction = 4+1=5

n Successful Transactions =1
n Success Rate = 1/5*100 = 20%
TI M EO UT er r or s
n The RCEM application monitors ACK messages for a corresponding DIAMETER message for a time out
duration.
n If the RCEM application does not observe an ACK message within the time out duration, the application
identifies such concurrences as TIMEOUT errors and excludes this transaction from the successful
DIAMETER transactions count.
n You can configure the time out duration in the diawriter.max.transaction.timeout.msec parameter
IPProbe.cfg file.
Which KPIs does each widget display in the DIAMETER

Performance dashboard?
Widgets in the DIAMETER Performance dashboard display the following KPIs:
: Total number of DIAMETER transactions that occurred between the home and visited
network.
: Total number of DIAMETER transactions for which ACK messages were

exchanged between the home and visited network.
: Number of DIAMETER transactions (in percentage) for which an ACK message was
exchanged between the home and visited network. The RCEM application uses the following formula to
determine Success Rate:
n Successful Transaction / Total Transactions * 100

the DIAMETER Performance dashboard?
Filters in this dashboard and in the DIAMETER Transaction Failure dashboard are identical. For more
information, refer to "Filters available in the Diameter failure dashboard" on page 42.


DIAMETER Performance dashboard?
F I GU R E 1 2 : W I D GET S IN THE D IA M E TE R P ER F OR M A N C E D A SH B OA R D
As shown in Figure 12 on page 54, the DIAMETER Performance dashboard displays the following widgets:
n DIAMETER TXN SUCCESS RATE BY REGION

n DIAMETER TXN SUCCESS TREND
n DIAMETER TXN SUCCESS RATE BY MESSAGE TYPE
n DIAMETER TXN SUCCESS RATE BY MESSAGE GROUP
DI AM ETER TXN SUCCESS RATE BY REG I O N
F I GU R E 1 3 : D IA M E TE R TX N S U C C E S S R A TE B Y R E GION W I D GET

n The DIAMETER TXN SUCCESS RATE BY REGION widget displays region-wise trend of total
DIAMETER transaction and success rate of DIAMETER transactions.
n The widget displays the top 10 partner countries, networks, or nodes (depending on the criteria you
select) that have the most number successful DIAMETER transactions. The regions are sorted first on
the basis of total transactions and then by success rate.
DI AM ETER TXN SUCCESS TREND
F I GU R E 1 4 : D IA M E TE R TX N S U C C E S S TR E N D W I D GET
n The DIAMETER TXN SUCCESS TREND widget displays the trend of total DIAMETER transactions and
the transaction success rate over time for the selected duration.
DI AM ETER TXN SUCCESS RATE BY M ESSAG E TYPE
F I GU R E 1 5 : D IA M E TE R TX N S U C C E S S R A TE B Y M E S S A GE TY P E W I D GET
n The DIAMETER TXN SUCCESS RATE BY MESSAGE TYPE widget displays the message-wise trend of
total DIAMETER transactions and the transaction success rate. The widget displays the message types
with the maximum success rate. For a list of the DIAMETER messages that the RCEM application

considers for generating the dashboard, refer to "Supported Diameter messages and message groups"
on page 46
DI AM ETER TXN SUCCESS RATE BY M ESSAG E

G RO UP
F I GU R E 1 6 : D IA M E TE R TX N S U C C E S S R A TE B Y M E S S A GE GR OU P W I D GET
n The DIAMETER TXN SUCCESS RATE BY MESSAGE GROUP widget displays the message group-
wise trend of total DIAMETER transactions and success rate.
n DIAMETER transactions are initiated between the networks to provide services (registration, LTE call,
VoLTE data, and so on) to subscribers. The message types are grouped together to form specific
message groups based on the services offered to the subscribers. The widget displays the information
for the following message groups:
n Registration
n Fault Recovery
For a list of the DIAMETER messages that the RCEM application considers for generating the dashboard, refer
to "Supported Diameter messages and message groups" on page 46
Voice service accessibility dashboard

The Voice service accessibility dashboard provides an analysis of the following information:
n Ability of networks to deliver calls to the destination: The dashboard displays this analysis in terms of
the NER KPI. The NER expresses the relationship between the number of international calls that were
successfully delivered to the destination and the total number of international calls between networks.
n Voice call connection speed between networks: Voice call connection speed is measured in terms of
the average PDD time interval KPI. The average PDD provides an estimate of a network’s voice call
connection speed between networks. The dashboard also displays the reasons that cause delays in
voice call connections.

The dashboard also displays the failures observed during voice call transactions and the effect of these failures
on the average PDD and NER values. Analyzing the failures from multiple dimensions is important to fix the
failures. The Voice service accessibility dashboard helps operators to analyze the failures across the following
dimensions:
n Region
n Time
n Error code
n Call type
The dashboard displays data for ISUP and CAMEL voice services offered to both inbound and outbound
roamers.
KPIs in the Voice service accessibility dashboard

n NER: (Expressed as a percentage value, for international roaming call transactions.) NER expresses the
relationship between the total number of calls and the sum of the number of calls resulting in either of
the following results:
n Answer signal
n User busy (release cause codes: 17)
n Ring but no answer (cause codes: 16 (normal call clearing), 18 (no user responding), 19 (no answer
from user (user alerted)))
n In the case of ISDN, a terminal rejection or unavailability (release cause codes: 21 (call rejected), 27
(destination out of order))
NER is calculated as follows:
[Number of successful call attempts] x 100 / [Number of call attempts]
n PDD: PDD corresponds to the time between sending of complete address information and receipt of call
set-up notification. PDD is computed as the difference in time between the IAM and ACM messages and
is measured in seconds.
Note: The RCEM application does not calculate PDD for CAMEL-based calls.
n Total call count: Number of calls attempted (includes successful and failed attempts) by the roamers in
the specified region and time.
n Count of successful calls: Number of successful calls with the following release cause codes: 16, 17,
18, 19, 21, 27.
Filters available in the Voice service accessibility

dashboard
Table 11 on page 58 lists and describes the filters available for generating the Voice service accessibility
dashboard.

T A B L E 1 1 : F I L T ER S F OR GEN ER A T I N G T H E V OI C E SER VI C E A C C ESSI B I L I T Y D A SH B OA R D
Host Name No For descriptions, refer to Table 4 on page 29.

Partner Type Yes
Partner No
Network
Partner GT No
Time Yes
Granularity
Start date Yes
End date Yes
Within last Yes
Roamer Type No
Voice Protocol No Voice protocol for which you want to generate the dashboard.
n ISUP
n CAMEL
From the drop-down list, select the required protocols.
Call Type No Type of call for which you want to generate the dashboard.
n Mobile Terminated
n Mobile Originated
From the drop-down list, select the required call types.
Voice Error No The voice error codes for which you want to generate the dashboard.
Code From the drop-down list, select the required voice error codes.
For a list of supported voice error codes, refer to "Supported voice service error
codes" on page 60.

Widgets in the Voice service accessibility dashboard

Figure 17 on page 59 displays the Voice service accessibility dashboard.

F I GU R E 1 7 : V OI C E SER VI C E A C C ESSI B I L I T Y D A SH B OA R D
Table 12 on page 59 lists and describes the widgets available in the Voice service accessibility dashboard.
T A B L E 1 2 : W I D GET S IN THE V OI C E SER VI C E A C C ESSI B I L I T Y D A SH B OA R D
Widget Description
Service Accessibility Displays region-wise (partner country, network, node) trend of average PDD and NER
by Region values.
The widget helps the operator to identify the regions where the NER values are low
and where the PDD values are high.
Service Accessibility Displays the trend of average PDD and NER values over time for the selected
by Time duration.
Service Accessibility Displays the distribution of voice service error codes that cause the delay in accessing
by Cause Code voice services.
For a list of voice service error codes that are supported by the RCEM application,

Widget Description
refer to "Supported voice service error codes" on page 60.

Service Accessibility Displays the trend of average PDD and NER values over time for the selected call
by Call Type types.
The following call types are supported:
n Mobile Terminated
n Mobile Originated
Voice Service Displays a detailed list of the top 20 partner networks with the maximum number of
Accessibility call counts during the period that you select.
The voice service accessibility table displays the following information:
Partner Network Name Name of the partner network for which the maximum voice
call count is present.
Roamer Type Type of roamer for which the maximum voice call count is
present.
Call Type Type of call for which the maximum voice call count is
present.
Error Code Error codes that cause voice call failures.
For a list of voice error codes, refer to "Supported voice
service error codes" on page 60.
Total Call Count Number of voice calls that have occurred between the host
and partner networks.
Successful Calls Number of successful calls with the following release cause
Attempted Count codes: 16, 17, 18, 19, 21, 27.
Network Efficiency NER (in percentage value) for the partner network.
Ratio (%)
Average Post Dial Average PDD (in seconds) for the partner network.
Delay (sec)
Supported voice service messages

Following are the ISUP messages that the RCEM application supports and monitors:
n Initial Address Message (IAM)

n Address Complete Message (ACM)
n Subsequent Address Message (SAM)
n Answer Message (ANM)
n CONT
n Release (REL)
n Release Complete (RLC)
Supported voice service error codes

Following is the list of voice service error codes that the RCEM application supports:
n A suspended call exists but this call identity does not

n Access information discarded

n Bearer capability not authorized
n Bearer capability not implemented
n Bearer capability not presently available
n Call awarded and being delivered in established channel
n Call having the requested call identity has been cleared
n Call identity in use
n Call rejected
n Channel type not implemented
n Channel unacceptable
n Destination out of order
n Exchange routing error
n Facility rejected
n Identified channel does not exist
n Incoming calls barred within CUG
n Incompatible destination
n Inconsistency in designed outg. access inf. and subscr. class
n Information element non-existent or not implemented
n Interworking or unspecified
n Invalid call reference value
n Invalid information element contents
n Invalid message, unspecified
n Invalid number format
n Invalid transit network selection
n Mandatory information element is missing
n Message incompatible with call state or mesg type non-existent or not implemented
n Message not compatible with call state
n Message type non-existing or not implemented
n Message with unrecognized parameter discarded
n Misdialed trunk prefix
n Network out of order
n No answer from user (user alerted)
n No call suspended
n No circuit/channel available
n No route to destination
n No route to specific transit network
n No user responding
n Non-existing CUG
n Non-selected user clearing
n Normal call clearing

n Normal or unspecified
n Number changed
n Only restricted digital information bearer capability is available
n Outgoing calls barred within CUG
n Parameter non-existent or not implemented - passed on
n Permanent frame mode connection operational
n Permanent frame mode connection out of service
n Precedence call blocked
n Preemption
n Preemption – circuit reserved for reuse
n Protocol error or unspecified
n Quality of service unavailable
n Recovery on timer expiry
n Requested channel/circuit not available
n Requested facility not implemented
n Requested facility not subscribed
n Resources unavailable or unspecified
n Response to STATUS ENQUIRY
n Send special info tone
n Service or option not available or unspecified
n Service or option not implemented, unspecified
n Subscriber absent
n Switching equipment congestion
n Temporary failure
n Transaction Abort Received
n Transaction Error Received
n Transaction Reject Received
n Unallocated (unassigned) number
n Unknown cause code
n Unknown release cause code
n User busy
n User not member of CUG
Voice connection establishment

dashboard
The Voice connection establishment dashboard provides an analysis of the following information:

n Voice call seizures: Voice call seizure is measured in terms of the ASR KPI. The ASR expresses the
relationship between the number of calls that were successfully answered and the total number of calls.
The dashboard also displays the failures observed during the voice call transactions and the effect of these
failures on the ASR values. Analyzing the failures from multiple dimensions is important to fix the failures. The
Voice service accessibility dashboard helps operators to analyze the failures across the following dimensions:
n Region
n Time
n Error code
n Call type
The dashboard helps operators to obtain the cause of the failures and help fix these errors.
roamers.
KPIs in the Voice connection establishment dashboard

n ASR: (Expressed as a percentage value, for international roaming call transactions.) ASR expresses the
relationship between the number of call attempts that result in an answer signal and the total number of
call attempts. This is a direct measure of the effectiveness of the service being offered onward from the
point of measurement.
ASR is calculated as follows:
[Number of answered international calls] x 100 / [Number of international calls that were
successfully attempted] x 100
n Total call count: Number of calls attempted (includes successful and failed attempts) by the roamers in
the specified region and time.
n Count of successful calls: Number of calls that were answered.
Filters available in the Voice connection establishment

dashboard
Table 13 on page 64 lists and describes the filters available for generating the Voice connection establishment
dashboard.

T A B L E 1 3 : F I L T ER S F OR GEN ER A T I N G T H E V OI C E C ON N EC T I ON EST A B L I SH M EN T D A SH B OA R D

Partner Type Yes
Partner Country No
Partner Network No
Partner GT No
Start date Yes
End date Yes
Within last Yes
Roamer Type No
Voice Protocol No For descriptions, refer to Table 11 on page 58.
Call Type No
Voice Error Code No

Widgets in the Voice connection establishment dashboard

Figure 18 on page 65 displays the Voice connection establishment dashboard.

F I GU R E 1 8 : V OI C E C ON N EC T I ON EST A B L I SH M EN T D A SH B OA R D
Table 14 on page 65 lists and describes the widgets available in the Voice connection establishment
dashboard.
T A B L E 1 4 : W I D GET S IN THE V OI C E C ON N EC T I ON EST A B L I SH M EN T D A SH B OA R D
Widget Description
Connection Displays region-wise (partner country, network, node) trend of ASR value and the count of
Establishment by total and successful calls.
Region
Connection Displays the trend of ASR value and the count of total and successful calls over time for the
Establishment by selected duration.
Time

Widget Description
Connection Displays the distribution of voice service error codes that are causing call failures and, in
Establishment by turn, resulting in reduced ASR values.
Cause Code For a list of voice service error codes supported by the RCEM application, refer to
"Supported voice service error codes" on page 60.
Connection Displays the trend of ASR values over time for the selected call types.
Establishment by The following call types are supported:
Call Type n Mobile Terminated
n Mobile Originated
Voice Connection Displays a detailed list of the top 20 partner networks with the maximum number of call
Establishment counts during the period that you select. It also displays the ASR values corresponding to
the successful calls that were answered.
The voice connection establishment table displays the following information:
Partner Network Name Name of the partner network for which the maximum
voice call count is present.
Roamer Type Type of roamer for which the maximum voice call count
is present.
present.
Total Call Count Number of voice calls that have occurred between the
host and partner networks.
Successful Call Count Number of calls that were answered.
Answer Seizure Ratio (%) ASR (in percentage value) of the partner network.
Voice connection retainability dashboard

The Voice connection retainability dashboard provides an analysis of the following information:
n Successful call completion: The dashboard displays this information in terms of the CCR KPI. CCR
expresses the relationship between successful calls and successfully established calls that are
intentionally released by the roamers.
n Average duration of call: The dashboard displays the trend in the average duration of international
voice calls that the roamers were involved in.
The dashboard also displays the failures observed during the voice call transactions and the effect of these
failures on the CCR and average call duration values. Analyzing the failures from multiple dimensions is
important to fix the failures. The Voice service retainability dashboard helps operators to analyze the failures
across the following dimensions:
n Region
n Time

n Error code
n Call type
roamers.
KPIs in the Voice connection retainability dashboard

n CCR: CCR is the ratio between successful calls and successfully established calls that were
intentionally released by the roamer.
n Average duration of call: Average time between the call answer message (ANM) and the call release
message (REL) in an international call transaction.
n Count of successful calls: Number of calls that were successfully answered.
n Count of intentionally released calls: Number of answered calls that were intentionally released.
Filters available in the Voice connection retainability

dashboard
Table 15 on page 67 lists and describes the filters available for generating the Voice connection retainability
dashboard.
T A B L E 1 5 : F I L T ER S F OR GEN ER A T I N G T H E V OI C E C ON N EC T I ON R ET A I N A B I L I T Y D A SH B OA R D
Host Name No For descriptions, refer to ": Filters for generating the MAP transaction failure
Partner Type Yes dashboard" on page 29.
Partner Country No
Partner Network No
Partner GT No
Start date Yes
End date Yes
Within last Yes
Roamer Type No
Voice Protocol No For descriptions, refer to ": Filters for generating the Voice service
Call Type No accessibility dashboard" on page 58.
Voice Error Code No

Widgets in the Voice connection retainability dashboard

Figure 19 on page 68 displays the Voice Connection Retainability dashboard.

F I GU R E 1 9 : V OI C E C ON N EC T I ON R ET A I N A B I L I T Y D A SH B OA R D
Table 16 on page 68 lists and describes the widgets available in the Voice connection retainability dashboard.
T A B L E 1 6 : W I D GET S IN THE V OI C E C ON N EC T I ON R ET A I N A B I L I T Y D A SH B OA R D
Widget Description
Connection Retainability Displays region-wise (partner country, network, node) trend of average duration of
by Region calls and CCR values.
The widget helps the operator to identify the regions where the calls have long
durations and where the CCR values are low.
Connection Retainability Displays the trend of average duration of calls and CCR values over time for the
by Time selected duration.
Connection Retainability Displays the distribution of voice connection error codes that cause the delay in

Widget Description
by Cause Code accessing voice service.

For a list of voice service error codes supported by the RCEM application, refer to
"Supported voice service error codes" on page 60.
Connection Retainability Displays the trend of average duration of calls and CCR values over time for the
by Call Type selected call types.
The following call types are supported:
n Mobile Terminated
n Mobile Originated
Voice Connection Displays a detailed list of the top 20 partner networks with the maximum number of
Retainability call counts during the period that you select.
The voice connection retainability table displays the following information:
Partner Network Name of the partner network for which the maximum
Name voice call count is present.
Roamer Type Type of roamer for which the maximum voice call count is
present.
present.
Successful Call Count Number of calls that were answered.
Intentionally Released Number of answered calls that were intentionally
Calls Count released by the roamers.
Average Call Duration Average call duration (in minutes) for the partner network.
(min)
Call Completion Ratio CCR (in percentage value) for the partner network.
(%)
Data session establishment dashboard

The Data session establishment dashboard provides an analysis of the failures observed during the process of
registering packet data sessions on the roaming links. Data session registrations can fail because of any of the
participating nodes and will impact the end service provided to the roamers. Analyzing the failures from multiple
dimensions is important to fix the failures. The data session establishment dashboard helps operators to
analyze these failures across the following dimensions:
n Region
n Error code
n APN
n Time
n GTP version

KPIs in the Data session establishment dashboard

n Total sessions: Number of packet data sessions that have occurred during the specified period.
n Failed sessions: Number of packet data sessions that have failed to establish during the specified
period.
n Failure rate (%): Packet data sessions that have failed to establish compared to the total data sessions
that have occurred for a particular dimension and specified duration.
The packet data session failure rate for a particular dimension is computed as follows:
Data sessions failed (grouped for a dimension) / Total sessions
Filters available in the Data session establishment

dashboard
Table 17 on page 70 lists and describes the filters available for generating the data session establishment
dashboard.
T A B L E 1 7 : F I L T ER S F OR GEN ER A T I N G T H E DATA SESSI ON EST A B L I SH M EN T D A SH B OA R D

Partner Type Yes
Partner Country No
Partner Network No
Start date Yes
End date Yes
Within last Yes
Roamer Type No
Partner IP No ---
Note: This field is applicable only if you select the Nodewise option in the
---
Address of a partner network’s IP for which you want to generate the
dashboard.
Specify the address (in string format) in the text box.
Initial Version No Version of the GTP protocol that is involved in the packet data sessions’
registration process.
n V1
n V2
n Version Handover
RAT Type No The Radio Access Technology (RAT) involved in the packet data sessions.

n GAN
n UTRAN
n EUTRAN
n GERAN
n HSPA Evolution
n WLAN
n Reserved
n Virtual
GTP Error Code No The GTP error codes for which you want to generate the dashboard.
From the drop-down list, select the required GTP error codes.
For a list of supported GTP error codes, refer to "Supported packet data error
APN No Name of the partner network’s APN for which you want to generate the
dashboard.
From the drop-down list, select the required APNs.

Widgets in the Data session establishment dashboard

Figure 20 on page 72 displays the Data session establishment dashboard.

F I GU R E 2 0 : D A T A SESSI ON EST A B L I SH M EN T D A SH B OA R D
Table 18 on page 72 lists and describes the widgets available in the Data session establishment dashboard.
T A B L E 1 8 : W I D GET S IN THE DATA SESSI ON EST A B L I SH M EN T D A SH B OA R D
Widget Description
Failure by Displays region-wise (partner country, network, node) trend of total packet data sessions, number
Region of failed sessions, and the sessions failure rate.
The widget displays the top 10 partner countries, networks, or IPs (depending on the criteria you
select) that have the most number of data session failures. The regions are sorted first on the
basis of total sessions and then by session failure rate.
The widget helps the operator to identify the regions where the packet data session failures are
high.
Failure by Displays the trend of total packet data sessions, number of failed sessions, and the sessions’
Time failure rate over time for the selected duration.

Widget Description
Failure by Displays the distribution of error codes that cause the data session registration failures that are
CauseCode observed.
For a list of the packet data error codes supported by the RCEM application, refer to "Supported
packet data error messages" on page 73.
Failure by Displays the distribution of data session registration failures across the APNs that were used by
APN roamers to create the sessions.
The widget displays the top 10 APNs where the maximum data session registration attempts
occurred and the failures in each of these APNs.
Failure by Displays the GTP version-wise trend of total packet data sessions, data session registration
Version failures, and the failure rate.
Failure by Displays the RAT-wise trend of total packet data sessions, data session registration failures, and
Start RAT the failure rate.

Supported packet data messages

The RCEM application monitors and collects transaction information for the following GTP messages to provide
reports to the deploying operator for packet data performance:
n Create PDP Context Request

n Create PDP Context Response
n Update PDP Context Request
n Update PDP Context Response
n Delete PDP Context Request
n Delete PDP Context Response
n GTPU Unitdata
n SGSN Context Request
n SGSN Context Response
n SGSN Context Acknowledge
Supported packet data error messages

Following is the list of packet data error messages that the RCEM application supports:
n V1 Request IMSI
n V1 Request IMEI
n V1 Request IMSI and IMEI
n V1 No identity needed
n V1 MS refuses (request)
n V1 MS is not GPRS responding (request)
n V1 For future use 6-48
n V1 Cause values reserved for GPRS charging protocol use 49-63
n V1 Request accepted
n New PDP type due to network preference

n New PDP type due to single address bearer only

n V1 Cause values reserved for GPRS charging protocol use 177-191
n V1 Non-existent
n V1 Invalid message format
n V1 IMSI not known
n V1 MS is GPRS detached
n V1 MS is not GPRS responding (reject)
n V1 MS refuses (reject)
n V1 For future use
n V1 No resources available
n V1 Service not supported
n V1 Mandatory IE incorrect
n V1 Mandatory IE missing
n V1 Optional IE incorrect
n V1 System failure
n V1 Roaming Restriction
n V1 P-TMSI signature mismatch
n V1 GPRS connection suspended
n V1 Authentication failure
n V1 User authentication failed
n V1 Context not found
n V1 All dynamic PDP addresses are occupied
n V1 No memory is available
n V1 Relocation failure
n V1 Unknown mandatory extension header
n V1 Semantic error in the TFT operation
n V1 Syntactic error in the TFT operation
n V1 Semantic errors in packet filter(s)
n V1 Syntactic errors in packet filter(s)
n V1 Missing or unknown APN
n V1 Unknown PDP address or PDP type
n V1 PDP context without TFT already activated
n V1 APN access denied no subscription
n V1 APN Restriction type incompatibility with currently active PDP Contexts
n V1 MS MBMS Capabilities Insufficient
n V1 Invalid Correlation-ID
n V1 MBMS Bearer Context Superseded
n V1 Bearer Control Mode violation
n V1 Collision with network initiated request

n V1 APN Congestion
n V1 Bearer handling not supported
n V1 Target access restricted for the subscriber
n V1 UE is temporarily not reachable due to power saving
n V1 Relocation failure due to NAS message redirection
n V1 Cause Values Reserved For Gprs Charging Protocol Use
n V2 Reserved Invalid IE
n V2 Reserved
n V2 Local Detach
n V2 Complete Detach
n V2 RAT changed from 3GPP to Non-3GPP
n V2 ISR deactivation
n V2 Error Indication recvd from RNC/eNodeB/S4-SGSN
n V2 IMSI Detach Only
n V2 Reactivation Requested
n V2 PDN reconnection to this APN disallowed
n V2 Access changed from Non-3GPP to 3GPP
n V2 PDN connection inactivity timer expires
n V2 PGW not responding
n V2 Network Failure
n V2 QoS parameter mismatch
n V2 For Future Use
n V2 Request accepted
n V2 Request accepted partially
n V2 New PDN type due to network preference
n V2 New PDN type due to single address bearer only
n V2 Context Not Found
n V2 Invalid Message Format
n V2 Version not supported by next peer
n V2 Invalid length
n V2 Service not supported
n V2 Mandatory IE incorrect
n V2 Mandatory IE missing
n V2 Not used 71
n V2 System failure
n V2 No resources available
n V2 Semantic error in the TFT operation
n V2 Syntactic error in the TFT operation

n V2 Semantic errors in packet filter(s)

n V2 Syntactic errors in packet filter(s)
n V2 Missing or unknown APN
n V2 Not used 79
n V2 GRE key not found
n V2 Relocation failure
n V2 Denied in RAT
n V2 Preferred PDN type not supported
n V2 All dynamic addresses are occupied
n V2 UE context without TFT already activated
n V2 Protocol type not supported
n V2 UE not responding
n V2 UE refuses
n V2 Service denied
n V2 Unable to page UE
n V2 No memory available
n V2 User authentication failed
n V2 APN access denied no subscription
n V2 Request rejected (reason not specified)
n V2 P-TMSI Signature mismatch
n V2 IMSI/IMEI not known
n V2 Semantic error in the TAD operation
n V2 Syntactic error in the TAD operation
n V2 Shall not be used
n V2 Remote peer not responding
n V2 Collision with network initiated request
n V2 Unable to page UE due to Suspension
n V2 Conditional IE missing
n V2 APN Restriction type Incompatible with currently active PDN connection
n V2 Invalid overall length of the trigg resp mesg and a piggybacked init mesg
n V2 Data forwarding not supported
n V2 Invalid reply from remote peer
n V2 Fallback to GTPv1
n V2 Invalid peer
n V2 Temporarily rejected due to handover procedure in progress
n V2 Modifications not limited to S1-U bearers
n V2 Request rejected for a PMIPv6
n V2 APN Congestion
n V2 Bearer handling not supported
n V2 UE already re-attached

n V2 Multiple PDN connections for a given APN not allowed

n V2 Target access restricted for the subscriber
n V2 For Future Use 118-239
n V2 For Future Use 240-255
Data session retention dashboard

The Data session retention dashboard provides an analysis of the failures that are responsible for the data
sessions to be dropped. The dashboard displays the trend in the drop rate of data sessions across multiple
dimensions. The data sessions can fail because of any of the participating nodes and will impact the end
service provided to the roamers. Analyzing the failures from multiple dimensions is important to fix the failures.
The Data session retention dashboard helps operators to analyze these failures across the following
dimensions:
n Region
n Error code
n APN
n Time
n GTP version
KPIs in the Data session retention dashboard

n Total sessions: Number of successful packet data sessions that have occurred during the specified
period.
n Total session drops: Number of packet data sessions that have been dropped without being
intentionally dropped by the roamers during the specified period.
n Drop rate (%): Relationship between packet data sessions that have been dropped (not intentionally by
the roamers) compared to the total successful data sessions that have occurred for a particular
dimension and specified duration.
The packet data drop rate for a particular dimension is computed as follows:
Data sessions dropped (not intentionally dropped by roamers), grouped for a dimension / Total
successful sessions
Filters available in the Data session retention dashboard

Table 19 on page 78 lists and describes the filters available for generating the Data session retention
dashboard.

T A B L E 1 9 : F I L T ER S F OR GEN ER A T I N G T H E DATA SESSI ON R ET EN T I ON D A SH B OA R D

Partner Type Yes
Partner Country No
Partner Network No
Start date Yes
End date Yes
Within last Yes
Roamer Type No
Partner IP No For descriptions, refer to Table 17 on page 70.
Initial Version No
RAT Type No
GTP Error Code No
APN No

Widgets in the Data session retention dashboard

Figure 21 on page 78 displays the Data session retention dashboard.
F I GU R E 2 1 : D A T A SESSI ON R ET EN T I ON D A SH B OA R D
Table 20 on page 79 lists and describes the widgets available in the data session retention dashboard.

T A B L E 2 0 : W I D GET S IN THE DATA SESSI ON R ET EN T I ON D A SH B OA R D
Widget Description
Data Session Displays region-wise (partner country, network, node) trend of total successful packet data
Retention sessions, number of dropped sessions, and the sessions drop rate (in percentage value).
Failure by The widget displays the top 10 partner countries, networks, or IPs (depending on the criteria
Region you select) that have the most number of session drops. The regions are sorted first on the
basis of total successful data sessions and then by session drop rate.
The widget helps the operator to identify the regions where the packet data session drops
are high.
Data Session Displays the trend of total successful packet data sessions, number of dropped sessions,
Retention and the sessions’ drop rate (in percentage value) over time for the selected duration.
Failure by Time
Data Session Displays the distribution of error codes that cause the data session drops.
Retention For a list of packet data error codes supported by the RCEM application, refer to "Supported
Failure by packet data error messages" on page 73.
CauseCode
Data Session Displays the distribution of data session drops across the APNs that were used by roamers
Retention to create the data sessions.
Failure by APN The widget displays the top 10 APNs where the maximum data session registrations were
successful and the session drops in each of these APNs.
Data Session Displays the GTP version-wise trend of total successful packet data sessions, number of
Retention dropped sessions, and the sessions’ drop rate (in percentage value).
Failure by
Version

Registration dashboards
The registration dashboards, Registration Latency and Registration Performance, provide country-wise
distribution of registration attempts, registration failures, and the percentage of stuck handsets observed across
different technologies (GSM, GPRS, LTE, GSM_GPRS, and LTE_GSM). It also displays CoS-wise and
registration reject code–wise distribution of the number of registration failures. The dashboard also provides
operators with information about the count of registrations categorized based on the following criteria:
n Time taken by mobile devices to register with a partner network

n Registrations in each of the technologies, such as GSM, GPRS, LTE, GSM_GPRS, and LTE_GSM.
The registration dashboards provide information about outbound roamer registration–related KPIs, such as
registration attempts, registration failures, and the percentage of stuck handsets. The registration KPIs are
based on roamer registration cycles in each of the technologies (GSM, GPRS, LTE, GSM_GPRS, and LTE_
GSM).
Registration latency
Registration latency is the time taken for one complete successful registration cycle. The registration time is not
calculated for failed registration cycles.

Registration cycle
The registration cycle process begins with the first UL message (corresponding to GSM, GPRS, LTE, or a
combination of GSM and GPRS, or LTE and GSM) from the roamers’ mobile device and ends when there is a
successful UL transaction. A delayed UL transaction might time out as well.
For example, consider an outbound roamer attempting to register with the following networks and status of each
registration attempt.
T A B L E 2 1 : S C EN A R I O F OR R EGI ST R A T I ON C YC L E
Registration attempt Time stamp Country Network VLR Registration status
1 T1 C1 N1 V1 Reject
9 T9 C1 N3 V3 Success

In the scenario displayed in the table, the registration cycle is completed at the ninth registration attempt,
because the registration is successful at the ninth attempt and the latency for this registration is the difference
between T9 and T1.
A registration attempt is considered failed if there are no further UL messages until timeout.
Table 22 on page 80 lists the scenarios of registration success and failures in different technologies.
T A B L E 2 2 : S C EN A R I OS F OR R EGI ST R A T I ON S A C R OSS T EC H N OL OGI ES
Scenario Registration success or failure
GSM attach on the following instances: Successful registration with domain GSM
n first UL only
n failed in multiple instances in one network but finally
successful in another network
GSM attach failed followed by a series of failures and no Failed registration on domain GSM only
followon GSM UL from the same or another network for a (handset stuck)
timeout
GPRS attach on the following instances: Successful registration with domain GPRS
n first UL only
n failed in multiple instances in one network but finally
successful in another network
GSM attach on first UL immediately followed by successful Successful registration with domain
GPRS attach GSM+GPRS
LTE ULR followed by CLR , and a series of ULR–CLR Successful registration with domain LTE only
messages followed by successful ULR on some network and no
followon CLR

Scenario Registration success or failure
LTE attach on preferred network successful followed by GSM Successful registration with domain
attach on same network LTE+GSM

The RCEM application creates MAP-related log files by using the GPRS and GSM UL transaction and
DIAMETER-related log files by using the ULR and CLR messages.
Note
The RCEM application does not identify and view registration cycles for inbound roamers because
the application does not have the visibility over transactions that occur with other networks.
n "Registration latency dashboard" on page 81

n "Registration performance dashboard" on page 87
Registration latency dashboard

The Registration latency dashboard displays region–, technology– (GSM, GPRS, LTE, GSM_GPRS, and LTE_
GSM) and CoS–wise distribution of number of successful registrations, grouped into different registration time
buckets for the selected duration. It also displays the number of successful registrations based on whether any
steering application was involved in the registrations.
n "Causes for registration latency" on page 81

n "When does a registration cycle close and the traces are generated again?" on page 82
n "Trace generation based on event sequence" on page 83
n "KPIs in the Registration latency dashboard" on page 84
n "Filters for generating the Registration latency dashboard" on page 84
n "Widgets in the Registration latency dashboard" on page 84
Causes f or r egist r at ion lat ency

Following are some of the reasons that cause registration latency:
n Network congestion.
n Delay in processing of registration-related messages by home network.
n Deployment of SoR solution, for example NTR application, in a home network.
n Handset-network frequency incompatibility issues. For example, handset that a roamer carries does not
support the frequency that the network offers.
n Manual mode in which the handset is set for network selection. For example, if you have set the handset
to manual network selection, then the handset would not automatically search for networks when the
handset fails to register with a given network.
What is SoR
Steering of Roaming (SoR) is a solution that influences the choice of networks for roamers when roaming

Benefits of using SoR
Following are some of the reasons why a telecom operator performs SoR:
n Saves cost for roamers by redirecting roamers to roaming networks that offer lower tariffs for voice and
data services.
n Saves cost for home operators by redirecting roamers to networks that offer competitive tariffs in roaming
agreements.
n Redirects roamers to networks that offer good quality of network coverage and improve QoS to roamers.
n Improves roaming experience.
SoR implementation scenario
n Consider an operator, operator a, whose subscribers roam in the US. Operator a intends to deploy an
SoR solution in its network.
n Operator a has roaming agreements with a few operators in the US, for example operator b and operator
c.
n Based on the roaming agreements with both operators b and c, operator a has to pay more Inter-
operator tariff (IOT) to operator b for the services that operator a's roamers use when roaming in network
b compared to IOT that operator a has to pay to operator c for services that operator a's roamers use
when roaming in network c.
n Consequently, operator a prefers operator c over operator b for the services that operator a's roamers
must use when they roam in the US.
n Therefore, operator a deploys SoR in its network and ensures that its roamers use services of operator c
when they roam in the US.
n As a result, operator a saves additional cost that the operator would have incurred if its roamers had
used services of network b.
When does a r egist r at ion cycle close and t he t r aces

ar e gener at ed again?
The following table describes when traces are generated:
Event Event description
Registration time expired Subsequent transactions are not received despite the failure of previous
transactions.
Technology changed The currently registered technology is LTE+GSM or LTE only while the next
transaction is a GPRS UL message.
The currently registered technology is GSM+GPRS or GPRS only while the next
transaction is a ULR message.
Country changed The next transaction received from a different country.
Maximum UL messages Threshold for maximum number of UL messages in transaction is breached.
attempted
As described in the aforementioned table, regardless of whether the current transaction fails, both current and
next transaction for a registration cycle is logged.

Note
The RCEM application measures the threshold (maximum count of UL messages in a transaction)
by using the max.ul.attempts parameter (default value: 160).
The Registration Handler class stores the events for a configurable duration. You can modify the
duration by using the reg.cycle.interval parameter (default value: 2 (in minutes)) of the
fsmapp.properties under the [RIS] section
Tr ace gener at ion based on event sequence

Table 23 on page 83 describes the sequence of events and the appropriate event-specific trace that the RCEM
application generates. The RCEM application generates the trace based on the cached transactions.
T A B L E 2 3 : E VEN T SEQU EN C E A N D T R A C E
Event sequence Trace that the RCEM application generates
GSM UL message successful on N1 (preferred network) GSM only

GSM UL message attached on N1 (preferred network) GSM+GPRS
successfully followed by a GPRS UL message that was
successful as well
GSM UL message successfully attached on N1 (non- GSM only
preferred network), roamer leaves N1 and attempts on
attach on N2 and then N3.
GSM UL message successfully attached on N1 (non- GSM
preferred network), roamer leaves N1 and attempts on GPRS
attach on N2 and then N3, successfully registers with N3 GSM+GPRS
for GPRS.
LTE ULR message successful on N1 (preferred network) LTE only
LTE ULR message attached on N1 (preferred network) LTE+GSM
successfully followed by a GSM UL message that was
successful as well
LTE ULR message attached on N1 (non-preferred LTE only
network) successfully followed by a CLR message, and
then attaches on N2 (preferred)
LTE ULR message attached on N1 (non-preferred LTE+GSM
network) successfully followed by a CLR message, and
then attaches on N2 (preferred) followed by a
GSM UL message
GSM attach attempt on N1 (rejected), then attempts to GSM only
register with N2 (rejected), and then the handset gets
stuck by the error code. Subsequently, no UL message
observed for the same roamer.
LTE ULR registration attempt on N1 followed by a CLR LTE only
message, then attempts to register (LTE ULR) with N2
followed by a CLR message, and then the handset gets
stuck by the error code (in the CLR message).
Subsequently, no ULR message observed for the same
roamer.
message, then attempts to register (GSM UL) with N1 and GSM only

Event sequence Trace that the RCEM application generates
is allowed. (LTE registration fails. So, downgrades to 3G

technology of the same network)
message, then attempts to register (GSM UL) with N2 and GSM only
is allowed. (LTE registration fails. So, downgrades to 3G
technology of the different network)
KPI s in t he Regist r at ion lat ency dashboar d

The following KPI is computed and displayed in the widgets:
n Registration Count: Number of successful registrations observed by roamers’ mobile devices during
the specified period.
Filt er s f or gener at ing t he Regist r at ion lat ency

dashboard
Table 24 on page 84 lists and describes the filters available for generating the Registration latency dashboard.
T A B L E 2 4 : F I L T ER S F OR GEN ER A T I N G T H E R EGI ST R A T I ON L A T EN C Y D A SH B OA R D

Partner Type No
Partner Network No
Partner Country No
Partner GT No
Start date Yes
End date Yes
Within last Yes
Class of Subscriber No The CoS for which you want to generate the dashboard.
From the drop-down list, select the required CoS.
Registration Domain No Type of technology or protocol involved in the registrations for which you
want to generate the dashboard.
n GSM
n GPRS
n LTE
n GSM_GPRS
n LTE_GPRS
From the drop-down list, select the required registration domain.

Widget s in t he Regist r at ion lat ency dashboar d

Figure 22 on page 85 displays the Registration latency dashboard.

F I GU R E 2 2 : R EGI ST R A T I ON L A T EN C Y D A SH B OA R D
Table 25 on page 85 lists and describes the widgets available in the registration latency dashboard.
T A B L E 2 5 : W I D GET S IN THE R EGI ST R A T I ON L A T EN C Y D A SH B OA R D
Widget Description
Registration Displays the distribution of number of successful registrations grouped into different registration
latency time buckets for the selected duration.
Buckets Following time buckets are displayed in the widget:
n < 1 second

Widget Description
n2 to 30 seconds
n31-60 seconds
n 1 to 2 minutes
n > 2 minutes
Registration Displays country-wise distribution of number of successful registrations for the selected duration.
by Region In this view, when you click a particular country, the widget drills-down to display network-wise
distribution of registration count. It displays the information for all networks present in the
selected country. Also, the dashboard applies the selected country filter to the other widgets to
display information for the selected country.
You can further drill down to the node level distribution by clicking a network in this widget. Here,
the widget displays the information for all nodes present in the selected country and network
combination. Also, the dashboard applies the selected network filter to the other widgets to
display information for the selected country and network combination.
Registration Displays technology-wise (GSM, GPRS, LTE, GSM_GPRS, and LTE_GSM) distribution of
by number of successful registrations.
Technology
Registration Displays the trend (every hour, month, day, 15 minutes) of number of successful registrations.
Trend
Registration Displays CoS-wise distribution of number of successful registrations for the selected duration.
by CoS
Registration Displays the distribution of the number of successful registrations with respect to any steering
by Steering application that was involved in the registrations.
Attempted Following scenarios are available:
n Without Steering: “Number of registrations without any steering attempts during
registrations.”
n With Steering: “Number of registrations involving any steering attempts during
registrations.”
Registration Displays the daily list of successful registrations that have occurred in the preceding 15 days and
(last 15 the average registration latency corresponding to the country, technology, CoS, and time bucket
days) combination.
The table displays the following information:
Columns in
Description
the widget
Date The date on which the registrations occurred.
Country Name of the country where the registrations occurred.
Technology Type of technology in which the registrations occurred.
CoS Name of the CoS to which the subscribers belong, for whom the registrations
occurred.
Bucket The registration time bucket into which the registrations are grouped.
Registration Number of successful registrations for the corresponding date, country,
Count technology, CoS, and time bucket combination.
Average Average registration latency of all successful registrations that have occurred
Registration corresponding to the date, country, technology, CoS, and time bucket
Latency combination.


Registration performance dashboard

The Registration performance dashboard displays technology-wise (GSM, GPRS, and LTE) and region–wise
distribution of a number of failed registrations for the selected duration. It also displays CoS-wise and
registration reject code–wise distribution of the number of failed registrations.
KPI s in t he Regist r at ion per f or m ance dashboar d

n Total registration attempts: Number of registration attempts by roamers’ mobile devices during the
specified period.
n Failed registrations: Number of registration attempts that failed to register with a partner network during
the specified period.
n Failure rate (%): Relationship between the total number of registration attempts and the number of
failed registrations that have occurred during the specified period.
The registration failure rate for a particular dimension is computed as follows:
[Number of failed registrations / Total registration attempts] * 100
Filt er s f or gener at ing t he Regist r at ion per f or m ance

dashboard
Table 26 on page 87 lists and describes the filters available for generating the Registration performance
dashboard.
T A B L E 2 6 : F I L T ER S F OR GEN ER A T I N G T H E R EGI ST R A T I ON PER F OR M A N C E D A SH B OA R D

Partner Type No
Partner Network No
Partner Country No
Partner GT No
Start date Yes
End date Yes
Within last Yes
Registration Domain No Type of technology or protocol involved in the registrations for which
you want to generate the dashboard.
n GSM
n GPRS
n LTE
n GSM_GPRS
n LTE_GPRS
From the drop-down list, select the required registration domain.

Reject code No The registration reject codes for which you want to generate the

dashboard.
From the drop-down list, select the required reject codes.
For a list of supported reject codes, refer to the following topics:
n "Supported MAP error messages" on page 35
n "Supported Diameter error messages" on page 46
Widget s in t he Regist r at ion per f or m ance dashboar d

Figure 23 on page 89 displays the Registration performance dashboard.

F I GU R E 2 3 : R EGI ST R A T I ON PER F OR M A N C E D A SH B OA R D
Table 27 on page 89 lists and describes the widgets available in the Registration performance dashboard.
T A B L E 2 7 : W I D GET S IN THE R EGI ST R A T I ON PER F OR M A N C E D A SH B OA R D
Widget Description
Registration Displays country–wise distribution of number of failed registrations for the selected duration.
Failure By
Region
Registration Displays the trend in registration failures for the selected duration.

Widget Description
Failure Trend
Registration Displays technology–wise (GSM, GPRS, LTE, GSM+GPRS, and LTE+GSM) distribution of
Failure By number of failed registrations.
Technology
Registration Displays CoS–wise distribution of number of failed registrations for the selected duration.
Failure By CoS
REGISTRATION Displays the reasons for which the registration has failed.
FAILURE ---
REASONS Important: In this widget, the RCEM application displays a short text that depicts the reason
for which a registration attempt has failed. This short text is not the standard reject code.
---
Note: The complete reasons' list includes numerous short texts. However, the
RCEM application displays only the top ten reasons in this widget. The following table
displays short texts and the associated descriptions for a few reasons.
REASONS Description
Attempted Upgrade to 4G on Determines that roamer's 2G/3G registration attempt

different network has failed and the roamer has attempted to register with
a different 4G network.
Attempted Upgrade to 4G on same Determines that roamer's 2G/3G registration attempt
network has failed and the roamer has attempted to register with
the 4G technology of the same network.
Downgraded to 3G on different Determines that the roamer's 4G registration attempt
the 3G technology of a different network.
Downgraded to 3G on same Determines that the roamer's 4G registration attempt
the 3G technology of the same network.
Switched to another country Determines that the roamer has switched to a different
country.
Switched country with DIA event Determines that the roamer has attempted to register
with a an LTE network in another country while the
preceding registration attempt with a LTE network in the
previous country has failed because of a CLR
message.
Top Displays the daily list of failed registrations that have occurred corresponding to the country,
Registration technology, CoS, and reject code combination.
Failures The table displays the following information:
Columns in
Description
the widget
Country Name of the country where the registration failures occurred.
Registration Type of technology in which the registration failures occurred.
Domain
CoS Name of the CoS to which the subscribers belong, for whom the registration
failures occurred.
Last Reject The reject code that was observed in the registration failures.
Code
Failed Number of failed registration attempts for the corresponding date, country,
Registrations technology, CoS, and reject code combination.


GRQ dashboard
The GRQ dashboard displays adherence of a roaming partner to agreed-on roaming SLAs (configured) against
pre-defined KPIs. The dashboard presents a view on how the roaming partner is performing and its compliance
to the GRQ SLAs. The dashboard provides information about the number of times the KPIs have been breached
by each of the partner networks. It also provides the trend of the frequently breached KPIs and also displays the
alerts that were raised when the thresholds for the GRQ SLAs was breached. The dashboard displays all this
information with respect to the service type you select: voice, SMS, data, or registration.
KPIs in the GRQ dashboard

Table 28 on page 91 lists and describes the KPIs available in the GRQ dashboard.
TA B L E 2 8 : K P IS IN THE GR Q D A SH B OA R D
KPI Description
PDP Context Cut- Percentage of the probability that the PDP context is deactivated unintentionally by the
off (%) roamers.
[Number of PDP context deactivations not initiated by the user] / [Total number
of successfully activated PDP Contexts] x 100
---
Note: If the error indication received is followed by Destination Point Code (DPC), that
context is considered as not terminated intentionally by user.
---
PDP Context Delay Time between successful MAP PDP Context Activation Request and Response
(ms) messages.
PDP GoodPut (%) Ratio between the volume of useful data by the specified duration.
It is the average number of bytes exchanged per second, corrected by filtering
retransmitted packets for GTP sessions based on GTP-U traffic, that is, PDP Throughput –
PDP Packet Loss Count.
PDP Throughput Average packet volume (in bytes per second) exchanged in all GTP sessions based on
(%) GTP-U traffic.
Here, the duration considered is the time period in which data usage was actually
observed, that is, RCEM filters out the silent period—where no data usage is observed.
PDP Packet Loss Number of bytes lost during data transmission in GTP sessions based on TCP
Count (bytes per retransmission mechanisms. This KPI is also calculated based on GTP-U data traffic.
second)
PDP Average time taken to retransmit the lost data packets.
Retransmission
time (ms)
PDP Session Time between the Delete PDP Request and the Create PDP Response messages.
Duration (seconds)
PDP Session Ratio between successful MAP PDP Context activations and attempts.
Success Rate (%)
PDP LTE Average time taken to retransmit the lost LTE data packets.
Retransmission
time (ms)
PDP LTE Average packet volume (in bytes per second) exchanged in all LTE sessions.
Throughput (%) Here, the duration considered is the time period in which data usage was actually

KPI Description
PDP LTE Goodput Ratio between the volume of useful data by the specified duration.
(%) It is the average number of bytes exchanged per second, corrected by filtering
retransmitted packets for LTE sessions, that is, PDP LTE Throughput – PDP LTE Packet
Loss Count.
PDP LTE Packet Number of bytes lost during data transmission in LTE sessions based on Diameter
Loss Count (bytes retransmission mechanisms.
per second)
GPRS UL Delay Time (in milliseconds) between the GPRS UL request message and the GPRS UL ACK
(ms) message.
This is applicable only for successful transactions.
GPRS UL Success Ratio between successful GPRS UL attempts and the total number of GPRS UL attempts.
Rate (%) [Number of successful GPRS UL attempts] / [Total number of GPRS UL attempts] x
100
GSM UL Delay (ms) Time (in milliseconds) between the MAP UL request message and the MAP UL ACK
message.
This is applicable only for successful transactions.
GSM UL Success Ratio between successful GSM UL attempts and the total number of GSM UL attempts.
Rate (%) [Number of successful GSM UL attempts] / [Total number of GSM UL attempts] x 100
Average Length of Average Length of Call Mobile Originated. The time between reception of call answer
Call MO (seconds) ISUP ANM and call release (ISUP REL) for MO calls.
Average Length of Average Length of Call Mobile Terminated. The time between reception of call answer
Call MT (seconds) ISUP ANM and call release (ISUP REL) for MT calls.
Call completion Ratio between successful calls and successfully established calls that are intentionally
ratio MO (%) released by the subscriber for MO calls.
Call completion Ratio between successful calls and successfully established calls that are intentionally
ratio MT (%) released by the subscriber for MT calls.
Call setup success Ratio between successful calls (reception of ISUP ANM message) and attempts (ISUP
rate MO (%) IAM message) for MO calls.
Call setup success Ratio between successful calls (reception of ISUP ANM message) and attempts (ISUP
rate MT (%) IAM message) for MT calls.
Network Ratio between successful calls (reception of ISUP ACM message) and attempts (ISUP
Effectiveness Ratio IAM message) for MO calls.
MO (%)
Network Ratio between successful calls (reception of ISUP ACM message) and attempts (ISUP
Effectiveness Ratio IAM message) for MT calls.
MT (%)
Post Dial Delay MO Time between sending of complete address information and receipt of call set-up
(ms) notification for MO calls.
Difference of time between the IAM and ACM messages for MO calls.
Post Dial Delay MT Time between sending of complete address information and receipt of call set-up
(ms) notification for MT calls.
Difference of time between the IAM and ACM messages for MT calls.
MO SMS DELAY Average latency for the MO SMS transactions. Latency is calculated as the time between
(ms) SMS SUBMIT and ACK messages.
MO SMS SA (%) Service Accessibility for Mobile Originated SMS. The SA SMS MO is the ratio between
successful SMS-SUBMIT and attempts.
MT SMS DELAY Average latency for Mobile Terminated SMS transactions. Latency is calculated as the
(ms) time duration between successful SMS DELIVER and ACK messages.
MT SMS SA (%) Service Accessibility for Mobile Terminated SMS. The SA SMS MT is the ratio between
the number of successful SMS messages delivered and the number of SMS message
delivery attempts.
SMS End to End Average latency between the MAP-FWD-SM (SMS-Submit) operation and the MAP-

KPI Description
DELAY (ms) FWD-SM (SMS-Deliver) operation acknowledgment for an SMS message.

% GRQ Percentage of registration KPI breaches for a particular country. The KPI is calculated as
Registration KPI follows:
breaches by [Total number of registration KPI breaches for the country in selected days] /
country [Selected number of days x Number of networks configured in the selected country
x Number of registration KPIs] x 100
% GRQ Data KPI Percentage of packet data KPI breaches for a particular country. The KPI is calculated as
breaches by follows:
country [Total number of data KPI breaches for the country in selected days] / [Selected
number of days x Number of networks configured in the selected country x Number
of data KPIs] x 100
% GRQ SMS KPI Percentage of SMS KPI breaches for a particular country. The KPI is calculated as
country [Total number of SMS KPI breaches for the country in selected days] / [Selected
number of days x Number of networks configured in the selected country x Number
of SMS KPIs] x 100
% GRQ Voice KPI Percentage of voice KPI breaches for a particular country. The KPI is calculated as
country [Total number of voice KPI breaches for the country in selected days] /
[Selected number of days x Number of networks configured in the selected country
x Number of voice KPIs] x 100
Total SLA breaches Total number of KPI breaches per KPI category, that is, data, voice, SMS, and
by service registration.
Top 5 frequently Top five KPIs based on the total number of breaches observed over the selected time
breached KPIs period.
LTE Registration: Ratio between successful LTE ULR attempts and the total number of LTE ULR attempts.
Location Update [Number of successful LTE ULR messages] / [Total number of LTE ULR attempts]
Success Rate x100
LTE Registration: Time (in milliseconds) between UL Request (ULR) and UL Answer (ULA) messages.
Location Update This is applicable only for successful transactions.
Delay
LTE Data: Ratio between successful Create Session Requests and attempts.
Activation success
rate
LTE Data: Time between successful Create Session Request and Create session Response
Activation Delay or messages.
Set-up Time
LTE Data: Cut-Off The probability that an LTE data session is deactivated without being deactivated
Ratio intentionally by the user.
[Number of LTE Data sessions not terminated by the users] / [Number of
successfully activated LTE data sessions] x 100
---
Note: If error indication is received followed by the Delete Session message, then that
session will be considered an unintentional release.
---
LTE Data: Average Time between the Create Session Response and Delete Session Request messages.
session time

Filters for generating the GRQ dashboard

Table 29 on page 94 lists and describes the filters available for generating the GRQ dashboard.

T A B L E 2 9 : F I L T ER S F OR GEN ER A T I N G T H E GR Q D A SH B OA R D
Host Name No For descriptions, refer Table 4 on page 29.

Partner Country No
Partner Network No
Start date Yes
End date Yes
Within last Yes
Roamer Type No
Service No Type of service for which you want to generate the GRQ dashboard.
n Registration
n Data
n Voice
n SMS
From the drop-down list, select the required service type.

KPI No The KPIs for which you want to generate the GRQ dashboard.
From the drop-down list, select the required KPIs.

Widgets in the GRQ dashboard

Figure 24 on page 95 displays the GRQ dashboard.

F I GU R E 2 4 : GR Q D A SH B OA R D
Table 30 on page 95 lists and describes the widgets available in the GRQ dashboard.
T A B L E 3 0 : W I D GET S IN THE GR Q D A SH B OA R D
Widget Description
Geographical Displays the distribution of GRQ KPI breaches (in percentage value) at the country level.
Distribution of
You can click any country to generate the Networkwise KPI performance dashboard. For
Breaches more information, refer to "Networkwise KPI Performance" on page 96.
Networkwise Displays the top 10 networks with maximum threshold breaches of KPIs for the selected
Breaches service type during the specified period.
Frequently Displays distribution of the KPIs that are frequently breached, specific to the specified service
Breached KPIs type and duration.

Widget Description
Recent Alerts Displays a list of the top 10 alerts that were raised whenever a KPI threshold was breached. It
also displays the actual KPI value when the KPI was breached. The dashboard displays this
information for the specified service type and duration.
Other dashboards generated from the Geographical Distribution of Breaches widget.
Networkwise This dashboard is generated in a new tab when you click a country in the world map of the
KPI Geographical Distribution of Breaches widget.
Performance This dashboard displays information in the following widgets:
n Networkwise KPI Performance: “Displays average values of the KPIs for all networks
in the selected duration.”
n Networkwise KPI Alarms: “Displays the count of breaches for each of the KPIs in the
selected duration.”
You can click any KPI corresponding to a network to generate the KPI trend dashboard. For
more information, refer to "KPI Trend" on page 96.
KPI Trend This dashboard is generated in a new tab when you click a KPI corresponding to a network in
the Networkwise KPI performance dashboard.
Displays the trend in the actual KPI value of a particular network for the specified duration. It
also displays the threshold value for the KPI as a reference in the graph.

VIP performance dashboard

The VIP performance dashboard displays the issues faced by a specific group of subscribers over a period of
time. The dashboard provides this data to the operator categorized by the service type (registration, voice, SMS,
data) in which the issues occurred. The operators can drill down to the network- and IMSI-levels to view details
about the issues faced. The dashboard also displays the most recent alerts that the RCEM application sends
based on the thresholds that the operator configures for a CoS and the available KPIs. The VIP performance
dashboard helps operators to analyze the failures across the following dimensions:
n Nature of issue: Dashboard displays distribution of failures across KPI groups (registration, call, SMS,
and data) for different types of technologies where the issues have occurred.
n CoS
Prerequisites for generating the VIP performance

dashboard
Before generating the VIP dashboard, you must configure the CoS for which you want to view the data, and
configure the thresholds for each of the available KPIs for the CoSes that you configure.
1. Configure the VIP subscribers in the CoS Configuration page of the RCEM GUI.
For information about configuring VIP subscribers, refer to "Managing classes of subscribers" on page
24.
2. Define thresholds for various failure and latency KPIs for each of the CoSes in the CoS Threshold
Configuration section of the RCEM GUI.
You can also define the interval for which these KPIs must be monitored.
For information about configuring CoS thresholds, refer to "Configuring CoS thresholds" on page 166.

KPIs in the VIP performance dashboard

Following is the KPI that is computed and displayed in the widgets:
n Total failures: Number of failures that have occurred with respect to the services offered to a specific
group of customers during the specified period.
Filters for generating the VIP performance dashboard

Table 31 on page 97 lists and describes the filters available for generating the VIP performance dashboard.
T A B L E 3 1 : F I L T ER S F OR GEN ER A T I N G T H E V IP PER F OR M A N C E D A SH B OA R D
Host Name No For description s, refer to Table 4 on page 29.

Partner Type No
Partner Country No
Partner Network No
Start date Yes
End date Yes
Within last Yes
IMSI No IMSI of the subscriber for which you want to generate the dashboard.
MSISDN No MSISDN of the subscriber for which you want to generate the
dashboard.
KPI Group No The KPI group for which you want to generate the GRQ dashboard.
n Registration
n Data
n Call
n SMS
From the drop-down list, select the required KPI group.

Widgets in the VIP performance dashboard

Figure 25 on page 98 displays the VIP performance dashboard.

F I GU R E 2 5 : V IP PER F OR M A N C E D A SH B OA R D
Table 32 on page 98 lists and describes the widgets available in the VIP performance dashboard.
T A B L E 3 2 : W I D GET S IN THE V IP PER F OR M A N C E D A SH B OA R D
Widget Description
Incidents by CoS Displays CoS-wise distribution (in percentage value) of the issues faced in the selected
duration.
Incidents by Displays the list of incidents that have occurred in the selected duration with the
Subscriber following information:
Columns in the
Description
widget
IMSI IMSI of the subscriber who faced the issue recorded in the alert.
MSISDN MSISDN of the subscriber who faced the issue recorded in the
alert.

Widget Description
Columns in the
Description
widget
Class of Subscriber Name of the CoS to which the subscriber belongs.
Incidents Number of incidents that the subscriber has faced.
Geographies Displays country-wise (and subsequent drill-down to network-wise) distribution (in

percentage value) of the issues faced in the selected duration.
Nature of Issue Displays a hierarchical widget that contains a distribution of the number of issues,
service type, and the type of issues faced by the subscribers belonging to the CoSes
configured.
The widget displays details in the following circles:
n Inner circle: Displays the total issues.
n Middle circle: Displays the following service types to which the issues belong:
n Registration
n Call
n SMS
n Data
n Outer circle: Displays the following issue types that have occurred:
n 3G and LTE Authentication
n 3G and LTE Registration
n Call: 3G Voice
n SMS: 3G Failed
n Data: LTE Failed, 3G Data, and LTE Data

Trend Displays the trend in terms of the total number of issues that have occurred for the
selected CoS and duration.
Most Recent Displays a list (in the tabular format) of the most recent alerts that were sent in the
Incidents preceding one hour whenever a CoS threshold was breached. It also displays the
actual KPI value when the KPI was breached. The dashboard displays this information
for the specified service type and duration.
The table displays the following information:
Columns in
Description
the widget
Alert Date The date on which the alert was sent.
IMSI IMSI of the subscriber who faced the issue recorded in the alert.
Class of Name of the CoS to which the subscriber belongs.
Subscriber
Partner Name of the partner network where the threshold breach occurred.
Incident Type Name of the KPI that was breached.
Show Trace Click Trace to view the details of the incident.
The details are displayed in the Trace page from where you can
generate the pcap file for further analysis of the issue.


Voice usage dashboard

The Voice usage dashboard displays the distribution and trend of successful voice calls and the average
duration of successful voice calls for the filters selected. The Voice usage dashboard helps operators to analyze
these trends across the following dimensions:
n Destination
n CoS
KPIs in the Voice usage dashboard

n Average call duration: Average time between the call answer message (ANM) and the call release
message (REL) in the answered calls.
n Successful call count: Number of calls that were answered.
Filters for generating the Voice usage dashboard

Table 33 on page 100 lists and describes the filters available for generating the Voice usage dashboard.
T A B L E 3 3 : F I L T ER S F OR GEN ER A T I N G T H E V OI C E U SA GE D A SH B OA R D

Partner Type No
Partner Country No
Partner Network No
Roamer Type No
Start date Yes
End date Yes
Within last Yes
Class of No The CoS for which you want to generate the dashboard.
Voice Protocol No For descriptions, refer to Table 11 on page 58.
Call Type No
Destination Type No Specifies the type of roaming capability for which you want to generate the
dashboard.
n Short Code: “Calls to short codes by subscribers.”
n National: “National calls by subscribers.”
n International: “International calls by subscribers.”
n Back To Home: “Calls made to subscribers in their home network.”
n Unknown
n NA

Widgets in the Voice usage dashboard

Figure 26 on page 101 displays the Voice usage dashboard.
F I GU R E 2 6 : V OI C E U SA GE D A SH B OA R D
Table 34 on page 101 lists and describes the widgets available in the Voice usage dashboard.
T A B L E 3 4 : W I D GET S IN THE V OI C E U SA GE D A SH B OA R D
Widget Description
Usage Displays country-wise (and drill-down to network-wise) distribution of the number of successful
distribution calls and the average duration of successful calls in the selected duration.
Usage Displays the trend (monthly, daily, and hourly) of the number of successful calls and the average
trend duration of successful calls in the selected duration.
Usage by Displays the destination-wise distribution (in percentage value) of the average duration of
Destination successful voice calls.
The widget displays information for the following destinations:
n National: “Average duration of successful national calls made by subscribers.”
n International: “Average duration of successful international calls made by subscribers.”
n Short Code: “Average duration of successful short code calls made by subscribers.”
n Back To Home: “Average duration of calls made to subscribers in their home network.”
n Unknown: “Average duration of unknown calls.”
n NA
Usage by Displays the CoS-wise distribution (in percentage value) of the average duration of successful
CoS voice calls.


Data usage dashboard

The Data usage dashboard displays the distribution and trend of the duration of sessions and the average data
usage in all successfully established packet data sessions. The Data usage dashboard helps operators to
analyze these trends across the following dimensions:
n Region
n RAT type
n CoS
KPIs in the Data usage dashboard

n Average session duration (in min): Average time between the Delete PDP Request and the Create
PDP Response messages.
n Average session usage (in MB): Average amount of data (in MB) used by subscribers (as observed in
the GTP-C and –U messages) in all successfully established packet data sessions.
Filters for generating the Data usage dashboard

Table 35 on page 102 lists and describes the filters available for generating the Data usage dashboard.
T A B L E 3 5 : F I L T ER S F OR GEN ER A T I N G T H E DATA U SA GE D A SH B OA R D

Partner Type No
Partner Country No
Partner Network No
Roamer Type No
Start date Yes
End date Yes
Within last Yes
RAT Type No The Radio Access Technology (RAT) involved in the packet data
sessions.
n GAN
n UTRAN
n EUTRAN
n GERAN
n HSPA Evolution
n WLAN
n Reserved
n Virtual

Widgets in the Data usage dashboard

Figure 27 on page 103 displays the Data usage dashboard.
F I GU R E 2 7 : D A T A U SA GE D A SH B OA R D
Table 36 on page 103 lists and describes the widgets available in the Data usage dashboard.
T A B L E 3 6 : W I D GET S IN THE DATA U SA GE D A SH B OA R D
Widget Description
Session Usage Displays the trend (monthly, daily, and hourly) of total and average data usage of
Trend successfully established data sessions in the selected duration.
Session Usage Displays country-wise (and drill-down to network-wise) distribution of total and average data
Distribution usage of successfully established data sessions in the selected duration.
Session Displays the trend (monthly, daily, and hourly) of total and average session duration of
Duration Trend successfully established data sessions in the selected duration.
Session Displays country-wise (and drill-down to network-wise) distribution of total and average
Duration session duration of successfully established data sessions in the selected duration.
Distribution
Session Usage Displays the RAT-wise distribution (in percentage value) of total and average data usage of

Widget Description
by RAT successfully established data sessions.

Session Displays the RAT-wise distribution (in percentage value) of the total and average session
Duration by duration of successfully established data sessions.
RAT

SMS usage dashboard

The SMS usage dashboard displays the distribution and trend of the number of SMS messages sent by
subscribers. The SMS usage dashboard helps operators to analyze these trends across the following
dimensions:
n Region
n SMS type
n CoS
KPIs in the SMS usage dashboard

Following is the KPI that is computed and displayed in the widgets:
n SMS count: Total number of SMS messages sent by roamers in the selected duration.
Filters for generating the SMS usage dashboard

Table 37 on page 105 lists and describes the filters available for generating the SMS usage dashboard.

T A B L E 3 7 : F I L T ER S F OR GEN ER A T I N G T H E SMS U SA GE D A SH B OA R D

Partner No
Type
Partner No
Country
Partner No
Network
Partner GT No
Alliance No
Roamer No
Type
Time Yes
Granularity
Start date Yes
End date Yes
Within last Yes
Class of No The CoS for which you want to generate the dashboard.
SMS No Status of the SMS messages for which you want to generate the dashboard. The
Status following options are available:
n Success: If you select this option, the RCEM application generates the
dashboard for SMS messages for which the transaction has been completed
successfully over the MAP layer.
n Failure: If you select this option, the RCEM application generates the
dashboard for SMS messages for which the transaction has not been
completed successfully over the MAP layer.
From the drop-down list, select an appropriate option.
SMS Type No The type of SMS for which you want to generate the dashboard.
n Mobile Originated (MO)
n Mobile Terminated (MT)
Widgets in the SMS usage dashboard

Figure 28 on page 106 displays the SMS Usage dashboard.

F I GU R E 2 8 : S M S U SA GE D A SH B OA R D
Table 38 on page 106 lists and describes the widgets available in the SMS usage dashboard.
T A B L E 3 8 : W I D GET S IN THE SMS U SA GE D A SH B OA R D
Widget Description
SMS Usage Displays country-wise (and drill-down to network-wise) distribution of the number of SMS
Duration messages sent in the selected duration.
SMS Usage Displays the trend (every hour, month, day, 15 minutes) of the number of SMS messages
Trend sent in the selected duration.
SMS Usage by Displays the CoS-wise distribution (in percentage value) of the number of SMS messages
CoS sent.
SMS Usage by Displays the SMS type-wise distribution (in percentage value) of the number of SMS
SMS Type messages sent.

Unique roamers dashboard

The Unique roamers dashboard provides details about the number of roamers who have successfully
registered for the voice or data service for a given country during the specified duration. The dashboard also
provides details about the distribution of unique roamers across the networks in a country and the trend in the
number of unique roamers over a period of time.

The number of unique roamers is calculated based on the registrations across voice and data services. If a
roamer registers for the first time in a network for either the voice or data service, then that roamer is counted as
a unique roamer for that network for that day.
Unique roamer count is individually maintained for daily and monthly statistics. Here, one subscriber might stay
in the network for more than a day and therefore, will be counted for each day for daily count of unique roamers.
While for monthly, the same roamer will be counted only once for that network. Therefore, the sum of the daily
count of unique roamers for a particular month will not be equal to the monthly count of unique roamers for that
month.
The dashboard provides the details of unique roamers across the following dimensions:
n Region: Distribution of unique roamers across partner networks and countries

n Time: Trend of unique roamers over a period
KPIs in the Unique roamers dashboard

n Voice: Number of roamers who have successfully registered for voice services in a partner network
n Data: Number of roamers who have registered for only GPRS or LTE data services in a partner network
n Voice and data: Number of roamers who have registered for both voice and GPRS or LTE data services
Filters for generating the Unique roamers dashboard

Following are the filters available for generating the Diameter failure dashboard:
n Host name
n Class of Subscriber
n Start date and end date
n Last x days, weeks, months, quarters, or years
n Periodicity of data to be displayed
For descriptions of the these filters, refer to Table 4 on page 29.
Widgets in the Unique roamers dashboard

Figure 29 on page 108 displays the Unique roamers dashboard.

F I GU R E 2 9 : U N I QU E R OA M ER S D A SH B OA R D
Table 39 on page 108 lists and describes the widgets available in the Unique roamers dashboard.
T A B L E 3 9 : W I D GET S IN THE U N I QU E R OA M ER S D A SH B OA R D
Widget Description
Roamer Displays the country-wise distribution of the number of unique roamers in a world map.
Distribution The world map is color-coded based on the number of unique roamers who have successfully
registered during the specified duration.
Clicking a country in this widget applies the country in the other widgets in this dashboard to
display data for the selected country.
Region Displays network-wise distribution of the number of unique roamers.
Distribution
Roamer Displays the message-wise trend of total Diameter transactions and the transaction failure rate.
Trend The widget displays the message types with the maximum failure rate.
For a list of Diameter messages that the RCEM application considers for generating the
dashboard, refer to "Supported Diameter messages and message groups" on page 46.


Roamer trip dashboard

The Roamer trip dashboard provides information about a roamer’s usage of voice, SMS, and data (GPRS and
LTE) services during a roaming trip.
Whenever a roamer visits a country other than the home country and registers with a partner network, a roaming
trip is started. The roamer might stay in the same network or move and register with other partner networks
(within the same country). For as long as the roamer stays within the same country, all data will be considered
under a single trip (the current trip), which will remain open.
However, if the roamer moves to a partner network in another country, it is considered as a new trip, and
subsequently, the trip in the previous country is considered closed.
The following trips are considered in the Roamer trip dashboard:
n Global-level trip: A trip that a roamer undertakes, starting from the home country and travels to multiple
countries before returning to the home country.
n Country-level trip: A trip that a roamer undertakes starting from one partner network in a country and
travels to multiple networks within the same country.
n Network-level trip: A trip that a roamer undertakes within one partner network.

KPIs in the Roamer trip dashboard

Table 40 on page 109 lists and describes the KPIs that are computed and displayed in the widgets.
TA B L E 4 0 : K P IS IN THE R OA M ER T R I P D A SH B OA R D
KPI Description
Trip start time Date and time (in the DD MMM, YYYY HH:MM:SS 24-hour format) when the roamer started the
trip in a partner network.
It is the time when the first UL message is initiated in a network.
Trip end time Date and time (in the DD MMM, YYYY HH:MM:SS 24-hour format) when the roamer ended the
trip in a partner network.
It is the time when a CL message is initiated for a network.
Time Spent (days) Duration (in days) that the roamer spent in a partner network during the trip.
First Country Name of the country where the roamer started the trip.
This is based on the first UL message initiated in a network when the subscriber started
roaming.
Exit Country Country from where the roamer exited before entering the current country.
This is based on the CL message initiated for a network of one country and a subsequent
UL message in a network of another country.
Call Attempts Total number of calls attempted (including successful and failed attempts) by the roamer
in the specified region and time.
Successful Number of call attempts that resulted in an answer signal.
Dropped Number of calls that were dropped, that is, calls that were terminated due to network
issues.
MOU Average usage (in minutes) of voice calls.

KPI Description
SMS Sent Number of SMS messages that the roamer sends during a trip.
Data Session Number of packet data sessions that have occurred during the trip.
Attempts
Failures Number of packet data sessions that have failed to establish during the trip.
Duration (min) Average duration (in minutes) for which the data sessions are active during the trip.
This time is computed as the difference in time between the Delete PDP Request and the
Create PDP Response messages.
Usage (MB) Average amount of data (in MB) used by subscribers in all successfully established
packet data sessions during the trip.
3G Throughput Average packet volume (in Megabits per second) exchanged in all GTP sessions during
(Mbps) the trip.
4G Throughput Average packet volume (in Megabits per second) exchanged in all LTE sessions during
(Mbps) the trip.
Time taken for first Duration (in minutes) the roamer took to initiate the first call after the trip started.
call (min)
Time taken for first Duration (in minutes) the roamer took to initiate the first SMS message after the trip
SMS (min) started.
Time taken for first Duration (in minutes) the roamer took to initiate the first packet data session after the trip
data (min) started.

Filters for generating the Roamer trip dashboard

Following are the filters available for generating the Roamer trip dashboard:
n IMSI of the subscriber

n MSISDN of the subscriber
n Partner country and network
For descriptions of the these filters, refer to Table 4 on page 29.
Widgets in the Roamer trip dashboard

Figure 30 on page 111 displays the Roamer trip dashboard.

F I GU R E 3 0 : R OA M ER T R I P D A SH B OA R D
Table 41 on page 111 lists and describes the widgets available in the Roamer trip dashboard.
T A B L E 4 1 : W I D GET S IN THE R OA M ER T R I P D A SH B OA R D
Widget Description
Current Displays the current location of the roamer in a country.

Location
Countries Displays a list of countries that the roamer has visited in the roaming trip. This widget also displays
Visited the total duration (in days) that the roamer has spent in each of the countries.
Clicking a country applies the country filter to the following widgets and displays the network-level
information about the roamer’s usage.

Widget Description
Stay Displays the duration (in hours) a roamer has stayed in all the networks that the roamer registers
Duration during the trip.
(hrs) If you click a particular country in the Countries Visited widget, this widget displays details about
the networks within that country.
Usage Displays network-wise average usage and quality details of the services used by the roamer in a
and particular trip. For a detailed description of the columns in this widget, refer to Table 40 on page
Quality 109.
Roaming Displays details of all the previous trips undertaken by the roamer. It displays the daily average
History usage and quality details of the services used by the roamer during all the previous trips. For a
detailed description of the columns in this widget, refer to Table 40 on page 109.

Interconnect SMS dashboard

The Interconnect SMS dashboard provides information about the international SMS transactions occurred
between by local subscribers, inbound and outbound roamers. The dashboard also displays the distribution of
SMS messages by region (country, network), interconnect carriers, and subscriber type. The operator can also
view the distribution of SMS messages based on the errors that have occurred during the SMS transactions and
analyze the errors that are causing the failures.
KPIs in the Interconnect SMS dashboard

TA B L E 4 2 : K P IS IN THE I N T ER C ON N EC T S M S D A SH B OA R D
KPI Description
SMS count Number of SMS messages sent by the subscribers in the selected duration.
SRI-SM or MT-FSM count Number of SRI-SM and MT-FSM messages observed in the selected duration.
Successful SMS Number of the SMS messages that were successfully delivered to the
messages subscribers.
Failed SMS messages Number of the SMS messages that were not delivered to the subscribers.

Filters for generating the Interconnect SMS dashboard

Table 43 on page 113 lists and describes the filters available for generating the Interconnect SMS dashboard.

T A B L E 4 3 : F I L T ER S F OR GEN ER A T I N G T H E I N T ER C ON N EC T S M S D A SH B OA R D

Partner Type No
Partner Country No
Partner Network No
Partner Node No
Address
Time Granularity No
Start date No
End date No
Within last No
Subscriber Type No Type of subscriber for which you want to generate the dashboard.
n Local: “Dashboard is generated for local subscribers of the host
network.”
n Inbound: “Dashboard is generated for inbound roamers from the
selected regions.”
n Outbound: “Dashboard is generated for outbound roamers to the
From the drop-down list, select the required subscriber type.
SMS Direction No Direction of the SMS messages for generating the dashboard.
n Incoming: “Dashboard is generated for all SMS messages received
by the subscribers (based on the Subscriber Type filter.)”
n Outgoing: “Dashboard is generated for all SMS messages sent by
the subscribers (based on the Subscriber Type filter.)”
From the drop-down list, select the required direction of SMS messages.

Widgets in the Interconnect SMS dashboard

Figure 31 on page 114 displays the Interconnect SMS dashboard.

F I GU R E 3 1 : I N T ER C ON N EC T S M S D A SH B OA R D
Table 44 on page 114 lists and describes the widgets available in the Interconnect SMS dashboard.
T A B L E 4 4 : W I D GET S IN THE I N T ER C ON N EC T S M S D A SH B OA R D
Widget Description
SMS Trend Displays the trend in the SMS message transactions for the selected subscriber
types in the selected duration.
SMS Distribution by Displays the region-wise distribution of SMS message transactions for the selected
Region subscriber types in the selected duration.
SRI-SM/MT-FSM Displays the region-wise distribution of the count of SRI-SM and MT-FSM messages

Widget Description
Distribution by Region that have occurred in the SMS message transactions.

SMS Distribution by Displays the distribution of the count of incoming and outgoing SMS messages for
Direction the selected duration.
SMS Distribution by Displays the interconnect carrier-wise distribution of international SMS messages.
Carrier This widget provides information about the capacity utilization of the interconnect
carriers for SMS messages.
SMS Distribution by Displays the distribution of SMS message count for the subscriber types (local,
Subscriber Type inroamer, outroamer).
SMS Distribution by Displays the distribution of error messages that are observed in the SMS message
Error Codes transactions.

Advanced packet data dashboard

The Advanced packet data dashboard provides information about the quality of the packet data service that the
partner networks offer to the roamers. The dashboard displays the region-wise distribution of average
throughput, average session duration, and average session usage. It also displays the count of packet data
sessions in predefined buckets (for throughput, session duration, and session usage). This dashboard includes
data for both 3G and LTE packet data sessions. The dashboard supports the following drill-down option:
n Region-based: Country à Network
KPIs in the Advanced packet data dashboard

TA B L E 4 5 : K P IS IN THE A D VA N C ED PA C K ET D A T A D A SH B OA R D
KPI Description
Average Average packet volume (in megabits per second) exchanged in all GTP and LTE data
Throughput sessions based on GTP-U traffic.
(Mbps) Here, the duration considered is the time period in which data usage was actually
Average Session Average data (in MB) used by roamers in successfully established packet data sessions.
Usage (MB)
Average Session Average time (in minutes) between the Delete PDP Request and the Create PDP Response
Duration (min) messages for successfully established packet data sessions.
Session Count Number of packet data sessions observed in each of the corresponding predefined buckets
displayed in the widgets.

Filters for generating the Advanced packet data dashboard

Table 46 on page 116 lists and describes the filters available for generating the Advanced packet data
dashboard:

T A B L E 4 6 : F I L T ER S F OR GEN ER A T I N G T H E A D VA N C ED PA C K ET D A T A D A SH B OA R D

Partner Type No
Partner Network No
Roamer Type No
Class of Subscriber No
Time Granularity No
Start date No
End date No
Within last No
Start RAT No The type of RAT involved in the packet data sessions.
n GAN
n UTRAN
n EUTRAN
n GERAN
n HSPA Evolution
n WLAN
n Reserved
n Virtual
Widgets in the Advanced packet data dashboard

Figure 32 on page 117 displays the Advanced packet data dashboard.

F I GU R E 3 2 : A D VA N C ED PA C K ET D A T A D A SH B OA R D
Table 47 on page 117 lists and describes the widgets available in the Advanced packet data dashboard.
T A B L E 4 7 : W I D GET S IN THE A D VA N C ED PA C K ET D A T A D A SH B OA R D
Widget Description
Data Region-wise (country and corresponding drill-down to networks) distribution of average

Throughput throughput (in Mbps) observed in all data sessions during the selected period.
Distribution
Session Usage Region-wise (country and corresponding drill-down to networks) distribution of average data
Distribution usage (in MB) observed in all data sessions during the selected period.
Session Region-wise (country and corresponding drill-down to networks) distribution of average
Duration duration of sessions (in minutes) observed in all data sessions during the selected period.
Distribution
Data Distribution of the number of sessions grouped by average throughput buckets. The data is
Throughput by grouped and displayed in the following throughput buckets:
Bucket n 0–1 Mbps
n 2–30 Mbps
n 31–60 Mbps
n 61–120 Mbps

Widget Description
n >121 Mbps
Session Usage Distribution of the number of sessions grouped by average data usage buckets. The data is
by Bucket grouped and displayed in the following data usage buckets:
n 0–1 MB
n 2–30 MB
n 31–60 MB
n 61–120 MB
n >121 MB
Session Distribution of the number of sessions grouped by average session duration buckets. The
Duration by data is grouped and displayed in the following session duration buckets:
Bucket n 0–1 mins
n 2–30 mins
n 31–60 mins
n 61–120 mins
n >121 mins
DPI dashboard
The DPI dashboard provides detailed URL- and protocol-wise information about the following data:
n Number of times the URLs were accessed by the roamers

n Amount of data used and the average throughput when the URLs were accessed
n Number of times the URLs (grouped by the protocol that was involved while accessing them) were
accessed
n Amount of data used and the average throughput for all URLs accessed based on the protocol involved
while accessing the URLs
KPIs in the DPI dashboard

TA B L E 4 8 : K P IS IN THE DPI D A SH B OA R D
KPI Description
(Mbps) Here, the duration considered is the time period in which data usage was actually observed,
that is, RCEM filters out the silent period—where no data usage is observed.
Total Session Total data (in MB) used by roamers in successfully established packet data sessions. This
Usage (MB) information is displayed, grouped by the following criteria:
n URLs accessed
n Protocol involved in accessing the URLs

Access Count Based on the widgets, the access count displays the following information:

KPI Description
n Usage by URL widget: “Number of times roamers accessed the URLs.”

n Usage by Protocol widget: “Number of times the protocols were used to access the
URLs.”

Filters for generating the DPI dashboard

Table 49 on page 119 lists and describes the filters available for generating the DPI dashboard:
T A B L E 4 9 : F I L T ER S F OR GEN ER A T I N G T H E DPI D A SH B OA R D

Partner Type No
Partner Network No
Partner Country No
Roamer Type No
Time Granularity No
Start date No
End date No
Within last No
Protocol No The protocol for which you want to generate the dashboard.
n Domain Name Service
n File Transfer Protocol
n Hypertext Transfer Protocol
n Secure HTTP
n ICMP
n IP
n NTP
n SSL
n Transfer Control Protocol
n Unknown
n User Datagram Protocol
From the drop-down list, select the name of the required protocol.
URL No The specific URL for which you want to generate the dashboard.
From the drop-down list, select the name of the required URL.

Widgets in the DPI dashboard

Figure 33 on page 120 displays the DPI dashboard.

F I GU R E 3 3 : D P I D A SH B OA R D
Table 50 on page 120 lists and describes the widgets available in the DPI dashboard.
T A B L E 5 0 : W I D GET S IN THE DPI D A SH B OA R D
Widget Description
Usage by URL URL-wise distribution of average data usage (in MB) observed in all data
sessions during the selected period.
Throughput by URL URL-wise distribution of average throughput (in Mbps) observed in all data
Usage by Protocol Protocol-wise distribution of average data usage (in MB) observed in all data
sessions and URLs accessed during the selected period.
Throughput by Protocol Protocol-wise distribution of average throughput (in Mbps) observed in all data
sessions and URLs accessed during the selected period.

DPI by technology dashboard

The DPI by technology dashboard provides detailed RAT-wise distribution of the amount of data used by
subscribers and the trend in the average throughput in the packet data sessions.
n RAT-wise information about the amount of data used and average throughput in the sessions

n Region-wise distribution of amount of data used and the trend of average throughput for all URLs
accessed
KPIs in the DPI by technology dashboard

TA B L E 5 1 : K P IS IN THE DPI B Y T EC H N OL OGY D A SH B OA R D
KPI Description
(Mbps) Here, the duration considered is the time period in which data usage was actually observed,
that is, RCEM filters out the silent period—where no data usage is observed.
Total Session Total data (in MB) used by roamers in successfully established packet data sessions. This
Usage (MB) information is displayed, grouped by the following criteria:
n URLs accessed
n Protocol involved in accessing the URLs
Filters for generating the DPI by technology dashboard

Table 52 on page 121 lists and describes the filters available for generating the DPI by technology dashboard:
T A B L E 5 2 : F I L T ER S F OR GEN ER A T I N G T H E DPI B Y T EC H N OL OGY D A SH B OA R D

Partner Type No
Partner Network No
Partner Country No
Roamer Type No
Time Granularity No
Start date No
End date No
Within last No

Widgets in the DPI by technology dashboard

Figure 34 on page 122 displays the DPI by technology dashboard.

F I GU R E 3 4 : D P I B Y T EC H N OL OGY D A SH B OA R D
Table 53 on page 122 lists and describes the widgets available in the DPI dashboard.
T A B L E 5 3 : W I D GET S IN THE DPI B Y T EC H N OL OGY D A SH B OA R D
Widget Description
RAT-Wise Usage RAT-wise distribution (in percentage) of total data usage observed in all data
RAT-Wise Throughput RAT-wise trend of average throughput (in Mbps) observed in all data sessions
during the selected period.
Usage Distribution Region-wise (country and corresponding drill-down to networks) distribution of total
data usage (in MB) observed in all data sessions and average throughput (in Mbps)
during the selected period.
Usage Trend Trend in the total data usage (in MB) and average throughput (in Mbps) observed in
all data sessions during the selected period.

SCCP carrier dashboard

The SCCP carrier dashboard provides signaling carrier-wise information about Message Signal Unit (MSU)
transactions that have occurred during the selected period. It displays the trend and distribution of MSUs, and
the average latency of signaling messages that are exchanged between the host and partner networks. It also

displays error messages that have occurred in the transactions. The dashboard helps an operator to assess the
traffic on the signaling SS7 links and displays the trend in data to help configure the network accordingly.
KPIs in the SCCP carrier dashboard

TA B L E 5 4 : K P IS IN THE SCCP C A R R I ER D A SH B OA R D
KPI Description
Total Incoming MSU Number of MSUs received by the partner networks in the selected period.
Total Outgoing MSU Number of MSUs sent to the partner networks in the selected period.
Average Transaction Latency The average latency (in milliseconds) of the MAP messages that are
(ms) exchanged.

Filters for generating the SCCP carrier dashboard

Table 55 on page 123 lists and describes the filters available for generating the SCCP carrier dashboard:
T A B L E 5 5 : F I L T ER S F OR GEN ER A T I N G T H E SCCP C A R R I ER D A SH B OA R D

Partner Network No
Roamer Type
Time Granularity No
Start date No
End date No
Within last No
Message Type No The MAP messages for which you want to generate the dashboard.
From the drop-down list, select the required MAP messages.
For a list of supported MAP messages, refer to "Supported MAP messages
and message groups" on page 34.
Error Code No The SCCP error codes for which you want to generate the dashboard.
The following SCCP error codes are available:
n Success Message
n No translation for an address of such nature
n No translation for this specific address
n Subsystem Congestion
n Subsystem Failure
n Unequipped User
n MTP Failure
n Network Congestion
n Unqualified
n Error in message transport (Note)
n Error in local processing (Note)

n Destination cannot perform reassembly (Note)

n SCCP Failure
n Hop Counter Violation
n Segmentation Not Supported
n Segmentation Failure
n Reserved for International Use
n Reserved for National Networks
n Invalid ISNI routing request (1)
n Unauthorized message
n Message Incompatibility
n Cannot perform ISNI constrained routing (1)
n Redundant ISNI constrained routing information (1)
n Unable to perform ISNI identification (1)
n Undefined
From the drop-down list, select the required SCCP error codes.

Widgets in the SCCP carrier dashboard

Figure 35 on page 125 displays the SCCP carrier dashboard.

F I GU R E 3 5 : S C C P C A R R I ER D A SH B OA R D

Table 56 on page 125 lists and describes the widgets available in the SCCP carrier dashboard.
T A B L E 5 6 : W I D GET S IN THE SCCP C A R R I ER D A SH B OA R D
Widget Description
Transactions by Carrier Carrier-wise percentage share of the transactions that have occurred.
MSU Distribution Partner network-wise distribution of incoming and outgoing MSUs that are
exchanged with the host network.
UDTS Errors Percentage distribution of the UDTS errors that are observed in the MAP
transactions.
Average Transaction MAP message-wise distribution of the average latency that is observed.
Latency(ms)
MSU Trend Displays the trend in MSU transactions that have occurred between the host
network and all partner networks.


Session handover analysis dashboard

The Session handover analysis dashboard provides information about packet data sessions where a handover
between 3G and 4G have occurred. It displays information about the duration of sessions in each of the
technologies (2G only, 3G only, 4G only, and 3G to 4G) in which packet data sessions have occurred. This
dashboard helps the deploying operator to obtain the reliability of 4G coverage in a network.
KPIs in the Session handover analysis dashboard

TA B L E 5 7 : K P IS IN THE S ESSI ON H A N D OVER A N A L YSI S D A SH B OA R D
KPI Description
Session Usage (MB) Average data (in MB) used by roamers in data sessions of different technologies.
Session Duration (min) Average time (in minutes) spent by roamers in data sessions of different
technologies.
Session Count Number of packet data sessions in the following scenarios:
n Sessions in the same technology and no handover has occurred.
n Sessions where handover between different technologies has occurred.
Filters for generating the Session handover analysis

dashboard
Table 58 on page 126 lists and describes the filters available for generating the Session handover analysis
dashboard:
T A B L E 5 8 : F I L T ER S F OR GEN ER A T I N G T H E S ESSI ON H A N D OVER A N A L YSI S D A SH B OA R D

Partner Type No
Partner Network No
Roamer Type
Time Granularity No
Start date No
End date No
Within last No

Widgets in the Session handover analysis dashboard

Figure 36 on page 127 displays the Session handover analysis dashboard.

F I GU R E 3 6 : S ESSI ON H A N D OVER A N A L YSI S D A SH B OA R D
Table 59 on page 127 lists and describes the widgets available in the Session handover analysis dashboard.
T A B L E 5 9 : W I D GET S IN THE S ESSI ON H A N D OVER A N A L YSI S D A SH B OA R D
Widget Description
Session Count by Technology-wise (2G only, 3G only, 4G only, and 3G to 4G) percentage share
Handover distribution of the data sessions that are observed during the selected period.
Session Count Region-wise (country and corresponding drill-down to networks) distribution of number
Distribution of data observed during the selected period.
Session Duration Technology-wise percentage share distribution of data sessions observed during the
(min) by Technology selected period.
Session Usage (MB) Technology-wise percentage share distribution of average data usage (in MB)
by Technology observed in data sessions during the selected period.

First time registration dashboard

The First time registration dashboard provides information about the trend in the number of first-time
registrations observed in the country. The first-time registration is considered when the roamer starts roaming in
the country for the first time. The registration can be either in the 3G or the 4G technology. In cases where

registrations in both technologies (3G and 4G) occur for the same roamer, those registrations are included in
the 4G registrations count.
KPIs in the First time registration dashboard

TA B L E 6 0 : K P IS IN THE F I R ST T I M E R EGI ST R A T I ON D A SH B OA R D
KPI Description
3G Registration count Number of first-time 3G registrations that have occurred.

4G Registration count Number of first-time 4G registrations that have occurred. This count also includes a
combined registration where 4G and 3G registrations occur at the same time for a
roamer.

Filters for generating the First time registration dashboard

Table 61 on page 128 lists and describes the filters available for generating the First time registration
dashboard:
T A B L E 6 1 : F I L T ER S F OR GEN ER A T I N G T H E F I R ST T I M E R EGI ST R A T I ON D A SH B OA R D

Partner Type No
Partner Network No
Roamer Type No
Time Granularity No
Start date No
End date No
Within last No

Widgets in the First time registration dashboard

Figure 37 on page 129 displays the First time registration dashboard.

F I GU R E 3 7 : F I R ST T I M E R EGI ST R A T I ON D A SH B OA R D
Table 62 on page 129 lists and describes the widgets available in the First time registration dashboard.
T A B L E 6 2 : W I D GET S IN THE F I R ST T I M E R EGI ST R A T I ON D A SH B OA R D
Widget Description
Registration Displays the trend in the first-time 3G and 4G registrations that have occurred during the
Count 3G/4G selected period.
Trend
Registration Region-wise (country and corresponding drill-down to networks) distribution of first-time
Count Distribution 3G and 4G registrations that have occurred during the selected period.

NQS dashboard
The Network Quality Score (NQS) dashboard provides a unique insight into the performance of a network by
monitoring key KPIs for each of the outbound roamers. The RCEM application monitors the KPIs across different
services for each of the roamers, to understand the experience of that roamer. This individual roamers’ data is
aggregated to analyze the performance of a network by computing the network quality score for that network.
The subscribers are grouped in to different NQS buckets and the NQS dashboard helps the operator to identify
the least performing networks.
Computing network quality score


n "KPIs used in the NQS dashboard" on page 130

n "Network quality score" on page 132
n "Weighted network quality score" on page 133
KPIs used in the NQS dashboard

Following are the KPIs that are used to compute the network quality score
TA B L E 6 3 : K P IS F OR N QS
KPIs-related to KPIs Description
Registration Registration success Determines the successful registration of

the subscriber's handset with a visited
network.
Registration latency Time taken for a mobile device to register
with a network. There are two types of
registration latency:
n Subscriber level: Time taken for
subscriber in registering with a
network. This time includes the
duration between the registration
attempt through a mobile device
and the successful registration with
a network. If the subscriber is
redirected to several networks
during a registration cycle, the
entire duration (from the
registration attempts that failed to
the successful registration with the
network that SoR application
allowed) is included in the
subscriber-level latency.
Important: The RCEM application
uses the high.reg.latency
parameter to measure latency. The
default value is 300 seconds. If the
time taken for a subscriber to
register with a network is more than
300 seconds, for example 350, the
RCEM application considers
registration latency and computes
the network quality score, as shown
in "Parameters that the RCEM
application uses to compute
network quality score" on page
132.
n Network level: Duration between
the instance when the UL message
was generated and the instance
when the UL ACK message was
received.
Voice Voice successful establishment Instance when the called party receives
the call.

KPIs-related to KPIs Description
PDD (post dial delay) Duration between the time when a

subscriber dials a number and the time
when the caller hears the ringing sound.
Voice successful release by Instance when the called party releases
subscriber the call.
Data session Data session successful Determines the instance when the
establishment GTP session is successfully established
and the subscriber can access data.
Data session successful release by Determines the instance when the
subscriber subscriber closes a data session. This
instance also includes the scenario in
which the subscriber enters an area where
network coverage is lost and the data
session is closed.
Data throughput Occurrence when the data used in a
session is lesser than a threshold value.
The RCEM application uses the configured
value of threshold parameters to identify
the breach. For information about the
threshold parameters, refer to the
examples demonstrated in the
"Parameters that the RCEM application
uses to compute network quality score" on
page 132 section.
SMS Successful SMS Determines the completion of all tasks that
include the flow of message from
subscribers handset to SMSC and from
SMSC to the receiver's handset.
The network quality score is computed based on the number of KPI breaches that have occurred for a particular
service event, compared to the KPIs that are encountered in that event.
Thresholds are configured for each of the aforementioned KPIs, and the same are monitored for any breaches
for each of the services configured. Based on the performance of the KPIs in the respective event (voice, SMS,
registration, and data session), a score is computed for the service.
If all the KPIs in a service event are breached, then the score for the service is computed as 0. However, if no
KPIs are beached, the score is computed as 1.
Consider the following examples for computing the NQS:
n Voice call event 1: Consider a voice call that is successfully established, the call setup time is within the
threshold, and the call is successfully released by the roamer. In this case, three KPIs were encountered
and no KPI was breached. Therefore, the NQS for this voice call event is computed as 1.
n Voice call event 2: Consider a voice call event that was not established. In this case, only one KPI was
encountered and it was breached. Therefore, the NQS for this voice call event would be 0.
n Data session event: Consider a data session that was successfully established and released by the
roamer. However, the data throughput was found to be less than the threshold and hence, one KPI was
breached out of three that were encountered in the event. Therefore, the NQS for this data session event
would be computed as 2/3 (=0.6).
All the scores that are computed for different services are aggregated to obtain the overall score (or experience)
of a roamer. Based on this overall score, roamers are categorized into the following buckets of NQS scores:

n 0.0-0.2
n 0.2-0.4
n 0.4-0.6
n 0.6-0.8
n 0.8-1.0
Note
If you have configured the weight-related parameters to obtain weighted score, the
RCEM application aggregates the overall score (of experience) of a roamer by including the
weighted score, as well. For information about how a weighted score is computed, refer to the
examples in "Weighted network quality score" on page 133.
The categorization of roamers in to the listed scores helps an operator to identify the networks where the
roamers are worst affected. This also helps the operator to identify the service or segment that is worst
affected.
Network quality score

n "Parameters that the RCEM application uses to compute network quality score" on page 132
n "Using an example, demonstrate scenarios that generate network quality score" on page 132
Par am et er s t hat t he RCEM applicat ion uses t o

com put e net wor k qualit y scor e
To compute network quality score, the RCEM application uses values that are configured in the following
threshold parameters of the fsmapp.properties file:
For call score
n cpdd_threshold
For data score
n nqs.data.lowThroughput.threshold.3G
n nqs.data.lowThroughput.threshold.LTE
For registration score
n reg.latency.3G
n reg.latency.LTE
Using an exam ple, dem onst r at e scenar ios t hat

gener at e net wor k qualit y scor e
Table 64 on page 133 demonstrates how the RCEM application computes the aggregated network quality
score while the parameter values are configured, as shown:

n cpdd_threshold=5000 (in milliseconds)

n nqs.data.lowThroughput.threshold.LTE=5 (in mega bits per second)
n reg.latency.3G=30 (in seconds)
n high.reg.latency=300 (in seconds)
T A B L E 6 4 : N ET W OR K QU A L I T Y SC OR ES
NQS
No Satisfactory (Total
Whether Satisfactory Success
Scenario No latency? Latency throughput applicable
successful? throughput? flag
flag flag flags / Total
flags)
Subscriber Yes No NA 1 0 NA 1/2=0.5
registers with a
network after
350 seconds
3G call Yes Yes NA 1 1 NA 2/2=1
established in (established
25 seconds within
threshold )
3G call not No NA NA 0 NA NA 0/0=0
established.
LTE data Yes Yes No 1 1 0 2/3=0.6
session (data
successfully session
completed. established
However, the within
throughput was threshold)
1 MBps.
The RCEM application aggregates the individual NQS to compute the final NQS.
Therefore, NQS=
0.5+1+0+0.6
---------------- =0.5
4
Weighted network quality score

The RCEM application supports weighted scores, as well, in the NQS and CRM dashboards.
n "Paramers that the RCEM application uses to compute weighted score" on page 134
n "For weighted score, what logic you must use while configuring parameters' values " on page 134
n "Using various scenarios, demonstrate how RCEM application generates weighted score" on page 135

Par am er s t hat t he RCEM applicat ion uses t o com put e

weight ed scor e
The RCEM application generates appropriate weighted score based on the logical values configured in the
following parameters of the fsmapp.properties file in the [RIS] section:
For call score
n wgt_avg_callSuccess
n wgt_avg_callDropped
n wgt_avg_pdd
n cpdd_threshold
For data score
n wgt_avg_sessionAttemptSuccess
n wgt_avg_lowThroughput
n wgt_avg_sessionDropped
n nqs.data.lowThroughput.threshold.3G
n nqs.data.lowThroughput.threshold.LTE
For registration score
n wgt_avg_regStatus
n wgt_avg_regLatency
n reg.latency.3G
n reg.latency. LTE
Note
The default value of all weight-related parameters is 1. You must modify the values based on
requirements, as described in the "For weighted score, what logic you must use while configuring
parameters' values " on page 134 section.
For weight ed scor e, what logic you m ust use while

conf igur ing par am et er s' values
n As operator, you must provide integer value to each parameter based on the parameter's significance
that reflects roamer's experience.
n For example, for registration score, you might configure a higher value to successful registration (wgt_
avg_regLatency) when compared to the value you configure for registration latency (wgt_avg_
regLatency).
n A sample configuration for registration score could be:
n wgt_avg_regStatus=80
n wgt_avg_regLatency=20

Using var ious scenar ios, dem onst r at e how

RCEM applicat ion gener at es weight ed scor e
Example for registration score
Table 64 on page 133 demonstrates how the RCEM application computes aggregated weighted scores for LTE
registration while the parameter values are configured, as shown:
n wgt_avg_regStatus=80
n wgt_avg_regLatency=20
n reg.latency.LTE=30
T A B L E 6 5 : W EI GH T ED SC OR ES F OR LTE R EGI ST R A T I ON
Weighted score
Weight 1 * Applicable
Whether Latency flag+...Weight n* Applicable
Scenarios Success flag Latency flag
successful? occurrence? flag n)
-----------------------------------------
---------
Weight 1+...Weight n
LTE No Not applicable 0 0 0
registration
attempt failed
after three
seconds
LTE Yes Yes 1 0 1*80+0*20
registration (Registration -------------- = 0.8
attempt occurred after 80+20
successful 35
after 3.5 milliseconds)
seconds
LTE Yes Yes 1 1 1*80+1*20
registration (Registration -------------- = 1
attempt occurred after 80+20
successful 10
after one milliseconds)
second.
Aggregated weighted score for registration=
0+0.8+1
---------- =0.6
3
Example for 3G data score
Table 64 on page 133 demonstrates how the RCEM application computes aggregated weighted scores for 3G
data session while the parameter values are configured, as shown:

n wgt_avg_sessionAttemptSuccess=60
n wgt_avg_lowThroughput=15
n wgt_avg_sessionDropped=25
n nqs.data.lowThroughput.threshold.3G=1 (in mega bits per seconds)
T A B L E 6 6 : W EI GH T ED SC OR ES F OR 3G D A T A SESSI ON
Weighted score
Weight
1*Applicable
No
Whether Satisfactory Success Session Satisfactory flag+...Weight
Scenarios session
successful? throughput flag drop flag throughput n*Applicable flag n)
dropped? ----------------------------
----------------------
Weight
1+...weight n
3G No NA NA 0 NA NA 0
registration
attempt
failed after
five
seconds
3G Yes Yes No 1 1 0 60*1+15*0+25*1
registration ----------------------
attempt 60+15+25
successful.
No data
session = 0.85
were
dropped.
However,
the data
speed was
0.8 MBps.
Yes No No 1 0 0 60*1+15*0+25*0
3G ----------------------
registration 60+15+25
attempt
successful. = 0.6
Several
data
session
were
dropped.
Data speed
was 0.8
MBps.
Aggregated weighted score for 3G data session=
0+0.85+0.6
-------------- =0.48
3

Example for call score
Table 64 on page 133 demonstrates how the RCEM application computes aggregated weighted scores for
voice call while the parameter values are configured, as shown:
n wgt_avg_callSuccess=40
n wgt_avg_callDropped=40
n wgt_avg_pdd=20
n cpdd_threshold=5000 (in milli seconds)
T A B L E 6 7 : W EI GH T ED SC OR ES F OR VOI C E C A L L
Weighted score
Weight 1 * Applicable
Post dial flag+...Weight n*
Whether No post Call Success Call
Scenarios delay Applicable flag n)
successful? dial delay? dropped? flag drop flag --------------------------------
flag
------------------
Weight 1 +
...weight n
Voice call not No NA NA 0 NA NA 0
established
Voice call Yes Yes Yes 1 0 0 40*1+40*0+20*0
established. ---------------------- = 0.4
Post dial 40+40+20
delay not
occurred.
Call dropped.
Yes No No 1 1 1 60*1+15*1+25*1
Voice call (occurred ---------------------- = 1
established. for 4000 60+15+25
Post dial milli
delay of seconds)
duration 4000
milliseconds
occurred.
Call not
dropped.
Aggregated weighted score for 3G data session=
0+0.4+1
---------- =0.46
3
Filters for generating the NQS dashboard

Table 68 on page 138 lists and describes the filters available for generating the NQS dashboard.

T A B L E 6 8 : F I L T ER S F OR GEN ER A T I N G T H E N QS D A SH B OA R D

Partner Type Yes
Partner Country No
Partner Network No
Start date Yes
End date Yes
Within last Yes
IMSI No

Widgets in the NQS dashboard

Figure 38 on page 139 displays the NQS dashboard.

F I GU R E 3 8 : N QS D A SH B OA R D
Table 69 on page 139 lists and describes the widgets available in the NQS dashboard.
T A B L E 6 9 : W I D GET S IN THE N QS D A SH B OA R D
Widget Description
Subscribers by Displays the NQS bucket-wise percentage distribution of subscribers for the selected
Buckets criteria.
The following NQS buckets are available:
n 0.0-0.2

Widget Description
n 0.2-0.4
n 0.4-0.6
n 0.6-0.8
n 0.8-1.0
Region Displays region-wise (partner country and network) distribution of subscribers across the
Distribution selected criteria.
Subscribers by Displays the CoS-wise distribution of subscribers across the selected NQS score, service,
CoS and country (or network).
Subscribers by Displays the service-wise distribution of subscribers across the selected NQS score and
Service country (or network).
Trend Displays the trend of subscribers across the selected criteria.
Subscriber Details Displays IMSI-level details of subscribers (in tabular format) for the selected NQS score
and duration.
The subscriber details table displays the following information:
Columns in
Description
the widget
Date Date on which the subscriber accessed the service.
IMSI IMSI of the subscriber.
CoS Name of the CoS to which the IMSI of the subscriber belongs.
Service Type of service accessed by the subscriber.
Bucket ID The bucket ID corresponding to the NQS score that is computed for the
subscriber and the service accessed.
Score The exact NQS score that is computed for the subscriber.

Network R-CX dashboard for the Steer to

Quality feature
Important
The Network R-CX dashboard is an important artifact of the Steer to Quality feature that the RCEM
application offers. Therefore, the section for Network R-CX dashboard is placed after the section for
the Steer to Quality feature.
n "Steer to Quality feature" on page 140

n "Network R-CX dashboard" on page 145
Steer to Quality feature


n "What is the Steer to Quality feature?" on page 141

n "How does the Steer to Quality feature help an operator in improving the roamer's experience?" on page
141
n "Describe stages that are involved in the Steer to Quality feature?" on page 141
n "High-level work flow" on page 143
n "Why do you configure alerts and threshold?" on page 143
n "How do you configure alerts and threshold?" on page 143
n "Sample alarm interval configuration" on page 144
What is t he St eer t o Q ualit y f eat ur e?

n A feature that recommends business settings for the NTR application based on the quality insights that
the RCEM application measures to ensure that roamers register with networks that provide good quality
of network coverage.
n In this feature, the RCEM application uses the quality score that the application measures and displays
in the Network R-CX dashboard. For information about the Network R-CX dashboard, refer "Network R-
CX dashboard" on page 145.
How does t he St eer t o Q ualit y f eat ur e help an

oper at or in im pr oving t he r oam er 's exper ience?
n The Steer to Quality feature aligns data that is stored and processed by the NTR and RCEM
applications.
n As an operator, you must always use the optimal business settings in the NTR application.
n In the NTR application, CoS of a roamer keeps changing based on the application logic.
n Therefore, by using this feature, the RCEM application keeps track of the roamer's CoS and monitors the
quality score associated with the CoS. A poor quality score could result into poor user experience.
n The RCEM application generates the necessary alarms when the quality score is degraded.
n Every time an operator is alerted about a degraded quality score, the operator can change the business
settings for the applicable CoS.
n In this manner, the Steer to Quality feature provides a mechanism through which the operator receives
the following information:
n Timely updates about the roamer's experience.
n Indication to modify and configure optimal business settings to ensure that roamer's experience is
maintained.
Descr ibe st ages t hat ar e involved in t he St eer t o

Q ualit y f eat ur e?
T A B L E 7 0 : S T A GES I N VOL VED I N T H E S T EER TO QU A L I T Y F EA T U R E
Stage Who Does what
1 RCEM application n Computes quality score for a CoS (that the NTR application has applied
to a roamer during the redirection activity) and displays the score in the
Network R-CX dashboard.

Stage Who Does what
n Note: The RCEM application merges the CoS (received from Transaction
processor) and applied CoS (received from roamerdata ), and then
computes the quality score based on the applied CoS.
If Then
The overall quality score is satisfactory The RCEM application does not take
and the service for a CoS is not any action.
degraded.
The overall quality score is low and the The RCEM application generates an
service for a CoS is degraded. alarm to notify the operator of the NTR
application and the appropriate
actions, as described in subsequent
stages, are taken.
---
Note: The alarm is generated on the
basis of threshold configurations. For
information about threshold
configuration, refer to "How do you
configure alerts and threshold?" on
page 143.
2 Operator n Receives the alarm and views the overall quality score in the Network R-
CX dashboard for the CoS and country for which the alarm was
generated.
n Opens the Zone Management page of the NTR application GUI from the
STEERING BUSINESS SETTINGS MANAGEMENT widget.
n Modifies the business settings.
Note: The logic to modify business settings is based on the quality score
that the operator views in the Network R-CX dashboard for a CoS and
network. For example, for a CoS and network, NetworkA, the quality score
is low, while NetworkA is a preferred network in the business settings.
Therefore, the operator might modify business settings and configure
NetworkA as a non-preferred network.
Note: When the operator modifies the business settings, the alarm is
cleared.

High- level wor k f low
F I GU R E 3 9 : H I GH - L EVEL W OR K F L OW
Why do you conf igur e aler t s and t hr eshold?

n To measure the quality offered by the partner network. Based on the KPIs that include voice, data, SMS,
and overall score, you configure a threshold.
n If a threshold is breached, the RCEM application generates an alarm, which you can configure based on
email, SMS message, or SNMP notification.
How do you conf igur e aler t s and t hr eshold?

You can configure alerts and threshold in the Threshold Configuration page, as shown in the sample Figure 40
on page 144. You can configure alerts to be received through email, SNMP alarm, or SMS messsage.

F I GU R E 4 0 : A L ER T S A N D T H R ESH OL D
For more information about the alert and threshold configuration, refer to "Configuring thresholds and alerts" on
page 170.
Sam ple alar m int er val conf igur at ion

You configure alarm while configuring the alerts and thresholds, as described in "Configuring thresholds and
alerts" on page 170.
KPI definition
You can define one the following KPI types:
1. Primary: Computed by a formula and does not depend on other KPIs.

2. Derived: Computed by an existing pre-defined KPI.
Types of KPI alarms currently supported
n Hourly
n Daily
n Monthly
Threshold details
Threshold type Description
User-defined A user configures a pre-defined threshold that is compared with a KPI and an
alarms is raised accordingly.
Historical trend Threshold is computed based on trend in one of the following ways:
n Hourly: For example, a job is running at the fifteenth hour of a day.
Therefore, KPI is computed at the fourteenth hour. In addition, the threshold
will be average of the KPI value of fourteenth hour from previous days.
n Daily: For example, a job is running today. Therefore, KPI is computed for
yesterday. In addition, the threshold will be average of the KPI values of all
days that are day before yesterday.

Threshold type Description
n Monthly: For example, a job is running in the current month, Therefore, the
KPI is computed for the previous month. In addition, the threshold will be
average of the KPI value of all months that are before previous month.
Alarm severity
Refer to "Configuring thresholds and alerts" on page 170.
Alerter severity example
Consider a scenario where you configure the threshold value as 1 and the severity percentages, as shown:
n Percentage below minor: 30%

n Percentage below major: 40%
n Percentage below critical: 50%
Therefore, the alarms will be raised, as shown:
n KPI value 0.71-1: Clear alarm

n KPI value 0.61-0.7: Minor alarm
n KPI value 0.51 to 0.6: Major alarm
n KPI value 0.0 to 0.5: Critical alarm
Network R-CX dashboard

This topic contains the following sections:
n "What information does the Network R-CX dashboard display?" on page 145
n "How is the information populated and displayed in each widget?" on page 146
n "How does the RCEM application compute quality score for each event?" on page 147
n "How does the RCEM application compute aggregated quality score that is displayed in each widget?"
on page 147
n "Which widgets does the RCEM application display in the Network R-CX dashboard" on page 148
n "Which filters are available in the Network R-CX dashboard?" on page 151
What information does the Network R-CX dashboard

display?
n The Network R-CX dashboard displays the network quality score that is associated with the services
availed by a subscriber.
n The services include data, voice, and SMS.
n In addition, the dashboard displays network-wise overall score and date-wise count of roamers
registered with a network.

How is the information populated and displayed in each

widget?
F I GU R E 4 1 : S T A GES F OR D A T A T O B E D I SPL A YED
T A B L E 7 1 : S T A GES F OR D A T A T O B E D I SPL A YED
Stage Who Does what
1 Probe module Collects the input feeds that contain raw statistical details about voice, SMS, and
data usage.
2 TxnWriter, Process and enhance raw data with the required details.
DiaTxnWriter, and
GTPTxnWriter
3 Transaction Generates the necessary trace files and sends the files to HDFS for processing.
processor
4 RCEM application n Fetches several data from the trace files, such as CoS, IMSI, and so on,
from the trace files and sends the data to feature factory.
n Accesses roamerdata log file and fetches the required details that include
IMSI and applied CoS.
Note: The RCEM application maintains the IMSI-applied CoS mapping
details.
The applied CoS denotes the CoS that the NTR application has applied
to a roamer during a redirection activity. The applied CoS keeps changing
based on the NTR application logic.

Stage Who Does what
4 Feature factory n Merges the data based on the applied CoS.

n Computes the quality score and aggregated quality score for each service
events (data, voice, and SMS) and stores the scores in the Hadoop
framework (HDFS). For information about how the quality score is
computed, refer to "How does the RCEM application compute quality
score for each event?" on page 147
n Segregates stored scores based on network, CoS, country, and so on.
5 RCEM application n Accesses the HDFS to fetch the aggregated score.

(iMAS dashboard) n Displays the aggregated score in the Network R-CX dashboard.
For information about how the RCEM application computes aggregated quality
score, refer to "How does the RCEM application compute aggregated quality
score that is displayed in each widget?" on page 147.
How does the RCEM application compute quality score for

each event?
For information about how the RCEM application computes quality score for an event, refer to "Computing
network quality score" on page 129
How does the RCEM application compute aggregated

quality score that is displayed in each widget?
For voice scor e:
Sum of individual scores /Sum of all call attempts
For example, if you are viewing minute-wise voice score, the RCEM application aggregates all individual call
scores. For example, in a minute, five calls were attempted, and the individual call scores were 0.3, 0.3, 0.6, 0.6,
and 1. Therefore, the aggregated voice score in that minute is 0.3+0.3+0.6+0.6+1/5=0.5.
For data score

Sum of individual data scores / Sum of all data session attempts
For SMS score

Sum of individual SMS score / Sum of SMS messages attempted
O ver all scor e

In the OVERALL R-CX SCORE widget, the RCEM application aggregates the weighted score for all events
(voice, SMS, and data). For information about how the RCEM application computes weighted score, refer to the
"Weighted network quality score" on page 133.


Network R-CX dashboard
F I GU R E 4 2 : W I D GET S IN THE N ET W OR K R - C X D A SH B OA R D
As shown in Figure 41 on page 146, the RCEM application displays the following widgets:
n "DATA R-CX SCORE" on page 149

n "VOICE R-CX SCORE" on page 149
n "SMS R-CX SCORE" on page 150
n "OVERALL R-CX SCORE" on page 150
n "ROAMERS ON EACH NETWORK" on page 151
n "STEERING BUSINESS SETTINGS MANAGEMENT" on page 151

DATA R- CX SCO RE
F I GU R E 4 3 : D A TA R - C X S C OR E
In this widget, the RCEM application displays aggregated quality score for data that is used by roamers in the
partner network.
VO I CE R- CX SCO RE
F I GU R E 4 4 : V OIC E R - C X S C OR E
In this widget, the RCEM application displays aggregated quality score for voice that is used by roamers in the
partner network.

SM S R- CX SCO RE
F I GU R E 4 5 : S M S R - C X S C OR E
In this widget, the RCEM application displays aggregated quality score for SMS messages (sent and received)
that is used by roamers in the partner network.
O VERALL R- CX SCO RE
F I GU R E 4 6 : OV E R A LL R - C X S C OR E
In this widget, the RCEM application displays aggregated weighted score of (voice, SMS, and data)

RO AM ERS O N EACH NETWO RK
F I GU R E 4 7 : R OA M E R S ON E A C H N E TWOR K
In this widget, the RCEM application displays total roamers who are registered with a network at a give time.
STEERI NG BUSI NESS SETTI NG S M ANAG EM ENT
F I GU R E 4 8 : S TE E R IN G B U S IN E S S S E TTIN GS M A N A GE M E N T
In this widget, the RCEM application provides a mechanism through which you can open the NTR application
GUI to modify business settings for a given CoS and county (zone. The NTR application identifies each country
as a zone.).
Which filters are available in the Network R-CX

dashboard?
F I GU R E 4 9 : F I L T ER S
As shown in Figure 49 on page 151, Table 72 on page 152 lists and describes the filters available for
generating the Network R-CX dashboard.

T A B L E 7 2 : F I L T ER S F OR GEN ER A T I N G T H E N ET W OR K R - C X D A SH B OA R D
Time Granularity Yes For descriptions, refer to Table 4 on page 29.

Partner Country No
Partner Network No
Start date Yes
End date Yes
Within last Yes
IMSI No
Steering CoS Yes CoS that the NTR application applied to a roamer during the redirection
activity.
---
Note: The CoS that you view in the Class of Subscriber drop-down list is
the CoS that you create in the CoS Management section of Mobileum
Administrator Studio.
Interconnect Voice dashboard

n "What details does the Interconnect Voice dashboard provide?" on page 152
n "Which KPIs does the Interconnect Voice dashboard use? " on page 152
n "Which filters does the RCEM application use to generate the Interconnect Voice dashboard?" on page
153
n "Which widgets does the RCEM application display in the Interconnect Voice dashboard?" on page 154
What details does the Interconnect Voice dashboard

provide?
The Interconnect Voice dashboard provides information about the international SIP and ISUP voice transactions
performed by local subscribers, inbound, and outbound roamers. The dashboard displays the distribution of SIP
and ISUP service availability. The dashboard also displays SIP and ISUP service retainability of partner
networks.
Which KPIs does the Interconnect Voice dashboard use?

T A B L E 7 3 : K P IS IN TH E IN TE R C ON N E C T V OIC E D A S H B OA R D
KPI Description
Answer Seizure Ratio expresses, as a percentage, the relationship between the

number of seizures that result in an answer signal and the total number of

KPI Description
seizures. This is a direct measure of the effectiveness of the service being offered
onward from the point of measurement.
[Number of answered calls]
------------------------------------- x 100
[Number of calls that were successfully attempted]
Network Efficiency Ratio expresses, as a percentage, the relationship between
the number of successful calls and the number of attempted calls.
[Number of successful call attempts]
------------------------------------------------ x 100 [Number of attempted calls].
Total duration of the call (in minutes).

the Interconnect Voice dashboard?
Table 74 on page 153 lists and describes the filters available for generating the Interconnect Voice dashboard.
T A B L E 7 4 : FILTE R S FOR GE N E R A TIN G TH E IN TE R C ON N E C T V OIC E D A S H B OA R D
Host Name No For description, refer to Table 4 on page 29.

Partner Type Yes
Partner Country No
Partner Network No
Alliance No
Class of Yes
Subscriber
Start date Yes
End date Yes
Within last No
Call Direction No Direction of call for which you want to generate the dashboard.
n Incoming: “Dashboard is generated for all the calls that are going in to
the network.”
n Outgoing: “Dashboard is generated for all the calls that are going out of
the network."
From the drop-down list, select the required call direction.
Voice Protocol No Voice protocol for which you want to generate the dashboard.
n ISUP
n SIP
From the drop-down list, select the required protocols.

Subscriber Type No Type of subscriber for which you want to generate the dashboard.
n Local: “Dashboard is generated for local subscribers of the host
network.”

n Inbound: “Dashboard is generated for inbound roamers from the

n Outbound: “Dashboard is generated for outbound roamers to the
From the drop-down list, select the required subscriber type.

Interconnect Voice dashboard?
Figure 50 on page 155 displays the Interconnect Voice dashboard.

F I GU R E 5 0 : IN TE R C ON N E C T V OIC E D A S H B OA R D
Table 75 on page 155 lists and describes the widgets available in the Interconnect Voice dashboard.
T A B L E 7 5 : WID GE TS IN TH E IN TE R C ON N E C T V OIC E D A S H B OA R D
Widget Description
Call Analysis Displays the trend (every 15 minutes, hour, day, or month) in the interconnect SIP KPIs in the
Trend selected duration.
Call Analysis Displays the region-wise distribution of interconnect SIP or ISUP KPIs in the selected duration.
by Region

Widget Description
Call Analysis Displays the interconnect carrier-wise distribution of SIP or ISUP KPIs in the selected duration.
by Carrier This widget provides information about the capacity utilization of the interconnect carriers for
calls.
Call Count by Displays the distribution of error messages that are observed in the interconnect SIP or ISUP
Error Code KPIs in the selected duration.
Call Analysis Displays the distribution of the count of incoming and outgoing calls for the selected duration.
by Call
Direction
Call Analysis Displays a detailed list of call transactions that have occurred during the period that you have
selected.
The call analysis table displays the following information:
Event Date Date and time (in the DD-MMM-YYYY 24-hour HH:MM:SS format) at
which the event occurred during the trip.
Country Name of the country where the roamer started the trip.
This is based on the first UL message initiated in a network when
the subscriber started roaming.
Error Code Error codes causing the call failures.
You can click the error code to drill-down to the Trace application if
you want to generate the trace details.
Carrier Domain Domain name of the carrier used during the transaction.
Call Direction Direction of call for which the transaction occurs.
n Incoming
n Outgoing
Call Attempts Total number of calls attempted (including successful and failed
attempts) by the roamer in the specified region and time.

5
Configuring GRQ SLAs

The Global Roaming Quality (GRQ) SLA configuration module of Mobileum Administrator Studio allows you to
configure KPIs, based on which you can measure the GRQ compliance of a roaming partner through the GRQ
dashboard section of the Mobileum dashboards. For information about the GRQ dashboard, refer to "GRQ
dashboard" on page 91.
n "Dynamic threshold learning" on page 158

n "Modifying a GRQ SLA configuration" on page 161
n "Searching for a GRQ SLA configuration" on page 164
n "Deleting a GRQ SLA configuration" on page 165
Table 76 on page 157 explains some commonly used terms in this section.
T A B L E 7 6 : C OM M ON L Y U SED T ER M S I N GR Q S LA C ON F I GU R A T I ON
Terms Explanation
NER Network Efficiency Ratio expresses, as a percentage, the relationship between the number of
successful calls and the number of attempted calls.
[Number of successful call attempts]

------------------------------------------------ x 100
[Number of attempted calls]
ASR Answer Seizure Ratio expresses, as a percentage, the relationship between the number of
seizures that result in an answer signal and the total number of seizures. This is a direct measure
of the effectiveness of the service being offered onward from the point of measurement.
[Number of answered calls]

------------------------------------- x 100
[Number of calls that were successfully attempted]
CCR Call Completion Ratio expresses, as a percentage, the number of successfully established calls
that are intentionally released by the user. This constitutes successfully completed calls and does
not include dropped calls, which are terminated unintentionally by the user due to network issues.
Chapter 5 - Configuring GRQ SLAs
Terms Explanation
[Number of calls released intentionally by the user]

-------------------------------------------------------------------- x 100
[Number of calls successfully established]
PDD Post Dial Delay refers to the time between sending of complete address information and receipt of
call set-up notification. PDD is computed as the difference of time between Initial Address
Message (IAM) and Address Complete Message (ACM). This is measured in seconds.
---
Note: The RCEM application does not calculate PDD for CAMEL-based calls.
ALOC Average Length of Call represents the average call duration.
PDP Packet Data Performance represents the ratio between the number of successful packet data
sessions and the total number of packet data sessions.
Cut-Off The probability that a PDP context is deactivated, without it being deactivated intentionally by the
ratio user.
[Number of PDP context deactivations not initiated by the user]
-------------------------------------------------------------------- x 100
[Number of all successfully activated PDP Contexts]
---
Note: If error indication received is followed by the Delete PDP Context message, then that context
is considered as not terminated intentionally by the user.
PDP Ratio between the number of successful PDP context established and the total number of PDP
Activation contexts creation attempts.
Success
Ratio
PDP Session duration between creating PDP context response and deleting PDP context request.
Session
Time
MOS Mean Opinion Score represents the quality of the SIP voice call.
The value of MOS ranges between 1 to 5.
1 represents the lowest quality of the SIP voice call and 5 represents the highest quality of the SIP
voice call.
Dynamic threshold learning

This section describes the dynamic threshold learning feature. This section contains the following topics:
n "What is the dynamic threshold learning feature?" on page 158

n "How does the dynamic threshold learning feature work?" on page 159
n "How do you configure the dynamic threshold feature in the RCEM application GUI?" on page 160
n "Which method does the RCEM application use to learn and forecast the optimal value for threshold
settings?" on page 160
What is the dynamic threshold learning feature?

A feature that the RCEM application uses to learn and set the GRQ KPI thresholds automatically by using
machine learning and forecasting algorithms based on the historical data that the application collects. The

operator only configures the network for which the RCEM application learns about the GRQ KPIs.
How does the dynamic threshold learning feature work?
F I GU R E 5 1 : T H R ESH OL D L EA R N I N G W OR K - F L OW
Table 76 on page 157 describes how the RCEM application uses the dynamic threshold learning feature to
learn and set the GRQ KPI threshold.
T A B L E 7 7 : H OW D YN A M I C T H R ESH OL D L EA R N I N G F EA T U R E W OR K S
Stage Who Does what
1 KPI processing layer n Periodically collects the input data from the probe
interface, aggregates the data into KPIs, and
stores the KPIs in Hive database.
2 Threshold manager Note: The objective of this layer is to learn thresholds
automatically. The threshold manager identifies
appropriate normal values for various KPI values across
dimensions such as network, roamer type, and so on for
the configured networks.
---
n Undergoes an initial learning period when the
input data from the probe interface is processed.

Stage Who Does what
n Analyzes the trend, during the learning period, of

various KPIs that is stored in the KPI database
and sets a threshold value for each KPI in the
application's normal behavior.
---
Note: The learning period refers to the auto-
learning duration that is of two weeks by default.
Note: The RCEM application uses the Holt-
Winters’ seasonal method to learn and forecast
about the optimal value for threshold settings. For
information about the Holts-Winters' seasonal
method, refer to Rob J Hyndman and George
Athanasopoulos. 2018. Forecasting Principles
and Practice.
---
n Resets the KPI values every two weeks, performs
the trend analysis of every two-week KPI values,
resets the threshold values, if required, for
subsequent monitoring.
3 KPI monitoring and alarms n Accesses and analyzes the currently computed
KPIs with respect to the set threshold.
n If observes a deviation, notifies the operator
through email, SNMP alarm, or SMS message.
How do you configure the dynamic threshold feature in the

RCEM application GUI?
Refer to the description for the Auto-Learn field in "Modifying a GRQ SLA configuration" on page 161.
Important
n Before you select a network for auto learning, you must set the GRQ thresholds for a minimum
period of two weeks to ensure that two-week's KPI data is available for auto-learning.
n After you select the Auto Learn checkbox in the Edit Configuration for GRQ SLAs screen, the
RCEM application displays the auto-learnt threshold values that you cannot modify.
n After you select the Auto Learn checkbox, the RCEM application learns about the threshold and
applies the threshold value during the next interval. In addition, till the next interval, the RCEM
application uses the threshold value that was set manually.
Which method does the RCEM application use to learn

and forecast the optimal value for threshold settings?
The RCEM application uses the Holt-Winters’ seasonal method to learn and forecast the optimal value for
threshold settings. The following benefits are availed while using the Holt-Winters’ seasonal method:

n Parameters while forecasting the threshold are optimized.

n Computation in the algorithm is simple.
For information about the Holts-Winters' seasonal method, refer to Rob J Hyndman and George
Athanasopoulos. 2018. Forecasting Principles and Practice.
Modifying a GRQ SLA configuration

To modify a GRQ SLA configuration
1. From the Applications drop-down list, point to RIS Management and then select GRQ SLA
Configuration.
Mobileum Administrator Studio displays the GRQ SLA Configuration page, as shown in Figure 52 on
page 161.
F I GU R E 5 2 : GR Q S LA C ON F I GU R A T I ON PA GE
Table 78 on page 161 lists and describes the fields available in the GRQ SLA configuration page.
T A B L E 7 8 : F I EL D S IN THE GR Q S LA C ON F I GU R A T I ON PA GE
Field Description
Host Network Select the host network name from the drop-down list for which the
GRQ SLA KPIs have to be defined.
Roamer Type Select the type of roamer.
n Inbound
n Outbound
Partner Network Displays the list of partner networks.
Class of Subscriber Displays the list of the class of subscribers.
Select the class of subscriber from the drop-down list for which the

Field Description
GRQ SLA KPIs have to be defined.

Network Access
GSM LU Success rate Type a value for the circuit switched LU success rate in percentage.
GSM LU Delay Type a value for the GSM LU delay time in milliseconds.
GPRS LU Success rate Type a value for the GPRS LU success rate in percentage.
GPRS LU Delay Type a value for the GPRS LU delay time in milliseconds.
LTE ULR Success rate Type a value for the LTE ULR success rate in percentage.
LTE ULR Delay Type a value for the LTE ULR delay time in milliseconds.
Call Performance
NER-MO Type the NER value for mobile originating calls.
NER-MT Type the NER value for mobile terminating calls.
ASR-MO Type the ASR value for mobile originating calls.
ASR-MT Type the ASR value for mobile terminating calls.
CCR-MO Type the CCR value for mobile originating calls.
CCR-MT Type the CCR value for mobile terminating calls.
PDD-MO Type the PDD value, in milliseconds, for mobile originating calls.
PDD-MT Type the PDD value, in milliseconds, for mobile terminating calls.
ALOC-MO Type the ALOC value, in seconds, for mobile originating calls.
ALOC-MT Type the ALOC value, in seconds, for mobile terminating calls.
MOS-MO Type the Mean Opinion Score (MOS) value for mobile originating
calls.
Note: You can enter the value of MOS between the range of 1 to 5.
MOS-MT Type the Mean Opinion Score (MOS) value for mobile terminating
calls.
Note: You can enter the value of MOS between the range of 1 to 5.
3G Packet Data Performance
PDP Cut-Off ratio Type the PDP context cut-off ratio value (in percentage). The PDP
context cut-off ratio denotes the probability that a PDP context is
deactivated without being deactivated intentionally by the user.
PDP Activation Success Ratio Type the PDP activation success ratio value (in percentage). It is the
percentage value of successful sessions divided by the total number
of attempted sessions.
PDP Session Time Type the PDP session time in seconds.
PDP Latency Type the PDP delay time in milliseconds.
PDP Round Trip Time Type the PDP round trip time in milliseconds.
PDP Throughput Type the PDP throughput value in bytes per second.
PDP Data Loss Type the PDP data loss value in bytes.
PDP Goodput Type the PDP goodput value in bytes per second.
LTE Packet Data Performance
PDP LTE Cut-Off ratio Type the LTE PDP context cut-off ratio value (in percentage). The
PDP LTE context cut-off ratio denotes the probability that a PDP
context is deactivated without being deactivated intentionally by the
user.
PDP LTE Activation Success Ratio Type the PDP LTE activation success ratio value (in percentage). It is
the percentage value of successful sessions divided by the total
number of attempted sessions.
PDP LTE Session Time Type the LTE PDP session time in seconds.
PDP LTE Latency Type the LTE PDP delay time in milliseconds.
PDP LTE Round Trip Time Type the LTE PDP round trip time in milliseconds.

Field Description
PDP LTE Throughput Type the LTE PDP throughput value in bytes per second.
PDP LTE Data Loss Type the LTE PDP data loss value in bytes.
PDP LTE Goodput Type the LTE PDP goodput value in bytes per second.
SMS Performance
MO-SMS Success Rate Type the mobile originating SMS success rate percentage value.
MT-SMS Success Rate Type the mobile terminating SMS success rate percentage value.
MO-SMS Latency Type the latency value for mobile originating SMS messages in
milliseconds.
MT-SMS Latency Type the latency value for mobile originating SMS messages in
milliseconds.
End to End SMS Delivery Time Type the value for the end-to-end SMS delivery time in milliseconds.
Threshold Deviation for Alarms-related fields
You can configure the deviations in the GRQ KPIs to be considered for raising minor, major, or critical alarms
whenever a KPI is breached. The deviation considers the percentage increase in the negative KPIs or the
percentage decrease in the positive KPIs threshold value that you configure for KPIs to raise the
corresponding alarm.
You must consider the following conditions when configuring the deviation for sending alarms:
n The value of deviation must be between zero and 100 percent.

n Minor alarm deviation value must be less than the major alarm deviation value, and in turn less than
the critical alarm deviation value. (Minor < Major < Critical)
n You can configure any or all the deviations. In case you do not configure any deviations, then RCEM
raises a major alarm whenever the KPI is breached.
---
Example 1 : Consider the following configurations for a GRQ KPI for a frequency of 15 minutes and the
deviations that RCEM must consider for raising alarms:
n GSM LU Success rate: 80 percent
n Minor alarm on deviation: 10 percent
n Major alarm on deviation: 20 percent
n Critical alarm on deviation: 30 percent
Here, RCEM raises the following alarms based on the success rate value that it computes at the end of 15
minutes:
n a minor alarm if the success rate is below 72 percent but more than 64 percent (that is, 80% minus 10%
= 72%)
n a major alarm if the success rate is below 64 percent (that is, 80% minus 20% = 64%)
n a critical alarm if the success rate is below 56 percent (that is, 80% minus 30% = 56%)
n No alarm is raised if the success rate is between 72% and 80%
Note: The GSM LU Success rate KPI is considered a positive KPI, that is, RCEM raises an alarm when the
value is below the threshold configured.
---
Example 2: Consider the following configurations for a GRQ SLA for a frequency of 15 minutes and the
deviations that RCEM must consider for raising alarms:
n LTE ULR Delay: 1000 milliseconds
n Minor alarm on deviation: 10 percent
n Major alarm on deviation: 20 percent
n Critical alarm on deviation: 30 percent
Here, RCEM raises the following alarms based on the average LTE ULR delay value that it computes at the
end of 15 minutes:
n a minor alarm if the ULR delay is more than 1100 milliseconds (that is, 1000 plus 10% = 1100)

Field Description
n No alarm is raised if the ULR delay is between 1000 and 1100 milliseconds
Note: The LTE ULR Delay KPI is considered a negative KPI, that is, RCEM raises an alarm when the value is
more than the threshold configured.
Minor Alarm on deviation Deviation (in percentage) in the GRQ KPI value for which RCEM must
raise a minor alarm.
Major Alarm on deviation Deviation (in percentage) in the GRQ KPI value for which RCEM must
raise a major alarm.
Critical Alarm on deviation Deviation (in percentage) in the GRQ KPI value for which RCEM must
raise a critical alarm.
Common fields
Should Notify Indicates that when the GRQ SLAs configured for a partner network
are breached, RCEM must notify the user about the breach.
Select the check box to enable the notification.
Auto-Learn Indicates whether the dynamic threshold learning feature is enabled
or not. When you select this option, RCEM periodically monitors the
actual value of this threshold for the configured duration and modifies
the threshold value based on the data it obtains during the monitoring
period.
For details about the dynamic threshold learning feature, refer
"Dynamic threshold learning" on page 158.
---
For information about configuring the auto-learn feature, refer to the
"Configuring dynamic threshold learning for GRQ KPIs" section in the
RCEM 2.2 Installation Guide.
Save All Option to save the values that you configured in the fields in a specific
network for all partner networks.
2. To save the changes, click Save.
Searching for a GRQ SLA configuration

To search for a GRQ SLA configuration
Configuration.
Mobileum Administrator Studio displays the GRQ SLA Configuration page.
2. Specify appropriate values for the following search criteria:
n Host Network
n Roamer Type
n Partner Network
3. Click Filter.
Mobileum Administrator Studio displays the GRQ SLA configurations for the respective partner networks.

Deleting a GRQ SLA configuration

To delete a GRQ SLA configuration
Configuration.
Mobileum Administrator Studio displays the GRQ SLA Configuration page.
2. Click the delete ( ) icon in the Available Configurations section corresponding to the partner network
that you want to delete.
3. When prompted, click OK to confirm the deletion.
Mobileum Administrator Studio refreshes the page and displays a message to indicate successful
deletion of the configuration.


6
Configuring CoS thresholds

The CoS Threshold Configuration section of Mobileum Administrator Studio allows you to configure
thresholds for different KPIs to monitor the performance of VIP subscribers and the monitor window for a
particular CoS. RCEM will monitor these KPIs over the defined window and on threshold breach, sends an
alert to the configured users.
Note
For information related to CoS configuration, refer to the Mobileum SDS 7.0 User Guide.
SDS CoS configuration supports specifying CCNDC or MCCMNC to configure all the MSISDNs or
IMSIs of a particular network. However, to monitor the performance of the VIP subscribers, RCEM
does not support configuring all subscribers of a network as VIP subscribers.
You can configure a maximum of 500,000 subscribers for VIP performance.
n "Modifying a CoS threshold configuration" on page 166

n "Searching for a CoS threshold configuration" on page 168
n "Deleting a CoS threshold configuration" on page 168
Modifying a CoS threshold configuration

To modify a CoS threshold configuration
1. From the Applications drop-down list, point to RIS Management and then select CoS Threshold
Configuration.
Chapter 6 - Configuring CoS thresholds
Mobileum Administrator Studio displays the CoS Threshold Configuration page, as shown in Figure 53
on page 167.
F I GU R E 5 3 : C O S T H R ESH OL D C ON F I GU R A T I ON
2. Specify the appropriate information in the relevant fields of the Edit Configuration for CoS Thresholds
section, as described in Table 79 on page 167
T A B L E 7 9 : F I EL D S IN THE C OS T H R ESH OL D C ON F I GU R A T I ON
Fields Descriptions
Class of Subscriber Displays the list of the class of subscribers.

(s)
Performance Measure
3G Registration Threshold (count in integer value) for number of 3G registration failures.
Failures
3G Authentication Threshold (count in integer value) for number of 3G authentication failures.
Failures
3G Registration Threshold (in seconds) for 3G poor registration latency.
Latency (seconds)
3G MO Call Failure Threshold (count in integer value) for number of 3G failed MO voice calls.
3G MT Call Failure Threshold (count in integer value) for number of 3G failed MT voice calls.
3G MO Call Drops Threshold (count in integer value) for number of 3G dropped MO voice calls.
3G MT Call Drops Threshold (count in integer value) for number of 3G dropped MT voice calls.
3G Failed SMS Threshold (count in integer value) for number of 3G failed SMS messages.
3G Failed Packet Data Threshold (count in integer value) for number of 3G failed packet data session
establishment.
LTE Registration Threshold (count in integer value) for number of LTE registration failures.
Failures
LTE Authentication Threshold (count in integer value) for number of LTE authentication failures.
Failures
LTE Registration Threshold (in seconds) for LTE poor registration latency.
Latency (seconds)

Fields Descriptions
LTE Failed Packet Threshold (count in integer value) for number of LTE failed packet data session
Data establishment.
3G Data Throughput Threshold (in kilobits per second) for 3G packet data throughput.
(Kbps)
LTE Data Throughput Threshold (in kilobits per second) for LTE data throughput.
(Kbps)
Threshold Threshold value for corresponding performance measures (KPIs). When this value is
breached, RCEM sends an alert to the configured user.
Analysis User The user ID to which the RCEM application must send the alert email and SMS
messages on breach of thresholds.
For information about configuring users, refer to the Mobileum SDS 6.0 User Guide.
Monitoring Interval The interval (in minutes) for which RCEM must monitor the failures.
The minimum value for this field is 15 minutes.

3. To modify the values, click Reset.
4. To save the changes, click Save at the bottom after editing the information.
Searching for a CoS threshold

configuration
To search a CoS threshold configuration
1. From the Applications drop-down list, point to RIS Management and then click CoS Threshold
Configuration.
Mobileum Administrator Studio displays the CoS Threshold Configuration page.
2. Choose the appropriate option from the Class of Subscriber drop-down list.
3. Click Filter.
Mobileum Administrator Studio displays the GRQ threshold configurations for the respective CoS.
Deleting a CoS threshold configuration

To delete a CoS threshold configuration
1. From the Applications drop-down list, point to RIS Management and then click CoS Threshold
Configuration.
Mobileum Administrator Studio displays the CoS Threshold Configuration page.
2. Click the delete ( ) icon corresponding to the CoS that you want to delete.
3. When prompted, click OK to confirm the deletion.

Mobileum Administrator Studio refreshes the page and displays a message to indicate successful
deletion of the configuration.

7
Configuring thresholds and alerts

Configuring thresholds and alerts refers to selecting the KPIs that the RCEM application supports and
configuring thresholds for the selected KPIs, based on which RCEM monitors these thresholds and sends
alerts to the operators.
The RCEM application continuously monitors various KPIs across region, time period, and for various time
granularities. Based on configured thresholds, RCEM sends alerts to the business or operations users when
the thresholds are breached. For example, you can configure RCEM to send an alert if the number of inbound
roamers from a particular network in the last completed month has decreased below a certain threshold. You
can also configure the threshold by comparing the trend for the past few months for inbound roamers from that
network from the RCEM dashboards.
The Threshold Configuration page of the Mobileum Administrator Studio allows the operator to configure the
settings for different KPIs based on which the operator must be alerted. The alerts can be configured to be sent
as SMS messages or email notifications.
RCEM saves details of the alerts it sends in the ri_kpi_alarm_history database table. You can verify the alerts
by checking the details in this database table. For information about correlating alarm details, refer to
"Correlating alarms in the alarm history table" on page 203.
n "Adding alert configuration" on page 170

n "Searching for, modifying, and deleting alert configuration" on page 176
Adding alert configuration

To add an alert configuration
1. From the Applications drop-down list, point to RIS Management and then click Threshold
Configuration.
Chapter 7 - Configuring thresholds and alerts
Mobileum Administrator Studio displays the Configured Alerts page, as shown in Figure 54 on page
171.
F I GU R E 5 4 : C ON F I GU R ED A L ER T S PA GE
2. Click the New Alert Configuration tab.

Mobileum Administrator Studio displays the New Alert Configuration page, as shown in Figure 55 on
page 171.
F I GU R E 5 5 : N EW A L ER T C ON F I GU R A T I ON PA GE
3. Specify the appropriate information in the relevant fields, as described in Table 80 on page 171.
T A B L E 8 0 : F I EL D S IN THE N EW A L ER T C ON F I GU R A T I ON PA GE
Field Required? Description
KPI Measurement–related fields

KPI Group Yes The KPI group for which you want to configure the threshold.
n LTE S6a Signaling Report
n MAP Signaling
n Packet Data QoS
n Roaming Voice Service

Based on the option you select in this field, the KPIs that are available
for this group are populated in the KPI field.
KPI Yes The KPI for which you want to configure the threshold.
The following KPIs are available:
n MAP and LTE S6a signaling:
n Average latency of a signaling message: “Average

transaction delay for MAP and LTE S6a signaling
messages.”
n Failure Ratio for signaling messages: “[Number
of failed signaling messages] / [Total number of
signaling messages] * 100”
n Success Ratio for signaling messages: “[Number
of successful signaling messages] / [Total number of
signaling messages] * 100”
n Total number of failed signaling messages
n Total number of signaling messages exchanged
n Total number of successful signaling messages
n Packet data QoS:
n Activation Failure Ratio: “[Number of failed
packet data sessions] / [Number of packet data
sessions that were attempted] * 100”
n Activation Success Ratio: “[Number of successful
packet data sessions] / [Number of packet data
sessions that were attempted] * 100”
n Average session duration (min): “[Total duration of
all successful packet data sessions] / [Number of
successful packet data sessions] * 100”
n Average usage per packet session (KB): “[Total
packet data used in all successful sessions (KB)] /
[Total number of successful packet data sessions]”
n Cut off ratio: “[Number of dropped data sessions] /
[Total number of successful data sessions] * 100”
n Total number of failed packet sessions
n Total number of sessions attempted
n Total number of successful packet sessions

n Roaming voice service:

n Average CCR: “[Number of calls that were
intentionally released] / [Total number of successful
calls] * 100”
n Average Length of Call: “[Total duration of all
successfully established calls (time between
reception of call answer (ISUP ANM) and call release
(ISUP REL))] / [Number of successfully established
calls]”
n Average NER: “[Number of call attempts with standard
cause code (16, 17, 18, 19, 21, and 27] / [Total number
of calls attempted] * 100”
The following cause codes are considered:
n 16: Normal call clearing
n 17: User busy
n 18: No user responding
n 19: No answer from user (user alerted)
n 21: Call rejected
n 27: Destination out of order
n Average PDD: “Average time delay between sending

of IAM and receipt of ACM messages”
n Average ASR: “[Number of successful calls] / [Total
number of calls attempted]”
n Total minutes of usage: “Total duration of all
successfully established calls (time between
reception of call answer (ISUP ANM) and call release
(ISUP REL))”
n Total number of calls attempted
n Total number of failed calls
n Total number of successful calls
Select a KPI from the drop-down list. The KPI varies based on the KPI
group that you select in the KPI Group field.
You must also select the criteria corresponding to the KPI in the
Measure for drop-down list.
Host Type Yes The type of host that you want to select for configuring the threshold.
The following option is available:
n Network
Host Yes Name of the host network for which you want to configure the threshold.
---
Note: This field depends on the value selected in the Host Type field.
For example, if the Host Type field is set to Network, then this field
displays the list of all host networks present in the system.
---
Partner Type Yes The type of partner that you want to select for configuring the threshold.
n Global: “Threshold is configured for all partner networks of all
countries for the selected host network.”
n Network: “Threshold is configured for a particular partner
network.”
n Country: “Threshold is configured for all partner networks in he
selected country.”

Partner No Name of the partner network or country (based on the option you select
in the Partner Type field) for which you want to configure the threshold.
---
Note: This field depends on the option you select in the Partner Type
field. For example, if the Partner Type field is set to Network, then this
field displays the list of all host networks present in the system.
---
Class of Yes The CoS for which you want to configure the threshold.
Measure for Yes Criteria corresponding to the KPI and KPI Group combination for which
you want to configure the threshold.
The options that appear in this drop-down list depends on the options
that you select in the KPI Group and KPI drop-down lists.
Measurement Yes The period for which the RCEM must calculate data for the selected
Period KPI.
n Last 1 hour
n Last 1 day
n Last 1 month
Measurement Yes Type of threshold value that you want to configure.
n Absolute: “Select this option if you want to configure threshold
based on the absolute value of the KPIs.
This is useful for KPIs where the absolute number or value of the
KPI is known. Example, if you know that the approximate
number of outbound roamers is 500,000 and you want an alert
when this number decreases to 400,000, then you can configure
the threshold type as Absolute and the value for the Lower
Threshold Value field as 400,000.”
n Percentage Change: “Select this option if you want to configure
the threshold based on the percentage change in KPI values
compared to the previous KPI value (that is, value of the KPI in
the previous monitoring interval).
Example, if you want an alert when the failed number of

messages increases by 10% or more in the past one hour, then
you must configure the measurement type as Percentage Change
and the value of the Upper Threshold Value field as 10.”
---
Note: Ensure the following when you configure the lower and upper
threshold values:
n When you configure absolute values, only positive values are
recommended for both upper and lower thresholds.
n When you configure percentage change values, the following
values are recommended:
n Positive values: For upper thresholds. This indicates an
increase in KPI values.
n Negative values: For lower thresholds. This indicates a
decrease in KPI values.
---

For more information about configuring the absolute and percentage

change values for KPIs, refer to "Alarm Details–related fields" on page
175.
Error Causing No Type of network that is responsible for the signaling message failures.
Network The following options are available:
n Host: “Configure thresholds for host network–induced errors.”
n Partner: “Configure thresholds for partner network–induced

errors.”
n Not Applicable"
Error Code No The MAP, Diameter, and packet data error codes for which you want to
configure thresholds.
For a list of supported error codes, refer to the following topics:
n "Supported MAP error messages" on page 35
n "Supported Diameter error messages" on page 46
n "Supported packet data error messages" on page 73

Alarm Details–related fields
---
Note: Ensure the following:
n Depending on the scenario, you must configure either the upper threshold or the lower threshold, or
both.
n If you are configuring both the values (upper and lower), then you must configure different values in the
fields.
Example 1: Absolute threshold configuration
Consider a scenario where you want to receive an alert when the number of inbound roamers in a day is more
than 300,000, and when the same number is less than 150,000.
Here, you must configure both Upper Threshold Value and Lower Threshold Value fields. You must configure
the Upper Threshold Value field with the value 300,000 and the Lower Threshold Value field with the value
150,000.
When the count of inbound roamers in a day is more than 300,000, then the RCEM application sends an alert
to the configured user. Also, when the count of inbound roamers is less than 150,000, then also the RCEM
application sends an alert to the configured user.
Example 2: Percentage change threshold configuration with upper threshold
If you want an alert when the number of failed messages is more than 10% when compared to the same value
in the preceding duration, you must:
1. First, configure the Measurement Type field as Percentage Change.
2. Then, you must configure the Upper Threshold Value field with the value 10.
If the number of failed messages at the end of the 13th hour of the day is 100 and at the end of the 14th hour is
115, the percentage change in the failed messages at the 14th hour (when compared to the 13th hour) is (115-
100)/100=15%.
Now, because you have configured the upper threshold for this failed messages as 10%, from the value
calculated, it is clear that the upper threshold has breached and hence, the RCEM application sends an alert
to the configured user.
Example 3: Percentage change threshold configuration with lower threshold
If you want an alert when the change in the success ratio for signaling messages decreases below 5% when
compared to the same value in the preceding duration, you must:
1. First, select the Percentage Change option from the Measurement Type drop-down list.
2. Then, you must configure the Lower Threshold Value field with the value -5 (that is, -5%).
If the number of signaling messages that are successful at the end of the 13th hour of the day is 80 and at the
end of the 14th hour is 75, the percentage change in the successful messages at the 14th hour (when
compared to the 13th hour) is (75-80)/80=-6.25%.

Now, because you have configured the lower threshold for this failed messages as -5, from the value
calculated, it is clear that the lower threshold has breached (success ratio has decreased more than 5%) and
hence, the RCEM application sends an alert to the configured user.
---
Upper Threshold No Type the absolute or percentage value for the upper threshold
Value depending on the option you selected in the Measurement Type field.
Acceptable values for percentage change are between 0 to 100.
Upper Threshold No Severity of the alarm that RCEM sends when the upper threshold value
Alarm Breach is breached.
n Minor
n Major
n Critical
Lower Threshold No Type the absolute or percentage value for the lower threshold
Value depending on the value set in the Measurement Type field.
Acceptable values for percentage change are between 0 to 100.
Lower Threshold No Severity of the alarm that RCEM sends when the lower threshold value
Alarm Breach is breached.
n Minor
n Major
n Critical
Notification Type Yes Type of alert notification that RCEM must send when the threshold is
breached.
n Email
n SMS
Notification User Yes Name of the user to whom RCEM must send the alert notification.

4. Depending on whether you want to add the alert configuration details or reset the values, perform one of
the following steps:
a. To add the alert configuration, click Add.
A message appears at the top of the page, confirming that the details have been added successfully.
b. To reset the values and add new details, click Reset.
You have successfully added alert configuration details.
Searching for, modifying, and deleting alert

configuration
To search for, modify, and delete an alert configuration

1. In the Configured Alerts page, from the KPI Group drop-down list, select the group for which you want
to view the configured alerts.
2. Click Filter.
The Configured Alerts section displays the details for the alert configurations, as shown in Figure 56 on
page 177.
F I GU R E 5 6 : C ON F I GU R ED A L ER T S SEC T I ON – E XI ST I N G C ON F I GU R A T I ON S
The fields in the table are described in Table 81 on page 177.
T A B L E 8 1 : F I EL D S I N T H E A VA I L A B L E L I ST OF A L ER T C ON F I GU R A T I ON S
Field Description
Host Type For descriptions, refer to Table 80 on page 171.

Host Value
Partner Type
Partner Value
KPI
Measurement For
Measurement Type
Measurement Period
Error Causing Network
Type
CoS
Delete Option to delete the configured alerts.
To delete an alert configuration, click the delete ( ) icon corresponding to the
required configuration and confirm the delete action.

3. To modify an alert configuration, click the required row.
The Threshold Details section appears in the right pane with details of the alert configuration.
Note
You can modify all fields in the Threshold Details section. For more information about fields in this
section, refer toTable 80 on page 171.

4. Depending on whether you want to save the modified alert configuration details or reset the values,
perform one of the following steps:
a. To save the modified details of the alert configuration, click Save.
A message appears at the top of the page, confirming that the details have been modified
successfully.
b. To reset the values and add new details, click Reset.
You have successfully searched for, modified, and deleted an existing alert configuration.

8
Generating trace reports

The Trace Reports section of Mobileum Administrator Studio consists of the following reports:
n Trace
n CRM
n "Trace " on page 179

n "CRM" on page 192
n "Pattern matching support in a standalone trace/CRM" on page 202
Trace
Trace includes the following details:
n The transaction details that are derived from the extended summary traces.
n Displays the event and PCAP traces by using the event and detail files respectively, that are generated
by TxnWriter.
n Historical data of any transaction that an operator can find, by using the appropriate filters.
To generate a trace report

1. From the Applications drop-down list, point to Trace Reports and then click Trace.
Mobileum Administrator Studio displays the Trace page, as shown in Figure 57 on page 180.
Chapter 8 - Generating trace reports
F I GU R E 5 7 : T R A C E PA GE
2. Specify the appropriate information in the relevant fields as described in Table 82 on page 180:
T A B L E 8 2 : F I L T ER S F OR GEN ER A T I N G T H E TR A C E D A T A SEC T I ON
Field Description
From Select the start date (in the format) by clicking the icon and then enter the start
(DD/MM/YYYY DD/MM/YYYY
HH:MI) time (in the Hour:Minute format) for which the report must be generated.
If you want a day-wise report instead of a report based on time interval, then start time and end
time must be 00:00.
---
Note: Time interval-based trace report must be used for small intervals (around 2–3 hours);
otherwise, the query might take a long time, due to which, the GUI might timeout.
---
To Select the end date (in the format) by clicking the icon and then enter the end
(DD/MM/YYYY DD/MM/YYYY
HH:MI) time (in the Hour:Minute format) for which the report must be generated.
If you want a day-wise report instead of a report based on time interval, then start time and end
time must be 00:00.
---
Note: Time interval-based trace report must be used for small intervals (around 2–3 hours);
otherwise, the query might take a long time, due to which, the GUI might timeout.
---
IMSI Type the IMSI number for which the report should be generated.
MSISDN Type the MSISDN number for which the report should be generated.
Application Select the appropriate application from the drop-down list.
n MAP: “Displays the report for the MAP protocol.”
n CAP: “Displays the report for the CAP protocol.”
n GTP: “Displays the report for the GTP protocol.”
n SIP: “Displays the report for the SIP protocol.”
n DIAMETER_S6a: “Displays the report for the Diameter_S6a protocol.”
n REGISTRATION: “Displays the report for the Registration attempts.”

T A B L E 8 3 : O T H ER F I L T ER S ( I N C L U D I N G A PPL I C A T I ON F I L T ER S ) F OR GEN ER A T I N G T H E TR A C E
D A T A SEC T I ON
Field Description
Class of The CoS for which you want to generate the dashboard.
Roamer Type of roamer for which you want to generate the dashboard. The following options are
Type available: n Inbound: “Report is generated for inbound roamers from the selected regions.” n
Outbound: “Report is generated for outbound roamers to the selected regions.” From the drop-
down list, select the required roamer type.
Host Name of the host network for which you want to configure the threshold.
Network
Partner Countries to which the roaming partner networks belong, for which you want to generate the
Country dashboard. From the drop-down list, select the required partner countries.
Partner Names of the partner networks for which you want to generate the dashboard. From the drop-
Network down list, select the required partner networks.
IMEI IMEI number of the subscriber’s mobile device.
---
Note: For security purpose, the RCEM application uses the masking feature that provides an
option to cover a few digits of the subscribers' IMSI, MSISDN, and IMEI. The RCEM application
provides the masking feature for Indexer (Tracer) and dashboard. For information about how to
enable the masking feature, refer to the description of the IMSI field.
Service Act Select the required service act.
Service Act refers to the actions that the service has performed. An action is specific to the
service it belongs to.
Note: There could be several actions in addition to those that are configured and displayed in the
Service Act drop-down list. Based on requirements and service's (Mobileum application)
capability, Mobiluem might modify the action list that are currently displayed in the Service Act
drop-down list.
Call Type Type of call for which you want to generate the dashboard. The following options are available:
n Mobile Terminated
n Mobile Originated
From the drop-down list, select the required call types.

RIS-Trace-MAP
Host Global Type the GT for the host network for which the report has to be generated.
Title
Partner Type the GT for the partner network for which the report has to be generated.
Global Title
Message Displays the type of message used in the transaction.
Type Following are the example of type of messages that are available:
n UL
n CL
n MO_FSM
Note: The complete list includes numerous type of messages that are displayed in the RCEM
GUI.
Result Code Displays the result code generated for the given transaction.
Following are the example of result codes that are available:
n Success Message(0)
n Incompatible Terminal(28)
n System Failure(34)
Note: The complete list includes numerous types of result codes that are displayed in the RCEM

Field Description
GUI.
RIS-Trace-CAP
Host Global Type the GT for the host network for which the report has to be generated.
Title
Partner Type the GT for the partner network for which the report has to be generated.
Global Title
CAMEL The phase of the CAMEL protocol for which you want to generate the trace report.
Phase The following options are available:
n 1, 2, 3
Following are example of result codes that are available:
n Access information discarded(43)
n Call rejected(21)
n Incomplete Transaction(-1)
GUI.
RIS-Trace-GTP
Host Node Type the IP address for the host network for which the report has to be generated.
IP
Partner Type the IP address for the partner network for which the report has to be generated.
Node IP
APN APN for which you want to generate the trace report.
RAT The Radio Access Technology (RAT) involved in the packet data sessions.
n GAN
n UTRAN
n EUTRAN
n GERAN
n HSPA Evolution
n WLAN
n Reserved
n Virtual
Subscriber Type the address of the subscriber.
IP address
Session Filter the number of dropped out sessions by selecting the session drop status.
Drop Status The following options are available:
n Dropped
n Not dropped
Usage Displays the distribution of data usage done in the session, grouped into different usage buckets.
Bucket The session is categorized in the following buckets:
n 0-1MB
n 2-30MB
n 31-60MB
n 61-120MB
n >121MB
Duration Distribution of the duration of the session grouped by average duration buckets. The data is
Bucket grouped and displayed in the following duration buckets:
n 0-1mins
n 2-30mins
n 31-60mins

Field Description
n 61-120mins
n >121mins
Throughput Distribution of the number of sessions grouped by average throughput buckets. The data is
Bucket grouped and displayed in the following throughput buckets:
n 0-1Mbps
n 2-30Mbps
n 31-60Mbps
n 61-120Mbps
n >121Mbps
Start Select the start technology on which the session was started.
Technology For example, a user starts using mobile data service on an LTE technology. After some time the
session switches to 3G due to:
n Lack of connectivity
n Congestion on the LTE network in that specific area.
The technology on which the session began is LTE.

n 3G
n LTE
n V1 Invalid Correlation-ID(225)
n V1 IMSI not known(194)
GUI.
RIS-Trace-SIP
n Alternative Service(380)
n Bad Extension(420)
GUI.
Call Indicates the direction of the SIP voice call in the event.
Directions The following values are supported:
n Outgoing
n Incoming
Carrier Type the carrier domain for which you want to generate the Trace.
Domain Carrier domain identifies the partner carrier with which the host network has arrangements to
carry the interconnect traffic.
Example: Carrier domain is derived from the host part of the Calling or Called URI depending
upon the call direction.
NSW.SYD.TATA.COM is an example of a carrier domain of the called party.
Note: The domain name provides information about the carrier location. A typical SIP URI has
the form sip:username@domainname, where domainname requires DNS SRV records to locate the
servers for SIP domain.
Example, 1456750011918437417378@IDD.NSW.OPTUS.COM.AU denotes the value of the called party,
where 1456750011918437417378 is the SIP username and IDD.NSW.OPTUS.COM.AU is the carrier
domain name.

Field Description
RIS-Trace-DIAMETER_S6a
Host Node Type the address (URL) of the host node.
Address
(URL)
Partner Type the address (URL) of the partner node.
Node
Address
(URL)
Message Displays the type of message used in the transaction.
n AIR
n CCR
n CLR
n DSR
n IDR
n NOR
n PUR
n RAR
n RSR
n ULR
n DIAMETER ADC RULE EVENT(5148)
n DIAMETER APPLICATION UNSUPPORTED(3007)
GUI.
RIS-Trace-REGISTRATION
Registration Displays the distribution of number of successful registrations grouped into different registration
Latency time buckets for the selected duration. Following time buckets are displayed in the widget:
Bucket n 1-2 min(s)
n 2-30 sec(s)
n 31-60 sec(s)
n <1 sec(s)
n >2 min(s)
Registration Displays the registration domain.
Domain The following options are available:
n GPRS
n GSM
n GSM_GPRS
n LTE_GSM
n Busy Subscriber(45)
n Call Barred(13)
GUI.

Note
The Application filters are optional and you can apply them if you want to drill down to the exact
search results.
3. Click Search.
Mobileum Administrator Studio displays the Trace report, as shown in Figure 58 on page 186.

F I GU R E 5 8 : R C E M T R A C E - R ESU L T S PA GE
RCEM displays the Trace information across the following sections and widgets:

n Section: Assess
RCEM displays the following widgets in the Asses section:
n Timeline
n Event History
Assess
The Assess section of the Trace report displays individual events that have occurred during a subscriber’s
roaming trip across all services and networks. It also displays details about each transaction that has occurred
within a particular event. For example, for a successful GSM attach event, details about individual message
transactions in this event are also displayed.
Figure 59 on page 188 displays the widgets in the Assess section of the Trace report.

F I GU R E 5 9 : W I D GET S IN THE A SSESS SEC T I ON
Table 84 on page 188 lists and describes the widgets displayed in the Assess section of the Trace report.
T A B L E 8 4 : W I D GET S IN THE A SSESS SEC T I ON – TR A C E R EPOR T
Widget
Description
name
Timeline Displays events on a time graph grouped by the service to which the events belong. The events are
displayed as dots in the following colors to indicate the status of that event:
n Green ( ): “Indicates a successful event.”
n Red ( ): “Indicates a failed event.”

Widget
Description
name
Event Displays an overview of all the events that have occurred during the trip for the subscriber.
History The event history table displays the following information:
n Time: “Date and time (in the DD-MMM-YYYY 24-hour HH:MM:SS format) at which the event
occurred during the trip.”
n Event: “Description of the event that has occurred.”
---
Note:
n To view details of the transactions of an event, click the ellipsis icon corresponding to the
event.
n To view the message details in an event, select the corresponding check box and then click
Show Event. For more information, refer to "Event details" on page 189.
n To generate the pcap file for the event, select the corresponding check box and then click
Export PCAP. Moreover, the Export PCAP option will not available if you have enabled the
masking feature of IMSI or MSISDN (PII Masking feature).
n To view the event details in the CSV format, select the corresponding check box and then
click Export Event As CSV.
---

Event det ails

You can view the TCAP-level details of an event, such as messages involved in that event, by selecting the
check box corresponding to the event and then clicking Show Event from the Event History table.
Figure 60 on page 189 displays the Event details page.
F I GU R E 6 0 : C OL U M N S IN THE E VEN T D ET A I L S T A B L E

Table 85 on page 190 describes the various columns displayed in the trace report:
T A B L E 8 5 : F I EL D S IN THE RCEM T R A C E R EPOR T F OR T H E MAP PR OT OC OL
Column name Description
Date Date and time (in the DD-MM-YYYY 24-hour HH:MM:SS format) at which the transaction
occurred for the event.
Protocol Name of the protocol that was involved in the transaction.
The following values are supported:
n ISUP
n MAP
n CAMEL
n GTP
n SIP
n Diameter
Version Version of the CAP, GTP, and Diameter call sessions.
Event Name of the event
Tcap Txn Type Type of TCAP transaction present in the event.
n BEGIN
n CONTINUE
n END
Tcap Comp Type Type of TCAP component present in the event.
The following options are supported:
n NONE
n INVOKE
n RESULT
n ERROR
n REJECT
IMSI IMSI of the subscriber involved in the transaction.
---
Note: For security purpose, the RCEM application uses the masking feature that
provides an option to cover a few digits of the subscribers' IMSI, MSISDN, and IMEI.
The RCEM application provides the masking feature for Indexer (Tracer) and
dashboard.
To ensure that masking feature works properly, you must configure and enable the
feature. For information about how to configure, refer to the "Configuring the masking
feature" section in the RCEM 2.2 Installation Guide.
Follow these steps to enable the masking feature for Indexer (Tracer):
1. Log in to the Mobileum Administrator Studio by using the admin credentials.
2. From the Application menu at the top left, select System Administration.
3. On the left, click the Application management ( )icon.
4. Under the List of applications section, click Indexer.
5. In the Authorization data section at the bottom left, select the user group for
which you want to enable the masking feature.
6. In the pii.masking.reqd text box, type yes and click Save.

Note: The masking feature is enabled or disabled at the group level only. If you
have configured the masking feature by following the steps available in the
"Configuring the masking feature" section of the RCEM 2.2 Installation Guide,
the RCEM application enables the feature for all groups by default. Therefore, if
you want to disable the feature for a group, make sure you type no in the
pii.masking.reqd text box for that group.
Important: The aforementioned steps enable the masking feature for Indexer (Tracer)
only. If you want to enable the feature for RCEM dashboard, you must follow similar
steps for dashboard, as well. Therefore, to enable the feature for dashboard, while
selecting the application under List of applications section, make sure you click
Dashboard. The remaining steps are identical.
MSISDN/Cg-MSISDN MSISDN of the subscriber or the calling party.
Cd-MSISDN MSISDN of the called party.
MSC/VLR Address of the MSC-VLR.
OTID/CIC/EndToEndID Source transaction ID, CIC of the carrier trunk, or end-to-end ID for the event.
DTID Destination transaction ID for the event.
SM TxnId Transaction ID generated by the state machine for this event.
Host Node GT of the subscriber’s host network.
Partner Node GT of the partner network where the subscriber is roaming.
Host GT SSN/Port SSN value present in the GT or the port number of the subscriber’s host network.
Partner GT SSN/Port SSN value present in the GT or the port number of the subscriber’s partner network.
Host GT NP/IP Numbering plan (NP) present in the GT or the IP address of the host network.
Address
Partner GT NP/IP Numbering plan (NP) present in the GT or the IP address of the partner network.
Address
Invoke Id/RPUI ID of the TCAP invoke component or the RP UI address
Address
GMSC PC/Host Point code (PC) or the realm address of the host network’s GMSC.
Realm
Carrier PC/Partner PC or the realm address of the partner carrier.
Realm
Carrier Id ID of the partner carrier.
Direction Indicates the direction of the message in the event.
n 1: “Outgoing”
n 2: “Incoming”
MSU Size Size (in bytes) of the event’s MSU.
Cause code Code of the error that has occurred in the event.
APN Name of the APN accessed in the event.
Note
If the feed is coming from the Anritsu Probe, there is no option to view or download the PCAP files or
sequence diagrams of the events that are displayed in the Trace field.

CRM
CRM generates a CRM report that provides details about a subscriber’s activity during a roaming trip. The
details include the following:
n Current location of the subscriber, if the subscriber is currently roaming. This information is obtained
from the open trip data for that subscriber.
n Trip details (including countries visited, time spent in each country, quality of the services provided by
partner networks, usage of the subscriber across services, history of all previous roaming trips by the
subscriber.)
n Simplified information displaying the details about the Roaming status, Roaming activities , Usage per
services (Data, Voice, or SMS) across visited countries, Quality scores per service across visited
countries, and Roaming history of the subscriber.
To generate a CRM report

1. From the Applications drop-down list, point to Trace Reports and then click CRM.
Mobileum Administrator Studio displays the CRM page, as shown in Figure 61 on page 192.
F I GU R E 6 1 : C R M PA GE
2. Specify the appropriate information in the relevant fields, as described in Table 86 on page 192:
T A B L E 8 6 : F I L T ER S F OR GEN ER A T I N G T H E CRM R EPOR T
Filter Description
From Start date and time (in the DD-MMM-YYYY HH:MM 24-hour format) for which you want to generate the
report.
To End date and time (in the DD-MM-YYYY HH:MM 24-hour format) for which you want to generate the
report.
IMSI IMSI for which you want to generate the report.
MSISDN MSISDN for which you want to generate the report.


Note
n All the filters mentioned are applicable to generate and view the Roaming Activity section in
CRM.
n Only IMSI and MSISDN filters are applicable to generate and view the Roaming Status and
Learn sections.

3. Click Search.
Mobileum Administrator Studio displays the CRM report, as shown in Figure 62 on page 194.

F I GU R E 6 2 : C R M – R ESU L T S PA GE

RCEM displays the CRM report information across the following sections and widgets:
n Section: Roaming Status
n Section: Roaming Activity
RCEM displays the following widgets in the Roaming Activitysection:
n Timeline
n Event History
n Section: Learn
RCEM displays the following widgets in the Learn section under the Trip Details subsection:
n Time Spent
n Trip Service Quality
n Trip Usage
n Roaming History
n "Roaming Status" on page 195

n "Roaming Activity" on page 196
n "Learn" on page 200
Roaming Status
Figure 63 on page 195 displays the Roaming Status section of the CRM report.
F I GU R E 6 3 : I N F OR M A T I ON IN THE R OA M I N G S T A T U S SEC T I ON
The Roaming Status section of the CRM report displays the following details by using the open trip data of a
roamer:

Note
n RCEM displays information in this section only if the open trip details are present for the roamer,
that is, only if the roamer is currently roaming.
n If no data is present in the open trip details, that is, if the roamer is not currently roaming, then in
the Roaming Status section, a message appears informing that the IMSI or MSISDN is not
roaming.

n Billing ID: MSISDN of the roamer
n Name of the CoS to which the roamer belongs. This is indicated by the icon.
n Timestamp: Date and time (in the MM/DD/YYYY 24-hour HH:MM:SS format) of the roamer’s first entry to
that country.
n Name of the current country where the roamer is present.
Roaming Activity
The Roaming Activity section of the CRM report displays individual events that have occurred during a
subscriber’s roaming trip across all services and networks. It also displays details about each transaction that
has occurred within a particular event. For example, for a successful GSM attach event, details about individual
message transactions in this event are also displayed.
Figure 64 on page 197 displays the widgets in the Roaming Activity section of the CRM report.

F I GU R E 6 4 : W I D GET S IN THE R OA M I N G A C T I VI T Y SEC T I ON
Table 87 on page 197 lists and describes the widgets displayed in the Roaming Activity section of the CRM
report.
T A B L E 8 7 : W I D GET S IN THE R OA M I N G A C T I VI T Y SEC T I ON – CRM R EPOR T
Widget
Description
name
Timeline Displays events on a time graph grouped by the service to which the events belong. The events are
displayed as dots in the following colors to indicate the status of that event:

Widget
Description
name
n Green ( ): “Indicates a successful event.”
n Red ( ): “Indicates a failed event.”
Event Displays an overview of all the events that have occurred during the trip for the subscriber.
History The event history table displays the following information:
n Time: “Date and time (in the DD-MMM-YYYY 24-hour HH:MM:SS format) at which the event
occurred during the trip.”
n Event: “Description of the event that has occurred.”
---
Note:
n To view details of the transactions of an event, click the ellipsis icon corresponding to the
event.
n To view the message details in an event, select the corresponding check box and then click
Show Event. For more information, refer to "Event details" on page 198.
n To generate the pcap file for the event, select the corresponding check box and then click
Export PCAP.
n To view the event details in the CSV format, select the corresponding check box and then
click Export Event As CSV.
---

Event det ails

You can view the TCAP-level details of an event, such as messages involved in that event, by selecting the
check box corresponding to the event and then clicking Show Event from the Event History table.
Figure 65 on page 198 displays the Event details page.
F I GU R E 6 5 : C OL U M N S IN THE E VEN T D ET A I L S T A B L E
Table 88 on page 198 lists and describes the columns in the Event Details table.
T A B L E 8 8 : C OL U M N S IN THE E VEN T D ET A I L S TABLE – E VEN T H I ST OR Y W I D GET
Date Date and time (in the DD-MM-YYYY 24-hour HH:MM:SS format) at which the transaction
occurred for the event.
Protocol Name of the protocol that was involved in the transaction.

n ISUP
n MAP
n CAMEL
n GTP
n SIP
n Diameter
Version Version of the protocol that was involved in the event.
Event Name of the event
Tcap Txn Type Type of TCAP transaction present in the event.
n BEGIN
n CONTINUE
n END
Tcap Comp Type Type of TCAP component present in the event.
The following options are supported:
n NONE
n INVOKE
n RESULT
n ERROR
n REJECT
IMSI IMSI of the subscriber.
MSISDN/Cg-MSISDN MSISDN of the subscriber or the calling party.
Cd-MSISDN MSISDN of the called party.
MSC/VLR Address of the MSC-VLR.
OTID/CIC/EndToEndID Source transaction ID, CIC of the carrier trunk, or end-to-end ID for the event.
DTID Destination transaction ID for the event.
SM TxnId Transaction ID generated by the state machine for this event.
Host Node GT of the subscriber’s host network.
Partner Node GT of the partner network where the subscriber is roaming.
Host GT SSN/Port SSN value present in the GT or the port number of the subscriber’s host network.
Partner GT SSN/Port SSN value present in the GT or the port number of the subscriber’s partner network.
Host GT NP/IP Numbering plan (NP) present in the GT or the IP address of the host network.
Address
Partner GT NP/IP Numbering plan (NP) present in the GT or the IP address of the partner network.
Address
Invoke Id/RPUI ID of the TCAP invoke component or the RP UI address
Address
GMSC PC/Host Point code (PC) or the realm address of the host network’s GMSC.
Realm
Carrier PC/Partner PC or the realm address of the partner carrier.
Realm
Carrier Id ID of the partner carrier.
Direction Indicates the direction of the message in the event.
n 1: “Outgoing”
n 2: “Incoming”
MSU Size Size (in bytes) of the event’s MSU.
Cause code Code of the error that has occurred in the event.

APN Name of the APN accessed in the event.


Learn
The Learn section of the CRM report displays information about both the open trip and all previous closed trip
details of a roamer. The Time Spent, Trip Service Quality, and Trip Usage widgets always display the current
open trip details of a subscriber, unless a user clicks a specific trip in the Roaming History widget to view the
details of a subscriber’s previous closed trips.
Figure 66 on page 200 displays the widgets in the Learn section of the CRM report.
F I GU R E 6 6 : W I D GET S IN THE L EA R N SEC T I ON
Table 89 on page 201 lists and describes the widgets displayed in the Learn section of the CRM report.

T A B L E 8 9 : W I D GET S IN THE L EA R N SEC T I ON – CRM R EPOR T
Widget
Description
name
Time Displays the percentage distribution of the time spent by a subscriber in various countries in a
Spent roaming trip.
---
Note: By default, this widget always displays details from a subscriber’s current open roaming trip. If
the subscriber is not roaming any longer, then this widget displays details from the subscriber’s last
closed roaming trip.
---
Trip Displays the subscriber’s level of satisfaction (in color-coded boxes) across the services that the
Service subscriber has accessed in all networks in a country during a trip.
Quality Details about the level of satisfaction are obtained from the network quality score that RCEM
computes for a subscriber based on predefined KPIs. For more information about the network quality
score, refer to "NQS dashboard" on page 129.
Trip Displays the country-wise details of total usage (in tabular format) of all the services that the
Usage subscriber has accessed in networks of that country during the trip.
The trip usage table displays the following information:
n Country Name: “Name of the country where the subscriber has accessed a service during
the trip.”
n Data Usage (MB): “Total amount of data (in megabytes) used by the subscriber when in that
country.”
n MOU (MT Calls): “Total number of minutes of MT calls received by the subscriber when in
that country.”
n MOU (MO Calls): “Total number of minutes of MO calls made by the subscriber when in that
country.”
n SMS: “Total number of SMS messages sent by the subscriber when in that country.”
Roaming Displays a consolidated view (in tabular format) of a subscriber’s roaming trips (open and closed)
History with details about the roaming start and end time, and start and end country.
The roaming history table displays the following information:
n Start Time: “Date and time (in the MM/DD/YYYY 24-hour HH:MM:SS format) when the subscriber
started the roaming trip.”
n End Time: “Date and time (in the MM/DD/YYYY 24-hour HH:MM:SS format) when the subscriber
ended the roaming trip.”
n Duration (days): “Number of days that the subscriber’s trip lasted.”
n Start Country: “Name of the country where the subscriber’s roaming trip started.”
n End Country: “Name of the country where the subscriber’s roaming trip ended.”
n Status: “Indicates whether the subscriber roaming trip is open or closed.”
n Trip Details: “Provides a link to view the details about a particular trip (open or closed) in the
following widgets in this section:
n Time Spent
n Trip Service Quality
n Trip Usage”

Pattern matching support in a standalone

trace/CRM
You can use wildcard characters (% and _) to search based on pattern in the RCEM Trace and RCEM CRM
reports.
The following wildcard characters are supported:
n %: can match any number of characters (including 0).

n _: can match any single character.

Examples:
An input of 919820% for the MSISDN field will match all the MSISDNs starting with 919820, such as
919820000001, 919820, and 919820555555.
An input of 919_20% for the MSISDN field will match the following MSISDNs: 919x20% --> where x could be
any character.
You can use the escape character (\) to search for strings that contain wildcard (% or _) characters.
Examples:
To search for a string that contains % (for example, ICICI%BANK), you can use an input of ICICI\%BANK, where
the escape character (\) is included before %.
To search for a string that contains _ (for example, ICICI_BANK), you can use an input of ICICI\_BANK, where
the escape character (\) is included before _.
To search for a string that contains % and \ (ICICI\BANK%HOME), you can use as input of ICICI\\BANK\%HOME,
where the escape character (\) is entered before % and \.
If the input value contains wildcard (% or _) characters and you want to search for strings containing \, you must
use \\.
Example:
To search for ICICI\BANK123 or ICICI\BANK1 or ICICI\BANKHOME, use the following input string:
ICICI\\BANK%
If the input value does not contain any wildcard characters (neither % nor _) then \ will not be treated as an
escape character.
Example:
If the input string is 'ICICI\BANK', the search results will show all the strings that match the input string. Here,
pattern matching will not be used.

A
Correlating alarms in the alarm history

table

The RCEM application sends alarms whenever a KPI is breached. RCEM computes the breach based on the
threshold configuration that the operator defines in the Threshold Configuration page of the RCEM GUI. For
information about configuring thresholds, refer to "Configuring thresholds and alerts" on page 170.
RCEM also saves details about all alarms in the ri_kpi_alarm_history database table. It also saves details of
multiple instances of the same alarm depending on the status of the alarm (cleared or raised) and the type of
threshold that is breached (lower or upper).
You can correlate details of the alarms by checking the following columns that are present in the ri_kpi_alarm_
history database table:
n TIMESTAMP: Date and time when the alarm is raised (or cleared).
n ALARM_CLEARED: Indicates whether the alarm was raised or cleared for a KPI. The following values are
applicable:
n 0: Alarm is raised
n 1: Alarm is cleared
n ALARM_TYPE: Indicates the type of threshold that is breached. The following values are applicable:
n 0: Lower threshold is breached
n 1: Upper threshold is breached
n ALERT_MESSAGE: Description of the alarm.
Consider the following scenarios where both the lower and upper thresholds for a KPI are configured in the
GUI and these thresholds are breached at different instances of time:
1. In the current processing cycle of the Alerter component (at timestamp 1): Lower threshold for the KPI is
breached. RCEM raises an alarm for the lower threshold breach and saves this information in the alarm
history table with the values; ALARM_CLEARED = 0 and ALARM_TYPE = 0.
2. In the next processing cycle of the Alerter component (at timestamp 2): The same KPI is breached,
however, for the upper threshold. Here, RCEM performs the following actions:
a. Because the KPI value does not breach the lower threshold at this instance, RCEM clears the alarm
that it had previously raised (for lower threshold breach) and updates the existing entry in the alarm
Appendix A - Correlating alarms in the alarm history table
history table with the value ALARM_CLEARED = 1.

b. Then, RCEM raises an alarm for the upper threshold breach of the same KPI and saves this
information in a new entry with the values; ALARM_CLEARED = 0 and ALARM_TYPE = 1.

B
Upgrading the Trace application

n "Upgrading the Trace application" on page 205

n "Enabling CRM application for a user under a user group other than 'RIS'" on page 208
Upgrading the Trace application

To upgrade the Trace application
Note
Before you begin, make sure you have completed the following steps:
n Take a backup of Oracle tables and the files that could be modified.
n The steps to upgrade the Trace application is applicable only if the CRM application is not
enabled for any user login, for example risuser, under the RIS user group. If the
CRM application is enabled already, follow these steps to disable CRM:
n Make sure that you have completed the RCEM 2.2 installation, as given in the RCEM 2.2
Installation Guide.
n Make sure that the environment variables such as ROAMWARE_HOME and CATALINA_HOME are set
through the setup.sh file.
n To remove CRM entry from the iMAS menu, run the following commands on Oracle database
schema that is configured as the default pool in the imaslight.properties file:
Important: Make sure that only one row is deleted after you run the following commands:
Appendix B - Upgrading the Trace application
n Delete from MENULABELS where KEY=10501 and DN='000001' and LABEL='CRM' ;
n Commit ;
1. Run the following commands on Oracle database schema that is configured as the default pool in the
imaslight.properties file:
n DELETE FROM APPAUTHORIZATION WHERE APPID = 's61' and GRPID = 'RIS' ;
n Insert into APPAUTHORIZATION (APPID,AUTHCODE,GRPID,AUTHVALUE,GRANTED) values
('s61','app.allowed.list','RIS','159_Verizon','Y');
('s61','db.pool.name','RIS','default','Y');

('s61','indexer.fixed.cols.from','RIS','ristrace','Y');
('s61','indexer.timeline.group.from','RIS','ristrace','Y');
n Commit ;
Important: Make sure that only one row is updated after you run the following commands:
n Update MENUDATA set MENUAPPID = 's61' where KEY = 10501 and DN = '000000' ;
n Commit ;
2. Modify the CATALINA_HOME/webapps/ROOT/imaslight.properties file, as shown:

a. Under the [RPCServers] section, configure the count of indexers. For example, if you want to
configure one indexer, update the following configuration, as shown:
rpc.servers=1
n Add the following configurations for each indexer that you want to configure:
Note:The following configurations are applicable when you have only one indexer. If there are
multiple indexers, you must ensure that similar configuration for each indexer is added.
n rpc.server.1.host=127.0.0.1
n rpc.server.1.name=RISIndexer
n rpc.server.1.type=1
n rpc.server.1.port=10538
n rpc.server.1.module=300
n rpc.server.1.size=1
b. Add or update (if required) the following configurations under the [Indexer] section:
# Limited IMSITracer input/output fields :
#-----------------------------------------
ristrace.fixed.input.column.names=IMSI,MSISDN,Class_of_Subscriber,Roamer_Type,Host_
Network,Partner_Country,Partner_Network,IMEI,Service_ID,Call_Type
ristrace.fixed.input.column.pii.tag=imsi,msisdn,NA,NA,NA,NA,NA,imei,NA,NA
ristrace.fixed.input.column.descriptions=IMSI,MSISDN,Class of Subscriber,Roamer Type,Host
Network,Partner Country,Partner Network,IMEI,Service Act,Call Type
ristrace.fixed.output.column.names=sequenceNumber,DateTime,IMSI,MSISDN,Message_
Type,Partner_Name,Error_Code

ristrace.fixed.output.column.descriptions=Txn Ref Number,Event Time,IMSI,MSISDN,Message

Type,Partner Network,Result Code
# Configure below parameters to get output date fields in required format :
#-----------------------------------------
ristrace.date.format.enable=true
ristrace.fixed.output.date.format.on.ui=MM/dd/YYYY
ristrace.fixed.output.date.format.description=month,day,year
ristrace.fixed.output.date.delimiter=/
# Configure below parameters for cascading of input filters :
#------------------------------------------------------------
ristrace.fixed.input.cascade.enable=true
ristrace.fixed.input.column.dependent.on.Partner_Country=Partner_Network
ristrace.cascade.dependent.fields=Partner_Network
# IMSITrace specific custom groups :
#-----------------------------------
ristrace.timeline.group.names=MAP,CAP,SIP,DIAMETER_S6a,REGISTRATION,GTP
ristrace.timeline.group.descriptions=MAP,CAP,SIP,DIAMETER_S6a,REGISTRATION,GTP
# Configure below entry for comma separated list of rpc module ids of indexers configured
and to be queried :
#---------------------------------------------------------
ristracer-indexers.module.list=300
c. Add the following section if you want to configure the CoS source as CoS Management module or
CoSEngine platfrom component:
Note: If you do not add the following texts, the RCEM application will use the CoS Management
module as the default source for CoS and login user-specific CoS association will be used to
populate the Class of Subscriber drop-down list in the Trace application. For details about CoS
source configuration, refer to the "Configuring CoS source for Trace application", section in the
RCEM 2.2 Installation Guide.
[RIS]
# Valid cos source names are "sds" or "cosengine"
cos.source.name=
# Database pool to fetch COS information (pool "default" will be used by default)
cos.source.db.pool.name=
# Configure COS feature name/s (comma separated) for populating COS, if 'cosengine' is
used as COS source
cos.feature.names=
3. Make sure that the ristrace_verizon.properties and ris22.jar files are available in the ROAMWARE_
HOME/indexerConfig and CATALINA_HOME/webapps/ROOT/WEB-INF/lib directories respectively.
Important
Make sure that the ristrace_verizon.properties and ris22.jar files are from the latest RCEM 2.2
package that you have installed.
4. Restart the Tomcat server.

Enabling CRM application for a user under

a user group other than 'RIS'
Note
n The steps in this section is applicable in a scenario where you have upgraded the Trace
application (by following the steps that are available in the aforementioned section) and have
disabled the CRM application. Therefore, you must follow the steps in this section if you want to
enable the CRM application after you have upgraded the Trace application.
n Make sure that you have taken a backup of Oracle tables and the files that could be modified.
n Make sure that you have completed the RCEM 2.2 installation, as given in the RCEM 2.2
Installation Guide
To enable CRM for a user under the group other than 'RIS'
Note
For information about how to create a user group, user under a group, menu, and access, refer to
the "Managing usergroups" , "Managing users", "Managing menu" and "Managing access rights"
chapters respectively in the Mobileum SDS 6.0 User Guide.
1. In the iMAS admin GUI, create iMAS menu for the CRM application, as shown in the following steps that
use a sample root node name as CRM Root.
Note: You can create a menu tree for the CRM application of your choice:
a. Create a root node named CRM Root.

b. Create a menu named CRM under the CRM Root that you created in the previous step.
Important: The Application label must be set to Indexer, which must have the app ID as s61.
2. In the iMAS admin GUI, create menu access for the CRM application, as shown in the following steps
that use a sample menu access that is named as CRMAccess:
Note:You can create an access ID (of your choice) that has access to the CRM application.
n Create menu access named CRMAccess and assign the CRM application (that you created the menu
for in the previous step) to CRMAccess.
3. In the iMAS admin GUI, create a user group named RISCRM that is assigned with menu access (created
in the previous step) as Access Name and root node name (created in step 1) as Menu Id, as shown in
the following steps:
Note: You can create a different user group that is assigned with Access Name and Menu Id that are
created in previous steps.
n Create a group ID/name as RISCRM with Access Name as CRMAccess and Menu Id as CRM Root.

4. In the iMAS admin GUI, create a user assigned to the user group (created in the previous step), as
shown in the following steps:
Note: You can create the user with the name of your choice that must be assigned to user group
(created in the previous step).
n Create a user name as crmuser, under the user group RISCRM that you created in the previous step.
5. Run the following commands on Oracle database schema that is configured as the default pool in the
imaslight.properties file:
Note
The commands uses the group ID (user group) that you created in previous steps. Therefore,
RISCRM is used as the group ID in the following commands.
n DELETE FROM APPAUTHORIZATION WHERE APPID = 's61' and GRPID = 'RISCRM' ;

('s61','db.pool.name','RISCRM','default','Y');
('s61','app.allowed.list','RISCRM','159','Y');
('s61','indexer.fixed.cols.from','RISCRM','crm','Y');
('s61','indexer.timeline.group.from','RISCRM','crm','Y');
('s61','indexer.other.cols.from','RISCRM','crm','Y');
n Commit ;
6. Modify the CATALINA_HOME/webapps/ROOT/imaslight.properties file, as shown:

a. Important: If you have already added the configuration that are available in this step while
upgrading the Trace application, ignore this step. Under the [RPCServers] section, configure the
count of indexers. For example, if you want to configure one indexer, update the following
configuration, as shown:
rpc.servers=1
n Add the following configurations for each indexer that you want to configure:
Note:The following configurations are applicable when you have only one indexer. If there are
multiple indexers, you must ensure that similar configuration for each indexer is added.
n rpc.server.1.host=127.0.0.1
n rpc.server.1.name=RISIndexer
n rpc.server.1.type=1
n rpc.server.1.port=10538
n rpc.server.1.module=300
n rpc.server.1.size=1
b. Important: Do not add the ristracer-indexers.module.list=300 configuration if you have already

added the configuration while upgrading the Trace application.
Add or update (if required) the following configurations under the [Indexer] section:
# CRM specific custom input/output section
#-----------------------------------------

crm.fixed.output.column.names=DateTime,TxnDetails
crm.fixed.output.column.descriptions=DateTime,TxnDetails
crm.fixed.input.column.names=IMSI,MSISDN
crm.fixed.input.column.descriptions=IMSI,MSISDN
# CRM specific custom groups
#---------------------------
crm.timeline.group.names=Registration,Voice,Data,SMS
crm.timeline.group.descriptions=Registration,Voice,Data,SMS
# CRM specific other column (descriptions)
#-----------------------------------------
crm.other.column.names=Startdate,Enddate,Product,Column,Value,Search,Other
Filters,Assess,TimeLine,Event History,Application Filters,Application,Transaction
Details,Event Details,Apply,Export CSV,Table,Zoom In,Zoom Out,Move Left,Move Right,Show
Event,Export Event As CSV,Export PCAP,Clear
crm.other.column.descriptions=From,To,Product,Column,Value,Search,Other Filters,Roaming
Activity,TimeLine,Event History,Application Filters,Application,Transaction
Details,Event Details,Apply,Export CSV,Table,Zoom In,Zoom Out,Move Left,Move Right,Show
Event,Export Event As CSV,Export PCAP,Clear
# Configure below entry for comma separated list of rpc module ids of indexers
configured and to be queried
#--------------------------------------------------------------------------------------
--------------------
ristracer-indexers.module.list=300
7. Make sure that the riscrm.properties and ris22.jar files are available in the ROAMWARE_
HOME/indexerConfig and CATALINA_HOME/webapps/ROOT/WEB-INF/lib directories respectively.
Important
Make sure that the riscrm.properties and ris22.jar files are from the latest RCEM 2.2 package
that you have installed. In addition, you might ignore the ris22.jar file if you have already fetched
the latest file from the RCEM 2.2 package while upgrading the Trace application.
8. Restart the Tomcat server.

C
Configuring settings to view

DIAMETER pcap in Wireshark

Wireshark is tool that helps you analyze fields of packets that several protocols support. Wireshark parses the
packets and displays, in its GUI, the meaning of each packet fields. This appendix section contains settings that
you must configure to view DIAMETER pcap.
To configure settings
1. Open Wireshark and click Edit.
2. Click Preferences. The Wireshark . Preferences screen appears.
3. On the left, expand Protocol and click DLT_USER.
4. On the right, for Encapsulations Table, click Edit.The User DLTS Table screen appears.
5. Click the ( ) Create a new entry button. A new appears inside the table.
6. Under the DLT column, double click the value to enable a drop-down list, and then select the DLT=152
option.
7. Under the Payload protocol column, double click the blank value to enable the text box, and then type
diameter.
8. Click OK and then click OK to apply the settings.
You have successfully configured the DIAMETER pcap settings.
D
What's new in this guide

This topic summarizes the new, modified, and deprecated features in each release of the RCEM 2.2
application and provides pointers to additional information about these features. Where appropriate, it
discusses the enhancements made to this document itself.
This chapter contains the following topic:
n "R190301 - Initial release" on page 212

n "R181218 - Revised release" on page 213
R190301 - Initial release

This topic summarizes the new, modified, and deprecated features in the initial release of RCEM 2.2.R190301,
provides pointers to additional information about these features, and discusses enhancements made to this
document.

Appendix D - What's new in this guide
n "Additions" on page 213

n "Modifications" on page 213
n "Deprecations" on page 213
n "Documentation enhancements" on page 213
Additions
No feature has been added in this release of the RCEM application.
Modifications
Information about generating a trace report has been modified. Example, screen-shots, related information have
been updated, restructuring has been done, and new protocols have been added. For more information, refer
"Trace " on page 179.
Deprecations
No feature has been deprecated in this release of the RCEM application.
Documentation enhancements
The following documentation enhancements have been made in this release of the RCEM application:
n Information about the Interconnect Voice dashboard has been added. For more information, refer
"Interconnect Voice dashboard" on page 152.
n Information about the Hub dashboard has been deprecated.
n Information about generating a CRM report has been modified. Example, screen-shots and the related
information have been updated. For more information, refer "CRM" on page 192.
n Information about modifying and configuring a GRQ SLA configuration has been modified. Example,
information about MOS has been added. For more information, refer "Configuring GRQ SLAs" on page
157.
n Screen-shot of the GRQ dashboard has been updated. Example, the country-wise distribution has been
modified from percentile to percentage basis. For more information, refer "Widgets in the GRQ
n Information about managing class of subscribers has been modified. For more information, refer to
"Managing classes of subscribers" on page 24.
n Information about the time-granularity of 15 minutes has been added in the "Generating dashboards" on
page 27 section.
n Information about upgrading the Trace application has been modified. Example, fields under the
[Indexer] section have been updated. For more information, refer to "Upgrading the Trace application"
on page 205.
R181218 - Revised release

This topic summarizes the new, modified, and deprecated features in the revised release of RCEM
2.2.R181218, provides pointers to additional information about these features, and discusses enhancements
made to this document.


Additions
No feature has been added in this release of the RCEM application
Modifications
The functionality of the RI_COS_MASTER database table has been modified in this release of the RCEM
application. For information about the functionality of RI_COS_MASTER database table, refer "Managing classes of
subscribers" on page 24.
Deprecations
The following documentation enhancements have been made in this release of the RCEM application:
n Information about the RCEM architecture has been added. For more information, refer "Introduction to
the RCEM application" on page 15.
n Information about a note specifying the feed coming from the Anritsu probe has been added. For more
information, refer "Trace " on page 179.

This topic summarizes the new, modified, and deprecated features in the initial revised of RCEM 2.2.R181218,
document.

Additions

Modifications
No feature has been modified in this release of the RCEM application.
Deprecations
Section for the MAP Performance dashboard has been added. For more information, refer "MAP Performance

document.

Additions
Modifications
Deprecations
This document has been rebranded.


document.

Additions
Modifications
Deprecations
Section for Registration dashboards has been updated. For example, added the information for reasons for
registration latency, reasons why an operator deploys SoR, and so on. For more information, refer "Registration
dashboards" on page 79.

document.


Additions
n SMS Status filter has been added for the SMS Usage dashboard. For more information, refer "Filters for
generating the SMS usage dashboard" on page 104.
n Dynamic threshold learning feature has been added. For more information, refer "Dynamic threshold
learning" on page 158.
n Masking feature has been added. For more information, refer to the description for IMSI field in "Trace "
on page 179.
Modifications
Deprecations
Definition for PDD and ASR have been updated. For more information, refer "Configuring GRQ SLAs" on page
157.

document.

Additions
Trace application has been upgraded. For information about how to upgrade the Trace application, refer
"Upgrading the Trace application" on page 205.
Modifications
Deprecations

No document-specific enhancement has been made in this release of the RCEM application. However, details
about features added, modified, or deprecated in this release are documented appropriately, as discussed in
the previous sections.

document.

Additions
n Network R-CX dashboard has been added. For more information, refer "Network R-CX dashboard for
the Steer to Quality feature" on page 140.
Modifications
Deprecations



Additions
Modifications
Deprecations
Description for the REGISTRATION FAILURE REASONS widget has been updated. For more information, refer
to Table 27 on page 89.

document.

Additions
n The RCEM application supports weighted score for the NQS dashboard. For more information, refer
"Computing network quality score" on page 129.
n DIAMETER Performance dashboard has been added. For more information, refer "DIAMETER
Performance dashboard" on page 51.
Modifications

Deprecations


Additions
Modifications
Deprecations
The Mapping CoSes to RCEM users section has been added.

document.


Additions
The RCEM application supports the Alliance option, as well, as a filter to generate applicable dashboards such
as SMS usage, MAP transaction failure, and so on. For more information, refer to "Filters available in the MAP
transaction failure dashboard" on page 29.
Modifications
Deprecations


Additions
Modifications

Deprecations
The following section has been added:
n "Configuring settings to view DIAMETER pcap in Wireshark" on page 211
End of document

RCEM 2.2 Ag Latest PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RCEM 2.2 Ag Latest PDF

Uploaded by

Copyright:

Available Formats

Roaming Customer Experience

Date Revision no. Description

Apr-23-2019 01 Initial release.

Introduction to the RCEM application 15

Managing classes of subscribers 24

Confidential and proprietary information of Mobileum, Inc. v

KPIs in the Roamer trip dashboard 109

Configuring GRQ SLAs 157

Confidential and proprietary information of Mobileum, Inc. vi

How does the dynamic threshold learning feature work? 159

Configuring CoS thresholds 166

Configuring thresholds and alerts 170

Generating trace reports 179

Correlating alarms in the alarm history table 203

Upgrading the Trace application 205

Configuring settings to view DIAMETER pcap in Wireshark 211

What's new in this guide 212

Confidential and proprietary information of Mobileum, Inc. vii

R181218 - Revised release 215

Confidential and proprietary information of Mobileum, Inc. viii

Purpose of this guide

n File and directory names

Confidential and proprietary information of Mobileum, Inc. x

How to contact Mobileum

Confidential and proprietary information of Mobileum, Inc. xi

This topic contains the following subtopics:

n "Supported administrative roles" on page 12

Supported administrative roles

For more information about this administrative role, refer to the

n Generate and view the RCEM application reports.

1. Logging in to Mobileum Administrator

To log in to Mobileum Administrator Studio, perform the following steps:

1. Open a web browser window.

Confidential and proprietary information of Mobileum, Inc. 13

In the preceding URL, replace the following:

Security guidelines for using Mobileum

n Do not share the browser session with other applications.

Logging out of Mobileum Administrator

Confidential and proprietary information of Mobileum, Inc. 14

Introduction to the RCEM application

Components used by the RCEM application

Confidential and proprietary information of Mobileum, Inc. 16

n Summary file (TDR)

Confidential and proprietary information of Mobileum, Inc. 17

n To query about a CoS of a specific subscriber or various features, when required

Confidential and proprietary information of Mobileum, Inc. 18

Modules in the RCEM application

n SS7 (generated by SS7TxnWriter)

Confidential and proprietary information of Mobileum, Inc. 19

Confidential and proprietary information of Mobileum, Inc. 20

The RCEM dashboards perform the following functions:

n Computes the KPIs based on the threshold that you configure

The Trace application performs the following functions:

n Start Date (DD/MM/YYYY) & End Date (DD/MM/YYYY)

Confidential and proprietary information of Mobileum, Inc. 21

n Start Date (DD/MM/YYYY) & End Date (DD/MM/YYYY)

Where the RCEM application fits in the

The RCEM application also communicates with the following components:

Confidential and proprietary information of Mobileum, Inc. 22

F I GU R E 3 : W H ER E THE RCEM A PPL I C A T I ON F I T S I N T H E N ET W OR K

Confidential and proprietary information of Mobileum, Inc. 23

Managing classes of subscribers

Mapping CoSes to RCEM users