Latency Experiment

To do the latency experiment, we set up our testbed as depicted in Figure 14. The OpenMTC platform was installed on two separate machines, one with Intel Xeon CPU E3-1230 V2 CPU, 8GB memory, 1 network interfaces for GSCL, and another with Intel Core i5-3470 CPU, 8GB memory, 1 network interfaces for NSCL. Each machine was installed with Ubuntu 12.04 LTS, which is the operating system suggested by Fraunhofer FOKUS. Before the installation of OpenMTC platform, we also installed the required software for the platform such as nodejs [16] and mongodb [17].

Figure 14: Experiment testbed

In our previous approach, the pushing data to clients problem is not well addressed. By using MQTT, we have developed a better approach than using HTTP for the handler

application. Hence in the following, we only focus on the Scenarios I and II of handler applications in Table 3 of Section 4.2 that collects data to the OpenMTC. The HTTP Proxy in

OpenMTC GSCL 140.113.241.3

OpenMTC NSCL 140.113.241.6 network switch

140.113.241.254

the experiment determines where the data contained in the resource tree by parsing the key

“topic” of the http post payload. The MQTT Proxy is the same as what we introduced in Chap. 4. To measure latency between pushing the data to GSCL and receiving the data from NSCL, we created data generators to simulate network traffic with timestamps to our handler applications on GSCL. GSCL will then transfer data to NSCL. The latency is calculated by using current time of receiving data from NSCL minus the previous generated timestamp.

The HTTP data generator was created by Apache JMeter [18], which is an open source java application designed for testing web applications. What we need to do is to set up the configuration for our test. Figure 15 is the snapshot of detailed Jmeter configuration. We created a Test Plan as the root directory, and under this test plan we created a Thread Group.

In the Thread Group, we can set up thread properties including the number of threads and the ramp-up period based on our experiment. Under the Thread Group, we added an HTTP Request Sampler and a Constant Timer. In the HTTP Request Sampler, we can set up the IP and the port number of the http server, the http method we used, and the path and the send parameters with the http requests. In the Constant Time, we can set up Thread Delay to control the frequency of the http requests.

Figure 15: Configuration of Apache JMeter

The MQTT data generator was created by Paho python client [19]. The Paho project has been created to provide open source implementations of messaging protocols for IoT inside the Eclipse M2M Industry Working Group. In Paho python client, it provides MQTT client class, so we can easily implement our MQTT client applications by using its helper functions.

The code of MQTT data generator is depicted in Figure 16. The Paho Python library and required libraries are imported at the beginning, and we created number of threads with 0.1

second ramp-up period through a for loop in the main function. Each thread will call the function createPatient which publishes MQTT messages to the MQTT Proxy regularly by calling the function of mqttc.publish in an infinite loop. We can control the frequency of MQTT publish using the time.sleep function between each loop. Note that the third parameter of mqttc.publish indicates the QoS level of the message to be published. In our experiment, QoS 0 is used because HTTP does not support reliability of delivery.

Figure 16: The code of MQTT data generator

Also, each thread pushes data once every second, and was created with 0.1 second ramp-up period. We changed the traffic to handler applications by tuning the number of data generator threads. Throughput can be calculated by the following equation:

Throughput = Thread number * Carried data per second

In the first experiment, we fix the size of carried data per request to 50 Bytes. The data

delivered to the application on the NSCL though the OpenMTC. We did two experiment based on scenario I and scenario II of the handler application, and the results are shown in Figure 17. The X-axis indicates the number of threads created in the data generator, and the Y-axis indicates the average latency we measured from nine thousand successive samples.

Figure 17: First latency experiment

In the second experiment, we fix the number of threads created in the data generator to 10. The data generator keeps pushing data to the interworking proxy on the GSCL, and then data will be delivered to the application on the NSCL though the OpenMTC. We did two experiment based on scenario I and scenario II of the handler application, and the results are

0

shown in Figure 18. The X-axis indicates the size of carried data per request, and the Y-axis indicates the average latency we measured from nine thousand successive samples.

Figure 18: Second latency experiment

In both experiments the scenario I and II have similar result. It shows that the MQTT Proxy can deliver data to the network application on NSCL with lower latency compared to the HTTP Proxy. This is especially obvious when the number of threads or the size of data increases.