|
This excerpt is from Chapter 9 of Fixed Mobile Convergence and Beyond, Unbounded Moible Communications, by Richard Watson. Watson observes that solutions targeted to meet evolving communication requirements are often labeled "fixed/mobile convergence" (FMC). He argues in earlier chapters that delivery of communications solutions with such sophistication of technology will result in unbounded mobile communications (UMC) by virtually eliminating the communication dependencies of geography or wireless access types. In Watson's terminonolgy, "UMC" encompasses the amalgamation of multiple technologies that work together, resulting in a seamless communications solution. This Chapter covers mobile handset issues in respect to UMC, and this excerpt specifically address network flexibility and platform design.
Click here for Part 1.
From the publisher: Order this book today and receive a 20% discount. Click here and make sure to type in 92839 when ordering this book. Or call 1-800-545-2522 and mention 92839 when ordering this book. Offer expires 12/31/2008.
Network Flexibility: Variances in Platform Design
Each operating system used for mobile handsets has its own unique approach for supporting, making, and breaking network connections, whether wireless or wireline. Most have a communication manager that is responsible for managing network connections, but there are design differences that may be important in a purchase decision from any one vendor. By intent, the communications manager is supposed to present an abstracted network interface that simplifies the operational management of network access. All require baseline configuration where all possible network connections are profiled (with proper security), including Bluetooth, WiFi, and USB connections.
Configuration management for WiFi will be the most challenging for UMC users. This
is because there are:
- Corporate-sanctioned WiFi networks (corporate campus " behind the firewall)
- Remote private WiFi networks (home or remote office)
- Remote public WiFi networks (commercial WiFi services)
The first two classes of WLANs are sustainable because they are rather static regarding the users' nominal work week/day experience. These usually don't change with the regard to ESSID or security and can be managed from a single corporate IT department. The third network, remote public WiFi, is the challenging one. To take advantage of these wireless services (in airports, hotels, malls, and so on), the individual end user must be able to configure these networks himself or herself. Most laptop wireless services present you with a list of accessible WiFi ESSIDs, and access is granted through use of a Web interface; the user enters license credentials or financial information for charges. Once a new wireless network has been configured, you're home free, right? Not so fast.
With most applications that are designed to operate in a wireless environment, once the network has been profiled and the device is associated, the application TCP services are made available to the application and execution is straightforward. With Symbian, however, there is an additional wrinkle. Whereas the majority of communication managers and applications have low coupling, in the Symbian "world" the application is tightly coupled to the specific network. Figure 9.2 shows an example of the differences between Windows Mobile and Symbian in requirements in terms of how applications gain access to a specific network.
In the Windows Mobile world, once the network has been configured, its services are available for all network-based applications through a generic TCP/IP API interface. With applications running on a Symbian platform, there is an additional requirement that each application must have an access point preference list enabled to permit it to access any network service. This architecture has its downside in that an additional configuration step is required for every network application installed and if the applications do not have the exact same access point preference list, the mobile terminal will not have the same application environment support across all networks. This can be somewhat confusing for the user; that is, Application #1 works in network #1 but not in Network #2! Deploying a UMC solution on Symbian-based phones will require some additional network planning to optimize the usability of the mobile devices.
Audio Routing
Without exception, every first-generation dual-mode handset had the same problem:
Audio traffic through the WiFi network connection was auto-routed to the back speaker. No configuration option was provided; with some designs, it was dictated by the electronic circuit in the handset. The presumptions of such designs were that (1) WiFi was only going to be used to play back audio from Web pages or (2) the audio would be routed to a headset. With such designs, a cellular call on a UMC handset would work fine with the audio being routed to the expected front speaker (as with any phone), but when that device roamed into WiFi coverage, the audio for the call would be routed to the back speaker. This is, of course, unacceptable for use in a wireless-VoIP scenario.
Handset manufacturers were informed of this shortcoming very quickly by all the UMC market contenders. Their response, however, was rather slow because the early upside market opportunity for UMC sales was too small. As the market has grown, handset manufacturers have acknowledged the need for application-directed audiorouting and have begun providing device-specific SDKs to be linked with UMC applications. The good news on this front is that the third and subsequent generation of dual-mode phones will not be plagued with this problem. The current dual-mode installed base, however, might not be blessed with such options. Many of these
phones have been through end-of-life (EOL) and no future engineering resources will
be applied.
In selecting a UMC solution, it will be important to know whether the application vendor has partnered with the handset vendor on this issue and has embedded the audio routing into its product.
Battery Life
Most consumers think little of the battery life on their cellular phone. The power demand for cellular phones has been greatly optimized over the past 20 years, and users are accustomed to purchasing automobile or laptop chargers for their phones. Cell phone batteries do go dead, but for most users, this is a manageable issue. With the advent of WiFi being added to the handset, power requirements for these devices have changed dramatically.
Transmit and receive power requirements for WiFi are greater than for typical cellular technology; this additional burden has strained the capacity of small, high-density batteries to the limit. With both cellular and WiFi radios enabled, a WiFi call is apt to completely drain a battery in less than one hour! Later generations of dual-mode phones do a little better on this metric, but they are nowhere near the battery life metrics for the cellular radio alone. To make a UMC solution viable over a long business workday, something has to change.
Optimization of battery life in a UMC device is achieved using two general solutions:
Implementing WMM power save. This driver-level feature optimizes management of power demand on the mobile radio by placing the radio in a sleep mode when little or no traffic is required. Products that conform to this standard are certified by the WiFi Alliance as part of their WMM certification. This feature has a significantly positive impact on standby time for the mobile handset.
Higher-capacity batteries. To ensure longer talk times on a UMC device, it is often the solution to configure it with a higher-capacity battery. Most dual-mode handset manufacturers offer these as accessories. They bump the cost of the total system a little and usually make the device a little heavier, but the increased usable time is the real benefit.
As the technology moves forward, the power requirements of WiFi components will become more efficient, thereby extending effective battery life. However, when evaluating a UMC solution, ask the vendor for battery life specifications for the device of interest. These should include cellular talk time, WiFi talk time, and several variants of standby time configurations.
Other Considerations
In selecting, purchasing, and deploying a UMC solution, other considerations that can
affect the usability need to be addressed:
Codec/audio encoding. In most VoIP systems supporting a generic G.711 (64Kbps), audio codec is not an issue. This is a reliable encoding standard that provides excellent voice quality over almost any network. There are other codecs (i.e., G.729, G.726, and ILBC) that provide different value benefits. Of most importance are the low bit rate (LBR) codecs that significantly lower the network bandwidth required for transporting an audio stream. Most popular of these codecs is G.729, which provides for excellent voice quality but requires only an 8 kbps bandwidth. Certain PBX and hosted providers no longer support G.711, and the winning solution must support a compatible codec.
Professional and Personal modes. Many UMC solutions require a mobile handset to support two phone numbers: one that the cellular carrier issues and one that is used by the UMC mobility authority (e.g., an office phone number). It is not unreasonable for a user to desire to make and receive business calls on the UMC number and personal calls on the carrier assigned number.
Global positioning systems (GPS). More sophisticated terminals and smartphones are coming on the market equipped with GPS. This technology is a double-edged sword in that it can aid the user in determining travel directions but can also be used by a business entity for monitoring the whereabouts of the individual. For example, Papa John's pizza delivery has launched the TrackMyPizza.com Website, where the customer can track the pizza delivery
person. This feature in a UMC handset opens up many untapped opportunities.
Push to Talk (PTT). The ability to use a walkie-talkie mode on a cellular phone
is very popular. This half-duplex communications mode allows a single person to send audio to multiple units simultaneously. Often used in construction, healthcare, and transportation and logistics fields, this feature has become a requirement for many who seek extended mobile communications. The challenge is implementing half-duplex over multiple networks. Some UMC
vendors are promising PTT sometime in 2008.
Printed with permission from Newnes, a division of Elsevier. Copyright 2009. "Fixed/Mobile Convergence and Beyond, Unbounded Mobile Communications" by Richard Watson. For more information about this title and other similar books, please visit www.elsevierdirect.com.
Related Articles
|
