by Sumit Chawla, Rishee Basdeo, Michael DAniello, Tristen Payne, James Seibel, Sargam Sharma, Georgianna Shoga, Weng Bingliang, Chris Willis, John Day, Lou Chitkushev (Boston University)
Abstract. IoT holds great promise to improve the quality of life and enable new capabilities. However this bright future is being endangered by at least two factors: security and the complexity created by the proliferation of IoT protocols. Proliferation will lead to an unnecessary increase in complexity and increased inefficiency, increased cost and lost effectiveness. Generally the argument is that IoT requirements are unique and therefore justify a unique protocol for its unique circumstances. But the power of IoT is in the potential to integrate what they do and the data they collect in ways, we have only scratched the surface. We undertook to test this rationale of uniqueness and found that it wanting. In fact, IoT protocols represent a rather elegant degenerate case of the general model of protocols we have uncovered over the past decade. That would seem to leave the only rationale for different protocols is to serve as barriers to competition.
Over the years we have seen technology transform exponentially, from using computers that took up whole rooms to workstations to desktop computers to holding a computer in the palm of our hands. This trend is continuing as there is now the potential for a computer in practically any physical object. Consequently, one of the current topics in networking that is grabbing considerable attention is the Internet of Things (IoT). The scope of IoT is sometimes hard to nail down. One might start to believe that there is a reason for every object in the world “to be on the ‘Net.”
The applications seem endless from industry to healthcare to transportation to shipping to the home and beyond. Applications range from thermostats, to home security, to RFIDs for packages, to industrial control, health monitors, every package that is shipped, traffic lights, drones, etc. etc. Along with the proliferation of IoT devices has come almost as many different protocols to control or retrieve information from these things. Because IoT applications have limited functionality and operate under very tight constraints of cost, bandwidth, power, tight resources on computing and memory, etc., there is a strong argument to include only the functionality absolutely necessary. Consequently, IoT protocols try to be as minimal as possible, to cut every possible corner. To try to understand them all and why they should be used for particular situations is a daunting task.
So the question arises, are all of these protocols necessary? Could IoT be simpler? Obviously, different environments and different application domains present opportunities for simpler protocols, or the converse, present special problems to overcome.
On the surface, it would seem we have set ourselves an impossible task. IoT is primarily concerned with protocols that operate directly over the physical media. Consequently, their design is most affected by the medium. Furthermore, the very nature of IoT devices and applications are highly constrained as well. All of this would seem to argue for the least flexibility to find commonality. Different protocols tend to lock the customer into one vendor’s (or set of vendors) IoT product line and at the same time create barriers to entry to competitors. Given the number of IoT “standards,” the practical effect is less to make devices more interchangeable (the purported purpose of standards) than it is to create alliances of companies in competition with each other.
Considering all of this, it might not appear at first glance there would be much chance of finding much commonality without sacrificing the advantages of a hand-crafted protocol. Commonality has many benefits:
- The customer can more easily mix and match devices from different vendors in their network.
- Commonality should create economies of scale and reduce product costs faster.
- The key to effective network management has always been commonality, commonality, commonality. Reducing the “parts count” is important to reducing the cost of operations. Furthermore, protocols (and therefore the products they are in) built to work together will complement each other, be more efficient, make management simpler, more effective, and to make changes more predictable with fewer surprises.
Clearly, if we look for equivalence where the protocols do precisely the same thing, the answer would be not much. But if we look for common functions that yield the same effect, the same service, but not necessarily precisely the same way that might yield better results. As long as we are looking for commonality, there is another area of concern. With the very large numbers of IoT devices both in terms of numbers of units and types of units, it would be advantageous if the devices were as self-configuring or dynamically configurable as possible. Experience with both the Protocol-Id field in IPv4 and the Ethertype field in Ethernet indicates that if at all possible, administrative Registration Authorities should be avoided wherever possible. Over time, these registration authorities become an “archeology” of legacy products and protocols where ranges of assigned numbers become strata, and worse, can never be reclaimed.
The rest of this paper is organized as follows. In Section 2, we introduce the model we will use in our search for commonality. For brevity in this paper, Table 1 replaces Appendix A and B of the Technical Report version , which briefly introduces the 10 IoT technologies surveyed for this work. Section 4 presents our conclusions.
II. Our Model of Protocols
A. The model itself
We will compare the existing IoT protocols to a canonical model of protocols developed in . To analyze these protocols, two tools can be brought to bear: separating mechanism and policy, and distinguishing abstract and concrete syntax. Separating mechanism and policy is often used in operating systems, but applies very well to protocols. Distinguishing abstract and concrete syntax makes the protocol invariant with respect to syntax. The functions performed on the information is the same only their lengths differ. The protocol can be specified with the abstract syntax and use different concrete syntaxes for different environments.
- Enrollment creates sufficient state within the network to allow an instance of communication to be created, or how a Layer Process (LP) joins a layer.
- Allocation creates the shared state to allocate and coordinate the resources to support the data transfer functions of an instance of communication.
- Data Transfer provides the functions to support the transfer of data as requested.
- An identifier, often called an address, that identifies the LP. Addresses are only unambiguous within the scope of the layer and only required when the layer has more than two LPs.
- If the LP is to support more than one flow at the same time, a connection-id is necessary to distinguish flows between the same two addresses and only need be unambiguous between the two LPs named by the addresses.
- This is generally created by concatenating connection-endpoint-ids (CEP-ids) of the source and destination. These CEP-ids are unambiguous within the LP, i.e. local to the LP.
- Finally, a port-id is required to identify each instance of communication between the LP and the user of the layer. Port-ids are the only identifier shared between the LP and a user of the LP and are unambiguous with respect to the (N)-LP.
B. The common IoT device
In the analysis of IoT protocols (see Table 1 or ), it was quickly recognized that many IoT devices (but probably not all) had a common model. The survey included 10 IoT protocols: Wireless Hart , ISA 100.11a , Zigbee , Z-wave , Dash-7 , Thread , Bluetooth-LE , NFC , LoRaWAN  and LTE-A . Most of these protocols support a single application, e.g. a thermostat, light controls, etc. with commands that involve a small amount of data. The data transfer protocol is often a stop-and-wait protocol, either explicitly, e.g. 802.11, or implicitly created by a request/response command form. Most of these protocols use pre-assigned MAC addresses, although some do have an explicit enrollment procedure to assign an address or join a layer, e.g. 802.11. Since these protocols are so simple and generally point-to-point, layer management is minimal or non-existent.
The single application implies that multiple flows between the same two addresses do not occur, so explicit connection-ids (port-ids and CEP-ids) are not required and enrollment (when present) is synonymous with allocation. The stop-and-wait nature of Data Transfer along with being point-to-point is sufficient to ensure reliable data transfer. Generally, one SDU is mapped to one PDU and a checksum or CRC is present. We found that all of the IoT protocols surveyed have this configuration. Figuredepicts a network of sensors/actuators connected to an IoT management platform that follows the common IoT device model.
In the interests of improved security, and consistent with the position above that registration authorities should be avoided. If possible, addresses should be assigned when a device joins the network and the size of the address fields in the protocol should be large enough to accommodate the largest layer using the address and no larger.
III. Putting it all together
This analysis has found that there is not much difference across IoT in the data transfer protocols or the application protocols. Then what is special about IoT?
- there is a wide variety of the object models that the application protocol manipulates, which on each device are relatively simple,
- there are a modest number of physical media technologies, where the choice of data transfer policies is mostly determined by the environment, and
- there are potentially a very large number of IoT devices to be put on a network.
It would not be an exaggeration to repeat that last one: There are potentially a very, very large number of IoT devices that could be attached to anyone network. In fact, scaling problems has been the one thing most talked about. At a meeting in London in 2015, it was said that in 5 to 10 years there could be more devices connected to the Internet in the London area, than on the Internet today. One can presume that that will be true of every major metropolitan area in the world. The general consensus in the meeting was that it was hard to figure out how to handle a network at that scale using the current technology.
IoT devices tend to be quite simple. They can be sensors and/or effectors of relatively simple tasks. The power and the promise of IoT is not in the individual devices but what they can do in concert. We have a glimmer of that potential now, but would suggest that we have not even begun to imagine what can be accomplished with combinations of IoT devices that have not yet been imagined. This is the real potential. People will find creative and innovative new capabilities from combinations that have not yet occurred to anyone and would probably sound outrageous if we had. This is where we want to spend our energies, not trying to get around incompatibilities in protocols. As we have seen limitations and incompatibilities like this can inhibit that innovation.
Given that, if IoT is going to be successful, one complicating factor is sufficient. The others should be minimized to the greatest degree possible. A common data transfer and common application protocol can go a long way toward making that the case. In fact, separating mechanism and policy as in RINA provides commonality without sacrificing flexibility. Because IoT networks are generally edge networks of limited scope (but high density of devices), the data transfer characteristics can be tailored to the owner’s requirements, and the recursive nature of the layer structure solves the scaling issues.
We must move to greater commonality and RINA is really the only way to do that. Furthermore, it not only simplifies the IoT networking problems by bringing simplicity and commonality, it does it for the rest of the network: whether WAN, Cloud, or Data Center. And that commonality can be leveraged to provide even greater savings in both capital expenditures and operating costs.
 S. Chawla, R. Basdeo, M. D’Aniello, T. Payne, J. Siebel, S. Sharma, G. Shoga, W. Bingliang, C. Willis, and J. Day, “Iot or coping with the tribble syndrome,” BU Technical Report, June 2017.
 J. Day, Patterns in network architecture: A return to fundamentals. Pearson Education, 2007.
 R. Watson, “Mechanisms for a reliable timer-based protocol,” Computer Networks, vol. 2, pp. 271–290, 1978.
 G. Boddapati, J. Day, I. Matta, and L. Chitkushev, “Assessing the security of a clean-slate internet architecture,” Proceedings of the Network Protocols (ICNP), 2012 20th IEEE International Conference on, 2012.
 F. Group, “Hart communication protocol specification,” HCF SPEC-13 version 7.5, May 2013.
 I. S. of Automation, “Ansi/isa-100.11a-2011 wireless systems for industrial automation: Process control and related applications,” ANSI/ISA standard, May 2011.
 Z. Alliance, “Zigbee specification,” Document 053474r20, September 2012.
 S. Labs, “Z-wave specifications,” Z-Wave Specifications release package,September 2018.
 D.-. Alliance, “Dash7 alliance protocol specification v1.1 – wireless sensor and actuator network protocol,,” DASH7 Alliance Protocol Specification v1.1, January 2017.
 T. Group, “Thread 1.1 specification,” Thread 1.1, 2017.
 B. S. I. G. (SIG), “Bluetooth mesh networking specifications,” Bluetooth specifications, July 2017.
 N. Forum, “Nfc logical link control protocol technical specification,” NFC Forum Technical Specifications.
 L. A. T. Committe, “Lorawan specification v1.1,” 2017.
 3GPP, “Lte advanced pro specifications,” 3GPP Release 13, June 2016.
 T. Ramazenifarkhani and P. Teymoori, “Securing the internet of things with recursive internetwork architecture (rina),” International Conference on Computing, Networking and Communications, May 2018.