INNOVATIVE NETWORKING CONCEPTS TESTED ON THE ADVANCED COMMUNICATIONS TECHNOLOGY SATELLITE

INTERNATIONAL JOURNAL OF SATELLITE COMMUNICATIONS, VOL. 14. 201-217 ( 1996)

INNOVATIVE NETWORKING CONCEPTS TESTED ON THE ADVANCED COMMUNICATIONS TECHNOLOGY

SATELLITE DANIEL FRIEDMAN, SONJAI GUF'TA, CHUANGUO ZHANG A N D ANTHONY EPHREMIDES

Center for Satellite and Hybrid Communication Networks, Institute for Systems Research, University of Maryland, College Park, MD 20742, U.S.A.

SUMMARY

This paper describes a program of experiments conducted over the advanced communications technology satellite (ACTS) and the associated Tl-VSAT (very small aperture terminal). The experiments were motivated by the commercial potential of low-cost receive-only satellite terminals that can operate in a hybrid network environment, and by the desire to demonstrate frame relay technology over satellite networks. The first experiment tested highly adaptive methods of satellite bandwidth allocation in an integrated voice-data service environment. The second involved comparison of forward error correction (FEC) and automatic-repeat-request (ARQ) methods of error control for satellite communication with emphasis on the advantage that a hybrid architecture provides, especially in the case of multicasts. Finally, the third experiment demonstrated hybrid access to databases and compared the performance of internetworking protocols for interconnecting local area networks (LANs) via satellite. A custom unit termed frame relay access switch (FRACS) was developed by COMSAT Laboratories for these experiments; the preparation and conduct of these experiments involved a total of 20 people from the University of Maryland, the University of Colorado and COMSAT Laboratories, from late 1992 until 1995.

INTRODUCTION

The Center for Satellite and Hybrid Communication Networks (CSHCN) at the University of Maryland was founded to explore and develop the commercial possibilities of satellite and combined satellite/terrestrial communication technologies. In many communication applications there is a need to transmit much information primarily in one direction between two points and much less information in the opposite direction. This is typically the case in file transfer and database services. While a two-way satellite channel may be used for such asymmetric applications, it is also possible to support them by means of a combination of a one-way satellite channel for the bulk information transfer and a parallel terrestrial channel for the low-bandwidth portion of the application traffic. In such a hybrid network- with parallel satellite and terrestrial channels-the satellite terminal need not have transmit capability, and thus it can be a much less expensive receive- only terminal. In addition to a cost savings, it is possible that improvement in network performance may also be achieved because the terrestrially carried traffic does not suffer the high propagation delay incurred through satellite links.

These advantages of hybrid networks, coupled with the availability of low-cost, receive-only satellite terminals, suggest commercial potential for hybrid networks. To develop this potential, the CSHCN proposed, in 1992, a series of experiments

in hybrid local area network (LAN) interconnection. The scope of the experiments was later expanded to include other facets of hybrid networking, and three experiments were ultimately devised. The first examined the dynamic allocation of satellite bandwidth in response to variations in the amount of traffic to be sent through the satellite. The second experiment investigated error-control schemes for use both in point-to-point and in point-to-multipoint hybrid networks. Finally, the third experiment considered using a hybrid network architecture for remote multimedia database access, and also compared the performance of some networking protocols in LAN interconnection.

These experiments, described below, were actually conducted in 1994 and 1995 using NASA's advanced communications technology satellite (ACTS) and the associated T1 -VSAT (very small aperture terminal). The satellite link was comp- lemented by a terrestrial link, either in the form of a dial-up telephone link or the Internet, to compose a hybrid network.

Frame relay was used over the satellite link, using a prototype frame relay access switch (FRACS) developed for the CSHCN by COMSAT Labora- tories. Although frame relay has been used over terrestrial networks, this was the first instance of its use over a satellite link. One of the experiments described below compared the performance of frame relay with that of the more traditional X.25 protocol.

All the experiments were based on a two-node

CCC 0737-2884/96/030201- 17 0 1996 by John Wiley & Sons, Ltd.

Received January 1996

202 D. FRIEDMAN ET AL.

satellite network configuration shown in Figure 1. One node was at the University of Maryland at College Park, and the other was at the University of Colorado at Boulder. The experiment equipment configuration at Maryland consisted of two Sun workstations connected through high-speed serial interfaces to the FRACS, which was in turn connected to the ACTS Tl-VSAT. The FRACS-to-VSAT connection consisted of a T1 connection for traffic, and an RS-232 connection for control messages (such as call setup and bandwidth allocation commands). The workstations ran CSHCN- developed software to implement the bandwidth allocation algorithm, the error-control schemes and the multimedia database server. SunLink frame relay software was used for the frame relay connections between the workstations and the FRACS.

A similar arrangement was used at the University of Colorado, except for an important difference. The Colorado T1 -VSAT was not co-located with the FRACS but was instead on the premises of the National Telecommunications and Information Administration (NTIA), also in Boulder. An optical link was used for the T1 traffic connection between the University of Colorado and NTIA sites, and a modem link was used for the FRACS control messages.

The experiments were motivated by the availability and potential commercial uses of low-cost, receive-only satellite terminals, as mentioned earlier. However, the scope of the experiments was expanded to include many more facets of hybrid

network operation. They were designed to support investigations into the network management chal- lenges that will confront future commercial and military network service providers, as they try to meet market demands and mission requirements for multimedia network services.

EXPERIMENT 1 : DYNAMIC BANDWIDTH ALLOCATION

The purpose of the first experiment was to find effective methods to adapt the link bandwidth rap- idly to fluctuating traffic levels, both for data traffic and for mixed-media traffic such as packetized voice and data. This adjustment of bandwidth was accomplished using a feature of the ACTS system, the ability to establish circuits of different band- widths, in multiples of 64 kb/s channels. The ration- ale behind the experiment is to request, and use, the minimum necessary amount of bandwidth that will permit the achievement of satisfactory performance levels, and release it when not needed. Because the performance criteria are several and are antagon- istic to each other, there is a need for fine-tuned trade-offs among them.

The bandwidth allocation algorithms investigated for data traffic were a rate-based algorithm implemented in the FRACS and a threshold-based algorithm of our own design. For mixed-media (voice and data), an algorithm that generalizes the concept of thresholds and is based on so-called switch functions was tested, both for a single station

Figure 1. Configuration for ACTS experiments

INNOVATIVE NETWORKING CONCEPTS 203

and in a setting of two stations competing for bandwidth. The FRACS was used to signal the ACTS system for requesting or releasing channels either according to its own algorithm, or upon instruction by our experiment software, for our algorithms.

The general experiment configuration is shown in Figure 2. The transmitter and the receiver may either be located at separate nodes, or they may be collocated at the same node, but on separate computers. It was important to run the transmitter and receiver software packages on separate workstations, in order to avoid any delays caused by the sharing of the computer processor. All the workstations involved in the experiment were isolated from the network to prevent unauthorized users from stealing processor time.

The software for the transmitter and the receiver was developed in-house. The transmitter software consisted of a source, a ‘packetizer’ to append index numbers to the data packets, a ‘transmit-logger’ to store the relevant statistics, a ‘transmit-buffer’ for the data packets arriving from the source, a ‘threshold-monitor’ to implement the appropriate bandwidth allocation algorithm, and a transmitter to send out the packets at the appropriate rate. The statistics stored by the transmit-logger included the times of packet arrivals into the transmit-buffer, the times when bandwidth requests were placed, the times when bandwidth changes actually took place, etc.

After the packets were sent out by the transmitter, they travelled through the FRACS, over the satellite link and to the FRACS at the receiver end. The

received packets were then read by the receiver software which consisted of a ‘de-packetizer’ to take off the index numbers, a ‘receive-logger’ to store the packet arrival times and a data ‘sink’. In order to calculate the end-to-end packet delays properly between the transmitter and the receiver, the clocks on the two workstations were synchronized using the network time protocol (described further in Implementation considerations).

A problem presented by the ACTS system for this experiment was the significant delay in allocating the requested bandwidth. The encountered delay for allocating bandwidth using the ACTS system varied between 2 and 15 seconds and was not fixed, but changed as a function of the overall load on the ACTS network. To simulate a system in which the delay is either fixed and/or smaller, and hence to assess the effect of such delay on performance, a scheme was devised and tested for pre-allocating, through request from the ACTS system, all necessary satellite channels, but using only those required according to our dynamic bandwidth allocation algorithms. Under such a scenario, the amount of delay used was completely under our control.

In the pre-allocated case, the FRACS at the transmitting station filled any pre-allocated, but unused channels with junk data, which was removed auto- matically by the FRACS at the receiving station. With pre-allocated channels, a bandwidth change could be accomplished instantaneously, or after some specified fixed delay. For data traffic, the FRACS’s algorithm was tested using both instantaneous bandwidth changes with such pre-allocated

I

I

Experiment sortware I

204 D. FIUEDMAN ET AL.

channels as well as with actual real-time channel requests to the ACTS system. The threshold-based algorithm was tested in the same way, and also with a fixed delay for changing the bandwidth when using pre-allocated channels. The switch function- based algorithm for mixed-media traffic and a single transmitter was tested, either with instantaneous bandwidth changes using pre-allocated channels or through the actual ACTS system. Testing of the switch function-based algorithm with two stations competing for satellite bandwidth was conducted using only pre-allocated channels, with bandwidth changes accomplished either instantaneously or after a fixed delay of our own choosing.

Data trafJic

In the data-traffic portion of the experiment, the data was generated according to a three-state Mar- kov-modulated Poisson process (MMPP) model. l The MMPP source was chosen because it is better suited for modelling LAN traffic than a simple Poisson source because it has the ability to model the time variation of the traffic arrival rate. An MMPP is a Poisson process whose instantaneous rate varies according to an m-state Markov chain. For this experiment, m was chosen to be three.

Two bandwidth control algorithms were investigated: a rate-based algorithm implemented by the FRACS and a threshold-based algorithm executed by our software. Both algorithms were evaluated on the basis of per-packet average end-to-end delay, number of packets lost due to buffer overflows, and the average number of satellite channels used, where a channel represented a 64 kb/s circuit. Depending on the relative importance of these parameters a suitable cost function can be devised that also includes the cost of the bandwidth used.

Rate-based algorithm. The FRACS’s rate-based algorithm determined the amount of bandwidth required by measuring the arrival rate of the incoming traffic. This traffic rate was measured over 100ms intervals and was compared with the allocated rate for the outgoing traffic. Whenever the rate of the incoming traffic exceeded the allocated bandwidth, more bandwidth was requested (in 64 kb/s increments). Slightly below the allocated bandwidth was a ‘release’ bandwidth. When the rate of the incoming traffic dropped below the release rate, bandwidth was released. In some parts of the experiment the release bandwidth was kept the same as the allocated bandwidth. A long-term history of the incoming traffic rate profile was used by the FRACS’s algorithm to reduce the effect of momentary traffic bursts. The actual effect of momentary traffic bursts was controlled by adjusting the weight given by the algorithm to the most recent rate measurement. The experiment was conducted with several such weights to find the best one for different source types. After each determination of the

amount of bandwidth required, the FRACS signalled the ACTS system to allocate or de-allocate multiple 64 kb/s channels, as necessary.

Threshold-based algorithm. We also proposed and tested a sophisticated threshold-based algorithm to compare with the FRACS’s crude rate-based algorithm. The threshold idea was motivated by theoretical analysis of the slow server problem, where for exponential servers an optimal policy was found to be of a threshold In this algorithm, the amount of bandwidth required was determined by measuring the amount of data queued for transmission. Whenever the queue size exceeded a specified fraction of the maximum buffer size, an additional 64 kb/s channel was requested from the ACTS system. Slightly below each such ‘request’ threshold was a release threshold, and a channel was released whenever the queue size fell below the release threshold (Figure 3). Tests were done to find the optimal difference between pairs of request and release thresholds, and also between pairs of thresholds. The ‘hysteresis’ between up-crossing and down-crossing thresholds was motivated by the need to smoothen the effect of short-term traffic fluctu- ations.

Mixed-media trafJic

In the mixed-media portion of the experiment, the traffic consisted of voice and data packets. The data packets were generated using an MMPP source as in the data-traffic portion of the experiment. The voice calls arrived according to a Poisson model, and the call durations were exponentially distributed and independent.

The bandwidth allocation algorithm for mixed- media traffic used two-dimensional ‘threshold’ struc- tures, known as switch functions (Figure 4).

The state of the system, i.e. the number of voice calls in progress and the number of data packets in the transmit-buffer, can be represented by a point in the abstract decision space of data buffer occupancy and amount of bandwidth used for voice calls (Figure4). Thus, a state ( i j ) indicates that there are i voice calls in progress a n d j packets of data traffic in the queue. The object is to decide what to do when a new voice call request arrives. The options are to reject it, admit it, or admit it at a ‘compressed’, reduced-quality (and reduced-bandwidth) level. As the acceptance of a new voice call may result in excessively reducing the bandwidth available for data-service, a decision must also be made whether to request more bandwidth. The purpose of the algorithm is to minimize the cost function

E(D) + f f P s

where E(D) is the average delay for data packets, PB is the voice call blocking probability, and a is a coefficient that reflects the desired relative weight-

INNOVATIVE NETWORKING CONCEPTS

Incoming Data ____)

205

Outgoing Data ___)

Request Threshold 2 I R r a s e Threshold 2

3 h II)

9) C

9 .s cc 0 G

i I ! Packet Overflows I Rdlease Threshold 1

Request Threshold 1

Data Buffer Figure 3. Thresholds on the data queue

.i A

2

1.5

1 ‘-7 - -

I

1

I - i x1 x2 x4 x8 x12

Data Queue Occupancy ---> (8 of maximum buffer size)

Figure 4. Switch functions for mixed-media bandwidth allocation

ing of the two cost criteria. Under a number of conditions, the optimal call admission policies have been shown to take the form of a set of switching curves in this abstract space.6 The switch functions consist of different threshold values in both dimen- sions, of i (the data queue size) and of j (the number of on-going calls). To the left and below a switch-curve, an arriving call is accepted, whereas to the right and above that curve that call is rejected. In addition, based on the same philosophy we introduce additional switch function curves that govern additional bandwidth requests and releases. A separate threshold on the voice call blocking rate is also enforced at all times. If blocking a call leads to a

blocking rate higher than that which is acceptable, additional bandwidth is requested and the call is accepted no matter where the instantaneous state lay in relation to the decision space.

In Figure4, the solid and dashed lines represent the ‘switching curves’. The solid curves A, B and C are the decision curves for accepting or rejecting a voice call request, and are hereafter referred to as the acceptheject curves. The dashed curves A’ and B‘ are the bandwidth adjustment curves, and indicate when more bandwidth should be requested or released. The curve C‘ does not exist because we restrict ourselves to using a maximum of three channels for implementation reasons. The region


below A’ indicates the region of operation with only one ACTS channel; the region below B’, with two ACTS channels; and the region below C, with three ACTS channels. The variables X,, X,, ..., XI, represent data buffer thresholds and are specified as percentages of the maximum queue size. Each uncompressed voice call is 32 kb/s, and thus takes up one half of an ACTS channel. If so desired, a voice call can be compressed down to 16 kb/s. A single ACTS channel can thus carry four compressed voice calls.

The algorithm was designed following the prin- ciple in Reference 6 that attempts to minimize the weighted sum of the delay and the voice call blocking probability. With this algorithm a voice call is blocked (not accepted) if its acceptance would result in a significant reduction of data service-rate for the current queue size (unless the pressure for performance dictates an increase in the available bandwidth and a new channel is hence requested). Voice call compression offers another degree of freedom in performing the complicated trade-offs. Voice call quality thus becomes a performance parameter: high voice quality could be traded for a low blocking probability.

As an example, let us trace a sample path through the decision space as shown in Figure 5. Initially we start off with zero ongoing voice calls and zero data packets in the queue, i.e. we start off at the origin. In this hypothetical example, suppose a voice call request arrives. The algorithm checks to see if accepting the call results in any switch functions being crossed. Because none are crossed, the voice

9

cr 0

?5

.- 8 8

S -

3

2.5

2

1.5

1 - .. -_ ._

.5

.25

0

.i

t

call is accepted and the state is now (0, 0.5) (point L in Figure5). Now suppose data packets start arriving and accumulate in the queue till it reaches level X,. As soon as the queue occupancy exceeds X , (point M in the figure) a new channel is requested. If data now starts arriving at a faster rate so that the queue size keeps going up in spite of the extra channel, the data queue occupancy would keep increasing. Suppose another voice call arrives when the queue occupancy is between X, and X , (point N). The algorithm determines that accepting this call results in the curve B being crossed. Thus, it checks to see if this call can be accepted compressed. After compression, the call only occupies one-fourth of an ACTS channel, thus it is accepted with no compression of ongoing calls. The new state is point P in Figure 5. All along, the blocking rate is ch‘ecked to make sure that it is maintained below a specified threshold. Say another voice call arrives immediately afterwards. There is no space to accept it without crossing the curve B. Thus, the algorithm makes space for it by compressing one ongoing call, and then accepts the new call in a compressed form. The state is still point P. Com- pressing an ongoing call frees up one-fourth of a channel, and this is all that is needed to accommodate the new compressed call. At this point, two channels are being used for transmission, the data queue is between X , and X,, and three-fourths of one ACTS channel is occupied by voice (three compressed calls). Now, suppose the number of waiting data packets starts to go down. When the queue occupancy gets down below X,, a channel is

XI x2 x4 X8 x 12

Data Queue Occupancy ---> (% of maximum buffer size)

Figure 5. A sample path through the decision space

i


released as the requesthelease curve A' is crossed (at point Q ) . Suppose when the queue occupancy gets to between X2 and X, (point R) , one compressed voice call ends. Thus, the state decreases by a quarter of a channel on the decision space, and the new position is between X2 and X, on the i axis, and at 0.5 on the j axis (point S). A voice call is rejected if accepting it results in some switch function being crossed even after all ongoing calls have been compressed. However, after a certain number of rejections, if the blocking rate threshold is exceeded, the system is forced to accept the voice calls (in a compressed mode), and to request additional bandwidth.

This algorithm was evaluated on the basis of per- packet average end-to-end delay, number of packets lost due to buffer overflows, average number of satellite channels used, voice call blocking fre- quency, and the voice call quality (degree of compression). Depending on the relative importance of these parameters, a suitable cost function can be devised that must include the cost of the bandwidth used. For example, the user may wish to assign more weight to voice call blocking probability and to end-to-end packet delays than to voice quality and average number of satellite channels used, and so on.

In the experimental setting of two stations competing for satellite bandwidth, the Maryland and Colorado stations transmitted to each other. A cen- tral bandwidth control algorithm for the two stations was operated at the University of Maryland; bandwidth requests from the Colorado station were trans- ported to Maryland through the Internet. While the algorithm was operated at Maryland, bandwidth was allocated on a first-come, first-served basis, and neither station had priority for being granted requested bandwidth.

Results

This experiment has not yet been completed. However, a few early results are available and are summarized below.

Each run of the experiment involved sending approximately four million bits of data. This data was organized into 4000 packets of 126 bytes each. It was decided to send 4000 packets, in order to get reproducible results, as determined by earlier tests. Information about the send and receive times of the data packets was stored in the transmit and receive loggers, and the data packets were destroyed once they reached the receiver. For the case of pre- allocated channels and data-traffic only, the rate- based algorithm (FRACS's algorithm) had a lower average per-packet end-to-end delay, but the threshold-based algorithm used a lower number of channels. Further tests are being conducted to allow a fairer comparison of the two algorithms.

Some of the results obtained are shown in Table I. The buffer size used was 100 packets. An MMPP

Table I. Threshold-based algorithm results

Offered Delay Average load rate (seconds) channel (kb/s) usage

58 0.837 1.82 62 0.883 1.81 76 0.866 1.78 70 1.878 1.19

source was used. The four values shown indicate performance corresponding to different settings of the threshold values.

The rate-based algorithm was also run, both with and without memory. The results are shown in TableII. The three values shown indicate performance for the rate-based algorithm of the FRACS for three different internal configurations.

As can be seen from these numbers, the threshold- based algorithm suffers greater delay because it uses bandwidth more economically. The FRACS algorithm tends to request additional channels earlier than the threshold-based algorithm and thus pays a higher penalty in bandwidth usage. This phenomenon, that is, less time is spent by customers in a system if more servers are available, is common in any service system. The relatively large difference in delay performance is due to the fact that the offered input load rate is close to the average channel usage for the parsimonious algorithm and, thus, tends to load the system to near-capacity levels. Additional tests in progress are expected to show a much smaller discrepancy in these values.

tmplementation considerations

In order to measure the end-to-end delays for data packets accurately, it was necessary for the clocks on the transmitting and receiving computers to be synchronized to within a few milliseconds. To achieve such synchronization, and to combat natural drifting of the clocks, XNTP (network time protocol, version 3) was used.7 The Maryland computers were synchronized to stratum 2 time servers at the Uni- versity of Maryland campus, while the Colorado computer was synchronized to a stratum 1 server in Boulder, Colorado. Synchronization of the Maryland and Colorado computers to within a few milliseconds was thus achieved.

Table 11. Rate-based (FRACS) algorithm results

Offered Delay Average load rate (seconds) channel (kb/s) usage

57 82 82

0.346 1.98 0.386 2.34 0.414 1.98


In order to do real-time channel allocation, requests were forwarded to the FRACS, which sent out the appropriate signals to the ACTS system. However, the combination of FRACS signalling and the call-manager software of the ACTS system was unable to handle frequent requests. When the transmitter and the receiver stations were collocated at the same node, only one outstanding request was allowed at any given point in time. Thus, parts of the experiment had to be redesigned and their testing is under way.

When using our bandwidth allocation algorithms, it was necessary to poll the FRACS to determine when bandwidth changes occurred, because the FRACS was not capable of reporting this information on its own. This polling was conducted by a portion of the transmitter software and it therefore ran on the same workstation, competing with the data transmission functions for processor time and thus slowing the traffic generation and transmission processes. On the other hand, no such polling was needed while running the rate-based algorithm, because the FRACS itself ran this algorithm and kept a log of bandwidth changes. However, for the purposes of a fair comparison, FRACS polling was conducted in all configurations of this experiment.

EXPERIMENT 2: ERROR CONTROL SCHEMES FOR SATELLITE AND HYBRID NETWORKS

As mentioned earlier, this program of experiments was motivated by the commercial potential of hybrid networks. Information transferred using a hybrid network must be protected against errors just as in a satellite or any other network. However, the availability in a hybrid network of a terrestrial link with less propagation delay and different error characteristics than those of the satellite channel presents additional problems as well as possibilities for error control, particularly in the case of automatic-repeat-request ( ARQ) schemes. The second experiment explored such possibilities. Furthermore, a satellite is an excellent means for point-to-multipoint communication. Hence this experiment also investigated ARQ error control schemes for multicast communication in hybrid networks.

This experiment was additionally motivated by the possibility of improving throughput by sending ARQ acknowledgments terrestrially instead of by satellite, thus avoiding the satellite propagation delay for the acknowledgments. Throughput might be further increased by retransmitting packets (as may be necessary) terrestrially instead of by satellite. Calculations showed that judicious use of the hybrid configuration could in some cases increase the throughput; sometimes significantly so.

The purpose of this experiment, as previously mentioned, is to explore error control techniques for hybrid networks. The terrestrial link of a hybrid network can be used as a feedback path from the receiver to the transmitter, and so the experiment

focuses on examining ARQ schemes in such a network. To calibrate the improvement offered by a hybrid architecture, an investigation and comparison of error control techniques in a hybrid network should include examining error control techniques used in a satellite-only network. Also, because the relative performance of ARQ and forward error correction (FEC) schemes depends on many factors, an FEC component was included in the experiment.

The experiment is depicted in Figure 6. Data, produced by a continuous traffic source, was sent from one station to another via satellite. Before transmission, an error control protocol was applied by the transmitter to protect the data as it travelled through the satellite channel. Because the ACTS channel typically exhibits a bit error rate (BER) of lo-’ or less, it was necessary to inject artificially- produced noise (described later) in order to study error control schemes. After corruption by artificial noise, the receiver applied the error-control protocol to correct any errors which may have developed in the data. The data was then stored for later comparison with the original data to determine a residual BER.

The FRACS was used as an interface between workstations and VSATs (except as detailed for multicast ARQ testing). The Internet and a 14.4 kb/s telephone modem connection were employed as the terrestrial link for hybrid operation. The parameters of interest were throughput, end-to-end delay, and the residual error rate of the data received. The number of packets sent, received, and received in error on each link were also recorded. Not only were the results from FEC testing compared with each other, as were the point-to-point ARQ results, but the results of these two parts were also compared.

Our intention was to compare these schemes based on the noise present on the actual satellite link. However, the experience of other ACTS exper- imenters indicated that the satellite link exhibited very low BER when not compromised by severe weather. Therefore, in order to study error control schemes, it was necessary to inject artificially-produced noise. It had originally been expected that burst errors would be seen when using ACTS, particularly due to disturbances of the K,-band channel by water in the atmosphere. In seeking a precise model to describe the burst error behavior of the ACTS channel-a model which would be used for the artificial noise effects-we learned of the pre- liminary results of another ACTS experimenter.* These results, and our observations also, indicate that a binary symmetric channel (BSC), not a burst channel, best characterizes the development of errors in the (uncoded) ACTS channel; such a model of error production was used in the experiment software. These noise effects were generated with bit error rates of 3.16 x lo4, 3.16 x 10-4,

A control case of zero artificial noise was also included.

and 3-16 x


t> source a comparison

Figure 6. General Experiment 2 configuration

It might appear that the FEC measurements in this configuration would represent nothing more than the simulated results of the FEC schemes over a BSC; something that is well known (see for example Reference 9). It might also appear that the actual use of the satellite is superfluous. However, because we wished to examine and compare error control techniques for satellite and hybrid communication, it was therefore necessary to conduct the FEK portion of the experiment in exactly the same fashion as the ARQ portion, which indeed requires the use of the actual satellite and hybrid architecture of Figure 6.

For FEC testing, the data was sent via satellite from one workstation at Maryland to another beside it. For point-to-point ARQ testing, a terrestrial link was sometimes required, so using two adjacent workstations would yield an unrealistically small terrestrial link propagation delay. The Colorado station was therefore used for transmitting to the Maryland station during such testing. During point- to-two-point ARQ testing, a workstation at Maryland transmitted to another beside it and to one in Color- ado, with a software delay used for terrestrially carried messages from the Maryland workstation.

To make meaningful statistical inferences from the data, about 100 error events (corrupted bits) were deemed to be the minimum necessary. There- fore, at least 10 million bits would have to be sent through the channel when operating the noise effects at the lowest BER setting ( lop5). A more meaningful approach, which was adopted, was to send at least 10 million infonnution bits from one end of the

system to the other. Therefore, in all testing, at least 10 million information bits were transferred.

Forward error correction (FEC)

The FEC codes selected were the BCH (15, 7) and the Golay (23, 12) code because they are simple to implement and have rates of about one-half, as it had originally been hoped to compare the performance of these with the rate one-half code used by ACTS (a convolutional code with constraint length 5 ) to combat rain fading.” (It was later determined that we could not test ACTS’S coding because we cannot control the en-ors produced in the channel, or even detect the occurrence of these errors, because the coding itself corrects them.) A third code, the BCH (15, 11) code, was later added to provide a broader set of FEC choices. For comparison purposes, plain uncoded text was also sent. (The Reed-Solomon (127, 123) and (127, 121) codes constructed over GF (2’) were originally included to protect against expected burst errors, but were abandoned when the actual non-bursty error model was obtained as described earlier.)

The system used for FEC experimentation is shown in Figure7. As the encoder and decoder software developed for this work would not support real-time operation for the desired ACTS channel bit rate (128 kb/s), encoding and decoding were conducted offline. The encoded data was sent via satellite, corrupted with noise and stored. Later, the data was decoded and the resulting information was compared bit-by-bit to the original data,


encoder

(&

d

Figure 7. FEC operation

A utomatic-repeat-request ( A R Q )

Both go-back4 and selective-repeat ARQ protocols were tested in satellite-only and hybrid configurations. The go-back4 and selective-repeat protocols tested followed the logic of the REJ protocol and SREJ* protocol with multi-selective reject option, respectively, specified in References 11 and 12. The parameters of the protocols were modified for our satellite experimentation, and some parts not integral to error control, such as call setup and termination, were not included in the software implementation because they were accomplished by other means.

In the go-back-N scheme, the transmitter sent packets continuously to the receiver, which returned an acknowledgement for each valid packet received. If a packet was found by the receiver to be defective, the receiver requested a retransmission and discarded all subsequently received packets until the required packet was received. In this protocol, N- 1 packets following the defective one were sent before the defective one was retransmitted, so each requested retransmission entailed sending N previously transmitted packets. l 3 In the selective-repeat scheme, the receiver could, to a limited extent, accept packets out of order, and so could specify to the transmitter a list of packets still required. Only defective packets, and no others, were sent again.

The system used for ARQ operation is shown in

*These terms (REJ and SREJ) are not pure abbreviations, but are standard nomenclature in References I I and 12 for the go- back-N and selective-repeat ARQ protocols, respectively.

Figure 8. Here, a set of data packets was produced continuously and sent over the satellite. Each packet comprised 125 bytes of data, a 2-byte sequence number, and a 2-byte cyclic redundancy check (CRC-CCITT). Upon receipt, they were corrupted with artificial noise as will be described towards the end of this section. After checking for errors, the receiver generated an acknowledgment according to the ARQ protocol and send this reply to the transmitter. Testing was conducted with the acknowledgments carried over ACTS or terrestrially either via the Internet or via the public switched telephone network. For cases in which acknowledgments were carried terrestrially, retransmitted packets were sent either over satellite or over the same terrestrial link (in the opposite direction). Retransmitted packets were always carried via satellite if the acknowledgments were so carried. All data accepted by the receiver was stored and later compared bit-by-bit to the original data.

The window size (N) was 76 for operation in a satellite network, and 65 for operation in a hybrid network. The window size was less for hybrid operation because of the lower propagation delay through the terrestrial link than through the satellite link and because the terrestrial link had less bandwidth than the satellite link. (For such purposes, the Internet was conservatively assumed to have the same bandwidth as available through modems connected through the telephone network.) The required ARQ timer periods were calculated to be 0-788 seconds for satellite operation and 0.674 seconds for hybrid operation, but these values were increased slightly to allow for software processing time.

Because transmission control protocol (TCP) employs an ARQ error control protocol of its own

INNOVATIVE NETWORKING CONCEPTS 21 1

Figure 8. ARQ operation

which would interfere with our work, it could not be used when employing Internet as the terrestrial link. Therefore user datagram protocol (UDP) was the transport protocol employed.

For each combination of ARQ protocol and network configuration (as explained earlier), tests were conducted for a set of values of noise BER chosen from the set of seven values mentioned earlier. In six of these, artificial noise was injected by the receiver into the forward channel and by the transmitter into the feedback channel, thus subjecting both data packets and acknowledgments to noise. The seventh test was a control case in which no noise was added. In all tests, IOOOO packets (corresponding to ten million information bits) were sent.

ARQ multicasting

A series of point-to-two-points ARQ protocol tests was also conducted, as the start of an inquiry into point-to-multipoint ARQ schemes for satellite and hybrid networks. In a purely satellite multicast system employing ARQ, each destination station must have a relatively expensive transmit and receive satellite terminal in order to receive information and send ARQ acknowledgments. Furthermore, if a single receiving station requires a packet retransmission, then the transmitting station must send the packet over the satellite link. This retransmission interrupts the stream of new packets for all destination stations. Only one receiving station benefits from the retransmission; the others are forced to

wait unproductively during this time. This delay may possibly be circumvented, and the throughput for the system correspondingly increased, by sending ARQ acknowledgments and retransmitted packets terrestrially. Again, a receive-only satellite terminal is adequate for the destination stations if a hybrid configuration is used, and a significant cost saving may be obtained in addition to the aforementioned throughput improvement.

For the ARQ multicasting tests conducted, the go-back4 and selective-repeat ARQ protocols used in point-to-point operation were modified slightly to accommodate two receiving stations. Whereas the ACTS system supports multipoint transmission, this feature was not used for this testing due to the lack of a suitable interface between the workstation and the VSAT. Instead, one copy of each transmitted packet had to sent via ACTS simultaneously on two separate paths, one for each destination. However, a single transmitting process was used to send the packets over satellite, process acknowledgments from the two receivers and conduct retransmissions as necessary.

As in the point-to-point case, four tests were conducted for each ARQ protocol and network configuration. As described earlier, one workstation at Maryland transmitted packets over ACTS simultaneously to another workstation beside it and to one in Colorado (conceptually depicted in Figure 9). The FRACS was used with the Maryland-to-Mary- land satellite link while a pair of channel- service/data-service units (CSU/DSUs) were used with the Maryland-Colorado satellite link. The


acknowledgments from the Maryland receiver, as well as packets retransmitted to it terrestrially, were delayed with software to simulate the propagation time which they would have experienced had the receiver not been located so near the transmitter.

For this part of the experiment, two network configurations were employed: either all data packets and acknowledgments were sent over satellite links and nothing was sent over terrestrial links, or data packets were sent originally via satellite while both acknowledgments and retransmissions were sent terrestrially. For each combination of these two configurations and the two ARQ protocols, three tests were conducted. In the first, the BER of the noise injected by both receivers was In the second test, one receiver injected noise of BER while the other receiver injected no noise. Finally, in the third test, one receiver injected noise of BER while the noise at the other receiver had a BER of

In all three tests, the transmitted injected noise with BER and loo00 packets were transmitted.

Results

The FEC portion of the experiment has been completed, while the ARQ portions are not yet complete. The residual bit error rates achieved by sending 10 million information bits through the satellite channel, including the noise effects gener- ator, are given in Table 111.

These results will develop their value when compared with the results of the ARQ portion of the experiment, which is not yet complete.

One result already available from the ARQ portion of the experiment is that the 14.4 kb/s modems introduce significant delay in carrying bits from one end of a telephone link to another. This delay, even after subtracting propagation delays, is about 140 ms in each direction. This delay is speculated to be due to compression/decompression of the data and the modems’ trellis-coded modulation scheme, particularly the Viterbi decoding. The precise causes for this delay have not yet been determined. As the delay is a significant fraction of the time required to send a bit between two points via geostationary satellite, it is possible that little throughput improvement over a satellite network might be achieved by using such a modem link as the terrestrial link in a hybrid network. This finding does not, however, diminish the significant cost savings achievable with the hybrid architecture instead of a pure-satellite architecture .

EXPERIMENT 3: REMOTE DATABASE ACCESS AND INTERNETWORKING

PROTOCOL COMPARISON

In the third experiment, the hybrid network mechanism of data access was demonstrated and evaluated against the use of solely satellite connection or solely Internet connection. Two internetworking protocols were applied in the satellite link, namely CCIlT’s standard X.25 protocol and the frame relay protocol. The logic and the performance of these protocols were studied and compared. We focused on the data link layer functionalities because this is where the key differences


TableIIJ. Residual bit error rates

Noise Code effects bit error rate Plain text BCH BCH Golay

(15, 11) (15, 7) (23, 12)

3.16 x IW3 2.042 x l t 3 9.990 x lo-’ 1.300 x lo4 1.180 x lo-’ lW3 8.163 x 10-4 1.160 x lW5 0 1 . 1 0 0 x 10-6

3-16 x 10-4 2.877 X 1P 1.100 X 10-6 0 0 10-4 9.970 x 0 0 0

3.16 x 10-5 3.210 x 10-5 2.000 x 10-7 0 0 1 0 - 5 1.010 x 10-5 0 0 0 0 0 0 0 0

of those two protocols reside. In addition, we studied the commonly used transport layer protocol (TCP) over the satellite link. In the process, a problem with using TCP was identified and a solution was provided, which was to use an extended version of TCP, called lTCP, developed at the University of Southern Cali- f01-11ia.l~ Finally, and most importantly, two emulated LANs were interconnected by the satellite link, and a comparison of the performance of X.25 and frame relay used for their interconnection is being carried out as the culmination of the objectives of this experiment.

Remote database access via a hybrid network

A common communication need in many applications is to access a computer network with a personal computer for the purpose of transferring files and databases. Whereas a telephone modem can be used to connect to the network, the low bandwidth of such a connection is often insufficient. A leased line of higher bandwidth (56kb/s, 1-544Mb/s T1, etc.) is an alternative but is expensive. A satellite link is also an option, but the required ground terminal can also be expensive. However, typical users of computer networks con- sume much more information from the network than they send to it. For such users with asymmetric bandwidth requirements the low-volume traffic to be sent to the network can be carried over a telephone modem connection instead of the satellite, whereas the bulk traffic from the network can be carried over a higher-bandwidth satellite channel. The transmit capability of the satellite terminal may thus be eliminated, significantly reducing the cost of the terminal.

The first part of this experiment demonstrated this concept by remotely accessing a multimedia database using a hybrid network (Figure 10). In particular, all short interactive access requests were routed through Internet, and the bulk information from the database was routed through a T1 satellite link. ASCII text, audio and image files, ranging in size from 50 kb to 6.4Mb, were transferred using the ‘point-and-click’ Mosaic user interface. The performance obtained when using only Internet varied with the time of day, with throughputs as low as

several kilobytes per second during peak network traffic hours up to 40 kb/s. Operation through the satellite exhibited much less variation, with throughput of about 39 kb/s, because the satellite link was a dedicated and directly connected link. The reason that there is still some variation in the throughput in the satellite link is that the transmission follows the TCP connection protocol and is therefore subject to variations caused by the error- and flow-control components of TCP. The throughput through the satellite usually exceeded that through Internet, when Internet exhibited stable throughput. Table IV provides some of the specific measurement results.

Thus several advantages of the hybrid architecture are seen. First, mass information services can be provided using the high-bandwidth and broadcast advantages of satellites and receive-only ground terminals. Second, greater throughput can be obtained in most cases with a hybrid network. And third, congestion on Internet may thus be offloaded.

In parallel with this work, and motivated by the same desire to support asymmetric communication with low-cost receive-only satellite terminals, the CSHCN helped Hughes Network Systems develop a recently announced product named DirecPC. With this product, a user can send an information request to a computer network (in particular, Internet) using a modem and have the information returned to him via a satellite link. To accomplish this, it is necessary that the computer accessed over the network return the requested information to a computer for uplinking to the satellite instead of to the computer connecting the user’s dialup connection to the network. Special software was therefore required for encapsulating Inter- net TCP/IP frames within TCP/IP frames with suitably modified addresses, so that the requested information would be routed properly. The CSHCN contribution to this product has been recognized by the University of Maryland Office of Technology Liaison as outstanding invention of 1994.

Protocol comparisons

We first considered the relative merits and performance of the two basic protocols for internetworking, namely X.25 and frame relay. Following


Figure 10. Remote multimedia database access with a hybrid network

Table IV. Results of the database access portion of Experiment 3

Database size (bytes) Delay Throughput (seconds) (kb/s)

Internet 103 488

3311 616 5 299 770 5 299 770 Satellite

103 488 206 976 413952 827 904

1 655 808 3311616 6 623 232 Hybrid

103 488 103 488 206 976 206 976 413952 413 952 827 904 827 904

1 655 808 1 655 808 1 655 808 1 655 808

9.5 240 132 170

6-5 9- 1

14 24 44 84

170

4.2 4.1 5.9 6.3 9.2 8.8

15 16 90 33 29 28

1 1 14 40 30

16 22 29 34 37 38 39

24 24 34 32 44 46 53 50 18 49 56 57

that, we considered both TCP and TTCP (the extended TCP version mentioned earlier) over satellite, and finally we engaged in the comparison of the performance of these protocols for interconnecting two LANs.

X.25 and frame relay. As we know, X.25 uses call-control packets for making and breaking virtual circuits. These call-control packets are carried on the same channel as data packets; therefore, in-band signalling is used. With X.25, flow-control and error- control mechanisms are within both the network and the data link layers. Multiplexing of virtual circuits is also conducted at the network layer. This approach results in considerable overhead. In con- trast, frame relay is a protocol which seeks to eliminate as much of this overhead as possible, thereby reducing network delay and increasing throughput. It is regarded as an improvement over the traditional packet switching technology of X.25. Frame relay uses call-control signalling which is carried on a logical connection separate from user data. Therefore intermediate nodes in frame relay communication need not maintain status tables or process messages relating to call control on an individual per-connection basis. Frame relay also multiplexes logical circuits at the data link layer instead of at the network layer, eliminating an entire layer of processing. Frame relay has no node-by- node flow control or error control; such functions are the responsibility of higher layers, if they are conducted at all. Thus, frame relay offers a more streamlined approach to communication than X.25.

The protocol logic, operation and performance of these two protocols were studied and compared in this portion of the experiment. SunNet X.25 and SunLink frame relay software packages were used for this work. A T1 satellite link was used to interconnect Ethernet LANs at the University of Maryland and the University of Colorado. A workstation at each of the two sites, was configured as

lNNOVATIVE NETWORKING CONCEPTS 215

internetworking gateways for both X.25 and frame relay. Because only two nodes were available for testing the protocols and not a network of several nodes, the differences in the multiplexing and rout- ing functions of the two protocols could not be tested. Therefore only the differences in the data- link layer could be studied by experimentation.

File transfer protocol (FTP) and TTCP were used to obtain throughput measurements. A throughput of up to 40 kb/s was obtained with frame relay. For X.25, the throughput was sensitive to the setting of the window size. The SunNet X.25 software allows a setting of 2 to 127, and calculation showed that using a window setting of 127 and a 1000-byte frame size should support non-stop transmission. However, the window size could not be set to higher than 18, probably due to a problem with the SunNet software. Therefore a throughput of only 9 kb/s was achieved. Assuming the window size could have been set to 127, the throughput of X.25 would still have been expected to be less than that of frame relay, because X.25 requires four steps for transferring a packet: the link level sending and acknowledging and the transmission level acknowledging sending and acknowledging. We observed this phenomenon by monitoring the link layer activity. From the foregoing discussion, frame relay can indeed be considered as an evolution of X.25, and can support higher end-to-end throughput than X.25, especially on high-quality links. Table V shows the relative performance of X.25 and frame relay in terms of delay and throughput, specifically for FTP traffic.

Conventional and extended TCP. It should be noticed from the previous section that when an FTP session was initiated over a frame relay link, even though frame relay does not have any link-level

Table V. X.25 vs. frame relay

Size (bytes) Delay Throughput (seconds) (kbls)

Performance of FTP over frame relay SOk 5 *2 9.7 l00k 6.5 16 200 k 9.1 22 400k 14 29 800 k 24 34 1.6 M 45 36 3-2 M 84 38 6.4 M 160 39 Performance of FTP over X.25 50 k 6.9 7.3 l00k 24 4.3 200 k 35 5.8 400 k 49 8.3 800 k 96 8-4 1-6 k 180 8.9

flow control and error control which may restrict the end-to-end throughput, the actual throughput of the FTP session over a dedicated TI link was only 39 kb/s. The flow control and error control functions of the transport-layer TCP were responsible for this inefficiency.

The flow control function uses a sliding window protocol similar to that of a high-level data link control (HDLC) protocol, with a maximum supported window size of 64 kb. This poses a problem for using TCP with a satellite channel, or any other link with a high bandwidth-delay product: TCP will allow at most 64 kb of unacknowledged data, whereas there can easily be more than 64 kb of data in the link at any instant. (In particular, 11 1 kb of data can simultaneously be in a T1 link with a 580 ms round-trip delay.) This leads to a 'stop-and- wait' syndrome, in which TCP sends a chunk of data and then waits for an acknowledgment before continuing. TCP therefore prevents the link from being filled to capacity, and the throughput is reduced correspondingly. Additional concerns about using TCP over a satellite link include the possibilities of sequence number wrap-around and earlier termination of the connection. These problems are addressed in an extended version of TCP, which was tested and compared with conventional TCP.

For the reasons mentioned above, a single session of conventional TCP was found to yield only up to 6-9 kb/s throughput over the satellite. Trying to increase the throughput by initiating multiple TCP sessions yielded, as a best result, an average throughput of 5 kb/s per session with 32 simul- taneous sessions. A single session of extended TCP was found to give a higher throughput for all sessions of the window size, with the best results obtained with an 80 kb window size (94 kb/s throughput). (Testing with larger window sizes yielded no performance improvement). Clearly, extended TCP performs much better than TCP over a satellite link, giving throughput more than 13 times greater than with conventional TCP. Table VJ shows the quantitative differences that were measured.

LAN interconnection. The ultimate objective of this experiment was to emulate two LANs interconnected over the satellite Iink, on which X.25 and frame relay protocols were applied as the internetworking protocol. The performance of particular applications in this interconnected system, over the two different protocols (either X.25 or frame relay), were compared. Specifically, the average packet delay of each individual application was the performance criterion.

The emulation of the LANs was composed of two components; the first was emulation of the background traffic of a LAN, and the second was the particular application that we are interested in. The background of LAN traffic was emulated by using the so-called self-similar m ~ d e I , ' ~ * ' ~ that is


Table VI. Conventional TCP vs. extended TCP

Number of Average sessions throughput per

session (kb/s)

Conventional TCP

1 6.6 2 6.6 4 6.6 8 6.6

16 6.5 32 5 *O

Window size Throughput (kb) (kb/s)

Extended TCP-single TCP session

10 20 30 40 50 60 70 80

14 29 43 57 70 84 92 94

based on recent Bellcore studies. It was found to be a more realistic traffic model for LAN traffic.

The particular application messages were merged with this emulated LAN traffic and fed into the network gateway, through which they were sent over the satellite link using either X.25 or frame relay (Figure 1 1 ) as the internetworking protocol.

As an extension, a two-hop LAN interconnection was tested. Here, on the receiving end (it is actually now the intermediate node), another self-similar

traffic source was built to represent the LAN traffic, and a portion of this traffic, considered as the inter- LAN traffic which is intended for the third node (ultimate destination), was merged with the incoming traffic from the first gateway. All these traffic streams were sent back through the satellite link to the first gateway, which virtually represented a third gateway. After the particular application’s traffic reached the final destination, its end-to-end delay-from generation to final receipt-was logged. In this two-hop transmission over the satellite link, either X.25 or frame relay was used as the link layer protocol.

This portion of the experiment has not yet been completed.

CONCLUSION

To date the experiments have not yet been completed, largely as a result of uncontrollable factors. The ACTS VSAT suffered several problems, including incorrect installation, cable breakage and several failures of components. The weather in Colorado also prevented experimentation several times by dis- rupting the optical link. Despite these difficulties, we are continuing the conduct of these experiments and expect to have the complete results in the near future.

ACKNOWLEDGMENTS

This work was supported by the National Aeronaut- ics and Space Administration under Grant No. 01526093 and the National Science Foundation under Grant No. NSF EEC 94-02384. This work would not have been possible without the kind and helpful support, including the loan of the T1 VSAT, of ACTS program personnel at the NASA Lewis

application

gateway

competing traffic

gateway

Figure 1 1 . LAN interconnection


Research Center in Cleveland, Ohio. Furthermore, the authors were only part of a larger team which designed, implemented and conducted the experiments. This team included: Dr Apostolos Traganitis of the University of Crete, Greece; Timothy Kirk- wood of the CSHCN; Yannis Konstantopoulos of MCI; Dr Anil Agarwal, Moorthy Hariharan and Anita Fitzwater of COMSAT Laboratories; Dr Stan- ley Bush, Fan Huang, Gil Weiss, Neil1 Cameron, Wenjin Yang and David Bailey of the University of Colorado at Boulder; Marjorie Weibul of NTIA; and Ruplu Bhattacharya, Samardh Kumar and Anas- tassios Michail of the University of Maryland.

REFERENCES I . W. Fisher and K. Meier-Hellstern. ‘The Markov-modulated

Poisson process (MMPP) cookbook’, Performance Evalu- ation, IS (1993).

2. W. Lin and P. R. Kumar, ‘Optimal control of a queueing system with two heterogeneous servers’, IEEE Trans. Auro- matic Control, 29. 696-703 ( 1984).

3. J. Walrand, ‘A note on “Optimal control of a queueing system with two heterogeneous servers,’’’ Systems and Con- trol Letters, 4, 131-134 (1984).

4. M. Rubinovitch, ‘The slow server problem: a queue with stalling’, J. Appl. fmoh., 22, 879-892 (1985).

5 . I. Viniotis, ‘Optimal control of a multiserver queueing system with heterogeneous servers’, Master’s thesis, University of Maryland, College Park, 1985.

6. I. Viniotis and A. Ephremides, ‘On the optimal dynamic switching of voice and data in communication networks’, Proc. Computer Networking Symposium, April 1988, pp. 8- 16.

7. D. L. Mills, Network Time Protocol (Version 3 ) Specification, Implementation and Analysis (RFC 1305). University of Delaware, March 1992.

8. D. P. Kennedy, Personal communication, INTELSAT, Wash- ington, DC, May 1994.

9. J. G. Proakis, Digital Communications. 2nd edn., McCraw- Hill, New York, 1989.

10. National Aeronautics and Space Administration, System Handbook: Advanced Communications Technology Satellite (NASA TM-I0 1490). Lewis Research Center, Cleveland, OH, 1993.

1 1. International Standards Organization, International Standard I S 0 4335, ‘Information processing Systems-Data communication-High-level data link control procedures- Consolidation of elements of procedures’.

12. International Standards Organization, Proposed Draff Inter- national Standard I S 0 7776/DAM 2, ‘Information processing systems-Datu communication-High-level data link control procedures-Description of the X.25 LAPB-compatible DTE data link procedures-DAM 2: Multi-selective reject option’.

13. S . Lin and D. J. Costello Jr.. Error Control Coding: Funda- mentals and Applications. Prentice-Hall, Englewood Cliffs, NJ, 1983.

14. R. B. V. Jacobson and D. Borman. TCP Extensionsfor High Performance (RFC 1323). May 1992.

15. W. E. Leland, M. S. Taqqu, W. Willinger and D. V. Wilson, ‘On the self-similar nature of Ethernet traffic’, Proc. ACM Sigcomm ’93, 1993, pp. 183-193.

16. W. E. Leland, M. S. Taqqu, W. Willinger and D. V. Wilson, ‘On the self-similar nature of Ethernet traffic (extended version), IEEE/ACM Trans. Networking, 2, 1 - 15 ( 1994).

Authors ’ biographies

Daniel Friedman received a Bachelor of Science degree with University Honors and Department Highest Honors from the University of Illinois at Chicago in May 1992, and a Master of Science from the University of Maryland at College Park in December 1995, both in electrical engineering. His interests lie in satellite communication, communication networks, and error control. He is currently pursuing a doctoral degree at the University of Maryland under the guidance of Dr. Anthony Ephremides.

Sonjai Gupta received a Bachelor of Science degree with a university honors citation in 1993 and a Master of Science in 1996, both in electrical engineering from the University of Maryland at College Park. His research interests lie in communication networks, satellite communications and network protocols. He is currently working at Hughes Network Systems in the field of direct broadcast satellite communication.

Anthony Ephrernides received his B.S. degree from the National Technical University of Athens (1967), and M.S. (1969) and Ph.D. (1971) degrees from Princeton Univer- sity, all in Electrical Engineering. He has been at the University of Maryland since 1971, and currently holds a joint appointment as Professor in the Electrical Engineering Department and the Institute of Systems Research (ISR). He is co-founder of the NASA Center for Commercial Development of Space on Hybrid and Satellite Communi- cations Networks established in 1991 at Maryland as an off-shoot of the ISR.

He was a Visiting Professor in 1978 at the National Technical University in Athens, Greece, and in 1979 at the EECS Department of the University of California, Berkeley, amd at INRIA, France. During 1985-1986 he was on leave at MIT and ETH in Zurich, Switzerland. He was the General Chairman of the 1986 IEEE Confer- ence on Decision and Control in Athens, Greece. He has also been the Director of the Fairchild Scholars and Doc- toral Fellows Program, an academic and research partner- ship programme in Satellite Communications between Fair- child Industries and the University of Maryland. He won the IEEE Donald E. Fink Prize Paper Award (1992). He has been the President of the Information Theory Society of the IEEE (1987), and served on the Board of the IEEE (1989 and 1990).

Dr. Ephremides’ interests are in the areas of communication theory, communication systems and networks, queueing systems, signal processing, and satellite communications.

INNOVATIVE NETWORKING CONCEPTS TESTED ON THE ADVANCED COMMUNICATIONS TECHNOLOGY SATELLITE

Documents

Transcript of INNOVATIVE NETWORKING CONCEPTS TESTED ON THE ADVANCED COMMUNICATIONS TECHNOLOGY SATELLITE