MediationZone Real-time

Mediation and Usage

Management
Case Study
MediationZone Real-time Mediation
and Usage Management
Case Study

This whitepaper outlines the background, business drivers, solution

architecture, technology selection and implementation of a real-time
mediation and usage framework at a North American Communications
Service Provider

Management summary

2010 – The CSP invested in a new B/OSS solution for its wireless post-paid business to
support a 400000-strong CDMA and HSPA customer base.

2012! – The CSP launched LTE and extended the B/OSS to support LTE services,
accommodating the latest iOS and Android devices. Growth of the customer base was
experienced with sky rocketing data usage.

2013! January– The CSP and other wireless carriers in its geography were asked to
comply with a new wireless code by the national regulatory commission to limit
customer data usage to prevent bill shock.

2013 June – The CSP selected DigitalRoute’s MediationZone to enable a meeting of the
new regulations with the enhanced scope of offering data roaming passes, a prepaid
quota of data sold on demand for roaming customers.

Background

1 !!
DigitalRoute’s customer is a leading national communication solutions company in its geography,
providing innovative communications services. Since 2o10, it has identified a need to introduce real-time
capabilities within its B/OSS. However, with a focus on its post-paid customer base, real-time product
offerings were kept at lower priority. With the explosion of customer data usage, as result of the
introduction of smartphones and investments in LTE technology, the CSP soon realized that there was
huge market potential in ‘hybrid plans’. However, in order to offer such plans its IT systems have to be
able to detect customer state and activities in real-time, to offer ‘products’ that align with the activities
when needed and to measure and control usage in real-time. Such products closely follow the ‘prepaid’
service.

With this in mind the CSP started exploring possible technology solutions as early as 2012. Following
extensive research, its IT team had a clear understanding of which technology needed to be acquired – but
it was preoccupied with improving its newly implemented B/OSS systems. Late in 2013 the national
regulator introduced a new rule to ‘control’ real-time data usage to prevent customers from ‘bill shock’.
This was the necessary spark and catalyst needed to embark upon the planned, but long awaited, real-
time mediation and usage management framework. Fortunately, the company had already established a
high level reference architecture as shown in Figure 1.

The solution required real-time and batch interfaces to the network and back-office including; subscriber
provisioning, flow based charging, online credit control, real-time quota consumption reporting and batch
oriented usage reporting exports. Integral support needed to include both prepaid and post-paid
subscribers for the following general case scenarios:

•" Integration with the Ericsson SASN: The solution proposed had to be pre-integrated with the Ericsson
SASN via the DIAMETER Gy/DCCA protocol as per 3GPP TS 32.251 and 3GPP TS 32.299. The
interface would manage subscriber network access requests to allow/deny/redirect based on real-time
network consumption.
•" SOA based provisioning and usage queries: The solution would provide a web services based interface
suitable for provisioning subscriber quota and reporting current subscriber usage levels.
•" Notification Alerts: Notification levels will be configurable to generate events at soft configurable
amounts of quota consumption either by percentage of plan, or at exact byte consumption. Levels can
be added, adjusted or updated via a web accessible User Interface. Alerts will be delivered via a file or
SOA based interface.
•" Session Redirection: Upon encountering a roaming subscriber, or on exhaustion of a subscriber’s
quota, the solution will redirect session data to the internal portal host using the “No Funds” URL. The
URL will be encoded in the MZ CCA response to the CCR from SASN requesting quota on behalf of the
subscriber.
•" CDR Feed to Billing: The system will be configured to export CDRs for billing and invoicing purposes,
the system will support CSV, or a fixed length file, or XML format as specified by the telco.
•" Expandable: The solution must be easily expandable to service additional network interfaces including
Gx, Gxx, Sd, per 3GPP TS 29.212-v11, Sy as per 3GPP TS 29.219, Rx via 3GPP TS 29.214 and S9 as per
3GPP TS 29.215.

2 !!
Figure 1 –Reference Architecture

Business Drivers

The primary goal of the project was to fulfil the regulatory requirement mandated by the regulator as
summarized below:
Cap on data roaming A service provider must suspend national and international data roaming
chargers charges once they reach $100 within a single monthly billing cycle, unless
the customer expressly consents to pay additional charges.
Cap on data overage chargers A service provider must suspend data overage charges once they reach
$50 within a single monthly billing cycle, unless the customer expressly
consents to pay additional charges.
Table 1

3 !!
The CSP realized that these regulations were actually put forward to prevent customers from experiencing
bill shock. By allowing maximum exposure of a customer’s bill overrunning to $100, while roaming and
$50 within the local area, there will be no chance for customers to unknowingly pile up huge bills.
However, whilst good for the customer, limiting usage could be a dampener on the CSP’s revenue stream.
As a mobile service provider, it’s important for operators to limit the risk of customers going into
collections but the CSP felt that, by the same token, there should be a balance between control and
prevention. In addition, stopping a customer’s service abruptly is not a good experience for the customer.
Instead of capping usage, the CSP realized that selling incremental usage quotas on demand could provide
the customer with the control, and itself the opportunity, to extend the service without simple termination
of the service.

Additionally, the CSP realized that there is a majority of customers who would still want to continue their
usage after reaching the caps. It is therefore important that customers can make real-time decisions on
whether to continue usage.

Real-time notifications were not part of the new regulation; however, it is logical that any potential
interruptions to the service should be accompanied by an effective means of notification. Notification can
be send as a TXT/SMS message or a redirecting browsing session to a portal. Such notifications can then
empower customers to make real-time decisions.

The CSP also carefully looked at the usage patterns and habits of their customers when using data while
roaming. In general, customers were reluctant to enable their devices while roaming as roaming data was
perceived as ‘expensive’. Therefore, they learned that the majority of customers keep their mobile data
roaming off and seek Wi-Fi to access the Internet. Plus, the CSP realized that $100 Cap is really
ineffective if implemented as merely a regulatory compliance. To enable the wider adoptability of
roaming data, and to also comply with regulations, the CSP decided to adopt the concept of ‘hybrid offers’
for data roaming. While customers continue to be on a post-paid plan, roaming data is offered as a
‘prepaid’ quota or ‘bucket’. Customers can purchase these prepaid ‘buckets’ of data on demand. This
prepaid component enables customers to buy small chunks of data at a lower price point and consume as
they wish. Since all data is purchased on a prepaid basis, with the knowledge of the customer, there is no
possibility of overruns, thereby completely eliminating the need for the mandated $100 cap.

With the above business objectives in place, the CSP also thought to further strengthen the offers by
introducing much more control over the data usage to support parental controls. Account owners are
empowered by the facility to set up and bypass local caps or purchase roaming buckets for each device
that is covered in their plan. Thus, parents can pre-set their child’s device to cap at $50 without the ability
to bypass. Similarly, the same device can be setup to disable the ability to purchase roaming buckets.

4 !!
Business Objectives

Figure 2 – The Evolution of business scope with the introduction of real-time Mediation

As illustrated by Figure 2, the CSP’s business objective at a high level was to elevate the current batch
processing post-paid offerings to real-time, self-served offers. The objective is to start with Data products,
followed by messaging and finally the next generation of Voice (VoLTE). Since it’s a phased approach, new
products will need to be offered as add-ons. These new prepaid add-ons will present themselves based on
the various real-time considerations such as geographical location (roaming location), base plans (add-
ons are customized on base plan), customer type (consumer, small business and enterprise), customer
preferences (parental controls), network technology (CDMA, HSPA, LTE) or usage type ( tethering,
ondevice, MMS etc).

5 !!
Solution Architecture

Business Architecture

Drives Subscriber
Products Profiles

Drives Real-time
Authentication, Business Enable on device
Authorization a nd
Actions
Rules Real-time Decision
Making

Mobile Mobile
Phone Portal

Figure 3 - Business Context Diagram

At a very high level, business architecture revolves around three categories which are simple to
understand. There are three business processes that are involved; development of products, modeling of
real-time business rules (in RTM) and rules for customer self-service through a mobile portal. Once these
processes are completed, customers’ mobile devices can interact in real-time and be setup to make
decisions.

Products
Sellable products are built into the billing system and published to the CRM. When products are built and
pushed to the CRM, a manual process will map the CRM product to relevant products in RTM UM. The
CSP plans to automate this process through Product Catalog sync going forward; one CRM product could
map to multiple products in RTM UM. Then, when customers are provisioned, each customer identified
by their MSISDN (primary key) will get assigned a combination of ‘RTM Products’. These RTM products
consists of ‘buckets’. The concept of Subscriber Profile exists in the MediationZone UM and used to map
products. Then these RTM products get mapped to buckets which get created at run time. See Figure 4
for an example.

6 !!
Figure 4 – Product Mapping Example

As shown in the example, the CRM product 1-2AJ27K will map to RTM buckets 102,116,29 and 92.
Zone 0000 is within the CSP’s home geography and Zone 0999 is outside it. So bucket 116 is for tethered
usage within the geography. The concept of monetary buckets is also introduced. These monetary buckets
are used to track overage up to the limit of $50.

The following Product Types are defined in RTM:

•" Standard – Month-to-month plan with a set amount of data usage for an individual subscriber
with the following parameters:
o"""""Plan type – Base or Add-on.
o" Usage type – Tethered data or Non-Tethered data
o" Coverage type – local, non-local, or National. All these plans are also referred to as local.
o" Capacity – Volume or unlimited.
o" Overage rate – Price per unit; could be zero.
o" Overage unit – For example, MB or GB.
o" Notification level(s).
o" Priority – Add-on plans may have a higher priority than Base plans.
o" Zone – Not applicable.
o" Time limit – Not applicable.
o" Rate Plan Name – The telco’s unique identifier for the plan; e.g., JC19.
o" CRM Product Row ID – Not applicable.
o" Proration Indictor – Proratable or non-proratable.

7 !!
 A subscriber has one Base plan and can have one or more Add-on plans. Notifications are sent
based on the total capacity of the Base plan and all Add-on plans. Overage is calculated using the
lowest overage rate from the Base and Add-on plans that have the same usage type/coverage type.

•" Data Friend – Primary subscriber shares a pool of data with a secondary subscriber. The
secondary subscriber is linked to Primary by bi-directional link. No specific product has to be
provisioned to indicate data buddy plan since bi-directional link is enough.
The primary subscriber purchases one or more Standard plans, and the secondary (“buddy”) has a
data plan with a Monthly Recurring Charge (MRC), but no capacity. The primary and secondary
subscribers both have the same Billing Account number. The secondary subscriber shares the
data usage for all standard plans that are attached to the primary subscriber

•" Passport – International roaming plan with a set amount of data usage for a specified Zone for a
specified time period for an individual subscriber with the following parameters:
o" Plan type – Travel Pass.
o" Usage type – Not applicable.
o" Coverage type –International. International is also referred to as roaming.
o" Capacity – Volume.
o" Overage rate –Not applicable.
o" Overage unit – Not applicable.
o" Notification level(s).
o" Priority – Not applicable.
o" Zone – 1 through 7.
o" aTime limit – 24 hours or 30 days.
o" Rate Plan Name – The telco’s unique identifier for the plan; e.g., JC19.
o" CRM Product Row ID.
o" Proration Indictor – Not applicable.
A subscriber whose Roaming Purchase indicator is not set to 1 must have a Travel Pass for the
zone in which he wishes to roam, or he will be redirected. Notifications are sent based on the
capacity of the Travel Pass plan. No overage is calculated. The plan expires when the capacity is
used or the time limit is reached.

A subscriber whose Roaming Purchase indicator is set to 1 can roam in any zone without
purchasing a Travel Pass.

If a subscriber purchases multiple Travel Passes for the same Zone, then the priority should be
first in, first used.

Business Rules
Business Rules are built and configured in RTM by way of workflows. There are real-time and batch
workflows. As an example, one real-time workflow intercept Diameter CCR/CCA messages and applies
business rules to guide usage in to appropriate buckets. Centric to all business rules is the SPR
(Subscriber Profile Repository). Information that is stored in the repository for each subscriber includes:

•" MDN (or MSISDN).

•" IMSI.
•" Customer Account number (CA).
•" Billing Aggregate Account number (BAA), which is optional.
•" Billing Account number (BA).
•" Customer Type – Optional; for example, Enterprise, Business, Consumer.
•" Subscriber Type – Post-paid (default).
8 !!
•" Bill Cycle – 1, 7, 15, or 22.
•" Overage Cap indicator – 1 = redirect at $50 overage; 2 = do not redirect for the current Bill Cycle; 3 =
never redirect; 4 = redirect, but do not allow to bypass the overage cap.
•" Roaming Purchase indicator – 1 = no purchase required and never redirect; 2 = redirect and allow to
purchase a Travel Pass; 3 = redirect, but do not allow to purchase a Travel Pass.
•" Status – Active or inactive.
•" Activation Date – Date that the subscriber was provisioned (by a CreateSubscriber provisioning
request).
•" Deactivation Date – Date that the subscriber was deactivated (by a RemoveSubscriber provisioning
request).

For an example, the rules around Roaming Purchase Indicator are as follows:

A subscriber whose Roaming Purchase indicator is not set to 1 must have a Travel Pass for the zone in
which he wishes to roam, or he will be redirected to one of two pages.

a)" Subscriber is not authorized to purchase international passes (Roaming Purchase indicator = 3).
Until the subscriber is authorized or a Travel Pass is added by Customer Service, all future usage
requests will be denied.
b)" Subscriber is authorized to purchase international passes Roaming Purchase indicator = 2).
From this web page, the subscriber can do one of two things:

a." Purchase a Passport for the international zone where the subscriber is currently located.
b." Do nothing, which will result in all future usage requests being redirected to this same web
page.

Figure 5 shows a sequence diagram which illustrates the sequence of events expected to be handled by
RTM for a subscriber with international data usage who is required to have a Travel Pass, but does not
have a Travel Pass and is authorized to purchase a Passport (Roaming Purchase indicator = 2). The
subscriber is redirected and purchases a Passport for the Zone in which he is roaming.

9 !!
Figure 5 – CCR processing for Roaming Pass Purchase

10 !!
Mobile Portal
Mobile portal presents a customized experience for each customer based on business logic. A customer’s
device is recognized by the encrypted MSISDN sent over the HTTP headers. Business logic is embedded
into the portal backend to present a web page appropriate for the situation. For an example, when a
customer enters into a roaming zone AND they do not currently
have an active travel pass AND they are authorized to purchase
travel passes (Customer Profile set to Purchase Travel Pass
indicator 2) they will be redirected to a page to purchase a travel
pass. This page offers different travel passes depending on which
zone the customer has entered.

•" Zone1 – US/Mexico

•" Zone 2-5 – International
•" Zone 6-7 - Satellite and Cruise Ship

As shown in Figure 5, the customer will be presented with a list of

valid travel passes. Travel passes will indicate the price, time valid
and MB included. The customer will choose which travel pass they
require by clicking/tapping on Buy Now. Once clicked, the
customer will be redirected to a confirmation page.

Similarly, when a customer enters into a roaming zone AND they

are NOT authorized to purchase travel passes (Customer Profile set
to Purchase Travel Pass indicator 3) they will be redirected to a page
indicating they are not authorized to purchase Travel Passes as
shown in Figure 6.

The customer’s only action is to have the authorized contact call

with the CSP to allow the purchase of Roaming Passes (Set Purchase
Travel Pass Indicator to 2) or close their browser and not use data
while roaming.

Figure 6

11
Application and Data Architecture

Figure 8 – RTM project application architecture

12 !!
Application architecture of the RTM project spanned several systems within the CSP’s IT landscape.
Figure 8 shows the applications that are involved and interfaces. Table 2 below summarizes the functions
performed by each application.
Application"" Description""

CRM"" •" Relevant products will be tagged in the CRM using product attribute
•" Profile tab to display capping attributes(profile)
•" Data Passes are setup as OC&C Products
•" Customers can purchase these products by calling a CSR
•" Every order with an existing Data Product or a new Data Pass creates a
provisioning request towards RTM. It will be part of the sales order sent to OSM
OSM33 OSM identifies the Data Product with the RTM Tag in CRM Sales Order and build the
(Order33 provisioning request to RTM. OSM sends the request to AIA through weblogic JMS
Provisioning)"" queue
AIA33(Service33 AIA, upon receiving the provisioning order from OSM, will execute the RTM WS to
Activation)"" CRUD the subscriber/products in RTM
Observer33(CSR33 Observer provides multiple Tabs extracting data to be displayed to CSR
Tool)"" •"RTM Tab - for real-time usage, customer profile attributes, SMS notifications •"
CDRs Tab – CDRs from WinIQ
Portal"" When usage reaches a CAP or user not allowed to use roaming data, browser will get
redirected to Portal page. Portal page(s) will offer ability to extend the usage by
bypassing the caps or purchasing a data pass
Notification33 NG will accept WS requests from RTM whenever a notification to be sent. NG will
Gateway"" connect to SMSC and send SMS notifications to the mobile phone

RTM"" RTM holds all subscriber information, products and subscriber to product mapping. It
also provides southbound 3GPP Gy interface for Diameter credit control protocol.
UM"" UM Collect data (usage), aggregate and count (buckets), execute threshold logic and
send notifications
WinIQ33(Data33 WinIQ stores all Data Session Records. RTM-UM will cut periodic session records and
Warehouse)"" transfer to WinIQ
BRM33(Billing)"" BRM receives two feeds from RTM and IUM for data usage and will continue to rate,
charge and invoice.
IUM(Batch33 IUM will continue to feed batch files for SWANA and OnStar types of usage after
Mediation)"" filtering;
Wirecom(file33 Is an interim server for file transfer. Files that are used for reporting and filtered usage
Transfer33and33 is sent to Wirecom
temp33Storage)""
Table 2 – RTM Application Landscape

13
 !!

Technology Architecture
The technology layer that consists of Physical Dedicated Servers, Virtual Servers, CouchBase embedded
data store at MediationZone installation has been sized to handle up to 1.5 M subscribers. The current
subscriber base is .5M. \Technology architecture as shown in Fig 8 is designed to support up to 3,300
TPS as estimated in Table 3.
Subscribers)) Trans/Day/ Trans/Day)) TPS)) TPS6 UM))DB)) UM))DB)) UM))DB))
Subs)))) (DCCA))) (DCCA))) 6 Peak)) Transactio Transactio Transactio
(DCCA))) (Estimated))) (Estimate (DCCA))) ns))per)) ns))per)) ns))per))
d))) (Estimate DCCA)) Second)) Second6
d))) (Estimated))) (Estimated))) Peak))
(Estimated)))
20%))

500,000)) 160"" 80,000,00 926"" 1111"" 2"" 1852"" 2222""

0""
750,000)) 160"" 120,000,0 1389"" 1667"" 2"" 2778"" 3334""
00""
1,500,000)) 160"" 240,000,0 2778"" 3334"" 2"" 5556"" 6668""
00""
Table 3

The RTM environment spans two data centers to support disaster recovery requirements. The
primary site operates in Active/Standby configuration which will provide hardware and application
redundancy.

RTM uses a high performance key-­ !! !!value-­ !! !!store database for DIAMETER session state
preservation, quota management and subscriber product provisioning. Couchbase DB is setup with 3
nodes on Dedicated servers with 1 replication (data is replicated in 1 additional server). In the case of one
server failure, the Couchbase Cluster Manager will automatically promote replica data from such server in
the running server to become Active. It is ensured that every single document has at least 1 replica in
different server than where active document resides. This technology architecture will provide 99.999%
system availability.

Table 4 below provides hardware configuration.

ControlZone/EZ3 Database ExecutionZone ExecutionZone
1&2 4&5

Type Virtual Machine Virtual Machine HP DL360 G8 Virtual Machine

Memory 16GB 16GB 32GB

CPUs Quadcore Quadcore 2 * 6-core Xeon

Network 10 Gigabit 10 Gigabit 10 Gigabit

interface

Hostname rtmczprod N/A rtmezprod1 & rtmezprod4 &

rtmezprod2 rtmezprod5
Table 4

14 !!
 Legend:
Process,
Details

MZ* ***system* ***component

Process,
Details

Other****system* ***component*or
* ***resource

IWF* ***communications

External* ***communications

Diameter* ***communications
* ***

Couchbase* ***communications*

SFTP* ***communication* ***

(internal)

15
Figure 9 – Environment Setup for Primary Site

!!

Project Implementation

The project was executed at a brisk phase, triggered by the regulator’s mandated date of the end December
2013. The RFP publishing-to-project completion date was only 6 months. DigitalRoute’s knowledge about
the product and its application, coupled with the groundwork that the CSP’s teams had done prior to
launching the product, accelerated the process. In addition, efficient project management, clear solution
architecture and solution management by the CSP team, together with committed management support,
enabled the project to be successful even with a very tight schedule.

RFP Vendor Project Require Develop Test Ready to

Design Deploy
May Selected Kick Off ments Oct-Nov Nov-Dec Go Live
Sep 2013 Dec 2013
2013 Jun 2013 Jul 2013 Aug 2013 2013 2013 Jan 2014

Figure 10 – High Level Project Schedule

The small project team consisted of a PM, a Solution Manager, a Solution Architect, 2 Systems Analysts, 2
developers - and 3 testers drove the project. DigitalRoute teams built the core application ie design and
development of the MediationZone solution. Outside this core project team, there were several other
teams. These teams contributed to the overall solution, covering the Network, Portal, Provisioning and
Billing.

A small scale test environment was used for (UAT) Unit Testing as well as SIT (System Integration
testing).

16 !!