STC CEM Customer Journey Metrics

Functional Requirement Specification

UCE8: I can use my Mobile for SMS

Linked to CJ group

UCx8: I can use my Mobile for SMS

Verified tmforum Conformant

Version 1.4 (2017-04-23) . i
Abstract
STC CEM requires that a Customer Journey (CJ) ICT SQM UI, based upon objective and measurable Customer
Journey Touch-points should be developed for the CJ’s that an STC customer is likely to undergo in his day-
to-day interaction with STC services.
The CEM project focuses on Telecom Customer Experience assurance and aims to provide an end-to-end
Telecommunications Management Forum (TM Forum) based CJ quality monitoring and management
solution for STC.
The System should encompass features which can monitor, analyze and report the service quality and
customer experience of the Touch-points in the TM Forum Customer Experience Lifecycle model, Buying,
Using and Sharing and thus assure optimum Customer Experience on a per Journey, per User basis. (PJPU)

Audience:
This document is aimed primarily at:
• STC and Huawei CEM Engineers & Management
• Huawei product developing engineers

Modification record
Title Description Contact Information
Document Owner The person who wrote or owns this Keith Gardiner (KWX306548)
document
Change Log 1 30 /11/2016 Draft 1.1 Created from Keith Gardiner (KWX306548)
Parent UCP8
Change log 2 19/12/2016 1.2 M.Zohairy (M00748751)
Adding sample data and modify the
overview section.
Change Log 3 17/04/2017 V1.3 Updates to Ch 1, Keith Gardiner (KWX306548)
merged Consumer, Enterprise,
Postpaid & prepaid.
Change Log 4 23/04/2017 V1.4 Included MCC Keith Gardiner (KWX306548)
(Mobile Country Code in
Dimensions in order to capture
Inbound Roamers usage.
Service Owner
Business Analyst

Review TM Forum Initial Conformance Review by TM Alfred Anaya-Dubernard

V1R2 Forum aanaya@tmforum.org

Version 1.4 (2017-04-23) . ii

Contents

1 Overview ...................................................................................................................................... 1
1.1 Business Value: Customer Journey Dashboard ............................................................................................................. 1
1.2 Objective: ...................................................................................................................................................................... 1
1.3 Functional Requirements Overview:............................................................................................................................. 2
1.4 Functional Requirements: ............................................................................................................................................. 3
1.5 Integration Requirements ............................................................................................................................................. 5
1.6 Abbreviations ................................................................................................................................................................ 5
1.7 FRS Document Methodology: ....................................................................................................................................... 6
2 UCx8: I can use my Mobile for SMS....................................................................................... 7
2.1 Functional Value: .......................................................................................................................................................... 7
2.2 Solution Description ..................................................................................................................................................... 8
2.2.1 Customer Flow ........................................................................................................................................................... 8
2.2.2 TM Forum Metrics proposed. .................................................................................................................................. 10
2.2.3 Non-TM Forum Metrics required. ............................................................................................................................ 12
2.3 Mobile SMS system Chart ........................................................................................................................................... 14
2.4 Data to deliver the metrics ......................................................................................................................................... 15
2.4.1 System Flow ............................................................................................................................................................. 15
2.4.2 Formula. ................................................................................................................................................................... 16
2.4.3 System example data ............................................................................................................................................... 17

Version 1.4 (2017-04-23) . iii

Overview

Business Value: Customer Journey Dashboard

A Customer Journey (CJ) is comprised of multiple Touch-points, (TP) where a Customer has interactions
with a Telco Operator during their day-to-day transactions, usually across several of the Telco Operator’s
Business domains and Access Channels. (e.g. through retail outlets, the Web, Telco network and User
Equipment (UE))
In most Telco’s, there are structured Organizational silo’s where each Business unit controls his, and his-
only domain and what this means is that no single unit ever has total visibility or, more importantly,
accountability for the entire Customer Journey experience.
Looking solely at individual transactions makes it difficult for the Telco Operator to exactly identify where
to direct improvement efforts because performance data is also stored in silo’s and are monitored by
several, equally silo’d individuals making it difficult to reconcile the impact of failures upon other
domains.
Cumulative bad experiences within a CJ through any Access Channel will quickly lead to a poor Customer
Experience Index.
By introducing a way of monitoring and actioning a degraded CJ that a Customer may experience, by
means of defined threshold values for each Touchpoint within that CJ, the Operator is provided with an
End-to-end view of the Customer Experience and will discover more-effective ways to collaborate across
functions units (the silo’s), and provide a process that delivers gains throughout the Telco Operator’s
Organization, for example:
• Improved Customer Experience,
• Reduced Customer Complaints,
• Reduced churn,
• Increased revenue.
• More effective equipment utilization.

Objective:
• The objective is to cover the technology-related lifecycle of the customer included in the TM Forum
model of Buying, Using and Sharing and to measure the user experience at each touch point.
• Based on that, STC can ensure and improve the customer experience on all targeted journeys.

Version 1.4 (2017-04-23) . 1

Functional Requirements Overview:
1. A customer’s interaction with STC has been defined by means of Customer journeys. Customer
journeys are a recognised industry wide technique used to measure moments of truth with
customers and how customers are treated.

2. The value in customer journeys is in ascertaining for each SMOT (Single Moment of Truth) what
the customer expects and what level of service quality is delivered to the customer. This is
recorded by means of metrics.

3. Many Customer Journeys provide customers experience in totality and a customer’s interactions
must be able to be assessed not only in one journey but across all journeys they are involved
within.

4. STC’s customer journey framework is based upon decomposition of TM Forums CEM structure.
This is displayed within TM FORUM’s Customer Experience Lifecycle Model, whereby solution
should be able to track the experience of each customer across all the phases of customer’s
typical lifecycle with a service provider i.e. Buying, Using and Sharing.

Reference: TM FORUM GB962-C

Version 1.4 (2017-04-23) . 2

Functional Requirements:
1. Monitoring Capability

Service alarms should be raised when the performance is outside user specified norms of
tolerance. These should allow, if not acted upon by the team within a specified period, the auto
creation of trouble tickets which will be assigned to the correct remedy queue and escalated as
appropriate through the organization.

Provide real-time Consumer & Enterprise CX monitoring and tracking. Provide flexible and
configurable alarms and trouble ticket generation in case of CX breaches at various levels like
Customer, Service, Journey, Touchpoint, NE and Area.

2. Analysis Capability

Ability to query defined metrics based on required dimensions (such as channels, customer type,
service type and etc) to perform needed analysis. Capability of combination of certain dimensions
such as customer type, technology type and etc. All ICT and NW topology starting from channels till
all contributed NEs need to be covered. Comparison capability should be provided for historical
analysis on same metrics and similar objectives.

3. Filtering Capability

The creation of a capability to filter criteria within a dashboard screen to provide information to
Analysis use cases. This filter should be able to be saved for subsequent rerunning of such use case
queries. By adding this filter concept, we are effectively creating a dynamic dashboard that analysis
can use to answer specific use case queries. The ability to engage extra filtering requirements,
such as those customers who don’t receive the service that they are provisioned for. This requires
alignment with use cases of analysis.

4. Drill Down Capability

All dash boards need to contain a drill down capability to the xDR and signaling by customer and so
provide in-context drill down to root causes of all CX issues enabling step-wise troubleshooting. The
ability to report summaries of root-causes that have distressed customers. Should provide message
flow schematics based upon direct NE integration.

5. Reporting & Analytic Capability

Version 1.4 (2017-04-23) . 3

 The CJ should have Big Data, Real-time Processing, and Analytics as needed to process and analyse
customer experience and service quality data from a variety of high-volume data sources and allow
multi-dimensional analytical queries for analysis and reporting needs. Capability of xDR and SDR
extraction and correlation; storage to keep final results for historical analysis purpose; Mata-data
management; Flexibility of multi-dimension analytic and reporting; UI for end user to perform
direct analysis activities and Integration of other 3rd party reporting tools.

6. Dynamic Dashboard

Dashboards should have the ability to be user configurable and have the capability for the user to
dynamically select metrics from an available catalogue. These should be able to be amended as per
the user’s individual requirements so that the metrics can be designed by user interaction to
provide amended / new metrics using the source data that reflect the needs of the user.

7. Single view of customer Capability

Across- technology tracing capability to enable unified visibility to customers experience issues
between Fixed and Mobile. Provide End to End automatic data correlation required to cover the CJ
via all TPs from related sources. Ability to link multiple product/services to customer using unique
IDs, accounts, etc. Capability to let end user query with multiple type of user identification such as
MSISDN, IMSI, IMEI, Telephone number and etc.

8. Metrics Customization Capability

Allow extensive customization capabilities for introducing new services, metrics, KPIs/KQIs,
business/data flow changes, topology changes etc. without any development or changes needed in
the core product.

Provide a dynamic feature of building new CJ’s with customized TPs and related metrics and
dimensions.

9. Export Capability

All information on the dashboard can be exported as required by end user per agreed format.

10. System Availability and Stability

Version 1.4 (2017-04-23) . 4

 System resource will be dedicated for GUI features which should be impacted by other DB related
activities.

11. Dashboard Time Granularity

The Dashboard should allow the user to choose various time-granularities as follows:

15 minutes, 1 hour, 24 Hours, 7 Days, 1 Month 3 Months.

Integration Requirements
The product should be fully integrated with any required STC systems/Tools in order to
demonstrate an E2E view of the service quality and customer experience of the services and
metrics included in the scope. These integrations should enable the solution to provide E2E
service quality visibility and correlation starting from Physical layer till Application layer, and
vendor should demonstrate how the solution along with existing STC systems can be used to find
the root cause of service experience issues with possible ICT faults and degradations in lower
layers including physical connectivity layer.

Abbreviations

Abbreviation Description

CEM Customer Experience Management

TM Forum/TM FORUM TM Forum (www.TM Forumorum.org)

SoW Scope/Statement of Work

HLD High Level Design

LLD Low Level Design

HW Hardware

SW Software

KPI Key Performance Indicators

KQI Key Quality Indicators

Version 1.4 (2017-04-23) . 5

 QoS Quality of Service

CEI Customer Experience Index

CX Customer Experience

CSAT Customer Satisfaction

NPS Net Promoter Score

OSS Operations Support Systems

BSS Business Support Systems

DPI Deep Packet Inspection

FRS Document Methodology:

• The Functional Requirements Specification is derived from the development of a straw-man
customer journey discussed with STC, where the activities / steps that a customer will engage in are
documented.
• Metrics based upon the TM FORUM Metric Catalogue are subsequently aligned to the journey, with
metrics attached to a customer step. These metrics display the efficiency that the customer has
experienced at each step.
• The various Technological functional units involved at each Touch-point are then identified and
captured in a Sequence-flow diagram.
• This then enables further analysis of the required STC metrics and functional units involved for each
identified Customer Journey by the downstream P&S (Huawei Product& Support) so that they can
determine, in conjunction with STC, how to capture and represent this information. This will allow
P&S to deliver HLD and LLD documents which will drive a customer experience management
product that manages the delivery of STC services based upon an End-to-end Customer Journey
view.

Version 1.4 (2017-04-23) . 6

UCx8: I can use my Mobile for SMS

Mobile for Texts (SMS) is an important journey for a customer. Apart from the Network that supports the
interaction, the IT systems which monitor and allow the dispatch, based on the Customer’s Top-up balance, also
need to be monitored for correct functionality.
By analyzing customers and not just pure network or IT transactions, we can understand how a customer is
treated end to end within the SMS experience regardless of the tools that are used to accomplish the journey.
Our use of dimensions allows us to drill down to understand issues that customers may have, for example by
region, by delay in Top-up activation and so-on.

Note: This document merges 4 CJ’s across the Postpaid, Prepaid, Consumer and Enterprise CJ
types so a filter will be necessary to enable a Dashboard user to choose any single type,
multiples of, or all of the 4 CJ’s mentioned below:

I. UC8: I can use my Mobile for SMS

II. UCP8: I can use my Mobile for SMS
III. UCE8: I can use my Mobile for SMS
IV. UCPE8: I can use my Mobile for SMS

The addition of the MCC (Mobile Country Code) to the Dimensions field enables the capture of Inbound
Roamers’ quantity and usage pattern although, since the Inbound Roamers’ profile is unknown to STC the
value is limited. However, it can be useful for monitoring the number of Inbound Roamers, the SMSe usage and
Destination ID data.
It is therefore necessary to enable filtering on the MCC.

Functional Value:
The Mobile for SMS CJ will allow the CEM team to:
1. Monitor the performance of the SMS delivery system, identify issues with the SMSC and interfacing IT
systems.
2. Monitor the performance of the associated Network that delivers the SMS to the Customer and identify
issues.
3. Monitor interactions within STC OSS and set suitable benchmarking.

Version 1.4 (2017-04-23) . 7

 4. Monitor daily work against the benchmarking and resulting alerts.
5. Provide demarcation for identified issues and drive resolution thereof.
6. In conjunction with the Analysis team, provide insight to common problems.
7. Allow problem resolution before other customers are affected.

Solution Description
Although commonly referred to as Text messages, we align with the TM Forum terminology and refer to said
messages as Short Message Service. (SMS)
The SMS Customer Journey (CJ) is one of the most important journeys for a customer and is one that should
always be monitored since it is widely used as a means to reduce Mobile service costs by the end-user. Although
rapidly being ousted by Social chat applications, it remains one of the basic Mobile-to-Mobile communication
channels, particularly for business applications and Customer-support functions.
The SMS provides a means of sending messages of limited size to and from GSM/UMTS/LTE mobiles. The
provision of SMS makes use of a Short-Message Service Centre, (SMSC) which acts as a store-and-forward
centre for short messages. Mobile originated (MO) messages are transported from an MS to an SMSC and
Mobile terminated (MT) messages are transported from an SMSC to an MS.
In UCPE8, only MO and MT SMS delivery are considered due to the complexity of capturing all SMS scenarios
originating from USSD, Billing, CRM and other STC enterprise such as MySTC website as well as public Banking
transactions and so-on. It is proposed that these cases will be captured in UC20.

Customer Flow
The Customer Journey is measured from the time a mobile user enters a destination number into his mobile,
enters the message as text and presses send. The sequence of signaling messages that follows in order to set up
the SMS, through to B-party delivery acknowledgement are measured, thus completing the SMS CJ. The Billing
usage message at the end of the sequence below is shown here for clarity only but is included in the SMS and
Billing-flow CJ’s in UC20.

For each customer step we have recorded thinking regarding what is required to make the customer happy,
satisfied or unhappy. By the use of metrics, we should be able to measure success if the desired driver is being
provided to elicit customer happy responses.

Version 1.4 (2017-04-23) . 8

Thus, we identify what functional area owns the delivery of service to the customer at each step. Metrics
based upon TM FORUM can be attached to each stage.
TRIGGERS

Customer
wants to send PR1
a text message

Billing
Sending Acknowledge Receive
Text message
Message Usage
Message Message
message

2)
CO-C-35 # SMS Origination Success
CO-C-36% SMS Origination Success
CO-C-37 # Seconds SMS Origination
1)
CO-C-34 # SMS Origination Attempts
3)
CO-C-38 # SMS Termination Attempts
CO-C-39 # SMS Termination Success
CO-C-40 % SMS Termination Success
CO-C-41 # Seconds SMS Termination

System Network/CRM/Billing •Network •network •network

KPI None 1) 2) 3)

Version 1.4 (2017-04-23) . 9

 At this point, there are certain Pre-requisites that will determine whether-or-not the
mobile-user will be able to send and SMS as follows:
PR1 • Is there RF Coverage?
• Is there Network Congestion?
• Has the mobile-user sufficient Credit to send a text?
• Is the handset configured correctly?
• Does the Customer profile configuration allow such a call?
• Is the A-party attached?

These pre-requisites are beyond the scope of this CJ.

TM Forum Metrics proposed.

The following TM FORUM based metrics are proposed to enable the analysis of the Mobile SMS sending
customer journey.

CO-C-34 # SMS Origination Attempts

# Channel Required messages received for SMS send
Dimensions: Customer ID, Device ID, Location, Originating Cell ID, Called Party Number,
Technology Type {GSM, 3G, TD-LTE, FD-LTE….}
Units: Number
Capture Period: 15 minutes
Value: Used to measure SMS performance
Comments: None

CO-C-35 # SMS Origination Success

# CP_ACK messages received from MS following MSC forwarding the SMS to the SMC
Dimensions: Customer ID, Device ID, Location, Originating Cell ID, Called Party Number
Technology Type {GSM, 3G, TD-LTE, FD-LTE….},
Units: Number
Capture Period: 15 minutes
Value: Used to measure SMS performance
Comments: None

CO-C-36 % SMS Origination Success

# SMS Origination Success/ # SMS Origination Attempts
Dimensions: Customer ID, Device ID, Location, Originating Cell ID, Called Party Number,

Version 1.4 (2017-04-23) . 10

 Technology Type {GSM, 3G, TD-LTE, FD-LTE….}
Units: %
Capture Period: 15 minutes
Value: Used to measure SMS performance
Comments: None

CO-C-37 # Seconds SMS Origination

SUM (Time of final CP-ACK received – Time of Channel Required Received)/# SMS Origination Success
Dimensions: Customer ID, Device ID, Location, Originating Cell ID, Called Party Number,
Technology Type {GSM, 3G, TD-LTE, FD-LTE….}
Units: Seconds
Capture Period: 15 minutes
Value: Used to measure SMS performance
Comments: Messages specific to the SMS send procedure are counted

CO-C-38 # SMS Termination Attempts

# Channel Required messages received for SMS Termination
Dimensions: Customer ID, Device ID, Location, Originating Cell ID, Calling Party Number
Technology Type {GSM, 3G, TD-LTE, FD-LTE….}
Units: Number
Capture Period: 15 minutes
Value: Used to measure SMS performance
Comments: None

CO-C-39 # SMS Termination Success

# CP_ACK messages received at the MSC following forwarding the SMS to the MS
Dimensions: Customer ID, Device ID, Location, Originating Cell ID, Calling Party Number,
Technology Type {GSM, 3G, TD-LTE, FD-LTE….}
Units: Number
Capture Period: 15 minutes
Value: Used to measure SMS performance
Comments: None

CO-C-40 % SMS Termination Success

# SMS Termination Success/ # SMS Termination Attempts
Dimensions: Customer ID, Device ID, Location, Originating Cell ID, Calling Party Number,
Technology Type {GSM, 3G, TD-LTE, FD-LTE….}
Units: %

Version 1.4 (2017-04-23) . 11

 Capture Period: 15 minutes
Value: Used to measure SMS performance
Comments: None

CO-C-41 # Seconds SMS Termination

Sum(Time of final CP-ACK received – Time of CM Service Request Received)/# SMS Termination Success
Dimensions: Customer ID, Device ID, Location, Originating Cell ID, Calling Party Number,
Technology Type {GSM, 3G, TD-LTE, FD-LTE….}
Units: Seconds
Capture Period: 15 minutes
Value: Used to measure SMS performance
Comments: Messages specific to the SMS termination procedure are counted

CO-F-24 # Seconds SMS Origination Standard Deviation

Standard Deviation of # Seconds SMS Origination
Dimensions: Device Type, Region ID, Technology Type {GSM, 3G, TD-LTE, FD-LTE….}
Units: Seconds
Capture Period: 1 month
Value: Used to measure the consistency of SMS performance
Comments: None

CO-F-25 # Seconds SMS Termination Standard Deviation

Standard Deviation of # Seconds SMS Termination
Dimensions: Device Type, Region ID, Technology Type {GSM, 3G, TD-LTE, FD-LTE….}
Units: Seconds
Capture Period: 1 month
Value: Used to measure the consistency of SMS performance
Comments: None

Non-TM Forum Metrics required.

The TM Forum based metrics are required by STC to enable the analysis of the Mobile Text-message customer
journey. The table below shows system source and proposed capture period.

Version 1.4 (2017-04-23) . 12

 Metric System Dimension Capture
Period
CO-C-34 # SMS Origination Attempts SEQ Customer ID, Device ID, Near Real-
Location,(Country, Region, time
Province, City, Originating Cell ID,
Called Party Number,Technology
Type., MSC/RNC/BSC
CO-C-35 # SMS Origination Success SEQ Customer ID, Device ID, Near Real-
Location,(Country, Region, time
Province, City, Originating Cell ID,
Called Party Number,Technology
Type., MSC/RNC/BSC
CO-C-36 % SMS Origination Success SEQ Customer ID, Device ID, Near Real-
Location,(Country, Region, time
Province, City, Originating Cell ID,
Called Party Number,Technology
Type., MSC/RNC/BSC
CO-C-37 # Seconds SMS Origination SEQ Customer ID, Device ID, UE ID, Near Real-
MCC, Location,(Country, Region, time
Province, City, Originating Cell ID,
Called Party Number, Technology
Type., MSC/RNC/BSC
CO-C-38 # SMS Termination Attempts SEQ Customer ID, Device ID, UE ID, Near Real-
MCC, Location,(Country, Region, time
Province, City, Originating Cell ID,
Called Party Number, Technology
Type., MSC/RNC/BSC
CO-C-39 # SMS Termination Success SEQ Customer ID, Device ID, UE ID, Near Real-
MCC, Location,(Country, Region, time
Province, City, Originating Cell ID,
Called Party Number, Technology
Type., MSC/RNC/BSC
CO-C-40 % SMS Termination Success SEQ Customer ID, Device ID, UE ID, Near Real-
MCC, Location,(Country, Region, time
Province, City, Originating Cell ID,
Called Party Number, Technology
Type., MSC/RNC/BSC
CO-C-41 # Seconds SMS Termination SEQ Customer ID, Device ID, UE ID, Near Real-
MCC, Location,(Country, Region, time
Province, City, Originating Cell ID,
Called Party Number, Technology
Type., MSC/RNC/BSC

Version 1.4 (2017-04-23) . 13

 Metric System Dimension Capture
Period
CO-F-24 # Seconds SMS Origination Standard SEQ Customer ID, Device ID, UE ID, Monthly
Deviation MCC, Location,(Country, Region,
Province, City, Originating Cell ID,
Called Party Number, Technology
Type., MSC/RNC/BSC
CO-F-25 # Seconds SMS Termination Standard SEQ Customer ID, Device ID, UE ID, Monthly
Deviation MCC, Location,(Country, Region,
Province, City, Originating Cell ID,
Called Party Number, Technology
Type., MSC/RNC/BSC

Mobile SMS system Chart

The technology systems that manage this operation is provided below, along with the sequence of activities that
contribute to this journey being fulfilled. The systems involved being:-
• SEQ Analyst Platform, data collection by both Active and Passive probes deployed on
the Mobile network. For the Mobile SMS scenario, the probes are identified under
“CS”, marked in Green whilst the actual mobile data is marked in Red.
• The SMSC which acts as a store and forward centre for short messages.
• The RAN and its associated Network.

Version 1.4 (2017-04-23) . 14

Data to deliver the metrics

System Flow
The SMS service process includes two processes:
Mobile originated short message: The MS sends the short message to the MSC or the
SGSN. The visited PLMN routes the message to the appropriate SMSC, transiting other
networks if necessary.
Mobile terminated short message: The SMSC interrogates the HLR to retrieve routing information
necessary to forward the short message, and then sends the message to the relevant MSC or SGSN, transiting
other networks if necessary. The MSC or SGSN then sends the short message to the MS.

Figure 2.1: Flowchart of CS SMS services.

Version 1.4 (2017-04-23) . 15

 Table 2.1: Measurement items of CS SMS services

Trigger ID Description of User Protocol or Technical Description

Experience

(1) A-party enters the B- The A-party sends an SMS and it is sent on to the
party address and the SMSC.
Text-message and
presses the dial key.
An RRC connection has been established when
The MSC sends the
the user combines services. At this time, the
SMS to the SMSC.
time when the message is sent is regarded as
the time when the user presses the dial key.

(2) The Network replies Time when the SMSC acknowledges receipt of
to the A-party with the SMS from the A-party. (A report shall always
the message “Sent” or be returned to the A-party, either confirming
“Not Sent” that the SMSC has received the short message or
informing the MS that it was impossible to
deliver the short message to the SMSC.)

(3) Depending on local Time when the B-party sends an SMS received
setup, an “SMS message to the SMSC. (A report shall always be
delivered”or “SMS returned to the SMSC, either confirming that the
not delivered” B-party has received the short message, or
message is sent to the informing the SMSC that it was impossible to
A-party upon deliver the short message to the B-party.)
successful delivery to
the B-party.

Formula.
Metric Calculation Comments
CO-C-34 # SMS Origination Sum of Value 1 within (Time
Attempts x)
CO-C-35 # SMS Origination Sum of Value 2 within (Time
Success x)
CO-C-36 % SMS (Sum of Value 2 within (Time
Origination Success x)/ Sum of Value 1 within
(Time x))%
CO-C-37 # Seconds SMS Average(Value1-Value
Origination 2)within (Time x)
CO-C-38 # SMS Termination Value 3within (Time x)
Attempts
CO-C-39 # SMS Sum of Value 4 within (Time
Termination Success x)

Version 1.4 (2017-04-23) . 16

 CO-C-40 % SMS (Sum of Value 4 within (Time
Termination Success x)/ Sum of Value 3 within
(Time x))%
CO-C-41 # Seconds SMS Average(Value3-Value
Termination 4)within (Time x)
CO-F-24 # Seconds SMS
Origination Standard
Deviation
CO-F-25 # Seconds SMS
Termination Standard
Deviation

System example data

Attached is the sample data received for this journey and other Mobile journey based on SEQ probes.

CT Data
Source.docx

Version 1.4 (2017-04-23) . 17