Transport Layer

Overview

Mobile devices and the OpenMRS server need to communicate with each other in certain ways. The server needs to export forms to the mobile device, holding data which has to be displayed on the handset or specifying which data has to be collected. Further, collected data has to be transmitted to the OpenMRS server. The transport layer will provide a secure and flexible way for all kind of data transport. There are multiple ways in which client and server could interact with each other, including internet (HTTP over WAP or IP), SMS, WIFI or serial connection (cable, irda or bluetooth).

Requirements

Ways of Transport

The transport layer should not be limited to certain modes of transport. More transport methods might be added in the future. Still, the transport method can be divided into the following groups:

Problems:

•  

  • The sender needs to know the recipient's MSISDN

  • Sending an SMS causes costs

  • The capacity of a short message is limited to 160 characters. This is certainly not enough for transmission of patient data or forms (TODO: check on binary messages). However, SMS might be a very useful way to notify a mobile device that there is data available. The mobile device then can initiate a (HTTP) connection to the server to download the data. Mobile devices are able to listen on a certain port for incoming SMS using the Push Registry

  • As opposed to mobile devices, which can be expected to support SMS, additional hard- and software will be required on the server side (GSM modem, SMS server software).

    Problems:

  • It is impossible for the server to initiate an internet connection to a mobile device.
    Possible solutions:

    • The client performs checks for available data periodically.

    • The server may send a SMS to inform the client that there is data available for it. The client could listen on a certain port to incoming SMS (using the Push Registry) and then initiate an internet connection to the server to retrieve the data.

      Examples:

  • Wi-Fi

  • Serial connection (cable, bluetooth, irda)

     

Open

Use Case Scenarios

1. Server exports data to mobile client(s)

The server wants to send data, i.e. a set of XForms to a number of clients.
Problem: The server needs to address each clients using some kind of unique identifier.

2. Client sends data directly to server

The client sends the collected data by connecting to the server directly using an internet connection. The client receives immediate feedback about success of the transmission. If there is data available for the client the server might include it in the response, so all transfer can be done within a single session.

3. Client stores data on removable storage media

The client saves the data on a removable storage media which then can be carried to the final destination or an intermediate device.

4. Client sends data via an intermediate station

It is not possible for the client to initiate a direct connection to the server. Instead, the client sends the data (together with the final recipient's address) to another device (possibly a laptop), which in turn has the ability to connect to the server directly (if not immediately, then later on). The second device queues the data and may send it to the server using a direct connection and notify the actual sender (the first device) about state of the transmission (success, failure, still queued). The intermediate station might also save the data on a removable storage media for physical transport. In the latter case, it might be impossible to provide a status report about successful transmission to the sender.

The client might connect to the intermediate device via serial connection (cable, bluetooth) or Wi-Fi.

Registration

We need a way to announce available mobile clients to the server. Several methods may be possible:

1. Clients should be able to register themselves at a server by making a HTTP request and retrieve their unique id in the response.

2. Alternatively, it should be possible to enter new devices directly at the server. In such cases, one has to enter the MSISDN. The server could inform the device through SMS that is should connect to the server and retrieve it's unique identifier.

3. Together with installation: When the mobile client is being installed via OTA, the unique identifier could already be included in the JAD file. Still, the server needs know the MSISDN of the device.

Problems:

• What to do in cases when the server is not accessible through internet connections and does not provide functionality for sending SMS?

• The server needs the MSISDN of the mobile. It is not possible for a MIDlet to access the devices MSISDN, so it must be entered by the user, otherwise it cannot transmitted to the server through the registration request.

Open

Implementation

Draft:]

The transport layer will consist of three components:

1. A server component that will be responsible for sending data to mobile devices as well as for handling incoming data from mobile devices. It will export data to mobile clients and receive data send back to the server by those clients.

2. A client component that will handle all data transmission on the mobile device. It has to be able to receive data sent from the server to the particular device. Further, it should allow sending data back to a server either directly or through an intermediate station.

3. An intermediate device component that offers a service to other devices to forward their to the actual destination. It will act as some kind of message queue. Any device may send it's data to this component along with the final destination address. This component may run i.e. on a desktop PC or a laptop.
   Even though these three components are independent they may share common parts of code.

Open questions

• The mobile client needs to know to which server it has to deliver the data. This information could be part of the data exported from the server. Is the destination server always the same server that exported the data? An (alternate) destination could be entered on the device when the data transmission process is initiated by the user.

• Is the destination OpenMRS server always accessible through an internet connection. (Probably not.)

• We need a way to address each device (client as well as server) using some kind of unique identifier.

• For mobile devices the MSISDN must be available for the server.