Direct Broadcast Satellite Technology

Index

  • The Special Challenges of Satellite Communications Systems
  • The Soda Hall/Hughes DBS Experimental Testbed System
  • Applications Enabled by Direct Broadcast Satellite Technology
  • Application Support Services for Satellite Overlay Networks
  • Information Combining for the Broadcast Data Channel
  • Specifications of Hughes DirecPC System
  • The Special Challenges of Satellite Communications Systems

    Satellite systems hold forth the promise of true "anywhere, anytime" access to communications, even in the most rural and remote areas of the globe. A number of world-wide satellite telephone systems have been proposed, and several are already in operation. These systems provide communications coverage over very wide areas, including over the ocean. In general, they fall into three broad classes: geosynchronous (GEO), "big" low earth orbit (LEO), and "little" LEOs.

    Geosynchronous systems, in which the satellites maintain a high orbit that keeps them over a fixed spot on the Earth's equator, have several advantages in terms of long satellite life and wide area coverage by a small number of satellites. They have the disadvantages of round trip latencies that exceed a half a second, poor coverage and inadequate elevation angles (to avoid building radio shadows in urban areas) at the high latitudes. These weaknesses are addressed by the low earth orbit systems, which follow elliptical orbits, allowing them to provide reduced delays and better coverage and elevation angles when close to their orbital perigee. However, LEOs require substantially greater numbers of satellites to provide adequate coverage, and these will need more frequent replacement.

    Geosynchronous systems include Inmarsat and OmniTRACS. The former is geared mainly for analog voice transmission (it was used by reporters to transmit from Bagdad during the Gulf War). The first generation Inmarsat-A system was designed for large (1m parabolic dish antenna) and rather expensive terminals. Newer generations of Inmarsats are incorporating digital techniques for use with smaller, less expensive terminals (i.e., the size of briefcase). The Inmarsat system uses allocations in the 6 Ghz band for the ground station to the satellite,1.5 Ghz for the satellite to terminal downlink, 1.6 Ghz for the terminal to satellite uplink, and 4 Ghz for the satellite to ground station.

    Qualcomm's OmniTRACS provides two-way communications as well as location positioning. The system operates in the 12/14 Ghz bands. The downlink data rate is between 5 Kbps and 15 Kbps while the uplink is between 55 bps and 165 bps. The system is used extensively for alphanumeric messaging and on-board sensor reading for trucking fleets.

    Little LEOs are intended to be relatively small and inexpensive satellites that provide low cost, low data rate, two-way digital communications (but not voice) and location positioning to small, handheld terminals. The frequency allocations are in the VHF band below 400 MHz. The advantage of little LEOs are their small size and relatively low costs. Systems include Leosat, Orbcomm, Starnet, and Vitasat. For example, the Orbcomm system requires 34 satellites for reliable, full world coverage, and provides 2400 bps on the uplink and 4800 bps on the downlink.

    Big LEOs are larger, more expensive satellites that provide voice communications as well as moderate to high speed data communications (56 Kbps). Proposals include Aries, Ellipso, Globalstar, Iridium, and Odyssey. Frequency allocations are above 1 GHz. For example, Motorola's Iridium system will offer worldwide cellular phone service from 66 satellites placed in 6 polar orbits.

    Unlike the proposed LEO systems, the Hughes DBS system provides several unique communications capabilities. The system is no longer proposed; it has been launched, it is in operation, and it provides coverage for most of North American. Beyond its current ability to distribute digital video, it is ripe for data communications experimentation and pilot applications development. Of the commercially available GEO systems, only DBS has the potential for multi-megabit per second transmissions, although latencies are high (i.e., greater than 500 ms for the downlink alone).

    However, the system presents considerable challenges for applications development. Unlike the other mobile satellite systems, DBS is not intended to be used as a two-way system over the satellite segment; the data communications uplink is provided though wireline networks such as the public switched telephone system (PSTN) and Internet gateways. It is not suitable for mobile wireless communications; its 18-inch satellite dish, though rapid to deploy, will not support communications to users continuously on the move. And unlike the other systems, which have moderately asymmetric satellite segment uplinks and downlinks, the DBS is a highly asymmetric communications system that spans hybrid links (i.e., satellite downlink, wired uplink).

    This makes DBS a particularly attractive technology for wide-area data distribution or asymmetric data access, in which significantly more information can profitably be broadcast on the downlink than on the uplink. Note that this characteristic is not unique to satellite systems. The Berkeley InfoPad project is building a wireless in-building system in which the downlink radios can transmit at 100 mbps while the pad's uplink radios transmit at only 2 mbps. Numerous important applications can take advantage of broadcast-based and asymmetric access. Examples of the former include distribution to a dealer network of updates to maintenance manuals or product catalogs, and the latter include World Wide Web access.

    The Soda Hall/Hughes DBS Experimental Testbed System

    In order to investigate the issues of applications support for the DBS system, we are integrating DBS capabilities into our in-building wireless access testbed. This figure shows the planned organization of the testbed. Within the Computer Science Division's new facility in Soda Hall (see figure), we have already deployed a wireless local area network using commercially available radio modems (AT&T WaveLan devices) and PC-based basestations and laptop computers running the BSDI Unix-based operating system for x86 PCs. To this we are adding a DBS satellite dish mounted on the roof of the building, and a DirectPC basestation integrated with our wireline network. This testbed allows us to experiment with the integration of high data rate downlink transmissions from the satellite with distribution through the local area wireline network and forwarding to mobile devices roaming in the wireless in-building network. Uplink traffic will be routed back through the wireless network, to the wireline infrastructure, and then through the Internet to the DBS gateway.

    At first it may appear that there is no apparent reason to combine in-building wireless access with satellite-based information distribution. However, our applications testbed depends critically on the computational and storage resources of the in-building wireline infrastructure. Applications running on the mobile devices have full access to the capabilities of building's network of workstations (NOW) processor clusters, distributed workstations, and file and tertiary storage servers. In aggregate, these represent processing resources that far exceed the capabilities of any single device. For example, this testbed configuration will allow us to experiment with using the satellite broadcast channel to aggressively prestage data for cached storage in the local environment. America On-Line, for example, maintains a cache of all of the World Wide Web pages accessed by its 1 million+ users. The size of this cache is well less than 10 GBytes today. It would not take long at 10 mbps DBS transmission speeds to distribute this vast volume of data to user sites with the capacity to store it for local high speed access. We hope to be able to understand these kinds of system-level implications of the satellite technology by integrating DBS with a rich local computing environment.

    Applications Enabled by Direct Broadcast Satellite Technology

    Before we describe our strategies for supporting applications within the DBS system, it is important to gain a better understanding of the kinds of applications that are suited to broadcast-based information dissemination. Consider the following applications scenarios, which illustrate some of the possibilities inherent in the DBS system:

    DBS systems can be installed rapidly, even in areas without a well developed communications infrastructure, although some uplink path will be needed, perhaps through the public switched telephone system. This makes DBS ideal for establishing communications in support of emergency response activities, and the system is particularly effective at distributing critical information to the field.

    DBS was developed primarily to deliver video to users. However, the ability to integrate interactive data access with simultaneous video broadcasts opens new opportunities for information dissemination combined with television. Distance learning applications that combine broadcast telelectures on DirectTV with simultaneous access to instructional materials on DirectPC is but one example.

    The final scenario shows how a broadcast channel could be efficiently structured to combine frequent and less frequent data retrieval requests.

    Application Support Services for Satellite Overlay Networks

    Given the application scenarios described above, the technical challenge is to develop and demonstrate applications building blocks from which new kinds of applications can be developed that can take advantage of the highly asymmetric environment provided by the DBS system. We believe that the elements of successful DBS applications include the abilities to (1) exploit high bandwidth downlinks, (2) take advantage of the broadcast nature of the channel, and (3) hide the considerable latencies encountered in using the system. These three issues are addressed in the following paragraphs.

    A unique aspect of the DBS system is its potential for a very high bandwidth downlink. This makes DBS particularly appropriate for disseminating massive amounts of information. One way that the system could be used is to provide a distribution for large collections of information, such as directories, catalogs, software updates, or other digital library objects that could be locally cached on subscriber systems for better low latency access.

    The downlink is broadcast-based. Many subscribers can pick packets from the broadcast data stream simultaneously. Thus a broadcast satellite is of consider value as a way to implement a "community information system." For certain kinds of frequently requested information, it should be possible to combine information requests from multiple users. In effect, we trade some latency in order to combine more common results to be broadcast to users, thus more efficiently using the broadcast channel. Furthermore, if request combining can be effectively exploited, the system would be able to support a larger user population within a given amount of available bandwidth.

    Satellite systems always face significant latencies, but these may be even larger in the DBS system because of the hybrid uplink path. Given the high downlink bandwidth, aggressive prefetching could be cheap operation, and we can trade downlink bandwidth in order to reduce the number of expensive uplink transactions. Alternately, other strategies could be pursued to trade uplink transactions for bandwidth whenever possible. For example, when fetching multiple images in an World Wide Web HTML document, these can be combined into a single multi-image fetch rather than multiple image by image fetches. This is an example of a strategy that can be of equal value in wireline, WLAN, or satellite networks: the strategy dramatically reduces the number of TCP transactions needed to fetch an image intense document, which can lead to significantly higher latencies even in networks with symmetric bandwidths.

    These and other mechanisms must be developed to demonstrate their ability to be effectively used in constructing new kinds of information dissemination applications well suited for satellite networks. We believe that these will also be of value in other wireless network environments.

    Information Combining for the Broadcast Data Channel

    In order to pull the elements of our proposed applications support mechanisms and toolkits together, we plan to implement an experimental information dissemination application for the DBS system. The figure illustrates the kind of application we have in mind. It is particularly well-suited for a broadcast-based asymmetric channel.

    Consider a system that disseminates location-oriented information on a periodic basis, such as weather reports, traffic reports, and news stories. This is appropriate for the asymmetries of the communications path because (1) a typical uplinked request for information will be considerably shorter in length than the downlinked retrieved result, (2) frequently requested information can be combined and broadcast to multiple requesters simultaneously, and (3) very commonly requested information could be automatically circulated on the broadcast channel, with subscribers filtering it to retrieve the information of interest to them. The latter strategy has the advantage of dispensing with the uplink all together. Some of these ideas have been explored in the context of high speed fiber ring networks and wireless local area networks. The latter engenders some controversy, since it costs precious battery life for a mobile device to filter for the desired broadcast data. However, it appears to be a very appealing strategy for satellite networks with non-mobile end stations, which characterizes our environment.

    The key issue is to develop algorithms to schedule the use of the broadcast channel so as to satisfy the information retrieval needs of the greatest number of subscribers in the most efficient fashion (e.g., lowest latency). However, it is intrinsic in this approach that some requesters may be forced to wait to receive answers to their individual requests while those making the same request will be serviced more rapidly. Some notion of fair access to the broadcast channel, possibly in the form of a maximum latency constraint, should be included in the scheduling algorithms.

    One idea mentioned above is to combine frequent information requests, periodically broadcast the retrieved results, thus satisfying several subscribers at the same time. Unlike transactional queries, which must be processed within a reasonably short time interval, many kinds of information requests are not strictly time-sensitive. Weather reports are just one example (i.e., a one hour old weather report is acceptable; a day old weather report is not). In effect, we trade latency to get better utilization of the broadcast channel, assuming that there is a reasonable probability that multiple subscribers are interested in the same information.

    For example, at 10 mbps, 25000 bytes of general information associated with each one of Rand McNally's 500 U. S. metropolitan trading areas could be broadcast once every 10 seconds. Even if an order of magnitude more information was to be broadcast (e.g., 10X per region or 10X number of regions or some combination thereof), the queue would completely recirculate in less than 2 minutes!

    Furthermore, weather, traffic, news or other regional information does not change that frequently (e.g., CNN is quite successful recirculating its programming once every hour). This suggests that information deltas, or "bulletins," would yield an even better utilization of the broadcast channel. Other optimizations might include scheduling delivery of information based on density of subscribers. For example, information about Los Angeles could be scheduled for broadcast more frequently than reports about Fresno (i.e., "the lowest latency for the greatest number" as a figure of merit).

    Clearly the channel scheduler can trade additional latency to free bandwidth for more individualized information requests. If a given subscriber issues a request for the current price of IBM stock, the answer is placed at the end of the queue for eventual broadcast. If many subscribers request an IBM stock quote, or the original requester is willing to pay for a priority response, the requested data can be placed earlier in the queue for a reduced response latency (a strategy to insure that requests will not become starved should also be implemented). This same mechanism can be used to obtain circulating information, like the current weather report for Fresno, more rapidly for an impatient subscriber willing to pay for a priority request.

    We are implementing a pilot "broadcast combiner" information retrieval and dissemination application based on the concepts described above for the Hughes DBS system. This application provides the proof-of-concept context in which to try out the variety of mechanisms for applications support in the satellite overlay network environment.

    Specification of Hughes DirecPC System

    For an overview of the service, see figure.

    ISA Bus Adapter Card/Receiver Kit

    The 16-bit ISA adapter card was developed to allow a personal computer to receive high speed satellite data via the DirecPC's Network Operations Center. The ISA Adapter Card provides:

    Compact, Easy-to-Install Antenna

    The DirecPC system comes with a 24 inch dish antenna (frequency range 11.7-12.2 GHz), designed for maximum performance and very compact size. It is manufactured to withstand severe weather (-40 degrees to +50 degrees celsius, 120 mph wind speeds), and can be adapted to mount in a number of situations--sloped roof, vertical wall, ground pole, and even exterior pipe.

    DirecPC's antenna can be installed quickly and easily--in less than an hour. The process involves assembling and mounting the antenna, installing the ISA adapter card, connecting the cable and antenna, and adjusting the antenna to pick up the correct satellite.


    Randy H. Katz, randy@cs.Berkeley.edu, last updated 30 April 95