a flexible interplanetary internet n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
A flexible interplanetary Internet PowerPoint Presentation
Download Presentation
A flexible interplanetary Internet

Loading in 2 Seconds...

play fullscreen
1 / 17

A flexible interplanetary Internet - PowerPoint PPT Presentation


  • 78 Views
  • Uploaded on

A flexible interplanetary Internet. Stephen Farrell Trinity College Dublin, Ireland Stephen.Farrell@cs.tcd.ie Christian Jensen Technical University of Denmark. Background. Work on Interplanetary Internet (IPN) “Bundles” passed between nodes during strictly scheduled “contacts”

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A flexible interplanetary Internet' - avel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a flexible interplanetary internet
A flexible interplanetary Internet

Stephen Farrell

Trinity College Dublin, Ireland

Stephen.Farrell@cs.tcd.ie

Christian Jensen

Technical University of Denmark

background
Background
  • Work on Interplanetary Internet (IPN)
    • “Bundles” passed between nodes during strictly scheduled “contacts”
      • ISOC SIG: http://www.ipnsig.org
  • Generalised as a study of Delay tolerant networking (DTN)
    • E.g. Sensor networks, some application based on 1980's email
      • IRTF RG: http://www.dtnrg.org
  • DTN vs IPN
    • Generally not (very) strictly scheduled
    • Less predictable data flows
    • Broader applicability
reasons to look at this
Reasons to look at this
  • More direct PI control of experiments
    • Network (more) ignorant of application
  • More flexible experiment communications
    • Constellations, Sensor networks, weather etc.
  • Data from new SC using old SC as routers
    • Ubiquitous network stack including forwarding
  • Ability to handle more S/C
    • Alleviate DSN bottleneck, improve re-scheduling
    • Longer mission duration (SEP)
a comp sci reason to look at this
A (Comp. Sci.) reason to look at this
  • Internet architecture calls for all (well, most) intelligence to be at the network edges
    • Drop packets if you must
    • Eases new service introduction (ISPs don't care)
  • Web architecture calls for accepting (as normal) unresolved links
    • Databases no longer require link integrity and are much easier to start
  • Can an IPN take a similar approach?
    • Would it be better if it did?
      • Maybe, but depends on the “scale” of the network
when scaling might hit
When scaling might hit...
  • DSN oversubscription
    • Probably always inevitable
  • Inherently “bursty” experiments
    • Perhaps space weather, GRBs (and other things I don't understand:-)
  • New SC comms architectures
    • Orbiter, primary lander, secondary sensor nodes each with different comms. capabilities
    • Humans beyond LEO
flexible ipn concept
“Flexible” IPN concept
  • Its a DTN which
    • Meets IPN requirements to handle latency, uni-directional comms etc.
    • Includes schedule generation and distribution (in a delay-tolerant fashion!)
    • Allows simultaneous use of various routing topologies and forwarding schemes
  • Aiming to
    • Allow PIs to control their experiments from their desktops to a much greater degree than today
    • Increase the efficiency of the overall use of resources, when hit by scale factors
flexible ipn example
Flexible IPN example
  • PI has sensors deployed from a lander
    • Sensors have settings which determine when they produce data
  • PI decides to change settings
    • Commands (eventually) get to sensors via orbiter(s) and lander
      • Orbiters may use a token ring equivalent
      • Lander/sensors may use (a successor to) AODV
    • PI need not/cannot determine exactly when commands executed
  • (Some time later) Data from sensors increases
  • Routers (eventually) notice this and reschedule
    • Routers in sensors, lander, orbiter(s), earthstation
    • Schedule subject to many constraints (e.g. overall lander data budget), maybe centrally generated
so far
So far...
  • Simulations
    • Based on OMNET++ discrete event simulator and JPL DE406 ephemeris (and maybe cspice if necessary)
    • Routing topologies and forwarding schemes
      • Concept of the schedule as a data structure that is also distributed
        • Similar to how train timetables worked before telegraph
        • Some work on schedule visualisation
    • Traffic patterns
      • Request/response pattern
      • Triggered sensor pattern
planned
Planned...
  • Incorporate the scheduling and routing schemes into hardware
    • Lake water quality monitoring sensor network application
    • H/W prototype planned for Spring '04
  • Continue work on the “flexible” IPN concept and related simulations
    • Improve models (visibility, power, re-scheduling)
    • Would like to get good data against which to compare the simulations!
tentative conclusions
Tentative conclusions
  • Arguments for flexible IPN seem to be relatively convincing
    • Scaling and unpredictable traffic patterns => congestion handling and all that goes with that
  • Initial simulation results may support these arguments
    • Very early days here
    • Maybe layering violations are good!
      • When calculating schedules anyway, adding in the LTT's involved might help an edge node to re-calculate its scheduling without knowing much about the ephemeris
slide11

Questions?Now, later, or tostephen.farrell@cs.tcd.ieMore materials near:http://down.dsg.cs.tcd.ie/(will include a link to latest stuff when the paper's due)

slide17

./flexi20031024-1/endrun.txt

theIPN.sinks[0] bps is: 0.57013 (total bits: 1.46619e+06, total time: 2.592e+06)

theIPN.sinks[0] reporting: DIM'd 38715 messages!

theIPN.sinks[1] bps is: 814.86 (total bits: 2.10884e+09, total time: 2.592e+06)

theIPN.sinks[2] bps is: 121.361 (total bits: 3.14555e+08, total time: 2.592e+06)

./hand20031024-1/endrun.txt

theIPN.sinks[0] bps is: 17.8894 (total bits: 4.63059e+07, total time: 2.592e+06)

theIPN.sinks[0] reporting: DIM'd 8087 messages!

theIPN.sinks[1] bps is: 164.394 (total bits: 4.25888e+08, total time: 2.592e+06)

theIPN.sinks[2] bps is: 150.411 (total bits: 3.89862e+08, total time: 2.592e+06)

./hand20031024-2/endrun.txt

theIPN.sinks[0] bps is: 151.734 (total bits: 3.92843e+08, total time: 2.592e+06)

theIPN.sinks[0] reporting: DIM'd 16661 messages!

theIPN.sinks[1] bps is: 1503.07 (total bits: 3.89393e+09, total time: 2.592e+06)

theIPN.sinks[2] bps is: 139.669 (total bits: 3.62021e+08, total time: 2.592e+06)

./flexi20031024-2/endrun.txt

theIPN.sinks[0] bps is: 117.274 (total bits: 3.03969e+08, total time: 2.592e+06)

theIPN.sinks[0] reporting: DIM'd 42463 messages!

theIPN.sinks[1] bps is: 1823.34 (total bits: 4.726e+09, total time: 2.592e+06)

theIPN.sinks[2] bps is: 116.137 (total bits: 3.0102e+08, total time: 2.592e+06)

./filled20031030-1/endrun.txt

theIPN.sinks[0] bps is: 191.537 (total bits: 4.96459e+08, total time: 2.592e+06)

theIPN.sinks[0] reporting: DIM'd 15037 messages!

theIPN.sinks[1] bps is: 1831.17 (total bits: 4.74637e+09, total time: 2.592e+06)

theIPN.sinks[2] bps is: 288.596 (total bits: 7.48032e+08, total time: 2.592e+06)