Technical Geek

Building VoiceXML Applications

2009-11-10T09:58:00.000-08:00

Now that you have a solid understanding of the VoiceXML architecture, it is time to look more closely at the VoiceXML language itself. If you have experience with other XML-based markup languages, such as WML or XHTML, or even other tag-based languages, such as HTML or HDML, creating VoiceXML applications will not pose much difficulty for you. The main adjustment will be to the development of the user interface. Rather than sending content to a screen, it is spoken over a telephone. For this reason, it is very important to create clean, intuitive applications so users do not become frustrated and hang up. VoiceXML includes elements to help with this, as we will discuss later in this section.

Language Concepts
Before examining some VoiceXML code, let's take a quick look at the basic concepts behind a VoiceXML application.

Session
Once a user connects to the VoiceXML gateway, a session is started. This session is maintained as new VoiceXML documents are loaded and unloaded. The session ends only when requested by the user, the VoiceXML document, or the voice gateway. Each platform will have default session characteristics, many of which can be controlled by VoiceXML logic.

Dialogs
VoiceXML applications are constructed of one or many dialogs. Each dialog represents some form of conversational state with the user. After completing one dialog, you move on to another dialog, until the application is complete. There are two types of dialogs: forms and menus. A form collects user input, and a menu gives the user options to choose from. If at any point no dialog is specified, the VoiceXML application terminates automatically.

VoiceXML also has subdialogs. These are very similar to function calls, allowing the application to call out to a new dialog, then return to the original form. All of the variables, grammar, and state information is available upon returning to the calling document. Subdialogs can be used to create a set of components that may be used from several applications.

Applications
A VoiceXML application is a set of documents that share the same root document. This root document is automatically loaded any time a user interacts with any document in the application, and remains loaded until the user transitions to a document outside of the application. While it is loaded, the root document's variables are available to the other documents. It is also possible to specify grammars to be active for the duration of the application.

Grammars
Grammars make it possible to specify valid inputs from the user. Each dialog will contain at least one speech and/or DTMF grammar. In simple applications, only the dialog's grammars are active for that dialog. In the more complex, mixed-initiative applications, it is possible to have active grammars outside of the dialog being executed. Mixed-initiative refers to applications in which both the user and the gateway determine what will happen next.

Grammar creation is a very important aspect of designing intuitive, robust VoiceXML applications. It is essential to create grammars that accurately reflect the typical speech inputs from a user. If this is not achieved, either the prompts or the grammar will have to be changed. In some cases, the built-in grammars may be sufficient. VoiceXML 2.0 has the following built-in grammars: boolean, date, digits, currency, number, and time. In addition, many of the voice gateway vendors have proprietary grammars that you can use.

Events
When the normal execution of an application is interrupted, an event is thrown. In most cases, events are used when the user fails to respond to a prompt, or when the response is not suitable. They are also used when a user requests help or wants to exit the application. When an event is triggered, the element allows you to specify what the reaction should be. If there is no handler at the dialog level, the event can be caught at a higher level, since events follow an inheritance model.

Links
Links enable you to create mixed-initiative applications. They specify a grammar that is active when the user is within scope of the link. When the input matches the grammar, the user is redirected to the specified destination URI.

Scripting
If you require additional control over an application, which is not provided by standard VoiceXML elements, you can use scripting in the form of ECMAScript. This allows you to do such things as collect values of several fields in a single response.

VoiceXML

2009-11-10T09:48:00.000-08:00

Voice eXtensible Markup Language (VoiceXML) is an XML-based language for creating voice-enabled applications. It provides a standard way for developers to extend enterprise data and Web content to a new medium. Just as HTML describes the visual interface for a Web browser, VoiceXML describes the voice interface for a voice browser, allowing for audio input and output. VoiceXML leverages the Internet for development and delivery, making it easy for developers to add voice integration to existing systems.

The major goal of VoiceXML is to bring the advantages of Web-based development and content delivery to IVR systems. To do this, VoiceXML brings together many technologies, including speech recognition, keypad input, synthesized speech, digitized audio, and audio recordings. The result is an efficient and robust way to create userfriendly voice applications.

History of VoiceXML
Even though VoiceXML is a relatively new technology, it already has quite a history. In 1995, a group of researchers at AT&T Research were working to discover ways to use the Internet for telephony applications. The goal was to devise a system that could deliver Web content and services to ordinary phones. Over the next several years, the research continued, although in separate projects, in separate companies. AT&T, Lucent, and Motorola were all working on essentially the same thing: voice Internet.

By 1999, AT&T and Lucent each had its own version of the Phone Markup Language (PML), and Motorola had developed a technology called VoxML. At the same time, IBM was working on a similar technology called SpeechML. It quickly became clear that a joint solution was required if the voice Web market was going to succeed; consequently, these companies created an organization called the VoiceXML Forum. Its members used the best features of each proprietary technology (with the majority of the syntax coming for Motorola's VoxML), along with some additions, to create the first version of VoiceXML, 0.9.

After VoiceXML 0.9 was published, the growing community of VoiceXML Forum members made huge improvements to the language, resulting in the release of VoiceXML 1.0 in March 2000. This release was well received, leading to several VoiceXML 1.0-compliant product offerings. With this initial success, the VoiceXML Forum submitted VoiceXML 1.0 to the W3C for consideration. With the future of the language in its hands, the W3C's Voice Browser Working Group put together version 2.0 of VoiceXML, which is now an official W3C recommendation. Even with all of the improvements to version 2.0, it is still very similar to version 1.0, making application upgrades trivial.

The VoiceXML Forum continues to flourish. Along with the founding members—AT&T, Lucent, Motorola, and IBM—there are close to 70 promoter members and almost 400 supporters of the technology! This is quite an accomplishment in just over three years. With such broad industry support, VoiceXML is destined to change the face of voice application development. It will not be long before we see a variety of consumer-oriented voice portals, as well as corporate applications, taking advantage of this flexible language.

Design Goals
The developers of VoiceXML had several goals, many centered on how VoiceXML relates to Internet architecture and development. Here are some of the top areas where VoiceXML benefits from the Internet:

VoiceXML is an XML-based language. This allows it to take advantage of the powerful Web development tools on the market. It also allows developers to use existing skill sets to build voice-based applications.

VoiceXML applications are easy to deploy. Unlike many of the proprietary Interactive Voice Response (IVR) systems, VoiceXML servers can be placed anywhere on the Internet, taking advantage of common Internet server-side technologies.

The server logic and presentation logic can be cleanly separated. This allows VoiceXML applications to take advantage of existing business logic and enterprise integration. Using a common back end allows the development of different forms of presentation logic based on the requesting device.

VoiceXML applications are platform-independent. Developers do not have to worry about making VoiceXML applications work on multiple browsers over multiple networks. When developing VoiceXML applications, the only concern is making sure it works with the VoiceXML browser being used. This leads to quicker development and less maintenance when compared to wireless Internet and desktop Web applications.

VoiceXML Architecture
VoiceXML uses an architecture similar to that of Internet applications. The main difference is the requirement for a VoiceXML gateway. Rather than having a Web browser on the mobile device, VoiceXML applications use a voice browser on the voice gateway. The voice browser interprets VoiceXML and then sends the output to the client on a telephone, eliminating the need for any software on the client device. Being based on Internet technology makes voice application development much more approachable than previous voice systems.

Figure shows the architecture of a VoiceXML system and an Internet application. Showing both on the same diagram clearly shows the similarity between the two solutions. As you can see, the VoiceXML application does have some additional complexity when compared to the Internet application. Instead of using the standard request/response mechanism used in Internet applications, the VoiceXML application goes through additional steps on the voice gateway. Let's go through the steps of a sample voice interaction.

Figure: VoiceXML architecture.

Just as Internet users enter a URL to access an application, VoiceXML users dial a telephone number. Once connected, the public switched telephone network (PSTN) or cellular network communicates with the voice gateway. The gateway then forwards the request over HTTP to a Web server that can service the request. On the server, standard server-side technologies such as JSP, ASP, or CGI can be used to generate the VoiceXML content, which is then returned to the voice gateway. On the gateway, a voice browser interprets the VoiceXML code using a voice browser. The content is then spoken to the user over the telephone using prerecorded audio files or digitized speech. If user input is required at any point during the application cycle, it can be entered via either speech or tone input using Dual-Tone Multifrequency (DTMF). This entire process will occur many times during the use of a typical application.

As just stated, the main difference between Internet applications and VoiceXML applications is the use of a voice gateway. It is at this location where the voice browser resides, incorporating many important voice technologies, including Automatic Speech Recognition (ASR), telephony dialog control, DTMF, text-to-speech (TTS) and prerecorded audio playback. According to the VoiceXML 2.0 specification, a VoiceXML platform must support the following functions in order to be complete:

Document acquisition. The voice gateway is responsible for acquiring VoiceXML documents for use within the voice browser. This can be accomplished within the context of another VoiceXML document or by external events, such as receiving a phone call. When issuing an HTTP request to a Web server, the gateway has to identify itself using the User-Agent variable in the HTTP header, providing both the browser name and the version number: "/".

Audio output. Two forms of audio output must be supported: text-to-speech (TTS) and prerecorded audio files. Text-to-speech has to be generated on the fly, based on the VoiceXML content. The resulting digitized speech often sounds robotic, making it difficult to comprehend. This is where prerecorded audio files come into play. Application developers can prerecord the application output to make the voice sound more natural. The audio files can reside on a Web server and be referred to by a universal resource identifier (URI).

Audio input. The voice gateway has to be able to recognize both character and spoken input. The most common form of character input is DTMF. This input type is best suited for entering passwords, such as PIN numbers, or responses to choice menus. Unfortunately, DTMF input is quite limited. It does not work well for entering data that is not numeric, leading to the requirement for speech recognition.

Transfer. The voice gateway has to be capable of making a connection to a third party. This most commonly happens through a communications network, such as the telephone network.

When it comes to speech recognition, the Automatic Speech Recognition (ASR) engine has to be capable of recognizing input dynamically. A user will often speak commands into the telephone, which have to be recognized and acted upon. The set of suitable inputs is called a grammar. This set of data can either be directly incorporated to the VoiceXML document or referenced to an external location by a URI. It is important to provide "tight" grammars so the speech recognition engine can provide accurate speech recognition in noisy environments, such as over a cell phone.

In addition to speech recognition, the gateway also has to be able to record audio input. This capability is useful for applications that require open dictation, such as notes associated with a completed work order.

Why Voice?

2009-11-10T07:27:00.000-08:00

Before looking at the specifics of VoiceXML technology, it's a good idea to first consider the reasons why voice applications are being deployed. Some of the reasons are due to limitations of other application types, while others result from core benefits that voice solutions provide. Let's start with one of the most compelling reasons, accessibility.

There are more than 1 billion telephones in the world. This far exceeds the number of computers with Internet access and dwarfs the number of Internet-enabled mobile devices. Voice applications allow each of those telephones to act as an interface to the enterprise. In addition to universal accessibility, the medium of interaction is also desirable. Voice is the most efficient and preferred user interface for many applications, especially where a visual interface is impractical, such as when driving an automobile.

Cost savings is another factor. Since the users of the application already have access to telephones, there is no additional cost associated with purchasing and maintaining devices. Voice applications are device-independent as well, meaning you do not have to be concerned with developing multiple markup languages for multiple wireless network protocols for multiple devices. Finally, training costs are minimal; users will not have to be trained to use a new device with an unfamiliar user interface.

Voice applications benefit from the characteristics of the telephone, especially mobile phones. Mobile phones are small, inexpensive, easy to operate, and have a long battery life. This makes the phone an ideal platform for portable applications. As capabilities of mobile phones evolve, such as with the addition of location-based services, voice applications will quickly be able to take advantage of this new functionality.

The limitations of current user interfaces also provide reasons for developing voice applications. While WAP is a technology with lots of potential, many early users of WAP-based applications have been frustrated because the display screens are small, and inputting data using a keypad is slow and cumbersome. For devices with more advanced capabilities, such as wireless PDAs, the support for graphics and other rich content types are important features. The ideal solution will involve multimodal access to data. For example, to get weather information, you might speak the city name into the device to have the weather information for that city displayed on-screen of the device.

Voice does not have to be the only means of data access. In most cases, voice is used in conjunction with other application types. You might, for example, already have a smart client application for which you want to provide an easy way to access real-time data without requiring a wireless connection to synchronize the data. Offering a voice solution will provide an effective way to extend your enterprise applications to both existing and new users alike.

Finally, we consider the area where voice applications are used most often. Call centers have been using Interactive Voice Response (IVR) systems for some time. When handling large volumes of calls from people seeking similar sets of information, a voice system can be very effective. An IVR system allows a company to provide better service while reducing costs. Rather than providing limited hours of availability, with long hold times, voice systems can allow for immediate access to data 24 hours a day. In most cases, users can find the information they need without requiring human interaction. Unfortunately, user satisfaction with traditional IVR systems has been low. Rigid menus and slow response times often cause users to hang up or to press 0 to get a human attendant, rather than use the IVR system to its full benefit. This is just one of the many application areas that can be improved by a more flexible voice solution in VoiceXML.

Voice Applications with VoiceXML

2009-11-10T07:21:00.000-08:00

Overview

When building mobile and wireless applications, most corporations do not give adequate consideration to the benefits that a voice interface provides. Voice applications make it possible to extend enterprise data to anyone with a telephone, wireless or otherwise. Unlike the proprietary, inflexible systems of the past, the new wave of voice applications provides an open, robust solution for a variety of business and consumer applications.

The following posts discusse building voice applications using the Voice eXtensible Markup Language, VoiceXML. Unlike other applications described in this blog, VoiceXML provides a voice, rather than visual, interface to enterprise systems. The VoiceXML architecture is very similar to that of Internet applications, with the Web browser replaced by a voice browser, and the handheld device replaced with a telephone. Voice interfaces give true universal access to your applications.

After reviewing the history of VoiceXML, we will examine the VoiceXML architecture and then provide information on building VoiceXML applications. The goal is to give you enough information so that you can make educated decisions as to whether a voice interface is suitable for your enterprise applications. An overview of the VoiceXML language is also given, to enable you to get started building custom solutions.

SyncML Overview

2009-11-09T07:34:00.000-08:00

The way data is synchronized varies dramatically from one vendor to the next. Each implementation has its own proprietary way of exchanging data, sometimes making it difficult for device manufacturers, service providers, and application developers to integrate these solutions. Furthermore, each synchronization solution has support for different protocols, devices, and data types, making the task of data integration an even greater challenge. This is particularly the case when you need to synchronize applications from multiple vendors.

In February 2000, a group of companies, including Ericsson, IBM, Lotus, Motorola, Nokia, Palm, Psion, and Starfish Software, joined forces to create a new industry initiative to develop and promote a single, common data synchronization protocol that could be used throughout the industry. This protocol is called SyncML.

To date, the objectives of SyncML have not yet been realized for enterprise data synchronization. The specification is still relatively new and not many vendors have implemented SyncML-compliant products. This is largely because SyncML is not yet proven for corporate applications. Many of the existing synchronization solutions have proven market success, so there is no need for these vendors to rush to implement new SyncML solutions. The one exception is in the PIM space, the first market targeted by SyncML.

What Is SyncML?

SyncML is a specification for a common data synchronization framework and XML-based format, or representation protocol, for synchronizing data on networked devices. SyncML is designed for use between mobile devices that are intermittently connected to the network and network services that are continuously available on the network. SyncML can also be used for peer-to-peer data synchronization. SyncML is specifically designed to handle the case where the network services and the mobile device store the data they are synchronizing in different formats or use different software systems.

As the definition reveals, SyncML is an XML-based specification for synchronizing all forms of data between remote devices and enterprise systems. Its goal is to provide an industry-standard protocol for synchronizing data between all types of devices, such as PDAs, handheld PCs, smart phones, pagers, and cell phones, over any network protocols, to any data store. To achieve this lofty goal, the SyncML initiative decided to start with personal information management (PIM) synchronization, and then move to other forms of enterprise data.

Why Use SyncML?
The overall benefit of SyncML is that it is an industry initiative aimed at bringing together synchronization technology for many devices, networks, and data sources. Many of the current synchronization solutions use proprietary conduits that are often complex and limited in the data sources they can communicate with. As the number of mobile computing devices increases, and the expectations for access to corporate data grows, the SyncML Initiative hopes to provide enough benefits to make it the leading protocol for data synchronization.

SyncML Target Audiences
Four main groups are expected to benefit from the adoption of SyncML as an industry standard, each in its own specific way:

End users. SyncML promises to provide a single way to synchronize email, calendar, to-do lists, contact lists, as well as corporate application data. This would be a welcome change to the current landscape where different synchronization software is required for each task.

Device manufacturers. For devices that have built-in synchronization capabilities, SyncML offers a protocol that will allow the device to access a broader range of data sources, over any network and transmission technology. This will enable device manufacturers to provide a wider range of features with reduced overhead.

Service providers. Companies in the application-hosting field currently have to limit their offerings due to the numerous forms of synchronization technologies on the market. As it stands now, service providers already have a difficult time managing the few technologies they do support because they all have different requirements for devices, networks, and back-end data sources. SyncML should alleviate these issues by providing a single protocol that will be able to work with a broad range of applications, devices, and networks.

Application developers. Developers want to focus their efforts on technology that is in demand and will result in successful applications. SyncML should provide a single technology that will allow them to build a variety of data-driven applications without having to learn a number of synchronization technologies. This should result in developers being able to build applications that will work on a larger number of devices, over many network protocols.

SyncML Advantages
In addition to the advantages for the specific groups just listed, SyncML provides seven other advantages that should prove to be beneficial in a synchronization solution. Many of the existing synchronization solutions already include many of these advantages, but again, SyncML is attempting to provide them in an industry standardized way:

Designed for wireless and wireline networks. SyncML works over all networks used by mobile devices, including both wireline and wireless networks. Some of the challenges in this effort come from the characteristics of today's wireless networks: high latency, low bandwidth, low reliability, and high costs. To address these issues, SyncML has implemented a robust protocol that uses WBXML, to reduce the data being transferred; uses a single request-response model, to minimize network traffic; and has support for dropped connections during synchronization.

Support for multiple transport protocols. SyncML works over the following leading network protocols: TCP/IP, HTTP, Wireless Session Protocol (WSP), and OBEX (Bluetooth, IrDA). It can also be deployed over SMTP, POP3, IMAP, and proprietary wireless communication protocols. SyncML does not require any additional capabilities that are not addressed by these protocols.

Support for arbitrary data. The capability to support various forms of data is a requirement for any general-purpose synchronization solution. Since SyncML is targeted at providing synchronization for all forms of enterprise data, it has built-in support for the following data formats, and can add new formats if the need arises:

Personal data formats, such as calendars, to-do lists, and contact lists

Collaborative formats, such as email and network news

XML and HTML documents

Relational data

Binary data formats, binary large objects (BLOBS)

Data access for multiple applications. To work effectively with the largest number of possible applications, SyncML is not tied to any specific programming language. It does not make any assumptions about the programming language being used, and will work effectively when a different language is used on the client and the server parts of the application.

Optimized for constrained devices. Since many of today's mobile devices have limited memory and processor capacities, SyncML is designed to work in very constrained environments. By keeping the footprint and processor requirements to a minimum, SyncML-based application should be able to operate on a broad range of devices with varying processors, memory capacities, and operating systems. In addition, the data exchanged using SyncML is in a binary format, reducing memory requirements for storage.

Takes advantage of existing Internet technologies. Since many of today's corporate applications are Web-based, it is important for a synchronization protocol to be able to work with Web technologies. XML has emerged as the preferred way to represent structured data on the Web, so SyncML is XML-based, ensuring easy implementation and quick interoperability testing.

High level of interoperability. SyncML has been designed to work over any network, with any device and any data source. Even though this goal has yet to be realized, SyncML does work very well with highly constrained devices, allowing them to communicate with synchronization servers that are capable of executing complex synchronization logic.

How SyncML Works
As we take a look at how SyncML works, we are going to focus on the guidelines that have been laid out in the specifications, not individual vendor products. Once you have an understanding of the underlying SyncML protocols, you will be able to quickly evaluate vendor offerings to determine if they meet your specific requirements.

Specifically, we will examine the following components of the SyncML specification:

SyncML Representation Protocol

SyncML Synchronization Protocol

SyncML Transport Bindings

The SyncML Representation Protocol specifies a common synchronization frame-work and format that can be used to create different data synchronization models. This protocol is defined by a set of well-defined messages (either XML documents or MIME content type) that are transported between the devices participating in a synchronization procedure. It supports both the request/response and the blind push command structures as data synchronization models.

SyncML synchronization is an exchange of packages; each package contains one or more messages. The SyncML representation protocol specifies the expected result of various synchronization operations, based upon the SyncML synchronization frame-work and associated data synchronization models. In this way, the SyncML representation protocol defines the structure of a SyncML message. Each message within a package contains a single data synchronization operation.

A SyncML message is a well-formed XML document consisting of a header and a body. The header contains metadata, which conveys information about the SyncML message. This metadata may include versioning, session, routing, and security information. The body of the SyncML message contains a list of commands, which allow for inserts, updates, deletes, and other actions to be executed to make the two datasets the same.

Figure shows an example of the SyncML framework; notice the dotted line that defines its boundaries. It is in this framework that the SyncML Representation Protocol is applied. When you look at the overall interactions between the SyncML client and the SyncML server, the SyncML Sync Protocol is used. This protocol is essential for achieving interoperable data synchronization. It defines the protocol for various synchronization procedures, which occur between the SyncML client and the SyncML server in the form of message sequence charts. The SyncML Sync Protocol allows for both one-way and two-way data transfer in a variety of modes. One-way synchronization is an important feature because it allows clients to save time by sending only their changes to the server; clients do not have to receive the server changes at the same time. It also is appropriate where only one set of data has changed, in which case two-way synchronization is not required; by default, only the changed records are synchronized between the client and the server. If the full set of data has to be synchronized, there is a slow-sync mode that will allow this.

Figure: SyncML framework.

Within the SyncML Sync Protocol, two roles are defined: a client and a server. Most of the time, synchronization is initiated by the client application, although some of the always-on networks allow the server to initiate the transfer. Do not be fooled into thinking that the server role within the protocol has to be performed by a powerful server-class machine: Both the client and the server may be mobile devices.

When it comes to the transport layer, SyncML defines a set of transport bindings. These bindings are required to ensure that there will not be any problems using the underlying protocols. The three transport bindings currently supported are HTTP, WSP, and OBEX. Each of these is supported for a reason. HTTP is widely used, and usually is able to pass through corporate firewalls; WSP is a part of WAP, allowing WAP phones to support SyncML; finally, OBEX provides support for short-range connectivity, possibly using Bluetooth, IrDA, or USB.

Now let's see how this works. Figureshows how two applications communicate with each other using SyncML. Application A represents a server application that can synchronize with multiple client applications, such as Application B. The communication between these two applications can occur over any network transport, such as HTTP, WSP, or OBEX. The client application (Application B) uses the Sync Client Agent to access the network and send messages to the server. For this to happen, the client agent communicates with the SyncML Interface (SyncML I/F), which in turn uses the SyncML adapter to send the XML message object. The server (Application A), then receives the message through the Sync Server Agent and manages the entire process using the Sync Engine. All of the Sync Engine's network access and data synchronization operations to and from the client application go through the Sync Client Agent.

This example is at a conceptual level. As vendors bring commercial products to market, these products may not contain all of these concrete components. However, the functionality that is contained in these components will have to be incorporated into their solution in some fashion.

Future of SyncML
The first products to support the SyncML initiative have focused on the synchronization of PIM data such as email, to-do lists, contact lists, and calendar information. Companies like Starfish Software, Pumatech, Synchrologic, and FusionOne have added support for SyncML at this level. There has been some adoption by other SyncML sponsors, including Palm, Symbian, and Nokia; all of which have added SyncML support to their latest device offerings.

In contrast, SyncML has not been widely adopted for enterprise data synchronization. To date, only IBM (a founder of the SyncML initiative) has released SyncML-compliant products. Oracle, Sybase, and Microsoft have all decided to stay with their own synchronization solutions, which are not based on SyncML. These products have been on the market for some time, and it is unlikely that they will support SyncML anytime soon.

It is still too early to tell whether SyncML will become an industry standard. SyncML is currently in a prestandards phase, where it will remain until it gains sufficient momentum and market acceptance to justify its adoption by an international standards body. At this time, more than 700 companies are supporting the SyncML initiative, although many of them are taking a wait-and-see approach. If these companies start to release SyncML-compliant products, we could very well see plug-and-play integration between any device, on any network, and be able to synchronize with any data source.

Synchronization Architectures

2009-11-09T07:22:00.000-08:00

Enterprise data synchronization is not a straightforward task. Being able to communicate with a variety of enterprise systems over wireless and wireline networks to an assortment of client applications requires some flexibility at the architectural level. Considering that there are half a dozen mobile operating systems, with at least that many networks, and even more back-end systems that have to be accessed, the synchronization layer is often one of the most complex components of a complete smart client application.

After you take a look at the most common synchronization architecture, along with common synchronization topologies and data access methodologies, you will have a good foundation from which you can make informed decisions on implementing data synchronization within your mobile solution.

Architecture Overview
Synchronization is most often implemented in a distributed computing architecture with a client layer, a middle-tier layer, and an enterprise data layer. Each layer can be implemented using varying techniques, all aimed at accomplishing the same goal: providing a way to extend enterprise data to a variety of mobile devices.

We are going to take a closer look at each synchronization component and how it contributes to the overall synchronization process.

Figure: Synchronization architecture.

Client
When synchronizing data between an enterprise server and a persistent data store on the client device, a synchronization layer must be present to manage the two-way data communication (see Figure). Ideally, this layer will have a minimal impact on your client application, while still providing a simple, easy-to-use client API for controlling the synchronization process. By implementing a modular, self-contained synchronization layer, you can control the entire synchronization process with little interaction from the client application. In some cases, all that is required from the client is the invocation of the synchronization process; the synchronization layer does everything else from there.

Because so many client devices are on the market, the synchronization client must have support for the leading mobile devices, including laptops, Windows CE devices, Palm OS devices, Symbian OS devices, as well as specialized devices with add-on features such as barcode scanners and other industrial components. Each of these devices can have a different mobile operating system with different network protocol support. The synchronization layer on the client takes care of the network communication from the device back to the synchronization middleware.

Middleware
The synchronization server is where most of the synchronization logic is contained. Figureillustrates the role of the synchronization server in relation to the other components of the synchronization architecture. This server is responsible for communicating with the client application to send and receive required data packets. In order to do this, it has to be able to communicate over a protocol that the client application understands. Most of the time, this protocol is IP-based, and often is HTTP. When the synchronization server receives the data from the client, it then has to execute the synchronization logic to determine how this data is transferred into the enterprise data source.

Many of the advanced synchronization features are implemented within the synchronization server. Some of these features include data subsetting, conflict detection and resolution, data transformation, data compression, and security. All of these features have to be implemented while still maintaining server performance and scalability.

Two common synchronization server implementations exist: as a standalone server application, or as Java servlets running in a servlet engine. Both of these methods have benefits and drawbacks. The standalone synchronization server is convenient because it does not require any additional software to execute. These servers are usually programmed using the C programming language, taking advantage of OS-level calls, leading to enhanced performance. This also means that the server has to be available for the operating system to which you are deploying or you are out of luck. In terms of scalability and availability, the server can either have its own built-in load-balancing and failover mechanisms or use third-party load-balancing solutions, such as the hardware-based systems provided by Cisco systems.

For Java servlet-based synchronization servers, you will need a servlet engine for deployment. Since J2EE application servers are now commonplace in most organizations, this requirement does not usually pose a problem. By using an outside servlet engine, the performance, scalability, and availability of the synchronization server now rely on the capabilities of the application server/servlet engine being used. The same goes for the server operating systems that are supported; that is, as long as the servlet engine works on a given platform, the synchronization servlet should work as well. That said, you should give extra consideration to the synchronization vendor's supported platforms and recommended application servers when deciding which application server and operating system to use.

Enterprise Integration
The final part of a complete synchronization solution is the enterprise integration layer. While this layer is often part of the synchronization server, we are discussing it separately because it provides different functionality. The enterprise integration layer enables you to communicate with various back-end data sources. If you are using a commercial mobile relational database on the client, you will most likely have integration to enterprise relational databases on the server using ODBC, JDBC, or native drivers.

In addition to providing integration to relational databases, you may also require access to other forms of enterprise data, such as ERP systems, CRM systems, or XML data. If this is the case, you will have to look for additional enterprise adapters for the solution you are implementing; or if you have the resources, you can create your own adapter.

Publish/Subscribe Model
One of the most common models of data access being used by synchronization solutions today is the publish/subscribe model, so it is worthwhile to explore how it works.

The publish/subscribe synchronization model is based on the concept of having a master copy of your data, the publisher, and one or more copies of this data, the subscriber(s). The data between the publisher and subscribers is updated periodically to keep the data consistent. The update process, or synchronization, is bidirectional, allowing the publisher to update the subscriber data, and vice versa.

The publisher is responsible for defining which tables (or subsets of those tables) are available for external access. The data sets that are defined as being available are called publications. The application clients that are interested in having access to that information are called subscribers. They define which data they want access to using subscriptions. It is possible to have a number of publications defining the available data. These publications can have parameters, which makes it possible to use different subsets of data for different users. In this way, one publication can be used to send a different subset of data to each subscriber.

Figure shows an example of a field service application's data set. In this diagram, you can see that the publisher has the complete set of master data. This data contains all of the information for each field service representative. In this example, the field service representatives are the subscribers. They require only the subset of the publisher's data that pertains to their territory, so rather than keeping a copy of the entire set of data, they have a subset of data that is based on their individual subscriptions. In this way, you can easily define which data is available for mobile users and which parts of the data needs to be synchronized down to the mobile devices.

Figure: Publish/subscribe data synchronization.

Common Synchronization Configurations
A variety of network and data management configurations are commonly used with enterprise synchronization. Synchronization configurations (or topologies) are arrangements of publisher and subscriber databases that transmit data to one another. The publish/subscribe model of data access supports both peer-to-peer and hierarchical configurations.

The most common of these two is the hierarchical configuration, wherein every database has a single parent database, except for the master enterprise database, which has no parent. A diagram of common hierarchical layouts can be seen in Figure. In this diagram are two hierarchical configurations: the configuration on the right is commonly referred to as a hub-and-spoke configuration. In both cases, hierarchical configurations are good when a publisher needs to publish data to a large number of subscribers, or, in other words, when there are a large number of remote workers who need to have access to the enterprise data. In this configuration, the master database contains all of the changes made by any of the remote databases. Those updates can then be propagated to the other remote databases during their next synchronization.

Figure: Hierarchical database configurations.

Unlike the hierarchical configuration, peer-to-peer configurations do not have a single common enterprise data store. In Figureyou can see that peer-to-peer configurations enable each database to contain the same information, with no single database acting as a central server. In this configuration, you can still use the publish/subscribe model, but the data updates are not going to be propagated to all databases in the configuration. For this reason, peer-to-peer configurations are best suited for situations in which only two systems need to be synchronized, or when it is not important for each remote user to have the updates from all other users. In general, a peer-to-peer configuration is not recommended, because there is no central server responsible for collecting updates from the remote users and propagating those changes to the other users in the system. Other difficulties of peer-to-peer configurations include maintaining data integrity, implementing conflict detection, and programming synchronization logic.

Synchronization Fundamentals

2009-11-09T07:18:00.000-08:00

In the previous post, we learned how persistent data storage enables users to access enterprise data without being connected to a network. Without enterprise synchronization, the data on the devices would quickly become stale, hence unsuitable for many corporate applications. The synchronization process allows you to execute bidirectional updates on the required data. Any changes that have been made on the client device can be transmitted to the server database, and any changes on the server can be transmitted to the client device. In this way, you can keep the data on the client and the server synchronized.

Whether you are synchronizing over wireless networks or a wireline connection, synchronization offers many important benefits over an always-connected solution, namely:

Reduced data transfer over the network, often leading to reduced transmission costs.

Reduced loads on the enterprise server.

Faster data access, because the user does not have to constantly wait for data to download.

Increased control over data availability.

In the following pages, we will take a look at how synchronization works and introduce features you should consider as part of an enterprise synchronization solution.

TYPES OF SYNCHRONIZATION
The term synchronization applies to more than the movement of enterprise data. It is often used to describe the exchange of personal information management (PIM) data and the transfer of application files. This section briefly explains other types of synchronization before we spend the remainder of this post on the synchronization of enterprise data.

PIM Synchronization
One of the first applications that many corporations make available to mobile workers is email. This is often enabled at the same time as contact lists, to-do lists, and calendar entries. The combination of this data is commonly referred to as PIM data. Wireless access to email is often considered the killer application in the mobile world. It is a subject to which everyone can relate, and the benefits of which most people by now take for granted.

The leading PIM applications on the desktop are Microsoft Outlook and Lotus Notes. Both vendors provide mobile access to PIM data via laptops, so users are familiar with accessing this data remotely. When it comes to smaller mobile devices such as PDAs, a PIM synchronization solution is required to provide this functionality. PIM synchronization solutions allow users to have offline access to their personal information and to synchronize any changes made back into the enterprise system, often without requiring a companion PC.

File/Application Synchronization
Within an organization, a variety of applications and other files need to be distributed to mobile users. In the wired world, this information is often made available through use of portable media such as floppy disks or CD-ROMs or by a corporate server or intranet site. Unfortunately, these techniques do not work nearly as well for mobile workers. Many mobile devices do not have support for traditional portable storage media, and the storage that is available is somewhat expensive, making this an impractical means of distribution. Adding to the challenge is the fact that most users are at remote sites, without access to internal corporate systems.

To overcome these challenges, several file and application synchronization products have come to market. These products allow an administrator to deliver these files to remote workers in an automated way; they require no additional effort by the remote user. This means you can deploy and manage files and applications on remote devices, so you can quickly update remote workers with the applications they need. In most cases, this type of synchronization is one-way: Updates are sent from the server to the remote workers; only an acknowledgment receipt comes back.

Data Synchronization
Data synchronization refers to the bidirectional exchange and transformation of data between two separate data stores. For our purposes, these data stores are most often located on the client device and the enterprise server. In many cases, the synchronized data set is only a subset of the enterprise database. The reason for the limitation is twofold: one, because of the limitations of most mobile devices, and, two, because individual mobile users only require data that is relevant to them.

The data transfer itself occurs between the synchronization layer on the client and the synchronization middleware on the server. The server middleware then communicates with the enterprise data source. This is the most common way that smart client applications are given access to corporate data.

Database Development Options

2009-11-09T05:43:00.000-08:00

Now that we have shown some of the benefits of including persistent data storage in your mobile applications, it is time to take a look at the options available for implementing this functionality.

Several factors will influence which method you decide to use. They include the following:

Required features. Read the features listed earlier. Which are important to your particular application? A few key ones are performance, data storage capacity, transactional capabilities, operating system support, and tools integration.

Application complexity. How complex is the application's data structure? Does it require relationships between data sets? What forms of data manipulations are required?

Available resources. Such resources include both financial and development resources. Often a trade-off occurs between the cost and functionality. In addition, consider the internal development and maintenance costs versus the costs of a commercial solution.

Size of deployment. The number of seats being deployed can have a big impact on your decision. The per-seat cost of developing an in-house solution is higher for smaller deployments. At the same time, the development effort can become much more complex when building an in-house solution that has to support a large number of users. Determining the point at which it becomes more cost-effective to build instead of buy has to be determined on an individual basis

Support for standards. Is a proprietary system suitable for your corporate needs, or do you require support for standards such as SQL, ODBC, and JDBC?

Enterprise integration. What kind of enterprise integration is required? Many of the commercial systems come with built-in database synchronization capabilities that will work over a variety of protocols. Does your application require this, or would it be overkill?

As you read the options available, you will want to weigh the pros and cons of each solution against the requirements of your particular application. This decision will have both near-term and long-term consequences, so be sure to dedicate the appropriate effort to it.

Proprietary Storage
All of the leading mobile operating systems include a form of local data storage. These data storage systems are typically flat-file databases with limited features and storage capacity. The interface to these databases is most commonly at the API level. Let us take a look at how data is stored in each of the leading operating systems.

Palm OS
Any kind of persistent data storage on the Palm OS is contained in a flat-file database. This type of data includes both applications as well as user data. Two kinds of database systems are available: record database and resource database. Each is composed of blocks of memory that can contain any application-defined data. The only difference is the size and contents of the header for each of the objects. In general, record databases are used to store application data, such as contact lists. Resource databases are used to store the application code and user interface objects. For our purposes, we are going to concentrate on the record database, since the resource database is mainly used for managing applications, not user-defined data.

As the name indicates, a record database stores records of data. These records are essentially segments of memory that are part of the storage heap of the Palm OS. Each database contains a database header that describes the database, AppInfo and SortInfo blocks, and the record list. Both AppInfo and SortInfo are optional blocks that describe the application information and sorting information, respectively. Figure shows the logical record database layout.

Figure: Logical layout of the record database.

Within the header, various fields describe the database name (which is a 32-byte string), its attributes, the last modified date, the creatorID, the AppInfo, the SortInfo, and many other items. The header ends with a record list, which has its own header, followed by the record entries. Each record entry references the location of the actual data for the record and contains the attribute and ID information for that record.

From a programmer's perspective, the Palm DB is a quick and easy way to add persistent data to an application. To read or write data, the Palm OS provides functions that can be used to convert data into or out of Palm database formats.

When using the Palm database for your applications, keep in mind that it does have some limitations. First, the application programmer is responsible for database creation and maintenance. This means that within your application code you will have to use the Palm OS API to open, close, and access the data in any way. In addition, you will have to manage the code to create new records, access or modify them, or remove records. If you require additional functionality, it will have to be created by the programmer.

Second, the Palm database is a flat-file database, with all the limitations discussed earlier in this post. The main issues are that the Palm database limits the complexity and size of the data storage capabilities and does not have support for transactions. This may not be a factor for simple applications, but it can be a major limitation when representing a portion of an enterprise system on a handheld device.

The final limitation relates to enterprise integration. Palm databases do not come with very robust synchronization capabilities. You can synchronize blocks of data using HotSync, but this capability is often quite limiting in the enterprise space, where a companion PC is not always available and the data integration is often directly to an enterprise RDBMS. In these cases, you are required to write your own data synchronization conduit. This effort will involve creating your own data synchronization layer, which is not a trivial task.

Windows CE
Windows CE contains a built-in database system in the form of its object store API. It is a flat-file database geared at application programmers, to enable them to include persistent data storage in their Windows CE applications. The database is physically located in what is referred to as the object store, a portion of a device's memory allocated by the operating system for persistent storage of files, the Windows CE Registry, and Windows CE databases.

One advantage of this flat-file database is its ease of use. By using the provided API functions, you can add and remove records, search for a particular record, and sort the records based on four different columns. Another helpful feature is the support for timestamps as a data type. This allows the programmer to see if the data has been altered by another application since its last use. The API also includes functions for finding records. These include the FirstEqual, NextEqual, ValueGreater, and ValueSmaller methods, providing conditional search functionality without much extra programming.

Similar to the Palm database, the object store API has some major limitations for more advanced applications. The first is that it can reside only within the device's RAM, meaning it cannot be placed on an auxiliary storage card. This limitation can pose problems for applications that are shipped on PCMCIA or Compact Flash memory cards. In these cases, before the application can run, the database will have to be written to the device's built-in RAM.

Although flat-file databases work well for simple applications or those with mainly static data, they can introduce performance problems for more complex applications. When searching for a specific set of data or attempting to sort data, extra commands and I/O are often required, thereby inhibiting performance. This will become especially noticeable with large data sets.

As with other flat-file solutions, database synchronization with Windows CE object store is also an issue. You are left to develop your own synchronization routines. As discussed in the Palm OS section, this undertaking can require a significant amount of effort to implement.

Symbian OS
The DBMS in the Symbian OS is significantly more advanced than that in either the Palm OS or Windows CE. Rather than using a flat-file database structure, Symbian OS has implemented a relational database. This means you can have multiple tables in the same database, allowing for more complex schemas. In addition to making the storage capabilities more advanced, Symbian has also added data access through a subset of SQL, as well as using C++ APIs. This too provides a more approachable way to interact with the Symbian DBMS.

For most of the common database commands that you will require, such as opening and closing the database, creating tables, creating indexes, and querying data, you have the option of using either SQL or the C++ API. In most cases, the SQL code is more efficient than using the C++ API, with the exception of inserting rows of data. In this case, using the C++ API provides better performance, especially on large amounts of data. Overall, incorporating the built-in DBMS into your applications will require a considerable amount of custom code.

One of the other nice features of the Symbian OS DBMS is the support for transactions. When database changes occur within a transaction, all changes can be undone if something goes wrong during any part of the data manipulation. This is an important feature when you are modifying data in more than one table, ensuring that internal references remain intact.

As with the other built-in databases, the Symbian OS DBMS also has some limitations. For one, the API is only available in C++, limiting access to the other supported programming languages such as Java. This can be a fairly significant limitation as it is expected that Java and other high-level languages will be frequently used for Symbian OS development. Second, even though it is a relational database, it does not offer functionality that is normally found in commercial products. For example, table joins are not supported. This means that you cannot select, insert, or update data from more than one table in a single statement. Finally, there is the synchronization issue: With this database, too, you are required to implement your own synchronization support, which as explained for the Palm OS and Windows CE databases, is a significant challenge.

J2ME
The Mobile Information Device Profile (MIDP) of J2ME provides a persistent storage mechanism called the Record Management System (RMS). The RMS is a set of Java classes for storing and retrieving simple sets of data. The storage takes place in what is called a RecordStore. Each RecordStore consists of a collection of records that are stored in nonvolatile memory, meaning they are persistent. Internally, the data is essentially stored as a byte array.

The MIDP applications that access the RecordStores are called MIDlets. These MIDlets can be grouped together for deployment into MIDlet suites. Each MIDlet suite has its own space for RecordStores; no MIDlet suite is permitted to access other MIDlet suites' RecordStores. That is, there is no mechanism to share RecordStore data between MIDlets in different MIDlet suites. So, if you want to enable more than one MIDlet to access the same set of data, the MIDlets in question have to be in the same suite.

Each RecordStore can be given a name, which is case-sensitive and has a maximum length of 32 Unicode characters. There are not many naming restrictions, other than that two RecordStores within the same suite cannot use the same name. Within the RecordStore, each record is assigned a unique ID. These IDs are managed by the RMS and are autoincremented; thus, the first record will have an ID of 1, the second an ID of 2, and so on.

The application programmer is responsible for managing the RecordStore. There is a set of APIs to open, close, insert, delete, and move through the records. More advanced classes, such as RecordComparator and RecordFilter, allow you to compare two records and filter records, respectively.

As you can see, the MIDP RMS is a very simple data storage mechanism, for limited amounts of data. As a developer, you are responsible for managing the RMS as well as for implementing any synchronization capabilities that may be required.

For other J2ME profiles, commercial database solutions are available. These are discussed later in this post.

Proprietary Storage Summary
The leading mobile operating systems all have a built-in form of persistent data storage. The capabilities of these databases vary, but they all are best suited for simple applications that do not require large amounts of data or have complex data structures. If this is the type of application you are building, then these databases offer you a quick, lowcost way to incorporate data storage into your application. You do not have to worry about licensing fees, because the database is part of the operating environment.

If you are building a more complex application, one that has more demanding data storage requirements, these databases are probably not the best choice. As mentioned before, when the data sets become large, these databases suffer from poor performance. They also do not offer many of the key characteristics that are required for many corporate applications. While they all have low resource requirements, they typically do not provide the security, data integrity, support for transactions, scalability, support for standards, or data synchronization capabilities that many solutions require.

One of the final points to keep in mind about all of these solutions is that they are very specific to the given operating system. If you are planning on deploying your application to multiple operating systems, you will incur additional development and maintenance costs using these solutions, as you are essentially working with a different database for each operating system. Everything about how you store and interact with the data is OS-specific, requiring a significant amount of additional work to port the application to another operating system.

Custom-Coded Databases
If the built-in databases do not meet your needs, you always have the option of creating your own database. In this scenario, you can create as simple or as complex of a database as your application requires. If you are looking for basic storage, but are not interested in the built-in databases due to their proprietary nature, you can create a simple flat-file storage mechanism that can work on many platforms. On the other hand, if you require complex data storage with relational database features, you can hand-code this solution. In most cases, this comes down to a "build versus buy" decision.

Companies face a predicament when they come to the conclusion that the available commercial solutions do not meet their needs for one reason or another. It could be because of cost, features, or because of anticipated performance issues. In any case, they have to make a decision whether building a database in-house will result in longterm benefits. This may not be an easy decision to make.

By building a custom database, you can ensure it has all of the features that you require. If you require a relational format with referential integrity, you can build it into the system. At the same time, to maintain a small footprint, you can omit any extra features that may not be required. When it comes to performance and scalability, the onus is again on you. This is sometimes preferable, as you can ensure that the applications run as expected; that said, development and testing often end up being very timeconsuming. Some of the other database features that you may have to custom-code include indexing capabilities to maintain performance, referential integrity to maintain internal data consistency, data-access APIs or SQL support, memory management, and file management, to name just a few. These features alone are often enough to prevent making an in-house solution feasible.

If you require enterprise data integration, you will have to consider building a synchronization layer into your solution as well. This involves building client-side as well as server-side code that can transfer data between your device and back-end server in such a way that you do not lose any data.

Before you start to build a custom solution, make sure that you are aware of the challenges that lie ahead so you are adequately prepared. It is no secret that building a custom database will require significant resources. This is true not only for the development stage but also for the maintenance stage. Remember, mobile operating systems change constantly. Possibly you will have to port your database to new operating systems and new versions of existing operating systems. Each port requires additional development and testing resources to ensure it operates as expected. These cautions are not meant to dissuade you from creating a custom database but rather to make you aware of the effort that will be required.

Of course, there are times when a custom database makes sense. If you are targeting an operating system that is not widely supported by commercial solutions, it may be the only way to get the functionality you require. If you have very specific data storage requirements, which are not addressed by commercial mobile databases, you may find building a custom solution to be to your advantage. These are just two scenarios for which building an in-house solution is beneficial. Just remember that building and maintaining mobile applications is challenge enough; coupled with adding the database, it becomes more so. So if you are contemplating building a solution in-house, research the solutions that already exist to make sure you use your resources to the maximum.

Commercial Relational Databases
Relational databases not only lead the enterprise database market, they are the clear leaders in the mobile market as well. This is largely due to the fact that many of the mobile offerings are from enterprise database vendors. These companies provide a variety of SQL-based solutions with a wide range of capabilities. Some offer key features such as referential integrity, support for indexes, and transaction support, while others do not. Some have open support for operating systems, synchronization integration, and programming languages, while others are more limited.

The point is, when it comes to mobile database implementations, all commercial databases are not created equal. In this section, we examine the leading vendors, summarizing their offerings to give you a place to start for evaluating which technology is best suited for your mobile applications.

Key Features:

Full-featured Adaptive Server Anywhere (ASA) database for desktop environments and Windows CE

UltraLite deployment for mobile operating systems, providing a relational database with a footprint as small as 50K

Built-in synchronization to any ODBC back-end data source

Strong encryption of both the data stores and communication stream

Summary:

To put more emphasis on its mobile and wireless computing solutions, Sybase launched a new company called iAnywhere Solutions. The flagship product offered by iAnywhere Solutions is SQLAnywhere Studio, which includes a variety of mobile database offerings. This product is the established leader in the mobile database market with 73 percent market share (Gartner Dataquest, December 2002). This lead over the competition is a result of iAnywhere's long-term focused commitment to mobile computing, which has enabled them to develop a set of products that squarely meet the requirements of enterprise customers. In the mobile database arena, three technologies are available: Adaptive Server Anywhere (ASA), UltraLite, and UltraLite Component Suite.

Adaptive Server Anywhere is a high-performance mobile database system that offers complete relational database functionality, including stored procedures, triggers, transaction management, record-level locking, and enterprise data replication. All of this is provided in an easy-to-use package that has a compact footprint (around 3 megabytes on Windows CE environments). This version of iAnywhere's technology is available for a variety of desktop and server platforms, as well as Windows CE.

If you are looking for a more compact solution, iAnywhere Solutions provides the innovative UltraLite deployment option. This technology analyzes the database features that your application requires and automatically generates a customized database containing only those features. You can then link this customized database with your application code to create a single executable for deployment. This reduces the complexity of implementing a mobile database solution. For development, you can use common C/C++ development tools such as eMbedded Visual C++ and Metrowerks CodeWarrior. If you are more interested in Java, iAnywhere also offers a pure Java version of the UltraLite database that allows you to develop with any Java development tool and deploy to any device with a Java VM.

In addition to the application-specific version of UltraLite, iAnywhere Solutions also has a more generic relational database for the same operating systems. This technology is called the UltraLite Component Suite; it provides interfaces for development using AppForge, Visual Basic, ActiveX controls, and Java, in addition to the C++ tools mentioned earlier.

On the synchronization side, iAnywhere Solutions offers its MobiLink synchronization server that provides direct, bidirectional synchronization to any ODBC data source, including Sybase, Oracle, Microsoft, and IBM. The synchronization rules are stored in the back-end database to provide a high level of customization capabilities. Both wireless and wireline protocols are supported for synchronization, including HTTP, TCP/IP, and common conduits such as HotSync and ActiveSync.

For security, iAnywhere provides 128-bit strong encryption of the communication stream as well as the data stores themselves.

With their wide platform support and open synchronization capabilities, the mobile database solutions from iAnywhere Solutions are well suited for companies that require a flexible solution that can integrate with heterogeneous back-end databases.

IBM

IBM incorporates three components in its DB2 Everyplace Enterprise product: a small relational database, a synchronization server, and a tool to develop smart client applications for the Palm Computing Platform and Java. Both native versions and Java versions (through IBM's acquisition of Informix) of the database are available. DB2 Everyplace is a relational database management system with a footprint as small as 150 KB. This RDBMS is composed of the default libraries and the database engine itself. The main goal of DB2 Everyplace it to provide a local data store on the mobile device while attempting to keep many of DB2's enterprise features. Some of the included features are SQL support for adding, deleting, and updating data. Missing is support for transactions, which is notable for many corporate developers. DB2 Everyplace implements a subset of the SQL 99 standard, DB2 Call Level Interface (CLI), Open Database Connectivity (ODBC), and Java Database Connectivity (JDBC).

On the development side, IBM offers its own development tool called Mobile Application Builder for Palm OS and Java applications. Mobile Application Builder offers a graphical rapid application development environment with wizards to aid development. DB2 Everyplace also integrates with Visual Basic, C/C++, and Java development tools.

For synchronization, the DB2 Everyplace Sync Server provides bidirectional synchronization from DB2 Everyplace to DB2 Universal Database. Once the data is in DB2 Universal Database, it can then be transmitted to other ODBC data sources, such as Oracle, Sybase, and Microsoft, by using adapters. The synchronization server is implemented as a Java servlet, so it can be hosted in any servlet engine, although it does work best in IBM's WebSphere application server. Being a Java servlet, the synchronization is HTTP-based, and works for both wireless and wired networks. SyncML is the synchronization protocol used by IBM for its data transfer.

With its broad platform support and small footprint, DB2 Everyplace is well suited for a variety of mobile applications. However, the enterprise integration is somewhat complex in that it requires DB2 Universal Database as an intermediate step before interacting with other data sources, so it may not be ideal for companies that do not currently use DB2 Universal Database.

Oracle

The Oracle9i Lite database is built upon the Oracle9i Database and Oracle9i Application server technology. It provides a lightweight relational database with a feature set aimed at being comparable to the Oracle9i database server. It incorporates other technologies (such as Web-to-Go and Mobile SQL) into a single product. This streamlines the installation and configuration procedures, breaking them into two groups: Oracle9i Lite Mobile Development Kit and Oracle9i Lite Mobile server.

The Mobile Development Kit incorporates a set of tools and APIs, along with sample code, to accelerate the development of Oracle9i Lite database applications on mobile devices. At the core of the product is the Oracle9i Lite database. It is a general-purpose database with support for ODBC and JDBC connectivity on all platforms using common development languages such as C/C++, Visual Basic, Satellite Forms, and Java. For Java development, you can take advantage of Oracle's lightweight JDBC driver from your Java clients, although the Oracle database itself is not written in Java.

As to the Oracle9i Lite footprint, it is considered more of a middleweight than a lightweight database. On Windows CE, for example, the combined memory required for the supporting files and engine is close to 5 MB, and this does not include the database itself. On other platforms, the footprint can be as low as 1 megabyte, which is still not small compared to other offerings on the market. In addition, the installation process and feature set vary from platform to platform, so there is no single solution for all mobile devices.

One of the unique features of Oracle9i Lite is how it manages mobile applications. The Oracle Mobile Server is an extension of the Oracle9i Application Server, making it possible to deploy, manage, and synchronize offline applications from a central console. Rather than having a separate engine for application management, Oracle has incorporated this capability directly into the database. This allows you to synchronize both data and applications from a single console. Unfortunately, the application deployment and management is available only for Win32 clients.

When it comes to synchronization, Oracle does not use standard interfaces such as ODBC or JDBC. This means that you can only synchronize Oracle9i Lite clients with Oracle databases. This is fine if your organization uses Oracle technology exclusively; if not, then you will find the synchronization limiting.

Overall, Oracle9i Lite is a capable mobile database platform best suited for companies with homogeneous Oracle server installations.

Microsoft

The latest offering in the Microsoft SQL Server family is SQL Server CE. This is a scaled-down version of SQL Server aimed at extending enterprise data to offline applications for Windows CE. It has maintained much of the functionality required for mobile solutions, including a wide range of data types and referential integrity. The database footprint varies, but is typically between 1 and 3 MB.

Microsoft SQL Server CE provides a familiar SQL grammar and a consistent development model and API set to the full-blown SQL Server. Development can be accomplished using Visual Studio .NET using the .NET Compact Framework. These tools and technologies allow developers to use their existing skills to build sophisticated Windows CE-based database applications for a wide range of mobile and embedded applications. In addition, Microsoft supports Remote Data Access (RDA) for accessing back-end Microsoft databases in real time without having to configure SQL Server synchronization.

Synchronization is provided over HTTP to Microsoft SQL Server back-end databases via Microsoft Internet Information Server (IIS). Replication can be performed over wired and wireless LANs and WANs. The communication protocol is well suited for wireless transports. Microsoft has also incorporated support for SSL, giving you the ability to encrypt the data stream to protect sensitive data.

Because the Microsoft SQL Server CE solution is targeted directly at Windows CE devices, and synchronizes only to Microsoft SQL Server, it is suitable only for a very specific market. If you are deploying Windows CE devices that only require integration with Microsoft SQL Server, then this solution should meet your requirements, while giving you a familiar development environment.

PointBase

PointBase is the most recent player to enter the mobile relational database market. Its database products are all 100 percent Java, to provide cross-platform development opportunities. There are two versions that will appeal to mobile developers: PointBase Embedded Edition and PointBase Micro Edition. Both are targeted at mobile applications development, but for different versions of the Java platform.

The PointBase Embedded Edition is aimed primarily at J2SE applications that require multiple database connections from within the same JVM. The Micro Edition works in both J2SE and J2ME environments that require only a single database connection. For this edition, the footprint can be as small as 45 KB; however, it is lacking many features that are required for enterprise mobile applications, most notably, synchronization support.

Both versions take advantage of common development tools, such as Metrowerks CodeWarrior for Java, for rapid application development. For deployment, you can use any JVM on the target platform. The Kada Systems' JVM is often used on the Palm OS, while Insignia Jeode is common on Windows CE. For smart phones and Symbian OS devices, you can use the JVM that comes with the device.

The Embedded Edition offers synchronization via PointBase UniSync. UniSync is a middleware server that allows the PointBase clients to synchronize to any JDBCcompliant back-end data source. Even though it is open to many back-end sources, the synchronization is better if you are communicating to the PointBase Server database. In this case, bidirectional, changes-based updates are supported. For other JDBC data sources, only snapshot updates are supported.

PointBase's main strength is its focus on Java. The concept of developing an application once and deploying it to any mobile device with a Java VM is very attractive to corporate developers. Unfortunately, Java on mobile devices is still relatively immature compared to server and desktop platforms, and users may suffer through some growing pains. However, on some of the more capable mobile devices, creating Java applications is a promising alternative.

Reasons for Using a Database

2009-11-08T03:24:00.000-08:00

Database technology is the foundation of many enterprise applications. This is true in the world of e-business, and it is becoming more true in the world of m-business. As corporations continue to develop mobile business applications, the requirement for persistent data on the mobile device becomes increasingly prevalent. Just as databases made the client/server era of computing possible, databases are changing the way companies look at mobile computing. One of the main goals of mobile computing is to extend enterprise data beyond the confines of the enterprise. In doing so, many lessons have been learned, demonstrating how mobile data access for e-business (or m-business) differs from client/server data access. The following are some of the key differences between the two means of data access:

The mobile-device landscape is much more complex. Compared to the choices in the desktop world, there are many different devices, which use a broad range of hardware, operating systems, and user interfaces.

The number of devices and applications that need to be managed in the mobile landscape is increasing. As mobile computing grows, users may use more than one device, and will definitely use many mobile applications. Desktop computers are a known entity. There are not many new hardware systems or radical new applications coming to market.

Mobile users often need to use applications when not connected to a network. One reason is the unreliable nature of the wireless networks, but it can also be credited to the performance and depth that offline applications can provide. Desktop computers typically have reliable, continuous network connectivity, allowing data access to occur over a network without worrying about prolonged downtime.

All of these points lead the conclusion that mobile data storage is an important aspect of mobile applications.

Key Features
Now that we have looked at the types of databases available, as well as some of the key differences of mobile computing, we are in a better position to evaluate the key features that are important in a mobile environment.

Data Storage Properties
The database engine and the technique used for data storage will play a significant role in the database's storage capacity, performance, and scalability. You want to choose a solution that can store a large amount of data, being limited only by the memory available on the device. At the same time, the solution should have fast data access, to ensure that the database does not cause a performance bottleneck. There is often a trade-off between data capacity and performance; in some products, as the data set grows, the performance decreases.

Another important consideration is the support for enterprise class functionality, such as indexes, referential integrity, and, especially, transactions. Choosing a product that has these features will enable you to produce a robust, high-performance solution. The importance of transaction integrity cannot be overemphasized for mission-critical applications. Transaction integrity means that clients can perform database actions within transactions, so if something goes wrong in any part of the transaction, the entire transaction can be undone. This is an important feature when you are modifying data in more than one table, as you can ensure that internal references remain intact. Since your mobile application will not contain the entire schema of your enterprise data source, the database system should provide an easy way to define the required subset of data. Once defined, the synchronization layer should be able to automatically take care of the data mappings. This leaves you with a minimum amount of data on the device and a means of direct synchronization.

Tool Support
Having tools for the development, testing, administration, and deployment of your mobile application will make the development process more efficient. Support for leading development tools and programming languages enables developers to use products that they know. Ideally, for maximum flexibility, the database system will support development of both native and Java applications. Being able to leverage existing tools and programming language skills will dramatically reduce the amount of training required. When it comes to administration and deployment, the database vendor should provide tools that support all of your target operating systems.

Flexible Synchronization
The database solution should provide an integrated synchronization layer. The synchronization must be bidirectional, so that both the client and server data can be updated. At the same time, the amount of data being transferred has to be kept to a minimum. One way to accomplish this is by synchronizing only the net changes. Imagine the case where a data field changes several times between synchronizations. When synchronizing net changes, the only information sent to the enterprise server would be the final value, rather than all of the intermediate values, which could add considerable overhead to the data being transferred. For most applications, receiving only the final value from the synchronization should be sufficient, but for others a complete transaction history might be required. A solution that offers a choice between the net changes and complete transaction history would be ideal.

Mobile applications run on many devices, using many communication protocols. The synchronization capabilities should be able to run over a variety of both wireline and wireless protocols. The system should also support access to enterprise data being stored in the leading enterprise database products.

Administration Requirements
In most mobile environments, technical staff to troubleshoot and resolve problems is not readily available. At the same time, it is unrealistic to expect the end user to take care of troubleshooting tasks. This means that you need to choose a solution that requires zero client administration. To accommodate this requirement, the database must be easy to install, configure, and manage.

When support is required, having remote device support capabilities can be very helpful. Such support may include the ability to remotely control a mobile device and to remotely deploy application updates to the device.

Low Resource Requirements
Because mobile devices have constrained resources, the solution has to be able to run efficiently on handheld devices. The database should be capable of being run on slow processors and provide a small footprint reducing memory usage. Choosing a solution that is modular, giving you only the features required for your application will minimize resource usage. Also note that native applications are often more efficient than Java-based solutions, so native support for your target operating systems can be important.

Operating System/Device Support
At a minimum, the database you choose should be capable of running on the leading operating systems and devices, both during development and deployment. Moreover, because the mobile operating system and device market is changing constantly, you need a solution that can adapt quickly to those changes. At a minimum, the operating systems it supports should include Windows CE, Palm OS, and possibly Symbian OS. You are also advised to choose a database that can run in the emulation environments that you have selected. If it does not, the development process will be much more difficult, because physical devices will be required for all stages of the development cycle.

Standards Support
Probably the developers in your organization have done some database development, meaning they have SQL skills as well as knowledge of ODBC or JDBC. Because these standards are used widely and have a broad level of industry support, the database system you choose would ideally support these standards. Even if you do not have previous database experience, choosing a solution that is standards-based will help you to learn the system faster and gain skills that are transferable to other platforms. In addition, technical resources are more readily available for standard systems than for proprietary ones.

Having a SQL relational database on the client can also ease the integration process with enterprise databases, which are commonly SQL relational as well.

Security
The database system should support security throughout all parts of your application. This includes both authentication and data encryption. To prevent unauthorized users from accessing your confidential data, having built-in authentication is important. This authentication should also carry through to your back-end data source during synchronization.

Two levels of data encryption are required: encryption of the communication stream, and of the data stores themselves. The encryption of the data stream will prevent others from listening in when data is transmitted from the data store to the enterprise database. The encryption of the client data store will ensure that confidential data cannot be viewed on a device that is lost, misplaced, or stolen.

Persistent Storage versus Real-Time Access
An argument can be made that direct real-time access to enterprise data is better suited for enterprise applications than persistent client data storage. This solution would involve having a communication layer within the client application that would go over a wireless network to retrieve data from the enterprise server. In the same way, the business logic could reside on the server as well, removing the need for client-side logic. This would leave the presentation layer on the device, along with a communication layer, allowing for enterprise integration, making the result very similar to wireless Internet applications. In this case, the real-time data access solutions would suffer from some of the limitations that real-time browser-based applications do, namely:

Unavailable or unreliable wireless networks. In many cases, mobile tasks such as sales force and field service applications take place in remote locations, where wireless coverage is either unavailable or unreliable. This is also true of workers for whom physical barriers, such as office buildings, cause interference issues.

Insufficient bandwidth. A significant amount of data is being recorded with data capture applications. With the low bandwidth of today's networks, constantly transmitting data is impractical and costly.

Static data. Much of the data retrieved in mobile applications is relatively static, requiring only periodic updates. Examples include customer contact information or product catalogues. In these cases, it does not make sense to be downloading the information over a wireless network when it can be stored persistently on the device.

Battery life. Communicating over a wireless network requires significantly more battery power than accessing data locally. This is a concern for workers who do not have the ability or time to charge their devices throughout the workday.

For all of these cases, developing a smart client application with persistent data storage and enterprise synchronization is a more practical and cost-efficient solution. In many cases, the data can be synchronized via a wireline network, avoiding the wireless network limitations.

And when real-time data is required, wireless Internet applications appear to be a better choice than creating custom client applications with real-time access. Wireless Internet applications do not require a client to be deployed to the device, plus they can communicate over standard protocols such as WAP and HTTP. Another option is hybrid applications that use local data storage for most of the data access, and wireless Internet access for content that is the most critical or time-sensitive.

Persistent Data on the Client

2009-11-08T03:22:00.000-08:00

The key component of smart client applications is the persistent data store. This is the technology that allows you to maintain data on the device, removing the requirement for wireless network coverage. Beyond allowing you to work offline, persistent data also makes it possible to build applications with rich user interfaces that have high-performance data access, transactional capabilities and enterprise integration support.

You have a variety of options to choose from for data storage: You can use the device's file system to store data, build your own data storage mechanism, or purchase a commercial solution. In this post we are going to take a closer look at some of the reasons why databases are an important component of smart client applications. We will also look at some of the options you have for implementing this type of solution.

Types of Data Storage
Before delving into the requirements for persistent storage within mobile applications, it is worthwhile to step back and take a look at traditional data storage systems. In general, database systems provide a storage mechanism for data. This can be accomplished in a variety of formats, with different storage techniques and relationships between the data. They also provide a means to access that data by using a defined language, like Structured Query Language (SQL), or other proprietary APIs. A complete system that provides the data storage, access mechanism, and administration tools is referred to as a database management system, or DBMS. This is clearly an oversimplified view of what a database is and does, but for our purposes here, it should suffice.

We are going to look at four main database systems: flat-file, relational, object, and XML databases.

Flat-File Databases
The most basic form of database is a flat-file database. This form of database is only able to store data as a single set of records of the same kind. Conceptually, flat-file databases are very similar to a card catalog where each record is kept in a distinct location. For example, a flat-file database might contain a list of contacts, each represented by a string and separated using a common delimiter such as a comma, tab, or other character that is unlikely to be part of the data itself. This type of data storage system is suitable only for the most basic forms of applications that require basic persistent storage, with limited programming capabilities. Since they store data only as a single record, they do not lend themselves to large or complex data sets. If the amount of data becomes too large, performance suffers considerably.

One of the major performance limitations of flat-file systems comes from the lack of tuning and optimizing features that are typically found in relational database models. For example, there is no means of database normalization; that is, there is no way to structure information to reduce redundancy and promote the most efficient use of resources. Normalization is accomplished by using separate tables with foreign and primary keys in the relational database model. In addition, flat-file databases do not allow for joins—retrieving related sets of data based on a common element.

To address some of the performance issues, many flat-file databases provide the ability to designate certain fields as keys, allowing the contents of the field to be indexed. Searches for information in a keyed field are much faster than for those in fields without keys. In a keyed field, the program only has to consult the index to determine which fields meet the search criteria, whereas in nonkeyed fields, every field in the record has to be scanned to achieve the same results.

Flat-file database implementations are rarely found in enterprise applications because of their lack of scalability and poor performance.

Relational Databases
Relational databases have a much more logical structure for storing data than flat-file databases, where you are limited to a single record type. Relational databases allow you to store many records of various data types in a format called a table. Within the table, the data is stored in rows and columns. Each column of data contains elements of the same data type. The table information is related on the basis of a common field (or key), which allows for relationship mapping. In this way it is possible to associate an unlimited number of different record types with one another.

In the late 1970s, Oracle came out with the first relational database; it was soon followed by offerings from IBM and Sybase. Today, relational databases rule the enterprise market. They use SQL for interacting with the database. Using SQL it is possible to perform complex database interactions using simple commands, and it gives users a standards-based way to interact with databases, although it's important to point out that many vendors have extended the SQL standards to create their own proprietary SQL languages.

Over the years, the capabilities offered in relational databases have evolved. The leading vendors such as Oracle, IBM, Sybase, and Microsoft have added the capability to store a wide variety of data types and data processing features, such as support for transactions. These new features are often aimed at making relational databases easier to use for business applications and e-business development. Stored procedures, for example, enable the user to build business logic into the database using either a SQL-based proprietary language or, as of late, using Java. These types of additions make the relational database more attractive than other competing technologies.

In the mobile space, we are seeing many of the enterprise relational database vendors retrofit their enterprise-scale offerings for mobile usage. As well, other vendors have introduced products specifically targeted for mobile use.

Object Databases
Recently, object databases have attempted to challenge relational databases for the enterprise market, but so far have not succeeded. They differ significantly from relational databases in their approach to data storage. This approach is based on the capability to store persistent objects; so, rather than storing tables, as relational databases do, object databases store a variety of persistent objects, which can then be referenced through persistent identifiers (PIDs). PIDs identify the objects and are used to build relationships between them. Instead of using SQL to access and manipulate the objects, common object-oriented (OO) programming languages such as C++ and Java are used.

The first object databases came to market in the early 1990s, more than 10 years after their relational counterparts. Though they have not caught on in the broad enterprise market, they do excel in certain areas. When, for example, you need to be able to store many forms of data, which do not lend themselves to the tabular setup of a relational database, object databases are a good choice. They give you the freedom to create and store any type of information, and provide tight integration with OO programming languages.

Recently, with the proliferation of Web-based applications, object databases are experiencing some surge in popularity because of the many formats of Web content and the requirement for easy access to these data formats. Unfortunately for the object database vendors, the performance overhead and nonstandard design continue to make them unattractive for many business application developers. Whether mobile applications will take advantage of object databases is yet to be determined, but the concept of sending persistent objects, instead of just data, to mobile applications is starting to gain some momentum.

The complete object database system is commonly referred to as an object database management system, or ODBMS. Another term that you may come across for object databases is object-oriented database management system, or OODBMS.

XML Databases
With eXtensible Markup Language (XML) data storage, there are two very different types of databases: one implements XML capabilities on top of another database format; the other uses XML as the storage mechanism itself. It is important to make this distinction, because here, when referring to XML databases, we are referring to the latter. This is because most, if not all, enterprise RDBMS vendors have added some form of XML capabilities to their offerings. These offerings range from the capability to store XML documents in text fields to the capability to interact with the database using XML datagrams. These relational database offerings are not XML databases, as the data storage itself is not XML-based.

The latter type of XML databases, comprise products that have been designed for use with XML from the ground up. They use XML database engines to store large amounts of data, provide concurrent access, and integrated security. The selling feature behind XML databases is that they can interact with XML streams more efficiently than can RDBMS that have XML features, because they do not have the overhead of converting XML to a relational format. In some cases, such as when manipulating an entire document, this can lead to better performance than using an RDBMS. That said, in most cases, storing data in XML formats can be very inefficient, and offers poor performance, due to the lack of indexing capabilities.

Another feature of XML databases is the integration with other XML technologies on mobile devices such as synchronization services, transformation engines, and XML query languages such as XQuery. The premise is that, by having all XML-based technologies on the client device, you should be able to reduce system complexity and cost while increasing the flexibility due to XML's platform independence. Increased flexibility may in fact be possible, but XML databases demand increased processing and storage requirements as well, which are not attractive characteristics for mobile computing.

XML database management systems (XDBMS) are rarely used, in comparison to relational systems, most likely because relational systems are ingrained in most organizations, and not enough compelling reasons exist for moving to a pure XML model at this time.

Mobile Operating Systems

2009-11-08T03:09:00.000-08:00

The mobile operating system (OS) market is vastly different from the desktop operating system market. In the mobile world, there is no clear leader in the operating system space. The Palm OS has a large amount of market share in the consumer space; Windows CE has been very successful in the enterprise market; and the Symbian OS is dominant in the European market. In addition, a following is growing for both Java-based operating systems and Linux.

The operating system is an important aspect of mobile application development. It is one of the main factors that will dictate whether you can develop a smart client application. It also plays a role in the development tools, prepackaged software, and device support that will be available to you. We will take a look at five main operating environments: Windows CE, Palm OS, Symbian OS, Linux, and Java.

Windows CE
Microsoft has made great strides in the Windows CE operating system, both in terms of functionality and usability, as well as in market share. Windows CE .NET, Microsoft's current operating system, delivers the most complete mobile operating system available. Windows CE enables multitasking, allowing the user to work on one application while another is executing in the background. For example, you could be working on PocketWord while synchronizing data in the background. Pocket PC 2002 devices use customized versions of Windows CE, and look as though they will be the market leader for the enterprise market, and possibly the consumer market as well. But the situation was not always so positive for Microsoft.

Back in 1995, when Microsoft released the first version of Windows CE, it had very limited success. Microsoft had just released Windows 95 and had a near monopoly in the desktop operating system market. The Windows CE operating system was designed for Handheld PC devices, which, size-wise, are in between PDAs and laptops. Even though many device manufacturers supported Windows CE, it was given a very cool reception by both the consumer and enterprise markets. It did not look as though Microsoft was going to reproduce its desktop OS success with Windows CE.

Unwilling to concede, in 1998, Microsoft released Windows CE 2.x for the PDA market. At this time, Palm dominated the palm-sized device market. Nevertheless, Microsoft was confident that Windows CE was going to be the "PalmPilot killer." This proved not to be the case. Once again, Windows CE was given a cool reception. Many consumers found the user interface too cluttered and complex. Microsoft found itself in an unfamiliar position, trailing both Palm OS and Symbian OS (at the time called EPOC) in popularity. It had to come up with something better.

Finally, in 2000, Microsoft released a version of Windows CE that garnered some attention. Windows CE 3.0 was released when the PDA market was becoming more attractive to enterprises considering building line-of-business applications. For these applications, corporations were looking for an operating system that would allow them to run existing Windows-based software and to create sophisticated data-driven applications. Windows CE fit that description. Even though the popularity of the Palm OS was at an all-time high, Microsoft made some early penetration into the enterprise market during the year. By 2001, Microsoft found itself in a more familiar position, often being the OS of choice for new business application development.

Why did Windows CE 3.0 succeed? For many reasons. It comes with many familiar applications, including PocketWord, PocketExcel, PocketOutlook, and Pocket Internet Explorer. In addition to its office products, Windows CE also features built-in multi-media capabilities for both audio and video. These capabilities make it easy for existing Windows desktop users to move to the Windows CE operating system. They can maintain the rich level of functionality they are used to, only on a smaller device.

On the development side, Windows CE 3.0 utilizes a scaled-down version of the commonly used Win32 application programming interface (API), allowing developers to quickly refit existing Windows applications for Windows CE 3.0-based devices. This provided the needed link between the Microsoft desktop operating systems and their mobile counterparts. Another major improvement from Windows CE 2.x to 3.0 is enhanced support for real-time functionality made to the OS kernel. This dramatically enhances the performance of Windows CE 3.0 over Windows CE 2.x.

The progression of Windows CE does not end there. At the end of 2001, Microsoft announced another version of the Windows CE family: Windows CE .NET 4.0. This version fits into Microsoft's overall .NET strategy by allowing developers to use the full suite of Microsoft tools, including Visual Basic and Visual C++, for development, as well as updated versions of the Microsoft suite of office products and Internet Explorer. Windows CE .NET also added built-in wireless capabilities, including broad support for WANs, LANs (including 802.11b), and PANs (including Bluetooth).

Pocket PC does not replace Windows CE at all: The former is the hardware device, the latter is the operating system. However, Pocket PC does use Windows CE 3.0 as its underlying operating system. Pocket PC uses a customized version of the Windows CE 3.0 operating system, built by Microsoft and used specifically in Personal Digital Assistants (PDAs) like the Compaq iPaq and the Hewlett-Packard Jornada. While this customized version is only used in PDA-type devices, Windows CE 3.0 can be used in a wide variety of devices including industrial automation, Internet access devices, Web terminals, kiosks, consumer electronics, or retail and point-of-sale devices.

This extract is somewhat dated as the latest versions of PocketPC are now based on Windows CE .NET 4.1, and will soon use Windows CE .NET 4.2.

Even though Windows CE is not the leading mobile operating system, it is definitely a strong platform on which you can build very robust, sophisticated smart client applications. Microsoft has spent the past several years enhancing the early versions of Windows CE to bring consumers the latest Windows CE .NET operating system, which should remain a strong player, if not become the leading mobile operating system.

Palm OS
Palm OS has experienced tremendous success in the PDA market. In the early days of PDAs, Palm established itself as the market leader, capturing nearly 75 percent of the worldwide mobile operating system market by early 2000 (IDC, June 2000). Since then, it has continued to be a dominant player in the market. Lately, however, it has faced some difficult times.

Palm has not had the same level of success in the enterprise market for new application development as it did with consumers. In the early days of PDA application development, many organizations chose Palm OS as a deployment platform because the devices were readily available and many employees were already familiar with them. This situation resulted in a wide range of applications being developed for Palm OS. As the requirements for business applications became more complex, however, Palm OS was found to be unsuitable for many of these tasks. For example, prior to the release of version 5.0, Palm OS had single-tasking capability only; meaning users could perform only one task at a time on the device. Thus, if they wanted to download a file, they had to wait for the download to complete before they could move on to other tasks. Many corporations found this to be a significant limitation. When, with version 5.0, Palm introduced some multi-tasking capabilities to the platform, it improved the usefulness of Palm OS for more complex applications. More enhancements for enterprise applications are also expected in Palm OS 6.0.

It's important to point out that Palm hardware devices and Palm OS used to be considered one and the same. This changed when Palm started licensing Palm OS to third-party device manufacturers. The first licensee was Handspring; many others followed suit, including IBM, Symbol, Kyocera, and Sony. Palm's goal by separating the hardware and software divisions was to maintain the widespread usage of Palm OS while avoiding the same problems Apple confronted as the sole manufacturer of both the hardware and the operating system software for the Macintosh. To date, it looks as though Palm is on the road to success in this regard. Handspring, for example, in 2001, released a device on the market called Treo, which incorporates a phone with wireless modem, Palm OS, email, wireless Internet access, SMS text messaging, and a full thumb keyboard, all in one device. Samsung and Kyocera have similar offerings.

Palm OS 5.0 also includes new features that make it more suitable for enterprise customers. The most significant of these is the move to the ARM series of processors. The result of this move is a significant increase in the overall performance of Palm OS, allowing for the development of more advanced, feature-rich, enterprise-level applications. At the same time, version 5.0 also added the aforementioned multitasking capabilities, additional security for encrypting private data, new expansion slot capabilities, and new wireless capabilities for easier access to the Internet and email systems; it also enhanced the level of color support.

Moreover, the new features of the Palm i705, including wireless support for always-on wireless networks, Bluetooth, and clip-on modems, will make the Palm OS a formidable challenger to Windows CE in the enterprise space. The only concern is that these new capabilities may have come too late; Windows CE had two years to become established before Palm OS delivered these new enterprise-level capabilities. To further distinguish their enterprise offerings, in the fall of 2002, Palm introduced two new product families: Tungsten and Zire. The Tungsten family of products is targeted at the enterprise market, providing powerful solutions for mobile professionals and enterprise work forces; the Zire family is focused on the consumer market, providing affordable options for individuals to organize their schedules and contacts. These new offerings should help Palm regain the momentum it had in 2000/2001.

Reference hardware design, consisting of device hardware, third-party hardware, and the hardware abstraction layer.

Palm OS with embedded system and third-party libraries.

Application software, featuring the applications included with Palm OS, such as the HotSync conduit and third-party applications.

Figure : Palm OS architecture.

Today, Palm OS has a bright future in the PDA marketplace. Even though other mobile operating systems are closing in on its market lead, it will be some time before another operating system overtakes Palm OS in market share. With the release of version 5.0, as well as innovative new devices based on the Palm OS, the market will remain split between the Palm OS and Windows CE in North America, and among the Palm OS, Windows CE, and the Symbian OS in other parts of the world.

Symbian OS
The Symbian gained its popularity in the mobile phone sector; in fact, Symbian is an operating system developed exclusively for mobile devices. As phone capabilities increased, a more functional operating system was required. Proprietary operating systems from the device manufacturers were no longer practical, so a group of the largest cell phone manufacturers, including Nokia, Ericsson, Motorola, and Matsushita, together with Psion, formed a joint venture known as Symbian. The goal of this partnership was to create a standard operating system for smart phones and PDAs based on Psion's EPOC operating system.

In June 1999, EPOC version 5 started shipping. It contained support for devices based on a 640×240 screen resolution, with pen and keyboard capabilities. Since then, versions 6.x and 7.x of the Symbian OS have been released by Symbian. These new implementations, described in turn in the subsequent paragraphs, build upon the core EPOC operating system, while adding new capabilities required for next-generation mobile devices.

Symbian OS version 6.0, which made some radical improvements over the previous version, was released in 2000. The design goal was to bring together various forms of communication protocols, including TCP/IP, WAP, GSM, Bluetooth, IrDA, as well as serial connections, while allowing applications to be presented using C++, Java, WAP, and other Web protocols. By linking the communications protocols and applications, Symbian hoped to achieve close integration of contact information, messaging, browsing, and wireless telephony. In 2002, Symbian OS version 7.0 was released. This version was designed for the unique requirements of advanced 2G, 2.5G, and 3G mobile phones. Some of the key features in this release included over-the-air data synchronization using SyncML; full-strength security using HTTPS, WTLS, and SSL; enhanced multimedia capabilities; support for advanced messaging, including MMS, EMS, and SMS; and a complete suite of application engines for contacts, schedules, Web browsing, and system control. These features make Symbian OS a leading choice for smart phone implementations.

In order to target the full range of mobile devices, there are a range of different platform models that can be used on mobile devices. The original two are the reference designs: Quartz and Crystal. Quartz is targeted at PDA-sized devices(320×240 pixels), while Crystal is targeted for communicator type devices (640×200 pixels). More recently with the release of Symbian OS 7.0, two other user interfaces called called UIQ and Series 60 were introduced. UIQ provides a customizable pen-based user interface for media-rich mobile phones. It was designed to take advantage of the large, touch-sensitive color displays found on 2.5G and 3G handsets. UIQ is targeted for screen sizes ranging from 208×320 to 240×320 pixels, the standard size of most PDAs. The first device that takes advantage of UIQ is the Sony Ericsson P800. The Series 60 platform is developed and licensed by Nokia to a variety of phone manufacturers including Siemens, Panasonic, and Samsung. It is designed for mobile phone users with easy-to-use, one-hand operated handsets that have high-quality color displays, rich communications, and enhanced applications. With these innovative new designs, Symbian OS is making a strong move into the smart phone and PDA markets. To make the job easier for device manufacturers, UIQ and Series 60 come with several built-in applications, including email, SMS and MMS messaging, integrated contact lists and calendars, and high-quality Web page delivery. In addition to providing the operating system platform, Symbian also provides a development kit for developers who are building applications for the Symbian OS. This kit offers a wide range of application development choices. For on-device applications, these include EPOC C++, an efficient and purely object-oriented language that provides full access to all of the platform APIs; and Java, which can run on Symbian's Java runtime, which implements the PersonalJava 3.0 JVM and the JavaPhone 1.0 profiles.

For server-based applications delivered to the device, Symbian OS implements WAP 1.2.1 and HTML 4.01 with full frames, HTTPS, and embedded Java applet support. The Symbian OS also supports GSM, GPRS, EDGE, and CDMA networks and full internationalization support with Unicode and international locales.

Historically, the Symbian OS has been dominant in the European markets, with little exposure in North America. This started to change in March 2002, with Nokia's release of the Communicator 9290 device in North America. It is expected that other vendors will also release Symbian OS devices outside of Europe, making Symbian OS a potential challenger to both Palm OS and Windows CE for enterprise application development.

Linux
Linux is a free UNIX operating system that was initially created by a developer named Linus Torvalds. It is an open source operating system developed under the GNU General Public License, making the source code freely available to anyone who is interested. Current versions of Linux are being implemented by developers around the world who submit updates to the original code. The development effort started in 1991 with version 0.02. In 1994, version 1.0 of the kernel was released. The current full-featured release, version 2.4, was released in late 2002, and is still constantly being updated.

When it comes to mobile devices, many flavors of Linux are available. Most of the device manufacturers supporting Linux will have their own version of the OS. In addition, many commercially available versions of embedded Linux are available. The major implementations of the Linux OS seem to be based on the handhelds.org kernel. Three companies offer Linux operating systems that are compatible with the Compaq iPaq: TransVirtual PocketLinux, Century Software MicroWindows, and TrollTech. The iPaq is not the only device that has Linux support though; other versions of the Linux OS are available for devices from Casio, Hewlett-Packard, Sony, and Sharp.

One of the drawbacks of using Linux is the range of applications available. With a small market share and no official support on many devices, it is a challenge to find the applications and support that is required in the enterprise space. This situation will surely change for the better with the release of more commercial devices.

While Linux is growing in popularity on the server market, it has yet to be shown whether it will have a lasting impact on the mobile operating system market. Judging by the number of delayed Linux PDA offerings, it looks as though Linux will fill a niche spot in the mobile operating system market for Linux enthusiasts.

Java and J2ME
When the Java programming language was initially developed by Sun Microsystems in the early 1990s, it was aimed at the embedded device market. The large number of devices with different chipsets made programming difficult with Assembler or C. The idea behind Java was to design a language that could be ported to different architectures and operating systems without reprogramming. It seemed like an ideal fit for the diverse device market, but device manufacturers were not interested. The result was a language that could run on multiple chipsets with multiple operating systems but that did not generate any interest in its target market.

Fortunately, Sun Microsystems did not give up. With the growing popularity of the World Wide Web, the need for such a language resurfaced. At the time, Internet content consisted of static HTML pages that did not generate much viewer excitement. Missing was dynamic content. But how could it be programmed? What was needed was a language that could be run on a variety of operating systems based on different hardware architectures—seemingly, a perfect fit for Java. Using the Java platform, developers could create little Java applications called applets that could run inside of a Web browser and provide a rich, dynamic user interface for Web applications. The version of the Java platform that provides this interface is the Java 2 Platform Standard Edition (J2SE). Java applets failed to catch on as many expected. The general feeling was that client-side Java applications were too slow and too large to download.

Around that time, Sun Microsystems was also working on a server-side API for Java, now called the Java 2 Platform Enterprise Edition (J2EE). Rather than developing server-side Web applications using proprietary software, developers can use the J2EE specification to develop applications that can be ported to a variety of servers across a variety of operating systems. The Java platform finally found a large audience of companies and developers ready to take advantage of the capabilities offered by the language. As you are probably aware, most of today's application server vendors support the J2EE specification, and many wireless server-side applications are based on J2EE as well.

With the success of the J2EE specification, in 2000, Sun Microsystems decided to give Java another try on mobile devices. This time the company implemented another version of Java called the Java 2 Platform, Micro Edition (J2ME). J2ME targets the embedded and consumer device space, which ranges from Java Smart Cards to set-top boxes and smart appliances. Java smart phones and PDAs are included in that range. J2ME applications maintain the same core features of J2SE and J2EE: code portability, cross-platform support, along with the Java programming language. In addition, J2ME applications are upwardly scalable, to work with J2SE and J2EE platforms.

That said, it's important to point out that the J2ME architecture is somewhat different from J2SE and J2EE as it incorporates a few new concepts. J2ME is based around configurations and profiles. A configuration consists of a Java Virtual Machine (JVM), core libraries, standard classes, and APIs. Two configurations exist for J2ME today: Connected Limited Device Configuration (CLDC) and Connected Device Configuration (CDC). Each is designed for a set of devices with varying capabilities. The configuration provides the lowest common denominator set of classes and the building blocks on which profiles are created. A profile sits on top of a configuration and provides a complete set of APIs for a narrower set of devices. The combination of a configuration and a profile results in a complete J2ME platform.

The CLDC is based on the K Virtual Machine (KVM) and associated libraries. It is targeted at highly constrained devices with either 16- or 32-bit CPUs and less than 512 KB of total memory available for applications. The current profiles for CLDC include the Mobile Information Device Profile (MIDP) and the PDA Profile. Devices that fit into this category include smart phones, two-way pagers, and low-end PDAs.

For devices with more robust resources, the CDC is the configuration of choice. These devices typically run on 32-bit processors and have over 2 MB of memory available for applications. The base profile for the CDC is the Foundation Profile. On top of the Foundation Profile is the Personal Basis Profile and the Personal Profile. The relationship between these profiles is somewhat unique. The Personal Basis Profile actually includes the Foundation Profile and is a subset of the Personal Profile. The Personal Profile provides a similar level of client support to J2SE, but has a smaller footprint. The relationship between the J2ME configurations and profiles is shown in Figure.

Figure: J2ME architecture.

Java is listed in the operating system section because you can create smart client applications using Java technology and deploy them to any operating system that has a JVM, which includes all the OSes listed previously. This means that rather than developing a native application that will work only on the targeted operating system, you can develop your application using Java and be able to target a variety of operating systems without having to rewrite the application. It sounds like the ideal solution. However, it is important to keep in mind that J2ME still suffers from some of the same problems experienced over five years ago with the Java on desktop clients; specifically, performance is not always adequate and the portability is not 100 percent. For most applications, extensive testing is required for each platform to which the application will be deployed.

As device manufacturers continue to add more capabilities to handheld devices, thus increasing their performance, it is expected that Java technology will become a viable option for creating sophisticated, data-driven smart client applications.

Proprietary Operating Systems
Before mobile operating systems were readily available, many manufacturers relied on proprietary operating systems for their devices. A proprietary operating system is defined as one that is only used, and available for use, by the device manufacturers themselves. Some examples include the RIM OS, used on the Research In Motion Black-Berry devices, and the Wysdom OS that Motorola used in its TimePort two-way pagers.

The use of proprietary operating systems is becoming quite rare, as it prevents large-scale development. For this reason, both RIM and Motorola have adopted J2ME as the development platform of choice for their most recent devices.

Smart Client Architecture

2009-11-08T02:55:00.000-08:00

By now you are probably aware that smart client applications differ significantly from thin client, browser-based wireless solutions. As a general rule, smart client applications enable the user to access data when disconnected from the network. There are many ways that this can be accomplished, but for the purposes of this section, we are going to focus on building applications that incorporate a persistent data store, rather than just using simple caching mechanisms.

The smart client architecture is illustrated in Figure. On the client, you have the user interface, the business logic, as well as a persistent data store. This application communicates with a back-end data source, often through an intermediate synchronization server. The communication stream itself can run either wirelessly or over a wireline connection. Depending on the technology being used, the connection may require an IP-based network or an additional communication layer for the synchronization process.

Figure: Smart client architecture.

When this type of solution is implemented, it quickly becomes clear why it is called a smart client solution. By deploying an application to the device itself, you have the ability to give the client application some "smarts," or logic. This logic dictates many aspects of the application. It determines where the application gets it data from (either locally or from a round-trip to the server), how the data is presented and stored, as well as the set of data that needs to be communicated back to the enterprise systems via a synchronization process. In the wireless space, the impact of having business logic on the device is often overlooked as many vendors and developers focus on low-level technical features of a solution rather than satisfying the requirements of the mobile user.

The Client
Smart client applications provide many attractive features for end users. Many of these features reside in the client application itself. By providing a rich user interface with persistent data storage, smart client applications are suitable for a large variety of corporate applications. We are going to take a closer look at each of the components that comprise the client of smart client applications.

User Interface
Initially, the user interface may not seem important when developing mobile applications, as most people feel that there is always going to be a trade-off between size and usability. But this trade-off does not always have to take place. Smart client applications can have very sophisticated user interfaces. In most cases, they are programmed using development tools that have extensive component frameworks. Incorporating tables, drop-down lists, radio buttons, and graphs are straightforward operations. Contrast this with the capabilities available for most wireless Internet applications, where the user interface is often text-based with limited support for graphical components.

Whether you are developing for the Palm OS, Windows CE, Symbian OS, or a Java-based system, you will find that user interface development is a very important part of a successful application. When the screen size is limited, as it is for handheld devices, the developer must take full advantage of the space that is available. In addition, putting special focus on the navigation through an application is essential. Mobile application users are often the same people who have been using advanced Windows-based application for years; hence, they have certain usability expectations that need to be met. One of the main reasons given by consumers for their slow acceptance of wireless applications is the complexity of the available solutions. This complexity is usually due to poor application design, rather than technical limitations. Obtaining end-user feedback during the development phase via a prototype can help you address usability concerns at an early stage in the application development process. In the Mobile Operating Systems section later in this post, we will take a look at the most popular mobile operating systems and review the types of applications that each operating system can support.

Data Storage
When you look at the requirements of typical mobile enterprise customers, you see some trends emerge. First and foremost, data access is a requirement. Users do not really care how the data is retrieved; they care only about its availability. Theoretically, they understand that wireless access is not pervasive; nevertheless, they quickly become frustrated if they can access their data only periodically, depending on the network coverage and/or penetration. By providing data storage capabilities on the device, you can ensure that users will be able to access important data when they need it.

Performance
In addition to providing timely data access, smart client applications also provide performance benefits. Consider how computer technicians work: They travel from location to location repairing a variety of computer systems. As often as possible they carry some inventory with them for common repairs; but just as often, they need to order a special part from the warehouse and schedule a follow-up visit. Before they can schedule the next visit, they have to make sure that the part in question will be available at a time that fits into their schedule. By utilizing a smart client application that contains a persistent data store, technicians can have immediate access to inventory information, as well as their schedule. Imagine if they had to search a database for a specific part number. This task could take a considerable amount of time if a wireless browser-based application were being used. The task could even be impossible if a technician happened to be at a location that was outside of the wireless network's coverage. By implementing a mobile data store, technicians can perform a quick search of the inventory right on the device to provide them with the information that they require.

The one concern with this approach is data freshness. If the data on the device is not updated regularly, then the technician may end up, for example, believing that a part is available, when in fact it is out of stock, leading him or her to make decisions based on inaccurate data. This leads to the data synchronization aspect of smart client applications.

Data Synchronization
In most smart client architectures, the majority of the data synchronization work is executed, not on the client, but on a synchronization server. Nevertheless, the client application is still required to have a certain amount of synchronization knowledge. Minimally, the client has to know the location of the synchronization server, details about the communication stream to the server, what data has to be synchronized, and how to handle incoming data from the server.

If you are developing the synchronization layer yourself, you will have to keep these issues in mind when designing the application. If you are going to use commercially available software, most vendors provide a synchronization client module that incorporates the required functionality with various levels of sophistication.

Messaging
Smart client applications can also take advantage of intelligent application-to-application messaging systems to communicate data. To do so, a client component has to be able to both send and receive these messages. When receiving a message, it has to be smart enough to relay the information appropriately. This communication may involve notifying the user directly or, possibly, updating a set of the data in the client data store. Application-to-application messaging can be important for applications that require frequent communication with enterprise systems.

The Server
Though the server component of smart client applications is invisible to the end user, it is still very important. The server component is responsible for data synchronization, data storage, and messaging.

Data Synchronization
When we refer to data synchronization, we are talking about how enterprise data is moved from the back-end enterprise system to the mobile device, and vice versa. This data movement can be accomplished in a number of ways, depending on the solution that is chosen. For a general overview, we will look only at the major components that are required in a synchronization server, as shown in Figure. These components include the interface to the client application, the synchronization logic, and the integration layer to the back-end data source.

Figure: Synchronization architecture.
Data can be sent between the client application and the synchronization server in a variety of formats. Transferring data over a wired connection is a fairly straightforward process. Transferring it over a wireless network can be a different story. Depending on the requirements of the synchronization software, some wireless networks may work better than others, and some may not work at all.

If you are developing an in-house solution, you may choose to create a proprietary data stream format, possibly basing it on XML, or you may decide to use an industry-specified format such as SyncML. The same options are available in commercial synchronization software. In both cases, a stream of data is being transferred that both the client and the server know how to decipher. When the server receives data, it needs to know how to process it. This capability involves understanding the data layout of the enterprise data source. In the most basic form, the synchronization logic will simply take the updates and apply them to the data store, without considering whether they should be applied or not. In more complex cases, the synchronization logic will perform a variety of duties, including conflict detection and resolution.

The integration with the back-end data source is often a simple process, using Open Database Connectivity (ODBC) or Java Database Connectivity (JDBC) drivers for direct database access. At the same time, integration can be difficult, requiring complex logic to interface with more complicated systems such as Enterprise Resource Planning (ERP) systems. In either case, providing the ability to access enterprise data is critical for an enterprise synchronization solution. Rarely does a company use only one enterprise data storage mechanism, so, ideally, the synchronization server will be flexible enough to integrate with a variety of back-end sources.

Enterprise Data Source
The final part of the smart client solution is the enterprise data itself. This data will vary in formats ranging from enterprise databases from vendors, such as Oracle, Sybase, Microsoft, or IBM, to flat-file systems and everything in between. For the more common storage systems, you should be able to find a driver or adapter that will provide an integration layer for your synchronization server. If you are using something that is uncommon or something developed in-house, you will most likely have to develop this integration layer yourself.

Keep in mind that one of the most common reasons for implementing a mobile solution is to provide enterprise data access to the mobile worker, so the enterprise integration is an essential part of the overall solution.

Messaging
The term messaging can be used to describe many different types of systems. Depending on whom you are talking to and the type of system being discussed, messaging can mean email, paging, SMS, voice, text, data, or a variety of other things. For the purpose of this section on smart client applications, messaging will be referred to in the context of application-to-application messaging with store-and-forward capabilities.

As seen in Figure, the basic form of smart client messaging is composed of a message queue on the client and another queue on the server. These message queues allow you to communicate with messaging system without a wireless network connection. When a message is sent from the server, it is simply placed in the queue that corresponds to a particular client alias. When the client matching that alias connects to the server, the messages in the server-side queue are sent to the client. In the same way, when a client sends a message to the server, it goes into a queue on the client device. When the client connects to the server, the messages from the client queue are sent to the server. This is commonly called store-and-forward messaging, since messages are stored when a connection is not available and forwarded when the connection becomes available.

Figure: Store-and-forward messaging.

When building smart client applications you have three options:

Create a client that uses a persistent data store and synchronization.

Create a client that uses store-and-forward messaging.

Create a client that combines both a persistent data store and store-and-forward messaging.

Depending on the type of solution being implemented, any one of these three options may meet your needs.

Smart Client Security

2009-11-06T06:05:00.000-08:00

The smart client architecture does not depend on a gateway for protocol conversion, so it does not suffer from the WAP gap. However, these applications do have security issues that must be addressed. Anytime data is available outside of corporate firewalls, security mechanisms are required to protect sensitive information. With a smart client architecture, it is possible to provide end-to-end security for your enterprise data. This goes beyond what is currently capable with many thin client solutions.

The main areas of security concern for smart client applications include user authentication, encryption of the client data store, and transport-level security. We will take a look at each of these in turn.

User Authentication
Smart client applications store data directly on the device, much like a client server desktop application does on a PC. To restrict access to this data, user authentication is required. A username/password combination is the minimal level of authentication that should be implemented. The password used should not be stored anywhere on the device, as this would jeopardize the system security. Commonly, this form of authentication is implemented as a check between a userid/password stored within the data store against the userid/password typed in by the user. This usually results in a machine-code jump if the comparison is successful, and, unfortunately, this kind of application can be hacked to always jump, thereby giving the hacker access to the data whenever he or she uses a cracked application. For a better implementation, refer to the Data Store Security section, which follows.

However you implement user authentication to the device and its data, it should not automatically authenticate the user to the enterprise server's data. At this level, a second form of authentication should be implemented, usually one more sophisticated, such as a VPN or digital certificate. In this way, an enterprise can minimize the amount of data that can be accessed by unauthorized users. They will be able to view the small amount of data stored locally, but be unable to update or retrieve any of the enterprise data.

It is also a good idea to take advantage of the security offering of the mobile operating system. All of the leading operating systems provide a mechanism to lock the machine, requiring users to be authenticated before they can gain any device access at all. This would provide a third layer of authentication and serve as a deterrent for someone who may find a lost device.

Data Store Security
With smart client applications, corporate data is stored locally on mobile devices. This data requires protection from unauthorized access, just as other parts of a mobile solution do. In many cases, requiring users to be authenticated before accessing the data is one step to securing this data. Another step is to encrypt the data store itself, making it impossible to view without providing the proper identification, ideally in the form of a digital certificate.

Implementing both authentication and encryption in a single process is the best way to ensure the data remains confidential. The data store can be encrypted using the password as the seed to a symmetric key algorithm. In this way there is no single check to gain access to the application, as all data being returned from the data store will be decrypted using the password.

The encryption should be strong enough so it cannot be easily broken; 128-bit security is not uncommon. This high level of security comes at a price, however: Every time data is added or retrieved, it has to go through the encryption algorithm. This could potentially have a significant negative impact on performance, especially on devices with limited computing power. Also, if for some reason the encryption key is lost, there is no way to access the data without breaking the key, which is computationally infeasible.

If the performance penalty of strong encryption is deemed to be too high, a weaker form of protection, such as data obfuscation, could be used. Obfuscation can scramble the data so it is not viewable by a text-viewing tool. It does, however, not provide nearly the level of security that strong encryption does, but it may be enough for some types of data. Obfuscation has little or no impact on overall performance.

The leading mobile database vendors, including iAnywhere Solutions, provide built-in encryption technologies for their products. If another form of data storage is being used, such as Palm DB or a custom solution, the developer should ensure that data encryption is implemented in the solution. Many of the mobile operating systems provide cryptography libraries to help with this process.

Transport-Level Security
At the transport level, data encryption is required to secure the enterprise data being synchronized. Whether you are using a packaged synchronization solution or building one in-house, the synchronization may be the most important part of the application to secure. Fortunately, there are many encryption products available to provide this security. Companies including Certicom and RSA provide products that can be used to encrypt nearly any type of data being transferred to and from mobile devices. Many of the smart client application vendors include 128-bit data encryption with their solutions. In this way, you can be ensured that the data being transferred over public networks is private from the time it leaves the device to the time it reaches the enterprise server.

Along with encryption, using a strong form of authentication, such as digital certificates, is recommended. In addition, try to keep the firewall around your corporate data as secure as possible; don't open any ports that are not absolutely required by your synchronization server.

WAP Security

2009-11-06T06:02:00.000-08:00

The Wireless Application Protocol, or WAP, has been widely criticized by the media and corporations alike for its security shortcomings. What are the security issues with WAP? How can organizations overcome them? This section attempts to answer those questions, by explaining where WAP excels and where it falls short. After we examine the security model of WAP 1.x, we will look at the improvements made in WAP 2.x.

In the WAP 1.x security architecture, two aspects of security need to be addressed:

Transport-level security. This aspect deals with the communication between the client applications and the enterprise servers. This involves two protocols: WTLS is used over the air, while SSL or TLS is used over the wire. This change in protocols is the basis of the major WAP security problem.

Application-level security. This aspect deals with the security of the client application. This involves digital signatures and encryption.

Together, these two security areas will address the security concerns that are typical in any security model, including authentication, data integrity, confidentiality, authorization, and nonrepudiation.

Transport-Level Security
Transport-level security, also known as channel security, deals with the point-to-point communication between a wireless client and the enterprise data source. This involves communication over both wireless and wireline channels. With WAP, data is encrypted during over-the-air transport using Wireless Transport Layer Security (WTLS) protocol, and over-the-wire transport using Internet security protocols such as SSL and TLS. This discrepancy leads to one of the main WAP security issues. But before we discuss that topic, we will examine the features of WTLS.

WTLS
Wireless Transport Layer Security (WTLS) protocol was developed to address the unique characteristics of wireless networks, namely low bandwidth and high latency. It is a variation of the Transport Layer Security (TLS) protocol, which is the IETF standard for security on Internet. Unfortunately, TLS cannot be used directly because it is not efficient enough for a wireless environment. WTLS improved on the efficiency of the protocol while adding new capabilities aimed at wireless users. The following are some of the major features added to WTLS, which are not in TLS:

Support for other cryptographic algorithms. SSL and TLS primarily use RSA encryption. WTLS supports RSA, Diffie-Hellman (DH), and Elliptic Curve Cryptography (ECC).

Definition of a new compact public key certificate, WTLS certificates. These are a more efficient version of X.509 certificates.

UDP datagram support. This impacts many areas of the protocol, from how data is encrypted to extra support for message handling, to ensure messages do not get lost, duplicated, or delivered out of order.

A key refresh option. This is renegotiated periodically, based on the number of messages sent.

An expanded set of alerts. This adds clarity for error handling.

Optimized handshakes. This reduces the number of round-trips required in high-latency networks.

In addition to these changes, WTLS also introduced three levels of authentication between the client and the gateway. They are listed in ascending order:

Class I WTLS. Anonymous interactions between the client and WAP gateway; no authentication takes place.

Class II WTLS. The server authenticates itself to the client using WTLS certificates.

Class III WTLS. Both the client and the WAP gateway authenticate to each other. This is the form of authentication used with smartcards. GSM Subscriber Identity Modules (SIM), for example, can store authentication details on the device for two-way authentication.

The WAP Gap
Unfortunately, at the same time WTLS improved on TLS for wireless communication, it also caused a major problem: Now that both TLS and WTLS are required within the WAP architecture, there is a point at which a translation between the two protocols occurs. It is from this point, not from the WTLS protocol itself, that the security issues arise. The translation occurs on the WAP gateway: From the client device to the WAP gateway, WTLS is used; from the gateway to the enterprise server, TLS is used. At this point, the WTLS content is decrypted and then reencrypted using TLS. The content exists as plaintext while this transfer takes place, creating the so-called WAP gap. Keep in mind that the amount of time that the content is unencrypted is minimal, and that the WAP gateway is not in the public domain, so there is still security in place. However, for many corporations, this risk is still too great, as it presents a vulnerable point in the network, preventing end-to-end security.

There are two options for alleviating the WAP gap:

Accept that the gateway is a vulnerable point and make every effort to protect it using firewalls, monitoring equipment, and a stringent security policy.

Move the WAP gateway within your corporate firewall and manage it yourself.

Choosing between these two options is a business decision that will depend on the individual enterprise. It is a trade-off between the extra resources required to maintain a WAP gateway and the potential security threat to corporate data. Fortunately, a solution is available, in the form of WAP 2.x.

WAP 2.x
There are many new features in WAP 2.0, but none is as important as the move to standard Internet protocols. This move to using HTTP, TCP, and IP allows the TLS protocol to be used for data communication, thereby removing the need for WTLS. Once a single protocol can be used from the client device to the enterprise server, WAP can enable true end-to-end security, making the WAP gap a thing of the past. Suffice to say, this is a major change in the WAP, and it will take some time for wireless carriers to move to WAP 2.x gateways. Nevertheless, it provides new life for WAP in the wireless Internet space.

Application-Level Security
With so much attention given to the WAP gap and transport-level security, developers often forget about application-level security altogether. Application-level security is important for two main reasons: (1) when security is required past the endpoints of transport-level security, and (2) when presentation content needs to be accessed but enterprise data does not. This can happen during transcoding, that is, when another markup language (often HTML) is being transformed into WML.

The first scenario can be addressed using the techniques provided in the WML specification. In general, the default settings are set to the highest security, but the following are a few things to keep an eye on:

Any WML card that requests access to sensitive data should set sendreferer=true in the element.

The script that handles requests for sensitive information should check the URL specified by the REFERER header HTTP request to make sure that requests being handled are from friendly domains.

Use HTTPS and require basic authentication. Relying on the phone's identity alone is not sufficient.

The second scenario can be addressed using WMLScript and the Crypto API. Using this signText function in the API, digital signatures can be created, opening the door for wireless PKI to manage and issue public key certificates. This technology allows for end-to-end encryption between the content provider (usually the enterprise) and the client.

Security Primer

2009-11-06T05:50:00.000-08:00

Before discussing the security issues surrounding enterprise applications, we are going to take a look at some security concepts and technologies. We will begin by looking at the major components involved in creating a secure environment, followed by the leading security threats that you need to be aware of. The last part of this primer covers the leading security technologies and other security measures that you will want to consider in your solutions.

Creating a Secure Environment
For end-to-end security you have to consider the entire environment, including enterprise access, middle-tier components, and client applications. End-to-end security means that the transmission of data is secure along the entire path from the sender to the receiver—usually the client application to the enterprise server. Contrary to popular belief, this endeavor involves more than just data encryption. In this post we examine five objectives involved in creating a secure mobile environment. Understanding these objectives and the impact they have on mobile application development is crucial for creating secure applications.

Authentication
Authentication is the process of proving that people and organizations are who or what they claim to be. For wireless networks, this is often done at two layers: the network layer and the application layer. The network requires the user to be authenticated before that person is granted access. This can be done implicitly, based on the device or modem being used, or explicitly, using a variety of mechanisms. At the application layer, authentication is important at two levels: the client and the enterprise server. To gain access to enterprise data, the client has to prove to the server that it is what it says it is. At the same time, before a client allows an outside server to connect to it—for example, to push some content—the server has to authenticate itself to the client application. The simplest, and probably least secure, method of authentication is a username/password combination. More advanced methods include digital certificates or digital signatures.

Data Integrity
Data integrity is assurance that the data in question has not been altered or corrupted in any way during the transmission from the sender to the receiver. This can be accomplished by using data encryption in combination with a cryptographic checksum or Message Authentication Code (MAC). This information is encoded into the message itself by applying an algorithm to the message. When recipients receive the message, they compute the MAC and compare it with the MAC encoded in the message to see if the codes are the same. If they are, recipients can be confident that the message has not been tampered with. If the codes are different, recipients can discard the data as inaccurate.

Confidentiality
Confidentiality is one of the most important aspects of security, and certainly the most talked about. Confidentiality is about maintaining data privacy, making sure it cannot be viewed by unwanted parties. Most often, when people are worried about the security of a system, they are concerned that sensitive information, such as a credit card number or health records, can be viewed by parties with malicious intent. The most common way of preventing this intrusion is by encrypting the data. This process involves encoding the content of a message into a form that is unreadable by anyone other than the intended recipient.

Authorization
Authorization is the process of determining the user's level of access—whether a user has the right to perform certain actions. Authorization is often closely tied to authentication. Once a user is authenticated, the system can determine what that party is permitted to do. Access control lists (ACLs) are often used to help determine this. For example, all users may have read-only access to a set of data, while the administrator, or another trusted source, may also have write access to the data.

Nonrepudiation
Nonrepudiation is about making parties accountable for transactions in which they have participated. It involves identifying the parties in such a way that they cannot at a later time deny their involvement in the transaction. In essence, it means that both the sender and the recipient of a message can prove to a third party that the sender did indeed send the message and the recipient received the identical message. To accomplish this, each transaction has to be signed with a digital signature that can be verified and time-stamped by a trusted third party.

Security Threats
Building a secure solution is difficult without awareness of the potential risks, so now that we have looked at the requirements for a secure environment, we will look at four common security threats: spoofing, sniffing, tampering, and theft. Whenever data is being transferred, whether over a wireless or wired network, you need to take precautions against these risks.

Spoofing
Spoofing is the attempt by a party to gain unauthorized access to an application or system by pretending to be someone he or she is not. If the spoofer gains access, he or she can then create fake responses to messages in an attempt to gain further knowledge and access to other parts of the system. Spoofing is a major problem for Internet security, hence, wireless Internet security because a spoofer can make application users believe that they are communicating with a trusted source, such as their bank, when in reality they are communicating with an attacker machine. Unknowingly, users often provide additional information that is useful to the attacker to gain access to other parts and other users of the system.

The process of sniffing, described next, is often used in conjunction with spoofing to get enough information to access the system in the first place. For this reason, implementing both authentication and encryption is required to combat spoofing.

Sniffing
Sniffing is a technique used to monitor data flow on a network. While sniffing can be used for proper purposes, it is more commonly associated with the unauthorized copying of network data. In this sense, sniffing is essentially electronic eavesdropping. By "listening" to network data, unauthorized parties are able to obtain sensitive information that will allow them to do further damage to the application users, the enterprise systems, or both.

Sniffing is dangerous because it is both simple to do and difficult to detect. Moreover, sniffing tools are easy to obtain and configure. In fact, Ethernet sniffing tools come with the Microsoft Windows NT and 2000 installs; fortunately, these tools are simple to detect. To combat the more sophisticated sniffing tools, data encryption is the best defense. If an unauthorized user is able to access encrypted data, he or she will lack a way to decrypt it, essentially making it useless. That said, you must ensure that the encryption protocol you are using is nearly impossible to break. Many wireless LAN users have discovered the hard way that Wired Equivalent Privacy (WEP) encryption is often not enough to protect their data.

Tampering
Data tampering, also called an integrity threat, involves the malicious modification of data from its original form. Very often this involves intercepting a data transmission, although it also can happen to data stored on a server or client device. The modified data is then passed off as the original. Employing data encryption, authentication, and authorization are ways to combat data tampering.

Theft
Device theft is a problem inherent in mobile computing. Not only do you lose the device itself but also any confidential data that may reside on this device. This can be a serious threat for smart client applications, as they contain persistent data, often confidential in nature. For this reason, you should follow these rules when it comes to securing mobile devices:

Lock down devices with a username/password combination to prevent easy access.

Require authentication to access any applications residing on the device.

Do not store passwords on the device.

Encrypt any persistent data storage facilities.

Enforce corporate security policies for mobile users.

Authentication and encryption, along with a security policy, are required to help prevent malicious data access from a lost or stolen device. Fortunately, this is not as serious a problem for wireless Internet applications, as they rarely store data outside of the browser's cache.

Security Technologies
Given the security threats just outlined, companies need to understand the technologies that are available to help them minimize security risks. Though the requirements for each company will be different, all companies will benefit by implementing a well-thought-out security plan. This section provides information on the main concepts and technologies that are required to implement end-to-end security for your m-business applications.

Cryptography
The basic objective of cryptography is to allow two parties to communicate over an insecure channel without a third party being able to understand what is being transmitted. This capability is one of the core requirements of a secure environment, as it deals with all aspects of secure data transfer, including authentication, digital signatures, and encryption. On the face of it, cryptography is a simple concept, but it is actually quite complex, especially for large-scale mobile implementations.

Algorithms and Protocols
Cryptography works on many levels. At the lowest level are cryptographic algorithms. These algorithms describe the steps required to perform a particular computation, typically based around the transformation of data from one format to another. Building on these algorithms, is a protocol. The protocol describes the complete process of executing a cryptographic activity, including explicit information on how to handle any contingency that might arise. Making this distinction is important, because an excellent cryptographic algorithm does not necessarily translate into a strong protocol. The protocol is responsible for more than just the encoding of data; data transmission and key exchange are also properties of a protocol.

Finally, on top of the protocol are the applications. Once again, a strong protocol does not guarantee strong security, as the application itself may lead to further problems. Thus, in order to create a secure solution, a strong protocol is required, as well as a good, robust application implementation.

Data Encryption
The core of any cryptographic system is encryption, the process of taking a regular set of data, called plaintext, and converting it into an unreadable form, called ciphertext. Encryption allows you to maintain the privacy of sensitive data, even when accessed by unauthorized users. The only way the data can be read is by transforming it back to its original form using a process called decryption. The method of encryption and decryption is called an algorithm or cipher.

Modern algorithms use keys to control the encryption and decryption of data. Once a message has been encrypted, it can only be decrypted by users who have the corresponding key. Key-based algorithms come in two classes: symmetric and asymmetric.

Symmetric algorithms are efficient: They use a single key to encrypt and decrypt all messages. The sender uses the key to encrypt the message and then sends the message to the intended recipient. Once the message is received, the recipient uses the same key to decrypt the message. This type of algorithm works well when there is a safe way to transmit the key between users, such as by meeting before the transmission takes place. Unfortunately a substantial problem arises when exchanging data between loosely related parties, such as an e-commerce Web site and a customer. Exchanging the key is a problem that symmetric encryption itself is incapable of solving; and without a secure method of exchange keys, this method is only useful between private parties.

Symmetric encryption is also referred to as secret-key encryption. The most popular form of this method is the Data Encryption Standard (DES), which was developed in the 1970s. Since then more secure forms of symmetric encryption have been developed; leaders among them include the Advanced Encryption Standard (AES), which is based on the Rijndael algorithm; Triple DES; International Data Encryption Algorithm (IDEA); Blowfish; and the Rivest family of algorithms, RC2, RC4, RC5, and RC6.

Asymmetric encryption addresses the main problem that has plagued symmetric key systems: the use of a single key. For years, cryptologists worked to find a solution to the key distribution problem with little success. Just as many mathematicians started to think that a solution was not possible, Whitfield Diffie and Martin Hellman proved them wrong. In 1975, Diffie and Hellman developed a solution using two separate but related keys: one to encrypt the data and another to decrypt it. The key used to encrypt the data is called the public key. This key can be widely distributed over insecure lines, for general public use. The key used to decrypt the corresponding data is called the private key. This key is never transmitted, as it is only required by the party that needs to decrypt the data. These keys are related in an obscure way using extremely large prime numbers and one-way functions. This technique makes it computationally infeasible to calculate the private key based on the public key. The larger the key is, the more difficult it becomes to break the system. Sixty-four-bit key systems, such as DES, are capable of being attacked by brute force—that is, trying every single key combination until the attacker finds the correct one. The more common 128-bit systems, such as ECC, so far have proven invulnerable to brute-force attacks.

Here is an example of how asymmetric, or public key, cryptography works. Suppose Alice wants to send a secure message to Bob. Alice can use Bob's public key to encrypt the message, since it is publicly available. She then sends the message to Bob. When he receives the message, he uses his private key, to which only he has access, to decrypt the message. Now Alice is able to send a secure message to Bob without having to do a key exchange. If information is to be exchanged in both directions using asymmetric encryption, each party must have his or her own public key and private key combination.

Encrypting a message with the private key and decrypting it with the public key is possible as well, but this has a different objective. It can be used on nonsensitive data simply to prove that the party who encrypted it actually has access to the private key.

The first, and best-known, asymmetric key algorithm was released in 1977 by Ron Rivest, Adi Shamir, and Leonard Adelman; who are commonly known as RSA. Other popular algorithms include Elliptic Curve Cryptography (ECC) and Diffie-Hellman (DH). RSA is being challenged in the mobile space by ECC, which is much less expensive in terms of processing power and key size, which are essential attributes in mobile computing.

Asymmetric ciphers are not, however, a perfect solution. Choosing a private key is not trivial, as a poor choice can lead to an easily broken scheme. Also, asymmetric ciphers provide a solution to the key distribution problem by using a public key and a private key, but they also are much more complicated, and therefore computationally slower than symmetric ciphers. For large sets of data, this can be problematic. In these cases, a combination of symmetric and asymmetric systems is an ideal solution. This allows you to take advantage of the higher performance of symmetric algorithms, by sending the secret key over insecure channels using public key systems. Once all parties have the secret key, the remainder of the data for that session can be encrypted and decrypted using symmetric algorithms. This is the basis for public key cryptography as used by many of today's leading protocols.

Digital Certificates
Digital certificates provide a way to guarantee that a public key belongs to the party it represents. For this to be successful, the certificate itself also has to be verified to ensure that it represents the claimed entity (a person or organization). This is accomplished using a trusted third party called a certificate authority (CA). The most common certificate authorities include VeriSign, Entrust, and Certicom. Users can purchase a digital certificate from the CA and use this certificate for authentication and to circulate their private key. Once a recipient has their private key and they are confident the recipient is who he or she claims to be (which is largely based on the trust of the CA), they can then send encrypted messages to this person, knowing they can decrypt them using their private key. Digital certificates typically contain the following:

The name of the holder, as well as other information that uniquely identifies the holder. Additional information can include the URL of a Web server using the certificate or an email address.

The holder's public key.

The name of the CA that issued the certificate.

The lifetime that the certificate if valid for (usually a start and end date).

A digital signature from the CA to make it easy to detect if the transmission has been tampered with.

Certified users also have the option of self-signing a digital certificate, thereby becoming a CA themselves. This additional party can be considered trustworthy if he or she was signed by another trusted key. In this way, you can continue to navigate to the root CA, thereby determining who provided the initial certificate. If the root CA is not recognized or trusted, then each certificate in the chain is considered invalid.

The leading format for digital certificates is X.509, an industry standard for authentication. These certificates are prominent in Internet applications. In the wireless space, another form of digital certificate, called a WAP Server WTLS Certificate, is available. These certificates, commonly shortened to WTLS certificates, are a simpler version of X.509, created because X.509 certificates were too big for wireless applications. The WTLS certificates are primarily used in WAP applications where the microbrowser wants to authenticate the identity of a WAP server and encrypt information using the Wireless Transport Layer Security (WTLS).

Digital Signatures
Digital signatures are used to verify that a message really came from the claimed sender. It is based upon the notion that only the creator of the signature has the private key and that it can be verified using a corresponding public key. The digital signature is created by computing the message digest of a document, then concatenating it with information about the signer, a timestamp, and any other required information. A message digest is a function that takes arbitrary-sized input data (the message) and generates a fixed-size output, called a digest. This set of information is then encrypted using the private key of the sender using a suitable asymmetric algorithm. The resulting encrypted block of information is the digital signature.

The message digest that was calculated is a bit value that represents the current state of a document. If the document changes in any way, the message digest will also change. By incorporating the message digest into the digital signature, it is possible for the recipient of the document to easily detect if the document has been altered since the digital signature was created.

Public Key Infrastructure
Public key infrastructure (PKI) is the term used to describe a complete organization of systems and rules defining a single security system. The Internet Engineering Task Force (IETF) X.509 Working Group (www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-09.txt) defines PKI as "the set of hardware, software, people, and procedures needed to create, manage, store, distribute, and revoke certificates based on public key cryptography."

The components of PKI include the following:

Certificate authorities responsible for issuing and revoking certificates

Registration authorities responsible for binding between public keys and the identities of their holders

Certificate holders who have been issued certificates that they can use to sign digital documents

Repositories that store certificates as well as certificate revocation lists

Security policy that defines an organization's top-level direction on security

Leading Protocols
The following are some leading protocols that are used for secure data transmission.

Secure Sockets Layer (SSL)
SSL is the dominant security protocol being used on the Internet today. It was developed by Netscape to provide secure and private Internet sessions, typically on top of HTTP, although it can also be used over FTP and other relevant protocols. SSL uses a combination of symmetric and asymmetric algorithms to maximize performance.

There are four phases in an SSL session:

Handshake and cipher negotiation. Both the client and server agree on the algorithms or ciphers to use.

Authentication. The server, and optionally the client, is authenticated using digital certificates.

Key exchange. The client creates a secret key and sends it to the server using its public key for encryption. The server decrypts the message using its private key; and for the remainder of that session, the client and server can communicate using the secret key.

Application data exchange. Once the secure symmetric session has been established, encrypted data can be communicated between the client and the server.

SSL can be used by many of the more powerful wireless clients, including laptops and Pocket PC devices. You can tell you are using SSL when the URL starts with https://, rather than just http://.

Encrypting the data within the protocol is more efficient than encrypting the data yourself and sending it over HTTP. Within the SSL protocol, the data will be encrypted on a packet level and can be decrypted on a packet level after it has arrived and has passed any sort of integrity test. If you encrypt your data as one large cipher text, then you will not be able to decrypt the data until all the packets have arrived.

Transport Layer Security (TLS)
Transport Layer Security (TLS) is the next generation of SSL. It consists of two layers. The lower layer is the TLS Record protocol, which is layered on top of a reliable transport protocol such as TCP. The two main features of the Record protocol are private and reliable connections. The higher level is the TLS Handshake protocol. This layer provides connection security that authenticates using asymmetric cryptography, negotiates a secret key, and provides a reliable negotiation. Like SSL, TLS is independent and can use a range of ciphers. The overall goals of TLS include cryptographic security, interoperability, and extensibility.

Wireless Transport Layer Security (WTLS)
WTLS is the security layer defined in the WAP specification. It operates above the Transport Protocol Layer, making it suitable for a variety of underlying wireless protocols. It is similar to TLS, but is optimized for low-bandwidth networks with high latency. It also adds new features such as datagram support, optimized handshakes, and key refreshing. It also supports the use of WTLS certificates for server-side authentication, in contrast to SSL/TLS, which typically use X.509 certificates. Overall, WTLS has similar goals to both SSL and TLS, in that it aims to provide privacy, data integrity, and authentication between two communicating parties.

IP Security (IPSec)
IPSec is different from the other protocols in that it does not operate on the application layer. Whereas SSL, TLS, and WTLS are aimed at providing secure communications over an inherently insecure network, IPSec is aimed at making the Internet itself secure. It does this by providing authentication, integrity, and privacy services at the IP datagram layer. While it is mainly targeted at laptop clients in the mobile space, IPSec-based virtual private network (VPN) products are starting to emerge for PDAs as well (see the upcoming section for more on VPNs). IPSec will become a more prominent solution when mobile devices start to support IP6, which includes IPSec as part of the standard. It is important to know that IPSec supports TCP/IP, not WAP.

Other Security Measures
The following subsections describe other security measures that you should consider when implementing your mobile solutions. You may find that some of these measures are already in place in your organization, as they are commonly used techniques for increasing overall system security.

Firewalls
Firewalls are the most common form of security implemented within organizations. They establish a network perimeter between what is public and what is private. A firewall is a set of software programs, usually located on a separate gateway server that restricts access to the private network resources from users on other networks. As soon as an enterprise installs Internet access to its site, a firewall is required to protect its own resources and, sometimes, to control outside resources to which its own users have access.

At a lower level, a firewall will examine each packet of network data to determine whether it should be forwarded to its destination. Where outside access is permitted, as in the case of a Web server, the firewall will allow outside traffic through the firewall on a specified port, for communication with a specified application. In this case, it would permit access from all outside users. At times, however, access from outside the firewall will be restricted to only known users, usually based on their IP addresses. This is used when a finite number of known users require access to a system.

For mobile devices that have always-on connections, a personal firewall may also be useful. This works in the same way as the firewall just described above, except it prevents unauthorized access to laptops and high-end PDAs. A personal firewall will prevent not only suspicious connections but also inappropriate content. Many devices contain hidden instructions that are used by maintenance professionals to repair a device. Lately, viruses and other inappropriate content have taken advantage of these hidden instructions to cause harm. A personal firewall can help prevent this from happening, although it should not be used a replacement for appropriate antivirus software.

Virtual Private Networks (VPNs)

A VPN allows a company to turn a public network (most commonly the Internet) into a private network. This technology allows remote workers to communicate with the corporate network in a secure fashion. Before VPN technology became available, dedicated leased lines were required to achieve the same result. Actually, VPNs present an additional benefit over leased lines, by providing secure access from many locations—essentially anywhere an Internet connection is available.

VPN technology is currently being used to help overcome the wireless LAN security problems by providing a direct link through a WLAN past the corporate firewall. The drawbacks of this configuration are cost and the inability to roam between WLAN access points. Mobile VPNs for devices on public networks are still in the early phases of adoption. As larger amounts of data are accessed remotely, mobile VPN usage is expected to increase.

Two-Factor Authentication
For some purposes, usually dealing with financial transactions, strong authentication is required. This involves using a two-factor approach, where users have to apply two factors to authenticate themselves. One factor is usually something the user knows, such as a PIN number; the other is something the user has, such a token card to generate a one-time password. This combination makes it much more difficult for unauthorized users to gain to access the system.

Smart client applications inherently provide a form of two-factor authentication: First you must have the device to access the application; second, you must authenticate yourself to gain access to the application, as well as to any back-end system to which it connects. This is not the traditional sense of the term, but it does provide additional security over thin client applications where any device with a microbrowser has the capability to access the content.

Biometrics
Even with the increased security of two-factor authentication, unauthorized users can compromise the system, for example, by obtaining the PIN code and token card, thereby gaining access to the enterprise system.

To avoid this situation, PIN codes can be replaced with a stronger form of authentication: biometric authentication. Biometrics provides a wide range of techniques for authenticating an individual based on his or her unique physical characteristics. Such techniques include fingerprint identification, face recognition, voice recognition, or iris and retina scanning. Using biometric techniques, you can ensure that the identification token is indeed unique. While this use of biometrics does improve security, this type of authentication does have some drawbacks. Many of these systems are somewhat intrusive and therefore not widely accepted by users. Also, the reliability of these technologies varies and so can lead to what's called "false refusal." That said, biometric systems are growing in popularity due to increased security concerns among all users.

Security Policy
The final, and often most important, security measure is the adoption of a corporate security policy. Such a policy will outline all aspects of a corporation's security measures, including both technology and the use and disclosure of confidential information within the enterprise. Even if a corporation has implemented a very strong technical security solution, the overall system will still be insecure if its users do not follow corporate security guidelines. Remember, intruders will always attack the weakest link in a system. Unfortunately, this link is often the users themselves.

Sometimes, very simple measures will dramatically increase overall security. For example, many PDA users do not lock the operating system when it is not in use. If the device is lost, nothing prevents another user from accessing the applications and corresponding data on the device. The same security measures that are in place for desktop users must be extended to remote workers.

Application Architectures

2009-11-06T05:00:00.000-08:00

In the wireless world, rarely does everything in your architecture perfectly suit your application needs. You will almost always have to make trade-offs between features, convenience for the end user, time to market, range of devices, ease of use, complexity, deployment options, and so on.

Figure shows the spectrum of mobile application architectures covered in this post. But, note, though the diagram shows five application models, for the purpose of our discussion, the architectures have been divided into three categories: wireless Internet, smart client, and messaging. As we will see shortly, messaging is interesting because it can be used either on its own or in conjunction with the other application architectures. As we move from left to right on the diagram, the complexity of developing and deploying the application increases, as do the capabilities the application provides.

Figure : Application architecture spectrum.

Finding the right combination of complexity and capabilities for each application being deployed is important. In some cases the benefits of developing a smart client with messaging application will prove to be worth the added development complexity, while in other cases a wireless Internet solution will be more suitable. It is a good idea to enter the design and development phase with an open mind. The purpose of answering the questions in the previous section is to gain an understanding of the user and application requirements, so they can then be matched against the most suitable architecture. Having preconceived opinions about a particular solution may lead to a poor architecture decision.

You may also find that incremental gains in an application can have a large impact on the result. This is often the case when messaging functionality is added to an application. Push messaging can turn a user-driven application into an enterprise-driven application. Rather than requiring the user to request data periodically, important data can be pushed to the user as soon as it is available.

We are now going to take an introductory look at wireless Internet, smart client, and messaging application architectures. The purpose of this overview is to provide enough information for you to understand the high-level benefits of each architecture.

Wireless Internet
In most regards, wireless Internet applications have the same architecture as wired Internet applications. The components of the system are essentially the same; the only difference is the way the information is transmitted to the end user. Figure depicts the wireless Internet architecture. All of the business logic and enterprise data is stored on servers within the corporate firewall. On the client side is a mobile device that has an Internet browser. These browsers are often called microbrowsers due to their limited size and functionality. No other software is required on the client device. For this reason, wireless Internet applications are also called thin client applications. Each component of the wireless Internet architecture is described in turn in the following subsection.

Figure : Wireless Internet architecture.

Wireless Internet Architecture Components
The following are the key components of the wireless Internet architecture.

Microbrowser client. The browser uses a URL address to contact the specified wireless Web server. The response containing the markup language is then parsed by the browser, and the results are displayed to the application user. In this regard, wireless browsers are very similar to desktop Internet browsers. When the wireless network is not Internet Protocol (IP)-based, the base station contains a gateway that will translate the request and send it as Hypertext Transfer Protocol (HTTP) to the Web server.

Unlike desktop Internet applications, wireless Internet applications may be deployed to devices running a variety of microbrowsers, supporting several markup languages, all having their own unique way of allowing users to navigate through the application. Most wireless devices come with a microbrowser preinstalled, although this is not always the case.

Wireless Web server. The wireless Web server listens to the incoming HTTP request and sends the appropriate response back to the client. This may require some additional steps to gather content from corporate data sources and format the data appropriately for the client in terms of markup language and form factor.

To accommodate the large number of microbrowsers and markup languages used in wireless computing, the wireless Web server often contains wireless-specific frameworks that help with the formatting of the wireless content. In all other regards, this is identical to how an Internet Web server works.

Enterprise data source. The wireless Web server will access the enterprise data source using the preferred access mechanism. Features of your enterprise data source, such as failover, high-availability, and access methods depend on many factors, including how much use you predict your site will see, how critical the service will become, and the existence of alternate methods of accessing your enterprise data source.

Additional Information on Wireless Internet Applications
The entire request/response process happens while the user is connected to a wireless network. If a connection is not available, the user is typically unable to access any part of the application or data. There are exceptions to this with some browsers that provide offline Web content caching. In these cases, cached content may be available, although this content is usually not adequate to perform a complete transaction.

One of the most common protocols for wireless Internet applications is the Wireless Application Protocol (WAP). This protocol was developed and is maintained by the Open Mobile Alliance (formerly the WAP Forum), which is composed of a group of companies to promote wireless Internet development. WAP applications are most common on limited-display devices such as mobile phones.

The majority of consumer application services such as mMode from AT&T (United States) and i-mode from NTT DoCoMo (Japan) are based on the wireless Internet model. Providing access to these services is very straightforward since no software has to be deployed to the device. Essentially, anyone with a wireless device and microbrowser can access the applications provided.

Advantages of Wireless Internet Architectures
The following are the key advantages of wireless Internet (thin client) architecture:

Minimal to zero software deployment. This allows applications to be deployed without any additional client-side configuration. Updates to these applications are also straightforward since only the server has to be updated.

Extends Internet computing model. Many corporate applications are based on the Internet model. Wireless Internet is a natural extension to these applications.

Familiar user interface. Many users are familiar with a browser interface to their applications. Providing a similar interface on mobile devices allows them to be productive immediately; there is no learning curve.

Enterprise integration. If an existing Internet application is being extended, the application logic and enterprise integration layers may already be taken care of. This is a tremendous benefit, as enterprise integration often proves to be the most resource-intensive part of a mobile application.

Broad deployment. If multiple mobile devices are being targeted, wireless Internet application is often the easiest approach since the entire configuration and adaptation of content takes place on the server.

Fresh data. All of the data is assured to be latest version available in the corporate system. There is no worry about stale data.

Security. All of the data is stored on the server behind corporate firewalls. No data is stored on the client.

Disadvantages of Wireless Internet Architectures
Wireless Internet architectures have some disadvantages as well, namely:

Wireless connectivity. To access any data, all of which resides on the server, you need wireless connectivity. This can be problematic when users are moving between multiple locations. The exception is when browsers have content-caching capabilities. That said, even when caching is available, there is still a very limited amount of data and logic available to perform transactions.

Simple user interface. Many microbrowsers have limited capabilities for graphics or other "rich" components. Graphics are also often avoided to minimize the amount of data being downloaded over potentially slow wireless networks.

Application performance. For each request being transferred over a wireless network, performance can be an issue. This is due partially to network throughput and partially to network latency.

Application testing. Controlling, predicting, and testing the behavior of the application is difficult on the full range of microbrowsers. When emulation software is used to simulate devices, it is not always an accurate representation of the end-user experience since it is not executing over a wireless network.

Availability. If a server-side problem occurs, all users will be brought to a halt.

Security. Total control of the environment is not available in most cases, because a wireless gateway exists that may lead to security concerns.

Cost. Wireless airtime fees can become an issue if the mobile user has to constantly be connected to use the application. On circuit-switched networks, where fees are charged based on the time connected, not the data transferred, charges are incurred even when a user is reading Web content or filling in a form.

Application Examples
Nearly any application can be presented as thin client. This section highlights those applications which are almost always best suited as thin client.

Securities Trading
Securities data is extremely volatile and it is imperative that users be assured that the data they are viewing is the most up-to-date and accurate. This data category is an ideal fit for wireless Internet applications. Users viewing stock quotes or portfolio summaries can be confident the information presented reflects the most up-to-date information available on the enterprise server.

Wireless Internet applications are also applicable to financial transactions. When users purchase or sell a security, they need to be updated immediately on the status of the transaction. With thin-client applications, the transaction information is immediately relayed to the appropriate server where the transaction will take place. If the transaction occurs immediately, the result can be transmitted back to the user in real time. If the transaction happens at a later point in time, the user can check the status throughout the day to get real-time updates.

Information Services
Information services comprise one of the leading uses of wireless Internet applications. Any user with a wireless device and a microbrowser can quickly and easily access a variety of informational sites to access many types of content, including news, weather, sports, airline schedules, traffic information, movie schedules, restaurant information.

Entertainment Information
Similar to information services, a variety of entertainment information is available from wireless Internet devices, including interactive games, horoscopes, puzzles, and instant messaging.

m-Commerce
The majority of m-commerce applications are targeted at the general consumer population. These applications are more successful when they are for goods that can be purchased and obtained immediately, such as downloadable games and mobile phone ringtones. Purchases that require pickup or delivery at a later date have not proven to be popular over mobile devices. This is because m-commerce makes the most sense when there is a sense of urgency.

m-Commerce applications, information services, and entertainment information are all targeted at consumer audiences, so supporting the largest possible number of devices, and in turn the largest number of potential customers, is essential.

Smart Client
Smart client applications are a powerful alternative to wireless Internet applications. Instead of using a microbrowser on the client, custom software is developed. This software typically contains a persistent data storage mechanism as well as business logic. This means that smart client applications can be executed at any time, even when a wireless connection is unavailable. Actually, smart client applications are essentially mobile and do not require wireless communication at all. Integration to the enterprise is typically provided via a synchronization process whereby the client application communicates data to back-end data sources through a synchronization server. This communication can occur over wireless or wired connections such as TCP/IP, serial, or USB. The smart client architecture is depicted in Figure .

Figure : Smart client architecture.

In order to deploy smart client applications, the client device has to have a mobile operating system that supports custom applications. This usually eliminates mobile phones from the smart client deployment options, leaving smart phones, PDAs, hand-held PCs, and laptops. The common approach for developing smart client applications is to use libraries native to the mobile operating system, although alternatives such as Java are also available. Let us look at each component of the smart client architecture, in turn in the next subsection.

Smart Client Architecture Components
The following are key components of the smart client architecture:

Smart Client
The smart client application is where client-side business logic is executed. The application itself is either a native executable or Java application that is deployed to the mobile device. To provide offline data access, mobile data store products are incorporated into the application.

Synchronization Server
Data is sent from the client application to the synchronization server. This can occur over a wireless or wired connection to the server. From there it is then communicated to the enterprise data sources. The synchronization server, with its associated logic, is responsible for ensuring that the minimal amount of data is transferred and that any conflicts are detected and resolved.

Enterprise Data Source
The synchronization server will access the enterprise data source using the preferred access mechanism. The access to the enterprise source may occur during the synchronization process if it is imperative for the smart client to receive feedback from the synchronization. This is a simple process and requires that the client connection to the synchronization server remain active until the enterprise is finished processing the data.

It is also possible to synchronize data to a corporate data buffer and return pending status for any operations that need to be completed. The enterprise system can poll the data buffer at its convenience for information to process. On the next smart client synchronization, the status of all pending operations are downloaded. This provides for a much shorter connection time to the server, and a greater number of clients can connect, but at the cost of end-user convenience.

Additional Information on Smart Client Applications
One of the most common concerns about smart client applications is software deployment. Manufacturers of products that specialize in mobile device management have addressed this in the enterprise space. These software packages allow a central server to manage all aspects of application delivery and maintenance. For the consumer market, over-the-air (OTA) provisioning is a key enabler of smart client computing. OTA provisioning enables consumers to purchase and install applications directly over a wireless connection; no companion PC is required. Many wireless operators and device manufacturers are setting up digital malls that users can browse to find a variety of applications. When they find an application they like, they download and install it on the device. A nominal charge [usually between $1 and $5 (U.S.)] will be added to the user's airtime bill.

These malls are very attractive for developers who require a distribution channel for their applications. The most common examples are games, but utilities, music, and other software applications all are benefiting from this type of distribution.

Advantages of Smart Client Applications
The following are key advantages of smart client applications:

Always-available data. When no wireless coverage is available, the user is still able to access and modify enterprise data to be synchronized later. This overcomes one of the most significant limitations experienced with wireless Internet applications.

Rich user interface. Sophisticated displays with graphics and charts can be developed. This type of user interface is more similar to what users expect based on desktop experiences. In the case of Pocket PC devices, a subset of the Windows functionality is available, allowing for rich graphical components.

Performance. How the interface is "served up" is determined by processor speed and data access, which are known qualities. No performance is lost in having to continually communicate over wireless networks to access data.

Distributed computing. The execution of business logic and data processing occurs on the client devices, reducing the load on the server machines. This means organizations have to purchase less server-side hardware.

Security. Implementing a solid end-to-end security scheme is easier than with wireless Internet architectures, as you have the ability to control data on both ends of communication. There is no dependence on third-party systems such as WAP gateways.

Cost. Wireless airtime fees can be reduced or even eliminated with smart client applications. Only the data pertaining to the specific mobile user has to be transferred between the smart client and the synchronization server. This results in a minimal amount of data being transferred, thereby lowering wireless airtime charges. The synchronization can also occur over wired networks so that wireless fees can be avoided altogether.

Disadvantages of Smart Client Applications
The disadvantages of smart client architectures are:

Enterprise integration. Because smart client application can provide advanced functionality on the client device, many organizations end up enhancing the client application beyond the original design. While the client-side component may not be complex to develop, the enterprise integration component will often take more time and resources than expected. (In a way, this is both an advantage and a disadvantage since the result is a more capable client-side application.)

Application deployment. Remote deployment and management of the smart client applications may seem a trivial or end-user-driven process, but it can become an IT burden when there are a lot of remote users.

Mobile viruses. Introducing a mobile operating system opens the doors to viruses. This can be addressed by software in the application deployment phase; never-theless, it does add another item of concern.

Development complexity. Programming in the native language of the mobile device requires learning a new client-side API. If you are developing for multiple mobile devices, with different operating systems, this can turn into a significant challenge. Java and other cross-platform tools are on the market to help address this issue.

Multiple development cycles. When multiple devices and mobile operating systems are targeted, separate development and testing phases may be required for each device involved. This can be a drain on resources and result in drawn-out development cycles if not planned for ahead of time.

Application Examples
In general, a smart client architecture deserves strong consideration for any application that requires offline data access. Here are a few example applications that are particularly well suited for a smart client architecture:

Sales Force Automation (SFA)
One of the most important assets for a salesforce is current information. The difference between making a sale or not often depends on having immediate access to information while the salesperson is meeting with the customer. The best way to ensure that the sales staff has this information is to deploy a Sales Force Automation (SFA) application with persistent data storage.

SFA applications give sales representative immediate access to important sales information, such as the customer's contact information and order history, product catalogues, price lists, and inventory lists. With this information on hand, the sales rep can put together quotes with delivery dates on the spot. Once the order is placed locally on the device, the rep relays the order to the back office through synchronization.

Field Force Automation (FFA)
Field service workers can benefit from persistent data access in many ways. By empowering service workers with the information they need, they can improve all aspects of their jobs, resulting in higher productivity and increased customer satisfaction.

The benefits start with order entry and dispatching. Orders can be taken at a call center, entered into a central database, and synchronized through to the mobile worker. This eliminates paperwork and streamlines the dispatching process. Once the service worker is at the job site, he or she will have all the related job information on hand. This includes a machine's service history, repair checklists, troubleshooting information, schematic diagrams, and parts inventory levels. Having this information on hand decreases delays that occur when the required information is not readily available.

Once the job is complete, the field service worker can complete the transaction by completing the job report. This involves entering the appropriate work order data, such as placing an order for parts and scheduling a follow-up visit. Once the data is entered into the remote application, it can be synchronized to the enterprise system, reducing administrative costs.

The overall benefit of providing mobile workers with always-available data is improved customer satisfaction, with the ultimate result being increased customer loyalty.

Healthcare Applications
Medical professionals, such as doctors and nurses, can realize many benefits from smart client applications, in particular, the availability of up-to-date, accurate, patient information at their fingertips. With this information, medical practitioners can diagnose conditions more effectively and accurately.

A prime example is prescription writing. In the United States, close to 3 billion prescriptions are written annually, for some 100,000 different prescription drugs, from a variety of pharmaceutical companies, and over a dozen insurance carriers. Managing this data is an arduous task. By automating this process with a smart client application, doctors can deliver accurate, easy-to-read prescriptions that meet the requirements of the patient's insurance plan. This is just one example where persistent data within a mobile application increases productivity and reduces errors. Many other medical processes can be automated in a similar fashion.

Data Collection Applications
An entire breed of applications has been designed for data capture. These applications allow businesses to streamline existing data capture processes. Many of the most recent devices are very well suited for this task. The rich user interfaces and add-on peripherals increase their usability.

For inventory management applications, having a built-in barcode scanner allows for easy capture of merchandise, asset, and document information. This information is recorded without data entry errors and can be synchronized directly into back-end systems. Digital camera add-ons allow the user to take pictures and store them on the device. They can then manipulate the pictures before synchronization. Insurance claims agents can take advantage of this functionality. They can take a picture of an item and make quick edits to the image to illustrate where the damage occurred. This picture can then be attached to the claim as it is synchronized into the central database.

These are just two examples where smart client applications with persistent data storage increase productivity while reducing errors and administrative costs. Other vertical markets that can achieve the same benefits include the financial, retail, transportation, and healthcare verticals.

Mobile Productivity Applications
For professional services staff and other mobile professionals, several applications are available to increase productivity. In the professional services industry, workers' success is often based on billable hours. By providing an application where they can capture the number of hours logged on each task, corporations will have more accurate records of how time was spent. This often results in more billable hours since they can be entered at the job site, reducing the likelihood that they will be forgotten.

Productivity gains can also be accomplished by providing mobile access to other enterprise business applications such as SAP, PeopleSoft, and Siebel. This type of mobile application allows for more accurate data capture and reduced data entry costs.

Messaging
Messaging applications can take many forms, ranging from email to alerts and notifications to application-to-application messaging. In some cases messaging is used as an enhancement to an existing mobile application; in other situations, it is itself an application architecture.

Numerous messaging technologies are available, so it follows that there are many uses for messaging. However, for our purposes here, three categories of mobile messaging are of interest to us. The following is a brief description of each:

User-to-user messaging. Messages can be sent from one user to another using a variety of mechanisms, including email, paging, and wireless text messaging such as the Short Message Service (SMS) or Instant Messaging (IM). Richer messages that include graphics and formatted text can be sent using the Enhanced Message Service (EMS), while multimedia content can be sent using the Multimedia Message Service (MMS). These forms of messaging can also be generated by server-side processes as a means of information dispersal.

Notifications and alerts. Messages that are urgent in nature can be pushed to mobile users on their wireless devices. This allows corporations to ensure that information is received in a timely fashion. These messages can contain a URL link to a wireless Internet site where the user can obtain additional information. These types of messages are called actionable alerts, since the recipient performs an action based on the message content. The two leading technologies for notifications and alerts are Handheld Device Markup Language (HDML) alerts and WAP Push.

Application-to-application messaging. In many cases, user interaction is not required for the message to be successful. Enterprises can communicate data directly from an enterprise server to a client application without user interaction. This can be useful to enhance smart client applications with server-initiated synchronization.

The first two types of messaging in this list do not require additional software to be deployed to the client device. For user-to-user messaging, the client software is typically provided by the device manufacturer; and for notifications and alerts, this capability is part of the microbrowser on the device. From the users' perspective, when they receive these types of messages, they view the information and react accordingly. This type of messaging is relatively straightforward to implement.

Application-to-application messaging is more involved. It requires software to be deployed on a device that understands the communication stream between the client and the server, as well as how to operate over a wireless or wired network. In a way, an application-to-application messaging application falls under the smart client category since a software application is deployed to the device that can be used when disconnected from a wireless network. Additionally, the client application typically contains a message queue that can store information. Figure illustrates the application-to-application messaging architecture. Each component of the application-to-application messaging architecture is described in the next subsection.

Figure : Application-to-application messaging architecture.

Application-to-Application Messaging Architecture Components
Here are the main components of an application-to-application messaging system:

Messaging client. The client application contains message queues as well as clientside logic. The message queues can store incoming and outgoing transactions for future access. For example, if an application attempts to send data to the server when a connection is unavailable, it can be stored in an outgoing queue and be sent automatically when the user establishes a connection to the server. This technique is called store-and-forward messaging. The messaging client can be used either on its own or in conjunction with other smart client features such as a persistent data store. The application itself can usually be programmed in languages specific to the operating system or in Java.

Messaging server. The server component is the part of the system that communicates with the messaging client, as well as the enterprise systems. The industry name for messaging servers is Message Oriented Middleware (MOM). Many of these systems are built on the Java Message Service (JMS). JMS provides a reliable and scalable base platform with store-and-forward capabilities. This form of messaging is useful for m-business applications because the sender of the message does not have to wait for the recipient to receive the information, allowing him or her to continue working while the message is routed and acted upon.

Enterprise data source. The messaging server can interact with a variety of backend systems, including databases, business applications, and other messaging systems. This integration can use the preferred access technique for the enterprise system. The asynchronous nature of messaging systems is well suited for systems that require complex enterprise integration since the user does not have to wait for a response.

Additional Information on Messaging Applications
The store-and-forward capability is not unique to application-to-application messaging. The server components of both user-to-user messaging and notifications and alerts can implement store-and-forward as well. This feature is especially important when communicating over a wireless network as it helps address the issues of intermittent connectivity, dropped connections, and coverage.

Many types of applications take advantage of messaging technology. For corporate applications, messaging is often used in conjunction with other technologies to provide access to enterprise data. Application-to-application messaging excels in this arena, often as an enhancement to smart client applications, whereas, HDML alerts and WAP Push are very valuable for enhancing thin client applications. SMS can be a valuable service for many businesses, but it is not typically integrated into corporate applications. Over 80 percent of all SMS messages are sent from consumer applications. Over time, more business may adopt text messaging, but the initial market focus is clearly on the consumer. After we examine the advantages and disadvantages of messaging, we will take a look at specific consumer and corporate areas where messaging technology is beneficial.

Advantages of Messaging
Here are the advantages of messaging:

Push capabilities. Wireless Internet and smart client applications can be enhanced with push messaging functionality. For wireless Internet applications, the message may contain a URL where the user can go to get more information. For smart client applications the push message could notify the user that he or she should synchronize the client data; or in some cases, the message may actually be able to initiate the synchronization automatically from the server.

Store-and-forward. When working over wireless networks, an important capability is for messages to be stored in a queue and delivered when connectivity is available . On the client, it means users can work as if a network connection is available, since the information will be forwarded to the server at a later time. On the server, it is beneficial because messages will be sent to users when they connect to the network, offering a form of guaranteed message delivery.

Personalized data delivery. The leading messaging products give end users the ability to register their messaging-enabled devices and schedule the delivery of messages to a particular device. For example, the schedule might dictate that between 9:00 A.M. to 5:00 P.M., a message should be delivered to an email account, but between 5:00 P.M. and 11:00 P.M., it should be sent as an SMS text message. In this way, users can receive messages at the location that is most convenient for them.

Wired and wireless communication. Application-to-application messaging can operate over both wired and wireless networks. This gives companies the option of providing wireless access to the application users. It also allows application users to connect through a wired connection when wireless coverage is not available. User-to-user messaging and notifications and alerts typically require wireless networks for communication.

Disadvantages of Messaging
Messaging is an optional component for many applications, so typically it is incorporated into applications only where there is a clear benefit. For this reason, there are not many disadvantages to using messaging, other than when it is simply not required.

However, messaging does add complexity to the development of the mobile application. For application-to-application messaging, development is required on both the client and the server. For text messaging and notifications and alerts, most, if not all, of the development occurs only on the server. In either case, incorporating messaging functionality into an application does require additional development and testing resources.

Sample Consumer Applications
Messaging is extremely popular in consumer applications. Whether using SMS, IM, email, HDML notifications, or WAP Push, consumer applications are usually focused on communication, entertainment, or information dispersal. In all cases, the messages are typically text-based, although this will change as more advanced messaging services grow in popularity.

Communication
Messaging technology is often used for person-to-person communication from something as simple as saying hello to asking a question, arranging a meeting, and to conduct other general interactions. It works well when making a voice call is inconvenient, inappropriate, or too expensive, and when the user wants immediate delivery of messages. SMS is currently the most common mobile messaging technology used for communication, although this may change as IM adoption grows, which will definitely be the case when IM vendors allow for interservice communication between different wireless systems and wired Internet users.

Entertainment
Many entertainment services use messaging technology. Some of the most common include viewing sports scores, reading horoscopes, and exchanging ringtones with other users. SMS can be used for this service, but push technologies such as HDML notifications and WAP Push are better suited. These technologies will include a URL that the user can visit to get more information, usually resulting in higher wireless usage. This benefits both the application provider and the wireless carrier.

Information Dispersal
Perhaps the most useful implementation of messaging in the consumer space is information dispersal. Applications that alert users of, for example, flight information, stock information, and weather forecasts, to name just three, can be very helpful to the mobile user. Essentially, any information that can be incorporated into a message, be it SMS or otherwise, can be dispersed using messaging technology. For urgent messages, push technologies are the best choice, while for general information, a pull-based solution will prove to be less intrusive to the user.

One concern for many people regarding push messaging is the potential of receiving unwanted messages, similar to spam on email. Mobile users are concerned that push messaging will continually interrupt them throughout the day. In addition, push clients have limits on the size and number of messages that can be stored on the device. For example, the Openwave client allows only 1500 bytes to be stored on the device, with each message containing a maximum of 160 bytes. This allows for as few as nine messages before the client reaches capacity.

Already applications are out there that will push information such as advertisements and promotions to mobile users based upon their location. While this is a great service if you are a subscriber, it will quickly become annoying if you are not interested in receiving this kind of message.

Sample Corporate Applications
Corporate applications can reap tremendous benefits by incorporating messaging technology. Whereas consumer applications benefit largely from the communication aspect, corporate applications gain by making enterprise data more readily available. Text-messaging technologies such as SMS and IM do not currently play a large role in corporate applications; application-to-application messaging and some of the push technologies are more conducive to the requirements of enterprise applications.

System Integration
On the server, messaging technology can provide a way to integrate disparate systems. In most organizations, enterprise information is stored in multiple sources, most often with different mechanisms for accessing the data. Messaging systems can provide access to these sources of enterprise data and relay the information to mobile users. The goal is to implement a solution that will require very little, if any, change to the existing systems, while providing a common layer for accessing enterprise data. Systems based on JMS will help meet this goal, at the same time providing integration with other J2EE technologies such as EJBs and JDBC.

Information Exchange
Messaging systems are very effective for exchanging information between mobile and nonmobile applications alike. New mobile applications can be based exclusively on messaging technology. Applications to access corporate email, dispatch work orders, and update inventory levels or pricing information and customer relationship management (CRM) applications are commonplace in the mobile workforce. All of these can be built using messaging as the transport of data between the mobile user and the enterprise system.

In the case of job dispatch, messaging technology is useful both for scheduling new jobs and for retrieving the status of existing ones. The field agent can be notified of an upcoming work order by a text message such as SMS or by a more advanced mechanism using application-to-application messaging, which could add the order directly into a calendar or custom application. Once the service agent has completed the task, he or she can send a message back to the office to keep staff there informed of the current status. This message could also contain notes or other information to keep the customer up to date on the processing of the order.

Application Enhancement
In addition to creating new mobile applications, messaging technology is also useful to enhance existing applications. Many smart client applications can benefit by adding new features such as server-initiated synchronization or store-and-forward messaging, while thin client applications can benefit from HDML or WAP alerts. In most cases, it is possible to add new messaging functionality without having to make major changes to the existing application. In this way, messaging technology can be incorporated into nearly all the smart client and thin client applications.

Event Propagation
When events occur within corporations that require the attention of some form of service staff (whether it involves repairing a malfunctioning system, fixing a database conflict, or replenishing inventory levels) messaging technology is a great way to notify workers that their attention is required. When a problem arises, the messaging server can take the request, and notify an individual user or a group of users using a variety of technologies. In this scenario, sending out a message to a pager may be the ideal choice for one worker, while an SMS message might be better for another. At the same time, the system administrator may want to receive an email message each time a problem arises to monitor response times. Messaging systems are well suited to handle these types of scenarios.

Mobile Application Architectures

2009-11-06T04:54:00.000-08:00

Many factors contribute to the success (or failure) of a mobile solution. These include the mobile device, wireless network connectivity, enterprise integration, and most important, the application architecture. Many people do not realize that several application models are available for mobile development, each with a different set of characteristics that make it appropriate for some applications and inappropriate for others.

In this post we introduce three mobile application architectures: wireless Internet, smart client, and messaging. A summary of each application model is provided, along with the advantages and disadvantages it offers. But before we investigate the architectures, we will look at some of the key criteria used for determining which architecture is best suited for a given application.

Choosing the Right Architecture
Many factors come into play when selecting a mobile application architecture. Evaluating the target audience, device type, network connectivity, enterprise integration, and security requirements, along with the specific criteria in the following list will enable you to select the architecture that is most suitable for your particular situation. Finding the answers to these questions, along with any others that may arise is an important step to determining which application architecture is most appropriate for your particular application.

Application Users
Who are the end users of this application?

Do they have technical skills?

What are the expected usage scenarios?

Understanding the end users is important in meeting their needs and is a fundamental requirement for any mobile application. The success of many mobile applications is often determined by the adoption and usage by end users.

Device Type
For corporate solutions, are there devices already deployed that must be used, or are new devices being provisioned for this application?

What type of device is most appropriate? Some factors that will affect this include the data input mechanism, wireless connectivity options, and form factor.

Is the device a complete package? Some devices come with wireless capabilities, while others need to be coupled with wireless components.

What are the capabilities of the components? For instance, some wireless PCM-CIA cards cannot be connected to the Internet and receive SMS messages simultaneously.

For some corporate solutions and many consumer solutions, you may not be allowed to dictate the target device. In that case, the questions must be approached from a different angle.

What functionality is available within a specified group of devices?

Do any devices preclude certain functionality?

Enterprise Connectivity
How will the mobile device connect to the enterprise?

Does it require wireless access, or is wired access (for example, USB, dial-up, serial) acceptable?

If wireless, what type of networking will it use: WPAN, WLAN, WWAN, or satellite?

Does the type of networking affect the amount of data transferred from the mobile application to the enterprise server?

Enterprise Data
How much data has to be available to the mobile user?

Where does this data reside: on the client device or enterprise server?

Is it feasible to download the data in real-time over a wireless network, or is client-side data storage required?

What is the longevity of the data and how often must it be refreshed? For example, stock quotes are only valuable when they are current, while an inventory list may not require daily updates.

Is it assumed that each end user will have only one device?

Can users share a device without mixing their data?

If a local data store is chosen, how will you reconcile local data with enterprise data?

Do you have a conflict-resolution scheme for updates to your corporate database?

Enterprise Integration
Does your client-side method of integration match your server-side API? For example, an application that has a local data store may choose to synchronize its changes up to the corporate database. Usually this process requires direct access to the corporate database or access to a data buffer which sends the data to the corporate data store later.

What if the only access to the corporate data store is through an API? In that case, you will need to use business logic to call the API using the data buffer.

One of the fundamental reasons to deploy mobile solutions is to extend the reach of enterprise data to mobile workers. To accomplish this, an application architecture must integrate with enterprise data. This can range in time and complexity, from trivial to impossible, and could be considered the most important area for concern.

For these reasons, many companies that are extending existing Internet sites will choose a wireless Internet model even though other application models may be more appropriate based on the other selection criteria.

User Notification
Do users need to be notified of new information during the day?

If the only message needed is a "ping" to the user, can existing mobile phones or paging device be used? For example, if a field technician must be informed that he or she must synchronize because another customer has been added to the schedule, can the message be sent via phone, pager, or to a smart client device? Does the message have to be sent at all, because the field technician will synchronize at the end of every job anyway?

Does the notification have to communicate some specific information directly to the mobile application, allowing for a lookup value, hyperlink, or automatic login to speed up the process? Receiving a message that reads: "New customer added. Click here to view details," is certainly easier for the end user.

What happens if the device is off or in another mode, which does not permit notifications to be received?

The ability for mobile users to be notified or updated during the day is a growing requirement for many mobile applications. This ability to push information can make mobile applications much more effective, and more manageable from the users' perspective.

Security
Is the mobile data sensitive in nature? Sensitive data must be protected from within the corporate network, during transmission, and on the device.

How can data be kept secure over public networks? Is Secure Sockets Layer (SSL) available for Internet content?

Is your data store on the device protected from casual prying and/or from serious hacking?

In addition to hosting your planned application, the device can provide access to other corporate resources. For this reason, access to the device and corporate network needs to be monitored.

How strong is your authentication method?

Where does user authentication take place: on the device, on the server, or in both locations?

Are viruses a concern? If so, where does virus scanning take place?

How about the device itself? What happens if a device is lost or stolen?

Battery Life
Is power consumption a concern?

Does wireless connectivity consume too much power?

Can devices be recharged during the day?

Is it possible to provide backup batteries for the device?

Will users abandon devices that they don't find convenient?

If surfing the Web for one hour will drain the battery of the device, is it worth it?

The battery life of the mobile device is a major concern. Mobile phones can often last several days on a single charge, while PDAs often only last a single day. Furthermore, applications that have frequent wireless communication require substantially more battery power than offline applications.

Other Services
In addition to the line-of-business application being developed, are there other services that mobile users will require? This may include access to corporate email, wireless Internet support, or instant messaging.

Satellite Systems

2009-11-06T04:39:00.001-08:00

Using satellite systems for wireless voice and data first came into consideration in the early 1990s. The goal was to provide a wireless network that would provide coverage for the entire planet, without the need for multiple mobile phones or to roam between many carriers' networks. The state of WWANs then was quite different from today. Many of the existing WWANs were still analog and there was no clear standard for second-generation networks. Satellite phones had the potential to become the de facto standard for wide area communication.

At the same time that satellite marketers were pitching a phone that would work across the globe, wireless carriers were implementing expansive networks; and mobile phone manufacturers were working on new lightweight attractive designs. By the time the satellite networks were ready for commercial use, they had already been overtaken by cellular systems. Satellite companies had a very difficult time promoting bulky, expensive satellite phones, when attractive, inexpensive cellular phones would provide the same benefits. If that were not enough, the airtime fees for the satellite networks would scare away even the most spendthrift customer.

Many of the early mobile Internet satellite providers discovered that their business plans were not as foolproof as they thought; some went bankrupt. Fortunately, the story did not end here. Even though widespread satellite phone usage was not destined for success, many other scenarios existed where satellite technology could prove to be helpful. Here are three examples:

Fixed locations. This refers to situations when access to voice and data systems is required from locations that are not serviced by other network types. Some examples of locations that could benefit from this service are industries such as oil and gas, utilities, and manufacturing; humanitarian workers in remote areas; military establishments; remote office locations or semifixed locations such as trailers or shelters. Consumer services are also offered where the download link is via satellite and the upload is through a telephone line.

Portable communication. Field personnel can send and receive voice and data regardless of their location. This can be useful for search-and-rescue efforts, research in remote locations, news agencies, corporate travelers in remote locations, and military efforts.

Vehicle. This may be one of the more compelling cases for satellite connectivity. Field workers can be assured that no matter what their location, they can communicate it and other pertinent information back to enterprise systems. Delivery personnel, law enforcement, and news organizations can all benefit from guaranteed coverage.

The terminals used for satellite communication range from handheld units to mobile base stations to fixed satellite dish receivers. The peak data transmission speeds range from 2.4 Kbps to 2 Mbps, depending on the solution being sought. For the everyday mobile professional, satellite communication does not provide a compelling benefit, but for people requiring voice and data access from remote locations or guaranteed coverage in nonremote locations, satellite technology may be worth consideration. Also of interest, some of the satellite service providers offer roaming between existing cellular systems and satellite systems.

Wireless Wide Area Networks (WWANs)

2009-11-06T04:27:00.000-08:00

WWANs have been in place since the early 1980s for voice communication, and since the early 1990s for data communication. Access to these networks requires users to sign an agreement with the company that operates the network they are interested in. This agreement will allow them to use the wireless network for a fee, which is often calculated by the number of minutes the user is connected to the network, or more recently, by the amount of data transferred over the network. This fee helps the service provider cover the cost of building and maintaining the wide area network, as well as the cost required to purchase the spectrum used for communication. Unlike WPANs and WLANs, wireless wide area networks do not operate over unlicensed frequencies, meaning they have to pay to purchase (or license) the spectrum being used. In some cases the amount of money paid for this spectrum is incredibly large. For example, the sale of spectrum for next-generation wireless networks cost more than $35 billion (U.S.). In order to recover some of those expenses, a usage fee has to be charged.

Do not let the prospect of a fee turn you away from using WWANs, however, as they provide an important component of many wireless solutions. When coverage beyond the range of a WLAN solution is required, WWANs are the place to look. They can provide national, and often international, wireless coverage for both voice and data communication. The communication quality and speed depends on the technology being used. Other properties that are network-dependent include area of wireless coverage, operating frequencies, handset availability, and, of course, cost.

In the remainder of this section we will take a look at the generations of wireless networks and the protocols currently being used. We will start with an overview of the terminology and concepts for wide area wireless networks.

Communication Fundamentals
Many technical concepts are involved with wireless voice and data transmissions. We are going to cover the most pertinent ones in this section before we discuss the evolution of wide area wireless networks. You will find these terms to be very relevant to WWANs.

Analog versus Digital Signals
The first wireless networks used analog signals to transmit sound. Analog signals constantly change as the voice is transmitted, similar to fluctuations in voice itself. Due to the fluctuating nature of analog waves, they are often represented by a sine wave. The first generation of wireless networks used analog transmission for voice communication.

As wireless networks evolved and started to be used for more data as well as voice traffic, a need for digital communication arose. Digital transmissions are a stream of 1s and 0s. Since the data stored on computers is inherently digital, digital networks proved to be more efficient in terms of both spectrum and power consumption. All second-generation wireless networks with data capabilities use digital technology.

The following are some of the many benefits attained by moving to digital networks:

Efficiency. Digital networks can transfer more data over the same amount of spectrum; they also allow for compression for even higher efficiency. Additionally, digital signals consume less power than analog.

Security. Analog signals can be easily listened to by eavesdroppers with a radio tuner; even encrypted analog signals can be cracked quite easily. Eavesdroppers have a much more difficult time with digital signals as they can be encrypted to various strengths, depending on the level of privacy required. In addition, the distribution techniques of digital signals make them more difficult to decipher.

Quality. Digital signals result in better-quality sound with less interference. Advanced filters can be used to remove any noise.

Features. Digital technology allows for voice features such as call answer and caller ID, as well as provide the basis for all data traffic as required for any wireless m-business application.

Circuit-Switching versus Packet-Switching
Two switching mechanisms are used for data transfer: circuit-switched and packet-switched. Circuit-switched networks establish a physical connection between the two communicating parties. This connection is maintained for the duration of the connection and cannot be used by any other parties. Landline telephone networks are circuit-switched. When you make a telephone call, you are granted a connection to the person you are talking to. The line becomes available again only after the conversation is finished and one party hangs up. Thus, for every conversation, a dedicated line is required.

Circuit-switching works well for voice communication where there is a constant stream of data being transferred, but is very inefficient for many forms of data communication where information is requested in bursts, such as when browsing Web pages, because even when no data is being transferred, the connection has to be maintained. This adds additional cost to consumers, as they pay according to the time connected to the network, not by the amount of data downloaded. From the wireless operators' perspective it is also wasteful, as they cannot use that connection for any other purpose. Additionally, if the connection is lost, the user has to establish a new connection, a process that takes anywhere from 5 to 40 seconds.

Packet-switched networks solve these problems. They do not require dedicated connections, but rather allow several users to share a single connection to maximize spectrum. Internet traffic uses packet-based networks for data transmission. This works by dividing data into small units called packets. These packets are then assigned a destination address that they carry around as they are being routed through the network. Multiple users can share the same data path since the data packets do not have to follow any specific path to get to their destination. This allows them to take the optimal path for bandwidth efficiency. At the receiving end, the data packets are then reassembled into their original format.

In terms of the user experience, packet-switched networks are far superior to circuit-switched when it comes to transferring data. Since a dedicated connection does not have to be established, and since no bandwidth is being wasted if data is not being transferred, devices are able to maintain a constant connection to the network without incurring additional costs or network burden. This alleviates users from having to establish a network connection each time they need to transfer data. Additionally, users are charged only for the data they transmit rather than connection times. This can result in significant savings. Network operators also prefer packet networks since they can utilize all of their network bandwidth. Packet switching is the basis of always-on connectivity provided by third-generation wireless networks.

Cells, Handoffs, and Roaming
A cell is the geographical area that obtains wireless coverage from a single cell site (base station). The coverage area for a cell depends on the network protocol, signal power, and obstructions that may impede its progress. As you move further away from the base station, the signal strength is weaker. Typical cell sizes range from 1 to 40 kilometers in radius. For wireless wide area networks, multiple cells are coordinated into a cell system. These systems provide coverage over a larger geographic area. Figure illustrates the coverage area of nine cells; Figure illustrates the same cells as hexagons as they are often depicted in theoretical drawings.

Figure : Cell coverage.

In highly populated areas, it is frequently necessary to create microcells, where base stations are positioned closer to one another to handle higher numbers of users. Microcells are often deployed in individual buildings, such as conference centers or airports, to handle the large volume of users. The coverage area of microcells is much less than a regular cell, typically around 100 meters in diameter.

When users move from one cell to another while a call is in progress, their connection has to be passed from cell to cell. This process is called a handoff (or in some cases, handover). The handoff is one of the most important aspects of mobile computing since it allows for the uninterrupted movement of mobile users. An unsuccessful hand-off results in a "dropped" call, which can be very frustrating for users. This is especially true on circuit-switched networks where users have to reestablish their connection before continuing.

When users move to a cell owned by a different wireless operator, they are roaming. Historically, wireless operators have charged high premiums for using services from other carriers, especially when roaming between countries. This situation is starting to change as carrier consolidation and strategic partnerships increasingly come into being. In fact, many wireless plans allow for unlimited roaming within the country or sometimes even the continent.

Multiplexing Techniques
Multiplexing is a term used to describe how a signal can be divided among multiple users. This spectrum sharing allows wireless operators to maximize the use of their spectrum to accommodate a large number of users over fewer channels. For digital systems, three main multiplexing techniques are being used for wide area networks: frequency division, time division, and code division. A fourth method, called orthogonal frequency division, is the most complex of all of these methods. It is commonly used in high-speed local area networks, as discussed earlier in this post, but is starting to grow in popularity for wide area networks as well.

Frequency-division multiplexing (FDM). Numerous signals are combined on a single channel. Each signal on the channel is assigned unique frequency for communication. The caller and the receiver tune to the same frequency to communicate. This is similar to how radio stations work. Each has its own frequency band over which it broadcasts. To listen to a particular channel, you tune the receiver to that particular frequency. For person-to-person communication, this is a very inefficient use of spectrum, hence is only used by analog wireless networks.

Time-division multiplexing (TDM). As with FDM, numerous signals are combined on a single channel, but with TDM they are divided into separate time slots. The time segments are assigned to an individual user and are rotated at regular intervals. The receiver interprets the appropriate time slot (channel) to receive the information. This technique allows for variation in the number of signals sent along the line, and constantly adjusts the time intervals to maximize bandwidth. Many of the current second-generation wireless systems are based on time-division multiplexing as it provides efficient use of spectrum with minimal interference.

Code-division multiplexing (CDM). Rather than dividing the signal using frequency or time, CDM attaches a code to each signal, and sends them all over the same broad spectrum. This results in very high spectrum efficiency and low levels of interference by other signals. Even though all of the signals are being broadcast at once, a receiver will only accept the signals with the right code. This technique is used in several second-generation wireless networks and is the basis for nearly all third-generation networks.

First-Generation Networks (1G)
First-generation (1G) wireless networks were first constructed in the late 1970s in the United States and in the early 1980s in Europe. These analog networks were used only for voice communication and they suffered from high levels of interference, which led to unpredictable call quality. Early on, first-generation networks also suffered from poor handoffs, often resulting in dropped connections, low capacity, and almost no security. The devices also had to be quite large to incorporate the radio receivers necessary to capture the analog signal.

Despite these difficulties, first-generation networks were deployed commercially in many countries. In the early 1980s, the United States, along with Japan, Mexico, and Saudi Arabia, deployed networks using the Advanced Mobile Phone Service (AMPS). In Europe, several analog standards were introduced, including the Total Access Communications System (TACS) and Nordic Mobile Telephony (NMT).

Due to the limitations of the first-generation networks, European countries were quick to move to a new standard based on completely different technology. The case is different in the United States where the AMPS network was widely deployed across all geographies. In many regions, the AMPS network is still used, often as a backup when digital coverage is unavailable.

First-generation networks do not play much of a role in the current m-business environment. They are of interest only when looking at backward compatibility of second-generation networks or for broader coverage in rural areas for voice coverage.

Second-Generation Networks (2G)
Second-generation networks introduced digital capabilities to wireless in the early 1990s. This resulted in higher-quality voice as well as basic data services. In addition, other features such as voicemail, call waiting, caller ID, and three-way calling were introduced to the wireless voice market. Another incredibly important benefit of moving to digital technology was increased capacity. Digital technology allows for more users to communicate on the same amount of spectrum, thereby increasing efficiency. Additionally, digital networks also provide a means for strong security, which was missing in the first-generation analog networks.

All of the second-generation networks provide support for data communications, with the exception of TDMA, which uses Cellular Digital Packet Data (CDPD) for its data services. The rates of data transfer range between 9.6 and 19.2 Kbps. This is fast enough for simple Internet applications based on the Wireless Application Protocol (WAP) or text messaging with Short Message Service (SMS), but it is not adequate for more data-intensive applications.

Four major second-generation systems are currently in use:

Digital AMPS (DAMPS, now known as TDMA), which can take advantage of first-generation AMPS service.

Code Division Multiple Access (CDMA IS-95), introduced by QUALCOMM in 1995.

Global System for Mobile Communications (GSM), which is the most popular of the 2G networks.

Personal Digital Cellular (PDC), largely used in Japan.

These four networks are all based on different standards, making them incompatible with one another. Moreover, even the same network protocol may not be compatible due to frequency regulations. For example, in Europe, GSM networks operate on the 900-MHz and 1800-MHz frequency bands, while in North America GSM networks use the 1900-MHz frequency band.

To accommodate these differences, dual-band and tri-band handsets are available. These handsets can switch between the different GSM frequencies so a user can roam between countries, or even continents, and still use the same mobile phone. In North America there are also dual-mode phones, which allow for roaming between the digital DAMPS network and the analog AMPS network. Other features in second-generation handsets include WAP browsers, text messaging, contact lists, calendars, games, and changeable ringtones. Kits are also available that allow for PDAs to gain wireless access using a mobile phone as the modem. The handheld devices are either attached to the phone using a cable or via short-range wireless connectivity such as infrared or Bluetooth.

When it comes to deploying data-driven applications, second-generation networks are often inadequate. They are circuit-switched, which is inefficient and expensive, and provide very limited data transfer rates. The need for higher capacity, higher data transfer rates, and global roaming were the driving forces behind the introduction of third-generation wireless networks.

Second-and-a-Half-Generation Networks (2.5G)
Just as the name suggests, 2.5G networks are a step toward third-generation networks, but they are not quite there. The good news is that they provide the main feature that users require to be successful on the mobile Internet: packet data. The move from circuit-switched systems to packet-switched systems is the major difference between 2G and 2.5G networks. This move brings along many other positive features, the leading one being high-speed data transfer at rates up to 144 Kbps, nearly 10 times that of 2G networks. For wireless operators, upgrading to 2.5G networks often requires only a software upgrade, not hardware modifications. This is a very attractive option for carriers who want to test the market for enhanced data services without incurring large capital expenditures.

Note Although 115 to 144 Kbps is commonly used as the theoretical throughput of 2.5G systems, in practice, a more realistic data transfer rate is approximately 40 to 56 Kbps. This is still fast enough for a broad range of new applications.

Two leading 2.5G network protocols are in use: General Packet Radio Services (GPRS) Code Division Multiple Access 2000 1x (CDMA2000 1x). Both offer many compelling enhancements over existing 2G networks. The following are five important characteristics of 2.5G networks:

Efficiency. More efficient use of spectrum by sharing connections among several users for both data and voice communication. This allows wireless operators to accommodate more users on the same network.

Speed. By implementing more efficient modulation algorithms and by being able to use multiple channels simultaneously for data transfer, 2.5G networks can provide transfer rates up to 115 Kbps. This is a vast improvement over 2G systems.

Always-on capability. Users can remain connected to the 2.5G network without having to pay by-the-minute charges, as they would on a circuit-switched network. This allows users to access data services at their convenience without incurring fees for resources they are not using. It also allows for a new range of applications that can push data to the user, rather than have them request it.

Upgrade to 2G systems. Both 2.5G technologies, GPRS and CDMA 1x, are upgrades to existing cellular networks. Users still have the same voice capabilities as before, but now have high-speed data access with the same network coverage. In most cases, moving to 2.5G from 2G involves a software upgrade for the wireless carrier, as opposed to building new infrastructure from the ground up.

Foundation of 3G infrastructure. The implementation of 2.5G technology lays the groundwork for future upgrades to 3G systems. This is true from both a business and technical standpoint. It is expected that as users experience the benefits of high-speed packet data, they will require even more speed and capacity, forcing carriers to upgrade to 3G. At the technical level, 2.5G provides the base packet network on which 3G networks can be built.

GPRS Handsets
Three classes of handsets have been defined to take advantage of the new GPRS services. Terminal is the term used to describe the GPRS unit, since it may not actually be a mobile handset, but instead a wireless network card or other module. The following are the three classes:

Class A. These terminals handle both voice and packet data at the same time. This requires two transceivers, making Class A devices the most expensive of the three.

Class B. These terminals can handle both voice and packet data, but not at the same time. This requires one transceiver that can be used for either voice or data. This keeps the cost of the handset down.

Class C. These terminals can handle either voice or data. This class of terminal may be a low-end handset or, more likely, a wireless modem.

Often it is the device that is the limiting factor for the total data rates that 2.5G networks provide. In order to achieve the theoretical 115 Kbps, the device has to utilize all available time slots for both uploading and downloading data. Most devices do not provide this capability, as it increases the overall cost of the device for speed improvements that are not required by the average user.

2.5G Applications
Along with enhanced networks and new handsets come a full range of new wireless data applications. In some cases, the 2.5G applications are simply extensions to the applications used on 2G networks; in other cases, they are applications that previously were not practical or even possible on 2G networks. A good example of this is wireless Internet applications. On 2G networks, WAP applications are typically text-based with limited graphics. With 2.5G networks, wireless Internet applications can contain full graphics with some multimedia capabilities. The applications will also run more efficiently since the networks are packet-switched.

Other applications that lend themselves to 2.5G networks include:

Corporate email, calendar, contact lists

Instant messaging

Still and moving images

Job dispatch

Vehicle positioning using location-based services

Remote LAN access

File-sharing applications

All of these applications take advantage of at least one of the characteristics mentioned earlier in this section. The increased data transfer rates apply to nearly all applications, while others, such as instant messaging and job dispatch, make particular use of the always-on functionality. In addition, since GPRS networks behave similarly to a typical LAN, they allow developers to build applications the same way they would for a typical IP network (of course, keeping the device and network limitations in mind).

Third-Generation Networks (3G)
Third-generation (3G) networks started with the vision to develop a single global standard for high-speed data and high-quality voice services. The goal was to have all users worldwide use a single standard that would allow for true global roaming. Unfortunately, as companies and standards bodies from Europe, North America, and Japan met, they could not agree on a single protocol for 3G systems. To help things progress, the leading standards bodies from these countries created a new group called the Third-Generation Partnership Project (3GPP). This group became the driving force behind the development of 3G standards.

After much negotiation, it was realized that backward compatibility with 2G networks and frequency differences among countries were too much to overcome, so agreement on a single 3G implementation could not be reached. Instead, three branches of 3G systems were created: Wideband CDMA (WCDMA), CDMA2000, and Enhanced Data Rates for Global Evolution (EDGE). In 1999, The International Telecommunication Union (ITU) approved an industry standard for third-generation wireless systems. This standard is called International Mobile Telecommunication-2000 (IMT-2000). Each of the 3G network protocols is explained in more depth in the section entitled "Network Protocols" later in this post.

Interestingly, 3G systems are based on CDMA technology, whereas the majority of 2G implementations use TDMA. This fact was also an item of contention among the standards bodies. Several proposals were made to the 3GPP, but the eventual winner was the CDMA-based solutions mentioned previously. The first 3G systems were implemented on a trial basis in Japan and Europe in late 2001. Worldwide commercial rollouts of these networks began in late 2002, and will continue into 2005. By 2005 to 2006, 3G networks are expected to reach a critical mass in both the consumer and corporate markets. This is the point at which the high-speed wireless networks become a necessity, not a luxury. Over time, the goal of the IMT-2000 is to converge the three 3G standards into a single universally accepted standard. Only time will tell if this will occur.

Once there was agreement on the standards, details were provided on which features these networks would offer. Two main enhancements characterize third-generation networks:

Higher data rates. 3G systems provide data transfer rates ranging from 144 Kbps to 2 Mbps, depending on the level of mobility. The IMT-2000 has defined three levels of mobility. All 3G networks must support the following minimum requirements:

High mobility: 144 Kbps for outdoor rural users who are traveling at speeds greater than 120 kilometers per hour (75 miles per hour).

Full mobility: 384 Kbps for users traveling less than 120 kilometers per hour in urban areas.

Limited mobility: 2 Mbps for users who are moving at less than 10 kilometers per hour (around 6 miles per hour).

Enhanced quality of service. QoS is supported from end to end in 3G systems, unlike their 2.5G predecessors. This allows users to establish agreements with network operators for certain network properties such as data transfer rate and network latency.

Looking at the preceding information, note that most vendors talk about 2 Mbps bit rates for 3G networks, when in reality that is only for users in stationary indoor environments. A more typical rate for the average mobile user is around 384 Kbps, which is still close to 50 times the rates achieved in most 2G systems. This is also notable, because when users move away from 3G network coverage, they will typically drop into 2.5G or 2G networks that have wider coverage areas. This may result in an unacceptable decrease in speed, as users could potentially move from 384 Kbps to 56 Kbps, or possibly even 9.6 Kbps transfer rates.

Another important point is that the data transfer rates in 3G systems are dependent on the user's distance from the base station. The further a user moves from the base station, the more difficult it becomes to achieve high speeds. The QoS features of 3G networks often mitigate this, but distance still affects network performance.

3G Devices
Device manufacturers typically trail network operators when releasing new devices. This means that we have yet to see many of the devices for third-generation networks. That said, many manufacturers have already started releasing devices for 3G networks. These devices usually have a few things in common, namely:

Support for multimedia content such as video streaming

Large, high-resolution screens

Form factors similar to PDAs

Integrated voice and data as seen in high-end smart phones

Mobile operating systems that allow for sophisticated client-side applications

Looking at the device characteristics, it becomes clear that 3G networks are targeted at wireless data as much as they are at voice communication.

3G Applications
Many of the applications aimed at 3G networks are similar to those being developed for 2.5G systems. Both generations of networks support IP applications, providing an easy migration path for application developers. That said, there are several new applications that are enabled specifically by the increased bit rates 3G networks offer, namely:

Streaming video applications

Downloadable audio such as MP3s

Over-the-air download of software programs

Workplace collaboration

Voice-over-IP (VoIP)

Location-based services

Multimedia messaging services

Support for corporate email and a full range of attachments

This is just a sampling of the new applications that 3G networks will enable. As developers start to gain access to these networks, and the programming interfaces they provide, new and innovative applications will start to enter the market. This is a very exciting time for application developers, as they are just beginning to see the capabilities that wireless has to offer.

Network Protocols
Many network protocols were mentioned in the discussion of the different generations of wireless systems. This section offers more information on these protocols, such as the frequencies over which they operate, their data transfer rates, and the locations where they are deployed. We start with paging networks and data-only networks, and progress to third-generation networks.

Paging Networks
Paging networks provide an alternative to the networks discussed earlier in this post. While many people consider pagers to be behind the times, these devices continue to provide some advantages over the current wireless networks. Paging networks operate at a very low frequency, which allows them to have good in-building coverage and wider coverage areas per base station. This has enabled nationwide coverage for paging networks, even in very remote areas. Paging networks are packet-based, allowing for information to be pushed to the user. This is clearly an important characteristic as push data is fundamental to receiving a page.

Three leading paging networks are currently in use:

Flex/reflex. A popular paging network in North America, invented by Motorola.

ERMES. The European Radio Message System, developed for use in Europe, has been adopted by the ITU as the recommended paging system.

POCSAG. This older paging system, named after the Post Office Code Standardization Group, has been replaced by more advanced systems, and is not widely used.

Even though paging networks are often overlooked when evaluating wireless network options, they still provide a service that is essential to many consumers and corporate workers: They are a low-cost alternative for users who do not require the additional features found in mobile phones or wireless PDAs.

Data-Only Networks
Several data-only networks are worth discussing. These networks are either used in conjunction with a voice network or on their own for data-driven applications.

CDPD
Cellular Digital Packet Data (CDPD) was introduced as a packet-switched option for AMPS and DAMPS. This allowed carriers to offer both voice and data services with their existing network infrastructure. It is the only way to send data over the analog AMPS network. Additionally, it is used as the data layer for TDMA networks.

CDPD has a maximum download speed of 19.2 Kbps and upload speed of 9.2 Kbps. In practice, these rates are lower, because they are shared among multiple users in a cell. Even with slow data rates however, CDPD became a popular option for wireless data using laptops and PDAs. In this scenario, wireless cards with embedded CDPD terminals are used for connectivity. For application developers, CDPD is a familiar protocol since it can run IP applications without modification. Every user connected to a CDPD network has a unique IP address. CDPD network coverage is found in most major cities in North America.

Mobitex
Mobitex is a narrowband, packet-switched protocol that provides data transfer rates up to 8 Kbps. It was first developed by Ericsson in the 1980s and has since been deployed in 23 countries worldwide. Mobitex networks provide low data rates at a low cost. The most substantial Mobitex network in North America is offered by Cingular Wireless; consequently, it is used by both Palm.net and BlackBerry.net networks in the United States.

Mobitex operates on three different spectrum bands: 400 MHz, 800 MHz, and 900 MHz. Any application developed for the Mobitex specification can operate equally well on any of these frequencies.

DataTAC
DataTAC stands for Data Total Access Communications. Like Mobitex, DataTAC offers packet-switched narrowband wireless data access, in this case with data transfer rates up to 19.2 Kbps. Three types of DataTAC networks have been deployed:

DataTAC 4000, which operates in North America.

DataTAC 5000, which operates in Asia and the Pacific.

DataTAC 6000, which operates in Europe.

The DataTAC network is often referred to as ARDIS, which is the name brand it operates under in North America. According to ARDIS, its network covers more than 90 percent of the North American business population. Notably, the RIM BlackBerry 850 and 857 devices use the DataTAC network for wireless connectivity.

TDMA (2G)
In the Americas, the term Time-Division Multiple Access (TDMA) is used to describe the DAMPS network, which is used to provide digital capabilities to the AMPS network. TDMA by itself does not provide any data capabilities; these are provided by CDPD, which is commonly integrated into TDMA networks.

TDMA networks are the leading 2G technology in the Americas; in the United States, it has nearly 100 percent coverage, and it is the only national network in many South American countries. In this region, TDMA subscriber growth is outpacing all other technologies, although this is likely to change as third-generation networks become mainstream. AMPS operators are able to add a TDMA layer on their existing infrastructure. By moving to a TDMA network, AMPS operators can achieve a threefold increase in capacity.

In other locations, TDMA is viewed from more of an engineering level. It is a multiplexing technology that uses time slices to divide a signal among multiple users (as described earlier in this post). In this sense, TDMA, also referred to as ANSI-136, is the leading 2G technology, as it provides the base for other network protocols such as GSM.

GSM (2G)
The Global System for Mobile Communications (GSM) is the most extensively used 2G technology in the world. GSM is a circuit-switched technology based on TDMA (ANSI-136). TDMA operators in North America are increasingly seeing the benefits of GSM technology: high voice quality, international roaming capability, large number of handset manufacturers, and broad developer base. Additionally, GSM offers a clear path of migration to 3G networks, which is attractive for many TDMA carriers.

GSM operates on three distinct frequencies: 900 MHz, 1800 MHz, and 1900 MHz. The 900 MHz and 1800 MHz are used in Europe, while 1900 MHz is used in North America. In order to provide international roaming, handsets are available that support all three GSM frequencies. These devices are called world phones because they provide worldwide access to wireless networks.

The data transfer rate of GSM networks is 9.6 Kbps. This is enough for the popular text-messaging applications and WAP browsing, but inadequate for other types of applications. To address this concern, a transitional technology called High-Speed, Circuit-Switched Data (HSCSD) was introduced. HSCSD allowed for multiple time slots to be used in a single connection for data transfer up to 57.6 Kbps. This was the expected evolution of GSM networks until more attractive packet-based networks such as GPRS came along. Now HSCSD is rarely discussed as the future for GSM networks. Instead, GSM networks have an upgrade path to 3G using GPRS as the 2.5G technology.

cdmaOne (2G)
Similar to TDMA, Code-Division Multiple Access (CDMA) is both a multiplexing technique and a 2G wireless network protocol. In order to differentiate the two, the network protocol is commonly referred to as cdmaOne, while the standard itself is CDMA, or IS-95.

cdmaOne is a circuit-switched technology that uses a spread-spectrum signal propagation technique. A signal is divided using distinct codes, then spread over the entire spectrum available to it. The advantages of this approach are increased user capacity and high voice quality. CDMA is very efficient when it comes to using spectrum; cdmaOne has been shown to increase the user capacity of an AMPS network by 8 to 10 times.

cdmaOne operates over two main frequencies: 800 MHz and 1900 MHz. The 800 MHz implementation competes with TDMA (DAMPS) in the United States, while the 1900 MHz implementation competes with GSM. Each channel of a cdmaOne system is 1.25 MHz wide and offers data transfer rates of 14.4 Kbps. Like GSM, this is sufficient for text messaging and simple wireless Internet applications, but insufficient for richer applications using images and multimedia content. This has been addressed in the newer CDMA standards called CDMA2000 and WCDMA. Each of these is described later in this section.

QUALCOMM, the pioneer of CDMA, commercially introduced CDMA in 1995. The evolution and promotion of CDMA is now handled by the CDMA Development Group (CDG), which is composed of the leading CDMA service providers and manufacturers. CDMA has experienced broad commercial success in the United States and Asia Pacific where GSM is not as prevalent. It has also been selected by the ITU as the basis for third-generation networks.

PDC (2G)
Personal Digital Cellular (PDC), a system used in Japan, is based on TDMA and offers backward compatibility to the country's existing analog networks. PDC offers a 9.6 Kbps data transfer rate over circuit-switched networks.

In the 1990s, Japan's largest telecom company, NTT DoCoMo, added a packet-switched addition to PDC called Packet PDC (P-PDC) that provides packet data capabilities. It also launched a service called i-mode that provides wireless multimedia over this network. Due to the phenomenal success of i-mode, PDC is now one of the world's most popular wireless standards, even though it is used only in one country.

The evolution of PDC goes directly to third-generation networks using WCDMA. There is no intermediate transition to 2.5G networks.

GPRS (2.5G)
General Packet Radio System (GPRS) introduced packet-switched capabilities to wireless networks. It is a simple, cost-effective upgrade to GSM and TDMA networks that provides increased bit rates and an improved user experience. As discussed in the earlier section on 2.5G networks, packet data systems provide always-on capabilities that allow users to remain connected to the wireless network for extended periods of time without incurring large usage fees.

GPRS operates on the same frequencies as the 2G networks it upgrades, specifically 900 MHz, 1800 MHz, and 1900 MHz. It can provide high-speed data transfer at theoretical rates approaching 115 Kbps, although in practice the throughput has proven to be closer to 40 Kbps. Since GPRS is an upgrade to existing infrastructure, users are able to roam between the GPRS network and GSM/TDMA networks. This ability allows operators to upgrade the major urban centers first, and gradually extend the GPRS network into rural areas.

GPRS is considered a safe point between 2G and 3G networks. It allows operators to experiment with new data services without incurring high capital expenditures. As users become more familiar with the benefits that GPRS networks provide, it is expected they will want even faster data rates, therefore increasing demand for 3G networks. GPRS is the base for EDGE and WCDMA systems.

CDMA2000 1x (2.5G)
CDMA2000 1x is difficult to categorize. Officially, it is classified as a third-generation technology, as defined by the ITU. Practically, it is a 2.5G technology, as it does not meet the minimum speed requirements for 3G networks, and is very similar to GPRS, which is clearly defined at 2.5G. For this reason, we are including CDMA2000 1x as a 2.5G standard.

CDMA2000 1x supports both voice and data services over the standard 1.25 MHz CDMA channel. The 1x in the name signifies that it uses one 1.25 MHz channel. Due to improved modulation, power control, and overall design, it can achieve theoretical data transfer rates of 144 Kbps. In practice, the data throughput for CDMA2000 1x is closer to those of GPRS at 40 to 56 Kbps. Additionally, CDMA2000 1x provides nearly double the capacity of previous CDMA systems and even more substantial increases for TDMA and GSM systems. It also adds packet-data capabilities to provide always-on capabilities.

CDMA2000 1x is backward-compatible with cdmaOne, operating on the same 800-MHz and 1900-MHz frequency bands. It is a cost-effective upgrade to existing cdmaOne networks, paving the way for third-generation CDMA2000 1XEV and CDMA2000 3x networks (3x networks use three 1.25-MHz channels simultaneously, thereby providing increased data throughput).

EDGE (3G)
Enhanced Data Rates for Global Evolution (EDGE) is a technology that allows current GSM networks to offer 3G services within existing frequencies. TDMA or GSM/GPRS infrastructure can be upgraded to EDGE with minimum impact. Since EDGE is a narrowband (200-kHz channels) technology, wireless operators are able to deploy 3G EDGE services without obtaining a 3G license. These two factors make EDGE a lowcost, fast solution for providing 3G services on a nationwide level.

EDGE is able to increase the over-the-air data rates using the same spectrum as 2G/2.5G systems. The peak data rates with EDGE are typically around 384 Kbps, with actual download rates ranging between 75 and 150 Kbps, depending on the user's distance from the base station, among other factors.

EDGE provides a seamless upgrade from 2G GSM networks to 3G UMTS (WCDMA) networks. The frequency bands that EDGE operates in complement the UMTS/WCDMA technology, allowing for the deployment of networks that use GSM, EDGE, and WCDMA in a fashion that is transparent the to user.

CDMA2000 1x EV (3G)
There are two members of CDMA2000 1x EV family: CDMA2000 1x Evolution Data Optimized (CDMA 1x EV-DO) and CDMA2000 1x Evolution Data and Voice (CDMA 1x EV-DV).

CDMA2000 1x EV-DO is a data-optimized version of CDMA2000 that can provide peak data rates of up to 2.4 Mbps using a single CDMA 1.25-MHz channel. With the introduction of improved technology for modulation and dynamically assigned data rates, 1x EV-DO is able to achieve download rates near the theoretical levels. CDMA2000 1x EV-DO supports the complete range of available frequencies, including 450 MHz, 700 MHz, 800 MHz, 1800 MHz, 1900 MHz, and 2 GHz. CDMA 1x EV-DO can work on all IP networks, giving wireless operators an opportunity to gain experience with IP-based technologies before moving their voice networks to IP. It is the natural path of evolution for CDMA 2000 1x networks.

CDMA2000 1x EV-DV networks are expected to be available in 2003. They will provide similar wireless data capabilities as CDMA2000 1x EV-DO, but with the addition of integrated voice capabilities. CDMA2000 1x EV-DV will provide peak data rates topping 3 Mbps, with typical throughput around 1 Mbps. This technology will enable real-time packet services for two-way conversational communication.

WCDMA (3G)
Two types of Wideband CDMA (WCDMA) are in use: Frequency-Division Duplex (FDD) and Time-Division Duplex (TDD). TDD is a hybrid of CDMA and TDMA technologies and is not commonly used commercially for WWAN implementations. It is better suited for indoor usage. The FDD version is the focus here, as it is being deployed commercially in several countries. The "wideband" part of its name refers to the requirement for channel bandwidth of 5 MHz. This is four times larger than CDMA2000 1x (1.25-MHz channel width) and 25 times larger than the GSM (200-kHz channel width). The wider bandwidth allows for higher data transfer rates. WCDMA supports all three modes of mobility as defined in the IMT-2000. As a refresher, these modes are high mobility (144 Kbps), full mobility (384 Kbps), and limited mobility (2 Mbps).

The version of WCDMA being deployed in Europe is commonly referred to as Universal Mobile Telecommunication System (UMTS). It uses direct-sequence (DS) CDMA and therefore it is also called DS-WCDMA. For our purposes, we will continue to refer to it simply as WCDMA. WCDMA has been designed as an upgrade to existing GPRS and EDGE networks, operating on the 2-GHz frequency band, and providing peak data transfer rates of 2 Mbps in stationary environments. Unlike the upgrade to GPRS and EDGE, WCDMA requires coverage to be built from scratch. Since this requires significant capital expenditures by carriers, WCDMA coverage will initially be available only in urban centers. Fortunately, WCDMA is compatible with GSM, GPRS, and EDGE networks, so users do have the ability to roam between the various network implementations. This means that as users move out of WCDMA coverage, they will automatically be handed off to a GSM, GPRS, or EDGE network and continue communicating at a slower data rate.

In Japan, NTT DoCoMo has deployed a WCDMA-based 3G network called Freedom of Multimedia Access (FOMA). It uses a slightly different version of WCDMA than that used in Europe. It was designed as an upgrade from PDC, and therefore does not require backward compatibility with GSM-based networks. In North America, the 2-GHz frequency band is already in use, so WCDMA either has to be introduced into the existing frequencies or new spectrum has to be allotted. This is one of the reasons why a single 3G network protocol cannot be adopted worldwide.

Wireless Local Area Networks (WLANs)

2009-11-06T04:10:00.000-08:00

Wireless local area network solutions comprise one of the fastest growing segments of the telecommunications industry. The finalization of industry standards, and the corresponding release of WLAN products by leading manufacturers, has sparked the implementation of WLAN solutions in many market segments, including small office/home office (SOHO), large corporations, manufacturing plants, and public hotspots such as airports, convention centers, hotels, and even coffee shops.

In some instances WLAN technology is used to save costs and avoid laying cable, while in other cases it is the only option for providing high-speed Internet access to the public. Whatever the reason, WLAN solutions are popping up everywhere.

To address this growing demand, traditional networking companies, as well as new players to the market, have released a variety of WLAN products. These products typically implement one of the many WLAN standards, although dual-mode products that support multiple standards are starting to emerge as well. When evaluating these products, some key areas should be considered, including:

Range/coverage. The range for WLAN products is anywhere from 50 meters to 150 meters.

Throughput. The data transfer rate ranges from 1 Mbps to 54 Mbps.

Interference. Some standards will experience interference from standard household electronics and other wireless networking technologies.

Power consumption. The amount of power consumed by the wireless adapter differs between product offerings, often depending on standards they implement.

Cost. The cost of a solution can vary significantly depending on the requirements of the deployment and which standard is being implemented.

In this section we provide some insight into typical WLAN configurations, as well as the leading WLAN standards.

WLAN Configurations
Wireless LAN configurations range from extremely simple to very complex. The simplest WLAN is an independent, peer-to-peer configuration where two or more devices with wireless adapters connect to each other, as depicted in Figure . Peer-to-peer configurations are often called ad hoc networks since they do not require any administration or preconfiguration. They also do not require the use of an access point, as each adapter communicates directly to another adapter without going through a central location.

Figure : Peer-to-peer WLAN configuration.

Peer-to-peer networks are very useful when a group of users need to communicate with one another in an unstructured way. These networks can be extended by adding a wireless access point (AP) to the configuration. The AP can act as a repeater between the devices, essentially doubling the range of operation. In addition, access points can provide connectivity to a wired network allowing wireless users to share the wired network resources. Figure illustrates this configuration.

Figure : WLAN configuration with access point.

In a SOHO environment, access points can be used to provide multiple users access to a single high-speed connection without having to run Ethernet wires to each computer. In a corporate environment, many access points can work together to provide wireless coverage for an entire building or campus. The coverage area from each access point is called a microcell. To ensure coverage over a large area, the microcells will overlap at their boundaries, allowing users to freely move between cells without losing connectivity. This movement between a cluster of access points in a wireless network is called roaming. Roaming is made possible by a handoff mechanism whereby one access point passes the client information to another access point. This entire process is invisible to the client.

In more advanced configurations, extension points (EP) may be used in conjunction with access points. These EPs extend the range of the network by relaying signals to client devices, other EPs, or to an access point. They do not have to be tethered to the wired network, making it possible to service far-reaching clients. One other piece of WLAN equipment is a directional antenna. It allows a signal to be extended to locations many kilometers away. At the second location, the antenna is then connected to an access point, which provides wireless LAN connectivity for the rest of the facility.

WLAN Standards
Two standards bodies, IEEE and European Telecommunications Standards Institute (ETSI) and one technology alliance (HomeRF) promote WLAN standards. In the IEEE 802.11 family of WLANs, three standards deserve individual attention, and a handful of others are worth a quick mention. The leading standard is 802.11b, or Wi-Fi, short for Wireless Fidelity. The clear challenger is 802.11a, which provides increased throughput at a higher, less cluttered frequency; the outside contender is 802.11g, which just completed the final stage of IEEE approval at the time of writing. Other WLAN standards that are worth consideration are HIPERLAN/1 and HIPERLAN/2. We will provide information on each of these standards to give you a firm understanding of their technical and business advantages.

802.11
The IEEE 802.11 specification was approved in July 1997, making it the first wireless LAN standard to be defined. It uses the same switching protocols as wired Ethernet, but allows communication to happen without wires, instead using unlicensed 2.4-GHz frequency radio communication. Two frequency modulation techniques are supported in 802.11: FHSS and DSSS. 802.11 products are not commonly sold anymore, as updated versions (802.11a and 802.11b) have taken its place, providing higher bandwidths at a lower cost.

802.11b/Wi-Fi
802.11b is the most popular standard in the 802.11x family. The specification was approved at the same time as 802.11a in 1999, but since then has achieved broad market acceptance for wireless networking. 802.11b is based on the DSSS version of 802.11, using the 2.4-GHz spectrum. Since DSSS is easier to implement than orthogonal frequency division multiplexing (OFDM), as used in 802.11a, 802.11b products came to market much sooner than their 802.11a counterparts. In addition, the 2.4-GHz spectrum is available globally for WLAN configurations, while the 5-GHz spectrum that 802.11a uses is for limited uses in many countries.

802.11b is able to reach a maximum capacity of 11 Mbps. This surpassed the 10 Mbps speed that is part of the original Ethernet standard, making 802.11b a practical alternative to, or extension of, a wired LAN. To help foster interoperability between 802.11b products, the Wi-Fi Alliance [formerly the Wireless Ethernet Compatibility Alliance (WECA)] has set up certification the aforementioned Wireless Fidelity, or Wi-Fi. Obtaining Wi-Fi certification ensures that 802.11b products will be able to interoperate with other Wi-Fi products globally. This certification, combined with the release of 802.11b products by leading networking companies such as Cisco, Lucent, Agere Systems, Proxim, and 3Com, has made 802.11b the leading WLAN standard.

The use of the 2.4-GHz band for communication has advantages and disadvantages. On the plus side, the 2.4-GHz spectrum is almost universally available for WLAN configurations. Initially, a few countries did not allow for its usage, but this has changed thanks to lobbying by industry groups. Additionally, 2.4-GHz signals are able to penetrate physical barriers such as walls and ceilings more effectively than higher frequencies can. The downside of using the 2.4-GHz spectrum is congestion. Since it is unlicensed, meaning anyone can use it without obtaining a special license, other electronic products also use this frequency for communication. Two common examples are cordless phones and microwave ovens. With the widespread use of this spectrum, there is a possibility that it will become overcrowded, resulting in too much interference for effective data communication. Hopefully, this will not be the case since any manufacturer of any product that uses the 2.4-GHz band is required to take interference into account in its product design.

One interesting point about the 802.11b specification is how it handles roaming between access points. The specification requires a method for roaming, but leaves the implementation up to the AP manufacturer. This will make roaming between different vendors' access points difficult, as it is unlikely that manufacturers will employ the same handoff routines.

In typical indoor office configurations, an 802.11b access point can communicate with devices up to 100 meters (around 300 feet) away. The further away a terminal is from the access point, the slower the communication will be. Devices within about 30 meters can usually achieve a raw data transfer rate of 11 Mbps; beyond 30 meters, the rate drops to 5.5 Mbps, and then to 2 Mbps around 65 meters away, and finally, to 1 Mbps around the outer edge. These numbers represent the anticipated coverage area and transmission speeds, but the products from each vendor will differ in performance. If you are looking to implement an 802.11b WLAN, it is recommended that you do a site survey to obtain the actual operating range and associated bandwidth for your location.

802.11b Security
When the IEEE created the 802.11 specification, it implemented a feature called Wired Equivalent Privacy (WEP) with the intent of providing basic levels of authentication and data encryption. As the name suggests, the goal of WEP is to provide an equivalent level of security as normally present in an unsecured wired LAN. This is clearly important, as wireless networks do not have the physical protection that wired environments do. Both 802.11a and 802.11b specifications use WEP.

For authentication, an access point that has WEP enabled will send a text request to the client to verify the client's identity. The client uses RC4 encryption with a secret key to encrypt the text, then returns the encrypted text back to the access point. Once received, the access point decrypts the text using the same key. If the text matches the text that was sent, then the client is authenticated and granted access. For encryption, WEP provides a 24-bit initialization vector that augments the WEP key. This vector changes with each packet, thereby providing a basic level of data encryption.

Unfortunately, both forms of WEP security present some concerns. For authentication, WEP supports no more than four keys and provides no mechanism for refreshing those keys on a regular basis. The result is that the same keys are used by multiple clients and access points and are never changed. This means that malicious users can "listen" to the communication stream and, by using freely available software, very quickly authenticate themselves to the access point. For the encryption layer, WEP uses RC4 in what is called a one-time-pad manner. The security of a one-time-pad is only as secure as the pad being used, which for WEP is the 24 bits. This means that the onetime-pad is repeated at least every 224 packets. For access points with moderate amounts of traffic, this is a matter of hours, hence, attackers monitoring the datastream could detect two messages encrypted with the same 24-bit initialization vector and be able to determine the keys and decipher the plain text.

Companies should realize that WEP was never designed to provide end-to-end security. It is intended for usage in conjunction with existing security mechanisms such as firewalls, virtual private networks (VPNs), and application-level security. The following are some suggestions for corporations that are using, or planning on using, WEP security as part of their WLAN:

Use a firewall to separate the wireless network from the wired network.

Have the wireless users authenticate with a VPN to access the corporate network.

Incorporate security at the application level for highly confidential information.

Implement dynamic key refreshing for the WEP keys.

Do not assume that WEP guarantees absolute data privacy.

Not all of the 802.11 WLAN security issues can be attributed to problems with WEP. Many of these issues have resulted from companies not using the WEP for its original purpose or from not using it at all. By implementing additional security mechanisms as listed, corporations can ensure secure wireless communication. In addition, the 802.11i Task Group is working additional levels of security for 802.11 WLANs. The first component of the 802.11i draft is currently being implemented in the form of Wi-Fi Protected Access. Wi-Fi Protected Access offers increased security over WEP.

802.11a
802.11a is a high-speed alternative to 802.11b, transmitting at 5 GHz and speeds up to 54 Mbps. Unlike 802.11 and 802.11b, 802.11a uses OFDM modulation technology. This, along with the difference in frequency, makes 802.11a networks incompatible with 802.11b networks. Due to the increased complexity of 802.11a, the first products did not reach the market until early 2002, with all the chipsets being provided by a single vendor, Atheros Communications. Since then other vendors have released 802.11a chipsets, helping 802.11a gain broader market acceptance and interoperability certification.

The Wi-Fi Alliance has included certification for 802.11a products within the Wi-Fi certification program. They are using the same name for both 802.11b and 802.11a to help reduce confusion in the market and to foster growth of the emerging 802.11a products. The Wi-Fi Alliance are hoping that Wi-Fi certification will have the same effect on the 802.11a market as it did on the 802.11b market. Certification gives consumers confidence that the products they are purchasing will work with other products based on the same specification.

The move to the 5-GHz band and OFDM modulation provides two important benefits over 802.11b. First, it increases the maximum speed per channel from 11 Mbps to 54 Mbps. This is a tremendous boost, especially considering that the bandwidth is shared among all the users on an access point. The increased speed is especially useful for wireless multimedia, large file transfers, and fast Internet access. Second, the bandwidth available in the 5-GHz range is larger than available at 2.4 GHz, allowing for more simultaneous users without potential conflicts. Additionally, the 5-GHz band is not as congested at the 2.4-GHz band, resulting in less interference.

These advantages come with some downsides. The higher operating frequency equates to a shorter range. This means that to maintain the high data rates, a larger number of 802.11a access points are required to cover the same area, versus 802.11b. While 802.11b access points have a typical range of 100 meters, 802.11a access points are often limited to between 25 and 50 meters. In addition, OFDM requires more power than DSSS, leading to higher power consumption by 802.11a products. This is definitely a disadvantage for mobile devices that have limited battery power. Another downside is that 802.11a and 802.11b products are not compatible. With the large number of 802.11b products on the market, this will have a negative effect on the adoption of 802.11a products. That said, both standards can coexist, and products are now on the market that support both 802.11a and 802.11b in a single chipset. This dual-mode approach is very attractive for users who want the advantages of 802.11a, with the backward compatibility and market penetration of 802.11b.

One final item to note about 802.11a is that the 5-GHz frequency is not universally available for WLAN products. Many European countries, as well as Japan, are resisting the adoption of 802.11a as a standard, leaving some doubt as to whether it will become a global standard as 802.11b has.

802.11g
IEEE 802.11g brings high-speed wireless communication to the 2.4-GHz band, while maintaining backward compatibility with 802.11b. This is accomplished on two layers. First, 802.11g operates on the same 2.4-GHz frequency band as 802.11b, with the same DSSS modulation types for speeds up to 11 Mbps. For 54 Mbps, 802.11g uses the more efficient OFDM modulation types, still within the 2.4-GHz band. In practice, an 802.11g network card will be able to work with an 802.11b access point, and 802.11b cards will work with an 802.11g access point. In both of these scenarios, the 802.11b component is the limiting factor, so the maximum speed is 11 Mbps. To obtain the 54-Mbps speeds, both the network cards and access point have to be 802.11g compliant. In all other aspects, such as network capacity and range, 802.11b and 802.11g are the same.

Since 802.11g offers the same speed as 802.11a, comparisons between them are inevitable. And because they both use OFDM modulation, the main differences result from their frequency ranges and corresponding bandwidth. The total available bandwidth at 2.4 GHz remains the same as with 802.11b. This results in lower capacity for 802.11g WLANs when compared to 802.11a. In addition, fewer channels are available, leading to a higher potential of conflicts. When we take into consideration the backward compatibility that 802.11g has with 802.11b, 802.11g becomes an attractive option for companies that have 802.11b installations.

Other 802.11 Standards
Just as 802.11g improved upon 802.11b, other 802.11 task groups are in place to improve upon the exiting 802.11x standards. The areas of concentration are security, quality of service, compliance, and interoperability. All of these are still in the task group stage of the specification process:

IEEE 802.11e. Aimed at providing quality of service (QoS) capabilities to enable reliable voice communication to complement 802.11b systems. 802.11e will also provide enhanced security and authentication mechanisms. It is expected to receive final IEEE approval in 2003.

IEEE 802.11f. Aimed at developing the recommended practices for an Inter-Access Point Protocol (IAPP) to achieve multivendor access point interoperability.

IEEE 802.11h. Aimed at enhancing the 802.11a High-Speed Physical layer in the 5-GHz band to make IEED 802.11a products compliant with European regulatory requirements.

IEEE 802.11i. Aimed at enhancing the 802.11 MAC layer to increase security and authentication mechanisms.

HomeRF
As the name suggests, HomeRF is a wireless LAN technology aimed at home wireless networking. It is based on the 802.11 FHSS standard, but enhancements have been made to meet the unique needs of the average consumer. HomeRF uses the Shared Wireless Access Protocol (SWAP). One of the major enhancements of SWAP is its support for high-quality voice communication. Additionally, the HomeRF specification incorporates the Digital Enhanced Cordless Telephony (DECT) standard. This allows cordless phones to use the same home networking infrastructure as PCs and appliances while providing advanced telephony features, including call waiting, caller ID, call forwarding, and personal ringtones.

The HomeRF specification has been designed for ease of use and price rather than bandwidth and performance. HomeRF networks provide a range of up to 50 meters (around 150 feet) with maximum speeds at 10 Mbps. The first generation of HomeRF products provided throughput of 1.6 Mbps. HomeRF uses the 2.4-GHz frequency band so it will experience similar interference as 802.11b from household appliances such as microwaves.

With wide industry adoption of 802.11b, HomeRF products have not been able to reach critical mass. The major advantages of HomeRF over 802.11b are ease of use, cost, and telephony support, all areas being addressed by 802.11b products and upcoming 802.11x specifications. For this reason among others, the HomeRF Consortium disbanded in early 2003, making HomeRF a defunct standard.

HIPERLAN/1 and HIPERLAN/2
The European Telecommunications Standards Institute (ETSI) proposed the High-Performance Radio Local Area Network (HIPERLAN) standard in 1992 to address the need for high-speed short-range wireless communication. This first version is commonly referred to as HIPERLAN/1. It is based on Ethernet standards, with its radio transmission taken from GSM. It uses the 5-GHz frequency band. The operating range and bandwidth is difficult to determine since HIPERLAN/1 did not experience commercial success. According to the specification, HIPERLAN/1 has data rates approaching 23.5 Mbps.

HIPERLAN/2 is the next-generation WLAN specification from ETSI Broadband Radio Access Networks (BRAN). It continues to use the 5-GHz frequency band, but with OFDM technology. It is able to achieve peak speeds of 54 Mbps with an approximate range of 150 meters (450 feet).

HIPERLAN/2 has been designed to address the various market segments where WLANs are used: enterprise networking, SOHO, and 3G wireless hotspots. To this end, it has incorporated QoS for real-time multimedia communication, efficient power consumption for portable devices, strong security and interoperability with Ethernet, IEEE 1394 (Firewire), and 3G mobile systems. The specification also permits roaming between HIPERLAN/2 access points, making it suitable for corporate environments. As of late 2002, HIPERLAN/2 still has not seen any meaningful adoption in either the consumer or corporate space.

WLAN Summary
The market demand for WLAN solutions is growing at a rapid pace across several market segments, including the home, office, and public hotspots. Deciding which technology is appropriate to use is not a trivial task, as all three WLAN specifications have strengths and weaknesses and because each WLAN deployment is unique. When evaluating a WLAN solution, make sure you take into consideration future needs, since the technology upgrade paths depend upon the original choice. The following are some key criteria for selecting the right high-speed WLAN solution for you:

Capacity requirements. If you are installing a WLAN for a large number of users, and population density is a concern, then 802.11a may be a good choice since it provides larger bandwidth to accommodate more users per access point. If not, 802.11b/g might be more appropriate.

Interoperability of wireless devices. Wireless LAN solutions from different vendors may not be interoperable, perhaps because of the frequency band used, the frequency modulation technology (FHSS, DSSS, or OFDM), or just due to the implementation of a particular vendor. Wi-Fi certification helps to ensure that 802.11b and 802.11a products will work with products using the same standard. (The first 802.11g products became available in January 2003.)

Timing of high-speed requirement. If high-speed access is needed immediately, a WLAN technology such as 802.11a or HIPERLAN/2 is probably the right choice. If it can wait, then 802.11b with an upgrade to 802.11g might be suitable.

Migration plan. If a WLAN solution is already in place, or if you are looking to take advantage of proven technology such as 802.11b, keep in mind the migration plans for incorporating higher speeds or, possibly, other frequencies. A range of dual-mode WLAN products are available that support both 802.11a and 802.11b.

Interference concerns. If interference is expected on the 2.4-GHz frequency band from products such as Bluetooth, cordless phones, or even microwave ovens, it might make sense to select a product that is using the less-crowded 5-GHz frequency band.

Range/penetration. Higher-frequency signals have shorter range and worse penetration than lower-frequency signals. In some ways, these effects are mitigated by the system manufacturers, but it is still a worthwhile consideration. In some cases, you may prefer a solution that cannot penetrate walls, to prevent eaves-dropping from outside parties. For longer range and better penetration, the 2.4-GHz standards such as 802.11b and 802.11g are better choices than those using the 5-GHz frequency band.

Power requirements. Does the device using the WLAN technology have a limited power source? If so, power requirements for each standard must be a factor. The rule of thumb is that higher frequencies require more power to transmit the signal the same distance as lower frequencies. This may not apply in all cases, but it is a safe guideline to go by.

Regulatory factors. Are there limitations imposed by your geographic location that you have to consider when choosing a technology? How about the availability of products in your region? These should be taken into account before making any decision.

Wireless Personal Area Networks (WPANs)

2009-11-06T03:50:00.000-08:00

The market for wireless personal area networks is expanding rapidly. As people use more electronic devices at home and in the office, and with the proliferation of peripherals, a clear need for wireless connectivity between these devices has emerged. Examples of the devices that need to be networked are desktop computers, handheld computers, printers, microphones, speakers, pagers, mobile phones, bar code readers, and sensors. Using cables to connect these devices with a PC and with each other can be a difficult task in a stationary location. When you add mobility into the mix, the challenge becomes daunting. If the setup and administration of a WPAN becomes simple and intuitive in the future for the end user, then the most concrete scenario for WPAN technology is cable replacement. This provides a compelling reason to use WPAN technology, and will open the door for more advanced applications in the future. Here are the main characteristics of a WPAN:

Short-range communication

Low power consumption

Low cost

Small personal networks

Communication of devices within a personal space

While providing these features, a WPAN has to achieve two main goals: broad market applicability and device interoperability. It is important that the WPAN specification addresses the leading device categories that require wireless connectivity in a way that is both easy to implement and affordable. The price point to make a technology attractive is $5 (U.S.) or less. At this level, device manufacturers are willing to incorporate a technology into a broad range of devices for both the consumer and business markets. Interoperability is also imperative. Wireless capabilities are not very useful if they do not allow a device to communicate with other devices and peripherals.

Three wireless standards are leading the way for WPANs: IrDA, Bluetooth, and IEEE 802.15. Each of these standards enables users to connect a variety of devices without having to buy, carry, or connect cables. They also provide a way to establish ad hoc networks among the abundance of mobile devices on the market. Each of these standards is discussed in the following subsections.

WPAN Standards
Many standards are available for personal area networks. Each standard has strengths and weaknesses, making it suitable for specific application scenarios. In some cases, more than one technology will be able to perform a required task, hence nontechnical factors such as cost and availability will factor into the decision as to which technology is more appropriate. Here we take a look at the leading standards in this space. The information provided will give you a solid understanding about where each standard is being used and for what purposes.

IrDA
IrDA, the acronym for Infrared Data Association, is an international organization that creates and promotes interoperable, low-cost infrared data connection standards. IrDA has a set of protocols to support a broad range of appliances, computing, and communication devices. These protocols are typically aimed at providing high-speed, short-range, line-of-sight, and point-to-point wireless data transfer. IrDA protocols use IrDA DATA as the data delivery mechanism, and IrDA CONTROL as the controlling mechanism.

Chances are that you currently own a device that has support for infrared communication. The Infrared Data Association estimates that more than 300 million IrDA enabled devices have been shipped, making it one of the most pervasive wireless technologies in existence. The original goal of IrDA was to provide a cable replacement technology, much like the other PAN standards. The idea was that two computers could communicate simply by pointing them at each other. For example, to print a document, you would simply point the infrared (IR) port at the printer and be able to send the data. No cables would be required.

Technically, infrared technology is well suited for such tasks. The following are some of infrared's features:

Communication range of up to 1 meter, although a distance of 2 meters can often be reached.

A low-power option for communication up to 20 centimeters. This requires 10 times less power than the full-power implementation.

Bidirectional communication.

Data transmission from 9600 bps to a maximum speed of 4 Mbps.

In theory, using IR for data transfer is a great idea. Unfortunately, even with such ubiquity it is rarely used for its original intent. This may be due to technical challenges in many early implementations, or more plausibly, to the line-of-sight restriction. For IR to work, the communicating devices have to maintain line of sight. This means that they have to situated within the operating range (typically up to 2 meters apart), point at each other, and have no physical impediments. In most office environments, this limitation is not practical for many peripherals such as printers or scanners. Using infrared to transfer data between two devices is more realistic. Two device users can use infrared to transfer information, such as electronic business cards, between one another. Users with Palm devices call this type of transfer beaming, as in, "Can you beam me your contact information?" Beyond user-to-user data transfer, infrared is not commonly used for information transfer, since most users do not use two devices with IR ports. While nearly all portable devices have one, the majority of desktops do not. Once again, this limits the effectiveness of IR as a mass-market data transfer protocol.

That said, there are some areas where infrared is frequently used. The IrDA CONTROL standard allows wireless peripherals such as keyboards, mice, game pads, joysticks, and pointing units to interact wirelessly with a host device, very often a desktop PC or gaming unit. A host device can communicate with up to eight peripherals simultaneously. The data transmission rate for IrDA CONTROL typically reaches a maximum at 75 Kbps, which is easily fast enough for the type of data being transferred by these types of devices.

One of the major advantages of IrDA from a device manufacturer's perspective is cost. IR ports can be incorporated into a device for as low as $1 (U.S.). This is a very low cost for implementing wireless communication into a device compared to other WPAN standards.

Bluetooth
Bluetooth is a standard for enabling wireless communication between mobile computers, mobile phones, and portable handheld devices. Unlike IR, Bluetooth does not require a line of sight between devices to be effective. It is able to communicate through physical barriers, typically with a range of 10 meters, although with power amplifiers, 100 meters is possible. Bluetooth uses the unlicensed 2.4-GHz spectrum for communication, with a peak throughput of 720 Kbps. It is expected that this throughput will increase to around 10 Mbps with future Bluetooth specifications.

The origins of Bluetooth date back to 1994 when Ericsson was researching ways to enable mobile phones to communicate with peripherals. Four years later, in 1998, Ericsson, along with Nokia, Intel, Toshiba, and IBM, formed the Bluetooth Special Interest Group (SIG) to define a specification for small form-factor, low-cost wireless communication. Since then, 3COM, Lucent, Microsoft, and Motorola have joined the Bluetooth SIG as Bluetooth promoters. In addition, well over 2,000 companies have joined the SIG as Bluetooth Adopter/Associate members. This all happened before a single Bluetooth product was commercially available, leading to unprecedented market excitement.

People were excited about the futuristic products that would soon be available, expecting that every device, from portable computers to home appliances, would soon incorporate Bluetooth technology. These devices would then interact with one another, transferring data files, contact information, security credentials, and even perform financial transactions. All of this would happen seamlessly without any technical knowledge required from the user.

Needless to say, the hype once again surpassed the technology. While Bluetooth will indeed enable those scenarios someday, right now it is most effective as a cable replacement technology. Since a line of sight is not required for communication, getting Bluetooth devices to interact with one another is trivial. Bluetooth provides an autodiscovery mode, whereby Bluetooth devices will automatically discover other devices that are within range. Once they are detected, they can start communicating. There is some concern that this will overload the 2.4-GHz spectrum as more Bluetooth devices become available. To address this issue, the Bluetooth specification defines three device modes:

Generally discoverable mode. This allows a Bluetooth device to be detected by any other Bluetooth device within its proximity.

Limited discoverable mode. Only well-defined devices will be able to detect a device in this mode. This mode will be used when a user has many Bluetooth devices and wants them to discover each other automatically.

Nondiscoverable mode. This makes the device invisible to other devices so it cannot be detected.

When two or more devices connect, they form a piconet, an ad hoc network that can consist of a maximum of eight devices. Every device in a piconet can communicate directly with the other devices. It is also possible to have networks with more than eight devices. In this case, several piconets can be combined together into a scatternet. In a scatternet configuration, not all devices can see each other; only the devices within each piconet are able to communicate. Figure helps to illustrate how this works. In this figure there is one scatternet consisting of five piconets; the hands-free mobile phone is a member of three different piconets and is able to communicate directly with the headset, the Bluetooth pen, and the access point, but is not able to communicate directly with the laptops, printer, or fax machine.

Figure : Bluetooth scatternet with five piconets.
The number of Bluetooth devices on the market is growing every day. It is common for mobile phones, PDAs, laptops, and peripherals to come equipped with Bluetooth chips. This has been made possible by the lowered cost of Bluetooth chipsets [currently around $20 (U.S.), with a targeted range of $5 to $10 (U.S.)] in conjunction with increased market demand. Users are now aware of the many compelling features that Bluetooth offers. The leading ones include:

Cable replacement

Mobile device networking

Global ad hoc networking

Support for both voice and data communication

Worldwide vendor and product support

Bluetooth Profiles
In order for Bluetooth to realize true ubiquity, interoperability is a key. Bluetooth devices from different vendors have to be able to communicate seamlessly. In order to promote this level of interoperability, the Bluetooth SIG has defined 13 profiles that device manufacturers can use when implementing their products. These profiles help ensure that Bluetooth products are built on a single foundation, allowing for true interoperability.

The entire second volume of the Bluetooth v1.1 specification is dedicated to profile definitions. Each profile is designed for a specific task. Four profiles are foundation profiles, providing the building blocks upon which other profiles are constructed. The other nine profiles are usage profiles. These describe actual usage cases where Bluetooth technology excels. Bluetooth profiles are not meant to be the definitive way to use Bluetooth technology but rather are aimed at providing standards for implementers to build upon. Device manufacturers will base their Bluetooth offerings on these profiles, ensuring that all Bluetooth devices will be able to communicate with one another.

Detailed summaries of each profile are provided in the Bluetooth profile definition book, which is over 450 pages long. If you are interested in obtaining this information, visit the Bluetooth Web site at www.bluetooth.com.

Bluetooth Security
Because cable replacement is one of Bluetooth's primary uses, the overall goal of Bluetooth security is to make the wireless connection at least as secure as cables would be. The Bluetooth specification defines security at the link level. Application-level security is not specified, leaving the developer to choose the security mechanism that is most appropriate for each particular application.

The Bluetooth specification defines several security measures that can be employed in various situations. Additionally, each profile definition outlines when security should be implemented for particular usage scenarios. Bluetooth communication can be encrypted for over-the-air communication and has built-in device authentication. The level of encryption is user-defined and can have a key size between 8 and 128 bits. This allows the user to determine what level of security is required. Note that a tradeoff exists between speed and security: Greater key lengths lead to slow communication. For authentication, each Bluetooth device has a unique address so the user can have some faith in the device with which they are communicating. (For an overview of mobile and wireless security, see Chapter 6, "Mobile and Wireless Security.")

802.15
802.15 is a specification driven by the Institute of Electrical and Electronics Engineers (IEEE) to develop consensus standards for short-range wireless networks or wireless personal area networks. It has similar goals to Bluetooth in that it looks to address wireless networking of portable and mobile computing devices such as PCs, PDAs, mobile phones, peripherals, and consumer electronics. The 802.15 WPAN Working Group was established in 1999 as part of the Local and Metropolitan Area Networks Standards Committee of the IEEE.

At the time of establishment, the 802.15 WPAN Working Group was aware of the Bluetooth specification and used parts of it as the foundation for the 802.15 standard. The 802.15 WPAN specification is aimed at standardizing the Media Access Control (MAC) and Physical (PHY) layers of Bluetooth, in the attempt to accommodate wider adoption of short-range wireless technology. 802.15 also deals with issues such as coexistence and interoperability within the networks. To accomplish this goal, four task groups have been established, each working on specific components of the 802.15 specification. They are:

802.15 WPAN Task Group 1: WPAN/Bluetooth. The WPAN Task Group 1 (TG1) has created the WPAN 802.15.1 standard based on the Bluetooth v1.1 specification. To accomplish this, the IEEE licensed technology from the Bluetooth SIG. Specifically, 802.15.1 defines the MAC and PHY specifications for wireless connectivity of devices that are either fixed or portable within the personal computing space. The spec also takes into consideration coexistence requirements with 802.11 wireless local area network (WLAN) devices.

802.15 WPAN Task Group 2: Coexistence Mechanisms. The 802.15 WPAN Task Group 2 (TG2) is developing the recommended practices to facilitate the coexistence of WPAN (802.15) and WLAN (802.11) technologies. Part of this task involves developing a coexistence model to quantify the mutual interference of a WPAN and a WLAN. Once approved, this outcome of TG2's work will become the IEEE 802.15.2 specification.

802.15 WPAN Task Group 3: High Rate WPAN. The 802.15 WPAN Task Group 3 (TG3) is chartered to publish a new standard for high-rate (20 Mbps or higher) WPANs. In addition to high data rates, 802.15.3 also has to provide a means for low-power and low-cost solutions to address the needs of portable consumer electronics, digital imaging, and multimedia applications.

802.15 WPAN Task Group 4: Low Rate-Long Battery Life. The 802.15 WPAN Task Group 4 (TG4) is chartered to establish a low-data-rate (200 Kbps maximum) solution with long battery life (many months to many years) and low complexity. It is intended to operate in an unlicensed international frequency band and is targeted at sensors, interactive toys, smart badges, home automation, and remote controls.

The 802.15 specification is still a work in progress as each of the task groups is at different stages in the specification process. TG1 has completed the 802.15.1 specification and has gotten approval from the IEEE Standards Association (IEEE-SA), while the other groups are still working toward that level. Once completed, the 802.15 WPAN specification will cover all of the current issues surrounding WPAN technology, including Bluetooth compatibility, coexistence with 802.11, high-data transfer rates, and low-power consumption solutions. The combination of all of these will make the IEEE 802.15 specification very attractive for WPAN infrastructure providers.

Frequency Fundamentals

2009-11-06T03:46:00.000-08:00

Before we can dive too deeply into wireless technologies, a brief primer on radio frequencies is required. Many of the wireless technologies in the WPAN, WLAN, and WWAN categories transmit information using radio waves. For this to take place, the data is superimposed onto the radio wave, which is also known as the carrier wave, since it carries the data. This process is called modulation. There are many modulation techniques available, all with certain advantages and disadvantages in terms of efficiency and power requirements. This summary of the various mechanisms will be helpful as you read this post. The modulation techniques are as follows:

Narrowband technology. Narrowband radio systems transmit and receive data on a specific radio frequency. The frequency band is kept as narrow as possible to allow the information to be passed. Interference is avoided by coordinating different users on different frequencies. The radio receiver filters out all signals except those on the designated frequency. For a company to use narrowband technology, it requires a license issued by the government.

Spread spectrum. By design, spread spectrum trades off bandwidth efficiency for reliability, integrity, and security. It consumes more bandwidth than narrow-band technology, but produces a signal that is louder and easier to detect by receivers that know the parameters of the signal being broadcast. To everyone else, the spread-spectrum signal looks like background noise. Two variations of spread-spectrum radio exist: frequency-hopping and direct-sequence.

Frequency-hopping spread spectrum (FHSS). FHSS uses a narrowband carrier that rapidly cycles through frequencies. Both the sender and receiver know the frequency pattern being used. The idea is that even if one frequency is blocked, another should be available. If this is not the case, then the data is re-sent. When properly synchronized, the result is a single logical channel over which the information is transmitted. To everyone else, it appears as short bursts of noise. The maximum data rate using FHSS is typically around 1 Mbps.

Direct-sequence spread spectrum (DSSS). DSSS spreads the signal across a broad band of radio frequencies simultaneously. Each bit transmitted has a redundant bit pattern called a chip. The longer the chip, the more likely the original data can be recovered. Longer bits also require more bandwidth. To receivers not expecting the signal, DSSS appears as low-power broadband noise and is rejected. DSSS requires more power than FHSS, but data rates can be increased to a maximum of 2 Mbps.

Orthogonal Frequency Division Multiplexing (OFDM). OFDM transmits data in a parallel method, as opposed to the hopping technique used by FHSS and the spreading technique used by DSSS. This protects it from interference since the signal is being sent over parallel frequencies. OFDM has ultrahigh spectrum efficiency, meaning that more data can travel over a smaller amount of bandwidth. This makes it effective for high-data-rate transmissions. The drawbacks of OFDM are that it is more difficult to implement than either FHSS or DSSS, and consumes greater amounts of power.

Wireless Networks

2009-11-06T03:42:00.000-08:00

Wireless network technology is one of the hottest topics in mobile computing. Everyone has an opinion on the state of the third-generation (3G) wireless networks, the effect of Bluetooth for personal networks, and which wireless local area network technology will dominate the market. Even though not all mobile applications require wireless connectivity, there is no doubt that wireless technology is one of the main driving forces behind mobile computing.

This post provides an overview of the four main categories of wireless networks: wireless personal area networks (WPANs), wireless local area networks (WLANs), wireless wide area networks (WWANs), and satellite networks. For each category we summarize the prevalent technologies and discuss what the future holds. By reading this post you will gain an understanding of which wireless network protocols are being used and for what types of applications. This knowledge will be valuable as you continue through the book to learn more about the design and development of mobile and wireless applications.

Overview of Wireless Networks
Wireless networks serve many purposes. In some cases they are used as cable replacements, while in other cases they are used to provide access to corporate data from remote locations. Much of the industry hype surrounds third-generation wide area networks that provide broadband wireless connectivity to users on a national basis. These networks are now commercially available (in larger urban centers) in most first-world regions. At the same time, breakthroughs in short-range networks are also generating excitement. As users carry around multiple devices, a need arises for an easy, effective way for them to communicate; and what is easier than wireless?

For the purpose of our discussion, wireless networks will be divided into two broad segments: short-range and long-range. Short-range wireless pertains to networks that are confined to a limited area. This applies to local area networks (LANs), such as corporate buildings, school campuses, manufacturing plants or homes, as well as to personal area networks (PANs) where portable computers within close proximity to one another need to communicate. These networks typically operate over unlicensed spectrum reserved for industrial, scientific, medical (ISM) usage. The available frequencies differ from country to country. The most common frequency band is at 2.4 GHz, which is available across most of the globe. Other bands at 5 GHz and 40 GHz are also often used. The availability of these frequencies allows users to operate wireless networks without obtaining a license, and without charge.

Long-range networks continue where LANs end. Connectivity is typically provided by companies that sell the wireless connectivity as a service. These networks span large areas such as a metropolitan area, a state or province, or an entire country. The goal of long-range networks is to provide wireless coverage globally. The most common longrange network is wireless wide area network (WWAN). When true global coverage is required, satellite networks are also available.

Wireless Communication

2009-11-06T03:34:00.000-08:00

Three basic connection options are available for obtaining wireless communication from a wireless device: two-unit, detachable, and integrated.

Two-Unit Configuration
Two-unit connections require two pieces of equipment to work together, such as a PDA and a cell phone, as shown in Figure. One unit provides the wireless connectivity for the other unit to use. These devices can communicate with each other in a variety of ways:

Cable connection. This involves having a physical cable connecting the cell phone and mobile device. The phone must have wireless data support as well as an interface cable to the device of choice.

Infrared connection. This involves lining up the Infrared ports on the cell phone and mobile device for communication. A direct line of sight is required for this solution to work. In addition, only selected phones have infrared support available.

Bluetooth connection. Bluetooth may be the best option for two-unit connectivity. It allows a mobile phone to provide connectivity through a personal area network (PAN) up to a range of about 10 meters. A direct line of sight is not required, so it is possible to have the cell phone in a different location from the mobile device. This will become an increasingly popular option as more Bluetooth-enabled devices are released.

Figure : Two-unit configuration.
The advantage of the two-unit configuration is that you can choose each device based on its own functionality, and you do not have to sacrifice features for wireless capabilities. The configuration also provides a great degree of flexibility. If one device becomes outdated or malfunctions, it can be replaced without having to replace the entire system. This is especially appealing when the data device is a laptop or PDA that may not need to be replaced as frequently. In addition, the cell phone can potentially provide the wireless communication for several other devices.

The downside to this configuration is its complexity. Both the cell phone and the mobile device have to be configured properly for this to work. When Bluetooth is not available, the cable or Infrared connections can become cumbersome.

This setup is recommended only where occasional wireless connectivity is required. When frequent access is necessary, it is worthwhile to investigate some of the other options available.

Detachable Configuration
A detachable configuration involves using a plug-in module or clip-on attachment to a mobile device to provide wireless connectivity. These additional modules can provide connectivity to a variety of wireless networks with little configuration. For the plug-in modules, either CompactFlash or PCMCIA cards can be used. This obviously requires a device that has a slot for this type of peripheral. For devices that do not have integrated CompactFlash or PCMCIA slots, external jackets are often available. These jackets (often called sleds) provide the support for CompactFlash or PCMCIA cards.

Note Some of the wireless modems on the market also include support for voice calls. An example of this is the Sierra AirCard 555, which provides CDMA2000 1x wireless data as well as voice capabilities.

The benefit of using these interfaces is that multiple wireless modems are available, providing connectivity to several wireless networks including WLANs, WANs, and PANs. You can then switch interface cards as you move into different wireless environments. Cards are also available that support connecting to multiple network protocols in one unit.

In some cases, the only available option is a clip-on modem. This is similar to the external jacket, except that the modem is incorporated directly to the unit. These modules are often purchased in conjunction with a wireless service plan since they only provide access to a single wireless protocol, most commonly a wireless WAN.

The majority of the PDAs available now use a detachable configuration for wireless connectivity. It allows users to select the PDA and wireless component separately, but at the same time have them integrate well together. The disadvantage is that the wireless modem uses the open expansion slot so other peripherals cannot be used at the same time.

Integrated Configuration
An emerging trend is to enclose wireless connectivity within the mobile device. This has always been the case for voice-oriented devices such as cell phones and smart phones, but is a new concept for many handheld devices. This configuration has many advantages, as it alleviates complexity and provides tight integration between the mobile OS and wireless modem. Applications for these devices can be designed to take advantage of the wireless modem, knowing that it is always going to be present. Troubleshooting is also simplified, since there is only one manufacturer involved in the solution.

On the downside, some flexibility is lost. The user is now limited to the wireless net-work type that has been integrated into the device. In addition, it may become more difficult for developers to calculate the amount of power an application requires, as they will have a hard time differentiating between the power that the application requires and that of the wireless modem.

For users who will be using wireless communication frequently or who are looking for a very intuitive, user-friendly experience, integrated configurations are ideal. Devices are available for a variety of wireless networks. Many ruggedized devices with integrated wireless LAN access have been on the market for some time, while integrated public WAN devices are just now being deployed on a large scale. As devices continue to evolve, it may become practical to carry a single device for both data and voice communication.

Mobile Devices

2009-11-06T03:30:00.000-08:00

A wide variety of mobile devices are available to address a broad range of applications and users. They range from very inexpensive Web-enabled devices to high-end customized tablets, with laptops, a variety of PDAs, and smart phones in between. Along with size differences come variations in the features and performance that these devices provide. No matter which type of mobile application you are looking to deploy, a device is available that will meet your needs.

This post provides an overview of the mobile device market, with an emphasis on the devices that are most appropriate for m-business solutions. For each device category we will look at the leading features, such as screen size, data input mechanisms, wireless support, and storage space. A table summarizing the device manufacturers and the class(es) of devices they sell is also provided for quick reference. This information should be helpful when deciding which device classes are most appropriate for a particular application and which manufacturers produce these devices.

Device Overview
Of all the components in a wireless solution, the mobile device gets the most attention. It is the only part of a mobile solution that the end user is in contact with. When a problem arises, some aspect of the mobile device is often held accountable. This may be the wireless connectivity, mobile operating system, input mechanisms, or performance characteristics. In any case, the application developer absolutely must be intimately familiar with the device or devices being used in order to take advantage of their unique capabilities.

Mobile devices come in all sizes with a wide range of features. Choosing the correct device involves evaluating a variety of criteria other than just cost. Two of the major factors that need to be considered are the data input mechanism and wireless connectivity options. Each of these is described in detail later in this section. Some of the other major areas that should be given special attention include the following:

Device size and weight.

Available memory for applications and data.

Processor speed: This will affect the types of applications that will be able to run on the device.

Screen characteristics such as size, color depth, indoor and outdoor suitability.

Mobile operating system support: Can it be upgraded when a new version of the operating system is released?

Expansion slots for adding peripherals such as more memory, wireless modems, GPS receivers, or digital cameras. Looking into what peripherals are available is also a good idea.

Battery life (this is a big one).

Integrated features such as digital cameras, keyboards, infrared, and Bluetooth.

Software support, including third-party applications, development tools, mobile browsers, hardware drivers, as well as others that may be applicable to your particular situation.

These cover some of the major factors that should be considered, but there are bound to be others specific to the solution being implemented. When you are researching mobile devices, the vendor Web sites are a great place to look first, but keep in mind the information provided will not be very objective. Many other information sites are aimed at developers and business managers alike that can help make the device selection process more effective. The overview of the device categories later in this post will also help you become familiar with which devices are available for the enterprise market.

Input Mechanisms
Along with device size and power, the data input mechanism is one of the most important aspects of selecting a mobile device. This does depend on the application, and the levels of user interaction required, but for most m-business applications where a substantial amount of data is entered into the application, data input options have to be given strong consideration.

Mobile data devices receive their properties from two areas: mobile phones and desktop PCs. Both of these have specific design goals and constraints. Mobile phones are designed to be efficient and simple, allowing for single-handed operation by inexperienced users. PCs are designed for power and richness. Mobile data devices have to compromise between the two to provide various levels of functionality and richness. When it comes to methods of data input, several options are available.

Keypad Input
Mobile phones typically implement a 12-digit keypad. This is very intuitive and effective for numerical input but cumbersome and awkward for entering text. This is because each key on a keypad represents three characters. Users have to press a key multiple times to enter a single character. Since mobile phones are primarily designed for voice usage, it is unlikely that the keypad will change anytime soon. That said, there are technologies available that make entering text easier. One of these is called T9, which stands for Text on 9 Keys. This is a predictive text input technology that allows a user to input words by pressing only one button per letter. T9 translates the button press sequences into words. It does not work in all cases, but when it does, it is about twice as fast as using traditional multi-tap systems. America Online, the owner of T9, estimates that it is accurate 95 percent of the time.

Device manufacturers are constantly looking for ways to make keypad text entry more effective. Toggle sticks, rollers, and touch screens will help to alleviate this problem in some areas, but do not expect fast data entry to be a reality on a keypad-driven device anytime soon.

Pen-Based Input
One of the breakthroughs for handheld devices was the introduction of touch screens for pen-based input. This allows a user to enter data using a stylus, without requiring any form of physical keyboard or keypad. Several pen-based input mechanisms are available. Deciding which ones to implement will depend on the mobile operating system and device being used. The most common types of pen-based input are:

Soft keyboards. The most approachable method of entering text on mobile devices is by using a soft keyboard, a keyboard displayed on the screen. Users enter data by pressing "keys," just as they would on a physical keyboard. This method is very easy to learn and use, but it is also takes up screen space and can be limiting in terms of input speed. It is often used as a backup mechanism when other forms of data input are not effective.

Character recognition. Character recognition works by interpreting which letters a user is entering on the screen. There is usually a specific area on the screen for users to construct the characters. The Windows CE operating system from Microsoft provides this capability. Software runs locally on the device to do the interpretation. The letters have to be constructed fairly accurately for them to be understood. This is usually not a problem for small amounts of data, but can be a challenge for users who need to enter data quickly. They often find the characters difficult to write, leading to mistakes.

Graffiti. Palm OS introduced a new form of character recognition based up on simple character-set called Graffiti. The Graffiti characters allow for quicker data input since the letters are easy to input and recognize. There is a learning curve involved, but once Graffiti is mastered, data can be input quickly with few errors.

Handwriting recognition. Some forms of handwriting recognition work by taking screen captures of the inputted text, while others actually interpret written characters. The interpretation solutions take character recognition to a new level. Instead of being able to interpret only a defined set of characters with predetermined strokes, handwriting recognition attempts to interpret a user's personal style of text entry. This requires sophisticated software and powerful hardware to do the analysis. Microsoft is implementing forms of handwriting recognition on its Tablet PC platform.

Keyboard Input
Even with the advances being made in other forms of data input, the keyboard remains the most efficient and easy to use (especially for Western languages such as English). Mobile devices have many ways to take advantage of keyboard data entry. Laptops and handheld PCs come equipped with physical keyboards, while the smaller palm-sized PDAs often support keyboards as a peripheral. These keyboards are usually attached as a clip-on unit or via a cable, but wireless connections are also an option. In addition, most PDAs have PC companion software, allowing the user to enter data such as contact information on the PC. Some handheld devices have taken the step of incorporating a keyboard into the unit itself. This is accomplished with small thumb-based keyboards at the bottom of the unit. Research in Motion (RIM) was the first to incorporate this concept into its BlackBerry devices. With its revolutionary design, RIM has attracted a wide variety of users to its devices, prompting other companies, including Handspring and Sharp, to adopt the thumb-sized keyboard as the means for data input.

Voice Input
Voice input is both effective and easy to use. Simple voice commands, such as initiating a call or looking up a contact, can be executed directly on the mobile device. This works by prerecording voice commands into the device. When a voice command is entered, it is compared to the recorded message and executes the corresponding action. Many mobile phones come equipped with this feature.

For more advanced voice applications, such as looking up product information or executing a bank transaction, the voice recognition software resides on a server called a voice gateway. These gateways are run on powerful machines that are capable of running automatic speech recognition and text-to-speech software. This software is capable of understanding complex commands—such as "What is the weather going to be like on Friday in Waterloo?"—and returning the appropriate spoken response. Many of these applications use proprietary Interactive Voice Response (IVR) systems or VoiceXML, an emerging voice standard. (If you are interested in learning more about VoiceXML