API | Sebastiao Ribeiro Photography

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:

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;
Parser: a component to grab the device information from the API Gateway in CSV format and generate the objects to the backend components;
Frontend: website UI to configure the custom push message to be delivered based on the target device language, OS and mobile app name;
Controller: a component to control the internal backend workflow;
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:

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.

Online Charging Future – Evolve or Die?

Technology and service evolution are affecting Billing and Charging process inside each mobile network operator (MNO), and contributing for IT and Telecom convergence. Progress in virtualization (NFV) and new services technologies (IoT, VoLTE, 5G) based on service API ecosystems will promote new revenue streams and distinguish business models.

Those advances are developing new opportunities for online charging and marketing offering flexibility. Both are key differentiators to unveil new services revenues for MNOs’ environment.

Industry Standards

But are the technology standards and architecture ready for these new scenarios? Two main standardizations bodies are applicable for online charging, one mainly focused on network and another on business process, 3GPP and TM Forum.

The 3GPP groups define all interfaces and protocols allowing the online charging system realization on top of mobile and convergent core infrastructure. Its specifications define also the functional elements to allow session based and event based charging functions. They are main reference for the traditional platforms used for pre-paid charging control in a network based service environment.

The TM Forum Business Process Framework (eTOM) defines the processes for Manage Balances and Charging of products and events inside the Customer Domain. These processes are part of Billing and Revenue Management and covers online and offline charging. They are main reference for business systems inside the MNOs’ IT domains.

Both standards set are perfectly complementary in theory, but in the real world we are watching a technological evolution that will permit the merge of these under a freshly online charging systems (OCS) concept.

Evolution Scenario

The future convergence is not only on platforms, but also on process and operations. We can foreseeing a future were all MNOs’ charging system will be online (OCS based), fully integrated into network authentication, policy decision resources and including all business processes ranging from subscription, advice of charging and reaching the billing invoice management.

On the vendors side this should represent a new solution development collapsing IT billing systems and Telecom platforms, open up opportunities and challenges in a new front between traditional IT and Telecommunications Equipment suppliers.

Challenges

But, Are the actual MNOs willing to embrace these technologies and process evolution? This is a question with no simple and straight answer. This is a strategic decision based on where each MNO believe will be their role in the future.

We can imagine a future complex scenario where the MNOs will deal with full convergent service bundle, including voice, data, TV, IoT and OTT partners in a 5G environment. This could require a rich and flexible charging plans, able to be customized to each subscriber and robust enough to handle residential and corporate segments.

On the other far side are the MNOs that will be forced (or chosen) to offer only the data connectivity to its subscribers, with flat rate charging style “one size fits all”.

The two scenarios above are extreme ones and probably none (or quite a few) will evolve to them. The first one will demand a powerful OCS fully integrated into the business systems, plentiful of network protocols, configurable and flexible product definition interface. The second will demand a simple traditional (legacy) charging platform.

Conclusion

The real world will lay anywhere in the space under the extremes described above.

The OCS evolution for the MNOs will be strongly tied to their evolution strategy and their place in the future of connected people, devices and things. This could lead to a deep process redesign and paradigm shift, together with the adoption of all new technological standards needed to offer all services foreseen.

For the vendors, the real risk is not to be able to design a flexible solution qualified to adapt and grow to any MNO scale and requirements. The future service differentiation should be provided by the MNO product portfolio, not by the vendor solution boundaries.

The API Exposure by Telecom Operators Paradox

Last week (post published May,29/2016) it was announced a manifest from the world’s largest Service Providers to promote the suite of APIs, following the standard OPEN API proposed by TM Forum (https://www.tmforum.org/press-and-news/open-apis/). Despite the interest aroused in the industry, it is early to known if this is another technological standardization initiative that will not reflect on new Operators’ business models.

The standardization of APIs for telecommunications network resource exposure began in the 2000s with the standard OSA / Parlay (3GPP Release 99), followed by Parlay X (3GPP Release 6) and culminated with the GSMA One API and other derivative initiatives (e.g. Mobile Connect). None of these standards had widespread adoption. The key question is what is the real obstacle for standard API exposure in a common environment with broad acceptance by Service Providers, especially after the experience gained over the past initiatives?

The initiatives mentioned were primarily focused on core network features such as call control, messaging or location. The evolution of 3GPP and GSMA initiatives did not change this scenario being basically a technology update, from CORBA to SOAP and lastly REST. Such technological standards were not associated with comprehensive business models and have been adopted in a limited way by few players.

By the same time, Web 2.0 services, web search services and social networks had grown in traffic and acceptance. This new service category enabled the direct access of new companies to customers, including their relationships, behaviors and even their location. As a result, information on communication habits, consumption and customer database previously restricted to a limited group of companies, including the Service Providers, have become commonly available and easily captured, beside the privacy discussion.

With the next wave, the OTT (Over the Top) app introduction was made possible due to technological developments in mobile data networks and smartphones processing power. Now individual apps running on top of handsets’ operating systems can deploy and use proprietary messaging, location and call control, among others resources. The OTT apps allow the creation of new forms of communication above the network Operators’ control plane. It was a paradigm shift; developers now have APIs available on the device’s operating system and from any cloud service. Telecommunications services could now be created without the use of network Operators’ API, which were regionally restricted and no always available. The OTT apps can have worldwide reaching using basically two SDKs sets (Apple and Google).

Concomitant with the above revolution, quite a few Operators had dared to create own API exposure programs and SDK aimed at new demand for long tail services. The business models gap for developers to get access Operators specific features ended up being filled by external players that sell and expose their own API (e.g. Twilio, Mobyt, etc.), using the APIs or direct connection to different Operators.

Returning to the new initiative, the standard TM Forum’s Open API is described as an API family that enables end-to-end services management and throughout their life cycle in an environment where multiple partners are involved in the services delivery. The standard focuses on the business aspects (IT) and not on network features, seeking to simplify the integration processes, the DevOps adoption and new virtualization technologies (SDN and NFV). In a way, this is a standard that aims to belatedly fulfill a gap left by previous initiatives.

In my conclusion, we are again seeking a technological framework for the development of APIs for network operators, now in a model focused on business processes. But the centerpiece of a complete and comprehensive API ecosystem leaded by converged service providers, is not being treated and continues to be the result of individual initiatives.