Internet of Things
Definition, applications and comparison of wifi-based communication protocols for implementation of an irrigation system
EMELIE BRUSE
Master of Science Thesis
Stockholm, Sweden April 2015
Internet of Things
Definition, applications and comparison of wifi- based communication protocols for
implementation of an irrigation system
Emelie Bruse
Master of Science Thesis MMK 2015:21 MDA 449 KTH Industrial Engineering and Management
Machine Design
SE-100 44 STOCKHOLM
Master of Science Thesis MMK 2015:21 MDA 449
Internet of Things
Definition, applications and comparison of wifi-based communication protocols for implementation of an
irrigation system
Emelie Bruse
Approved
2015-04-28
Examiner
Martin Grimheden
Supervisor
Bengt O Eriksson
Commissioner
KTH
Contact person
Bengt O Eriksson
Abstract
The aim of this thesis work has been to explore the state of the art of the Internet of Things, IoT.
Focus has been put on the role of communication protocols, or middleware, that enable communication between node and hub in the IoT architecture.
A literature study has been carried out, where the state of the art of the IoT has been studied. A comparison of six different pieces of middleware has been made, to use as a reference when choosing between communication protocols for a distributed system.
An irrigation system was to be implemented as an example application. It was implemented in the programming language Golang, using Websockets for communication between a standard laptop computer and a Raspberry Pi embedded sensor node.
The conclusion of this thesis is that the architecture, hardware and software design for IoT
systems all vary greatly depending on the specific demands of the application. Distributed
systems, having been used for decades in industrial applications, are now increasingly used in
many different fields. A wider adoption and expansion of a standardised and secure IoT has great
potential to leverage a moderate investment, increasing efficiency, security and quality of life
globally.
Examensarbete MMK 2015:21 MDA 449
Internet of Things
Definition, användningsfall och jämförelse av wifi- baserade kommunikationsprotokoll för
implementation av bevattningssystem
Emelie Bruse
Godkänt
2015-04-28
Examinator
Martin Grimheden
Handledare
Bengt O Eriksson
Uppdragsgivare
KTH
Kontaktperson
Bengt O Eriksson
Sammanfattning
Syftet med detta examensarbete har varit att utforska state of the art för Internet of Things (sakernas internet, IoT). Arbetet har till viss del fokuserats på de kommunikationsprotokoll som möjliggör kommunikation mellan nod och server.
En litteraturstudie har utförts, där referensramar har etablerats för IoT. Sex olika kommunikationsprotokoll har jämförts för att skapa ett underlag för design av IoT-system.
Ett bevattningssystem har utvecklats som ett exempelsystem. Det implementerades i programmeringsspråket Golang, och använder Websockets för kommunikation mellan en standardlaptop och en inbäddad Raspberry Pi-nod.
Slutsatsen av arbetet är att arkitektur, hårdvara och mjukvarudesign för IoT-system i hög grad
kommer bero av kraven som ställs av de olika användningsfallen. Distribuerade system har
använts inom industrin i decennier, men växer nu snabbt inom andra fält. Ett standardiserat och
säkert sakernas internet har potential att ge en hävstångseffekt, så att små investeringar kan ge
stora förbättringar av effektivitet, säkerhet och livskvalité.
Contents
Contents
1 Introduction 1
1.1 Background . . . 1
1.2 Purpose and definitions . . . 2
1.3 Implementation . . . 3
1.4 Delimitations . . . 5
1.5 Structure of this report . . . 5
2 Frame of reference: use cases and IP middleware for the IoT 7 2.1 Background . . . 7
2.2 Application examples . . . 8
2.2.1 Transport, logistics and infrastructure . . . 9
2.2.2 Healthcare . . . 10
2.2.3 Smart buildings . . . 12
2.2.4 Industrial applications . . . 13
2.2.5 Military applications . . . 13
2.2.6 Safety and disaster preparedness . . . 14
2.2.7 IoT in agricultural irrigation . . . 15
2.3 Components and architecture of the IoT . . . 17
2.3.1 Hardware . . . 17
2.3.2 Software . . . 18
2.4 Middleware for the IoT . . . 20
2.4.1 XML-RPC . . . 21
2.4.2 SOAP . . . 22
2.4.3 Websocket . . . 23
2.4.4 CORBA . . . 24
2.4.5 ZeroC/ICE . . . 25
2.4.6 DDS . . . 26
2.4.7 Evaluation and recommendations for choosing middleware . . 28
2.5 Technical issues and obstacles . . . 29
2.5.1 Physical and data link layers . . . 29
2.5.2 Network layer . . . 29
2.5.5 Application layer . . . 30
2.6 Security issues . . . 30
2.7 Research and standardisation bodies . . . 31
3 Implementation 33 3.1 Concept generation and evaluation . . . 33
3.2 Requirements . . . 33
3.2.1 Features . . . 33
3.2.2 Performance and technology . . . 34
3.2.3 Extended requirements . . . 35
3.2.4 User intervention . . . 35
3.3 Hardware and software development tools . . . 35
3.3.1 Hardware platform . . . 36
3.3.2 Software . . . 37
3.4 Software implementation details . . . 37
3.4.1 Using websocket in Go . . . 37
3.4.2 User interface . . . 39
3.4.3 Sensor node application . . . 40
3.4.4 Hub application . . . 41
3.5 Analysis and results . . . 41
4 Discussion 43 4.1 Research focus . . . 43
4.2 Features and behaviours of the implemented system . . . 43
4.3 Hardware and software choices . . . 43
4.4 Conclusions . . . 45
4.5 Future work . . . 46
Bibliography 49
Abbreviations
3G Third Generation mobile phone communication
6LoWPAN IPv6 over Low power Wireless Personal Area Networks API Application Programming Interface
ARM Advanced RISC Machines CDMA Code Division Multiple Access CeCP CORBA/e Compact Profile
CORBA Common Object Request Broker Architecture COTS commercial off-the-shelf
CPU Central Processing Unit CRUD Create, Read, Update, Delete DDS Data Distribution Service
EPCglobal Electronic Product Code global EPR Extended Producer Responsibility
ETSI European Telecommunications Standards Institute FPGA Field-Programmable Gate Array
GPIO General Purpose In Out
GSM Global System for Mobile communications HTTP Hyper Text Transfer Protocol
HTTPS HyperText Transfer Protocol Secure ICE Internet Communications Engine Ice-E Embedded ICE
IETF Internet Engineering Task Force IoT Internet of Things
IP Internet Protocol
IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 JSON JavaScript Object Notation M2M Machine to Machine
NFC Near Field Communication OS Operating System
OSI Open Systems Interconnection PAN Personal Area Network
PC Personal Computer QoS Quality of Service
REST Representational State Transfer RFID Radio Frequency Identification
ROLL Routing Over Low Power and Lossy networks RPC Remote Procedure Call
RTOS Real-Time Operating System SOAP Simple Object Access Protocol SRAM Static Random-Access Memory TCP Transmission Control Protocol UDP User Datagram Protocol
UMTS Universal Mobile Telecommunications System URL Uniform Resource Locator
USB Universal Serial Bus
WLAN Wireless Local Area Network
WPAN Wireless Personal Area Network WS WebSocket
WSN Wireless Sensor Node, or Wireless Sensor Network WSS WebSocket Secure
XML Extensible Markup Language
Chapter 1
Introduction
1.1 Background
The Internet of Things, IoT, is a term that describes the connection of previ- ously non-connected electronic devices or data sources (from here on referred to as ’nodes’), to each other, and/or to the Internet. Nodes range from passive tags and simple sensors and actuators, such as key tags, thermometers, valves, accelerom- eters, light switches or pulse meters, to complex systems such as smartphones, cars, or web Application Programming Interfaces, APIs.
Other components of the IoT are communication gateways and routers tying the nodes to each other or the internet (from here on these components will be referred to as ‘hubs’).
Customized Machine to Machine, M2M, solutions, often GSM-based, have been in practical use for decades. The idea of building mesh networks, using Zigbee [1], CDMA [2] et cetera, is not new either. The fact that these implementations have generally been tailored to fit a certain customer and situation ensures that they work well for their intended purpose.
The drawback is that they often follow a highly specialised architecture, and impose strict demands on node compliance. This makes it difficult and costly to incorporate new nodes, but also to interact with other systems or adapt the network to a new context.
Issues like the ones mentioned above initially drove this thesis work towards investigation of possibilities and limitations associated with the IoT. The results are summarised in chapter two, frame of reference.
The IoT is typically exemplified by a hypothetical generic framework for data transfer between nodes and a central hub (see Figure 1.1, 1.2 and 1.3).
This type of communication between nodes and hub requires agreed-upon stan- dards for communication medium, such as Zigbee, Wifi, Ethernet, GSM, or RFID [3], as well as middleware and data formats.
Diverse basic technologies needed to implement these types of solutions have ex- isted for a long time [4]. The challenge lies in incorporating heterogeneous hardware
Figure 1.1. Generic node with sensor and actuator
and software into a cohesive, flexible, resilient, reliable and secure product that also fulfils the specific demands of the intended use case.
1.2 Purpose and definitions
The topic of IoT was chosen since it is an immature but rapidly growing field. The goal was to get an inkling of the future of distributed sensor applications. The questions that this thesis set out to answer were:
’What is the state of the art of the IoT?’ ’What kind of communication protocol would be suitable for node-hub communication in such a system?’ and ’What could a simple, autonomous irrigation system with sensor feedback look like?’.
The answers to the first two can be found in chapter two, and the last one is explored in detail in chapter three.
Implementation of the irrigation system encompassed, among other things, selec- tion of a communication mechanism. Data needed to be exchanged between nodes and a central hub. Therefore, the thesis evaluates a number of relevant communica- tion protocols, or middleware, in the context of the type of distributed applications that are typical for the IoT. Application characteristics that determine suitability could be geographic distribution of nodes, reliability requirements and real-time demands. The chosen middleware represent a great range of complexity levels and mechanisms. The resulting comparison forms a large part of the scientific deliver-
1.3. IMPLEMENTATION
Figure 1.2. Generic system: hub with one node
ables for this thesis work. This material is meant to function as a reference when choosing between communication protocols for distributed applications. Based off of this comparison, the most suitable protocol for this specific implementation was chosen.
The system hardware components, sensors, embedded computers, routers and the like, should mainly be commercial off-the-shelf (COTS) products.
1.3 Implementation
One purpose of this thesis is to create a proof of concept for an irrigation system, consisting of at least one remote node and a hub (see Figure 1.4). The hub will exchange data with the node via Ethernet or wireless communication compliant with the IEEE 802.11 standard. The irrigation system will be designed for use in a private garden, public park or agriculture of a drought sensitive crop like lettuce.
This system would serve as an example application of the IoT.
The function of the system is autonomously optimising soil moisture levels while reducing water consumption. Keeping the soil from drying out too much between waterings is essential to ensure good cultivation results [5]. Drought sensitivity differs widely between crops, and can also vary between growth stages of a single crop. In case of a water shortage, it is important that correct priorities be made, or the yield of sensitive crops will decrease dramatically. While an irrigation system
controlled by a simple timer may be good enough to fulfil basic crop needs, such a system would likely waste water during cool and rainy periods, and it might still let the soil dry out too much when the weather is hot and dry.
Figure 1.4. Irrigation system flowchart
Closing the control loop by adding a moisture sensor will improve soil moisture stability considerably. The addition of an internet connection enables feed forward control based on weather forecast, which will save water by stopping irrigation if rain is expected in the near future. It also makes it possible to survey and control system status and behaviour remotely.
The implemented system will independently make irrigation decisions several times a day, based on the combination of time of day, input from soil moisture sensors, and weather data from a web API. The gathered data will be evaluated and weighted based on an algorithm input by the user.
The system should be autonomous, meaning that it should be able to operate and make decisions based on preset rules without user interference. It should also be able to adjust irrigation according to data gathered from different sources. These sources will, for the purposes of the prototype, be a moisture sensor and a weather forecast service.
The user interacts with the system through a web based interface, which presents the user with configuration options, such as setting threshold values for different parameters, as well as diagnostic and statistical system data. The user should also
1.4. DELIMITATIONS
be able to override the watering algorithm, turning watering on, or off, at any time.
1.4 Delimitations
The goal is limited to a frame-of-reference literature study of the IoT, a comparison of IP-based communication protocols or middleware, and one specific, non-generic implementation as a proof of concept.
The frame of reference is focused mainly on application examples and technical obstacles for the IoT.
The number of middleware in the comparison is limited to six. For a definition of middleware as used in this report, see section 2.4.
An important aspect of the subject is which requirements can reasonably be imposed on hardware, such as sensors and actuators, for example in terms of battery life, range, reliability, response time, and precision. This is excluded from the scope of the implemented system.
No mechanics or specific node hardware are included, aside from the Raspberry Pi embedded computer and Wifi antenna.
The software developed for the prototype supports only one sensor/actuator node. The system could be implemented with an arbitrary number of nodes. This would require some changes to the user interface and the part of the code that handles hub-node communication.
There are other delimitations of the implemented system regarding reliability guarantees, encryption (of the communication between node and hub, as well as between the hub and the internet), error handling, and redundancy.
1.5 Structure of this report
The report is divided into four chapters. The first chapter, Introduction, is followed by a Frame of reference chapter, chapter two, discussing technical and safety issues, possible architectures and application examples of the IoT. This chapter also in- cludes a comparison of six different communication protocols, as well as the state of the art of networked irrigation systems. Chapter three describes the practical implementation of such an irrigation system, along with analysis and results. The fourth chapter of the report, Discussion, provides answers for the research ques- tions, and details the results of the implementation work. The achievements and conclusions of the thesis work are summarised, and suggestions are given for future work in the field.
Figure 1.3. Generic system: hub with several nodes
Chapter 2
Frame of reference: use cases and IP middleware for the IoT
2.1 Background
Computers have been connected to each other for many years through the internet.
The next step in this direction involves objects (things) around us that have not previously been able to communicate remotely. The Internet of Things (IoT) is a concept that involves the connection of various devices to each other, and/or to the Internet. These devices will be referred to as nodes. A node can be a simple sensor or actuator, such as a thermometer, valve, accelerometer, light switch or pulse meter, or even an RFID, Radio Frequency ID, tag. Node can also refer to a complex system such as a smartphone, car, or web API.
Other architectural elements of the IoT are communication gateways and routers tying the nodes to each other and to the internet. These components will be referred to as hubs, see Figure 1.2.
The term IoT was introduced in 1999 by Kevin Ashton [6]. It is closely related to the pre-existing concept of Machine-To-Machine (M2M), which could be seen as a subset of IoT. Often, the terms IoT and M2M are used interchangeably [7].
However, when M2M first appeared decades ago [7], it was mainly in the context of industrial applications, whereas the IoT has conceivable applications in virtually every field.
M2M systems are usually
• Based on wired communication or cellular networks
• Used in industrial contexts
• Connected to a hub, but not to the internet
1http://www.kpcb.com/blog/how-kleiner-perkins-invests-in-the-internet-of-things-picking-the- winners
2http://www.capgemini.com/blog/capping-it-off/2014/02/things-on-the-internet-to-the- internet-of-things
Figure 2.1. IoT illustration1
IoT systems are typically
• Geared towards flexibility, scalability and usability
• Based on IP communication
• Integrated into other systems online
• Hardware platform agnostic, allowing for low-power, or even passive sensors
2.2 Application examples
IoT solutions are currently largely employed, and growing, in areas like smart build- ings, transport and infrastructure, industry, healthcare, safety and preparedness, and the military. Applying the IoT in relevant fields could vastly improve safety
2.2. APPLICATION EXAMPLES
Figure 2.2. An example of IoT architecture2
and health for people all over the world. Many of these systems will, at least in the near future, be attainable only for inhabitants of developed countries and for the wealthy. However, there are applications which could be used to leverage limited resources in order to save lives and decrease suffering of people in the developing world. Examples are basic health monitoring and natural disaster warning systems, infrastructural elements where a relatively minor investment could help many.
There are also considerable economic gains that come with increased efficiency in fields like industry, transport, healthcare and agriculture.
2.2.1 Transport, logistics and infrastructure
In the field of assisted driving (see Figure 2.3), smart, sensing, interconnected vehi- cles and roads could minimize collision risks and enable smoother traffic planning and flow [3]. IoT in transport will enable dynamic control of origin-destination route choice behavior for optimal traffic flow through an area [8]. It is also likely that IoT type solutions will take the place of existing sensor systems at light-controlled traffic intersections [8]. At present, the standard solution involves inductive loop vehicle detectors that keep track of approaching traffic and transmit the data only to the closest stop light via wired communication. Data exchanged between all intersections in an area could allow better decisions and decrease traffic congestion.
IoT might also be used for improved efficiency of the food supply chain. Keeping track of parameters like temperature and humidity during transport will help in
3http://www.driverlesstransportation.com/wp-content/uploads/2014/12/20110620_ITSDOT_0375_HIR.jpg
Figure 2.3. Smart traffic illustration3
assessing and preserving the freshness of sensitive goods like fruit, dairy, and meat [3].
IoT systems also find increasing application in reliable supply and quality control of drinking water. This is achieved through interconnected sensors at critical points, for example where contaminated water might flood drinking water reserves [8].
Smart grid is a new term in the context of M2M. When applied in power manage- ment, the grid assesses power consumption patterns through interconnected smart meters, and regulates production and distribution accordingly. Peaks in power us- age can be cut by suggesting suitable times to run appliances, encouraged by power providers using dynamic pricing models [9]. Three task forces are currently devel- oping IEEE P2030 SG (Smart Grid) standards for power engineering, information and technologies [9]. The technology is already in use for load balancing of energy grids [8].
2.2.2 Healthcare
In a near future, IoT systems in hospitals are likely to enhance identification and flow of patients, scheduling of physicians and procedures and inventory tracking [3]. Dynamic medical records, vital sign and status monitoring and centralised dosage control will lead to improved patient safety [3] and treatment efficiency.
These strategies could be used to improve and extend healthcare reach in developing countries, making the most of strictly limited resources.
4http://vertassets.blob.core.windows.net/image/4f1cdc06/4f1cdc06-a44f-4748-9de9- 0a87208761b8/iot_healthcareimage.jpg
2.2. APPLICATION EXAMPLES
Figure 2.4. IoT in healthcare illustration4
It is estimated that the mortality from complications due to pregnancy or child- birth is about 2.5 percent worldwide, and in some countries it is the cause of death for as many as one in seven women. Furthermore, many preventable deaths in these areas are caused by different forms of cancer, which are often curable if they are found in time. Rohokale et al [10] propose a cooperative multi-hop model for sen- sor communication in areas that lack both a local hospital and a reliable internet connection [10]. Multi-hop, in this context, means that data is relayed via one or several identical nodes towards a sink node, which is internet connected and makes data available for remote viewing by a physician. In this scenario, each patient has a personal sensor node periodically measuring parameters like blood pressure and blood glucose levels. Based on this data, the physician can quickly and efficiently screen a large number of patients and make informed decisions concerning follow-up and care.
Outside of the hospital, internet connected sensor networks might improve re- sponse times to health events like stroke or heart attack, where timing is critical if the patient is to survive [9]. Even for less acute conditions, it could be possible to decrease human suffering along with healthcare costs by suggesting adequate preventive care based on sensor readings.
To enable physicians to monitor patients’ health status remotely in order to get continuity between visits , BANs, Body Area Networks, are being developed [9].
A BAN could be incorporated into a smart watch or a piece of clothing, or even embedded under the patient’s skin.
2.2.3 Smart buildings
Figure 2.5. Smart home illustration5
Homes and offices will likely be equipped with more advanced networked sensor systems, see Figure 2.5. These could help inhabitants with anything from keeping track of RFID tagged personal items, like glasses and keys, to warning people and authorities in case of fire or burglary [11].
The smart home or office could track and optimise factors like temperature, air quality and humidity, in living spaces as well as storage spaces and refrigerators.
Tagged groceries could communicate their respective contents, expiration dates, and amounts, and suggest shopping lists along with recipes to reduce waste. [3] [12]
Creativity, productivity and comfort could be boosted by creating quiet zones using active noise cancellation.
Museums are another category where benefits could be reaped from automated sensing and control. Here, IoT could be used for stabilising of environmental pa- rameters, and for security surveillance, around sensitive and precious pieces [3].
5http://www.mit.edu/~georgios/figures/iot.jpg
2.2. APPLICATION EXAMPLES
2.2.4 Industrial applications
Figure 2.6. Industrial IoT illustration6
In production industry, while M2M solutions have been used for some time, IoT could add more extensive real-time monitoring possibilities as costs, and sizes, of sensors and tags drop. Following the flow through every link in the supply chain, from raw materials to finished product, enables traceability of individual goods and shorter response times to market events [3]. Aside from shorter lead times, tracking of every part might also give insight into workflow inefficiencies and shed light on causes for quality issues.
Examples of factors that can be monitored include torque and vibrations, which can reveal a need for maintenance (e.g. modification of intervals between lubrica- tions and changing of tool tips), as well as timing factors that can improve through- put and utilisation for a bottleneck in a production chain.
Another area where there is room for improvement is sustainability. Recy- cling will be easier and more efficient if complex products are equipped with RFID tags detailing the materials in them. Extended Producer Responsibility (EPR) is an environmental policy approach formulated by the Organisation for Economic Co-operation and Development (OECD), where manufacturers are assigned more responsibility for handling their products at the end of their life span7. Traceability through RFID tags would help in the enforcement of EPR policies.
2.2.5 Military applications
The US Army uses an IoT system aiming to give an overview of friendly troops and decrease the risk of friendly fire in chaotic battle situations. The GPS-based system
6http://www.iebmedia.com/images/art_images/IEB76_p32_35_2.jpg
7http://www.oecd.org/env/tools-evaluation/extendedproducerresponsibility.htm
8http://www.mpdigest.com/issue/Articles/2015/Jan/adi/fig1.jpg
Figure 2.7. IoT in the military illustration8
is called Blue Force Tracker (BFT) and is mainly used for tracking of units and individual soldiers [9]. It can also be used for communication via text messages, and for tracking materials in the battle field supply chain, the last steps of which are otherwise very inefficient and costly due to rapidly changing locations and needs [13].
Future Force Warrior is a related project which also measures and communicates the biometric status of the soldiers, for example body and skin temperature and hydration [9] (for an illustration, see Figure 2.7).
IoT/M2M systems are also thought to become useful for the military within the fields of automated border surveillance and vehicle diagnostics and maintenance [9].
2.2.6 Safety and disaster preparedness
Distributed sensor systems could give warnings in real-time for natural catastrophes like tsunamis (see Figure 2.8), earthquakes, floods, volcanic eruptions and forest fires.
The remote sensor readings that IoT systems make possible can provide eas- ier access to various types of measurements from inhospitable environments, where it would not be safe or practical to send a human observer. Some examples are
9http://newsimg.bbc.co.uk/media/images/40740000/gif/_40740353_warningsystem.gif
2.2. APPLICATION EXAMPLES
Figure 2.8. IoT tsunami warning illustration9
pollution levels and wildlife counts on the ocean floor and in remote areas, or mon- itoring of radiation levels in and around failed nuclear reactors. After the tsunami and subsequent nuclear plant disaster in Fukushima, Japan 2011, a few different sensor networks have been set up to monitor variation of radiation levels around the country [14]. The idea is to overlay a map with a mesh of frequently updated radiation measurements, allowing authorities, residents and others to monitor local fluctuations in radiation levels, and their development over time.
Video enabled IoT is another field where great strides are expected to be taken in the next decade [8]. This technology could be used for security surveillance.
2.2.7 IoT in agricultural irrigation
Wireless sensor systems are not currently widely used for agricultural irrigation (see Figure 2.9), but several such systems have been studied and deemed promising [15]
[8]. An estimated 70 percent of freshwater in the world is used for agriculture [15].
A growing population puts increasing demands on crop yield, consequently urging a more rational use of water.
Irrigation has been used for thousands of years, the earliest evidence showing water basins being used for irrigation in Egypt and Mesopotamia around 6000 b.c.
Automatic control has revolutionised almost all engineering fields, but it has not
10http://media.ofcom.org.uk/files/2015/smart-irrigation.gif
Figure 2.9. IoT irrigation illustration10
yet had a corresponding impact on the field of agriculture [15]. Simple automated irrigation systems use open loop control, simply dispensing a set amount of water per square metre and day. This approach may yield acceptable results in terms of crop growth, but is likely less than optimal and may lead to a waste of freshwater, which is drained away.
The open loop irrigation can be improved upon by implementing sensors that close the feedback loop, for example soil moisture sensors. Continuous advances in wireless technology facilitate this shift. Zigbee is a popular wireless standard, which, due to its relatively low power consumption, enables sensors to run on solar or battery power.
Several commercial irrigation systems exist, which work with thresholds for the feedback signal and on-off control. They do potentially save water compared to timer based systems, provided that the thresholds are suitably set. Even more water can be conserved if a rain sensor is implemented alongside the soil moisture sensor [15] [16]. This is the basic approach chosen for the present implementation work described in the next chapter, with the addition that rainfall probability for the next 24 hours will also be taken into account in the watering decision.
Parameters that could be used for an even more precisely targeted control strat- egy include plant measurements, such as sap flow, tissue water status, dendrometry, and stomatal conductance. These are promising, although there are practical hur- dles to overcome [15].
There are a handful of mathematical models, developed between the years of 1989 to 2004, for water dynamics in the soil-plant-air system and crop yield. These models make it possible to simulate control strategies before applying them in the
2.3. COMPONENTS AND ARCHITECTURE OF THE IOT
field.
Romero et al [15] describe how they implemented and compared two strategies, one model based, and one PID controller. The results of the simulations were adequate for both systems, however the model based strategy proved superior in terms of following the reference. This effect was especially visible after predicted heavy precipitation.
2.3 Components and architecture of the IoT
2.3.1 Hardware
The nodes of the IoT can be divided into two groups: active sensor and/or actuator nodes, most commonly wireless, and passive nodes, like standard RFID tags.
Active wireless nodes generally consist of sensors, actuators, interfaces (typi- cally A/D converters [8]), power supply, an embedded processor and communication hardware.
RFID comes in two varieties - passive and semi-passive. The passive tag can easily be added to virtually any product, and has functionality equivalent to that of a barcode. It is powered only by the energy from the radio signal transmitted by the reader. Passive RFID tags require a reader close by (the range is typically measured in centimetres), since the reply signal transmitted by the chip is very faint. It can be packaged as an adhesive sticker, or enveloped in plastic for applications like keys and access cards.
Semi-passive RFID units have some measure of internal power supply, which enables longer range and processing capabilities. These fit better, functionality-wise, in the wireless sensor node category, as they are not strictly passive. NFC, or Near Field Communication, is a growing technology, with similar functioning and uses to RFID. The range is even shorter, often to the point of requiring that transmitter and receiver physically touch. Many newer smartphones are NFC enabled.
Smart phones represent the powerful end of the node spectrum, and are easy to incorporate in IoT systems as nodes, or even as hubs. They generally contain several sensors and are easy to connect directly to the internet, either over the cellphone network, or via an IEEE 802.11 [17] compatible access point. In addition, they can usually connect via bluetooth or even NFC to other phones, or a hub.
The major drawbacks are that phones are unnecessarily complex and powerful, and therefore expensive, to use as a simple sensor node, and that they are not optimised for energy efficiency.
Power supply
Wireless technologies, as a rule, require considerable amounts of power [12], and this is especially true for WLAN. Wifi chip current is constant, rather than proportional to data throughput [12]. Also, the peak current is higher than a typical coin battery can supply [12].
Energy consumption in this context tends to be measured in power per bit [12].
A lot of research has gone into energy efficient communication schemes [8]. Alterna- tives for power supply in wireless sensor nodes are using disposable or rechargeable batteries, and the latter could be used in combination with energy harvesting mech- anisms, for example solar cell arrays [12].
Power over ethernet, where the ethernet wire is used both for data transfer and as a power source [18], is another possibility which could be useful for applications like routers, cameras streaming video, and point-of-sale systems (i.e. cash registers).
Power line communication (PLC) is sometimes used in the context of IoT, no- tably in power grid applications [12] [19]. IEEE 1901 is one of the standards for this type of communication. The node is connected to the power grid, and the communication signal is superpositioned over the supply voltage.
2.3.2 Software
Ad-hoc, or spontaneous, deployment of nodes is the most common approach [8], and control of routing and the MAC layer is vital for scalability and robustness of the network. Regardless of node-to-node and node-to-hub communication style, the hub would typically need an internet compatible communication stack in order to function as a gateway between the local network and the internet [8].
The communication requirements for a given system differ depending on com- munication characteristics, like frequency and size of typical messages, and how critical and/or timing sensitive the application is.
For a comparison of middleware for the IoT, see section 4 of this chapter.
Physical and data link layers
Wireless communication typically involves radio communication standards with sub- groups, like WPAN (e.g. Zigbee and Bluetooth), WLAN (e.g. Wifi) and various cellular technologies.
Wireless Personal Area Networks (WPAN or just PAN), like Zigbee, Bluetooth, or 6LoWPAN, follow the 802.15 standard. The range is shorter than for WLAN, but the power consumption can be several orders of magnitude smaller in applications with low data rates.
Most of the wireless sensor nodes on the market today are based on 802.15.4, a standard for low speed, energy conserving wireless communication [3]. The standard defines only the physical and MAC layers [3].
Wireless local area networks (WLAN), like Wifi, based on the 802.11 standard, are convenient because of compatibility with existing networks. WLAN communi- cation is not as energy efficient as GSM or 802.15. WLAN was developed with a standard internet architecture in mind, where powerful devices, plugged in to wall sockets, share what is in this context to be considered as very large amounts of data.
2.3. COMPONENTS AND ARCHITECTURE OF THE IOT
Mobile cellular network technologies, like GSM, have been a popular choice for M2M communication in industrial settings. CDMA and UMTS (third generation of mobile network technology) are also in this category.
Network layer
Internet Protocol (IPv4 and IPv6) is used for routing and identification of devices on the internet. 6LoWPAN, short for IPv6 over low power wireless personal area networks, is a version of IPv6 developed with the IoT in mind. 6LoWPAN based IoT networks are currently used in many different projects aimed towards areas like optimisation of waste management, livestock monitoring and home automation [20].
Transport and session layers
TCP and UDP are the most commonly used technologies for use on top of IP, but there are several other alternatives. They provide an abstraction layer that makes it possible for applications to communicate in larger chunks than IP allows.
UDP or equivalent protocol will be a better fit for the typical low bitrate, energy efficient IoT applications. It is connectionless, and has low latency and message overhead. However, for applications which require security or with larger amounts of data, like video streaming [21], TCP might be better suited.
Presentation layer
This layer is exemplified by HTTP, REST, JSON, msgbus, SOAP, et cetera. For this level, there are hundreds of communication protocols/middlewares to choose from.
Application layer
Applications will need to have very different features, depending on whether the main objective is smooth streaming of large data or, in the opposite end of the spectrum, shaving off nanowatts from the average energy consumption.
Computing power and memory resources at sensor node level varies from close to none in passive or very low-power devices, to arbitrarily large amounts. The low- powered devices are therefore limited to small amounts of resource efficient code expressed in low-level languages, while nodes on the other end of the spectrum can handle, independently process, and act upon large amounts of data and complex code, expressed in any language.
Along with access to massive amounts of raw data come the challenges of making sense - and use - of it. Data mining and handling strategies will be needed for larger systems that gather lots of data. The data should typically be accessible from multiple platforms, and presented and refined in such a way that it is easy for users to digest and interpret.
2.4 Middleware for the IoT
Figure 2.10. OSI model illustration11
Middleware is needed in the IoT in order for heterogeneous components to form a cohesive whole [22]. The types of middleware reviewed in this section provide an API, Application Programming Interface, for the transport layer and add the levels of abstraction needed between that and the application. This enables a degree of modularity which potentially brings systems closer to plug-and-play. For an illustration of the layers of abstraction in a TCP communication stack, see Figure 2.11.
The choice of middleware partly defines the application. A limited feature set means limited liberties for the programmer while designing the system. On the other hand, ease of use is a relevant factor, especially in a smaller project and/or where a developer might have to put a lot of time into learning a specific protocol.
Middleware demands on memory, OS, and CPU capacity also need to be considered in relation to the corresponding hardware, as incompatibilities between protocol
11http://gargasz.info/wp-content/uploads/2010/01/OSI_model_LAN.jpg
12http://what-when-how.com/data-communications-and-networking/network-and-transport- layers-data-communications-and-networking/
2.4. MIDDLEWARE FOR THE IOT
Figure 2.11. Illustration of the levels of abstraction in a TCP based commu- nication stack12
and certain types of hardware or software architectures might disqualify a protocol right off the bat. For any safety critical system, reliability, real-time properties and guarantees built in to a given protocol will be the highest priority, before complexity and cost. Middleware licenses range from free under Creative Commons [23] to quite costly. Six protocols was studied in detail, namely XML-RPC, SOAP, Websocket, ZeroC/ICE, CORBA and DDS. Websocket was used for implementation of the irrigation system described in the following chapter, mostly due to ease of use, programming language compatibility (Golang) and the full-duplex communication capabilities.
2.4.1 XML-RPC
XML-RPC fits into the application layer (layer seven) of the OSI model (Open Systems Interconnection, see Figure 2.10), and provides an interface between web services and clients. First developed in 1998, it is the predecessor to SOAP, Simple
Object Access Protocol, which will be discussed in the next section.
The acronym XML-RPC stands for Extensible Markup Language – Remote Procedure Call. As the name implies, it uses XML encoding for messages, which are then sent using HTTP, Hyper Text Transfer Protocol. This means that XML- RPC requires an HTTP stack.
The MinML-RPC implementation uses 512 kilobytes of RAM13.
XML-RPC is simpler to get started with than SOAP, since it has less encod- ing and security options and does not support WSDL (Web Services Description Language) [24]. As a result it is also limited in terms of functionality. As a compar- ison, XML-RPC is somewhat more complex than using the Representational State Transfer, REST, architecture. REST or similar architectures could therefore be preferable for simple CRUD (Create, Read, Update, Delete) operations.
XML-RPC provides reliable, synchronous communication, and has support for a plethora of programming languages. However, it uses about four times the amount of bytes for encoding an object compared to plain XML, which in turn, unless compressed, uses significantly more memory than for example JavaScript Object Notation (JSON).
2.4.2 SOAP
Like its predecessor, XML-RPC, SOAP belongs in the OSI application layer. It was designed in 1998 by a team at Microsoft.
SOAP stands for Simple Object Access Protocol, and is a standard mostly used within web services for sending messages over HTTP port 80. The SOAP standard is defined by the World Wide Web Consortium, W3C. SOAP follows a client-server architecture, and works as the interface between web services and clients.
SOAP converts data to XML, which is quite verbose, before transmission. It uses application layer protocols, such as Hyper Text Transfer Protocol, HTTP, Simple Mail Transfer Protocol (SMTP), Transmission Control Protocol (TCP) or Java Message Service (JMS) for message transmission. HTTP is the most widely used, since SOAP is mostly used for web services, where HTTP communication is the standard.
SOAP is more lightweight and easier to set up than CORBA, but more complex than for example XML-RPC. It is operating system and language independent, and there are many libraries for different languages. Implementations exist, like RomXOAP Embedded Toolkit, which claim to work on any 16-, 32-, or 64-bit pro- cessor, regardless of OS, TCP/IP stack and file system14. The lightweight gSOAP15 implementation has a 150 kilobyte total memory footprint.
SOAP is generally firewall compatible. It is well documented, widely used and time proven, and there is a lot of information about it available online.
13http://www.xml.com/pub/r/371 2015-03-18
14http://www.allegrosoft.com/embedded-soap 2013-06-28
15http://www.cs.fsu.edu/~engelen/cases03.html#tth_sEc4 2015-03-21
2.4. MIDDLEWARE FOR THE IOT
Soap would not be an option for real-time applications, due to limitations in speed and dependability. Message delivery using HTTP is best-effort, which means there is no guarantee that a given piece of data will be received. SOAP does not support transactions.
The downside to the firewall compatibility of SOAP over HTTP is that there is more room for errors leading to security breaches, compared to CORBA for example. When using SOAP, security needs to be implemented on the application level in order to obtain a satisfactory result16.
Source-code portability between SOAP implementation vendors is poor, with the exception of Java implementations, for which SOAP has a predefined language mapping.
2.4.3 Websocket
Websocket corresponds to the OSI session layer (layer five). It is a connection- oriented socket protocol, which provides a two-way communication channel via Transmission Control Protocol, TCP, connection. Websocket message parsing adds a layer of abstraction to TCP, which only transmits a stream of bytes. Websocket is HTTP compatible, in that it has a compatible handshake protocol, which allows socket connections to share a port with an HTTP web server. The HTTP server is not involved in the websocket communication beyond the initial handshake.
Websocket was standardised by the Internet Engineering Task Force, IETF, in 2011, as an alternative to the HTTP mechanisms of polling, long polling and streaming for providing full-duplex communication. Predecessors to Websocket, i.e.
protocols for achieving full-duplex communication on port 80, include a number of different technologies under the umbrella term Comet, also known as HTTP streaming, as well as a handful of other names. Websocket generally provides easier implementation and less HTTP header overhead than these techniques.
WebSocket Secure,WSS, is an encryption enabled version of WebSocket, analo- gous with the HyperText Transfer Protocol Secure, HTTPS.
The symmetrical bidirectionality of the websocket connection means that it lends itself to applications which have frequent traffic that does not necessarily conform to the request-reply or publish-subscribe formats. As an example, websocket con- nections are often used for continuous server-client communication in online com- munities and games with frequent updating and/or real-time requirements17.
Getting started is comparable to setting up an HTTP web server and client18. There are a number of server and client implementations. However, far from all implementations provide both server and client functionality. Though the subse- quent communication will be symmetrical, the server-client distinction is necessary while establishing a connection.
16http://searchsoa.techtarget.com/answer/Are-there-any-security-problems-related-to-SOAP 2013-06-28
17http://www.websocket.org/demos.html , http://demo.kaazing.com/livefeed/ 2013-06-28
18http://wickedlysmart.com/getting-started-with-html5s-web-sockets/ 2013-06-28
There are implementations specifically targeted at embedded devices19, like cWebsocket20, which can run on an Arduino, placing its memory footprint in the range smaller than 32 kilobytes.
Websocket allows for immediate updating without polling, and has less band- width overhead than HTTP (bytes rather than kilobytes)21. It also has lower latency compared to HTTP, as there is no need to establish a new connection before each message.
The technology is somewhat immature and untested. For example, there is a risk that security holes in Websockets communication could be exploited by hack- ers. Most firewall vendors have not addressed any of the potential security issues pertaining to Websockets, since it is relatively new and not nearly as commonly used as HTTP22.
Websocket has no automatic timeout discovery. Hence, it might not be the best choice for applications with unreliable connections. Keep-alive messages have to be sent if the traffic is low to prevent an idle timeout.
In order to guarantee reliability, the system would have to be implemented to send an acknowledge message for each received message, which would increase bandwidth usage23.
2.4.4 CORBA
CORBA covers the session, presentation and application layers of the OSI model (layers 5-7) [25].
CORBA, Common Object Request Broker Architecture, emerged in the mid 1990s, and was one of the first standardised pieces of middleware for distributed sys- tems. The communication typically follows a client-server architecture, but CORBA does have publish-subscribe features as well24.
CORBA is widely used today, due in part to its getting a relatively early start.
It is used in a wide array of applications, which are often safety critical, such as 3G base stations (third generation mobile phone communication), banking, air traffic control, defence and aerospace programs (e.g. the Hubble space telescope), research, healthcare, robotics, data storage, and measurement systems.
CORBA is generally considered complex25, and the learning curve is very steep for new users26.
19https://github.com/m8rge/cwebsocket 2013-06-28
20https://code.google.com/p/cwebsocket/ 2015-03-15
21http://www.slideshare.net/ffdead/the-html5-websocket-api 2013-06-28
22 (http://www.esecurityplanet.com/browser-security/html5-websockets-identified-as-security- risk.html , http://www.infoq.com/news/2012/03/websockets-security 2013-06-28)
23(http://blog.kaazing.com/2012/02/28/html5-websocket-security-is-strong/ 2013-06-28)
24 (http://www.ciaranmchale.com/corba-explained-simply/publish-and-subscribe-services.html 2013-06-28)
25(http://queue.acm.org/detail.cfm?id=1142044 , http://ovir.icp.ac.ru/corba/books/Teach14/ch01/ch01.htm http://www.field-theory.org/articles/corba/ 2013-06-28)
26(http://queue.acm.org/detail.cfm?id=1142044 2013-06-28)
2.4. MIDDLEWARE FOR THE IOT
CORBA transmits data via the Internet InterORB Protocol (IIOP) through TCP/IP connections.
CORBA was designed with a high degree of language and OS independence in mind. Many programming languages are currently supported by a number of CORBA vendors, Java being the most popular. Other supported languages are C++, C, SmallTalk, Python, Perl and Ruby, and many more. There exists a reduced-footprint version of the CORBA standard, called CORBA/e Compact Pro- file (from here on called CeCP, where the ’e’ stands for embedded). There are several implementations of CeCP which can provide real-time, deterministic execution of communication or signal processing on a standard 32-bit microcontroller equipped with a Real-Time Operating System, or RTOS. The CORBA/e Micro Profile is an even smaller standard, which does not, however, feature real-time support27.
Its strengths are best used in large, complex systems distributed over different platforms (operating systems as well as hardware) and written in different pro- gramming languages. CORBA can provide security and high performance, but as an effect of its multitude of features, there would be a disproportionate amount of overhead in smaller, non-safety-critical projects. A system comprised of a single computer, or limited to a single OS, would probably benefit from a more lightweight communication standard. A lack of experienced CORBA developers within the project may be another disincentive to choosing the protocol.
CORBA gives low bandwidth use, compared to SOAP, for example, thanks to efficient data marshalling. It is well documented, time-proven and secure28. Other advantages include transaction support, persistence and location transparency. Im- plementations compliant with the RT-CORBA (Real Time CORBA) standard pro- vide hard real-time support. The lightweight version CORBA/e has a minimum memory footprint in the range of tens of kilobytes29.
ORBexpress is a CORBA implementation from OIS, that has a real-time version, as well as one that can be run on FPGA hardware (Field-Programmable Gate Array)30.
2.4.5 ZeroC/ICE
Like CORBA, the Internet Communications Engine, ICE, spans the OSI levels 5-7, i.e. session layer, presentation layer and application layer.
ICE is a modern, object oriented protocol and API library, supporting multiple modes of communication. It was developed at ZeroC in 2003 by some of the original CORBA developers31. The design was influenced by CORBA, but ICEis much more lightweight32.
27 http://www.rtcmagazine.com/articles/view/100752 , http://www.corba.org/corba-e/ 2013- 06-28
28http://docs.oracle.com/cd/E13203_01/tuxedo/tux80/security/overview.htm 2013-06-28
29http://www.corba.org/corba-e/ 2015-02-15
30http://www.ois.com/Products/communications-middleware.html 2013-06-28
31http://www.zeroc.com/documents/ieee.pdf
32http://doc.zeroc.com/display/Ice/Ice+Architecture 2013-06-28
Like CORBA, ICE works well with heterogeneous node networks, where appli- cations run on different operating systems, and are implemented in different pro- gramming languages33. It uses Remote Procedure Call, RPC, and follows a publish- subscribe model of communication. ICE communication can be bidirectional, as the server can send a callback message over the original connection created by the client.
This feature is useful when traversing a firewall that is set to only accept outgoing connections34.
ICE is used within areas like healthcare, research, robotics, traffic information, access control and surveillance, real-time process control, banking and trading35.
Setup is relatively simple and well documented for Windows, Linux, OS X, and Solaris. ICE also works on Android 2.3 or later. The embedded version, Ice-E, works on Windows Mobile 6 Professional as well as some versions of Windows and Linux36. ICE has language mappings for C++, C#, Java, Python, and Objective-C.
On the client side, PHP and Ruby are supported.
It is well documented37, but there is little material about ICE online from other sources than ZeroC. It performs well in terms of round trip latency, scalability and overhead generation compared to CORBA and .NET38.
The required memory size for an ICE implementation is a few hundred kilo- bytes39.
With exception of Ice-E, it supports SSL, IPv4 and IPv6. Ice-E supports only IPv4. Ice-E provides real-time support, while standard ICE does not.
The IceGrid version of ICE has grid computing support. ICE is licensed under the GNU GPL (GNU’s Not Unix General Public License), but is controlled by ZeroC.
2.4.6 DDS
Data Distribution Service, DDS, was developed specifically for distributed embed- ded systems and covers OSI levels four through seven. The first version of the specification was approved by the Object Management Group, OMG, in 2003.
DDS lies between the application and the operating system within each node in a distributed system, where it provides an application programming interface, API, for data-centric publish-subscribe, DCPS, with highly configurable levels of quality of service, QoS. DDS avoids having a single point-of-failure by substituting the frequently used message broker architecture with a system where each publisher and subscriber shares meta-data about every other node in the network.
33http://doc.zeroc.com/display/Ice/Ice+Architecture 2013-06-28
34http://doc.zeroc.com/display/Ice/Overview+of+the+Ice+Protocol 2013-06-28
35http://www.zeroc.com/customers.html 2013-06-28
36http://www.zeroc.com/icee/platforms.html 2013-07-04
37http://doc.zeroc.com/display/Ice/Ice+Manual 2013-06-28
38http://www.ijcaonline.org/volume3/number11/pxc3871105.pdf, http://www.zeroc.com/documents/ieee.pdf 2013-06-28
39 https://www.zeroc.com/forums/help-center/1720-all-right-ice-hello-demo-such-size-memory- usage.html 2015-02-20
2.4. MIDDLEWARE FOR THE IOT
DDS nodes can also be used within one single process, for communication be- tween threads. The process could be running on one computer, or distributed over several different ones40.
DDS is mainly used for distributed systems with strict QoS requirements. There is less setup needed than for client-server solutions in complex systems, and DDS scales well with the number of devices. Automatic failover is easy to implement, since all communication is peer-to-peer.
DDS is most commonly used with UDP/IP41, but it works with various transport mechanisms, including shared memory and specialised, non-IP networking technolo- gies like InfiniBand and StarFabric42.
MicroDDS is the smallest footprint implementation43, which is possible to im- plement on 8-bit microcontrollers with 2 kilobytes static random-access memory (SRAM) and 32 kilobytes read-only memory (ROM). Only publishing (not sub- scribing) is supported by MicroDDS. RTI Connext Micro works on embedded 16-bit ARM microcontrollers, and provides baseline publish-subscribe functionality. How- ever, most implementations are intended for systems with pentium-class CPUs and memory in the hundreds of kilobytes or more. The lightweight implementations can run without an OS, while the others support an array of operating systems. In most cases this includes at least Linux, Windows and VxWorks.
DDS is not well suited for synchronous communication, request-reply services and file transfer. It has limited support for transactions44.
Developers are given the possibility to control, on a per-message basis, configu- ration and QoS parameters for transmission as well as reception of messages. There are 22 QoS parameters available controlling, among other things, data availability, delivery, timeliness and resource consumption.
DDS is geared towards efficient bandwidth utilisation, and has fewer features and low overhead in the main request path compared to middleware like CORBA. DDS is dynamically scalable and flexible, meaning that new network nodes with different roles, as well as new message types, may be added or removed in runtime. The communication can be one-to-one, one-to-many, many-to-one, and many-to-many, and DDS allows for configuring different nodes to have different subscription rates.
This means that variation in connection speeds between nodes does not generally pose a problem.
Many implementations don’t cover the entire spec, and information on exact coverage is sparse. Most implementations are poorly documented. As of now, two open source implementations exist; OpenSplice DDS and OpenDDS. Interoperabil- ity between different implementations has been an issue in the past, but this seems
40 http://www.omgwiki.org/dds/sites/default/files/DDS_Architectural_Overview.pdf 2013- 06-28
41http://blogs.rti.com/2011/03/30/tcp-transport-for-dds/ 2013-11-25
42http://www.rtcmagazine.com/articles/view/100492 2013-06-28
43http://www.icoup-consulting.com/microdds.html 2013-06-28
44 http://portals.omg.org/dds/sites/default/files/Comparison_of_DDS_and_JMS.pdf, p28, 2013-06-28
to have been mostly resolved45.
2.4.7 Evaluation and recommendations for choosing middleware
For applications with hard real-time requirements, for example in the medical and industrial sectors, CORBA and DDS are the only suitable candidates out of the six protocols that have been studied. They both give real-time guarantees and offer fine-grained control over quality of service parameters. For comparison, Websocket has no real-time guarantees, but is often used for example in timing sensitive online games thanks to efficient, symmetrical communication that bypasses the typical request-reply communication structure.
QoS for the four protocols lacking real-time guarantees, that is XML-RPC, SOAP, Websocket and ICE, is determined by the guarantees built into the under- lying transport mechanism, TCP being the most common.
The major drawback of CORBA and DDS is their complexity. In addition, DDS documentation online is scarce. For CORBA, there are a myriad implementations, and the majority don’t cover all the functionality described in the standard, and it is not a trivial task to figure out which one covers the needs of a specific project. De- velopers need to be experienced in order to achieve reasonable system development times. ICE, while inspired by CORBA and built in part by the same developers, is easier to use, more flexible and has more language mappings. There is one complete ICE implementation with a few variations, including one geared towards embedded systems.
XML-RPC and Websocket, on the other end of the spectrum, are the easiest ones to get started with. However, these protocols, along with SOAP, were developed for use in web applications rather than embedded systems, and all three need an HTTP enabled platform. This group is more suited for use in powerful nodes, like smartphones, that have looser demands on power conservation and relatively larger amounts of memory.
The largest of the middleware, ICE and XML-RPC, require roughly ten times more memory than the lightweight versions of Websocket, CORBA and DDS, whose total memory footprints are measured in tens of kilobytes. A lightweight SOAP im- plementation falls somewhere in between the extremes, with a 150 kilobyte footprint.
For very small, simple nodes, there are implementations of DDS and SOAP that can run on embedded 16-bit systems. DDS even has an 8-bit implementation, albeit with very limited functionality (only publish, no subscribe). DDS would be a good choice for an implementation with small, simple, battery powered sensors and strict QoS demands.
45http://portals.omg.org/dds/content/document/dds-interoperability-demo-rti-prismtech- twinoaks , http://portals.omg.org/dds/content/blog-feed-item/multi-vendor-dds-interoperability- here 2013-06-28
2.5. TECHNICAL ISSUES AND OBSTACLES
2.5 Technical issues and obstacles
There is a lack of compatibility between the numerous communication paradigms for IoT devices. There is at present no generalised, easy to use framework where users can plug in any device. The plug-and-play solutions that do exist are not cross-compatible with other networking technologies [26] and applications. Setting up an IoT system is still rather complex, unless a package solution intended for that certain purpose is chosen. Documentation, for protocols as well as hardware, is often scarce.
Trade-offs will have to be made in any battery driven implementation, where factors like communication capacity and processing power are weighed against bat- tery life. Specialised devices will be a preferred choice for many applications, where energy consumption per node is measured in micro- or even nanowatts at 3 volts (a typical voltage for the type of coin cell batteries that are often used in IoT nodes46).
Since the market is divided into so many standards with slightly different demands on hardware and firmware, the small production volumes render specialised devices expensive.
Longevity and self-sufficiency of permanent installations will become an issue as systems grow larger - human intervention is expensive, and the failure rate of an individual node multiplied with the total number of devices gives an inkling of the maintenance needs of a system.
Additionally, as will be discussed in the next chapter, developing high quality, standardised security solutions covering all layers of the OSI stack will be both a challenge and a priority.
The remainder of this section will be organised according to the layers of the OSI model, and will especially highlight some of the difficulties that standardisation efforts will meet.
2.5.1 Physical and data link layers
WPAN (e.g. Zigbee and Bluetooth), WLAN (e.g. Wifi) or cellular technologies make up this layer. This is the first crossroads of many in the communication stack, and interoperability between the different options is very limited.
2.5.2 Network layer
The Internet Protocol version 4 (IPv4) is currently used for over 90 percent of the routing and identification of devices on the internet. The 32-bit address space, with over 4 billion unique addresses, has already run out. Its lifespan has been extended through various workarounds, but in the long term IPv4 will not be able to accommodate the billions of uniquely identified nodes of the IoT. The successor to IPv4 is IPv6, which has 128-bit addresses, giving 3.4 · 1038unique identifications.
46http://www.em.avnet.com/en-us/design/technical-articles/Pages/Articles/Internet-of- Things-Designing-Sensor-Based-Devices-with-Coin-Cell-Batteries.aspx
2.5.3 Transport and session layers
TCP is resource expensive (in terms of battery, CPU, and memory) but full featured, while UDP is more lightweight but lacks a lot of features, like security, that are built into TCP. There are also lesser known and used alternatives, which may be problematic to use with restrictive firewalls that are configured to accept only the most common standards.
2.5.4 Presentation layer
There is a lack of standards and interconnectivity between the hundreds of alter- natives on this level, such as HTTP, REST, JSON, msgbus and SOAP. This means that the engineer tasked with implementing a system first needs to study some likely alternatives in order to understand their capabilities and limitations, and to assess their compatibility with any existing hardware or software. Once a standard has been chosen and built into a product, it will be cumbersome to change standards.
One proposed step towards plug-and-play is semantic web, where data is tagged in a standardised way in order to make it easier to parse [27]. For example, a node that has temperature, air moisture and wind speed sensors might have a server that publishes measurements in the form of a human readable web page, where each data point is also associated with tags like geographic location, unit, type of sensor, altitude and time.
2.5.5 Application layer
Here also, there is a lack of joint effort between suppliers, which makes it hard for consumers and customers to interconnect networks. This is a difficult problem to solve; applications in domains such as med tech, banking, public relations and social networking will have widely varying degrees of complexity and security levels among other things.
2.6 Security issues
Confidentiality and authenticity are critical criteria that need to be fulfilled before the IoT can be officially adopted by key entities like governmental institutions or large companies [11].
For the IoT to be useful, a trade-off will be necessary between user integrity and the free flow of data for statistical and other purposes. There is a lot of research to be done in the fields of encryption, access control and authentication, and “digital forgetting” [11] [8]. The latter term describes the possibility for the original poster or owner to remove information or media from digital records.
The IoT architecture is typically sensitive to attacks, like man-in-the-middle, where the attacker intercepts and relays or alters the communication between two nodes by impersonating them both.
