The significance of Wap lies not so much in the technology, but the
acronym's pronouncability. Everyone seems to have heard of it, and
the term has provided a rallying call for the new world of mobile
commerce.
It has also served to remind people of their mobile phone's
existing data capability via SMS (short message service), which
already provides a limited 'always on' capability, as many
adolescent schoolgirls are well aware. 'We have seen huge growth in
SMS, which consumers could have used before, but whose potential
they were woken up to by Wap,' says IBM's EMEA communications
sector vice president Val Rahmani.
As for the Wap protocol itself, opinions differ as to its
significance. Some, such as Rahmani herself, see it as just a
passing star in the mobile standards firmament, albeit a bright
one. 'We see Wap as an interim standard,' she says.
The more significant development, according to Rahmani, will be
the arrival of GPRS (General Packet Radio) Service during the
second half of this year. GPRS will provide a permanently connected
IP packet service enabling mobile handsets to both send and be sent
data on demand, without the need to establish a dial up connection.
It will also increase the bandwidth available from the current 9.6
Kbps to 56 Kbps, bringing it up to the speed of modems used for
fixed line connections to the internet. 'We see the biggest
advantage of GPRS being not the higher bandwidth, but the fact that
it is always on,' says Rahmani. This always on capability will
enable mobile handsets to deliver a range of new applications based
on push (see box for details of apps).
But GPRS alone will not allow push based applications to be
delivered, and here Wap in its next version 1.2 will have a
prominent role in providing the required standards for filtering
and formatting messages and content (see box for details of Wap
1.2). Indeed the key role of Wap in general is in shaping internet
content into a form suitable for delivery to, and display on,
devices with small screens.
While Wap may provide the mechanism for connecting mobile
devices to the internet, it does nothing to ensure that content
appropriate to the application is delivered. According to Jon
Newlyn, business development manager at Attachmate, which is best
known as a supplier of host connectivity software, most of the data
and content needed for Wap applications resides in legacy systems,
very often IBM mainframes, or AS/400s. Newlyn argued that the wrong
emphasis is often taken when designing Wap applications that rely
on host data.
'These applications are not web to host, but host to web, which
is fundamentally different,' says Newlyn. 'You should start by
looking at the business logic in the host, and then consider what
devices can best be used to access this depending on what you're
doing.'
The key point to observe is that while many legacy applications
employ large numbers of green screens, Wap devices are incapable of
displaying these, or facilitating the navigation needed to move
among them. Therefore the application needs to be pared down into
the essential input and display components needed for the mobile
version. Newlyn cited the example of a loan application developed
by Attachmate, where the original software comprised hundreds of
mainframe screens. However, the only function needed for the mobile
version was the ability for sales staff on the road to query the
status of a loan application. 'We've developed a simple screen that
highlights the status of the loan you've applied for in just five
lines,' says Newlyn. This re-engineering of an application to
display only the components needed by the people accessing from
mobile devices is something not provided by the Wap protocol
itself. Vendors, such as Attachmate, are helping though by
providing the requisite skills, and also software components that
facilitate the basic connectivity between the network of Wap
devices, and the backend host systems. 'We're just about to
announce Wap Frame, which will provide all the elements needed for
a Wap phone to access a mainframe,' says Newlyn.
Delivering the content
Functionally, products such as WAP Frame sit between the host,
and the Wap Gateway, which liaises directly with the mobile devices
to deliver the content in the right form. Wap Frame provides the
conversion between the display formats used by the host, and the
slimmed down version of the application for presentation to the Wap
devices. The Wap Gateway then takes care of the technical processes
needed to display the application and communicate with the
handsets.
The need for products such as Wap Frame highlights the fact that
Wap really only tackles the front-end part of the puzzle. This is
worth bearing in mind with respect to an important part of this
puzzle, security, where the forthcoming version 1.2 of Wap will
make a substantial contribution. It may be a truism, but
nonetheless true that security is only as strong as the weakest
link, so it needs to be implemented on an end-to-end basis.
According to Rahmani, the emphasis on the front end with Wap brings
the danger that the backend is neglected. 'Security should focus on
the whole environment,' Rahmani insisted.
Key component
It is indeed vital that the WAP Forum responsible for shaping
the standard does facilitate the deployment of a proper end-to-end
security structure, according to Esko Hannula, head of product
development for internet communications at Nokia. A key component
here (see box on Wap 1.2) will be a specification called Wim (Wap
Identity Module) enabling Wap devices to hook up with smart cards
to facilitate secure authentication. 'We believe that's a very
important development, not just for Wap, but for the future of
e-commerce as a whole,' says Hannula.
Incidentally, Hannula believes that Wap will continue to be the
focal point for mobile communications, rather than just a temporary
standard. To some extent though this debate is academic, in that
certain new functions and standards will need to be developed as
mobile communications evolve. Whether they are called Wap, or
something else, need not bother users too much.
Wap 1.2, whose ratification will shortly be completed, so that
implementation can begin towards the end of 2000, has two main
additional components, the Wap Push Architecture, and the Wap
Identity Module (WIM).
The push support is necessary and timely given that network
operators will be converting their services to GPRS (General Packet
Radio Service) during the second half of this year and early next.
This provides the 'always on' capability necessary for effective
delivery of push services to handsets without the need for the user
to instigate a dial up connection.
The key element of the Wap Push Architecture is the Push Proxy
Gateway, which is software controlling the construction and
delivery of the push message. As such it is an extension of the
existing Wap Gateway, and may well be implemented in the same
hardware. It deals with the specific higher-level issues of push
delivery. It has to cater for different degrees of urgency, with
options for acknowledgement and recorded delivery for more critical
applications. It also has to support different levels of filtering
to cater for varying capacities in the target handheld devices,
although here it can exploit the existing functions of the Wap
Gateway.
Wim defines how a handset interacts with a smart card, or indeed
any external secure devices comprising a memory and processing
facilities, to perform cryptographic computation. The idea is that
future handsets could have a slot for a second Sim card, which may
be a smart card holding the user's security credentials, such as
encryption keys. Having these in a separate portable device can
increase security, because it means that the handset itself cannot
be used fraudulently without it.
Wap on its own though cannot deliver complete end to end
security, which will require a Public Key Infrastructure (PKI)
providing the mechanism for validating the identity of individuals
via trusted third parties, and functions such as non-repudiation,
which supplies proof that a transaction has taken place.
According to Nokia's head of product development for Internet
services Esko Hannula, a PKI for the mobile internet is likely to
be implemented during 2001.
Wap phones are ideal for data collection type applications
feeding into a central database, especially when allied with the
always-on capability that GPRS will bring later this year (see main
article). One service provider promoting Wap for such applications
is Colt Telecom, one of whose clients (nameless) is using mobile
handsets for updating a stock control system. This uses software
from Informix that enables a single database system to serve
different channels, of which mobile links are just one. The
software detects what channel the user is coming in from, and
personalises the messages to the capabilities of the device,
highlighting the importance of shaving content down for Wap
delivery.
Access and update
These principles are also evident in a project management
service being marketed for Wap delivery by the carrier Norweb
telecoms. This uses existing project management software from the
Danish company Time Systems, allowing mobile users to access and
update scheduling systems from their Wap handsets. 'We took a
subset of the full PC based version of the software comprising just
the critical parts of the model,' says Norweb's head of mobile and
e-commerce Michael Dimelow. It incorporates some push capability
such as the ability to notify staff if a project milestone changes
or has just passed, or to ask whether particular individuals can
attend a meeting.
The use of push is certain to expand rapidly, allowing users,
for example, to be notified when pre-specified conditions have been
met, such as a particular stock falling below a given value. The
potential will expand further with the availability of third
generation mobile networks in 2002. Then users could be flashed a
message to view a particular video clip selected according to
pre-specified criteria. It could be David Beckham's latest goal, or
the US president's latest utterance about Northern Ireland.
Less bandwidth
Radio will feature in Wap services rather sooner, as this
requires less bandwidth, and here we already have the basic
capability with WTA, allowing a Wap session to control a radio
channel.
The other big development, which will probably involve some new
features in the version of Wap after 1.2 next year, will be in
location based services. Currently it is possible to determine the
location of phones to within 250 metres within the mobile
operators' networks, using triangulation techniques between the
transmitters of neighbouring cells. But this is limited in accuracy
to about 250 metres, and restricted in coverage to a given
operator's network.
Future phones will be equipped to calculate their location using
the GPS to much greater accuracies, eventually within a few metres,
also with worldwide coverage. The mobile phone could then become a
global A-Z with the advantage of being able to issue instructions
to get from where you happen to be at the time to the desired
destination. It will also be possible for companies to track the
location of staff accurately, or for emergency services to know
exactly where to direct vehicles to the scene of an accident. The
possibilities will be endless.l
BOXHEAD: Wap 1.1 - the standard
BOXTEXT:
Wap 1.1 embodies all the functions originally thought necessary
for mobile data communications involving dimensionally challenged
devices, and unreliable low bandwidth connections. It takes
existing standards, such as IP, HTTP, and XML, only adding new ones
to cope with the limitations of mobile devices, in particular: Less
CPU, less memory (both Ram and Rom), and a need to conserve
power.
Wap also copes with the low bit rate and intermittent nature of
mobile communications, although those limitations will diminish
when third generation mobile networks come on stream in 2002. But
even then there will be a need to optimise use of bandwidth,
because there will still be less of it than in fixed networks,
while some of the applications will be the same.
Five principle components can be identified: WML (wireless
mark-up language), the WTA (wireless telephony applications)
interface, the micro-browser specification, the Wap protocol stack,
and the Wap Gateway. These components in fact interact and overlap
within the overall Wap service.
Taking these in turn, WML is a mark-up language analogous to
HTML. Unlike HTML, WML does not assume that input comes from a
QWERTY keyboard, and divides documents up into units called cards
to cater for smaller displays. In addition it uses mark-up tags
designed to suit telephony aware applications and intermittent
communications. Being modelled on HTML, WML, and hence Wap is
particularly suitable for applications that also have a
conventional HTML based desktop component.
WTA allows applications to utilise telephony functions, such as
call control, and phone book access. Access to these functions is
provided by WMLScript applets,
which are small portable software components. WTA is needed to
allow multiple services and features to be integrated. For example
it will soon be possible to embed radio broadcasts within Wap
sessions. In this case WTA will provide the mechanism allowing the
user to access and control the radio from within the Wap
session.
The micro-browser specification, similar in function to a
conventional browser, defines how the commands issued, as
WMLScripts should be interpreted in the handset and presented to
the user. For example there could be a choice between displaying a
message as text or converting it into voice.
The Wap protocol stack is designed to be as lightweight as
possible to cater for the limited memory and processing facilities.
It incorporates features needed for security and transaction
control as well as the basic data transmission.
Finally the Wap Gateway connects the wireless domain with the
underlying World Wide Web, which will usually be the source of the
data and root application. By absorbing this functionality, which
can be quite computationally intensive, the Wap Gateway allows the
end user device to be small and relatively inexpensive.
There are two main sub-components:
Protocol gateway, to translate Wap requests to the WWW protocol
stack comprising HTTP and TCP/IP.
Content Encoders and Decoders, to compress web content to save
bandwidth for the final over-the-air leg of the overall
transmission path.
IBM' contribution WAPsody
IBM does not have any particularly unique stance on the Wap
protocol, but has made an important contribution with its WAPsody
environment. This allows Wap applications to be developed and
tested in software before deployment in a live environment.
This is important given the practical impossibility of
developing and testing Wap applications for all conceivable
combinations of network and handset device on which they may
subsequently be deployed. It also enables the concept of new
generation applications to be evaluated before the network and
devices exist, as is currently the case for forthcoming third
generation services.
Built in IBM's Zurich laboratory, WAPsody simulates the
components of the Wap 1.1 standard described elsewhere, enabling
the behaviour of an application both in terms of usability and
communications efficiency to be tested.
IBM is also assisting a number of mobile operators and service
providers with development of Wap applications.