OTA Message

8/3/2019 OTA Message

1/11

OTA OverviewFrom the mobile client's perspective, in concept OTA is simply a matter of findingan interesting application on the Web and initiating its download over the wirelessnetwork. In its simplest form, OTA is pretty straightforward, as Figure 1 illustrates


2/11

Note the participants in this process:Client device with a discovery application - The client device must have softwarethat allows the user to locate applications at a particular provisioning portal on thenetwork, and to choose which applications to download - this software is referred toas 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 thedownload server; for example, for MIDP OTA this protocol is HTTP.

The Network - This is any appropriate wireless network, which may include a radionetwork and a WAP gateway, for example.

The Download Server - Also called aprovisioning portal, or server, or vending machine,this is a host, visible in the network, that typically runs a web server and has accessto a content repository - in its simplest form any Web site can serve as aprovisioning portal. It has two main functions: it provides properly formattedmenus, often written in WML or HTML, that list the applications currently availablefor download, and it provides access (sometimes controlled) to the applications. Asingle download server might support one or many OTA protocols.

The Content Repository - As the name implies, this is the repository of all theapplication descriptors and applications that are available for download.


3/11

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

- Detailed View of an OTA Provisioning System


4/11

As you can see, the process behind the scenes is more involved than what the useractually 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 certifiedbefore making them available for OTA.

B. Content Discovery - As you've already seen, the user directs the discoverapplication to a download portal, which accesses the application repository andprovides a properly formatted menu of the available content and applications.

C. Authenticate - If the provisioning server supports an authentication module, theuser 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 itfrom the provisioning server's repository. Based on information found in thedownloaded application descriptor, the AMS automatically downloads theapplication (the MIDlet suite JAR) from the repository. If required, the user is re-

authenticated. If the application is retrieved successfully, installation is automatic.


5/11

E. Confirmation - The AMS sends a confirmation status to indicate whether theinstallation 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 theprovisioning server.

In addition to the basic features described above, some OTA provisioning serversadd value in the form of features such as:Personalization - the ability to offer selected applications based on userpreferences

Device-based classification - limiting offerings to only those applications that willrun 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. Thefollowing 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.


6/11

MIDP OTA Specification OverviewLet's take a look at the OTA of MIDP applications. The purpose of this section is not toduplicate the information in the OTA specification (see the resources section), but toprovide 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 provisioningservers, including how they download applications. The MIDP OTA specificationdefines 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.0specification itself. It was not a true specification, only a recommended practice, but itprovided a good foundation for the protocol for OTA. Many devices currently supportthe 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 willsupport OTA in a consistent, standard way. It's a great benefit to be able to distributeapplications to many different mobile devices all in the same way.


7/11

The two versions are very similar, but there are a few differences, such as a new JADproperty used by the AMS to report when MIDlet suites are removed, and morestringent checks when updating MIDlet suites. The use of cookies has also beenreplaced 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-cycleChanges to the Java Application Descriptor in support of OTAInteractions between the AMS and the provisioning server

Expected Device FunctionalityThere is certain functionality that MIDP-compliant devices must provide in their supportof OTA:Support for version 1.1 of the Hypertext Transport Protocol (HTTP) - or a protocol thatimplements the functionality of HTTP 1.1, including support for HTTP Basic Authentication (RFC 2617) and theability to prompt for (and resend) user credentials.

Support for a discovery application, as described in the "OTA Overview," that allows theuser to locate applications on the network, and to choose which applications todownload.Support for an application management system, the piece of software in the device thatmanages 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 J2ME-

enabled devices is the Java application manager (JAM).


8/11

OTA Provisioning Life-cycle

You already have a high-level view of some elements of the OTA life-cycle. Let's look atdiscovery, installation, update, execution, and removal of applications in some detail.

The OTA life-cycle is summarized graphically in Below figure


9/11

It all starts with the user instructing the device (using the DA) to search for anapplication of interest on a particular provisioning portal on the network. On findingone, the user selects the application to download and install. After a successfulinstallation, 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 userinterface details, and the DA and AMS implementations. Besides initiating theinstallation, update, or removal of the application, the things that are not transparentrevolve 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 contentappropriately, as I will describe shortly.


10/11

Status CodeDescription (StatusMessage)

MIDP 1.0 MIDP 2.0

900 Success x x

901 Insufficient Memory x x902 User Cancelled x x

903 Loss5 of Service x x

904 JAR size mismatch x x

905 Attribute Mismatch x x

906 Invalid Descriptor x x907 Invalid JAR x

908 Incompatible Configurationor Profile

x

909 Application authenticationfailure

x

910 Application authorizationfailure

x

911 Push registration failure x

912 Deletion Notification x

913 Required package not

supported by the device

x


11/11

OTA Message

Documents

Transcript of OTA Message