AERPAW includes some industry standard commercial equipment typically not available in academic laboratories; and the goal of the AERPAW project is to make them available for use by our experimenters. However, many of these are equipments or ecosystems of components that were designed exclusively for live access and control by an operator (specially trained for that purpose), and do not support a programmed or scripted mode of operation, nor functionality that can be accessed through high-level, easily accessible APIs suitable for a generic researcher. We use the broad term “Third-Party Black-Box Equipment” (3PBBE) to emphasize this essential nature common to them all. Confirmed such equipment at the time of this writing includes Keysight RF Sensors, Ericsson 4G/5G base stations and RAN/core system, and Facebook Terragraph system.
The canonical mode of operation cannot automatically encompass such 3PBBE, because of the lack of (i) virtual computational models of such 3PBBE that can be incorporated into AERPAW’s Development or Emulation environments, (ii) programmable control/configuration capabilities, to enable batch operation of Experimenter code (without live console access), and (iii) onboard programmable supervisor to run AERPAW Node orchestration software. Such capabilities also cannot be expected in the future from the respective vendors, since they pose no commercial advantage.
Accordingly, we do not expect to provide 3PBBE access through the canonical workflow. The following non-canonical workflows can be used to provide interested and qualified experimenters with such access.
Experiment-as-a-Service (EaaS). This workflow is essentially identical to the canonical workflow, and can be used even for canonical Experiments by Experimenters who are not comfortable with SDR or UAV programming, and uninterested in learning. In this workflow, the Experimenter simply describes (in documents, and through interaction with the AERPAW team) their experimental intent, and the experiment design, implementation, and execution, are all carried out by AERPAW personnel.
Although it is a much more protracted process than Program-it-Yourself, it has the advantage that non-programmable 3PBBE resources can be accommodated in the experiment without additional effort.
Experiment-Development-as-a-Service (EDaaS). This is an amalgamation of the canonical workflow and EaaS. As in EaaS, AERPAW personnel designs and develops the experiment based on experimenter intent, but once the base experiment is programmed, it is turned over to the experimenter who can further develop and customize it, to create future experiments. Beyond the handover, the experimenter follows the canonical workflow.
However, if 3PBBE are included, then the experiment cannot return to the canonical workflow. For such experiments, the EDaaS workflow degenerates to the EaaS workflow.
Live Limited Access. By going through some technical material and cooperative agreements, after some initial level-setting, qualified experimenters can be provided with testbed sessions in which they will have live login access to a specific predetermined subset of 3PBBE. Such use will not include the ability to integrate canonical experiment resources (i.e. SDR nodes and UAVs/UGVs) into such live access.
In Phase-2, the following systems are included as part of General Availability:
Ericsson system.
Keysight RF Sensors.
This User Manual has some information about these. Please make sure you have read these parts of the User Manual before reaching out to AERPAW Operations to propose a non-canonical Experiment.
Please also make sure to fill out the Experiment Information Request Form before reaching out (see the flowchart in Section 4.3).
Beyond all of the above, AERPAW is open to collaboratively defining custom uses of the testbed, one-of-a-kind or hero experiments. These are likely to be extremely costly, since they presuppose a good proportion of dedicated effort by AERPAW DevOps personnel, and potentially preclude or curtail much of the normal use of the facility for an extended period of time.
Mixed and Custom Service Approaches. If none of the above approaches can accommodate some particular, complex requirements of an experimenter, the AERPAW team will be open to discussing and coming up with unique custom approaches to support such requirements. For example, it may be possible to have a mix of various previous approaches where part of the experiment is executed in batch mode programmed by the experimenter, a part is manual by the operator, and part is live limited access. This might allow the experimenter to observe the effect of transmitting a specific waveform from a fixed node (programmed by the experimenter in canonical mode) on a Keysight RF sensor (limited live access), while a DJI drone is being flown by an AERPAW pilot (EaaS by AERPAW Ops).
Bring Your Own Device (BYOD): In this scenario, an Experimenter may provide custom wireless equipment that they desire to be installed (temporarily) in the AERPAW testbed, or otherwise integrated into experiment operation. AERPAW is receptive to the concept of BYOD, however our goal and responsibility remains to be able to manage the process so that the platform’s ability to verify and enforce safe operations, staying within appropriate regulations, is not compromised. BYOD cases are natural fits for one or the other non-canonical workflows. For example, some researchers interested in passive signature-based drone detection may want to specify that AERPAW personnel should fly a certain model of drone (or send us their own custom drones) in our wireless field, to test detection algorithms. Such a drone would typically not be programmable, but we would still be able to manually execute the experiment, if desired by the experimenter. We do not envisage being able to, or commit to, providing a canonical workflow for BYOD equipment. Part of the case-by-case interaction we will undertake when considering any BYOD scenario is to assess physical, electrical, and software characteristics of such custom devices, and their manageability by AERPAW Ops during the experiment.
Please make sure to fill out the BYOD Experiment Information Request Form (see the flowchart at the top of this page) before reaching out to propose any custom Experiment. (Fill out the same form for all custom Experiment proposals, whether you actually intend to provide additional wireless equipment for your Experiment or not.)
The access models for various non-canonical Experiment vary widely depending on the exact nature of the Experiment.
For some of the equipment that can be used in non-canonical Experiments, the corresponding Sample Experiment sections under Section 6 of this manual describe the access details for that equipment.
For some other types of non-canonical Experiments, there is no direct access to the Experiment by the Experimenter; rather, the Experimenter is expected to interact with the AERPAW Ops team in order to fully specify and design the Experiment, which will then by executing on the Experimenter's behalf by AERPAW Ops, and results returned.
In general, if in doubt about how to access or proceed with your non-canonical Experiment, please reach out to AERPAW Ops, or schedule a time during the open "office hours" that are regulary held by AERPAW Ops, to discuss.
For some non-canonical Experiments, a well-defined repeatable workflow has been defined by the AERPAW DevOps Team that is likely to address the needs of most Experimenters utilizing the corresponding equipment. These are listed below.