Why developers need to take responsibility and create more network-aware applications

In all the brouhaha about traffic management and Net Neutrality, it is startling that one aspect is often completely overlooked - the need for mobile application developers to become much more network-aware, and write their software to take account of the realities of the user's situation.

This is not, primarily, about saving money for the network operators. It is about creating a better all-round experience for the applications' users, whether that is through improved or more consistent performance, less impact on device battery life, easier monitoring and feedback, or saving users time and money.

Ideally, applications should be aware of a broad plethora of network-related variables, and be able to act on them accordingly. An incomplete list includes:

- Real-world end-to-end speed, latency and jitter, for both uplink and down
- Bearer type - WiFi (and SSID and security method), 3G, 2G etc - or combinations of the above
- Which bearers are potentially available, but not being used
- Whether the cellular connection is routed via a macro- or femtocell
- Roaming status
- Variations in network quality, either predicted or real-time measured
- Price plan details - eg per-MB billing, time- or location-variable, proximity of thresholds & caps
- Probable future connection status - eg likelihood of going out of coverage, or switching to another network
- Awareness of current or likely future congestion on the network
- Mechanisms used for offload
- Policies applied by the network, and how these vary by time or bearer
- What types of signalling the application is likely to generate, directly or indirectly
- Handset capabilities & status (eg ability to use multiple radios, battery level, whether WiFi or 3G or roaming are switched on, potential for side-loading via Flash memory or Bluetooth and so on)
- Whether the phone is being used as a tether, or could use another device as a tether / peer

In reality, no application is going to be able to deal with all of these, or pick a comprehensive decision-tree route to decide on how to behave. Instead, there is likely to be a sub-set chosen - based on the nature of the application, the availability of the various input data, and the preferences of the user. A certain proportion of these "network-aware" elements will also be the responsibility of the OS, which might dictate either universal rules ("no updates while roaming") or might bundle some up into a general "network status API" or "bearer-awareness recommendations" accessible by all apps.

Some apps already make use of this type of data, at least in part and on some platforms. VoIP and streaming-video applications are typically the most bearer-sensitive, able to choose different codecs or frame rates based on observed network performance.

But we are still at very early days, especially with regard to the ability of apps to understand or predict mobile broadband congestion, offload dynamics, or cell-edge drop-off effects.

There are three main sources of this data:

- Direct measurement and input by the app itself. For example, Skype clients can measure latency and packet-loss directly.
- From the handset OS, which may expose some of this data centrally - eg WiFi vs. 3G connections, or perhaps in future the aggregate cellular data consumption vs. a user-defined monthly cap.
- From an operator API - perhaps roaming status, or ideally information on the user's data plan. Ultimately, operators will expose "congestion APIs" to applications and devices, although this is still a future-looking concept.

There may also be data that can be gathered from other sources, such as utility applications in the handset or in the cloud, or via direct provision from network elements in the data path.

There is likely to be a considerable amount of push-back from parts of the developer community towards this concept. This stuff is complex, perhaps boring, and will add time and risk to the development process. Some will undoubtedly say "It's not my problem" and attempt to abdicate their part of the decision-making. Nevertheless, mobile application (and mobile web) developers need to take responsibility for their creations' actions and performance.

There are far more variables - and variability - involved in wireless connectivity than is the case on fixed broadband, or a company LAN. On an ADSL line, you're not at risk of suddenly "going out of coverage". On a local gigabit ethernet connection in an office, you don't have to conisder the impact of roaming or the benefits/drawbacks of switching to an alternative connection. Using normal home WiFi you don't have to think about signalling loads.

Mobile *is* different and is much less predictable, and that should be reflected in application design where connectivity is required.

Disruptive Analysis believes that it is incumbent open both device and OS vendors to educate their developer base on the importance of "network-awareness", to a much greater degree than in the past. It may even need some sort of app certification as "network-friendly" to identify which software acts as a good mobile citizen.

Operators also have a role to play - firstly by exposing the right information via APIs or other mechanisms, and secondly by being honest and communicating the limitations of their infrastructure. Whether they are ever going to be able to charge extra for this information is unclear, but it is certainly in their own self-interest to enable network-friendly applications. That said, they also need to be wary of providing tools to those trying to "game the system".

Overall, the next few years will continue to see grudging moves to more network-aware applications, and more application-aware networks that aim to actively help applications rather than just use DPI or PCC to arbitrarily enforce blind network policies.

In fact, all of this is an absolute prerequisite for the success of future mobile cloud applications. Without this bearer/radio-aware knowledge and the development of network-based feedback loops, cloud services are doomed to niche status.