Welcome to the IRIS Project

NASA TSGC TDC-30-F16

DYNAMIC ADDRESSING IN SPACE NETWORKS

IRIS is a senior design team from the Computer Science and Engineering Dept at the University of North Texas (UNT) sponsored by NASA through the Texas Space Grant Consortium (TSGC) Design Challenge. We are working on Topic-TDC_30-F16 IPv6 Addressing in Space.

Problem:

What is the problem we are trying to solve?

We’re trying to find a way for spacecraft to quickly and automatically connect to a network as it moves between networks, just like how your phone automatically connects to wifi as you move between home, work, and school. Due to the differences between networking on earth compared to in space, there are many challenges that we have to work around.

Challenges:

Networking requires addresses

If you want to mail a letter to the president, you can’t just write “To: the White House” on the front and hope it gets there. You have to know the White House’s address. Your letter has the be addressed to “1600 Pennsylvania Ave NW, Washington, DC 20500”. If you want to text your friend, but their number isn’t in your phone, you can’t just send the text to their name, you have to have their phone number. Computers work the same way. Sure, you can type Google into a browser and it’ll work, but what you don’t see in the background is how your computer looks up Google’s address using the Domain Name System. Every computer needs an address to communicate on a network. When a new computer connects to a network, it needs to get an address. The technical name for the process of getting and address is called Dynamic Host Configuration Protocol (DHCP). This process involves a server and a client. The DHCP server is in charge of managing addresses on the network. It gives out addresses to new computers on the network and keeps a list of what addresses have already been given out in order to prevent duplicates. A client is any computer that accesses services from a server. In this case, the client is a computer on the network asking the DHCP server for an address. This process involves several messages going back and forth between the server and the client until they can agree on which address the client will use.

Addressing on Earth is easy

Computers are fast. Really really fast. The amount of time it takes to snap your figures is enough time for two computers to have a lengthy and detailed conversation, if they are close to each other. The fastest possible speed to send a message is the speed of light. That’s really fast. So fast, that if you could bend a beam of light, it could travel around the earth seven and a half times in one second. It would take a Boeing 747 almost two days just to go around the earth once and that’s not even counting time to land and refuel the plane. A computer cannot respond to a message until it has received it. When the computers are clost to each other, the amount of time to send a message is too small for us humans to even notice. Computers located close to each other can have respond to each other several times before we even notice. Often if the computers are just in the same country, they can still communicate faster than we can react.

Addressing in space is hard

Space is big. Really really big. So big, that same beam of light that went around the earth seven and a half times in one second would take more than two and a half seconds to get to the moon and back. Space is so big, that as fast as light is, it still takes eight minutes and seventeen seconds for the light from the sun to get to earth. It takes over seventeen hours for a message from Voyager 1 to reach us. And that’s just one way. It would take over one and a half days to get an answer from Voyager 1, and that’s only if ask the question correctly and it makes it the first time. In Networking, this amount of time spent weighting is called propagation delay, and it is one of the most challenging aspects of communicating in space. Now imagine trying to have a conversation with a friend like this. Imagine if instead of seventeen hours, you only had to wait one extra second. Imagine if all of your texts, emails, and chats were delayed by one second. Communicating like this can be very hard. It’s especially hard for computers that are used to communicating so much faster than we are.

NASA currently statically assigns addresses

The long propagation delays of space combined with numerous the back and forth required for DHCP means that it takes a long time for a spacecraft to get an address. When you combine the fact that spacecraft are moving, this means that a spacecraft orbiting Earth could pass into and out of different networks many times in one day. If that spacecraft has people on board, this means they couldn’t send or receive a messages until the DHCP server for the new network had given them a new address. This happens all the time on earth, but we rarely notice it. If you talk on a cell phone while driving, your phone will enter and leave several networks along the trip. You would never notice the drop because we are so close to the cell towers. But in space, the distances and propagation delays are so large, that you could go several minutes without being able to communicate. There are some backups like radios, but seamless communication is very important when placing human lives in the dangers of space. To prevent these kind of blackouts of communications, NASA has chosen to statically assign addresses. This means that a person decides which space craft gets which address, and that spacecraft holds onto it until it is told to release it. This can work when there are only a few computers on the network, but NASA is responsible to around 1,100 different spacecraft. Imagine trying to keep track of all of those organized. Static addressing can lead to mistakes such as duplication and omission.

Proposal:

Here’s how we think this can be solved

Complexity

First, we need to create an environment to simulate the complexity of space networks. We can’t go put satellites in orbit to run these simulations, because that is far too expensive and we wouldn’t be able to make any changes. Instead, we will create a network of small, inexpensive computers here on earth. Each computer will represent a component in a space network such as the mission control center (MCC), a tracking and data relay satellite (TDRS), or the International Space Station (ISS). Our network will consist of ten computers, allowing us to show the basic complexity of space networks without simulating each of the 1,100 spacecraft NASA is responsible for. For our test simulation, we will incorporate the MCC, 3 TDRS satellites, the ISS, the Hubble Space Telescope, an Orion module, and 3 EVA space suits. This will allow us to simulate a sufficient amount of the complexity of space networks here on the groun The Orion module allows us to demonstrate several specific aspects of networking in space. We will be able to demonstrate how some spacecraft need to be able to communicate with MCC while they are still on the ground. We will show how the path of the data transitions from hard lines on the ground to satellite relays as it launches. From there we will also be able to show how data is routed through the ISS once Orion docks with it.

Line of Sight and Propagation Delay

In order for our simulation to be realistic, we want our devices to connect and disconnect to each other in a similar manner to how actual spacecraft join and leave networks in space. Each of the devices in our simulation will run a piece of software that we will create. This software will act in a similar manner to a firewall. Like a firewall, it will drop and allow packets based on a set of criteria. In this case, instead of allowing or blocking data based on rules determined by the safety of the site, out software will determine its rules based on line of sight. Our software will determine if the two spacecraft can see each other, or if a large celestial body, such as the earth or Sun, is blocking the path. If two space craft are on opposite sides of a planet, they cannot see or communicate with each other directly, so any data sent will be dropped by our software. In addition to line of sight issues, signals take to travel the distances of space and arrive at their destination. Since we are trying to simulate communications in space, these delays need to be accounted for. Our software will calculate the distance between the two space craft and divide that distance by the speed of light in order to determine the propagation delay. The software will then hold the data for that amount of time in order to simulate realistic propagation delays in space.

IPv6

NASA wants to use Internet Protocol version 6 in the future. Right now, most of the world uses IPv4 for networking. The problem is that we are running out of IPv4 addresses. IPv6 has more addresses than there are atoms in the planet Earth, so we should have enough for a long time into the future. IPv6 is designed to allow IPv4 traffic to pass through it, so it is entirely backwards compatible. Since IPv6 works with all current networks and has provisions built into it for future use, NASA has asked us to incorporate IPv6 into this project.

DHCP

Traditional

Currently, DHCP uses a four-way handshake to assign addresses. The new device, called a client, on the network sends out a discovery packet. This announces its presence on the network and lets the DHCP server know there is a new device in need of an address. The DHCP server responds with an offer of sever addresses for the new client to choose from. The client responds with a request containing its selection from the addresses offered by the DHCP. The DHCP serve responds with the client’s address assignment, and now data can flow freely between the new device and the rest of the network. Implementing this kind of protocol in space comes with many challenges. Currently all communication to space is relayed through a Tracking and Data Relay Satellite (TDRS) satellite. Currently, the TRDS satellites are just repeaters. TDRSs do not process the signal at all. They just parrot back whatever they receive. Because of this, if we were to implement a traditional DHCP protocol in space today, we would have to put the DHCP server on the earth, probably at the Ground Stations that transmit to the TDRSs. Since these satellites are in geosynchronous orbit, they are very far away. That means a signal to a spacecraft has to travel from earth, relayed through a TDRS, and then back to the spacecraft. This makes the distance the signal travels twice that of the altitude of a geosynchronous, which is 42,164 km. That means the signal must travel at least 84,328 km which from radio waves takes at least 281 milliseconds just for a one-way trip. Since the DHCP protocol is a four-way handshake, that means it can take at least 1.125 seconds to get an address. The amount of time is even longer in reality since the earth is curved and that altitude is the distance between the satellite and the closest part of earth. This all assumes that everything works correctly on the first try.

Pipelined

Since we’ve already built an orbital mechanics engine for the complexity and delay parts of the project, we are able to predict when a spacecraft will come into line of sight for a TDRS. This is the point when it will traditionally send a Discovery packet. Since we can predict this point in time, we don’t need to wait for the discovery packet to propagate across the distance of space, we can go ahead and send the offer. If we only offer the spacecraft one address to choose from, we know what it will request and we can send the Acknowledgement right away as well. This pipelined version of DHCP allows the TDRS to start sending data immediately and the client spacecraft can start sending data in one fourth the amount of time.

Results

Future work

Coming soon

FAQ

Why Two Line Element (TLE) data?

TLE data is very easy to find. Dr. Thomas Sean Kelso from Analytical Graphics, Inc.’s (AGI’s) Center for Space Standards and Innovation (CSSI) has made an enormous amount of TLE data available on CelesTrak.com/. TLE sets are also very easy for computers to parse and translate into Orbital Elements. TLE does suffer from some inaccuracies. The calculations can be off by a few kilometers, and those errors tend to compound over time. This is why TLE data must be refreshed frequently. Fortunately, for our purposes, 1km only equates to 3.3356 micro seconds (μs). Given the vastness of space, that is such a tiny fraction of the amount of propagation delay. 3.33 μs is only 0.00013% of the time it takes to get a signal to the moon and back. Oddly enough, due to other network and routing delays, that percentage is even smaller for the ISS. 3.33 μs comes to be only 0.000000834% of the delay when communicating with ISS. When it comes down to it, for the purposes of this project, errors this small are acceptable given the abundance of TLE data and the ease of which a computer can use it.

IRIS Team

Jacen R Kohler

• Team Leader
• Jacen likes to grill and smoke all kinds of meats specifically, ribs, brisket, turkey and chicken. He enjoys going on walks around town and is an aspiring bee keeper and rancher. He has dabbled in wood working, but really wants to try blacksmithing and metal fabrication. He is fond of challenging puzzles. Jacen plans to go into Information and Cyber Security.

Alex Fatum

• Team Deputy Leader
• Alex is a senior at the University of North Texas. He has lived in four different states and was born in Michigan, then moved to Indiana, and then Massachusetts, and now Texas. He discovered in high school that he had the ability to fix anything, even with no prior knowledge of how it worked. Alex knew he wanted to use this skill for a job and looked into engineering. He really enjoys working with computers and decided to go into computer hardware engineering.

Tyler Alvarez

• IPv6 Implementation Lead
• Tyler Alvarez is currently studying Computer Science and Engineering with a specialization area in Communications & Networks and a minor in Mathematics. Previously, he has worked as an IT security intern for Baker Hughes. After graduation, he will be looking to work in the industry utilizing his specialization. During his free time he enjoys reading and taking his dog hiking.

Yale Empie

• Technical Writer

Contributors

Dr. Robin Pottathuparambil

• Faculty Advisor
• Professor at University of North Texas Department of Computer Science and Engineering

Chatwin Lansdowne

• NASA Mentor
• Engineer at NASA Johnson Space Center

Special Thanks

Dr. Tim Urban

• Head of TSGC

Talia Jurgens

• TSGC Program Coordinator

Daniel Benbenek

• Engineer at NASA Johnson Space Center
• provided additional perspective, knowledge, and understanding to our project

Dr. Michael A. Earl

• Influential in helping us understand the math behind orbital mechanics that allowed us to calculate the distances between spacecraft

Luis Gonzalez

• Senior at UNT majoring in Mechanical Engineering graduating in May of 2017.
• Helped debug the orbital mechanics equations.
• Member of UNT’s University Student Launch Initiative team to NASA

Support or Contact

Questions? Email us

Usage

We would love to see other projects incorporate our work! If you’re working on a project that uses our code or references our work, we’d love to hear about it. We’ve put a lot of effort into building this system and we love to see others expand on it. Tell us about your project, how you heard about us, and how you got involved. Something I’d love to see is a Mars Rover simulator were a wifi toy car is controled with the delay functions we’ve created. Let us know so we can share a link to your project!