Category: Charging (page 2 of 2)

Announcing SCALE-UP Project

ICCLab, ZHAW is pleased to announce the successful start of the project SCALE-UP which is funded under program CUS 2013-2016 P-2 from swissuniversities. The project consortium includes 9 leading universities of Switzerland including EPFL, Universities of Bern, Basel, St. Gallen, USI, ZHAW, FHNW, FFHS, and FHSG. The kick-off meeting took place on August 28, 2015, at the project coordinator’s premises. The consortium is led by SWITCH. Continue reading

Conference Report : ConTEL 2015

This is an experience report of presenting a paper and attending the ConTEL 2015 conference.

The 13th Conference on Telecommunications was co-organized by Graz University of Technology and University of Zagreb at Graz in Austria. This edition of the conference focused primarily on Optical Communications and Near Field Communications. The conference was organized for two and half days and saw about 45 papers being presented.

Continue reading

CYCLOPS Dashboard: Usage visualization, rate configuration & billing for OpenStack

The first version of the Rating, Charging and Billing Dashboard is now available on Github! The dashboard is targeted towards a cloud service provider and their client. It has different views for an end user and a cloud administrator. The dashboard interacts with the different micro services of Rating, Charging & Billing to get the relevant data and for storing the configuration settings.

Following are some of the salient features of the dashboard –

  • OpenAM powered authentication and authorization.
  • Association of OpenStack account with the dashboard account
  • Separate view for an end user and a cloud administrator
  • User rights management
  • Visualization of resources consumed
  • Enabling different rate policy for cloud resources
  • Visualization of the generated rate of a resource
  • Visualization of charge data generated for a user

Let’s have a look at the features in detail:  Continue reading

Dynamic Rating, charging & billing for cloud – a micro service perspective

Rating, Charging & Billing (RCB) has been an ongoing research initiative from ICCLab. As part of this, a proof of concept (PoC) for OpenStack has been developed and released under Apache Licence v2.0. The PoC is a standalone application which can collect the resource usage data from Ceilometer for a certain time period interval, define a pricing function per user, determine the price for the resource used per user and eventually generate a bill and display it via a PDF. This is demonstrated through a video.

Even though the architecture used in PoC was able to demonstrate all the basic functionality of RCB, it was not extensible and not suitable for being deployed in the distributed environment. It was also observed that the data produced at different stages for RCB process had the potential to create a platform upon which other applications using them, could be built. With these drawbacks, an attempt has been made to redesign the architecture from a modular & micro service perspective.


CYCLOPS Architecture

The new architecture has been split into multiple micro services consisting of User Data Records (UDR) Generator μ service, Rating & Charging μ service, Billing μ service, Message broker μ service and authentication service.

Continue reading

Rating, charging and billing for the clouds – Cyclops demo

In the past few months, the ICCLab has been developing a generic rating-charging-billing engine that would offer cloud service providers a modular framework that enables dynamic pricing activities and distributed design. The model closely follows the general accounting process, in the same time providing a lot of flexibility due to the loosely-coupled design. The platform is currently being developed in Python on top of OpenStack using its Ceilometer component for collection and extraction of the metered data. To enable this facility, we have created a custom Ceilometer client that uses REST APIs to get the needed data records. The key architectural components are:

  • Mediation module: The data coming from the monitoring devices needs to be combined in a single user session and transformed in a common format.
  • Charging module: The rating engine collects the usage records and applies the appropriate pricing strategy.
  • Billing module: The basic billed amount in a billing cycle is generated by aggregating the charge records and readjusts it by applying discounts, penalties, taxation etc.
  • User/Management interface: The service can be accessed by a web-based user-interface that allows configuration of every aspect of the RCB process.

In the video below, a demo of the first Cyclops prototype is being shown. In the scenario, we take a look at the basic admin features: listing all the tenants and their respective users, checking the user status, calculating the accumulated cost per user, as well as starting a periodic counter for the specific user. The facility for defining the pricing function for a particular user, allows the admin to choose some of the available meters and apply standard arithmetics to get the desired formula.

This is the first prototype for our RCB solution. In future, the platform would offer more advanced rating and charging models with the support for discounts, taxation, penalties etc, as well as support for other cloud platforms.


Rating, Charging, and Billing for the Clouds

Cloud has revolutionized the way we think of computing now. Now everything is on-demand, self-service, pay-as-you-go, and scalable. Although, these are welcome features that tremendously reduces the CAP-Ex and OP-Ex for any business, but the true potential of the clouds in regards to novel rating-charging and billing potentials has yet to be realized. Infrastructure clouds are being treated as commodity now. Much of the innovation is now shifting towards platform and software services over infrastructure clouds.

Telecom domain has always seen lots of innovations in this regard – different tiers of pricing, bundled services, numerous packages, and what not. And think about it – they only offer in reality just 1 type of service namly voice traffic. They have standardized their protocols, they even have a standard to facilitate charging and billing a.k.a Diameter. Not downplaying the significance of their innovation, the standards are needed as the consumers are mobile and they roam from one business domain into another – and unless their interfaces, user-equipment radios, accounting is streamlined (read standardized) it would be almost impossible to support the demands of a modern telco consumer.

So now the question to ask is – is there a need to replicate what has been done in the telecom world for the cloud services? I tend to lean towards a NO. The needs of the cloud consumers are not same as a telco consumers. By keeping things manageable and simple – cloud providers can keep costs low which further reinforces the USP of the clouds – simplicity and lower costs. The computations in the cloud are generally not mobile – there is typically no need. By virtue of the Internet – a computation could take place in any part of the world and there is a complete delinking of customers’ actual location and where the services are being offered from, as long as certain broad-ranging SLAs are satisfied. Therefore there is no real need for cloud hardware systems to implement complex plethora of standards. And that could be argued for the charging and billing strategies too (there is a need for standards in the consumer facing management interfaces for mitigating vendor lock-ins, but I reserve it for another blog post for another day).

A unified and simple billing strategy would work wonders for the consumers. But one also should be mindful of willy-nilly application of such a strategy. There is a need to justify the cost to the consumer as well as the cost to the provider. And hence a proper rating-charging engine is desired. And that is where there is still a lot of room for innovation in the world of clouds. Modern infrastructure management stacks including CloudStack and OpenStack already include monitoring models and metering functions in their core offering. These must be utilized by the provider in determining the real cost of operating their cloud infrastructure, and then tie this to the cost offered to the consumers.

A proper rating-charging engines would really help the providers make a sound judgement in this aspect. There are already numerous open source products including jBilling,,, etc. in the market. The “open” part is a severely crippled offering either providing simple billing interfaces, or features without ability to compute and process “usage data records” (UDRs). There is a real need for a true open-source platform that would allow numerous cloud services to accurately undertake rating-charging activity for their customer so that they can keep the billing model accurate, simple but “no simpler”.

If we now consider PaaS services – there is a scope to do lot more with a unified RCB engine. The umbrella of metrics of interest would be dependent on the platform services and therefore the RCB engine must be adaptive for such systems. The built-in measurement systems have to be evaluated and proper metering mechanisms enabled / provided.

In summary, rating-charging-billing innovations are necessary for several reasons (money, money, and more money …), and the innovations in the world of the clouds are just starting.

Making money from your cloud services – Part 2

A thoughtful pricing strategy goes a long way!

In my previous post, I tried to explain in brief the various steps that makes (or ought to make) up a general business accounting workflow. The process described in that post was adapted for the cloud service business context. Staying with the same theme, in this post I will try to show some light on the next logical step in the service monetization process.

The holy grail – the optimal pricing strategy

It is very important to have the correct pricing strategy in place. In an arena which is getting increasingly crowded, it is very important to stand out from the rest. You can either create a cloud service offering which is truly outstanding in nature, but in this era of fast technology changes and cutthroat competition, very soon you will find your innovative space being encroached by copycats and other competitors. You will have to keep on innovating, and in step – you must also differentiate your service in terms of an attractive pricing for end users. This does not necessarily imply offering lower prices, but having a smarter pricing model in place for the full spectrum of consumers you cater to (enterprises, individuals, public organizations, governments, not-for-profit groups, etc.). The design of your optimal pricing strategy will be very much service model dependent, so I will not try to prophesize a universal pricing strategy. If I dare say that I have a universal strategy in place – I would be lying. Therefore in this post I will cover the various pricing strategies to help you design a custom strategy most suitable for your cloud service offerings.

Types of pricing strategies

A carefully thought out pricing strategy would help a provider differentiate themselves from their competitors. One must conduct periodic reviews of their pricing model to take into account the ever changing business environment and changing customer expectations. With that in mind I will list the different strategies that you could adopt in your financial processes.

  • Time based pricing – you charge your consumers based on how long they have been using your services
  • Volume based pricing – you charge your consumers based on the volume of the metric that has been consumed (for ex. amount of bytes sent/received over the network)
  • Quality of Service (QoS) based pricing – if you offer differentiated services to your end users, then you could have differentiated pricing based on the different QoS offered
  • Flat rate pricing – you offer your services at a fixed rate for a fixed duration of time regardless of the volume of consumption.
  • Paris-metro pricing – in this pricing strategy you offer two or more different services offering the exact same service configuration and exact same QoS guarantees but with different pricing levels. But you reserve dedicated resources for the two offerings. The idea behind the strategy is that the higher priced service will be used less and therefore whoever is using the higher priced service will have a better experience due to low load.
  • Priority pricing – in this you charge differently depending on the levels of priority assigned to end-users’ tasks. Normally a higher priority request will get charged at an elevated rate.
  • Smart market pricing – in this model you let the market demand and supply decide the prices. In other words – your services will be priced on auctioning. This model is similar to Amazon spot pricing.
  • Edge pricing – the service pricing depends on the distance of the user from the service.
  • Responsive pricing – in this model, the pricing is activated only when there is congestion in the system.
  • Proportional fairness pricing – in this model the service prices are set keeping in mind the users’ willingness to pay and costs involved in service optimization.
  • Cumulus pricing – in this model, the user agrees to pay a flat rate for service consumption upto a certain limit, over which an added charge is levied on the extra consumption. In some sense it is similar to a dynamic pricing using a credit point system.
  • Session oriented pricing – the price is determined based on the nature of the task being conducted in a particular session.
  • One-off pricing – in this model, you charge a small amount for each session, for example – this could include the cost to perform inter-domain network orchestration for each service instantiation/setup.
  • Time of day based pricing – in this model, you set a different price for your service depending on different hours the service is being consumed (for example – daytime vs. nighttime rates charged by various utility companies around the world).

Of course, there is no one correct model. You should feel free to devise your own pricing strategy using any one or even a combination of several models described above. Since pricing is an important piece in the overall puzzle, this decision is not to be made hastingly. Let me also list the various variations in the pricing strategies that I have already listed above. Many of these are self-explanatory so I will simply list those.

  • Free of charge model
  • Periodical fees model
  • Discounts
  • Pre-paid pricing model – in fact implementing a pre-paid pricing scheme for a cloud services can prove a bit challenging (more on that will be covered in a future blog post).
  • Post-paid pricing model
  • Online accounting – in this model, you do customer accounting in a real-time basis, this could be beneficial in the sense that as a provider, you have a real time view of your resources utilization pattern and you can react to demand variations quickly.
  • Offline accounting – You store your consumers usage metrics and process them periodically at a later time. This style of operation is simpler but you lose the ability to view your users’ real time consumption behavior.
  • Static pricing – in this model, you fix the pricing function (refer to my previous blog) for the computation of charge records.
  • Dynamic pricing – as the name suggest, the pricing function is not static but changes depending on the operating environment trigger conditions and is more suitable to react to congestion in your system as the prices of your service will adjust accordingly.

So where do we go from here? Now that you are aware of the basic accounting process and various pricing strategies / models, hopefully you are more equipped now to differentiate your cloud services from your competition. Of course – you must keep yourself aware of the market situations and your consumers’ expectations. And as a general rule – never stop innovating!

So moving ahead I will try to put together a general architecture that will throw some light on how to provision a system to bill your end users and have a cash-inflow to support your business. Until then – ciao!

Making money from your cloud services

Step 1 – Careful financial planning and understanding the financial process

Here at ICCLab, we do applied research covering the full spectrum of cloud services stack – Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and also Software as a Service (SaaS). Our researchers have been doing extensive research in automating the cloud stack installation and management, making your services highly available and dependable by identifying critical services in your offering. At the end of the day – everyone requires sufficient financial flow to keep their services up and running. All of us love doing ground-breaking, challenging applied research involving cutting-edge technologies, but it is also important to differentiate our service offerings from potential competition. Given the huge interest that cloud computing has generated among all stakeholders in any economic setting – it is not farfetched to assume that any novel cloud service you can come up with, very soon you will have to deal with potential competition in your service space. So the question naturally arise – how do I differentiate my service from my competitors? In this first post of a several part series we will try to take a baby step towards just that!

Understanding the business accounting process

Since most of us are pure technologists, we tend to overlook the importance of careful financial planning. Having a general understanding of the accounting process could help us create a sustainable business model for the cloud service offerings. So let us very briefly take a peek into a typical accounting process.

A typical financial process can be nicely explained using the flow diagram shown below.
Accounting process

The key elements of the accounting process are –

  • Metering – this refers to the process of collecting resource usage metrics of your customers. This step is critical and must be planned carefully as these metrics provides you the basis on which you bill your end users.
  • Mediation – it refers to the process of assimilating different metering records from various meters into a general meter-agnostic accounting records. This step helps transform disparate data into a form which is somewhat uniform and makes the rest of the elements of the accounting process metering strategy agnostic.
  • Accounting – within the overall accounting process, the accounting box task includes long term storage of the accounting records. It also houses the logic to combine several accounting records into a session record – which would entail identifying all accounting records belonging to the same customer session and then aggregating them into one or several session records.
  • Pricing – it refers to the various strategies that in the end generates the appropriate pricing function that would be applied to different session records. The pricing module needs a bit of thought to implement, and we will cover a bit more about it later in the series.
  • Charging – this is simply the process of applying the pricing functions to the session records in order to generate the charge records. This is the process that ultimately assigns the monetary values to end users’ consumption of your cloud services.
  • Cloud Bursting – in case you have agreements with other cloud service providers to migrate their peak load into our own environment, you will at some point in time bill them for the use of your resources. Depending on special agreements that could be in place between the two providers, the interdomain billing process will be different. The translation of session records into an interdomain format and handling of inter-domain bills is done in this module.
  • Billing – this refers to the process of combining the various charge units of the consumer since the last billing cycle into an easily comprehensible bill that will be sent to the users for payment. The final bill format could depend on the billing preferences such as consolidated view vs. itemized view and possibly other parameters.
  • Financial Clearing – it refers to the actual money collection from the customers, it could include processes such as handling of automatic clearing house (ACH), credit card transactions, direct banking channels, etc. Once the customer pays the bill, the billing cycle is considered closed.

Now that we have learned the high level view of a general accounting process, in the next post of the series we will focus on one of the more critical elements of the whole process – pricing!

Newer posts »