Personalized Services Instead of One-Size-Fits-All Plans: How It Works Under the Hood

Marketing comes up with these conditions quickly, but the real question is what the equipment must be able to do to deliver them. In this article, we look at why some ideas hit a wall in the network rather than in billing, what a personalized service is built from, how functions are split between nodes, and how to quickly tell whether your network is ready for personalized plans.

What a personalized service is built from

Most plan conditions boil down to a few simple actions on traffic. First, the equipment classifies traffic, that is, determines which application it belongs to. After that, four things can be done with the traffic:

1. Assign the traffic to the appropriate rating group.
2. Assign the traffic a class of service.
3. Limit the speed.
4. Control access: allow, block, or redirect.

Figure 1 — The four traffic actions that plan conditions are built from

Most plan conditions are combinations of these four actions. To keep video from eating into the data allowance, its traffic is counted in a separate group rather than the main one. Prioritizing a messaging app means marking its traffic with a class of service. And a portal after the allowance runs out is traffic redirection on quota exhaustion instead of blocking. Break a marketing idea down into these actions, and you immediately see what it requires from the network. Some conditions don’t need the network at all. For example, a shared family plan is implemented almost entirely in the OCS: the OCS grants quotas to the sessions of all family members from a common balance.

For more on rating groups, quotas, and thresholds, see the article “Gone When It Fails? How to Calculate Traffic Accounting Losses in Advance”.

Why this can’t be done in the OCS

You often hear that a plan is a commercial entity, so the charging system should implement it. The charging system grants quotas and sets the conditions for using them, but it can’t classify traffic, limit speed, or redirect a subscriber to a portal.

Four elements are involved in enforcing a plan:

• PCRF — the policy control system that determines which services are available to the subscriber.
• OCS — the online charging system. It determines how much the subscriber can use in each rating group.
• PCEF — the policy and charging enforcement node on the control plane. It combines PCRF rules and OCS quotas into a configuration for the processing node.
• DPI — the processing node on the user plane that subscriber traffic passes through. It classifies traffic and performs those same four actions on it.

On the DPI, each of these actions takes the form of a service, that is, a traffic processing rule: accounting, marking, rate limiting, or access control. All services active for a subscriber together make up their service set.

Figure 2 — PCRF and OCS functions

The full cycle looks like this:

1. The subscriber connects, and the PCEF asks the PCRF which services are available to the subscriber.
2. The PCRF returns rules: which rating groups applications belong to and which classes of service, rate limits, and access rules to apply.
3. The PCEF requests quotas for each rating group from the OCS and receives them along with the usage conditions.
4. The PCEF combines both responses into a configuration and creates a subscriber session on the DPI with services, profiles, and thresholds. The DPI starts processing the subscriber’s traffic.
5. When usage in a rating group reaches the threshold, the DPI sends a report to the PCEF. The PCEF passes the usage to the OCS and requests a new quota in advance.
6. If the OCS grants a new quota, the PCEF sets a new threshold on the DPI. Along with the final quota, the OCS specifies what to do once it’s exhausted, for example, restrict access to a whitelist and redirect all other requests to a payment portal. When the final quota is used up, the PCEF changes the service set on the DPI without tearing down the session.

The PCRF and OCS control different parameters, and those parameters change at different rates. The service set changes with marketing campaigns; the quota changes with every payment. If you combine these functions in one system, the charging system will have to be reconfigured for every new campaign.

Equipment requirements

Below are six requirements. They make a handy checklist for assessing whether a network is ready for personalized plans.

A separate counter for each rating group

If the equipment only counts a subscriber’s total traffic volume, a service with separate charging can’t be implemented. So a subscriber must have as many independent counters as they have rating groups, each with its own threshold, and when the quota for one group is exhausted, the action must apply only to that group’s traffic.

Each counter also has its own threshold with its own action. For example, when the main allowance runs out, the subscriber is redirected to a payment portal. If the video service is whitelisted, video keeps working because its rating group has its own quota.

Changing the service set without re-creating the session

When the allowance runs out, the set of services must change mid-session. If a new configuration can only be applied by disconnecting and reconnecting, every allowance exhaustion causes a dropped connection, and every top-up causes another one. An active subscriber may go through several such changes a day and will notice every drop. To them, it looks like poor service, and they take their complaints to the operator.

Threshold-based reports, not just scheduled ones

The equipment should send usage reports primarily when a threshold is reached. Scheduled reports remain a supplement, for example, for quota validity limits (Validity-Time) or time-based plans. Scheduled reporting forces a choice between frequent messages and stale data. With threshold-based reporting, accuracy is known in advance: the usage the PCEF doesn’t yet know about never exceeds the threshold for each rating group.

Rate limiting separate from accounting

Speed and volume are independent parameters. An unlimited plan at 128 kbps after the allowance runs out changes the rate limit, while accounting continues. Discounted nighttime traffic, by contrast, changes the charging rule but not the speed. If the equipment doesn’t let you change these parameters independently, some plan conditions can’t be implemented.

Named profiles instead of full configuration in every command

An operator has dozens of rule combinations and millions of subscribers. If the full configuration is sent in every session creation command, each command becomes large, and subscriber connections put unnecessary load on the PCEF, the DPI, and the link between them. It’s more efficient to preload the configuration onto the DPI under its own name. This named configuration is called a profile. The session creation command then contains only a reference to the profile.

Lossless accounting during network maintenance

Both the subscriber and the operator must be able to trust a personalized plan. If part of the usage is lost or counted twice during a planned node replacement, a discrepancy arises. Lost usage means direct losses for the operator; double counting means subscriber complaints. Where accounting gets lost and how to prevent it is covered in the article “Gone When It Fails? How to Calculate Traffic Accounting Losses in Advance”.

What becomes possible

If the equipment meets these requirements, personalized services are implemented as follows:

Service	How it’s implemented
Zero-rated service	A separate rating group whose traffic doesn’t consume the main quota
Application priority	Class of service based on a classification rule
Separate charging for tethering	Tethering traffic is identified by a separate classification rule and counted in its own rating group
Portal after allowance exhaustion	Once the quota is exhausted, access isn’t fully blocked. The subscriber can still reach whitelisted resources, other traffic is blocked, and HTTP requests are redirected to a payment portal
Rate limiting after allowance exhaustion	The speed profile changes; traffic is still counted but doesn’t consume the allowance
Kids’ or corporate profile	A set of filtering services that the PCRF enables based on a subscriber attribute
IoT devices	A whitelist of addresses allowed for the device, thresholds sized for low traffic, and a separate rating group
Dedicated public IP address	An address translation service controlled by policy rather than by the addressing plan
Family or shared plan	The OCS grants quotas to the sessions of all members from the plan’s common balance

The last two rows deserve special mention. A dedicated public IP address can be sold as a service without changing the addressing plan only if address translation is assigned to the subscriber by policy. Otherwise, the plan has to be defined by the subnet the address was issued from. A shared plan requires almost nothing from the network: the OCS grants quotas to all members from a common balance. Any possible overage is capped by the sum of quotas granted to members at the same time.

What personalization requires from operations

Personalized services noticeably increase the cost of handling subscriber inquiries. A complaint that “it’s not working” is no longer clear-cut. A subscriber may have exhausted the allowance in one rating group but not in another, a whitelist may be active, or a rate limit may apply. That’s why personalized plans need two more things.

End-to-end subscriber tracing

A single place should show the subscriber’s signaling across all nodes, their session state, active rules, and remaining balances for each rating group. Without this, support costs grow along with the number of plan conditions.

Plan verifiability

For every service, there needs to be a way to confirm that it’s actually being applied. Knowing that a rule is installed isn’t enough. You need to see that a specific application’s traffic landed in the right rating group and was marked with the right class of service.

Summary

A personalized plan is delivered not by billing or by the network alone but by the two working together, with each participant playing its own role:

• the PCRF determines which services are available to the subscriber;
• the OCS determines how much the subscriber can use;
• the PCEF combines PCRF rules and OCS quotas into a configuration for the DPI;
• the DPI classifies traffic and performs four actions: it counts, marks, rate-limits, and controls access.

To check whether a network is ready for personalization, it’s enough to answer two questions: is there an independent counter and an independent threshold for each rating group, and can the service set of an active session be changed without dropping the connection?

If the answer to both is “yes,” most plan conditions can be implemented on existing equipment. The other requirements in this article determine how convenient operations will be and how reliable accounting is.