Enablers – The link between Terminals, Networks and Applications

Photo of author

By Miro Stoichev

A common question that I get when talking to mobile Operators today is ‘What are the 3G Applications going to be?’. Not only is that a difficult question to answer, as many of them are not even developed (or started on) yet, but most people do not even know what the 3G handsets will look like. Today an even more urgent issue is what applications should be launched in order to secure GPRS success. As a matter of fact, the networks themselves only indirectly define what the applications will be – many applications will similar for GPRS and 3G, with some extra spice in 3G.

Now the thought of having the same basic set of applications across different networks is indeed appealing, but how should developers approach this new opportunity? Imagine starting a software project where you do not know what the target platform is! The handset manufacturers are careful about disclosing plans of future handsets because of the tough competition, but still depend on good applications for the success. Here I will show a method to understand what the applications of the future will be, by looking at what ties terminals, networks and applications together – Enablers.

What is the role of enablers

For each and every mobile Internet device, there is a set of Enablers that decide what you can do with it. The basic GSM/GPRS handset only supports voice, SMS and WAP and then that is exactly the kind of applications you can get. As handsets get more and more advanced we see more and more Enablers added into the devices and networks. One example of such an enabler is positioning support. If your terminal supports that, the handset will be able to report what the position is. This opens up for a new range of applications that leverage this feature, where you might for example have a taxi ordering application that knows in what city you are. Positioning as an Enabler also requires support in the network, but we’ll get back to that in a while.

Other examples of Enabler support in terminals are Multimedia Messaging Service (MMS), video playback and Bluetooth. All of those enablers open up for a new set of applications for the user. Just as the networks themselves are migrated into the future by adding first GPRS and then 3G, these Enablers add more and more applications capabilities step-by-step. In 2001 we started with WAP and SMS and then Enhanced Message Service (EMS) and SyncML. Going into 2002 we add positioning support, Java and MMS and video playback. From the application’s point of view this is what decides what the GPRS and 3G applications will be, not primarily the networks themselves. This means that you can actually know what categories of applications there will be in 3G networks by knowing what Enablers the 3G terminals will support.

You can view an enabler as a catalyst that, when available, opens up for a new bouquet of applications. For example, the positioning Enabler removes the need for the user to type in his current address and makes a new range of position-aware applications possible, like ‘The Weather Near me’, ‘Buddy-locator’. Although some of these applications will be completely new, the bulk is instead previously known applications that now work a lot better. This is a key success factor for the introduction of new technology – migrate step-by-step into more advanced features without the quantum leaps. It has been shown many times that the most difficult part is not to migrate the technology but to migrate the minds of the users – it is hard to change habits!

Table 1 shows four sample Enablers and what they add to the picture. Here we can also see an interesting detail, that some Enablers primarily need support in the terminal while others require some kind of server in the network (WAP, MMS etc). Generally, an Enabler is a client component plus a server component that adds a certain feature to the network.

MMS was one of the key factors that saw it spread in 2002

Some react when I call MMS an Enabler as it has often been regarded as a great application in itself. The point I want to make is that it is very dangerous to view MMS as an application that will drive itself without need for support. After all, what is it that we are going to send to each other using MMS? Who is going to create the MMS slide shows and clips? We need to view MMS as an Enabler in order to create focus on the content that is so dearly needed to help it succeed. Then there will be sites that not only host ring tones and logos showing Britney Spears but also advanced MMS shows with animations, pictures and sound clips that create early multimedia experiences on the nice color screen handsets. When we view MMS as an Enabler we also make sure there are communities where content developers can get help and support and exchange experiences as well as download content creation tools.

The figure above shows how the Enablers become the glue between networks/terminals and applications. The idea is that applications should not have to worry on which networks they run or how they really work in detail. The Enablers should have Application Programming Interfaces (API’s) that raises above the details but still lets the developer access the key features – like position, notification and charging.

As an example, a WAP application should be able to run on all WAP Terminals and all networks with a WAP Gateway. In the same way, a Java 2 Micro Edition (J2ME) application should be able to run on all terminals with the Enabler J2ME built in (which unfortunately only happens in the ideal world at this point).

Although many Enablers need support both in the network and the handset it is mostly the handset that is the bottleneck. With the small space in the device and many things that everyone wants included it is hard to fit it all in. Besides, the Enablers that open up for new applications also often put new requirements on processors and screens which adds to the complexity. Therefore it is good to look at the upcoming handsets when trying to understand what Enablers (and in turn the associated applications) that will prevail in the future.

An example GPRS phone due mid-2002 typically will have the following Enablers: 

* Bluetooth
* Color screen
* Positioning
* Enhanced Messaging Service (EMS)
* Multimedia Messaging Service (MMS)
* Java (J2ME)
* WAP 2.0 (with XHTML)
* Synchronization via SyncML Bluetooth here enablers a range of new applications including connection to PDAs via the divided concept (see Chapter 10 in the book). Note in the list above how you can know pretty well what applications that will be enabled even without knowing what speed the handsets will support!

By looking more at the Enablers of the handsets the handset manufacturers to have to disclose exactly what products they will release. It is enough to know roughly what enablers that are available at what time and how to develop for them. The handset and Enabler manufacturers then are producing API specifications and associated Software Developer Kits (SDK’s) that can be downloaded from that company’s developer site.

As the Enablers become more and more widespread we will indeed have a very colorful and interactive environment to develop for!

Leave a Comment