In a wide variety of broadband applications, there is a need to distribute information to a potentially large number of receiver sites that are widely dispersed from each other. Communication satellites are a natural technology option and are extremely well suited for carrying such services because of the inherent broadcast capability of the satellite channel. Despite the potential of satellite multicast, there exists little support for multicast services over satellite networks. Although several multicast protocols have been proposed for use over the Internet, they are not optimized for satellite networks. One of the key multicast components that is affected when satellite networks are involved in the communication is the transport layer. In this paper, we attempt to provide an overview of the design space and the ways in which the network deployment and application requirements affect the solution space for transport layer schemes in a satellite environment. We also highlight some of the issues that are critical in the development of next generation satellite multicast services.

1. Introduction

In a wide variety of broadband applications, such as software updates, distributed computing, and multimedia content distribution, there is a need to distribute information to a potentially large number of receiver sites that are widely dispersed from each other. Communication satellites are a natural option for this because of the inherent broadcast capability of the satellite channel. Also, a satellite-based infrastructure can, in many cases, be established to offer widespread service provision with greater ease and simplicity than an infrastructure based on terrestrial broadband links, when the latter is not available. Hence, while much of the broadband communication today is carried via terrestrial links, satellites will come to play a greater and more important role, especially for point-to-multipoint services.

Next-generation satellite communication systems utilizing higher frequency bands such as the Ka-band, spot-beam technology and on-board processing are currently under development。Ka-band is very desirable for satellite communication systems, because it offers abundant bandwidth. The use of spot-beam and on-board processing technologies enable the use of small, low-power, low-cost user terminals that offer two-way direct communication. These systems are likely to play an important role in the global communication infrastructure.

Despite the potential of satellite multicast, there exists little support for multicast services over satellite networks. Although several multicast protocols have been proposed for use over the Internet, they are not optimized for satellite networks. Therefore, efficient integration of next generation satellite systems and multicast services requires the study and adaptation of these protocols. One of the key multicast components that is affected when satellite networks are involved in the communication is the transport layer.

2．We consider two of the most common topologies for multicast service support involving broadband satellites

(i) Satellite networks can be deployed as a backbone for interconnection of geographically distributed high-speed local area networks (LAN). In this scenario, LAN are connected to the satellite backbone through one or more gateway nodes that have satellite uplink capability (Figure 1(a)). This network topology gives rise to a hierarchical structure: satellite and gateway nodes acting as an overlay network for the LAN(s). In general, LAN(s) may also have access to a terrestrial core network. This network architecture provides unique opportunities for multicast distribution of data. In this scenario, the forward (downlink) feed may be used to efficiently distribute content to many sites, while the terrestrial links are used for transmission of out-of-band control information, user feedback, and data retransmissions.

Figure 1. Satellite network topologies.

(a) Case I: backbone deployment. (b) Case II: direct-to-home deployment.

(ii) A direct-to-home (or direct-to-business) deployment, where the network consists of independent ground terminals with direct unit- or bi-directional connection to the satellite. In this scenario, network has a star topology and user terminals have no direct access to other networks. Ground terminals access the terrestrial core network through a gateway node located at the so-called network operations center (NOC) (Figure 1(b)). This architecture imposes additional challenges on the transport protocol, especially if reliable delivery of the data is required, because a satellite return channel is required and the transmission of user feedback, out-of-band control information, and data retransmission has to go through the satellite channel.

3. Loss detection and feedback

To provide reliability, a protocol needs to identify the packets that failed to reach a given destination. This is achieved through loss-notification (feedback) packets returned to the designated source  by the receivers. Traditionally, this feedback has been in one of the following forms:

* Positive acknowledgments (ACK): Receivers return ACK packets to the designated source, indicating which packets have been received.

* Negative acknowledgments (NACK): Receivers return NACK packets to the designated source, indicating only packets that are missing by a receiver.

* A hybrid approach (both ACK(s) and NACK(s)).

For multicast transport protocols, ACK-based loss-notification has been shown to lead to the ACK implosion problem. The problem arises when a large number of multicast receivers return an ACK packet for every packet they receive correctly, causing a serious network congestion around the links of the source. Another potential problem is that the source is required to keep track of the size, and the current state of the reporting receiver-set, in order to identify the last data packet correctly received by all receivers. In a large scale multicast application, the memory and processing load becomes prohibitive.

NACK-based feedback alleviates some of the problems. The performance comparison study presented in Reference confirms that NACK-based multicast transport protocols deliver better performance than their ACK-based counterparts in wire line terrestrial networks. In NACK-based feedback, receivers detect missing packets by checking for gaps in the packet sequence numbers and report to the designated source. The source neither needs to know the size of the receiver-set at any point in time, nor keeps track of the current state of every receiver in its group. Also, the number of NACK packets is expected to be less than that of ACK packets at low error rates. A disadvantage is that it is more difficult for the source to know when it can free the transmission buffers, since NACK packets may be lost in transmission. For a satellite multicast application, the potential problems related to loss detection and user feedback are more pronounced. Due to high error rates over the satellite links and the potentially large number of receivers, even NACK-based feedback may lead to an implosion problem. Moreover, long propagation delays make retransmission of data in response to user feedback inefficient, if not impossible. In a backbone deployment, existence of terrestrial links allows the use of supporting mechanisms such as feedback aggregation and feedback suppression, which have been primarily developed with wire line terrestrial networks in mind. In a direct-to-home deployment, however, the applicability of these algorithms is limited, so we will further elaborate in Section 3.3.

3.1 Loss reduction

A packet recovery mechanism is an essential component of a reliable transport protocol.

Automatic repeat request (ARQ) is a well-known technique for this purpose. In ARQ, sources respond to loss notification reports by retransmitting the missing packets. In a satellite multicast application, pure-ARQ for packet recovery turns out to be inefficient for several reasons. Long propagation delays associated with satellite links make the delay incurred during this repeat request process unacceptable for many delay sensitive applications (e.g. video streaming). The frequent and deep fades observed in satellite links result in high error rates and burst error patterns. Therefore, even if the feedback mechanism is efficient in returning the loss information back to the sources, in a typical wide area satellite deployment, considerable network bandwidth and processing time would be spent by retransmitting the different packets lost at different receivers. Several early papers exist on use of ARQ in satellite multicast applications

3.2 Feedback suppression and aggregation

Several existing multicast protocols adopt feedback suppression and feedback aggregation schemes to control the number and flow of feedback packets to avoid feedback implosion problem. Applicability of these methods in a satellite multicast application depends heavily on the   architecture of the deployed network.

Feedback aggregation is applicable in networks where a logical or physical hierarchy is possible. Feedback aggregation relies on intermediate entities to collect, filter-out and combine feedback information towards the source. In a backbone scenario, it is possible for intermediate LAN routers to aggregate feedback packets from receiver nodes and to report only the aggregated feedback information to the satellite gateways. Gateway nodes can further aggregate reports from several routers to pass only single feedback information back to the source.

3.3 Packet recovery

In uncials communication, feedback reports are returned to sender and retransmissions are initiated by the sender. In order to avoid feedback implosion and traffic concentration at the sender and to reduce the packet recovery latency, several multicast protocols adopt local recovery methods. Local recovery allows designated nodes to buffer data packets, and initiate retransmissions on behalf of the sender. Therefore, receivers first try to recover missing packets through these nodes. If the missing packet can not be recovered through the use of designated nodes, then the retransmission request is forwarded to the sender. In networks where a logical or physical hierarchy is possible, intermediate routers can buffer the packets forwarded through them and initiate retransmission up on receiving a request. Coupled with feedback aggregation router-assisted local recovery is shown to improve the scalability and the performance of reliable multicast protocols

Local recoveries of packets are particularly important in satellite networks because of the long propagation delays associated with satellite links. In a backbone deployment, satellite gateways are in a very good position to assist in the local recovery together with other intermediate routers. However, as it is the case with feedback aggregation, router-assisted local recovery requires support from intermediate network elements and its availability depends on existence of router extensions. A generalization of router-assisted local recovery is possible, if receiver nodes are also allowed to respond to retransmission requests. In this case, feedback packets need to be multicast to the set of receivers. However, efficient scoping of feedback and repair packets must be implemented to avoid flooding of network. In a direct-to-home deployment, all receivers receive packets directly from the satellite and there are no intermediate routers between satellite and the receivers. Therefore, it is difficult to implement local recovery for this type of networks.

4. Protocol of data communications

There is an effort in the research community to provide a ubiquitous end-to-end congestion control algorithm for hybrid satellite-terrestrial networks. This requires careful modification of the TCP protocol to match the characteristics of the satellite channels. Another approach is to split a connection at the terrestrial-satellite network interface, and to run TCP between the end nodes and the satellite network gateways, while running a customized algorithm in the satellite-only core network. The latter approach has several advantages in practice. It allows satellite provider to optimize the traffic flow inside the core network to achieve high utilization. Also, it makes it possible to push the congestion to the edges of the satellite network and let the TCP protocol’s congestion control mechanism to take care of the congestion in the terrestrial portion of the network. Inside the core network, the problem is reduced to a flow control problem rather than a congestion control problem since the satellite bandwidth is fixed and is to be shared among all the active connections. Hence, the satellite-only tier is isolated from the rest of the Internet, and flow control can be implemented by a simple window control mechanism. There is also no need to differentiate between losses due to congestion and losses due to link losses.

Isolating the satellite network from the rest of the Internet would require additional functionality at the gateway nodes. However, we believe that satellite providers would be willing to go with this design, since the implementation will allow them to have full control of the traffic flow in their networks. Adding to this the challenges of having a TCP-like behavior for multicast services, we believe that, having a customized algorithm for the satellite network has considerable advantages.

5. Conclusion

In this chapter, we have presented a taxonomy and survey of various design alternatives for supporting multicast services, and discussed how the design space of various multicast transport protocol components are constrained in the context of satellite networks. Our classification is based on the IETF building blocks for multicast transport protocols, but highlights which components of a general transport protocol are affected by the two most common satellite network deployment scenarios.

We also outlined some of the issues that are critical in the development of next generation satellite multicast services. Some of these problems, such as feedback implosion avoidance and packet level FEC coding at the transport layer, have counterparts in terrestrial networks, but they have to be addressed separately while taking into consideration the unique characteristics of satellite networks. We believe that efficient solutions to these problems and development of new technologies, such as on-board processing and buffering, would demonstrate the true value of satellite networks in the global communication infrastructure.