An Oracle White Paper November Typical Key Performance Indicator Reports for Performance Intelligence Centers

(1)

An Oracle White Paper

November 2013

Typical Key Performance Indicator Reports

for Performance Intelligence Centers

(2)

Disclaimer

The following is intended to outline our general product direction. It is intended for information purposes

only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code,

or functionality, and should not be relied upon in making purchasing decisions. The development, release,

and timing of any features or functionality described for Oracle’s products remains at the sole discretion

of Oracle.

(3)

Executive Overview ... 1

Introduction ... 1

1.0 Service Overview ... 2

1.1 Available Services ... 2

1.2 Presentation of Reports ... 2

2.0 Reports Descriptions ... 3

2.1 Call QoS Reports ... 3

2.2 Roaming QoS Reports ... 10

2.3 Network Interconnection Reports ... 32

2.4 2G Core Network Reports ... 33

2.5 Mobile Number Portability Reports ... 35

2.6 Network Security and Fraud Detection Reports ... 37

2.7 Accounting Reports ... 40

2.8 LTE Reports ... 42

(4)

Executive Overview

This document helps performance intelligence center (PIC) customers derive more value from

their current system by giving them access to Oracle expertise in implementing a broad set of

key performance indicator (KPI) reports.

Introduction

The PIC system enables customers to configure fully customized KPI reports, to generate

alarms, and to get real time curves. These features can be linked together to provide the best

tools to manage operations the best way. From this framework, it is possible to configure a

cost effective system tailored to meet individual needs.

Customers without available resources to set up reports by themselves may obtain additional

support to configure their KPI reports. In those cases, Oracle provides KPI reports

(5)

1.0 Service Overview

1.1 Available Services

The set of services provided by Oracle usually comprises the following elements:

•

Detailed Scope of Work definition

•

Configuration of

•

Enrichments

•

KPI records

•

Alarms

•

Dashboards

•

Datafeeds

•

Documentation, acceptance test, and handoff

When needed, the following services may be included:

•

System audit

•

System reengineering

•

System expansion

The KPI reports configured can be used as a model to cover other needs autonomously. But Oracle

Communications products can also handle the entire KPI lifecycle if needed.

1.2 Presentation of Reports

This KPI catalog defines KPI records that can be configured in the context of KPI services. It is the

base for writing a Scope of Work for such services. Usually the most difficult task is to define the

dimensions. This catalog provides examples for interesting dimensions, but Oracle service

professionals can also perform pre-studies to refine the dimensions in the actual context of a network

and traffic. While each project is unique at the detailed level, Oracle service professionals bring the

knowledge of multiple engagements to each project.

This catalog covers use cases that are identified as providing business benefit when applied in the right

context. The catalog will grow over time with new versions published regularly.

(6)

2.0 Reports Descriptions

2.1 Call QoS Reports

2.1.1 ISUP QOS Report

The

business driver for this report is to manage the Quality of Service (QOS) of calls managed by

ISUP.

The record dimensions are directions or point codes. The results can be used to avoid losing calls and

to use Network Elements better. This report can be used in different contexts:

•

Network wide per network element

•

International interconnection

•

Long distance interconnection

•

Specific traffic only

As a

prerequisite, the business context shall be agreed with the customer. Several contexts would

require several KPI reports. At least one of the following builders is required:

•

SS7 ISUP ETSI

•

SS7 ISUP ANSI

The service package would require a review in case ANSI and ETSI need to be managed.

The monitoring coverage shall match the agreed business context.

(7)

ISUP QoS

MEASURES

• Call Attempts: Simple Data Counter, Total Call Attempts • ASR: # Answered / # Attempts

• NER: Net Success / # Attempts

• Net Success = Call is Answered or Cause Family = NA or SSB or HE

• Unsuccessful calls due to customer (cause 17,18 and 19) • Unsuccessful calls due to customer and/or network

(cause 1, 3, 4, 21, 22, 27, 28, 29, 31) • Unsuccessful calls due to resource unavailable

(cause 34 to 47)

• Unsuccessful calls due to service or option not available (cause 50 to 63)

• Unsuccessful calls due to service or option not implemented (cause 65 to 79)

• Unsuccessful calls due to invalid message (cause 87 to 95) • Unsuccessful calls due to protocol error (cause 102 to 11) • Unsuccessful calls due to interworking (cause 127)

• Percentage of unsuccessful calls due to customer (cause 17,18 and 19)

• Percentage of unsuccessful calls due to customer and/or network (cause 1, 3, 4, 21, 22, 27, 28, 29, 31)

• Percentage of unsuccessful calls due to resource unavailable (cause 34 to 47)

• Percentage of unsuccessful calls due to service or option not available (cause 50 to 63)

• Percentage of unsuccessful calls due to service or option not implemented (cause 65 to 79)

• Percentage of unsuccessful calls due to invalid message (cause 87 to 95)

• Percentage of unsuccessful calls due to protocol error (cause 102 to 11)

• Percentage of unsuccessful calls due to interworking (cause 127)

• Average setup time • Average conversation time • Average length of call

DIMENSIONS

The customer shall determine which of the following dimensions shall be used: • Operator (reference data to be provided by the customer)

• Point codes • Country • Other directions

The customer shall provide the reference data.

Note 1: The dimensions shall be focused on the most important ones from a business perspective. It is possible to think about a

pre-study to identify those ones.

Note 2: For directions it is important to identify specific problems due to national numbering plan, carrier prefixes, or others.

AGGREGATION PERIOD RETENTION PERIOD

15 minutes 1 month

DASHBOARD ALARMS

Global ASR, NER and number of calls versus time Per NER: • Minor if < 80% • Major if < 70%

(8)

2.1.2 SIP/SIP-T QOS Report

The

business driver for this report is to manage the QoS of calls managed by SIP/SIP-T.

The record dimensions are directions or IP addresses. The results can be used to avoid losing calls and

to use Network Elements better. This report can be used in different contexts:

•

Network wide per network element

•

International interconnection

•

Long distance interconnection

•

Specific traffic only

As a

prerequisite, the customer shall agree with the business context. Several contexts would require

several KPI reports. At least one of the following builders is required:

•

SIP

•

SIP-T

(9)

SIP/SIP-T QoS

MEASURES

• Attempts (simple counter)

• Successful (filtered counter on “Status Code” set to “OK”) • ASR (ratio Successful/Attempts)

• Net Successful (filtered counter on “Status Code” set to OK or Busy here or Invite aborted or request terminated) (**needs to be refined based on services provided by the customer)

• NER (ratio net Successful/Attempts)

• Switch Problem (filtered counter on “Status Code” set to “5??”

• Total Conversation time (cumulative counter on “Conversation Time” field Transaction Duration • Average Conversation Time (ratio Total Conversation Time / Invites)

• Average Transaction Duration (ratio Transaction Duration / Attempts)

Note: Measures are made from a SIP perspective. For SIP-T, the protocol provides also the “Cause Value” according to the ETSI

Q.850. Oracle is ready to use also this information to refine the ASR/NER measures.

DIMENSIONS

It shall be determined with the customer which of the following dimensions shall be used: • Operator (reference data to be provided by the customer)

• IP addresses • Country • Other directions

prestudy to identify those ones.

15 minutes 1 month

Global ASR, NER, and number of calls versus time Per NER: • Minor if < 80% • Major if < 70%

Those standard values can be adjusted afterward either globally or per dimension.

(10)

2.1.3 SIP Registration Report

The

business driver for this report is the need to ensure registration. On SIP, the registration is

important to access the service. This report can be used to detect if and where registration is failing.

As a

prerequisite, the SIP builder is required.

SIP Registration

MEASURES

• Total Registrations - (REGISTER) • Total Successful Registrations • Total Unsuccessful Registrations • Total Forbidden

• Total Unauthorized

• Percentage of Successful Registrations – Total Successful Registrations/Total Registrations • Percentage of Unsuccessful Registrations – Total Unsuccessful Registrations/Total Registrations • Percentage Forbidden

• Percentage Unauthorized • Total transaction time • Average transaction time

DIMENSIONS

It shall be determined with the customer which of the following dimensions shall be used: • IP source

• IP destination

• Top 20 IP source not OK • Top 20 URI (field “to” ) not OK

• Addresses may be enriched to get operator or other business information The customer shall provide the reference data for the enrichment.

Note: The dimensions shall be focused on the most important ones from a business perspective. It is possible to think about a

15 minutes 1 month

Global registration success rate versus time Threshold to be determined on the registration success per operator

(11)

2.1.4 SIP Method Report

The

business driver for this report occurs when the SIP method error surveillance shows possible

internetworking issues between network elements.

As a

prerequisite, the SIP builder is required.

SIP Method

MEASURES

• Total session

• Total session due to “Bad Request”- 400 or “Method Not Allowed”- 405 or “Not Acceptable”- 406 • Total sessions tear down due to “Bad Request”- 400

• Total sessions tear down due to “Method Not Allowed”- 405 • Total sessions tear down due to “Not Acceptable”- 406

• Percentage of session tear down due to “Bad Request” – Total sessions tear down due to Bad Request /Total sessions • Percentage of session tear down due to “Method Not Allowed” – Total sessions tear down due to Method Not Allowed /Total

sessions

• Percentage of session tear down due to “Not Acceptable” – Total sessions tear down due to Not Acceptable /Total sessions • Percentage of session due to “Bad Request”- 400 or “Method Not Allowed”- 405 or “Not Acceptable”- 406

DIMENSIONS

It shall be determined with the customer which of the following dimensions shall be used: • IP source

• IP destination

• Top 20 IP source with 400 or 405 or 406 • Top 20 URI (field “to” ) with 400 or 405 or 406

• Addresses may be enriched to get operator or other business information The customer shall provide the reference data for the enrichment.

15 minutes 1 month

Global curves with 400 or 405 or 406 over time Threshold to be determined on percentage of session due to “Bad Request”- 400 or “Method Not Allowed”- 405 or “Not Acceptable”- 406

(12)

2.1.5 BICC QoS Report

The

business driver for this report is to manage the QoS of calls managed by the BICC.

The record dimensions are directions or point codes. The results can be used to avoid losing calls and

to use Network Elements better. This report can be used in the following contexts:

•

Network wide per network element

•

International interconnection

•

Long distance interconnection

•

Specific traffic only

As a

prerequisite, the BICC ANSI or BICC ETSI XDR builder is required.

BICC QoS

MEASURES

• Net Success = Call is Answered or Cause Family = NA or SSB or HE • Unsuccessful calls due to customer (cause 17,18 and 19)

• Unsuccessful calls due to customer and/or network (cause 1, 3, 4, 21, 22, 27, 28, 29, 31) • Unsuccessful calls due to resource unavailable (cause 34 to 47)

• Unsuccessful calls due to service or option not available (cause 50 to 63) • Unsuccessful calls due to service or option not implemented (cause 65 to 79) • Unsuccessful calls due to invalid message (cause 87 to 95)

• Unsuccessful calls due to protocol error (cause 102 to 11) • Unsuccessful calls due to interworking (cause 127)

• Percentage of unsuccessful calls due to customer (cause 17,18 and 19)

• Percentage of unsuccessful calls due to customer and/or network (cause 1, 3, 4, 21, 22, 27, 28, 29, 31) • Percentage of unsuccessful calls due to resource unavailable (cause 34 to 47)

• Percentage of unsuccessful calls due to service or option not available (cause 50 to 63) • Percentage of unsuccessful calls due to service or option not implemented (cause 65 to 79) • Percentage of unsuccessful calls due to invalid message (cause 87 to 95)

• Percentage of unsuccessful calls due to protocol error (cause 102 to 11) • Percentage of unsuccessful calls due to interworking (cause 127) • Average setup time

• Average conversation time • Average length of call

(13)

BICC QoS (continued)

DIMENSIONS

It shall be determine with the customer which of the following dimensions shall be used: • Operator (reference data to be provided by the customer)

Note 2: for directions it is important to identify specific problems due to national numbering plan, carrier prefixes, or others.

15 minutes 1 month

2.2 Roaming QoS Reports

2.2.1 Roaming Access Reports

2.2.1.1 Roaming In – Visitor Network QoS – Update Location Report

The

business driver for this report is to manage QoS of inbound roaming traffic.

For inbound roamers, this report checks that services can be accessed correctly from the GSM core

network perspective, based on the Update Location operation. Update Location is a critical MAP

Operation which needs to work properly to access voice and data services. In the context of roaming

failures, it may reveal configuration issues between roaming partners.

As a

prerequisite, the record dimensions are country/operators. This report must only be used on

(14)

Roaming In – Visitor Network QoS – Update Location

MEASURES

• Total number of Update Locations (simple counter) • Number of Update Location OK

• Number of Update Location NOK

• Ratio of number of Update Locations OK/Total number of Update Locations

• Number of Update Location failed due to “Data Missing”

• Number of Update Location failed due to “Roaming Not Allowed”

• Number of Update Location failed due to “System Failure” • Number of Update Location failed due to “Unexpected Data

Value”

• Average access time

DIMENSIONS

• Country/Operator based on Roamer IMSI analysis

Both dimensions are mixed together and the list shall be provided by the customer.

Note 1: The dimensions shall be selected from a business perspective. A prestudy might be required to identify the relevant

dimensions.

Note 2: As a variant, country and operator might be separated.

15 minutes 1 month

Global ER (Efficiency Ratio) and number of attempts versus time

Per ER (Efficiency Ratio): • Minor if < 80% • Major if < 70%

2.2.1.2 Roaming In – Visitor Network QoS – Top Ten – Update Location Report

The

business driver for this report is to manage Quality of Service of inbound roaming traffic.

For inbound roamers, it checks that services can be accessed correctly from the GSM core network

perspective based on the Update Location operation. Update Location is a critical MAP Operation

which needs to work properly to access voice and data services. In the context of roaming failures, it

may reveal configuration issues between roaming partners.

As a

prerequisite, the record dimensions are country/operators. This report must be only used on

(15)

Roaming In – Visitor Network QoS – Top 10 – Update Location

MEASURES

• Ratio of number of Update Locations OK/Total number of Update Locations • Number of Update Location failed due to “Roaming Not Allowed”

• Number of Update Location failed due to “System Failure” • Number of Update Location failed due to “Data Missing”

• Number of Update Location failed due to “Unexpected Data Value” • Average access time

DIMENSIONS

• Top 10 Country/Operator based on Roamer IMSI analysis

15 minutes 1 month

(16)

2.2.1.3 Roaming In – Visitor Network QoS – IMSI Report

The

business driver for this report is to manage Quality of Service of inbound roaming traffic.

For inbound roamers, it checks that services can be accessed correctly from the GSM core network

perspective based on the Update Location operation. Update Location is a critical MAP Operation

which needs to work properly to access voice and data services. In the context of roaming failures, it

may reveal configuration issues between roaming partners.

As a

prerequisite, this report must be only used on MAP roaming traffic at the interconnection. The

MAP ETSI builder is required.

Roaming In – Visitor Network QoS – IMSI

MEASURES

• Ratio of Number of Update Locations OK/Total number of Update Locations • Number of Update Location failed due to “Roaming Not Allowed”

• Number of Update Location failed due to “System Failure” • Number of Update Location failed due to “Data Missing” • Number of Update Location failed due to “Unexpected Data Value” • Average access time

DIMENSIONS

• Top N IMSI

15 minutes 1 month

(17)

2.2.1.4 Roaming In – Steering of Roaming (SoR) Report

The

business driver for this report is to identify service providers using SoR.

This report identifies service providers probably using SoR. SoR KPIs apply to roaming in traffic. It

helps to detect any new steering, and eventually renegotiate roaming agreements. Mobile operators may

prefer roaming partners in a given country, in particular when they are part of larger groups. In such

cases, SoR is often used. SoR consists of aborting Update Locations several times before allowing

them to be successful. SoR is guided by the GSMA, and only some predefined failures are allowed.

These are analyzed by this report.

As a

prerequisite, the MAP ETSI builder is required.

Roaming In – Steering of Roaming (SoR)

MEASURES

• Number of Update Location failed due to “Roaming Not Allowed” or “System Failure” or “Unexpected Data Value”

• Steering of roaming ratio number of Update Location failed due to “Roaming Not Allowed,”, “System Failure”, “Unexpected Data Value” / Total number of Update Locations

DIMENSIONS

• Top 20 among 500 Country/Operator having the highest steering of roaming ratio • Country/Operator is based on enrichment

The two dimensions are mixed together and the list shall be provided by the customer.

1 hour 1 month

(18)

2.2.1.5 Roaming Out – Visitor Network QoS – Update Location Report

The

business driver for this report is to manage QoS of outbound roaming traffic.

This report ensures that services for outbound roamers can be accessed from a core network

perspective, based on the Update Location operation. Update Location is a critical MAP Operation

that needs to work properly to access voice and data services. In the context of roaming failures, it may

reveal configurations between roaming partners.

As a

prerequisite, this record dimensions are country/operators. This report must only be used on

MAP roaming traffic at the interconnection. The required builder is MAP ETSI.

Roaming Out – Visitor Network QoS – Update Location

MEASURES

DIMENSIONS

• Country/Operator based on GTT analysis

Both dimensions are mixed together and the list shall be provided by the customer.

Note 1: The dimensions shall be selected from a business perspective. A prestudy might be required to identify the relevant

dimensions.

Note 2: As a variant, country and operator might be separated.

15 minutes 1 month

(19)

2.2.1.6 Roaming Out – Visitor Network QoS – Top Ten – Update Location Report

The

business driver for this report is to manage QoS of outbound roaming traffic.

This report ensures that services for outbound roamers can be accessed from a core network

perspective, based on the Update Location operation. Update Location is a critical MAP Operation

that needs to work properly to access voice and data services. In the context of roaming failures, it may

reveal configurations between roaming partners.

As a

prerequisite, the record dimensions are country/operators. This report must only be used on

MAP roaming traffic at the interconnection. The required builder is MAP ETSI.

Roaming Out – Visitor Network QoS – Top Ten – Update Location

MEASURES

DIMENSIONS

Top 10 Country/Operator based on GTT analysis

15 minutes 1 month

(20)

2.2.1.7 Roaming Out – Visitor Network QoS – IMSI Report

The

business driver for this report is to manage QoS of outbound roaming traffic.

This report ensures that services for outbound roamers can be accessed from a core network

perspective, based on the Update Location operation. Update Location is a critical MAP Operation

that needs to work properly to access voice and data services. In the context of roaming failures, it may

reveal configurations between roaming partners.

As a

prerequisite, the report must only be used on MAP roaming traffic at the interconnection. The

required builder is MAP ETSI.

Roaming Out – Visitor Network QoS – IMSI

MEASURES

DIMENSIONS

• Top N IMSI

15 minutes 1 month

(21)

2.2.1.8 Roaming Out – Anti-steering of Roaming Report

The

business driver for this report is to identify service providers using SoR.

This report identifies service providers probably using anti-steering. SoR KPIs apply to roaming in

traffic. Anti-steering is not allowed. When applying steering, the Update Location success should drop

to a very low rate. When it is low, but over a certain percentage depending on steering strategy, this is

abnormal and requires analysis. SoR consists of aborting Update Locations several times before

allowing them to be successful.

As a

prerequisite, the required builder is MAP ETSI.

Roaming Out – Antisteering of Roaming

MEASURES

• Number of Update Location failed due to “Roaming Not Allowed” or “System Failure” or “Unexpected Data Value”

• Steering of roaming ratio number of Update Location failed due to “Roaming Not Allowed,”, “System Failure”, “Unexpected Data Value” / Total number of Update Locations

DIMENSIONS

• Top 20 among 500 Country/Operator having the highest steering of roaming ratio • Country/Operator is based on enrichment

The two dimensions are mixed together and the list shall be provided by the customer.

1 hour 1 month

None None

2.2.2 Roaming SMS Reports

2.2.2.1 Roaming In – MAP MO SMS Transaction Efficiency and Delay Report

The

business driver for this report is to manage QoS of SMS MO traffic.

SMS is a very popular service and it is critical for the service provider to control it. This is particularly

important for identified subscribers and for roaming services.

Three major steps to consider are

1. Submitting the SMS to the SMSC (also corresponding to the MO / Mobile Originated SMS)

2. Retrieving the information to route the SMS to the final destination

(22)

Several contexts (or use cases) shall be considered as well, by changing the following dimensions:

•

Internal SMS traffic

•

National SMS traffic

•

International SMS traffic

This report checks QoS for step 1, SMS MO.

As a

prerequisite, the required builder is MAP ETSI.

Roaming In – MAP MO SMS Transaction Efficiency and Delay

MEASURES

• Total SMS MO (simple counter)

• Successful SMS MO (No SMS, SCCP, TCAP, User and Provider error) • SMS Success ratio (Successful SMS MO/ Total SMS MO)

• Total transaction time (Cumulative counter for the transaction time field) • Average transaction time (Total transaction time / Total SMS MO)

• Maximum transaction time (Maximum value counter on transaction time field)

Note: The SMS operations are identified with OpCodes = (Forward SM and TPMTI = SMS SUBMIT) or MO Forward SM

DIMENSIONS

One of these dimensions shall be selected

• Country/Operator based on GTT analysis, which shall be selected for the roaming case. For roaming out, the SMSC belongs to the home network and the visited MSC belongs to a foreign network. For roaming in, this is the opposite.

• Home MSC (identified by Point Code or GTT depending on routing options) • Home SMSC (identified by Point Code or GTT depending on routing options)

1 hour 1 month

Global SMS MO Success Rate and number Minor and major alarms on the SMS MO Success Rate per selected dimensions

(23)

2.2.2.2 Roaming In – MAP MT SMS Transaction Efficiency and Delay Report

The

business driver for this report is to manage QoS of SMS MT traffic.

SMS is a very popular service and it is critical for the service provider to control it. This is particularly

important for identified subscribers and for roaming services.

Three major steps to consider are

1. Submitting the SMS to the SMSC (also corresponding to the MO / Mobile Originated SMS)

2. Retrieving the information to route the SMS to the final destination

3. Delivering the SMS to the final destination (also corresponding to the MT / Mobile

Terminated SMS)

Several contexts (or use cases) shall be considered as well, by changing the following dimensions:

•

Internal SMS traffic

•

National SMS traffic

•

International SMS traffic

This report checks QoS for step 3, SMS MT.

As a

prerequisite, the required builder is MAP ETSI.

Roaming In – MAP MT SMS Transaction Efficiency and Delay

MEASURES

• Total SMS MT (simple counter)

• Successful SMS MT (No SMS, SCCP, TCAP, User and Provider error) • SMS Success ratio (Successful SMS MT/ Total SMS MO)

• Total transaction time (Cumulative counter for the transaction time field) • Average transaction time (Total transaction time / Total SMS MT)

Note: The SMS operations are identified with OpCodes = (Forward SM and TPMTI = SMS DELIVER) or MT Forward SM

DIMENSIONS

• Home MSC (identified by Point Code or GTT depending on routing options) • Home SMSC (identified by Point Code or GTT depending on routing options) • Top N IMSI

1 hour 1 month

(24)

2.2.2.3 Roaming Out – MAP MO SMS Transaction Efficiency and Delay Report

The

business driver for this report is to manage QoS of SMS MO traffic.

SMS is a very popular service and it is critical for the service provider to control it. This is particularly

important for identified subscribers and for roaming services.

Three major steps to consider are

1. Submitting the SMS to the SMSC (also corresponding to the MO / Mobile Originated SMS)

2. Retrieving the information to route the SMS to the final destination

3. Delivering the SMS to the final destination (also corresponding to the MT / Mobile

Terminated SMS)

Several contexts (or use cases) shall be considered as well, by changing the following dimensions:

•

Internal SMS traffic

•

National SMS traffic

•

International SMS traffic

This report checks QoS for step 1, SMS MO.

As a

prerequisite, the required builder is MAP ETSI.

Roaming Out – MAP MO SMS Transaction Efficiency and Delay

MEASURES

• Total SMS MO (simple counter)

• Successful SMS MO (No SMS, SCCP, TCAP, User and Provider error) • SMS Success ratio (Successful SMS MO/ Total SMS MO)

• Total transaction time (Cumulative counter for the transaction time field) • Average transaction time (Total transaction time / Total SMS MO)

Note: The SMS operations are identified with OpCodes = (Forward SM and TPMTI = SMS SUBMIT) or MO Forward SM

DIMENSIONS

1 hour 1 month

(25)

2.2.2.4 Roaming Out – MAP MT SMS Transaction Efficiency and Delay Report

The

business driver for this report is to manage QoS of SMS MT traffic.

SMS is a very popular service and it is critical for the service provider to control it. This is particularly

important for identified subscribers and for roaming services.

Three major steps to consider are

1. Submitting the SMS to the SMSC (also corresponding to the MO / Mobile Originated SMS)

2. Retrieving the information to route the SMS to the final destination

3. Delivering the SMS to the final destination (also corresponding to the MT / Mobile

Terminated SMS)

Several contexts (or use cases) shall be considered as well, by changing the following dimensions:

•

Internal SMS traffic

•

National SMS traffic

•

International SMS traffic

This report checks QoS for step 3, SMS MT.

As a

prerequisite, the required builder is MAP ETSI.

Roaming Out – MAP MT SMS Transaction Efficiency and Delay

MEASURES

• Total SMS MT (simple counter)

• Successful SMS MT (No SMS, SCCP, TCAP, User and Provider error) • SMS Success ratio (Successful SMS MT/ Total SMS MO)

• Total transaction time (Cumulative counter for the transaction time field) • Average transaction time (Total transaction time / Total SMS MT)

Note: The SMS operations are identified with OpCodes = (Forward SM and TPMTI = SMS DELIVER) or MT Forward SM

DIMENSIONS

• Home MSC (identified by Point Code or GTT depending on routing options) • Home SMSC (identified by Point Code or GTT depending on routing options) • Top N IMSI

1 hour 1 month

(26)

2.2.2.5 Map SRI for SM Report

The

business driver for this report is to manage QoS of SMS SRI for SM traffic.

SMS is a very popular service and it is critical for the service provider to control it. This is particularly

important for identified subscribers and for roaming services.

Three major steps to consider are

1. Submitting the SMS to the SMSC (also corresponding to the MO / Mobile Originated SMS)

2. Retrieving the information to route the SMS to the final destination

3. Delivering the SMS to the final destination (also corresponding to the MT / Mobile

Terminated SMS)

Several contexts (or use cases) shall be considered as well, by changing the following dimensions:

•

Internal SMS traffic

•

National SMS traffic

•

International SMS traffic

This report checks QoS for step 2, SRI for SM report.

As a

prerequisite, the required builder is MAP ETSI.

Map SRI for SM

MEASURES

• Total SRI for MS (simple counter)

• Successful SRI for SM (No SMS, SCCP, TCAP, User and Provider error) • SRI for SM Success ratio (Successful SRI for SM / Total SRI for SM) • Total transaction time (Cumulative counter for the transaction time field) • Average transaction time (Total transaction time / Total SRI for SM) • Maximum transaction time (Maximum value counter on transaction time field)

DIMENSIONS

1 hour 1 month

Global SMS MT Success Rate and number Minor and major alarms on the SMS MT Success Rate per selected dimensions

(27)

2.2.3 Roaming Data Reports

2.2.3.1 Roaming In – GTP Context Creation Report

The

business driver for this report is to create a PDP context during the setup of a data service.

This procedure creates a GTP tunnel that will be used later for the service. From a roaming

perspective, this is where interaction between networks starts in the context of data service. Thus, it is

important to survey that PDP context creation is working well in both networks and countries.

As a

prerequisite, the required builder is Gp TDR.

Roaming In – GTP Context Creation

MEASURES

• Total Create PDP (filter on transaction type = create PDP context)

• Successful Create PDP (filtered counter on success field set to Yes and transaction type = create PDP context) • PDP context creation success ratio (Total Create PDP/ Successful Create PDP)

• Total PDP context creation duration (cumulative counter on PDP context creation duration) • AVG PDP context creation duration (Total PDP context creation duration/Total create PDP context)

DIMENSIONS

The following dimensions can be used: • Per country (enrichment needed) • Per operator (enrichment needed) • Per SGSN

Note 2: Reference data to be provided by the customer.

15 minutes 1 month

Global PDP context success rate versus time Alarm on PDP context success rate per major roaming partner (list to be determined)

(28)

2.2.3.2 Roaming In – GTP Traffic Report

The

business driver for this report is to measure the Gp traffic volumes. This can be used to manage

load sharing or capacity extensions.

As a

prerequisite, the required builder is Gp TDR.

Roaming In – GTP Traffic

MEASURES

• Volume DL (cumulative counter on data length and filter on way=DL and transaction type=T-PDU) • Volume UL (cumulative counter on data length and filter on way=UL and transaction type=T-PDU)

DIMENSIONS

15 minutes 1 month

(29)

2.2.3.3 Roaming Out – GTP Context Creation Report

The

business driver for this report is to create a PDP context during the setup of a data service.

This procedure creates a GTP tunnel that will be used later for the service. From a roaming

perspective, this is where interaction between networks starts in the context of data service. Thus, it is

important to survey that PDP context creation is working well in both networks and countries.

As a

prerequisite, the required builder is Gp TDR.

Roaming Out – GTP Context Creation

MEASURES

• Total Create PDP (filter on transaction type = create PDP context)

• Successful Create PDP (filtered counter on success field set to Yes and transaction type = create PDP context) • PDP context creation success ratio (Total Create PDP/ Successful Create PDP)

• Total PDP context creation duration (cumulative counter on PDP context creation duration) • AVG PDP context creation duration (Total PDP context creation duration/Total create PDP context)

DIMENSIONS

15 minutes 1 month

(30)

2.2.3.4 Roaming Out – GTP Traffic Report

The

business driver for this report is to measure the Gp traffic volumes. This can be used to manage

load sharing or capacity extensions.

As a

prerequisite, the required builder is Gp TDR.

Roaming Out – GTP Traffic

MEASURES

• Volume DL (cumulative counter on data length and filter on way=DL and transaction type=T-PDU) • Volume UL (cumulative counter on data length and filter on way=UL and transaction type=T-PDU)

DIMENSIONS

15 minutes 1 month

2.2.4 Roaming Voice Reports

2.2.4.1 Roaming In – MO Calls at ISUP Interco Report

The

business driver for this report is to manage the QoS of calls managed by the ISUP.

The record dimensions are directions or point codes. The results can be used to avoid losing calls and

to use Network Elements better. This report shall be applied at the roaming interco, on outgoing

traffic from roaming in subscribers.

As a

prerequisite, the business context shall be agreed with the customer. Several contexts would

require several KPI reports.

At least one of the following builders is required:

•

SS7 ISUP ETSI

•

SS7 ISUP ANSI

(31)

Roaming In – MO Calls at ISUP Interco

MEASURES

• Net Success = Call is Answered or Cause Family = NA or SSB or HE

• Unsuccessful calls due to customer (cause 17,18 and 19) • Unsuccessful calls due to customer and/or network

(cause 1, 3, 4, 21, 22, 27, 28, 29, 31) • Unsuccessful calls due to resource unavailable

(cause 34 to 47)

• Unsuccessful calls due to service or option not available (cause 50 to 63)

• Unsuccessful calls due to service or option not implemented (cause 65 to 79)

• Unsuccessful calls due to invalid message (cause 87 to 95) • Unsuccessful calls due to protocol error (cause 102 to 11) • Unsuccessful calls due to interworking (cause 127)

• Percentage of Unsuccessful calls due to customer (cause 17,18 and 19)

• Percentage of Unsuccessful calls due to customer and/or network (cause 1, 3, 4, 21, 22, 27, 28, 29, 31)

• Percentage of Unsuccessful calls due to resource unavailable (cause 34 to 47)

• Percentage of Unsuccessful calls due to service or option not available (cause 50 to 63)

• Percentage of Unsuccessful calls due to service or option not implemented (cause 65 to 79)

• Percentage of Unsuccessful calls due to invalid message (cause 87 to 95)

• Percentage of Unsuccessful calls due to protocol error (cause 102 to 11)

• Percentage of Unsuccessful calls due to interworking (cause 127)

• Average setup time • Average conversation time • Average length of call

DIMENSIONS

15 minutes 1 month

(32)

2.2.4.2 Roaming In – MO Calls at the RAN Report

The

business driver for this report is to measure voice quality for visitors from the RAN interface.

As a

prerequisite, the required builder is RAN CC.

Roaming In – MO Calls at the RAN

MEASURES

• Total nb of call

• Total nb of Successful (Successful=yes) • ASR (Total nb of successful / total nb of call)

• Total nb of network failure (cause value = Normal call clearing or normal unspecified or user busy or no user responding or no answer from user or subscriber absent)

• NER (Total nb of network failure/ Total nb of call)

DIMENSIONS

• Country

15 minutes 1 month

(33)

2.2.4.3 Roaming In – MT Calls at the RAN Report

The

business driver for this report is to measure voice quality for visitors from the RAN interface on

Mobile Terminated calls. For the MT Calls, it is difficult to monitor calls at the interco since the

subscriber identifier (MSISDN or IMSI) is not usually provided.

As a

prerequisite, the required builder is RAN CC.

Roaming In – MT Calls at the RAN

MEASURES

• Total nb of call

• Total nb of Successful (Successful=yes) • ASR (Total nb of successful / total nb of call)

• Total nb of network failure (cause value = Normal call clearing or normal unspecified or user busy or no user responding or no answer from user or subscriber absent)

• NER (Total nb of network failure/ Total nb of call)

DIMENSIONS

• Country

15 minutes 1 month

2.2.5 CAMEL QoS and Traffic Reports

The

business driver for this report is to manage the QoS of prepaid traffic.

This report is to control QoS for CAMEL prepaid services for outbound roamers. Any issue occurring

with CAMEL may prevent subscribers from using services while roaming. For service providers, it is

critical to check CAMEL QoS details in order to solve problems quickly and avoid losing revenues and

degrading QoS (typically with roaming subscribers).

(34)

CAMEL QoS and Traffic

MEASURES

• Total Call attempts

• Total Answered calls and ASR

• Time measurements, cumulated and average for: • Accept Time, connection time, transaction time • Total Charged time and related average value

• Number of connections, number of resource connections

• Normal release cause (and ratio) (list of normal causes: normal call clearing, User busy, No User responding, No answer from user, Subscriber absent, Normal unspecified)

• Abnormal release cause (and ratio) • SCCP error (and ratio)

• TCAP error (and ratio) • User (CAMEL) error (and ratio) • Provider error (and ratio)

• Total MSUs (received + transmitted) • Total bytes (received + transmitted)

DIMENSIONS

• Overall total except prepaid • Overall total prepaid • Per SCP prepaid only

Note: A filter shall be applied to CAMEL traffic for outbound roamers; calling GTT shall be different to home network.

15 minutes 1 month

Global ASR and number of attempts versus time Per SCP ASR (efficiency ratio): • Minor if < 65%

• Major if < 45%

(35)

2.3 Network Interconnection Reports

2.3.1 MAP QoS per GMSC Report

The

business driver for this report is management of the QoS of MAP interconnect traffic. This

report is focused on MAP QoS at the network interconnection points. In particular, it helps detect

abnormal errors for the MAP traffic at GMSC.

As a

prerequisite, the required builder is MAP ETSI.

MAP QoS per GMSC

MEASURES

• Total TDRs (simple counter)

• Total Send routing info (Filtered counter on Operation = Send routing info) • Total Update Location (Filtered counter on Operation code = Update location) • Total transaction time (Cumulative counter on Transaction time)

• Average transaction time (Total transaction time / Total TDRs)

• Total successful transactions (No SMS, SCCP, TCAP, User and Provider error) • Successful ratio (Total Successful / Total TDRs)

DIMENSIONS

• Per GMSC based on point code

• Report can be specific to incoming and outgoing traffic based on the way field

• A filter shall be used to ensure that the report addresses interconnect traffic. Filter shall be based on GTT (either calling or called GTT shall be different to the home network).

15 minutes 1 month

Total success ratio Per GMSC success ratio:

• Minor if < 60% • Major if < 50%

(36)

2.4 2G Core Network Reports

2.4.1 MAP QoS per NE Report

The

business driver for this report is to manage the QoS of Core Network MAP traffic. This report is

focused on MAP QoS at the Core Network. It identifies and shows any abnormal MAP errors that

impair traffic at the Core Network elements level.

As a

prerequisite, the required builder is MAP ETSI.

MAP QoS per NE

MEASURES

• Total TDRs (simple counter)

• Total transaction time (Cumulative counter on Transaction time) • Average transaction time (Total transaction time / Total TDRs)

• Total successful transactions (No SMS, SCCP, TCAP, User and Provider error) • Successful ratio (Total Successful / Total TDRs)

DIMENSIONS

• Per Point Code

• The report can be separated on incoming and outgoing traffic based on the way field

• A filter shall be used to ensure the report does not address interco traffic. Filter can be based on GTT (either calling or called GTT shall be equal to the home network).

15 minutes 1 month

Total success ratio Per GMSC success ratio:

(37)

2.4.2 CAMEL QoS for Core Network Report

The

business driver for this report is to manage the QoS of home network prepaid traffic and identify

QoS for CAMEL prepaid services. This report is similar to the roaming prepaid report, though the

context is focused on home core network.

As a

prerequisite, the required builder is INAP ETSI.

CAMEL QoS for Core Network

MEASURES

• Total Call attempts

• Total Answered calls and ASR

• Time measurements, cumulated and average for: • Accept Time, connection time, transaction time • Total Charged time and related average value

• Number of connections, number of resource connections

• Normal release cause (and ratio) (list of normal causes: normal call clearing, User busy, No User responding, No answer from user, Subscriber absent, Normal unspecified)

• Abnormal release cause (and ratio) • SCCP error (and ratio)

• TCAP error (and ratio) • User (CAMEL) error (and ratio) • Provider error (and ratio)

• Total MSUs (received + transmitted) • Total bytes (received + transmitted)

DIMENSIONS

• Overall total except prepaid • Overall total prepaid • Per SCP prepaid only

Note: A filter shall be applied to exclude any CAMEL interconnect traffic.

15 minutes 1 month

Global ASR and number of attempts versus time Per SCP ASR(Efficiency Ratio): • Minor if < 65%

• Major if < 45%

(38)

2.5 Mobile Number Portability Reports

2.5.1 ISUP MNP Report

The

business driver for this report is to manage the QoS of MNP related ISUP traffic.

In the case of MNP, several issues may occur with ISUP calls. This report identifies and manages the

following such cases:

•

Errors in the ported number Database. For instance, calls are routed to the monitored network

before being updated. Some errors may occur such as unknown subscriber. This type of error is

mostly important to control for incoming calls, and in particular when provisioning is completed and

the portability service is ready to go live.

•

Setup time increase

•

Transit traffic increase, causing problems

As a

prerequisite, one of the following builders is required:

•

ISUP ETSI

•

ISUP ANSI

ISUP MNP

MEASURES • Total calls • Answered calls • Failed calls

• Failed due to network resources • Failed due to subscriber unknown

• Network success calls • ASR, NER

• Average Setup time • Average conversation time

DIMENSIONS

• Per DPC and Routing Number Prefix

• Or Per TOP N B-Number (for this report B-Number shall be included in the column definition)

Note: Only incoming ported calls shall be considered. A filter shall be applied to focus the report on this traffic.

15 minutes 1 month

Global ASR and number of attempts versus time Alarm shall be raised if failure due to subscriber unknown count • Minor if > 50

• Major if > 100

(39)

2.5.2 MAP MNP Report

The

business driver for this report is to manage the QoS of MNP related MAP traffic.

The MAP MNP report identifies QoS in the context of portability when the GMSC is asking the

routing number to the HLR. Compared to the ISUP MNP report, this is another leg for the same call

management. Getting two reports provides the service provider with a comprehensive view of any

failures that occur at the various legs of the call management.

As a

prerequisite, the required builder is MAP TDR.

MAP MNP

MEASURES

• Total SRI

• Successful SRI and Ratio • Failed SRI

• Failed due to network • Failed to subscriber unknown

DIMENSIONS

• Per DPC and Routing Number Prefix

• Or Per TOP N MSISDN (for this report MSISDN shall be included in the column definition)

Note: Only incoming ported calls shall be considered. A filter shall be applied to focus the report on this traffic.

15 minutes 1 month

Global SRI success ratio and number of attempts versus time Alarm shall be raised if failure due to subscriber unknown count • Minor if > 50

• Major if > 100

(40)

2.6 Network Security and Fraud Detection Reports

2.6.1 Spamming (Unbalanced SMS Traffic) Report

The

business driver for this report is to identify SMS spamming.

Traffic between networks is typically balanced, which means there is roughly as much traffic received

as transmitted. Therefore, any unbalanced traffic may be due to unexpected traffic patterns like

spamming. To identify such behaviors, it is useful to check the details of the traffic routes, knowing

that spam traffic often uses fake GTT addresses. This report helps identify the exact origin of such

traffic. Once the inappropriate GTT addresses are being detected, it is possible to use Eagle5 Network

Security features to screen the traffic accordingly.

As a

prerequisite, the required builder is MAP ETSI.

Spamming (Unbalanced SMS Traffic)

MEASURES

• Total MAP (from Foreign SMSC)

• MAP operations with XDR type frame alone

• SRI for SM Error ratio (SRI for SM Error count/ Total SRI for SM

• Ratio to/from (Total SMS deliver to Foreign SMSC / Total SMS deliver from Foreign SMSC) • Total number of SRI with error cause “unidentified subscriber”

• Total number of SRI with error cause “illegal subscriber” • Total number of SRI with error cause “illegal equipment” • Total number of SRI with error cause “unknown equipment”

DIMENSIONS

• TOP Country/Operator based on enrichment • Enrichment applies on both Calling GTT

15 minutes 1 month

None Per Country/Operator SRI for SM error ratio:

(41)

2.6.2 SRI for SM Error Ratio Report

The

business driver for this report is to identify SMS spamming due to fake SMSC.

This report addresses spamming done with fake SMSC, sending SRI for SM. In such cases, many MAP

errors usually appear since used subscriber numbers are not accurate. In case of alarm, GTT at the

origin of the traffic, as well as route being used, needs to be checked. Once the fake SMSC is detected,

it is then easy to screen the traffic using Eagle5 Network Security features.

As a

prerequisite, the required builder is MAP ETSI.

SRI for SM Error Ratio

MEASURES

• Total MAP (from Foreign SMSC)

• MAP operations with XDR type frame alone

• SRI for SM Error ratio (SRI for SM Error count/ Total SRI for SM

• Ratio to/from (Total SMS deliver to Foreign SMSC / Total SMS deliver from Foreign SMSC) • Total number of SRI with error cause “unidentified subscriber”

• Total number of SRI with error cause “illegal subscriber” • Total number of SRI with error cause “illegal equipment” • Total number of SRI with error cause “unknown equipment”

DIMENSIONS

• TOP Country/Operator based on enrichment • Enrichment applies on both Calling GTT

15 minutes 1 month

(42)

2.6.3 TCAP Error Report

The

business driver for this report is to identify Mobile Service Providers that send spam traffic and

risk getting bills for fake SMS traffic.

When a service provider is faking SCCP addresses, responses are sent to equipment that is not actually

at the origin of the messages and they will receive isolated TCAP end messages. If the spam is not

detected, the spammed operator will ask for payment of SMS – payment that isn’t due. Detecting the

TCAP helps proactively manage problems. As well, some missing links or route can generate the same

kind of errors. These same reports will also help manage traffic QoS.

As a

prerequisite, the required builder is MAP ETSI.

TCAP Error

MEASURES

• Total MAP Operation • Total XDR type frame alone

• Frame alone ratio (Total XDR type frame alone/ Total MAP Operation)

DIMENSIONS

• TOP Country/Operator based on enrichment • Enrichment applies on Calling GTT • A filter shall focus the traffic on SMS deliver

15 minutes 1 month

• Minor if > 10% • Major if < 20%