|
Newsletters
|
|
|
|
|
Enablers - The link between Terminals, Networks and Applications
By: Christoffer Andersson (01/07/02)
Printer Friendly Article
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.
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 is one of the key enablers which we will see spreading throughout 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!
About The Author:
Christoffer Andersson of Stockholm, Sweden, is heading the
Product Management unit that defines the Ericsson offering around Enablers and
Applications for GSM/GPRS/EDGE and WCDMA. This includes products like MMS and
WAP Gateway. Christoffer is also author of the Amazon.com best-selling book 'GPRS
and 3G Wireless Applications - The Professional Developer's Guide', published by
John Wiley & Sons. Christoffer can be reached at christoffer@wirelessdevnet.com.
The opinions expressed in this column are those of the author and not necessarily Ericsson.
See also Articles By Christoffer Andersson
|
|
|
