IP Telephony Via Satellite: A Technology
BY LAWRENCE E. KINGSLEY
In this article:
It is no surprise that the explosive growth of the Web is driving most
media to the Internet. Almost every desktop, at work or home, is equipped
with some form of Internet Protocol (IP) connection, be it a LAN
connection, dial-up, DSL, or cable modem. Given the near-ubiquitous
presence of IP connections, it is only natural to extend the IP networks
capabilities to carry more than just the data traffic that drove its
creation. It is now common to use the Internet for interactive videoconferencing, streaming audio and video, and real-time applications
besides the usual Web surfing. In fact, the long-time staple application
of telecommunications, telephony, can now be carried over the Internet as
The lure of a one-protocol, one-cable, all-IP network has made Voice
over IP (VoIP)
very attractive. This allows complete integration of voice and data over a
common LAN infrastructure, processed by common data/VoIP routers. When IP
packets must travel between LANs over the WAN, voice and data IP packets
are treated alike and share the same WAN data transport system, which will
include satellite links for many networks. In fact, the huge demand for
Internet connectivity has resulted in a corresponding increase in IP
traffic carried via satellite. While today broadband (multi-megabit) IP
solutions dominate the VSAT (Very Small Aperture Terminal) market for data
delivery, such systems will increasingly be used to carry VoIP traffic in
addition to data. In fact, there are some distinct advantages to using
VoIP with satellite IP delivery.
What, if any, are the special issues concerning VoIP via satellite?
What must the IP via satellite network engineer do to properly groom the network to carry voice traffic with acceptable performance? This
article will discuss the various issues concerning VoIP and satellite
links. A brief review of VoIP basics will be presented, followed by a
discussion of satellite networks, networks in general, and IP telephony
over satellite in particular. Some recommendations and conclusions will be
drawn as to the proper role of VoIP in satellite networks, including
VoIP Technical Overview
Voice-over-packet systems, including VoIP, VoATM, and VoFR, are all
variations on the same theme. To start, the analog voice signal produced
by the telephone handset is converted into a digital signal by first
sampling with an analog-to-digital converter and then translating the
sampled values into digital code values. This process is called voice
"encoding" and is carried out by a CODEC (coder-decoder). The CODEC output is segmented into voice
"frames," and these frames are encapsulated into a voice packet
using a packet protocol that allows for packet addressing, sequencing, and
signaling. VoIP, VoFR, and VoATM are differentiated by packetization
efficiency, packet addressing, and by the ability of the packet protocol
to provide quality of service in the presence of congestion, erred links,
jitter and delay. These terms will reappear later in the discussion of the
nature of satellite links.
There are a number of widely used ITU G-series CODEC standards,
including G.711, G.726, G.729, and G.729a. VoIP systems typically use
G.729a. G.711 encodes voice into a 64 kbps stream and is the format used
for digital voice by the PSTN. G.729a encodes voice at 8 kbps, essentially
compressing 64 kbps voice down to 8 kbps using a CELP (Code-Excited Linear
Predictive) algorithm. While G.729a coding is efficient, the CODEC is only
one of the factors determining the overall efficiency of the VoIP packet
stream. For relatively low-speed, high-cost satellite links, efficiency is
a major concern.
In VoIP using the G.729a CODEC, a voice frame is generated every 10
msec consisting of 10 bytes of coded voice. Two voice frames (20 msec) are
placed into a VoIP packet, consisting of a header and the voice payload.
The VoIP header consists of several components: the standard IP header,
the UDP header, and the RTP (Real Time Protocol) header. The combined IP/UDP/RTP
VoIP header consists of 40 bytes, which is twice the voice payload. The
complete VoIP packet is 40 bytes header + 20 bytes voice payload = 60
bytes. The 60-byte VoIP packet must be transmitted in 20 msec, so the bit
rate for one simplex VoIP call is 24 kbps, three times the original 8 kbps
CODEC rate. Note that a 28.8 kbps dial-up IP connection is generally
considered insufficient for VoIP telephony, while the same telephone wire
connected to the dial-up modem supports traditional analog telephony,
demonstrating the large overhead of VoIP. The large VoIP header overhead,
which is the dominant element in VoIP bandwidth utilization, must be
considered when estimating required data throughput and provisioning space
segment for VoIP satellite-based networks. Some techniques to decrease the
VoIP overhead, and, thus, space segment requirements will be discussed
VoIP packets are transported over IP networks using the ITU H.323
standard, the specification for transmitting multimedia across an IP
network. H.323 is commonly implemented for IP video teleconferencing and
IP phones running on PCs, allowing IP telephony between PCs
without an actual telephone. To use a traditional phone, one must
have a VoIP access device to covert the analog voice from the phone to
digital voice and perform the VoIP packetization. The VoIP access device,
while usually a small router, may now be only a small conversion unit.
This VoIP access device, besides voice packetization, must also provide
some dial plan map. The map links dialed digits (which determine the
destination phone) from the calling phone to an IP host which is either
attached to the destination phone, or is connected to a PBX which can
switch the call to the destination phone. This dial map may reside on each
VoIP access device in the network, which is practical in small networks
where the size of the dial plan map is within reason. Alternatively, the
dial map may reside on only one IP host in the VoIP network, which is
accessed, using the IP network, by all other network IP hosts for dial
plan mapping. This is more practical for large networks, where the dial
plan map would be too extensive to program into each IP host and where
central management of the dial plan is preferred.
A generic VoIP network is shown schematically in Figure 1 below. Note
that in Figure 1 the IP network is represented only by the familiar cloud, which indicates that the actual IP transport scheme does
not impact the logical network: the call set-up and progress is
independent of the IP transport scheme. Briefly, to place a VoIP call
between two handsets connected to VoIP access devices out in the cloud
requires the originating party to first obtain the IP address of the
destination IP host from the IP host with the dial plan mapper.
In Figure 1, this device is also serving as a gateway,
providing access to a PBX in the PSTN for calls outside the VoIP network.
It is not necessary to combine the functions of gateway and dial plan
mapper, but they are often combined in the same IP host acting as an IP-PBX. After the call is
set up, voice packets will flow
between end stations. However, in some vendor solutions, the flow of voice
packets may have to go through the IP-PBX, similar to a tandem PBX call,
instead of flowing directly between end stations. Direct connection
between end stations is sometimes called "direct media
streaming." Clearly, in a satellite network, whether direct-media
streaming or tandem calling is used will have an enormous impact: A tandem call will require two satellite hops between end stations, while
direct media streaming will require mesh satellite connections between end
stations. When using IP satellite links, the IP cloud with
generic any-to-any connections must be decomposed into the individual
satellite links between end stations. Figures 2 and 3 show, respectively,
a star-topology VoIP network and a mesh-topology VoIP network using
satellite links. These figures will be referred to throughout the VoIP
satellite network discussion that follows.
Figure 1. Generic
IP telephony network.
The logical connections are shown between the network
nodes without regard to actual transport scheme.
Figure 2. Star-topology
satellite IP telephony network.
A large satellite terminal at the hub communicates with smaller remote
satellite terminals. No remote-to-remote communication is allowed.
Mesh-topology satellite IP telephony network.
All network nodes can communicate with all other nodes.
All satellite terminals are sized the same. Unlike star-topology,
remote-to-remote communication is permitted.
Satellite Networks Overview
Satellite IP networks offer some distinct advantages over terrestrial IP
networks. The greatest benefit of satellite communications in general is,
of course, distance-insensitive connectivity. This was one of the prime
drivers behind the development of satellite communications in the first
place. Satellites provide ubiquitous connectivity within the satellite
coverage footprint with every site theoretically capable of reaching all
other sites in the network regardless of the terrestrial distance between
sites. Terrestrial networks are limited to the land-bound connections
running between nodes -- reaching from one end of a large region to
another may involve crossing dozens of interconnect points. The land lines
eventually end, and IP service or any service beyond the terrestrial
infrastructure must wait for the copper line to be installed. Satellite
networks deploy quickly, requiring only a good look angle to the
satellite. This is as true today as it ever was, with the growing need to
offer broadband services beyond the industrial corridors and urban centers
also driving the development of satellite IP products.
An often-disregarded advantage of satellite networks is the delivery of
almost identical quality of service across an endless number of locations.
Terrestrial networks are a composite of sub-networks with different
topologies -- e.g., ring fiber networks with star-topology terminating
points or metropolitan networks -- and tens or hundreds of switching or
routing points in between. In the case of IP traffic over terrestrial
networks, the tens or hundreds of routing points between source and
destination often have unpredictably heavy congestion, causing a large
variability in latency. This variation in latency will lead to VoIP packet
jitter, severely degrading voice quality, and requiring large playback
buffers on VoIP equipment (termed "jitter" buffers).
Satellite networks, on the other hand, usually do not require large
jitter buffers, as the jitter is predictable. John Puetz, a satellite
consultant with Master Works Communications, published Internet Protocol
latency measurements to ten major international cities.1
His measurements show very large and unpredictable latency variances over
terrestrial facilities from NYC to many major international locations --
0.5s to 2.0s to Brazilia and 0.7s to 3.3s to Mexico City, for example.
Terrestrial network links, although very low in bit errors, do not
necessarily have less delay than satellite links and cannot guarantee the
homogeneous quality of service that satellite networks can.
Satellite networks fall into two broad categories: star-topology
networks and mesh-topology networks. Star networks (also called hub-spoke
networks) are networks in which all remote nodes "talk" only to
one central hub terminal. Mesh networks are just the opposite -- any site
may talk to any other site. Most satellite IP delivery systems are star
topology, although mesh IP satellite systems are also available. Note that
mesh-capable networks can support logical star configurations by default.
It is quite logical to assume that satellite mesh IP networks are the
best choice, offering the most flexibility and connection possibilities.
However, the trend in satellite IP delivery systems is largely toward
broadband star networks, with a large outbound IP stream from the hub
(multi-Mbps) and small return channels from each remote (~100 kbps). With
a star-based system, it is possible to use one large RFT (Radio Frequency
Terminal) at the hub station and relatively small RFTs at the remotes,
significantly reducing the cost of the remotes, which is important where a
large number of remotes are involved. By contrast, in a mesh network, all
terminals are peers, and the RFT size is relatively large and, thus, the
RFTs are more costly. Considering this, satellite mesh IP networks are
applicable only for customers who must have any-to-any connectivity,
typically private corporate networks. Note that mesh satellite networks
have relatively low-speed (< 1 Mbps) inter-site link speeds due to the
Clearly, a star network will never have direct remote-to-remote media
streaming and remote-to-remote calls are also not possible. However, a
star network is ideal for remote sites to call back to a central office
extension or for PSTN access. Mesh networks allow any site to call any
site provided the gateway equipment supports direct media streaming, or if
each VoIP access device directly routes its own VoIP traffic.
Customer requirements seldom fit a single solution -- particularly
corporate users. Satellite networks allows users to fit a solution to
their real requirements, even if those requirements change over time.
Satellite Link Characteristics
Most VoIP networks tend to be purely terrestrial, with all connections
carried by land-based copper, fiber, or microwave connections. Terrestrial
connections are characterized, in general, by low errors, low packet
transport delay (tens of milliseconds), high-speed (T1 and up), and for
dedicated lines, consistency of delay and error rate. Satellite links, on
the other hand, are exactly the opposite, with long delays, variable
errors, and often sub-Mbps speed.
Satellite networks that use a geo-stationary satellite -- one with an
orbital location that appears stationary to the earth -- have a round-trip
path delay in the order of 270 ms. This delay affects the transmission of
voice in two ways:
- Speaker turn-around response time (or latency) reaches the
threshold where it becomes perceptible to the trained ear, particularly
if it approaches 400 msec; and
- Echo of the audio signal caused by an impedance mismatch at the
terminating phone becomes detectable unless it is somehow controlled.
(Echo is also present in the public switched telephone network, but not
normally perceived over short distances.)
The speaker turn-around response time is an important issue, because
users expect only a short delay before the person at the far-end answers.
Users will perceive a lower quality of service if delay is excessive or if
delay is variable. On the other hand, the proper use of echo cancellation
reduces the problem of echo to an imperceptible level, making the second
disadvantage outlined above a non-issue.
The satellite link is affected by sources of interference and signal
power variations that manifest as errors in the transmitted information,
or as occasional loss of signal or fading. Satellite transmission of
data normally exhibits a higher error rate than terrestrial transmission
systems such as fiber. However, the use of high-gain forward error
correction (FEC) coding algorithms can minimize this disadvantage, making
it possible to design "fiber-like" satellite links. Of course,
the penalty for using high-gain FEC is the loss of capacity used to
transmit the encoding information bits. On the other hand, the loss of
signal or fading results in loss of availability. In practice, it is a
matter of properly defining the availability requirements and designing
the link accordingly.
Optimizing VoIP For Satellite Networks
IP telephony network engineers must take into account the nature of
satellite networks to successfully deploy voice applications. Some features of
VoIP can be optimized for satellite networks. First, physics sets the
minimum one-way packet transit delay for a satellite link at about 270
msec. Since 400 msec one-way is about the maximum acceptable delay for a
satellite phone call, extra effort must be made to avoid additional
handling delay introduced by the IP telephony equipment.
One source of handling delay is the digitization delay of the CODEC.
For G.729a, CODEC-induced delay is 15 msec. Another source of handling
delay is the packetization delay. Since two 10-msec voice frames are sent
for each VoIP packet (default), the time it takes to generate a VoIP
packet is at least 20 msec. A third source of handling delay is the queue
processing time in the VoIP access device or router, which can be
variable, but is usually less than 10 msec, excluding congestion.
The total of these VoIP handling delays can easily introduce 45 msec
delay processing time at each end of the link, bringing the total one-way
delay to 270 + 45 + 45 = 360 msecs. With this slim margin, any additional delay must be
avoided. Output queuing delay must be minimized using a
priority queuing scheme for voice, available on vendor equipment under
such names as IP precedence and real-time priority.
Minimizing the handling delay is difficult, as most techniques to
minimize delay increase the already large inefficiency of VoIP. Actually,
the converse is also true -- attempts to improve efficiency may increase
delay. Efficiency is improved by sending more voice frames per VoIP
packet, reducing relative overhead due to header. Sending five G.729a
voice frames per VoIP packet reduces per call bit rate from 24 kbps to
14.4 kbps, however this increases packetization delay from 20 msec to 50
msecs and voice quality suffers.
The large VoIP header overhead can be reduced significantly for some
links. Header compression (sometimes called cRTP) can reduce the IP/UDP/RTP
header from 40 bytes to 2-4 bytes. G.729a per call bit rate is reduced to
< 10 kbps. cRTP can only be used on point-to-point links, as the VoIP
packet is no longer routable, and each end of the link must implement
cRTP to compress/decompress the packet.
Broadband Internet Protocol requirements have given the satellite industry
a new life. Although the catalyst for this renewal is the growth in the
Internet, satellite solutions must also support telephony requirements.
This is particularly true in developing regions, where delivery of
dial tone for voice services will not be supplied by an alternate public
switched voice network. Such satellite networks may also address the basic
communications requirement of telephony, and not just the desire for
IP telephony can be a practical and cost
efficient voice solution when implemented in a broadband IP network with
appropriate optimization. This optimization includes delay management and
efficiency improvement, including use of cRTP and IP QoS schemes to
prioritize voice traffic. IP
telephony over satellite offers better quality than terrestrial VoIP over
the public Internet because of end-to-end control of link
quality, and very minimal delay variation as compared with
It is advisable to limit IP telephony solutions to PSTN access and
corporate networks where the star satellite network topology is
appropriate and RFT costs are relatively low. Adding IP telephony
services to star-based Internet access is an ideal combination. Mesh voice
requirements, often required of corporate networks, can be filled with IP
telephony only if the satellite network offers mesh connectivity, avoiding
a double-hop delay. In high-end, mesh corporate networks, integrating IP
telephony and IP data services with a mesh satellite IP network is, again,
an ideal combination. It is in the integration of VoIP with other IP data
services that IP telephony will realize its potential.
"Integration of Satellite and Terrestrial." Satellite
Communications, November 1999, p. 27.
Lawrence E. Kingsley is manager of Applications Engineering for Lockheed
Martin Global Telecommunications (LMGT) Products. LMGT, a wholly owned
subsidiary of Lockheed Martin Corporation, is a global provider of network
services and advanced technology solutions to enterprise customers. LMGT
is headquartered in Bethesda, Maryland and includes the satellite, network
and product assets of the former COMSAT Corporation and the Integrated
Business Solutions unit of Lockheed Martin.