The Need For The Wireless Application Protocol (Wap) in Cars
The Need For The Wireless Application Protocol (Wap) in Cars
The Need For The Wireless Application Protocol (Wap) in Cars
SUMMARY
Future cars will be integrated in large information systems, where various kinds of information might be sent to and from a car. Beyond information about the current traffic condition or
weather forecast, cars should also offer access to the Internet, enabling electronic commerce
or mobile commerce such as online banking and online brokerage, and various other applications. In order to handle this flood of information, a common platform is needed that allows
for the integration of those different information streams. We explain, why the use of the
common Internet protocols does not make sense and describe the Wireless Application Protocol (WAP), which was developed especially for the use in mobile and wireless networks, and
why it is advantageous for the use in the area of traffic telematics.
MOTIVATION
Regarding the current traffic flow in cities and on motorways, we can state that the car density
became more and more dramatic within the last few years. In 1996, a German driver was statistically involved in a traffic jam about 65 hours per year. The resulting economic damage
was estimated at about 100 Billion , while the consumption of gas additionally increased
about 2.5 Billion litres, as cars have to wait in traffic jams or cruising through cities to find a
place to park. This situation becomes even worse as the admission of new cars in Germany
increases every year, 5.9% in 1998. Counteracting this situation by building new streets and,
thus, enlarging the road infrastructure is in most cases not feasible, not accepted by the population, or often too expensive. Thus, the alternative is to improve the utilization of the roads
by providing vehicles with dynamic information, e.g., about the current traffic situation.
Therefore, the navigation unit within the car will be able to calculate both, the best route to the
destination as well as the travelling time under the current circumstances.
In the future, we will see an evolution from vehicles to mobile information centres. Drivers
enter their car in the morning, when the car already has cached the current road and weather
conditions sent via DAB (Digital Audio Broadcasting [1]), while the drivers PDA (Personal
Digital Assistant) uploads the new destination to the cars onboard navigation system. A Personal Travel Assistant (PTA) supports the driver planning his or her trip. While driving, traffic conditions on the highways will be sent to the car, the car forwards the selected information to the PTA, which can calculate a new route. The information is also sent to the PDA inside the car, which automatically rearranges the schedule for meetings. Similar scenarios are
also conceivable for air traffic or railroad traffic. Beyond road information, future cars will
offer more services to passengers, such as online banking, online brokerage, e-mail, maybe
video conferencing, telephony, or browsing in the Internet. However, this plethora of new ca1
pabilities with specific requirements to the communication system arises the question how this
information can be sent to the car by using a common platform.
UMTS, WLAN,
DAB, GSM,
TETRA, ...
ad
ho
applications should not rely on one single communication system; the development of new
applications becomes easier as developers do not have to take care of the technical aspects
specific to one communication system, and the robustness of the application will be improved
as it can use other communication systems for exchanging information. Thus, one single platform is needed that offers a reliable and possibly secure connection and fits to these different
requirements.
Those disadvantages show the need for an alternative architecture with standardised protocols
that are optimised for the use in mobile and wireless environments. Thus, in 1997, the WAPForum [7] was founded by a few companies in order to create an open, global specification
that empowers mobile users with wireless devices to easily access and interact with information and services instantly. This aspect makes it interesting for the use in vehicles. Meanwhile,
over 200 companies joined the forum, representing over 90 % of the global handset market,
carriers with more than 100 million subscribers, leading infrastructure providers, software developers and other organizations providing solutions to the wireless industry.
Figure 2 gives an overview of a typical WAP infrastructure. A mobile device communicates
with, e.g., a Web server via a WAP proxy. Thus, a set of new techniques can be used for the
wireless network, such as protocols optimised for wireless links, or, as shown in figure 2, the
use of the Wireless Markup Language (WML) instead of the unsuitable HTML for describing
3
the information. The WAP proxy is also integrated in the Internet environment, i.e., it can access Web Servers by simply using the Internet protocols, i.e., TCP/IP and HTTP. The basic
communication interaction between mobile device and Web Server works in the following
way. The mobile device sends an encoded request to the WAP Proxy, which decodes the request and translates it from the WAP protocol stack to the Internet protocol stack. The WAP
Proxy passes the new request to the specified Web Server, which sends the requested information in a response back to the WAP Proxy. The information will be translated to the WAP protocols, encoded, and finally sent to the mobile device. There are two ways to create WML
content. The first is to write raw WML code, which is stored directly on a Web Server. The
WAP Proxy downloads this code via HTTP and sends it directly to the mobile device, using
the protocols defined in the WAP architecture. Alternatively, the WAP Proxy requests common HTML code, and converts it to WML code using specific filters. From the outset, WAP
integrates speech services for telephony using WTA Servers (Wireless Telephony Application). This empowers the WAP architecture as one common platform for supporting voice and
data communication and, thus, takes the preceding integration of voice and data services into
account.
HTM
Internet
Web
Server
WML
L
TM
H
L
M
Filter
WAP
Proxy
WAP
Proxy
WM
L
WML
L
WM
Filter
WTA
Server
Wireless
Network
Telephone
Network
that services and applications can be implemented using parts of the architecture, or have direct access to the bearer services, which is shown on the right side in figure 3.
Internet
HTML,
HTML, Java
Java
HTTP
HTTP
Session
SessionLayer:
Layer:WSP
WSP
Transaction
TransactionLayer:
Layer:WTP
WTP
SSL/TLS
SSL/TLS
TCP/IP,
TCP/IP, UDP/IP
UDP/IP
Security
SecurityLayer:
Layer:WTLS
WTLS
Transport
TransportLayer:
Layer:WDP/UDP
WDP/UDP
WCMP
Bearer
Bearer (GSM,
(GSM,GPRS,
GPRS, UMTS,
UMTS, ...)
...)
Privacy: WTLS assures that the information transmitted between the terminal and an
application server is confidential. Other participants who might record this information
will not be able to read it.
Data integrity: WTLS guarantees that the information transmitted between terminal
and server could not be modified or damaged in a way that the receiver does not recognise the modifications.
Authentication: WTLS features a mechanism that both application server and mobile
terminal can authenticate each other. Thus, it is ensured that the mobile device communicates with the application server it has contacted, and vice versa.
Denial-of-service protection: WTLS supports mechanisms to identify and reject data
which might be replayed by a third party, and makes many typical denial-of-service attacks more difficult in order to protect the higher layers.
For the initialisation of a secure connection, a handshake (HS) protocol (either a full HS or an
optimised HS) is used, where client and server agree on a protocol version, select the cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate a shared secret key. In order to support the features listed above, WTLS has
to perform four classes of cryptographic operations:
Digital Signing, by using one-way hash functions as input for a signing algorithm for
authentication during the initial handshake operation.
Stream cipher encryption, where plaintext is XORed with an identical amount of output generated from a cryptographic secure-keyed pseudo-random number generator.
Block cipher encryption, where every block of plaintext is encrypted to a block of ciphertext using cipher block chaining (CBC), e.g., RC5, DES, 3DES, or IDEA.
Public-key encryption, using a public-key algorithm to encrypt data in such a way that
it can be decrypted only with the matching private key. In WTLS, algorithms such as
Diffie Hellman (DH) or RSA can be used for those purposes, especially for exchanging a shared secret key during the initial handshake.
After creating a secure connection, the messages for transmission are optionally compressed,
authenticated using a MAC (Message Authentication Code, negotiated during the initial handshake), and afterwards encrypted. Hence, the receiver has to perform the inverse transformation of those steps to receive the original message.
The Wireless Transaction Protocol (WTP) on top of the WTLS layer has no explicit complement in the Internet (however, the seldom used T/TCP [6] has similar characteristics). WTP
was defined to provide the services that are necessary for interactive browsing, i.e., typical
request/response applications. Such a request/response pair is called a transaction. The objective of WTP is to deliver a transaction in a reliable way while balancing the amount of reliability required for the application with the cost of delivering the reliability, resulting in an
improved reliability over datagram services. WTP provides three different classes of lightweight transaction services:
Class 0: Unreliable Request, which might be used for simple push services.
Class 1: Reliable Request, used for reliable push services. Thereby, the sender will be
acknowledged that her or his message was delivered to the receiver.
Class 2: Reliable Request/Response, the basic transaction. A reliable request will be
sent to the receiver, which itself responds with the requested data.
In order to achieve the objectives mentioned above, WTP supports protocol features such as
message transfer instead of byte-stream transfer, asynchronous transactions, error handling,
concatenation and separation, as well as no explicit connection set up or tear down phases
(causing excessive overhead). Although WTP is an optional layer, it is very important for,
e.g., mobile banking applications as the user has to be aware whether the transaction s/he adjoined was performed or not.
As described above, HTTP does not perform well in wireless communications. Thus, the
WAP-Forum specified the Wireless Session Protocol (WSP), which is the last layer underneath the applications. The objective is to enable an organised exchange of information between co-operating client/server applications by establishing and releasing a reliable session
and capability negotiation. WSP provides a consistent interface for two session services: A
Connection Mode, which defines a connection-oriented service that directly accesses WTP
functionality, and a Connectionless Mode, which specifies a connectionless service, based on
a secure (WTLS) or non-secure (WDP) datagram service. The essential properties of WSP are
full HTTP 1.1 functionality and semantics, but using compact binary encoding (e.g., using
definitions for well-known headers to reduce protocol overhead, or header code pages), a
long-lived session state including session migration, and a facility for pushing data to mobile
devices.
On top of the WAP stack, the Wireless Application Environment (WAE) is located which includes all elements of the WAP architecture related to application specification and execution.
This comprises networking schemes, content formats, programming languages as well as
shared services, caching, and device profiles. The WAE model consists of four components:
WAE User Agents, e.g. a browser that interprets content delivered from the underlying WAP
layers. This can be WML (Wireless Markup Language), or WMLScript similar to Javascript.
The filters (second component) within the WAP Proxy (see figure 2) act as a converter for
WAP content, as they are able to convert HTML to WML. The third component, WTA (Wireless Telephony Applications), is a set of telephony specific extensions that allows for the integration of voice services in the WAP model.
New Features in WAP 1.2
The functionality of each layer described above is the same in WAP 1.1 and WAP 1.2, i.e.,
WAP 1.1 enabled devices could be used in a WAP 1.2 environment and vice versa, but cannot
take advantage of the new features specified in version 1.2. Additionally to version 1.1, WAP
1.2 introduces a WAP pushing architecture. The pushing architecture allows for pushing contents from a server to a mobile client using the push-over-the-air protocol between WAP
Proxy and WAP-enabled mobile device. On application layer, the WTA interface was enhanced to support further telephony services. In order to make use of the security aspects at
the client, a WMLScript Crypto Library was specified in WAP 1.2. An important progress of
WAP 1.2 is the introduction of a Framework for Composite Capability/Preference Profiles
(CC/PP) which allows a description of a mobile devices capabilities (so called User Agent
Profiles or Capability and Preference Information (CPI), comprising hardware capabilities,
software characteristics, applications and users preferences, WAP-specific settings, as well
as the characteristics of the network technology the mobile device is currently using for communication. According to this feature, the relevant mechanisms of WSP were specified in
more detail in order to support an efficient transmission and caching of the CPI specified for a
mobile device.
The next generation of the Wireless Application Protocol will comprise several interfaces to
support further technologies, such as SIM-cards or billing and accounting functionality.
WAP
Proxy
SP
WSP
WSP
WTP
WTP
WAE
WAE
WSP
WSP
WTP
WTP
WTLS
WTLS
UDP
UDP
WTLS
WTLS
UDP
UDP
IP
IP
PPP
PPP
PSTN
PSTN
PSTN
PSTN CSD-RF
CSD-RF
IP
IP
PPP
PPP MOST/
MOST/
CSD-RF
CAN
CSD-RF CAN
IP
IP
MOST/
MOST/
CAN
CAN
CONCLUSION
In order to handle the information flood for future cars, the current protocol suite of the Internet as a common platform is unusable, as the protocols are not optimised for mobile and wireless environments. In this paper, we described the architecture of the Wireless Application
Protocol and how mobile applications can benefit from the mechanisms and protocols provided by WAP. Those properties empower WAP as a common platform for implementing
new applications for future cars.
[1] European Telecommunications Standards Institute (ETSI), http://www.etsi.org/, 2000
[2] Institute of Electrical and Electronics Engineers (IEEE), http://www.ieee.org/, 2000
[3] Infrared Data Association (IrDA), http://www.irda.org/, 2000
[4] Bluetooth Consortium, http://www.bluetooth.com/, 2000
[5] U. Black: Voice over IP, Prentice Hall, 2000
[6] J. Schiller: Mobile Communications. Addison Wesley, 1999
[7] Wireless Application Protocol Forum, http://www.wapforum.org/, 2000
8