5G Converged Charging: Overview, Specifications and Challenges


5G is advancing around the world and can already be classified as a maturing technology, although some of the innovations, such as Network Slicing, have not yet reached the expected point of use. Like any technological evolution model, justification for development was not only based in technology evolution itself, but new business models need also to be defined and described to justify the costs of system and network upgrade.

And the new business models are anchored on the ability to charge for the services and features made possible by new technology. To this end, the historical mechanism used in telecom business models for retail offerings was and still is based on the ability to properly billing and charging end user on an individual or collective basis.

Charging technology has always been a sensitive subject for operators, we can even argue that the model is outdated in relation to those applied by big techs, but it is a robust model that still meets partially the needs of offering mobile services to the customers chain.

5G has also evolved the charging technology model and procedures, replacing previous models based on interfaces supported by specialized protocols to a model based on open and flexible service interfaces, called SBA (Service Based Architecture), and a converged architecture in which online and offline models are tight tied.

This article proposes to be a summary and non-exhaustive compilation of the new charging procedures defined for the 5GS (5G System), with the objective of guiding the reader in the paths to search for more in-depth information.

Charging and Billing for 5G Architecture

5G architecture has radically changed the way mobile networks are performing charging and billing. Starting with usage collection, where there are no more files reporting consumption (xDR) being generated by any functional elements responsible for the user plane or control plane. Passing through the model, where charging is convergent and real time regardless of whether the service plan is prepaid (online) or postpaid (offline).

To achieve above requirements for convergent charging, a new functional element was introduced by 3GPP in Release 15, the CCS (Converged Charging System), which also comply to the new service architecture SBA (Service Based Architecture). All chargeable events, charging information and message commands are merged and includes the functions:

CHF – Charging Function
RF – Rating Function
ABMF – Account Balance Management Function
CGF – Charging Gateway Function

Figure 1 details above functions that were also defined in 3GPP TS 32.240 for Converged Charging System.

Figure 1 –Converged Charging System architecture
Figure 1 – Converged Charging System architecture

As CCS is complied to service-based architecture, 3GPP specification TS 32.290 introduced new services for converged charging to be consumed by others 5GS functions. These services are intended to cover all the network’s requirements related to billing and integration with Billing Systems.

CHF is seen as a service provider for the network, so other functions are needed inside Converged Charging System to complement the overall charging requirements. In this way, the RF function was defined to determine the value of the network resource usage, the AMBF where the subscribers’ account balance is located and the CGF that acts as a gateway between the 3GPP network and the external Billing and BSS systems. External interface Bx for the Billing systems is the only one that has maintained the legacy support for billing records in ASN.1 syntax, the others are based on the new SBA architecture.

Figure 2 – Charging architecture and information flow for 5GS
Figure 2 – Charging architecture and information flow for 5GS

In 3GPP Release 15 specification, CCS supports network resource usage charging, such as volume consumed, for the following 5GS network functions:

SMF (Session Management Function): for data connectivity charging, e.g. via PDU session;
SMSF (Short Message Service Function): for SMS text message charging;
PCF (Policy Charging Function): for control of usage limits.

Within SBA architecture reference, Nchf_ConvergedCharging is main service provided by CHF. It is specified in TS 32.291, contains Create, Update, and Release operations, and has the SMF and SMSF network functions as its primary consumers. The CHF also provides the Nchf_SpendingLimitControl service, which is specified in TS 23.503 and PCF is its consumer.

All operations for Nchf_ConvergedCharging and Nchf_SpendingLimitControl are based on HTTP POST method.

Charging and Billing Capabilities

3GPP defines some charging and billing procedures for 5GS summarized below.

5G data connection charging, specified in TS 32.255 and includes PDU session charging, data service flows (within the PDU session), and QoS flow (within the PDU session). The billing information is collected as QoS flow Based Charging (QBC) by the CHF in each PLMN.

Converged 5G SMS charging, as defined in TS specifications 32.274, 32.290, 32.291 and 32.298, SMSF network function charging and billing improvements for IP-SM-GW element.

The API interface which is defined via network exposure functionality. Network resource exposure capabilities have been specified in the 5G architecture in documents TS 23.501, TS 23.502, and TS 23.503. Network Exposure Function (NEF) APIs are specified in TS 29.522 and are interoperable with other network functions (NF) through the Service Based Interface (SBI). 3GPP TS 32.254 specification for billing APIs covers the interoperability of SCEF with SCS/AS, including online and offline event-based billing.

Charging for mobility management features via AMF (Access and Mobility Management Function). An evolution of the billing concept to collect usage of other 5GS features associated with AMF, such as registration management, mobility, and access connection. These features are defined in TS 32.256.

5G EPC Interworking Charging

3GPP has also defined enhancements in the charging for interoperability of 5GS with EPC (4G), enabling interoperability between 5GS and EPC architectures, when the User Equipment (UE) supports both networks and needs to be able to perform handover between these two modes.

By TS 23.501 and TS 23.503 specifications, networks can support interoperability procedures and these procedures can use the N26 interface. The N26 interface is defined as an inter-CN interface between the MME in the EPC network and the AMF in the 5GS. Interoperability between 5GS and EPC defines billing processes via interaction between PGW-C + SMF with CHF through the same interface defined between SMF and CHF. The corresponding triggers, message flow and parameters are specified.

Network Slicing Charging

Network Slicing functionality defined for 5GS represents an evolution of the way mobile network services are offered and expands the ability to offer new business models, such as B2B services and NSaaS. 3GPP specifies network slicing charging capabilities on a per-device (UE) and per-tenant basis, requirements based on the charging requirements received from the 3GPP working groups (SA1 and SA2) and GSMA.

On the basic, Network Slicing billing is collected via network slice instance information that the PDU session belongs to, which is then reported to the CCS via charging service.

In Release 16, billing management was expanded to Network Slicing (NS) with the introduction of NS lifecycle management (NSM) and NS Performance and Analytics (NSPA). CCS receives the billing information report for the NSPA, such as latency and throughput, and for the NSM, such as the billing service list for Network Slice Instance (NSI) for creation, modification, and termination. For Release 17, an enhancement is introduced in NS billing for data connectivity, the CHF was extended within the CCS to NS tenant, through the S-NSSAI parameter.

New NF was defined for Network Slice charging within Converged Charging architecture, the CEF (Charging Enablement Function). CEF is a consumer of the billing Nchf service and, for the purpose of collecting performance data and billing analytics, may consume managed services (MnS), services exposed by other NF, such as Network Data Analytics Function (MWDAF), or both, as specified in TS 28.201.

Figure 3 – Network slice performance and analytics converged charging architecture (TS 28.201)
Figure 3 – Network slice performance and analytics converged charging architecture (TS 28.201)

Network Slice lifecycle management charging covers creation, modification, and termination of Network Slice Instance (NSI) and is based on two alternate architectures defined in TS 28.202. One of the architectures defines the CEF as a consumer of the Nchf charging service and consuming managed service (MnS) and the other defines a CTF internal to the MnS Producer as responsible for collecting NS management charging information and acting as a consumer of the Nchf billing service.


Billing and charging procedures for 5GS follow the network evolution capabilities and enable creation and offer of new business models. On the other hand, they create some challenges for legacy Billing and BSS systems, due to the amount of new information generated, the change in the collection of usage information and the new design for a convergent architecture.

The flexibility of the SBA architecture will encourage more advanced charging models and hoping stimulate creativity in the design of new services. Some scenarios of network resource exposure and roaming have not been explored in this article and should be addressed in further work.

Adoption of new charging models can also pave the way for even more evolution ahead with upcoming 6G specification.


List of specifications cited:

3GPP TS 23.501
3GPP TS 23.502
3GPP TS 23.503
3GPP TS 28.201
3GPP TS 32.240
3GPP TS 32.255
3GPP TS 32.256
3GPP TS 32.274
3GPP TS 32.290
3GPP TS 32.291
3GPP TS 32.298


3GPP             3rd Generation Partnership Project
5GS                5G System
ABMF           Account Balance Management Function
AMF              Acess and Mobility Management Function
ASN.1            Abstract Syntax Notation One
BSS                Business Support System
CCS               Converged Charging System
CDF               Charging Data Function
CEF               Charging Enablement Function
CGF               Charging Gateway Function
CHF               Charging Function
CTF               Charging Trigger Function
EPS                Evolved Packet System
IP-SM-GW    IP-Short Message Gateway
MME             Mobility Management Entity
MnS               Management Service
MWDAF       Network Data Analytics Function
NEF               Network Exposure Function
NF                  Network Function
NS                  Network Slicing
NSI                Network Slice Instance
NSM              NS lifecycle Management
NSPA            NS Performance and Analytics
OCF               Online Charging Function
PCF                Policy Charging Function
PDU               Protocol Data Unit
PLMN            Public landline Mobile Network
PGW-C          PS Gateway – Control plane
QBC              QoS flow Based Charging
RF                  Rating Function
SBA               Service Based Architecture
SBI                Service Based Interface
SCEF             Service Capability Exposure Function
SCS/AS         Service Capability Server/Application Server
SMF               Session Management Function
SMSF            Short Message Service Function
TS                  Technical Specification
UE                 User Equipment

Custom Fields Usage in LugarVazio Theme

LugarVazio Theme for WorldPress includes a number of custom fields which can be used to configure certain aspects of pages and posts.



Define qual categoria é para ser usada em página de categorias (page with cat).


If exists (value ‘1’) define to use image position defined inside post edit area and do not use featured image on post top.


to be defined


to be defined


You can set the meta description of each page using this custom field.


…and you can also set meta keywords on a page by page basis too.


If you use the [more] shortcode in your post, you can change the default ‘Read More’ link for each article listed on the homepage to something a little more descriptive and inviting such as ‘Find out more about Widgets!’ (this does not work for the for the ‘featured page’ feature).


If exists block theme social buttons to be shown in post and page.


Quantidade de posts mostrar em uma página de categoria (page with cat).


to be defined


The URL of a thumbnail image associated with the post which is used by the HeatMap Theme ‘Recent Posts PLUS’ widget.


A very short text excerpt for use with the HeatMap Theme ‘Recent Posts PLUS’ widget.


Link text which sits underneath the short-excerpt when using the HeatMap Theme ‘Recent Posts PLUS’ widget.

LugarVazio Theme – Positioning Widgets in Post

How to place widgets when using WorldPress LugarVazio Theme. Old reference.

To start placing your widgets on your heatmap you need to go to Appearance -> Widgets, and you’ll see all the available default WordPress widgets as well as the ad widgets you just created.

All the standard built in WordPress Widgets have been styled ready for use in the Sidebar positions.

If you are using WordPress 2.8 upwards you can just drag and drop these widgets into their appropriate positions.

It’s important to know that LugarVazio Theme is designed with experimentation in mind.

Have fun trying different ads out in different positions to see what effect it has.

Some WordPress widgets and ad widgets require a certain amount of space. Note the following about each widget position before you start tuning your ad positions to suit your blog and content:

[Widebar] Top

In the default LugarVazio theme this sits at the top of the sidebar, and is suitable for Ads which are 300 pixels wide, such as the Medium Rectangle (300 x 250). It’s also great for widgets that need lots of room for text such as the LugarVazio Theme ‘Recent Posts PLUS’ widget and WordPress ‘Recents Post Widget’.

[Widebar] Bottom

This sits right at the bottom of the sidebar, and is suitable for similar widgets as the [Widebar] Top widget position

[Sidebar] Left and [Sidebar] Right

These two widget positions sit side by side in the sidebar, sandwiched between [Widebar] Top and [Widebar] Bottom.

[Sidebar] Left is suitable for Wide Sky Scraper Ads (160 x 600) and Link Units (160×90).

[Sidebar] Right is suitable for Skyscraper ads (120×600), Link Units (120 x 90) and 125 x 125 square ads.

Some of the standard WordPress Widgets do work just fine in here too, such as the calendar, WordPress Search Box and Meta. Experiment to see what works in these narrower format boxes.

[Header] High

This position sits above the Theme logo header, and expands the top of HeatMap Theme to accomodate a Leaderboard (728×90) ad.

[Header] Right

This position sits to the right of Theme logo header, and accommodates a Banner (468×60) ad.

[All Content] Above

You can place an ad widget right above the title of your content using this position. It would make a great home for a Banner (468×60) ad or a Link Unit (468 x 15).

[All Content] Below

If you need an adsense ad widget below your entire article (including the post/comment details block), then this is the one to go for. Suggested ads for this position are Banner (468×60) , Link Unit (468 x 15), Medium Rectangle (300 x 250) or Large Rectangle (336 x 280) ads.

[Content Item] Above

If you want to pop an ad widget right underneath the title then this is the place to put it. Again it makes a great home for a Banner (468×60) ad or a Link Unit (468 x 15), but also can be great for placing a high visibility Medium Rectangle (300 x 250) or Large Rectangle (336 x 280) ad if you are going for a ‘maximum visibility, maximum revenue strategy’ – use with care.

[Content Item] Below

This position sits below the article content, but above the post/comment details block.

[Content Item] Left and [Content Item] Right

If you want your ad to wrap around your text at the top of the article then this is the one to go for. Depending on how visible you want your ad to be, it’s a great spot for the Square Ad (250 x 250) or Medium Rectangle (300 x 250).

Important: Featured Page Option

Please note that if you use the Featured Page option in the LugarVazio Options Page, that the featured page will have widgets applied to it as if it were the first blog entry on the page.

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.


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.


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


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

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.

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.


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.


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.

What about MNOs’ IoT Business Models?

We are entering in a new era where the data connectivity will expand to integrate ordinary things around us. The Internet of Things (IoT) technology already allows a myriad of “things” (and its integrated electronic modules) to be connected by companies and end users to collect data and automate simple daily tasks, in an unprecedented scale. All this capabilities are being driven by new or evolved technologies like computer miniaturization, big data analytics, microelectromechanical systems (sensors and actuators), IPv6, cloud, virtualization and Low Power Wide Area (LPWA).

Mobile IoT increasing importance

Even considering that most of IoT’s applications are based on non-mobile devices, Ericsson Mobility Report (June 2016) predicts 14.2 billion non-cellular IoT devices versus 1.5 billion cellular IoT devices by 2021, the mobile connectivity is of increasing importance. The same report also foreseen that IoT mobile devices will surpass mobile handsets by 2018. Due to wireless technologies (LPWA) evolution, the IoT devices will tolerate better battery life (over 10 years), low cost connection and high coverage.

As result, big technology companies (e.g. Apple, GE, Google, IBM, Oracle, etc.) are building their own IoT ecosystems and products, some based on services as data analytics and cloud, and other based on dedicated hardware (modules and semiconductors) and software (Operating Systems and protocols). On the other side, a bunch of new start-ups are also developing their own systems and products. Some of them are targeting IoT’s Application and Service Providers and other pursuing the end user market.

IoT Business Models

But how will the mobile network operators (MNOs) define their business models to capture space into IoT market? The LPWA and other narrow band wireless access technologies gave us an easy answer, but the IoT device scale, small payload data and low cost connectivity could not be enough to remunerate the upcoming cost to build a new access network.

Anticipating the market, some companies are already building dedicated wireless networks based on non-standard LPWA to connect the IoT devices. LoRa and SIGFOX are key technologies on this field. Current proprietary LPWA network architectures rely on centralized gateway to perform data aggregation from various devices and data preprocessing. Companies offering LPWA accesses are using this architecture design to also offer value added services thru the gateway, providing dashboards, reports, security and API access to IoT devices.

On the other side, the 3GPP standards based technologies (mostly NB-IoT and LTE-M) allow direct access to IoT devices, bringing flexibility to IoT application providers and opening new opportunity to third party players to offer services as data analytics, managed service and security. This is an apparent benefit for market development but can hurt the MNO business models, which can be constrained to a low cost dumb pipe offer.

Hopefully 3GPP defined a MNO standard network architecture that can help in adding value to the IoT connectivity business. The specification TS23.638 defines an element called Service Capability Exposure Function (SCEF) that provides a means to securely expose the services and capabilities exposed by 3GPP network interfaces. This element can also aggregate MNOs’ value added services and expose its capabilities as APIs to third party actors.


The conclusion is that mobile IoT will demand a new set of value added services ranging from data analytics, security, network policies, cloud, etc.  As all these services will be useful and common for all IoT applications, upcoming aggregators companies can play a key role reducing costs and offering a scalable product to IoT service providers.

The MNOs’ business models must consider these new services to leverage the investments needed to build the access networks for IoT. It must also be considered that connectivity management platform acting also as standard 3GPP SCEF element and API gateway to application providers can generate a new revenue stream to future MNOs’ IoT products.


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.


First Post

This is the beginning, it takes a long time for me to figure out how to create this site and if should be a good idea do it. But after some indecisions and a lot of experimentation on formats, layouts and design, finally my home page is up and running.

Why create an own site and domain instead to use a page on Facebook or Instagram? In simple words, because I want a place where I can decide about format, content, and my policies and terms. I will continue to use Instagram, 500px, Twitter, Facebook and others; there is no chance to win alone in the Internet, but I need a place to experimentation, to share my thoughts and maybe make some mistakes.

To start this blog, I present an image captured on a business trip to San Francisco in Oct/2015. We were in a terrace during the lunch time and I noted the seagull outside the glass looking inside, probably knowing that someone could seat on the tables and share some food. Hopefully I was with iPhone in hands and ready to use it. This photo was selected and published on NatGeo Your Shot site as one of Daily Dozen (Nov, 30/2015).