A Versatile MANET Experimentation Platform and Its Evaluation through Experiments on the Performance of Routing Protocols under Diverse Conditions

Abstract

Mobile Ad hoc Networks (MANETs) are characterized by highly dynamic phenomena and volatility. These features have a significant impact on network performance and should be present in the scenarios of experiments for the assessment of MANET-related technologies. However, the currently available experimentation approaches suffer from limitations, either employing overly abstract simulation-based models that cannot capture real-world imperfections or drawing upon “monolithic” testbeds suited only to a narrow set of predetermined technologies, operational scenarios, or environmental conditions. Toward addressing these limitations, this work proposes a versatile platform that can accommodate many of the complexities present in real-world scenarios while still remaining highly flexible and customizable to enable a wide variety of MANET-related experiments. The platform is characterized by a modular architecture with clearly defined modules for the signaling between peer mobile nodes, the tracking of each node’s location and motion, the routing protocol functionality, and the management of communication messages at each node. The relevant software runs on inexpensive Raspberry Pi-based commodity hardware, which can be readily attached to robotic devices for moving the network nodes in accordance with controlled mobility patterns. Moreover, through an appropriate tuning of certain modules, a number of important operational conditions can be precisely controlled through software, e.g., restricting the communications range (thus reducing the network density) or for emulating the mobility patterns of nodes. The effectiveness and versatility of the proposed platform are demonstrated through the realization of a series of experiments on the performance comparison of selected routing protocols under diverse network density conditions.

1. Introduction

1.1. Background and Motivation

Mobile Ad hoc Networks (MANETs) [1,2] provide a versatile form of networking that enables the spontaneous formation of communication networks for data exchanges between peer mobile nodes without a need for dedicated infrastructure support. This versatility, apart from being valuable on its own sake, also blends well with the concept of the Internet of Things (IoT), which targets the aggregation of any networking-capable device under the assumption of common networking protocols [3]. IoT allows the connection of various physical things, called smart objects, to each other and to the Internet, through the use of heterogeneous communication technologies. The combination of the MANET and IoT concepts gives rise to the Future Internet paradigm of MANETs (named global MANET-IoT system [4]) that aims at the interoperability and interaction between heterogeneous networks (e.g., various types of MANETs and/or sensor networks [5]) and becomes attractive for developing a wide range of novel applications [6].

A more specialized but highly relevant example aligning with the general principles of MANET is the Vehicle Ad hoc Network (VANET) paradigm [7]. This networking concept underlies Intelligent Transportation Systems [8] and is used to provide communication between nearby vehicles (i.e., vehicle to vehicle communication), and between vehicles and fixed infrastructure on the roadside (i.e., vehicle to infrastructure communication). In the special case where the vehicles are unmanned devices, the unmanned vehicle networks (UxVs) emerge [9,10,11,12]. This type of network can be harnessed for military and civil applications, embracing a multitude of different environments. With respect to deployment, UxVs may target roads and ground terrains in general (UGVs), aerial applications (UAVs/Drones), the surface of maritime environments (USVs), and underwater applications (UUVs).

The aforementioned scenarios present additional challenges when the involved MANETs are characterized by sparse topologies, i.e., when the mobile nodes encounter, on average, very few neighbor nodes within the communication range. In such networks, called Delay Tolerant Networks (DTNs) [13], mobile nodes may become temporarily disconnected and thus unable to immediately forward their messages to suitable next-hop nodes. To overcome this obstacle, the nodes must leverage their mobility and keep carrying the messages until they encounter forwarding opportunities (i.e., contacts with other suitable next-hop nodes). Accordingly, routing protocols for DTNs become more effective when the evaluation of the candidate next-hop nodes considers not only the current status of the nodes at the time of contact (i.e., their current position, possibly in conjunction with further attributes pertaining to the delay/disruption-tolerant application in hand), collectively called their “forward effect/action”, but also their mobility pattern, determining their “carry effect/action”, i.e., their suitability for effectively carrying the received message until encountering a better next-hop node.

In view of the dynamic character and the volatility of the environments just described, there is a clear need for comprehensive methodologies to evaluate MANET-related technologies, applications, and protocols and to assess their effectiveness under diverse operational and environmental conditions. To this end, the most commonly employed techniques draw upon network simulation, network emulation, or testbed-based experimentation. (The terms “testbed” and “platform” are used interchangeably in the following.)

1.2. Related Work and Limitations

With network simulation [14], a software program is used to represent the behavior of a network by imitating the interaction between different network entities (e.g., gateways, nodes, mobility attributes) in accordance with the underlying models. The networking protocols, the applications, and services, as well as the various environmental conditions and nodal attributes that the simulator supports, can be adjusted in a controlled manner to assess how the network and the protocols would behave under different conditions [15,16]. In that way, the network simulation provides a repeatable and controlled environment for rapid prototyping and experimental evaluation [17]. However, simulation models are inherently limited in their potential for accurately capturing finer details of network functions, nodal mobility behavior, and wireless medium characteristics [18].

Network emulation [19,20,21] comes a step closer to the real system by combining actual elements of a deployed network implementation with other simulated components. A fundamental difference between simulation and emulation is that while the former runs in virtual simulated time (advanced either through triggers by discrete events or by fixed increments), the latter must run in real-time. This real-time nature of emulation, often in combination with a physically distributed computation infrastructure, hinders the repeatability of a sequence of events, contrary to simulation [22]. Moreover, while emulation comes closer to the real world than a plain simulation model, it still suffers from inaccuracies in the modeling of the abstracted elements. Generally, the potential and limitations of the emulation methods have been discussed in the literature (see, e.g., [23,24]).

By employing a full-blown set of real components, testbed-based methods provide the most realistic alternative for testing networking scenarios [25]. In particular, testbeds can represent, in realistic terms, the mobile nodes’ motion, which critically affects the operation of real MANETs. This is in contrast to emulationor simulation-based methods, which represent motion through idealized models that cannot accurately capture the effect of real-world limitations and/or other interactions of the nodes with the environment. This is the key reason why most of the current MANET testbeds put an emphasis on mechanisms for controlling and tracking the motion of the employed mobile devices. For the localization (also called positioning) process, used for tracking and monitoring the positions and movements of the mobile devices over time, several centralized and distributed techniques exist, targeting indoor and/or outdoor experimentation terrains. These techniques employ visual-based methods [26], Global Positioning Systems (GPS) [27,28], Inertial Measurements Units [27], or beacon-based methods (e.g., RSSI techniques and Bluetooth low energy beacons [29]). Additionally, the realization and control of the mobile nodes’ motion involve facilities responsible for the navigation of the mobile devices [30,31], including components and mechanisms for obstacles and collision avoidance [32]. For a comprehensive survey of selected MANET testbeds, see [33,34].

Currently existing MANET testbeds, however, although certainly useful for experimentation in the field, are monolithic “black box” designs, targeting a narrow set of predetermined technologies, operational scenarios, or environmental conditions. As such, they cannot be easily employed for the investigation of protocols or operational scenarios of a greater scope.

1.3. Contributions

In an attempt to address these limitations, this paper proposes a versatile MANET experimentation platform, which is characterized by a modular architecture and can be flexibly employed in a wide range of experimentation scenarios, as demonstrated by its use in the scope of the ATLAS research project [35], on UxV-based mobile networks. The platform includes clearly defined modules for: the signaling between peer mobile nodes within communication range, according to a beacon-based mechanism; the localization/tracking of each mobile node’s location and motion over time; the routing protocol functionality, including the evaluation and selection of next-hop nodes; and the management of communication messages at each node, including message reception, storage, and next-hop forwarding. All signaling and data exchanges occur at the application layer, decoupling the operation of the platform from the intricacies of the actual wireless technologies employed.

The software of the MANET platform has been implemented in Python and runs on standard Raspberry Pi-based commodity hardware, using one board computer per network node. It is straightforward to mount the boards on robotic devices, which are used for moving the network nodes in accordance with controlled mobility patterns. With this arrangement, it becomes possible to completely decouple the operation of the attached boards from the intricacies of the robotic devices realizing mobility, thus maximizing the compatibility between the two sets of entities. Nevertheless, a controllable degree of coupling is still possible, if so desired. For example, the localization module of the MANET platform may take input from GPS facilities on the robotic devicesor, alternatively, disregard these facilities and perform the localization through other independent means.

The modular structure of the platform facilitates the adaptation of the software to enable experiments involving a variety of different routing protocols. Moreover, through an appropriate tuning of certain modules, it becomes possible to precisely control a number of important operational and environmental conditions through the software. In particular, by jointly exploiting input from the beacon-based signaling module and from the localization module, a reduced communication range between peer nodes can be emulated. This feature enables experiments that can address a wider range of network densities. In another direction, instead of mounting the MANET boards on actual robotic devices, it is possible to interface the localization module of some or all of the boards with another software module, providing input according to simulated mobility patterns. By leveraging these features, the operation of the proposed platform can span the range between emulated and real-world experiments, trading repeatability and control for realism, as required.

All these aspects are highlighted through the presentation and analysis of results from a comprehensive set of experiments on the performance of selected routing protocols under diverse conditions. These results not only demonstrate the effectiveness and versatility of the platformbut also yield additional insight into the performance impact of real-world imperfections, such as inaccurate location information or restricted mobility patterns.

In summary, the paper makes the following contributions:

• It proposes a MANET experimentation platform with a modular architecture that includes clearly defined modules for the functions associated with localization, nodal interactions, and ad hoc networking. The architecture can accommodate a variety of different routing protocols and supports mechanisms for controlling, through software, a number of operational and environmental conditions.
• It discusses a lightweight implementation of the design on inexpensive Raspberry Pi-based commodity hardware, using one board computer per network node. The implementation is compatible with a wide range of wireless communications technologies and any type of robotic device undertaking nodal mobility.
• It presents and analyses results from a comprehensive set of experiments, demonstrating the platform’s potential and highlighting the impact of real-world imperfections.

The rest of the paper is organized as follows: Section 2 elaborates further on the scope of the proposed MANET platform and on associated use-case scenarios. Then, Section 3 presents the platform’s modular architecture and provides all necessary details about the software design, as well as about implementation aspects and the hardware components involved. Subsequently, Section 4 discusses robotic devices that may be employed for the physical motion of the mobile nodes. Section 5 presents results from experiments using the platform. Finally, Section 6 provides concluding remarks.

2. Scope of Applicability and Use-Case Scenario

The platform addresses a mobile ad hoc setting, where each mobile node can communicate directly with all other nodes within its communication range. The associated coverage area around each node is called the node’s neighborhood, and the platform provides all the necessary mechanisms for an effective neighborhood perception. Specifically, as discussed in the introduction, the position and motion of all nodes in the neighborhood are particularly important attributes of the neighborhood’s status. Accordingly, the platform provides means so that each mobile node may obtain quasi-real-time updates of the position and motion of itself and all its neighbors. More precisely, each node obtains updates about its own position and motion through a GPS-based localization process and advertises this updated information to its neighborhood by means of periodically broadcast beacons.

By leveraging the updated status of its neighborhood, a mobile node holding messages that must be routed to their destination can evaluate the appropriateness of its neighbor nodes as next hops for each such message, according to an employed routing protocol (whose metric differentiates between neighbor nodes on the basis of their suitability). When the application of the routing protocol indicates that there exist neighbor nodes more suitable than the current node, the latter forwards the message to the most suitable such neighbor. The modular design of the platform facilitates the implementation of appropriate routing protocols, ensuring the proper interaction between the routing module and the modules responsible for the neighborhood perception.

Another worthwhile feature of the platform is the absence of requirements for a tight coupling between the core processes of the platform (which undertake the neighborhood perception and ad hoc networking functions) and the robotic devices employed for implementing the physical motion of the MANET nodes. This characteristic proved valuable during the initial deployment of the platform for realizing MANET-related experiments in the context of the ATLAS research project, implemented as part of the second Open Call from the RAWFIE European project (in the Horizon 2020 Framework Programme, under the FIRE+ initiative) [35]. RAWFIE developed and made available a wide variety of different UxV devices, together with a comprehensive (and complex) infrastructure for the coordination and control of these devices. Avoiding the need for tight integration with this infrastructure enabled a flexible and rapid deployment of the MANET platform for the realization of the ATLAS experiments. Moreover, due to the lack of integration requirements, it became straight-forward to apply the MANET platform in further experiments beyond the scope of ATLAS/RAWFIE.

The ATLAS experiments aimed at assessing the performance of various routing protocols (detailed further in Section 3.2.4) suitable for use in UxV-based opportunistic networks under a variety of real-world conditions referring to the concrete use-case of providing connectivity to remote maritime areas, as depicted in Figure 1. According to this scenario, a remote island without networking infrastructure obtains opportunistic network connectivity via another area already equipped with network access. The network gateways at the two areas are connected by means of an opportunistic network of USVs acting as mobile nodes.

Figure 1. Use-case for the ATLAS experiments.

The evaluation results presented in Section 5 also refer to message exchanges between two fixed endpoints, but this time across stretches of land rather than water. In connection with this point, it is noted that the platform can readily accommodate additional scenarios beyond the case of Figure 1, involving further types of terrain or different traffic endpoints.

3. Architecture of the Platform and Related Software and Hardware Aspects

The architecture of the platform is outlined in Figure 2, which depicts three main modules. One of the modules is responsible for the localization process, which periodically provides updated values for the position and velocity of the mobile node. Another module undertakes the beacon-based signaling, used to periodically advertise the node’s presence (also announcing the node’s current position and velocity) and to sense the existence (and status) of other nodes in its neighborhood. The information about neighbor nodes is collected into an appropriate data structure (see “Beacon Table” in Figure 2). The third module manages the messages to be forwarded to other nodes. For each such message, this module determines the most suitable next-hop node in the neighborhood and forwards the message to it. Next-hop selection occurs in a sub-module labeled “logic for the routing metric”. Different routing protocols can be implemented by modifying only this localized part. Section 3.1 provides further details on the structure and functionality of the aforementioned modules, also discussing some additional auxiliary mechanisms (not depicted in Figure 2).

Figure 2. Architecture of the platform.

3.1. Core Facilities for Nodal Interactions and Ad Hoc Networking

3.1.1. The Localization Process

The localization of each mobile node relies on GPS input and involves a transformation of coordinates and a parametrizable smoothing of the results.

In general, there are two types of coordinate systems used in a Geographic Information System (GIS): The first type is a global, spherical coordinate system expressed in terms of the latitude (φ) and longitude (λ). (In three-dimensional mappings, this representation additionally includes an altitude/elevation component.) The second type is a projected coordinate system. All systems of this type, such as Universal Transverse Mercator (UTM), Albers Equal-Area, or Robinson, among others, provide mechanisms to project maps of local areas on the Earth’s spherical surface onto a two-dimensional Cartesian coordinate plane by transforming the global coordinates of the Earth model φ and λ to planar Cartesian coordinates x and y.

In the MANET platform, each mobile node is equipped with its own GPS device, which provides measurements of the node’s location expressed in spherical coordinates (φ, λ). These are subsequently transformed to Easting (E) and Northing (N) geographic Cartesian coordinates using the “Albers Equal-Area Conic Projection” method [36,37,38], which is a conic, equal-area map projection that uses two standard parallels to reduce some of the distortion introduced by projections with one standard parallel. Although this method still suffers from some distortion of shapes and linear scales, the distortion is minimized in the region between the standard parallels.

GPS measurements are repeatedly acquired and transformed by each node periodically (with a frequency that can be tailored), thus enabling updates of the node’s current position (expressed in Cartesian coordinates) and velocity. However, instead of using the most recent values directly, these values are fed into a circular buffer, which acts as a sliding window of observations. Whenever the current position and velocity of the node are required, the relevant information is obtained by least squares-based smoothing exercised on the values currently stored in the buffer. This smoothing helps to alleviate anomalies due to measurement errors or random perturbations induced by the real-world environment. The size of the buffer can be parametrized, thus controlling the degree of the smoothing effect.

We note that it is possible to bypass the aforementioned GPS-based localization process, simply by making the localization module return location and velocity values produced by simulation software, according to an appropriate mobility model. This alternative mode of operation can be applied to some or all of the mobile nodes in the MANET. In this mode, the mobility of the affected nodes is emulated, and there is no need to attach them to robotic devices.

3.1.2. The Beacon-Based Signaling

As already mentioned in Section 2 and at the beginning of Section 3, each mobile node advertises its current position and velocity through beacon messages broadcast periodically (again, with a frequency that can be tailored) to the node’s neighborhood. The structure of a beacon message is depicted in Figure 3. As it can be seen, the beacon contains information about the current position of the node (expressed in Cartesian coordinates, as obtained by the last activation of the localization module), the previous position (obtained by the immediately preceding activation of the localization module and used for determining the direction of motion) and the current speed (again obtained by the localization module), along with fields for marking the time the beacon was issued and for identifying the sender.

Figure 3. Format of the Beacon Message.

On the receiving side, each node listening to a beacon detects that the sender is a neighbor node. To implement this feature, each node maintains a “beacon table”, including one entry per neighbor node. Once a beacon is received, the receiver checks its beacon table to determine if an entry for the sender of the beacon already exists (by checking the beacon sender’s ID against the IDs of the entries). If the entry exists, the relevant location and motion data are updated in accordance with the data in the beacon message. Otherwise, an entry is created for the newly encountered neighbor. Moreover, apart from the beacon-triggered updates just mentioned, the table is inspected periodically to eliminate obsolete entries, i.e., entries for nodes that were neighbors in the past, but no updated beacon message has been heard from them for a time interval greater than a parameter-specified threshold.

With the aforementioned management of the beacon table, all nodes within communication range are treated as neighbor nodes. However, the platform provides additional facilities for emulating a precisely controlled smaller communication range through software. Specifically, when a node receives a beacon, it calculates its own distance from the sender of the beacon (by using its own location and the location data in the beacon) and considers the creation or update of a beacon table entry only if the calculated distance does not exceed the emulated communication range (specified as a parameter). This software mechanism enables experiments that can address a broader range of network densities, especially when the experiments are conducted in smaller terrains and is handier (and perhaps more precise) than the hardware-based alternative of employing radio signal attenuators (as in other testbeds [39,40]) to reduce the signal range by decreasing the radio transmit power (i.e., the signal strength).

3.1.3. The Routing Protocol and Associated Message Handling Mechanisms

Each node maintains aso-called “routing message table” (see Figure 2), which contains the messages that are currently held at the node and must be forwarded to a different destinationnode. This table is checked periodically (with a frequency that can be tailored), and the next-hop candidate evaluation process is individually exercised for each entry found therein. To this end, the beacon table is consulted to retrieve the current status of the neighborhood, and the value of the routing metric is calculated for each neighbor node in the table. The routing metric takes, as input, the location and velocity of the current node (from the localization module), the location and velocity of the neighbor node being evaluated (from the data in the respective entry of the beacon table), and the location of the message’s destination node (from the data in the routing message table). This input, possibly in conjunction with other relevant data (e.g., the local network density, which can be calculated using the number of entries included in the beacon table and the magnitude of the communication range), determines the suitability of the considered neighbor as a next hop for the message.

When this evaluation process indicates that there exist neighbor nodes more suitable than the current node, the latter forwards the message to the most suitable next hop. According to a special rule, in particular, if the message’s destination node is included among the neighbors, it always scores highest and receives the message. On the other hand, if all neighbor nodes score lower than the current node, this node keeps the message until the next iteration of the evaluation process.

Next-hop forwarding materializes through a routing message sent from the current node to the next-hop node determined by the aforementioned process. As it can be seen from Figure 4, the structure of the routing message includes fields for the sender and receiver addresses and fields for relaying the information in the corresponding entry of the message routing table (i.e., the message’s origin and destination addresses, the location of the destination node, the message ID, and fields useful for calculating end-to-end performance metrics, discussed further in Section 3.1.4). The last field contains the payload of the message (Given the performance evaluation focus of the experiments reported in Section 5, all the messages exchanged in the course of these experiments contained dummy payloads). When the next-hop node receives the routing message, it logs a new entry for the message in its own routing message table and returns an acknowledgment (ACK) message (whose structure is depicted in Figure 5) to the previous message holder. Upon receiving the ACK message, the previous message holder updates its routing message table by removing the entry indicated by the message ID in the ACK message. This acknowledgment process adds robustness to the message forwarding and eliminates the possibility of duplicate or lost messages in the network.

Figure 4. Format of the Routing Message.

Figure 5. Format of the Acknowledgment Message.

The platform makes it easy to implement different routing protocols simply by changing the code for the routing metric. The current implementation already provides support for several alternative routing protocols, briefly described in Section 3.2.4. Moreover, it is noted that the platform is capable of supporting experiments with more than one routing protocol in parallel. To this end, each entry of the routing message table contains an additional field (see third field from the right in Figure 4) that specifies the routing protocol to be used for the routing of the corresponding message. When candidate next-hop nodes are considered for this message, the appropriate routing metric is invoked. The routing protocol specifier propagates from hop to hop through the corresponding field in the routing message, so all hops from source to destination are governed by the same protocol.

3.1.4. Traffic Endpoints and Support for Calculating Performance Metrics

As currently implemented, the platform directly supports MANET experimentation scenarios that employ fixedtraffic source and destination endpoints (as in the scenario of Figure 1). While it is readily possible to implement the source and destination nodes by the same infrastructure used for the mobile nodes, simply by keeping the source and destination stationary at their fixed locations, the platform provides specific stripped-down facilities for them, reflecting their special nature. In more detail, neither the source nor the destination node need the localization module, as they remain stationary at locations known in advance. Similarly, the source node does not need to transmit beacons advertising its status; it just needs to listen to beacons from mobile nodes in its neighborhood so that it can exercise the routing protocol to select the next hops for the messages originating from itself. Analogously, the destination node must send beacons to advertise its presence but does not need to maintain a beacon table for its neighborhood or to exercise the routing protocol functionality (except from returning an ACK for each message delivered to it).

Unlike the mobile nodes, the source node includes a message generation facility for periodically creating messages to be forwarded to the destination node. As already discussed in the previous subsection, the platform supports experiments employing multiple routing protocols in parallel, so each generated message is marked with the ID of the particular protocol pertaining to it. Parameters control the number of different routing protocols that will be employed and the number of messages that will be generated for each protocol.

It is straight-forward to upgrade the platform so that it can support traffic originating from mobile source nodessimply by incorporating the message generation functionality in the mobile node infrastructure. Implementing mobile destination nodes is more difficult, as many routing protocols require knowledge of the destination node’s location. However, the platform can directly support the delivery of traffic to multiple alternative fixed destination nodes. All that is required is to mark each message generated at a source (fixed or stationary) with the destination node applying to this message (according to a pattern determined by the experiment).

The platform also provides facilities for calculating performance metrics: Once a message is generated at its source, a time-stamp of the message generation instant is recorded and relayed all the way to the destination through the corresponding routing messages (see the respective field in Figure 4). When the destination node takes delivery of the message, it subtracts the time-stamp from the current time to determine the end-to-end delay. To enable accurate delay calculations, the source and destination nodes are equipped with real-time clocks (RTC) to maintain their synchronization. Alternatively, this synchronization can be achieved without RTCs, using a Network Time Protocol (NTP) server instead, provided that all MANET nodes are equipped with Internet connectivity through an additional network interfacedifferent than that used for the ad hoc connectivity. Such a dual connectivity feature is also useful for monitoring the operational status of the platform, as discussed further in Section 3.2.

In addition to delays, the platform provides support for determining the number of hops along the path from source to destination. This metric is calculated incrementally as the routing message propagates from hop to hop, and the updated value is stored in the last but one field of the routing message (see Figure 4). The final value of the metric becomes available when the message is delivered to its destination node.

3.1.5. Overall Operation and Event Dynamics

The description given in the previous subsections can be summarized by representing the operation of each node through an appropriate Finite State Machine (FSM). The FSM for the mobile node is depicted in Figure 6a, while the modified versions for the fixed source and destination nodes appear in Figure 6b,c, respectively. In all cases, transitions between states are indicated by arrows denoting the direction of change, and each transition is annotated with a description of the triggering condition. Moreover, transitions related to the localization process, the beacon-based signaling, and the routing protocol are marked in blue, red, and green, respectively, in conformance with the colors used in Figure 2. In the FSM for the fixed source node, transitions relating to the message generation process are marked in brown.

Figure 6. State transition diagram for: (a) mobile node; (b) fixed source node; (c) fixed destination node.

3.2. Implementation Aspects and Associated Configuration and Monitoring Processes

As already mentioned in the introduction, the software of the MANET platform has been implemented in Python on standard Raspberry Pi-based commodity hardware running the Linux OS, using one board computer per network node. Here, we discuss a number of implementation aspects relating to wireless communications and networking, configuration and monitoring of the platform, and hardware capabilities. We also comment on a number of MANET routing protocols that have been implemented on the platform for use in experiments.

3.2.1. Wireless Communications and Networking and Support for Monitoring the MANET Nodes

The platform can be realized using a wide range of wireless communications technologies. The implementation is based on IEEE 802.11 due to the wide availability of versatile and low-cost hardware for its support, but other alternative technologies could have been used instead. The operation of the MANET platform is insensitive to the underlying wireless technology, as all three types of messages (beacon, routing message, ACK) exchanged between nodes, as discussed in Section 3.1, are encapsulated in UDP packets. The connectionless nature of the UDP protocol matches well with the characteristics of the interactions in the MANET environment.

In the implemented platform, each node is equipped with two distinct radio interfaces (both Wi-Fi). The first one is setup in ad hoc mode and supports the UDP-based message exchanges between peer MANET nodes, as just explained. The second interface operates in infrastructure mode and connects the node to an independent auxiliary network of star topology, so that the status of the MANET nodes can be monitored through a gateway. Figure 7 depicts this dual connectivity feature. Typical Linux tools supporting SSH and/or VNC sessions can be leveraged for monitoring. As an example, Figure 8 displays a screenshot capturing status parameters during the realization of an experiment.

Figure 7. Ad hoc and monitoring communications in the MANET platform.

Figure 8. Screenshot from the monitoring process during an experiment.

It is noted that the auxiliary network may also be used to enable an NTP-based clock synchronization between the traffic source and destination nodes, avoiding the need for using RTCs in these nodes, as already discussed in Section 3.1.4.

3.2.2. Initialization and Configuration

As explained in Section 3.1, several aspects of the platform’s operation can be parametrized. In order to implement this feature and to provide means for configuring individual experiments, during initialization, each node in the platform reads a corresponding configuration file and sets relevant parameters to the values specified in the file. The list of parameters is displayed in Table 1, organized in categories. Given that the platform involves three different types of nodes (mobile nodes, static source node, and static destination node) differing in their functionality, the last column in the table indicates the types of nodes using each parameter.

Table 1. Parameters in the configuration files of individual nodes, according to their type.

Group of Parameters	Parameter	Example	Types of Nodes Using the Parameter
Ad hoc network	Network specifier	192.168.167.0/24	All
	Port specifier	10,000	All
Monitoring Network	Monitoring IP	192.168.168.100	All
	Monitoring Port	11,000	All
Node Characteristics	ID (host part of ad hoc net address)	100	All
	Transmission range threshold (m)	20	Mobile, Source
	Period for message table checks (s)	2	Mobile, Source
	Beacon period (s)	2	Mobile, Destination
	Beacon table entry timeout threshold (s)	4	Mobile, Source
Localization Characteristics	Reference Latitude	zz.zzz	All
	Reference Longitude	rr.rrr	All
	Rotation Angle (Degrees)	0	All
	Buffer size for least squares smoothing	5	Mobile
	Location update period (s)	2	Mobile
	Source Latitude	yy.yyy	Source
	Source Longitude	qq.qqq	Source
	Destination Latitude	xx.xxx	Destination
	Destination Longitude	ww.www	Destination
Experiment Characteristics	# Routing Protocols	4	All
	# Messages per protocol	10	Source
	Message generation period (s)	100	Source
	Destination IP Address	192.168.167.103	Source
	Destination ID (host part of the address)	103	Source
	Destination Latitude	xx.xxx	Source
	Destination Longitude	ww.www	Source

As it can be observed, there are parameters for setting up the connectivity of a node with the ad hoc network and the auxiliary monitoring network. Moreover, there are parameters for tailoring the node’s characteristics, namely: the node’s ID (coinciding with the host part of its address in the ad hoc network); the threshold determining the software-controlled communication range of the node (as discussed in Section 3.1.2; if the value of this parameter is set at a suitably high value, the full hardware-attainable range is enabled); the periods between successive routing message table checks (Section 3.1.3) and between successive beacon transmissions (Section 3.1.2); and the timeout threshold for detecting obsolete neighborhood entries in the beacon table (Section 3.1.2).

The category of localization characteristics includes parameters for the longitude and latitude coordinates of a reference point (common for all nodes), which becomes the origin of the transformed Cartesian coordinate system specifying the nodes’ locations in the experiment (see Section 3.1.1). Any fixed location in the vicinity of the experimentation terrain can be chosen as the reference point. Additionally, there is a parameter (again common for all nodes) specifying if the Cartesian coordinate system has been rotated with respect to the easting-northing orientation. A positive rotation angle signifies a clockwise rotation. Further parameters in the localization category specify the period between successive location updates and the size of the buffer used for the least-squares-based smoothing. The fixed locations of the source and destination nodes are directly specified in the respective configuration files.

Finally, the parameters for the experiment characteristics specify the number of routing protocols involved in the experiment, the number of messages that will be routed according to each protocol, the period between successively generated messages, and the ID and location of their destination node.

3.2.3. Hardware Details

The software implementing the functions of each node in the platform runs on Raspberry Pi3 model B (RPi) [41] hardware. The RPi is a low-cost, credit card-sized unit that provides functionality comparable to that of a conventional computer and a computational power exceeding the platform’s requirements. The board uses the BCM2837 chip, a quad-core Cortex-A53 (ARMv8) cluster running at 1.2 GHz, has 1 GB of RAM, and can host up to 32 GB of microSD storage. Moreover, it provides a wide range of connectivity options (USB, serial, GPIO, HDMI, Ethernet, Wi-Fi, Bluetooth, etc.). Due to these features and the existence of an active support community, RPi has been widely adopted in many prototyping projects.

The RPi unit has a built-in Wi-Fi radio and can host additional USB-attached Wi-Fi adapters. In the platform, the built-in Wi-Fi unit implements the ad hoc radio link, while an additional USB-attached Wi-Fi radio, specifically a TP-Link TL-WN722N [42] unit equipped with an external omnidirectional antenna, is setup in infrastructure mode and provides connectivity to the auxiliary network used for monitoring.

Concerning the GPS modules, typical units of medium accuracy have been selected for all the mobile nodes. As a first choice, the nodes were equipped with easy to install VK-162 USB GPS receiver modules (based on the Ublox 7 hardware setup [43]). This system has a positioning accuracy of 3 m and 0.5 degrees in direction and a timing accuracy of 30 ns. An alternative configuration has also been tested, in which the nodes were equipped with a more precise NEO-M8N GPS unit [44], having a positioning accuracy of 2.5 m and 0.3 degrees in direction and a timing accuracy of 30 ns. In both cases, the Gpsd Linux package has been used for reading the data provided by the GPS module.

Regarding power-related issues, each RPi-based network node in the MANET platform can be powered by a 5 V power supply or by a power bank through a micro-USB plug. The exact input current requirements vary, depending mainly on the kind of equipment attached to the main RPi board, but typically remain below 0.5 A. In more detail, an active RPi model B board consumes about 250 mA, and an additional amount of 100 mA is needed for the external Wi-Fi adapter, while the GPS module takes another 70 mA. Given the need for mobility, the most flexible way to support the experiments is by using power banks. In view of the power consumption requirements just discussed, a 5000 mAh power bank can enable more than 9 h of experimentation before a need to recharge, which is more than enough for typical experiments, such as those presented in the paper.

The cost of an RPi unit, including a typical microSD card providing 16GB of storage, is less than 60 USD. The external Wi-Fi module costs less than 10 USD, while a GPS unit (of characteristics comparable to those mentioned above) can be purchased at prices around 15 USD. Even when an additional 20 USD for a 5000 mAh power bank is counted in, the total cost per node is kept below 100 USD. This cost is low enough to permit flexible platform deployments, free from any scalability concerns.

3.2.4. Routing Protocols Implemented in the Platform

Several routing protocols have been implemented and used in experiments. The routing metrics associated with these protocols differ, making the protocols more or less suitable for a given set of network conditions. Some metrics emphasize the “forward action”, i.e., the immediate impact of the next-hop forwarding on the progress of the message towards the destination node. Other metrics consider only the “carry action”, namely the progress due to the motion of the node holding the message. A third class of metrics takes into consideration both effects.

As a typical representative of the protocols focusing on the forward action, an implementation of the geographic MFR protocol [45] has been provided. This protocol selects as the next hop the neighbor node maximizing the distance between the current node and the neighbor node’s projection on the line connecting the current and destination nodes. In common with all forward-based protocols, MFR performs best in dense network topologies, when the existence of multiple neighbors permits the immediate selection of a next-hop node and the forward effect dominates. However, such protocols are not appropriate for low-density environments. In such conditions, the exploitation of the nodes’ motion becomes necessary, and carry-based protocols are preferable. To provide a typical representative of the carry-based category, the MoVe protocol [46] has also been implemented. This protocol employs a metric based on the orientation of the nodes’ motion: a candidate next-hop node becomes more preferable when it moves more directly towards the destination.

Besides these two extremes, an implementation of the Maximum Advance Decision (MAD) routing protocol has also been provided. (The experiments in the context of the ATLAS/RAWFIE project explored the performance of this protocol.) MAD is a more advanced protocol that dynamically combines the effect of both the forward and carry actions on the rate of a message’s approach to the destination in a way that arises naturally from a consideration of the system’s dynamics. The metric of this protocol makes use of the “retaining time”, which is an estimation of the time that a candidate node will keep the message if it is selected as the next hop. The retaining time encapsulates information relevant to the local network density and to the location and velocity of the considered next-hop node. In view of these characteristics, MAD operates effectively in environments spanning a wide range of mobility and nodal density conditions. For a deeper insight into the dependence of the mean retaining time on the relevant network and nodal context, see [47]. Two versions of MAD have been implemented in the platform: the original version of the protocol [48] and a more recent version, which uses a refined representation of the retaining time [49]. Specifically, for candidate next-hop nodes moving toward the message destination, the original version of the protocol estimates the retaining time by calculating the time required until the node reaches the point closest to the destination, assuming straight-line motion at a constant speed. The refined version distinguishes between nodes capable of becomingclose enough to the destination for direct message delivery and nodes whose trajectory does not enable such a delivery. In the second case, the estimation of the retaining time includes an additional term to represent the time spent by the node while moving away, past the point closest to the destination, until a suitable next-hop node is encountered. Moreover, the refined version of the protocol consistently scales the retaining time by a factor inversely proportional to the network density to capture the positive impact of the more frequent forwarding opportunities encountered in denser networks, leading to an earlier discovery of an appropriate next-hop node and, thus, to a shorter retaining time.

In addition to the protocols previously mentioned, it is readily possible to provide implementations for other protocols too. As already noted, the required changes in the software are confined within a small part of the codeused for defining the routing metric.

4. Devices Enabling Mobility in the MANET Platform

As mentioned in the introduction and Section 2, the mechanisms of the MANET platform are completely decoupled from the details of the devices realizing mobility. To demonstrate this flexibility, in this section, we briefly describe a number of different devices that have been employed so far for realizing the physical motion of the platform’s mobile nodes in experiments.

4.1. UxV Devices Enabling Mobility in the ATLAS/RAWFIE Experiments

Given the orientation of the ATLAS-related experiments towards the use-case scenario of Figure 1, USVs were used for carrying the boards for the MANET nodes. (These experimentation activities took place in a naval base located in Skaramagkas, near Athens, Greece.) Among the choices available in the RAWFIE infrastructure, the platform was tested on board specific types of USVs with desirable characteristics. Specifically, the FLEXUS USV devices (Figure 9a) [50] were capable of maintaining a steady trajectory, and this characteristic matched well with the requirements of the mobile nodes. The PLaDyFeet USV devices (Figure 9b) [51] could maintain a stationary location at sea, fitting better to the needs of the static source and destination nodes. Moreover, besides the USVs just mentioned, RAWFIE was made available to other types of UxVs as well, such as the Endeavour All-Terrain UGVs (Figure 9c) [52]. These were exploited for conducting further experiments, this time on a ground terrain.

Figure 9. (a) An ATLAS mobile node attached to a “FLEXUS” USV; (b) ATLAS static destination node attached to a “PLaDyFeet” USV; (c) ATLAS mobile node attached to Endeavour UGV.

The mobility model for all types of UxVs was implemented using a series of specific waypoints that had been calculated before the experiment. It is noted that the RAWFIE infrastructure employed a dedicated IEEE 802.11 network (operating in a channel different from those used by the MANET platform) to interconnect the UxVs with the RAWFIE control and navigation facilities. The lack of requirements for a tight integration of the MANET platform with the RAWFIE infrastructure enabled a flexible and rapid deployment of the platform for the realization of the experiments.

4.2. Enabling Mobility through Simple Arduino-Based Mobile Robots

The experiments reported in the next section relied on simpler, inexpensive mobile robots. The said devices have a three-wheeled configuration, with two driving wheels at the front sides of the chassis, each powered by a continuous rotation servomotor, and a third rear caster/free-wheel (see Figure 10). This configuration is simple but effective, making the vehicles flexible and capable of changing their direction through differential steering techniques with minimum friction. The driving side wheels are equipped with photo interrupters for speed and direction stabilization purposes.

Figure 10. Board of a mobile node attached to an Arduino-based mobile robot.

Each mobile robot is controlled by a dedicated Arduino Uno unit and uses a 2-cell lithium-polymer battery for energy supply. Moreover, the chassis of each robot is equipped with an ultrasound distance sensor on its front, which can sense the robot’s approach to an obstacle, e.g., whenever the borders of the testing area are reached. By programming the control unit to respond to triggers from the distance sensor with appropriate changes in the robot’s direction, several typical mobility models can be supported (including the Random Direction mobility employed in the experiments of Section 5).

For more details on the design, the control principles and the implementation of these robotic vehicles, the reader may consult [53,54].

5. Results from Experiments Using the Platform

We now turn to the use of the platform and present results from an extensive set of experiments targeting the performance comparison of all implemented routing protocols, namely: the forward action-oriented MFR, the carry action-oriented MoVe, and the two versions of MAD (original and improved, the latter using a more refined estimation of the retaining time; see Section 3.2.4).

5.1. Setup and Methodology

All experiments addressed the same scenario, according to which mobile nodes relayed messages exchanged between a pair of static source and destination nodes. The mobile nodes moved within a square area of size 14 × 14 m, and the source and destination nodes were placed at diagonally opposite vertices of the square. Four mobile nodes were employed, all of which moved according to the Random Direction mobility model [55] with zero pause time and a constant speed of magnitude $V=0.54 \mathrm{m}/\mathrm{s}$ (approx. 2 km/h). The experimentation activities took place in an outdoor area within the campus of the Agricultural University of Athens, Greece. Figure 11a provides relevant coordinates (based on the Google Maps information), while Figure 11b captures a snapshot of activity on the terrain.

Figure 11. (a) Coordinates of the experimentation terrain; (b) snapshot of activity in the terrain.

Given the moderate size of the experimentation terrain, if the full range of wireless communications had been enabled, it would have been impossible to explore the impact of the network density on the performance, as all MANET nodes would have been in range of one another, and every node would have perceived all others as (topological) neighbors. Even worse, the destination node would have been directly reachable from the source node, negating the need for any intermediate message relays. To mitigate such effects, the experiments leveraged the platform’s capability of controlling through software the communication range of the MANET nodes (see Section 3.1.2). Using this mechanism, different experiments were conducted, setting the communication range $r$ of the MANET nodes to 3, 5, 6, and 7 m in turn. Higher values of the range yield greater network densities. Indeed, the regularity of the Random Direction mobility model implies that, at steady-state, a mobile node may occupy any point in the mobility terrain equally likely. Thus, given a mobility terrain of overall area $A$, a mobile node with communication range $r$ has each of the other $N-1$ mobile nodes in range with probability $\pi r^2/A$, so the node has on average $\left(N-1\right)\pi r^2/A$ neighbors. In the experiment scenarios, $A={14}^2{ \mathrm{m}}^2$ and $N=4$, so the four aforementioned range values correspond toan average number of 0.43, 1.20, 1.73, and 2.36 neighbors per node, respectively, spanning a range from low to higher network densities.

Experiments addressing all four network densities were repeated three times, each time employing a different configuration of the platform. In the first configuration, the motion of the mobile nodes was emulatedby interfacing the localization module of the nodes with software simulating mobility, as explained in Section 3.1.1. Both of the other two configurations involved actual mobility (realized by attaching the hardware for the mobile nodes to mobile robots with characteristics as in Section 4.2), differing in the type of the GPS devices used for localization. Specifically, the MANET nodes in the second configuration were equipped with NEO-M8N GPS receivers, while the third configuration employed the lessprecise VK-162 USB devices instead (see Section 3.2.3). By comparing results across all three configurations, it became possible to explore the impact of varying degrees of localization accuracy on the performance of the routing protocols.

For all protocols, network densities, and platform configurations, the performance was quantified through the average delay for message delivery from source to destination and the average number of hops required for this delivery. The platform provides facilities for calculating both of these metrics, as discussed in Section 3.1.4. The values reported here were obtained by averaging samples over 20 message deliveries using each routing protocol. In order to avoid correlations in the sampling process, the time between message generation events was chosen to be sufficiently large to ensure that the arrangement of MANET nodes on the terrain, as “seen” by any two consecutively generated messages, were completely different. It is noted that, in the interest of representing the end-to-end delays in a speed-invariant form, their values in the following results are expressed in a normalized way as multiples of the time constant $r/V$ that determines the time required for refreshing a node’s neighborhood (For a node with range $r$ moving at constant speed $V$ on a straight line, time equal to $2r/V$ must elapse before the neighborhood areas spanned by the node at the beginning and end of this time become non-overlapping).

5.2. Results

The results from the experiments appear in Figure 12, Figure 13 and Figure 14. All the main trends exhibited therein are in accordance with intuition, as we now discuss. In particular, for all considered routing protocols and platform configurations, the average end-to-end delay decreases as the network density increases. This happens because in denser topologies, a message-carrying node is in contact with more neighbors and thus experiences an increased number of potential message-forwarding opportunities per unit of time, with beneficial impacts on the delay-related performance.

Figure 12. Configuration 1 (emulated mobility): (a) average end-to-end delay and (b) average number of hops vs. network density (V = 0.54 m/s).

Figure 13. Configuration 2 (real mobility, GPS type NEO-M8N): (a) average end-to-end delay and (b) average number of hops vs. network density (V = 0.54 m/s).

Figure 14. Configuration 3 (real mobility, GPS type VK-162): (a) average end-to-end delay and (b) average number of hops vs. network density (V = 0.54 m/s).

The effect and relative importance of the forward and carry actions are also visible in the results. By comparing the end-to-end delays for MFR and MoVe, it is seen that in all configurations, the carry-based MoVe protocol outperforms the forward-based MFR when the network density is low, while the opposite is true for high densities. Again, this phenomenon is intuitively appealing: When the network density is low, a message-carrying node makes contact with just a few neighbors, on average, so the node rarely encounters suitable forwarding opportunities. Thus, in such environments, the carry action is more effective. On the other hand, in dense topologies, there are more neighbors, and it is easier for the node to identify suitable next hops, the forward action prevails, and the MFR protocol performs better.

In networks of intermediate densities, both the forward and carry actions have a significant effect, and both should be taken into account for an effective routing. The MAD protocol is inherently capable of exploiting the right combination of the forward and carry actions, behaving more like MoVe in low densities and more like MFR in higher ones. As it can be seen from the delay-related results, both versions of the protocol adjust their operation properly across the entire range of network densities and for all configurations, thus being more flexible and better performing overall than the protocols relying on a single action. Further, the results indicate that the improved version of MAD outperforms the original version of the protocol throughoutbecause the more accurate estimation of the retaining time in the improved version enables a better adjustment of the forward and carry components in the protocol’s next-hop selection metric.

With respect to the number of hops required for message delivery, the results demonstrate that, in all configurations, MoVe uses a smaller number of hops than MFR. Again, this is expectedbecause MoVe determines the suitability of next-hop nodes solely on the basis of the direction of motion. Thus, once a node heading towards the destination receives the message, it will be unlikely to encounter neighbors better directed than itself, and the same node will keep carrying the message until delivery. On the contrary, MFR bases its operation on the forward action, which inherently involves a greater number of hops. It is noted that a smaller number of hops is not necessarily accompanied by better delay-related performance: The results clearly show that in dense environments (where the forward action is most impactful), the fewer hops of MoVe prevent this protocol from attaining the better end-to-end delay exhibited by MFR and the two versions of MAD.

The aforementioned patterns in the results are not only reasonable, as discussed, but also well aligned with analogous patterns in other results, such as the simulation-based results in [47]. This is remarkable, considering that the simulation results addressed idealized settings (perfect communication channels, perfect knowledge of location and motion, etc.) and involved significantly larger terrains and a significantly greater number of mobile nodes (enabling a smoother, more uniform coverage of the mobility terrainand a reduced impact of boundary effects at the terrain’s borders). The fact that experimentation using the platform in a terrain of moderate size, with only a few mobile nodes, was capable of reproducing important trends identified in results from idealized setups provides validation for the platform and a strong indication of its capability to support the realization of meaningful experiments.

5.3. Further Discussion and Real-World Effects

Of course, the main reason for employing an experimentation platform is not to replicate results from simulations but rather to study the impact of real-world effects and imperfections, something not possible with simulations. Here, this aspect is demonstrated by exploring the impact of localization accuracy through a comparison of the performance results across the three configurations. Indeed, the simulated mobility in the first configuration sets a benchmark for perfect localization, while the second and third configurations capture settings of increasingly coarser localization accuracy due to the characteristics of the GPS devices employed in each case. The results indicate clearly that, while all three configurations exhibit the same trends, the performance of all protocols degrades as the localization accuracy becomes coarser. This occurs because message-carrying nodes select next hops on the basis of partially incorrect position information, and this leads to sub-optimalor even inappropriate message forwarding decisions.

It is interesting that, in some respects, the reduced performance due to imprecise localization manifests itself as a smaller network density. Indeed, as remarked earlier, lower network densities are also associated with a degraded performance of all routing protocols because of the reduced number of potential message-forwarding opportunities. However, the connection is stronger, as now explained: By considering the delay-related performance results for each configuration alone, one may determine the value of the density for which the delay curves of MFR and MoVe intersect. Since the carry-based MoVe performs better in sparse topologies and the forward-based MFR in dense ones, the value of the density at the intersection characterizes the transition from sparse to dense topologies, i.e., intermediate regimes for which both the forward and carry actions have a significant impact. In light of this, the results demonstrate that the value of the “transitional” density becomes greater for configurations with more inaccurate localization. In other words, a given network topology will appear to be sparser when the localization becomes less precise.

We point out that the performance impact of the localization inaccuracy has been represented somewhat emphatically in the results just discussed due to particular characteristics of the relevant experiments. Specifically, although the GPS units employed in the second and third configurations are typical devices featuring a modest degree of imprecision (2.5 m for NEO-M8N and 3 m for VK-162, see Section 3.2.3), the effect of this imprecision becomes pronounced in the context of the experiments, due to the comparably small size of the mobility terrain (14 × 14 m, also restricting the magnitude of the distances between nodes) and of the communication ranges employed (3–7 m, also restricting the extent of a node’s neighborhood). If the same GPS devices had been used in setups involving larger terrains and longer communication ranges, the impact of localization inaccuracy would have been milder; the same performance trends would still have been present but to a lesser extent. In the same spirit, it is seen that the small-size experiments discussed here, besides their capability for emphasizing the effect of location inaccuracies, are also useful in demonstrating that the performance of all considered routing protocols degrades gracefully, even when the information on the positions of candidate next-hop nodes becomes highly inaccurate (in relative terms).

We close by presenting results from one more experiment, again representative of real-world aspects that can be studied with the help of the platform. For this experiment, the central part of the mobility terrain was blocked by means of a square obstacle of size 6 × 6 m placed therein (see Figure 15). The experiment employed the second configuration of the platform (real mobility, nodes equipped with NEO-M8N GPS devices), and the communication range was set to 3 m (for a network density of 0.43 neighbors per node, on average). The mobile nodes could move in the free part of the terrain according to the same mobility model as before (Random Direction mobility with speed $V=0.54 \mathrm{m}/\mathrm{s}$), but in this case, the nodes changed direction, not only when reaching the borders of the terrain but also when hitting the obstacle.

Figure 15. Modified experimentation terrain with blocked central part.

The results are in Figure 16, which also displays the corresponding performance metrics for the free terrain (same values as those depicted in the left parts of Figure 13a,b). Clearly, the delay-related performance of all routing protocols is reduced in the blocked terrain. This is expected because the obstacle occupies the central part of the terrain and prevents mobile nodes from taking positions that would enable them to act as beneficial next-hops for other nearby nodes. Moreover, apart from deteriorating the effectiveness of the forward action, the obstacle has a negative impact on the carry action too, as it prevents mobile nodes from moving along trajectories proximal to the shortest path from source to destination.

Figure 16. Configuration 2 (real mobility, GPS type NEO-M8N): (a) average end-to-end delay and (b) average number of hops in a terrain with and without obstacle (V = 0.54 m/s, r = 3 m).

Between these two effects, the one having an influence on the forward action is the strongest. It can be observed that the MFR protocol, which relies exclusively on this action, suffers the worst degradation in the delay-related performance. The low network density featured in the experiment is also a contributing factor: MFR performs poorly in sparse environments, and the reduced effectiveness due to the obstacle of the rarely encountered forwarding opportunities has an adverse effect. The deterioration of performance is less severe for the other protocols, because they can leverage (exclusively or partly) the carry action, which is more suitable in sparse environments. These trends are also reflected in the hops-related results. In the blocked terrain, MFR uses a significantly greater number of hops in its attempts to circumvent the obstacle and make progress towards the destination. Contrarily, the other protocols use a smaller number of hops because in the blocked terrain, it is more difficult to encounter better-directed nodes that would carry faster the message to the destination. Finally, it may be observed that the two versions of MAD exhibit the smallest performance differences between the free and blocked terrains (with respect to both metrics)because of the protocol’s potential for dynamic adaptation and effective exploitation of both the forward and carry effects, as the local conditions vary.

6. Conclusions

The platform proposed in the paper responds to the need for enabling a more flexible and customizable experimentation on a variety of MANET scenarios. The platform has a modular software architecture, which facilitates adaptations, modifications and/or extensions, and can be operated in conjunction with a variety of wireless communications technologies. Its software runs on inexpensive Raspberry Pi-based commodity hardware, using one board computer per network node, and this hardware can be attached to robotic devices in a straight-forward manner, without tight coupling, for moving the network nodes in accordance with controlled mobility patterns. Moreover, the platform provides facilities for restricting through software the communications range (thus affecting the network density) or for emulating the mobility patterns of nodes. By leveraging these features, the operation of the platform can span the range between emulated and real-world experiments, trading repeatability and control for realism, as required.

The effectiveness and versatility of the platform were demonstrated through results from an extensive set of experiments on the comparative performance evaluation of selected routing protocols under diverse conditions. Although the experiments were conducted on a small area and employed only a few mobile nodes, they were capable of reproducing many important phenomena identified in previous results, derived in connection with idealized simulation-based setups. Moreover, the experiments provided additional insight into real-world aspects, such as the impact of inaccurate location information or of restricted mobility patterns. Overall, the results provide validation and a strong indication of the platform’s potential for supporting the realization of meaningful experiments.