Why We Need Network-Aware Apps
Mobile apps routinely make use of the GPS chips, accelerometers, cameras, compasses and other high-tech widgets embedded in a smartphone, but they mostly fail to exploit the bells and whistles in the mobile networks. The network could tell the app where the handset is, the speed of the connection and sometimes the age and gender of the user. Moreover, the network operator can authenticate the user's identity, send them a text or picture message and enable them to easily pay for a service.
But most apps don't make use of any of these network capabilities. Why not and does it matter?
In this post, the first in a series focused on the future of the mobile app, I'll attempt to answer these questions. Let's start with the question of how much help apps need from the networks.
It is true that apps can find out a lot about the user without the aid of the network. Facebook, for example, may know more about a particular individual than a mobile operator ever will, while Google's Cell-ID database can figure out approximately where a handset is, even if it doesn't have built-in GPS. Moreover, email can serve as a substitute for SMS and MMS, while specialist web services can test the speed of the handset's connection. Operator's sophisticated micropayment systems are harder to replicate, but iTunes makes payment simple within the Apple ecosystem.
Still, depending on the handset and app involved, many of these workarounds can involve pain for developers and consumers alike, requiring the user to login to particular web services or, in the worst case scenario, key in a sixteen digit credit card number to make a micropayment.
Tackling network congestion
But there is much more at stake than convenience and ease-of-use. If mobile apps and mobile networks were to work closely together, they could make better use of the limited network resources available, sharing bandwidth and signaling systems more equitably between the fast growing band of smartphone users. If an app is aware of the bandwidth available, for example, it could automatically adjust the quality of a streaming video or music track.
Moreover, the mobile apps ecosystem needs to find a way to further incentivize mobile operators to make the investments in network capacity that will be needed to fully accommodate the rising demand from apps for bandwidth. In practice, that may mean paying the operator, rather than a credit card company, a small fee to use its billing system to charge for apps.
A common, lightweight API
Right now the apps and networks work largely independent of each other. That's because making use of a mobile network's capabilities can be even harder than many of the workarounds. Network operators typically use different application programming interfaces (APIs) meaning that a developer may have to adapt their app for each network. The GSMA is trying to change that through its OneAPI programme, which aims to provide developers with a common lightweight, web-friendly API that is supported by many different mobile operators.
The first version of the OneAPI is nearing completion. We'll probably hear more about it at the Mobile World Congress in Barcelona this month. Let's hope it is widely adopted by mobile operators and developers respond by creating many more network-friendly apps. Only by working together, will mobile operators and developers be able to ensure that the mobile apps market realizes its full potential.
I believe for mobile operators to open its network capability is necessary and will be a must for them in the near future. otherwise, they will turn to be a dumb pipe provider.
The MNO should transform to be a platform provider from servcie provider. Now with the SDP, they can provide API for 3rd party use its network capabilities and providing some marshup servcies, another issues are open its subscriber data to 3rd party for new servcies innovation.
Dave,
MNOs have tried the platform route before as well. The whole fleet of Application Servers, Feature Servers, Telecom Servers, SDPs that were introduced to solve the problem of a platform for third party application development were part of this effort. There have been API standardizations as well - JAIN, OSA, PARLAY, PARLAY-X, SMPP, IMS and various SIP abstraction APIs serve as examples.
The vendors of these platforms soon realized that there are still not enough applications getting written on these platforms, and they themselves started pushing applications on their platforms. Most of these applications have been porting and transplantation of existing popular telco offerings [prepaid, voice mail, unified messaging, etc]. Once they got into the app development proper, the deployment and lifecycle aspects of those applications naturally took the business focus of these vendors, as it should be expected. So, many open platforms increasingly got heavy with not so open enhancements and proprietary extensions. The fact that any API would suffer from the underspecification of some real life functions added to these differentiators.
There is definitely a need of integration, as you argue in the article. The clumsiness of integration is still a problem, but from the SCP days onwards, we have seen improvements on the integration platform options. But, the biggest gap is in visualizing new , interesting applications.
-Jobin Thomas
http://in.linkedin.com/in/telecomjobinthomas