Internet of Things: Concepts and Technologies

1

Internet of Things: Concepts and Technologies

Payam BarnaghiInstitute for Communication Systems Faculty of Engineering and Physical Sciences University of Surrey

Internet of Things

2P. Barnaghi et al., "Digital Technology Adoption in the Smart Built Environment", IET Sector Technical Briefing, The Institution of Engineering and Technology (IET), I. Borthwick (editor), March 2015.

3

Wireless Sensor Networks (WSN)

− Sensor Networks consist of nodes with different capabilities.− Large number of heterogeneous sensor nodes− Spread over a physical location − It includes physical sensing, data processing and

networking − In ad-hoc networks, sensors can join and leave

due to mobility, failure etc.− Data can be processed in-network, or it can be

directly communicated to the endpoints.

4


Sinknode Gateway

Core networke.g. InternetGateway

End-user

Computer services

- The networks typically run Low Power Devices- Consist of one or more sensors, could be different type of sensors (or actuators)

5

Types of nodes

− Sensor nodes− Low power − Consist of sensing device, memory, processor and radio− Resource-constrained

− Sink nodes− Another sensor node or a different wireless node− Normally more powerful/better resources

− Gateway− A more powerful node− Connection to core network− Could consist service representation, cache/storage,

discovery and other functions

6

Types of applications

− Event detection− Reporting occurrences of events− Reporting abnormalities and changes − Could require collaboration of other nearby or remote nodes− Event definition and classification is an issue

− Periodic measurements− Sensors periodically measure and report the observation and

measurement data − Reporting period is application dependent

− Approximation and pattern detection− Sending messages along the boundaries of patterns in both

space/time− Tracking

− When the source of an event is mobile− Sending event updates with location information

7

Requirements and challenges

− Types of services− In conventional communication network the target is

moving bits from one place to another− In WSN moving the data is not the actual goal.

− It is expected to provide meaningful information/actions.

8

Type of Services in WSN

Sinknode Gateway

Core networke.g. Internet End-user

Data

Sender

Data

Receiver

A sample data communication in conventional networks

A sample data communication in WSN

Fire! Some bits01100011100

9

Requirements and challenges – Cont’d

− Quality of Service− In networks QoS usually comes from multimedia type

applications; e.g. delay, bandwidth (and often for large data)

− Here the transmitted data is small (but in large networks could be a large number of small data transmissions).

− QoS requirements depends on the application− Latency could be an important factor for time-sensitive

applications or actuation control− The packet delivery metric could be insufficient

− What is more relevant is Quality of Information that can be extracted.

10


− Fault tolerance− The nodes can get damaged, run out of power, the

wireless communication between two nodes can be interrupted, etc.

− To tolerate node failures, redundant deployments can be necessary.

− Lifetime− The nodes could have a limited energy supply;− Sometimes replacing the energy sources is not practical

(e.g. underwater deployment, large/remote field deployments).

− Energy efficient operation can be a necessity.

11


− Scalability− A WSN can consists of a large number of nodes− The employed architectures and protocols should scale

to these numbers. − Wide range of densities

− Density of the network can vary− Different applications can have different node densities− Density does not need to be homogeneous in the entire

network and network should adapt to such variations.

12


− Programmability − Nodes should be flexible and their tasks could change− The programmes should be also changeable during

operation. − Maintainability

− WSN and environment of a WSN can change;− The system should be adaptable to the changes.− The operational parameters can change to choose

different trade-offs (e.g. to provide lower quality when energy efficiency is more important)

13

Required mechanisms

− Multi-hop wireless communications− Communication over long distances can require

intermediary nodes as relay (instead of using high transmission power for long range communications).

− Energy-efficient operation− To support long lifetime− Energy efficient communication/dissemination of

information− Energy efficient determination of a requested

information− Auto-configuration

− Self-xxx functionalities− Tolerating node failures− Integrating new nodes

14

− Collaboration and in-network processing− In some applications a single sensor node is not able to handle

the given task or provide the requested information.− Instead of sending the information form various source to an

external network/node, the information can be processed in the network itself.

− e.g. data aggregation, summarisation and then propagating the processed data with reduced size (hence improving energy efficiency by reducing the amount of data to be transmitted).

− Data-centric− Conventional networks often focus on sending data between

two specific nodes each equipped with an address. − Here what is important is data and the observations and

measurements not the node that provides it.

Required mechanisms

15

Architectures (hardware and software)

− Hardware components − Examples of nodes− Energy characteristics− Operating systems and run-time environments

16

Sensor node- overview

Power supply

Communication device Controller Sensors/

Actuators

Memory

17

Example: Radiation Sensor Board (Libelium)

Source: Wireless Sensor Networks to Control Radiation Levels, David Gascón, Marcos Yarza, Libelium, April 2011.

Waspmote

18

Sensors and sensor nodes

− Active & Passive Sensors− Energy Efficiency− Processing capabilities

− e.g. Intel StrongARM (RISC, 32bit, up to 206MHz)− e.g. Texas Instrument MSP40 (RISC core, 16bit, up to

4MHz)− Network communications

− For actual communication both a transmitter and a receiver is required in a sensor node.

− Device that combined these two tasks (transmission, and receive) are called transceivers.

− Data rate: typically a few tens of kilobits per second

19

Sensor devices are becoming widely available

- Programmable devices- Off-the-shelf gadgets/tools

20

Radio-frequency identification (RFID)

− Active Tags and Passive Tags− Applications: supply chain, inventory tracking,

tools collection, etc.− Limitations:

− Technology− Reading range − Physical limitations

− Interference− Security and Privacy

21

Some of the existing solutions for sensor nodes

22

Energy consumption of the nodes

− Batteries have small capacity and recharging could be complex (if not impossible) in some cases.

− The main consumers of the energy are: the controller, radio, to some extent memory and depending on the type, the sensor(s).

− A controller can go to:− “active”, “idle” and “sleep”

− A radio modem could turn transmitter, receiver, or both on or off,

− sensors and memory can be also turned on and off.

23

Power consumption of commercial sensor nodes

Source: James M. Gilbert, Farooq Balouchi, "Comparison of Energy Harvesting Systems for Wireless Sensor Networks", International Journal of Automation and Computing, 2008

24

Comparison of Energy sources

Source: UC Berkeley, via C. Edward Chow, Wireless Sensor Network (WSN), University of Colorado

25

Power consumption: Computation vs. Communication

Source: ISI & DARPA PAC/C Program, via C. Edward Chow, Wireless Sensor Network (WSN), University of Colorado

26

Relationship between computation and communication− Communication is considerably more expensive

than computation.− However, energy required for communication can

not be ignored;− The main principle is investing into computation

within the network wherever applicable (e.g. in-network processing, aggregation) and reduce the communication. − The load of computation should still be considered.

27

Energy Management Issues

− Actuation usually uses more energy − Strategy: using ultra-low-power nodes

− Wake-up or command movement of mobile nodes− Communication energy is the next important issue

− Strategy: energy-aware data communication− Adapting the instantaneous performance to meet the timing and error rate

constraints, while minimizing energy/bit− Processor and sensor energy usually use less energy

Source: C. Edward Chow, Wireless Sensor Network (WSN), University of Colorado.

28

Operating Systems and Run-time environments

− Embedded operating systems− Virtual machines

− Abstracting the hardware specific issues from the users.− Need for energy-efficient execution− The code is more restricted (compared to

conventional operating systems) so a full-blown OS is not obviously required. − An appropriate programming model− A clear way to structure a protocol stack− And support for energy management

29

Embedded Operating Systems

− OS running on devices with restricted functionality− In the case of sensor nodes, there devices typically also

have limited processing capability− e.g. TinyOS

− Restricted to narrow applications − industrial controllers, robots, networking gear, gaming

consoles, metering, sensor nodes…− Architecture and purpose of embedded OS

changes as the hardware capabilities change (i.e. mobile phones)

Source: The Web of Things, Marko Grobelnik, Carolina Fortuna, Jožef Stefan Institute.

30

TinyOS

− “TinyOS is an open source, BSD-licensed operating system designed for low-power wireless devices, such as those used in sensor networks .”

− TinyOS applications are developed using nesC− nesC is a dialect of the C language that is

optimised for the memory limits of sensor networks.

31

TinOS - programming

− “TinyOS is completely non-blocking: − it has one stack. − All I/O operations that last longer than a few hundred

microseconds are asynchronous and have a callback. − To enable the native compiler to better optimize across

call boundaries, TinyOS uses nesC's features to link these callbacks, called events, statically.”

TinyOS home page: http://www.tinyos.net/TinyOS tutorial: http://docs.tinyos.net/tinywiki/index.php/TinyOS_Tutorials

http://www.tinyos.net/

http://docs.tinyos.net/tinywiki/index.php/TinyOS_Tutorials

32

Contiki

− Contiki is the open source operating system for the Internet of Things. − runs on networked embedded systems and wireless sensor

networks.− It is designed for microcontrollers with small amounts of

memory. A typical Contiki configuration is 2 kilobytes of RAM and 40 kilobytes of ROM.

− Contiki provides IP communication, both for IPv4 and IPv6. − It has a fully tested IPv6 stack that, combined with power-

efficient radio mechanisms such as ContikiMAC, allow battery-operated devices to participate in IPv6 networking - even routers can run on batteries.

− Contiki supports 6lowPAN header compression, IETF RPL IPv6 routing, and the IETF CoAP application layer protocol.

Source: http://www.contiki-os.org

33

Beyond conventional sensors

− Human as a sensor (citizen sensors)− e.g. tweeting real world data and/or events

− Virtual (software) sensors− e.g. Software agents/services generating/representing

data

Road block, A3

Road block, A3

Suggest a different route

34

Actuators

Stepper Motor [1]Image sources:[1] http://directory.ac/telco-motion.html[2] http://bruce.pennypacker.org/category/theater/[3] http://www.arbworx.com/services/fencing-garden-fencing/

[2]

[3]

http://directory.ac/telco-motion.html

http://bruce.pennypacker.org/category/theater/

35


Source: Protocols and Architectures for Wireless Sensor Networks, Protocols and Architectures for Wireless Sensor NetworksHolger Karl, Andreas Willig, chapter 3, Wiley, 2005 .

36

Gateway Concept

SunSpots

Information channelControl channel

Directory server

Gateway

Web user/application

Gateway/Middleware

Connectivity/Device Association Layer

Data Exchange/Interoperability Layer

Service/Application Layer

Bluetooth

WiFI

ZigBEE

CloudHyperCAT

REST API

ProprietaryCloud/Data Services H

yperCAT

HyperCAT

38

Gateway communications

39

Designing a gateway/node association protocol

Source: F. Ganz, P. Barnaghi, F. Carrez, and K. Moessner, Context-aware Management of Wireless Sensor Networks, In: The 5th Int. Conf. on COMmunication System softWAre and middlewaRE, (COMSWARE11),ACM, 2011.

40

How to say what a sensor is and what it measures?

More about this soon! in the coming slides

Sinknode

Gateway

41

Distributed WSN- Gateways and directories

42

What are the main issues?

− Heterogeneity− Interoperability− Mobility− Energy efficiency− Scalability− Security

43

Communication Protocols

− Wired − USB, Ethernet

− Wireless− Wifi, Bluetooth, ZigBee, IEEE 802.15.x

− Single-hop or multi-hop− Sink nodes, cluster heads…

− Point-to-Point or Point-to-Multi Point− (Energy) efficient routing

44

Wireless Communications

−Mostly performed in unlicensed bands according to open standards−Standard: IEEE 802.15.4 -Low Rate WPAN

−868/915 MHz bands with transfer rates of 20 and 40 kbit/s, 2450 MHz band with a rate of 250 kbit/s

−Technology: ZigBee, WirelessHART−Standard: ISO/IEC 18000-7 (standard for active

RFID)−433 MHz unlicensed spectrum with transfer

rates of 200kbit/s

Adapted from: The Web of Things, Marko Grobelnik, Carolina Fortuna, Jožef Stefan Institute.

45

Wireless Communications - continued

− Standard: IEEE 802.15.1 –High Rate WPAN − 2.40GHzbands with transfer rates of 1-24 Mbit/s− Technology: Bluetooth (BT 3.0 Low Energy Mode)

− Standard: IEEE 802.11x –WLAN − 2.4, 3.6 and 5GHz with transfer rates 15-150 Mbit/s− Technology: Wi-Fi

− Licensed bands− Standard: 3GPP –WMAN, WWAN cellular communication− 950 MHz, 1.8 and 2.1 GHz bands with data rate ranging from

20 Kbit/s to 7.2 Mbit/s, depending on the release− Technology: GPRS, HSPA


46

Wireless Communications

− Proprietary standards and protocols− Z-Wave–for home automation

− 900 MHzband (partly overlaps with 900 MHz cellular) with data rates of 9.6 Kbit/s or 40 Kbit/s

− ANT–for sportsmen and outdoor activity monitoring, owned by Garmin

− 2.4 GHz and 1 Mbit/s data rates− Wavenis–for M2M periodic low data rate communication

− 868 MHz, 915 MHz, 433 MHz with data rates from 4.8 Kbits/s to 100 Kbits/s

− most Wavenis applications communicate at 19.2 kbits/s.− MiWi, SimpliciTI, Digixxx, …


47

IEEE 802.15.4 WPAN

− IEEE standard for WPAN applications− MAC protocol

− Single channel at any one time− Combines contention-based and schedule-based

schemes− Asymmetric: nodes can assume different roles

− It does not define other higher-level layers and interoperability sub-layers are− ZigBee is built on this standard − TinyOS stack also uses some items of IEEE 802.15.4

hardware.

48

ISO/IEC 18000-7

− RFID devices operating in the 433 MHz frequency band.

− Provides an air interface implementation for wireless, non-contact information system equipments.

− Parameters for active air interface communications at 433 MHz.

− Typical applications operate at ranges greater than one meter.

ZigBee

− It is supposed to be a low cost, low power mesh network protocol.

− ZigBee operation range is in the industrial, scientific and medical radio bands;

− ZigBee’s physical layer and media access control defined in defined based on the IEEE 802.15.4 standard.

− ZigBee nodes can go from sleep to active mode in 30 ms or less, the latency can be low and in result the devices can be responsive, in particular compared to Bluetooth devices that wake-up time can be longer (typically around three seconds).

[source: Gary Legg, ZigBee: Wireless Technology for Low-Power Sensor Networks, http://www.eetimes.com/document.asp?doc_id=1275760]

http://www.eetimes.com/document.asp?doc_id=1275760

ZigBee

[source: Gary Legg, ZigBee: Wireless Technology for Low-Power Sensor Networks, http://www.eetimes.com/document.asp?doc_id=1275760]

http://www.eetimes.com/document.asp?doc_id=1275760

51

Network protocols

− The network (or OSI Layer 3 abstraction) provides an abstraction of the physical world.

− Communication protocols− Most of the IP-based communications are based on the

IPV.4 (and often via gateway middleware solutions)− IP overhead makes it inefficient for embedded devices

with low bit rate and constrained power. − However, IPv6.0 is increasingly being introduced for

embedded devices− 6LowPAN

IPv6 over Low power Wireless Personal Area Networks (6LowPAN)

− 6LoWPAN typically includes devices that work together to connect the physical environment to real-world applications, e.g., wireless sensors.

− Small packet size− the maximum physical layer packet is 127 bytes − 81 octets (81 * 8 bits) for data packets.

− Header compression− Fragmentation and reassembly

− 6LoWPAN defines a header encoding to support fragmentation when IPv6 datagrams do not fit within a single frame and compresses IPv6 headers to reduce header overhead.

− Support for both 16-bit short or IEEE 64-bit extended media access control addresses.

− Low bandwidth− Data rates of 250 kbps, 40 kbps, and 20 kbps for each of the currently

defined physical layers (2.4 GHz, 915 MHz, and 868 MHz, respectively).

Source: Jonathan W. Hui and David E. Culler, IPv6 in Low-Power Wireless Networks, Proceedings of the IEEE (Volume:98 , Issue: 11 ).

6LowPAN

− IPv6 requires the link to carry a payload of up to 1280 Bytes.

− Low-power radio links often do not support such a large payload - IEEE 802.15.4 frame only supports 127 Bytes of payload and around 80 B in the worst case (with extended addressing and full security information).

− the IPv6 base header, as shown, is relatively large at 40 Bytes.

Source: Jonathan W. Hui and David E. Culler, IPv6 in Low-Power Wireless Networks, Proceedings of the IEEE (Volume:98 , Issue: 11 ).

54

Using gateway and middleware

− It is unlikely that everything will be IP enabled and/or will run IP protocol stack

− Gateway and middleware solutions can interfaces between low-level sensor island protocols and IP-based networks.

− The gateway can also provide other components such as QoS support, caching, mechanisms to address heterogeneity and interoperability issues.

55

Gateway and IP networks

Gateway

56

In-network processing

− Mobile Ad-hoc Networks are supposed to deliver bits from one end to the other

− WSNs, on the other end, are expected to provide information, not necessarily original bits− Gives additional options− e.g., manipulate or process the data in the network

− Main example: aggregation − Applying aggregation functions to a obtain an average value of

measurement data− Typical functions: minimum, maximum, average, sum, … − Not amenable functions: median


57

In-network processing- signal processing

− Depending on application, more sophisticated processing of data can take place within the network− Example edge detection: locally exchange raw data with

neighboring nodes, compute edges, only communicate edge description to far away data sinks

− Example tracking/angle detection of signal source: Conceive of sensor nodes as a distributed microphone array, use it to compute the angle of a single source, only communicate this angle, not all the raw data

− Exploit temporal and spatial correlation− Observed signals might vary only slowly in time ! no need to

transmit all data at full rate all the time− Signals of neighboring nodes are often quite similar! only try to

transmit differences (details a bit complicated, see later)


58

In-network processing- exampleUsing Symbolic Aggregate Approximation (SAX)

SAX Pattern (blue) with word length of 20 and a vocabulary of 10 symbolsover the original sensor time-series data (green)

Source: P. Barnaghi, F. Ganz, C. Henson, A. Sheth, "Computing Perception from Sensor Data", in Proc. of the IEEE Sensors 2012, Oct. 2012.

fggfffhfffffgjhghfff

jfhiggfffhfffffgjhgi


59

Data-centric networking

− In typical networks (including ad hoc networks), network transactions are addressed to the identities of specific nodes− A “node-centric” or “address-centric” networking paradigm

− In a redundantly deployed sensor networks, specific source of an event, alarm, etc. might not be important− Redundancy: e.g., several nodes can observe the same area

− Thus: focus networking transactions on the data directly instead of their senders and transmitters ! data-centric networking − Principal design change


60

Implementation options for data-centric networking− Overlay networks & distributed hash tables (DHT)

− Hash table: content-addressable memory− Retrieve data from an unknown source, like in peer-to-peer networking

– with efficient implementation− Some disparities remain

− Static key in DHT, dynamic changes in WSN− DHTs typically ignore issues like hop count or distance between nodes

when performing a lookup operation − Publish/subscribe− Different interaction paradigm

− Nodes can publish data, can subscribe to any particular kind of data− Once data of a certain type has been published, it is delivered to all

subscribes− Subscription and publication are decoupled in time; subscriber and

published are agnostic of each other (decoupled in identity);


61

Data-centric networking for Internet content

62

Data-centric networking in WSN

− Data in WSN is transient (or at least time dependent)− Spatial feature of data− Quality of Information − In large-scale deployments, we have large number of small

information (in contrast to conventional data-centric networks that mainly focus on multimedia data)

− Data discovery (or resource discovery) is a challenge− Data annotation and description frameworks

− e.g. Semantic sensor Networks- to annotate sensor resources and observation and measurement data.

63

Other issues/concepts in WSN

− Naming and addressing− Time Synchronization− Localisation and positioning− Routing protocols− Mobility− Security/Privacy

64

Some of the security issues

− Identity management− Trade-off between security, usability, and privacy

in resource constrained devices.− Encryption and Public Key and/ or Pre-Provisioned

Symmetric Keys − Resource constraints and applicability of the existing

solutions − Privacy issues− Hijacking

65

Service interfaces to WSN

− Supporting high-level request/response interactions− Asynchronous event notifications− Identifying and accessing data

− By location, by observed entity, − By semantically meaningful representations – “Room 35BA01”

− Accessibility of in-network processing functions− Defining complex events

− Allow to specify Quality of Information requirements (e.g. accuracy & timeliness requirements)

− Accessing node/network status information (e.g., battery level)− Security, management functionality, …

− There are emerging solutions and standards in this area supported by Semantic Web technologies and Linked-data.

66

Service interfaces and Web connectivity

− WSN nodes are typically resource constrained− Memory and process limitations− Communication load

− Often none-IP or use 6LowPAN− Using gateway and middleware is a clear solution− Or can the nodes directly connect to the Web and

or support service interfaces?

67

Constrained Application Protocol (CoAp)

− CoAp is a transfer protocol for constrained nodes and networks.

− CoAp uses the Representational State Transfer (REST) architecture. − REST make information available as resources that are

identified by URIs.− Applications communication by exchanging representation of

these resources using a transfer protocol such as HTTP. − Clients access servicer controlled resources using synchronous

request/response mechanisms.− Such as GET, PUT, POST and DELETE.

− CoAp uses UDP instead of TCP and has a simple “message layer” for re-transmitting lost packets.

− It also uses compression techniques.

C. Bormann, A. P. Castellani, Z. Shelby, "CoAP: An Application Protocol for Billions of Tiny Internet Nodes," IEEE Internet Computing, vol. 16, no. 2, pp. 62-67, Feb. 2012, doi:10.1109/MIC.2012.29

68

Constrained Application Protocol (CoAp)- continued

Client

GET/temperature,Room A

Server

200 OKTxt/plain17, Celsius

CoAP protocol stack and interactions

C. Bormann, A. P. Castellani, Z. Shelby, "CoAP: An Application Protocol for Billions of Tiny Internet Nodes," IEEE Internet Computing, vol. 16, no. 2, pp. 62-67, Feb. 2012, doi:10.1109/MIC.2012.29

70

Connecting WSN nodes to Internet

71

Machine-to-Machine Communications (M2M)− What is M2M?− Design of M2M services − Networking technologies and M2M− M2M data communication− M2M Applications− Making Sense of Data − Semantic technologies and Linked-data

72

Machine-to-Machine

Machine-to-Machine (M2M) communications represent technological solutions and deployments allowing Machines, Devices or Objects to communicate with each other, with no human interactions.[source EU FP7 Exalted project]

Source: ETSI

M2M system – Key features- Support of a huge number

of devices- Seamless operability

across multiple domains- Autonomous operation- Self organisation- Power efficiency- etc., etc…

73

M2M Device Domain

− M2M Device− A device that runs application(s) using M2M capabilities and network

domain functions. − An M2M Device is either connected straight to an Access Network or

interfaced to M2M Gateways via an M2M Area Network. − M2M Area Network

− A M2M Area Network provides connectivity between M2M Devices and M2M Gateways.

− Examples of M2M Area Networks include: Personal Area Network technologies such as IEEE 802.15, SRD, UWB, Zigbee, Bluetooth, etc or local networks such as PLC, M-BUS, Wireless M-BUS.

− M2M Gateways− Equipments using M2M Capabilities to ensure M2M Devices

interworking and interconnection to the Network and Application Domain.

− The M2M Gateway may also run M2M applications.

Source: KAIST KSE, Uichin Lee, M2M and Semantic Sensor Web

74

M2M Network/Application Domain

− Network Service Capabilities− Provide functions that are shared by different

applications − Expose functionalities through a set of open interfaces − Use Core Network functionalities and simplify and

optimize applications development and deployment whilst hiding network specificities to applications

− Examples include: data storage and aggregation, unicast and multicast message delivery, etc.

− M2M Applications (Server)− Applications that run the service logic and use service

capabilities accessible via open interfaces.

Source: KAIST KSE, Uichin Lee, M2M and Semantic Sensor Web

75

More “Things” are being connected

Home/daily-life devicesBusiness and Public infrastructureHealth-care…

76

People Connecting to Things

Motion sensorMotion sensor

Motion sensor

ECG sensor

Internet

77

Things Connecting to Things

- Complex and heterogeneous resources and networks

78

Network connected Things and Devices

Image courtesy: CISCO

79

Networking technologies

− Billions of devices, subscribers, trillions of objects, − Seamless connection and integration− Cellular, WiMax, WiFi, Femto− ZigBee, IEEE 802.15.4 WPAN, …

80

3GPP Long Term Evolution (LTE)

− LTE radio access is called Evolved UMTS Terrestrial Radio Access Network (E-UTRAN)

− It is expected to substantially improve end-user throughputs and bring significantly improved user experience with full mobility.

− support for IP-based traffic with end-to-end Quality of service (QoS).

− Voice traffic is supported mainly as Voice over IP (VoIP) enabling better integration with other multimedia services.

− a new Packet Core, the Evolved Packet Core (EPC) network architecture to support the E-UTRAN.

Source: Long Term Evolution (LTE): A Technical Overview, Technical White Paper, Motorola.

81

M2MGateway

ClientApplication

M2M ApplicationM2M Area Network

M2M Architecture (ETSI)

Service Capabilities

M2MCore

Source: ETSI, via KAIST KSE, Uichin Lee, M2M and Semantic Sensor Web

Application domain Network domain M2M device domain

82

M2M architecture

Remote clients Communication networks M2M area networks

-Zigbee- Bluetooth-WiFi- …

Satellite (GPS)

GPRS, 3G, 4G, …

LAN, xDSL, …

M2M Gateway

83

Wide-Area M2M Networks

− Access network – connecting devices such as sensors and actuators:− Wired (Cable, xDSL, optical, etc.)− Wireless cellular (GSM, GPRS, EDGE, 3G, LTE, WiMAX, etc.)− Wireless capillary (Zigbee, Bluetooth, RFID, Wi-Fi, etc.)

− Gateway/Middleware – connecting the access network to the core network− Network address translation− Local device management− Traffic aggregation− etc.

− Core network – connecting the Internet− IP enabled

84

Enabling the Internet of Things

- Diversity range of applications- Interacting with large number of devices with various types-Multiple heterogeneous networks-Deluge of data

85

Key characteristics of M2M

−Inexpensive sensors equipped with a radio transceiver for various applications, typically low data rate ~ 10-250 kbps.

−Deployed in large numbers (several thousands).

−The sensors coordinate to perform the desired task.

−The acquired information (periodic or event-based) is reported back to the information processing centre (sink, BS, etc.).

−Solutions are application-dependent.

85

86

M2M Requirements− A huge number of devices i.e. many active users (~10

times more than H2H users/devices)− Low data rate (small data transmission)− Larger delay tolerance (also depends on application)− Autonomous devices− Battery life for months and years (i.e. minimum energy at a

given payload)− Low cost devices and operations− Low mobility− High security

Challenge: − Different applications have different requirements

87

Application requirements in M2M

−Smart Grid−Lower power consumption, location tracking,

reliability and long maintenance cycles−eHealth

−Service reliability, mobility, lower power consumption, lower delays

− Automotive−Mobility, location tracking

−Smart cities−Reliability, fault tolerance, delay tolerance

88

Key challenges for M2M− Scarce Resources

−Battery, Computational Power, Available Memory, Bandwidth− Extended unattended lifetime − Replacing or recharging the batteries may be impossible− Fault tolerance− Scalability− Node Addressing− Spectrum allocation and interference management− PHY issues, Medium Access Control (MAC) issues, Routing issues, E2E

Transport protocols− Security – Authentication, data integrity, robustness to attacks, etc.− Mobility − Topology Control− Data Fusion & Aggregation

88

89

“Raw data is both an oxymoron and bad data”

Geoff Bowker, 2005

Source: Kate Crawford, "Algorithmic Illusions: Hidden Biases of Big Data", Strata 2013.

90

From data to actionable information

Data

Information

Knowledge

Wisdom?

Raw sensory data

Structured data (with semantics)

Abstractions and perceptions

Actionable information

Heterogeneity, multi-modality and volume are among the key issues.

We need interoperable and machine-interpretable solutions…

91

Semantics and Data

−Data with semantic annotations−Provenance, quality of information−Interpretable formats−Links and interconnections−Background knowledge, domain

information−Hypotheses, expert knowledge −Adaptable and context-aware solutions

92

Wireless Sensor (and Actuator) Networks

Sinknode Gateway

Core networke.g. InternetGateway

End-user

Computer services

- The networks typically run Low Power Devices- Consist of one or more sensors, could be different type of sensors (or actuators)

Operating Systems?

Services?

Protocols?Protocols?

In-node Data

Processing

Data Aggregation/

Fusion

Inference/Processing of IoT data

Interoperable/Machine-

interpretablerepresentations


interpretableRepresentations?

“Web of Things”


interpretablerepresentations

94

Observation and measurement data- annotation

Tags

Data formats

Location

Source: Cosm.com

Observation and measurement data

15, C, 08:15, 51.243057, -0.589444

95

value

Unit of measurement

Time

Longitude

Latitude

How to make the data representations more machine-readable and machine-interpretable;


15, C, 08:15, 51.243057, -0.589444

96

<value>

<unit>

<Time>

<Longitude>

<Latitude>

What about this?

<value>15</value><unit>C</unit>

<time>08:15</time><longitude>51.243057</longitude>

<latitude>-0.58944</latitude>

Extensible Markup Language (XML)

− XML is a simple, flexible text format that is used for data representation and annotation.

− XML was originally designed for large-scale electronic publishing.

− XML plays a key role in the exchange of a wide variety of data on the Web and elsewhere.

− It is one of the most widely-used formats for sharing structured information.

97

XML Document Example

<?xml version="1.0"?><measurement>

<value>15</value><unit>C</unit><time>08:15</time><longitude>51.243057</longitude><latitude>-0.58944</latitude>

</measurement>

98

XML Prolog- the XML declaration

XML elements

XML documents MUST be “well

formed”

Root element

XML Document Example- with attributes<?xml version="1.0“ encoding="ISO-8859-1"?><measurement>

<value type=“Decimal”>15</value><unit>C</unit><time>08:15</time><longitude>51.243057</longitude><latitude>-0.58944</latitude>

</measurement>

99

Well Formed XML Documents

−A "Well Formed" XML document has correct XML syntax.

−XML documents must have a root element−XML elements must have a closing tag−XML tags are case sensitive−XML elements must be properly nested−XML attribute values must be quoted

100Source: W3C Schools, http://www.w3schools.com/

Validating XML Documents

−A "Valid" XML document is a "Well Formed" XML document, which conforms to the structure of the document defined in an XML Schema.

−XML Schema defines the structure and a list of defined elements for an XML document.

101

XML Schema- example

<xs:element name=“measurement">

<xs:complexType> <xs:sequence> <xs:element name=“value" type="xs:decimal"/> <xs:element name=“unit" type="xs:string"/> <xs:element name=“time" type="xs:time"/> <xs:element name=“longitude" type="xs:double"/> <xs:element name=“latitude" type="xs:double"/> </xs:sequence></xs:complexType>

</xs:element>

102

- XML Schema defines the structure and elements- An XML document then becomes an instantiation of the

document defined by the schema;

XML Documents– revisiting the example<?xml version="1.0"?><measurement>

<value>15</value><unit>C</unit><time>08:15</time><longitude>51.243057</longitude><latitude>-0.58944</latitude>

</measurement>

103

<?xml version="1.0"?> “But how about this?”

<sensor_data><reading>15</reading><u>C</u><timestamp>08:15</timestamp><long>51.243057</long><lat>-0.58944</lat>

</sensor_data>

104

XML

− Meaning of XML-Documents is intuitively clear− due to "semantic" Mark-Up− tags are domain-terms

− But, computers do not have intuition− tag-names do not provide semantics for machines.

− DTDs or XML Schema specify the structure of documents, not the meaning of the document contents

− XML lacks a semantic model− has only a "surface model”, i.e. tree

Source: Semantic Web, John Davies, BT, 2003.

XML: limitations for semantic markup

− XML representation makes no commitment on:− Domain specific ontological vocabulary

− Which words shall we use to describe a given set of concepts?− Ontological modelling primitives

− How can we combine these concepts, e.g. “car is a-kind-of (subclass-of) vehicle”

requires pre-arranged agreement on vocabulary and primitives

Only feasible for closed collaboration agents in a small & stable community

pages on a small & stable intranet.. not for sharable Web-resources

Source: Semantic Web, John Davies, BT, 2003. 105

Semantic Web technologies

− XML provide a metadata format.− It defines the elements but does not provide

any modelling primitive nor describes the meaningful relations between different elements.

− Using semantic technologies to solve these issues.

106

A bit of history

− “The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in co-operation.“ (Tim Berners-Lee et al, 2001)

107Image source: Miller 2004

Semantics & the IoT

− The Semantic Sensor (&Actuator) Web is an extension of the current Web/Internet in which information is given well-defined meaning, better enabling objects, devices and people to work in co-operation and to also enable autonomous interactions between devices and/or objects.

108

Resource Description Framework (RDF)

− A W3C standard− Relationships between documents− Consisting of triples or sentences:

− <subject, property, object>− <“Sensor”, hasType, “Temperature”>− <“Node01”, hasLocation, “Room_BA_01” >

− RDFS extends RDF with standard “ontology vocabulary”:− Class, Property− Type, subClassOf− domain, range

109

RDF for semantic annotation

− RDF provides metadata about resources− Object -> Attribute-> Value triples or− Object -> Property-> Subject− It can be represented in XML − The RDF triples form a graph

110

RDF Graph

111

xsd:decimal

Measurement

hasValuehasTime

xsd:double

xsd:time

xsd:double

xsd:string

hasLongitude hasLatitude

hasUnit

RDF Graph- an instance

112

15

Measurement#0001

hasValuehasTime

-0.589444

08:15

51.243057

C

hasLongitude hasLatitude

hasUnit

RDF/XML

<rdf:RDF><rdf:Description rdf:about=“Measurment#0001"><hasValue>15</hasValue><hasUnit>C</hasUnit><hasTime>08:15</hasTime><hasLongitude>51.243057</hasLongitude><hasLatitude>-0.589444</hasLatitude></rdf:Description>

</rdf:RDF>

113

Let’s add a bit more structure (complexity?)

114

xsd:decimal

Location

hasValue

hasTime

xsd:double

xsd:time

xsd:double

xsd:string

hasLongitude

hasLatitude

hasUnit

Measurement

hasLocation

An instance of our model

115

15

Location#0126

hasValue

hasTime

51.243057

08:15

-0.589444

C

hasLongitude

hasLatitude

hasUnit

Measurement#0001

hasLocation

RDF: Basic Ideas

−Resources−Every resource has a URI (Universal Resource

Identifier)−A URI can be a URL (a web address) or a some

other kind of identifier;−An identifier does not necessarily enable

access to a resources−We can think of a resources as an object that

we want to describe it.−Car−Person−Places, etc.

116

RDF: Basic Ideas

− Properties− Properties are special kind of resources;− Properties describe relations between resources.− For example: “hasLocation”, “hasType”, “hasID”,

“sratTime”, “deviceID”,.− Properties in RDF are also identified by URIs.− This provides a global, unique naming scheme.− For example:

− “hasLocation” can be defined as:− URI: http://www.loanr.it/ontologies/DUL.owl#hasLocation

− SPARQL is a query language for the RDF data. − SPARQL provide capabilities to query RDF graph patterns

along with their conjunctions and disjunctions.

117

http://www.loanr.it/ontologies/DUL.owl#hasLocation

Ontologies

−The term ontology is originated from philosophy. In that context it is used as the name of a subfield of philosophy, namely, the study of the nature of existence.

−In the Semantic Web:−An ontology is a formal specification of a

domain; concepts in a domain and relationships between the concepts (and some logical restrictions).

118

Ontologies and Semantic Web

− In general, an ontology describes a set of concepts in a domain.

− An ontology consists of a finite list of terms and the relationships between the terms.

− The terms denote important concepts (classes of objects) of the domain.

− For example, in a university setting, staff members, students, courses, modules, lecture theatres, and schools are some important concepts.

119

Web Ontology Language (OWL)

− RDF(S) is useful to describe the concepts and their relationships, but does not solve all possible requirements

− Complex applications may want more possibilities:− similarity and/or differences of terms (properties or

classes)− construct classes, not just name them− can a program reason about some terms? e.g.:

− each «Sensor» resource «A» has at least one «hasLocation»− each «Sensor» resource «A» has maximum one ID

− This lead to the development of Web Ontology Language or OWL.

120

OWL

− OWL provide more concepts to express meaning and semantics than XML and RDF(S)

− OWL provides more constructs for stating logical expressions such as: Equality, Property Characteristics, Property Restrictions, Restricted Cardinality, Class Intersection, Annotation Properties, Versioning, etc.

Source: http://www.w3.org/TR/owl-features/ 121

Ontology engineering

− An ontology: classes and properties (also referred to as schema ontology)

− Knowledge base: a set of individual instances of classes and their relationships

− Steps for developing an ontology:− defining classes in the ontology and arranging the

classes in a taxonomic (subclass–superclass) hierarchy− defining properties and describing allowed values and

restriction for these properties− Adding instances and individuals

Basic rules for designing ontologies

− There is no one correct way to model a domain; there are always possible alternatives. − The best solution almost always depends on the

application that you have in mind and the required scope and details.

− Ontology development is an iterative process. − The ontologies provide a sharable and extensible form to

represent a domain model.− Concepts that you choose in an ontology should

be close to physical or logical objects and relationships in your domain of interest (using meaningful nouns and verbs).

A simple methodology

1. Determine the domain and scope of the model that you want to design your ontology.2. Consider reusing existing concepts/ontologies; this will help to increase the interoperability of your ontology. 3. Enumerate important terms in the ontology; this will determine what are the key concepts that need to be defined in an ontology. 4. Define the classes and the class hierarchy; decide on the classes and the parent/child relationships5. Define the properties of classes; define the properties that relate the classes; 6. Define features of the properties; if you are going to add restriction or other OWL type restrictions/logical expressions. 7. Define/add instances

124

Semantic technologies in the IoT

−Applying semantic technologies to IoT can support: −Interoperability−effective data access and integration−resource discovery −reasoning and processing of data−knowledge extraction (for automated decision

making and management)

125

126

Data/Service description frameworks

−There are standards such as Sensor Web Enablement (SWE) set developed by the Open Geospatial Consortium that are widely being adopted in industry, government and academia.

−While such frameworks provide some interoperability, semantic technologies are increasingly seen as key enabler for integration of IoT data and broader Web information systems.

Revisiting goals of the Internet of Things

− A primary goal of interconnecting devices and collecting/processing data from them is to create situation awareness and enable applications, machines, and human users to better understand their surrounding environments.

− The understanding of a situation, or context, potentially enables services and applications to make intelligent decisions and to respond to the dynamics of their environments.

127

128

Semantic technologies − The sensors (and in general “Things”) are increasingly being

connected with Web infrastructure.− This can be supported by embedded devices that directly

support IP and web-based connection (e.g. 6LowPAN and CoAp) or devices that are connected via gateway components. − Broadening the IoT to the concept of “Web of Things”

− There are already Sensor Web Enablement (SWE) standards developed by the Open Geospatial Consortium that are widely being adopted in industry, government and academia.

− While such frameworks provide some interoperability, semantic technologies are increasingly seen as key enabler for integration of IoT data and broader Web information systems.

129129


Source: W3C Semantic Sensor Networks, SSN Ontology presentation, Laurent Lefort et al.

130

Sensor Markup Language (SensorML)

Source: http://www.mitre.org/

131

Semantics and sensor data

Source: W. Wang, P. Barnaghi, "Semantic Annotation and Reasoning for Sensor Data", In proceedings of the 4th European Conference on Smart Sensing and Context (EuroSSC2009), 2009.

132

Observation and measurement data- a semantic model

P. Barnaghi, S. Meissner, M. Presser, K. Moessner, "Sense and Sens’ability: Semantic Data Modelling for Sensor Networks", In Proc of the ICT Mobile Summit 2009, June 2009.

Semantic modelling

− Lightweight: experiences show that a lightweight ontology model that well balances expressiveness and inference complexity is more likely to be widely adopted and reused; also large number of IoT resources and huge amount of data need efficient processing

− Compatibility: an ontology needs to be consistent with those well designed, existing ontologies to ensure compatibility wherever possible.

− Modularity: modular approach to facilitate ontology evolution, extension and integration with external ontologies.

133

Existing models- SSN Ontology

− W3C Semantic Sensor Network Incubator Group’s SSN ontology (mainly for sensors and sensor networks, platforms and systems).

http://www.w3.org/2005/Incubator/ssn/

Stimulus-Sensor-Observation

- The SSO Ontology Design Pattern developed following the principle of minimal ontological commitments to make it reusable for a variety of application areas.-Introduces a minimal set of classes and relations centered around the notions of stimuli, sensor, and observations. -Defines stimuli as the (only) link to the physical environment.

135

SSN Ontology Modules

136

137

Basic Structure

138

SSN OntologyOntology Link: http://www.w3.org/2005/Incubator/ssn/ssnx/ssn

M. Compton et al, "The SSN Ontology of the W3C Semantic Sensor Network Incubator Group", Journal of Web Semantics, 2012.

139 139

W3C SSN Ontology

makes observations of

this type

Where it is

What it measures

units

SSN-XG ontologies

SSN-XG annotationsSSN-XG Ontology Scope

What SSN does not model

− Sensor types and models− Networks: communication, topology− Representation of data and units of measurement

− Location, mobility or other dynamic behaviours− Control and actuation− ….

140

Web of Things

− Integrating the real world data into the Web and providing Web-based interactions with the IoT resources is also often discussed under umbrella term of “Web of Things” (WoT).

− WoT data is not only large in scale and volume, but also continuous, with rich spatiotemporal dependency.

141

142

Example: Linked IoT Data

Internal location ontology (local)

Lined-data location(external)

143

IoT and Semantics: Challenges and issues

Several ontologies and description models

144

145

We have good models and description frameworks;

The problem is that having good models and developing ontologies is

not enough.

146

Semantic descriptions are intermediary solutions, not the end product.

They should be transparent to the end-user and probably to the data producer

as well.

A WoT/IoT Framework

WSN

WSN

WSN

WSNWSN

Network-enabled Devices

Semantically annotate data

147

GatewayCoAP

HTTP

CoAP

CoAP

HTTP

6LowPAN

Semantically annotate data

http://mynet1/snodeA23/readTemp?

WSNMQTT

MQTT

Gateway

And several other protocols and solutions…

Publishing Semantic annotations

− We need a model (ontology) – this is often the easy part for a single application.

− Interoperability between the models is a big issue.

− Express-ability vs Complexity is a challenge

− How and where to add the semantics− Where to publish and store them− Semantic descriptions for data, streams, devices

(resources) and entities that are represented by the devices, and description of the services.

148

149

Simplicity can be very useful…

Hyper/CAT

150Source: Toby Jaffey, HyperCat Consortium, http://www.hypercat.io/standard.html

- Servers provide catalogues of resources toclients.

- A catalogue is an array of URIs.- Each resource in the catalogue is annotatedwith metadata (RDF-like triples).

Hyper/CAT model

151Source: Toby Jaffey, HyperCat Consortium, http://www.hypercat.io/standard.html

152

Complex models are (sometimes) good for publishing research papers….

But they are often difficult to implement and use in real world

products.

What happens afterwards is more important

− How to index and query the annotated data− How to make the publication suitable for

constrained environments and/or allow them to scale

− How to query them (considering the fact that here we are dealing with live data and often reducing the processing time and latency is crucial)

− Linking to other sources

153

154

Data Challenges

− Discovery: finding appropriate device and data sources− Access: Availability and (open) access to M2M resources

and data− Search: querying for data− Integration: dealing with heterogeneous device, networks

and data− Interpretation: translating data to knowledge usable by

people and applications− Scalability: dealing with large number of devices and

myriad of data and computational complexity of interpreting the data.

155155

Myth and reality − #1: If we create an Ontology our data is interoperable

− Reality: there are/could be a number of ontologies for a domain− Ontology mapping − Reference ontologies − Standardisation efforts

− #2: Semantic data will make my data machine-understandable and my system will be intelligent.− Reality: it is still meta-data, machines don’t understand it but can interpret it.

It still does need intelligent processing, reasoning mechanism to process and interpret the data.

− #3: It’s a Hype! Ontologies and semantic data are too much overhead; we deal with tiny devices in IoT. − Reality: Ontologies are a way to share and agree on a common vocabulary

and knowledge; at the same time there are machine-interpretable and represented in interoperable and re-usable forms;

− You don’t necessarily need to add semantic metadata in the source- it could be added to the data at a later stage (e.g. in a gateway);

− Legacy applications can ignore it or to be extended to work with it.

156

Semantics and Linked-data

− The principles in designing the linked data are defined as:− using URI’s as names for things;− using HTTP URI’s to enable people to look up those

names;− provide useful RDF information related to URI’s that are

looked up by machine or people;− including RDF statements that link to other URI’s to

enable discovery of other related concepts of the Web of Data;

157157

Linked-data

Linked data is data presented in a better way and in relation to other resources…

158

Linked Sensor data

159

Linked Open DataCollectively, the 203 data sets consist of over 25 billion RDF triples, which are interlinked by around 395 million RDF links (September 2010).

160

Creating and using Linked Sensor Data

161

Linked sensor data

162

Smart-Campus Infrastructure

User devices

Core Network by FI platform

USBEthernet

Ethernet802.15.4

Smart Campus Service platformIoT

devices

GW devices

Bluetooth

Bluetooth

Wifi, Ethernet

Display infrastructure

Wifi, Ethernet

GW devices

Indoor IoT deployments

• Smart Transportation• Smart Waste Management• Environmental Monitoring

Outdoor IoT deployments

• Intelligent offices spaces

Sustainable Campus using Internet of Things Technologies

Source: A. Gluhak et al, CCSR, University of Surrey, 2012.

163

IoT Data Access

− Publish/Subscribe (long-term/short-term)− Ad-hoc query− The typical types of data request for sensory data:

− Query based on− ID (resource/service) – for known resources− Location− Type− Time – requests for freshness data or historical data; − One of the above + a range [+ Unit of Measurement]− Type/Location/Time + A combination of Quality of Information

attributes − An entity of interest (a feature of an entity on interest)− Complex Data Types (e.g. pollution data could be a combination of

different types)

Comparing IoT data streams with conventionalmultimedia streams

Source: P. Barnaghi, W. Wang, L. Dong, C. Wang, "A Linked-data Model for Semantic Sensor Streams", in the Proc. of

IEEE International Conference on Internet of Things (iThings 2013), August 2013.

165

Describing IoT Data: An example

Time

Location

Type

Value

Link to QoI metadata

UTC

#GeoHash

#Hash

[DataType, Value]

URI

Ontology for common

types

166

Observation and Measurement Value

GeoHash

UTC time

UTC time (in Java) : The time indicated is returned represented as the distance, measured in milliseconds, of that time from the epoch (00:00:00 GMT on January 1, 1970).

Standard XSD data type

167

GeoHashing

− For example Guildford: lat: 51.235401 and long: -0.574600 can be hashed as: gcpe6zjeffgp

− It can be used as:− A unique identifier − represent point data as hash string

− It uses Base 32 encoding and bit interleaving − It’s used for geo-tagging (and is a symmetric technique)− Place close to each other will have similar prefix (string similarity) − Limitations:

− We could have Geohash codes with no common prefix − Edge case (locations close to each other but on opposite sides of the

Equator)− A meridian point (line of longitude)

http://geohash.org/gcpe6zjeffgp

168

GeoHash Example

Sample locations on a Google Map and theirequivalent geohash strings; - close locations have similar prefixes

IoT Data Processing

WSN

WSN

WSN

WSNWSN



Network services/storage and processing

units Data/service access at

application level

Data collections and processing

within the networks

Data Discovery

Service/Resource Discovery

Data Aggregation − Computing a smaller representation of a number of data

items (or messages) that is extracted from all the individual data items.

− For example computing min/max or mean of sensor data.

− More advance aggregation solutions could use approximation techniques to transform high-dimensionality data to lower-dimensionality abstractions/representations.

− The aggregated data can be smaller in size, represent patterns/abstractions; so in multi-hop networks, nodes can receive data form other node and aggregate them before forwarding them to a sink or gateway.

− Or the aggregation can happen on a sink/gateway node.

Aggregation example

− Reduce number of transmitted bits/packets by applying an aggregation function in the network

1

1

31

1

6

1

1

11

1

1

Source: Holger Karl, Andreas Willig, Protocols and Architectures for Wireless Sensor Networks, Protocols and Architectures for Wireless Sensor Networks, chapter 3, Wiley, 2005 .

Efficacy of an aggregation mechanism − Accuracy: difference between the resulting value or

representation and the original data− Some solutions can be lossless or lossly depending on the

applied techniques. − Completeness: the percentage of all the data items that are

included in the computation of the aggregated data.− Latency: delay time to compute and report the aggregated

data− Computation foot-print; complexity;

− Overhead: the main advantage of the aggregation is reducing the size of the data representation;− Aggregation functions can trade-off between accuracy, latency

and overhead;

− Aggregation should happen close to the source.

Publish/Subscribe

− Achieved by publish/subscribe paradigm− Idea: Entities can publish data under certain names− Entities can subscribe to updates of such named data

− Conceptually: Implemented by a software bus− Software bus stores subscriptions, published data; names used

as filters; subscribers notified when values of named data changes

Software bus

Publisher 1 Publisher 2

Subscriber 1 Subscriber 2 Subscriber 3

− Variations− Topic-based P/S –

inflexible − Content-based

P/S – use general predicates over

named data

Source: Holger Karl, Andreas Willig, Protocols and Architectures for Wireless Sensor Networks, Protocols and Architectures for Wireless Sensor Networks, chapter 12, Wiley, 2005 .

MQTT Pub/Sub Protocol− MQ Telemetry Transport (MQTT) is a lightweight broker-based

publish/subscribe messaging protocol. − MQTT is designed to be open, simple, lightweight and easy to

implement. − These characteristics make MQTT ideal for use in

constrained environments, for example in IoT. −Where the network is expensive, has low bandwidth or

is unreliable −When run on an embedded device with limited

processor or memory resources;− A small transport overhead (the fixed-length header is just 2

bytes), and protocol exchanges minimised to reduce network traffic

− MQTT was developed by Andy Stanford-Clark of IBM, and Arlen Nipper of Cirrus Link Solutions.

Source: MQTT V3.1 Protocol Specification, IBM, http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html

MQTT− It supports publish/subscribe message pattern to provide one-to-many

message distribution and decoupling of applications − A messaging transport that is agnostic to the content of the payload − The use of TCP/IP to provide basic network connectivity − Three qualities of service for message delivery:

− "At most once", where messages are delivered according to the best efforts of the underlying TCP/IP network. Message loss or duplication can occur.

− This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published soon after.

− "At least once", where messages are assured to arrive but duplicates may occur.

− "Exactly once", where message are assured to arrive exactly once. This level could be used, for example, with billing systems where duplicate or lost messages could lead to incorrect charges being applied.


MQTT Message Format− The message header for each MQTT command message

contains a fixed header. − Some messages also require a variable header and a payload. − The format for each part of the message header:


— DUP: Duplicate delivery— QoS: Quality of Service— RETAIN: RETAIN flag

—This flag is only used on PUBLISH messages. When a client sends a PUBLISH to a server, if the Retain flag is set (1), the server should hold on to the message after it has been delivered to the current subscribers.—This allows new subscribers to instantly receive data with the retained, or Last Known Good, value.

Sensor Data as time-series data− The sensor data (or IoT data in general) can be

seen as time-series data. − A sensor stream refers to a source that provide

sensor data over time. − The data can be sampled/collected at a rate (can

be also variable) and is sent as a series of values. − Over time, there will be a large number of data

items collected. − Using time-series processing techniques can help

to reduce the size of the data that is communicated; −Let’s remember, communication can consume

more energy than communication;

Sensor Data as time-series data

− Different representation method that introduced for time-series data can be applied.

− The goal is to reduce the dimensionality (and size) of the data, to find patterns, detect anomalies, to query similar data;

− Dimensionality reduction techniques transform a data series with n items to a representation with w items where w < n.− This functions are often lossy in comparison with solutions like

normal compression that preserve all the data. − One of these techniques is called Symbolic Aggregation

Approximation (SAX).− SAX was originally proposed for symbolic representation of time-

series data; it can be also used for symbolic representation of time-series sensor measurements.

− The computational foot-print of SAX is low; so it can be also used as a an in-network processing technique.

179

In-network processingUsing Symbolic Aggregate Approximation (SAX)

SAX Pattern (blue) with word length of 20 and a vocabulary of 10 symbolsover the original sensor time-series data (green)

Source: P. Barnaghi, F. Ganz, C. Henson, A. Sheth, "Computing Perception from Sensor Data", in Proc. of the IEEE Sensors 2012, Oct. 2012.


jfhiggfffhfffffgjhgi


Symbolic Aggregate Approximation (SAX)− SAX transforms time-series data into symbolic string representations. − Symbolic Aggregate approXimation was proposed by Jessica Lin et al

at the University of California –Riverside;− http://www.cs.ucr.edu/~eamonn/SAX.htm .

− It extends Piecewise Aggregate Approximation (PAA) symbolic representation approach.

− SAX algorithm is interesting for in-network processing in WSN because of its simplicity and low computational complexity.

− SAX provides reasonable sensitivity and selectivity in representing the data.

− The use of a symbolic representation makes it possible to use several other algorithms and techniques to process/utilise SAX representations such as hashing, pattern matching, suffix trees etc.

Processing Steps in SAX− SAX transforms a time-series X of length n into

the string of arbitrary length, where typically, using an alphabet A of size a > 2.

− The SAX algorithm has two main steps: −Transforming the original time-series into a PAA

representation−Converting the PAA intermediate

representation into a string during. − The string representations can be used for

pattern matching, distance measurements, outlier detection, etc.

Piecewise Aggregate Approximation

− In PAA, to reduce the time series from n dimensions to w dimensions, the data is divided into w equal sized “frames.”

− The mean value of the data falling within a frame is calculated and a vector of these values becomes the data-reduced representation.

− Before applying PAA, each time series to have a needs to be normalised to achieve a mean of zero and a standard deviation of one.−The reason is to avoid comparing time series

with different offsets and amplitudes;

Source: Jessica Lin, Eamonn Keogh, Stefano Lonardi, and Bill Chiu. 2003. A symbolic representation of time series, with implications for streaming algorithms. In Proceedings of the 8th ACM SIGMOD workshop on Research issues in data mining and knowledge

discovery (DMKD '03). ACM, New York, NY, USA, 2-11.

SAX- normalisation before PAA

Timeseries (c): 2, 3, 4.5, 7.6, 4, 2, 2, 2, 3, 1

Mean (μ): μ= (2+3+4.5+7.6+4+2+2+2+3+1)/10= 3.11

Standard deviation (σ): (2-3.11)2 = 1.2321(3-3.11)2 = 0.0121(4.5-3.11)2 = 1.9321(7.6-3.11)2 = 20.1601(4-3.11)2 = 0.7921(2-3.11)2 = 1.2321(2-3.11)2 = 1.2321(2-3.11)2 = 1.2321(3-3.11)2 = 0.0121(1-3.11)2 = 4.4521

1.2321+0.0121+ 1.9321+ 20.1601+ 0.7921+ 1.2321+ 1.2321+ 1.2321+ 1.2321+ 0.0121+4.4521 = 33.5211

σ = √ (33.5211/10) = 1.83087683911

NormalisationTimeseries (c): 2, 3, 4.5, 7.6, 4, 2, 2, 2, 3, 1

Normalised: zi = (ci – μ)/ σ

σ = 1.83087683911μ = 3.11z1 = (2- 3.11)/1.83087683911 = -0.606z2 = (3-3.11)/ 1.83087683911= -0.600z3 = (4.5-3.11)/ 1.83087683911= 2.452z4 = (7.6-3.11)/ 1.83087683911= -0.600z5 = (4-3.11)/ 1.83087683911= 0.486z6 = (2-3.11)/ 1.83087683911= -0.606z7 = (2-3.11)/ 1.83087683911= -0.606z8 = (2-3.11)/ 1.83087683911= -0.606z9 = (3-3.11)/ 1.83087683911= -0.600z10 = (1-3.11)/ 1.83087683911= -1.152

Normalised Timeseries (z): -0.606, -0.600, 2.452, -0.600, 0.486, -0.606, -0.606, -0.606 , -0.600, -1.152

PAA calculation

Timeseries (c): 2, 3, 4.5, 7.6, 4, 2, 2, 2, 3, 1Normalised Timeseries (z): -0.606, -0.600, 2.452, -

0.600, 0.486, -0.606, -0.606, -0.606 , -0.600, -1.152

PAA (w=5): -0.603, 0.926, -0.06, -0.606, 0.273

PAA to SAX Conversion

− Conversion of the PAA representation of a time-series into SAX is based on producing symbols that correspond to the time-series features with equal probability.

− The SAX developers have shown that time-series which are normalised (zero mean and standard deviation of 1) follow a Normal distribution (Gaussian distribution).

− The SAX method introduces breakpoints that divides the PAA representation to equal sections and assigns an alphabet for each section.− For defining breakpoints, Normal inverse cumulative

distribution function

Breakpoints in SAX

− “Breakpoints: breakpoints are a sorted list of numbers B = β 1,…, β a-1 such that the area under a N(0,1) Gaussian curve from βi to βi+1 = 1/a”.

Source: Jessica Lin, Eamonn Keogh, Stefano Lonardi, and Bill Chiu. 2003. A symbolic representation of time series, with implications for streaming algorithms. In Proceedings of the 8th ACM SIGMOD workshop on Research issues in data mining and knowledge discovery (DMKD '03).

ACM, New York, NY, USA, 2-11.

Alphabet representation in SAX

− Let’s assume that we will have 4 symbols alphabet: a,b,c,d

− As shown in the table in the previous slide, the cut lines for this alphabet (also shown as the thin red lines on the plot below) will be { -0.67, 0, 0.67 }

Source: JMOTIF Time series mining, http://code.google.com/p/jmotif/wiki/SAX

SAX Represetantion

Timeseries (c): 2, 3, 4.5, 7.6, 4, 2, 2, 2, 3, 1Normalised Timeseries (z): -0.606, -0.600,

2.452, -0.600, 0.486, -0.606, -0.606, -0.606 , -0.600, -1.152

PAA (w=5): -0.603, 0.926, -0.06, -0.606, 0.273

Cut off ranges: {-0.67, 0, 0.67}Alphabet: a ,b ,c, d

SAX representation: bdbbc

Features of the SAX technique− SAX divides a time series data into equal

segments and then creates a string representation for each segment.

− The SAX patterns create the lower-level abstractions that are used to create the higher-level interpretation of the underlying data.

− The string representation of the SAX mechanism enables to compare the patterns using a specific type of string similarity function.

191

A sample data processing framework


dddfffffffffffddd

cccddddccccdddccc

aaaacccaaaaaaaacccc

dddcdcdcdcddasddd

PIR Sensor Light Sensor Temperature Sensor

Raw sensor data stream



Attendance Phone

Hot Temperatur

e Cold

Temperature Bright

Day-timeNight-time

Office room

BA0121

On going meeting

Window has been left

open

….

Temporal data

(extracted from descriptions)

Spatial data(extracted from

descriptions)

Thematic data

(low level abstractions

)

Intelligent Processing

Observations

High-level abstractions

Domain knowledge

SAX Patterns

Raw sensor data(or Annotated data)

…

….

Intelligent Processing/Reasoning

High-level information/knowledge

192

Summary

− Wireless Sensor Networks − Communication− Networks− Middleware/gateway− Service/application layer− 6LowPAN and CoAp

− Machine-to-machine communication− M2M architecture− M2M networks− Applications− Semantic technologies

− Machine-interpretable data for automated processing, − Modelling and annotation − Linked-data

193

Some related books

194

Links and further Reading− ETSI, Machine to Machine Communications

− http://www.etsi.org/technologies-clusters/technologies/m2m− Machine-to-Machine Communications, OECD Library,

− http://www.oecd-ilibrary.org/science-and-technology/machine-to-machine-communications_5k9gsh2gp043-en

− Internet of Things, ITU− http://www.itu.int/osg/spu/publications/internetofthings/InternetofT

hings_summary.pdf− IoT Comic Book

− http://www.theinternetofthings.eu/content/mirko-presser-iot-comic-book− W3C Semantic Sensor Networks

− http://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/

http://www.etsi.org/technologies-clusters/technologies/m2m

http://www.oecd-ilibrary.org/science-and-technology/machine-to-machine-communications_5k9gsh2gp043-en

http://www.oecd-ilibrary.org/science-and-technology/machine-to-machine-communications_5k9gsh2gp043-en

http://www.itu.int/osg/spu/publications/internetofthings/InternetofThings_summary.pdf

http://www.itu.int/osg/spu/publications/internetofthings/InternetofThings_summary.pdf

http://www.theinternetofthings.eu/content/mirko-presser-iot-comic-book

http://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/

195

Acknowledgments

− Protocols and Architectures for Wireless Sensor Networks, Protocols and Architectures for Wireless Sensor Networks, Holger Karl, Andreas Willig, Wiley, 2005 .

− Dave Evans, The Internet of Things: How the Next Evolution of the Internet Is Changing Everything, Cisco, April 2011.

− The Web of Things, Marko Grobelnik, Carolina Fortuna, Jožef Stefan Institute, Slovenia.

Acknowledgements

− Some parts of the content are adapted from:− Holger Karl, Andreas Willig, Protocols and Architectures for

Wireless Sensor Networks, Protocols and Architectures for Wireless Sensor Networks, chapters 3 and 12, Wiley, 2005 .

− Jessica Lin, Eamonn Keogh, Stefano Lonardi, and Bill Chiu. 2003. A symbolic representation of time series, with implications for streaming algorithms. In Proceedings of the 8th ACM SIGMOD workshop on Research issues in data mining and knowledge discovery (DMKD '03). ACM, New York, NY, USA, 2-11.

− JMOTIF Time series mining, http://code.google.com/p/jmotif/wiki/SAX

Q&A

Education

Internet of Things: Concepts and Technologies