From the various experiences all have had with landline Internet connections, a general understanding is that a satellite Internet connection is performance limited to a given bandwidth.
The following chart offers examples of bandwidths that are offered by Inmarsat:
The total satellite communication channel bandwidth is shared with other users in order to maximize frequency spectrum utilization. As a consequence, each user’s terminal is at a particular time only allocated the bandwidth actually in use.
If there is no transmission, no bandwidth is allocated, and the terminal needs to resort to random-access bursts in order to send requests for bandwidth to the ground Earth station. Other users in the same channel for the bandwidth must also be managed.
If the total demand is greater than the capacity, the users obtain only their share of the available bandwidth. This is all done to use resources efficiently and to provide the best service at the lowest cost. The ground Earth station makes the decisions about bandwidth allocation, with forward link capacity divided between the terminals that have data actually being sent to them.
Return link capacity is divided between the terminals that have data to send. In order to get information about which terminals have data to send, the terminals must first request bandwidth by sending a random access burst, which indicates the need for bandwidth capacity.
Due to the long path delay between the ground to the satellite in geostationary orbit and back to the ground, at least around 500 milliseconds are required before bandwidth becomes available.
This bandwidth scheduling mechanism has several effects. Ramping up to the bandwidth that can actually be obtained and utilized requires time—if bandwidth is available, and there is a lot of data to send, the bandwidth which meets the demand will require round-trip times of around 500 ms. In many situations, longer time periods may be required.
Many applications use TCP as their transport protocol in order to deliver data reliably between hosts. TCP is designed to adapt automatically to available bandwidth, but the design of TCP is conservative and will adapt slowly due to the high latencies.
TCP will cautiously send a little bit of data, wait for acknowledgement, then send a little bit more data. This will require several round trip times to ramp up to full bandwidth—meanwhile, data will sit in the queue in the terminal, awaiting transmission.
In some cases, the extra delays induced by the satellite communication protocol will cause TCP to believe that packets have been lost, even though they may still remain in the queue. This has two effects; TCP will reduce the data throughput, and reduce user demand and bandwidth, and will retransmit the packet, which wastes bandwidth.
TCP is typically affected by highly variable latency and bandwidth. TCP’s internal algorithms can, themselves, exacerbate the problems and cause reduced performance because of the underutilization of the
available bandwidth.
Other TCP features include early retransmission of lost packets that can be incorrectly triggered due to buffering and high latencies. Packets may be retransmitted while they are still waiting in a queue somewhere, resulting in wasted bandwidth.
Whenever TCP believes a packet has been lost, the belief will be that this loss is due to congestion and throughput will be reduced. If the packets are not really lost, but just slow to be acknowledged, TCP will fail to use the bandwidth that is available.
These effects and others can decrease performance for end-user applications. TCP-based applications may be challenged to achieve optimal performance, suffer long delays and timeouts.
UDP based applications, such as a VOIP service, may experience highly variable delays, resulting in poor audio and long delays. Ensure a positive end-user experience by verifying that the application can adapt to the varying satellite link conditions and produce meaningful feedback, regardless of the circumstances, to the user.
What does shared bandwidth mean?
1. You are only allocated the bandwidth you can use
2. If terminal is not transmitting, it’s bandwidth is 0 Kbit/sec
3. You are contending with other users for the available bandwidth
How does it work?
1. The Ground Station decides; terminal has to ‘ask’ for allocations
2. Allocation latency is at least one round-trip time (480 ms)
Effects
1. Ramping up bandwidth takes time
2. Extra delays when bandwidth doesn’t meet the demand
3. Buffering causes extra delays
4. TCP performance is affected
Validating Application Performance
Ensuring an applications good performance in the face of these challenges requires careful testing. Network conditions on the BGAN system will vary over time. Depending on the current congestion, contend for bandwidth with many other users or capture all of the bandwidth. Testing or demonstrating solutions on the live network also involves airtime costs and the logistical issues of setting up terminal, antenna, and test equipment for the test that is to be performed.
Testing with a network emulator, such as the GateHouse BGAN Application Tester, provides complete control over the test and demonstration conditions. The BGAN Application Tester is a full implementation of the BGAN protocol, which accurately implements all the scheduling mechanisms of the BGAN system, giving a truthful representation of the live system. The tester is used with an actual, normally operating, physical BGAN terminal, just as would occur on the BGAN system, and the terminal operates normally without being aware that a simulated system is the actual operating environment. The BGAN Application Tester can be configured to apply traffic congestion according to an individual’s test requirements, which greatly increases the number of possible test scenarios and boosts the
test coverage.
gatehouse.dk/
Lars Christensen, M.Sc.C.S, is an experienced BGAN engineer and Chief Architect at GateHouse Telecom A/S. Lars’ main areas of expertise are system architecture, computer system design and development, particularly within computer networking, including TCP/IP, satellite communications (Inmarsat BGAN) and UMTS.
GateHouse Telecom A/S is a wholly owned subsidiary of the GateHouse Holding Group. For more than a decade, it has provided the satellite communications industry with a range of market-leading software products for commercial, government and military use. With deep knowledge and understanding of global communications infrastructures and platforms, GateHouse Telecom also offers consultancy services for software, hardware and system integration as well as for the preparation and evaluation of international tenders.
