Policy Control and Charging – An Evolving Architecture Helping Disruptive Business Models

This is a short article on a relative “old” architecture, from the standardization point of view, but not yet fully used on top of its capabilities by the established MNOs (Mobile Network Operators).

Architecture Standards

3GPP Policy Control and Charging (PCC) architecture is an evolutionary not a revolutionary one. When it was proposed, their functions split off existing mobile IN (Intelligent Network, aka CAMEL) functions, translated from switch (voice) to packet domain.

The main architectural control elements specified are PCRF (Policy and Charging Rules Function) – for police control (a lot more than only QoS)  – and OCS (Online Charging System) – for charging control. Since its first release, it is ones core network architecture with more updates over the last decade, and still work in progress.

Driving New Services

Over the past years most vendors describe bunch of possible business cases to validate the heavy investment on network capabilities to support all newly policy functions. However, the evolving part of the architecture plays its role and most of new products launched were focused on online charging services, with pre-paid data plans potentials and variations being a must.

Abstracting the architecture and thinking about policy user cases, we realize that a lot of business cases didn’t come to light due to enough support on legacy packet network elements and even on standards (one reason for too many spec upgrades) and regulatory issues.

Speed Bumps

On the network side, the capability to detect and inform the correct user traffic and application were main bottleneck that 3GPP specification try to address, e.g. with the TDF (Traffic Detection Function). A great number of business models can be explored at this configuration, but it’ll require a new network element (or new capabilities on existing ones), and new interface to PCRF. Virtualization (SDN and NFV) can play a role here, easing new capabilities adoption and deployment.

On the northbound side, the 3GPP standards are less restrictive, and the MNOs should decide how easy would be integration of new services , by defining a good APIs set to expose those policy control and charging capabilities (see my previous article on online charging future here). Vendors support in providing an open and fully configurable application interface is mandatory for MNOs willing to explore those capabilities.

On the regulatory side, the policy control services face a great pressure from net neutrality rules on some markets. Less net neutrality should drive new services models, but its still unclear how deep political changes as seen with Trump’s election and Brexit will affect the current regulatory direction.

Evolution

As policy and online charging services are a cornerstone on MNOs market, the 5G ongoing discussion on core network architecture will certain drive another evolution round on PCC architecture, after VNF introduction as well.

Also IoT mass deployment will demand a strong policy control and differentiate charging from MVOs, something hard to achieve without a standard architecture.

Mindset Changing and Next Steps

As conclusion, the Policy and Charging Control architecture are a powerful technology for service differentiation. Though, a key paradigm on MNOs business systems must change.

Policy and Charging architecture should be understood as the lower end of the Operator’s service creation chain and not as core network elements. PCRF and OCS are better described as service platforms and service enablers’ functions, but they’ll add value only when tied on Operator’s service layer business process.

Operators’ online policy and charging capabilities must also be securely exposed to internal and external service partners to be able to fulfill the business models predicted by the industry.

 

Push Notification Architecture Using React and Node.JS

While I was planning my “in-between-jobs projects”, including a mobile app framework development (which resulted in SBR Photography), I bumped with the requirement of an application server to deliver Push Notifications (PN) to the mobile app (Android and iOS flavors). I know there is a bunch of commercial offers available over the Internet to do the job, but I was tied to the main project’s requirement, no cost at all (besides me).

Other project’s requirement was to be simple enough to be operated by anyone, meaning to avoid the compulsion to solve this with beauty shell script command. After some research, I’ve designed a simple architecture that could be implemented on a local Node.js server as backend and a frontend webserver done in React.js.

This PN application server solution is able to handle app tokens grabbed by a REST API Gateway on the cloud, select specific destinations options and send custom PN messages to the devices thru Google (Firebase) and Apple (APN) services. All tasks controlled by the frontend friendly UI.

Architecture

There are some major components on the system:

  1. API Gateway: a PHP server deployed on the same webserver that host the mobile app content. This component gets the push notification register (token) and other information from the app and hold on a database;
  2. Parser: a component to grab the device information from the API Gateway in CSV format and generate the objects to the backend components;
  3. Frontend: website UI to configure the custom push message to be delivered based on the target device language, OS and mobile app name;
  4. Controller: a component to control the internal backend workflow;
  5. APN interface and Google FCM interface: services that handle the Apple Push Notification (APN) keys and Google Firebase Cloud Messaging (FCM) keys related to each mobile app registered and establishes the secure communication channel to each external service to deliver the notification messages payload.

The API Gateway is a webservice that need to be always on to catch push notification register from the mobile apps. The remaining components are started over demand by operator and could be locally hosted on any end user computer.

Here the end-to-end architecture:

Architecture Push Notification Server

Implementation

Here’s a short walk through over the main project’s components.

Frontend
A very simple Single Page Application done in React, bundled with Webpack, minified and load as static asset. The original UI is also on Codepen and you can play with it. All UI changes are handled by user events, a lazy decision to avoid implement Flux into this project. The drawback of this decision is only the manual log text area update, through the ‘log’ button.

The user inputs and selection are submitted to the backend via REST API.

Backend
The backend was done in Node.js using as much as possible available packages for the parser and APN and FCM services.

Final Remarks

This project implement a local, low cost, automation to the operational process to deliver push notification to mobile app bundle, where individual notification is not a requirement. The basic architecture is robust, permits room for future improvements and is an option for initial low to mid volume mobile app deployments.