InterPlaNetary Internet: state-of-the-art and research challenges

Computer Networks 43 (2003) 75–112 www.elsevier.com/locate/comnet InterPlaNetary Internet: state-of-the-art and research challenges € zg€ Ian F. Akyildiz, O ur B. Akan *, Chao Chen, Jian Fang, Weilian Su Broadband and Wireless Networking Laboratory, School of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta, GA 30332, USA Received 30 June 2003; accepted 3 July 2003 Responsible Editor: I.F. Akyildiz Abstract The developments in the space technologies are enabling the realization of deep space scientific missions such as Mars exploration. InterPlaNetary (IPN) Internet is expected to be the next step in the design and development of deep space networks as the Internet of the deep space planetary networks. However, there exist significant challenges to be addressed for the realization of this objective. Many researchers and several international organizations are currently engaged in defining and addressing these challenges and developing the required technologies for the realization of the InterPlaNetary Internet. In this paper, the current status of the research efforts to realize the InterPlaNetary Internet objective is captured. The communication architecture is presented, and the challenges posed by the several aspects of the InterPlaNetary Internet are introduced. The existing algorithms and protocols developed for each layer and the other related work are explored, and their shortcomings are pointed out along with the open research issues for the realization of the InterPlaNetary Internet. The objective of this survey is to motivate the researchers around the world to tackle these challenging problems and help to realize the InterPlaNetary Internet.
2003 Elsevier B.V. All rights reserved. Keywords: InterPlaNetary Internet; Deep space networks; Space missions; Architecture; Transport layer; Network layer; Data link layer; Physical layer technologies; Deep space time synchronization 1. Introduction The developments in the space technologies are enabling the realization of deep space scientific * Corresponding author. Tel.: +1-404-894-5141; fax: +1-404894-7883. E-mail addresses: [email protected] (I.F. Akyildiz), € .B. Akan), [email protected] (C. [email protected] (O Chen), [email protected] (J. Fang), [email protected] (W. Su). missions such as Mars exploration. The vision of future space exploration includes missions to deep space that require communication among planets, moons, satellites, asteroids, robotic spacecrafts, and crewed vehicles. These missions produce significant amount of scientific data to be delivered to the Earth. In addition, these missions require autonomous space data delivery at high data rates, interactivity among the in-space instruments, security of operations, and seamless inter-operability between in-space entities. 1389-1286/$ - see front matter
2003 Elsevier B.V. All rights reserved. doi:10.1016/S1389-1286(03)00345-1 76 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 For successful transfer of scientific data and reliable navigational communications, NASA enterprises have outlined significant challenges for development of next-generation space network architectures. The next step in the design and development of deep space networks is expected to be the Internet of the deep space planetary networks and defined as the InterPlaNetary (IPN) Internet [107]. The InterPlaNetary Internet is envisioned to provide communication services for scientific data delivery and navigation services for the explorer spacecrafts and orbiters of the future deep space missions [9]. Many of these future planetary missions, which will be performed by the international space organizations such as NASA and European Space Agency (ESA), have already been scheduled for the next decade. These missions are summarized along with their timelines and objectives in Table 1 [12,105]. As shown in Table 1, all of these future space missions have a common objective of scientific data acquisition and delivery, which are also the main possible applications of the InterPlaNetary Internet described as follows [18]: • Time-Insensitive Scientific Data Delivery. The main objective of InterPlaNetary Internet is to realize communication between in-space entities allowing large volume of scientific data to be collected from planets and moons. • Time-Sensitive Scientific Data Delivery. This type of application is required to deliver great volumes of audio and visual information about the local environment to Earth, in-situ controlling robots, or eventually in-situ astronauts [18]. • Mission Status Telemetry. The status and the health report of the mission, spacecraft, or the landed vehicles could be delivered to the mission center or other nodes. This application requires periodic or event-driven, unreliable transmission services. • Command and Control. Another important application of the InterPlaNetary Internet is the command and control of in-situ elements. The closed-loop command and control may involve in direct or multi-hop communication of the remote nodes, i.e., Earth station controls the mis- sion rover on planet surface, or close proximity nodes, i.e., planetary orbit controls the lander. It is clear that the InterPlaNetary Internet is expected to extend the current space communications capabilities to a point where the boundaries between the terrestrial and space communications become transparent. The experience obtained, thus far, from the space missions help to understand the unique challenges posed by the deep space communication environments. For example, the current communication infrastructure deployed for the NASAÕs Deep Space Network (DSN) [103] provides significant research and implementation experience which also constitutes the basis to step up the development of the required technologies for next generation deep space communications and hence the InterPlaNetary Internet. From the experience obtained via previous space missions and based on the communication requirements of the future space missions, NASAÕs Space Science Enterprise aims three-step deployment strategy for Mars Exploration communication architecture, i.e., near-term (2001–2010), mid-term (2010–2020), and far-term (beyond 2020) [9]. Some of the future deep space missions summarized in Table 1 such as Mars Reconnaisance Orbiter, Mars 2007, and Mars 2009 will play crucial roles in the realization of the Mars Exploration communication architecture. Along with the NASAÕs Mars exploration mission, the InterPlaNetary Internet Special Interest Group (IPNSIG) within the Internet Society foresees to make Mars as the first true extension of the Internet by the 2005–2007 timeframe [13]. However, there exist significantly challenging and unique characteristics of the deep space networking paradigm that need to be addressed for this objective as follows: • extremely long and variable propagation delays; • asymmetrical forward and reverse link capacities; • high link error rates for radio-frequency (RF) communication channels; • intermittent link connectivity; • lack of fixed communication infrastructure; • effects of planetary distances on the signal strength and the protocol design; I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 77 Table 1 Future InterPlaNetary mission timeline Mission name Schedule Description and objective Mars Exploration Rover June 2003 Smart-1 Galaxy Evolution Explorer Rosetta Messenger July 2003 2003 To gather data to help determine if life ever arose on Mars, characterize the climate of Mars, characterize the geology of Mars, and prepare for human exploration of Mars To test spacecraft technologies for future missions To measure star formation 11 billion years ago using ultraviolet wavelengths February 2004 March 2004 Deep Impact December 2004 CloudSat Mars Reconnaisance Orbiter 2004 July 2005 Venus Express New Horizons November 2005 January 2006 Dawn May 2006 Kepler October 2006 Europa Orbiter 2008 LISA 2007 Mars 2007 Late 2007 Mars 2009 Late 2009 BepiColombo January 2011 Comet orbiter and lander to gather scientific data To study the surface composition, geologic history, core and mantle, magnetic field, and tenous atmosphere of Mercury, and to search for water ice and other frozen volatiles To investigate the interior of the comet, the crater formation process, the resulting crater, and any outgassing from the nucleus, particularly the newly exposed surface Three satellites as the first spacecraft to study the clouds on a global basis To study Mars from orbit, perform high-resolution measurements including images with a resolution of 20–30 cm, and possibly serve as communications relay for later Mars landers until about February 2010 ESA mission to study the atmosphere and plasma environment of Venus To fly by Pluto and its moon Charon and transmit images and scientific data back to Earth. The mission will continue on into Kuiper Belt to return further data from Kuiper Belt Objects Orbit two of the largest asteroids, Ceres and Vesta, in our solar system. The objective is to return data from these asteroids including full surface images, full surface spectometric mapping, elemental abundances, topographic profiles, gravity fiels, and mapping of remnan magnetism, if any Search for terrestrial planets, i.e., similar to Earth, using a telescope equipped with equivalent of 42 cameras to monitor the stars To study the JupiterÕs Moon EuropaÕs icy surface and attempt to determine the thickness of the ice and whether liquid water exists below the ice Joint NASA/European Space Agency mission to probe the gravity waves emitted by dwarf stars and other objects sucked into black holes Orbiters, Netlanders, Scout Missions: The French Space Agency mission to launch a remote sensing orbiter and four small Netlanders to Mars. Also, Italian Space Agency mission to launch communications orbiter to link the netlanders and future missions. Scout missions to Mars including to return samples of Mars atmosphere, networks of small landers, orbiting constellations of small craft, and a rover Smart Lander, Long Range Rover and Communication Satellite: Long-range, long-duration rover equipped to perform many scientific studies of Mars, and to demonstrate the technology for accurate landing and hazard avoidance in order to travel to difficult-to-reach sites ESA mission to study MercuryÕs form, interior structure, geology, composition, and craters origin, structure, magnetic field, composition and dynamics of atmosphere • power, mass, size, and cost constraints for communication hardware and protocol design; • backward compatibility requirement due to high cost involved in deployment and launching processes. These characteristics lead to different research challenges and hence necessitate different approaches and protocol designs at each of the networking layers for the InterPlaNetary Internet. Although some of these challenges are also 78 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 encountered in the terrestrial wireless networking domain, most of them are unique to deep space environments and they further amplify the effects of those other similar factors. Many researchers and several international research organizations are currently engaged in addressing these challenges and developing the required technologies for the realization of the InterPlaNetary Internet. In this paper, we present the survey of the proposed architectures and communication protocols and algorithms for the deep space networks and InterPlaNetary Internet. Our aim is to provide better understanding of the current research issues in this field. The remainder of the paper is organized as follows. We explore the proposed communication architectures for the InterPlanetary Internet in Section 2. In Section 3, we investigate the current and proposed protocol stacks for the communication throughout the InterPlaNetary Internet. After that, we explore the challenges, related work and the open research issues pertaining to the InterPlaNetary Internet communication protocols for each layer. We provide a detailed investigation of the transport layer issues for reliable data and multimedia transport in the InterPlaNetary Internet in Section 4. In Section 5, we introduce the challenges at the network layer for the different architectural elements of the InterPlaNetary Internet, and discuss the current related work. We then present the further research issues in the data link layer, physical layer technologies, and timing and synchronization in Sections 6–8, respectively. Finally, we state the concluding remarks in Section 9. 2. InterPlaNetary Internet architecture A common infrastructure for interplanetary networking and distributed communication technologies are needed to support the scientific research and possible commercial applications in the near future. Since Internet is truly horizontal and has a diverse set of open interoperable standards, building the space Internet on top of Internet technologies could enable any space mission to ‘‘plug in’’ with high quality of service and cost savings. Therefore, most of the network architectures proposed for the deep space exploration are based on Internet technologies. A general infrastructure is described in [10] for the NASA space Internet (similar architectural decomposition has also been used for the Mars communication network [9]), which contains the following architectural elements: • Backbone Network. It includes NASAÕs ground network and space network, NASAÕs Intranets and virtual private networks, the Internet, and any commercial or foreign communications system that may be employed. • Access Network. The communication interfaces between the backbones and the mission spacecraft and vehicles, and the local area networks onboard the spacecraft or vehicles. • Inter-spacecraft Network. The network of spacecrafts flying in a constellation, formation, or cluster. • Proximity Network. Space vehicles (rovers, airplanes, aerobots), landers, and sensors spread out in an ad hoc network. The space Internet is considered to consist of a ‘‘network of Internets’’ in [13], with a specialized deep space backbone network of long-haul wireless links interconnecting these local Internets. Internet or Internet-related protocols are used to form local networks with low delay, relatively low noise environments such as around Earth, within a free flying spacecraft, on and around another planet, etc. Specific protocols are designed for use within various environments, exploiting favorable circumstances in the environments while operating within their constraints. A new overlay protocol concept called ‘‘bundling’’ [94] is employed to tie together a set of heterogeneous Internets, performing any required additional functions that the local protocols typically cannot [14]. To build a general space Internet architecture that combines differently challenging parts, our view of the InterPlaNetary Internet is depicted in Fig. 1. It includes InterPlaNetary Backbone Network, InterPlaNetary External Networks, and PlaNetary Networks. I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 79 Fig. 1. The InterPlaNetary Internet architecture. • InterPlaNetary Backbone Network. It provides a common infrastructure for communications among the Earth, outer-space planets, moons, satellite, and relay stations placed at gravitationally stable Lagrangian points of planets [9], etc. It includes the data links (direct link or multi-hop paths) between elements with long-haul capabilities. • InterPlaNetary External Network. It consists of spacecrafts flying in groups in deep space between planets, clusters of sensor nodes, and groups of space stations, etc. Some nodes in the InterPlaNetary External Network also have long-haul communication capabilities. • PlaNetary Network. The expanded view of the PlaNetary Network shown in Fig. 1 is illustrated in Fig. 2, which is composed of PlaNetary Satellite Network and PlaNetary Surface Network. This architecture can be implemented at any outer-space planet, providing interconnection and cooperation among the satellites and surface elements on a planet.
PlaNetary Satellite Network. The satellites circling the planets can provide relay services between the Earth and the outer-space planet as well as communication and navigation services to the surface elements [55]. Some surface elements have the capability to communicate with satellites, reporting local topology upward and receiving data and commands from satellites. The PlaNetary Satellite Network includes the links between orbiting satellites, and links between satellites and surface elements. It is composed of satellites which lie in multiple layers [20] as shown in Fig. 2 and provides the following services [47]: intermediary caching and relay service between the Earth and the planet, relay service between the in-situ mission elements, and location management of PlaNetary Surface Networks.
PlaNetary Surface Network. It provides the communication links between high power surface elements, such as rovers and landers Fig. 2. The PlaNetary Network architecture. 80 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 as shown in Fig. 2, which have the capability to connect with satellites. They also provide a power-stable wireless backbone in the planet. Moreover, PlaNetary Surface Network includes surface elements that cannot communicate with satellites directly. These elements are often organized in clusters and spread out in an ad hoc manner, e.g., sensor nodes and balloons as illustrated in Fig. 2. Currently, the space stations and satellites are already deployed, which can be easily integrated into the InterPlaNetary Backbone Network. Also, in the near future, sensor nodes deployed in deep space for scientific study can be connected to the InterPlaNetary Backbone Network. According to [9], some equipments that are already planned for Mars surface missions are sensor nodes for in-situ science, rover collective, robotic outposts, and Human Exploration and Development of Space (HEDS) outposts. These equipments can be organized according to the PlaNetary Network infrastructure. The exploration sites where these equipments are deployed are called community regions as shown in Fig. 2. Within each community region, PlaNetary Surface Networks can be set up. In summary, the entire InterPlaNetary Internet architecture shown in Figs. 1 and 2 is decomposed into different sub-networks. Each sub-network faces different challenges and has its own design requirements. Therefore, a common protocol stack is needed to integrate the differently challenging parts together and to extend the terrestrial Internet into its InterPlaNetary counterpart. Meanwhile, it also leaves space for developing protocols adaptive to the peculiar circumstances in each sub-network. protocols that best fit the environment [14]. For example, a protocol stack for the InterPlaNetary Backbone Network requires protocols to handle extremely long and variable propagation delays, intermittent link connectively, and high error rates. In this section, we will explore the current and proposed protocol suites to realize communication in the InterPlaNetary Internet. The current space/ground protocol stack used by the Consultative Committee for Space Data Systems (CCSDS) is described in Section 3.1 while a proposed protocol suite for the InterPlaNetary Internet [14] is discussed in Section 3.2. 3.1. CCSDS current space/ground protocol stack The current space/ground protocol stack is proposed by the CCSDS for space communications [13,37]. The protocol stack consists of eight layers: Space Applications, Space File Transfer, Space End-to-End Reliability, Space End-to-End Security, Space Networking, Space Link, Space Channel Coding, and Space Wireless Frequency and Modulation. A specific implementation of the stack is shown in Fig. 3. It is used for Mars Exploration mission communications [13], and its functionalities are mapped to the generic eight layers of the current space/ground protocol stack as follows: Internet Earth InterPlaNetary Backbone PlaNetary Satellite Network Network Deep Space Backbone Mars Orbit PlaNetary Surface Network Mars Surface CCSDS File Delivery Protocol (CFDP) CCSDS TCP Tranquility TCP, UDP IPSEC CCSDS End-to-End Security IP CCSDS Path, Network or IP 3. Communication protocol suite The InterPlaNetary Internet consists of three major networks, i.e., InterPlaNetary Backbone Network, InterPlaNetary External Network, and PlaNetary Network as shown in Fig. 1. As different types of networks are being deployed throughout the InterPlaNetary Internet, the ability to communicate with each other is vital. Each of these components may have to run different set of Local Terrestrial Link CCSDS Long-Haul Link and Coding CCSDS Proximity Link and Coding CCSDS Link Security Local Terrestrial Wired CCSDS S, X or Ka Band CCSDS UHF CCSDS UHF (or local wired/ wireless) Fig. 3. The Mars communication protocol stack [13]. 81 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 livery Protocol (CFDP) [29] for long delay link. The CFDP is used by all the components of the InterPlaNetary Internet as shown in Fig. 3. Although the current protocol stack seems viable, there is also a need to make the protocol stack adaptable to different environmental changes allowing integration of highly optimized regional network protocols. For example, the protocols used for the Earth and Mars are different as shown in Fig. 3. As a result, a proposed protocol stack [14] for future space exploration is described in Section 3.2. It is still an ongoing research in making the stack adaptable with the perceived capabilities. 3.2. Delay tolerant networking protocol stack The ability to integrate highly optimized regional network protocols is the objective of the future space/ground protocol stack developed by the Delay-Tolerant Networking Research Group (DTNRG) [104]. The protocol stack relies on a middleware layer called bundle layer [13,14,109], that resides between the application and the lower layers. The bundle layer resolves the intermittent connectivity, long or variable delay, asymmetric data rates, and high error rates by using a store End-to-End Applications (e.g., Bundle FTP, CFDP, Bundle NTP) Bundle API Bundle TBD Services Bundle Encryption Bundle Authentication Bundle end-to-end Reliability Bundle Custody Transfer Bundle Routing • Space Wireless Frequency and Modulation. Providing efficient modulation with specified frequencies to create channels between spacecrafts. The frequency and modulation techniques are different for different parts of the InterPlaNetary Internet. For example, Earth may use local terrestrial wired while the deep space backbone uses CCSDS S, X, or Ka Band as shown in Fig. 3. For Mars orbit and Mars surface, the physical links are also different. The radio frequency (RF) and modulation standards for space communications are recommended by the CCSDS in [33]. • Space Channel Coding. Detecting/correcting errors in a noisy channel for reliable data transfer. The channel coding used for Mars orbit and surface is different than at Earth because of the noise level differences. • Space Link. Providing retransmission capability in deep space environment. Often times, data are transmitted through a very long distance. Because of this, different protocols other than the ones at Earth are needed to address this issue. For instance, the CCSDS long-haul link and coding protocol is used as illustrated in Fig. 3. • Space Networking. Providing connection oriented path for CCSDS Packet used by the Packet Telemetry and Telecommand [27,32]. • Space End-to-end Security. Providing protection against attacks on the flow of user data. Two of such security protocols are Internet Protocol Security (IPSec) and SCPS Security Protocol (SP). The IPSec is used in the Earth side, while other deep space end-to-end security protocols are required as shown in Fig. 3. • Space End-to-end Reliability. Ensuring packets in a session are arrived at the destination. For short delay communications, the CCSDS recommends TCP and TCP Tranquility, which is an extension of TCP. For non-connection oriented services, the UDP may be used. The TCP is used in Earth while TCP Tranquility is used in Mars orbit and surface. • Space File Transfer. Transferring independent files that can be assigned priority in downloading. Two current CCSDS file transferring protocols are FTP and SCPS extensions to FTP for short delay connection and CCSDS File De- Convergence Layer (specific adapters that map Bundles to underlying transmission services) Licklider Transmission Protocol (LTP) CCSDS Long-haul Link CCSDS Proximity Link TCP UDP IP SONET Ethernet Fig. 4. The bundling architecture [13]. 82 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 Application Application [PGP, etc.] Bundling [PGP, etc.] Bundling Bundling TCP TCP IP IP Ethernet Ethernet SONET Cable Workstation Cable TCP IP Fiber Internet Router IP SONET CFDP-RP ccsds Fiber R/F Tracking Station (Gateway) Ethernet Cable Spacecraft Fig. 5. An example of using bundling for deep space communication [14]. CFDP-RP is a hypothetical automated repeat request protocol implementing just the data retransmission procedures of the CFDP. and forward mechanism similar to e-mail. It sends a bundle of message fragments to the next-hop node with per-hop error control, which increases the probability of data transmission. In addition, it provides six classes of service (CoS) for the bundle [109]: (1) custody transfer, (2) return receipt, (3) custody-transfer notification, (4) bundle-forwarding notification, (5) priority of delivery, and (6) authentication. The DTN future space/ground protocol stack with the bundle layer is illustrated in Fig. 4 and the usage of the stack is shown in Fig. 5. The bundle layer consists of many services as shown in Fig. 4 that are currently being developed. Some of these services are bundle routing, bundle custody transfer, bundle end-to-end reliability, bundle authentication, and bundle encryption. The bundle layer allows the lower layer protocols to be transparent to the application layer. As a result, different types of protocols may be applied in different parts of the InterPlaNetary Internet. As shown in Fig. 4, Ethernet is used at the workstation in Earth while CFDP-RP/CCSDS is used at the tracking station (gateway) to enable communication between spacecrafts and users located on Earth. The capabilities of the bundling layer is currently being developed and should be ready by the middle of this decade [13]. Although the bundle layer enables optimization of the lower layer protocols for different types of networks throughout the InterPlaNetary Internet, there exist significant challenges in developing new protocols for each of the layers below bundling, i.e., transport, network, data link, and physical. The challenges for these lower layers are described in Sections 4–7. In addition, the challenges and current work in time synchronization are described in Section 8. It is critical that these lower layer protocols are developed for various types of deep space environments, so the bundling layer may be successfully deployed. In addition, these protocols are required to be optimized for different deep space environments. It is expected that by around 2005–2007, significant capabilities will be available to enable deep space communication for Mars Exploration mission with the InterPlaNetary Internet [13]. 4. Transport layer issues The transport layer functionalities are necessary for both the reliable transfer of the scientific data and the timely delivery of the multimedia information in the InterPlaNetary Internet. Among the architectural elements of the InterPlaNetary Internet shown in Fig. 1, the InterPlaNetary Backbone Network poses the most challenging problems for reliable data and multimedia transport in the InterPlaNetary Internet. Therefore, it plays a very significant role for the performance of the entire InterPlaNetary Internet. The most important characteristics and challenges posed by the InterPlaNetary Backbone links are listed as follows: • Very Long Propagation Delays. The deep space communication links may have extremely long propagation delays. For example, the endto-end round trip time (RTT) for the Mars– Earth communication network varies from 8.5 to 40 min according to the orbital location of the planets [43]. Similarly, the end-to-end RTT from Jupiter and Pluto to Earth vary between approximately 81.6 and 133.3 min and between 593.3 and 1044.4 min, respectively. • High Link Error Rates. The raw bit error rates on the InterPlaNetary Backbone links are on the order of 101 [43]. • Blackouts. Periodic link outages may occur due to orbital obscuration with the loss of lineof-sight because of moving planetary bodies, the interference of an asteroid or a spacecraft [10]. 83 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 • Bandwidth Asymmetry. The asymmetry in the bandwidth capacities of the forward and reverse channels is typically on the order of 1000:1 in spacecraft missions [43]. The existing transport layer protocols proposed for terrestrial, satellite, wireless, and ad hoc networks [3,4,7,22,73,99] with appropriate modifications and improvements can be applied to the InterPlaNetary External Networks and PlaNetary Networks as shown in Fig. 1. However, the above challenges posed by the InterPlaNetary Backbone Network need specifically tailored new transport layer solutions. In the next sections, we will explore the current research in this direction and the proposed solutions for the reliable data transport and multimedia delivery in the InterPlaNetary Backbone Network. 4.1. Reliable data transport in InterPlaNetary backbone network 4.1.1. Related work The challenges posed by the InterPlaNetary Backbone links need to be addressed in order to meet the communication requirements of deep space missions and to realize the InterPlaNetary Internet. In [1], however, the existing reliable transport protocols [4,11,16,50,61,62,75,76] have been shown to achieve very poor performance in deep space communication networks. The dominant factor in this performance degradation is the extremely high propagation delay in deep space links [1]. This is solely due to the window-based mechanism used by the current TCP protocols during slow start and congestion avoidance algorithms. In the slow start algorithm, the congestion window size ðW Þ is increased by one packet per received ACK until the slow start threshold ðWss Þ is reached, i.e., W < Wss . However, this approach wastes the link resources for a very long duration which is proportional to the propagation delay. For Wss ¼ 20 and RTT ¼ 20 min, it is shown in [1] that the slow start algorithm cannot utilize the link resources for approximately 120 min in deep space links. The inefficiency in link utilization due to window-based mechanisms also exists during the congestion avoidance phase, i.e., W P Wss , where the TCP source increments the congestion window size by roughly one at each RTT. As shown in Fig. 6, the existing window-based TCP protocols achieve throughput of approximately 10 bytes/s for the link capacity of 1 MB/s, packet loss probability of p ¼ 103 and RTT ¼ 40 min. In other words, the entire deep space link remains almost unutilized during the entire connection period. 600 Reno NewReno SACK Vegas FACK Westwood Tahoe Peach+ Throughput (bytes/s) 500 400 300 200 100 0 100 500 1000 1500 2000 2400 RTT (s) Fig. 6. Throughput performance of TCP implementations over InterPlaNetary Backbone links. 84 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 Note that RTT ¼ 40 min is within the RTT range for communication links between Mars and Earth, i.e., 8.5–40 min based on the orbital position [43]. Furthermore, the current TCP protocols are designed for wired links, which are reasonably assumed to have negligible bit error rates. Consequently, the packet loss based congestion detection mechanism results in unnecessary rate throttle and leads to severe throughput degradation in InterPlaNetary Backbone links [1]. Much research has been performed in recent years in order to address the throughput degradation due to wireless link errors [7]. However, these solutions cannot be directly applied to InterPlaNetary Backbone Network because of the amplifying effects of the extremely high propagation delay and the other above-mentioned characteristics on the problem. Many transport protocols [3,4,57] are proposed for satellite links, which are also characterized by high bandwidth-delay products and high bit error rates. Nevertheless, these studies mostly refer to Geo-stationary Earth Orbit (GEO) satellite links with typical RTT values around 550 ms, which are very low compared to RTTs in deep space communication links. Moreover, packet losses due the blackout conditions may also mislead the congestion control mechanisms based on packet losses. In [53], an enhancement for TCP is developed to address signal loss conditions due to mobility. However, the blackout situations in deep space links are much more complicated due to extremely high propagation delay and hence solutions as in [53] cannot be applied directly. There are more challenges which need to be addressed by the new transport protocols in InterPlaNetary Backbone Network. These challenges are consequences of the characteristics of the deep space links, and can be summarized as follows: • Delayed Feedback. TCP is expected to respond to network state. This expectation creates problems in long-delay environments, since TCP uses end-to-end signaling for its control loops. The higher RTT is experienced, the older information about link conditions is received at the source. Thus, the congestion control decision based on such past information might not lead to proper action. Therefore congestion control schemes, which react to instantaneous packet loss situations, do not yield proper response on the links with high propagation delay. • Buffer Size. In order to assure 100% reliable transport, retransmission mechanism is inevitable. However, this brings considerable amount of memory requirement. For example, the transport protocol source should maintain 1.2 GB buffer size for RTT ¼ 20 min and the average data transmission rate of 1 MB/s. There already exists an active research on transport layer protocols for space-based communication networks. Space Communications Protocol Standards-Transport Protocol (SCPSTP) [30,44] is a set of TCP extensions developed by the CCSDS for space communications. SCPS-TP is designed to support current communication environments and those of upcoming space missions [30]. SCPS-TP is developed based on the existing TCP protocols with some modifications and extensions to address the challenges posed by space-based systems such as link errors, bandwidth asymmetry, and link outages. It can provide full, best-effort and minimal reliability according to the mission specific communication requirements. The capabilities of the SCPS-TP are basically a combination of existing TCP protocols, which are shown to be inadequate in addressing the challenges in InterPlaNetary Backbone Network [1]. For example, SCPS-TP with Vegas congestion control uses window-based scheme and adopts slow-start algorithm. Although the ratebased version of SCPS-TP is under development, it disables congestion control mechanism and performs transmission with user selected fixed rate [106]. On the other hand, for example, SCPS-TP uses TCP-Vegas [11] congestion decision mechanism based on the RTT variation. However, since the window-based nature of TCP-Vegas cannot fully utilize the link, it is not even possible for it to experience the congestion and hence variation in RTT. Therefore, congestion decision based on RTT variation does not provide proper congestion control functionality. Furthermore, due to the extremely high propagation delay, the variation in RTT may not be measured accurately such that the resultant congestion control behavior may also I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 not be accurate. In [29], the CFDP is also developed by the CCSDS. The protocol can achieve reliable file transport over space links. However, it does not address the challenges introduced above and is not a transport layer protocol with required functionalities to realize high data rate reliable data transport over InterPlaNetary Internet. In [94], the bundling protocol is introduced to address the intermittent connectivity, large and variable delays, and high bit error rates. As shown in Fig. 4, the bundling protocol sits between the application and the lower layers, and performs a custody-based store-and-forward approach for the delay-tolerant networking (DTN) architecture introduced in Section 3. Furthermore, this method requires the intermediate routers to have very high amount of buffer to store the data. The amount of required buffer space further increases with increasing link delay and the data rate. Moreover, such huge buffer also requires efficient and fast buffer management schemes to prevent the transmission from being adversely effected by the store-and-forward approach. Based on the storeand-forward functionality of the bundling layer, the DTN approach incorporates tiered ARQ and tiered congestion control concepts [14] to provide reliable transmission via local retransmissions and perform congestion control on the regional basis, i.e., locally between bundling nodes instead of endto-end reliability and congestion control. Although this approach achieves reliable transport over intermittent links, it still requires a transport layer protocol, which is specifically tailored to address the same challenges, to achieve high throughput performance in bundle transport between two InterPlaNetary Internet nodes. In [45], the long-haul transmission protocol (LTP) is introduced for transmission of the bundles between bundling nodes. LTP is currently under development and described in [113] as a link-layer ARQ using some of the relevant functionalities of the CFDP file delivery protocol as add-on rather than a transport protocol like TCP. 4.1.2. TP-Planet In [2], a reliable transport protocol, TP-Planet, for InterPlaNetary Internet is introduced. TP-Planet is developed for the InterPlaNetary Backbone 85 Network where the source and sink end-points are basically InterPlaNetary Backbone nodes such as the relay satellites orbiting around the planets or the ground stations which are capable of direct deep space communications as shown in Fig. 1. It runs on top of Internet Protocol (IP) layer and does not require any specific modification to the lower layers in the current TCP/IP protocol suite. TPPlanet can be used as the transport layer protocol for both existing CCSDS protocol stack and the proposed DTN bundling protocol stack as shown in Figs. 3 and 4, respectively. Two novel algorithms, i.e., Initial State and Steady State, constitute the structure of the TPPlanet protocol. Both of the Initial State and the Steady State algorithms are developed to solve the above-mentioned challenges posed by InterPlaNetary Backbone network. The main functionalities of the TP-Planet algorithms are summarized as follows: 1. Initial State. In order to avoid the performance degradation due to the Slow Start algorithms [1], TP-Planet introduces new Initial State algorithm, which is composed of two main parts, i.e., Immediate Start and Follow-Up. The objective of the new algorithm is to capture available link resources as soon as possible in a controlled manner. For this purpose, TP-Planet divides actual RTT into equal time intervals of size T . During Immediate Start, it emulates slow start and congestion avoidance algorithms of current TCP protocols by treating intervals of T as RTTs of the emulated connection. Along with data packets, TP-Planet source transmits low priority NIL segments [4] to probe link resources during t 6 RTT. In Follow-Up, i.e., RTT 6 t 6 2  RTT, TP-Planet source updates its transmission rate S based on the feedback received from the sink every T period. Thus, the InterPlaNetary Backbone link resources are efficiently utilized in the initial phase improving the overall throughput performance. 2. New Rate-Based Adaptive AIMD Scheme. The throughput of the window-based TCP protocols and rate-based schemes are inversely proportional to the RTT [51] and the square-root of RTT [2], respectively. Thus, the rate-based 86 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 congestion control schemes are more robust to excessive propagation delays than the windowbased mechanisms. Hence, to address the adverse effects of extremely high propagation delay on the throughput performance, TPPlanet deploys a rate-based additive-increase multiplicative-decrease (AIMD) congestion control. Furthermore, in order to compensate the throughput degradation due to propagation delay, TP-Planet adapts its additive-increase and multiplicative-decrease parameters [2]. 3. New Congestion Control. To address the performance degradation due to high error rates of the InterPlaNetary Backbone links, TP-Planet deploys a new congestion detection and control mechanism in the Steady State. TP-Planet source simultaneously sends low and high priority NIX segments, which are smaller than the data packets, i.e., 40 bytes. Assuming the routers along the path are capable of priority-queuing, the higher packet loss rate for low priority NIX segments is recognized as congestion indication. The number of low NLow and high NHigh priority NIX segments received is periodically sent back by the sink. Their ratio, i.e., / ¼ ðNLow =NHigh Þ, is tested with preset decision thresholds, i.e., /i and /d , and then the data transmission rate, S, is hold, decreased or increased accordingly as shown in Fig. 7 [2]. 4. Blackout State. In order to reduce the effects of blackout conditions on the throughput performance, TP-Planet incorporates Blackout State procedure into the protocol operation. The details of the Blackout State operation can be found in [2]. In order to provide reliable transport, SACK options [75] are adopted by TPPlanet to address burst losses. Due to possible STEADY STATE INITIAL STATE Hold Rate t= 2*RTT t=RTT Immediate Start φd<Φ<φ i Φ<φ d Φ>φi φd <Φ<φi Blackout Follow-Up Decrease Rate Φ>φ i Increase Rate Φ<φ d Fig. 7. TP-Planet protocol operation state diagram including sub-states and the state transitions based on congestion control decision mechanism. inadequacy of the number of SACK blocks in the SACK option field for very long blackout durations, timeout mechanism is also included in TP-Planet. 5. Delayed-SACK. To address the problems due to the bandwidth asymmetry in the InterPlaNetary Backbone links, TP-Planet adopts delayedSACK mechanism, which reduces the traffic in the reverse channel to avoid congestion in the reverse channel. In this scheme, the source regulates the transmission of SACK packets with a certain delay factor d until a packet loss occurs. When a new packet loss occurs, the receiver sends a SACK packet immediately. By this way, TP-Planet can control the traffic amount in the reverse channel of the InterPlaNetary Backbone link. It is shown in [2] via simulation experiments that TP-Planet provides high throughput performance and addresses the challenges in the InterPlaNetary Backbone Network links. 4.2. Multimedia transport in InterPlaNetary backbone network In addition to the reliable data transmission, the multimedia traffic will be a part of the aggregate traffic over the InterPlaNetary Internet [9]. Some audio and visual information including planet images and scientific observations will be also transmitted via these links. Multimedia traffic does not require 100% reliability and mostly has strict requirements on bounded jitter, minimum bandwidth, and smooth change of the transmission rate. The multimedia applications usually are classified into two classes: streaming of stored or live multimedia and real-time interactive multimedia. Obviously, real-time interactive multimedia is not applicable over InterPlaNetary Internet backbone links because of the extremely long propagation delays. However, live or stored media streaming will be a part of the traffic carried over the space links. The control for the multimedia traffic is a serious problem, because uncontrolled multimedia traffic can not only congest the network, but can also cause unfairness and starvation for other data traffic. I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 4.2.1. Challenges In addition to the challenges for reliable data transport in InterPlaNetary Backbone Networks described in Section 4, there exist additional challenges due to the unique requirements of the multimedia transport. These challenges are summarized as follows: • Bounded Jitter. The variation in the end-to-end delay that a packet experiences is referred to as the delay jitter. Multimedia traffic has strict requirements on bounded jitter, because the delay jitter can cause problems in reconstructing the multimedia. This challenge is typically addressed by including a playout buffer at the receiver. • Minimum Bandwidth. Most multimedia applications require minimum bandwidth in order to maintain minimum media perception quality. The received media cannot be perceived properly if the bandwidth drops below this threshold. • Smooth Traffic. Abrupt and frequent fluctuations in the media rate can cause significant degradation in the received media quality. Consequently, the primary goal of multimedia transport protocols is not to aggressively find and use the available bandwidth, but to maintain a relatively steady media rate while still being responsive to congestions. • Error Control. Multimedia traffic over InterPlaNetary Internet can be coded in MPEG, motion JPEG, or H.26x. Even though error resilience techniques are adopted in coded video [68], compressed video is still highly sensitive to data loss. The quality of other types of multimedia can also be degraded dramatically if the packet loss rate is high. As a result, error control mechanism must be designed to deal with the packet losses due to link errors or congestions in the InterPlaNetary Internet. 4.2.2. Related work Many multimedia transport protocols are proposed to control the flow of multimedia traffic in terrestrial networks [17,52,54,77,89,90,100]. These proposed protocols can be mainly categorized into two types of rate control schemes, i.e., AIMDbased and equation-based. 87 AIMD-based rate control schemes are TCPcompatible, i.e., they compete reasonably fairly with the existing TCP by following TCP behavior to conservatively update the sending rate based on feedback information [17,89,100]. Streaming Control Protocol (SCP) [17] is a modified version of TCP that performs TCP-Vegas-like rate adjustment. TCP Emulation at Receiver (TEAR) [90] determines the receiving rates at the receiver based on signals, such as packet arrivals, packet losses, and timeouts. Using these signals, TEAR emulates the TCP flow control functions at the receiver including slow start, fast recovery, and congestion avoidance. Rate Adaptation Protocol (RAP) [89] is a rate-based congestion control mechanism for wired and short distance networks. Rate Control Scheme (RCS) [100] is a rate control scheme for real-time traffic in networks with high bandwidthdelay products and lossy links. However, all of these existing AIMD-based rate control schemes [17,89, 90,100] are developed based on the assumption that the propagation delay is relatively short, which does not hold in the InterPlaNetary Backbone Network links. Moreover, the AIMD schemes cause abrupt and frequent fluctuations in the media rate in the form of a saw-tooth pattern which is not suitable for most multimedia applications. The equation-based rate control schemes [52,54,77] are proposed in order to provide relatively smooth congestion control for multimedia traffic in the terrestrial networks. The idea of the equation-based congestion control is to adjust the transmission rate no more than the estimated throughput of the corresponding TCP counterpart experiencing the same packet loss rate, round-trip time, and packet size. TCP Friendly Rate Control (TFRC) [54] is an equation-based rate control scheme which adopts a simple TCP throughput model in its congestion control mechanism. MPEG-TFRCP (TCP Friendly Rate Control Protocol for MPEG-2 Video Transfer) [77] is another equation-based rate control scheme designed for transporting MPEG-2 video in a TCP-friendly manner. Unlike TFRC, TFRCP specifically takes video characteristics into consideration while adjusting its media rate. Although the use of TCP response function ensures that equation-based control schemes compete fairly with TCP over 88 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 long time scales, the steady-state throughput model of TCP source is highly sensitive to RTT values. Therefore, the equation-based rate control schemes cannot achieve high link utilization and hence are not promising solutions for the InterPlaNetary Backbone Network links with extremely high propagation delay. SCPS Rate-based protocol is proposed for space communication [106]. However, no congestion control algorithm is incorporated into the protocol. The transmission rate of the SCPS Ratebased protocol source is defined by the user and also constrained by the receiver buffer size. In other words, SCPS Rate-based protocol does not adapt its transmission rate to the network conditions. Thus, it may cause congestion for InterPlaNetary Backbone Network links if its transmission rate is higher than the available bandwidth. Besides the rate control schemes mentioned above, layered approaches [88] are proposed for the terrestrial networks to minimize the variations in video quality. Many commonly used compression standards, such as MPEG-2, MPEG-4, and H.263, have extensions for layered coding. Using hierarchical encoding, the source maintains a layered encoded stream, i.e., a base layer and multiple enhancement layers. The rate control is performed by adding or dropping enhancement layers. If more bandwidth becomes available, more enhancement layers are added to improve the video quality. On the other hand, if the available bandwidth decreases, some enhancement layers have to be dropped. In layered approaches, in order to decode an enhancement layer, it requires that all the lower quality layers have been received successfully. For InterPlaNetary Internet links, such requirement usually cannot be guaranteed. Furthermore, layered approaches also incur a significant compression penalty as compared to non-layered approaches. Due to this reason, the layered approaches might not be suitable for InterPlaNetary Internet. The bundling protocol as shown in Fig. 4 is proposed on top of the transport layer for deep space communication [13,19]. As explained in Section 4.1, the basic idea of the bundling protocol is to operate in a store and forward mode. However, multimedia traffic has strict timing requirements, the data received after a certain point in time are useless. Thus, the store and forward approach is not suitable for the multimedia data. Furthermore, the intermediate routers have to buffer data in the store and forward mode, which may request prohibitive buffering space. Assume the RTT value of a hop is 20 min and the average transmission rate at the router is 1MBps, then the router should keep 1.2 GB in its buffer. If the average transmission rate and the RTT value are higher, the buffer space becomes much higher. For such huge buffer space, it also takes very long time to manipulate the buffer. As a result, the Bundling protocol is not suitable for the rate control of multimedia traffic in InterPlaNetary Internet. Packet Path Diversity [72] is a scheme proposed for real-time voice communication over the Internet to improve the tradeoff among delay, late loss rate, and the speech quality. Instead of restricting the transmission to one network path, multiple redundant descriptions of the voice stream are sent over different independent paths to take advantage of their largely uncorrelated loss and delay characteristics. However, since the InterPlaNetary Backbone Network links are mainly pointto-point links, it may not be possible to send multiple streams over presumably uncorrelated links. Hence, this scheme may not be feasible in InterPlaNetary Internet. On the other hand, although the multimedia flows are inherently loss-tolerant, error control mechanisms are still necessary to maintain a certain level of success rate in the existence of high link errors. However, due to the extremely high propagation delays, retransmission-based Automatic Repeat reQuest (ARQ) schemes cannot be used for this purpose in the InterPlaNetary Backbone Network links. Therefore, packet-level forward error correction (FEC) mechanisms [83] can be used in the InterPlaNetary Internet. An important factor for the determination of the packet-level FEC for multimedia transport is the encoding and decoding times. The traditional FEC schemes such as Reed-Solomon codes have quite slow encoding and decoding times for large FEC block sizes [15], which limit the block size to very small numbers. This, in turn, increases the overhead incurred by the FEC redundancy, which should be avoided for the scarce communication I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 resources of the InterPlaNetary Internet. On the other hand, Tornado codes [15] are based on random bipartite graphs and exclusive-or operations, which make Tornado codes orders of magnitude faster than standard erasure codes. As a result, Tornado codes are appropriate for packet level FEC with large FEC block size for InterPlaNetary Backbone Network links. Although Tornado codes require slightly more encoding packets to reconstruct the original data, this disadvantage is compensated by the large FEC block size, hence the lower FEC overhead. Consequently, the existing rate control schemes cannot address the challenges posed by the InterPlaNetary Internet Backbone Network. New multimedia transport protocols should be proposed in InterPlaNetary Internet to address all these challenges. 4.2.3. RCP-Planet RCP-Planet [49], a rate control scheme, is proposed to address all the challenges for multimedia transport protocols in the InterPlaNetary Backbone Network where the source and sink endpoints are basically relay satellites orbiting around the planets as shown in Fig. 1. RCP-Planet runs on top of Internet Protocol (IP) layer and does not require any specific modification to the lower layers in TCP/IP protocol suite. RCP-Planet consists of two states, i.e., Initial State and Steady State, as shown in Fig. 8. The main functionalities of the RCP-Planet are summarized as follows: 1. Packet Level FEC. In order to recover the packet losses due to link errors or congestions in the InterPlaNetary Internet, Tornado codes [15] are used for packet-level FEC because of their very fast encoding and decoding times. STEADY STATE INITIAL STATE t=RTT Increase Rate r a < rm r a > rm t Initial State eou Tim r a> rm Timeout Blackout Decrease Rate r a< r m Fig. 8. RCP-Planet operation state diagram. 89 Although Tornado codes require slightly more encoding packets to reconstruct the original data, this disadvantage is compensated by the large FEC block size, hence the lower FEC overhead. Moreover, Tornado codes use only exclusive-or operations, which make them simple to implement in practice. The FEC block length is chosen appropriately to minimize the FEC overhead for different packet loss rates. 2. Initial State. In the Initial State, it is difficult to determine the initial sending rate since no link information is available at the beginning. Conservatively, we set the initial media rate to be the minimum media rate required by the application in order not to inject too many packets into the network. As the packet loss rate in the Initial State is also unknown, the most recent history value ph is first used as an approximation of the current packet loss rate to determine the FEC block length n. However, the actual packet loss rate might not be exactly the same as ph . In order to address the worse network condition, we conservatively choose a packet loss rate pl much larger than ph for the possible worse network condition and calculate the corresponding FEC block length n0 . n0 is used as the actual FEC block length to encode the data. Since the n0  n redundant packets are additional redundancy to address the possible worse network condition, they are sent in low priority. The low priority packets are dropped first during the congestion so that they do not affect normal traffic during congestion. The remaining n packets are transmitted in high priority. 3. New Rate Probing Mechanism. Rate probing is a mechanism to measure the observed rate at the receiver side to determine the available bandwidth. The new rate probing scheme is performed in each FEC block, i.e., for each FEC block, a fixed number of packets, called a probing sequence, are first sent at a high rate so-called the probing rate rp . The remaining packets in the FEC block are sent using the current source sending rate rs . Some probing packets can be dropped by the gateway due to the limit of network bandwidth, the observed rate ro for the probing sequence at the receiver is 90 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 the available bandwidth. The probing sequence length is a design parameter and is chosen appropriately. Another design parameter is the probing rate rp . In the initial state, no information about network condition is available, thus, rp is set in a way such that it can catch the available bandwidth as fast as possible. In the Steady State, the probing rate is updated adaptively according to the network condition. 4. New Rate Control Scheme. In order to deliver the multimedia smoothly, RCP-Planet deploys a new rate control scheme based on the new rate probing mechanism. Upon receiving an ACK from the receiver, the current observed rate ro is known, which reveals the available network bandwidth. The corresponding available media rate ra is calculated from ro , which is the upper bound of current media rate. If ra P rm , where rm is the current media rate, the network bandwidth is not fully utilized, i.e., the media rate should be increased. The extra amount ðra  rm Þ is increased in one RTT linearly with respect to time so that the media rate is increased smoothly in order to decrease the chances of congestion in the network. On the other hand, if ra < rm , i.e., the current media rate is too high, the sender needs to back up and decreases its media rate, thus, the media rate is decreased multiplicatively. 5. Blackout State. In order to reduce the throughput degradation due to blackouts, RCP-Planet incorporates the Blackout State into the protocol operation. The sender infers blackout and stops sending any packets if it does not receive any ACKs for a certain period of time. In a similar way, the receiver also infers blackout and starts to transmit so-called Zero ACKs. Since RTT is very high, the effect of blackout on the performance changes with its relative location of blackout occurrence with respect to the receiver. Zero ACKs and the on-fly ACKs when blackout occurs are used for the sender to capture the accurate information regarding the blackout situation and act accordingly. 6. FEC Block Level ACK. In order to address the bandwidth asymmetry problem in the InterPlaNetary Backbone links, RCP-Planet adopts FEC block level ACKs, i.e., only one ACK is sent for an entire FEC block. If the FEC block size is large enough, the bandwidth asymmetry problem can be solved by the FEC block level ACKs. Delayed ACKs can also be used to further reduce the number of ACKs in the reverse link, i.e., only sends one ACK for a certain number of FEC blocks. In this case, the observed rate and the current packet loss rate are the average values over multiple FEC blocks. Simulation results in [49] show that RCP-Planet achieves high throughput performance, fairness, and is delay-tolerant by addressing the challenges of InterPlaNetary Internet. 4.3. Open research issues As we just presented although there exists some research in the literature to address the challenges pertaining to the transport layer issues in the InterPlaNetary Internet, there still exist many open research issues to be solved. These can be summarized as follows: • Transport Protocols for PlaNetary Networks. Thus far, the focus of the research performed on transport layer issues for InterPlaNetary Internet has been mainly on the InterPlaNetary Backbone Networks. This is because of the unique challenges posed by the deep space links such as extremely long propagation delays and high link errors. Although the current transport layer solutions for the terrestrial satellite, wireless ad-hoc and sensor networks can be applied to the PlaNetary Satellite and Surface Networks, their performance should be extensively evaluated for these environments and the required modifications and improvements should be researched. • Extreme PlaNetary Distances. Although there exist solutions such as TP-Planet [2] and RCPPlanet [49] that can improve the throughput performance in case of blackout situations, some of the links with extreme distances such as Jupiter, Pluto, etc. have intermittent connectivity within a round-trip time period. Therefore, the effect of intermittent connectivity is amplified by the extreme round-trip times. I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 Hence, the performance of the existing proposed solutions over these environments needs to be evaluated and proper modifications and improvements should be performed if necessary. • End-to-End Transport. As explained in Section 4.1, one proposed way of addressing the reliability and the congestion control is to perform local retransmissions and congestion control instead of end-to-end approach. However, local reliability and congestion control may lead to significant delays, and vulnerability to intermediate node failures. Furthermore, store-and-forward approach is not suitable for time-sensitive multimedia delivery at all. On the other hand, end-to-end transport may lead to sub-optimal solutions due to the heterogeneity of the InterPlaNetary Internet architectural elements. For example, TP-Planet and RCP-Planet are developed for InterPlaNetary Backbone links with extremely high propagation delay. Thus, if they are applied to end-to-end transport, e.g., from the Mars surface to the Earth Internet, they would be unresponsive to the congestions in the PlaNetary Network part of the end-to-end path due to the significant difference between the delay in the InterPlaNetary Backbone Network and the PlaNetary Networks. Hence, the possible extensions of the existing proposed solutions and new adaptive transport protocols for the end-to-end transport should be further investigated. The extensive performance comparison between the end-to-end solutions and the store-and-forward approaches should be performed. Moreover, end-to-end approach should be investigated for both reliable data and multimedia transport over the entire InterPlaNetary Internet. The interactions between the protocols tailored for specific environments need to be explored. • Cross-Layer Optimization. Due to the scarcity of the power and processing resources at the planetary distant communication nodes, the cross-layer optimization is an essential direction to pursue. The cross-layer optimization for transport layer protocols should be researched to achieve highest efficiency in resource utilization in the extreme networking environment such as in InterPlaNetary Internet. For exam- 91 ple, the link information, which is available to lower layers, should be exploited to the maximum to achieve resource-efficient reliable data and multimedia transport throughout the InterPlaNetary Internet. 5. Network layer issues In the InterPlaNetary Internet architecture as shown in Figs. 1 and 2, the end-to-end communication includes identifying the communicating endpoints, as well as the routing in the InterPlaNetary Backbone Network, the PlaNetary Networks, and the InterPlaNetary External Networks. While the existing routing protocols for mobile ad hoc and sensor networks [5,84] can be applied to the InterPlaNetary External Networks shown in Fig. 1, there exists significant challenges which necessitate specifically tailored solutions for routing in the other parts of the InterPlaNetary Internet. In the following sections, the design issues of naming and addressing in the InterPlaNetary Internet; routing in the InterPlaNetary Backbone Network and PlaNetary Networks are explored. 5.1. Naming and addressing To provide inter-operability between different elements in the architecture that may use IP, sensor, or proprietary addressing formats, a universal addressing scheme is needed to locate the elements in the InterPlaNetary Internet architecture as shown in Figs. 1 and 2. For example, a user may want to communicate with or give commands to an element, e.g., a satellite, lander, rover, or sensor node, an element on a remote planet may also want to communicate with the Earth control center. The addressing scheme should be able to incorporate equipments in different parts of the InterPlaNetary Internet, which will result in significant cost savings in space network deployment. The factors influencing naming and addressing in the InterPlaNetary Internet include [48]: • what objects are named (typically nodes or data objects), 92 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 • whether a name can be directly used by a data router in order to determine the delivery path, and • the method by which name/object binding are managed. In todayÕs Internet, addressing is used for routing purpose. The matching of global unique destination addresses in a routerÕs local forwarding table gives the next-hop address. Naming is applied to make the addressing easier for humans. Naming/addressing translation is done through domain name system (DNS) services [86]. Although the DNS approach results in great forwarding efficiency at IP routers (no per-hop name resolution is needed), its use across interplanetary links with long delay poses a number of significant problems. For example, if an application on a remote planet wished to resolve an Earth-based name to an address, it could use one of the three alternatives in todayÕs Internet [43]: 1. It could query an Earth-resident name server. This results in a delay of a round-trip time in the commencement of communication and this delay may be significant in terms of the available communication time. 2. It could maintain a secondary name server locally. If so, some updates would dominate communication channel utilization to the exclusion of other data. 3. It could maintain a static list of host names and addresses. This has the disadvantage of not scaling well as the system grows. Because of the delay-tolerant nature of the InterPlaNetary Internet, name/address binding at intermediate nodes is not considered detrimental to the overall delay performance. Therefore, the tiered naming and addressing [14] is proposed to address the challenges in employing DNS in delay tolerant networks such as the InterPlaNetary Internet. A name tuple identifies a communicating entity and is comprised of two variable length portions: {region ID, entity ID} [45]. The region ID identifies the entityÕs region and is known by all regions in the InterPlaNetary Inter- net. The entity ID is a name local to its local region and treated as opaque data outside this region. The opacity of entity names outside their local region enforces late binding, i.e., the entity name of a tuple is not interpreted outside its local region, which avoids having a universal nameto-address binding space (and its associated database and synchronization issues), and preserves a significant amount of autonomy within each region. Specifically, the tuple structure requires at least two indirect lookups to ultimately determine the endpoint: One to resolve the region ID to a valid local next-hop, and the second to resolve the region-specific entity ID to a valid next-hop or aggregate-set address within the specific region. Fig. 9 gives a simple example of using tuples as the naming method in the InterPlaNetary Internet, which is composed of three distinct regions interconnected by two gateways GW1 and GW2. The name tuples of a source node in EarthÕs Internet, a destination node in MarsÕ Internet, and the gateways are shown. The tiered naming and addressing enables new regions with new naming and addressing systems to be added without impact on previously deployed nodes, and keeps the DNS translation efficient in the InterPlaNetary Internet [14]. In terms of designing the addressing space, it is suggested in [45] that the names are directly used to identify objects, or any particular identifier space may be used together with a name translation. For the addressing in the InterPlaNetary Internet, the objective is to make it as compatible as possible with existing IP technologies [102]. Therefore, in Earth’s Internet GW1 SRC IPN region: earth.sol Host SRC GW1 GW2 DST The "Backbone" IPN Regions earth.sol earth.sol ipn.sol ipn.sol mars.sol mars.sol GW2 IPN region: ipn.sol Mars’ Internet DST IPN region: mars.sol Host name tuples {earth.sol, src.jpl.nasa.gov:6769} {earth.sol, ipngw1.jpl.nasa.gov:6769} {ipn.sol, ipngw1.jpl.nasa.gov:6769} {ipn.sol, ipngw2.jpl.nasa.gov:6769} {mars.sol, ipngw2.jpl.nasa.gov:6769} {mars.sol, dst.jpl.nasa.gov:6769} Fig. 9. An InterPlaNetary Internet example and host name tuples [45]. I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 [31] and [102], Internet address space is used to identify the objects. The current deployment of addressing scheme in the Internet uses IPv4. IPv6 has also been designed to replace the IPv4 since it solves the address depletion problem and adds many improvements to IPv4 in areas such as routing and network auto-configuration [40]. However, IPv6 has seen little practical deployment for its lack of backward compatibility [60]. Therefore, the coexistence of IPv4 and IPv6 is expected in the InterPlaNetary Internet. Whereas IP addresses are assigned topologically in the Internet, names are directly used for lowlevel communication in some distributed systems such as the sensor networks. These names are external to the network topology and based on application characteristics such as sensor types or geographic location [56]. To allow interoperability between different types of subnetworks such as the InterPlaNetary Backbone Network and InterPlaNetary External Networks (e.g., sensor clusters), adaptation between topology-based addressing and application-based naming is required. When a uniquely addressed end-node travels through different sub-networks in the InterPlaNetary Internet, the registration and routing must be updated accordingly. Mobile-IP [82] allows hosts to seamlessly roam among various IP sub-networks. Moreover, if the spacecraft has multiple instruments that are IP addressable, the mobile router technology [82] can be used as an automated solution to enable the entire network onboard the spacecraft to roam. The mobile IP and mobile router technologies can be used for communication in PlaNetary Networks, example applications include NASAÕs near-planetary observation and spacecraft sensing [71]. However, their use in the InterPlaNetary Backbone Network is limited due to the extremely high propagation delays of the InterPlaNetary Backbone links. To achieve efficient routing, new mechanisms and services are needed to address the mobile elements as they travel through different sub-networks. In summary, to support end-to-end communication in the InterPlaNetary Internet, the expected new universal addressing scheme should perform the following functions: 93 • locate the elements in a hierarchical way in the InterPlaNetary Internet architecture, support for efficient routing through different sub-networks and under node movement; • allow the InterPlaNetary Internet to expand while maintaining the addressability of previously-deployed elements; • dynamically allocate addresses, i.e., retrieve addresses from nodes under power failure or physical damage, and assign new addresses to newly deployed elements. 5.2. InterPlaNetary backbone network The InterPlaNetary Backbone Network in Fig. 1 consists of the long haul data links (direct link or multi-hop paths) among backbone elements, such as devices on outer-space planets, the Earth, moons, and satellite relays. It provides the data delivery across interplanetary distances to support deep space exploration. 5.2.1. Challenges and related work The main challenges that affect network layer design in the InterPlaNetary Backbone Network are long and variable delay, and intermittent connectivity. • Long and Variable Delay. As explained in Section 4, the InterPlaNetary backbone links may have extremely long propagation delays. In such networks, routing protocols most severely affected are those distributed algorithms, which require timely dissemination of state. Without timely distribution of topology information, routing computations will fail to converge to a common solution, resulting in route inconsistency or oscillation. The movement of some backbone nodes (such as planets and satellite relays) adds to the variability of delay. The movement of nodes during propagation must be considered while computing the routes or while scheduling the packet forwarding time. • Intermittent Connectivity. Intermittent links cause several challenging problems: determining the predicted time and duration of intermittent links and the degree of uncertainty of these estimates, obtaining knowledge of the state of 94 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 pending messages, the scheduling of their transmission when the link becomes available, and decision of the time at which to abandon the wait for a predicted link. Because of the message-oriented nature of the deep space exploration system, it is preferable that optimal path selection and transmission time assignment is done prior to message transport. However, these problems are difficult due to the temporal nature of the topology graph (edges come and go according to the schedules that may be known in advance or abruptly due to interference) and the non-negligible edge transit times. To deal with the above-mentioned challenges, some research attempts have been made recently to address the networking layer issues in the InterPlaNetary Backbone Network. Space Communication Protocol Standards-Network Protocol (SCPS-NP) by CCSDS [31] is proposed as a scalable network protocol for in-space routing through networks containing space or other wireless data links. To allow the designers to accommodate the differences from one mission to another, SCPS-NP provides multiple options to meet the requirements and constraints of specific missions. For example, SCPS-NP employs scalable bit-efficient header using a technique called capability-driven header construction to reduce the transmission overhead. The format of the packet header is based exclusively on the protocolÕs capabilities required for each particular datagram. Routing tables can be configured either statically, centrally, or locally by exchanging state information among each other. In addition, selectable routing method is used for datagrams with different priorities. Since the routing algorithm in SCPSNP is implementation-specific, the detailed design should first be worked out to address the abovementioned challenges before using SCPS-NP in the InterPlaNetary Backbone Network. The InterPlaNetary Internet can be regarded as a special type of the DTN [19] where continuous end-to-end connectivity cannot be assumed. To deal with the intermittent property of the interplanetary backbone links, the tiered routing mechanism uses both current and expected connectivity information. Specifically, routes through the InterPlaNetary Backbone Network are comprised of a sequence of contacts that indicate the duration, endpoints, and forwarding capacity of a link in the topology graph. Contacts may be anticipated in a variety of ways [14] • they may be scheduled by explicit network management; • they may be discovered in real time within regions with small propagation delays; • they may be predicted based on region-specific structural awareness; • they may be computed stochastically based on prior contact history. One-hop link state information and a distancevector type of aggregation beyond one hop is maintained to obtain a probabilistic view of the overall topology. Rerouting is conducted if an episode of connectivity does not occur as expected. 5.2.2. Open research issues Despite some protocols proposed for routing in the InterPlaNetary Backbone Network, the following research issues need further exploration: • Distribution of Topology Information. Possible ways to distribute the topology information over the InterPlaNetary Backbone Network are: 1. Combination of link state and distance vector information exchange. For example, the link state information can be exchanged within local (e.g., one-hop) range, whereas distance-vector type of aggregated information beyond local range is obtained. 2. Distribution of trajectory and velocity information. This method has low signaling overhead, but it requires strict time synchronization, the ability to compute the locations at any time from the trajectory information at any node, active update and correction of location and congestion information. An efficient way to distribute the information from Earth is needed as well. • Path Calculation. Unlike the terrestrial Internet, the InterPlaNetary Backbone Network is composed of links with variable length and intermit- I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 tent existence. No optimal path can be guaranteed through the packet routing process without overall knowledge of the network topology and possible environmental impacts. Hop-by-hop routing is expected using incomplete topology information and probabilistic estimation. Moreover, adaptive algorithms are needed to decide when and how to reroute packets, whether or not to keep a local copy of forwarded packets and when to drop it. When a packet arrives at the border of a PlaNetary Network, specific routing protocols adaptive to the local circumstances can be initiated to continue forwarding the packet to its final destination. • Interaction with Transport Layer Protocols. Just as the border gateway protocol (BGP) ties together different autonomous systems (ASs) in the Internet, routing protocols in the InterPlaNetary Backbone Network unite different PlaNetary Networks and InterPlaNetary External Networks together. BGP is built on TCP. Therefore, BGP performs poorly in high-delay environments when TCP is unable to keep a connection established [96]. Moreover, inaccurate timeout interval estimates may adversely affect the path calculation algorithms. Likewise, the performance of routing protocols will be affected by the transport layer protocols, such as those described in Section 4. The interaction between transport and network layers needs to be considered to achieve better performance. 5.3. PlaNetary networks The routing in PlaNetary Networks is a necessary part to achieve end-to-end communication between Earth and outer-space planets. It also integrate the local planetary components, such as orbiting satellites, rovers, landers, and sensor clusters, to realize autonomous communication and control. 5.3.1. Challenges and related work The challenges for routing in the PlaNetary Network are summarized as follows: • Extreme Power Constraints. Space elements mainly depend on rechargeable battery using 95 solar energy [80]. Therefore, the PlaNetary Network nodes may fail permanently or temporarily with very long periods of failure when there is no light for a long duration. The power availability is of overriding importance to the PlaNetary Surface Network. • Frequent Network Partitioning. The network can be partitioned due to environmental factors [19], such as meteoroid shower, high electromagnetic radiation, sand storm, and node malfunction. • Adaptive Routing Through Heterogeneous Networks. As shown in Fig. 2, the PlaNetary Network includes fixed elements (e.g., landers), satellites with scheduled movement, mobile elements with slow movement (e.g., rovers, balloons), mobile elements with fast movement (e.g., powered spacecraft), and low-power sensor nodes in clusters. Adaptive protocols are needed to maintain the connectivity and achieve seamless routing among these elements. Terrestrial mobile ad hoc networks and sensor networks also face power constraints and topology dynamics. Therefore, much of the ongoing work in these areas is relevant and timely. Generally, the ad hoc routing protocols proposed for terrestrial networks either 1. concentrate on developing power-related routing metrics such as to minimize energy consumption or to maximize the lifetime of the network [21,91,98], 2. control the network topology by changing the transmit powers of the nodes [66,87,110] or 3. use multiple paths simultaneously to increase the probability that the information is received at the destination [79]. Some of these emerging terrestrial technologies can be applied to the PlaNetary Network. However, their performance depends on the node density and the connectivity of the network. For sparse networks, the role of nodes for avoiding the network partitioning is more crucial. In outerspace planets, frequent power failure and node damage may cause frequent network partitioning that will affect the performance of the abovementioned routing protocols. 96 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 In respect to data delivery in a network experiencing frequent partitioning due to sporadic or constant disconnectivity, a number of research efforts have arisen recently. Epidemic routing [108] relies upon ‘‘carriers’’ to carry messages between disconnected portions of the network through node mobility. The carriers exchange messages with other nodes when they meet. An example of epidemic routing is depicted in Fig. 10, in which carriers C1  C3 are utilized to transitively deliver the messages to its destination at some later time. The MULE architecture [95] adds an intermediate layer of mobile nodes to the existing relationship between sensors and access points used in typical sensor network designs. The MULEs are mobile transport agents with large storage capabilities and renewable power. They collect data from fixed sensor nodes and later transfer to access points in a store-and-forward manner. In ZebraNet [65], wireless sensor nodes are attached to animals, which can be seemed as the sensor and the MULE mapped to the same device. The sensor nodes collect location data and send data when they come in radio range of the mobile access points (only active some of the time). These ideas can be leveraged in PlaNetary Surface Networks for routing during periods of disconnection. Since space exploration missions may be carried out on different parts of the planet, the PlaNetary Surface Network may be divided into several physically disconnected sub-networks where each belongs to a community region as shown in Fig. 2. One possible way to resume the connection between partitioned domains is through the satellite connections. This calls for the use of satellites in the PlaNetary Satellite Network to assist surface communications and node reconfigurations. In addition, the cost of the landing equipments on remote planetary surfaces motivates designers to C2 keep as much communication infrastructure in orbit as possible [18]. Several routing protocols in terrestrial satellite IP networks have been proposed in recent years [6,23,46,58]. Some of them only consider routing within satellite network [46,58]. Although others [6,23] incorporate the routing between terrestrial gateways through satellite network, it is assumed that the gateways are fixed and directly connected to satellites. The support for the surface network topology maintenance is lacking in these protocols. Because of the extreme long delay from the Earth control center to outer-space planets, autonomous control and local coordination is required to maintain network connectivity, make timely local decision based on the temporal conditions, detect and recover from the reduction in resources and change in topology that are resulted in unpredictable failures by the harsh environment [25]. The Sensor Web project [101] poses an interesting approach to realize coordination and information sharing among multiple sensor nodes. The sensor web consists of intra-communicating, spatially distributed sensor pods that are deployed to monitor and explore environments. Different from ‘‘sensor networks’’, sensor web allows information gathered by one sensor shared and used by other sensors, thus sensor webs can react and modify their behavior on the basis of the collected data [41]. An example sensor web architecture for Mars exploration is shown in Fig. 11, where the first tier of mother pods (cubes) form their own Web structure, leading to the idea that the sensor web is a web of Web nodes [42]. Individual (spherical) pods are not necessarily associated with a particular (cubic) mother pod. Mother pods can communicate with Mars surface elements, such as landers and rovers, which have the capability to connect with the Mars orbiting satellites. As an C3 C3 S D S C2 C1 C1 time = t1 time = t2 > t1 Fig. 10. An example of epidemic routing [108]. D I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 Sensor pod Mother pod Lander Satellite Fig. 11. An example sensor web architecture for Mars exploration [101]. example for the application of space exploration, sensor webs can be used together with orbital spacecrafts to adaptively adjust the monitoring spatial scales between those of a lander to those of an orbital platform [41]. Webs of sensors carried on orbiting satellites allows the observation area to extend to a global scale [69]. Therefore, sensor web is a very promising concept that can be exported to the PlaNetary Networks. 5.3.2. Open research issues Because of the extreme environmental constraints and lack of timely control from the Earth, distributed processing and local decisions is required for network layer protocols in the PlaNetary Networks. The following are some of the key issues to realize the autonomous and reconfigurable PlaNetary Network: • Routing Support from Satellites. The satellite orbiting a planet can act as gateways between the InterPlaNetary Backbone Network and the PlaNetary Network. They also help to build a robust communication and navigation infrastructure at the planet. Therefore, PlaNetary Satellite Network plays an important role to support the end-to-end routing between Earth and outer-space planet, as well as between community regions within PlaNetary Surface Networks. Meanwhile, new protocol support from the satellites is called to help maximize the con- 97 nectivity of the PlaNetary Surface Network. For example, a surface element can be moved to a new position by the command from an above satellite to achieve better network connectivity. • Topology Maintenance and Re-configuration. The frequent network partitioning in the PlaNetary Surface Network calls for network reconfiguration mechanisms to reconstruct network topology to achieve better performance, e.g., extend network lifetime, maximize network connectivity, and minimize communication overhead, etc. It is preferable that these mechanisms are executed locally due to the long distance of interplanetary links to the Earth control center. Local decisions can be made to update network topology by node mobility, power adjustment, and adaptive clustering, etc. • Power Efficiency. Power efficiency is of great importance in developing mechanisms in the PlaNetary Surface Networks. Therefore, routing decisions should consider power availability at each node; network reconfiguration should reduce power dissipation in topology set up and maintenance; surface elements can switch to sleep mode temporarily when no mission is planned and under unfavorable environmental conditions. • Cross-layer Interaction. The adaptive protocol design that works efficiently on an end-to-end basis in the PlaNetary Network is challenging. However, due to the extreme environment characteristics, different layers are likely to use the same information (such as the location and energy information) in making layer-specific decisions. Moreover, in a dynamic wireless network with nodes of different capabilities and mobility levels, different layers need to cooperate closely to meet the QoS requirements of the applications. As an example, cross-layer metrics can be developed and utilized to make relevant decisions, e.g., routing decisions, which suit the system as a whole. 6. Data link layer issues The data link layer is mainly responsible for the multiplexing of data streams, data frame detection, 98 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 fixed assignment protocols; demand assignment protocols; random access protocols; hybrid of random access and reservation protocols; • adaptive protocols. medium access and error control. It performs the transmission of the upper layer protocol data units over physical space channel. In this section, we explore the challenges, existing solutions and the open research issues in the data link layer for InterPlaNetary Internet. • • • • 6.1. Medium access control Based on this classification, frequency-division multiple access (FDMA), time-division multiple access (TDMA), and code-division multiple access (CDMA) based schemes are fixed assignment protocols since the allocation of the channel bandwidth to a station is a static assignment. FDMA does not require any coordination or synchronization. However, FDMA is not suitable for InterPlaNetary Backbone network since the channel allocated to an idle node cannot be used by other station. On the other hand, TDMA also has allocated channels within time slots and it does require time synchronization, which is also an important paradigm in InterPlaNetary Internet as will be described in Section 8. CDMA does not have any of these problems, although it has lower throughput. However, an extensive performance evaluation is yet to be performed to assess the suitability and the performance of all these fundamental MAC schemes and their variants in the InterPlaNetary Internet. The link layer for the deep space long-haul links has been thus far addressed by the Packet Telecommand [32] and Packet Telemetry standards [27] established by the CCSDS. Packet Telecommand incorporates the Virtual Channelisation method which is responsible for the MAC layer functionalities. Virtual Channelisation allows the various sources to be virtually granted exclusive access to the physical channel by assigning them transmission capacity on a frame-by-frame basis. Each transfer frame is identified as belonging to one of the up to eight virtual channels. This method is normally used to separate sources or destinations with different characteristics [32]. For example, if a payload produces scientific imagery data with packets containing many thousands of octets, and a number of other instruments which generate smaller packets, the system architecture would assign the imaging instrument packets to one virtual channel and to handle the rest by multiplexing Medium access control is required in the data link layer to accommodate multiple nodes to share the same transmission medium by utilizing network resources with maximum efficiency and minimum contention. Although the objective of medium access control (MAC) layer is common, the challenges experienced and hence the required solutions significantly differ for different architectural elements of the InterPlaNetary Internet. Therefore, we will explore the issues pertaining to MAC separately for InterPlaNetary Backbone Network and PlaNetary Networks. 6.1.1. InterPlaNetary backbone network The challenges posed by the InterPlaNetary Backbone link for the MAC layer protocols can be summarized as follows: • Very Long Propagation Delay. As explained in Section 4, the InterPlaNetary Backbone links have extremely high propagation delays. This characteristics lead to rule out a certain class of MAC protocols proposed for LANs and WANs. • Physical Design Change Constraints. The MAC protocols should be designed such that minimum physical or hardware changes are necessary at the controllers in the space. • Topological Changes. Due to the possible frequent topology changes, MAC protocols need to accommodate reconfigurability and dynamic access control mechanisms. • Power Constraint. The limitations in the power require stringent use of memory, processing, and communication powers, which require power-efficient MAC designs. In [85], the MAC protocols for satellite communications have been studied and classified as follows: I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 them onto a second virtual channel. Different virtual channels can also be used to separate real-time data from time-insensitive data. On the other hand, the Operating Missions as Nodes on the Internet (OMNI) project [102] at NASA Goddard Space Flight Center (GSFC) defines and demonstrates the end-to-end communication architecture for future space missions. The OMNI project chooses high-level data link control (HDLC) protocol for the link layer protocol on space-to-ground links [59]. This choice is mainly motivated by the fact that HDLC has been widely used in communication equipments for decades and provides basic framing for many serial line protocols such as SDLC, Frame Relay, and X.25. Due to the point-to-point nature of the InterPlaNetary Backbone links, HDLC suffices as the link layer protocol for InterPlaNetary Backbone links without any specific medium access control mechanism. However, HDLC alone cannot provide reliable link layer transmission, hence it is used along with convolutional and Reed Solomon forward error correction codes [81]. 6.1.2. PlaNetary networks Although the challenges described above for InterPlaNetary Backbone links apply for PlaNetary Networks as well, their magnitude and the order of significance and effectiveness significantly vary. For example, while the link delays are very low for PlaNetary Surface Network links; the link delays are high for PlaNetary Satellite Network links, but not even comparable to the InterPlaNetary Backbone links. On the other hand, power limitations and the physical design considerations become more challenging in PlaNetary Networks. Furthermore, the need for an efficient MAC protocol is especially greater in the PlaNetary Networks due to the highly shared transmission medium in the denser network deployment composed of the architectural elements of the PlaNetary Satellite and Surface Networks. The MAC protocols proposed for satellite communications [85] can be used at the PlaNetary Satellite Networks with proper modifications and improvements. The link layer issues for the Planetary Surface Network, on the other hand, could be addressed by incorporating the existing MAC 99 protocols for mobile ad-hoc networks and wireless sensor networks [9]. However, these solutions need proper modifications and improvements to address the heterogeneous networking environments of the Planetary Networks. For short-delay proximity space links, Proximity-1 link layer protocol [26] is currently being developed by the CCSDS. Proximity space links are defined to be short-range, bi-directional, fixed or mobile radio links, generally used to communicate among probes, landers, rovers, orbiting constellations, and orbiting relays [26]. The Proximity-1 protocol is a bi-directional data link layer protocol specifically designed for short-range communications between surface vehicles and planetary orbiters in the Planetary Satellite Network as shown in Fig. 2, or between multiple spacecraft flying in a constellation [13]. The protocol incorporates five sub-layers: Coding and Synchronization, Frame, Medium Access Control, Data Services, and Input/Output. It provides both reliable and best-effort message delivery services; fixed block size and variable length messaging; and enables the orbiter to access several surface elements. The Medium Access Control (MAC) sub-layer is responsible for the establishment and termination of each communications session and for any operational changes in the Physical layer configuration made during the data services phase [26]. Some of the operations performed by the MAC sub-layer require a handshaking process between the sending transceiver and the responding transceiver based upon interpretation of values of the interlayer control signals. Because of the potential for loss of an inter-transceiver control message due to corruption across the space link, MAC activities require a persistence process to ensure that the expected results of an activity are verified before any other activity is started [26]. Although the protocol specification includes some procedures for contention management for multiple orbiters, further research is required to obtain a concrete solution that addresses the medium access problems of the Planetary Networks in the InterPlaNetary Internet. A subset of the Proximity-1 protocol will be first implemented for communication between the Mars Odyssey satellite, which is currently orbiting Mars, and the Mars 100 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 Express/Beagle II lander scheduled for launch in June 2003 [35]. As a result, although there exists previous relevant research in this direction, medium access control for InterPlaNetary Internet is still vastly unexplored research field. Furthermore, adaptive MAC protocols would be preferable to achieve unified efficient solution for the heterogeneous environments of the PlaNetary Networks. 6.2. Error control Another important function of the data link layer is the error control of transmission data. Typical error control mechanisms fall into two classes, i.e., ARQ and Forward Error Correction (FEC) [83]. ARQ mechanisms are mainly based on the retransmission of lost packets. FEC mechanisms, on the other hand, are based on the transmission of redundant information along with the original information so that the lost original data can be recovered from the redundant information. Although FEC is an effective mechanism for error control without retransmission, its main drawback is the transmission overhead. Hence, FEC increases the probability of successful frame delivery at the expense of increased bandwidth usage. The overhead is high, especially when the channel is loss free. In this section, we explore the currently proposed error control techniques and their shortcomings for InterPlaNetary Backbone and PlaNetary Networks. 6.2.1. InterPlaNetary backbone network The deep-space channel is safely modeled as the memory-less Additive White Gaussian Noise (AWGN) channel [38]. However, space links need to operate at reasonably low error conditions in order to deliver useful scientific data. For this reason, all NASA missions, including Earth orbit and deep space, design their RF systems to provide 105 or better bit error-rate (BER) after physical link coding [92]. Therefore, despite the existence of reliable transport layer protocols, the data link layer and its error control/correction capabilities play a crucial role in the overall performance of the deep space communications for both data and multimedia traffic delivery. The most important challenges for the selection and design of error control mechanisms are once again very long propagation delay of the InterPlaNetary Backbone links and the power constraints of the space nodes. Since ARQ mechanisms are mainly based on the retransmission of lost packets, they can be directly ruled out due to very long delays of the InterPlaNetary Backbone links. Therefore, FEC schemes become almost only practical option for error control in the InterPlaNetary Backbone Network. Because of the large transmission distances involved, which cause severe signal attenuation, powerful, low-rate codes, with complex decoding methods, are required [38]. There exists considerable amount of research on FEC in satellite and wireless communications [74,93]. However, all these works are for satellite links which have relatively much lower link delays than the InterPlaNetary Backbone links. Furthermore, most of the FEC schemes proposed for terrestrial satellite links consider rician fading channel, which may not hold for deep space channel of the InterPlaNetary Backbone links. Therefore, their performance are yet to be assessed for very long propagation delay links. For deep space missions, CCSDS Telemetry Standard includes the recommendation for the Telemetry Channel Coding [28] which defines possible practical FEC schemes to be used based on the performance requirements of the specific space mission. Thus far, many space missions exploited these FEC schemes described and recommended in the Telemetry Channel Coding recommendation. In the Telemetry Channel Coding recommendation, the rate 1/2 convolutional code is recommended for Gaussian channels. If the space channel for a specific mission is further bandwidth-constrained and cannot tolerate the increase in bandwidth required by the basic convolutional code, the punctured convolutional codes are also included in the recommendation due to its advantage of smaller bandwidth expansion. Furthermore, to accommodate the missions which require a greater coding gain, the CCSDS recommendation incorporates a concatenated codes, which are mainly concatenation of the convolutional code as the inner code with the Reed–Solomon code as the I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 outer code. The typical CCSDS concatenation standard is illustrated in Fig. 12. Moreover, the turbo codes are recommended to obtain even greater coding gain where it is required. On the other hand, the Packet Telecommand standard of the CCSDS seeks to achieve link-layer reliability by providing a go-back-n frame retransmission protocol, known as the Command Operation Procedure (COP) [13]. However, COP is mainly designed to address the short-range communication links. In [34], Advance Orbiting Systems recommendation by CCSDS includes a space link ARQ protocol (SLAP) for handling link layer issues of the space missions. SLAP is a part of the proposed data link layer structure, which is composed of virtual channel link control sub-layer and virtual channel access sub-layer. It performs ARQ link layer protocol over created Virtual Channels. However, ARQ mechanisms are not suitable for the InterPlaNetary Backbone links due to very long propagation delay. Hence, the virtual channels are protected by Reed Solomon forward error correction codes. AOS recommendations are used by the International Space Station and many Earth-observing missions [13]. Similarly, the Operating Missions as Nodes on the Internet (OMNI) project [102] uses convolutional and Reed Solomon forward error correction codes [81] to assure reliable frame delivery, since HDLC alone cannot provide reliable link layer transmission at the link layer. In summary, although there exists considerable experience in the application of error control in the Outer Channel Data Source (255, 233) RS Encoder Block Interleaver Inner Channel (2, 1, 7) Convolutional Encoder Space Channel Data Sink RS Decoder Block Interleaver Viterbi Decoder Fig. 12. An example of CCSDS concatenation standard [38]. 101 space communications, the performance of the existing solutions over the InterPlaNetery Backbone link and the development of the optimum error coding schemes are key open research issues yet to be investigated. 6.2.2. PlaNetary networks Due to the similarities between the PlaNetary Satellite Network links and the terrestrial satellite channels, the FEC schemes proposed for terrestrial satellite links [74,93] can be applied for the PlaNetary Satellite Networks. As the PlaNetary Surface Networks are composed of several mobile and static wireless ad hoc and sensors, the error control solutions proposed for terrestrial wireless networks, wireless sensor and ad-hoc networks are possible candidates for this environment. In this respect, ARQ becomes a viable option again due to its low delay access links. However, ARQ alone may lead to significant communication inefficiency in the existence of high link errors due to harsh space environments and atmospheric effects. Therefore, hybrid ARQ schemes, which take advantage of both FEC and ARQ methods, would be an important design principle for the PlaNetary Surface Networks. Furthermore, the scarcity of the power resources at the remote communication nodes such as sensors, landers, and rovers require specifically tailored FEC schemes which have high energyefficiency as well as powerful correcting capability. In this respect, the impact of adapting packet size and error control on energy efficiency in wireless systems is investigated in [70,78]. In [97], the authors examine this issue for wireless sensor networks and observe that FEC is generally inefficient if the decoding is performed using a microprocessor and recommend an on-board dedicated Viterbi decoder. Hence, hybrid ARQ schemes with simple encoding techniques that enable easy decoding might be preferred as the energy efficient solutions for the PlaNetary Surface Networks. The Proximity-1 link layer protocol [26] recommended by the CCSDS for the proximity space links also incorporates Coding and Synchronization sub-layer as one of its five main sub-layers. In this sub-layer, 32-bit Cyclic Redundancy Check 102 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 (CRC-32) are attached to the transfer frames for an asynchronous data link. On the other hand, due to the architectural heterogeneity of the PlaNetary Networks, one error control method simply may not be adequate to provide efficient error control within the PlaNetary Network. Therefore, adaptive error control schemes can significantly improve the communication performance while reducing design, implementation, and processing requirements. 6.3. Open research issues Although the recommendations by the CCSDS and research and implementation experiences within OMNI project framework are possible solution candidates for the link layer issues of the InterPlaNetary Internet, the area is vastly unexplored and open to extensive research effort to develop the solutions that fit best to the requirements of the InterPlaNetary Internet. The key open research issues can be summarized as follows: • MAC for InterPlaNetary Backbone Network. New MAC protocols should be devised which can accommodate extremely long delay InterPlaNetary Backbone links as well as high link errors. The MAC schemes should be able to accommodate both reliable data and multimedia traffic requirements. • MAC for PlaNetary Networks. New MAC protocols need to be developed for reliable data and time-sensitive multimedia flows in the PlaNetary Networks. The adaptive MAC protocols would be preferable in order to maintain seamless communication throughout the PlaNetary Surface and PlaNetary Satellite Networks. • Error Coding Schemes. In InterPlaNetary Internet, the error coding is detrimental to the performance of the entire communication. Therefore, several coding schemes should be explored to find the optimum solution for space communication needs. The design for such error coding scheme should also consider possible power and processing constraints in the remote communications nodes such as planetary landers and rovers. To address the requirements for the real-time delivery of the scientific audio and visual data error coding schemes with very fast and efficient encoding/decoding should be investigated. New and very fast FEC schemes such as Tornado codes [15], which are orders of magnitude faster than standard erasure codes such as Reed-Solomon, could be investigated. Furthermore, adaptive error control schemes would be preferred for PlaNetary Networks to achieve unified efficient error control in the heterogeneous environments of the PlaNetary Networks. Moreover, hybrid ARQ schemes with simple encoding techniques that enable easy decoding should be investigated as the energy efficient solutions for the PlaNetary Surface Networks. • Cross-Layer Optimization. As explained in Section 4.3, the cross-layer optimization is a significant research issue for efficient communication throughout the InterPlaNetary Internet. At the data link layer, MAC protocols and error control techniques should be developed by considering the interactions between the physical and network layers. For example, while the physical channel information should be exploited to the maximum, the information residing at the data link layer should be available to the upper layers. Therefore, these various avenues regarding to the cross-layer interaction and optimization should also be explored for the link layer protocols to achieve resource-efficient reliable data and multimedia transport throughout the InterPlaNetary Internet. Furthermore, the optimal packet size for the data link layer should be investigated to minimize the overhead and maximize the link performance considering the InterPlaNetary Internet link characteristics as well as the cross-layer interaction. 7. Physical layer technologies The physical layer is mainly responsible for frequency selection, carrier frequency generation, signal detection, modulation and data encryption. Most of the significant challenges for the realization of the InterPlaNetary Internet exist due to the physical layer issues. In this section, we explore the current and possible future physical layer tech- I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 nologies for different architectural elements of the InterPlaNetary Internet. 7.1. InterPlaNetary backbone network The wireless communication systems depend on the radiated RF energy, which is subject to spreading loss. This problem leads to significant signal power degradation over very high distance deep space links. In addition to this, signalto-noise ratio (SNR) requirement to reliably decipher the received symbols amplifies the problem. Therefore, the objective of high data rate delivery of bits at very long distances over deep space channel requires specifically tailored physical layer solutions. One possible approach is to increase the radiated signal power via high power amplifiers such as travelling wave tubes (TWT) or klystrons, both of which can produce output powers up to several thousand watts [111]. However, this comes with an expense of increased antenna size, cost, and also power problems for remote deep space nodes. The NASAÕs deep space network (DSN) has several deep space communication stations around the world with 70 meters antennas for the deep space missions. The DSN is designed to operate in SBand and X-Band (2GHz and 8GHz respectively) used for spacecraft telemetry, tracking and command. While the existing communication infrastructure within the DSN will play crucial role at the Earth side of the InterPlaNetary Internet, for high data rate InterPlaNetary Internet backbone new physical technologies are required. There exists considerable ongoing research to achieve high data rate physical layer InterPlaNetary backbone technologies. The new 34m antennas that are being designed to operate at Ka-band (32 GHz) will improve the data rate over currently achievable XBand frequencies [63]. In addition, the power amplifiers to amplify the radiated output power of Ka-band transmitters are being developed [67]. In the Cassini spacecraft, which is currently on the way to explore Saturn, 20 watt 32GHz TWT amplifier has been used [9]. On the other hand, despite its current technological immaturity, due to much higher data rates, reduced mass, size and power 103 requirements, the optical communication technologies will also be employed to achieve high data rate in the InterPlaNetary Internet backbone links [9,112]. However, the deployment of the optical communication technologies for the InterPlaNetary Internet still remains a largely unexplored domain. On top of the RF backbone technology, the carrier frequency selections and the RF modulation schemes for different space missions have been recommended by the CCSDS in [33]. Furthermore, several channel coding schemes are studied and recommended by the CCSDS for the deep space channel [27,28]. However, due to its high coding gain, compliance with CCSDS recommendations, and reduced receiver complexity, Turbo codes are mostly studied as a channel coding scheme at the physical layer of the deep space channel. In [8], the implementation of the Turbo decoder for a future deep space mission is studied. In [24], it has been shown that the Turbo codes, indeed, address the deep space channel needs as recommended by the CCSDS. 7.2. PlaNetary network The most important challenge in the design of physical layer technologies for the communication nodes in the PlaNetary Surface Networks is their physical limitations such as size, mass, and power constraints. For the Planetary Satellite and Surface Networks, the required physical layer technologies are the small volume, mass, and low-power RF receivers and transmitters operating over the UHF, X-band, and Ka-band frequency regimes; and very low power infrared depending on the planetary node communication requirements [9]. For these purposes, novel receiver-transmitters that are small in size, mass, and with low-power requirement need to be developed for physical layer technologies of the space nodes of the InterPlaNetary Internet. 7.3. Open research issues Despite the space communication experience of almost over 40 years, the requirements of the next generation space networks and hence the 104 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 InterPlaNetary Internet dictate advanced physical layer technologies. Open research issues in the physical layer technologies for the InterPlaNetary Internet range from power efficient transceiver design for InterPlaNetary Backbone Networks to modulation schemes for PlaNetary Surface Network nodes. These open issues are summarized as follows: one part of Mars and a magnetic storm occurring at another part. The discussion of time synchronization is separated into two parts. The first part describes about the challenges and protocols in deep-space time synchronization, and the second part discusses about the clocks designed for deepspace operations. These two parts are described in Sections 8.1 and 8.2. • Signal Power Loss. Powerful and size-, mass-, and cost-efficient antennas and power amplifiers need to be developed to minimize the effects of the spreading loss due to the extremely high propagation delay on the InterPlaNetary Backbone link performance. • Channel Coding. Efficient and powerful channel coding schemes should be investigated to achieve reliable and very high rate bit delivery over the long delay InterPlaNetary Backbone links. • Optical Communications. Optical communication technologies should be researched for a possible application to InterPlaNetary Backbone Network due to their ability to accommodate much higher data rates, reduced mass, size and power requirements. • Hardware Design. Low-power, low-cost transceiver and antennas need to be designed for PlaNetary Networks. • Modulation Schemes. Simple and low power modulation schemes need to be developed for the communication nodes in the PlaNetary Surface Networks such as networks of sensors, rovers, and landers. Ultra-wide band (UWB) could be explored for this purpose as it provides lowpower low-complexity wireless communication. 8.1. Challenges and protocols for deep-space 8. Deep-space time synchronization As space technology advances, more equipments may be deployed in the deep space for data collection and space missions. These equipments must have a common view of time in order to coordinate and communicate with each other. Also, time allows data to be interpreted in a meaningful way. For example, correlation data may be needed between a sand storm occurring at The challenges in synchronizing devices in deepspace are as follows [115]: • Variable and Long Transmission Delays. As explained in Section 4, the InterPlaNetary Backbone links have very long and variable delays. The long and variable delays may cause a fluctuating offset to the clock. • Variable Transmission Speeds. Depending on the characteristic of the link, the transmission speed varies. This is due to the environmental factor, e.g., solar radiation. It may produce a fluctuating offset problem. • Variable Temperature. The temperatures in different planets and deep-space are different. They may cause the clock to drift in a different rate. • Variable Electromagnetic Interference. This may cause the clock to drift or even permanent damage to the crystal if the equipment is not properly shielded. • Intermittent Connectivity. The situation may cause the clock offset to fluctuate and jump. • Impractical Retransmissions. A time synchronization protocol can not depend on message retransmissions to synchronize the clocks, because the distance between deep-space equipments are simply too large. • Distributed Time Servers. The deep-space equipments may be required to synchronize to their local time servers, i.e., equipments in Mars synchronize to time servers in Mars. As a result, the time servers in different planets must synchronize to each other in order to provide a common view of time. Currently, the Network Time Protocol (NTP) is being modified for the InterPlaNetary Internet to I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 provide time synchronization. Since NTP is not designed to handle mobile servers and clients (variable range and range rate with intermittent connectivity), the time offset has wiggles of few milliseconds of amplitude [115]. In addition, the light-time between Earth and another planet changes over time. For example, the light-time changes from little over 1 s to 270 ms during a period of around 1 year [115]. Furthermore, an NTP client was ported to a UoSAT-12 spacecraft [39], where it was used to synchronize the clock of the spacecraft to the Universal Coordinated Time (UTC) that was maintained by a time server. The time server was located in the US Naval Observatory. The experiment showed that the clock offset of the UoSAT-12 spacecraft was within 20 ms. As the NTP is being modified to provide time synchronization of devices in deep space, a different technology is used to provide precise synchronization among the three DSN sites, i.e., Goldstone, USA; Madrid, Spain; and Canberra, Australia. It is the DSN Frequency and Timing Sub-systems (FTS) [114]. The FTS uses several atomic frequency standards to synchronize the devices and provide references for the three DSN sites. It has 1015 frequency stability between 1000 and 10,000 s, and a timing pulse <2 ns jitter (1 r). Besides having protocols to synchronize time, the time must be represented in a meaningful way. Hence, a recommendation of ‘‘Time Code Formats’’ is proposed to the CCSDS [36]. It describes the formats of representing time in space data in- 105 terchange applications. The time code formats consist of a preamble field (P-field) and a time specification field (T-field). The P-field defines the options, parameters, and encoding structure of the T-field. There are four recommended time code formats, and each format requires a different Tfield and P-field configurations. These formats are described in Table 2. In addition to the time code formats, a recommendation for Proximity-1 space link protocol is proposed to the CCSDS [26]. This recommendation describes the procedures to find the correlation between the clocks of the proximity nodes. After such correlation is obtained, the initiator sends the UTC time and correlation data to remote hosts. The hosts use the UTC time and correlation data to correct the past UTC values or project the future UTC values. 8.2. Clocks and oscillators The stability and accuracy of a clock is very important, especially when the clock is used as a reference. The stability of a clock is separated into two types: short and long term stability. They both are required depending on the usage of the clocks. For example, short-term stable frequency standards enable measurements of quick signal fluctuations. They are cryogenic microwave oscillators: 10 K compensated sapphire oscillator, 77 K CSO, and superconducting cavity laser oscillator [114]. These oscillators have great short-term frequency stability and low phase noise. Table 2 Time code formats Format Description CCSDS Unsegmented Time Code Represents time in seconds and sub-seconds from January 1, 1958 or defined reference epoch Represents time in days, millisecond, and sub-milliseconds from January 1, 1958 or defined reference epoch Describes the time in year/month of year/day of month/hour/minute/second or year/day of year/hour/minute/second format Composes of ASCII characters in the YYYY-MM-DDThh:mm:ss.d ! dZ or YYYY-DDDThh:mm:ss.d ! dZ format, where Y, M, D, h, m, s, and d ! d are characters representing year, month, day, hour, minute, second, and fraction of a second, respectively; the character ‘‘T’’ and ‘‘Z’’ are calendar-time separator and time code terminator, respectively CCSDS Day Segmented Time Code CCSDS Calendar Segmented Time Code CCSDS ASCII Calendar Segmented Time Code 106 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 On the other hand, long-term stable frequency standards allow time to be accurately kept within 1 min over 10 billion years (Linear Ion Trap Frequency Standards (LITS)) [114]. The LITS uses the mercury and ytterbium ions that are suspended in space by radio frequency fields as a reference for frequency and time. These ions/atoms may be further cooled with laser to the desirable temperature. In essence, the internal frequency of the ion/ atom is more clean resulting a better atomic clock. Also, an atomic clock may also be synchronized [64]. Since atomic clock represents a significant advancement in technology, the Primary Atomic Reference Clock in Space (PARCS) is an atomicclock mission scheduled for 2008 [116]. It uses a laser-cooled cesium atomic clock and Global Positioning System satellites to transfer the time among space stations. The atomic clock will be Table 3 Current research projects Project name Research area HTTP location DTN, IPN Architecture and protocol design Bundling overlay protocol, postal class of service, security http://www.dtnrg.org http://www.ipnsig.org CCSDS Transport, network, data link and physical layers Security and space file transfer http://www.ccsds.org SCPS File handling (SCPS-FP), retransmission control (SCPS-TP) Data protection (SCPS-SP), networking (SCPS-NP) http://www.scps.org OMNI Operating missions as nodes on the Internet Investigate Internet technologies to enable space operation http://www.ipinspace. gsfc.nasa.gov DSN NASA Deep Space Network Support the exploration of the solar system and the universe http://deepspace.jpl.nasa.gov/ dsn Mars Network Space Communications Mobile Router Constellation of Microsats and MARSats as a Mars ‘‘Internet’’ Space data delivery and distributed communication Enable continuous connectivity using Internet-based protocols, for near-planetary observation and sensing spacecraft TDRS Space network tracking, data, voice and video services to NASA satellites, the shuttle, international space station, etc. http://marsnet.jpl.nasa.gov http://scp.grc.nasa.gov http://www.grc.nasa.gov/www/ RT2001/5000/5610ivancic1.html http://tdrs.gsfc.nasa.gov/Tdrsproject/ Sensor Webs An network of wireless, intra-communicating sensor pods Establish a virtual presence throughout the solar system http://sensorwebs.jpl.nasa.gov IPN3 A group of spacecraft equipped with gamma-ray burst detectors http://ssl.berkeley.edu/ipn3 DSN FTS Frequency and timing sub-system for NASAÕs DSN Provide frequency references and synchronized timing signals http://horology.jpl.nasa.gov/ dsnpage.html InterPlaNetary Timekeeping Synchronization issues in the InterPlaNetary Internet by modifying the Network Time Protcol (NTP) http://www.eecis.udel.edu/ ~mills/ipin.html PARCS Primary Atomic Reference Clock in Space Provide clock reference using a laser-cooled cesium atomic clock http://www.boulder.nist.gov/ timefreq/cesium/parcs.htm SUMO SUperconducting Microwave Oscillator Project Develop a superconducting cavity-stabilized oscillator system http://bigben.stanford.edu/sumo/ SpI Space Internet: Architecture and protocol design for Space Internet http://www.ece.gatech.edu/research/labs/bwn/ I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 compared to a clock generated by the SUperconducting Microwave Oscillator [117]. The objective of PARCS is to test gravitational theory, study laser-cooled atoms in microgravity, and improve the accuracy of timekeeping on earth [116]. 8.3. Open research issues Although the NTP protocol is currently being modified for the InterPlaNetary Internet, there are still many research issues that need to be resolved. Some of them are listed below: • Integration of Multi-domain Time. Since the distance between planets (an example of domains) are pretty far apart, the translation of time between these domains requires attention. If time synchronization packets are loss, the time between domains may fluctuate and deviate causing a temporal distortion in time. The distortion may be devastating for time critical missions. • Time Fluctuation. The variable delays may cause time fluctuation with significant magnitude that may be unacceptable for some space applications. • Clean Clocks/Oscillators. The clocks/oscillators need to handle radical changes in temperature and electro-magnetic radiations. If the clocks/ oscillators are stable, the time synchronization protocol requires less number of timing messages. 9. Conclusions The vision of future space exploration includes missions to deep space that require communication among planets, moons, satellites, asteroids, robotic spacecrafts, and crewed vehicles. This vision involves in the design and development of next generation deep space networks, which is expected to be the Internet of the deep space planetary networks and defined as InterPlaNetary Internet. However, there exist significant challenges for the realization of this vision in several aspects of the communication architecture. In this paper, these challenges, the current status of the 107 research efforts to address them are explored along with their short-comings. Many researchers and several international research organizations are currently engaged in developing the required technologies to realize the InterPlaNetary Internet. A list of current active related research projects is provided in Table 3. Despite the considerable amount of ongoing research in this direction, there still remains significantly challenging tasks for the research community to address before the realization of the InterPlaNetary Internet. We anticipate that this survey will serve as a building block for researchers around the world to motivate them to solve these challenging problems and help to realize the InterPlaNetary Internet. Acknowledgements NASAÕs VISION: to improve life here, to extend life to there, to find life beyond. NASAÕs MISSION: to understand and protect our home planet, to explore the Universe and search for life, to inspire the next generation of explorers. OUR AIM: to point out the research problems and inspire the researchers worldwide to realize these objectives. References [1] O.B. Akan, J. Fang, I.F. Akyildiz, Performance of TCP protocols in deep space communication networks, IEEE Communication Letters 6 (11) (2002) 478–480. [2] O.B. Akan, J. Fang, I.F. Akyildiz, TP-Planet: a reliable transport protocol for InterPlaNetary Internet, IEEE Journal on Selected Areas in Communications, 1st Quarter 2004 (to appear). [3] I.F. Akyildiz, G. Morabito, S. Palazzo, TCP-Peach: a new congestion control scheme for satellite IP networks, IEEE/ACM Transactions on Networking 9 (3) (2001) 307–321. [4] I.F. Akyildiz, X. Zhang, J. Fang, TCP-Peach+: enhancement of TCP-Peach for satellite IP networks, IEEE Communication Letters 6 (7) (2002) 303–305. [5] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci, Wireless sensor networks: a survey, Computer Networks 38 (4) (2002) 393–422. [6] I.F. Akyildiz, E. Ekici, M.D. Bender, MLSR: a novel routing algorithm for multi-layered satellite IP networks, 108 [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 IEEE/ACM Transactions on Networking 10 (3) (2002) 411–424. H. Balakrishnan, V.N. Padmanabhan, S. Seshan, R.H. Katz, A comparison of mechanisms for improving TCP performance over wireless links, IEEE/ACM Transactions on Networking 5 (6) (1997) 756–769. J.B. Berner, K.S. Andrews, Deep Space Network Turbo Decoder Implementation, in: Proceedings of the IEEE Aerospace Conference 2001, vol. 3, 2001, pp. 1149–1157. K. Bhasin, J. Hayden, J.R. Agre, L.P. Clare, T.Y. Yan, Advanced communication and networking technologies for Mars exploration, in: 19th Annual AIAA International Communications Satellite Systems Conference, Toulouse, France, April 2001. K. Bhasin, J.L. Hayden, Space Internet architecture and technologies for NASA enterprises, International Journal of Satellite Communications 20 (2002) 311–332. L.S. Brakmo, S.O Malley, L.L. Peterson, TCP Vegas: new techniques for congestion detection and avoidance, in: Proceedings of the ACM SIGCOMM 1994, October 1994, pp. 24–35. W. Bryant, Manned or unmanned into space? USA Today, 7D, Wednesday, February 26, 2003. S. Burleigh, V. Cerf, R. Durst, K. Fall, A. Hooke, K. Scott, H. Weiss, The InterPlaNetary Internet: a communications infrastructure for Mars exploration, in: 53rd International Astronautical Congress, The World Space Congress, Houston, Texas, October 2002. S. Burleigh, A. Hooke, L. Torgerson, K. Fall, V. Cerf, B. Durst, K. Scott, Delay-Tolerant networking: an approach to InterPlaNetary Internet, IEEE Communications Magazine 41 (6) (2003) 128–136. J. Byers, M. Luby, M. Mitzenmacher, A. Rege, A digital fountain approach to reliable distribution of bulk data, in: Proceedings of the ACM SIGCOMMÕ98, Vancouver, Canada, September 1998. C. Casetti, M. Gerla, S. Mascolo, M.Y. Sanadidi, R. Wang, TCP Westwood: bandwidth estimation for enhanced transport over wireless links, in: Proceedings of the ACM MOBICOM 2001, Rome, Italy, July 16–21 2001, pp. 287–297. S. Cen, C. Pu, J. Walpole, Flow and congestion control for Internet media streaming applications, in: Proceedings of the Multimedia Computing and Networking, January 1998. V. Cerf et al., InterPlaNetary Internet (IPN): architectural definition, Internet draft, draft-irtf-ipnrg-arch-00. txt, May 2001. V. Cerf et al., Delay-Tolerant Network Architecture, Internet draft, draft-irtf-dtnrg-arch-02.txt, March 2003. R.J. Cesarone, R.C. Hastrup, D.J.Bell, D.T. Lyons, K.G. Nelson, Architectural design for a Mars communications and navigation orbital infrastructure, Paper presented at the AAS/AIAA Astrodynamics Specialist Conference, Girwood, Alaska, August 16–19, 1999. J.-H. Chang, L. Tassiulas, Energy conserving routing in wireless ad hoc networks, in: Proceedings of the [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] IEEE INFOCOM 2000, Tel Aviv, Israel, March 2000, pp. 22–31. K. Chandran, S. Raghunathan, S. Venkatesan, R. Prakash, A feedback-based scheme for improving TCP performance in ad hoc wireless networks, IEEE Personal Communications 8 (1) (2001) 34–39. C. Chen, E. Ekici, I.F. Akyildiz, Satellite grouping and routing protocol for LEO/MEO satellite IP networks, in: 5th International Workshop on Wireless Mobile Multimedia (WoWMoM 2002), pp. 109–116, Atlanta, GA, September 28, 2002. F. Chiaraluce, E. Gambi, R. Garello, P. Pierleoni, G.P. Calzolari, R. Vassallo, On the new CCSDS standard for space telemetry: turbo codes and symbol synchronization, in: Proceedings of the IEEE ICC 2000, vol. 1, 2000, pp. 451–454. L.P. Clare, J.R. Agre, T.-Y. Yan, Considerations on communications network protocols in deep space, in: Proceedings of the IEEE Aerospace Conference 2001, vol. 2, BigSky, MT 11–15, March 2001, pp. 943–950. Consultative Committee for Space Data Systems, Proximity-1 Space Link Protocol, Recommendation for Space Data System Standards, CCSDS 211.0-B-1, Blue Book (1), CCSDS, Washington, DC, October 2002. Consultative Committee for Space Data Systems, Packet Telemetry, Recommendation for Space Data System Standards, CCSDS 102.0-B-5, Blue Book (5), CCSDS, Washington, DC, November 2000. Consultative Committee for Space Data Systems, Telemetry Channel Coding, Recommendation for Space Data System Standards, CCSDS 101.0-B-6, Blue Book (6), CCSDS, Washington, DC, October 2002. Consultative Committee for Space Data Systems, CCSDS File Delivery Protocol, Recommendation for Space Data System Standards, CCSDS 727.0-B-1, Blue Book (1) CCSDS, Washington, DC, January 2002. Consultative Committee for Space Data Systems, Space Communications Protocol Specification-Transport Protocol (SCPS-TP), Recommendation for Space Data Systems Standards, CCSDS 714.0-B-1, Blue Book (1), CCSDS, Washington, DC, May 1999. Consultative Committee for Space Data Systems, Space Communications Protocol Specification (SCPS)––Network Protocol (SCPS-NP), Draft recommendation for Space Data Systems Standards, CCSDS 713.0-B-1, Blue Book, Newport Beach, CA, May 1999. Consultative Committee for Space Data Systems, Telecommand Part 1 Channel Service, Recommendation for Space Data System Standards, CCSDS 201.0-B-3, Blue Book (3) CCSDS, Washington, DC, June 2000. Consultative Committee for Space Data Systems, Radio Frequency and Modulation Systems––Part 1 Earth Stations and Spacecraft, Recommendation for Space Data System Standards, CCSDS 401.0-B, Blue Book, CCSDS, Washington, DC, March 2003. Consultative Committee for Space Data Systems, Advanced Orbiting Systems, Networks And Data Links: I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] Architectural Specification, Recommendation for Space Data System Standards, CCSDS 701.0-B-3, Blue Book (3), CCSDS, Washington, DC, June 2001. Consultative Committee for Space Data Systems, The Rapporteur (5), January 2003. Consultative Committee for Space Data Systems, Time Code Formats, Recommendation for Space Data System Standards, CCSDS 301.0-B-3., Blue Book (3) CCSDS, Washington, DC, January 2002. Consultative Committee for Space Data Systems, Space Communications Protocol Standards (SCPS): Rationale, Requirements and Application Notes, CCSDS710.0-G0.4, draft green book, August, 1998. D.J. Costello Jr., J. Hagenauer, H. Imai, S.B. Wicker, Applications of error-control coding, IEEE Transactions of Information Theory 44 (6) (1998) 2531–2560. E. Criscuolo, K. Hogie, R. Parise, Transport protocols and applications for Internet use in space, in: Proceedings of the IEEE Aerospace Conference 2001, vol. 2, 2001, pp. 951–962. S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998. K.A. Delin, S.P. Jackson, The sensor web: a new instrument concept, Paper Presented at SPIEÕs Symposium on Integrated Optics, San Jose, CA, January 20–26, 2001. K.A. Delin, S.P. Jackson, Sensor web for in-situ exploration of gaseous biosignatures, Paper Presented at the 2000 IEEE Aerospace Conference, Big Sky, MT, 2000. R.C. Durst, P.D. Feighery, K.L. Scott, Why not use the Standard Internet Suite for the InterPlaNetary Internet? Available from <http://www.ipnsig.org/techinfo.htm>. R.C. Durst, G.J. Miller, E.J. Travis, TCP extensions for space communications, Wireless Networks 3 (5) (1997) 389–403. R.C. Durst, Delay-Tolerant Networking: an example InterPlaNetary Internet bundle transfer, Internet draft, draft-irtf-dtnrg-ipn-bundle-xfer-00.txt, March 2003. E. Ekici, I.F. Akyildiz, M.D. Bender, A distributed routing algorithm for datagram traffic in LEO satellite networks, IEEE/ACM Transactions on Networking 9 (2) (2001) 137–147. T.A. Ely et al., Mars network constellation design drivers and strategies, Paper Presented at AAS/AIAA Astrodynamics Specialist Conference, Girwood, Alaska, August 16–19, 1999. K. Fall, A message-switched architecture for challenged Internets, Technical Report, IRB-TR-02-010, Intel Research Berkeley, July 2002. J. Fang, I.F. Akyildiz, RCP-Planet: a rate control scheme for multimedia traffic in InterPlaNetary Internet, submitted for publication, July 2003. S. Floyd, T. Henderson, The NewReno Modification to TCPÕs Fast Recovery Algorithm, RFC 2585, April 1999. S. Floyd, M. Handley, J. Padhye, J. Widmer, Equationbased congestion control for unicast applications, in: Proceedings of the ACM SIGCOMM 2000, August 2000. S. Floyd, M. Handley, J. Padhye, A comparison of equation-based and AIMD congestion control, ACIRI [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] 109 Technical Teport, May 2000, Available from <http:// www.aciri.org/tfrc/aimd.pdf>. T. Goff, J. Moronski, D.S. Phatak, V. Gupta, FreezeTCP: A true end-to-end TCP enhancement mechanism for mobile environments, in: Proceedings of the INFOCOM 2000, vol. 3, Israel, 2000, pp. 1537–1545. M. Handley, J. Padhye, S. Floyd, J. Widmer, TCP Friendly Rate Control (TFRC): Protocol Specification, Internet Draft, April 2002. R.C. Hastrup, R.J. Cesarone, J.M. Srinivasan, D.D. Morabito, Mars Comm/Nav MicroSat Network, Paper presented at the 13th AIAA/USU Conference on Small Satellites. Logan, Utah, August 23–26, 1999. J. Heidemann, F. Silva, C. Intanagonwiwat, R. Govindan, D. Estrin, D. Ganesan, Building efficient wireless sensor networks with low-level naming, in: Proceedings of the SOSP 2001, October 2001, pp. 146–159. T.R. Henderson, R.H. Katz, Transport protocols for Internet-compatible satellite networks, IEEE Journal on Selected Areas in Communications 17 (2) (1999) 326–344. T.R. Henderson, R.H. Katz, On distributed, geographicbased packet routing for LEO satellite networks, in: Proceedings of the IEEE GLOBECOM 2000, vol. 2, 2000 pp. 1119–1123. K. Hogie, E. Criscuolo, R. Parise, Link and routing issues for Internet protocols in space, in: Proceedings of the IEEE Aerospace Conference 2001, vol. 2, 2001, pp. 963–976. To NAT or IPv6––that is the question, Satellite Broadband Magazine, December 2000, Available from <http://www. telstra.net/gih>. V. Jacobson, Congestion avoidance and control, in: Proceedings of the ACM SIGCOMM 1988, pp. 314– 329, Stanford, August 1988. V. Jacobson, Berkeley TCP Evolution from 4.3-Tahoe to 4.3-Reno, in: Proceedings of the British Columbia Internet Engineering Task Force, July 1990. V. Jamnejad, J. Huang, B. Levitt, T. Pham, R. Cesarone, Array antennas for JPL/NASA Deep Space Network, in: Proceedings of the IEEE Aerospace Conference 2002, vol. 2, 2002, pp. 911–921. R. Jozsa, D.S. Abrams, J.P. Dowling, C.P. Williams, Quantum clock synchronization based on shared prior entanglement, Physical Review Letters 85 (9) (2000) 2013– 2020. P. Juang, H. Oki, Y. Wang, M. Martonosi, L.-S. Peh, D. Rubenstein, Energy-efficient computing for wildlife tracking: design tradeoffs and early experience with ZebraNet, in: Proceedings of the 10th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), San Jose, CA, October 2002, pp. 96–107. V. Kawadia, P.R. Kumar, Power control and clustering in ad hoc networks, in: Proceedings of the IEEE Infocom 2003, San Francisco, CA, April 2003. D.S. Komm, R.T. Benton, H.C. Limburg, W.L. Menninger, Z. Xiaoling, Advances in space TWT efficiencies, IEEE Transactions of Electronic Devices 48 (1) (2001) 174–176. 110 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 [68] C. Kuhm€ unch, G. K€ uhne, Efficient video transport over Lossy Networks, Technical Report TR-98-798, University of Mannheim, April 1998. [69] L. Lemmerman et al., Earth science vision: platform technology challenges, in: International Geoscience and Remote Sensing Symposium (IGARSS 2001), Sydney, Australia, July 2001. [70] P. Letteri, M.B. Srivastava, Adaptive frame length control for improving wireless link throughput, range, and energy efficiency, in: Proceedings of the IEEE INFOCOM Õ98, San Francisco, USA, March 1998, pp. 564–571. [71] K. Leung, S. Shell, N.D. Ivancic, D.H. Stewart, T.L. Bell, B.A. Kachmar, Application of Mobile-IP to space and aeronautical networks, in: Proceedings of the IEEE Aerospace Conference 2001, vol. 2, 2001, pp. 1027–1033. [72] Y. Liang, E. Steinbach, B. Girod, Real-time voice communication over the Internet using packet path diversity, in: Proceedings of the ACM MultimediaÕ01, Ottawa, Canada, October 2001. [73] J. Liu, S. Singh, ATCP: TCP for mobile Ad Hoc networks, IEEE Journal on Selected Areas in Communications 19 (7) (2001) 1300–1315. [74] H.-L. Lou, M.J.F.-G. Garcia, V. Weerackody, FEC scheme for a TDM-OFDM based satellite radio broadcasting system, IEEE Transactions on Broadcasting 46 (1) (2000) 60–67. [75] M. Mathis, J. Mahdavi, S. Floyd, A. Romanov, TCP selective acknowledgement options, RFC 2018, 1996. [76] M. Mathis, J. Mahdavi, Forward acknowledgement: refining TCP congestion control, in: Proceedings of the ACM SIGCOMM 1996, pp. 281–292, August 1996. [77] M. Miyabayashi, N. Wakamiya, M. Murata, H. Miyahara, MPEG-TFRCP: video transfer with TCP-friendly rate control protocol, in: Proceedings of the IEEE ICC 2001, vol. 1, Helsinki, June 2001, pp. 137–141. [78] B. Narendran, J. Sienicki, S.Yajnik, P. Agrawal, Evaluation of an adaptive power and error control algorithm for wireless systems, in: Proceedings of the IEEE ICC 1997, Montreal, Canada, June 1997. [79] A. Nasipuri, S.R. Das, On-demand multipath routing for mobile ad hoc networks, in: Proceedings of the IEEE International Conference on Computer Communications and Networks (ICCCN), Boston, MA, October 1999, pp. 64–70. [80] H. Oman, Deep space travel energy sources, IEEE Aerospace and Electronics Systems Magazine 18 (2) (2003) 28–35. [81] R. Parise, K. Hogie, E. Criscuolo, R. Schnurr, J. Wesdock, M. Burns, A standard link-layer protocol for space mission communications, in: Proceedings of the International Telemetring Conference, 2002. [82] C. Perkins, IP Mobility Support, RFC2002, October 1996. [83] C. Perkins, O. Hodson, V. Hardman, A survey of packet loss recovery techniques for streaming media, IEEE Network 12 (5) (1998) 40–48. [84] C. Perkins, Ad Hoc Networks, Addison-Wesley, Reading, MA, 2000. [85] H. Peyravi, Medium access control protocols performance in satellite communications, IEEE Communications Magazine 37 (3) (1999) 62–72. [86] J. Postel, Domain Name System Structure and Delegation, Internet RFC1591, March 1994. [87] R. Ramanathan, R. Rosales-Hain, Topology control of multihop wireless networks using transmit power adjustment, in: Proceedings of the IEEE INFOCOM 2000, Tel Aviv, Israel, March 2000, pp. 404–413. [88] R. Rejaie, M. Handley, D. Estrin, Quality adaptation for congestion controlled video playback over the Internet, in: Proceedings of the ACM SIGCOMM 1999, Cambridge, MA, September 1999. [89] R. Rejaie, M. Handley, D. Estrin, RAP: an end-to-end rate-based congestion control mechanism for realtime streams in the Internet, in: Proceedings of the IEEE INFOCOM 1999, vol. 3, 1999, pp. 1337–1345. [90] I. Rhee, V. Ozdemir, Y. Yi, TEAR: TCP emulation at receivers––flow control for multimedia streaming, Technical Report, Department of Computer Science, North Carolina State University, Raleigh, North Carolina, April 2000. [91] V. Rodoplu, T.H. Meng, Minimum energy mobile wireless networks, IEEE Journal on Selected Areas of Communications 17 (8) (1999) 1333–1344. [92] R. Schnurr, J. Rash, K. Hogie, R. Parise, E. Criscuolo, NASA/GSFC Space Internet: extending Internet technology into Space, NASA/GSFC Space Internet––NRO Technical Seminar, NASA Goddard Space Flight Center, May 2001. [93] J.B. Schodorf, Error control for Ka-band land mobile satellite communications systems in: Proceedings of the IEEE VTC 2000, vol. 4, 2000, pp. 1894–1901. [94] K. Scott, S. Burleigh, Bundle Protocol Specification, Internet Draft, draft-irtf-dtnrg-bundle-spec-00.txt, March 2003. [95] R.C. Shah, S. Roy, S. Jian, W. Brunette, Data MULEs: modeling a three-tier architecture for sparse sensor networks, in: Proceedings of the IEEE Workshop on Sensor Network Protocols and Applications (SNPA), May 2003, pp. 30–41. [96] A. Shaikh, L. Kalampoukas, R. Dube, A. Varma, Routing stability in congested networks: experimentation and analysis, in: Proceedings of the ACM SIGCOMM 2000, August 2000, pp. 163–174. [97] E. Shih, B.H. Calhoun, S. Cho, A. Chandrakasan, Energyefficient link layer for wireless microsensor networks, in: Proceedings of the IEEE Computer Society Workshop on VLSI 2001, Orlando, FL, April 2001, pp. 16–21. [98] S. Singh, M. Woo, C.S. Raghavendra, Power-aware routing in mobile ad hoc networks, in: Proceedings of the ACM Mobicom 1998, Dallas, TX, October 2000, pp. 181–190. [99] P. Sinha, N. Venkitaraman, R. Sivakumar, V. Bharghavan, WTCP: a reliable transport protocol for wireless wide-area networks, in: Proceedings of the ACM MOBICOM 1999, Seattle, Washington, August 1999, pp. 231–241. [100] J. Tang, G. Morabito, I.F. Akyildiz, and M. Johnson, RCS: a rate control scheme for real-time traffic in networks I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] with high bandwidth-delay products and high bit error rates, in: Proceedings of the IEEE INFOCOM 2001, vol. 1, 2001, pp. 114–122. The Sensor Web project, NASA Jet Propulsion Laboratory, Available from <http://sensorweb.jpl.nasa.gov>. The OMNI Project, NASA Goddard Space Flight Center, Available from <http://ipinspace.gsfc.nasa.gov>. The NASA Deep Space Network (DSN), Available from <http://deepspace.jpl.nasa.gov/dsn/>. The Delay-Tolerant Networking Research Group, Available from <http://www.dtnrg.org>. The National Space Science Data Center (NSSDC), NASA Goddard Space Flight Center, Chronology of Lunar and Planetary Exploration, Available from <http:// nssdc.gsfc.nasa.gov/planetary/chrono.html>. D.T. Tran, F.J. Lawas-Grodek, R.P. Dimond, W.D. Ivancic, SCPS-TP, TCP and rate-based protocol evaluation for high-delay, error-prone links, in: SpaceOps 2002, Houston, TX, October 2002. E. Travis, The InterPlaNetary Internet: architecture and key technical concepts, Paper Presented at the Internet Global Summit, INET 2001, June 5, 2001. A. Vahdat, D. Becker, Epidemic routing for partiallyconnected Ad hoc networks, Technical Report, Duke University, 2000. F. Warthman, Delay-tolerant networks (DTNs): A Tutorial v1.1, March, 2003, Available from <http://dtnrg.org/ tutorials/warthman-1.1.pdf>. R. Wattenhofer, L. Li, P. Bahl, Y. Wang, Distributed topology control for power efficient operation in multihop wireless ad hoc networks, in: Proceedings of the IEEE INFOCOM 2001, Anchorage, AK, April 2001, pp. 1388– 1397. M. Williamson, Deep space communications, IEE Review 44 (3) (1998) 119–122. K. Wilson, M. Enoch, Optical communications for deep space missions, IEEE Communications Magazine 38 (8) (2000) 134–139. Available from <http://mailman.dtnrg.org/pipermail/dtninterest/2002-October/000013.html>. Available from <http://horology.jpl.nasa.gov/dsnpage. html>. Available from <http://www.eecis.udel.edu/mills>. Available from <http://www.boulder.nist.gov/timefreq/cesium/parcs.htm>. Available from <http://bigben.stanford.edu/sumo/>. Ian F. Akyildiz received his BS, MS, and Ph.D. degrees in Computer Engineering from the University of Erlangen-Nuernberg, Germany, in 1978, 1981 and 1984, respectively. Currently, he is the Ken Byers Distinguished Chair Professor with the School of Electrical and Computer Engineering, Georgia Institute of Technology and Director of Broadband and Wireless Networking Laboratory. 111 He has held visiting professorships at the Universidad Tecnica Federico Santa Maria, Chile, Universite Pierre et Marie Curie (Paris VI), Ecole Nationale Superieure Telecommunications in Paris, France, Universidad Politecnico de Cataluna in Barcelona, Spain, and Universidad Illes Baleares, Palma de Mallorca, Spain. He has published over two-hundred technical papers in journals and conference proceedings. He is an Editor-in-Chief of Computer Networks (Elsevier) and for the newly launched AdHoc Networks Journal and an Editor for ACM-Kluwer Journal of Wireless Networks. He is a past editor for IEEE/ ACM Transactions on Networking (1996–2001), Kluwer Journal of Cluster Computing (1997–2001), ACM-Springer Journal for Multimedia Systems (1995–2001) as well as for IEEE Transactions on Computers (1992–1996). He guest-edited more than 10 special issues for various journals in the last decade. He was the technical program chair of the ‘‘9th IEEE Computer Communications’’ workshop in 1994, for ACM/IEEE MOBICOMÕ96 (Mobile Computing and Networking) conference, IEEE INFOCOMÕ98 (Computer Networking Conference), as well as IEEE ICCÕ2003 (International Conference on Communications). He served as the General Chair for the premier conference in wireless networking, ACM/IEEE MOBICOMÕ2002, Atlanta, September 2002. He is the co-founder and co-General Chair of the newly established ACM SenSysÕ03 conference on Sensor Systems which will take place in Los Angeles in November 2003. He is an IEEE FELLOW (1995), an ACM FELLOW (1996). He received the ‘‘Don Federico Santa Maria Medal’’ for his services to the Universidad of Federico Santa Maria in Chile in 1986. He served as a National Lecturer for ACM from 1989 until 1998 and received the ACM Outstanding Distinguished Lecturer Award for 1994. He received the 1997 IEEE Leonard G. Abraham Prize award (IEEE Communications Society) for his paper entitled ‘‘Multimedia Group Synchronization Protocols for Integrated Services Architectures’’ published in the IEEE Journal of Selected Areas in Communications (JSAC) in January 1996. He received the 2002 IEEE Harry M. Goode Memorial award (IEEE Computer Society) with the citation ‘‘for significant and pioneering contributions to advanced architectures and protocols for wireless and satellite networking’’. He received the 2003 IEEE Best Tutorial Award (IEEE Communications Society) for his paper entitled ‘‘A Survey on Sensor Networks’’, published in IEEE Communications Magazine, in August 2002. He received the 2003 ACM SIGMOBILE award for his significant contributions to mobile computing and wireless networking. His current research interests are in Sensor Networks, InterPlaNetary Internet, Wireless Networks, Satellite Networks and the Next Generation Internet. Özgür B. Akan received his B.Sc. and M.Sc. degrees in Electrical and Electronics Engineering from Bilkent University and Middle East Technical University, Ankara, Turkey, in 1999 and 2001, respectively. He is currently a Research Assistant in the Broadband and Wireless Networking Laboratory and pursuing his Ph.D. degree at the School of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta, GA. His current research interests include adaptive transport protocols for heterogeneous wireless architectures, next generation wireless networks, and deep space communication networks. 112 I.F. Akyildiz et al. / Computer Networks 43 (2003) 75–112 Chao Chen received the B.E. and M.E. degrees from Department of Electronic Engineering, Shanghai Jiao Tong University, Shanghai, China in September, 1998 and March, 2001 respectively. She is currently working toward the Ph.D. degree in the School of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta. She is a graduate research assistant in the Broadband and Wireless Networking Laboratory at the Georgia Institute of Technology. Her research interests include routing in satellite networks, wireless networks, and interplanetary networks. Jian Fang got his Bachelor, Master and Doctor degrees from Shanghai Jiao Tong University, China. After graduation, he had been a research associate in the department of computer science and engineering, the Chinese University of Hong Kong for one year. Currently, he is a Research Assistant in the Broadband and Wireless Networking Laboratory, Georgia Institute of Technology, pursuing his Ph.D. degree. Weilian Su received his BS degree in Electrical and Computer Engineering from Rensselaer Polytechnic Institute in 1997. He also received his MS degree in Electrical and Computer Engineering from Georgia Institute of Technology in 2001. In 2003, he received the IEEE Communications Society 2003 Best Tutorial Paper Award. Currently, he is enrolled in the Ph.D. program of the School of Electrical and Computer Engineering, Georgia Institute of Technology. His research interests include timing recovery and sensor networks.