4G and Implications for Mobile Application Development

(The article is extracted from Wireless Design & Development's March/April 2010 issue)

Over the past few years wireless data applications have received a lot of buzz and attention due to steady and significant adoption and growth. This is due in part to the success of emerging devices such as the iPhone in addition to the maturity of wireless data services which are now more affordable than ever. In this article, we will examine wireless capabilities in order to build the best data applications.

Location, screen size and mobility are intrinsic to the wireless aspect of data applications. Those very properties of an application are independent of the underlying technologies which are sometimes challenged with core network technology selections (for example, 3GPP vs. EGPP2 based core networks) and mobile bandwidth limitations. In an ideal world, application developers should focus on exploring the intrinsic properties of mobile data when designing specific applications so that they are not limited by constraints which can potentially lower performance levels. A number of initiatives, outlined below, will bring us closer to ideal best practices where wireless technology is isolated from application design.

Core Networks

The applications should be independent of the core network selection. To achieve this, IP Multi-service Subsystem (IMS) and Service Delivery Platform (SDP) are introduced. IMS is introduced to unify the session control layer for different underlying networks as it is the only standard able to perform session control on both mobile and fixed networks.

One of the main objectives of SDP is to hide the complexity of the core network while exploring its service capabilities. The SDP is also able to link all of the relevant components inside the network to enable an integrated application. For example, the SDP needs to link the email system and voice mail system for applications to send an email to a subscriber if the user receives a voice mail. There are several points that highlight the fact that SDP is still in its infancy, notably:

■    The relative immaturity of SDP standards and the fact that the process of partitioning the architecture components and their interface specifications is still a work in progress.

(1) Parlay X may represent a relatively mature and open mechanism to abstract network capabilities for data applications. Given the limited and cumbersome capabilities of Parlay X, its popularity and future is uncertain.

(2) Apple has a very successful development environment for iPhone, but it is proprietary (Note: for practical purposes, iPhone SDK is similar to SDP in many aspects.)

(3) Google has an application development platform which is also proprietary in nature despite having no accessibility restrictions.

(4) Many mobile carriers are seeking an open platform for application development which is typically driven by branding interest rather than specific capabilities.

■    Open third party development environments: One of the promises of the SDP is to ‘open’ the development environment. Any small company can develop applications for carriers to use, however it should not be forgotten that developing applications on SDP has its challenges and requires intimate knowledge of the underlying network.

■    Legacy systems further hinder the development and deployment of SDP. For example, an operator may have existing voice mail and email systems with limited capabilities. The SDP they want to deploy needs to address those differences and expose the limitations to the applications so that the right solution may be found.

■    In spite of the various difficulties and challenges, an open, standard SDP is in fact possible. Mobile carriers came to the conclusion that one of the key reasons GSM experienced success was because of the universal feature sets on GSM networks. Today, the application is data centric instead of voice centric, but the principles remain the same: users are expecting similar experiences regardless of what technologies a carrier deploys.

Bandwidth Limitations

In terms of mobile applications, the bandwidth of the air interface is one of the key limitations. In addition, the speed of edge network (474kbps) and W-CDMA network (2Mbps) will impose server limitations on the application for a reasonable user experience.

That said, bandwidth issues can often be alleviated once major wireless carriers introduce solutions such as LTE technology, WiMAX technology and Wi-Fi access points. In terms of bandwidth, LTE, WiMAX and WiFi are similar, but looking ahead into the future limitations may exist inside the network (for example on the server side or on the core network) instead of on the access side.

As an application developer and consumer, it’s fair to say that the air interface speed of various wireless technologies does meet the requirements for many applications. However, in this case the particular technology selection is of less importance as businesses move toward an open-standard, more flexible overall IT structure.

Challenges

For application developers moving forward, the challenge is how to design applications that fully utilize the intrinsic properties of the mobile application in question. Given various limitations, a scaled down version of the application needs to live within the limitations of the core networks and the access networks (for bandwidth limitations). Once those limitations are removed, the full potential of the application can be materialized.