DIPLOMARBEIT
Diplom-Ingenieur
an der Fakultät für Informatik der Technischen Universität Wien
Betreuung: Ao.Univ.Prof. Dr. Wolfgang Kastner Mitwirkung: Dipl.-Ing. Dr. Mario Kofler
Wien, October 7, 2014 (Unterschrift Verfasser) (Unterschrift Betreuung)
Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at
Die approbierte Originalversion dieser Diplom-/ Masterarbeit ist in der Hauptbibliothek der Tech- nischen Universität Wien aufgestellt und zugänglich.
http://www.ub.tuwien.ac.at
The approved original version of this diploma or master thesis is available at the main library of the Vienna University of Technology.
http://www.ub.tuwien.ac.at/eng
MASTER’S THESIS
submitted in partial fulfillment of the requirements for the degree of
Diplom-Ingenieur
in
Bakk. techn. Marc Grabner Registration Number 0203298
to the Faculty of Informatics at the Vienna University of Technology
Advisor: Ao.Univ.Prof. Dr. Wolfgang Kastner Assistance: Dipl.-Ing. Dr. Mario Kofler
Vienna, October 7, 2014 (Signature of Author) (Signature of Advisor)
Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at
Erklärung zur Verfassung der Arbeit
Bakk. techn. Marc Grabner Nußdorfer Straße 35/9
Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen- deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit - einschließlich Tabellen, Karten und Abbildungen -, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe.
(Ort, Datum) (Unterschrift Verfasser)
i
Acknowledgements
For my beloved parents Dagmar and Wilfried, as well as for my grandparents for their ever enduring patience.
iii
Abstract
In the recent years, the Internet has been under constant change, where two revolutions have had the most impact and paved the road for the rise of the Internet of Things (IoT). In the first place, the number of connected devices like phones, tables or smart objects, which form the most essential part of the next generation of the Internet, have outranged the number of con- nected human beings. This has invoked the second change the Internet has seen, which is the transition towards the Internet Protocol version 6 (IPv6), which is able to provide the required addressing capabilities for the interconnection of this vast number of devices, potentially par- ticipating in the IoT. One of the main characteristics found in IoT environments is, that they are highly-heterogeneous, comprised of many different devices using different communication technologies and protocols. Therefore, interoperability between all the different devices is of major concern and also embodies a big obstacle for the IoT to evolve to its fully predicted value.
On this way, the IoT6 (Universal Integration of the Internet of Things through an IPv6 based Service Oriented Architecture enabling heterogeneous components interoperability) project was initiated in order to overcome the current fragmentation of the IoT, by putting efforts into research topics concerned with exploiting potential IPv6 features and to construct a service- oriented architecture, that sets on the vision of IoT by integrating various heterogeneous subsys- tems.
This thesis provides an analysis of interoperability testing methodologies for the IoT based on the input and the information gained from two research projects (PROBE-IT, IoT.est), that put their focus on testing issues within the IoT domain. The result is a light-weight testing methodology based on a generic testing framework developed by the European Telecommunica- tions Standards Institute, which has been adapted for our purposes. Subsequently, the developed methodology has been applied to an example use case scenario provided by the IoT6 project, to evaluate the functionalities of the different architectural components, where the focus of the use case was placed on multi-protocol integration of legacy device technologies.
v
Kurzfassung
In den letzten Jahren konnte ein permanenter Status der Veränderung bezüglich der grundle- genden Eigenschaften des Internets beobachtet werden. Zwei revolutionäre Schritte haben dabei besonderen Beitrag geleistet, um den rasanten Aufstieg des Internets der Dinge (IoT) voranzutreiben. Erstens hat die Anzahl der verbundenen Geräte, wie Smartphones, Tablets oder Smart Objekte, die den wesentlichsten Anteil der Teilnehmer in der nächsten Generation des Internets darstellen, die Anzahl der verbundenen Menschen überschritten. Aus direkter Konsequenz daraus entstand der zweite maßgebliche Wandel des Internets, nämlich die Transition zum Internet Protokoll Ver- sion 6 (IPv6), das die Fähigkeit besitzt, diese enorme Anzahl von Geräten, die die potentiellen Teilnehmer des IoT darstellen, untereinander zu verbinden, indem es den dafür notwendigen Adressraum zur Verfügung stellt. Eines der Hauptaugenmerke, das auch gleichzeitig eines der größten Hindernisse darstellt, um dem IoT die Möglichkeit zu bieten, seinen vollen Nutzen zu entfalten, ist die Interoperabilität unter möglichst allen teilnehmenden und auf heterogenen Technologien basierenden Geräten.
Aus diesem Grund wurde das Projekt IoT6 (Universal Integration of the Internet of Things through an IPv6 based Service Oriented Architecture enabling heterogeneous components inter- operability) ins Leben gerufen, welches das Ziel verfolgt, das Problem der momentanen Frag- mentierung des IoT in Angriff zu nehmen. Der Forschungsaufwand des Projekts legt dabei den Fokus auf jene Eigenschaften von IPv6, die das Potential besitzen, eine Serviceorientierte Ar- chitektur zu konstruieren, die auf der Vision des IoT aufbaut und es ermöglicht heterogene Sub- systeme zu integrieren.
Basierend auf der verfügbaren Information zweier Forschungsprojekte (PROBE-IT, IoT.est), die sich mit Fragestellungen des Testens in Verbindung mit dem IoT beschäftigen, liefert diese Diplomarbeit eine Analyse von Interoperabilitätstest-Methodologien, die sich für das IoT eignen. Das Ergebnis ist eine light-weight Interoperabilitätstest-Methodologie, die sich auf ein gener- isches Test Framework stützt, das vom European Telecommunications Standards Institute (ET- SI) entwickelt wurde. Die Konzepte des Frameworks wurden für unsere Zwecke übernommen und darauf folgend anhand eines Beispiel-Anwendungsfalls aus dem IoT6 Projekt demonstriert. Der Schwerpunkt des Anwendungsfalls lag dabei auf der Multiprotokoll Integration von Legacy Geräten und der Evaluierung der damit verbundenen Komponenten der IoT6 Architektur.
vii
Contents
Contents ix
1 Introduction 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Objectives of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 IoT Technology Overview 9 2.1 RFID Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 EPCglobal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3 Near Field Communication (NFC) . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4 Internet Protocol, Version 6 (IPv6) . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.6 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.7 Constrained Application Protocol (CoAP) . . . . . . . . . . . . . . . . . . . . 27
3 Architectures for the IoT 31 3.1 IoT-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2 ETSI M2M Architecture/oneM2M . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3 FI-WARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4 IoT6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.5 Concrete IoT6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.6 IoT.est . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4 Fundamentals of Interoperability Testing for the Internet of Things 57 4.1 Layers of Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.2 Testing and Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.3 Testing Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4 Identification of Candidate Framework for Interoperability Testing . . . . . . . 66 4.5 The IoT6 Interoperability Testing Methodology . . . . . . . . . . . . . . . . . 68 4.6 Ensuring Technical Interoperability . . . . . . . . . . . . . . . . . . . . . . . 75
5 Test Process 77 5.1 The Smart Office Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
ix
5.2 Test case specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.3 Test process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6 Conclusion and Outlook 119 6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Bibliography 123
CHAPTER 1 Introduction
The Internet as we know it, is under a constant process of change, variation and evolution. Ini- tially, started as "Internet of Computers" [6], providing services like the World Wide Web, built on top of the original platform, the trend of the last years pointed into another direction, where content is created and consumed by (always connected) human beings, forming the "Internet of People" (Web 2.0). Another tendency witnessed was the change of devices that are used to access the Internet. Broadband Internet connectivity is cheap and ubiquitous and has unleashed an explosive growth of mobile Internet and applications. We have witnessed a shift from the dominance of the PC, used as primary access mechanism, to mobile devices (phones, tablets, notebooks), expanding the boundaries of the Internet [6]. In addition to connectivity for any- body, anytime at any place, another dimension in the world of information and communication technologies appears: connectivity for anything [7].
The Internet of Things (IoT) is an integrated part of the future Internet, forming a global and dynamic network infrastructure with self-configuring capabilities. The basis of the IoT are interoperable standards and communication protocols, where things have unique identities and are linked to their virtual representation on the Internet, containing additional information to their identity, status location or any other business, social or privately relevant data [1][5]. The Radio Frequency Identification (RFID) technology is often seen as a prerequisite for the IoT, which enables machines and computers to automatically identify objects, record meta-data or control individual targets [4]. The general idea of the IoT is not a new one but, however, re- cently became relevant for practical issues mainly because the progress that can be witnessed in hardware development in the last decade. Seamless and transparent integration of smart ob- jects into the environment, to bridge the gap between the physical and virtual world has been an open research topic for almost twenty years [87]. Advancements in wireless sensor networks, matured technologies for manufacturing RFID tags and low priced sensors and actuators have initiated the potential to connect millions of smart objects to the Internet. The IoT has generated a vast interest from different communities and the industry. The information obtained by and produced through the IoT, evokes the potential of better understanding the real world and sup- ports the generation of ambient intelligence for a wide area of applications in various domains,
1
like intelligent logistics and supply chain management services. The detection of the physical status of things through sensors, in combination with intelligent processing of the collected data, raises the possibility to immediately respond to varying conditions of the real world, yielding immense potential for citizens, consumers and business [2].
The International Telecommunication Union (ITU) has pointed out the following dimension that are necessary to connect the physical to the virtual world [7]:
• "feeling things": sensors and wireless sensor networks (WSNs)
• "thinking things": embedded systems
Figure 1.1: IoT Dimensions [6]
The IoT vision of things is a very wide and generic definition, including a myriad of different physical entities. Personal objects, like cameras and smart phones or any possible element of our environments, as well as entities fitted with tags, that are integrated via gateways or proxies are considered to be participants in the IoT universe. The IoT is driven by an expansion of the Inter- net through the inclusion of physical objects combined with an ability to provide smarter services to the environment as more data becomes available. [6]. At the moment, the vast majority of In- ternet connections are established from devices that are directly used by humans, like computers and mobile handsets. The future vision points beyond this trend, that humans will become the
2
minority of information generators and receivers. Machine to Machine (M2M) communication will take over to be the major traffic source, where devices are exchanging information on behalf of people, in an autonomous fashion. Fig. 1.1 depicts the augmentation of the Internet by the up- take of M2M communication becoming the major communication paradigm. The vision of the IoT enhances connectivity from "any-time, any-place" for "any-one" into "any-time, any-place" for "any-thing" [6]. The more intelligent devices are integrated into a global connected network, that provide all kinds of different status information for higher-level-services, the more smart processes and services are possible to be realized, that can support our economies and environ- ments. Seamless and transparent integration of smart objects into the environment, to bridge the gap between the physical and virtual world has been an open research topic for almost twenty years [87]. Originally concerned with the traceability of physical objects using RFID technology the trend points beyond this proposition. The focus has shifted to areas like infrastructure and architecture, communication protocols for constrained devices, mobile sensor technology, secu- rity and privacy or semantic technologies and service-oriented perspectives towards the IoT [88]. Advancements in wireless sensor networks, matured technologies for manufacturing RFID tags and low priced sensors and actuators have initiated the potential to connect millions of smart objects to the Internet. The IoT has generated a vast interest from different communities and the industry. The information obtained by and produced through the IoT, evokes the potential of better understanding the real world and supports the generation of ambient intelligence for a wide area of applications in various domains, like intelligent logistics and supply chain man- agement services. The detection of the physical status of things through sensors, in combination with intelligent processing of the collected data, raises the possibility to immediately respond to varying conditions of the real world, yielding immense potential for citizens, consumers and business [2].
Fleisch [8] identified the main difference of the IoT to the common Internet as we know it, these days.
1 Invisible versus flashy hardware. Hardware brought into action in IoT deployments, serves a considerably different purpose than the personal computers and mobile phones part of the Internet. Fully-blown computers (high-capacity workstations, mobile phones etc.) represent the "nerve ends" of the Internet, that need steady supply from the power- grid, in contrast to the IoT, where we find very small, low-end and low energy consumption computers, that in many cases aren’t even visible. They are not constructed to commu- nicate in direct fashion with human beings and only provide a subset of the functionality of their bigger counterparts on the Internet. In the majority of cases, they only include routines for sensing, storing and communicating data to a limited amount, that is aligned with the requirements of the application scenarios of the device’s deployment.
2 Trillions versus billions of network nodes. At the moment about five billion devices like mobile phones or personal computers serve a population of approximately 6.7 billion human beings, of which only 1.5 billion are currently using the Internet [8]. At the first sight, this may seem a vast number, but if we try to take a look in the near future, the number of devices, that are possibly equipped with communication facilities, to be able to actively take part in the Internet, will reach a dimension, where people will not able,
3
to directly communicate with them. The immense number of participants will call for a new kind of network infrastructure, the IoT. The structure of today’s Internet (of Things) is depicted in Fig. 1.2 and can be split up into three different regions [48]:
Figure 1.2: The Internet of Things [48]
– Core Internet (million nodes): This part builds the core infrastructure of the Internet, which is comprised of servers and routers. This Internet region does not change very fast in capacity and is of relatively stable nature.
– Fringe Internet (billion nodes): Here, we can witness the biggest growth rate in capacity, nowadays. The size of this part of the Internet is clearly related to the number of (human) users with mobile phones, PCs or home multimedia equipment. The upper bound for this Internet region is determined by the people living on earth with Internet access, since devices, which are part of the Fringe Internet need human users, that operate and maintain them.
– Internet of Things (trillion nodes): For this region the biggest growth is predicted for the near future. In comparison to the Fringe Internet, the connected devices are not dependent on the people who are actively using or maintaining them. The corre- sponding applications are embedded, such as smart metering, industrial automation, logistics (transportation and tracking of things) or access control. Especially, build- ing automation is said to become the ubiquitous part of IoT technologies.
3 Last mile bottleneck versus highway. The last leg of transmission in a communication infrastructure is termed the last mile, which builds the communication link between the nerve endings and its next tier. Not long ago, the last mile was considered the bottleneck
4
of communication, since the transmission of data via twisted pair cables was competing with the transmission over fiber within the core network. Through emerging technology, driven by user demands for high-bandwidth services like streaming video, the speed of the Internet in this area has been increasing steadily. Through techniques like Fiber-To-The- Home (FTTH), the bandwidth constraint for the last mile, soon will not be valid anymore. In contrast, the transmission bandwidth of the last mile for constrained low energy devices communication over radio links will operate over highly bandwidth limited transmission channels.
4 Babylon versus global identification and addressing. The resource constrained char- acteristics of the IoT end devices are the reason for another difference, that is of major concern: addressing. Identification and addressing schemes that are applied in the Inter- net are not capable to be run on constrained devices, since they are too resource hungry. There has been invested a lot of research work in developing alternative standards and technologies, that are fitted to be executed on smart devices, enabling their addressing and identification. So far, there are many different identification schemes, that are used for addressing IoT devices on the last mile. For the IoT, to become as successful as the Internet itself, there has to be an agreed upon standard protocol, used for addressing and identification purpose to bridge the gap to the smart devices.
5 Machine-centric versus user-centric. The services, that are supported by the Internet and the IoT are determined by their inherent characteristics, respectively. Most of Internet- based services, like WWW, e-mail, file sharing and online shopping, are centered around humans. The IoT will bring a paradigm shift, that almost completely excludes humans from direct intervention. Human users’ contribution, will only be performed in case of decision making purposes, via mobile phones or personal computers. The majority of IoT applications will be carried out between smart things in Machine-to-Machine (M2M) fashion.
6 Focus on sensing versus on communication. The main focus of the Internet was based on communication. For the first time, it was possible for companies and individuals to reach almost everybody on a global scale, at very low cost. The WWW was centered around the distribution and presentation of content. As a result, the first economic success was achieved with advertising (e.g. Google) and shopping (e.g. Amazon). The second era of the Internet was dominated by the ability to handle user-generated content, switching the role of the user of only to be a consumer of data, to be an active contributor (Facebook, Twitter, Wikipedia, Youtube). Now, we are on the verge of entering the next generation of the Internet and another paradigm shift is to be witnessed. IoT integrates the physical with the virtual world and allows real world things to generate data automatically, without any direct human interaction. The new infrastructure enables sensing and measuring the world in a cost-effective and very fine granulated manner. If this measurement information is linked together in an intelligent way, this will facilitate many new applications and benefits. Nonetheless, this will also bring various, yet, unknown social, political, and ethical issues, that will to be tackled. Everyday objects will hold the potential to become
5
information security risks and the IoT could distribute these risks far more widely, than the Internet has done to date.
Through the immense number of intelligent devices, that are predicted to be connected to the IoT, an addressing protocol that offers an address space that is wide enough to handle this vast number of physical devices is the foundation to make the vision of IoT become reality. The Internet Protocol, Version 6 (IPv6) for Internet communication, which allows 2128 unique addresses seems to be the perfect choice for this task.
Since there exists a plethora of communication standards, that have to be integrated into the IoT environment, a highly scalable solution to be able to overcome the prevalent heterogene- ity and fragmentation of the IoT domain is required. The key issue of IoT is the diversity of integrated protocols and supported interfaces, but the lack of interoperability between different vendor implementations, limits the combination of different components to provide sophisti- cated IoT services.
1.1 Motivation
The IoT is built upon a heterogeneous and distributed architecture, and the involved products complexity is rapidly growing, which raises the attention to a common quality assurance method- ology for such systems, by the means of testing. Many different standards that are tailored for various application domains, like Radio Freuquency Identification for automatic identification, Wireless Sensor and Actuator Network technologies for sensing and acting on the physical envi- ronment or service-layer protocols, like SOAP or HTML are all involved in the realization of the IoT and lead to a powerful paradigm. The envisioned advantages and possibilities are hampered by interoperability issues at the communication level, as well as at the data level. The IoT6 (Uni- versal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture enabling heterogeneous components interoperability) [3] is a 3 years FP7 (Seventh Framework Programme) European research project, that aims at providing recommendations on IP features that can be exploited for the IoT with a specific emphasis on those unique to IPv6. The project defines an architecture and communication stack for the IoT, provides solutions for the integra- tion of heterogeneous technologies and proposes measures to solve the interoperability problem. Unifying test procedures and design methodologies for accomplishing interoperability testing, which are flexible to adopt to different equipment and system configurations are of great impor- tance, but also carry big challenges, along testing IoT deployments. This thesis addresses the mentioned problems, by providing an analysis of the state-of-the-art on interoperability testing methodologies and tries to investigate the suitability of these approaches for testing of interop- erability in IoT environments.
1.2 Objectives of the Thesis
Interoperability testing requires, that two systems running the same communication protocol are tested for their ability to communicate with each other by running test scenarios, which are com- prised of interactions across the interfaces of the two systems. Based on the insights and results
6
of an analysis of the state-of-the-art on interoperability testing and the input of the research work of the PROBE-IT project, an interoperability testing methodology should be defined, which is suitable, efficient and allows a structured testing for interoperability of IoT systems. The re- sulting methodology should be used in order to validate the different components of the IoT6 architecture. This process shall ensure the components compliance with IoT6 requirements, as well as validate their functionalities and interoperability within the IoT6 architecture [1, 2].
1.3 Structure of the Thesis
Chapter one serves an introductory purpose, provides general information about the vision of the IoT and also presents the scope of the topics treated in this thesis including motivation and expected results of the work.
Chapter two gives an overview about the most important technologies, which are found in the IoT universe. The central importance of IPv6 is emphasized, which is used to harmonize the various heterogeneous underlying technologies and provides the desired huge and homogeneous address space vital for the IoT. Additionally, there is given a short review about Wireless Sensor and Actuator Networks (WSANs) and related technologies, like IEEE 802.15.4 or the important 6LoWPAN standard, which allows to run IPv6 directly on resource constrained IoT nodes. The section is concluded with a short discussion about Web Services and the Constrained Application Protocol (CoAP), which is also an important candidate for the realization of a full-fledged IoT.
Chapter three introduces different Reference Architectures (RAs) for the IoT. Based on the concepts of the IoT-A [84], FI-WARE [67] and ETSI M2M [10] projects, which provide the grounding for several other research projects in the IoT domain, the different components and approaches of the IoT6 architecture are presented. The mapping of the concepts, found in this projects, to the IoT6 is discussed and thereafter the derivation of a concrete system architecture is defined. A special focus is given on the multi-protocol integration of legacy BAS system, which are integrated using an IoT6 gateway that provides an IPv6 address for every devices, provides protocol adaption functionalities and provides a homogeneous view on the heterogeneous device landscape that is managed by the gateway. The chapter is closed with another RA, developed in the course of the IoT.est [2, 78] project, which is also based on the concepts presented in the IoT- A. This project aims at the construction of an environment for service creation and testing. The heart of the project is lightweight semantic description framework for knowledge representation, that supports interoperability in highly heterogeneous IoT environments and also provides the means for semi-automatic test case generation.
Chapter four defines the guidelines for the development of interoperability tests for IoT de- ployments. The methodology is based on guidelines made available by the European Telecom- munications Standards Institute (ETSI) and provides the necessary information to define abstract test architectures, test purposes and as a final result the derivation of a test suite comprised of various test cases, which can be manually executed against the system to be tested for interop- erability. Furthermore, this chapter also includes a section about the PROBE-IT [1] project, which aims at benchmarking, guidelines for IoT roll-out and testing roadmaps. Especially, the work of the latter provides many interesting inputs for the definition of an interoperabil- ity testing methodology for IoT. This chapter also discusses and compares different available
7
test frameworks and methodologies and subsequently states the reasons why the applied method was chosen for our purpose.
Chapter five gives a thorough descriptions of the use case scenario, which serves as the base specification for the application of the test process. Thereafter, the the test specification including abstract test architectures, test purposes and test case descriptions is constructed based on the chosen test process, proposed by ETSI. The rest of the chapter is devoted to the application of the test process to a concrete IoT6 architecture set up in a lab environment to demonstrate the feasibility of the developed test method.
Chapter six concludes the work with a summary of the previous chapters and discusses the final results of the thesis. In this place, there are also given hints and suggestions for future research work and open topics.
8
2.1 RFID Systems
Radio Frequency Identification (RFID) is an identification technology, which enables to capture information wirelessly from tagged objects. This leads to the possibility to remotely detect, iden- tify and track any physical entity, which is equipped with an RFID tag. The tags serve as data carrier holding the identification information of the object. RFID falls in the special category of Automatic Identification (Auto ID), that uses electromagnetic waves in order to exchange infor- mation between the reader and transponder (tag). RFID technology removes the "line-of-sight" operation constraint, in comparison to optical barcodes. Information can be extracted from tags without direct human intervention and they are not supposed to be under direct sight of the inter- rogator. Barcodes still have the advantage of vanishingly small manufacturing costs compared to RFID tags, but a steady decrease for construction of such tags can be observed. Application areas of RFID can be found in processes such as supply chain management, logistics, quality control inventory management an so on. [56] The three main components that an RFID system is composed of are depicted in Fig. 2.1 [55].
Figure 2.1: RFID System [56]
9
• RFID tags: These are transponders (transmitter/receiver) that are attached to objects for identification purpose and are similar to optical barcodes. They are comprised of an an- tenna and a high frequency electronic circuit, that broadcasts the position or other at- tributes, for example an identifier of the data item the tag is attached to. There exists various kinds of tags and they are classified according to their power source.
– Active Tags: The characteristics of (the less common) active tags are, that they are fully battery powered, carry a transmitter and have the built-in capability to initiate a dialog with the tag reader on their own. They can act as interrogator on their own and are able to accept information from other tags. For that reason, they carry a large amount of memory. Active tags are able to switch into sleep mode to extend battery life time. The battery life time of active tags can be monitored and interrogators can be informed by an alarm message if the battery is near its end. Their usage is limited because of their high cost factor.
– Passive Tags: On the contrary, there are passive tags, that, as might be expected, have no internal power source. The energy needed to operate the IC chip for this kind of tags is supplied by the emitted radio waves of the tag reader. They represent the least expensive tag class and have limited data storage capabilities. Passive tags are of special interest for environments where it is impossible or at least hard to substitute the tag on an item, because (in theory) their lifetime is unlimited.
– Semi-Passive Tags: These tags have an on-board power supply for powering up the IC chip, but in comparison to active tags do not carry a transmitter. The memory capacity lies in between active and passive tags and the overall life time of these tags is determined by their battery life time.
• Tag Reader/Interrogator: They can be compared to scanners used for optical barcodes. Tag Readers emerge in different manifestations, like handheld, mobile or stationary. The two main components of a reader are an antenna that is used to communicate with the tags in form of electromagnetic waves and the interrogator circuitry that manages com- munication between multiple tags. Tag Readers are also termed Transceivers (transmit- ter/receiver) and have the main purpose to activate RFID tags, and transmit the extracted information to the application system. Furthermore, they have to guide the communication sequence with the tag. If there are multiple tags in the range of the reader, there would be collisions, through interference of the different signals, that scramble the communication. In many systems, there is taken a resembled anti-collision approach to the one in 802.11 networks, that is a variation of the Slotted ALOHA. If the reader detects a collision, it sends an indication message to the tags, which subsequently draw a random number that determines the interval, they have to wait, before retransmitting their identification [9].
• Application System: This part of the system is in charge of data processing and all tasks related with the initiation of reader and tag activities. In general, this part of the system comprises a Middle-ware and an Enterprise Application.
10
• Interrogation Zone (IZ): This is the three-dimensional physical space, where the electro- magnetic waves travel between the tag and reader. Successful communication is heavily dependent on the interferences from other electromagnetic sources within the IZ.
In general, the operation of RFID systems works as follows. Signals are broadcast by the reader via its attached antenna. If the electromagnetic waves are received by the tag a response is generated by either reading or writing the data or by replying with another signal containing some data, like an identifier or a measurement value. The IC of the tag includes the unique identification of the item to be tracked (e.g. in the form of an Electronic Product Code) and has some additional memory, where information related to the product can be placed, while passing through different manufacturing, warehousing and transportation processes [56]. Radio frequency is the means of communication between tag and reader and the nature of the Inter- rogation Zone is primarily determined by the kind of RF waves that are used for operating the IZ [56]. RFID Tags are categorized by the frequencies, part of the electromagnetic spectrum, they are using for operation and can be grouped into Low-Frequency- (LF), High-Frequency- (HF) Tags, Ultra-High-Frequency- (UHF) and Microwave Tags. Additionally, tags can be fur- ther classified by the way they transfer energy in order to achieve communication between the interrogator and a tag. Near-Field coupling techniques obtain the necessary power required to energize the tag’s IC from the oscillatory magnetic field provided by the reader’s antenna (Elec- trical Resonance Effect) [57]. Backscatter coupling basically works similar to radar systems, where the transceiver provides the signal for communication in both directions, and if passive tags are used is again in charge of supplying the necessary power for the tag circuity. The actual data transfer is achieved through load modulation [56].
2.2 EPCglobal
Once the Electronic Product Code (EPC) of an object is retrieved from a tag it can be associated with different information that belongs to the physical entity, where the components and inter- faces for this purpose are provided by the EPCglobal Architecture Framework [62]. We find specifications about
• the RFID reader interface
• a distributed database
• Object Naming Service (ONS) and discovery service.
The high-level goals of the framework are to facilitate the exchange of information on physi- cal objects between business partners, encourage the existence of a competitive marketplace and innovation. The standards that are part of the EPCglobal are designed to work on a global scale, are royalty-free and are driven by end-user demands. The framework and the interfaces between components are specified by open standards to represent the architecture in a vendor neutral
11
manner. Therefore, the framework can be implemented on heterogeneous software and hard- ware platforms, because all specifications are formulated in platform independent ways. One important part of the specifications of the EPCglobal is the definition of the EPC, that has the purpose to uniquely identify objects. Another part is the specification of the different RFID tag standards [58, 61]. The EPCglobal network tries to link all enterprises together in a single global network structure, which on the logic level represents a resource that is shared by all EPCglobal Subscribers. The architecture is organized in a decentralized fashion, where logically centralized functionality is distributed among multiple facilities. For discovery of data and services associ- ated to a specific EPC, the Object Naming Service (ONS) [59] is defined within the EPCglobal Architecture. ONS uses the infrastructure of the Domain Name system, thus the query and re- sponse types adhere to the well-known formats. In order to extract information about a specific serial number, an application layer server designated by the ONS result has to be appointed. The server provides services which are part of the EPC Information Services (EPCIS) [60], which defines interfaces for the representation and exchange of EPC-related information. Additional parts of the EPICS are definitions for event types, actions and the related semantics for captured events, a Data Model, location types and various other aspects for the management of the EPC related data.
2.3 Near Field Communication (NFC)
The number of issued physical smart cards has been steadily increasing in the last few years and the majority of people own multiple cards with different functionalities, like a credit card for non-cash payment or a key emulation card for gaining privileged access some specific facil- ities [63]. The increasing availability of smart handsets has transformed mobile phones into the device of choice for accessing sophisticated services and applications. Near Field Communica- tion (NFC) plays a major role in this area, which provides the phone with an interface allowing it to act as a smart card reader (tag reader) or to emulate smart cards (tag), which allows a mobile phone to act on behalf of many different smart cards in one monolithic shell. The NFC standard specified by the NFC Forum in ISO/IEC 18092 [64] is a short-range wireless connectivity technology with low transmitting power and a maximum data exchange rate of 424 Kbps. NFC operates in the unlicensed ISM band with an operating frequency of 13.56MHz and differs between three different types of operation modes [66].
The main application areas are payment/transaction, ticketing, access control, connectivity and information download [65].
2.4 Internet Protocol, Version 6 (IPv6)
The Internet Protocol (IP) is one of the substantial components of the protocol stack, deployed on networks and the Internet. The current version, IP Version 4 (IPv4), was developed in the early 1970’s with the purpose of enabling communication between researchers of the United States government and academics. Back in the days, the designers of IPv4 were not aware of the number of devices, that would potentially find their way into the Internet, and therefore would need an IP address. IPv4 is in use for decades and has performed extremely well, as the growth
12
of the Internet proved beyond debate, but networking requirements have changed today, from the simple access of e-mail and web pages to an explosive growth of networked devices and mobile communication. The theoretical address space provided by IPv4 is about 4.3 billion, but the early classful address allocation method further lowered the number of available addresses. Several solutions have been proposed, to create a little bit of extra time. Classless Inter Domain Routing (CIDR [38]) was introduced, which main idea was to assign the remaining addresses in variable- sized blocks without regard to classes. Moreover, Network Address Translation (NAT [39]) was defined, that in principle maps an entire private IP address space into a single public IP address. Both techniques have delayed the point in time, when no IP addresses are available anymore, but did not provide a sufficient solution for address exhaustion. As a consequence, a successor protocol was developed, which provides an extended address space. Additionally, the new protocol version tries to accommodate to the changes of requirements, that have risen over the years, concerning for better integration of mobile devices, quality of service (QoS) and more efficient representation of packets. Internet Protocol, Version 61 (IPv6), represents an evolution of IPv4. Its core specification can be found in RFC 2460 [40].
According to the specification, the main changes fall into the following categories:
• Extended Address Space: First an foremost, a remarkable renewal is the increased address space that is extended from 32 bits found in IPv4 to 128 bit for the current version of IPv6.
• Autoconfiguration: One of the most promising features included in IPv6 is Stateless Auto- configuration (SLAAC) mechanism. IPv6 routers are able to notify booting devices about network prefixes available on their link. This information can be used by the devices to auto-configure one or more valid global IP addresses, by combining the link layer MAC address or a private random number with the network prefix to generate a unique IP ad- dress, that can be assigned to the devices network interface. When using IPv4, the task of assigning unique addresses to network interfaces was accomplished by DHCP or manual configuration. According to the number of devices that will join the Internet thought IoT applications, SLAAC is an indispensable feature of the future Internet.
• Simplification of header format: The number of header fields that a router needs to exam- ine in order to process the packet are reduced down to seven, in comparison to version 4, where thirteen fields are present in the header. This allows faster processing of packets, thus ensures better throughput and less delay. The header checksum has been removed and error checking is left to link layer and transport layer functions. In IPv4, the checksum has to be computed for every packet that was processed by the router, since at least the hop count was changed, which results in the need for a new calculation of the checksum. This is not necessary anymore for IPv6, which reliefs the processing burden of routers. An- other header simplification is the fixed length (40 bytes) for IPv6 headers, which further speeds up packet processing.
• Improved support for options and extensions: Fields that were required in the old version of IP are now transformed to optional fields, out of the reason, that some of them are
1A more logical consequence for the naming of the new protocol version would have been IPv5, but Version 5 was already assigned to the experimental Internet Stream Protocol.
13
not used that often. Additionally, in order to further speed up the packet processing, options are represented in different manner and routers now have the possibility to skip over options that are not addressed for them. IPv4 integrates options in the base header, whereas IPv6 places options in extension headers, which are only added on demand.
IPv6 Header Format
This section should give an insight, what changes have been defined for the header format of IPv6 in comparison to the previous protocol version IPv4. The required fields of an IPv6 packet are depicted in Fig. 2.2.
Figure 2.2: IPv6 (required) Header [40]
The Version (4-bit) field within the IPv6 header always equals (0110) == 6 and is used by routers during the transition period from the older to the new version of the Internet Protocol. The second field (8-bit) of the packet header is concerned with Differentiated services and fa- cilitates the ability to make a difference between packets with different real-time requirements. The Flow Label (20-bit) is used by sources to request special treatment for a sequence of pack- ets, like non-default QoS, in order to establish a pseudo-connection. The design choice enables 220 active flows in parallel between a pair of IP addresses, since the flows are identified by the combination of Flow Label and Source- and Destination Address. The Payload Length (16-bit) carries the information about how many bytes are following the (required) 40 header bytes. The Next Header Field (8-bit) is the part of new features of IPv6 that allows for simplification of the header format, by providing the possibility to signal, if there are added optional Extension Headers that directly follow the required header portion. Currently, there exist six different kinds of Extension Headers, which are identified by a distinct value in the Next Header field. They are optional and carry extra information encoded in efficient manner. Every Extension Header carries a Next Header field itself, for the purpose of concatenating the various Extension Headers. The standard recommends a specific order for the appearance of the extensions. The
14
Next Header field of the last Extension Header signals the termination of the header section and indicates that now the TCP/UDP header follows. The extension header fields include:
1. Hop-by-hop options: Misc. information for routers
2. Destination options: Additional information for the destination
3. Routing: Loose list of routers to visit
4. Fragmentation: Management of datagram fragments
5. Authentication (RFC2402): Verification of the sender’s identity
6. Encrypted security payload (RFC2406): information about the encrypted contents
The Hop Limit Field (8-bit) is used to avoid packets that got involved into looping behavior, from circulating for eternity. The value contained in this field is decremented every hop by one. The packet in question is discarded if this value is equal to zero. The last two fields of the required header section are the Source- and Destination IPv6 address fields (128-bit each).
IPv6 vs IPv4 Header. In IPv6, several fields have been removed from the header format in comparison to IPv4. The required IPv6 header is 40 bytes long and therefore the Header Length field is not required anymore. The three fields for Identification, Flags and Fragmentation Offset are used to handle fragmentation in IPv4. Fragmentation is not provided anymore by IPv6 routers. If a packet should be fragmented a sending host learns the Maximum Transmission Unit (MTU) along a path through a discovery procedure and handles the fragmentation over an Extension Header.
Figure 2.3: IPv4 Header [41]
Therefore, the three mentioned fields were removed form the IPv6 header and are now placed in the Fragmentation extension header by the source of the packet. As mentioned before, the Header Checksum field is left out in order to improve the processing speed of routers. Since IP is a best-effort delivery protocol, the responsibility to ensure data integrity is placed at the upper
15
layer protocol at the transport layer. One important point to mention is, that when using UDP as the transport option, the checksum, which was not required with IPv4, becomes mandatory with IPv6 [46]. Finally, the Type of Service field in IPv4 was replaced with the Differentiated services (Traffic Class) field, since preferences are handled in a different manner by IPv6, the Time-to-live field is substituted by the Hop Limit and the Protocol field now is communicated over the Next Header field. No padding is required, because of the fixed header size of IPv6. What we can conclude from this section is that the two protocol version are not interopera- ble, because of the fundamental changes of the packet format. Therefore, during the transition period, routers have to run a dual-stack, that supports both types of protocols.
IPv6 Addressing Architecture
The address space extension was one of the main objectives, along with the optimization of routing tables, for the introduction of IPv6. The IPv6 address space was increased from 32 to 128 bits. This section has the purpose to become familiar with the structure of IP addresses and will also explain the design decisions, that were made for the novel standard. The addressing architecture for IPv6 is defined in RFC 4291 [42].
IPv6 Address Types
There are classified three different address types in IPv6.
• Unicast: This address type is used to uniquely identify an interface. Packets sent to this kind of address are delivered exactly to the interface identified by this address.
• Multicast: Addresses of this class are used to identify a group of IPv6 interfaces. Packets sent to such an address are delivered to all interfaces of members that previously joined the multicast group the address is identifying.
• Anycast: The anycast address type is assigned to multiple interfaces. A packet sent to this address is delivered to only one of the interfaces, usually the nearest one.
IPv6 discards broadcast addresses used in IPv4 and uses multicast instead.
IPv6 Address Notation
An IPv6 address has 128 bits (16 bytes) and the defined notation splits up the address into eight 2 byte hexadecimal blocks, that are separated by colons (:). An example for a valid IPv6 address could be
2001:0EF8:0000:0000:00AA:EF01:2345:6789
For the sake of a more compact notation, leading zeros in each block can be omitted. The address of the previous example could be rewritten as
2001:EF8:0:0:AA:EF01:2345:6789
16
Furthermore, a double colon (::) can be used to replace consecutive zeros in an address. When there are witnessed double colons in an address, the address is expanded with the number of zeros that are missing to the full 128 bit representation. This is the reason, why double colons can only appear once per address. Our example address would look like this
2001:EF8::AA:EF01:2345:6789
in compressed notation.
Literal IPv6 Addresses in URLs. The problem that arises, when using IPv6 address in URLs is, that in this place the colon is used to denote the port number. In order to use a literal IPv6 address in a URL, the address needs only to be enclosed in "[" and "]" characters (RFC 2732). The example address within a URL would look like
http://[2001:EF8::AA:EF01:2345:6789]:80/index.html
IPv6 Prefix Notation
Network prefixes (RFC 4291) of IPv6 address are defined in similar form as they are written in CIDR notation of IPv4. Specific address types or subnets are identified using this notation by the high order bits of an address. The prefix length is appended by separating the address with a slash ("/") and writing down the length as decimal number. This leads to the following notation:
IPv6 address/prefix length
where IPv6 address corresponds to the notation of the previous section and prefix length is an integer that defines how many left-most bits are part of the prefix. The prefix of an IP address is used to identify the subnet an interface belongs to and routers examine the prefix in order to forward packets. Furthermore, the same prefixes are used in order to define special address types.
Allocation Prefix binary Prefix hex Unspecified 0. . . 0 (128 bits) ::/128 Loopback 0. . . 1 (128 bits) ::1/128 Global unicast 001 2000::/3 Link-local unicast 1111 1110 10 FE80::/10 Multicast 1111 1111 FF00::/8
Table 2.1: Prefix Allocation (adapted from IPv6 Essentials) [46]
17
Tab.2.1 gives an excerpt of some assignments of reserved prefixes and special addresses, like link-local or multicast addresses. The address assignments are done by the Internet Assigned Numbers Authority (IANA). The whole list and more information can be found at [45].
Unicast Address
The binary prefix 001 identifies global unicast addresses, which are defined in RFC 4291. The global routing prefix has a hierarchical structure and is assigned by international registry ser- vices and by the Internet Service Provider (ISP).
Figure 2.4: IPv6 Unicast Address Format; adapted from [46]
The subnet ID is the part of the address that is assigned by a local administrator and identi- fies a link within a site. Finally, the interface ID has to be unique within a subnet and identifies an interface of a node attached to a link.
Interface Identifiers
An interface identifier is used by a host during auto-configuration. Addresses with the prefix 001 and 111 should use a 64-bit interface identifier in the EUI-64 (ref) format, that in the com- mon case is constructed from the link layer Ethernet MAC address. The Link-Local interface address of a node is the combination of the prefix FE80::/64 and the 64-bit interface identifier. The process for generating a link-local address is presented in RFC 2464.
Multicast Addresses
When a packet is sent to a multicast address, the packet is processed by all members of the multicast group. Multicast addresses are identified with the prefix FF::/8. The prefix is followed by a 4-bit field reserved for flags. The first bit of this field is always set to zero and reserved for the future. The second bit indicates if this multicast address embeds a Rendezvous Point (RFC 3956) and the third one signals if the address carries prefix information (RFC 3306). The last bit in the flag field is used to distinguish between permanently assigned (well-known) or transient addresses.
The scope field is used to define the topological span of the multicast and is further explained a little bit later. The last field in a IPv6 multicast address is the 112-bit group identifier.
18
Anycast Addresses
Anycast addresses are designed in order to provide redundancy and load balancing between mul- tiple hosts or routers, that provide the same service [46]. In IPv6, anycast addresses are allocated from the unicast address pool and are syntactically indistinguishable from unicast addresses. An anycast address is a unicast address, that is assigned to more than one interface. The node to which the address is assigned must be explicitly configured to know that the address assigned to the interface is an anycast address. A packet sent to an anycast address is routed to the nearest interface the address was assigned to, according to the metrics of the routing protocol [42].
IPv6 Address Scope
IPv6 accommodates the notion of different address scopes [43] into its base address architec- ture, which is another major difference in comparison to IPv4. Every IPv6 address except the unspecified address has a specific topological span, for which the address can be used as unique identifier for an interface. The scope of an address is directly carried as part of the address.
IPv6 Unicast Scope. Four different address scopes are defined for packets sent to unicast addresses.
• Interface-Local (loopback): Any transmission to or from this address, can be read by any application bound to the loopback (localhost) address. For communication with link-local scope, no physical network interface is involved.
• Link-Local: These addresses are outside the global address block and routers prevent packets sent to these addresses from being forwarded between interfaces. They are like any other unicast address except for being limited to the local link. One important point to mention is, that Link-Local addresses are generated by any IPv6 interface when powered- up and they are used for the Neighbor Discovery (Router Discovery, Address Resolution and Stateless Auto Address Configuration) protocol.
19
• Site-Local: This address type is similar to Link-Local addresses except, that in this case multiple links can be included. The original Site-Local [40] is deprecated and was sub- stituted by Unique Local IPv6 Unicast Addresses (ULAs) [44], that solve the problem of address conflicts, when joining sites.
• Global: The scope of global unicast addresses comprises all the links and interfaces on the Internet. All IPv6 addresses in the address block 2000::/3 can be used in order to accom- plish global communication. Every node, that wants to accept incoming connections has to assign one of these addresses to a communication interface. Global unicast addresses enable true end-to-end communication, because interfaces that are identified with this ad- dress type can be reached from any node on the global IPv6 Internet. Just to mention, through the introduction of NAT, the end-to-end principle is not given in IPv4 networks, since the addresses are hidden and rendered private.
IPv6 Multicast Scope. For multicast addresses, there are six different scope types defined. A multicast packet starts with the prefix FF00::/8, followed by a 4-bit flag field, that is used to mark the address transient or permanent, plus the 4-bit scope field, that carries the scope information. The value of this field defines one of the following scopes [42]. The semantics are pretty similar to unicast scopes.
• Interface-Local (0x1): spans only a single interface on a node (loopback traffic of multi- cast).
• Link-Local (0x2): same topological span as for corresponding unicast scope.
• Admin-Local (0x4): smallest scope, that must be administratively configured. The con- figuration is not automatically derived from physical connectivity or other related config- uration and must therefore be administrated manually.
• Site-Local (0x5): the scope for this multicast type is a single site.
• Organization-Local (0x8): the span is comprised of multiple sites belonging to a single organization
• Global (0xE): multicast with global scope.
Advanced IPv6 Features and IoT
We want to conclude this section by bringing all the mentioned features of IPv6 in relation to IoT and outline, why this new protocol is one of the essential technologies, that would drive the evolution towards the Future Internet.
Address Space. The large number of devices said to be part of IoT raises the need for large address space, which is definitely provided by IPv6.
20
Autoconfiguration. Because of the many devices statelessness and autoconfiguration is a highly desirable feature.
Connectivity. The native application of IPv6 on IoT devices enables simple end-to-end con- nectivity and the connection to IP-networks and the Internet.
2.5 Wireless Sensor Networks
The steady proliferation of wireless sensor networks (WSNs) was paved by many different fac- tors, but especially the rapid advances in the areas of sensor design, information technologies, and wireless networks [49] should be mentioned as the most important factors, that permitted the success of this promising technology. Miniaturization of computing and sensing technolo- gies rises the possibility to manufacture low-power and inexpensive sensors, actuators and con- trollers [49]. WSNs are another fundamental component of the IoT ecosystem, that, expressed metaphorically, form the sensing nerve ends of the IoT infrastructure, that have the potential to provide an interface from the physical world to the virtual world. Sensors capture and re- veal real-world phenomena and transform these into a representation, that subsequently can be processed and stored by computers.
Figure 2.6: Sensing and Actuation [49]
From a technical point of view, a sensor is a device that transforms parameters and events of physical objects into electrical energy that can be passed to a computer system or controller for further analyzation [49]. Figure 2.6 depicts the data acquisition of a process (phenomena of the real world) and further actuation that is performed after the data has been processed. The signal conditioning stage removes unwanted noise components by filtering the obtained analog signal and does preparation for more precise analog-to-digital conversion. Thereafter, the signal is available in digital form for further processing and visualization. In many cases, WSNs are additionally equipped with actuators, which allow to directly control the physical objects. The signal processing flow works in reverse direction, where command of the processing unit are transformed into analog signals, which serve as input for the actuator, that acts upon the phys- ical object, like opening a valve or controlling a motor to open a door. In this case we speak
21
about Wireless Sensor and Actuator Networks (WSANs). A wireless sensor is additionally fit with on-board processing and storing capabilities for com- municating the collected data to a central authority processing station, via radio frequency waves. Undeniably, this is an absolute important fact since many applications require thousands of sen- sor nodes, often deployed in inaccessible areas. When many sensors cooperatively monitor large physical environments, they form a wireless sensor network [49].
Figure 2.7: Wireless Sensor Network [49]
Figure 2.8 depicts two different sensor fields monitoring two different distant geographic areas connected to the Internet via a Base Station (BS) acting as a gateway node. Within a WSN, there may exist different kinds of sensor nodes classified by their complexity and their capabilities. They range from simple nodes that only monitor and communicate information in their vicinity, to more powerful devices that perform extensive processing and data aggregation functions. Through their larger processing and energy capabilities, then nodes often act as a backbone for more constrained sensor nodes to reach the BS (multi-hop communication). In some scenarios, where the current position of a nodes is of concern, even GPS receivers can be additionally attached to a device within the WSN.
IEEE 802.15.4
The IEEE 802.15.4 protocol stack is the key enabler for low complexity, ultra low power con- sumption and low data rate wireless connectivity among inexpensive fixed, portable or moving devices. Therefore it became the main candidate for the implementation of low data rate wire- less personal area networks (LoWPAN) and WSNs [51]. The key design requirements of WSN applications are driven by the constrained nature of the underlying nodes, a WSN is comprised of. They are low-powered and designs strive for long battery life. Low cost is another factor and
22
mesh-networking in order to support communication of a large amount of devices should be sup- ported. Self-Organization plays an important role, because individual devices need to have the possibility to join or leave such networks at will, without any fixed infrastructure. The deployed protocol must be able to support and facilitate topology construction, dynamic re-configuration, routing and admission control. The network should be able to retain performance parameters even under large changes of the number of nodes participating, hence scalability of such net- works is another crucial feature for protocols applied in such environments. Further important characteristics of communication protocols deployed on sensor network nodes and Low Power Personal Area Networks are low delay, which can be achieved by bandwidth reservation and admission control, fairness among different nodes and power management to enable long bat- tery life [50]. The IEEE 802.15.4 standard defines a physical (PHY) and data-link layer (MAC) in correspondence to the ISO/OSI reference model. To start with the PHY, three RF bands are part of the standard: 868 to 868.6 MHz, 902 to 928 MHz and 2400 to 2483.5 MHz. Direct Sequence Spread Spectrum (DSSS) in combination with Binary Phase Shift Keying (BPSK) is applied in the two lower frequency bands, which results in data rates of 20 kbps and 40 kbps, respectively. For the 2450 MHZ ISM band, Orthogonal Quadrature Phase Shift Keying (O- QPSK) modulation, where four data bits are further spread with a 32-bit spreading sequence achieves a maximum data rate of 250 kbps. In a revised standard, released in 2006, additional combinations of spread spectrum and modulation techniques, this data rate is also available for the lower frequency bands. Another important characteristic of the standards PHY layer, that will be interesting for further discussion, is the maximum PDU size that can be handled, which is only 127 bytes [51]. This amount of data is enough for most WSN applications, since they most often are deployed for monitoring or actuation tasks that do not require the delivery of big packets. Addressing is achieved with 64-bit or 16-bit addresses, providing unicast or broadcast semantics. The payload that remains available after link-layer framing is between 72 and 116 octets.
Two different modes are offered by the standard:
• Star topology: the communication is controlled by the PAN coordinator. There is a synchronized (beacon-enabled) mode, where the coordinator publishes beacon frames, that contain information to control the channel access.
• Peer-to-Peer topology: devices are free to communicate with each other and do not have to choose the route via the coordinator. Nonetheless, they have to associate to a PAN coordinator to join a network.
We find two different device classes in the IEEE 802.15.4 standard. Full Function Devices (FFDs) can be present in both mentioned topologies, can act as PAN coordinator and are able to talk to any other device, part of the PAN. On the other hand, we find Reduced Function devices (RDFs), that are limited to act in a star topology and have not the ability to operate as coordinator of a PAN. These devices communicate with other devices indirectly routed over an FFD and all have small foot-printed and simple implementations [49].
Medium Access Control (MAC) for the star topology is managed by so-called beacon frame, that are special frames, which are emitted by the coordinator. The time interval, that elapses
23
Figure 2.8: Topologies for IEEE 802.15.4 [49]
between two consecutive beacons is called a super-frame or the beacon interval, which is fur- ther split up into an active and passive period. The active period of the beacon frame is used for communication with a cluster, where the nodes are able to send to and receive data from the coordinator. The access mechanism is a contention-based Slotted CSMA/CA mechanism. Thereafter, during the passive period some devices could be granted individual access to the channel, in cases where contention-based medium access does not offer adequate performance. For peer-to-peer topologies, non-beacon enabled operation is defined. Beacon frames are only emitted on request, for the purpose of synchronizing the clocks of the device part of the network. The access method for this case is Unslotted CSMA/CA [51].
Several different standards like ISA 100, ZigBee or 6LoWPAN are using 802.15.4 as their PHY and MAC layer.
2.6 6LoWPAN
To ensure the success of the Future Internet and at the same time the future of the IoT, IPv6 should be enforced to run on any device, to make it possible to easily integrate such systems directly to the global Internet. IPv6 Over Low power Wireless Personal Area Network (6LoW- PAN) started as a working group of the IETF, that was formed to create specifications for ways of building IP-connected wireless networks for embedded systems. As we already know, the ad- dress space of IPv6 is theoretically that large, that we are able to assign unique addresses to any kind of device or object we can think of. This fact makes it desirable to enable sensors and con- sumer devices with the communication capabilities provided by IPv6. A lot of devices deployed in IoT environments are WSN technologies and it would not be possible to run a full IPv6 stack implementation on such resource-constrained systems. The main concept behind 6LoWPAN is to run IPv6 even on the smallest devices, with limited processing power, memory and bandwidth for communication. Originally, the name of the working group at the IETF, 6LoWPAN, became the name for a protocol definition to enable IPv6 packets to be carried on top of low power wire- less networks, specifically over the PHY/MAC specification of IEEE 802.15.4. The first draft was released in RFC4944 and defines the frame format for transmission of IPv6 packets, the formation of IPv6 link-local addresses and statelessly auto-configured addresses on top of IEEE
24
802.15.4. Additionally, the standard defines an Adaption Layer, that deals with the frame-size mismatch of the two protocols, supporting fragmentation and reassembly where needed and a header compression mechanism, required to make IPv6 practical on devices running the above mentioned PHY/MAC layers. The current development of the standard added further compan- ion specifications for discussion, that make it possible to run 6LoWPAN on top of Bluetooth Low Energy (BT-LE), DECT Ultra Low Energy (DECT-ULE) or G.9959, which is used in Z- WAVE. Additional standards, that are not obligatory, but are often used in combination are RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks, RFC 6550) for routing or CoAP (Constrained Application Protocol) on the application layer for data transfer.
LoWPAN Characteristics
Low-power Wireless Personal Area Networks (LoWPANs) are simple low cost networks that are comprised of devices, that are based on the IEEE 802.15.4 protocol stack. The devices are characterized by limited power and relaxed throughput requirements and are applied to connect the physical environment with real-world applications.
Some characteristics that are found in LoWPAN environments are [47]:
• Small Packet Size. The MTU defined by IPv6 is 1280 bytes, which brings the constraint for IP networks, that they must be able to carry packets of at least 1280 bytes (header plus payload) without the need for fragmentation. This is far beyond the maximum frame size used in IEEE 802.15.4 networks, which is not more than 127 bytes. This is further reduced by the MAC layer header using IEEE EUI-64 addresses down to 102 bytes. To make things even worse, if there is required IEEE 802.15.4 link-layer security, which takes up 21 bytes of space, the remaining space is only 81 bytes. From there on, the header of IPv6 packets needs 40 bytes, which shrinks the available space for transport protocols like UDP down to 41 bytes.
• Low bandwidth. The data rates are between 250 and 20 kbps depending on the applied physical layer.
• Low power. In nearly all scenarios the devices are battery powered.
• Large number of devices. The devices participating in LoWPANs around the world are said to outrange the number of deployed personal computers.
• No predefined device location. The location of devices may often not be easily accessible and the devices tend to have no fixed location and may be on the move.
It is desirable to apply IP technology, because of the pervasive nature of IP networks and the existing infrastructure. IP is a well-known technology, that exists for a long time and there is available lots of knowledge, experience and tested diagnostic and management tools. If the devices natively run IP, there is no need for gateways or proxies for translation, which enables a direct connection to IP-based networks.
25
Benefits of 6LoWPAN
Back in the days, IP connectivity was not desired by system designers and proprietary tech- nologies were deployed for special purpose problems. But there are a lot of reasons, why the application of IP technology within sensor networks brings many advantages over proprietary solutions [48]. First IP-based devices are easy to integrate into larger networks, without the need for gateways and proxies, that would be a necessary mean for performing translation between different networking technologies. When the devices are natively IP-enabled, communication and data flows happen in real end-to-end manner, which is of utmost importance to achieve a future proof and scalable solution. Another good reason for using IP on embedded devices is, that the existing network infrastructure can be reused. Third, IP technology is built upon a long- lived standard, that already exists for 30 years and has proven to work and grow organically on a global scale. Next, IP follows an open and free specification process providing public docu- ments, which is a driving factor for innovation and helps standards to be understood by a wide audience. Finally, there exists a broad range of well-proven tools for maintenance, diagnostics and commissioning of IP networks, that also can be used for 6LoWPAN networks.
6LoWPAN Protocol Stack
Figure 2.9 depicts the general five layers Internet model in correspondence to the 6LoWPAN stack, that is based on IPv6 with the additional LoWPAN feature. First off, it is important to understand some general aspects of the Internet model, for conceiving the functionality provided by 6LoWPAN.
Figure 2.9: IP stack in comparison to 6LoWPAN stack [48]
The Internet is comprised of a vast number of different networks, based on various link-layer technologies, which are all integrated and made interconnectable on a global scale by IP. Instead of having many different specialized networks the IP layer constructs a virtual network above these various links and provides a homogeneous addressing space and integrates all different technologies within the same infrastructure. As a consequence, the Internet model is often termed a narrow waste model [48], where the IP layer provides a standardized interface to the
26
different transport protocols, consequently hiding the peculiarities of the link-layer technologies. The first difference of the 6LoWPAN stack is that it is completely based on IPv6, which is made applicable on IEEE 802.15.4 and similar link technologies through the LoWPAN adaption. The address hierarchy defined for the addressing architecture of IPv6 is used by 6LoWPAN to achieve header (address) compression. Two levels of header compression are defined, HC1 for the compression of IPv6 addresses and HC2 for the size reduction of UDP headers. The actual address compression is accomplished at the edge of the LoWPANs by routers. Since an entire LoWPAN shares the same network prefix, this information can be compressed away in lossless manner by the edge router devices at the network borders. The transformation is transparent, efficient and stateless in both directions [48]. Another important task of the LoWPAN adaption layer is to handle the frame size mismatch by supporting fragmentation of packets that exceed the maximum permissible size of the underlying link. Because of its complexity, TCP is not fitted for the application on resource constrained nodes, therefore UDP is used as transport protocol. ICMPv6 messages are used for control task and neighbor discovery. At the application layer, we often find application specific binary protocols, although CoAP has become one of the most used options.
2.7 Constrained Application Protocol (CoAP)
Even though HTTP is often used in conjunction with Web Services, it is certainly not the only protocol that can be used for M2M communication and especially carries shortcomings on de- vices that operate in constrained environments, because of their resource hungry and "chatty" nature. Constrained RESTful Environments (CoRE), is another working group part of the IETF, that developed a protocol, that takes into account the low processing capabilities and energy con- straints of nodes part of WSNs and small embedded devices and enables the efficient application of RESTful Web Services [89] in such use cases. CoAP (Constrained Application Protocol) is an application layer protocol (ISO/OSI-Layer-7), that includes several functionalities provided by HTTP, which have undergone a re-design, that aligns with the requirements of M2M commu- nication in constrained (IoT-) environments. Furthermore, CoAP provides additional important mechanisms not present in HTTP, like a built-in resource discovery, IP multicast support, a na- tive push model and asynchronous message exchange [52, 21]. HTTP is based on TCP at the transport layer, which has performance issues over low-power and lossy networks, and because of its connection-oriented nature carries lots of overhead for short-termed connections like just sending a few bytes of data that represent a sensor value. Therefore, CoAP relies on UDP at the transport layer, that fits much better the requirements that are present in such environments. Features to underline, that are supported by UDP are
• significantly lower overhead in comparison to TCP
• support for multicast and
• less sensitivity concerning mobility.
CoAP can be counted as another IoT-enabling technology, that can be used together with 6LoWPAN, to easily integrate constrained embedded device into the Internet, while at the same
27
time keeping the resource demand on a low level and extending the battery life of the devices, where these technologies are applied on.
Figure 2.10: RESTful Architecture using CoAP [21]
Additionally, the standard provides the definition of a mapping between HTTP and CoAP, that allows the implementation of proxies, for the translation of HTTP requests to be mapped in a uniform manner to constrained environments.
Interaction Model
CoAP supports request/response interaction based on the classical client/server model, that finds also its application in HTTP. However, M2M interactions mostly result in CoAP implementa- tions, that take on both roles, client and server. A CoAP client sends a message in order to request an action using a method code on a specific resource, that is identified by a URI. The server returns a response code, where the response additionally can include a resource repre- sentation. As previously mentioned, UDP is used as datagram-oriented transport protocol, thus CoAP deals with messages in asynchronous manner. Four basic message types are defined [53]
• Confirmable (CON)
• Non-confirmable (NON)
• Acknowledgment (ACK)
• Reset (RST)
To carry requests and responses, method and response codes are added to some of these message types. CON messages are re-transmitted using a default timeout and exponential back- off between retransmissions, until the recipient responds with an ACK message, with the same Message ID (used in order to detect duplicates). The RST message is used in cases, where the
28
recipient is not able to process the CON message. When reliable transmission is not of concern, like for single messages within a stream of sensor data, NON messages are used. Since running over UDP, multicast IP addressing is supported, which gives the possibility of multicast CoAP requests. The methods supported by CoAP are [53]
• GET: retrieves information that corresponds to the resource identified by the request URI.
• POST: requests processing of resource identified by the request URI. This usually results in the creation of an update of the target.
• PUT: requests the processing or update of the resource target identified by the request URI
• DELETE: requests the resource identified by the request URI to be deleted.
• OBSERVE: This method extends the core protocol of CoAP with a mechanism to push resource representations from servers to interested clients [54].
29
3.1 IoT-A
The main challenge for the IoT is to find a way to connect many different applications and technologies into one coherent network. Most of the solutions are implemented with specific requirements in mind and do not provide the necessary interoperability capabilities to interact with each other, which results in a vast number of vertical applications existing besides each other, completely isolated, without the means to exchange or reuse information. For that reason, a more horizontal approach where applications are based on a common technical grounding and common architectural principles is required to finally realize a fully fledged IoT. This fact motivated the IoT-A (IoT-Architecture) [83] project to propose an Architectural Reference Model (ARM), which is comprised of a Reference Model (RM), which aims at providing a common understanding of the IoT domain, as well as a Reference Architecture (RA), that describes the essential building blocks and design choices that need to be followed in order to create compliant IoT solutions.
IoT-A Reference Model
The RM builds the foundation for working with the RA, and besides the model itself, intends to provide the concepts and definitions required to build IoT architectures. There are numerous sub-models, that are part of the RM, like [84]
• the IoT Domain Model, depicted in Figure 3.1, that introduces the concepts of Devices, IoT Services and Virtual Entities (VE) and their relationships between each other. This part of the model generates the common understanding of the target domain in question, which is essential for arguing about architectural solutions and to evaluate them. The definition of a common grounding is inevitable for developing interoperable architectures and systems. In this part of the RM, the important roles and relations between Entities, Resources and Services in IoT scenarios are presented. The starting point is a Physical
31
Entity1, that is an identifiable part of the physical world and a user2 that has the intention to interact with this Entity.
Figure 3.1: IoT-A Domain Model
The digital representation of a Physical Entity is termed a Virtual Entity (VE). To construct the relation between physical and virtual entities, a Device3 is attached to the Physical Entity, that provides the technological interface and gives the possibility to interact with or retrieve information about the "thing". The Device acts as mediator for interactions taking place between physical and virtual entity and builds the bridge between physical and digital world. A Resource is a software component, that enables control functionality and provides information about an entity. Resources typically have native interfaces, thus are of heterogeneous nature. Finally, IoT Services expose the functionality of Resources, by offering well-defined and standardized interfaces, hiding the complexity of accessing a variety of heterogeneous Resources [83].
• an IoT Information Model, depicted in Figure 3.2 that models all the concepts of the Domain Model and their relations, that are to be explicitly represented and manipulated in the digital world. The Information Model is used in order to provide a structure for the information, that is processed by IoT systems. This provides the basis for all aspects of the system related to representation, processing, storage and retrieval of information and builds the foundation for the definition of functional interfaces of the IoT system [83].
VEs are defined in more detail by adding the notion of attributes that have a name, a type and one or more values to which meta-information (e.g. time-stamp and location of a measurement) can be associated. Furthermore, an association between the service and the VE is defined, that links the service to a specific attribute of an entity
1almost any object like animal, car, computer, logistic items etc. 2e.g. human person or digital artifact, like service or application 3e.g. sensor, actuator, tag
32
Figure 3.2: IoT-A Information Model
The type of a Virtual Entity class may refer to concepts in an ontology, that defines which attributes are associated with this entity type. The attribute type determines the semantic meaning of an attribute (e.g. the value represents humidity). A Service Description models the relevant aspects of an IoT-Service including its interface and may additional contain Resource Descriptions, which describe the Resources, whose functionality is exposed by the associated Service [88]. Moreover, the a Resource Description can contain information about the Device, that hosts the resource in form of a Device Description [83].
• the IoT Functional Model that identifies several Functional Groups (FGs), which are based on the IoT concepts, envisioned in the IoT Domain Model and sets them in relation to com- mon functionalities, present in IoT architectures. For structuring information within the FGs, the concepts of IoT Information Model are utilized. Fig. 3.3 depicts the functional decomposition in various FGs, that in sum, make up the ARM. The functional decom- position is applied to break up the overall complexity of IoT ARM compliant systems in small manageable parts and additionally highlights the relationships between the different system components. The result of the functional decomposition is a superset of func- tionalities, which have to be implemented in order to produce an IoT-compliant system. Briefly speaking, the Functional Model defines an abstract framework for understanding the main FGs and their interactions [84].
Figure 3.3 depicts the functional view resulting from the functional decomposition of the ARM. The model is comprised of seven longitudinal FGs in combination with two vertical FGs, that hold available functionalities that are needed by several longitudinal groups.
The Application-, Virtual Entity-, Device and IoT Service FGs are derived from the ab- stractions that were identified in the Domain Model.
33
Figure 3.3: Functional Model of IoT-A [83]
Service Organization and Process Management FGs are concerned with the development of services and applications on top of the IoT. The composition and orchestration of IoT services and the development of Business Processes are accomplished at this FG level. The Process Management FG has the purpose of conceptual integration of traditional busi- ness process management systems with the ARM. The FG should provide functionalities and interfaces in order to integrate the peculiarities of the IoT with the business process world. This results in the fact that enterprises can access and utilize IoT systems by common technologies and standards, thus avoiding additional costs and overhead for the integration of proprietary silo solutions.
One of the most important aspects of distributed systems and one major characteristic of IoT systems is the heterogeneity of communication technologies that are employed in such systems, which is a direct reflection of the inherent complexity in the world of the IoT [84]. Since IoT architectures are faced with enormous numbers of different communi- cation technologies, the ARM also needs a functional group that deals with this problem. The Communication FG (CFG) is based on the Communication Model defined within the IoT-A RM, which builds upon the ISO