Defining a Wireless Solution
5.6.2 Example Architecture: Wireless LAN
- Application Hull Trading wanted to give its derivatives traders access to current pricing information and to capture a record of trades as they occurred. As mobile workers on the floor of an exchange, these traders previously had to rely on hand signals and runners to obtain information from individuals using desktop systems.
- Information The pricing information that traders needed included real-time bids, offers, and other proprietary information. This information was already available on site through a wired network connection, making it simply a matter of transmitting the data to the floor. As transactions completed on the floor, that data would be transmitted to a local server to be forwarded to a central database.
- Device Traders needed to look up information and execute trades quickly. With speed as a primary requirement, data entry had to be fast, precluding keyboard-based input. Since traders would be physically standing on the floor, they needed a device they could easily hold in their hands, that wasn't too weighty, that would remain charged during the course of trading hours, and that allowed them to access information using one hand. A pen-based handheld PC from Fujitsu Personal Systems fulfilled these requirements.
- Network Traders were located within a main, indoor area, but were mobile within that space. Network choices were narrowed down to short- and medium-range solutions given the local coverage needed. With a lot of movement on the floor, an infrared network was obviously inappropriate—traders could not stay in close, unobstructed proximity to network transceivers. The range limitations of Bluetooth would not work within the exchange. A WLAN solution was selected for its ability to support mobile traders throughout the entire trading area despite physical obstacles.
5.6.3 Example Architecture: Data Capture
- Application UPS wanted to standardize its systems for tracking packages in its distribution centers. The wireless application had to be able to capture data for each package traveling through a center, to enable the company and its customers to track a shipment in real time. Package sorters would use the application to collect data encapsulated in the bar code affixed to each package.
- Information The goal of this application was to improve the way that data was transmitted from the point of collection on the sorting line to the back-end databases. Since this data was already being collected and tracked via other means, the existing information architecture would suffice for the new wireless implementation.
- Device The users for the application were package sorters handling the packages moving on belts through the distribution center. The chosen device had to allow the workers to be mobile at their station, permit hands-free usage so that workers could continue to handle packages, and be free of parts or cables that might snag in the moving equipment. The device also had to support bar code scanning, and contain appropriate integrated wireless communications capabilities.
To meet these requirements, two devices were chosen. The final selection was inextricably tied to the network options chosen (see below). The first device would perform the bar code scanning function. To free the workers' hands and avoid cabling, UPS chose a cordless, optical, bar code scanner mounted in a ring and worn on the finger. No commercial device was available that met these specifications, so Symbol Technologies was tapped to develop a custom device. To move the data scanned by the ring device to back-end systems, some type of wireless capability was needed. The size of the ring device precluded using a modem or WLAN adapter, but a small Bluetooth chip could be integrated without any problem. The disadvantage of using Bluetooth was that its range was insufficient to transmit the data straight to an access point located a distance away from the worker. Another device was needed to effectively "stage" the data and forward it via a more powerful network technology such as a WLAN.
The second device had the same requirements as the first device—it could not impede the workers' movements and could not have cables—but would necessarily have to be larger than the ring device to accommodate integrated WLAN capabilities. The final choice—a belt-worn terminal that would receive data sent from the ring device and forward it via a WLAN. Again, no commercial device existed with integrated Bluetooth and WLAN capabilities, so Motorola was chosen to develop a custom device. The cost savings anticipated from the wireless solution were deemed sufficient to justify the investment in these custom devices.
- Network Given that the users of the solution—the package sorters—were located in a relatively contained physical space—a distribution center—short- and medium-range wireless networks were potential solutions. The distance over which data would be transmitted was within the range of a WLAN solution. But as noted above, device considerations (the small size of the ring scanners) precluded the use of a unified WLAN solution. The remaining possibilities, infrared and Bluetooth networks, could handle the size constraints, but faced other issues. Infrared technology was eliminated because the workers' hands were constantly in motion and obstacles, such as packages and equipment, meant that line-of-sight requirements could not be met. Bluetooth, with its small chips, would work in the ring devices but was not robust enough to transmit data over the distances required in the distribution centers. A dual-network solution was needed to pick up the Bluetooth transmitted data, and then pipe it to the transceivers strategically located through the center. The best candidate for that task was a WLAN.
Choosing a dual-network solution posed device challenges since an integrated Bluetooth/WLAN device did not exist. Developing a device that could interact with both types of networks took some ingenuity. Since Bluetooth and WLAN networks operate in the same 2.4 GHz radio frequencies, signal conflict was a foreseeable problem. Symbol Technologies came up with a solution that allowed the device to pick up Bluetooth signals, and when the spectrum was quiet on the Bluetooth front, transmit the data over the same frequency to a WLAN access point.
5.6.4 Example Architecture: National Tracking and Location
- Application Penske Logistics wanted to offer its customers more timely access to performance and logistics data, allowing them to monitor service levels among their supply chain partners. Penske designed three different applications to gather the necessary data: an application to improve communications between dispatcher and driver and transmit time-sensitive information; an application to track incoming and outgoing shipments at its cross docks; and an application to capture detailed data about goods picked up and delivered. The wireless applications needed the following abilities:
- Locate trucks and communicate with drivers to provide route information, pickup and delivery information, and route or schedule changes
- Track events such as arrivals, departures, and downtime, and communicate these events in real time to the internal logistics management system
- Track, locate, and manage inbound and outbound freight at cross docks
- Collect detailed delivery and pickup information for later uploading to the logistics management system
- Capture customer signatures and print receipts, if desired
- Information Several types of data were implicated in the solution, including:
- Bar code and other detailed freight and package information collected in the field and uploaded to internal systems intermittently
- Arrival, departure, and other time-dependent information, originating in the field and transmitted to headquarters in real time
- Alerts, schedule changes, and route information, originating at headquarters and sent to trucks in real time
- Inbound and outbound freight information tracked, collected, and managed at cross docks
- Device Application requirements indicated that more than one device type was needed. For the truck fleet, two devices were chosen. First, GPS locators were installed on each truck to enable communications between dispatch centers and drivers no matter where the trucks were located. Second, to communicate route information, arrival and departure data, and freeform messages between driver and headquarters, another device was needed, one that would have data input capabilities for the driver. A larger-sized device with a keyboard was acceptable because the device would be mounted in the truck, drawing battery power from the engine. In addition, the device had to support real-time communications via a satellite network. QUALCOMM's OmniTRACS unit was chosen, a rugged device with integrated satellite communication capabilities. To collect detailed data on pickups and deliveries, a third device was chosen. These devices had to be portable so drivers could easily carry them, and had to be capable of capturing data on labels as well as customer signatures. A handheld PDA from Symbol Technologies was chosen for the task. A fourth device was needed at the cross docks to locate, track, and manage incoming and outgoing freight. This device had to be portable and rugged, and needed WLAN capabilities to transmit the tracking information to an internal system, leading to the selection of an Intermec unit.
- Network With trucks traveling virtually anywhere in the U.S., relaying real-time information would require a WAN. Because trucks would often travel in remote or rural places where digital cellular coverage was spotty or unreliable, a satellite network with ubiquitous coverage was chosen. To minimize the number (and expense) of satellite transmissions, only certain time-sensitive information (arrival times, departure times, downtime) is sent via satellite. At the cross docks, where incoming and outgoing packages and freight are scanned, tracked and managed, a medium-range WLAN solution was selected since it allowed dock workers and equipment to be mobile without the constraints of cables. Finally, the more detailed pickup and delivery information (number of parts, pieces, etc.) was not needed in real time, and could remain stored in the hand-held unit until a driver finished his route. This information would then be uploaded into internal systems, using a cradle and wired network connection.
National Tracking and Location Architecture
by Ian S. Hayes
For the full text, visit http://www.phptr.com
©2002 Pearson Education. All Rights Reserved.
# # #
Page 10 of 10