Evaluation against Requirements

This section evaluates the outcome of the project against the requirements that were defined and described in Chapter 3. Mainly, the requirements of this project were set regarding three distinct parts of the developed system; the application on the client side, the application on the server side and the envisaged communication framework that defined the connectivity options that could enable the transmission of GPS coordinates from the clients to the server.

At this point, it should be highlighted that the focus of this project and the overall aim of it was to equip a mobile device with the capability of sending GPS coordinates to a server via the best suited wireless communication option among the ones that could be applied in the Mountain Rescue domain. This aim was successfully achieved and an Ipaq 6915 PDA was equipped with the ability of identifying the available communication option (WIFI, GPRS or SMS) and utilizing it to send GPS coordinates to the server.

6.4.1

Communication Framework vs Requirements

The first part of this project was to theoretically and practically study and define a communication framework that could provide the grounding for the communication between a client and a server. This communication framework succeeded in defining three different connectivity options that could be applied on the Mountain Rescue Domain considering the transmission of GPS coordinates. The first connectivity option was to transfer GPS coordinates via IPv4 or IPv6 over a WIFI network, the second one was via IPv4 using GPRS over the GSM network and the third one was to transmit them as SMS messages via the GSM network.

The defined connectivity options were carefully identified, assessed and prioritized based on main criteria, namely their availability, cost to be purchased and ran, the extensibility that they can provide, their ability to follow technological evolution and their practicality. Although their thorough evaluation could only be done with studies on the Mountain Rescue Domain the author of this dissertation believes that the devised communication framework meets its requirements as it successfully provided the grounding for the application developed for the client. Moreover, the properties that were used to define the communication options included in the communication framework, are general enough to provide a promising framework that could be reused or extended for other network services in such a domain.

6.4.2

Client vs Requirements

The high-level requirement that was set for the application that was developed for the client side was met as the conducted experiment proved that the application was able to identify the best suited connectivity option and utilize it for transmitting GPS coordinates. This high level requirement was split into more detailed ones that should be evaluated one by one. Therefore, the detailed requirements for the application developed for the client side were :

It should be able to acquire real-time GPS coordinates.

□The developed application was able to acquire real-time GPS coordinates either from an external GPS device or from the internal GPS module of the PDA. The conducted experiment proved the use of the external GPS device.

It should be able to identify which of the predefined connectivity options are

available.

□ The developed application was able to identify the availability of each connectivity options that was defined in the envisaged communication framework. The conducted experimented pointed out that there were times when the Operating System of the PDA used was unable to connect to the wireless network and therefore the application was correctly identifying that the WIFI connectivity option was not available and should not be used.

It should be able to utilize the best suited connectivity option and seamlessly

swap among them based on some criteria.

□ The developed application was able to identify and swap to the best suited connectivity option without any intervention from the user. An Operating System limitation regarding the Connection Manager networking component (described in Section 5.3.6.1), prevented the immediate swap from WIFI to GPRS unless the WIFI coverage was completely lost. Even at these occasions, the application was able to identify the loss and swap to another connectivity option after a while.

It should be able to support IPv4 and IPv6.

□ The developed application was able to support both IPv4 and IPv6. The IPv6 support was fully designed and implemented but was not evaluated thoroughly in the

testbed that was used for the evaluation of the project as the wireless network of the University’s campus could not support IPv6.

It should be able to transmit GPS coordinates in defined intervals.

□The developed application was able to transmit GPS coordinates according to the defined 15 second intervals when a specific communication option was set. Due to a hardware limitation of the GPRS class B module (described in Section 5.3.6.2) the specified interval was not followed when the application had to swap from WIFI to GPRS as it had to wait for the GPRS connection to be established.

Moreover, the application that was developed for the client’s side could be used without any configuration or experience needed from the rescue worker. In addition, it could present to the rescue worker many useful information, such as its current GPS coordinates, the communication option used and the number of packets sent from using each communication method. Finally, the client’s application was able to present a Map to the user with its current location based on the information retrieved from the GPS module.

Concluding, the difficult task of developing an application for a mobile device with many hardware and software limitations, and equip it with the capability of sending GPS coordinates over different connectivity options was achieved successfully.

6.4.3

Server vs Requirements

As the main focus of this project was on the client’s side the high level requirement for the server’s application was to be able to just receive the GPS coordinates regardless of the connectivity option that the client used for their transmission. This high level requirement was split into the following detailed requirements :

It should be able to listen for GPS coordinates regardless the connectivity

option that the client used to sent them

□The experiment that we conducted proved that the developed application for the server was able to listen for GPS coordinates regardless of the connectivity option used for their transmission.

It should be able to identify the exact node that sent a packet and the exact

connectivity option used

□The application developed for the server was successfully identifying the exact connectivity option used for each received packet and also the node ID of the client that send it. Moreover, the application was able to analyze the content of each packet and present the suitable information to the Mountain Rescue coordinator.

It should be able to identify packets received in the wrong order.

□The application developed for the server was able to identify packets received in the wrong order. Although such an incident did not occur during the presented experiment, it was identified in a few of the numerous experiments that we did and

was successfully confronted from the server. Interestingly, there are occasions when even SMS messages arrive in wrong order.

The application for the server side has successfully satisfied the above requirements and was also able to present, in a nice way, all the retrieved information to the Mountain Rescue coordinator. The coordinator, located at the headquarters of the team, is able to see a map that gets updated every time a message is received and could also be informed of the node ID of the client that send it. Moreover, it could be informed of the connectivity option used, the overall number of messages received, the time that a packet was sent and many more information regarding the status of the server and the last message received.

Judging from the conducted experiment it can be concluded that the devised system has successfully met its main aim, as GPS coordinates were transferred from a client roaming in an environment with heterogeneity in the provided connectivity options. Moreover, the each part of the devised system has also successfully met all its requirements. Although the developed system is just a prototype, and as such is evaluated, it provides a promising grounding for future work in this domain.