Overview Of Interplanetary Internet System

DOI : 10.17577/IJERTV2IS3350

Download Full-Text PDF Cite this Publication

Text Only Version

Overview Of Interplanetary Internet System

Priyanka Jaiswal, Prof. Pragati Patil, Prof.Parul Bhanarkar

Student (M-tech-CSE) AGPCE, HOD (M-tech-CSE) AGPCE, Professor (M-tech CSE) AGPCE,Nagpur

Abstract

Space has always been a matter of awe for humans during all ages. For some it has always been something to be afraid of and for some it has been like a vast ocean of knowledge to take a plunge and check for themselves what is in store up there. And then again there has always been speculations of life outside this planet of ours we call Earth.

Man has always tried to gather more knowledge in this field. In order to gather more knowledge in this field man has at some particular intervals of time, so that they send some information before they die out. Thus, a fast and reliable mode of information transfer is a prerequisite so that the collected information does not go in vain.

There is even a very high chance of humans going to Mars before the end of this century. And that there is a clear chance of even humans setting up a base in Mars for

future explorations, which would mean increased expectations on these systems for setting up even faster and reliable communications.

So this interplanetary internet system is basically an answer to these problems. As a lot of work has already been undertaken, so here there is no looking back. Thus, here I have tried my best to put forward the knowledge I have acquired on this inexhaustible field. Always sent various rovers and robots and even human. Interplanetary internet system is just another milestone in this quest of knowledge.

Interplanetary internet (IPN) System, as the name suggests, it deals with the interconnection of the two different worlds separated by large, void space. Just the name of the topic is sufficient to bring a sparkle in the eyes of even the most ignorant person on this earth. Albeit however abstract the idea might seem it is not in its infant hood any more

1. Introduction

. A lot of work has been undertaken in this field since 2003, the first time probably when the concept was taken up seriously by the science community.

A lot of exploratory missions have already been undertaken on distant planets, which require setting up lot of robotic rovers and such other information gathering robots.

These robots need to send their findings to Earth via some path

    1. Need of IPN

      Even before this concept scientists have been able to communicate with the robots and space vehicles using radio frequencies. But those systems were directed and specific, meant for only the system they directed the

      commands to. However, now the basic stress is on the data transfer in and out. The rovers or the robots, or even humans for that matter, should be able to send their readings and recordings. And even they need to be informed of any latest proceedings going on back home here on Earth, such as any new system to be deployed for the help of the people already there, new instructions etc. For all these and many more reasons IPN is the one and only solution so far.

    2. Required parameters of IPN

Space is not so friendly, neither much is known about it. There are a lot of problems we need to consider before taking a plunge at this concept of setting up network of network in this vast void space. It would never be feasible nor would it ever make sense to cite out all the problems that could surface in the outer space. But still some basic problems can always be stated out as standardized problems that we need to take care of before we get to use this system.

Some of the problems are stated as under

  • Distance – On Earth, we are only a fraction of a light second apart, making Earth communication nearly instantaneous over the Internet. As you move farther out into space, however, there is a delay of minutes or hours because light has to travel millions of miles, instead of thousands of miles, between transmitter and receiver.

  • Line of sight obstruction – Anything that blocks the space between the signal transmitter and receiver can interrupt communication.

  • Weight – High-powered antennas that would improve communication with deep space probes are often too heavy to send

on a space mission, because the payload must be light and efficiently used.

There are many more major problems associated to network connectivity to be discussed later.

1. Literature Survey

This study is actually funded by DARPA (Defense Advanced Research Projects Association) as it is expected that the protocols and architecture discovered in this research would help even our very own terrestrial networks.

Another main organization behind this huge research is the Consultative Committee for Space Data Systems (CCSDS). This organization carries out all the main administrative tasks in this field and also decides the amount of fund distribution. This organization has even defined different protocols for data transfers.

  1. Methodology

    1. The architecture

      The current state-of-the-art infrastructure for the interplanetary internet systems consists of many different communication techniques and elements. The various elements used in these networks are stated as in the as follows and shown in the following figure.

      Figure 1: Elements used in IPN Network

      • The Interplanetary Internet Backbone Network

      • The backbone network consists of the ground network what we use here back on Earth. This network includes the major NASA intranets and virtual private networks. These networks carry the major data connection for all the terrestrial networks, including all commercial or foreign communication system that may be employed.

      • Access Network

        The communication interfaces between the backbones and the mission space crafts and vehicles, and the local area networks onboard the space craft or the vehicles. Thus here we are actually talking about the interconnectivity between the ones we have already established here, i.e. the one

        existing here on the terrestrial surface to the ones that we intend to connect.

      • Inter-spacecraft Network

        The networks of spacecrafts flying in a constellation, formation or cluster are also need to be considered to be able to communicate among them.

      • Proximity Network

        Space vehicles (rovers, air planes, aerobots), landers and sensors spread out and in an ad hoc network.

    2. IPN Network Architecture

      Suitable network architecture for IPN is based on the bundle concept introducing a new, so called bundle layer. This convergence layer comprises transport and application layer functionalities. The transport of data packets between IPN nodes is handled by a bundle protocol, while the provision of end-to-end connectivity between source and destination node is handled by application layer functionalities. Since in interplanetary network environments continuous end-to-end connectivity cannot be assumed, the bundle layer must have the capability of storing data bundles as well as their address and route to their final destination until they can be forwarded to the next hop and so on. The protocol stack of IPN architecture consists of four layers: physical layer, data link layer, network layer, and bundle layer.

      For the proposed architecture, five key research areas have been defined by :

      • Inter-internet dialogs

      • Function of the unique nodes of IPN

      • Security architecture

      • Backbone network for IPN

      • Issues in deploying internets on remote targets

      1. Inter-Internet Dialogs

        Inter-internet dialogs describe the interconnection of regional internets resident on different planets, or of such internets with the Earth. A major challenge in this context is the definition of an adequate naming strategy. The common DNS mechanism is not applicable due to the distributed mechanism of the DNS database, in which the portion of the database capable of resolving a name to its address can be very distant from the requesting host. While solving this problem, for IPN a new naming concept has been elaborated. Each IPN node is given a naming tuple consisting of an administrative and a routing part. The administrative part contains an IPN name resolvable to an useful address within a certain IPN region (locally deployed internet). The routing part defines the corresponding IPN region. DNS requests will be forwarded around the network to the IPN region defined in the routing part, where the IPN name will be resolved to its address by a local DNS- server. The IPN name will be given in the following manner: {administrative part, routing part}. The routing part serves as a new top level domain, denoting a fictive domain name used for routing purposes.

      2. The Function of the Unique IPN Nodes

        IPN nodes are members of store- and-forward chains and must perform resource allocation to support bundle transfers. They are responsible for routing bundles between IPN domains. IPN nodes can be classified into three types:

        1. Bundle Agents (hosts): Bundle Agents are comparable to hosts in common internet terminology. They build and consume bundles and represent the endpoints of an end-to-end bundle transmission.

        2. IPN Relays (routers): IPN Relays are comparable to routers. They receive and forward bundles toward their destination, within or between IPN regions, performing forwarding of bundles without altering their contents.

        3. IPN Gateways: IPN Gateways represent the interface between IPN regions, for which inter-internet dialogs are provided. They must provide reliable backbone connectivity for long-haul communication links.

      3. Security Architecture

        Although no detailed security requirements are known at the moment, various security mechanisms must be provided to ensure protection of the IPN infrastructure itself and the bundles traversing it. Possible mechanisms include authorisation, authentication, and encryption.

      4. IPN Backbone

        In order to provide reliable connections over IPN, a stable backbone network must be available. The main challenge for this backbone is represented by intermittent instead of continuous connectivity. Unlike terrestrial Internet, where packets are dropped if connection to the destination does not exist, in IPN every gateway has to keep incoming packets in memory until they can be forwarded to the next hop and the correct

        reception of these data bundles is acknowledged. Appropriate store-and forward strategies can be achieved with the functionalities provided at the bundle layer of the IPN architecture. However, these functionalities require huge amounts of memory in the IPN backbone nodes.

      5. Deployed Internets

        A deployed internet describes an IPN region which is connected to the backbone or other deployed internets through a gateway [1]. Within a deployed internet, similar scenarios to Earth environment will occur. The communication sessions will be established over short-haul links. A deployed internet must be capable of using domain name space for referencing objects and systems across deployed internets.

  2. The Design

    1. The communication protocol suite

As the IPN Internet consists of heterogeneous network architectures as shown in Fig. Of IPN internet architecture each of these components may have to run a different set of protocols that best fits the environment. In this section we explore the current and proposed protocol suites to realize communication in the IPN Internet.

The main communication factors to be taken under consideration are as different types of networks are being deployed throughout the InterPlaNetary Internet, the ability to communicate with each other is vital. There has to be connection at all points of time, so that the connection never goes out of connection for a long time without even getting the attention. So in short all the nodes should

be connected or at least the disconnection should be known to the base station.

Here, also we sub divide the network into manageable components so as to make the maintenance a lot easier. These network components can be stated as Interplanetary Backbone Network, Interplanetary External Network, and Planetary Network. The current space/ground protocol stack was proposed by the Consultative Committee for Space Data Systems (CCSDS). This organization is associated with considering the major protocols for all space networks. The current space/ground protocol stack is proposed by the CCSDS for space communications. The protocol stack consists of five layers which performs the eight functionality of networking: 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.

  1. The Communication protocols

        1. 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. 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.

        2. 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.

        3. Space Link

          Providing retransmission capability in deep space environment, Often times, and 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 Fig4..

        4. Space Networking

          Providing connection oriented path for CCSDS Packet used by the Packet Telemetry and Telecommand.

          .

        5. 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.4.

        1. 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 Tranquillity, which is an extension of TCP. For non-connection oriented services, the UDP may be used. The TCP is used in Earth while TCP Tranquillity is used in Mars orbit and surface.

        2. 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 Delivery Protocol (CFDP)

    [29] for long delay link.

  2. The transport layer issues

    In terms of technologies, the current Internet capabilities work well on Earth where the propagation delay of light-speed signals is short. The packets exchanged according to the TCP protocol reach their destination in fractions of a second, for the most part. However, the Interplanetary Internet System has to face a lot of problems, the major ones related to the transport layers. The major problems to be considered in the transport layer are,

    • Propagation delays

      The most obvious difference between communicating between points on Earth and communicating between planets is the delay. The deep void space with no medium practically makes it impossible for any proper communication to be continuously maintained for a long duration. This is because of the large distance between the two points of communication.

    • The error rates

      The difficulties of generating power on and around other planets will also result in relatively high bit error rates. Current deep-space missions operate with very high bit error rates (on the order of one error in ten bits) that are then improved using heavy coding. The tradeoffs between coding, bit error rate and

      reliability requirements will need to be re- examined in the context of the IPN.

    • Black outs

      Interplanetary communications will, at least in the near future, be characterized by intermittent connectivity between nodes. As satellites or moons pass behind planets, and as planets pass behind the sun as seen from Earth, we lose the ability to communicate with them. This effect adds to the delays experienced by and could push queuing delays to several weeks or a month if the source and destination are in opposition (on opposite sides of the sun).

    • Lack of fixed infrastructure

    There is no fixed infrastructure built-in to take care of the networking in the outer space. So we do not have anything as such to call reliable network in terms of connectivity. We cannot assure 100% reliability here in Earth even, where we have so much better chances of connectivity, the interplanetary internet system is in much worse condition.

    state in terms of their size and functionality. Unlike NIL, NIX segments are much smaller compared with data segments, i.e., 40 bytes. They do not carry any information and, thus, cannot be used for error recovery purposes.

    7.2.2 New Rate-Based AIMD Scheme

    As mentioned before, current TCP protocols achieve very poor performance on the links with extremely high propagation delay mostly due to their window-based operation. The throughput of the window-based TCP protocols and rate-based schemes are inversely proportional to the RTT and the square- root of RTT, respectively. Thus, the rate- based congestion control schemes are more robust to excessive propagation

    delays than the window-based mechanisms. Hence, in order to address the adverse effects of extremely high

  3. Conclusion

    The inadequacy of the current TCP protocols in the IPN backbone network has already been known and the need for new transport protocol has been known. In order to address this need, a new reliable transport protocol (TP- Planet) has been developed. The objective of TP-Planet is to address the challenges posed by the IPN backbone network for reliable data delivery and achieve high throughput performance. TP-Planet deploys a rate-based AIMD congestion control scheme. It runs on top of the IP layer and does not require any specific modification to the lower layers in the current TCP/IP suite. Performance evaluation via simulation experiments revealed that TP-Planet significantly improves the throughput performance and addresses the challenges posed by deep- space communication networks.

    TP-Planet replaces the inefficient slow start algorithms with a novel initial state algorithm, which takes the link resources in a too fast and controlled manner. Simulation experiments showed that TP-Planet can reach high initial data rates very quickly. In order to address the challenges due to extremely high propagation delay, TP-Planet deploys a rate-based AIMD congestion control, whose AIMD parameters are tuned to help avoid throughput degradation. A new congestion control mechanism, which decouples congestion decision from single packet loss events, is developed to minimize the erroneous congestion decisions due to high link errors.

    Consequently, TP-Planet improves throughput with a factor more than 10 compared with the current TCP protocols. In order to reduce the effects of blackout conditions on the throughput performance, TP-Planet incorporates blackout state behaviour into the protocol operation. By this way, it achieves up to 14% performance improvement in blackout conditions. The bandwidth asymmetry problem is addressed by the adoption of delayed SACK options. As a result, TP- Planet is a reliable transport protocol equipped with diverse set of algorithms and features, which can address the requirements of the IPN backbone network. Note that TP-Planet is mainly implemented at the IPN backbone network nodes, i.e., the TP-Planet source and sink are the ground station gateway at the Earth and the planetary gateway connected to the relay satellites orbiting around the outer-space planets. The end-to-end transport control can be achieved by using the existing transport protocols developed for terrestrial wireless networks on the PlaNetary surface networks in conjunction with TP-Planet on the IPN backbone network. However, the detailed description of such cooperation and its performance evaluation are beyond the scope of this paper and left for future study.

  4. Future Scope

    • Help in covering up the vast inter- planetary distances.

    • Also can be applied to the existing ground technology.

  5. References

  1. Koutsogiannis, E.; Papastergiou, G.; Tsaoussidis, V.; , "Evaluation of CCSDS

    file delivery protocol over Delay Tolerant Networks," Satellite and Space Communications, 2009. IWSSC2009. vol., no., pp.381-384, 9-11Sept.2009 doi: 10.1109/IWSSC.2009.5286338

  2. Akan, O.B.; Jian Fang; Akyildiz, I.F.; , "TP-planet: a reliable transport protocol for interplanetary Internet," Selected Areas in Communications, vol.22, no.2, pp. 348- 361, Feb. 2004 doi: 10.1109/JSAC.2003.819985

  3. "InterPlaNetary Internet: state-of-the- art and research challenges", "Computer Networks",volume = "43", "Ian F. Akyildiz and Özgür B. Akan and Chao Chen and Jian Fang and Weilian Su" DOI: 10.1016/S1389-1286(03)00345-

    1

  4. Interplanetary Internet (IPN): Architectural Definition, V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R.

    Durst, K. Scott, E. Travis, H. Weiss

  5. Developments Towards an Interplanetary Internet Patrick Romano, Peter Schrotter, Otto Koudelka, and Manfred Wittig Institute of Communication Networks and Satellite Communications Graz University of Technology, Graz, AustriaESA-ESTEC,

    Noordwijk, The Netherlands

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

    Ian F. Akyildiz, OOzgur B. Akan *, Chao Chen, Jian Fang, Weilian Su.

  7. www.computerrscienceweb.com [8]http://sunset.usc.edu/gsaw/gsaw2003/s3

/burleigh.pdf

[9] http://www.ipnsig.org/

Leave a Reply