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.
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.
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
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.
This was first published in July 2000