Applied Research NET 412

Research Project:

“Key Technologies and Communication Standards for

Internet of Things”

by

Nurgeldi Pudakov

102200019

CONTENT OUTLINE

1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33. IoT Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34. Examples of Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55. Fundamental IoT Mechanisms and Key Technologies. . . . . . . . . . . . . . . . . . . . 7

5.1. Structural Aspects of the IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1. Key IoT Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.2.1. Sensor Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.2.2. RFID Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6. Evolving IoT Communication Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.1. IETF IPv6 Routing Protocol for Low-Power and Lossy Networks (LLNs) . . 10

6.2. Constrained Application Protocol (CoAP) . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.3. Message Queuing Telemetry Transport (MQTT) . . . . . . . . . . . . . . . . . . . . . 16

6.4.ETSI M2M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2

Abstract

This project explores main technologies involved in the concept of “Internet of Things (IoT) as well as the emerging standards of IoT/M2M (machine-to-machine) communication. The project holds an educational purpose. Literary analysis was conducted in order to achieve detailed and an overall view of the IoT in terms of communication technologies and standards.

2. Introduction

The potential of Internet of Things (IoT) is a world where billions of objects, interconnected over public or private Internet Protocol (IP) networks, can sense, communicate and share information. These interconnected objects can collect data regularly, analyze and use it to provide a wealth of high quality information for planning, management and decision making. This is the world of the Internet of Things. The concept of the IoT and the term “Internet of Things” were invented by the co-founder of the MIT Auto-ID Center, Kevin Ashton, in 1999 and only recently the IoT has gained its relevance to the practical world mainly because of the growth of mobile industry, cloud computing and data analytics. Since then, many visionaries have recognized the phrase “Internet of Things” as the general idea of everyday objects that are readable, locatable, addressable, and controllable via the Internet, irrespective of the communication means (whether via RFID, wireless LAN, WAN or other means). The objects in the IoT are not only the electronic devices we encounter in daily basis or the equipment of higher technology, but things that we do not ordinarily think of as electronic at all - such as food and clothing. Examples of “things” include people, location (of objects), time Information (of objects), condition (of objects). These “things” of the real world will be seamlessly integrated into the virtual world by the IoT, enabling ubiquitous connectivity at any time.

3. IoT Definitions

The overall definition of the IoT is still evolving as it is the new Internet application and its standards are in the process of development and implementation. However, as mentioned in

3

Chapter 2, the concept of the IoT was invented by Kevin Ashton, the co-founder of the MIT Auto-ID Center, and formulated as the architecture that includes four elements:

Passive radio frequency identification (RFIDs), such as Class-1 Generation-2 UHF RFIDs, operating in the 860– 960 MHz range 1, introduced by the electronic product code (EPC) Global Consortium

Readers plugged to a local (computing) system, which read the EPC A local system offering IP connectivity that collects information pointed by the EPC

through a protocol called object naming service (ONS) EPC Information Services (EPCIS) servers that process incoming ONS requests and

returns physical markup language (PML) files, for example, XML documents carrying meaningful information linked to RFIDs

Despite the formulation of the concept by its inventor, different perspectives of commercial and non-commercial organizations in the ICT industry on the IoT concept have created definition of it in multiple variations. The material includes several of these definitions to provide the overall perception of the IoT concept by the industry:

“The Internet of Things consists of networks of sensors attached to objects and communication devices, providing data that can be analyzed and used to initiate automated actions. The data also generate vital intelligence for planning, management, policy, and decision-making.”

Proposed by Cisco

“A global network infrastructure, linking physical and virtual objects through the exploitation of data capture and communication capabilities. This infrastructure includes existing and evolving Internet and network developments. It will offer specific object identification, sensor and connection capability as the basis for the development of independent federated services and applications. These will be characterized by a high degree of autonomous data capture, event transfer, network connectivity, and interoperability.”

Proposed by Coordination and Support Action (CSA) for Global RFID-related Activities and

Standardization (CASAGRAS)

“A global ICT infrastructure, linking physical objects and virtual objects (as the informational counterparts of physical objects) through the exploitation of sensor and actuator data capture, processing and transmission capabilities. As such, the IoT is an overlay above the “generic” Internet, offering federated physical-object-related services (including, if relevant, identification, monitoring, and control of these objects) to all kinds of applications.”

4

Proposed by France Telecom

“The Internet of Things links the objects of the real world with the virtual world, thus enabling anytime, anyplace connectivity for anything and not only for anyone. It refers to a world where physical objects and beings, as well as virtual data and environments, all interact with each other in the same space and time.”

Proposed by IoT European Research Cluster (IERC)

A more reflective definition of the IoT concept was produced by International Telecommunication Union (ITU):

“A global information and communication infrastructure, enabling automated chains of actions (not requiring explicit human intervention), facilitating information assembly and knowledge production and contributing to enrichment of human life by interconnecting physical and logical objects based on standard and interoperable communication protocols and through the exploitation of data capture and communication capabilities, supported by existing and evolving information and communication technologies.”

4. Examples of Application

This chapter provides a list of possible applications than can be developed by the Internet of Things (IoT), although the list is incomplete and is limited in the temporal domain (with new applications being added on an ongoing basis). Also, the chapter includes several examples of already functioning IoT applications.

A long list of possible applications includes, but is not limited to, the following (Libelium):

Smart Citieso Smart Parking (monitoring the availability of parking spaces in the city)o Traffic Congestion (monitoring of vehicles and pedestrian levels to optimize driving

and walking routes)o Smart Lightning (intelligent and weather adaptive lightning in the street lights)o Waste Management (detection of rubbish levels in the trash containers to optimize

the trash collection routes)o Smart Roads (intelligent Highways with warning messages and diversions according

to climate conditions and unexpected events like accidents or traffic jams)

5

Smart Environmento Air pollution (control of CO2 emissions of factories, pollution emitted by cars)

Smart Watero City water monitoring (monitoring the quality of tap water in the city)o Chemical leakages detection in the rivers (detecting leakages and wastes of factories

in the rivers)o Water leakage detection (detecting water leakages in water tanks and pipes of the

city) Smart Grid (intelligent energy consumption monitoring and management) Smart Security

o Perimeter Access Control (detection of people in non-authorized areas)o Liquid Detection (in data centers, warehouses)

Smart Retailo Supply Chain Control (monitoring of storage conditions along the supply chain and

product tracking for traceability purposes)o Smart Product Management (control of rotation of products in shelves and

warehouses to automate restocking processes)

Smart Logisticso Quality of Shipment Conditions (monitoring of vibrations, strokes, container

openings or cold chain maintenance for insurance purposes)o Item Location (search of individual items in big surfaces like warehouses or harbors)o Storage Incompatibility Detection (warning emission on containers storing

inflammable goods closed to others containing explosive material)o Fleet Tracking (control of routes followed for delicate goods like medical drugs,

jewels or dangerous merchandises) Home Automation

o Energy and Water Use (energy and water supply consumption monitoring to obtain advice on how to save cost and resources)

o Intrusion Detection Systems (detection of windows and doors openings and violations to prevent intruders)

eHealtho Fall Detection (remote assistance for elderly or disabled people living independent)o Sportsmen Care (monitoring of sportsmen’s performance and health status)o Patients Surveillance (monitoring of conditions of patients inside hospitals and in old

people's home)

6

5. Fundamental IoT Mechanisms and Key

Technologies

This chapter explores the fundamental mechanisms and technologies that are involved in the design and deployment of the IoT. A hybrid view of the IoT both as a service concept and as an infrastructure is provided in this part of the material.

5.1 Structural Aspects of the IoT

IoT or machine-to-machine (M2M) nodes have several design constraints and requirements, the most important of them are the following (Minoli, 2013):

Low power (with the requirement that they will run potentially for years on batteries) Low cost (total device cost in single-digit dollars) Significantly large amount of devices than in a LAN environment Severely limited code and RAM space (fixed-size code: MAC, IP, and data to execute the

embedded application— in, for example, 32K of flash memory, using 8-bit microprocessors)

New types of user interface for configuration (e.g., using gestures or interactions involving the physical world)

Requirement for simple wireless communication technology (the IEEE 802.15.4 standard is suitable for the physical and link layers)

The M2M communication has specific requirements and properties due to its format. Table 1.0 shows these characteristics of the M2M communication in some areas of IoT application.

Table 1.0 Properties and Requirements of M2M Applications

ITS e-Health Surveillance Smart Meters

7

Mobility Vehicular Pedestrian/ None None Vehicular

Message size Medium Medium Large Small

Traffic pattern Regular/ Regular/ Regular Regular Irregular Irregular Device density High Medium Low Very high (up to 10000 per cell)

Latency Very high Medium Medium Lowrequirements (few msec) (seconds) (<200 ms) (hours)

Power efficiency Low High Low High requirements

Reliability High High Medium High

Security Very high Very high Medium High

Courtesy: A. Maedar, NEC Laboratories Europe.

5.2 Key IoT Technologies

The following content of the material describes the main technologies which serve as the fundamental of the IoT.

5.2.1 Sensor Technology

A sensor network is an infrastructure with primary functions such as sensing (measuring), computing, and communication elements that gives an administrator the ability to instrument, observe, and react to events and phenomena in a specified environment. Usually, the administrator of the sensor network is a civil, governmental, commercial, or industrial entity. The operating environment of such networks can be the physical world, a biological system, or an information technology (IT) framework. Typical applications include, but are not limited to,

8

data collection, monitoring, surveillance, and medical telemetry (Sohraby, Minoli & Znati, 2007).There are four basic components in a sensor network: (i) an assembly of distributed or localized sensors; (ii) an interconnecting network (usually, but not always, wirelessbased); (iii) a central point of information clustering; and (iv) a set of computing resources at the central point (or beyond) to handle data correlation, event-trending, querying, and data mining. Because the interconnecting network is generally wireless. These systems are known as wireless sensor networks (WSNs).The sensing and control technology includes electric and magnetic field sensors; radio-wave frequency sensors; optical, electro-optic, and infrared sensors; radars; lasers;

location/navigation sensors; earthquake-oriented and pressure sensors; undersea submarine traffic sensors based on sonars; controllable environmental sensors for sensing weather conditions such as wind, humidity, heat.Sensors operate and are interconnected via a series of multi-hop short-distance low-power wireless links. They typically utilize the Internet for long-haul delivery of information to a point (or points) of final data collection and analysis. In general, within the sensor field, WSNs employ contention-oriented random-access channel sharing and transmission techniques that are now incorporated in the IEEE 802 family of standards (Sohraby, Minoli & Znati, 2007).Sensors differ in physical size; they range from nanoscopic-scale devices to mesoscopic-scale devices at one end, and from microscopic-scale devices to macroscopic-scale devices at the other end. Nanoscopic (also known as nanoscale) refers to objects or devices on the order of 1 to 100 nm in diameter; mesoscopic scale refers to objects between 100 and 10,000 nm in diameter; the microscopic scale ranges from 10 to 1000 mm, and the macroscopic scale is at the millimeter-to-meter range.Sensors may be passive and/or be self-powered. Some sensors may require relatively low power from a battery or line feed. High power-consumption sensors such as radars may require very high power feeds.

5.2.2 RFID Technology

RFID (Radio Frequency Identification) is a method of identifying unique items using radio waves. Typical RFID systems consist of three components: readers (interrogators), antennas and tags (transponders) that carry the data on a microchip. The data carrier, tag, transmits information to a reader within the safe reading range, which can forward the information to a host computer. RFID technology is used in various applications, including security and access control, transportation and supply chain tracking. It is an efficient technology for collecting multiple

9

pieces of data on items for tracking and counting purposes in a cooperative environment. Figure 1.0 illustrates the communication mechanism of RFID tag.

Figure 1.0 Communication mechanism of RFID tag

One of the methods of object identification for tracking purpose is the EPC (Electronic Product Code) which provides a standardized unique serial number for an object in the EPCglobal Network, with an Object Name Service (ONS) providing the adequate Internet addresses to access or update specific data of the object. Typically, EPC codes used for active RFIDs are transmitted in clear text format; however, some new protocols are now emerging that can solve the privacy issue of the IoT. One example of such protocols is host identity protocol (HIP) within which the identity of active RFIDs are not exposed in clear text, but protect the identity

value (e.g., an EPC) using cryptographic procedure (Ilie, Kemeny, Egri & Monostor, 2006).

RFID primarily operates in the following frequency bands (ISO 18000):

• Low Frequency (125/134KHz) – most commonly used for access control and asset tracking.

• Mid-Frequency (13.56 MHz) – Used where medium data rate and read ranges are required.

• Ultra High-Frequency (850 MHz to 950 MHz and 2.4 GHz to 2.5 GHz) – offer the longest read ranges and high reading speeds.

10

6. Evolving IoT Communication Standards

This chapter is dedicated to the evolving communication standards which are emerging in the IoT market.

6.1 IETF IPv6 Routing Protocol for Low-Power and Lossy Networks (LLNs)

Low power and lossy networks (LLNs) are a class of networks in which both the routers and the connection between them are constrained. LLN routers typically operate with constraints on processing power, memory, and battery power. Their connections are characterized by high loss rates, low data rates, and instability. To solve these routing issues, IETF ROLL Working Group developed a new mechanism, called the IPv6 Routing Protocol for LLNs (RPL). LLNs can comprise up to thousands of routers. All of the In LLNs, traffic flows can be point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN toward a central control point). These types of traffic flows are supported by the IPv6 Routing Protocol for LLNs (RPL), a protocol by proposed by IETF.

As shown in the Figure 2.0, existing routing protocols fail to meet one or more communication metrics for IoT applications.

Figure 2.0 Survey of routing protocol for IoT applications

11

Communication metrics for IoT applications include:

Routing State - limited memory resources of low-power nodes Loss Response - response to link failures Control cost - constraints on control traffic Link&Node cost - link and node properties are considered when choosing routes

In order to be useful in a wide range of LLN application domains, RPL separates packet processing and forwarding from the routing optimization objectives such as minimizing energy, minimizing latency and satisfying constraints. A RPL implementation, in support of a particular LLN application, will include the necessary Objective Function(s) as required by the application (RFC 6550).

The functioning of the RPL routing protocol is based on the construction of Directed Acyclic Graph (DAG), a directed graph of a network with no cycles in connection of its nodes. A DAG consists of one or more DODAGs (Destination Oriented DAGs). DODAG is a DAG rooted at a single destination, as illustrated in Figure 2.1. There is a DODAG for each single destination in the network.

Figure 2.1 DAG and DODAG

DODAG determines the position of each node in the network by the calculated rank of the nodes. The calculation of this rank is performed the Objective Function (OF), which defines how to interpret one or more metrics and constraints, defined in Routing metrics used for path calculation in low-power and lossy networks (RFC 6551), into a rank. Each node has a set of parent nodes, and they are also specified by OF. Different DODAGs based on a same OF are identified by a RPLInstanceID.

In topology building and negotiating metrics such as link reliability, link latency, node power state, RPL uses three types of messages:

12

DAG information object (DIO)—carries information that helps a node to discover an RPL instance, get its configuration parameters, and select DODAG parents;

DAG information solicitation (DIS)—solicit a DODAG information object from an RPL node;

Destination advertisement object (DAO)—used to propagate destination information upward along the DODAG.

When a new node is connected to a RPL network, it first listens to receive DODAG Information Object (DIO) messages. Neighboring nodes periodically broadcast DIO messages into the network. The node will trigger the neighboring nodes to send a DIO message by broadcasting a DODAG Information Solicitation (DIS) message, if no DIO message is received. The information inside the DIO message from the neighboring nodes allows the Objective Function (OF) to select the preferred parent in the network. The DODAG has been constructed for a specific OF and for each root when all the nodes of the network have selected a preferred parent. Routing in RPL is hierarchical. Packets are forwarded by each node to its parent node, until they reach the root. Destination Advertisement Object (DAO) messages are used to create downward routes. DAO messages are forwarded by each node to its parent node. This process continues, until the messages reach the root. There are two modes of RPL operation: Storing and Non-Storing mode.

In the Non-Storing operation mode, packets will first travel all the way to a DODAG root and only then they will travel to the destination node. In the Storing mode, packets are forwarded towards the destination node by a common ancestor of the source and the destination prior to reaching a DODAG root. If the destination is on the route towards the root, the destination node will not forward the message (Ishaq, 2013).

RPL supports many-to-one and one-to-many traffic flows. In RPL protocol, stateless nodes can store only configuration parameters and a list of parent nodes. The protocol constructs paths to destination, considering link and node properties.

6.2 Constrained Application Protocol (CoAP)

The IETF constrained RESTful environments (CoRE) Working Group has recently started to work on a new standardization – The Constrained Application Protocol (CoAP).

CoAP is a simple application layer protocol purpose of which is to allow electronic (IoT/M2M) devices to communicate interactively over the Internet. CoAP is a protocol specially developed for wireless sensor network (WSN), which is a network of actuators that are monitored and

13

remotely controlled through the Internet. CoAP can be categorized as web transfer protocol for communication of M2M application nodes in constrained networks.

“CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments” (RFC 7252).

Some key aspects of the protocol are as follows:

easy mapping with HTTP; low header overhead and easy parsing; support for the discovery of resources; simple resource subscription process; simple caching and proxy capabilities; asynchronous message exchanges.

The interaction model of CoAP is analogous to the client/server model of HTTP. However, in CoAP, M2M nodes can act as both client and server roles. This interaction is called an end-point. As in HTTP, client, using a method code, sends a CoAP request to a server for action on URI identified resource. Then, server, using a response code, sends a response with a resource representation.

Figure 2.2 Abstract Layering of CoAP

14

However, in CoAP, the exchange of these messages between client and server is not similar to HTTP interaction model. CoAP performs the transmission of the messages asynchronously over a datagram-oriented transport such as UDP. This process is done logically by using a part of messages that is responsible for optional reliability, with exponential back-off. CoAP operates four types of messages: confirmable (CON), non-confirmable (NON), acknowledgement and reset.

In the CoAP messaging model, the exchange of messages between a client and a server is done over UDP. Both request and response messages consist of a short fixed-length binary header (4 bytes), compact binary options and a payload. To prevent duplication, each CoAP message has an ID. Reliable messages are marked as CON. A CON message is retransmitted using a default timeout and exponential back-off between retransmissions, until the recipient sends an acknowledgement message (ACK) with the same message ID from the corresponding end-point. If a recipient cannot process a CON message, it sends a reset message (RST) to a sender instead of an ACK. A message such as measurement data sent by an actuator does not require reliable delivery and can be marked as a NON message. This type of messages is not acknowledged, but it is still identified with an ID to prevent duplication. If a recipient cannot process a NON message, it sends an RST message. Since the messaging model of CoAP is based on UDP, which supports the multicast IP destination addresses, the protocol can send multicast CoAP requests.

Using validity information in CoAP response message, the protocol caches the responses to process efficiently the requests. A cache is saved in an end-point or an intermediate node which is located in the path to destination. CoAP also features proxy, which is helps to limit the traffic in constrained networks and access to resources of sleeping. CoAP uses proxy on request on the behalf of an end-point. A CoAP request includes the URI of the resource, while the destination IP address is set to the proxy.

As shown in Figure 2.2, CoAP operates on top of UDP not TCP. UDP does not support SSL/TLS to provide security. DTLS (Datagram Transport Layer Security) is can be a security solution for CoAP. It provides the same security level as TLS but for transfers of data over UDP. Typically, DTLS capable CoAP devices will support RSA and AES or ECC and AES.

6.3 Message Queuing Telemetry Transport (MQTT)

MQTT was developed by Andy Stanford-Clark (IBM) and Arlen Nipper (Eurotech) in 1999 for the monitoring of an oil pipeline through the desert. The goal was to design a protocol, which requires low bandwidth and power-efficient, because the sensing devices were connected via

15

satellite link, which was extremely expensive at that time. These features of the MQTT protocol recently became the reason of standardization of it for the communication of IoT applications.

Unlike the request/response model of HTTP, MQTT protocol has a different architecture, called a publish/subscribe. Publish/Subscribe is event-driven, which means messages are delivered to clients even without a request. MQTT has a central communication point called the MQTT broker. It coordinates all messages between the senders and the rightful receivers. Each client publishes a message to the broker with a topic included in the message. The topic is the routing information for the broker. Each client subscribes to a certain topic in order to receive messages and the broker delivers all messages with the matching topic to the client. Therefore, the clients do not have to identify each other, they only communicate over the topic (Figure 2.3). This architecture enables high scalability of networks, staying independent from the data producers and the data consumers.

In MQTT, a client does not request a resource, instead, it subscribes to the topic and the broker pushes any new resource, related to the topic, to the client. Therefore, each MQTT client keeps an open TCP connection with the broker. If this connection is lost, the MQTT broker buffers all messages and sends them to the client when the connection is recovered. (HiveMQ, 2015).

Figure 2.3 MQTT Publish/Subscribe Architecture (Courtesy of HiveMQ)

The main concept of MQTT is that the delivery of messages to clients is based on subscription to a topic which the messages are related to. A topic is a clear-text string which can consist of several hierarchy levels, separated by a slash. A sample topic for sending temperature data of

16

the living room could be house/living-room/temperature. There are two subscription options for a client: subscribing to the exact topic or using a wildcard. The subscription to house/+/temperature would result a client receiving all messages sent to the previously mention topic house/living-room/temperature as well as any topic that is under the house topic, for example house/kitchen/temperature. The plus sign is a single level wildcard which allows clients to receive all messages related to the subtopics of only one hierarchy level. If client wants to subscribe to all levels under the main level, there is also a multilevel wildcard (#). It allows subscribing to all underlying hierarchy levels. For example house/# is subscribing to all topics beginning with house (HiveMQ, 2015).

6.4 ETSI M2M

Technical Committee, recently formed by ETSI, is working on the development of M2M communication standards. The goal of this group is to provide an end-to-end view of M2M standardization for emerging IoT industry. According to standards released by ETSI Technical Committee (ETSI TS 102 689, ETSI TS 102 690 and ETSI TS 102 921, 2010-13), main elements in M2M environment are the following:

M2M device: A device capable of replying to request for data contained within those device or capable of transmitting data contained within those devices autonomously;

M2M area network (device domain): A network that provides connectivity between M2M devices and M2M gateways, for example, a PAN;

M2M gateway: A gateway (a router or higher layer network element) that uses M2M capabilities to ensure M2M devices interworking and interconnection to the communication network;

M2M communication networks (network domain): A wider-range network that supports communications between the M2M gateway(s) and M2M application; examples include but are not limited to xDSL, LTE, WiMAX, and WLAN;

M2M applications: Systems that contain the middleware layer where data goes through various application services and is used by the specific business processing engines.

7. References

1. Ishaq, I. (2013). IETF Standardization in the Field of the Internet of Things (IoT): A Survey. Journal of Sensor and Actual Networks, 2, 235-287. Retrieved from www.mdpi.com/journal/jsan

17

2. ETSI, (2013). Machine-to-machine communications (M2M); Functional architecture. ETSI TS 102 690. 2.1.1. Retrieved from www.etsi.org/deliver/etsi_ts/102600_102699/102690/02.01.01_60/ts_102690v020101p.pdf

3. ETSI, (2012). Machine-to-machine communications (M2M); mla, dla and mld interfaces. ETSI TS 102 921. 1.1.1. Retrieved from www.etsi.org/deliver/etsi_ts/102900_102999/102921/01.01.01_60/ts_102921v010101p.pdf

4. ETSI, (2010). Machine-to-machine communications (M2M); M2M service requirements. ETSI TS 102 689. 1.1.1. Retrieved from www.etsi.org/deliver/etsi_ts/102600_102699/102689/01.01.01_60/ts_102689v010101p.pdf

5. Minoli, D. (2015). Building the Internet of Things with IPv6 and MIPv6 : The Evolving World of M2M Communications. Somerset, NJ, USA: John Wiley & Sons.

6. IETF, (2014). The Constrained Application Protocol (CoAP). RFC 7252. Retrieved from https://tools.ietf.org/html/rfc7252#page-5

7. IETF, (2012). RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. RFC 6550. Retrieved from https://tools.ietf.org/html/rfc6550

8. HiveMQ, (2014). MQTT 101 - How to get started with the lightweight IoT protocol. Retrieved from http://www.hivemq.com/blog/how-to-get-started-with-mqtt

9. Ilie, E., Kemeny, Z., Egri, P., & Monostor, L. (2006). The RFID Technology and Its Current Applications. MITIP, 5 (7), 29-36. Retrieved from http://www.ropardo.ro/fileadmin/prezentari_pdf/RFID_MITIP2006.pdf

10. Sohraby, K., Minoli, D., & Znati, T. (2007). Wireless Sensor Networks: Technology, Protocols, and Applications. Canada: John Wiley & Sons.

11. Libelium. 50 Sensor Applications for a Smarter World. Retrieved from http://www.libelium.com/top_50_iot_sensor_applications_ranking/

18

8. Bibliography

1. ITU-T, (2012). Global Information Infrastructure, Internet Protocol Aspects and Next-Generation Networks. Recommendation ITU-T, Y.2060

2. Vermesan, O., & Friess, P. (2014). Internet of Things: From Research and Innovation to Market Deployment. Denmark: River Publishers.

3. Vermesan, O., & Friess, P. (2013). Internet of Things: Converging Technologies for Smart Environments and Integrated Ecosystems. Denmark: River Publishers.

4. Kaur, M., Sandhu, M., Mohan, N., & Sandhu, P. (2011) RFID Technology Principles,

Advantages, Limitations & Its Applications. International Journal of Computer and Electrical Engineering, 3 (1).

19