• 1 Virtualization and Mobile Phones
• 2 Mobile Handset Design Challenges
  • 2.1 Market Segmentation
  • 2.2 The Migration Strategy
  • 2.3 Evolution Readiness
  • 2.4 Open OS’ and Security
  • 2.5 Handset Management
  • 2.6 Ideally, the best of legacy an OpenOS worlds would run on a common hardware
• 3 Implementation Alternatives
• 4 The Solution: Virtualization
  • 4.1 Real-Time and Virtualization
  • 4.2 Resources Partitioning
  • 4.3 Resources Virtualization
  • 4.4 OS Isolation
  • 4.5 Flexible OS Scheduling
  • 4.6 Device Virtualization
    • 4.6.1 I/O Peripherals
    • 4.6.2 Dedicated Peripherals
    • 4.6.3 Shared Peripherals
    • 4.6.4 Virtual Peripherals
  • 4.7 Communication
• 5 Questions and Answers

The rapidly-evolving mobile handset market presents both a major market opportunity and a major design challenge. The market opportunity is to transform the handset from a mobile voice and basic data terminal into the consumer’s primary mobile communications, information, financial transaction and entertainment center, with a commensurate added value.

This transformation is well under way, with many handsets combining voice and simple data communications with:

• Communication capabilities such as secure inter-device wireless communications and Internet access.
• Information capabilities, such as secure remote mail access and office data access.
• Entertainment capabilities, such as MP3 audio playback, digital camera, and video recording and playback, with secure intellectual property rights protection.

The fastest growing segment of the mobile handset market is that which delivers this functionality – smart phones. However, it is an inescapable dynamic of consumer markets that the functionality of today’s high-end product must be implemented in tomorrow’s mid-range product in order to maintain sales volume, growth and market share. Consequently, the industry faces the design challenge of migrating smart phone functionality to the mid-range handset – the feature phone. And it must do so, with the competitive development costs, the competitive bill of materials (BOM) and the short design time necessary to succeed in fast-moving and demanding consumer markets.

This paper describes the design challenge in more detail, and compares and contrasts various implementation approaches. It then discusses how a virtualization solution may be used to ease introduction of smart phone software functionality to an existing feature phone hardware platform, with minimal efforts and costs. It also shows how a virtualization based solution opens up the phone software architecture to bring added functionality, to both feature phones and smart phones in the area of service availability, security and device management.

The mobile handset market is conventionally partitioned into three major cost/feature segments: low cost phones, feature phones and smart phones.

Low cost phones typically provide only voice communication and short messaging services (SMS). They typically use a DSP for signal processing and a RISC CPU to execute the upper protocol stack layers.

At the other end of the spectrum, smart phones offer advanced services similar to those provided by PDAs. Such phones typically use multiple processors: a DSP for signal processing, a RISC CPU with an RTOS to execute the upper protocol stack layers and some applications, and a more powerful RISC CPU with an OpenOS – such as Windows CE, Symbian OS or Linux – to execute a richer set of native applications delivering the features which make the phone a smart phone.

In the middle of the spectrum, feature phones offer a trade-off between low cost phones and smart phones. They typically offer fewer services than smart phones on less expensive hardware and with less battery drain. Typical hardware configurations use a DSP for signal processing and a RISC CPU (more capable than those used in low cost phones) to run an RTOS that executes the upper protocol stack layers and some applications, including Java and Flash based ones.

However, as noted in the introduction, the design challenge is to provide smart phone applications and functionalities on the feature phone, and to run the native OpenOS applications instead of the ones currently ported to the feature phone RTOS..

The feature phone design challenge is to offer more services inherited from smart phones on less capable hardware. Consequently, the processing capabilities of the platform (CPU, co-processors and hardware accelerators) must be optimally selected to support real-time protocol stacks and some end-user applications such as browsers, email clients, calendar applications and so forth.

In addition, mobile handsets, whether feature or smart phones, must be IP-connected using the common communications technologies, including cellular radio protocols – both narrow- and broadband –, Wi-Fi, Bluetooth, and InfraRed as well as USB and serial line. Such connectivity enables the delivery of more end-user services, such as TV, video and audio streaming, video and audio download and playback, network gaming, photo transfer, mobile data synchronization with PC or laptop, and e-mail. Location Based Services will soon enrich this set of services.

The on-time delivery of a new phone model mandates extensive design reuse, especially of legacy software. This software includes functions such as radio protocol stacks with their real-time constraints, and multimedia services that are difficult to validate and certify over the full range of operating conditions,.

However, end-user services such as those enabled by IP protocols are better delivered using OpenOS’ and open environments such as Linux, Symbian or Windows. These environments enable the reuse of high-level applications such as email clients, browsers, audio, video players, and Java applications. Linux, in particular, is rapidly becoming an OpenOS of choice. It provides the latest evolutions of IP family protocols and many up-to-date drivers for complex interfaces, such as USB, and as such is a good candidate to easily bring connectivity and new features on a mobile handset.

There is, therefore, an apparent conflict between the need for extensive legacy software reuse, the need to adopt additional “new” OS suites to execute new applications, and the need to deliver new features on a hardware constrained phone – and within the time to market constraints.

The optimum migration strategy must therefore enable the un-modified reuse of multiple software stacks executing on a single processor – resource consolidation.

Obviously, time to market constraints will not weaken as mobile handsets continue to evolve with richer feature sets – and mobile handset software stacks must be ready to support these evolutions. Hence a robust, but flexible stack architecture is essential to the timely delivery of evolving but validated software stacks.

Moreover, mobile handsets are and will be increasingly open, enabling the download of software to satisfy more personalized user requirements. Personalized requirements might well include – in addition to the phone’s standard feature set – business oriented Java applications; “one-touch” transactions such as train control gate “pass”, theater and train ticket purchase, and more complex financial transactions such as bank and brokerage account access.

Many of these applications may involve several handset users in a single set of transactions. Every participant must be able to dynamically download, install and run the appropriate software.

To avoid problems with administration, management and security of the evolving functionality, such software is best executed in independent run-time environments.

Security is a serious – and growing – issue for mobile handsets running an OpenOS. There are already more than 180 known viruses for mobile phones – still far behind the number of known PC viruses, but the number is growing fast. Consortia such as OMA, OMTP, LiPS Forum, and TCG are already attacking the issue.

Security cannot be an afterthought. The frequent, emergency post-development security upgrades and patches common in the PC world would be unacceptable to the average user of a mobile handset. Indeed, such an approach to security could stall the proliferation of smart and feature phones. Consequently, security must be designed-in from day one of the handset’s life cycle.

Environments that allow software downloads are obviously more susceptible to malware attacks than closed ones, and therefore must be protected and isolated to limit or prevent attacks. For example, operator stacks must be protected against any kind of attack, so that the phone continues to work and the customer is not billed for calls that he did not explicitly make. A second example: enterprise data must not be compromised by an attack from a downloaded game. Another example: the digital rights of a downloaded video should be stored securely to prevent unauthorized access. A final example: personal data must be protected to prevent spyware monitoring.

Most often, security is implemented by the sub-systems that are subject to attack. For instance, scanning for viruses in incoming and outgoing mail is usually executed by a program running in the same environment as the user’s email client. However, it is dangerous to rely upon self-security, especially in a multi-use scenario with different operators, banks, and other enterprises. The mobile handset user is simply a roving agent in a wireless IT world – and security is every bit as important as it is in the fixed-wire IT world.

Security should be achieved by means of clear partitioning and robust isolation. As an example, the NTT Docomo Intel specifications (http://www.nttdocomo.co.jp/english/binary/pdf/corporate/technology/osti/OSTI_Arch_R1_00.pdf) clearly calls for two independent environments supported within a phone (see figure). Isolating the assets of each party (operator, content provider, bank, user, etc.) ensures that if one asset is compromised, the others remain secure. In addition, robust isolation enables security checks to be conducted from a sandboxed part of the system other than that containing the attacked asset. In other words, handset functionality should be firewalled, just as IT networks and home LANs are firewalled.

The increasingly complex nature of mobile phone software will necessitate its management from various remote sources. Mobile phones are already managed over the air by the operators. For instance, it is not uncommon to be asked to power cycle the phone to activate new configuration data remotely installed in the SIM card. Indeed, the SIM card is considered to be a trusted execution environment that could be used as the standard means to manage and control many or all of the additional services offered by smart phones and feature phones. Of course, this use of the SIM card must be accompanied by the deployment of trusted application extensions, such as a secure user interface, in order to maintain security integrity.

Device management can be partitioned into three main categories: closed device management, open device management and local device management.

Closed device management encompasses management of the physical device and of the software that controls operator services, such as voice communications, SMS, and MMS. It thus manages the basic phone functions for which the phone manufacturer and the phone service provider are responsible. Examples of such management operations may include, but are not limited to:

• Availability: monitor hardware and software events; safely log errors for improvement purposes; retrieve and reset logs; restart failed systems and components.

• Upgrade: enable both operators and handset designers to patch, modify or upgrade their part of the system, safely and securely, with fall-back mechanisms.

Open device management encompasses management of all other phone software components that have been installed post-purchase by the user. Since the high end mobile phone is used for sensitive and confidential business, banking or personal applications, open device management may be the responsibility of different stakeholders, such as the enterprise, bank and the user.

In both management categories, management facilities must provide control data, software backup, software refresh, provisioning, and software removal and installation. Any and all such management operations must be executed safely and securely with authenticated management servers, and all software and critical data transfers must be signed.

Local device management is required in addition to the closed and open device management categories. It enables the mobile phone to operate under a broad range of conditions in a wide variety of environments. For example, local management dynamically adapts the system and/or application by stopping or suspending an application stack or component execution to give higher priority to another application. It also adapts phone behavior to changing security policies as it moves from one working environment to another. Such local management is critical to making the phone truly mobile.

So, what are the requirements to address the foregoing challenges?

First, a solution should enable the reuse of legacy real-time systems, telephony protocol stacks, together with OpenOS protocol stacks (IP protocol) and native OpenOS applications. Such a consolidation enables the simultaneous execution of both software environments on a single processor to deliver both sets of services without using more powerful and more expensive processing capacity. Also, an ideal consolidated solution would deliver native performance levels while avoiding extra porting cost.

Second, a consolidation solution would enable evolutions of both systems. In particular, it should enable the use of newer versions of the legacy OS and the OpenOS – with new or upgraded protocol stacks, drivers and applications– to deliver up-to-date services.

Third, a solution should enable the execution of security controls and policies, robustly isolated from both the legacy RTOS environment and from the OpenOS environment – an approach that applies equally well to non-consolidated dual-core architectures. This ensures that security and secure services remain protected in the event that other – more open – assets are breached. In fact, security services should be designed in a modular fashion and will be subject to evolution over time, requiring that the execution environment in which they operate be flexible to easily support such evolutions.

Fourth, the device management services should execute separately from the legacy real-time system and OpenOS. Such an approach enables to more easily provision and configure the resources of the mobile handset between each party in multi-tenants configurations. It also enables the secure and controlled upgrade of functions and services, with fall-back mechanisms in case of any misbehavior on the part of updated software.

Various potential implementation alternatives to implementing smart phone software functionality will now be considered.

Two processors: Obviously, two processors would execute two different software environments without software modification. Unfortunately, this approach violates one of the most important requirements: bringing smart-phone functionality to feature phones without increasing the processing power of the feature phone. In addition to the greater design complexity, requiring additional processing power increases both the BOM and the power consumption of the device. It also requires the duplication of other devices, such as audio devices, or the deployment of dual-port devices that can be accessed by both OS’.

Single processor, single OS: Another approach merges the legacy and OpenOS environments in a single environment. However, in practice, this conceptually simple approach requires a huge amount of effort to port, test and revalidate the software, thus significantly increasing time to market. Moreover, a OpenOS may not possess all of the properties of a legacy RTOS, especially real-time quality of service (QoS). On the other hand, the use of a legacy RTOS would make it difficult to use existing open implementations of protocol stacks such as TCP/IP and application software. Once the merge is complete, developers would then face evolution problems such as how to keep the merged environment up-to-date with the evolution of its individual components in their native environments. As an example, the TCP/IP family protocol is still evolving and getting richer. Such evolutions are easier to follow when using unmodified OpenOS such as Linux.

Hybrid OS: This approach partially solves the main problems of the single OS approach just described. Hybrid OS’ usually provide a real time environment within a Linux kernel. However, this conceptually-simple approach lacks the requisite flexibility. The real time environment usually commences execution after Linux has started, delaying critical real time applications. Moreover, the systems are not mutually isolated. Consequently, any misbehaviour of one system could seriously impact the behaviour of the overall platform, jeopardizing both availability and security. Moreover, such hybrid OS’ approaches impose their own real time framework and interfaces, which are generally different from those of any legacy system. Hence, additional porting effort is required. Finally, the approach is limited to two environments: it is quite difficult to extend the approach to support additional execution environments for example, for security or device management applications.

Paravirtualization: Paravirtualization enables the execution of multiple OS environments on a single processor, each environment being isolated within a dedicated partition. Physical resources such as memory and I/O devices are dedicated to partitions. The number of partitions can be optimized to the needs of the overall system, thus permitting the isolation of given security and device management functions in dedicated partitions. System environments can be reused in their partitions without much effort. Only part the hardware abstraction layer (HAL) of the OS require some adaptation, amounting for a quite small effort and cost.

Transparent Virtualization: An even better solution would be to use transparent virtualization, which in addition to all of the benefits of the paravirtualization approach, does not require modification of the operating systems. Depending upon the processor capabilities, transparent virtualization may require some complex dynamic binary translation mechanism, such as implemented by VMware on x86 machines, or may be implemented through hardware based mechanisms, such as those found on Intel VT-enabled processors. Unfortunately, embedded processors in mobile phones do not provide support for efficient transparent virtualization. Hence paravirtualization appears to be the best trade-off choice.

Generally, mobile handsets use processors that do not currently support hardware virtualization. Therefore, practical solutions must use the paravirtualization approach. Because paravirtualization achieves the same goals as virtualization and differs mostly in the means by which it is achieved, for the sake of brevity, we will simply refer to virtualization in the rest of this document.

Virtualization must enable real-time environments to execute in parallel with OpenOS and other execution environments on a common hardware platform or processor. The virtualization software layer that supports these multiple environments must maintain the system’s real time properties. It must also occupy a small memory footprint as required by real-time embedded markets. The most important benefits of virtualization for real-time systems are:

• Consolidation of RTOS and OpenOS: One or more OpenOS such as Linux, Symbian or Windows may execute in parallel with a RTOS without disrupting the behaviour of the supported applications. Guest OS’ require only some adaptations in their Hardware Abstraction Layer (HAL) to run within the virtualized environment.

• Binary Legacy Reuse: Most of the guest OS’ is reused without modifications. Native device drivers, protocol stacks and system modules can be reused in a straight-forward fashion. Legacy applications are absolutely unmodified and still run in the new context. This ensures minimum development costs and a short time to market.

• Device Assignment: Devices can be dedicated to a given partition or efficiently and securely shared by different guest operating systems.

• Increased Security: The real-time virtualization solution offers robust security via hardware enforced memory isolation of partitions, isolating each OS from the others, and preventing cross-corruption. In addition, specific partitions may be added and used to execute secure applications in small certifiable environments protected from the larger and open OpenOS or RTOS executing in other partitions.

• Increased Availability: Guest systems may be transparently monitored and, depending upon the configuration, may be automatically rebooted in case of failure. Failure of a guest system does not impact the other ones which continue to deliver their service. Moreover, restart of a failed system is triggered by software and bypasses any hardware mechanisms leading to a faster return to service. Hence, overall system reliability is increased.

Virtualization most often relies on a foundation layer known as a hypervisor or a Virtual Machine Monitor (VMM) which may provide all or parts of the following services:

• Memory partitioning, robust isolation and I/O access control, CPU virtualization and scheduling,

• Virtualization of at least a few basic devices such as clock, timers, and PIC (Programmable Interrupt Controller).

If multiple guest OS’ execute on the same processor, the hypervisor has to schedule the guest OS’ in a way that maintains the RTOS’ real-time properties.

Physical memory must be partitioned, and each memory partition allocated to a given guest OS. Thus, each guest OS may use its own native memory management mechanisms and policies without interfering with other guest OS'. This approach allows OS’ that make use of the MMU, for example, Linux and Windows CE, and those that do not, to run cooperatively on a single processor.

I/O devices used by a single guest OS are assigned exclusively to that guest OS. Native device drivers can thus be reused with no modification.

Hardware resources required by several guest OS’, such as the CPU, MMU, and FPU are virtualized so that they can be shared between all guest OS’. The CPU is shared among guest OS’ based on scheduling policies that ensure that real-time guest OS’ (and their applications) are assigned the highest priorities and can thus maintain their real-time guarantees. Once a guest OS has been granted CPU access, the OS uses its native policies to schedule its own applications and services.

The MMU is virtualized so that each guest OS may use it for its own purposes. As discussed above, MMU use by one guest OS is independent of that by another guest OS.

It must be possible to protect and securely isolate memory partitions from each other so that no OS can read or write into the memory partition of another OS. I/O access performed by the guest OS must also be controlled.

The usual policy provided by hypervisors for real-time embedded systems is close to a FIFO scheduling policy within an OS: guest OS’ are given priorities. The RTOS is assigned the highest priority, ensuring that it will preempt any other guest OS as soon as needed. Remember, it is the RTOS where time critical tasks are running.

Other OS’ sharing a given priority level may be scheduled in a FIFO manner or on a fair share basis, depending upon the configuration.

Executing different OS’ simultaneously on the same processor is only one part of the problem. The guest OS’ also need to share other hardware resources beside the CPU, the MMU and the physical main memory, namely, core devices and I/O peripherals:

• Core devices are used by all guest OS’: clock, timers and Programmable Interrupt Controller. A UART used for OS’ console and for debugging may also fall into this category.

• I/O peripherals are I/O devices such as network interface controllers, disk controllers, and serial lines.

I/O devices such as screen, keypad, USB, audio device, flash memory, camera, Bluetooth interface, and modem may be further classified depending upon their use by the various guest OS’.

I/O peripherals that are used by a single environment, for example a Bluetooth interface exclusively accessed by a Linux system, are dedicated to that system. In such a configuration, the guest OS may use a native driver to manage the peripheral. Interrupts generated by the peripheral are virtualized and propagated to the guest OS by virtue of the Core BSP component previously described.

Some I/O peripherals may be accessed by applications from both OS’. For example, the screen may be accessed by real-time applications dedicated to voice calls, and by a Linux system for browsing the file system on the flash.

It may be possible to configure a guest OS’ with purely virtual devices that are not associated with actual hardware. For example, one may configure a virtual Ethernet network connecting two or more guest OS’, enabling them to further communicate with whatever TCP/IP application they wish.

A typical OS supports multiple processes, provides them with services such as synchronization and inter-process communication, as well as scheduling policies, shared access to system and network interfaces, and memory management.

Similarly, a virtualization solution may provide each guest OS with synchronization - a virtual cross-interrupt mechanism - and inter-OS communication mechanisms. Such low-level communication mechanisms are commonly used by virtual and shared peripherals. Stacking the most appropriate virtual peripheral driver on top of the low-level communication mechanisms insures that the communication is well tuned to the application’s needs while hiding the low-level complexity from the application. This enables applications running in a OpenOs guest to communicate efficiently with applications running on the legacy OS or RTOS, using the most appropriate communication paradigm. Remember that such applications cooperate within the mobile handset to deliver an integrated service to the user.

1. How can virtualization help us isolate sensitive or proprietary and / or licensed information (e.g keys), preventing possible disclosure (because of licensing constraints)?
   • VM’s are isolated one from each other based on HW MMU protection mechanism. Direct I/O access (and especially DMA) is either forbidden or strictly controlled, -the control and the way it’s done depends upon the underlying hardware properties-. Hence a VM cannot create breaches to access other ones.
   • Such VM’s may be used to run different software stacks delivering different services and originating from different providers. This may permit to implement software architecture as depicted by the NTT Docomo / Intel Architecture Specifications Open and Secure Terminal Initiative (OSTI). See: http://www.nttdocomo.co.jp/english/binary/pdf/corporate/technology/osti/OSTI_Arch_R1_00.pdf
   • Isolate info, keys in Virtual Machines where the only running software would be the one trusted (certified) to access and use such info. Info requiring keys to be accessed are sent to the VM holding the key (key is not sent outside its secured VM).
   • Non-trusted software, downloaded software run in different VM’s.
   • Communications between VM’s must be secured so that requesting VM (and the user’s identity on behalf of which it is acting) is authenticated. Needs to take care of bandwidth issue, covert channels
   • Likely to require pretty light-weight VM’s to effectively scale.
2. How can virtualization enable single-CPU packaging of functionality formerly split between multiple CPUs?
   • Assumptions:
     • Before virtualization / consolidation:
       • Running OS A + applications A on CPU A
       • Running OS B + applications B on CPU B
     • Homogeneous multiple CPU’s (same ISA family)
     • Target processor has enough CPU cycles and physical memory to host OS A, applications A, OS B and applications B as well as some minor extra room for hypervisor (virtualization software).
   • Virtualization avoids the needs to:
     • Select between OS A or OS B and then port applications (and drivers) A on OS B or applications (and drivers) B on OS A
     • Virtualization provides each OS with the illusion it has a physical machine for its private use (CPU, memory and I/O peripherals). Physical I/O peripherals may actually be transparently shared between multiple guest OS’s.
     • Scheduling of VM’s must preserve responsiveness properties of RTOS, and prevent VM’s from CPU starvation.
     • Communication which was used over a physical connection in the split world must be maintained over a logical connection in the consolidated world.
     • Simplifies some complex situations: avoiding the need for extra-memory (or dual ported memory) as well as the need for some duplicated devices (audio).
3. How can virtualization provide a secure sandbox for isolating subsystems and 3rd party applications development/integration?
   • Similar to issue N°1. Isolation between VM relies on HW memory protection (MMU). Each VM is given a distinct subset of physical memory and subsequent memory management operations (mapping of physical pages) is controlled by virtualization software. Virtualization software is protected from VM by HW memory protection mechanisms. Similarly real devices are assigned to VM’s.
   • Each VM is therefore seen as a standalone machine, independent from other VM’s hosted on the same hardware platform. OS and supported applications may be developed independently for each VM. Interaction between such stacks is achieved by appropriate communication means which may be selected according to application’s needs (TCP/IP, serial line…).
   • It may be worth to have some static/dynamic provisioning/configuration to make room for such 3rd party VM’s, depending upon the way such 3rd party software will be added on the device.
4. How can virtualization help us reduce power consumption by eliminating the need to have a separate applications processors for Rich OS?
   • By requiring a single processor instead of 2, power consumption is lowered.
   • However, when running with 2 processors, in some cases the RichOS CPU can be powered off. This is no longer possible with a single CPU design. Power management mechanism and policies implemented by the different consolidated OS’s must be coordinated so that global power management remains consistent at the CPU level. This is usually achieved through virtualization of power management.
5. How can virtualization help us Support multiple OS on the same hardware for faster 3rd party applications deployment?
   • Each OS and supported set of applications is provided with a virtual machine having the properties of a real machine (CPU, memory, timers, I/O peripherals…). Hence each software stack can be developed independently from each other. Interaction with pre-configured software (operator’s stack) can be done through appropriate set of libraries hiding the real communications with such operator’s stack over virtualized communication mechanisms.
   • Since operator’s stack is running in a different VM it cannot be compromised as long as the protocol to interact with the operator’s VM is robust. Hence development can proceed in parallel and integration of 3rd party software should be eased since the 3rd party application stays in its own OS environment. Each stack being validated on its part, the final validation of the composed system is very much minimized.