Wireless Application Factors around Accessing Remote Data

As mentioned earlier, there are many factors when planning a mobile solution. These factors are mentioned all through this book, but this section will focus on issues related to connectivity. If you are planning your company's first smart device application, this section serves as a starting point.

Application Factors

The first basic issue to research is the location of the data. This should lead to several questions like the following:

• Must the device remain connected to the back end while using the application? This scenario is more typical of a manufacturing environment where local access is direct to the company LAN. If required for a device that is outside of the office, then a wireless provider will be sought. Also, the need for real-time data could be different when inside, rather than outside, the firewall and is specific to the application.

• Can the device connect periodically to the back end? This is more typical of devices "in the field" in two scenarios. The first is where devices contain information related to a field activity and the information is used as a reference. The second is where a field person collects information that is periodically sent to the back-end system.

• Is the back-end data located on a machine so that it is accessible from the network or Internet? Many mobile applications will be enhancements to existing corporate or department applications; therefore, systems planning will be required. While not specific to mobile-application factors, this issue does exist frequently. How many applications do you know about that started as a stand-alone PC application and evolved into some type of multiuser system?

• Can enough of the business logic from the back end be duplicated on the device in order to make the application and returning data valid? There are several issues here. First, the processing of a mainframe system cannot be moved to a mobile device (yet) due to memory and processor constraints. Second, the business logic of an existing application should exist in such a form that it can be factored into manageable pieces, some of which can be reused on the device. These issues frequently arises for organizations that have developed so called fat clients that later need to be broken up and their business logic distributed to the middle tier. The existence of good data validation and middle-tier logic make the process of developing a smart device application that much simpler because the logic can be reused rather than rewritten.

Connection Type and Distance

Of these questions, two were related to the location of the data and how often it is updated. Related to these questions is the issue of how far the device is from network. Or in other words, what are the connectivity options based on where the device will be used? The following lists several options:

• Direct connection: This is available via the cradle and ActiveSync, which provide Internet access to the device (one might argue that a mobile device connected via a data cable to a cellular phone fits the criteria; however, this belongs to the cellular network category). This might be required by companies that do not trust wireless fidelity (Wi-Fi) or the 802.11x standard, which is discussed below. These types of connections can be made from virtually any wired access point, inside or outside the LAN.

• IrDA: Some infrared devices can act as network connections if they are within three feet and have an unobstructed line of sight to the server device. This includes not only some cell phones, but also some wireless access points.

• Personal area network (PAN): If the device will be within 30 to 100 feet of the network connection device, smart devices that support PAN connectivity are an option. This is probably known to most as BlueTooth technology, a standard that allows wireless communication between devices at short distances and provides bandwidth up to 1Mbps. One scenario would allow for a device to communicate with a BlueTooth-enabled access point; this would be an in-office scenario. In another scenario, the device would communicate with a cellular phone in order to access the Internet; this would be an in-the-field scenario. In these scenarios, the next critical factor is the bandwidth of the base device. Obviously, an access point would be preferred, because it is connected directly to a traditional LAN (10 to 100 Mbps) instead of a cellular phone, which uses connections that range from 14.4 to 128 Kbps. The PAN standard, also known as WPAN, is managed by the IEEE 802.15 Group.^[1] They are working with another group called the BlueTooth Special Interest Group (SIG),^[2] which based the BlueTooth standard on work previously done in IEEE activities. This cooperative effort is now known as 802.15.1, where BlueTooth is the PAN standard.

  ^[1] The official Web site for the IEEE 802.15 Working Group is http://grouper.ieee.org/groups/802/11.

  ^[2] The home page of this group is www.bluetooth.com.

• WLAN: This standard provides for devices up to one mile away to connect to a base station, otherwise known as an access point, which is the connection to the LAN or Internet. The specification typically includes one of the IEEE 802.11 wireless protocols that provides an 11-Mbps connection. Many corporate environments have embraced this wireless network standard, but corporations are cautious about deploying this technology due to its ease of use by noninvited outsiders. The Wi-Fi Alliance is a group that provides certification of 802.11b-based products. This group provides a certification process so that consumers can have confidence that a purchased wireless product is interoperable with other Wi-Fi products. As of this writing, about 200 member companies have manufactured over 500 different certified products. Therefore, it is a good idea to ensure that purchased products have the Wi-Fi logo.

• Wide area network (WAN): WANs are networks provided by the cellular companies and provide reach for mobile devices that span entire continents. There are a variety of network standards and a plethora of service providers; consequently, there is no universal standard. The transfer rates range today from 14.4Kbps to 114Kbps, depending on network type; however, providers are pushing this envelope as data services become mission critical. The vendor choices will be constrained by geographic region; therefore, the vendor's network type will affect the application's throughput and operation cost (because some vendors bill based on time, while others bill on amount of data). The network types will be mentioned throughout this section; however, take a moment to review the types in the Table 4-1. Currently, the technology race is composed of GSM, CDMA, and TDMA, while the older CDPD is widely used in metropolitan areas. GSM has the majority of the world's subscribers in the form of cellular and wireless users. A new standard, GPRS, is growing as it provides GSM networks more users running at higher speeds on the same capacity. In reviewing this industry, acronyms for the next generations of these networks will appear, like those for second generation (2G) and third generation (3G). The good news is that wireless communications is a very competitive global environment and continued improvements are to be expected.

• Satellite: As an extended form of WAN solution, satellite solutions do exist. While expensive, some applications require this type of communication. Examples include devastated environments or remote regions. The speeds are typically less than the 9.6Kbps, and the costs can be much higher than those for typical WAN options.

The various options for connecting smart devices are illustrated in Figure 4-1, with those spanning smaller distances nearer the center of the circle.

Throughput

For this discussion, "throughput" is defined as how much data can be moved through a network connection in a given amount of time. For 802.11 connections, this is not an issue at 11 MB. But for others, consider the following questions:

• For a remote connection, will the available providers' network types have enough throughput? In scenarios where connections cannot be maintained due to either cost of the call or intermittent connectivity, this will require that data be cached locally and synchronized periodically. If the application requires that data be current, throughput will be a factor, especially when the amount of data is large.

• For slower connections, will the slower connection last long enough for an acceptable synchronization? This question raises multiple issues, including throughput, battery power (see the following), intelligent and reliable synchronization, and the reliability of the vendor's network.

Many of these considerations are illustrated in Figure 4-2, which shows the kinds of application scenarios that might be suitable for the various types of connections discussed previously.

Battery Power

As you might expect, battery power is always an issue with mobile devices, and it becomes an even more prominent one when those devices use power for remote connections. As a result, the following basic questions must be asked:

• Does the attached communication hardware drain the mobile device's battery? In all scenarios, communications will decrease the device's battery power more quickly than it will when a connection is not active. The difference in power consumption can be quite dramatic and can halve the effective battery life of the device (or worse).

• Will the attached or integrated communication hardware be used for extended periods due to slower connections? Although it may seem obvious, this issue has to be considered. However, there are options, including purchasing additional batteries, using chargers in vehicles, and cradling the device (if the application allows).

Communication Hardware for the Mobile Device

There are different ways that the mobile device will connect to the communications hardware. Each has varying costs and possible usage fees.

• Integrated: This is a specialized device where the communication type agrees with the application factors and provider options. Some devices, like the Pocket PC Phone, are integrated with GPRS connectivity and, therefore, work as data or cellular connections. Vendors, including Casio, Intermec, and Symbol, have ruggedized products with CDPD, GSM, or WLAN (802.11) capabilities.

• Two body: This scenario requires that a mobile device have some type of communication with another device that serves as the mobile device's communication hardware. Examples include a cell phone with a data cable, using a BlueTooth-enabled cell phone, an infrared-equipped cell phone, or even the old fashioned modem.

• Detachable clip-on or plug-in module: Most mobile devices provide a way to add other hardware. For example, the Pocket PC devices support sleeves that have additional slots for PCMCIA cards or CompactFlash cards. Therefore, a vast number of cards fits into this category. All connectivity types are covered, including WLAN and wireless WAN (WWAN). Some sleeves have the communication hardware integrated like the Novatel CDPD Modem.

Cost

As always costs are a factor when determining how to provide connectivity to a mobile device, and so, the following considerations come into play:

• Based on the provider type and the amount of data, what is the communication cost? There are several different billing models for WAN links. Models are based on the amount of data transmitted or the duration of the connection, or they are fixed. Obviously, a fixed model is preferred when large amounts of data need to be transmitted.

• Have all of the hardware costs been considered? In some cases, hardware that connects to the device will have to be purchased. If talking about PANs or LANs, access points have to be included as well. If a company has existing mobile hardware that does not have integrated communications, the resulting purchases have to be considered in the project planning.

• What is the price of developing a software driver? Although it is not typical for network communications, consider the scenario of communicating with hardware that is not supported in the Compact Framework. For example, if data collection is done on a special hardware device, a driver or an interface to the driver may have to be developed. The cost of this development and its maintenance should be included in the planning.

There are plenty of issues to consider when accessing data remotely. When analyzing the application scenario, start with the application factors. This will usually drive the rest of the issues.