Its not just broadband data load that's clogging up mobile networks.

It's easy to concentrate on the headline figures of peak data rates and total data volumes when measuring the tremendous growth in mobile broadband network capacity. One of the other issues which is consuming resources relates to short bursts of traffic used to check status. Some applications are particularly "chatty", pinging a central server frequently to check for updates. On today's wired IP networks, this may not have much effect - each individual packet is treated much like the next. However, on a wireless network this can involve bringing up the radio transport session from dormant to active state, arranging for a suitable timeslot to send/receive the traffic with all the associated processing and management.

• The huge growth of smart devices such as Windows Mobile and the iPhone (which has now taken greater market share than RIM's Blackberry)
• Unlimited data usage tariffs
• A wide variety of downloadable applications

There is often little incentive for mobile applications to be very efficient other than extending battery life.

Its happened before on wireline data networks
In the early days of wireline networks, steps were taken to optimise and reduce this type of inefficient traffic. ISDN lines, which made data calls between two phone numbers and sent 64kbit/s data streams, often caused bill shock, because frequent short duration data calls were made between office sites to check status. Smart routers were developed which fooled the applications into thinking that they were still connected and online, restricting the number of actual datacall sessions setup.

Offloading mobile broadband data also offloads the clutter
Wireless operators need to offload as much of the data traffic as they can from their congested outdoor macrocellular networks. This can include offloading to WiFi access points where possible (many operators such as Verizon and ATT include free access via WiFi).

Femtocells can also absorb not just the high volume of data traffic from individual users, but also this "chatty" clutter originating from applications.

Learning from other internet pricing schemes
Some internet services actually set their charges based on API calls as well as their core service delivered. For example, Amazon S3 Storage (the IT department of Amazon etailer, which resells its storage and processing capacity on demand to anyone). Their pricing includes a fee per GB per month for storage, but they also charge for "gets" and "puts", so that those who frequently update or access their data pay much more than those who just leave it untouched. It also more closely reflects their own cost structure.

Another common internet service is DNS. Usually provided by a website hosting service, domain naming is provided by a server which returns the associated IP addresses of a domain name on request. Typically, this is included in the fee for hosting your website or your domain name. Some independent DNS hosts set a threshold of 200MB of DNS traffic (which is a lot), above which excess charges apply.

Can operators change application developer behaviour?
Operators need to consider if there are ways to change the behaviour of application developers to optimise their applications, particularly when used on laptops or other high power devices which are less affected by battery load.

At the risk of adding complexity to the consumer proposition, this may involve a pricing scheme which measures how many "pings" or individual packet session requests are made. Often with these type of traffic, it is a small number of users who contribute to a high proportion of the load (the Pareto principle may apply here, where 80% of the load originates from 20% of users). Once measured and the cost implications of the load are assessed, a tariff scheme could be implemented which charges a premium for high users - these can then migrate to more efficient applications and/or pay a higher rate.

The easy solution is offloading to local access points
Clearly, offloading the data traffic of this type to femtocells or WiFi access points will help free up capacity in the operators external radio network. This benefits everyone and is a byproduct not to be underestimated as the number of mobile broadband enabled gadgets increases.

TrackBack URI for this entry

Comments (2)

Subscribe to this comment's feed

Dean Bubley said:

... Good post. I think an absolutely key feature of future PC and handset operating systems will be much smarter "connection manager" layers. These should provide APIs to application developers that indicate which bearer(s) are being used - WiFi, 3G macro, ethernet, femtocell etc. There's no reason to design apps to be "ping efficient" if they're sitting on a gigabit ethernet LAN. But making them bearer-aware to optimise their performance will make a big impact on congested networks, or those which could impact battery consumption.

report abuse vote down vote up

November 27, 2008 | url
Votes: +0

David Chambers said:

... Dean, Thanks for the feedback. Yes, good connection manager layers will be essential, although there's nothing better than native application intelligence - it's just that this does cost more and take longer - and where is the commercial motivation for application designers to include this? Maybe applications can be rated for "network efficiency", a bit like white electrical goods are rated for energy efficiency??

report abuse vote down vote up

November 27, 2008 | url
Votes: +0