We'll be talking about all these different IoT protocols and how they work. We've been talking about how they can work in the context of wireless networks where things are unreliable and things change, and that's great. Now the thing is, things in IoT can be a little bit more dangerous and tricky that I've been describing it so far. There's a key assumption that I have been making so far, which is, you have a network, and the network is connected, somehow. We're assuming the network is not partitioned when I've been talking about all these protocols. It seems like a fundamental assumption. If you have a node, and it's sending data to another node, or replicating data, or forming a trio or whatever, they better be connected somehow. Otherwise, how can you send data between them? However, in the real world, when you do real deployments, things aren't always so simple. Sometimes, you have environments where you have a network, and it's partitioned. Your graph might not always be connected. Some scenarios where this can happen are things called, for example, occasionally connected networks. In some environments, you have a setup where you have your deployment, and there's a bunch of nodes and sensors all over the place. They might not be able to reach each other all the time. For example, wildlife monitoring is an example of this where you have a bunch of animals, and you put colors on them. You are tracking them, moving them around, and stuff like that. You don't always have 4G cellular coverage or LTE data in these environments. If you're in the African savanna or the forests, and so you have a situation where you have these nodes, they're collecting data and storing data, but you want to retrieve it. What are you going to do, go out to each animal, find every single animal, and collect the data? That doesn't work. What you do in these environments is you're going to have these sensors collecting data, and they talk to each other opportunistically. Whenever two animals walk by each other, there will be a communication where one will replicate data on the other. And then, what the field engineer can do is, she can go out there and get close to one of the animals, then they collect data for all of them, so there's this event you're having the sensors talk to each other. Another example of this is space satellites. In outer space, we have the satellites that orbit the Earth and provide internet connectivity. These satellites, we talk to them and bounce signals off them, and things like that, but these satellites often need to talk to each other, too. They might not be right next to each other because they orbit the Earth. Sometimes they're near each other, and sometimes they're far away from each other. So when they come in contact, it's nice for them to communicate with each other, and then they go out of radio range. When challenges dealing with occasionally connected networks where your networks occasionally connected, and then get disconnected. Another situation where this comes up is a very unreliable environment. Imagine military networks or networks where you're suffering from security issues. You've adversary jamming them, and taking out links where your adversary might start winning and take out big, chunkier topologies. You have multiple disconnected regions. They might come in contact with each other sometimes, and you try to send data and orchestrate maneuvers, and things like that. How can you deal with that or extremely unreliable links? For example, if you're doing deployment in water, you can't really use Wi-Fi because we know Wi-Fi doesn't go through water that well. So you might use acoustic links, but acoustic links are very sensitive to waves and vibrations under waters. They go down a lot, free-space optical communications. In highly unreliable environment, you have this challenge of links just fail so often that your network may become disconnected. Another situation is low-power environments where everything is within radio range. You can talk to each other, but you may really need to save power. You're doing deployment in a cornfield. You're throwing out some sensors, they have to sit there for six months, and they really have to be off most of the time. If nodes seem to be off most of the time, you need to communicate with some node multiple hops away. It's hard to do mesh networking in that context because your neighbors are asleep. They can't wake up and assist you, and do multi-hop communications. So in all these environments, you get this situation of you have a deployment, and you need this ability to talk to other nodes that may not be directly connected to you, but connectivity is intermittent. What do you do if your graph is not always connected? IoT protocol engineers have recognized this challenge. They've come up with a suite of protocols known as delay-tolerant networking protocols. What these protocols do is they actually address this problem. They actually allow you to route to know that you're not connected to, even if you're in disconnected partitions. It is based on this idea of, maybe I can't communicate directly with the destination. There may be some disconnected region. But maybe if I forward data to another guy, then they forward it to another guy, maybe they'll form a connection eventually, and maybe that person will forward data to another node. If you disseminate your data out, maybe even multiple replicas of it, you have some hope of getting that data through, eventually. For a motivating example, suppose you have this topology. You have the source and the destination M. The source wants to send a packet to M. The source can't do that right now because you have two separate partitions. But being with the source, what you can do is you can say, "Well, I'm just going to forward as far as I can towards M, and then just sit there and wait. Eventually, the animals will move around or the interference patterns will change, and then the topology will change, and then maybe I'll be able to make some more progress. I'll eventually get a link to K, and I'll forward that data to K. You could see that if you have some natural churn in the environment, this is something we can leverage to eventually make more progress to destination. Nodes might have to wait,. They may have to hold on to the data for some time. If we're patient, we really care about getting that data through eventually, there might be a working path to the destination. This is called delay-tolerant networking because we're being tolerant of delays. We can't send the data now, but if we delay it and wait, maybe we'll get a way to do it. There's a number of different kinds of forwarding protocols and data dissemination protocols for delay-tolerant network, and they're based on this general concept. You could see that, if we're doing geographic routing, it might be pretty intuitive, how you do geographic routing for this environment. Because what we can do is, every node has its geographic coordinates, and to forward data, we can do this greedy forwarding procedure, or we forward the data as far as we can go. And then we sit there and wait while we can't make more progress. We wait for links to come up, and whenever a link comes up that makes more progress, we forward over that link. This is a small change in the greedy forwarding procedure. In traditional geographic routing, you sit there, forward as far as you can, and then you phase routing. With delay-tolerant geographic routing, you're forwarding as far as you can, and then you sit there and wait for a new link to come up that makes more progress, then you forward more in that direction. This is one way to do delay-tolerant mesh networking. We can also adapt other protocols to delay-tolerant networking. All the protocols we talked about, so far, if you sit down and think about it, a lot of them can be adapted to the scenario by leveraging these tricks. For example, let's consider link-state routing. Link-state routing doesn't work in partitioned networks, but let's run it anyway and see what happens. What we can do in these environments is, every node can run link-state routing. If we run it, every node will discover its local topology within its partition. So A, for example, we'll discover the topology of this partition, nozzle exchange these link-state messages. P will discover its partition, and so on. They'll have different pictures of the topology because they only know subsets of it. This protocol run every node with this partition will know about its entire local partition, so this gives us some information. For doing delay-tolerant link-state routing, what we can do is, we can do this, and then we can remember these links over time. We can run link-state but age out links when they go down, and the hope is that these links might go down, but they'll hopefully reappear in the future. This is good for scenarios where you get jammed, or links might come up and go down a lot. With this approach, you remember links that are down, and then send traffic in that direction anyway with the hope they'll come back up. The way this works is nodes will run this process, disseminate link-state advertisement, and discover their own local topologies. Let's focus on node A right now for clarity. What A will do is it'll sit there and it'll say, "I've discovered this topology, that's great, and then, eventually, the topology will change. Some links will go up, some will go down and then new link-state advertisements will be flooded, so this is the new topology. So A will say, "This is the new topology," but it's going to remember the old links. Because A is going to say, "Those old links, they're down. They were withdrawn, but they might come back up later, so I'm going to remember them." This process continues. The topology changes, and then enable aged-out links. In some drawing, older links as kind of yellow. We'll age them out more, they'll become red, and green will be the newest set of links that we know about. You'd see that over time. A builds a picture of the network, but not just the current topology, the historical topology over time. So A can sit there and they could say, " If I want to route the destination, I might have a working path. If I don't, I can see links that were there in the past that route in a certain direction, that reaches there, and then maybe those links will come back up later." You can make decisions about, not only the current set of links, but about links that are likely to come up in the future. So that's how delay-tolerant link-state routing works.
