Subscriber Policy and Charging Manager

Here we provide an overview of Subscriber Policy And Charging Manager (SPCM) in the Tango Policy and Charging Control (iAX PCC) platform. It contains the following sections:

  • Introduction

  • Data Plans

  • Subscriber Provisioning

  • Subscriber Self-Care

  • Subscriber Notifications

  • Group Accounts

  • Policy Promotion Service (PPS)

  • Combo Pack Service (CPS)

Introduction

The Tango Subscriber Policy and Charging Manager (SPCM) allows for the management and configuration of subscriber accounts and data plans in the Tango iAX PCC. Notification messages can also be managed and configured in multiple languages.

The main function of the SPCM is to manage subscriber data plans (which can be purchased by the subscribers) and to notify the PCRF rules handler if a policy or charging control change is needed. In the event of such a change it will also notify the subscriber via SMS. The SPCM:

  • provides the PCRF rules handler with subscriber profile information at the start of a data session.

  • provides the PCRF rules handler with usage-tracking parameters and processes the subsequent usage reports received from the PCRF rules handler.

  • notifies the PCRF rules handler of subscriber profile changes, e.g. due to data-usage thresholds being exceeded or a data plan expiring.

Data usage can be monitored for a subscriber’s data plans. The data usage may be categorised by time-band (e.g. Peak/Offpeak), location (e.g. Home/Roaming) or APN. If the total data usage exceeds a configured threshold value, the following actions may be taken:

  • Notify the PCRF to change policy and/or charging control for data sessions.

  • Send an SMS alert to the subscriber.

The SPCM also provides the following functionality:

  • A self-care HTTP API to allow subscribers to purchase data plans, manage multiple data plans and view usage information.

  • Tango Open Charging Interface (OCI) server to charge for data plans which are purchased by subscribers. The OCI server can be configured to use the appropriate online charging protocol as required by the third-party Online Charging System (OCS).

  • An API to a third-party provisioning platform to create, update and query subscribers in the Tango PCC database.

  • Maintenance of multiple usage counters for a data plan, e.g. daily or weekly counters with fair usage thresholds.

  • Automatically provision subscribers who are not already on the system but who purchase a data plan via self-care.

  • Batch provisioning of subscribers, including migration from legacy systems.

  • A policy promotion web service to grant bonus plans to subscribers who have consumed a configured amount of existing plans.

  • A combo pack service to bundle voice, SMS, or MMS plans as a bonus for subscribers who purchase a data plan.

Data Plans

Data plans can be defined under the Policy > SPCM > Plan Mgmt menu of the Tango PMI GUI. The Tango iAX PCC allows subscribers to purchase data plans. It tracks the data usage and manages quotas and policies on a per subscriber basis. Usage can be debited from a data plan before switching to the normal prepaid or postpaid pay per use charging when the data plan has been exhausted.

Core Data Plans

A Core plan is a plan that is automatically assigned to a subscriber when the subscriber is provisioned. A Core plan has the following attributes:

  • Core plans cannot be deactivated

  • Core plans are automatically activated on purchase

  • Core plans must be recurring

  • There cannot be more than one core plan (may be none)

  • Core plans can be chargeable or non-chargeable

  • Core plans are typically lower in precedence than add-on plans (unless the add-on plan is blocking all data access in which case any plan in a service blocking state will have the lowest precedence)

Generally plans are given precedence based on the following criteria: Plans with a service profile that blocks all data are given lowest precedence while plans with a non-blocking service profile are given the highest precedence Plans with the same service blocking state are given precedence based on the precedence value assigned to them when the plan is created For plans with the same assigned precedence value, QoS bit-rates are checked, with the higher rate taking precedence For plans with the same QoS bit-rates, activation dates are checked, with the earlier activation taking precedence

  • Core plans will not appear on the self-care list of data plans that are available to be purchased

  • There may be a pay-per-use type core plan which supports unlimited usage with no policy thresholds and no usage reset

Recurring Data Plans

A recurring plan is a data plan that is automatically recharged and the usage is reset after the validity period has expired. Recurring plans continue to be recharged automatically, until cancelled by the user. This is in contrast to single-use data plans which are no-longer available once they have been exhausted.

Monthly recurring data plans also allow you to set a day-of-month for plan renewal. This allows you to set a specific day in the month for the plan to renew, e.g. on the 1st of every month.

If the plan is set to renew on the 29th, 30th or 31st, and the current month has less days in the month, then the renewal will happen on the last day of the month.

Pro-Rating for Monthly Recurring Plans

A subscriber can purchase a recurring plan at any time during the month. If the subscriber buys the plan on a date that coincides with the start date for the plan then the subscriber has the full month to consume the plan (cost and/or volume). If however, the subscriber buys the plan at any other time during the month, the plan cost and allowed volume for the first billing period is calculated on a pro-rata basis depending the number of days (from plan activation) until the first plan renewal day-of-month.

The pro-rating feature can be enabled or disabled as required via configuration and is a system-wide feature. The following restrictions apply:

  • Only applies to monthly recurring plans.

  • If a monthly plan is configured with daily counters, these daily counters are not pro-rated, e.g. daily Fair Usage policy of 100MB - this daily counter is not pro-rated.

  • Time-based usage thresholds are not supported.

The following examples illustrate how the pro-rating is applied.

Example 1

Plan A is a simple 1GB plan recurring on the 1st of every month with an SMS notification being sent to the subscriber at 80% usage. Assuming a 30-day month, if a subscriber buys the plan on the 15th of the month then they will be allowed 500MB of data usage for the remainder of the month and an SMS notification message will be sent to the subscriber at 400MB usage. The table below shows an example pro-rating billing cycle.

Table 1. Pro-rating for First Billing Cycle - Simple Plan
Day of Month Data Volume SMS Notification Sent

1st

1GB allowed

800MB consumed

15th

500GB allowed

400MB consumed

21st

300MB allowed

240MB consumed

27th

100MB allowed

80MB consumed

Example 2

Plan B is a complex 1.25GB plan recurring on the 1st of every month (assuming a 30-day month) where: 1st 500MB is delivered at 21Mbps, 2nd 500MB is delivered at 1Mbps and the remainder is delivered at 128Kbps. An SMS notification is sent to the subscriber at 50% consumed and at 80% consumed. The table below shows an example pro-rating billing cycle for this plan.

Table 2. Pro-rating for First Billing Cycle - Complex Plan
Day of Month Data Volume@QoS 1st SMS Notifictaion 2nd SMS Notification

500MB@21Mbps, 500MB@1Mbps, 250MB@128Kbps

50%

80%

1st

500MB@21Mbps, 500MB@1Mbps, 250MB@128Kbps

625MB consumed

1GB consumed

15th

250MB@21Mbps, 250MB@1Mbps, 125MB@128Kbps

312.5MB consumed

500MB consumed

21st

150MB@21Mbps, 150MB@1Mbps, 75MB@128Kbps

187.5MB consumed

300MB consumed

27th

50MB@21Mbps, 50MB@21Mbps, 25MB@128Kbps

62.5MB consumed

100MB consumed

Roll Over Usage for Recurring Plans

Subscriber usage that is not consumed in one time period can be carried over to the next recurring period. Plans can be configured to allow rollover or not during the plan definition process.

If rollover is enabled, a limit can be defined for the volume of usage that is allowed to be carried over. Any unused data above the rollover limit is lost to the subscriber.

For example: A subscriber has a monthly recurring plan with 1GB of data usage. Last month he had 300MB of unused data left over at the end of the month. The plan has a rollover limit of 200MB. Only 200MB from his unused data can be rolled over into the next billing cycle.

Limited Cycles for Recurring Plans

This feature enables the operator to set limits on how many times a plan can recur.

If the operator wants to limit the plan to 3 renewals, this is achieved by setting a maximum occurrence limit of 4 during the plan definition process.

At the plan renewal time, the system will check the “occurenceCount” of the plan. If it matches the “maxOccurrenceCount” then the plan will not be renewed.

For example: If the “maxOccurenceCount” is set to 4 the following cycle occurs. The plan is renewed 3 times as desired which means there are a total of 4 occurrences of the plan.

Table 3. Limited Cycles
Subscriber Usage Occurrence Count MaxOccurrence Count Action at Expiry Time

1st time plan is used

1

4

Plan is renewed

2nd time plan is used

2

4

Plan is renewed

3rd time plan is used

3

4

Plan is renewed

4th time plan is used

4

4

Plan is not renewed: Expiry Warning notification is sent (if configured).

The following rules apply to the maximum occurrence count for data plans:

  • The “maxOccurrenceCount” parameter is set per plan and not per subscriber.

  • There is no overall expiry timer on the plan. It expires based on the cycle (i.e. weekly, monthly) in conjunction with the maximum occurrence count. Therefore, if the plan is configured as weekly and the maxOccurrenceCount is 3, it will have a lifetime of 3 weeks

Plan Top Up

This feature supports adding volume or time to a plan via the PMI.

  • If a subscriber has a 1GB plan and 0.1GB is unused, it is possible to add 200MB to the plan. It then becomes a 1.2GB plan with 0.3GB unused.

  • If the rollover feature is enabled, the volume added via plan top-up is treated the same as normal plan volume where unused data is rolled-over up to the maximum limit. When the plan thresholds are exceeded notifications will be sent multiple times.

  • If a plan is consumed and a volume top-up is done, the plan will revert to active status.

  • Threshold notifications will be sent multiple times when the top-up feature is used, e.g. a notification is sent when 80% of the plan is consumed; volume is subsequently added reducing the usage to 70%; when the usages exceeds 80% again a notification will be sent for the second time.

  • If a plan is due to expire at 16:30pm and two hours are added then the plan will now expire at 18:30pm.

The following top-up requests will be rejected:

  • Validity period top-up for a recurring plan

  • Validity period top-up for a plan with no validity period

  • Volume top-up for an unlimited plan

  • Any type of top-up when plan is in the process of being purchased or expiring

Add-On Data Plans

Add-on data plans can be purchased as a supplement to the core or recurring data plans at any time for an additional charge. This allows the subscriber an additional specified amount of data for a limited time period. An add-on data plan can also be assigned as a bonus plan to a subscriber whereby the subscriber gets the bonus data plan on sign-up, on special occasions, etc.

Add-on plan precedence is determined by the following criteria in order:

  1. Its service-blocking state

  2. The precedence value assigned when the plan is created

  3. Its QoS bit-rate4

  4. Its activation time

Time-Metered Plans

For time-metered plans, subscriber usage is based on active time quotas where active means the length of time a rule from the plan is installed and active1 on the PCEF.[1] There are a few restrictions with time-metering as follows:

  • Time Metering cannot be service or rule specific so only time metered plans that allow all services are supported. They are measured internally based only on the length of time that a rule from the time metered plan is installed and active on the PCEF.

  • A subscriber cannot have another active plan (either volume or time metered) if they have an active time-metered plan. For example, if a subscriber had a time metered plan (e.g. two hour plan enhanced QoS) and also a volume metered Facebook plan, then both plans would be installed on the PCEF. The PCRF would start counting time for the time metered plan but the subscriber could actually be using Facebook, therefore double counting the Facebook usage.

When a subscriber terminates his/her session, the time tracking stops. This makes it possible to pause/resume a time metered plan and therefore consume the plan over multiple sessions.

The state machine timeMeterSl assigns a time meter to each rule generated from a time metered plan and periodically checks which time meters have reached their granted time quota. It then reports the used time to the existing gxSession state machine which in turns reports it to the rulesHandlerSl state machine and SPCM.

The following sequence diagram shows the flow of messages between state machines and processes where a subscriber has a time metered plan which he uses during a session:

SequenceReport1


SequenceReport2

  1. The session starts as normal when the gxSession state machine receives a CCR-I from the PCEF.

    1. The gxSession requests rules from the rulesHandlerSl which in turn requests subscriber profile information from the SPCM.

    2. SPCM responds with subscriber profile which contains the subscriber’s time metered plan information. (This will indicate the metering type is “time” and the information will also include the granted time for the plan).

    3. The rulesHandlerSl processes the plan information as normal, creating rules, usage monitoring info etc. and sends them to gxSession

  2. The gxSession sends the rules in a CCA-I to the PCEF. However, as the usage monitoring for the rules is time metered, the usage monitoring information is not included in the CCA-I.

    1. Instead the time metering info is sent to the timeMeterSl via the startTimeMetering message to start time metering for this session

  3. The timeMeterSl starts a timer to expire when the granted time has been used up

    1. The timer reports the used time to gxSession via a reportTimeUsage message, which in turn reports the time usage to the rulesHandlerSl via a usage report eventReport (event trigger 26)

    2. The rulesHandlerSl handles the usage report as normal by reporting the usage to SPCM, waiting for the response and then responding to gxSession with the updated usage monitoring information containing the new granted time for the rule

    3. The gxSession restarts the time metering for the session by sending an updateTimeMetering to the timeMeterSl with updated time metering info (including new granted time amount)

    4. Step 3 then repeats over and over until the plan’s time quota is fully consumed (at which point SPCM would send a subscriber profile update notification which would trigger a RAR to PCEF to remove the rules from the time metered plan) or until the session is terminated

  4. When the subscriber does terminate the session, the PCRF’s gxSession receives a CCR-T

    1. The gxSession sends a stopTimeMetering request to timeMeterSl to stop the time metering for the session

    2. The timeMeterSl reports any residue usage since the last usage report back to gxSession which it forwards to the rulesHandlerSl in the terminateRules request

    3. This usage is then reported to the SPCM as normal

Data Plan Categorisation

Data plan categorisation allows you to define categories of subscribers which are permitted to purchase certain data plans. The subscriber categories may be based on billing type (prepaid/postpaid), subscriber class (e.g. standard/premium) or IMSI range (e.g. MVNO brand).

QoS Boost

An add-on can be purchased with QoS boost for a limited period to enhance the quality of service delivered to the subscriber. This QoS boost will supersede the default QoS of the core plan and can be started via subscriber self-care.

Bill Shock Control

The following features are supported to enable bill shock control as required by EU regulations:

  • Tracking of credit usage by location.

  • Calculation of credit usage based on a configurable rate which is applied to volume usage.

  • Configuration of SMS credit usage warnings via the PMI GUI for data-plans.

  • Blocking or restricting of data services (via QoS downgrade) when credit usage threshold is reached.

  • Counters for daily/weekly/monthly credit usage.

  • Disabling of warnings or policy changes related to credit usage via self-care.

  • Modification of credit usage warnings or policy changes threshold values via self-care.

  • Re-activation of disabled warnings or policy changes after a configurable period of time.

  • Configuration of rates and usage rules via customer-care GUI based on geographic zones.

Data Plan Lifecycle

data plan lifecycle

This section describes the lifecycle of a data plan in the Tango iAX PCC platform. The diagram below illustrates the data plan lifecycle.

Plan Activation

Plans can be activated in any of the following ways:

Default

The plan is automatically activated on purchase.

Deferred Activation

The subscriber can request that the plan becomes active at a future date and time.

The future date and time (activationtimestamp) is specified when the plan is purchased by a subscriber. The plan will be in a state of “Activation Pending” until that time and date is reached. The plan will move into an “Active” state at the specified time and date.

If the plan is not activated on purchase and a future date and time is not set, then the plan must be activated via the PMI or an API call. The current date and time will be used if an activation date is not supplied.

The following rules apply to deferred plan activations:

  • There is an overall restriction of 5 plans per subscriber. Each deferred plan will count as one plan against the 5 plan limit. The plan limit is configurable and can be set to less than 5 if desired.

  • The activation date and time must be greater than the current date and time; if the date is in the past the plan will be activated immediately.

  • For non-recurring plans a validity period can be set. The validity period means the plan is valid for a defined period from the purchase date and not the activation date.

Deferred plan activation is not supported for recurring plans.

First Usage Activation

The plan is in an activation pending state after purchase and when the first usage report for the plan is received the plan will be activated; the validity period of the plan starts and expiry timestamp is calculated at this stage.

In this case the plan definition will have an activation pending timeout period and plans will be terminated if they are not activated within this time period.

First Usage plan activation is not supported for recurring plans.

Active Data Plans

A subscriber can have multiple active data plans. The following rules apply to determine which data plan is used when a subscriber has purchased multiple data plans:

  • When a data plan is defined, it is assigned a precedence value. This data plan information is passed by the SPCM to the Tango PCRF which then prioritises the rules accordingly.

  • If the data plans have equal precedence, the data plan activation date is taken into account, where the oldest data plan is used first, followed by the next oldest data plan, etc.

  • Add-on data plans always have a higher precedence than core data plans and will be used first.

Activated/Deactivated Data Plans

An active data plan can be deactivated and subsequently reactivated by the subscribers via their self-care application. The following rules apply to deactivating/activating data plans:

  • All plans, except for Core plans can be deactivated. If a time-based plan is deactivated, the expiry period of the plan is extended by the length of time the plan was deactivated for.

  • All data plans can be set to deactivated at purchase time, so that they can be later activated via self-care or on the PMI.

  • When a data plan is deactivated, the subscriber will not be able to access any data services using that plan. However, data services may be available if the subscriber has another active data plan.

  • Each data plan (except Core plans) has a configurable maximum number of deactivations.

  • Each data plan (except Core plans) has a configurable maximum deactivation time, e.g. 2 weeks. The data plan will automatically be activated after this time period has elapsed.

Exhausted Data Plans

Exhausted data plans are data plans that have reached their volume or time limits. The next active data plan (if available) is then activated for use.

Plan Versioning

An operator can create a new version of an existing Plan Definition. This allows for changes in requirements for plan definitions that are already in use. It allows the flexibility to create a new version of the same plan with the necessary changes included. Only one version of a plan definition can be 'Available' at any one time.

Plans purchased will be created based on the 'Available' plan definition version. Existing plans will continue to use the old version until they renew.

It is also possible to clone a plan definition to create second plan with exactly the same features.

Data Plan Rules

The following set of rules set out the criteria that is used to control the creation and use of data plans in the Tango Policy & Charging Control (iAX PCC) platform.

  • Before a subscriber uses the data network for the first time, they are asked to purchase a data plan. If the subscriber does not want to purchase a data plan, they can select the pay per use option.

  • When a new subscriber purchases a data plan via self-care they are automatically provisioned on the system. If multiple data plans are active, the data plan to be used is determined by the active data plan rules described in the section titled Plan Activation.

  • When a subscriber who is not currently provisioned on the system purchases a data plan via self-care then that subscriber is automatically provisioned.

  • All data plans have a time limit. The timer is started when the data plan is activated.

  • When an active data plan has been exhausted, the next active data plan (as determined by the active data plan rules described in Plan Activation on page 44) is used. If no active data plan is available, the subscriber is notified and the charging automatically switches to pay per use.

  • Volume-limited data plans are exhausted when the volume limit is reached or the time limit is reached, whichever happens first. If the time limit is reached first, the remaining volume is discarded.

  • Time-limited data plans are exhausted when the time limit expires.

Fair Usage Policy

A fair usage policy can be applied to all data plans. A fair usage limit is a volume limit which can be applied to time-limited data plans. When this configurable volume limit (fair usage limit) for a time-limited data plan is reached, the data plan is deemed to be exhausted and the next active data plan (as determined by the active data plan rules described in the section on Plan Activation) is used. A fair usage policy can also be configured to downgrade the QoS at a configurable usage threshold level.

If no active data plans are available, the subscriber is notified and pay per use charging is applied.

Data Plan Policy Management

The SPCM manages configurable policy profiles which are associated with data plans. A data plan can have multiple policy profiles which may be activated depending on the subscriber usage.

A policy profile may contain the following attributes:

  • Service Profile - allowed IP addresses

  • QoS Profile - QoS parameters

  • Charging Profile - rating group, metering method, payment type

  • Location Profile - location constraint for Service, QoS, Charging

  • Time Profile - time constraint for Service, QoS, Charging

  • APN Profile - APN constraint for Service, QoS, Charging

A Policy Profile must contain at least a Service Profile or QoS Profile.

Meter at Discount Rate

This feature allows operators to configure (via the PMI) what percentage of the total data consumed by a subscriber is reported, based on a selection of parameters. Percentages may be assigned to the plan usage counters based on conditions such as:

  • Location

  • Time-band

  • Device

  • Network

This means that an operator can set a percentage discount, e.g. off-peak, based on a specific location or based on network type, etc.

Subscriber Provisioning

The Tango iAX PCC subscriber provisioning service provided by the SPCM allows third-party platforms to provision and update subscriber accounts on the Tango iAX PCC platform. Subscribers can be provisioned individually via the PMI GUI or self-care, or they can be provisioned in bulk by importing the subscriber information from a file (including existing legacy data plans). A subscriber purchasing a data plan for the first time is also automatically provisioned on the system if they are not already included. Some features of the provisioning service include:

  • Subscribers may be auto-provisioned when they purchase their first data plan.

  • A welcome SMS is sent to the subscriber.

  • Up to 100,000 subscribers may be batch-provisioned from a single file.

  • Subscribers with active plans from other platforms may be migrated to the Tango iAX PCC with no disruption to the active data plan.

The following subscriber parameters may be defined for each subscriber by the provisioning platform:

  • MSISDN (mandatory)

  • IMSI

  • Payment Type: prepaid, postpaid or unknown

  • Subscriber Class

  • Language

  • Core Plan (if previously defined for the subscriber)

  • Status: active or inactive

  • Location Zone

  • Billing Day of Month

The Tango iAX PCC subscriber provisioning platform also allows subscriber updates. The following subscriber attributes may be updated:

  • IMSI

  • Payment Type: prepaid, postpaid or unknown

  • Subscriber Class

  • Language

  • Status: active or inactive

  • Location Zone: home location zone for the subscriber

  • Billing Day of the Month

The Tango iAX PCC system will return an error report per subscriber in the case of provisioning failures.

Subscriber Provisioning Call Flows

The following sections show the call flows associated with subscriber provisioning over the HTTP REST API in the Tango iAX PCC.

Provisioning a Single Subscriber with a Chargeable Core Plan

The diagram below shows the call flow for this subscriber provisioning task.

SingleSubscriberWithChargeableCorePlanFlow

  1. The SPCM detects and validates the subscriber provisioning request.

  2. The SPCM creates a subscriber record in the PCC database.

  3. The SPCM generates a Subscriber Creation CDR.

  4. The SPCM creates the subscriber plan record in the PCC database which includes the following information:

    • Plan status (depends on whether the plan is auto-activated or purchased)

    • Plan recurrence flag

    • Usage counters

    • Usage rules

    • Usage timers

  5. The SPCM debits the charge for the data-plan from the subscriber’s account over the open charging interface.

  6. The SPCM generates a Subscriber Plan Added CDR.

  7. The SPCM returns a successful result code to the subscriber provisioning client.

Provisioning of Multiple Subscribers from a Remote Client – successful

The following diagram shows the call flow for this bulk provisioning task.

BulkSubscriberSuccessfulPlanFlow

  1. The SPCM detects and validates the subscriber provisioning request. All the subscriber provisioning requests are detected as valid.

  2. The SPCM returns a success response code to the subscriber provisioning client. NOTE: The SPCM may be configured to return this response code after validation or after subscriber creation.

  3. The SPCM creates the subscriber records in the PCC database.

  4. The SPCM generates a Subscriber Creation CDR.

  5. If a core plan is specified, the SPCM creates the subscriber plan records in the PCC database, including the following information:

    • Plan status (depends on whether the plan is auto-activated or purchased)

    • Plan recurrence flag

    • Usage counters

    • Usage rules

    • Usage timers (e.g. validity-expiry, usage-reset)

  6. If a charge is applicable for the core plan the SPCM debits the charge from the subscribers account over the open charging interface.

  7. The SPCM generates a Subscriber Plan Added CDR.

  8. The SPCM returns a successful result code to the subscriber provisioning client.

Bulk Provisioning of Multiple Subscribers with Some Failures

The following diagram shows the call flow for this bulk provisioning task.

BulkSubscriberFailureslPlanFlow

  1. The SPCM detects and validates the subscriber provisioning request and some subscribers are detected as already existing.

  2. The SPCM returns a response to the subscriber provisioning client with a report on the subscribers that failed. There is an entry for each subscriber with MSISDN, IMSI and failure code (subscriber already exists). NOTE: The SPCM may be configured to return this response after validation or after subscriber creation.

  3. The SPCM generates a Subscriber Creation Failure (subscriber already exists) CDR for each subscriber that already exists.

  4. Provisioning continues for valid subscribers.

  5. The SPCM creates the subscriber records in the PCC database.

  6. The SPCM generates a Subscriber Creation CDR.

  7. If a core plan is specified, the SPCM creates the subscriber plan records in the PCC database, including the following information:

    • Plan status (depends on whether the plan is auto-activated or purchased)

    • Plan recurrence flag

    • Usage counters

    • Usage rules

    • Usage timers (e.g. validity-expiry, usage-reset)

  8. If a charge is applicable for the core plan the SPCM debits the charge from the subscribers account over the open charging interface.

  9. The SPCM generates a Subscriber Plan Added CDR.

  10. The SPCM returns a successful result code to the subscriber provisioning client.

Subscriber Meta-data

A web service is available that allows the provisioning of subscriber meta-data along with the normal SPCM subscriber account fields. Batch provisioning of subscriber meta-data is also supported via the batch provisioning tool.

The following table describes the meta-data fields that are supported.

Table 4. Subscriber Meta-data Fields
Field Name Type Description

MSISDN

String

Subscriber Identity

First name

String

Subscriber name string

Initial

String

Subscriber middle name string

Second name

String

Subscriber name string

Date of birth

Date

Number of seconds that have elapsed since the subscriber’s date of birth.

Sign up date

Date

Number of seconds that have elapsed since the subscriber was provisioned.

Gender

String

Male or female subscriber

IMSI

String

The IMSI for the subscriber

Notification Profile

NotificationProfile

The preferred notification type for the subscriber. The following options are available:

  • None

  • SMS

  • SMS Alternative

  • Email

  • Email AlternativeAudit

Audit Info

AuditInfo

The audit information for the subscriber.

Custom Field 1

String

The custom fields section allows for storage of metadata custom information. NOTE: Each field is 64 characters wide.

Custom Field 2

String

Custom Field 3

String

Custom Field 4

String

Custom Field 5

String

Custom Field 6

String

Custom Field 7

String

Custom Field 8

String

Custom Field 9

String

Custom Field 10

String

Custom Field 11

String

Custom Field 12

String

Locations and Location Zones

The Tango PCC solution supports different policy treatment based on the subscribers location. Locations are defined and grouped as follows in the system:

  • The Network Location is the actual location on the network where the subscriber is,this has a unique value/ID assigned to it.

  • A Location is a group of network locations and rates are assigned per location.

  • A Location Profile defines a group of locations. The location profile is used when a plan is being created to allow different policy control settings and constraints to be applied based on the underlying subscriber location.

  • A Location Zone defines a group of location profiles. The location zone is used when a subscriber is being added to identify the subscribers location (typically the home location). A location zone can have up to 4 location profiles associated with it.

Location Zones

The location zone feature allows for the creation of plans that can only be used when a subscriber is in their home location zone. Furthermore this feature allows for service differentiation based on specific location profile within the their home location zone.

This feature supports 4 location profiles within a subscribers home location zone.

The features of location zones include:

  • Location zones can be created and managed via the GUI.

  • A location zone can be specified for a subscriber when they are provisioned. Each subscriber can have one home location zone.

  • Each location zone has unique name and has up to four locations associated with it.

  • Typically, the location zone and associated location profiles are a one off configuration set up on the UI. However, a location zone can be modified via the UI. The location zone name and the underlying subscriber location profiles can also be changed.

Billing Date

Each subscriber can define a billing date to suit themselves. It is possible to set and change the subscribers monthly billing date on the UI. The subscriber billing date has higher precedence than a plan renewal date; therefore if a billing date is not set the plan renewal date will be used by default.

There are two modes of operation to choose from at installation as follows:

Billing Date Changed Immediately

  • The subscribers current recurring plan is terminated and is restarted from the current time with the new billing date.

  • The subscriber loses any remaining usage allowance from the previous recurring plan.

  • For the first billing cycle of the new recurring plan, the cost and usage allowance is pro rated until the new billing date.

Billing Date Changed on Next Occurrence of Current Billing Date

  • The subscribers current recurring plan is terminated and is restarted with the new billing date on completion of the current billing cycle.

  • For the first billing cycle of the new recurring plan, the cost and usage allowance is pro rated from the old billing date until the new billing date.

If the PCC has the group accounts feature enabled then the following applies:

  • When a subscriber billing date is changed, the plans affected are the subscribers non-shared plans and/or any group plans where the subscriber is the chargeable member.

  • If a plan is shared, the billing date of the chargeable subscriber is used.

Subscriber Self-Care

The Tango iAX PCC self-care API is a HTTP REST service provided by the SPCM which allows subscribers to purchase and manage data packages.

The self-care API may be used when the Tango SPCM is performing the role of SPR and subscriber accounts are provisioned on the Tango iAX PCC platform.

The self-care API allows subscribers to perform the following actions:

  • Get a list of data plans that are available to purchase.

  • Purchase data plans.

  • Get a list of the subscribers currently purchased data plans.

  • Activate or deactivate a data plan.

  • Get usage information and policy information for a data plan.

  • Deactivate usage rules.

  • Change usage rule thresholds.

All self-care functions can also be performed via the Tango PMI GUI.

The self-care API may be accessed by the subscriber through one of the following three methods:

  • USSD menu

  • Web-portal

  • Phone application

The Web-Portal and Phone Applications are not supplied by Tango Telecom Ltd. In the case of the USSD menu option, the Tango USSD Gateway translates USSD requests over MAP into the self-care API requests. Web portals and phone applications may use the self-care HTTP API directly.

Subscriber Self-Care Call Flows

This section describes the call flows for subscriber self-care in the Tango iAX PCC.

Subscriber Purchases Data Plan - Charge Successful

The following diagram shows the call flow for this subscriber self-care task.

SubscriberPurchasePlanSuccess

  1. The SPCM detects and parses the self-care request. NOTE: It is assumed that the plan is chargeable.

  2. The SPCM initialises subscriber plan records in the PCC database, including the following information:

    • Plan status (Charge Pending)

    • Plan recurrence flag

    • Usage counters

    • Usage rules

    • Usage timers (e.g. validity-expiry, usage-reset)

  3. The SPCM debits the charge for the data-plan to the subscriber’s account over the open charging interface. NOTE: The open charging interface determines whether the charge is prepaid or postpaid.

  4. The charge debit is successful so the SPCM sets the subscriber plan status to “active” if auto-activated on purchase or “purchased” if not.

  5. The SPCM generates a Subscriber Plan Purchased CDR.

  6. An SMS payment receipt is sent to the self-care client.

  7. If the SPCM detects that a data-session is active for the subscriber:

    • the SPCM sends a notification to the PCRF with an updated list of PCC profiles related to the subscribers active data-plan(s).

    • the PCRF generates PCC rules based on the updated subscriber PCC profiles received from the SPCM and installs these new rules along with usage-monitors onto the PCEF over the Gx interface.

  8. The SPCM returns a result code to the self-care client.

Subscriber Purchases a Data Plan - Insufficient Balance

The following diagram shows the call flow for this subscriber self-care task.

SubscriberPurchasePlanInsuffBalance

  1. The SPCM detects and parses the self-care request. NOTE: It is assumed that the plan is chargeable.

  2. The SPCM initialises subscriber plan records in the PCC database, including the following information:

    • Plan status (“charge-pending”)

    • Plan recurrence flag

    • Usage counters

    • Usage rules

    • Usage timers (e.g. validity-expiry, usage-reset)

  3. The SPCM attempts to debit the charge for the data-plan to the subscriber’s account over the open charging interface.

  4. The SPCM sets the subscriber plan status to “charge-failed”.

  5. The SPCM generates a “subscriber plan purchase failure due to insufficient balance” CDR.

  6. The SPCM returns a result code to the self-care client.

Subscriber Requests Usage Information

The following diagram shows the call flow for this subscriber self-care task.

SubscriberRequestsUsageInformationviaSelfcareClient

  1. The SPCM detects and parses the self-care request.

  2. The SPCM retrieves a list of the subscriber’s data plans and usage information for each plan. The following information is retrieved for each plan:

    • Status of data-plan (active/inactive)

    • Usage counter levels

    • Usage rules and status

    • Usage timers (e.g. validity-expiry date, usage-reset date)

  3. The SPCM constructs a response with subscriber usage information.

  4. The SPCM returns subscriber usage information to the self-care client.

Subscriber Notifications

The SPCM allows you to configure the notification messages that are sent to subscribers when configurable actions occur. For example, a message such as "You have exceeded the fair usage limit." could be sent to a subscriber that has gone over the configured fair usage threshold for data traffic. These notification messages can be sent in a configurable number of different languages as required.

Subscriber notifications are sent for the following events:

  • Usage Limit notification (based on thresholds)

  • Plan Expiry notifications

  • Data Plan Charging notifications (both success and failure)

Subscriber Notifications Call-Flow

The Tango iAX PCC solution includes an SMPP (v3.4) client which will bind to the operators SMSC for sending SMS notifications. The following figure shows the flow for this operation:

Bundle Management Flow

SMS Address and Alternative Address

The SPCM SMS notifications can be configured to send the notifications to a secondary MSISDN using the meta-data notification settings via the meta-data web service (see the Subscriber Meta-data section) or the batch provisioning tool [Ref. 6].

The SMS notifications are only sent to one MSISDN.

Group Accounts

The group accounts features allows a number of subscribers (prepaid and postpaid) the option to be grouped together to share the same account. They can share data quotas and avail of group plans. A GUI is provided for the creation and management of group accounts. Some examples of where group accounts can be used include:

  • Family groups, e.g. parent accounts and child accounts

  • Small businesses

  • Individuals with multiple devices where each device has its own unique MSISDN and IMEI

Group accounts are configured via the Platform Management Interface (PMI) GUI. Administrators must be assigned to the group account and the administrator privileges include changing group members, assigning member usage quotas and purchasing shared data plans for the group account. The following features/settings can be configured for group accounts/members:

  • Usage quota may be assigned per group member as a percentage of the total group volume.

  • Policy control actions for the consumption of the group usage quota may be assigned per group member. This means a group members use of a shared plan may be restricted (block-all-data or downgrade QoS or denied once they have consumed their quota of the shared plan.

Changes to the group account settings for “quota percentage” and “quota consumption action” have immediate effect for each subscriber

  • The group member to be charged for the plan purchase may be assigned from the list of group members. This member is charged for any shared plans which are purchased for the group. Usually the administrator is the member who is charged.

Group Account and Group Plan Rules

The following rules apply to group accounts and group plans in the iAX PCC:

  • A subscriber may only be a member of one group account.

  • A role is assigned to each group member and the member is only allowed to perform actions which are defined in the role.

  • A group account may have a single shared core plan and multiple shared add-on plans.

  • Individual group members can purchase their own individual add-on plans which are not shared by the group.

  • Individual plan features are inherited by group plans, e.g. policy and charging control by location/time-band/device/network, policy and charging control by usage tracking, etc…​

  • Group plan precedence is managed in the same way as for individual plan precedence:

    • Core plans (shared or individual) are usually lower in precedence than add-on plans (unless the add-on plan is blocking all data access in which case any plan in a service blocking state will have the lowest precedence).

    • Add-on plan precedence is determined by the following criteria in order: (i) Its service-blocking state (ii) The precedence value assigned when the plan is created (iii) Its QoS bit-rate (iv) Its activation time

Generally plans are given precedence based on the following criteria:

  • Plans with a service profile that blocks all data are given lowest precedence while plans with a non-blocking service profile are given the highest precedence

  • Plans with the same service blocking state are given precedencebased on the precedence value assigned to them when the plan iscreated

  • For plans with the same assigned precedence value, QoS bit-rates are checked, with the higher rate taking precedence

  • For plans with the same QoS bit-rates, activation dates are checked, with the earlier activation taking precedence

  • All group members receive SMS notification on group account activation, individual quota consumption and group limit consumption.

  • When the total shared plan usage limit is consumed, the plan is unavailable to all members until the next plan renewal date in the case of a recurring plan or the plan is terminated in the case of a non-recurring plan.

Group Plan Types

Group accounts can have a range of plans and attributes. These plans and associated attributes are described in the following table.

Table 5. Group Plan Types
Plan Type Plan Status Group Account Functionality

Core Plan

Purchased for the group account.

The core plan is accessible to all group members.

Recurring Plan

Recurring plan purchased for the group.

A recurring plan is a data plan that is automatically recharged and the usage reset after the validity period has expired. Recurring plans continue to be recharged automatically until cancelled via the PMI or a configurable expiry date has been reached. This plan is shared among all members.

Add-on Plan

Add-on plan(s) purchased for the group

The add-on plan is accessible to all group members according to the “quota percentage” assigned to each member.

Add-on Plan

The plan currently being consumed by the group.

A group account may have multiple active plans. The following rules apply to determine which data plan is used when a group has purchased multiple data plans:

  • When a data plan is defined, it is assigned a precedence value. This data plan information is passed by the SPCM to the Tango PCRF which then prioritises the rules accordingly.

  • If the data plans have equal precedence, the data plan activation date is taken into account, where the oldest data plan is used first, followed by the next oldest, etc.

  • Add-on data plans always have a higher precedence than core data plans and will be used first.

Individual Member Plan

Group members purchases a plan for individual use.

Other group members do not have access to these individual plans.

Otherwise shared plans inherit all of the features of normal subscriber plans such as listed below:

These features are applied on a per plan basis and not per subscriber/group member.

  • Core/Add on plans

  • Recurring/Non Recurring plans

  • Plan activation/deactivation/deferred activation

  • Service filtering

  • QoS control

  • Charging control

  • Subscriber notifications for plan purchase, activation, consumption, expiry warning, expiry, renewal, or when plan-specific usage thresholds are exceeded

  • Usage tracking based on time, location, device or network parameters such as RAT type and APN

  • Change of PCC rules based on usage, e.g. Fair Usage Policy

  • Pro-rating of cost and usage limit

  • Roll-over of unused data (for recurring plans)

  • Renewal day of the month (for recurring plans)

  • Limited occurrences of a recurring plan

  • Location zones

  • IMEI locking

  • Gifted bonus plan

LBO SMS Provisioning

Local Breakout (LBO) enables mobile network operators to offer affordable data roaming to inbound international roamers by allowing them to register on the operators local network.

This is facilitated by the LBO SMS Provisioning service as follows:

  • The roaming subscriber purchases an LBO voucher and sends an SMS with the voucher number to a specific LBO MSISDN to register for the LBO service.

  • The LBO SMS Provisioning service verifies that the MSISDN is from a country and network that is permitted to use the LBO service.

  • The voucher is validated via an external voucher management system (VoMs). where the face value is determined and the LBO Provisioning service applies the appropriate data plan to the subscriber.

  • The LBO SMS Provisioning service sends an SMS to notify the subscriber that the registration attempt was successful.

The subscribers MSISDN is foreign to the local network and therefore it is assigned a “dummy” MSISDN that will be recognised by the network when consuming the voucher.

The LBO SMS Provisioning service appears as a mobile device on the local network. This enables it to “act” as a HLR in order to accept the foreign networks initial SRI-SM request to retrieve the MSISDN of the inbound roamer. It subsequently “acts” as an MSC to handle the FWD-SM message.

The following diagram shows the message flow from the start of the registration attempt.

MessageFlowForSMSDeliveryLBOVPSMSISDN

Policy Promotion Service (PPS)

The Policy Promotion Service (PPS) facilitates the provision of bonus plans to subscribers who have purchased a configured volume of data plans within a configured time period.

The PPS is composed of the following components:

  • PPS web service (PPS-WS)

  • PPS-Executor

PPS Process Description

The PPS process is illustrated in the diagram below.

PPS Process

  1. Using the PMI, the administrator creates the promotion rules and the plan identifier whitelists via the PPS-WS. For example, a promotion rule may state that subscribers are given a bonus data plan (BonusPlan1) on purchasing 10Gb worth of data plans over a 10 day period from a specified list of allowable plans.

  2. A periodic task/cron is executed on each live traffic SPCM node to copy SPCM plan CDRs to the configured PPS base directory on the PPS node.

  3. Periodically, the PPS-Executor scans the PPS base directory for SPCM plan CDRs.

  4. The PPS-Executor reads the promotion rules before processing each CDR file.

  5. The PPS-Executor does the following for each CDR file:

    1. Updates the relevant purchase counters for any matching promotion rules found.

    2. When the promotion rule threshold has been reached, schedules a bonus plan promotion for purchase at the next scan of the promotion table.

  6. A separate task scans the promotion table for new bonus plan entries. A plan purchase request is sent to the SPCM WS for any new promotions and the result is recorded in the promotions table.

PPS-WS

Promotion rules define conditions under which subscribers are granted bonus plans. The PPS-WS provides a HTTP REST interface through which you can create, delete, and update promotion rules. Additionally, the PPW-WS manages whitelists of eligible promotion plans. Promotion rules compare the plan name in the SPCM CDR against a promotion plan whitelist to determine if the plan usage is to be processed for that subscriber.

For more information on the HTTP REST API of the PPS-WS, see the Tango iAX PCC API Guide [Ref. 9].

PPS-Executor

The PPS-Executor analyses and processes SPCM plan CDRs, evaluates them against promotion rules configured through the PPS-WS, and executes a request to purchase bonus plans for subscribers when criteria specified in the promotion rules are met.

PPS File Processing

CDRs are filtered by service ID, transaction type, plan state, and plan purchase type. CDRs not meeting the filter criteria are discarded. When a configured batch size has been reached, the PPS-Exector commences processing the CDR files.

The PPS-Executor compares the CDR plan name against the promotion rules plan whitelist. Each time a CDR’s plan name matches a rule, the subscriber’s purchase counter is incremented with the CDR’s volume usage limit. If the counter reaches the promotion rules threshold, a bonus plan (as configured in the promotion rule) is queued for purchase via the SPCM WS API.

Each promotion rule has a maximum bonus plan limit within a specified time period (the reset period). If a subscriber reaches the maximum bonus plan of a rule, no more bonus plans can be applied by the promotion rule until the reset period has expired. When the reset period expires, the subscriber’s usage count for the promotion rule is reset and a new reset period commences.

PPS Promotion Processing

A PPS-Executor job runs at configurable intervals to purchase any promotions pending and delete non-pending entries older than a configured time period.

To purchase promotions the PPS has its own HTTP REST client that uses SPCM REST API to interact with the SPCM. The PPS can be configured to work with a list of SPCM servers to which the PPS will send requests on a round-robin basis. It can be configured to retry on another server in the case of a problem connecting, a status 404 error, or a status 500 error.

Combo Pack Service (CPS)

The CPS feature enables you to bundle voice, SMS, or MMS plans as a bonus for subscribers who purchase a data plan.

Operators create a combo pack via the Tango PMI. The combo pack can then be associated with an existing plan definition.

When a subscriber purchases a plan, the SPCM creates an event. A CPS Agent process handles such events. If the name of a purchased plan matches the name of a combo pack in the DB then the agent adjusts accounts on the online charging service (OCS) as defined by the configuration for that Combo Pack in the DB.

If an OCS failure occurs, the CPS Agent requests the SPCM to refund the plan. If the refund fails on the SPCM, for example due to no available connection to the charging platform, the SPCM produces a Refund Deferred CDR. This CDR can be post-processed if required.

Interactions with the OCS produce CDRs.

CPS Process

1. Time-metered plans are considered active based on the time they are scheduled to become active and deactivate via Rule Activation Time and Rule Deactivation Time AVPs.