| 11 | | ===== ORBIT-specific Methods ===== |
| 12 | | Four ORBIT-specific methods are available for debugging help: ''error( |
| 13 | | )'', ''warn( |
| 14 | | )'', ''info( |
| 15 | | )'', and ''debug( |
| 16 | | )''. How do they work? Like assertions? What arguments do they take? Besides these debugging methods, there are three classes of ORBIT-specific methods discussed below: implicit, Experiment, and NodeSet. |
| 17 | | |
| 18 | | Among the implicit methods two are used to define resources: |
| 19 | | {{{ |
| 20 | | defProperty(name, value, description) |
| 21 | | defNodes(setName, nodeList) {} |
| 22 | | }}} |
| 23 | | Some ORBIT-specific methods work with node sets to specify a set of nodes for each member of which the associated block of code is executed: |
| 24 | | {{{ |
| 25 | | nodes(setName) {} |
| 26 | | allNodes {} |
| 27 | | nodes("_ALL_") {} |
| 28 | | }}} |
| 29 | | Other ORBIT-specific methods use events which delay execution of the associated block of code and sequential execution until that event is true: |
| 30 | | {{{ |
| 31 | | whenAll(setTest, nodeTest, interval = 5) {} |
| 32 | | whenAllInstalled() |
| 33 | | whenAll("_ALL_", "apps/app/status[text()='INSTALLED.OK']") {} |
| 34 | | wait time_in_sec |
| 35 | | }}} |
| 36 | | |
| 37 | | The Experiment methods and properties are ORBIT-specific methods and properties associated with the Experiment object. They have the form Experiment.method. These methods include: |
| 38 | | {{{ |
| 39 | | name = "tutorial-1a" |
| 40 | | project = "orbit:tutorial" |
| 41 | | props.propName = "" |
| 42 | | Done |
| 43 | | }}} |
| 44 | | It is anticipated that the 'Experiment' prefix will be removed in future versions. |
| 45 | | |
| 46 | | Other ORBIT-specific methods are NodeSet methods that set properties for the specified set of nodes. They have the form |
| 47 | | {{{ |
| 48 | | NodeSet ( nodes(setName).method ) |
| 49 | | image = |
| 50 | | pxeImage = |
| 51 | | prototype(name) {|node| |
| 52 | | } |
| 53 | | onNodesUp {|node| |
| 54 | | } |
| 55 | | startApplication(appName), startApplications |
| 56 | | stopApplication(appName), stopApplications |
| 57 | | resource |
| 58 | | net.if_name |
| 59 | | }}} |
| 60 | | |
| 61 | | The defNodes method declares the nodes used in the experiment: |
| 62 | | {{{ |
| 63 | | defNodes(setName:string, nodeList) {} |
| 64 | | }}} |
| 65 | | There are various ways to declare node list: |
| 66 | | {{{ |
| 67 | | A single node: [x,y] |
| 68 | | multiple nodes: [[x1,y1], [x2, y2], [x3, y3]] |
| 69 | | ranges of nodes: [x1..x2, y1..y2] |
| 70 | | the entire grid: [1..20, 1..20] |
| 71 | | with other node sets: [nodeSet1, nodeSet2] |
| 72 | | }}} |
| 73 | | These methods are useful for declaring common functionality over multiple sets. The various network parameters that may be configured within a defNodes or allNodes block are shown in Figure 9 below, here the first and second Ethernet interfaces are e0 and e1, and the first and second wireless interfaces are w0 and w1. |
| 74 | | |
| 75 | | {{{ |
| 76 | | net |
| 77 | | e0, e1 |
| 78 | | arp = true|false En/disable ARP |
| 79 | | forward = true|false Enable forwarding |
| 80 | | ip = address/netmask IP address of interface |
| 81 | | up = true|false En/disable interface |
| 82 | | route |
| 83 | | w0, w1 |
| 84 | | All the above |
| 85 | | channelI = 1..11; 36, 40, 44, 48, 52, 56, 60, 64, 149, 153, 157, 161 |
| 86 | | essid = string |
| 87 | | frequencyI = 2.412 2.462 (5 Mhz steps); 5.18Ghz (20Mhz steps) |
| 88 | | mode = master|managed|ad-hocI|monitorI |
| 89 | | rtsA = packetSizeThreshold [bytes] |
| 90 | | rateI = 1, 5, 11; 6, 9, 12, 18, 24, 36, 48, 54 |
| 91 | | tx_power = -12 .. 15 dBm (intel), 0 .. 20 dBm (atheros) |
| 92 | | type = a/b/g |
| 93 | | }}} |
| 94 | | |
| 95 | | Figure 9. Configurable Network Parameters |
| 96 | | |
| 97 | | ===== ORBIT Script Coding Techniques ===== |
| 98 | | There are many known techniques for defining an experiment with parameters that do not change over the course of the experiment and for controlling experiments with parameters that change while the experiment runs. These techniques are available in the standard scripts for the baseline ORBIT experiments [where?]. It is also possible to change parameters based on the experiment's own measured behavior, e.g., to run until the observed packet error rate exceeds a given value, see [http://www.orbit-lab.org/download/publications/Orbit_Software.pdf '''ORBIT Testbed Software Architecture: Supporting Experiments as a Service''']. |
| 99 | | |
| 100 | | ===== Developing Application Software ===== |
| 101 | | The experimenter may need to develop application software, for example, to emulate the operation of a new network protocol. An '''ORBIT Radio Grid Testbed''' application operates in the environment shown in Figure 10 below. An application needs to be integrated into this application harness. Once an application is developed it needs to have an application description developed and to be loaded onto an application server and assigned an id. The process for developing this application description and loading the application software is as follows [?]. |
| 102 | | |
| 103 | | Figure 10. Experiment Execution Architecture (see page 12 of [http://www.orbit-lab.org/doc/tutorial]). |
| 104 | | |
| 105 | | ===== Development Tools for Application Software ===== |
| 106 | | Three major tools are provided to the ORBIT experimenter to develop an application in C on Linux: '''ORBIT Traffic Generator/Receiver (OTG/OTR)''', '''Libmac''' and the '''ORBIT Measurement Framework (OML)'''. The '''ORBIT traffic generator/receiver (OTG/OTR)''' illustrated in Figure 11 below is a modular traffic generator/receiver that is integrated with '''OML''' and '''Libmac'''. '''OTG/OTR''' has pluggable traffic models and transport protocols, see [http://www.orbit-lab.org/download/publications/Orbit_OML.pdf '''ORBIT Measurements Framework and Library (OML): Motivations, Design, Implementation, and Features''']. |
| 107 | | |
| 108 | | Figure 11. '''ORBIT Traffic Generator/Receiver (OTG/OTR)'''(on page 53 of [http://www.orbit-lab.org/doc/tutorial]). |
| 109 | | |
| 110 | | '''Libmac''' is a user-space C library that brings the wireless driver application program interface (API) into user space allowing one to get or set values of driver parameters. This library supports operation for a variable number of parameters per call. The call mac_get_params(struct mac_params *h, struct mac_ifinfo_list *if_ptr, int argc, |
| 111 | | ) requests the wireless device driver to GET parameter information. The call mac_set_params(struct mac_params *h, struct mac_ifinfo_list *if_ptr, int argc, |
| 112 | | ) requests device driver to SET parameter information. |
| 113 | | |
| 114 | | 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. |
| 115 | | |
| 116 | | The definition of a measurement point is illustrated in Figure 12 below. Measurement point definitions are saved as an XML-based configuration file, and source code for the measurement client is automatically generated that 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 in Figure 13 and sample application code in Figure 14 below. |
| 117 | | |
| 118 | | {{{ |
| 119 | | <measurement-points> |
| 120 | | <measurement-point id="group-1"> |
| 121 | | <metric id="rssi" type="float"/> |
| 122 | | <metric id="noise" type="float"/> |
| 123 | | </measurement-point> |
| 124 | | <measurement-point id="group-2"> |
| 125 | | <metric id="throughput" type="int"/> |
| 126 | | </measurement-point> |
| 127 | | </measurement-points> |
| 128 | | }}} |
| 129 | | |
| 130 | | Figure 12. Defining Measurement Points |
| 131 | | |
| 132 | | {{{ |
| 133 | | Makefile: |
| 134 | | $(INC_DIR)/oml_%.h : $(ETC_DIR)/%.xml |
| 135 | | mkdir -p $(INC_DIR) |
| 136 | | wget -q http://www.orbit-lab.org/oml/client_wrapper\ |
| 137 | | --post-file $< -O - \ |
| 138 | | | tar -C $(BUILD_DIR) -xzf |
| 139 | | oml_foo.h: |
| 140 | | int oml_group1(float rssi, float noise); |
| 141 | | int oml_group2(int throughput); |
| 142 | | }}} |
| 143 | | |
| 144 | | Figure 13. Makefile and include file for Measurement Points |
| 145 | | |
| 146 | | {{{ |
| 147 | | oml_init(&argc, &argv, NULL); |
| 148 | | |
| 149 | | |
| 150 | | if (r_data->send_option == 1) { |
| 151 | | buffer->rssi = recv_packet_params.rssi ; |
| 152 | | buffer->noise = recv_packet_params.noise; |
| 153 | | oml_group1(buffer->rssi, buffer->noise); |
| 154 | | } else { |
| 155 | | log(LOG_ERR, "Unknown receive option! \n"); |
| 156 | | } |
| 157 | | lost_packets = pck_id.seqnum - old - 1; |
| 158 | | oml_group2(lost_packets); |
| 159 | | }}} |
| 160 | | |
| 161 | | Figure 14. Application Code Sample |
| 162 | | |
| 163 | | 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 15 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 16 below. |
| 164 | | |
| 165 | | Figure 15. Client-side Data Flow (see page 66 of [http://www.orbit-lab.org/doc/tutorial]). |
| 166 | | |
| 167 | | Figure 16. Server-side DB Schema Generation (see page 67 of [http://www.orbit-lab.org/doc/tutorial]). |
| 168 | | |
| 169 | | ===== Developing Device Drivers ===== |
| 170 | | A possibly difficult aspect of having to develop a completely new application would be to have to develop a device driver for Linux or for another operation system to support a new communications device. Even a simple modification to an existing device driver requires extensive testing. Once a device driver has been developed it needs to be loaded onto an application server. The process for loading a device driver is as follows [?]. |
| 171 | | |
