Much of the hype in the design community around the portable communication and set-top box sectors have focused on building equipment, such as 3G mobiles, that provide video conferencing capabilities, web access, MP-3 downloads, and more. During these discussions, much of the focus has centered on advanced processing techniques, new RF front-end designs, analog design tips, and more.

But, the true cornerstone for these designs may not lie in the hardware design. Rather, it could lie on the software side with the development and implementation of embedded web browsers for these devices.

No matter how good a hardware design is, if users find it difficult to use, then the design will never be successful. That's why embedded browser design is such a vital part of the mobile communication design process. Here are 9 tips for improving the design and implementation of embedded web browsers in 3G, PDA, and other advanced communication architectures.

Tip 1: Understand design limitations

With more and more devices offering access to the Internet, the microbrowser is becoming the new embedded interface. This interface can range from a two-color liquid crystal display (LCD) screen to a multi-colored graphical display or a television screen. Figure 1 shows some of the typical microbrowser component modules.

Click Here for Figure 1
Figure 1: Typical component modules of a microbrowser.
The Internet offers enormous amounts of data that can meet the need of any application. This data is tailored towards the PC. When the content is too rich, it can be difficult to navigate when using an embedded browsing device.

The first consideration when selecting a microbrowser is how it will integrate into your tool chain and other software components (such as an RTOS and network stack). Most embedded browsers are developed using ANSI C. However, since the use of embedded browsers is fairly new, there has been limited porting to different OS. This leaves the porting task in your hands.

When selecting a microbrowser as the core user interface to a broad range of products, you will need to make sure that the browser is very adaptable to a broad range of device types -- from high-end Internet appliances to low-end performance limited systems. In order to have this flexibility the core browser functionality should be abstracted away from the hardware.

Another key concern is a browser's adaptability. Many web programmers can testify to the ever-changing and new standards being generated from different Internet groups. Having the ability to adapt to these new standards is a key. With a little foresight, you can ensure that your browser is capable of being updated in the field to take full advantage of the latest Internet standards.

Tip 2: Memory usage counts

The need to have the core microbrowser code as small as possible is a benefit when adapting the browser to multiple devices. Components can then be added to achieve the desired functionality for a specific device.

The amount of memory (RAM and ROM) needed directly corresponds to the functionality desired in the browser. Without taking too in-depth a look into the requirements of any one particular browser, the ranges start around 250 KB of ROM for core browser features and extend up to 900 KB when accommodating the full feature set. RAM resources vary from 200 KB to support core browser capabilities up to 1000 KB when utilizing all optional features.

Other storage related issues needing consideration are the method for caching web pages and dealing with the storage of cookies. Web page caching allows the user faster access to content previously downloaded from the Internet. By providing a mechanism to cache web pages, when a user back tracks during a browsing session, the web page can be retrieved from local storage rather than resubmitting a request for the page over the Internet. Since most embedded devices have limited bandwidth capabilities, the ability to retrieve web pages quickly is a concern.

One possible solution is to provide caching with a limitation on the amount of memory used. Older web pages are discarded first based on a memory limit devoted to storing web pages. The amount of resources used can be dynamically set based on the currently available memory in the system. Cookies present a similar problem where most web sites want to use device memory resources to store information.

There are two things needed to accommodate web page caching and cookies, the first is a file system module and the other is the physical memory resource. A file system has the ability to store files in a memory region, whether it is RAM or flash ROM, with the capability to access, update, and delete the stored file.

There are several approaches for implementing the physical memory resource. Devoting a portion of RAM or flash ROM to store web pages or cookies is one solution. Another way is to have some sort of add-in memory, such as CompactFlash or MultiMedia Card (MMC). Many PDA devices include some type of add-in memory to extend passed the capabilities of the main system memory. This allows the user to save valuable main memory for the device's core application execution and use external (and usually slower to access) memory for less important web page caching.

Tip 3: Dealing with the display

The display type will dictate the functionality that the browser will need to supply.1 A major concern with the selection of the display is the power consumption. For mobile devices, the usage of precious battery power is a key design consideration.

If you are implementing a browser on a text only display, similar to many web phones, you will not need the graphical content present on the majority of web sites. In order to deal with the limitations of certain devices, some browsers offer the capability to dynamically alter the content as the device receives it.

Enhanced displays are also available for higher-end devices, such as for a PDA or Internet Appliances. The two popular choices for these types of devices are either LCD or a cathode ray tube (CRT).

LCDs are typically used for handheld devices offering low power consumption, lighter weights, and compact sizes. There are two types of LCDs used today, passive-matrix and active-matrix. The passive-matrix display grids are typically less expensive, however, suffer from a low response time causing a slower image refresh. The active-matrix display grid uses thin film transistors (TFT).

CRTs on the other hand are typically far less expensive for a given screen size. However, they consume far more power and outweigh equivalent LCDs.

Many new display technology alternatives are being developed that may meet the needs of your device. These technologies include ThinCRT field-emission displays (FED), electrophoretic displays, organic light-emitting diodes (OLED), and microelectromechanical (MEMS) system displays.

Tip 4: Use Advanced Display Technologies

Some browsers implement a programming technique called double-buffering. This allows the next display frame to be stored in an off-screen frame buffer while the current frame is being displayed. When the current frame is finished, the next frame is ready to write out to the display immediately.

Multiple language support and foreign fonts may also be concerns for your device. If your device is going to be marketed in different countries, some investigation is necessary to determine if your browser and display can support this.2,3

For set-top box designers, display size can vary greatly. Along with this, rendering of characters so that the user can read what is displayed on their screen becomes an issue. Not only that, but the distance a user may sit from the television set can also hinder the ability to read characters if they are not formatted properly. A group exists called the Advanced Television Enhancement Forum (ATVEF) that is heading the standards being developed for enhancing televisions to include Internet content.4

Tip 5: Dealing with user input devices

The mechanism for getting input from the user can vary greatly from a numeric keypad to a stylus with a touch-screen display. Allowing a user to access web links might be an easy design implementation. However, if a user needs to input text for an email message, for example, a numeric keypad may not be the best method. Typing a message of more than a line using this type of input device can be cumbersome. Offering alternative methods such as handwriting recognition can increase the usability of the device.

Embedded browsers for automotive applications have safety concerns if a user accesses the device while driving. One method for obtaining input from a user while driving is through voice recognition. Having the device capable of understanding audible commands and respond aurally provides a safer way for the user to operate the device.

Tip 6: Be Concerned with Processing Power

Processors used in most embedded devices do not have the power of those found in PCs. An embedded browser needs to deal with this when accessing rich content found on most web sites. The ability for the processor to render web pages is going to depend on the content included on the web page.

Pages with large amounts of graphical content or a lot of script files need to be handled by the browser decoding and interpreter engines. This can overload the processor and cause the device to become unresponsive, and in turn, unusable. Careful consideration is necessary when deciding how to extend the embedded device to incorporate the ability to handle these types of content.

Tip 7: Watch speed concerns

For mobile devices using a wireless connection, speed is a major concern. For these devices typically the connection speed is anywhere from 9600 bps (bits per second) to 28.8 Kbps. At these low rates it can take up to 3.5 minutes to download a 250 KB web page. If the link is very lossy, this time can be significantly extended.

This is a system design issue that needs to be addressed based on the capabilities of client device. Below we'll take a look at some standards and protocols that address these concerns.

Tip 8: Boost security

When users are giving out private information, such as credit card numbers, providing some level of security is important. Embedded browsers can help out by implementing some level of security.

Right now, the secure sockets layer (SSL) protocol is the most commonly implemented security mechanism in today's embedded browsers. Originally developed by Netscape, SSL allows authentication of the client and server, as well as negotiation of the encryption algorithm and secret keys used prior to any private data being exchanged. Higher-level reliable protocols, such as TCP, layer on top of SSL transparently.

Another secure protocol implemented in some microbrowsers is secure HTTP (S-HTTP). S-HTTP is designed to send individual messages securely whereas SSL establishes a secure connection between two computers. Each S-HTTP file is encrypted and can also contain a digital certificate.

Adding security, however, can also increase the load on the processor. If the encryption algorithm implementation is not efficient for your processor, a large amount of time can be spent decrypting incoming packets.

Tip 9: Standards groups can help

A number of working groups exist that are actively working on providing standards to deal with the issues involved in accessing the Internet from devices other than the typical PC. One group is the World Wide Web Consortium (W3C).5 Within W3C, a number of working groups exist that target specific issues in the Internet community. These working groups develop standards for adoption by the Internet community to ensure interoperability across different platforms.

The W3C working group specifically targeting the integration of Internet technologies in mobile devices is the Device Independence Activity. The following are a few of the standards aimed at the interoperability of non-PC devices.

The composite capability/preferences profiles (CC/PP) standard details the description (hardware, software and application) of a device's capabilities and user preferences that can be used by the server to guide the content presented to that device. The server uses the attribute names and associated values contained in a CC/PP profile to determine the most appropriate form of a resource to deliver to a client.

The cascading style sheets (CSS -- Level 1 and Level 2) specification defines a language that allows the attaching of style, such as fonts and spacing, to documents, such as HTML pages. The goal is to separate the presentation style of the document from the content of the document, allowing the device to decide on the best method for rendering the information. A subset of the CSS Level 2 specification is being developed specifically for mobile devices.

Scalable vector graphics (SVG) is a language, written in XML, which describes graphic shapes, images, and text. SVG allows a device to determine the method for rendering the content that will be best suited for that device. A disadvantage for mobile devices is that SVG can be CPU and memory intensive.

Another group devoted to forming the delivery of information to mobile users is the Wireless Application Protocol (WAP) Forum.6,7 WAP defines a system architecture from the protocol stack to the markup language based on existing programming models to solve problems with wireless mobile networks. One important detail to keep in mind is that web pages accessed by a WAP browser must be written in Wireless Markup Language (WML) or converted to WML at the server. This can limit the content available to users.

Wrap up

With the need to incorporate Internet access in embedded systems, the microbrowser is going to become a standard module in embedded devices very soon. Putting a little forethought into the design when selecting an embedded browser will allow your device to meet your user's needs and accommodate future features.