Delay Tolerant Networks (DTN)

There are myriad applications for this intermittent connectivity model and so a solution was required and there is ongoing research into possible alternative communication protocols, one of which is DTN or Delay Tolerant Networks. The characteristics of DTN are that the protocol is designed for intermittent connectivity, where there is no direct path from source to destination. It also supports long variable delays, and long propagation delays between nodes. The reason DTN was developed was to support interplanetary communications as part of a NASA research project. NASA were looking into alternative protocol to TCP/IP as it doesn’t work well over the long variable propagation times and intermittent connectivity which are characteristics of space communications. The solution was DTN and they made the protocol available for use out with the space program.

DTN turns out to be perfect for many IoT applications as it works on a store, carry and forward basis. For example the sending node the sensor in IoT collects and stores the data (store) until it comes into contact (carries) with another node to which it can pass on the information (forwards). The recipient node then stores the data, and carries it on its travels until it can forward the data to another node and in this way the data gets passed up through the network until it reaches its destination. The point being here that large variable
delays are tolerated as the primary concern is delivering the data to the destination over an intermittent and unreliable network.




























DTN has many applications in the IoT world, for example interplanetary internet, wildlife monitoring, battlefield communications and internet communication in rural areas. In the latter, whereby rural villages have no communication infrastructure, communication can still be possible albeit slowly. How it works is the village builds a booth that contains a PC and communication equipment running DTN protocol. The villagers’ messages are stored locally on the DTN device. The local buses that service the villages and interconnect the
rural villages carry Wi-Fi routers that connect/peer to the DTN equipment when they come into range and the messages are forwarded to the data equipment on the bus. The bus then carries the data with it on its journey from village to village collecting and storing more data as it goes. Eventually when the bus returns to the town or city depot it forwards the data it has collected on its journey to an internet connected router and the data is delivered to the eventual destination over the internet. The return internet traffic is handled in a
similar manner, with the bus delivering the return traffic (messages) back to each village on it next journey. This is simply a digital version of how mail was delivered once upon a time.

DTN can store-carry-forward data across a long distance without any direct connection between source and destination. Though it could be said that in the previous example a bus was the path between the source and the destination and wasn’t random. When handling communication though in random networks, for example when performing wildlife tracking, there is no regular bus passing by so we have to make use of other relay
nodes to store, carry and forward the data. When we use these mobile ad-hoc networks there are several tactics that can be deployed to increase efficiency. One method is called the epidemic technique, and this is where the holder of the data passes it on to any other relay node that it comes across. This method can be effective but wasteful of resources and high on overhead as there could be multiple copies of the data being carried and forwarded throughout the network.

One solution to the epidemic techniques inefficiency is Prophet, which stands for Probabilistic Routing Protocol using History of Encounters and Transitivity. Prophet mitigates some of epidemic’s inefficiency by using an algorithm to try to exploit the nonrandomness of travelling node encounters. It does this by maintaining a set of probabilities that the node it encounters has a higher likelihood of being able to deliver the data
message than itself.

Spray and Wait is another delivery method that sets a strict limit to the number of replications allowed on the ad-hoc network. By doing so, it increases the probability of successfully delivering the message whilst restricting the waste of resources. It does this because when the message is originally created on the source node, it is assigned a fixed number of allowed replications that may co-exist in the network. The source node is then permitted to forward the message only to that exact number of relay nodes. The relay nodes once they accept the message then go into a wait phase whereby they carry the message – they will not forward it to other relays - until they directly encounter the intended destination. Only then, will they come out of the wait state and forward the message to the intended recipient.

As we have just seen with DTN IoT can work even in the most remote areas and inhospitable environments, because it does not need constant connectivity it can handle intermittent ad-hoc network connections and long delays in delivery. However, that is in remote areas transmitting small amounts of data within specialist applications – wildlife tracking, battlefield conditions. In most IoT applications, we have another issue, and that is handling lots of data, really large amounts of data.