RSS
High Speed Satellite Access to Biomedical Text/Image Databases
L. Rodney Long
Michael J. Gill
George R. Thoma
Abstract
This paper describes a satellite-mediated experiment in accessing biomedical databases. The experimental tool is MIRS, a prototype client/server, SQL-based system for the retrieval and display of medical information from mixed text/image databases. We have installed the MIRS client at the Laboratory for Radiological Informatics at the University of California at San Francisco and the MIRS server in our Image Processing Laboratory at the National Library of Medicine (NLM). We have run the MIRS client to do database queries and access images over a T-1 satellite link. Our initial performance evaluation has yielded results which relate to the ability of client/server systems such as MIRS to perform effectively over geosynchronous satellite links. We have developed an application-level method that allows for the efficient use of standard TCP protocol. We have evaluated this method on the T-1 link provided by the NASA geosynchronous ACTS, and measured faster delivery of cervical spine x-ray images by a factor of 2.7:1, as compared to conventional FTP.
1. Introduction
1.1 Background: satellite-mediated telemedicine
Use of satellite technology for telemedicine applications is frequently described in recent biomedical literature. Recent and current work can be classified along several dimensions: examples are maturity of technology (demonstration versus operational service), scale of coverage (international versus national or regional), and channel capacity (low versus high data bandwidth).
Grand scale international projects which have been reported in the literature include the NASA Spacebridge projects, which provided technology demonstration of long-range telemedicine plus operational remote consultation services to victims of the 1989 Armenian earthquake and to victims of the 1993 civil disturbances in Moscow. NASA is currently planning a 768 kbps satellite link to connect to a Moscow communications backbone which will include Moscow State University; the US side will connect to Texas Medical Center in Houston; one goal of the project is to continue to evolve a telemedicine link between the two countries [1]. The Spacebridge projects represent examples of demonstration systems which eventually provided operational services. (For a critique of general telemedicine needs for support of remote medical care via telecommunications--such as the support for the Armenian earthquake victims--see Llewellyn[2]).
Myers [3] describes the operation of HealthNet, a telecommunications system administered by the SatelLife organization. HealthNet uses the HealthSat satellite, operating in an 800 km polar orbit, to deliver health information to sites in the underdeveloped world. In 1994 HealthNet sites were operating in 15 African states and three Latin American countries. Each ground station served by HealthSat has at least two satellite passes per day with a minimum of 10 minutes per pass. The system is "store and forward": as HealthSat passes over a ground station, it accepts messages from that station and stores them; similarly, if it has messages in storage which are addressed to that station, it delivers them during the pass. HealthSat appears to be oriented toward text only; it can transmit or receive 100 pages per day. Medical journal tables of contents, newsletters, and sometimes abstracts are delivered. HealthNet is a mature system providing low-bandwidth data delivery on an international scale.
Within the US, the NASA Advanced Communications Technology Satellite (ACTS) has provided a testbed for various telemedicine experiments at bandwidths up to T-1 rate, including evaluation of the satellite link for transfer of medical images from a mobile vehicle to a fixed site for providing remote medical diagnosis (University of Washington); evaluation of the link for use in transfer of patient data and for two-way voice communications from a mobile vehicle en route to hospital (Jet Propulsion Laboratory); evaluation of the link for remote ophthalmological examination and diagnosis (NASA Johnson Space Center); evaluation of T-1 rate video for medical applications (Mayo Foundation); evaluation of the link for collaborative telemedicine, image processing, and education (Pacific Space Center); and the NLM experiment in biomedical database access described in this paper. In addition, Georgetown University plans to use ACTS in 1996 for delivery of x-rays from Mt. Edgecumbe Hospital in Alaska to the Georgetown campus in Washington, D.C. for demonstration of teleconferencing-based telemedicine for remote patient care[4]. A second set of ACTS experiments using High Data Rate (HDR) terminals is now beginning, and will provide data rates of OC-3 (155 Mbps) or higher. Experiments planned include telemedicine applications, such as linking the Phoenix Children's Hospital to the Mayo Clinic for providing remote clinical support (Mayo Clinic Foundation); evaluation of the link for transmission of vast amounts of medical information and images, and use of remote supercomputers for radiation treatment planning (University of Hawaii) [4]. NLM also plans to participate in HDR experimentation, subject to the availability of a communications link to an HDR terminal.
Use of satellites in the national and global telecommunications structure continues to be of great interest, both for medical and non-medical applications. In lower bandwidth applications, satellite use appears to be growing steadily. In 1993 it was reported that the growth rate for US use of Very Small Aperture Terminals (VSATs) was 15 per cent annually, and the reported VSAT growth rate internationally was 20 to 25 per cent.[5] High-bandwidth satellite communications experiments are ongoing or imminent, as NASA's High Data Rate (HDR) terminals become available to provide OC-3 and higher communications rates via ACTS.
It also should be noted that the role of satellites in building the envisioned National Information Infrastructure (NII) may be significant. In [6] Kirkwood argues that economic considerations will force a move toward more use of satellites as compared to fiber for meeting the NII national connectivity goals of the year 2000.
1.2 Online access to large data sets
Online access to biomedical text information in the form of bibliographic citations and journal abstracts has been routine for decades. Such data has been delivered via the public telephone system and value-added networks, and more recently the Internet. At the Lister Hill National Center for Biomedical Communications, a research and development division of NLM, we are exploring approaches to the delivery of more complex information sets. We have initially focussed on the delivery of database records consisting not only of text but of associated images, such as digitized medical x rays. Future work may expand the accommodated data types to include the full spectrum of multimedia data: 3-D images, sound, and video. Database records with any of these data types are usually orders of magnitude larger than simple text records. This data scaling factor alone is sufficient to require special system design considerations for multimedia systems: more storage is required; moreover, the storage media itself may change--a magnetic disk which holds 1,000,000 1Kbyte text records will hold only 200 cervical spine xrays; hence, the system developer may need to invest in RAID technology or, alternatively, a magneto-optical or tape jukebox system with their slower access times relative to magnetic storage; storage requirements for the user may change, too, since a database system typically lets the user save selected records to local storage; finally, the client/server communication channel bandwidth should be adequate to allow a reasonable system response from the user's viewpoint.
We have developed a prototype client/server system for the delivery of records containing text and associated 2-D imagery. Estimated delivery times for such imagery are shown in Tables 1 and 2 (based on data from [7]), as a function of communication channel used.
If we take, for purposes of discussion, a response time of 1 minute as a system goal, then Table 1 shows that for small images, we can transmit a query response from the server of 10 images even on today's Internet, using conventional FTP. (The 1 minute system goal compares well with the approximate average search time reported in some text-only medical database systems for hospitals [8].) For large images, however, Table 2 shows that T-1 rate is required to transmit even one image in less than a minute. Even T-1 does not allow for the timely (< 1 minute) delivery of multiple records containing large medical images. (Tohme [9] presents a more extensive analysis of transmission demands for support of digital radiology applications in the clinical environment and similarly concludes that T-1 rate is not sufficient for high volume teleradiology/telemedicine applications.)
MIRS (Medical Information Retrieval System), the client/server application we have developed, is potentially well adapted to bandwidth-limited conditions in that it lets the user download a specified number of records with associated small, low-resolution images for review: this control over the data flow is intended to guarantee reasonable response times for the user. In addition, the user may download a large, high-resolution version of any of the record images.
In the sections below we describe the design and functionality of the MIRS client/server system, shortcomings of the transmission protocol limiting the timely reception of image data at the client, special considerations relative to communication via geosynchronous satellites, an experimental technique to speed up data transmission, initial results from the experiment using MIRS, and a summary and conclusions.
2. MIRS
The Medical Information Retrieval System (MIRS) is designed with a separation of client/server communication channels between low- and high-bandwidth data: text is sent down one path, while images are sent down a second path. This separation allows the text transmission to be handled by the conventional TCP methods used by an off-the-shelf database management system, while the image transmission is handled by our custom-written multisocket transmission method.
MIRS provides users a Graphical User Interface (GUI) to assist in the generation of queries in Structured Query Language (SQL). After the NHANES II database has been selected the query which has been entered on the screen is a search for all database records which satisfiy the search criteria: females over age 60 who have cervical spine pain of any degree (minimal, maximal, or moderate), according to the findings of the physician's examination. To construct the query, the user creates search relations by interacting with list and edit boxes which are dynamically displayed and removed from the screen, as they are needed. These relations, such as "age > 60", appear in the Query Construction Area box as they are created. The user then combines these relations with logical operators to form the final SQL query, which appears in the Constructed Query box.
After the database manager has completed its search, the user is presented a Matches screen (not shown) for specifying how many of the database hits are to be batched together for downloading to the local user workstation at one time; this is the system response time control described earlier. In addition, the user may optionally specify the types of images which are to be downloaded. The NHANES database may contain two types of images (cervical or lumbar spine); the user may selectively control which of these is sent to the user's local workstation.
The Database Information screen is then displayed with the query results. Multiple low-resolution images are displayed at the top, while the text part of one record appears below. An image cursor always highlights the image corresponding to the text currently being displayed. If the user moves the mouse pointer to another image and clicks, the text will update to correspond to that image, and the image cursor will highlight that image. The user may also navigate through images by using a slider control to quickly move through all of the downloaded batch in a smooth, continuous stream. Alternatively, the user may use the next record/prev record buttons to step through the text records. As a new text appears, the image cursor will move to highlight the associated image.
Finally, the user may request downloading of the full-resolution image corresponding to any of the screen images. The resulting full-resolution image (not shown) appears on a conventional Sun 1152 x 9 00 monitor. Since the image size (1463 x 1755) exceeds the screen resolution, only a part of the image is viewable at one time. However, horizontal and vertical scrollbars allow roaming over the entire image.
3. Factors affecting transmission rate
3.1 Communications protocol considerations
Like most client/server applications compatible with Internet use, MIRS uses TCP/IP communications protocol. Internet Protocol (IP) provides addressing and encapsulation of the data in the form of TCP packets, but not guaranteed delivery. Transport Control Protocol (TCP) adds guaranteed delivery (by retransmitting lost packets if necessary), error checking, and flow control. Together, TCP and IP guarantee that a data buffer can be transmitted and received reliably and with preservation of the data integrity.
TCP is a complex algorithm with many features designed to facilitate communications in the Internet environment shared by many users, and using communications end-points on processors which may have vastly differing computing capabilities and storage capacities. This latter consideration leads to a TCP data flow control algorithm intended to deliver data efficiently, but no faster than the the receiver can accept the data. Reference [10] provides detailed discussions of TCP algorithms, including data flow control.
In TCP data transmission the TCP sending process maintains a window on the stream of data to be transmitted. Only packets lying within the sending window have permission from TCP to be transmitted, regardless of the availability of bandwidth and CPU power to transmit more packets. This window size is calculated dynamically by TCP during the sending process; a key factor in the calculation of the current sending window size is the size of the window maintained by the TCP receiving process. This receiving window size represents the amount of data the receiving end is prepared to accept at any particular point in time, and is a function of how fast the receiver can read the TCP buffers where the data is being received. The sending window will be no larger than the current receiving window. The receiving window size is advertised in the TCP header in packets sent from the receiver back to the sender to acknowledge data packets which have been received. Current TCP allows only two bytes in the TCP header for this advertised window size.
This means that the advertised receiving window size, and hence the sending window size, is limited to 64 Kbytes (specific operating systems may implement TCP with an even smaller upper bound on the advertised window, even though the TCP header will accommodate 64K). This represents a fundamental limitation in current TCP transmission rate, both on the Internet and even in the context of a dedicated, contention-free channel. The effects of this limitation are pronounced on the transmission of large files only and represent no significant limitation for transmission of small files.
A second factor limiting TCP transmission rate is congestion control. TCP attempts to detect channel congestion by monitoring how long transmitted packets have remained unacknowledged. If TCP detects congestion, it shrinks the sending window, regardless of the size of the advertised receiving window. This is an important and possibly dominant factor on many Internet connections. On a clean dedicated channel with little packet loss or none, we expect it to have little effect on the transmission rate.
A third factor, identified by Kruse [11] is the TCP "slow-start" algorithm. Regardless of advertised receiving window size, TCP begins its transmissions by sending only one packet. When this is successfully acknowledged, it increases the sending window gradually, until it reaches the size of the advertised receiving window. This conservative approach to beginning the transmission is likely designed to avoid immediately creating congestion on the Internet. For small files, this factor can contribute to a significant part of the transmission time, particularly when there is a large delay time between sending packets and receiving the returning acknowledgments. This applies in particular to the case of a geosynchronous satellite link.
To achieve a higher transmission rate than is possible on a single TCP channel because of these limitations, we have implemented an NLM-developed algorithm which simultaneously opens multiple TCP channels for file transmission. This algorithm, called "multisocket" transmission (from the "sockets" terminology used to describe communications end-points in Unix software) has been implemented at NLM and tested on the Internet and over our ACTS geosynchronous link. On the Internet by using five TCP channels, we have observed increased transmission rates from 1.6:1 to 3.5:1, as compared to standard FTP (one channel TCP). See [12] and [13] for a description of Internet tests and results. Satellite link results are discussed in the next section. Allman, Ostermann, and Kruse [14] have described work done independently of our own which uses a similar strategy of exploiting multiple TCP channels for transmission.
3.2 Geosynchronous satellite link considerations
The effect of the signal path of the geosynchronous satellite link must be taken into account independently of the characteristics of current TCP. Even though the geosynchronous link delay exacerbates the TCP slow-start effect, this type of link would pose problems for interactive communication even if the slow-start algorithm were removed. For a simple example, consider running ordinary Telnet in character mode over such a link. When a user runs Telnet, he logs in to a remote machine, then enters text commands on a Telnet command line provided on his local terminal. As a user types, the Telnet program sends the characters typed by the user, one at a time, to the remote machine, which echos them back, one at a time, to the user; each character appears on the user's command line after it has made the round trip to the remote machine and back. On a geosynchronous satellite link, the round trip time is approximately 600 ms: the effect on a user is very obvious-- regardless of how fast he types, his text appears on the screen in a staccato, character-punctuated-by-delay fashion. (For comparison, we have measured round-trip delay times on the Internet to be around 100 ms for coast-to-coast transmissions - keeping in mind variability in Internet delays due to contending traffic.)
Any application which relies on many small transactions with a remote machine over such a link must take these effects into account if it is intended to serve an interactive user. A designer may consider the possibility of batching a number of transactions into one transmission request, for example. (In the case of Telnet, a line mode option is provided; in this mode, the local machine echoes the user's text as he types; only when an entire line is entered is the transmission made.) Alternatively, work being done by the remote machine may be reallocated to the local machine, if the application allows.
These considerations for geosynchronous links appear to place additional design burdens on the developer of highly interactive client/server applications.
4. Experimental results
4.1 Experimental setup
NLM's experiment is conducted via a Wide Area Network T-1 link which travels a terrestrial T-1 line and a satellite link segment via the NASA Advanced Communications Technology Satellite (ACTS). NLM is connected via a terrestrial T-1 line to Very Small Aperture Terminal (VSAT) equipment in the Center for Satellite and Hybrid Communications Networks at the University of Maryland at College Park (UMCP). The ACTS segment consists of a satellite link connecting the UMCP VSAT to the VSAT at the Laboratory for Radiological Informatics at the University of California at San Francisco (UCSF). In the following, the link is described starting at the NLM Lab location extending through UMCP over the ACTS satellite and ending at UCSF.
At the NLM Lab, the WAN connection begins at a Cisco 4000 router connected to a DSU. On the LAN side is a 10Base-T concentrator that provides the LAN for two Suns and the router. From NLM to UMCP and the VSAT the facilities include NIH fiber and copper media thru a Digital Access Cross Connect connected to a Bell Atlantic T1. The VSAT consists of an outdoor 1.2 m. antenna and indoor equipment. Uplink/downlink is at 30/20 GHz. ACTS is an experimental geosynchronous equatorial satellite operating in the Ka band and put into orbit in 1993. Its features include on-board switching, fast-hopping spot beams, and on-demand-assignment access. It operates in a 2.5 GHz bandwidth with dynamic rain fade compensation.
At UCSF the VSAT dish is mounted on a fifth floor loading dock canopy with the terminal racks located in a nearby computer room. The associated equipment racks provide T1 output to a Cisco 2510 router. The LAN interface to the router is through Ethernet over an inter-building fiber optic link directly to an Ethernet port on a Sun Sparc IPC workstation. The Sun IPC is connected to a router via another Ethernet connection. Internet connectivity for test setup and configuration is via this other router.
4.2 Multisocket algorithm performance on the satellite link
We have tested the NLM multisocket algorithm on our ACTS link by transmitting 5 Mbyte cervical x-ray image files from two remote sites to NLM. The first transmitting site was the NASA Lewis Research Center (Cleveland), where the transmitting machine was a Sun IPX running SunOS 4.1.3. The second site was the Laboratory for Radiological Informatics at UCSF (San Francisco), where the transmitting machine was a Sun IPC running Solaris 2.4. The receiving machine in both cases was a Sun 670MPmachine at NLM running Solaris 2.3. In each case we collected data by varying the number of TCP channels used in the multisocket transmission from 1 to 20 and recording the transmission times as a function of number of channels used. The curve labelled Application data gives the transmission rates as seen by an application doing file-to-file transfer; it includes not only the transmission times, but the times required to read and write the file on the sending and receiving machines. This curve was plotted for comparison with FTP performance, since the time reported by FTP also includes file read/write times. The data for the Application data curve was directly measured by inserting time-recording checkpoints into our software. The curve labelled Raw data represents the transmission rate observed for the channel transmission alone; it also takes into account the packet overhead required to transmit the application data. The Raw data curve was derived from the Application data measurements by subtracting out file read and write times and by adding the size of the TCP, IP, and Data Link control headers to the size of the application data packets transmitted. Finally, the observed (conventional, 1-channel) FTP rate is plotted as a horizontal reference line.
For the transmission from Cleveland we observed an FTP rate of 40 Kbytes/sec. With multisocket, we reached maximum throughput using 7 channels, where we recorded an application throughput for file-to-file transfer of about 109,000 bytes/sec. This is 2.7 times FTP rate. The corresponding raw data throughput is about 161,000 bytes/sec, about 84% of the maximum T-1 rate.
For the transmission from San Francisco we observed an FTP rate of 20 Kbytes/sec. With the multisocket technique, we required 11 channels to achieve approximately the same results as for the Cleveland transmission. (File-to-file transfers: 101,000 bytes/sec; raw data transfers: 156,000 bytes/sec. Note that for this sending site, the multisocket rate was 5 times the observed FTP rate.)
In addition to the experiments in methods to achieve faster transmission of a single file, we have applied the multisocket technique to mass file transfers, such as would be required for the transfer of significant parts of a large digital image library. Experiments were conducted in the transfer of 1- and 5-Mbyte cervical spine x-ray images, and 7 Mbyte Visible Human digital color photo images. The goal was to move as many images as possible file-to-file across the satellite link between NLM and UCSF in a fixed amount of time. Results are shown in Table 1. Ideally, the data rate of the mass file transfers should be the same as for a single file; in practice, however, efficiency may be lost in waiting for the operating system to free previously-used resources (such as ports used for the communication) and in occasional, random transmission failures--the current multisocket implementation is experimental and has no error recovery mechanism. We are continuing to refine the software set-up to make the mass file transfer rate approach the singe file transfer rate.
Our experiments have shown that the multisocket method is an effective way of achieving faster bulk file throughput using TCP over a geosynchronous satellite link. We are continuing to work to investigate the differences in FTP rate observed between the two sending sites, and the differences in number of channels required to reach maximum throughput.
4.3 MIRS performance on the satellite link
We have installed the MIRS client at UCSF on the same machine used for the multisocket testing. We have made initial test runs and recorded the results obtained in Table 2. For the results shown here, the query used was "Find all persons in the database older than 50."
As shown in Table 2, for comparison with the system response times over the satellite link, we have included timings for the same operations done in our local lab environment, where both the Client and Server are on the same Ethernet. At the present time, we do not have comparative results for MIRS performance over the Internet.
We are investigating the performance differences of each of these steps. Some of the observed differences, in particular the difference in start-up times (1) may be due primarily to differences in the client machines and hardware configurations being used. Steps (4-6) are considerably slower than expected. In each of steps (4-5) only about 1 Mbyte of image data is being transferred; in step (6) 5 Mbytes of image data are being transferred. We have been able do file-to-file transfers of 5 Mbyte files consistently over ACTS in less than 50 seconds independently of MIRS.
Since MIRS is based on the X windows system, one of the areas we are investigating is whether a large volume of X traffic is occurring for X window management or other X processing. As we have previously discussed, a large number of exchanges on the geosynchronous link, even if files are of small size, can have a large effect on performance.
5. Conclusion and future directions
The use of satellite technology in telemedicine applications has been shown to be promising by projects such as NASA Spacebridge, SatelLife HealthNet, and NASA ACTS. Much of this technology is applicable to providing access to general digital library information. An important question is, how seamlessly will current applications, common design practices, and communications protocols fit into a geosynchronous satellite network and how efficiently will they operate?
We have experimented with the TCP protocol on the geosynchronous link provided by the ACTS and conclude that:
- (1) the well-known window size limitation in current TCP can be effectively overcome by applying a multisocket algorithm on a dedicated geosynchronous satellite channel; this is effective for giving higher throughput rate on large bulk file transfers than is available by conventional FTP;
- (2) the TCP slow-start algorithm contributes to a significant part of the transfer time for small files on the geosynchronous link, as pointed out by Kruse [11].
- Further, the signal delay inherent in the geosynchronous link creates a special consideration which must be taken into account for designers of highly interactive systems intended to operate on such links.
- Future versions of TCP protocol may allow advertisement of a larger receive window size and may modify the slow-start algorithm to avoid its deleterious effects on small-file transmission over the geosynchronous link.
- For highly-interactive applications, choices appear to be to avoid the geosynchronous environment altogether, by using low-earth orbit satellite links (see [15]), or other communications links, or to dedicate design time to optimally batch interactions for transmissions over the link. In applications where the user has a high input bandwidth requirement, but a low output requirement, a third option has been investigated: a conventional, terrestrial link (e.g. the Internet) is used to handle the user's small-bandwidth, interactive transactions, but a high-bandwidth satellite link is used to deliver large amounts of data to the user when required. This technique has been experimentally investigated using an ACTS VSAT connection and is reported by Friedman in [16].
- Future plans: NLM is currently scheduled to be connected to the Advanced Technology Demonstration Network (ATDnet). The ATDnet is sponsored by the Advanced Research Projects Agency (ARPA) and uses ATM protocols over SONET facilities. It acts as a testbed for high performance communications between Washington D.C. area federal agencies including NASA and NLM. Planned activities include investigation into performance and interoperability issues involving online access to complex information sets using ATM with collaborators at UCSF through use of ATDnet and remote ATM networks. High Data Rate Terminals at NASA GSFC and the Jet Propulsion Laboratory (JPL) will extend ATM service to the West Coast via the ACTS. ATM connectivity to the JPL will also be required.
Acknowledgments: We gratefully acknowledge the support of the NASA ACTS Project and Experiments Office, especially Ron Schertler, Chief of the ACTS Experiments Office, and our liaison, Barry Fairbanks of the Analex Corporation; our collaborators in the ACTS experiments, Dr. H.K. Huang and Todd Bazzill of the UCSF Laboratory for Radiological Informatics; the UMCP support provided by Dr. Timothy Kirkwood and his staff at the Center for Satellite and Hybrid Communications Networks; and the invaluable networking consultation and support provided by Dr. Hans Kruse of Ohio University.
We are also indebted to Dr. Stanley Pillemer and Reva Lawrence of the National Institute of Arthritis and Muscuoloskeletal and Skin Diseases and Dr. Ami Ostchega of the National Center for Health Statistics for their support and guidance in developing applications such as MIRS to provide new medical information resources to researchers across the nation.
| File type | Number of transfers |
Elapsed time (h:mm:ss) |
Rate (bytes/hour x 106) |
|---|---|---|---|
| 1 Mbyte cerv spine | 884 | 4:18:38 | 215 |
| 5 Mbyte cerv spine | 70 | 1:00:00 | 359 |
| 7 Mbyte VH color | 94 | 53 | 2:03:51 |
| User request (MIRS client) | System response (MIRS server) | Sat | Lab |
|---|---|---|---|
| Start | Login screen | 55 | 19 |
| Login | Query screen | 10 | 2 |
| Submit query | Search database | 14 | 7 |
| Download first 10 records (low-res images) | First Database Information screen | 2:55 | 27 |
| Download next 10 records | Next Database Information screen | 3:10 | 28 |
| Download full-res image | Full-res image screen | 4:09 | 37 |
References
1. Ferguson EW, Doarn CR, Scott JC. Survey of global telemedicine. The Electronic Library, vol. 13(4), August 1995, 35-46.
2. Llewellyn CH. The role of telemedicine in disaster medicine, Journal of Medical Systems, vol. 19(1), 1995, 29-34.
3. Myers G, Nkabinde T, Blaauw D. HealthLink: SatelLife and HealthNet in South Africa. The Electronic Library, vol. 13(4), August 1995, 293-297.
4. Proceedings of ACTS Results Conference; NASA Lewis Research Center, Cleveland, OH, September 11-13, 1995, Experiments Summary section.
5. Flanagan P. VSAT: A market and technology overview. Telecommunications, March 1993, 19-24.
6. Kirkwood TJ, Campanella SJ. Satellites in the national information infrastructure. American Institute of Physics Conference Proceedings 325, Albuquerque, NM, January 8-12, 1995.
7. Long LR, Thoma GR. Medical image database access via satellite (MIDAS). Proceedings of ACTS Results Conference; NASA Lewis Research Center, Cleveland, OH, September 11-13, 1995, VSAT section.
8. Safran C, Porter D, Lightfoot J, Rury CD, Underhill LH, Bleich HL, Slack WV. ClinQuery: a system for online searching of data in a teaching hospital. Annals of Internal Medicine, vol. 111(9), November 1, 1989, pp. 751-756.
9. Tohme WG, Rodgers JE, Mun SK, Freedman MT, Popescu G, Yun DYY, Chen-Garcia HM, Carlson W, May S, Cook JF. The NASA Advanced Communications Technology Satellite: the Georgetown experience, Proceedings of ACTS Results Conference; NASA Lewis Research Center, Cleveland, OH, September 11-13, 1995, HDR section.
10. Feit S. TCP/IP Architecture, Protocols, and Implementation. McGraw-Hill, New York, 1993.
11. Kruse H. Performance of common data communications protocols over long delay links: an experimental evaluation. Proceedings of the 3rd International Telecommunication Systems Modelling Conference, Nashville, TN, March 1995.
12. Long LR, Berman LE, Thoma GR. An application-level technique for transmission of large images on the Internet. Proceedings of SPIE: Multimedia Computing and Networking 1995, Vol. 2417, San Jose, CA, February 6-8, 1995, 116-129.
3. Long LR, Berman LE, Thoma GR. Client/Server design for fast retrieval of large images on the Internet. Proceedings of the 8th A Symposium of Computer-Based Medical Systems (CBMS'95), Lubbock TX, June 9-10, 1995; pp.284-291.
14. Allman M, Ostermann S, Kruse H. Data transfer efficiency over satellite circuits using a multi-socket extension to the File Transfer Protocol (FTP). Proceeedings of ACTS Results Conference; NASA Lewis Research Center, Cleveland, OH, September 11-13, 1995, Network section.
15. Campanella SJ, Kirkwood TJ. Faster than fiber: advantages and challenges of LEO communications satellite systems. American Institute of Physics Conference Proceedings 325, Albuquerque, NM, January 8-12, 1995.
16. Friedman D, Gupta S, Zhang C, Ephremides A. The ACTS experiments program at the Center for Satellite and Hybrid Communication Networks. Proceeedings of ACTS Results Conference; NASA Lewis Research Center, Cleveland, OH, September 11-13, 1995, VSAT section.
17. Dendy R. T1 VSAT User Technical Handbook, Revision 1, 9 June 1992. Analex Corp. ACTS Project Office.
18. High Performance Computing and Communications: Foundation for America's Information Future, a report by the Committee on Information and Communications, National Science and Technology Council, 1995, 14.
19. ACTS Systems Overview, Insert Number 5 (revised) August 1994, ACTS Program Office.
National Institutes of Health (NIH)
U.S. Dept. of Health