How to Overcome the Limits of Fixed-Function Mobile Devices
How to Overcome the Limits of Fixed-Function Mobile Devices
By: Peter Baldwin
Jan. 1, 2000 12:00 AM
Here's how system provisioning can provide a way for carriers and device manufacturers to introduce new capabilities for handsets after they've been deployed in the field, ensuring the most up-to-date services without incurring high costs.
Mobile data services such as gaming, video messaging, graphical enterprise applications, and music offer an excellent opportunity to drive revenue for wireless carriers and portable device manufacturers. But many wonder how today's fixed-function Java technologyenabled mobile devices can deliver ever-changing and increasingly sophisticated services to the market with the speed and quality users demand, while minimizing standards fragmentation.
Betting on what the market will subscribe to by integrating as many technologies as possible into a device can lead to unnecessarily high development costs, inefficient use of technology, and "technology handcuffs" that restrict the wireless carrier and device manufacturer from providing the services users want. This article shows how system provisioning can provide a way for carriers and device manufacturers to introduce new capabilities for handsets after they've been deployed in the field, ensuring the most up-to-date services without incurring high costs.
These data services will provide carriers with a much-needed increase in the average revenue per user (ARPU). However, to provide these new services, next-generation handsets will need to contain many new features. Plus, the addition of more software on the handset means that manufacturers must ensure the same level of reliability and performance that consumers have come to expect from their mobile phones.
Carriers and handset manufacturers will also have to support the latest standards if they want to offer compelling services to the broadest audience. Currently there are many new, sophisticated media formats and graphics subsystems, as well as new Java technology standards in development that must be integrated, especially rich-media standards such as MPEG-4, XMF Audio, SVG graphics, and games engines. Fragmentation of new standards in the mobile market is forcing content developers to bet on platforms, which is precisely the problem that Java technology was designed to solve.
The earliest OTA provisioning methodologies gave the carrier the ability to remotely interact with the handset to activate users and update roaming and area code lists. Later with WAP-based devices, OTA provisioning technologies gave the carrier the ability to remotely change WAP configuration parameters.
Then SyncML, another open standard protocol, enabled synchronization of data, such as address book and calendar, between mobile devices and corporate servers, such as Microsoft Exchange. Later SyncML/DM was extended for limited device management functions. Earlier OTA provisioning systems were primarily focused on the configuration of remote devices and other device management functions. In short, this first-generation of mobile device provisioning was limited (see Figure 1).
System provisioning, the second-generation of OTA provisioning, leverages Java technology and opens the door for carriers to provide new and compelling services to the handset after the phone has been introduced to the marketplace. It enables wireless carriers and device manufacturers to provide new capabilities and system upgrades for mobile devices remotely, reducing handset and customer-care costs and opening a wide gamut of mobile ser-vices for the wireless carriers to sell to their customers.
System Provisioning Defined
A system-provisioning server provides two main services. First, it allows the carrier and handset manufacturer to ensure that their customers' handsets always contain the latest release of the components that make up the handset application image. Second, it allows the carrier to provision new capabilities dynamically into the handset. The provisioning server maintains a database for each handset owner, and a list of the assets/capabilities on their devices.
System provisioning servers also provide asset/capabilities management. The key is to move the management of software components/capabilities to the server, which keeps track of the versions of the various components/capabilities on the handset. Users can be notified when new versions are available, allowing the carrier to ensure that the software is always up to date.
The server keeps track of the versions and manages a list of assets/capabilities on the handset. This allows the carrier to personalize the handset, offering unique services for any given consumer. Providing this enhanced functionality lifts the burden of managing the services from the consumer (see Figure 3).
To illustrate how system provisioning works, let's say a consumer requests a sports highlight service. The system-provisioning server is queried to determine the current handset capabilities. If the handset supports the capabilities, which in this instance is a particular video CODEC and a specific Java-technology standard API, then the sports highlight service request is processed. If not, a new image that contains the new video CODEC and Java-technology standard API is downloaded, and the new capabilities are re-flashed on the client handset. The sports highlight service is then initiated and the consumer gets the desired service, with a mobile device that has new enhanced capabilities (see Figure 4).
The system must have enough performance to keep up with user demands, and include the tools and services to allow system checks and upgrades to occur without subscribers losing service. Keeping download time to a minimum is also important. And good bandwidth utilization is essential to enable carriers to provide additional services and bug fixes on slower-speed networks.
These requirements make the Java platform, which makes code portable, the natural choice for developing OTA provisioning systems. And as provisioning technologies must also be scalable, secure, and efficient, especially as they grow, the Java 2 Platform, Enterprise Edition (J2EE), was chosen for the server side of the provisioning component because it can fulfill such needs. J2EE's infrastructure includes features such as security, distributed transaction management, and connection pool management, all of which are essential for industrial strength system-provisioning servers. The components are reusable, so development time is substantially reduced.
A typical secure system-provisioning server is based on J2EE and consists of the following components: a profile database that keeps track of handset capabilities; a device database that manages assets, and tracks component versions and native extensions; a protocol component that contains security measures, protocols, and standards; and administration tools for managing handset images and reports.
The system-provisioning client-side component is based on Java 2 Micro Edition (J2ME) technology, Mobile Information Device Profile (MIDP), Personal Profile (PP), or PDA Profile (PDAP). The provisioning client typically contains the following components: a download agent responsible for downloading an image (firmware) from the server into flash memory, which includes interactions with a flash memory manager for standard flash and read/write support; a communications manager for TCP/IP and HTTPS protocols for server/client communication; and a memory map manager to manage flash workspace, RAM, and image segmentation. An upload agent is responsible for transferring the downloaded data into the new image.
System provisioning enables new capabilities to be sent to handsets, providing the widest array of possible mobile services that can be sold to a subscriber audience and enabling wireless carriers to meet market demands in real time. Capabilities typically take the form of certified native code for that handset. This approach eliminates the fixed-function mobile device paradigm and significantly increases the potential of the carrier's network.
There are two common approaches to implementing a remote updating capability. The first approach calls for a new image to be downloaded into a special workspace area reserved for system updating. A minimum size is required, typically the size of the flash erase block, which is usually around 128KB.
The main advantage of using a reserved area is that the handset can take advantage of high-level APIs, and full handset functionality can continue to be available during the download process. Also the radio stack used by the DSP can be downloaded during this process, and XML-based control files can be used to control the download process. The disadvantage of this method is the need for additional flash space. Since compression is used to maximize the available workspace, it is possible that certain updates could exceed the size of the workspace area. In principle, this can be resolved by successive interim updates.
The second approach is to download and flash at the same time. In this scenario, the handset contains redundant code that allows the handset to function as portions of the handset image are updated. The advantage of this implementation is that there are no additional flash space requirements and no limit on the size of the image being downloaded.
The downside of this approach is a limitation on which components can actually be altered. For example, portions of the communications stack can't be updated because they are in use during the download process. Another issue is that the increased complexity of the redundant code to support the update process can require modifications that cannot be updated during the process, but can be done only by the handset manufacturer.
All that being said, using a reserved area to download system updates to a handset is the most functional and practical approach for remote updating. This approach will become increasingly more affordable and widely used as the cost of flash memory decreases. The ability to flash in new capabilities and update existing functionality will also increase.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week