34 Other protocols for IoT

Prof. Bhushan Trivedi

Introduction

In this module, we will look at how routing and forwarding are done for IoT networks and some other protocols which are normally used with IoT devices. We will begin with routing and forwarding process using RPL, we will discuss some protocols used at various other layers, for example, DNS-SD for discovering services offered by other IoT devices, mDNS to look for a specific node by name, CoAP as an application layer protocol for constrained devices etc.

IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL)

IETF devised RPL for routing over mesh networks. The protocol only works for IPv6 and not IPv4. This is a routing protocol like OSPF, IS-IS, AODV, and OLSR (all of which are from IETF for specific forms of routing, for example, OSPF (Open Shortest Path First) and IS-IS (Intermediate System to Intermediate System) are implementations of Link-state routing protocol for internal routing (within AS). AODV is used for mobile ad hoc networks while OLSR (Optimized Link State Routing) is another implementation of LSR.

The IETF group was given a job to find solution to this problem1. They started with evaluating other protocols to find if some other protocol can be directly applied to this situation. However, after careful deliberations, they decided that none of the existing protocols can work for this problem so an additional protocol was needed. The outcome was RPL.

The job of RPL to help each node announcing their direct connections and learning about other nodes and route to connect to them. Non-storing node runs a client RPL2 which sends the information about themselves, their direct neighbors and other details to the RPL server running in the coordinator. The RPL server, once receives all communication from all nodes, can easily decide the entire network topology.

The RPL server constructs a forwarding tree in a little different fashion. Each link in this tree is directed and have direction from the leaf to the router. This typical formation is known as Destination Oriented, Directed, Acyclic, Graph (DODAG). It is destination oriented as it is forwarding in the direction of the destination, the coordinator, it is directed as the

1  This group is known as ROLL, (Routing over Low Power Lossy Networks)

2  an exception to this are the leaves. They only have one connection so they do not need to decide the route. All other nodes who have more than one connection should be acting as intermediaries and thus need to run the RPL client movement is in the direction of the coordinator, it is acyclic as there are no cycles (there is only one path possible between any two nodes). The word Graph is little surprising but sometimes the node is just not reachable and it is basically an isolated node. Such nodes are not allowed in a tree and thus we call this a graph. Also, the direction of the arrows is such that a node has multiple parents, thus cannot be called a tree. However, if we ignore isolated nodes and reverse the direction of the arrows, it is a tree and we can still call it forwarding tree.

Though this graph is called a directed graph, the movement is in reverse direction when the coordinator passes the packet to the destination node. (i.e. it starts acting like a tree when the coordinator sends the packet received from the sender to the receiver.) The movement of the packet, in this case, is exactly in the opposite direction of the arrow. The coordinator, having complete topology, knows the exact path which it puts in the source header of the packet it sends to the receiver. The packet travels along the path indicated by the source route information in the header of the packet. This source route information is not present when the sender sends that packet to the coordinator. The coordinator actually constructs a new packet with source header and embeds the actual packet inside that new packet.

In this DODAG, there are three types of nodes, first, is the root itself. The coordinator is at the position of the root (here the terminology of a tree is used again but please do not get confused. If the arrow directions are reversed, the graph becomes a tree and the coordinator becomes the root). The nodes which are only connected to one node, are leaves. The nodes which have at least two connections are called intermediaries. The intermediaries help in forwarding packets and thus they are known as ZigBee IP Routers, (ZIP Routers). The RPL client runs at ZIP routers (and not leaves). The leaves send all their packets to ZIP routers and they determine the path to the coordinator.

The RPL is also used with storing nodes. The node needs to specify exactly what mode it is operating on, if it is storing node, the routing is performed based on its forwarding table.

One of the links is to be chosen as the best routing link. These routing links are chosen over an objective function. This function is based on parameters of the link (for example, how reliable it is), and node (for example status of the node, energy level of the node etc.).

Loops are to be avoided in any type of routing, RPL is not an exception. It introduces a concept of a rank to counter the problem of loops. A rank value is the distance of the node from the root. Directly connected nodes have the rank value 1 and their immediate neighbors have the rank value 2 and so on. One critical parameter set by the coordinator (the root) is maximum rank value. That means a node cannot go deeper than this maximum rank value. This provides an upper bound to the routing process. When the packets are moving towards the coordinator and coming back, RPL checks the anomalies in the rank values. Rank values, while going towards coordinator, should be decremented by one and while coming back, should be incremented by one at each hop. If that is not happening, it is called an anomaly. The RPL, when an anomaly is found, restores it by setting the right rank values.

Another critical feature of RPL is repairing or recovering from a node or link failure. When a node or link fails, the network must restore the connections. That is done by two mechanisms in RPL, a local repair, and a global repair. A local repair is required when a node suddenly loses its connectivity with the router. It has to find an alternate path to the root. Once the alternate path is selected, the packet starts routing over that new path (which may not be optimal) and local repair is done. When multiple local repairs are performed on the graph, most of the nodes of the graph do not have an optimal path to the router and graph is reconstructed at that point of time. That process is known as global repair. Global repair demands the complete restructuring of the graph and that is why it is quite expensive in terms of time and energy. Thus root only can initiate that when it feels that the network has many un-optimized routes. In that case, each node has to execute the optimization function yet gain to choose the best parent to the root.

As RPL needs to save energy of the nodes, periodic timers are avoided and an adaptive method to send multicast routing updates. When the network is stable, very few messages are sent. When there is some inconsistency occurs, for example, a new node enters the network or removed from the network, or a node detects a loop etc., the multicast updates are sent at much faster intervals. Thus the routing updates are more when there is a major upheaval in the network and less when the network is steady.

Shortcomings of the IETF route-over approach

We have looked at both Mesh Under and Route Over approaches and discussed that IETF has opted for Route Over approach over Mesh Under approach.

Many researchers have continuously worked on many issues related to both approaches and raised questions about the choice of the route over approach. Let us summarize some of them.

Some researchers claim that IPv6 and mesh networks are fundamentally different in terms of capacity (the MTU or Maximum Transferable Unit, the bandwidth supported, the volume of traffic) etc. and using IPv6 for that network is a misfit. The protocols like MLE and RPL are basically patches that are needed to match these two different worlds. Also, when IPv6 can send the network related information, and RPL also can do so, administrators are in a dilemma which one to choose. When different segments of the mesh network share the same IPv6 prefix but do not share the same broadcast domain, the neighbor discovery protocol also requires being upgraded. The shim or adaptation layer is another example that is needed for 6LoWPAN to be used for mismatching the MTU between these two different types of networks. We have already seen that 1280 bytes are a minimum value for a payload in an IPv6 packet, while maximum payload for 6LoWPAN is only 107 of total 127 bytes (and 81 bytes if we use authentication tag). The solution requires fraglets to manage this.

Interestingly, this fragmentation leads to other problems. For example, one typical characteristic of the mesh networks is that they are lossy. The walls and pipelines of a home network, for example, sometimes prohibits propagation of signal and other devices working in home interferes with the transmission of the devices running this protocol. That means, there is a definite possibility of losing some fraglets. Unfortunately, even when one of the many fraglet of a packet is lost, an entire packet is garbled. That means, the probability of a packet being garbled increases manifold.

There are other problems too. A coordinator is connected to the rest of the world as well. It is an IPv6 router and an entry point for packets coming from other networks. Such routers are known as border routers. Once such problem associated with this router is, what will be the network MTU for the coordinator (which is also a border router for this IPv6 network) should advertise?

The network cannot advertise it to be 127 bytes as it is not allowed. The next best option is to advertise 1280 bytes which are minimum allowed value. Consider a case of a packet needs to be routed through this network. In that case, the outside sending router will send the packets of size 1280 bytes to this network. Now this network cannot send such big packet to any node of this network and thus it must generate fragments. When the packet exit from the other end of the network, it must be defragmented and the original packet must be constructed yet again. That process demands some additional headers which increase the total size of the packet beyond 1280. That means, the border router, when advertises the MTU value to 1280 to the outside world, it must consider the additional overhead of fragmentation and use a little higher value of MTU inside. This is doable but the problem is that the border router cannot use a readymade software for IP routing and a new software must be constructed. Such a design is hardly welcome in our world for many reasons. First, conventional software usually gets updated and improved over a period of time, having different software demands that additional burden. Second, most such software is designed and updated for interoperability. For example, when IPv6 proposed to replace IPv4, a huge amount of time was spent on making sure IPv6 can work with existing TCP protocol and many other protocols. Similarly, it is possible that the software for managing IP related issues like MTU-probe is redesigned. An MTU-probe is sent to a network to ask for their MTU size. When such a software is redesigned, the designers take the pain in making sure it works with existing IPv6 border router solutions. If the programmers do not take care of looking at the compatibility of the 6LoWPAN border router software, it might fail to work with such a network.

When RPL is used to transmit the packet to the destination, the root must be able to send it to the right destination. The path to the destination is encoded using a source routing option in an IPv6 header indicating which intermediaries to travel over to reach to the given destination. The root knows the complete topology of the network and thus can pinpoint an exact path to the destination and place it in the IPv6 header as source route information. An incoming IPv6 packet already has a header indicating information that it needs to reach to the destination as a node of this mesh network. That header must remain intact for the receiver to process that packet correctly and respond back properly. That means the new header with source routing cannot be added to the existing packet.

The solution is to have a new packet with source routing information and embed the original IP header inside. We know that this approach is called tunneling and is commonly used at many other places in the conventional network for a variety of reasons. We also call it IP-in-IP encapsulation. The overhead in the conventional network is not considered too much but for a mesh network with very low capacity, this is a huge overhead. Another problem is that it will also increase the size of the packet, which may be of the maximum size already, resulting into additional fragmentation.

We have seen a lot of mesh networks. Let us talk about other options for IoT and few other supporting protocols now.

5G with IoT

When we state that mesh networks are most common networks and protocols that we discussed are most common, there are many other protocols which are also used where mesh networks are no appropriate for deploying the IoT-based solution. For example, in a smart agricultural case, or habitat monitoring case, the recorder is quite far from the sensor itself and the small distance protocols that we discussed here may not be appropriate.

Home networks or factory networks can have the liberty of having a border router but some other networks, for example, environment modeling, water quality testing, fleet management etc. might not have that luxury. One of the nodes or all nodes needs to communicate to a far-away server, over a long distance wireless line. Another assumption about low bandwidth might also be false in some cases where minute details of the device being monitored are sent over the line. For example, a wearable device might send many details about the wearer including multiple images of surrounding and many other details to enable context aware computing. Such a device might also be able to handle a huge amount of data from the body and also have AI capabilities to learn about the body related trends. Such trends can help conclude if there is a significant probability of a person is having of disease in the first stage and can suggest initiating diagnosis. This can save huge medical cost and human lives in some cases. In some cases, we might not even have a cluster, for example, a smart metering system will only have one sensor which will have to communicate the electricity company’s reader significantly far considering the range in which 6LoWPAN networks work.

Many problems that we discussed during our discussion about smart cities in module 6 demand long range, high bandwidth transmission, for example, vehicular information to the central server for congestion detection, finding alternate routes, avoid polluted areas, detecting accidents, provide faster assistance in case of accidents and calamities etc.

The technology used for deploying such network is known as LTE (Long Term Evolution) or 4G in slang and LTE-Advanced or 5G in slang. It is the first fully packet switched mobile network in 2004 by 3GPP (3rd Generation Partnership Project, a collaboration between some telecom associations). This technology is an extension of GSM (Global System for Mobile Communication) and UMTS (Universal Mobile Telecommunication System) technologies. The technology supports a range of up to 5 Km.

LTE-A (the advanced version) is able to provide throughput up to 1 Gbps downlink and 500 Mbps uplink. It improves the spectral efficiency (the amount of data sent per given frequency band) and latency (the delay for the data to travel to the destination). Some researchers are pointing out some technical issues in using these technologies with IoT but others are suggesting solutions to those issues. For example, OFDM (Orthogonal Frequency Division Multiplexing) which is considered very good for a smartphone as well as laptops, is considered not suitable for IoT. Other methods are being researched right now. Many researchers see 5G is a viable option for IoT long-range high bandwidth transmission.

M2M and other technologies

We have already seen that M2M is a communication from machine to machine and it is fundamental for IoT. This communication is autonomous. In the context of IoT, M2M describes the autonomous exchange of information among multiple IoT devices interconnected with each other. Intelligent transportation systems, Supply chain management systems, smart metering, e-healthcare, surveillance, security, smart cities, home automation etc. demand such communication. For example, smart metering demands a smart meter communicate with a reader, e-healthcare demands IMDs talking to doctor’s phone or any other monitoring device, supply chain management systems generate orders for any component that is in short supply for any product on its own and communicate with the vendor.

We can see that the mesh networks that we discussed earlier are not able to handle quite a few of these cases. Here are a few challenges.

1. For a large number of devices, the total amount of bandwidth needed is quite high.

Consider all patient’s X-ray images going to the doctor’s mobile phone together.

2. Coverage must be extended to every IoT device located anywhere, thus enhanced coverage is a must. For example, in a smart city case, the coverage must cover every corner of the city, including basements.

3. The power consumption, even though the capacity demanded is high, must be low.

4. The network must be reliable, for a case like health care, if a network cannot send the message about bad heart condition of the patient to the doctor immediately, there are serious consequences. In other cases, though little delay may be accepted, one needs a reliable network otherwise the decision making may not be accurate. For example, a timely update about traffic can save a person from a traffic jam and also help traffic jam to recover faster.

5. The technology should be easy to deploy and easy to be integrated with existing networks.

6. There are many devices to be deployed in many cases, thus, the cost per device and the software needed to run that device must be low cost.

7. The traffic is usually very small in size. 1 to 128 bytes is observed in normally used IoT networks. One needs to provide efficient solutions for such a small size of data.

8. The IoT network traffic is more in uplink than downlink, unlike conventional mobile networks. Typical schemes which favor downlink than uplink (for example, ADSL) cannot work here.

9. When IoT devices use technologies like 5G, they need to compete with mobile traffic. New and better methods to enhance spectral efficiency, control latency and avoid network congestion in presence of very large number of devices.

There are many other technologies that are being presented but none could solve all of above in a satisfactory manner and the search and the research are on. Let us look at some of the technologies here.

802.15.1 or Bluetooth is also considered by many and they are using it for IoT deployment. The plus side for that technology is a huge number of devices already supporting this technology like smartphones and it becomes easier to deal with such devices. The downside is the shorter range.

802.15.3a or ultra-wide bandwidth or UWB is another technology. It is a short range but high bandwidth option as well as long range low bandwidth option. The information is sent over a more than 500 MHz bandwidth, but it allows others to use the same bandwidth at the same point in time.

Some applications demand intelligent and autonomous control. For example, a system which takes command from eye movement of a user or system which control the dosage of medicine for a typical patient. Such systems join two different worlds, cyber and physical, and thus are known as CPS (Cyber Physical System). Some researchers claim that most of the IoT systems will evolve into CPS systems in near future.

The model that we have elaborated while discussing with 6LoWPAN networks, where the devices communicate to each other, is prevalent and known as cooperative network model. There are other models used in practice as well. For example, a case where all devices directly communicate with every other device is known as fully distributed networks. One of the nodes of the network acts as a router. Another case is called client-server model, where each device directly communicates to the server without communicating to any other device. These different types of model demand different types of solutions.

Let us brief about CoAP before going further. The Constrained Application Protocol is preferred to be used at the application layer. CoAP is quite similar to HTTP, the difference is, it is designed to obtain value from a sensor and HTTP does so from a web API. CoAP is designed to use minimal resources, unlike HTTP. It uses UDP over IP, a 4 byte fixed header and very compact message based on clever use of options. RFC 7532 describes it in detail. It uses DTLS (Datagram TLS) over UDP. Running CoAP at the application layer is considered a very good option.

The world or IoT is highly convoluted and many things are brewing at this point of time. It is very hard to see who will be a final winner.

Supporting Technologies

IoT is a new wave of computing and technologies which enable networking those devices and enabling communication between them are the core part of the solution. However, there are other technologies which are there to support (run at other layers). Let us briefly discuss those technologies before concluding.

There are applications which people would like to build on top of the IoT device and thus these applications run at the application layer. Based on the need for saving energy, the application layer for IoT device is little different than the normal application layer. For example, the ZigBee specification demands applications which are compliant to Smart Energy Profile (currently version 2.0) only are allowed.

Smart Energy Profile (SME) is a standard from ZigBee Alliance and monitored by NIST. SME guarantees low power consumption for devices. It is basically an application layer collection of standards where clear cut options and sets of configuration values are specified. This helps the messaging process to be optimized for efficiency. It primarily runs over ZigBee but can run over few other protocols as well.

SME has some similarity with Bluetooth. It has some application layer profiles already suggested. Those profiles are known as function sets. For example, one of the profile is called pricing. Pricing allows the utility company like electricity company to price the customer in a dynamic fashion3. Similarly, another function set allows the customer to get metering and energy usage information. The standard is (right now) heavily biased towards utility company needs and home networking demands.

The IoT devices, when sends a message to a server running over the web, use web service as an intermediary. Most applications reside on cloud and thus these web services provide the interface of the IoT devices to the cloud. The people who write programs to get information from IoT devices and use them need to also store and retrieve that information and some database solution is also used along with cloud and server application.

One more issue with such small networks is that they do not have their own DNS server. In the conventional network as there is a DNS server running in the network which is connected to other DNS servers of the rest of the world and thus any URL, if not possible to be resolved locally, will be resolved using a name server query by this local DNS server. A small network needs a similar service for locally resolving a name of a device into its IP address. It does not, therefore, need to have the heavy duty DNS server. The solution is called mDNS and it is used at many other places and not only with IoT devices.

In an IoT network, if a node wants to learn about an IP address of any other node, it sends an mDNS query using the name of that node. The mDNS client sends an IP multicast query. The target machine, upon receipt of the query, responds back using multicast. In this way, not only the source node but all those who are in receipt of the message as a member of multicast gets this information and can use that information. For example, when a node demands an IP address of a typical node, the response is also multicast so other nodes can also update their DNS cache. mDNS is a low-cost solution and used only in the local context. Each host listens on the port 5353 and resolves requests for the DNS record of its local hostname. Thus A (IPv4 Address), AAAA (IPv6 Address) and CNAME (Alias names) queries can be answered locally.

The mDNS is useful in making sure each device in the network having a proper user-friendly name. The mDNS converts such names into IP addresses and thus help users easily address problems associated with specific devices.

3  the profile is like a mobile app. One can directly use it at a programmer level

Another requirement is to locate nearby servers and peer to peer clients for web access. The process called DNS Service Discovery is included in many conventional products like Safari from Apple. The applications can use DNS-SD to browse the network for specific services. Thus using this service, the clients can locate a typical web page and a device like a printer etc. This can also be configured to allow clients to advertise their own service over the web. The DNS-SD in most cases use mDNS but it can use other protocols for sending requests for service discovery and get responses as well.

DNS-SD is a handy technology needed for IoT devices. Let us try to understand. IoT devices are independent devices, running their program and communicating with the world. Configuring them is a difficult job as most of them do not have any user interface. For example, if we want to provide them IP address or network mask it is not as straight forward unlike the normal laptop or mobile device. This is also true for IoT devices used at home where the customer does not even have the technical knowledge for setting IP address. The DNS-SD helps in automatic configuring an IoT (and other non-IoT devices if need be) devices and discovery of network services.

A device (or a user), sometimes need only a typical type of service provided by any device. The device is not interested in the particular device but a service. The device which needs this service is interested only in getting that service (with specific properties sometimes), irrespective of which device provides it. For example, a device might send a picture of patient’s X-ray and want to get it printed on some high-resolution printer. It is looking for a device which can provide a service of the high-resolution printer and that is all. The DNS-SD helps in finding such a device.

All service discovery use IP multicasting. IP multicasting uses a specific range (224.0.0.0 to 239.255.255.255, popularly known as the multicast range in IPv4 and Class D type of address). Normally a UDP packet is sent to one such multicast address. All nodes which have shown willingness to be part of that multicast (for example, a printer may show a willingness to be part of a multicast group of printers), will receive that multicast.

Service discovery in done in following steps.

1. A sender sends a service request with specific parameters, for example, printing with high resolution

2. Other devices belong to the same network and part of the multicast group gets the request. If they run such a service or know some other node which provides such service, they respond back with that answer

3. The sender of the request collects all responses and choose the best offer based on its own choice.

Once a certain service is found, the sender may need to communicate with the node which provides service further. For example, the printer might provide multiple options like portrait and landscape printing or different resolutions or color and BW type. The sender might need to find out what are the options supported and what are the arguments passed to that device.

DNS-SD can be used with mDNS if the service to be obtained from the local network or conventional DNS if service demanded to be obtained from the Internet.

Another important requirement is security. It has been mentioned earlier that the 8-2.15.4 links operate in a secure or normal fashion based on user’s choice. When security is chosen, which is recommended, an additional protocol is needed for making the communication secure. There are a few options, IPv6 provides IPsec by default but one can also use TLS or SSL over TCP link. TLS or Transport Layer Security is a standard from IETF for encrypting and authenticating anything over TCP4. TLS is quite a complex protocol and the discussion is beyond our scope. You may refer to a book by William Stallings, Cryptography and Network Security, Pearson for learning more about it. The CoAP uses a little different version of TLS which runs on top of UDP and known as Datagram TLS or DTLS.

Another option is to use security called EAP or extensible authentication protocol. Those who have installed some router at their own place for wireless access have gone through some configuration settings probably know about this protocol. EAP is a protocol for a device to get authenticated with the access point. The access point is not usually being able to authenticate so a request from the device is relayed to a typical authentication server for the authentication. The EAP is the protocol for the first hop in this two-hop security process5. The LAN based on 802.11 uses 802.11i for security and 802.11i uses EAP for authentication exchange. The same protocol is used here. The process includes key exchange (for encryption and authentication), and other parameter exchanges needed for security the communication and generating and adding authentication tag which is analogous to a human signature. Thus EAP helps the receiver confirm the sender being who he claims to be, and also confirm the content being valid and not changed after sent by the sender.

PANA or Protocol for Carrying Authentication for Network Access is an additional protocol used here. It is an IETF protocol defined in RFC 5191. As EAP expects the access point to be directly reachable which is not possible in many cases in 802.15.4, PANA is used to carry the request to that access point over the mesh network. It does not define any now authentication protocol etc. It is only used as a vehicle to carry the EAP payload to the access point. One of the biggest advantages of PANA is that it is independent of the link layer protocol and help to choose service provider dynamically.

4  a solution called DTLS or Datagram TLS is another option to run over UDP.

5  For the second hop, i.e. between an access point and an authentication server, a protocol called RADIUS (Remote Access Dial-In Service) or a later version of it called DIAMETER is used normally.

Summary

In this module, we looked at how RPL manages to route between storing and non-storing nodes by using DODAG. We have looked at some protocols like mDNS, DNS-SD, PANA, etc. which helps to work of IoT protocols and mentioned some alternatives to 6LoWPAN. We have seen the drawbacks of route-over approach as well.

References

1. Computer Networks by Bhushan Trivedi, Oxford University Press

2. Data Communication and Networking, Bhushan Trivedi, Oxford University Press

3. Internetworking with TCP/IP, Douglas Comer,Pearson