Unit -2 Mobile Device Technologies

Mobile Computing:
Mobile computing is a form of humancomputer interaction where a computer is expected to be transported during normal usage. Mobile computing has three aspects: mobile communication, mobile hardware, and mobile software. The first aspect addresses communication issues in ad-hoc and infrastructure networks as well as communication properties, protocols, data formats and concrete technologies. The second aspect focuses on the hardware, i.e. mobile devices or device components. The third aspect deals with the characteristics and requirements of mobile applications.

Adaptation: 1. Introduction
Mobile computing is characterized by a mobile device with computing capabilities operating in a wireless environment. This scenario inserts constraints not present in traditional fixed systems. Mobile devices have power restrictions and their computing capabilities are more restricted when compared to fixed devices. Also, wireless communication brings higher transmission error rates and lower and highly variable bandwidth. In order to offer acceptable services in this environment, mobile devices must provide some mechanisms to manage the environment modifications and to react to those changes. This problem can be mainly solved through adaptation. Adaptation in mobile computing means the ability an application or algorithm has to output different valid results, depending on the characteristics of the environment where the mobile device is located. This is not common in fixed systems, where the conditions are practically stable. In mobile systems, however, the environment is highly variable, which leads to this solution. There is no best strategy for adaptation. In each case, a specific strategy will fit better. This non-existence of a best strategy makes the task of defining an adaptation architecture troublesome. However, through the study of some target applications, it is possible to identify aspects that can be adapted that are more common to those applications and, thus, to define a basic adaptation architecture.

2. Architecture Specification
An adaptation architecture consists of a mobile middleware system. It provides high level services to the applications, hiding the complexities of the system from them. An application running in a mobile device may request for its location, for instance, without the knowledge of which mechanism will be used to gather the location data. When defining an adaptation architecture, prior to specifying the functionalities it will provide, it must be specified whether it is designed for a specific application or not, and the aspects it will focus.

3.1. Adaptation Architecture The different types of devices, network connection, and execution context of mobile systems when compared to fixed ones insert many constraints in the mobile environment not present in the fixed one. Due to those constraints, when defining an adaptation architecture in mobile computing, various aspects should be observed: data, security, quality of service, available resources, costs, performance, and broadcast and multicast issues. It is also important to consider whether or not the adaptation architecture is addressed to a specific application. Architectures addressed to specific applications often achieve better results, since the target application is known, and the designer may focus on its main characteristics and propose the best adaptation techniques for that application. However, those adaptation architectures can only be used for that target application. Other applications running upon this architecture will not benefit from it. Generic architectures, on the other hand, do not address a target application. Instead, some general adaptation techniques are implemented. When an application is running upon a generic architecture, it will benefit only from the adaptation techniques that can be applied to it. Since these techniques were not designed specifically for this application, they often will not achieve the best possible adaptation level. However, they will be able to achieve good adaptation levels with many applications. There is a trade off between generic and specific adaptation architectures. The most generic the architecture is, the most applications it can run. On the other hand, the most specific it is, the better results can be achieved for that specific application. 3.2. Architecture Specification There are various aspects that can be adapted in a multimedia environment. Depending on the application being adapted, the importance of some aspects, such as synchronization and delay, can be greater or lesser. When specifying a generic adaptation architecture, it is important to define first the target applications for this architecture. Once this is done, it is possible to identify which adaptation techniques can be applied to those applications, and then to define the functionalities the architecture will provide. 3.2.1. Target Applications Handheld devices computing capabilities have been growing. Some of them already have colored screens. It is already possible to access the Internet through them. Moreover, new transmission technologies providing higher bandwidth have been developed, and some of them, such as UMTS and Wi-Fi, are already in use. When defining target applications for an adaptation architecture, these facts must be considered. Video on demand is a target application for this work. Users will be able to watch music and news clips, or even movies in their handheld devices. In video on demand, the aspects to be adapted are the video and the audio. Synchronization between the video and the audio is an important issue. In addition, the delay must be constant.

A target application similar to video on demand is video conference. Instead of making a phone conference with only voice, users will be able to see each other while talking. The aspects to be adapted in this case are the same of video on demand. However, in this case, the delay must be minimum. Another target application is audio on demand. Users could listen to Internet radio stations live, or even request songs to listen from audio on demand servers. In this case, the aspect to be adapted is the own audio. Again, there may be a delay, but it must be constant. A last target application for this work is some common Internet services, such as e-mail, ftp, or the world wide web (www). Users will eventually access the Internet for checking their e-mails, reading the news, downloading files, or visiting web pages. Each one of these services have different characteristics that must be addressed. E-mails and ftp files can be compressed. In www pages, images can be adapted, and texts compressed. There is no need for synchronization between them, and the delay may be variable. 3.2.2. Adaptation Techniques There are many techniques to adapt each one of the aspects described previously. The best ones to be used depend on the users handheld devices, and the level of adaptation required. Video may be adapted in various ways. First of all, it can be colored or in gray scale. Another aspect that can be adapted in a video flow is the quality of the video. Some frames may be discarded. Also, its resolution may be set lower. On the other hand, it is not possible to discard packets while leading with audio. Broken audio is hard to understand. In this case, the aspects to be adapted are the quality of the audio and its sample rate. Images have a different approach to be adapted. The delay here is not an issue. Nevertheless, customers would not like to wait minutes for an image to load (unless they really want that image in its higher resolution). The adaptation for images can be done in three ways: reduce the number of colors, reduce the sample of the image, or reduce its quality. A last approach that can be used to decrease the amount of data to be sent over the wireless link is compressing texts before sending them. HTTP has an extensive header, which can also be compressed. Although compression is not considered an adaptation technique, it may be useful sometimes. 3.2.3. Functionalities and Services Once the target applications and the adaptation techniques for those applications are defined, it is possible to specify the functionalities the adaptation architecture will provide: image resolution modification, image number of colors decrease, video packets discard, video resolution modification, video quality modification, video conversion to black and white, audio sample ratio modification, audio quality reduction, text compression, and HTTP header compression. The adaptation architecture also provides some services to the applications: gather data location, increase or decrease quality an application quality level, increase or decrease an application priority, and enable or disable the security tools provided by the architecture.

User Interface Issues in Mobile Computing

A theme common to much of the past work on mobile computing devices is the desire to run similar computing environments on the mobile machines and on the users office workstation [4, 8]. Although running many of the same applications may be useful and desirable, running the same environment may be both undesirable and, for many mobile devices, impossible. In addition, researchers must realize that although we would like our research to guide the development of commercial systems, we are no longer the typical users of these systems. By designing systems for our past work habits and preferences we may help to produce systems that are appropriate and efficient, but not for the intended user base [2].

User Interface Processors vs. General-Purpose Computers

Duchamp has constructed a simple four category taxonomy for mobile computers: terminal vs. workstation and disconnected-often vs. disconnected-rarely [4]. It is not clear which of these four categories will produce the best mobile device for the users of these machines. While some may argue that mobile devices should be general-purpose computers [4], we opted instead for simple user interface processors. A user interface processor (or a disconnectedrarely terminal in Duchamps taxonomy) only performs drawing and low-level event processing, leaving the rest of an applications computation to a remote server. Other disconnected-rarely terminals include the Berkeley Infopad [15] and the Xerox ParcTab [18]. User-centered design [11] and task analysis [5] techniques stress that we should first determine what tasks the intended user population would likely perform on mobile devices. It was argued at a recent mobile computing panel [1] that much of the usage of mobile devices will be to access rapidly changing data at the home office, rather than authoring new data. The current uses of communications technology (i.e., pagers and telephones) seem to support this conclusion. Placing most of the computational power on the mobile device seems to be overkill if this is how the machines are actually used. In designing a device that has stringent constraints on price, power consumption, and size, one must omit components that are not absolutely necessary. Running applications on a remote host and using the mobile device primarily for the user interface solves some of the hard problems faced by designers of mobile computer operating systems. First, the system reinitialization problem becomes less complicated. When the mobile device crashes, it can be rebooted and the user can continue the application with no loss of data or state. This assumes that the remote hosts are more reliable than the mobile devices. The second major problem that the user interface processor approach solves is the data consistency problem. Instead of needing intelligent caching and consistency protocols as in Coda [9], a user will have access to the most current versions of their private and home office data as long as their communications link is stable. This is a reasonable assumption in a single building or campus setting. The user interface processor approach fits well with the idea that autonomous local file systems will become increasingly undesirable [14]. Although we focus on our experience in building a user interface management system for BNU, much of this discussion applies to all mobile computers, regardless of where they fit in Duchamps taxonomy.

Mobile Tasks are Different

As suggested above, an analysis of mobile computing tasks may produce a vastly different set of application priorities than an analysis of the use of a typical office workstation. It will certainly produce a different set of tasks than those performed by a typical computer scientist. For example, an analysis may indicate that the primary tasks to be performed on mobile devices are: scheduling ,short note taking, email reading and composition, large database browsing, and filling out forms that must be incorporated into large home office databases. Compare this set of tasks with the typical tasks performed on office workstations by researchers: large document preparation and layout, programming, email reading and composition, and the creation of graphics presentations. Most of the workstation tasks involve a large amount of data entry, whereas the mobile tasks mainly involve small amounts of data entry and the presentation of existing information. If an actual task analysis produced these disparate sets of tasks, we would like to have mobile devices optimized for the typical mobile task set. For example, these mobile tasks would favor a system that includes strong communications capabilities and therefore needs little local storage, yet does not require high-rate input devices (e.g., a keyboard). The workstation tasks would favor just the opposite. We have not actually carried out this task analysis, but we present this example to illustrate how a different set of user tasks can affect systems design decisions.

Mobile Agents:
A software agent is an intelligent program that acts as a users personal assistant. Software agents endowed with the property of mobility are called mobile agents. Mobile agents perform a users task by migrating and executing on several hosts connected to the network. Software agents have the following properties, which distinguish them from other programs: Intelligence: Software agents employ techniques from the field of artificial intelligence, which empower them with a fair degree of intelligence and common sense. For example, the travel agent program should realize that people generally do not prefer travelling by flights that depart or arrive at the airport late in the night and the agent should avoid booking tickets on such flights. The travel agent program should be smart enough to bargain and arrange the trip so that the overall expenditure for the trip is as low as possible without compromising on the users preferences. Autonomy: The agents themselves decide the sequence of actions to be performed to achieve the users task. This autonomy enables agents to operate without requiring human intervention. Once the specifications are given to the travel agent, it should be able to proceed on its own to arrange the trip for the user without requiring the user to constantly monitor the agent. Responsiveness: Agents perceive their environment (which may be the Internet, a collection of other agents, etc.) and respond in a timely fashion to changes that occur in it. At the same time,

agents should not simply act in response to their environment, they should be able to exhibit opportunistic, goal-oriented behaviour and take the initiative when appropriate. Communicative Ability: Software agents should provide a user friendly interface so that the user can easily interact with the agent. Agents are social entities and often communicate and collaborate with one another in order to complete their tasks. For example, the travel agent program of one user must be able to communicate with other travel agents to find out about hotels which customers disliked and avoid such hotels. Adaptability: Agents learn about the users behavior and adapt themselves to suit the user. Consider a search agent that retrieves information for the user from the Internet. The search agent should be able to learn about the type of information the user is interested in and adapt itself to deliver only the relevant information to the user. Software agents can be classified as static agents and mobile agents. Static agents achieve their goal by executing on a single machine. On the other hand, mobile agents migrate from one computer to another in the network and execute on several machines. Mobility increases the functionality of the mobile agent and allows the mobile agent to perform tasks beyond the scope of static agents. For example, a travel agent program may visit several hosts such as an airline reservation system, a hotel resources host, etc. in order to achieve its function. This eliminates the need to have all the relevant databases on one host. This article gives the architecture of mobile agents and tradeoffs involved in using them.

Working of Mobile Agents

A mobile agent consists of the program code and the program execution state (the current values of variables, next instruction to be executed, etc.). Initially a mobile agent resides on a computer called the home machine. The agent is then dispatched to execute on a remote computer called a mobile agent host (a mobile agent host is also called mobile agent platform or mobile agent server). When a mobile agent is dispatched the entire code of the mobile agent and the execution state of the mobile agent is transferred to the host. The host provides a suitable execution environment for the mobile agent to execute. The mobile agent uses resources (CPU, memory, etc.) of the host to perform its task. After completing its task on the host, the mobile agent migrates to another computer. Since the state information is also transferred to the host, mobile agents can resume the execution of the code from where they left off in the previous host instead of having to restart execution from the beginning. This continues until the mobile agent returns to its home machine after completing execution on the last machine in its itinerary. The life cycle of a mobile agent 1. The mobile agent is created in the Home Machine. 2. The mobile agent is dispatched to the Host Machine A for execution. 3. The agent executes on Host Machine A. 4. After execution the agent is cloned to create two copies. One copy is dispatched to Host Machine B and the other is dispatched to Host Machine C. 5. The cloned copies execute on their respective hosts.

6. After execution, Host Machine B and C send the mobile agent received by them back to the Home Machine. 7. The Home Machine retracts the agents and the data brought by the agents is analyzed. The agents are then disposed. From this we observe that a mobile agent experiences the following events in its life cycle: Creation: a brand new agent is born and its state is initialized. Dispatch: an agent travels to a new host. Cloning: a twin agent is born and the current state of the original is duplicated in the clone.

Figure 1. The life cycle of a mobile agent. Deactivation: an agent is put to sleep and its state is stored on a disk of the host. Activation: a deactivated agent is brought back to life and its state is restored from disk.

Retraction: an agent is brought back from a remote host along with its state to the home machine. Disposal: an agent is terminated and its state is lost forever.

Properties of Mobile Agents

Mobile agents have the following unique properties. Adaptive Learning: Mobile agents can learn from experiences and adapt themselves to the environment. They can monitor traffic in large networks and learn about the trouble spots in the network. Based on the experiences of the agent in the network the agent can choose better routes to reach the next host. Autonomy: Mobile agents can take some decisions on its own. For example, mobile agents are free to choose the next host and when to migrate to the next host. These decisions are transparent to the user and the decisions are taken in the interest of the user. Mobility: Mobile agents have the ability to move from one host to another in the network.

Advantages of Mobile Agents

Reduction in Network Load The interactions in a distributed system are often achieved using communication protocols. These protocols involve transfer of large volumes of data stored at remote hosts over the network to a central processing site resulting in high network traffic. An alternative to using communication protocols is the use of mobile agents. Mobile agents are dispatched to the remote hosts containing the data. The agents perform the computations at the remote hosts and return back with the results. Since computations are moved to the data storage location instead of moving data to the computing location, network load is reduced. Overcome Network Latency Consider a manufacturing plant in which many critical real time systems are controlled through a network. Controlling many systems through a network involves significant delays, which are not acceptable for critical real time systems. To overcome this problem, mobile agents can be directly dispatched from the central controller in the manufacturing plant to the real time systems. The agents act locally and directly execute the controllers directions. Protocol Encapsulation Protocols enable components of a distributed system to communicate and co-ordinate their activities. However, protocols evolve over a period of time and new features such as better security may be introduced in the protocol. It is a cumbersome task to upgrade the protocol code at all locations in the distributed system. Mobile agents offer a solution to this problem. The

mobile agent code can encapsulate the protocol. When a protocol is upgraded, only the mobile agent has to be altered. Asynchronous and Autonomous Execution Mobile agents operate asynchronously. Once a mobile agent is dispatched from the home machine, the home machine can disconnect from the network. The mobile agent executes autonomously without the intervention of the home machine. The home machine can reconnect at a later time and collect the agent.

Fault Tolerance
Mobile agents react dynamically and autonomously to the changes in their environment, which makes them robust, and fault tolerant. They have the ability to distribute themselves in the network in such a way as to maintain the optimal configuration for solving the particular problem. If a host is being shut down, all agents executing on that machine will be warned and Mobile agents react dynamically and autonomously to the changes in their environment, which makes them robust, and fault tolerant, given time to dispatch themselves and continue their operation on another host in the network.

Disadvantages of Mobile Agents

The main drawback of mobile agents is the security risk involved in using mobile agents. Security risks in a mobile computing environment are two fold. Firstly a malicious mobile agent can damage a host. For example a virus can be disguised as a mobile agent and distributed in the network causing damage to the host machines that execute the agent. On the other hand a malicious host can tamper with the functioning of the mobile agent . Most experts suggest that this risk is far more difficult to deal with. To illustrate this scenario, consider a mobile agent that visits the servers of several airlines to buy a ticket for the lowest price. A malicious airline server can try to obtain sensitive price information from the mobile agent (such as the prices quoted at the servers previously visited by the mobile agent). The malicious server may tamper with the mobile agent and increase the prices quoted by other airlines thereby giving it an unfair advantage. Some servers may even try to steal the credit card number from the mobile agent. The defense mechanisms suggested try to prevent malicious actions in the first place. These include safe programming languages that prevent mobile agents from performing malicious actions on the hosts. If a malicious action does occur then the defense mechanisms detect it as soon as possible and take remedial action. One of the schemes proposed is to introduce a tracing mechanism that records the execution of the mobile agent at each host. When the agent is dispatched to the next host, the trace is also sent. Using this trace, malicious actions can be detected and the malicious host can be identified. However, in spite of significant development in the field of cryptography there still exist many security issues that need to be addressed in mobile agents.

Applications of Mobile Agents

Although no universally used application (normally called killer application) has been developed for them, mobile agents are suitable for the following applications. Parallel Computing: Solving a complex problem on a single computer takes a lot of time. To overcome this, mobile agents can be written to solve the problem. These agents migrate to computers on the network, which have the required resources and use them to solve the problem in parallel thereby reducing the time required to solve the problem. Data Collection: Consider a case wherein, data from many clients has to be processed. In the traditional client-server model, all the clients have to send their data to the server for processing resulting in high network traffic. Instead mobile agents can be sent to the individual clients to process data and send back results to the server, thereby reducing the network load. E-commerce: Mobile agents can travel to different trading sites and help to locate the most appropriate deal, negotiate the deal and even finalize business transactions on behalf of their owners. A mobile agent can be programmed to bid in an online auction on behalf of the user. The user himself need not be online during the auction. Mobile Computing: Wireless Internet access is likely to stay slow and expensive. Power consumption of wireless devices and high connection fee deter users from staying online while some complicated query is handled on behalf of the user. Users can dispatch a mobile agent, which embodies their queries, and log off, and the results can be picked up at a later time.

Mobile device technology overview:

Mobile Phone Technology and Trends Coverage

Source: IDC

Windows CE:

Windows CE (now officially known as Windows Embedded Compact and previously also known as Windows Embedded CE and sometimes abbreviated WinCE) is an operating system developed by Microsoft for embedded systems. Windows CE is a distinct operating system and kernel, rather than a trimmed-down version of desktop Windows. It is not to be confused with Windows XP Embedded which is NT-based. Microsoft licenses Windows CE to OEMs and device makers. The OEMs and device makers can modify and create their own user interfaces and experiences, while Windows CE provides the technical foundation to do so. The current version of Windows Embedded Compact supports Intel x86 and compatibles, MIPS, and ARM processors.

Features of Windows CE:

Windows CE is optimized for devices that have minimal storage .A Windows CE kernel may run in under a megabyte of memory. Devices are often configured without disk storage, and may be configured as a closed system that does not allow for end-user extension (for instance, it can be burned into ROM). Windows CE conforms to the definition of a real-time operating system, with a deterministic interrupt latency. From version 3 and onward, the system supports 256 priority level and uses priority inheritance for dealing with priority inversion. The fundamental unit of execution is the thread. This helps to simplify the interface and improve execution time. Microsoft has stated that the CE is not an intentional initialism, but many people believe CE stands for Consumer Electronics or Compact Edition. Microsoft says the letters instead imply a number of Windows CE design precepts, including Compact, Connectable, Compatible, Companion, and Efficient.[7] The first version, known during development under the code name Pegasus, featured a Windows-like GUI and a number of Microsoft's popular applications, all trimmed down for smaller storage, memory, and speed of the palmtops of the day. Since then, Windows CE has evolved into a component-based, embedded, real-time operating system. It is no longer targeted solely at hand-held computers. [8] Many platforms have been based on the core Windows CE operating system, including Microsoft's AutoPC, Pocket PC 2000, Pocket PC 2002, Windows Mobile 2003, Windows Mobile 2003 SE, Windows Mobile 5.0, Windows Mobile 6, Smartphone 2002, Smartphone 2003, Portable Media Center and many industrial devices and embedded systems. Windows CE even powered select games for the Dreamcast, was the operating system of the Gizmondo handheld, and can partially run on modified Xbox game consoles. A distinctive feature of Windows CE compared to other Microsoft operating systems is that large parts of it are offered in source code form. First, source code was offered to several vendors, so they could adjust it to their hardware. Then products like Platform Builder (an integrated environment for Windows CE OS image creation and integration, or customized operating system designs based on CE) offered several components in source code form to the

general public. However, a number of core components that do not need adaptation to specific hardware environments (other than the CPU family) are still distributed in binary only form.

Relationship to Windows Mobile, Pocket PC, and SmartPhone

Often Windows CE, Windows Mobile, and Pocket PC are used interchangeably in part due to their common origin. This practice is not entirely accurate. Windows CE is a modular/componentized operating system that serves as the foundation of several classes of devices. Some of these modules provide subsets of other components' features (e.g. varying levels of windowing support; DCOM vs COM), others which are separate (Bitmap or TrueType font support), and others which add additional features to another component. One can buy a kit (the Platform Builder) which contains all these components and the tools with which to develop a custom platform. Applications such as Excel Mobile/Pocket Excel are not part of this kit. The older Handheld PC version of Pocket Word and several other older applications are included as samples, however. Windows Mobile is best described as a subset of platforms based on a Windows CE underpinning. Currently, Pocket PC (now called Windows Mobile Classic), SmartPhone (Windows Mobile Standard), and Pocket PC Phone Edition (Windows Mobile Professional) are the three main platforms under the Windows Mobile umbrella. Each platform uses different components of Windows CE, plus supplemental features and applications suited for their respective devices. Pocket PC and Windows Mobile are Microsoft-defined custom platforms for general PDA use, consisting of a Microsoft-defined set of minimum profiles (Professional Edition, Premium Edition) of software and hardware that is supported. The rules for manufacturing a Pocket PC device are stricter than those for producing a custom Windows CE-based platform. The defining characteristics of the Pocket PC are the touchscreen as the primary human interface device and its extremely portable size. CE v3.0 is the basis for Pocket PC 2002. A successor to CE v3.0 is CE.net. [11] "PocketPC [is] a separate layer of code on top of the core Windows CE OS... Pocket PC is based on Windows CE, but it's a different offering." And licensees of Pocket PC are forbidden to modify the WinCE part.[12] The SmartPhone platform is a feature rich OS and interface for cellular phone handsets. SmartPhone offers productivity features to business users, such as email, and multimedia abilities for consumers. The SmartPhone interface relies heavily on joystick navigation and PhonePad input. Devices running SmartPhone do not include a touchscreen interface. SmartPhone devices generally resemble other cellular handset form factors, whereas most Phone Edition devices use a PDA form factor with a larger display.

Symbian:

Symbian is an operating system (OS) and software platform designed for smartphones and currently maintained by Nokia. The Symbian platform is the successor to Symbian OS and Nokia Series 60; unlike Symbian OS, which needed an additional user interface system, Symbian includes a user interface component based on S60 5th Edition. The latest version, Symbian^3, was officially released in Q4 2010, first used in the Nokia N8. Symbian OS was originally developed by Symbian Ltd. It is a descendant of Psion's EPOC and runs exclusively on ARM processors, although an unreleased x86 port existed. Devices based on Symbian accounted for 43.5% of worldwide smartphone market share in 2010 Q2. Some estimates indicate that the cumulative number of mobile devices shipped with the Symbian OS up to the end of Q2 2010 is 385 million.

Features of Symbian: User interface:

Symbian has had a native graphics toolkit since its inception, known as AVKON (formerly known as Series 60). S60 was designed to be manipulated by a keyboard-like interface metaphor, such as the ~15-key augmented telephone keypad, or the mini-QWERTY keyboards. AVKON-based software is binary-compatible with Symbian versions up to and including Symbian^3. Symbian^3 includes the Qt framework, which is now the recommended user interface toolkit for new applications. Qt can also be installed on older Symbian devices. Symbian^4 was planned to introduce a new GUI library framework specifically designed for a touch-based interface, known as "UI Extensions for Mobile" or UIEMO (internal project name "Orbit"), which was built on top of Qt; a preview was released in January 2010, however in October 2010 Nokia announced that Orbit/UIEMO has been cancelled. Nokia currently recommends that developers use Qt Quick with QML, the new high-level GUI and scripting framework for creating visually rich touchscreen interfaces that allows development for both Symbian and MeeGo; it will be delivered to existing Symbian^3 devices as a Qt update. When more applications gradually feature a user interface reworked in Qt, the legacy S60 framework (AVKON) will be deprecated and no longer included with new devices at some point, thus breaking binary compatibility with older S60 applications.

Browser:
Symbian^3 and earlier have a native WebKit based browser; indeed, Symbian was the first mobile platform to make use of WebKit (in June 2005).

Application development
From 2010, Symbian switched to using standard C++ with Qt as the SDK, which can be used with either Qt Creator or Carbide. Qt supports the older Symbian S60 3rd and 5th editions, as well as the new Symbian platform. It also supports Maemo and MeeGo, Windows, Linux and Mac OS X.Alternative application development can be done using Python (see Python for S60), Adobe Flash or Java ME. Symbian OS previously used a Symbian specific C++ version along with Carbide.c++ integrated development environment (IDE) as the native application development environment. Web Runtime (WRT) is a portable application framework that allows creating widgets on the S60 Platform; it is an extension to the S60 WebKit based browser that allows launching multiple browser instances as separate JavaScript applications.

Architecture:
Technology domains and packages Symbian's design is subdivided into technology domains, each of which comprises a number of software packages. Each technology domain has its own roadmap, and the Symbian Foundation has a team of technology managers who manage these technology domain roadmaps. Every package is allocated to exactly one technology domain, based on the general functional area to which the package contributes and by which it may be influenced. By grouping related packages by themes, the Symbian Foundation hopes to encourage a strong community to form around them and to generate discussion and review. The Symbian System Model illustrates the scope of each of the technology domains across the platform packages. Packages are owned and maintained by a package owner, a named individual from an organization member of the Symbian Foundation, who accepts code contributions from the wider Symbian community and is responsible for package. Symbian kernel The Symbian kernel (EKA2) supports sufficiently-fast real-time response to build a single-core phone around itthat is, a phone in which a single processor core executes both the user applications and the signalling stack.[37] The real-time kernel has a microkernel architecture containing only the minimum, most basic primitives and functionality, for maximum robustness, availability and responsiveness. It has been termed a nanokernel, because it needs an extended kernel to implement any other abstractions. It contains a scheduler, memory management and device drivers, with networking, telephony and file system support services in the OS Services Layer or the Base Services Layer. The inclusion of device drivers means the kernel is not a true microkernel.

Design Symbian features pre-emptive multitasking and memory protection, like other operating systems (especially those created for use on desktop computers). EPOC's approach to multitasking was inspired by VMS and is based on asynchronous server-based events. Symbian OS was created with three systems design principles in mind: 1. the integrity and security of user data is paramount 2. user time must not be wasted 3. all resources are scarce To best follow these principles, Symbian uses a microkernel, has a request-and-callback approach to services, and maintains separation between user interface and engine. The OS is optimised for low-power battery-based devices and for ROM-based systems (e.g. features like XIP and re-entrancy in shared libraries). Applications, and the OS itself, follow an objectoriented design: Model-view-controller (MVC). Later OS iterations diluted this approach in response to market demands, notably with the introduction of a real-time kernel and a platform security model in versions 8 and 9. There is a strong emphasis on conserving resources which is exemplified by Symbian-specific programming idioms like descriptors and a cleanup stack. Similar methods exist to conserve disk space, though disks on Symbian devices are usually flash memory. Further, all Symbian programming is event-based, and the central processing unit (CPU) is switched into a low power mode when applications are not directly dealing with an event. This is done via a programming idiom called active objects. Similarly the Symbian approach to threads and processes is driven by reducing overheads. Operating system The All over Model contains the following layers, from top to bottom:

UI Framework Layer Application Services Layer

o

Java ME

OS Services Layer
o o o o

generic OS services communications services multimedia and graphics services connectivity services

Base Services Layer Kernel Services & Hardware Interface Layer

The Base Services Layer is the lowest level reachable by user-side operations; it includes the File Server and User Library, a Plug-In Framework which manages all plug-ins, Store, Central Repository, DBMS and cryptographic services. It also includes the Text Window Server and the Text Shell: the two basic services from which a completely functional port can be created without the need for any higher layer services. Symbian has a microkernel architecture, which means that the minimum necessary is within the kernel to maximise robustness, availability and responsiveness. It contains a scheduler, memory management and device drivers, but other services like networking, telephony and filesystem support are placed in the OS Services Layer or the Base Services Layer. The inclusion of device drivers means the kernel is not a true microkernel. The EKA2 real-time kernel, which has been termed a nanokernel, contains only the most basic primitives and requires an extended kernel to implement any other abstractions. Symbian is designed to emphasise compatibility with other devices, especially removable media file systems. Early development of EPOC led to adopting FAT as the internal file system, and this remains, but an object-oriented persistence model was placed over the underlying FAT to provide a POSIX-style interface and a streaming model. The internal data formats rely on using the same APIs that create the data to run all file manipulations. This has resulted in datadependence and associated difficulties with changes and data migration. There is a large networking and communication subsystem, which has three main servers called: ETEL (EPOC telephony), ESOCK (EPOC sockets) and C32 (responsible for serial communication). Each of these has a plug-in scheme. For example, ESOCK allows different ".PRT" protocol modules to implement various networking protocol schemes. The subsystem also contains code that supports short-range communication links, such as Bluetooth, IrDA and USB. There is also a large volume of user interface (UI) Code. Only the base classes and substructure were contained in Symbian OS, while most of the actual user interfaces were maintained by third parties. This is no longer the case. The three major UIs S60, UIQ and MOAP were contributed to Symbian in 2009. Symbian also contains graphics, text layout and font rendering libraries. All native Symbian C++ applications are built up from three framework classes defined by the application architecture: an application class, a document class and an application user interface class. These classes create the fundamental application behaviour. The remaining needed functions, the application view, data model and data interface, are created independently and interact solely through their APIs with the other classes. Many other things do not yet fit into this model for example, SyncML, Java ME providing another set of APIs on top of most of the OS and multimedia. Many of these are frameworks, and vendors are expected to supply plug-ins to these frameworks from third parties (for example,

Helix Player for multimedia codecs). This has the advantage that the APIs to such areas of functionality are the same on many phone models, and that vendors get a lot of flexibility. But it means that phone vendors needed to do a great deal of integration work to make a Symbian OS phone. Symbian includes a reference user-interface called "TechView." It provides a basis for starting customisation and is the environment in which much Symbian test and example code runs. It is very similar to the user interface from the Psion Series 5 personal organiser and is not used for any production phone user interface.

J2ME:
Java Platform, Micro Edition, or Java ME, is a Java platform designed for embedded systems (mobile devices are one kind of such systems) . Target devices range from industrial controls to mobile phones (especially feature phones) and set-top boxes. Java ME was formerly known as Java 2 Platform, Micro Edition (J2ME). Java ME was designed by Sun Microsystems, now a subsidiary of Oracle Corporation; the platform replaced a similar technology, PersonalJava. Originally developed under the Java Community Process as JSR 68, the different flavors of Java ME have evolved in separate JSRs. Sun provides a reference implementation of the specification, but has tended not to provide free binary implementations of its Java ME runtime environment for mobile devices, rather relying on third parties to provide their own. As of 22 December 2006, the Java ME source code is licensed under the GNU General Public License, and is released under the project name phoneME. As of 2008, all Java ME platforms are currently restricted to JRE 1.3 features and use that version of the class file format (internally known as version 47.0). Should Oracle ever declare a new round of Java ME configuration versions that support the later class file formats and language features, such as those corresponding JRE 1.5 or 1.6 (notably, generics), it will entail extra work on the part of all platform vendors to update their JREs. Java ME devices implement a profile. The most common of these are the Mobile Information Device Profile aimed at mobile devices, such as cell phones, and the Personal Profile aimed at consumer products and embedded devices like set-top boxes and PDAs. Profiles are subsets of configurations, of which there are currently two: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). There are more than 2.1 billion Java ME enabled mobile phones and PDAs, but it is becoming old technology as it is not used on any of today's newest mobile platforms (eg iPhone, Android, Windows Phone 7, MeeGo, BlackBerry's new QNX).

Connected Limited Device Configuration

The Connected Limited Device Configuration (CLDC) contains a strict subset of the Java-class libraries, and is the minimum amount needed for a Java virtual machine to operate. CLDC is basically used for classifying myriad devices into a fixed configuration. A configuration provides the most basic set of libraries and virtual-machine features that must be present in each implementation of a J2ME environment. When coupled with one or more profiles, the Connected Limited Device Configuration gives developers a solid Java platform for creating applications for consumer and embedded devices.

Mobile Information Device Profile

Designed for mobile phones, the Mobile Information Device Profile includes a GUI, and a data storage API, and MIDP 2.0 includes a basic 2D gaming API. Applications written for this profile are called MIDlets. Almost all new cell phones come with a MIDP implementation, and it is now the de facto standard for downloadable cell phone games. However, many cellphones can run only those MIDlets that have been approved by the carrier, especially in North America. JSR 271: Mobile Information Device Profile 3 (Final release on 09 Dec, 2009) specified the 3rd generation Mobile Information Device Profile (MIDP3), expanding upon the functionality in all areas as well as improving interoperability across devices. A key design goal of MIDP3 is backward compatibility with MIDP2 content.

Information Module Profile

The Information Module Profile (IMP) is a profile for embedded, "headless" devices such as vending machines, industrial embedded applications, security systems, and similar devices with either simple or no display and with some limited network connectivity. Originally introduced by Siemens Mobile and Nokia as JSR-195, IMP 1.0 is a strict subset of MIDP 1.0 except that it doesn't include user interface APIs in other words, it doesn't include support for the Java package javax.microedition.lcdui. JSR-228, also known as IMP-NG, is IMP's next generation that is based on MIDP 2.0, leveraging MIDP 2.0's new security and networking types and APIs, and other APIs such as PushRegistry and platformRequest(), but again it doesn't include UI APIs, nor the game API.

Connected Device Configuration

The Connected Device Configuration is a subset of Java SE, containing almost all the libraries that are not GUI related. It is richer than CLDC.

Foundation Profile
The Foundation Profile is a Java ME Connected Device Configuration (CDC) profile. This profile is intended to be used by devices requiring a complete implementation of the Java virtual machine up to and including the entire Java Platform, Standard Edition API. Typical

implementations will use some subset of that API set depending on the additional profiles supported. This document describes the facilities that the Foundation Profile provides to the device and other profiles that use it. This specification was developed under the Java Community Process.

Personal Basis Profile

The Personal Basis Profile extends the Foundation Profile to include lightweight GUI support in the form of an AWT subset. This is the platform that BD-J is built upon.

Pocket PC:
According to Microsoft, the Pocket PC is "a handheld device that enables users to store and retrieve e-mail, contacts, appointments, tasks, play multimedia files, games, exchange text messages with Windows Live Messenger (formerly known as MSN Messenger), browse the Web, and more." (src: microsoft buyersguide)[dead link] From a technical standpoint, "Pocket PC" is a Microsoft specification that sets various hardware and software requirements for mobile devices bearing the "Pocket PC" label. For instance, any device which is to be classified as a Pocket PC must:

Run Microsoft's Windows Mobile, PocketPC edition Come bundled with a specific suite of applications in ROM Note: the name Windows Mobile includes both the Windows CE operating system and a suite of basic applications along with a specified user interface Include a touchscreen Include a directional pad or touchpad Include a set of hardware application buttons Be based on an ARM version 4 compatible CPU, Intel XScale CPU, MIPS CPU or SH3 CPU. (As of the Pocket PC 2002 specification, ARM-based CPUs are required.)

BREW: Binary Runtime Environment for Wireless

Brew (Brew MP) is an application development platform created by Qualcomm, originally for CDMA mobile phones. As a software platform that can download and run small programs for playing games, sending messages, and sharing photos, the main advantage of Brew MP is that the application developers can easily port their applications among all Brew MP devices. Brew MP acts between the application and the wireless device on-chip operating system in order to allow programmers

to develop applications without needing to code for system interface or understand wireless applications.