Supporting group applications via satellite constellations with multicast

Construction of low-earth-orbiting satellite constellations for global wireless communication to small user terminals has begun with the launch of a number of Motorola's Iridium satellites in 1997 and the building of a number of Qualcomm's Globalstar satellites for launch in 1998. These early constellations, and their competitors, aim to provide low-bandwidth satellite telephony world-wide, including paging, faxing and 2400bps modem services.

Future satellite constellations have been proposed for high-bandwidth wireless data transmission. These include Teledesic (1), Alcatel's SkyBridge, formerly known as Sativod (2), and Motorola's Celestri, whose components were formerly known as M-Star and Millennium (3).

In providing data networking services, the ability to internetwork with pre-existing ground networks will be an important requirement for these constellations.

Proponents of these schemes have stressed their advantages over existing geostationary satellite networking solutions of higher overall capacity, due to frequency reuse, and of decreased latency in communication due to the decrease in propagation delay in going from high-altitude geostationary orbit (GEO) to low-altitude low earth orbit (LEO).

However, support for low-latency group applications, such as multiparty videoconferencing, is problematical. Here, the networking aspects of the broadband satellite constellations are discussed, and the suitability of the constellations for multicast is assessed.

1.0 Data constellation overview

1.1 Teledesic

Each Teledesic satellite has eight intersatellite links, in the 60GHz band, to its two nearest neighbours in each of the four cardinal directions, forming a complex cylindrical mesh network, a topology described as 'geodesic'. Constellation topology is discussed in more detail in (4).

a. Original design

b. 288-satellite redesign

Figure 1 - Teledesic satellites and ground coverage rendered by SaVi (5)

Ka-band frequencies were allocated to Teledesic at the 1995 World Radio Conference (WRC), and the US Federal Communications Commission (FCC) granted a licence in March 1997. Construction has not yet begun, but service is scheduled to begin in 2002.

1.2 SkyBridge

SkyBridge is intended to share Ku-band with existing GEO satellites. It uses two overlapping offset constellations of 32 satellites each (each being four planes of eight active satellites per plane, all at an altitude of 1457km) to give a choice of satellites to ground stations. For each satellite pair, the satellite furthest from the centre of a GEO footprint that satellite footprints overlap with is used for minimum interference with the GEO satellite.

SkyBridge does not use intersatellite links. Its satellites are planned to act as in-orbit 'bent-pipe' transponders, or amplifying repeaters, forwarding traffic to local gateways. This can therefore be thought of as a ground network with a space-based component, rather than as a space-based network, as all the switching fabric is ground-based.

User terminals offer data rates from 16kbps to over 60Mbps, in increments of 16kbps, using an ATM cell-switching interface.

Figure 2 - SkyBridge satellites and ground coverage rendered by SaVi (5)

1.3 Celestri

Celestri combines a LEO constellation (formerly developed at Motorola under the name M-Star) with a GEO constellation (developed under the name Millennium). The LEO constellation has nine planes, each containing seven active satellites and one spare, at an altitude of 1400km.

Each satellite has six optical intersatellite links, forming a toroidal mesh network around the Earth, and an onboard ATM switch with throughput of 17.5Gbps.

Communication rates to terminals are either from 64kbps to 2Mbps in increments of 64kbps, or at the fixed rates of 10Mbps, 16Mbps, 51Mbps (OC-1) or 155Mbps (OC-3). Protocol adapters for transparently carrying various network protocols over the Celestri network are to be included in terminals, presumably to tunnel these protocols over the underlying ATM infrastructure.

Figure 3 - Celestri LEO satellites and ground coverage rendered by SaVi (5)

2.0 Multicast

2.1 What is multicast?

Multicast allows a source to simultaneously send data to all users on the internetwork interested in receiving the data, but in a more efficient manner than simply flooding the entire internetwork with unnecessary broadcast packets.

The set of all interested hosts forms a multicast group, and group management is an internetwork function. Users not in the group do not see the data (perhaps because there is no need for the data to be sent across their network) or, if they do see it, discard it.

To communicate the data efficiently to all users in the group, the internetwork must set up a spanning tree, along which the messages can be sent and replicated at tree branches.

2.2 Multicast in existing network stacks

These protocols can be split into two main groups, according to the assumptions that they make about group distribution and network traffic.

Dense-mode multicast protocols assume that multicast group members are densely distributed throughout the internetwork, i.e. that many subnetworks contain at least one group member, and that internetwork capacity is plentiful. These are data-driven, in that construction of the multicast tree begins top-down from the source outward, and data on the state of the tree is propagated to all routers. The multicast trees constructed allow data to travel in one direction, from source to group, emulating broadcast.

For full group-to-group communication, a multicast tree must be set up from every user; this scales badly for large groups and imposes joining and leaving overhead and delays. DVMRP and MOSPF are dense-mode.

Sparse-mode multicast protocols assume that group members are sparsely distributed and that capacity is constrained. In sparse mode, the multicast tree is receiver-initiated, i.e. a router only becomes involved in the construction of a multicast distribution tree only when one of the hosts on its subnet requests membership. Core-Based Trees (CBT), with a single central router from which the tree branches out in all directions, have been suggested for groups where there are many active senders within the group, allowing multi-way communication over a single tree (9). This effectively minimises the amount of multicast state routing information that needs to be stored and the number of routers involved. This single-tree approach differs from the (source, group) pairings of DVRMP and MOSPF, and scales better for large networks, with minimal joining and leaving overheads. Protocol-Independent Multicast - Sparse Mode (PIM-SM) constructs a multicast tree around a chosen router, called a rendezvous point, similar to the core in CBT (10).

Given the constraints of a satellite constellation network with intersatellite links, a sparse-mode multicast protocol would appear to make best use of limited, expensive, capacity. However, as the satellites move in their orbits it would become necessary to periodically move the core of the tree, and this would also require support for native multicast routing in the satellite on-board switches.

As we saw in section 1.0, proposed commercial satellite constellations intend to implement ATM-based networks. With its circuit-switching focus, ATM did not originally have the concept of multicast, and the closest it came to multicast was the concept of a multicast server, where virtual circuits from all receivers would connect to a single source. This scales extremely badly in large networks with many users, as the links adjacent to the server soon run out of capacity and available Virtual Path Identifiers (VPIs) to allocate to connections.

Work is now taking place to add multicast support to ATM, e.g. SEAM, which uses a single core-based tree and combines ATM Virtual Circuits to minimise VC switching overhead (11). However, IP multicast is a considerably more mature area. It is likely that much of the traffic over ATM networks, including satellite ATM networks, will be generated by applications using IP, and tunnelled through ATM.

2.3 Internetworking with multicast

This is the strategy adopted by the MBone, or Multicast Backbone, where isolated IP-multicast-aware networks are internetworked together across multicast-unaware networks by tunnelling IP multicast messages through ATM circuits between the multicast islands. This forms a virtual network layered on top of the physical network.

However, tunnelling gives a false picture of the latency of a connection as measured by a time-to-live (TTL) or hop counter, since the header containing the count value is encapsulated and is not decremented in the tunnel, no matter how long the tunnel is. All tunnels appear the same length to the packets being tunnelled through them.

Tunnelling does not make optimal use of the intervening network. The tunnel must often be set up manually, and the tunnel endpoints cannot be moved easily.

Adapting the TCP/IP and ATM network stacks to each other to increase throughput when IP is layered over ATM has been an area of considerable interest for some time, and adaptations such as TCP Boston, where the implementations of both protocols are modified slightly in order to increase tunnelling performance, are starting to appear. (12)

As an extension of this, protocol federation of ATM multicast protocols with IP multicast protocols is one possible, albeit highly unlikely, solution to allow true IP/ATM internetwork multicasting.

2.4 Multicast over satellite

Satellite-based videoconferencing could be accomplished by tunnelling the IP-multicast messages through the satellite gateways, but this would require the setting up of multiple tunnelled virtual circuits between geographically-separate users, making group management difficult and using more satellite capacity than would be necessary if the satellites' on-board switches were to support IP multicast directly. None of the proposed commercial schemes do this.

SkyBridge treats each of its satellites as a simple transparent repeater, resulting in each satellite connection acting as a simple short one-hop ATM tunnel that is transparent to IP multicast, and the problem of internetwork multicast is moved away from the satellites into the ground networks that are utilising SkyBridge satellites for connectivity.

Celestri is effectively a standalone ATM network utilising ATM switching in the ground/air interface and between satellites. Tunnelling of IP multicast packets over a changing-geometry ATM switching fabric will not permit multicasting within the constellation. The inclusion of a complementary GEO component in Celestri for broadcast applications appears to tacitly acknowledge and attempt to side-step the networking limitations of the LEO component. However, the increase in propagation delay for the GEO component is offset by the decrease in the amount of switching required.

Teledesic utilises a purpose-designed 512-bit fixed-length packet, and is likely to encapsulate or tunnel even ATM across its network. This protocol tunnelling across the Teledesic geodesic mesh is likely to make implementation of IP multicast within the constellation network impossible.

3.0 Conclusions

Leaving implementation of multicast solely to the IP-routing ground networks, rather than making it a problem for both ground and mesh satellite networks, would appear to make the problem of implementing efficient internetwork multicast with a satellite component more tractable.

SkyBridge can be considered the least ambitious of the proposed schemes when viewed from a satellite networking viewpoint, as the satellites are simple transponders rather than complex routing switches with intersatellite links. However, by being the most transparent from a tunnelling viewpoint SkyBridge paradoxically appears to offer the most at present for the implementation of IP multicast applications - at least until the appearance of native IP multicast routing onboard satellites.

4.0 References

12. Bestavros, A. and Kim, G., "TCP Boston: a fragmentation-tolerant TCP protocol for ATM networks", Proceedings of Infocom '97.