Issues in Mobile Computing

Being of the most prominent technologies, mobile computing has its fair share of issues and
concerns. These issues need to be resolved in order to improve upon Mobile Technology
and provide more capable and secure facilities to people. Some of the issues are listed
below:

Security Standards:
When working mobile, one is dependent on public networks, requiring careful use of
Virtual Private Network (VPN). Security is a major concern while concerning the
mobile computing standards on the fleet. Along with this improper and unethical
practices such as hacking, industrial espionage, pirating, online fraud and malicious
destruction are some but few of the problems experienced by mobile computing.
Another big problem is of identity theft. Various users sharing names and passwords
pose a major threat to security. Unauthorized access can leak sensitive information to
the outsiders.

Bandwidth:
Bandwidth utilization can be improved by logging (bulk operations against short
requests) and compression of data before transmission. Additionally, lazy write back
and file prefetching can help the network in times of peak demands. Lazy write back
is very helpful in the sense that the data to be written may undergo further
modifications. The technique of caching frequently accessed data items can play an
important role in reducing contention in narrow bandwidth wireless networks. The
cached data can help improve query response time. Since mobile clients often
disconnect to conserve battery power the cached data can support disconnected
operations

Location Intelligence:
As the mobile computers move they encounter networks with different features. A mobile
computer must be able to switch from infrared mode to radio mode as it moves from indoors
to outdoors. Additionally it should be capable of switching from cellular mode of operation
to satellite mode as the computer moves from urban and rural areas. In mobile computing as
computers are working in cells and are being serviced by different network providers, the
physical distance may not reflect the true network distance. A small movement may result in
a much longer path if cell or network boundaries are crossed. It will also lead to updating of

Faculty: Ms. Vimal Gaur

the location dependent information as described above. This can increase the network latency
as well as risk of disconnection. Service connections must be dynamically transferred to the
nearest server. However, when load balancing is a priority this may not be possible.

Power Consumption:
Mobile Computers will rely on their batteries as the primary power source. Batteries
should be ideally as light as possible but at the same time they should be capable of
longer operation times. Power consumption should be minimized to increase battery life.
Chips can be redesigned to operate at lower voltages. Power management can also help.
Individual Components, be powered down when they are idle.

Transmission Interferences:
Weather and terrain problems exist in mobile computing. Some connections in certain
technologies are limited by the distance. Along with that reception in poor at certain
places such as tunnels and basements.

Faculty: Ms. Vimal Gaur

Design Considerations For Mobile Computing

The mobile computing environment needs to be context independent as well as context

sensitive. Context information is related to the environment.

The term context means all the information that helps to determine the state of the object.

In a mobile computing environment the context data is captured so that decisions can be made
about how to adapt content or behaviour to suit this context.
There are many ways in which contexts can be adapted:
Content with Context Awareness
Content switch on Context
Content Transcoding on Context
EXAMPLES OF CONTEXT INFROMATION

Faculty: Ms. Vimal Gaur

 Mobile computing is basically the use of portable devices that are capable of use wireless network
communication.
It is divided into mobile devices and wireless communication.
For designing mobile applications have altogether different challenges than designing
desktop application. It requires different mind-set.

On mobile platform everything is limited to make balance between design principles and resources
at hand such changes shall mean that content and behavior of applications should be adapted to
suit the current situation.
Few of design consideration parameter for mobile computing:

Native vs. Mobile Web

If your application requires local processing, access to local resources and can work in
occasionally connected scenario or no connectivity consider designing a native application.
A native application is hard to maintain, requires separate distribution and upgrade infrastructure,
are compatible only with target device/platform, requires more effort (sometimes huge) to port on
different devices.
A mobile web application is compatible with all devices with internet connection and a browser.

Target device
Target device and platform (OS) play a key role throughout design decisions making process.
Design decisions are influenced by target device’s screen size, resolution, orientations, memory,
CPU performance characteristics, Operating systems capabilities, OEM (device vendor) specific
OS changes/limitations, device

Faculty: Ms. Vimal Gaur

 hardware, user input mechanism (touch/non-touch), sensors (such as GPS or accelerometer)
etc.

User experience
User experience, for mobile applications, needs utmost importance (may be more than
desktop).
User interface should be rich, intuitive and responsive. While using mobile application user
is often distracted by external or internal (e.g. incoming call when user is in middle of a
wizard) events.

Resource Constraint
In design decision should take into account the limited CPU, memory and battery life.
Reading and writing to memory, wireless connections, specialized hardware, and processor
speed all have an impact on the overall power usage.
For example using notification or app directed SMS instead of polling to monitor a
value/flag on server.

Multiple Platform
An application will target not only one platform or only one device.
In near future, requirement like same code base should support iPhone and iPad or Android
Phone and Android tablet will arise.
Design Architect should consider portability, technology agnostic with platform specific
implementation. To make design with reuse across the platforms.

Security
Devices are more vulnerable than desktop, primarily due to lack of awareness.
It may device can be lost easily. It needs to secured device – server communication and
server accepts request only from authentic source (device).
If you are storing any confidential application or configuration data locally, ensure
that the data is encrypted.

Network Communication
Network communication on device is very significant parameter.
To reduce network traffic by combining several commands in one request.
For example, committing added, updated and deleted records in one request instead of
firing separate request on each add/update/delete.

Faculty: Ms. Vimal Gaur

 Mobile File Systems
Coda(File system)

Coda is a distributed file system developed as a research project at Carnegie Mellon

University since 1987 under the direction of Mahadev Satyanarayanan. It descended directly
from an older version of Andrew File System (AFS-2) and offers many similar features.
The InterMezzo file system was inspired by Coda.

Why is Coda promising and potentially very important?

Coda is a distributed filesystem with its origin in AFS2. It has many features that are very
desirable for network filesystems. Currently, Coda has several features not found elsewhere.
• disconnected operation for mobile computing
• is freely available under a liberal license
• high performance through client side persistent caching
• server replication
• security model for authentication, encryption and access control
• continued operation during partial network failures in server network
• network bandwith adaptation
• good scalability
• well defined semantics of sharing, even in the presence of network failures

How does Coda work?

It works by implementing two complementary

functionalities:
1. Availability of files by replicating a file volume across many servers
2. Disconnected mode of operation by caching files at the client machine

Supported platforms:

Coda has been developed on Linux. Support for it appeared in the 2.1 Linux kernel series. It has
also been ported to FreeBSD. Efforts have been made to port Coda to Microsoft Windows, from
the Windows 95/Windows 98 era, Windows NT to Windows XP, by means of open source
projects like the DJGCC DOS C Compiler and Cygwin.

Features:

• Disconnected operation for mobile computing.

• Is freely available under the GPL[1]

Faculty: Ms. Vimal Gaur

 • High performance through client side persistent caching
• Server replication
• Security model for authentication, encryption and access control
• Continued operation during partial network failures in server network
• Network bandwidth adaptation
• Good scalability
• Well defined semantics of sharing, even in the presence of network failures
Coda uses a local cache to provide access to server data when the network connection is lost.
During normal operation, a user reads and writes to the file system normally, while the client
fetches, or "hoards", all of the data the user has listed as important in the event of network
disconnection. If the network connection is lost, the Coda client's local cache serves data from
this cache and logs all updates. This operating state is called disconnected operation. Upon
network reconnection, the client moves to reintegration state; it sends logged updates to the
servers. Then it transitions back to normal connected-mode operation.
Also different from AFS is Coda's data replication method. AFS uses a pessimistic replication
strategy with its files, only allowing one read/write server to receive updates and all other servers
acting as read-only replicas. Coda allows all servers to receive updates, allowing for a greater
availability of server data in the event of network partitions, a case which AFS cannot handle.
These unique features introduce the possibility of semantically diverging copies of the same files
or directories, known as "conflicts". Disconnected operation's local updates can potentially clash
with other connected users' updates on the same objects, preventing reintegration. Optimistic
replication can potentially cause concurrent updates to different servers on the same object,
preventing replication. The former case is called a "local/global" conflict, and the latter case a
"server/server" conflict. Coda has extensive repair tools, both manual and automated, to handle
and repair both types of conflicts.

Current activities on Coda

Faculty: Ms. Vimal Gaur

CMU is making a serious effort to improve Coda. We believe that the system needs to be taken
from its current status to a widely available system. The research to date has produced a lot of
information regarding performance and implementation on which the design was based. We are
now in a position to further develop and adapt the system for wider use. We will emphasize:

• reliability and performance

• ports to important platforms

• documentation, mailing groups

• extensions in functionality

The current activities with Coda are mostly aimed at making this very good file system widely
available, and a network file system of choice.

Architecture of Coda

Coda was designed to be a scalable, secure, and highly available distributed file system. An
important goal was to achieve a high degree of naming and location transparency so that the
system would appear to its users very similar to a pure local file system. By also taking high
availability into account, the designers of Coda have also tried to reach a high degree of failure
transparency. Coda is a descendant of version 2 of the Andrew File System (AFS), which was
also developed at CMU (Howard et al., 1988; Satyanarayanan, 1990), and inherits many of its
architectural features from AFS. AFS was designed to support the entire CMU community,
which implied that approximately 10,000 workstations would need to have access to the system.
To meet this requirement, AFS nodes are partitioned into two groups. One group consists of a
relatively small number of dedicated Vice file servers, which are centrally administered. The
other group consists of a very much larger collection of Virtue workstations that give users and
processes access to the file system, as shown in Figure. Coda follows the same organization as
AFS. Every Virtue workstation hosts a user-level process called Venus, whose role is similar to
that of an NFS client. A Venus process is responsible for providing access to the files that are
maintained by the Vice file servers. In Coda, Venus is also responsible for allowing the client to
continue operation even if access to the file servers is (temporarily) impossible. This additional
role is a major difference with the approach followed in NFS. The internal architecture of a
Virtue workstation is shown in Fig. 10-2. The important issue is that Venus runs as a user-level
process. Again, there is a separate Virtual File System (VFS) layer that intercepts all calls from
client applications, and forwards these calls either to the local file system or to Venus, as shown
in Fig. 10-2. This organization with VFS is the same as in NFS. Venus, in turn, communicates
with Vice file servers using a user-level RPC system. The RPC system is constructed on top of
UDP datagrams and provides at-most-once semantics. There are three different server-side
processes. The great majority of the SEC. 10.2 THE CODA FILE SYSTEM 605 Vice file server
Virtue client Transparent access to a Vice file server Figure 10-1. The overall organization of

Faculty: Ms. Vimal Gaur

AFS. work is done by the actual Vice file servers, which are responsible for maintaining a local
collection of files. Like Venus, a file server runs as a user-level process. In addition, trusted Vice
machines are allowed to run an authentication server, which we discuss in detail later. Finally,
update processes are used to keep metainformation on the file system consistent at each Vice
server. Coda appears to its users as a traditional UNIX-based file system. It supports most of the
operations that form part of the VFS specification (Kleiman, 1986), which are similar to those
listed in Fig. 10-0 and will therefore not be repeated here. Unlike NFS, Coda provides a globally
shared name space that is maintained by the Vice servers. Clients have access to this name space
by means of a special subdirectory in their local name space, such as /afs. Whenever a client
looks up a name in this subdirectory, Venus ensures that the appropriate part of the shared name
space is mounted locally. We return to the details below.

Fig: Architecture of Coda

Faculty: Ms. Vimal Gaur

 WAP (Wireless Application Protocol)

WAP is an international standard establishing how mobile devices can access information on the
Internet. It is a widely used set of protocols used on wireless devices such as mobile phones and
PDAs. WAP is the set of rules governing the transmission and reception of data by computer
applications on or via wireless devices like mobile phones. WAP allows wireless devices to view
specifically designed pages from the Internet using only plain text and very simple black-and-
white pictures.

WAP is a standardized technology for cross-platform, distributed computing very similar to the
Internet's combination of Hypertext Markup Language (HTML) and Hypertext Transfer Protocol
(HTTP), except that it is optimized for:

 low-display capability
 low-memory
 Low-bandwidth devices, such as personal digital assistants (PDAs), wireless phones, and
pagers.

WAP is designed to scale across a broad range of wireless networks like GSM, IS-95, IS-136,
and PDC.

The WAP Model:

The figure below shows the WAP programming model. Note, the similarities with the Internet
model. Without the WAP Gateway/Proxy, the two models would have been practically identical.

Faculty: Ms. Vimal Gaur

WAP Gateway/Proxy is the entity that connects the wireless domain with the Internet. You
should make a note that the request that is sent from the wireless client to the WAP
Gateway/Proxy uses the Wireless Session Protocol (WSP). In its essence, WSP is a binary
version of HTTP.

A markup language - the Wireless Markup Language (WML) has been adapted to develop
optimized WAP applications. In order to save valuable bandwidth in the wireless network, WML
can be encoded into a compact binary format. Encoding WML is one of the tasks performed by
the WAP Gateway/Proxy.

How WAP Model Works?

When it comes to actual use, WAP works like this:

 The user selects an option on their mobile device that has a URL with Wireless Markup
language (WML) content assigned to it.
 The phone sends the URL request via the phone network to a WAP gateway using the
binary encoded WAP protocol.

Faculty: Ms. Vimal Gaur

  The gateway translates this WAP request into a conventional HTTP request for the
specified URL and sends it on to the Internet.
 The appropriate Web server picks up the HTTP request.
 The server processes the request just as it would any other request. If the URL refers to a
static WML file, the server delivers it. If a CGI script is requested, it is processed and the
content returned as usual.
 The Web server adds the HTTP header to the WML content and returns it to the gateway.
 The WAP gateway compiles the WML into binary form.
 The gateway then sends the WML response back to the phone.
 The phone receives the WML via the WAP protocol.
 The micro-browser processes the WML and displays the content on the screen.

WAP is designed in a layered fashion, so that it can be extensible, flexible, and scalable. As a
result, the WAP protocol stack is divided into five layers:

 Application Layer

Wireless Application Environment (WAE). This layer is of most interest to content

developers because it contains among other things, device specifications, and the content
development programming languages, WML, and WMLScript.

 Session Layer

Wireless Session Protocol (WSP). Unlike HTTP, WSP has been designed by the WAP
Forum to provide fast connection suspension and reconnection.

 Transaction Layer

Wireless Transaction Protocol (WTP). The WTP runs on top of a datagram service, such
as User Datagram Protocol (UDP) and is part of the standard suite of TCP/IP protocols
used to provide a simplified protocol suitable for low bandwidth wireless stations.

 Security Layer

Faculty: Ms. Vimal Gaur

 Wireless Transport Layer Security (WTLS). WTLS incorporates security features that are
based upon the established Transport Layer Security (TLS) protocol standard. It includes
data integrity checks, privacy, service denial, and authentication services.

 Transport Layer

Wireless Datagram Protocol (WDP). The WDP allows WAP to be bearer-independent by

adapting the transport layer of the underlying bearer. The WDP presents a consistent data
format to the higher layers of the WAP protocol stack, thereby offering the advantage of
bearer independence to application developers.

Each of these layers provides a well-defined interface to the layer above it. This means that the
internal workings of any layer are transparent or invisible to the layers above it. The layered
architecture allows other applications and services to utilise the features provided by the WAP-
stack as well. This makes it possible to use the WAP-stack for services and applications that
currently are not specified by WAP.

The WAP protocol architecture is shown below alongside a typical Internet Protocol stack.

Note that the mobile network bearers in the lower part of the figure above are not part of the
WAP protocol stack.

Faculty: Ms. Vimal Gaur

Wireless Transport Layer Security (WTLS)

A secure connection between a client and the server is required in the various Web
Applications. Wireless Transport Layer Security is the security protocol to ensure transactions
on Wireless Application Protocol terminal. WTLS is based on the Internet de facto standard
Transport Layer Security (TLS) v1.0 and TLS is derived from the widely used Secure Sockets
Layer (SSL) 3.0. WTLS is poised to do for the wireless internet what SSL did for the internet
and optimized for wireless communication environments.

WTLS has been optimized for use over narrow-band communication channels. It ensures
data integrity, privacy, authentication, and denial-of-service protection. For Web Applications,
that employ standard Internet security techniques with TLS, the WAP gateway automatically
and transparently manages wireless security with minimal overhead. It provides end-to-end
security and application-level security. This includes security facilities for encrypting or
decrypting, strong authentication, integrity and key management. WTLS complies with
regulations on the use of cryptographic algorithms and key lengths in different countries.

WTLS employs specially adapted mechanisms for the wireless environment. For
example, long existing secure sessions, optimized handshake procedure for the wireless
network, and simple data reliability for operation over datagram bearers.

WTLS provides functionality similar to SSL/TLS and incorporates new features such as
datagram support, optimized handshake and dynamic key refreshing. Applications are able to
selectively enable or disable WTLS features depending on their security requirements and the
characteristics of the underlying network like SSL.

Despite of their close resemblance, WTLS has been amended partially to meet the
requirements of wireless network. The common requirements set by wireless networks are
described below:

Both datagram and connection oriented transport layer protocols must be supported. It

Faculty: Ms. Vimal Gaur

 must be possible to cope with, for example, lost, duplicated, or out of order datagrams
without breaking the connection state.

The protocol must take into account that round-trip times with some bearers can be long.

The slowness of some bearers is a major constraint. Therefore, the amount of overhead
must be kept in the minimum.

The processing power of many mobile terminals is quite limited. This must be taken into
account when cryptographic algorithms are chosen.

The memory capacity of most mobile terminals is very modest. Therefore, the
number of cryptographic algorithms must be minimized and small-sized
algorithms must be chosen.

International restrictions and rules for using, exporting, and importing cryptography must
be taken into account. This means that it must be possible to achieve the best permitted
security level according to the legislation of each area.

WTLS Layer Goals

The primary goal is to provide security between client and server in terms of:

Privacy: Data sent is not presented in clear text to make it difficult for another network
user to look at the data. This is done through encrypting the data stream.

Faculty: Ms. Vimal Gaur

 Data Integrity: If a network user were able to change the sent data, it should be detected
by the client or server that sent the data. This is done through message digests.

Authentication: A network partner can be sure that he or she is connected with the true
desired partner and not with someone else who pretends to be it. This is done through
digital certificates.

Denial of Service: Rejection and detecting data that is not successfully verified. This
is done through a WTLS function.

WTLS Connection Management

WTLS connection management provides a secure communication between client and

server. Several steps are needed within the connection establishment process through
negotiations to agree to security parameters between the client and server. This is nearly
similar to a secure connection establishment process via Secure Socket Layer(SSL).

Security parameters for the secure connection establishment process may include, for
example, cryptographic algorithm, key exchange procedures, and authentication.

Service primitives provide support to initiate this secure connection. The following
service primitives are available:
SEC-Create:Initiates a secure connection with the following optional parameters:

1. Client certificates 4. Compression methods

2. Key exchange suites 5. Key refreshing rules
3. Cipher suites 6. Session ID
SEC-Exchange: Performs public-key authentication or key exchange with a client.
SEC-Commit: Initiated when the handshake is completed and either peer requests to
switch to the agreed connection state.

Faculty: Ms. Vimal Gaur

 SEC-Terminate: Terminates the connection.

SEC-Exception: Informs the other partner about warning level alerts.

SEC-Create-Request: The server requests the client to initiate a new
handshake.

Protocol Overview

The internal architecture of WTLS is shown in Figure below. The WTLS Record
Protocol is layered protocol and divided into four protocol clients – the handshake protocol,
the change cipher spec protocol, the alert protocol and the application data protocol. The
application protocol is not described here, since it is the interface for the upper layers.

Record Protocol

The Record Protocol takes messages to be transmitted, optionally compresses the data, applies
a MAC, encrypts and transmits the result. Received data is decrypted, verified, decompressed
and then delivered to higher level clients. Moreover, the Record Protocol takes care of the data
integrity and authentication.

Handshake Protocol

The Handshake Protocol is composed of three sub-protocols, which are used to allow peers to
agree upon security parameters for the Record Layer, authenticate themselves, instantiate
negotiated security parameters, and report error conditions to each other. This layer is
responsible for negotiating a secure session and produces the cryptographic parameters
described below:

Faculty: Ms. Vimal Gaur

 Session Identifier:An arbitrary byte sequence chosen by the server to identify an
active or resumable secure.
Protocol Version:WTLS protocol version number.

Peer Certificate:Certificate of the peer (may not be null).

Compression Method:The algorithm used to compress data prior to encryption.

Cipher Spec:Specifies the bulk data encryption algorithm (such as null, RC5, DES,
etc.) and a MAC algorithm (such as SHA-1).

Master Secret:20-byte secret shared between the client and server.

Sequence Number Mode:Which sequence numbering scheme (off, implicit, or explicit)
is used to this secure connection .

Key Refresh:Defines how often some connection state values (encryption key, MAC
secret, and IV) calculations are performed.
Is Resumable:A flag indication whether the secure session can be used to initiate new
secure connection.

Change Cipher Spec Protocol

The change cipher spec protocol exists to signal transitions in ciphering strategies. The
protocol consists of a single message, which is encrypted and compressed under the current
connection state. The message consists of a single byte of value 1.

Alert Protocol

Alert messages convey the severity of the message and a description of the alert. There are
three types of alert messages: warning, critical, and fatal. Alert messages, labeled as critical or
fatal, result in termination of the current secure connection. Other connections using the secure

Faculty: Ms. Vimal Gaur

session may continue. In case of the fatal message, the session identifier must be invalidated so
that the failed connection is not used to establish new secure connections. However, in case of
the critical message, the session identifier may be used for establishing new secure connections.

User Data Protocol

Consists of the payload which the WAP client intends to use.

Wireless Session Layer Protocol

The Session layer protocol family in the WAP architecture is called the Wireless Session
Protocol, WSP. WSP provides the upper-level application layer of WAP with a consistent
interface for two session services. The first is a connection-mode service that operates above a
transaction layer protocol WTP, and the second is a connectionless service that operates above
a secure or non-secure datagram transport service.

The Wireless Session Protocol offers the HTTP request-response paradigm, and in addition it
offers a new service named Wap Push, allowing applications in the network to push
(unsolicited) data to a push-enabled application on the mobile device.

The Wireless Session Protocol started with the knowledge that many header names and values
in the Hyper_Text_Transfer_Protocol are fixed strings. With efficient over-the-air usage of the
bandwidth in mind, WSP attempts at encoding these fixed strings in a compact binary manner.
This way, the header cache-control: no-cache can be encoded in 2 bytes: one for the header
name (cache-control) and one for its value (no-cache).

There are 2 types of WSP:

 Connectionless WSP (CL-WSP) only offers unreliable transport of WSP primitives,

both pull (request and response) and push (single message).
 Conection-oriented WSP (CO-WSP) offers the same services as CL-WSP, extended
with connection (session) management, session capability negotiation, larger data

Faculty: Ms. Vimal Gaur

 transfer (segmentation and reassembly) and reliable data transport (acknowledgement
mechanism).

On a protocol level, CO-WSP relies upon WTP for the added functionality. With CL-WSP,
the WTP layer is reduced to a one-byte transaction identifier, which is part of WSP as the 1st
byte. This way it is still possible in WTP to match a response with a request (same WSP
transaction identifier).

The word "connection" in connection-oriented WSP has nothing to do with the actual bearer
connection. In fact CO-WSP might be seen as a more stateful and elaborate version of CL-
WSP, where the latter provides only basic functionality.

WSP is based on HTTP 1.1 with few enhancements. WSP provides the upper-level application
layer of WAP with a consistent interface for two session services. The first is a connection-
oriented service that operates above a transaction layer protocol WTP and the second is a
connection less service that operates above a secure or non-secure datagram transport service.
Therefore, WSP exists for two reasons. First, in the connection-mode it enhances the HTTP
1.1's performance over wireless environment. Second, it provides a session layer so the whole
WAP environment resembles ISO OSI Reference Model.

Wireless Application Environment

Wireless Application Environment (WAE)

WAE is the uppermost layer in the WAP software stack. This layer provides basic
components on which developers can develop their mobile applications. It provides an
environment that enables a wide range of applications to be used on wireless devices.The WAE
defines user agents, services, and formats. The WAE provides a vendor-neutral application
architecture based on Internet standards. The WAE specifications outlines an application
programming model that supports browsing, scripting, and extensions that allow cellular
network operators to offer network services within WAP. Like the WAP protocol stack
specifications, the WAE standards are tailored to suit the requirements of mobile devices and
networks.

Faculty: Ms. Vimal Gaur

 The standards support independent user agents to allow for expanded device
functionality and to ensure that special services such as mobile network access are isolated from
regular Internet services. The services that comprise the WAE include an XML compliant
Wireless Markup Language, a scripting language (WMLScript) and supporting libraries, as well
as telephony services provided by the Wireless Telephony Application libraries. Each class of
information within the WAE is identified by unique format.

Need for WAE

HTTP was developed prior and is successful so why not use HTTP as the WWW model does?

The need for different environment was because mobile phones are much slower and
less have less bandwidth so a different model was required hence we came up with WAE.
Because WAE is designed to handle slower processors and the specific constraints of the
wireless network, such as limited bandwidth and high error rates, the markup languages
available to wireless devices, such as WML and WMLscript, are scaled-down and conform to a
format that requires less memory and processing power than HTML.

Parts of WAE

WAE consists of following components:

1. Addressing mode

syntax suitable for naming resources stored on servers. WAP use the same addressing
model as the one used on the Internet that is Uniform Resource Locators (URL).

Wireless Markup Language (WML)

lightweight markup language designed to meet the constraints of a wireless

Faculty: Ms. Vimal Gaur

 environment with low bandwidth and small handheld devices. The Wireless Markup
Language is WAP's analogy to HTML used on the WWW. WML is based on the
Extensible Markup Language (XML).

WMLScript

lightweight scripting language. WMLScript is based on ECMAScript, the same

scripting language similar to JavaScript. It can be used for enhancing services written in
WML in the way that it to some extent adds intelligence to the services; for example,
procedural logic, loops, conditional expressions, and computational functions.

Wireless Telephony Application (WTA, WTAI)

WTA is a framework and programming interface for telephony services. The Wireless
Telephony Application (WTA) environment provides a means to create telephony
services using WAP.

WAP Model

Model for WAP is similar to that of HTTP but because a Web server only speaks
HTTP, WAE uses a gateway to translate between WAP and HTTP. Each wireless device
communicates with a designated gateway that makes calls to any number of Web servers.

Faculty: Ms. Vimal Gaur

As WAE sits at top of WAP model the gateway must be designed to convert HTML pages to
WML pages or provide WAP supported pages only the function of lower layers may remain
same for these server .As HTML pages can be easily converted to WML pages gateways uses
converter rather than storing different files for web and wireless users.

Different application for WAE are

● The Mobile Internet

Mobile phones today are equipped with WAP enabled browsers and colour screens.
This allows easily access to the Web and download online content or access online
services. People can use their phones to search on Google, send emails, or access a
website through WAP servers.

● Mobile Instant Messaging Services

Mobile instant messaging (MIM) services are the same as online instant messaging
such as ICQ, Skype, and Windows Live Messenger except that it used on a cellphone.
It allows users to communicate with one or more selected friends or contacts using text
messages.

● WAP FTP Servers

FTP servers can be deployed for accessing small file online .this allow easy remote
access for off site files on mobile. Big sized files are generally restricted on this server
as data rate is slow

● Banking

Faculty: Ms. Vimal Gaur

 Actions like checking bank statements ,Paying bills & Transferring money between
accounts are implemented with WAP. These can be easily implemented with WAP
compliance as data rate required is low .

● Shopping and Ticketing

Buying everyday commodities and booking or buying tickets can be supported with
WAP servers which are accessed via mobiles to use these services

Faculty: Ms. Vimal Gaur

REFERENCES

[1] https://en.wikipedia.org/wiki/Wireless_Application_Protocol

[2]https://docs.oracle.com/cd/E23095_01/Platform.93/ATGProgGuide/html/s1602wirelessappli
cationenvi ronment01.html

[3] http://www.informit.com/articles/article.aspx?p=19578&seqNum=10

[4] http://textofvideo.nptel.iitm.ac.in/106105081/lec22.pdf

[5]http://www.dauniv.ac.in/downloads/Mobilecomputing/MobileCompChap121L04WAPProtocolLayer
s.pdf

[6] https://www.slideshare.net/snehcp/coda-file-system

Faculty: Ms. Vimal Gaur

Faculty: Ms. Vimal Gaur
Faculty: Ms. Vimal Gaur