Measurements Collection

The ORBIT Measurement Framework (OML) was discussed in the first section of this tutorial as one of the ORBIT Services. It is a distributed software framework enabling real-time collection of data, and, as such, has a client application programming interface (API). A developer can use this client API through a web interface to define the measurement points and parameters for his or her application. Measurement points and their frequency of collection are an important part of ones experimental plan.

The definition of a measurement point is shown below.

<application id="foo">
<measurement-points>
  <measurement-point id="group1">
    <metric id="rssi" type="float"/>
    <metric id="noise" type="float"/>
  </measurement-point>
  <measurement-point id="group2">
    <metric id="throughput" type="int"/>
  </measurement-point>
</measurement-points>
</application>

Measurement point definitions are saved as an XML-based configuration file as shown above. The source code for the measurement client is automatically generated by the web-based OML service that accepts the xml file shown above and returns the autogenerated client API. This API contains application-specific methods that handle type-safe data collection. This source code can be compiled and linked with the application as illustrated by a Makefile and sample application code below.

The OML service returns a file called "wrapper" which is a tar+gzipped file containing the src,include and lib directories for the OML client API. The src directory need not be used as we already create a static library for the API (see lib directory). In the Makefile, note that the autogenerated filenames include the application id (foo) from the xml file above. Also note how we use the include and lib directories in CFLAGS and LDFLAGS and then link to the oml_client and the client_api libs in LIBS variable. The oml_client library is installed on the gateway machine and is part of the baseline image.

Makefile and include file for Measurement Points

Sample Makefile:
APP = foo
CC  = gcc
CFLAGS  = -g -Wall -I./include
LDFLAGS = -L./lib/i386-linux
LIBS    = -loml_client -loml_$(APP)
SRCS = app.c

app: $(SRCS) oml_$(APP).h
        $(CC) -o app $(CFLAGS) $(SRCS) $(LDFLAGS) $(LIBS)

oml_$(APP).h: $(APP)-def.xml
        wget -q http://oml.orbit-lab.org/generator/wrapper --post-file $< -O -\
        | tar -xzf -

---------------- End of Makefile --------------------

./include/oml_foo.h:
	int oml_group1(float rssi, float noise);
	int oml_group2(int throughput);

Application Code Sample

// needs to be called only once
initialize_oml(&argc, argv, NULL);

if (r_data->send_option == 1) {
  buffer->rssi = recv_packet_params.rssi ;
  buffer->noise = recv_packet_params.noise;
  oml_group1(buffer->rssi, buffer->noise);
} else {
  log(LOG_ERR, "Unknown receive option! \n");
}
lost_packets = pck_id.seqnum - old - 1;
oml_group2(lost_packets);

Because not all measurements are needed and not all measurement samples are needed, OML supports preprocessing or filtering at source to reduce the amount of reported and recorded data. Filters are defined by experimenter, and experimenter-provided filters are supported. Figure 1. below illustrates the client-side data flow. Collection of and access to the recorded data requires the use of a database schema. OML automatically generates the appropriate schema as diagrammed in Figure 2 below.

Figure 1. Client-side Data Flow.

Figure 2. Server-side DB Schema Generation.