IP Communications Uncovered



“The Digital Ship” magazine published our article covering the technical challenges of IP communication over satellite.  Read the full article here.

Satellite IP Communications

With the launch of Inmarsat Fleet Broadband, Iridum OpenPort and a wider choice of VSAT, finally reliable IP communication is now possible at sea.

However, installing the satellite terminal has proven to be the easy part of the IP jigsaw. Figuring out how much data you are paying for, and matching your airtime bills against what your software is reporting is a difficult and sometimes impossible task.

When Inmarsat A was launched in 1975 data transfer was performed using a modem.  A modem converts the data from a computer into a series of sounds that could be transmitted over a voice circuit, in the same way a fax machine works.

When using a satellite link some of the data would be corrupted before it was received by the modem at the other end of the connection.  This corruption was generally caused by line interference which you could hear in the form of “crackles” on the line.   Another challenge was dealing with the considerable higher latency times than those found on land based networks (the time taken to send data from one end of a connection to the other).

When you sent data using a modem you had the choice of setting up an ‘error-corrected’ or a ‘non-error-corrected’ link.  The difference being what was responsible for correcting any data errors or corruption during the transmission, the software application or the modem.

‘Non-error-corrected’ links depended on software, such as the email or file transfer programs, to figure out what data had become corrupted during transmission and how to correct or resend it.  Various marine software companies came up with their own set of protocols to deal with this (some better than others) most used ‘sliding window’ techniques to deal with the latency and CRC (Cyclic Redundancy Check) for the corruption of data.  Traditional data connections sent some data and then waited until the receiving side acknowledged its receipt before sending any more, this method is a wasteful use of airtime because the connection is idle for some of the time.  CRC is a way of calculating what was received wasn’t altered during transmission.  ‘Sliding window’ is a little different as it assumes that the data reached the recipient, and continues to send data without waiting for an acknowledgement back.  It was up to the receiving end to decide if the data it had received was not corrupted and to request any missing or corrupt parts.  This meant the connection was used more efficiently and the software knew exactly how much data had been sent over the link and could provide actuate logs for billing comparisons later.

On ‘error-corrected’ links the flow of data became the responsibility of the modem.  The result was that any errors detected by the modem during data transmission were not detected by the software.  The software passes the data to the modem and as far as it was concerned the data was sent uncorrupted and in the correct order. This seldom happens when using directly connected devices via a cable, and even less so with satellite connections.

So how does all this relate to modern IP based connections like VSAT, Fleet Broadband andOpen Port?

‘Error-corrected’ links are a lot like TCP/IP connections.  TCP (Transmission Control Protocol) is a protocol suite used to control the transmission of data and forms the foundations of most of the internet today.  Think of it as the modem ‘error-corrected’ link.  The software application (like an email client) sends data to a destination; it’s up to TCP to make sure it gets there in the correct order and without corruption.

TCP is an excellent protocol hence why it’s been widely adopted.  Despite this, a software application has little control of what happens to the data once it has been passed to TCP for transmission.  Meanwhile most satellite operators bill for the data at IP level, therefore if a packet of data gets lost or becomes corrupted TCP will resend the missing data without the software knowing.  This is why you often see discrepancies between the data billed and what the software reports as the data transmitted and or received.

There is an alternative to TCP. UDP (User Datagram Protocol) is similar to a ‘non-error-corrected’ link and sends the data to the destination without asking for any acknowledgement that the data was received correctly, or if it even got there.  As the control information is not needed, UDP packets are much smaller and therefore less expensive to use when you paying for each bit sent and received.

You may question why all software isn’t written using UDP if it’s more efficient. Perhaps because you still have to guarantee all packets of data arrive at the destination in one piece and in the correct order. This means developing your own set of protocols, and depending on how good your protocol writing skills are, you may end up with something less efficient than TCP.

Add to this the additional data overhead when using VPN technology and/or encryption. Soon your 1MB of data costs you double the amount to send.

Don’t let all this put you off the idea of using IP based connections.  You just need to do a little research and testing to make the IP connection efficient as possible by selecting the right firewall, software and maybe using WAN acceleration devices, and always remember to budget for those overheads.

The new opportunities IP brings to deploy ‘office like’ applications are endless.  Remote desktop access to onboard PCs is just one of many examples of how spending a little more on satellite airtime can save lots in man hours and airfares where traditionally you might have sent someone to the vessel or have them call the sat phone for hours at a time.  Embracing this new technology can and will bring massive value and cost savings to the business.