The Internet of Things

Now, that we have profiled most of the IoT technologies, let us look at some of the design considerations for designing a practical IoT network.

The first consideration is the design of the sensors. Even though there might not be much of a choice regarding the sensors, there is definitely a lot of choice regarding the processing and networking capabilities that are bundled along with the sensors. Our choices range from small sub-mW boards meant for sensor motes to Arduino or Atom boards that consume 300–500 mW of power. This choice depends on the degree of analytics and data preprocessing that we want to perform at the sensor itself. Secondly, there is an issue of logistics also. To create a sub-mW board, we need board design expertise, and this might not be readily available. Hence, it might be advisable to bundle a sensor with commercially available embedded processor kits.

The next important consideration is communication. In IoT nodes, power is the most dominant issue. The power required to transmit and receive messages is a major fraction of the overall power, and as a result a choice of the networking technology is vital. The important factors that we need to consider are the distance between the sender and the receiver, the nature of obstacles, signal distortion, ambient noise, and governmental regulations. Based on these key factors, we need to choose a given wireless networking protocol. For example, if we just need to communicate inside a small building, we can use Zigbee, whereas if we need communication in a smart city, we should choose Sigfox or LoraWAN. In addition, often there are significant constraints on the frequency and the power that can be spent in transmission. These limitations are mainly imposed by government agencies. An apt decision needs to be made by taking all of these factors into account.

Let us then come to the middleware. The first choice that needs to be made is to choose between an open source middleware such as FiWare or a proprietary solution. There are pros and cons of both. It is true that open source middleware is in theory more flexible; however, they may have limited support for IoT devices. We ideally want a middleware solution to interoperate with all kinds of communication protocols and devices; however, that might not be the case. Hence, if we need strict compatibility with certain devices and protocols, a proprietary solution is better. Nevertheless, open source offerings have cost advantages and are sometimes easier to deploy. We also need to choose the communication protocol and ensure that it is compatible with the firewalls in the organizations involved. In general choosing a protocol based on HTTP is the best from this point of view. We also need to choose between TCP and UDP. UDP is always better from the point of view of power consumption. Along with these considerations, we also need to look at options to store sensor data streams, querying languages, and support for generating dynamic alerts.

Finally, let us consider the application layer. Most IoT frameworks provide significant amount of support for creating the application layer. This includes data mining, data processing, and visualization APIs. Creating mashups and dashboards of data is nowadays very easy to do given the extensive support provided by IoT frameworks. Nevertheless, here the tradeoff is between the features provided and the resources that are required. We do not need a very heavy framework if we do not desire a lot of features. This call needs to be taken by the application developers.