Search the Directory


Home
Archive
Features
Events Diary
Glossary
Links
About Us
Advertise
Press Releases









16,000 industry execs receive our Daily News.
Register here to join them
Sample Newsletter


 

Features

Free subscription
The industry's best reporters and commentators bring you their views and analysis of the world of future TV.


Cover Story - Chain Reaction
May/June 2005

Asia Watch - Going DTH in India

May/June 2005

Broadband - The Long and Winding Road
May/June 2005

US Cable Operators: It's all about the Bundle
May/June 2005

Review - Content to Travel
May/June 2005

IPTV - Telecom Video
May/June 2005

Wireless Watch
May/June 2005

 


Billing and OSS

Billing for people
April/May 2002
By Hans Eriksson, Product Marketing Director Vertical Markets, Protek


Re-thinking content and how people will pay for it

Yesterday, your newsagent charged you the usual amount for your newspaper. Today, the delivery truck was delayed en route from the printing plant, so the newsagent charged you 10 per cent extra.

You didn't bat an eyelid, and handed over the extra money. Tomorrow, if the delivery truck breaks down and the newspaper has to be distributed by bicycle, you won't mind paying double the normal price.

Will you?

Perhaps that's an extreme example, but it's intended to demonstrate the major flaw in billing for networks: people should not have to pay for content depending on the transport method used to deliver it.

To end-users, the transport method is utterly unimportant. It is the content itself that they are interested in, and that they are prepared to pay for. Charging structures and billing systems should reflect this.

"Instead of real-time measurement of network usage, you simply specify flat-rate prices for all content options."

It's understandable that mobile operators want to charge according to usage of the network. They have network-centric thinking - they measure the usage of the network and charge accordingly. But that model may not always be the most efficient.

True, end-users have grown accustomed to paying access charges. They understand that the more use they make of network resources, the more they will have to pay.

But the future of mobile networks depends on value-added services. Less and less money is coming in from the network itself, so new revenue streams are essential for long-term profitability and return on investment. These revenue streams depend on content, and the content depends on the opening-up of new technologies.

The first stage is happening right now, with the introduction of GPRS, but that still does not allow service providers to directly charge people for content - the technology is not yet there. People are still only charged for volume.

Consider what sort of content users will pay for, and the perceived value they will get from it. Things like breaking news, sports results, music downloads, and location-based services (on visiting a new town, you can find out where a good restaurant is, and so on).

In Japan, content is being made profitable thanks to the success of i-mode. Why does i-mode work? It is fast and cheap - sending a single email to someone via i-mode costs considerably less than it costs to do so via a mobile network in the USA.

How much is sending an email worth to most consumers? Probably fractions of a cent. But rather than simply dwelling on how much to charge, one of our other main challenges is deciding what to charge for, and how to charge for it.

Simply measuring network usage adds complexity to the network itself. With voice-only applications, you need only one probe to understand network use, but with data-rich content services you will need many hundreds of them.

It's perfectly possible to 'listen' to all the devices on a network, and so be absolutely certain of how the network is being used. But doing this is very expensive, and perhaps not very cost-effective nor necessary for every event.

In the past, every operator existed almost independently, and just billed for voice calls. But now there are lots of people involved in the value chain, and tremendous effort is required to ensure that all of them end up with the revenue they deserve from their contribution. New technologies in revenue settlement will need to be built to maximise efficiency of such a chain. Again, it is feasible to do this, but is it worth doing from a return-on-investment point of view?

End users also expect to know, instantly and in real-time, what they are being charged for any particular transaction. We cannot expect them to download a file, which may be one kilobyte or 10 megabytes, and only find out what the cost is when their bill arrives at the end of the month. People will want to know straight away what the cost impact is.

As for security - everyone knows that any information on the Internet can be intercepted and read by anybody else, given the right knowledge and motivation. To create a secure platform for mobile electronic trading, we shall need to ensure that all data traffic is encrypted. Under variable pricing structures, there will be a need for end-to-end network security to be put in place - security that stretches from the end user, via the mobile operator, the service provider, the content aggregator, and the content provider. Again, this is feasible, but the return-on-investment gets even worse.

In many cases, these feasible but expensive methods are the ones being considered as the only way forward.

We believe that there may be other ways of doing it.

Instead of real-time measurement of network usage, you simply specify flat-rate prices for all content options. Downloading any MP3 file will cost, say, two dollars. Getting live sports results delivered to your mobile handset will cost 10 dollars per month.

It should be up to the service and content providers to negotiate and come up with a list of clear fixed - and fair - prices that can be communicated direct to the users.

There's still a need for a settlement process, so that everyone gets paid the money they have earned from the value chain, but if prices have been fixed and communicated in advance, it no longer needs to be fulfilled in real time. With fixed prices clear up front, the user does not need to be informed of the cost of each content option as it is delivered - they already know what it has cost them.

The consumer pays a fixed price for the content in its entirety, and remains unaware of how it was delivered, or how many bytes of data were sent in either direction to fulfill the transaction.

Also, by using a fixed-rate pricing system, the security requirements are less intensive. With fixed rate pricing, rather than the end-to-end security requirement, there is a less intensive (and less expensive) need for security between the mobile operator and the end-user.

Our networks are going to be used, sooner or later, for delivery of all kinds of premium digital content to consumer devices.

We know that consumers will be interested in a variety of data services tailor-made for their mobile handsets. These will certainly include electronic newspapers. But people are accustomed to paying a fixed price for a newspaper. They will be unwilling to pay more for any digital version of it just because one day's edition comprises more bytes than another day's.

Nor will they be particularly impressed with paying more because their newspaper has followed a different path through the network than before. All they want to do is read the news, and know that they are getting it for a reasonable price.

The greatest challenge facing those of us involved in billing for content is adjusting our internal processes to better serve the end-users, bringing them a service they enjoy using and are happy to pay for. Ultimately, we are billing for people.

This article was written for Billing Systems 2002, running from 22nd-25th April 2002, Earls Court Conference & Exhibition Centre, London www.iir.co.uk/billing

Protek is an exhibitor at Billing Systems 2002, 22-25 April at Earls Court Conference & Exhibition Centre

For further details contact billing@telecoms.iir.co.uk or visit www.iir.co.uk/billing


Back to top  
  Back to Billing and OSS front page