Upstream billing in two-sided telco models will face same challenges as normal user billing

I just read this post on the Telco 2.0 blog. While it's an interesting idea (to try to create a business model for free broadband, using apps as a means to create cable-TV style service bundles and sell lots of advertising), at first glance I can see multiple flaws in the theory and approach.

I'm not going to do a forensic dissection of it for now, because it highlighted a specific set of problems likely to be generic across all "upstream"-paid telco models: how to do fair and secure billing to the advertisers / content / app provider, especially where there's some form of volume-based charging involved.

Let's assume for a moment that non-neutrality of access is permitted, at least to specific upstream walled gardens, rather the full Internet. So to use that blog post's idea, maybe the user has a set of apps from "useful" services such as Facebook, YouTube, Salesforce or whatever, rather than the full open Internet through a browsers. Each app's access profile is able to be analysed and accurately modeled, based on the various new app-analytics frameworks evolving.

So, in theory, each app's owner could be charged for the data consumed within its application - eg YouTube gets billed $x per GB and so on. It's a bit like freephone or freepost services, paid for by the company, not the user.

Sounds like the Holy Grail for monetising broadband, no?

No. I'm unconvinced, on several levels.

Firstly, what are the protections for upstream provider? Are they exposed to a potentially unlimited bill, for example if a virus or unscrupulous competitor racks up huge downloads? I'm not sure how this works with Freephone, but presumably it's a lot easier to track usage and spot fraud and abuse - if a robot keeps calling your number, your call centre agents will spot it pretty fast. For freepost, I'm pretty sure if you stuck the prepaid envelope to a brick or something else heavy, the recipient wouldn't get stung for a huge postage bill.

Next, how are errors and re-sends accounted for? Netflix is probably not going to be happy if a network outage or other glitch means resending large volumes of data and thus having to pay twice.

What are the appropriate metrics for billing, anyway? A simple cost per MB or GB of data downloaded is a spectacularly poor way of pricing data, especially on mobile, as it doesn't reflect the way that network costs build up. How are uploads priced compared to downloads? For mobile, how do you deal with small-volume / high-signalling apps? Do you charge apps that download during quiet hours the same amount as those that are oriented towards peak-hour commuters?

Then there are future "gotchas". How aer mashups dealt with? What happens when one app on a device discovers the other apps running concurrently on a PC or phone or set-top box, and routes some traffic through their own exposed APIs? On the server side, is Facebook expected to pay for YouTube traffic displayed within its own app, without a way to "cascade" payments onward?

There are plenty more issues I could list.

The bottom line is that upstream charging is going to need just as much sophistication in terms of rating, realtime capabilities, anti-fraud, revenue assurance, policy and so forth, as we currently see in normal downstream billing. For some of these, even more sophistication will be needed as things like anti-fraud will need to be bi-directional.

Overall, this isn't going to be easy - and it's not obvious that the operators or billing vendors have yet to go far enough down this path in terms of ready solutions.