UTFacultiesEEMCSDisciplines & departmentsPSEducationAssignment: Build a MaritimeManet node

Assignment: Build a MaritimeManet node

Design and implementation of an improved MaritimeManet node

Mobile Ad-hoc Networking at Sea

Maritime organizations increasingly conduct operations at sea using multiple, possibly unmanned, platforms. An example for the Coast Guard is ‘distributed surveillance’ in which a large operational area is collectively inspected by unmanned surface vehicles (USV) and unmanned aerial vehicle (UAV), each carrying sensors with limited coverage. Video, image and data communication among those platforms is indispensable for such operations, while the distance between platforms at sea is generally relatively large. The maritime environment thus poses challenges for suitable communication within multi-platform systems.

MaritimeManet is an ad-hoc self-organizing wi­re­­less network that addresses these challenges. For radio communication, a MaritimeManet node uses a number of beams arranged in a sunflower pattern as shown left in Figure 1. The middle of the figure illustrates how each beam is created with state-of-the-art WiFi radio modules, a single board computer and a panel antenna to enable long distances transmission. The beams collectively cover all directions and thus enable communication in all directions. The resulting node, shown right in Figure 1, is called a Multi-Beam Antenna (MBA).

The fundamental principle in MaritimeManet is to automatically discover other nodes and to set up the strongest possible wireless connection between two nodes within radio reach by selecting the ‘best’ antenna at both nodes. To support connectivity while nodes move with respect to each other, MaritimeManet periodically selects the ‘best’ antenna at all nodes, which may result in handover of a connection to an adjacent antenna of a node. Movement of nodes may also lead to automatic removal of connections or to automatic creation of new connections.

Figure 1 – Composition of a single beam using commercial-off-the-shelf components.


Problem Statement: 

Via the control channel, MaritimeManet calculates between which sectors of peer nodes a data connection can be set up, and at what frequency. Figure 2.a shows a schematic view of the composition of such a data connection in the initial implementation. Between sectors (S) of node A and node B a wireless connection is set up. In the hub (H) of each node there is a router with an interface for each sector. A concatenation of a VLAN (HA->SA), a wireless connection (SA->SB) and a VLAN (SB->HB) must result in a transparent connection between HA and HB. In order to create this transparent connection, the wireless connection must support 4-address mode. At the time of this initial implementation, only the AP/STA mode of 802.11 supported 4-address mode in OpenWRT. For more details see [1].

This initial implementation is complex because of two reasons: first there must be unambiguous decisions about the AP or STA role of the peer sectors of a wireless connection, and second the scope of a handover of a connection to an adjacent sector involves not only own sectors, but also the peer sector. The reason for the latter is that a new 802.11 association needs to be set up (dashed blue line in Figure 2.a). Notice that 802.11 fast roaming mechanisms do not help here because the STA part may also need a handover, which is not supported by fast roaming.

Figure 2 – Abstract visualization of implementations. In (a) the initial implementation of MaritimeManet, and in (b) the envisioned SDWN implementation of the node.

In order to simplify the operation of handovers in MaritimeManet, the idea is suggested to use Software-Defined Wireless Network (SDWN) concepts. With such concepts, the 802.11 functionality is split over the sector and the hub of a node: the sector is merely a wired-wireless relay taking care of the physical 802.11 layer, and the hub does all other 802.11 processing including association. In this case, 802.11 associations exist between the hubs of peer nodes instead of between sectors of peer nodes in the initial implementation. Hence in Figure 2.b there are only blue lines. Handover in this case would only require dynamically changing a forwarding rule to the new sector in the SDN-switch, e.g., Open vSwitch [3], and setting the radio of the new sector to the correct frequency. Though this results in much simpler operation, the network functionality and configuration required for it is far more complex to realize.

Tasks: 

An improvement w.r.t. the initial implementation that maintains the advantages of the SDWN implementation, but avoids its complexity, might be obtained when using 802.11s mesh mode interfaces at the sectors instead of AP/STA (see e.g., [2]). Mesh interfaces are symmetric on both sides of a wireless connection like IBSS interfaces. Unlike IBSS, mesh interfaces do support 4-addresses (in fact, even six) and have improved security and MAC operation. Although 802.11s has been designed to provide multi-hop mesh networks, and thus include a routing function, in MaritimeManet we don’t need this routing function. We will only use the discovery and peering capabilities.

The connection between the hub and the sectors of a node can be according to the initial implementation or according to the SDWN implementation. When using the latter, the handover switching times can be much shorter.

The central question in this assignment is to provide theoretical and practical evidence that mesh interfaces can advantageously be used in MaritimeManet. More specifically, the assignment entails:

Work: 

30% Theory, 50% Simulation, implementation and demonstration, 20% Writing


Contact:  

Jan Laarhuis (j.h.laarhuis@utwente.nl)

Alessandro Chiumento (a.chiumento@utwente.nl)


References

[1] J.H. Laarhuis, ‘MaritimeManet initial implementation’, TNL internal report (powerpoint with notes), 2017

[2] OpenWRT page on 802.11s, https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s

[3] Linux Foundation, ‘Production Quality, Multilayer Open Virtual Switch’. Retrieved from http://www.openvswitch.org