delay tolerant network (Download Full Report And Abstract)
computer science crazy|
Joined: Dec 2008
22-02-2009, 12:49 AM
Consider a scientist who is responsible for the operation of robotic meteorological station located on the planet Mars (Fig. 1). The weather station is one of several dozen instrument platforms that communicate among themselves via a wireless local area network deployed on the Martian surface. The scientist wants to upgrade the software in the weather stationâ„¢s data management computer by installing and dynamically loading a large new module. The module must be transmitted first from the scientistâ„¢s workstation to a deep space antenna complex, then form the antenna complex to a constellation of relay satellites in low Mars orbit (no one of which is visible from Earth ling enough on any single orbit to receive the entire module), and finally from the relay satellites to the weather station.
The first leg of this journey would typically be completed using the TCP/IP protocol suite over the Internet, where electronic communication is generally characterized by:
Â¢ Relatively small signal propagation latencies (on the order of milliseconds)
Â¢ Relatively high data rates (up to 40 Gb/s for OC-768 service)
Â¢ Bidirectional communication on each connection
Â¢ Continuous end-to-end connectivity
Â¢ On-demand network access with high potential for congestion
However, for the second leg a different protocol stack would be necessary. Electronic communication between a tracking station and a robotic spacecraft in deep space is generally characterized by:
Â¢ Very large signal propagation latencies (on the order of minutes; Fig. 2)
Â¢ Relatively low data rates (typically 8-256 kb/s)
Â¢ Possibly time-disjoint periods of reception and transmission, due to orbital mechanics and/or spacecraft operational policy
Â¢ Intermittent scheduled connectivity
Â¢ Centrally managed access to the communication channel with essentially no potential for congestion
The combination of ling signal propagation times and intermittent connectivity-caused, for example, by the interposition of a planetary body between the sender and the receiver-can result in round-trip communication delays measured not in milliseconds or even minutes but in hours or days. The Internet protocols do not behave well under these conditions, for reasons discussed later in this article.
Yet a retransmission protocol of some sort is required to assure that every bit of the new executable module is correctly received. Forward error correction (FEC) can reduce data loss and corruption, but it consumes bandwidth whether data are lost or not, and it offers no protection against sustained outage. Optimum utilization of meager links demands automated repeat request (ARO) in addition to some level of FEC what in needed on this part of the route is an ARO system fir efficient retransmission on the link.
Recent developments in deep space communications technology have begun to address this problem. Over the past 20 years the Consultative Committee for Space Data Systems (CCSDS) has established a wide range of standards for deep space communications, including Telecommand and Telemetry wireless link protocols for spacecraft operations. A recent addition to this program is the CCSDS File Delivery protocol (CFDP) which is designed for reliable file transfer across interplanetary distances .The CFDPRP link ARQ system in Fig. 1 is a hypothetical protocol that would be constructed by, in essence, implementing just the data retransmission procedures specified for CFDP. (Note that although CFDP implementations exist, the CFDP-RP stand alone subset has not yet been isolated for the purpose proposed here.)
For the final delivery of the module from the relay orbiters to the weather station on its wireless LAN, TCP/RP might again be the best choice .But now TCP/IP would be running over wireless link protocols, perhaps CCSDS Proximity-1 to the satellites and 802.11b among the landed assets. As in interplanetary space, and in contrast to the wired Internet, data rates on these links are likely to be fairly low, and the potential for congestion will be low for the foreseeable future.
Since no single stack will perform satisfactorily on all segments of the route, no single protocol immediately below the application layer is suitable for end-to-end use in this scenario. How then can the application operate?
This is not an altogether new problem. The three different sets of physical and operational constraints described above define very different networking environments. Protocols that enable effective communication within each of these environments have been developed and are continually being improved, and techniques already exist for forwarding data between environments that differ in less radical ways. For example, IP routers typically convey traffic between adjacent subnets running at different data rates; transport-level proxies can bridge between TCP connections tuned to different data loss profiles and relatively small differences in signal propagation time. But for large differences in the scale of round-trip latency, wholly different transport mechanisms are needed.
AN OVERVIEW OF CFDP
One approach to reliable transport that can tolerate extremely long and variable round-trip latency is reflected in the design of CFDP . CFDP can operate in either acknowledged (reliable) or unacknowledged mode; in acknowledged mode, lost or corrupted data are automatically retransmitted. CFDPâ„¢s design includes a number of measures adopted to enable robust operation of its ARQ system in high-latency environments:
Â¢ Because the time required establishing a connection might exceed the duration of a communication opportunity, there is no connection protocol; communication parameters are managed.
Â¢ Because round-trip latency may far exceed the time required to transmit a given file, CFDP never waits for acknowledgment of one transmission before beginning another. Therefore, the retransmitted data for one file may arrive long after the originally transmitted data for a subsequently issued file, so CFDP must attach a common transaction identifier to all messages pertaining to a given file transmission.
Â¢ Because a large number of file transmissions may concurrently be in various stages of transmission, retransmission buffers typically must be retained in nonvolatile storage; this can help prevent catastrophic communications failure in the event of an unplanned power cycle at either the sender or the receiver.
Download Full Report And Abstract