BY LAWRENCE E. KINGSLEY

In this article:

• Introduction
• VoIP Technical Overview
• Satellite Networks Overview
• Satellite Link Characteristics
• Optimizing VoIP For Satellite Networks
• Conclusion

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 well.

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 network optimization.

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 later.

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.

Figure 3. 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.¹ 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 RFT constraints.

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:

1. 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
2. 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.

Conclusions
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 Internet access.

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 terrestrial networks.

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.

¹John Puetz, "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.