Mobile Phones: the Embedded Linux Challenge

Although mobile handset manufacturers are embracing Linux as an emerging platform for next-generation smart phones, development and deployment of those devices still face key technical challenges. In particular, mobile phone OEMs must deliver devices with power management, fast boot up, integrated radio (GPRS) interfaces, advanced multimedia capabilities, attractive small form-factor GUIs and differentiated PIM application sets (browser, phone book and so forth)—all integrated and running in a modest memory footprint. This is a particular challenge for embedded Linux developers because, unlike PCs, phones aren't built to a standard architecture.

This article examines various technical challenges that face developers of Linux-based mobile phones. It addresses availability and maturity of key enabling Linux capabilities and also of open-source projects that support phone application development. In addition, it discusses technical and economic challenges presented by the stringent and numerous requirements of mobile network operators.

The global mobile phone market is growing at an explosive pace. Industry analysts at IDC report that in Q2/2005, the handset market grew 34%, as almost 700 million handsets made their way from device OEMs into people's hands and onto the global voice and data networks. Analysts at Gartner predict that by 2009, the global installed base will number more than 2.6 billion mobile phones.

For the Linux-centric segment of the IT industry, these numbers are tantalizing—orders of magnitude greater than total Linux shipments and installed base for servers, and far greater in volume than the worldwide desktop market. As such, the mobile phone market represents both an opportunity to “break out”, reaching significant market share in client devices and to complement the already significant presence of Linux in the communications infrastructure (based on carrier grade and other versions of enterprise and embedded Linux).

In the past few years, Linux has made significant gains as a mobile phone platform OS. Device manufacturers LG, Motorola, NEC, Panasonic and Samsung today ship two-dozen smart phone models based on Linux, complemented by Chinese brands like Datang, e28, Haier, Huawei and ZTE. Nokia and others also are beginning to ship Linux-based wireless VoIP clients.

Device OEMs, large and small, are choosing Linux as the strategic platform for their smart phones for a mix of technical and economic reasons. On the technical side, OEMs look to Linux for performance, robustness, “gold standard” TCP/IP networking (especially routing) and flexibility. On the economic front, Linux offers OEMs lower development and deployment costs, more choice of vendors (including “roll your own”), a larger open and commercial technology ecosystem, and an opportunity to unify the divergent and costly product lines and engineering efforts needed to support multiple product tiers (smart phones, feature phones and entry-level devices), network types (GSM, CDMA, analog and Wi-Fi) and carrier requirements.

For all of these strong technical and economic benefits, Linux phones account today for between 1–2% of the total market. On smart phones, the fastest-growing segment, Linux enjoys a stronger position. Smart phone share is growing at 85% per year, and Linux owns 25% of the smart phone segment (Q2/2005 Gartner), far ahead of Windows Mobile and others, but behind SymbianOS by a factor of two or more.

Categorizing phone types is not an exact science, nor even an exacting marketing exercise. Features that once differentiated phones strongly (like e-mail or imaging) are now commonplace across tiers and price ranges. Moreover, what is smart today may be a common feature in six months. Feature phones for which you pay good money at the holidays can end up as entry-level giveaways toward the end of their market lifetime the following spring and summer.

Figure 1. Mobile Phone Segment Shares (Gartner Q2/2005)

Although delivering Linux-based smart phones is no mean feat, it is still easier and more viable than putting the open-source OS on lower-tier phones. Why? Because smart phones, with higher prices and more ample margins, have more room in the BOM (Bill of Materials)—room for hardware dedicated to key phone functions (multimedia, display control, baseband RF and so on) and for software to enable that hardware. Often the application OS (Linux, WindowsMobile and so on) runs on a dedicated application processor, with additional CPU and DSP cores handling voice, multimedia and RF functions. Smart phone buyers are also typically early adopters, eager for the latest technology and more tolerant of some marginal behaviors, especially of shorter battery life in technology-rich devices.

Smart phones, however, represent only about 6% of the total phone market. If the Linux industry and developer communities want truly ubiquitous phone-based deployment, a Linux phone platform also must be able to support the technical and economic requirements of the broader middle-tier or feature phone space. These handsets don't sport all the technical goodies of smart phones, and the underlying hardware doesn't come with all the support hardware either. A cost-down BOM means that Linux on the application CPU is directly exposed to the vagaries of software support for voice, data, RF and graphics. Place that burden on a single CPU running between 0–200MHz as needed for energy management, in a much more modest memory footprint, and Linux can't make the middle-tier cut.

Social projects aimed at bridging the digital divide also envision open-source phones for low-income populations in developing countries (think tiny Ubuntu). But just as the $100 desktop is proving elusive, so likely will the free Linux-based cell phone.

Over time, the specs for middle- and even low-tier phones might rise to meet Linux base capabilities, but margins also get much thinner on these same devices. Battery technology is not improving at an appreciable rate, meaning that applications can't make up the difference with faster clocks either. So, if Linux is going to break out of the smart phone trap, it must acquire a series of new capabilities and enhance and unify many existing ones to meet the challenge.

OSDL kicked off a new initiative (see the OSDL MLI sidebar) to foster Linux adoption on mobile telephony handsets. As its first order of business, MLI is cataloging gaps and requirements to make Linux a more apt phone platform OS. The following list and discussion is representative of input from MLI participants and other interested parties, especially handset manufacturers and phone silicon suppliers.

Today, if a portable device manufacturer wants to offer a Linux-based and power-managed device, he or she faces a boggling choice among variously divergent paradigms (Table 2).

OEMs can look to the desktop where notebook-centric schemes like ACPI and APM dominate, and indeed occupy most discussions of Linux power management on the kernel mailing list. For non-x86/IA-32 notebook hardware, OEMs can turn to PMU for Apple PowerPC hardware. Embedded OEMs deploying ARM-licensed silicon can leverage the ARM Ltd. IEM framework, or work with the various power management schemes present on silicon from dozens of ARM licensees (FreeScale, Intel, NEC, Samsung, TI and others). There also exist unique and further divergent energy conservation protocols from MIPS and MIPS licensees, from FreeScale for its CPU lines, from IBM for Power Architecture, from Renesas and Hitachi, and so on across the silicon supplier universe. OEMs also can choose schemes like MontaVista's DPM and other embedded Linux supplier solutions.

Although choice is a good thing, too much choice can lead to fragmentation. In response to this power management smorgasbord, members of OSDL MLI and other embedded industry consortia have expressed a desire to see either a unified cross-processor power and energy management scheme, or a mainstream high-level “umbrella” that covers embedded, desktop and even blade-based thermal management.

Motorola has been building radio sets for nearly a century. They and other handset manufacturers like NEC, Nokia and Panasonic leverage their hard-won RF know-how to build their popular phone product lines. New entrants and also new designs from existing suppliers, however, must overcome a range of designs challenges before they can build handsets that meet the requirements of carriers, operators and regulators, and do so cost effectively.

In today's crop of Linux-based smart phones, the GPRS interface resides in an encapsulated “modem” device that can contain an additional CPU core, a DSP and RF hardware to support wireless communications. It really behaves like a modem—many smart phones communicate with these embedded processors via AT modem commands over a dedicated serial port. Offloading the radio function makes it easier to build a smart phone, but it impacts costs by adding components to an already heavy BOM.

Some experimental designs today remove the modem and expose the baseband interface to the application OS (as with Nucleus in mid- and low-tier phones), but doing so exposes Linux to hard real-time requirements that stretch beyond the limits of recent advances in Linux real-time (preemption and open-source real time—see below). GSM and also CDMA wireless protocols predicate signal frame times in the 800–900 microsecond range. For x86/IA-32 and PowerPC processors with 500MHz–1.5GHz CPU clocks, submillisecond worst-case response is now commonplace, but with clock-scaled ARM processors running at 0–200MHz, hard real-time interrupt response and preemption are still marginal.

A separate challenge arises from the use of legacy telephony stacks ported “as is” to Linux. This software was written and optimized for legacy phone OSes like Nucleus and REX. These proprietary multilayer stacks were implemented with unique thread contexts for each layer, and when ported to Linux can exhibit 20–30 microsecond context switch latencies layer to layer. As such, just traversing the stack with a single packet can consume a large portion of available compute time, leaving few CPU cycles for other tasks.

If Linux is going to participate in cost-down mid- and low-tier phone designs, it will need both more spritely context switching and/or optimized and open native ports of key GPRS and CDMA protocol implementations.

During the past five years, Linux has progressed toward offering significant native real-time responsiveness. Today, Linux is replete with native real-time options, including capabilities like the preemptible kernel, O(1) scheduler, FUTEXes and the recent Open Source Real-Time Linux Project (now merged into preemption patches maintained by Ingo Molnar—see the on-line Resources). There also exist dual kernel and virtualization technologies like RTLinux, RTAI, Adeos and proprietary Jaluna OSware that offer RTOS-like responsiveness by virtue of embedding an actual RTOS into the Linux stack.

OSDL MLI members and others in the community would prefer to see native Linux solutions do real-time response. For exposed RF interfaces, and time-sensitive and QoS capabilities like multimedia and voice processing, the consensus is that Linux needs continual nudging in the direction of native RTOS-like responsiveness. In mobile designs, Linux must meet deadlines and switch context with agility in systems whose clocks can scale erratically to conserve battery power, jumping from 200MHz peak performance down to 40MHz (or even 0MHz) and back in response to system policies and peripheral inputs.

Today's smart phones can ship with 128MB of Flash and 64MB of RAM. However, a phone OS need not seek to occupy every last byte of available storage. Every byte used by the OS and middleware is a byte not available to OEMs for value-added content. On the plus side, embedded Linux can theoretically deploy in a footprint of 1MB or less; real phone configurations are much larger.

Embedded developers, platform providers and maintainers of the Linux kernel itself provide a range of configurations and tools to shrink the platform footprint:

There are myriad methods, tips and tricks for reducing the user-space memory burden. These include using uClibc instead of glibc as a standard library, deploying BusyBox and TinyLogin instead of standard shells and multiple utilities, and using compressed filesystems like CramFS and YAFFS.

Phone manufacturers, however innovative they wish to be, cannot simply build the phone of your dreams—or of theirs. Rather, they must respond to the expansive and exacting requirements presented to them by their customers, the mobile carriers and operators (think Cingular, Vodaphone and others), predicated by the networks those companies build and maintain, which are highly regulated by national governments and even some international bodies. These requirements come in the form of phonebook-sized tomes, comprising 5,000 or more distinct specifications, and many of these specs are themselves highly complex and multifaceted.

Governments, especially the US Government, jealously guard their control of the electromagnetic spectrum. The US Federal Communications Commission (FCC) auctions and doles out grants of radio spectrum use and has very particular ideas about bandwidth, signal strength, security and as we've (re)learned in the last six years, about content on the “public” airways. Other governments and regulatory bodies around the world are similarly disposed toward open and free uses of radio frequencies. Devices that do not conform to these (overlapping) regulations and do not pass regulatory muster (homologation) do not earn approval and are not licensed for sale. Violations carry nasty fines and even criminal penalties.

Mobile carriers and operators, in response to these regulatory regimens, are understandably reluctant to experiment with open device architectures. Ditto for their suppliers, at least on the “thin” end of the wire (carrier-grade Linux and other implementations are today powering a growing share of wireless infrastructure). Carriers and operators are not completely averse to openness, but tend to think only in terms of secure delivery of value-added services. By establishing careful sandbox environments and limiting API sets on the technical end, and by even more careful political negotiations, the chain of manufacturing, deployment and regulation have begun to crack the lid on otherwise closed handsets. As such, mobile phone users and market watchers have seen a handful of “can openers” emerge during the last five years, principally Mid-P Java and BREW, with mixed results, especially in performance. More recently, a slew of native applications has emerged for phones based on SymbianOS and on Windows Mobile 5.0.

Linux-based phones offer up the promise of further prying open the clamshell by leveraging the OS to provide a secure application programming environment (in user space); it also comes with a well-established community of skilled developers. Whether Linux-based handsets will be truly open platforms, remains an open question. Phone deployed so far, although based on a Linux kernel and many familiar OSS components (like versions of Qt), are by no means open devices. Hackers cannot (easily or at all) rebuild the kernel, OS and application components, or even add functionality to the stack. These devices are not designed to accept logins, let alone reflashing. The “can opener” for these Linux-based mobile devices, like those based on proprietary OSes, is Java, even if you can download source code for the OS and portions of the application stack.

There do exist after-market resources to support hacking Linux-based phones. One such project is Harald Welte's Open-EZX (see Resources). This project, still in its early stages, strives to build a 100% open phone stack for Motorola mobile phones like the A780 and e680. The project's wiki is replete with warnings about rendering your phone unbootable and losing regulatory approval, but also with useful information on how to get a shell and how to cross compile for these devices (they're based on Intel XScale Architecture PXA processors).

Motorola's chief phone architect definitively disavowed support for such efforts. Why? Principally, liability issues stemming from its customers' concerns for the integrity and security of their mobile networks and the complex burden of supporting millions of devices with potentially divergent versions of the Open-EZX software stack. Then why call it Open-EZX? Because device OEMs like Motorola do want to encourage the evolution of developer communities around their devices and platforms. They just need to foster that evolution in a way that is amenable to carrier, operator and regulatory sensibilities. Today, that means offering SDKs to hand-picked ISVs.

Hopefully soon, through educational efforts and persistence, this very conservative and careful audience of network operators and government regulators will be more comfortable with mobile phones as computing platforms, not mere mono-function radio devices.

Resources for this article: /article/9073.