> 8.11 | How To

> This chapter is a step-by-step guide for using OTAP.

> 1. | Do you need OTAP? Is there any chance that it might be necessary to update the Java application, install a new one or delete it? It could be that device is in the field and you cannot or do not want to update it over the serial line. If the answer is “yes” then read through the following steps, if the answer is “no” then consider simply setting the OTAP SMS password to protect your system. Then you are finished with OTAP.

> 2. | Take a look at the parameters (Section 8.3), which control OTAP. You need to decide which of them you want to allow to be changed over the air (by SMS) and which you do not. This is mainly a question of security and what can fit into a short message. Then set the “unchangeable” parameters with the AT command (AT^SJOTAP).

> 3. | Prepare the http server. The server must be accessible from your device over TCP/IP. That means there is a route from your device over the air interface to the http server and back. When in doubt, write a small Java application using the httpConnection Interface to test it.

> 4. | Prepare the JAR and JAD files which are to be loaded over the air. Make sure that these files conform to the requirements listed in Section 8.5 and that they represent a valid application which can be started by AT^SJRA.

> 5. | Put the files (JAR and JAD) on the http Server. The files can either be publicly available or protected through basic authentication. When in doubt try to download the files from the server by using a common Web browser on a PC, which can reach your http server over TCP/IP.

> 6. | Prepare the SM sender. The sender must be able to send SMs, which conform to Section 8.4, to your device. When in doubt try to send “normal” SMs to your device which can than be read out from the AT command interface.

> 7. | Test with a local device. Send a suitable short message to your device, which completes the necessary parameter, sets and starts the operation. The operation is finished when the device reboots. You can now check the content of the file system and if the correct jar and jad files were loaded into the correct location.

> 8. | Analyze errors. If the above test failed, looking at your device’s behavior and your http servers access log can give you a hint as to what went wrong:

> - | Ιf the device did not terminate the running Java application and did not reboot, not even after the safety timeout, either your SM was not understood (probably in the wrong format) or it did not properly authenticate (probably used the wrong password) or your parameter set is incomplete for the requested operation.

> - | If the device terminated the running Java application, but did not access your http server, and rebooted after the safety timeout, there were most likely some problems when opening the network connection. Check your network parameters.

> - | If the device downloaded the jad and possibly even the jar file but then rebooted without saving them in the file system, most likely one of the errors outlined in Section 8.5 occurred. These are also the only errors which will return a response. They are posted to the http server if the jad file contains the required URL.

> 9. | Start update of remote devices. If you were able to successfully update your local device, which is hopefully a mirror of all your remote devices, you can start the update of all other devices.