InterPla Internet

1
(No Transcript)
2
InterPlanetary InternetDeep Space Network

3
InterPlaNetary Internet Architecture

• InterPlaNetary Backbone Network
• InterPlaNetary External Network
• PlaNetary Network

4
PlaNetary Network Architecture

• PlaNetary Satellite Network
• PlaNetary Surface Network

5
CHALLENGES

• Extremely long and variable propagation delays
• Asymmetrical forward and reverse link capacities
• Extremely high link error rates
• Intermittent link connectivity, e.g., Blackouts
• Lack of fixed communication infrastructure
• Effects of planetary distances on the signal
  strength and the protocol design
• 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

6
Planned InterPlaNetary Internet Missions
7
Proposed Consultative Committee for Space Data
Systems (CCSDS) Protocol Stack
Used for Mars Exploration Mission Communications
8
Proposed Delay Tolerant Networking (DTN) Protocol
Stack (Bundling Architecture)
9
Applications

• Time-Insensitive Scientific Data Delivery
• Large volume of scientific data to be collected
  from planets and moons.
• Time-Sensitive Scientific Data Delivery
• Audio and visual information about the local
  environment to Earth, in-situ controlling robots,
  or eventually in-situ astronauts.
• Mission Status Telemetry
• Delivery of the status and the health report of
  the mission, spacecraft, or the landed vehicles
  to the mission center or other nodes.
• Command and Control
• Closed-loop command and control of the in-situ
  space mission elements.

10
Transport Layer Issues

• Extremely High Propagation Delays
• High Link Error Rates
• Asymmetrical Bandwidth
• Blackouts

11
Extremely Long Propagation Delays
12
Performance of Existing TCP Protocols

• Window-Based TCPs are not suitable!!!
• For RTT 40 min ? 20B/s throughput on 1Mb/s
  link !!

O. B. Akan, J. Fang, I. F. Akyildiz, Performance
of TCP Protocols in Deep Space Communication
Networks, IEEE Communications Letters, Vol. 6,
No. 11, pp. 478-480, November 2002.
13
Space Communications Protocol Standards
Transport Protocol (SCPS-TP)

• Addresses link errors, asymmetry, and outages
• SCPS-TP Combination of existing TCP protocols
• Window-based
• Slow Start
• Retransmission timeout
• TCP-Vegas congestion control scheme variation
  of the RTT value as an indication of congestion
• SCPS-TP Rate-Based
• Does not perform congestion control
• Uses fixed transmission rate

New Transport Protocols are needed !!!
Space Communications Protocol
Specification-Transport Protocol (SCPS-TP)",
Recommendation for Space Data Systems Standards,
CCSDS 714.0-B-1, May 1999.
14
TP-PlanetO. B. Akan, J. Fang and I.F.
Akyildiz, TP-Planet A Reliable Transport
Protocol for InterPlaNetary Internet, to appear
in IEEE Journal of Selected Areas in
Communications (JSAC), early 2004.
Steady State
t2RTT
Initial State
tRTT
Immediate Start
FollowUP
Follow Up

• Objective To address challenges of
  InterPlaNetary Internet
• A New Initial State Algorithm
• A New Congestion Detection Algorithm in Steady
  State
• A New Rate-Based scheme instead of Window-Based

15
Performance Evaluation (Initial State)

• Initial State (TP-Planet) vs. Jump Start
  (TCP-Peach) and Slow Start (TCP) RTT600 sec
  p10-5 Target Rate 100packets/sec.

16
Performance Evaluation (Throughput)

• Throughput vs. File size RTT600 s, p10-5
  ,10-4,10-3, Link 1Mb/s Target rate 100
  packets/sec (? 100 KB/sec for data packets of
  size 1KB). NOTE 200 MB ? Vegas
  (SCPS-TP) ? 30 B/sec
• 
  ? Planet ? 83 KB/sec !!!!!!

17
Multimedia Transport in InterPlaNetary Internet

• Additional Challenges
• Bounded Jitter
• Minimum Bandwidth
• Smoothness
• Error Control

18
Performance of Existing Multimedia Rate Control
Protocols

• Existing multimedia rate control protocols are
  not suitable for IPN Backbone link with high
  delay and link errors!!!
• For RTT 40 min ? RCS 41 KB/s, RAP 237
  B/s, and TFRC, SCTP 100 B/s throughput on a
  10 Mb/s link !!

J. Fang and O. B. Akan, Performance of
Multimedia Rate Control Protocols in
InterPlaNetary Internet, submitted to IEEE
Communications Letters, November 2003.
19
RCP-Planet OverviewJ. Fang and I.F. Akyildiz,
RCP Planet A Rate Control Scheme for
Multimedia Traffic in InterPlaNetary Internet,
July 2003.

• Objective To Address the Challenges
• Framework
• A New Packet Level FEC
• A New Rate-Based Approach
• A New BEGIN State Algorithm
• A New Rate Control Algorithm in
  OPERATIONAL State

20
Performance Evaluation (Throughput)
Throughput vs. Packet Loss Rate due to
Link Errors (10 RCP connections, RTT300,
600, 1200 sec, p10-5 - 10-1, Minimum Media Rate
20KB/s, Maximum Media Rate 140KB/s, Link Speed
1300 KB/s, Duration 10 RTTs)
21
Transport LayerOpen Research Issues

• End-to-End Transport
• Feasibility of the end-to-end transport should be
  investigated and new end-to-end transport
  protocols should be devised accordingly.
• Extreme PlaNetary Distances
• Deep Space links with extreme delays such as
  Jupiter, Pluto have intermittent connectivity
  even within an RTT.
• Cross-layer Optimization
• The interactions between the transport layer and
  lower/higher layers should be maximized to
  increase network efficiency for scarce space link
  resources.

22
Network Layer Issues

• Naming and Addressing
• in the InterPlaNetary Internet
• Routing
• in the InterPlaNetary Backbone Network
• Routing
• in PlaNetary Networks

23
Naming and Addressing

• Purpose To provide inter-operability between
  different elements in the architecture
• Influencing Factors
• What objects are named?
• (Typically nodes or data objects)
• Whether a name can be directly used by a data
  router in order to determine the delivery path?
• The method by which name/object binding is
  managed?

24
Domain Name System (DNS) Approach in Internet

• If an application on a remote planet needs to
  resolve an Earth based name to an address
• Problems
• If query an Earth-resident name server
• A significant delay of a round-trip time in
  the commencement of communication
• If maintain a secondary name server locally
  State updates would dominate communication
  channel utilization
• If maintain a static list of host names and
  addresses
• Not scale well with systems growth

25
Tiered Naming and Addressing

• Name Tuple region ID, entity ID
• Region ID identifies the entitys region and is
  known by all regions in the InterPlaNetary
  Internet
• Entity ID is a name local to its entitys local
  region and treated as opaque data outside this
  region
• ? The opacity of entity names outside their local
  region
• enforces Late Binding the entity ID of a
  tuple is not interpreted outside its
  local region
• which avoids a universal name-to-address
  binding space and preserves a significant amount
  of autonomy within each region.

26
An InterPlaNetary Internet Example and Host
Name Tuples
27
ChallengesNetwork Layer

• Long and Variable Delays
• Without timely distribution of topology
  information, routing computations fail to
  converge to a common solution, resulting in route
  inconsistency or oscillation
• The node movement adds to the variability of
  delays
• Intermittent Connectivity
• Determine the predicted time and duration of
  intermittent links and the degree of uncertainity
• Obtain knowledge of the state of pending messages
• Schedule transmission of the pending messages
  when links become available
• SCPS-NP ? possible solution???

28
Open Research IssuesNetwork Layer

• Distribution of Topology Information
• Combination of link state and distance vector
  information exchange
• Distribution of trajectory and velocity
  information
• Path Calculation
• Hop-by-hop routing is expected using incomplete
  topology information and probabilistic estimation
• Adaptive algorithms are needed for rerouting and
  caching decisions
• Interaction with Transport Layer Protocols

29
Error ControlInterPlaNetary Backbone Network

• CCSDS Telemetry Standard (Telemetry Channel
  Coding)
• For Gaussian Channels ?
• ½ Rate Convolutional Code
• For Bandwidth-Constrained Channels ?
• Punctured Convolutional Codes
• For Further Constrained Channels ?
• Concatenated Codes (i.e.,Convolutional code as
  the inner code and the RS code as the outer code)
• Own Experience ? TORNADO CODES!!!

30
ChallengesNetwork Layer (Planet)

• Extreme Power Constraints
• Space elements mainly depend on rechargeable
  battery using solar energy
• Frequent Network Partitioning
• The network can be partitioned due to harsh
  environmental factors
• Adaptive Routing through Heterogeneous Networks
• Fixed elements (e.g., landers)
• Satellites with scheduled movement
• Mobile elements with slow movement (e.g., rovers)
• Mobile elements with fast movement (e.g.,
  spacecraft)
• Low-power sensor nodes in clusters

31
Medium Access Control InterPlaNetary Backbone
Network

• Challenges
• Very Long Propagation Delays
• Physical Design Change Constraints
• Topological Changes
• Power Constraints

32
Medium Access Control InterPlaNetary Backbone
Network

• Vastly unexplored research field
• The suitability and performance evaluation of
  fundamental MAC schemes, i.e., TDMA, CDMA, and
  FDMA, should be investigated
• Thus far, Packet Telecommand, and Packet
  Telemetry standards developed by CCSDS are used
  to address deep space link layer issues
• (Virtual Channelization Method!!!)

33
Error ControlInterPlaNetary Backbone Network

• Deep space channel is generally modelled as
  Additive White Gaussian Noise (AWGN) channel
• Scientific space missions require bit-error rate
  of 10-5 or better after physical link layer
  coding
• ? Error control at link layer is necessary

34
Error ControlInterPlaNetary Backbone Network

• Advance Orbiting Systems Rec. by CCSDS ?
• Space Link (ARQ) Protocol (SLAP)
• Packet Telecommand Standard of CCSDS ?
• Command Operation Procedure (COP) (GoBack
  N)

35
Open Research IssuesLink Layer

• MAC for InterPlaNetary Backbone Network
• MAC for PlaNetary Networks
• Error Coding Schemes
• Cross-layer Optimization
• Optimum Packet Sizes

36
ITLP Integrated Transport/Link Layer Protocol
for IPN Backbone NetworkO. B. Akan and I.F.
Akyildiz, Hop-by-Hop or End-to-End in InterPla
Internet?, Nov. 2003.

• ITLP is unified integrated transport/link layer
  protocol to achieve efficient local congestion
  control and reliable data transport following
  hop-by-hop approach in the InterPlaNetary
  Backbone Network.

37
ITLP Integrated Transport/Link Layer Protocol
for IPN Backbone Network
SOURCE
RECEIVER
Integrated Transport / Link Layer (ITLP)
Integrated Transport / Link Layer (ITLP)
Channel Coding (RS, Turbo, etc.)
Channel Coding (RS, Turbo, etc.)
Modulator
Modulator
Transmitter
Transmitter
Upconvert
Upconvert
DEEP SPACE CHANNEL
ITLP Protocol Structure
38
ITLP Integrated Transport/Link Layer Protocol
for IPN Backbone Network

• Local Flow/Congestion Control Algorithm
• Exploits local link resource availability of the
  receiving IPN Relay Satellite (IRS).
• Independent of the link delay, hence achieves
  accurate congestion control.
• Local Adaptive Reliability Mechanism
• Adaptive Hybrid ARQ which adaptively switches
  between the FEC and ARQ modes according to the
  local wireless channel conditions.
• Achieves 100 reliable data transport.
• Optimum Packet Size
• The protocol uses the optimum packet size
  analytically obtained by considering the
  transmission efficiency, link delay, packet and
  bit error rates.

39
Hop-by-Hop Communication in IPN
Let ENe2e and ENhbh be the total number of
packets transmitted to reliably transport D data
packets between Planet and Earth in End-to-End
and Hop-by-Hop approaches, respectively.
Then, we analytically show that ENe2e gt
ENhbh, i.e., hop-by-hop approach is more
efficient in InterPlaNetary Backbone Network.
40
Physical Layer Issues InterPlaNetary Backbone
Network

• Possible approach is to increase radiated RF
  signal energy
• Use of high power amplifiers such as travelling
  wave tubes (TWT) or klystrons which can produce
  output powers up to several thousand watts
• This comes with an expense of increased antenna
  size, cost and also power problems at remote
  nodes
• Current NASA DSN has several 70m antennas for
  deep space missions
• DSN operates in S-Band and X-Band (2GHz and 8GHz,
  respectively) for spacecraft telemetry, tracking
  and command
• Not adequate to reach high data rates aimed for
  InterPlaNetary Internet
• New 34m antennas are being developed to operate
  in Ka-Band (32 GHz) which will significantly
  improve data rates

41
Open Research IssuesPHYSICAL LAYER

• Signal Power Loss
• Powerful and size-, mass-, and cost-efficient
  antennas and power amplifiers need to be
  developed
• 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
  investigated for possible deployment in
  InterPlaNetary Backbone links
• Hardware Design
• Low-power low-cost transceiver and antennas
  should be developed
• Modulation Schemes
• Simple and low-power modulation schemes should be
  developed for PlaNetary Surface Network nodes.
  Ultra-wide Band (UWB) could be explored for this
  purpose

42
Challenges in Deep Space Time Synchronization

• Variable and long transmission delays
• The long and variable delays may cause a
  fluctuating offset to the clock
• Variable transmission speed
• It may produce a fluctuating offset problem
• Variable temperature
• It may cause the clock to drift in 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

43
Challenges in Deep Space Time Synchronization
(contd)

• Intermittent connectivity
• The situation may cause the clock offset to
  fluctuate and jump
• Impractical transmissions
• 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
• Deep space equipments may require to synchronize
  to their local time servers, and the time servers
  have to synchronize among themselves

44
Related Work

• Network Time Protocol
• Can not handle mobile servers and clients
  (variable range and range rate with intermittent
  connectivity)
• Has time offset wiggles of few milliseconds of
  amplitude
• DSN Frequency and Time Subsystems
• Uses several atomic frequency standards to
  synchronize the devices and provide references
  for the three DSN sites, i.e., Goldstone, USA
  Madrid, Spain Canberra, Australia
• Recommendation for proximity-1 space link
  protocol
• Finds the correlation between the clocks of
  proximity nodes. The correlation data and UTC
  time are used to correct the past and project the
  future UTC values

45
Conclusions

• InterPlaNetary Internet will be the Internet of
  next generation deep space networks.
• There exist many significant challenges for the
  realization of InterPlaNetary Internet.
• Many researchers are currently engaged in
  developing the required technologies for this
  objective.

46
FiNAL WORDS

• NASAs VISION
• to improve life here, to extend life to there,
  to find
• life beyond...
• NASAs 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!!!!!!!!!