Satellite Communications

Why is satellite latency so high? (and it’s not all to do with distance)

This blog is Part 1 of a 3-part blog and concentrates on high latency, the subsequent parts will discuss jitter, the effect of atmospheric conditions and choice of wavebands.

If we want to our applications to be available globally we have to bear in mind that there are lots of places on the Earth where wired and mobile (or other wireless communications) are not available, for example:

– In remote places (some less remote than you might think!) 
– On aircraft flying over oceans or remote locations
– On ships distant from the shore
– In certain military situations
– Certain emergency services requirements, i.e. first responder

Just about the only reasonable way to serve these locations is to use satellite communications, provided you have a view of the sky that is. Due to their height satellites have a very large coverage (up to slightly less that 50% of the Earth’s surface you might think, but more on that in a moment).

It sounds fantastic.  Why do we bother with any other kind of communication system then, after all most of us could mount a satellite antenna on outside of our offices, houses etc.?  The answers are both technical and commercial:

– Satellite bandwidth has traditionally been very expensive
– Until recently satellite bandwidth has been very limited (128Kbps, 256Kbps)
– Satellites traditionally added a large amount of latency (delay) to network traffic
– Jitter is created which can affect streaming applications e.g. voice, video, rapid telemetry
– Adverse weather can cause large or almost complete data loss

But that was then.  Things are changing:

– Bandwidth is becoming more available and less expensive, though still pricey compared to wired and mobile
– Lower satellite orbits are becoming available, which reduce latency
– There is an increased choice of wavebands which have better penetration of the atmosphere and rain

The technical factors “stress” applications in ways not encountered with other networks and if we want our applications to work we will need to test them in satellite networks and employ programming strategies which work around those stresses.

In this blog I’m going to focus on high satellite latency and its implication on applications.  Look out for further blogs on jitter, the effect of atmospheric conditions and choice of wavebands.

Why is satellite latency high?

Anyone who has used the ping utility tool will have seen some very high ping times at times. For example, to many points opposite you on the Earth (antipodean) you may see ping times via undersea cable routes of 300ms, but you can see big ping times even to nearer locations – this is due to queuing i.e. the links are busy and your data has to queue which causes delay.

A satellite ping time might be 700ms or more and that’s nothing to do with queuing.  Why’s that?
Because the satellite is very high indeed.  Traditional Geosynchronous (aka Geostationary or simply GEO) satellites sit 22,236 miles (35,786 Km) above sea level, which is a very long way away, in fact almost 3 Earth diameters (just under 1 circumference) away.  No wonder it takes so long to ping to the other side: your ping and the response has to go up and down to the satellite 4 times since you’re not, in general, directly under the satellite.

Simple solution, make them lower, yes indeed and that has been thought of.  There are offerings for LEO (Low Earth Orbit and MEO (Medium Earth Orbit) but they have a problem.  At anything but the GEO orbit level the satellite cannot maintain position in one spot over the Earth without needing to be driven all the time (which is impracticable), so at the lower orbits the satellite are moving, relative to the Earth’s surface, sometimes very quickly.  Not so convenient for fixing on them, then.

Lastly to get round the back of the Earth will take more than one hop and that implies even more latency.

So how does this high latency impact your application?

Over a GEO satellite any chatty application will have to wait for a response from the server side (or client depending on the direction) which will take 700ms to perform.  

Compare that to LANs (Local Area Networks) with 1-3ms response times and WANs (Wide Area Networks) with 10-300ms delays – depending on end point locations with mobile and wireless networks adding somewhat to this. It’s clear that after a few round trip conversations an application may be intolerably slow or even timeout, compared to functioning well in wired or wireless networks.

And how can you fix satellite high latency issues with applications?

Clearly you can’t just move the satellite!  Though, there are lower orbit satellite options available that may work for you both in terms of service provided and budget.

If you need to work with the satellite as it is, then changing the way your software communicates offers the best solution:

– Change timeout values on network requests to allow for higher latencies
– Use overlapping network requests and responses where possible –  instead of waiting for something to complete before requesting the next thing
– Caching more data where possible means you don’t need the network all the time

Sometimes you can use other software or equipment solutions to help you out, but they can be expensive. For example, if fundamentally, you have a data transfer issue i.e. the latency prevents you from using up the bandwidth available to you in the service, then, if you use standard transfer methods (ftp, Microsoft CIFS or your custom application that uses TCP to transfer blocks of data etc.) you can get equipment and/or software that may cache on your behalf and/or acknowledge receipt of data locally to the transmitter thus avoiding the latency.  These are termed WAN optimisation solutions, but they don’t work in all cases, they can be expensive and they, themselves can cause issues.

But how do you know whether you have any issues with your application in satellite networks at all

Dirty word coming here: You need to “Test”

That may not be as formal as it sounds: we could say you need to try the application in the satellite network.  There are issues with testing or trying using actual (real) satellite networks though:

– Satellite time is expensive and the equipment may not be easy to deploy
– It will be just about impossible to mimic your or your customers’ real locations
– If you find an issue which needs attention, getting it to the developers for a solution will be difficult (and if the developers say they’ve sorted it out it is likely to be very difficult to retest)
– You won’t be able to try out other satellite environments e.g. MEO or LEO without purchasing them
– You won’t be able to have a rainstorm appear just when you need it during your testing

Using Satellite Network Emulators

Because of the issues of “real network testing” in Satellite networks  we’ve brought Satellite Network Emulation capabilities to our NE-ONE and INE Network Emulators.

People think of anything with the name Emulator in it as some sort of complex mathematical device which predicts behaviours.  They may be complex, but only internally. Externally, we make them very straightforward.  And, they don’t predict behaviour, you get to actually try out (“test”) your application using your real clients and servers just as though they were in the satellite network.