OTA Overview From the mobile client's perspective, in concept OTA is simply a matter of finding an interesting application on the

Web and initiating its download over the wireless network. In its simplest form, OTA is pretty straightforward, as Figure 1 illustrates

Note the participants in this process: Client device with a discovery application - The client device must have software that allows the user to locate applications at a particular provisioning portal on the network, and to choose which applications to download - this software is referred to as a discovery application (DA). The discovery application may be browser-based or a native application, so long as it shares a common provisioning protocol with the download server; for example, for MIDP OTA this protocol is HTTP. The Network - This is any appropriate wireless network, which may include a radio network and a WAP gateway, for example. The Download Server - Also called a provisioning portal, or server, or vending machine, this is a host, visible in the network, that typically runs a web server and has access to a content repository - in its simplest form any Web site can serve as a provisioning portal. It has two main functions: it provides properly formatted menus, often written in WML or HTML, that list the applications currently available for download, and it provides access (sometimes controlled) to the applications. A single download server might support one or many OTA protocols. The Content Repository - As the name implies, this is the repository of all the application descriptors and applications that are available for download.

In actual use, OTA is not quite so simple. An OTA provisioning system typically encompasses content publication and management, access control, installation (and upgrading) of applications, and tracking the use of applications (content) for billing purposes. Figure 2 introduces these complexities:

- Detailed View of an OTA Provisioning System

As you can see, the process behind the scenes is more involved than what the user actually sees: A. Content Management - Server-side software manages the repository, typically a database, and supports content versioning, ways for third-party developers to drop their applications, and so on. Some carriers require applications be certified before making them available for OTA. B. Content Discovery - As you've already seen, the user directs the discover application to a download portal, which accesses the application repository and provides a properly formatted menu of the available content and applications. C. Authenticate - If the provisioning server supports an authentication module, the user is authenticated before gaining access to the repository. D. Application retrieval and installation - Once any authentication is complete, downloading the application is a two-part operation, handled by the application management system (AMS), the software in the device that manages the download, installation, execution, and removal of applications and other resources on the device. If an application description (in the form of a JAD file) exists, the AMS downloads it from the provisioning server's repository. Based on information found in the downloaded application descriptor, the AMS automatically downloads the application (the MIDlet suite JAR) from the repository. If required, the user is reauthenticated. If the application is retrieved successfully, installation is automatic.

E. Confirmation - The AMS sends a confirmation status to indicate whether the installation succeeded or failed. F. Tracking - The confirmation status can be used to track the use of the application, for example for billing purposes. A billing system is often integrated into the provisioning server.

In addition to the basic features described above, some OTA provisioning servers add value in the form of features such as: Personalization - the ability to offer selected applications based on user preferences Device-based classification - limiting offerings to only those applications that will run on the user's device
Security - strong user authentication and access control Alerts - notices to users that new applications fitting their preferences are available You now have a high-level perspective of OTA application provisioning. The following sections will turn to the details, first on the client side, where we'll look at MIDlet provisioning specifically, and then on the server side.

MIDP OTA Specification Overview Let's take a look at the OTA of MIDP applications. The purpose of this section is not to duplicate the information in the OTA specification (see the resources section), but to provide you with a good starting point, then encourage you to spend some time reading the actual specification. The MIDP OTA specification defines how MIDP devices interact with provisioning servers, including how they download applications. The MIDP OTA specification defines a user-initiated OTA process - not a server-initiated "push" OTA mechanism. The first version of the MIDP OTA specification appeared after the MIDP 1.0 specification itself. It was not a true specification, only a recommended practice, but it provided a good foundation for the protocol for OTA. Many devices currently support the MIDP1.0 recommendation. MIDP 2.0 improved the MIDP 1.0 recommendation and made it part of the specification. Because it is now part of the standard, all future MIDP devices will support OTA in a consistent, standard way. It's a great benefit to be able to distribute applications to many different mobile devices all in the same way.

The two versions are very similar, but there are a few differences, such as a new JAD property used by the AMS to report when MIDlet suites are removed, and more stringent checks when updating MIDlet suites. The use of cookies has also been replaced by URL rewriting. The MIDP OTA specification can be broken down into the following areas of interest:

Expected device functionality (in support of OTA) The OTA provisioning life-cycle Changes to the Java Application Descriptor in support of OTA Interactions between the AMS and the provisioning server Expected Device Functionality There is certain functionality that MIDP-compliant devices must provide in their support of OTA: Support for version 1.1 of the Hypertext Transport Protocol (HTTP) - or a protocol that implements the functionality of HTTP 1.1, including support for HTTP Basic Authentication (RFC 2617) and the
ability to prompt for (and resend) user credentials.

Support for a discovery application, as described in the "OTA Overview," that allows the user to locate applications on the network, and to choose which applications to download. Support for an application management system, the piece of software in the device that manages the application's life-cycle - download, installation, execution, and removal. (We'll look at life-cycles in the next section.) Another name for the AMS on J2MEenabled devices is the Java application manager (JAM).

OTA Provisioning Life-cycle You already have a high-level view of some elements of the OTA life-cycle. Let's look at discovery, installation, update, execution, and removal of applications in some detail. The OTA life-cycle is summarized graphically in Below figure

It all starts with the user instructing the device (using the DA) to search for an application of interest on a particular provisioning portal on the network. On finding one, the user selects the application to download and install. After a successful installation, the application can be executed, updated, and removed from the device again, all these stages of the life-cycle are managed by the AMS. Most of the OTA life-cycle is transparent to us - the network protocols, the user interface details, and the DA and AMS implementations. Besides initiating the installation, update, or removal of the application, the things that are not transparent revolve around configuration, such as changes to the JAD file, .configuring the DA to point to the right server, and configuring the web server to serve content appropriately, as I will describe shortly.

Status Code

900 901 902 903 904 905 906 907 908

909 910 911 912 913

Description (Status Message) Success Insufficient Memory User Cancelled Loss5 of Service JAR size mismatch Attribute Mismatch Invalid Descriptor Invalid JAR Incompatible Configuration or Profile Application authentication failure Application authorization failure Push registration failure Deletion Notification Required package not supported by the device

MIDP 1.0

MIDP 2.0

x x x x x x x

x x x x x x x x x
x x x x x