Overview

In this brief tutorial we present an end-to-end simple program it yourself (PiY) sample experiment. In this experiment, we assume that the Experimenter wants to obtain measurements related to the success and delay of pings between a fixed nodes running an LTE base station and a portable node on an UAV running an LTE terminal. At a high level, as described in previous sections of the User Manual, there are several steps the Experimenter has to undergo:

• Login into the AERPAW Web Portal, define an experiment, and request resources for the development of the experiment (Sections 2.1, 2.2, 2.3 (optional), 2.4);

• Login into the development environment (Section 2.6), and develop the experiment (essentially specify the vehicle control, the radio control and traffic generator) (Section 3.1);

• Submit the experiment to the testbed and wait for the experiment to be executed in the testbed (Section 2.4);

• Retrieve and process the results (sections following this one).

In what follows we provide details for each of the major steps outlined above.

Web Portal

Follow appropriate instructions in previous sections.  When defining the Experiment (specifying Target Resources), choose the AFRN "LW1", and an APRN, say "LPN1".

Vehicle Control Application

For the vehicle control application, there is nothing  to be done for the fixed node, as there is no vehicle to be controlled. For the portable node, the prepanned trajectory sample application has to be selected as the vehicle control application. This is done by editing the script called vehicleControl.sh in the workspace directory of the portable node E-VM. The vehicleControl.sh script calls the preplanned trajectory control python script that takes as its main input a mission plan file. Most likely the Experimenter would want to edit the mission plan file to ensure that the UAV is following the desired trajectory. Ensure that the preplanned trajectory control script points to the correct (possibly freshly edited) mission plan file.

Traffic Generator

For generating traffic at this time AERPAW is offering two sample traffic generators: ping and iperf. We assumed that in this sample experiment ping will be used to obtain round trip delays (as well as failures) from the UE to the eNB. For this, the trafficGenerator.sh script on the E-VM of the portable node has to be edited to enable ping measurements to be collected during the experiment. To enable this functionality, the Experimenter has to edit the trafficGenerator.sh script in the workspace directory of the E-VM of the portable node, in particular to uncomment out the ping part of the script. Similar to the case of the Vehicle Control Application, there is nothing that needs to be done in the fixed node E-VM. If a second ping (from the fixed node to the portable node) is desired, then the same type of editing can be done in the trafficGenerator.sh script in the workspace of the E-VM of the fixed node.

Radio Software

We assumed that for this sample experiment the Experimenter wishes to use an LTE UE on the portable node and an LTE eNB on the fixed node. A popular choice of open source LTE software is srsLTE. AERPAW directly supports srsLTE in both the development as well as  testbed containers, so the Experimenter just has to call the preexisting code. To this end, the Experimenter should edit the radioSoftware.sh script in the workspace area of both the portable node E-VM and the fixed node E-VM.  In the case of the portable node E-VM, the Experimenter will enable the srsLTE - UE software that is by default commented out in the radioSoftware.sh script of the the portable node E-VM.  Similarly, while logged in the fixed node E-VM, the Experimenter will uncomment the srsLTE-eNB+EPC  in the radioSoftware.sh script. If the Experimenter wishes to change any parameters for srsLTE (either UE or eNB), the instructions on how to do so are available here.

Testing and Debugging

The main purpose of the development environment for AERPAW is to eliminate the most common mistakes, and, ideally, provide a bug-free code to the testbed. For this purpose, the experimenter is encouraged to test their experiment by executing the experiments in development mode. For executing the experiments the AERPAW team has provided a startexperiment.sh script in the workspace area of each of the E-VMs that starts all three scripts (vehicleControl.sh, trafficGenerator.sh, and radioSoftware.sh). The Experimenter could then observe the output of any of the scripts called by startexperiment.sh using the screen command. The Experimenter can also observe the UAV being initialized on the Lake Wheeler field in the OEO console VM. The Experimenter can then arm the UAV either using MAVProxy in the OEO Console-VM, or using QGroundControl in the same OEO-Console VM. 

Upon the experiment either succeeding, or failing, the Experimenter can stop the experiment in each of the E-VMs by running stopexperiment.sh in the workspace area of each of the E-VMs. If any of the components of the software is not working as desired, the Experimenter can edit the corresponding script files (or, possibly the configuration files) and restart the experiment. When the experiment behaves as desired (please double check the outputs of the scripts, which should be saved as logs), the Experimenter will submit the experiment for testbed execution.

Submitting the Experiment to the Testbed

When the Experimenter is satisfied with the results of the development process, including the resolution and format of the logged data, the Experimenter will, once again, use the AERPAW web portal to submit the experiment for execution in the testbed (see "Managing Sessions" in Section 2.4 and Step 8 in Section 1.8). 

The AERPAW Operator will then schedule the Experiment on a suitable day (when the safety pilots are available, the weather is cooperating, and there are no FAA restrictions in the area). Then the Operator will move the experimenter code from the development containers to the testbed containers, and will execute the code.

After the experiment terminates, the testbed containers will contain, in addition to the Experimenter code, the logs with the measurements from the testbed.  The Operator will then move the content of the testbed containers back into the development environment, and then will notify the Experimenter that the development containers are once again available.

Retrieving and Processing the Results

In the final phase, of the experiment life-cycle, Experimenter logs in the newly repopulated development containers, which, at this time, contain the logs from the testbed. The Experimenter can now retrieve the logs and post-process them to create graphs, or any other analysis the Experimenter sees fit. AERPAW provides a very basic set of post-procesing scripts that allow an experimenter to create kml files that can then be visualized in Google-Earth, or Matlab figures of significant quantities. In the case of the experiment in this sample, we assume that the Experimenter wanted to visualize the success of failure of the pings in Google-Earth, as well as to plot the round-trip-delays resulting from the ping probes as a function of the distance between the UE and the eNB. The resulting figures are available below. The Google Earth figure shows successful pings as red dots and missing pings (observed via a missing sequence number) in blue. It can be seen that the UE disconnects and reconnects to the eNB. Below are the Matlab figures comparing the results of the emulation with the ones from the testbed.