## 3 Description of the Maritime Data Transfer Protocol  
The proposal that has been designed for data transfer in autonomous maritime vehicles is aimed to address all the open issues previously described by means of the following features:  
1. The information that has been included is relevant and consistent with the needs of the partners and companies that are involved in the SWARMs project. Considering that the list of participants in the project ranges from autonomous maritime vehicle vendors to underwater acoustic modem manufacturers, it is believed by the authors of this manuscript that it fits quite accurately the requirements for information interchange. Specifically, feedback received from the network layer has been pivotal in order to tackle the issue of a constrained, unreliable transmission medium. 2. Data level transmissions. Unlike other protocols or decentralized data transmission proposals, information exchange has been conceived to be performed at the data level, so that it will be fully and easily ported to the autonomous maritime vehicles that are used in the project. 3. Underwater adaptation. The protocol has been designed from scratch for data transmissions in a maritime (and more specifically, underwater) environment. Again, the feedback provided by the partners of the SWARMs project has been of major importance in order to include all the relevant data in the PDUs. Therefore, they have been tailored in terms of types and fields used to contain the parameters of interest in a distributed system or a CPS with a significant component of autonomous maritime vehicles. If the previous proposals are taken into account, there are several actions that have been carried out when developing MDTP in order to solve the challenges that have been previously presented. These actions have been summarized in Table 2.  
It is due to all these reasons that the protocol has been named _Maritime Data Transfer Protocol_. Aside from the actions that have been taken by the developers of this protocol, there are several other advantages that can be offered due to the tools that have been used, such as time and space decoupling (due to the usage of DDS for this functionality, which allows publishers to connect whenever they are able to do so in case they become momentarily out of the deployment, as it is likely to happen from time to time in submarine environments), automatic discovery of nodes, quality of service guaranteed by default or optional security support. All the procedures undertaken that justify the PDUs design have been included. \begin{table}
\begin{tabular}{l l l l} \hline \hline
**Name of the Proposal** & **Advantages** & **Disadvantages** & **References** \\ \hline Message Queue & Solution suitable for & This proposal has not been conceived for underwater & MQTT consortium. _MQTT_ \\ Telemetry Transport & distributed systems. & & _Version 3.1.1_[29]. [PERSON], [PERSON], & _Mtg telemetry transport (mqtt) 03.1_ \\ \hline MQTT-SN & Includes Publish/Subscribe & It has been developed for sensor & [PERSON], H.L.T., _MQTT For Sensor Networks_ & _MQTT For Sensor Networks_ & _MQTT-SN Protocol_ \\ \hline Embedded binary HTTP & Small-sized transmissions with a similar approach to CoAP. & Solution conceived for the & \\  & & application layer rather than & \\  & & lower ones. Power demanded & \\  & & may be too much for & \\  & & constrained devices. & \\ \hline Extensible Messaging & Enables security. & Lack of Quality of Service & [PERSON] (technical \\ and Presence Protocol & Follows a CoAP approach. & capabilities. XML might be & representative of the Internet \\  & & troublesome for underwater & Engineering Task Force, \\  & & data transmissions. & _Extensible messaging and presence_ \\ \hline Lightweight M2M & Management of a wide range of & It is built on top of CoAP, so it is & Tian L. OMA device \\  & embedded systems. & unsuitable for underwater & (OMA DM WG), _Lightweight_ \\  & & data transmissions. & _m2m (ouna lzm2m)_[38]. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Cont.