Design of a naïve sub-sea communication protocol
for data transmission over an acoustic channel
S. K. Das, D. Pal, A. Saha, and S. N. Shome
Department of Robotics & Automation, C.M.E.R.I., M. G. Avenue, Durgapur-713209,
West Bengal, India
Abstract---This paper considers the design of a simple application
layer sub-sea data transmission technique over an acoustic channel,
which provides for the major communication link between an
unmanned submersible and a control-station residing on the sea-
surface. The proposed communication protocol aims towards the
correct and reliable delivery of data with the transmission of
maximum information during a single session of communication
over a noisy acoustic link. The protocol as discussed in this paper
comprises an error detection and recovery technique, characterized
by selective retransmissions and predictive recovery at the receiving
end. This also accounts for a fair utilization of bandwidth, which is
usually very low in the case of acoustic communications.
Keywords---acoustic communication, protocol, selective
retransmissions, error recovery
I. INTRODUCTION
T HE objective of this paper is to propose a simple
indigenous data transmission protocol to communicate
with an autonomous underwater vehicle (AUV), moving
underwater at a considerable depth from a control station
residing on the surface. The most adopted method of
communication in the case of underwater data transmission is
through acoustic links, since radio is not suitable for
underwater usage because of extremely limited propagation
[1]. But, due to the inherent limitations of acoustic modems
[2] a suitably efficient and error-free communication protocol
had to be designed for the purpose of transmission of data to
and from the surface and sub-sea networks.
In this paper, an attempt has been made to
concentrate on the design of an indigenous communication
protocol, involving the framing of data packets, realization of
the sequence for transmitting data and error-free reliable
delivery of data over the noisy channel by selective
retransmissions. As may be understood throughout the paper,
the protocol lays greater emphasis on correct and reliable
transmission of data over minimization of propagation delay
or bandwidth utilization.
In this regard, it is worth mentioning that acoustic
propagation of data is associated with various losses [4], like
spreading loss, absorption loss, multipath issue and others.
Hence, it is a necessity to design an application layer protocol
for the safe and reliable data communication between the
surface-control and the AUV for the safe and successful
operation of the unmanned vehicle.
II. CONTROL AND COMMUNICATION
The overall communication channel comprises a control as
well as data channel. The control command channel is
predominantly a downlink channel, whereas the data channel
is a two-way transmission. Since the control communication
link has a lower data rate with high information, therefore the
control channel needs to be put to a higher priority in
comparison to the data transmission link as far as the safety
of the AUV’s mission is concerned.
Now, since the AUV is autonomous therefore there
is no need for human intervention. But, in some situations
like launching, diving and retrieval phases it is very difficult
to maneuver the AUV automatically with human-like
precision. It is thus required that during these phases the
AUV must be operated manually from the surface in order to
maintain proper safety of the vehicle during the various
phases of the mission. As a result, it is necessarily important
to receive the commands correctly at the receiving end. In
this regard, the set of various commands, (in the form of
mnemonics) that have been employed are as follows:
• ALV
• MAN
• AUT
• ABT
• STA
The ALV command is request-for-alive-status and is
responsible for maintaining an idle control command link
between the AUV and the surface control. On reception of
this command, the AUV sends an ACK to the surface, which
indicates that the AUV is capable of communicating with the
surface. MAN command is requesting the AUV to switch
from the automatic controlling mode to manual (joystick)
controlling mode. Likewise, the AUT command is requesting
the AUV to revert back to the automatic mode from the
manual mode of control. The ABT command forces the AUV
to shutdown its system and abort the mission immediately.
This is required when it is understood that an emergency has
occurred and it is impossible or unsafe to put the AUV in
mission. The STA command is to request for the system
status from the AUV at a particular instant of time, for
example the positional and attitude information or the battery
status.
 Table-I
Association of command mnemonics and code
Mnemonics Patterns Codeword
ALV AL/LL/LV 0x0123
MAN MA/AA/AN 0x0456
ABT AB/BB/BT 0x0789
AUT AU/UU/UT 0x0ABC
STA ST/TT/TA 0x0DEF
Coming to the other side of the communication link,
the data channel comprises system specific and navigational
information, which the AUV uplinks to the surface-control
but only on the reception of the STA command from the
surface.
Considering the following example of data sent
from the AUV to the surface control station, we have
“$AOSI,22.098,0.000,1.000,23.000,148.678,98.97,0xFEDD
”. The first value following the $AOSI tag is the heading of
the vehicle; the next value indicates the speed of the vehicle
in the east direction, whereas the following value indicates
the speed in the north direction. Following it the value
indicates the net displacement of the vehicle from its start
position and it is once again followed by the available battery
life. Finally, the packet is completed with a checksum for
error detection. From the surface-control side, the data
channel comprises positional information of AUV (while
diving underwater) with the ship as reference, which the
surface-control receives from the USBL (an Acoustic
Positioning System) and downlinks the same to the AUV.
Fig. 1 Piggybacking data and Command
Since the acoustic link has a considerably low bandwidth,
therefore it becomes extremely important to transmit
maximal information in the available bandwidth. Out of this
necessity, each data packet transmitted from the surface-
control consists of a data message (data obtained from
USBL) and a control command framed into a single
encapsulation as shown in Fig.1. This results in the
elimination of the transmission delay as well as overhead of
bandwidth that would have got incurred for a separate
transmission of command packets alone.
III. COMMUNICATION PROTOCOL
This section has been subdivided into three sub-sections for a
detailed description of the overall design of the protocol. The
first sub-section deals with the process of framing of packets
both at the sending end as well as the receiving end of data
transmission. The subsequent sub-section describes the
overall transmission sequence between the surface-control
and the AUV. The last sub-section describes in details the
technique adopted for detection of errors and recovery.
A. Packet Format
The major determining factors for deciding upon the format
of data packets at either end have been:
• Bandwidth of the communication channel,
which is 80 bytes for uplink and downlinks
each. Hence, the total available bandwidth
accounts for only 1280 bits.
• High probability for occurrence of errors during
transmission, although the bit-error rate for
acoustic modems of Link quest make is of the
order of 10-7, as may be referred in [8].
At the surface-control end, a packet to be transmitted consists
of the following:
• Header Field
• Data Field
• Control command field
The header is very important as far as information
extraction is concerned. It contains a packet bit-map (PBM).
The PBM consists of the bit positions of all the internal
components of the packet. Fig2. is a schematic representation
of a PBM.
PSN DO DL CO CL
Command
ByteLength
Command
Byte Offset
Data
ByteLength
Data Byte
Offset
Packet
sequence
Number
Fig. 2 schematic for packet bitmap (PBM)
The PBM is of great help at the receiving end, i.e. AUV
where the receiving code gets to learn the precise bit
positions of all the packet contents straight from the PBM
and without exploring the entire packet.
The data field contains an original data message and
a replicated image of the same. This redundancy helps in
reducing the rate of retransmission requests, which shall be
covered in details in Section III.C, where the process of error
detection and recovery will be described. As shown in Fig. 3,
the structure of the data field is completed with a checksum
for detection of errors through CRC. The control command
field is structurally the same as the data field, with the only
difference being that it contains the various control
commands issued at the surface-control node. Following is a
byte organization for the entire structure of a packet of data
to be transmitted from the surface-control to the AUV.
Fig. 3 structure of a packet from Surface control to AUV
On the other hand, each packet to be transmitted
from the AUV back to the surface-control consists of the
following:
• Header Field
• Data Field
• Checksum
The header consists of the following information:
Packet Sequence Number (PSN): this acts as the
ACK for the packet just received. For example the PSN for a
received packet having sequence number 123, is 123+1=124.
This forms the ACK for the packet 123.
Negative Acknowledgement Byte (NACK): the
NACK field stores the sequence number of the packet that
the recipient should have received but it did not. This field is
important for retransmission of lost packets.
Data Error: this bit indicates whether the data field
in the received packet is erroneous or not. If this bit is set it
means some error was detected in the data field of the
received packet, and if it is reset, then no error was detected.
Command Error: this bit has the same function as
that of the data error bit, with the only difference being it
indicates the presence of errors in the command field of the
received packet.
The data field contains system related information
and navigational information which the surface needs to be
educated about the AUV, while it is carrying out its mission
underwater.
The checksum helps at the receiving side (surface
control) to detect the presence of errors in the packet. The
overall organization of a packet transmitted from the AUV to
the surface control is illustrated as follows in Fig. 4.
Fig. 4 structure of a packet from AUV to surface control
B. Sequence of Data Transmission
In this section, the authors would like to discuss in details the
various major activities as well as the sequential interaction
between the two communicating ends involved in the
proposed communication sub-system. For the same purpose,
the following notations may be considered,
B = the available bandwidth of the acoustic link,
N = the average packet size,
Δ = the mean propagation delay for the link,
R = the average response time of the USBL,
C = the mean data processing time of AUV,
T = the timeout required by the surface-control for
retransmissions.
As shown in the activity diagram in Fig. 5, the
surface-control first of all, gets the positional information
from the acoustic tracking system or USBL (Ultra Short
Baseband Line), connected to the AUV. At the next step, it
gets the operator’s command. Over here, the surface-control
does not indefinitely wait for the operator to give a
command, whereas it times out after a certain time interval
and issues an ALV command (refer to section II), just to keep
the communication alive. At the same time it stores the
operator’s command (if any) into a queue for future
reference. Subsequently, it transmits a packet consisting of
the data (from USBL) as well as control command from the
operator or ALV if the condition N<=B remains valid, and
waits for an ACK to come from the other end for a certain
time interval, after which it times out. The time for which it
keeps on waiting depends both on the transmission delay and
the response time of the acoustic modem. It can be therefore
mathematically expressed as follows:
 T >= 2NΔ+R -------------- (1)
Now, Δ can be expressed as:
Δ=L/VS -------------------------- (2)
where L is the slant-range of AUV from the surface-
control and VS is the speed of sound in water. But, this is only
an ideal value. The transmission delay may vary with time
and interference from waves and other noises. Hence,
equation (2) can be modified as follows:
Δ=L/VS + K ------------- (2’)
where K is a compensator which compensates for
the unwarranted variations in transmission delay. The value
of the compensator is to be decided empirically. Again, R can
be expressed as: R=1/F ------------------------- (3)
where F is the operating frequency of the modem.
Finally, substituting the values of Δ and R from (2’) and (3)
respectively in (1) the timeout time T may be obtained as
follows:
T = 2N (L/VS + K) + 1/F
Now, if the surface-control receives the ACK within
timeout, it checks the reply message from the AUV, to find
out the detection of errors. Over here, errors in the data field
as well as in the command field are taken care of separately.
No retransmissions are made in the case of errors in the data
field, whereas errors in the command field result in
retransmissions. This is because the AUV always demands
updated positional information from the surface, and there is
no point in sending the old positional information to it, when
it is already in a new position. Therefore, retransmitting a
particular data field is unnecessary. On the other hand, a
control command is significant enough for the safe execution
of the AUV’s mission. Therefore, it needs to be retransmitted
along with a new data field (recent position obtained from
APOS). The methodology of retransmission of commands
shall be discussed in details in section III.C.
: :
AUVCom... SurfCom...
1: Listen

2: Get APOS data

get APOS 3: Get operator's command

data StoreCommand
into queue

Yes 4: Send Pkt i=APOS+Control command / "ALV"

No
Command?

PKT=APOSData PKT=APOSData + 5: W ait for ACK

+"ALV" Command

SendPKTto 6: Retrans mit Pkt i if timeout occurs

AUV
7: Discard if Pkt i-1=Pk t i

Wait for ACK

8: Send ACK i+1 and data

9: Go to Step :1

No Yes Get APOS

Check for Error Timeout?
Data 10: Retransmit Pkt i if error or NACK

No Get the First Cmd 11: Go to Step: 2 if no error or NACK

Get Apos Data fromthe queue
CMDError?

12: Send Abort command if timeout c

Delete The Prev
Cmd fromqueue list Yes
Timeout Increment
count>=3? Timeout
Get the next Cmd
fromQueue Send Abort Fig. 6 Sequence Diagram for a particular session of
Cmd to AUV communication between the surface and AUV
PKT=APOS+CMD
On missing the timeout, the surface-control
retransmits a new packet consisting of recent position
information and the previous command. Now, on reception
Fig. 5 Activity Diagram for the
Communication Protocol of this duplicate packet the AUV can reject it if it discovers
that this is the same packet it had received during the
previous session. This is well illustrated in step: 7 of the
sequence diagram as shown in Fig. 6. It can also be realized ensured through the retransmission technique and
that a few interactions on the surface side are periodic maintenance of a command history. The retransmission
whereas others are asynchronous with respect to the AUV. technique can be well understood in Fig. 8.
On the AUV end the interactions are always asynchronous.
Coming once again to the Surface side, if the number of
timeouts exceeds 3, then the surface-control sends ABT
command (refer to section II) to the AUV and ends the
communication session. It may be realized that the protocol
for communication as described so far is simple and performs
effective bandwidth utilization through selective
retransmissions [3] of erroneous packets. Moreover,
piggybacking the command fields along with the data fields
saves transmission bandwidth and effectively delivers greater
information in a single session, which is a fair approach
towards the high and uncertain propagation delay of the
acoustic link. The subsequent section shall deal with the error
detection and recovery technique in details.

C. Error Detection and Recovery

One of the major aims of this protocol has remained to
deliver error-free data with maximum information permitted
by the available bandwidth. This section deals elaborately
with the technique adopted for error detection and recovery.
For the purpose of error detection the classical
approach of CRC (cyclic redundancy check) [5] has been
conformed to. This is the simplest kind of error detection
technique but it is incapable of correcting errors. Therefore, a
recovery technique had to be formulated as a part of this
protocol.
As has been discussed earlier in section III.C, each
message is associated with a CRC in a packet. The generator
polynomial for our protocol is the standard CRC-16
polynomial x16+x12+x5+1, which evaluates to be 8005H. The
algorithm for calculating the checksum for a message is
shown in Fig.7.
On reception of an erroneous message at the AUV
end, the corresponding error bit (Data error bit or Command
error bit) is set (refer to section III.C) in the header field of
the reply message transmitted from the AUV. Recovery
operations as defined in the proposed protocol are performed
either by (1) retransmission technique [6][7] or (2) predictive
technique.
As far as the retransmission technique is concerned,
there are no retransmissions in the case of data errors as
discussed in section III.C. Now, if there is error in the
command field, then the same command is retrieved from a
command queue (refer to section III.B), which stores
operator commands in a FIFO sequence. Unless, an error free
acknowledgement for the command last delivered is
received, the same command is not removed from the queue.
It is only on the reception of a positive acknowledgement,
that the command is deleted from the queue. Thus correct
reception of the operator’s commands at the AUV end is
Fig. 7 algorithm for calculating Checksum
The predictive technique involves correcting the
erroneous command at the receiving side (i.e. the AUV end)
there itself. In this regard, let us have an insight of the
construction of a particular command code sequence. If we
can go back to Table 1 in section II, we can find out that each
command is a combination of three pattern sequences. For
example, the single command ALV may be intrinsically
thought of as follows:
ALV=AL+LL+LV
Now, each pattern sequence is further represented in
our protocol as a hexadecimal number, and therefore the
above command can be represented as:
ALV=0001(AL)+0010(LL)+0011(LV)=000100100011
where, the ‘+’ sign represents the concatenation of
the binary sequences (binary codes for corresponding pattern
sequences). Since, each command is divided into three
sequences, therefore the probability of occurrence of errors
gets greatly reduced which can be well realized with the help
of table-2.
Now out of the 8 cases of reception only the last
case demands for retransmission of the same command.
Hence, theoretically the probability of request for
retransmission is 1/8 i.e. 0.125. Now, if it can be recalled, as
discussed in section III.C, each command has its duplicate
counterpart present in a packet. Therefore, using pigeonhole
principle of combinatorics, it can be shown that the overall
probability for request of retransmission for a particular
command on receiving a single packet is (1/8) x (1/8), i.e. and stored in the variable mask_lop. Since, a pattern is
0.015625. represented in the code by a nibble, therefore a masking
Table-II operation by 0x0f (00001111) is required. This helps to
Probable cases of reception of the various pattern extract the low order nibble of a particular byte of the
sequences for the command ALV command array. Likewise, in the second operation the middle
AL (0001) LL (0010) LV (0011) ordered pattern code is extracted and stored in the variable
Correct Correct Correct
mask_mop. The same activity is carried out in the third
Correct Correct Incorrect
Correct Incorrect Correct operation, where the right ordered pattern code is extracted
Incorrect Correct Correct and stored in the variable mask_rop.
Correct Incorrect Incorrect The pattern sequences are then compared with the
Incorrect Correct Incorrect predefined patterns and the respective command is obtained
Incorrect Incorrect Correct by mapping the pattern into a command versus pattern table.
Incorrect Incorrect Incorrect
The predictive technique fails only in one of the possible 64
cases and then recovery through retransmission technique is
The inception of code redundancy therefore reduces
adopted. The predictive technique is also significant when it
the rate of retransmissions to a great extent. Since, the
comes to utilization of limited available bandwidth.
patterns are unique throughout the protocol and no two
commands share a common pattern sequence, therefore on
IV. RESULTS
correct reception of at least a single pattern, we can predict
the command to which it belongs.
Although the actual intentions were to experiment out the
proposed protocol with the acoustic modems available in the
receivereply lab, it was not possible to do so due to some technical and
ACKfromAUV feasibility problems. Hence, the performance had to be
analyzed with the help of simulations carried out in
MATLAB. Since, the major aspect of the proposed protocol
is its recovery technique, therefore the evaluation of this
Get Next command No Command Yes feature can be assumed as the benchmark for the performance
Get thelast command of the protocol as a whole.
from queue Error? fromthequeue For the purpose of simulating a noisy environment,
a burst error model, as shown in Fig. 9 was constructed with
Deletethelast command the help of a MATLAB built-in function, which generates a
retransmit thesamecommand
fromthequeue randomly distributed bit error pattern.
alongwithrecent datafromAPOS

Piggybackwith
datafromAPOS

Resumeusual processof
transmission

Wait for ACK

reply

Fig. 8 retransmission of an erroneous command

This can be explained with some snippets of code Fig. 9 a burst error model showing the probability distribution of
used for implementing the predictive technique as follows: different bit errors with 6-bit error having the highest probability
mask_lop=cmd [0] & 0x0f
The error model consisted of the following bit error
mask_mop=(cmd [1]>>4) & 0x0f
probabilities:
mask_rop=cmd [1] & 0x0f
2-bit error: 0.15 probability
In the first operation, the left ordered pattern of a 4-bit error: 0.10 probability
command (represented by the cmd [] array) is being extracted 6-bit error: 0.45 probability
 8-bit error: 0.05 probability
10-bit error: 0.05 probability
16-bit error: 0.15 probability
20-bit error: 0.05 probability
6-bit error has been given the highest probability as can be
seen in Fig. 9, since a pair of 3-bit errors is sufficient to
corrupt both the original as well as the duplicate command
fields present in the same packet.
Subsequently, a simulated transmission of a set of
500 packets (each consisting of 32 bits) was carried out. Each
packet consists of 16 bits of original command field and
another 16 bits of duplicate command field. After getting
associated with the burst error model, the predictive
technique was applied at the received packet. The results
obtained can be well realized in Fig. 10.
Fig. 10 A bar graph demonstrating the number of retransmission
requests made by the simulation program
The bars as shown in Fig. 10, represent the number of cases
where retransmission is required. The thick bars represent
consecutive retransmission requests. The thin population of
bars indicates the probability of request for retransmissions is
very low. On calculating the number of such requests with
the help of the MATLAB program, the following results
were obtained:
Number of successful detections: 468
Probability of successful detection: 0.936
Number of retransmit requests: 32
Probability of request for retransmission: 0.064
The results obtained are quite convincing about the efficiency
of the predictive technique of forward error correction and
hence establishes the reliability of the proposed protocol.
V. CONCLUSION
In this paper the authors have proposed a simple and
effective sub-sea communication protocol for reliable data
transfer over an acoustic link. The salient characterizations of
the protocol have been to selectively retransmit the erroneous
field instead of the entire packet from surface-control to
AUV, and the inception of code redundancy through
introduction of unique pattern sequences for each recognized
operator’s command. Subsequent intentions are to
incorporate the protocol in action with the acoustic modems
available in the lab. Work is being further carried out to come
up with a better encoding technique for rectifying a complete
erroneous packet at the receiving side, without ever
requesting for retransmissions.
ACKNOWLEDGEMENTS
In this regard it would be significant enough to sincerely
acknowledge the tireless work of the people behind this
research work, without whose precious efforts and untiring
assistance this paper would remain incomplete. The authors
are also very grateful to the reviewers for their comments and
insight, which have significantly enhanced this paper. The
authors remain thankful to the entire Robotics and
Automation group for making it possible for this research to
happen. They would also like to thank the MOES (Ministry
of Earth Sciences, Govt. of India) for sponsoring the
concerned project, which motivated the concerned team
towards the development of this protocol.
REFERENCES
[1] Craig P. Sayers, Richard P. Paul, Louis L. Whitcomb,
Dana R. Yoerger, “Teleprogramming for Subsea
Teleoperation Using Acoustic Communication”, IEEE
JOURNAL OF OCEANIC ENGINEERING, VOL. 23, NO.
1, JANUARY 1998
[2] Ian F. Akyildiz, Dario Pompili, Tommaso Melodia,
“Underwater acoustic sensor networks: research challenges”,
Ad Hoc Networks 3 (2005) 257-279
[3] Imrich Chlamtac, Chiara Petrioli, Jason Redi, “Energy-
conserving Selective Repeat ARQ Protocols for Wireless
Data Networks”, Nineth IEEE International Symposium on
Personal, Indoor and Mobile Radio Comm. (PIMRC ’98),
Sept. 8-11, 1998
[4] James Preisig, “Acoustic Propagation Considerations for
Underwater Acoustic Communications Network
Development”, URL:
http://xy.com/index
[5] Michael Barr, “Easier said than done”,
http://www.netrino.com/Embedded-Systems/How-To/CRC-
Calculation-C-Code
[6] Andrew S. Tannenbaum, “Computer Networks 4/e”,
Prentice Hall India, ISBN: 0131629581
[7] Behrouz A. Forouzan, Sophia Chung Fegan, “Data
Communications and Networking 3/e”, McGraw-Hill
Professional, ISBN: 0072923547
[8] Xialong Yu, “Wireline Quality Underwater Wireless
Communication Using High Speed Acoustic Modems”,
http://www.link-quest.com/html/oceans2000.pdf